A very good short 6min video explaining how and why you should aim for high cohesion and loose coupling!
And this video 57min video with all the stars :) discussing this topic more in detail.
Alan Kay at OOPSLA 1997 - The computer revolution hasnt happened yet The notes for it http://www.cc.gatech.edu/fac/mark.guzdial/squeak/oopsla.html http://c2.com/cgi/wiki?TheComputerRevolutionHasntHappenedYet
These are great words by Alan Kay and they are not so young and still so true. And I am only close to the beginning of really understanding. But I have to, as usual, extract some of the key points for me. Make sure to read the entire message anyways, it’s really very short!
I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is “messaging” - that is what the kernal of Smalltalk/Squeak is all about (and it’s something that was never quite completed in our Xerox PARC phase).
This just means: make sure to understand how he means OO should be done. Need a starting point? Read poodr and listen to Sandi Metz‘s various talks findable online.
Inherently, once scratched on the surface of what OO means and reading about object calisthenics the question what is inheritance will stick out.
And Alan Key writes about it:
I would say that a system that allowed other metathings to be done in the ordinary course of programming (like changing what inheritance means, or what is an instance) is a bad design.
Two questions are raised here: 1) What does inheritance mean? 2) What is an instance?
/me has to go and read and answer those … And work on improving what he calls to be
Given the current low state of programming in general
(which I understand as: most programming done nowadays is “bad” [that’s how I interpret “low state”] - maybe I am wrong)
I have been titled as a Sandi Metz fanboy, I am :). I use “send to” and “plays the role” since I read her book poodr.
If you are looking for actionable hints about how to do OO right, remember those four:
Isolate the thing that varies
Name the concept
Define the role
Inject the players
more info you find in her railsconf talk linked below where she talks about
Inheritance is for specialization, not for sharing code
and find here why
the IF keeps us from thinking OO
I also like to quote her on
Inheritance is a knife that turns in your hand
browserfield in npm’s package.json
The browser field is where the module author can hint to the bundler which elements (other modules or source files) need to be replaced when packaging.
Read this file for all the details.
Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback (think IDE and OS rolled into one).
In the discussion about refactoring etc. at the Agile Tuesday someone mentioned Pharo which is supposed to be quite advanced in all things, just as the quote above mentions. Just watching the first 10min of this video was enough to be convinced that this looks really interesting, I am adding it to my “must look at” list :).
The new dojo? I started with dojo about 10 years ago, or so. Now I see reapp which seems to be the same as dojo, lots of widgets, just around react and transfered 10 years ahead and to mobile.
Good stuff? Or not?
With typeslab.com you can write poster like text.
Another pearl by @KevlinHenney in his Functional Programming You Already Know is his explaination of why we actually should leave out prefixes to our functions, such as
set. At the same time he explains better object-orientation and a more functional style.
“get” is an imperative word, it’s a noise word. But it’s an imperative. If you want to start thinking about things in an non-imperative way, stop using imperative words.
The words influence the way you think.
And in case you are also wondering, like me, what “imperative” really means, here is wikipedia’s explaination
imperative programming is a programming paradigm that describes computation in terms of statements that change a program state
And as Kevlin explains some seconds later, very well: “get” means to change something (or move around). Either 1) move money from one account to another or 2) change or move your marital state from single to married. But getting a year from a
Date object does not move/change anything.
@KevlinHenney is always worth watching, so there is Functional Programming You Already Know by him. I would like to extract this one piece where he explains decoupling in a, ask I think, great way. He says:
Let me translate “does not care” into computer science language. “Does not care” means decoupling.
Nothing to add to this post
Many modules […] encourage you to globally install them. This is a fragile practice as you might have multiple projects with dependencies on different versions of the same module. Rule of thumb: do not install Node packages globally if you can reasonably avoid it. You can almost always reasonably avoid it.
The site states that it is this:
Zero-bullshit, single–command, bring your own source control web publishing CDN.
On the blog post it revelas a bit more interesting information, imho.
Existing publishing solutions such as Github Pages and Amazon S3 were developed prior to the recent changes in client-side web development practices and thus didn’t have front-end developers in mind when they were built. These services leave a lot to be desired when it comes to deploying static web projects.
Now I expect to find what it can do beyond gh-pages, etc. And that’s what it says.
With surge you effortlessly get things like…
- Custom 404.html files.
- Catch-all 200.html files (for PushState apps).
- Indifferent (intelligently) about trailing slashes (“/”).
- Clean URLs (indifferent about trailing .html).
- Far-future expire headers.
- Easy collaboration built right in.
To me all this seems like something that gh-pages can do too, it just requires a bit of setup. What do I miss? I guess I just expected much more :).
I am sure my partner @Tobias posted this link in our internal flowdock (never used it? do it now! it’s Slack in better). @Tobias knows all the tools.
And we at uxebu are not so big grunt, gulp, etc. fans we rather let npm do the jobs that it just does well, so here are some pieces extracted from a great article about how to use npm as build tool.
This pretty much summarizes what you are going to read, if you follow this link.
some developers were brazen enough to present me with a Gruntfile and say “how could this be done in npm?!”. I thought I’d pull out how-tos from the original draft and make a new post, just focussing on how to do these common tasks with npm.
Windows always comes in the way again, there are some good tips here how to work around it.
1) Rather than relying on built in commands, you could simply use alternatives - for example instead of using rm, use the npm rimraf package.
2) Rather than trying to use syntax that is not cross compatible, stick to just the above ones. You’d be surprised just how much you can get done with just &&, >, |, and <.
** deciphered, for me :)
such as *.js and expand the stars out as wildcards. Using two stars allows it to search recursively.
Version bumping is baked into NPM.
This actually comes baked into npm (it is a package manager after all). Simply run npm version patch to increment the patch number (e.g. 1.1.1 -> 1.1.2), npm version minor to increment the minor version number (e.g. 1.1.1 -> 1.2.0) or npm version major (e.g. 1.1.1 -> 2.0.0).
Another tool I have to look at!? Just found via this article.
I first heard @bodil talk at the 2014 craftconf in Budapest where I saw her presentation where she was live coding in at least 10 languages on stage. Of course I started following her on twitter back then and from time to time I recap her tweets just to see what other interesting are out there in the world of functional stuff that I should look at. And there surely is always enough of it that I either never have heard of or that will cost me another couple of unplanned days to dive into in order to not feel so stupid anymore :).
Another thing she just posted, I guess preparing for another talk, is µkanrens. They are inspired by minikanren
an embedded Domain Specific Language for logic programming.
I actually came across because I was once again hunting ES6 stuff. And found some beautiful code in her repo. And I had thought I used many of the new ES6 features :).
A nice read about DVCSes, let me mention here the two things I like best. 1) Is about the feeling I still have when working with git :)
Here’s a tip: if you say something’s hard, and everyone starts screaming at you—sometimes literally—that it’s easy, then it’s really hard. The people yelling at you are trying desperately to pretend like it was easy so they don’t feel like an idiot for how long it took them to figure things out. This in turn makes you feel like an idiot for taking so long to grasp the “easy” concept, so you happily pay it forward, and we come to one of the two great Emperor Has No Clothes moments in computing.
And 2) towards the end of the article, make sure to read the comparison of contributing before we had git pull requests and today with github PRs. In short, it used to be 5 steps vs. 9 steps nowadays and quite a lot more knowledge we need to contribute via PRs.
Excuse me, I have to go back and install mercurial now :).
How to be a great software developer is a looong read, but it’s worth reading, since it contains lots of truths.
Refactoring is by far the most underevaluated technique of working. I mostly get the impression we like to rewrite and start on the green field. But how can the (mostly hidden) value that is there in some source code survive if we throw it away? Therefore …
Start with something ugly but functional and then apply and reapply yourself to that ugly and misshapen solution and refactor it back into its simplest form.
And the goal of reafactoring is to make the thing the source does simple.
Simplicity comes far more reliably from work than from brilliance. It comes more predictably from code written, than from thought expended. It comes from effort.
Go learn how to write better code, if you can’t learn how to make the ugly code you wrote nicer.
Your code has two functions: the first is its immediate job. The second is to get out of the way of everyone who comes after you and it should therefore always be optimised for readability and resilience.
Lazily written code slows you down, increases cycle times, releases bugs and pisses everyone off.
Just discussed the last two days what are the right tests to write, etc. and here comes the summary in short:
There is no intuitive answer to what the right amount of testing is. Take the time to understand what really needs tests and how to write good tests. Take the time to see when tests add value and what the least you need from them really is.
I think this is a collection of funny accidents that I have to remember, might come in handy for a next slide set.
Any browser project should have a look at DOMPurify at least, if not apply it right away. This might not be what you want to apply right away, but maybe it triggers you to learn more about this field, when security issues hit you it might be too late.
DOMPurify is a DOM-only, super-fast, uber-tolerant XSS sanitizer for HTML, MathML and SVG.
DOMPurify is written by security people who have vast background in web attacks and XSS.
For TDDBin I was just looking for all the icons to use on the website, icons from github, trello and twitter to embed them. And I found out that the collection of those images/graphics are called brand assets. Next time you search for them, don’t use the term logo, use “brand assets”.
This is a great talk by @KevlinHenney
When people write tests, they write less code.
Take a step back and try to look at the code from your colleagues perspective 27:
If I think it’s difficult to use, what do the others think?
He says about the question if tests slow you down 28:
Yes, tests are your breaks. They will allow you to go faster, for the very reason they slow you down.
It’s not additional synthesis, as I would interpret the headline first, but it’s pretty hard core cool what is possible in the browser already. See this the “Quick ‘n’ easy game sound effects generator.” including source code.
I wanted to just push my source code to github’s master branch and all the deployment after that shall be automatic. Every dev-op reading this will say “yeah sure, wtf?”. To make it a bit simpler, I have a pure client-side app, in this case http://tddbin.com. So I started searching and tweeting.
It all started with this tweet and the initial help from Stephan Then I worked through this article, which is actually wrong where it states the
travis-encrypt call. In short it has to be like this:
travis-encrypt -r tddbin/tddbin-frontend GH_TOKEN=<the token github gave you> and everything behind the repo name will be encrypted, you can also add multiple env vars and then use them. Just like I did it on tddbin. In order to have the env vars you encoded available you need to put the encrypted secret into the .travis.yml file.
I don’t get mocha to build with browserify, I always get
Error: Cannot find module '../suite' from '/Users/me/tddbin-frontend/node_modules/mocha'
The problems mentioned in those issues seem to have no solution provided yet. It seems that browserify picks up a built
mocha.js and can’t handle some magic done in there.
My solution for now is to use mocha from the CDN, which might not work in all use cases, but does for me now.
A Coding Dojo with @XaV1uzz doing the Kata Mars Rover and another one where he shows how to refactor the bowling kata to patterns. They are both in spanish!
As often as I look for this, I need to write it down. For example for my fork of github:dropping-spray, which got inspired by this tweet and the following discussion.
> # 1 - add the (so called) upstream repo so you can refer to it locally > git remote add upstream email@example.com:Narigo/dropping-spray.git > #2 - just double check it's there > git remote -v origin firstname.lastname@example.org:wolframkriesing/dropping-spray.git (fetch) origin email@example.com:wolframkriesing/dropping-spray.git (push) upstream firstname.lastname@example.org:Narigo/dropping-spray.git (fetch) upstream email@example.com:Narigo/dropping-spray.git (push) > # 3 - get up to date, I think in the flow as listed here its not needed, we are quite up to date > git fetch upstream > # 4 - fianlly merge in the latest stuff from the original repo > git merge upstream/gh-pages
As you can see above, I merged the
gh-pages branch and not
This is a very nice interview (video) with JB Rainsberger and Corey Haines, two of the people I closely follow and try to learn from as much as I can.
They are talking about the passion of being a programmer, how to become one and how they think that a programmer can become better. They share a lot of personal experience. Well worth your time.
If you want to dive into cookies, here is the RFC6265. I was looking around for some decent cookie libraries. There seem to be some of them. And it is very irritating that some are as young as from last year. I thought this topic is old enough so that there is one standard solution and done. But I seem to be wrong. What all of them have in common is their quality of testing is quite interesting. From nothing at all to hard core integration tests. Lot’s of potential for refactoring projects.
The simplest cookie lib ever, I guess. Also great for understanding cookies well, if it is complete - I don’t know.
cookie is a basic cookie parser and serializer. It doesn’t make assumptions about how you are going to deal with your cookies. It basically just provides a way to read and write the HTTP cookie headers.
Basically the same feature set as the one above, though I really like the API, it’s so close to the request/response.
A very simple cookie manager
Seems to be pretty complex. Uses Keygrip underneath, so the actual lib is quite small.
Cookies is a node.js module for getting and setting HTTP(S) cookies. Cookies can be signed to prevent tampering, using Keygrip. It can be used with the built-in node.js HTTP library, or as Connect/Express middleware.
The biggest one, that even implements cookieJar (a way to bundle and kinda anonymize/hide cookies).
RFC6265 Cookies and CookieJar for Node.js
I don’t know why shelljs hasn’t found me earlier :(
[Update 2014-02-11] well it’s not really all bash can do, it just imitates the interface using JS as the language. I was looking for the REPL. Well start
> node and there is the REPL :). So I played with it. Not as powerful and far from a replacement for bash but it spins quite some ideas.
is a post by Adrian Bolboaca
The rule of three says:
Extract duplication only when you see it the third time.
I asked myself what branch rebase refers to. The one I want to rebase on or the one I want to rebase from?
Also notice that, like the git merge command, git rebase requires you to be on the branch that you want to move.
Thanks to the great Rebasing article I know now :). (And store it here, to know where to look it up).
In short. If I want to get my branch
about to be back on top of master, I have to rebase it onto master, like this:
git checkout about git rebase master
As with everything, behave when rebasing! I believe that rebase is not meant for all situations. Sometimes it is much better to have a history visible in the commit history.
While reading about naming classes, etc. I came across the obligatory c2 wiki article and many more
Life without a controller, case 1 by [@CarloPescio]
Listen to your tools and materials one of the many papers by [@CarloPescio]
The early history of smalltalk
Execution in the Kingdom of Nouns by Steve Yegge
Ask not what an object is, but… by [@CarloPescio]
It Is Possible to Do Object-Oriented Programming in Java by @KevlinHenney
Linked in the comments of this I found another great article, which I just have to quote.
Unlike other disciplines, software development shows little interest for classics. Most people are more attracted by recent works. Who cares about some 20 years old paper when you can play with Node.js?
a vision of objects like little virtual machines, offering specialized services. Objects were meant to be smart. Hide data, expose behavior. It’s more than that: Alan is very explicit about the idea of methods as goals, something you want to happen, unconcerned about how it is going to happen.
It is unfortunate that much of what is called “object-oriented programming” today is simply old style programming with fancier constructs
Is he talking about me? I am trying hard!!!
Software development is about discovering and encoding knowledge. Now, humans have relatively few ways to encode knowledge: a fundamental strategy is to name things and concepts.
Good wrap-up of why naming is hard.
If you can’t find a proper name for the class, try naming functions. Look at those functions. What is keeping them together? You can apply them to… that’s the class name :-)
I have to remember that. Maybe that could be a good session for a JSCodeRetreat, finding class names.
Handler, again, is an obvious resurrection of procedural thinking. What is an handler if not a damn procedure? Why do something need to be “handled” in the first place? Oh, I know, you’re thinking of events, but even in that case, EventTarget, or even plain Target, is a much better abstraction than EventHandler.
Ouch, that hurt. I still catch me wanting to write various Handlers. I like the EventHandler example.
I was about to write a “Handler” class. But I remembered that the “er” classes are not so good. And I mean, think about it. Even if it is a
RequestHandler it still can do lots of things and can have many reasons to change, which breaks the Single Responsibility Principle. So I searched for it and found this article.
the jst of OOP is that we bind behavior to data
in nearly every “er” object case, there was a better name for it. And that giving it a better name would tend to make the design more encapsulated, less spaghetti code, in short more object oriented
now we are getting to the meat :)
Take some sort of “Loader” for example. The focus here is on the unit of work it does. […] Now instead replace that with a LoadRecord and a LoadStream. I’m reasonably confident you’ll end up with something that is more akin to what the original Founding Fathers of OOP had in mind.
A simple example: Loader => LoadRecord
Until you apply the mindset for a while though, you’ll never really know.
That is so true for a lot of things, and also a good reason why I do believe that katas have a value.
Just read the article, it’s quite short and compact but has some nice examples in it.
a talk by Chad Fowler
Software gets too complex, tests slow, test coverage doesn’t make you feel good, so you deploy less. The less often you deploy the scarrier it becomes.
I was just about to quote him on
comments are a code smell, there is just no way to validate them
which I strongly agree on. And just one sentence later he says this
Tests are also a design smell. If you find yourself more time in your tests, and I don’t mean in the design of your system.
which I just can’t follow along. Because I think the test as your first user of the code is doing exactly that for you “driving your design”. Especially when your code is so small and modular that you think you are doing great design that’s when a test is so easy to write and a simple way to also verify the code later (as opposed to comments) which is the value the tests add. They serve as the docs for what your tiny-modules-composition does, they allow others to go in change requirements and learn where they have to be implemented. And so on. Don’t they? Maybe I will get to that stage of understanding it at some point.
And Chad saying
My intention is to write code that can’t possibly break.
I admire him! I think I still have lot’s to learn.
TDD is a great way to do design, but it is not a great way to prevent bugs
I think we agree basically :)
Watch his talk, it is really very good and contains enough brain food!
simple pointers to create a clean, intelligible codebase that won’t use a lot of dependencies
- Kill Primitive Obsession
- Name things as Nouns (and not using verb nouns that have an ‘er’ ending)
- Remove duplication
First I read his article “Why I Don’t Teach SOLID” where I didn’t get his point, but the article where the quote above is from does make lot’s of sense. Event though I after having read poodr I can’t agree that inheritance will become unused.
I read it first in my personal trending twitter search, then I saw it on hacker news and I pulled the repo and being intrigued by the minimal size, compared to react and polymer I thought I try out the demo, didn’t work. So I looked a the code, very opinionated. My conclusion after having spent about just 1h on it I sumed up in this tweet.
from Sep 2013 https://github.com/perryharlock/refactor-to-functional
I have to read this, I just want to parse the data a bit and I fail. I smell that I don’t get the concept fully yet, or that I am using it in a different way than it’s meant.
Feature Injection is a business analysis process framework that allows teams to exploit the value of the traditional business analysis techniques in projects involving frequent iterative deliveries, such as the ones implemented using agile and lean processes.
CoffeeScript-Object-Notation Parser. Same as JSON but for CoffeeScript objects.
In order to keep all your meta data of your project in one place and only create files that actually just copy those data you can use projectz where you maintain data like title, description, author(s), badges, … in one CSON file and with a special markup you can update fill in the templates files like README, package.json, …
Dan North and Jessica Kerr make a journey through complexity. At the other side we may find simplicity, or we may find the light at the end of the tunnel is just another oncoming ESB.
Martin Fowler named interactive or more online consumable slides infodeck, writes about it here and he is building a frontend for it which you can feed via XML.
Martin Fowler lists the kinds of refactoring, the reasons why we refactor code, in his infodeck.
found on stackoverflow
The webdriver API is here
Myth - a simpler alternative to all the CSS transformers out there?
reducing function transformers are getting a name - ‘transducers’, and first-class support in Clojure core and core.async.
Very useful and right-away applicable insights into refactoring legacy code. Seems the VJUG has lot’s good content.
The hardest part of the learning journey is thinking in Reactive. It’s a lot about letting go of old imperative and stateful habits of typical programming, and forcing your brain to work in a different paradigm.
I think the world deserves a practical tutorial on how to think in Reactive, so that you can get started.
Find the Rx tutorial here, watch out it gets you hooked :)
Lately they don’t turn out so good, or is it my blurred vision?
One by James Shore An Unconventional Review of AngularJS and another by PPK The problem with angular.
I came across paxos more often lately. The first time was at a meetup group “Papers we love” there was a meetup in December about paxos.
Paxos is an algorithm to solve the consensus problem. Paxos is only a small piece of building a distributed database: it only implements the process to write exactly one new thing to the system.
And this is an explanation and demonstration
I really appreciate the things I learnt from Erik Meijer, but I am not so sure I can follow all his opinions he states in this talk.
But nevertheless it’s very entertaining!
Writing tests is waste.
TDD is for scared people, it’s for pussies.
Those statements are actually the funny parts of his talk, though I am not sure how funny they are meant :).
My lack of knowledge and understanding and knowing it scares me most about reading this article, because once I read it I know there comes a slew of things I would have to learn too, but I still try hard ignoring it :). Damn.
Watch the author of poodr describing how to solve the problem of mocks and real code running out of sync! (And lots of goodies about testing and stuff.) Watch it twice, it’s worth it :)
As I just found in the docs metalsmith, which again uses the package metalsmith-markdown which in again uses the package marked describes in the readme that is also supports github flavored markdown. (I was actually just looking for how to strikeout things :)).
The term ‘Mock Objects’ has become a popular one to describe special case objects that mimic real objects for testing.
Read the article from 2007!!!
Servo is an experimental browser engine for modern multi-core hardware written in an experimental memory safe language called Rust. Maybe the future Firefox engine?
IDEs are awesome but sometimes in my way and setting up test runners sometimes defeats the purpose of being fast with tests, which also means having feedback constantly and continuously. Thanks to @Christoph for showing me the shortest test runner there is, it runs on the command line, like this:
while true; do npm test; sleep 3; done;
it assumes of course, your tests can be run via
I expected my new 15” Retina MacBook Pro to just blow my mind in terms of speed. But it didn’t … until now I am pretty disappointed. So I finally did some cleanup this weekend that promises to speed up, I am hoping.
I never knew which is the right markdown syntax, I took the five minutes to find out now I know, it seems to be this one here. At least following the link chain that lead me from metalsmith, which I use here to create this site to the markdown syntax.
I found it always painful to only update the gh-pages branch for deploying to a custom domain, an easy solution is pushing a subdirectory to gh-pages branch, like so
git subtree push --prefix docs origin gh-pages
found at gsferreira.com
The answer on stackoverflow and also a more linux focused one on linuxedevcenter.com as given as reference in the article.