November 2015

This article about closures in ruby started somewhere by saying "Ruby has four different ways of using closures, each of which is a tad bit different, and sometimes nonsensical".

In the last days I had to learn a lot about how to use, write and understand user stories. This talk by Mike Cohn is a pretty good kick start and summary for the hows and whys.

I just read a post about GraphQL, and because the headline and all the article contains so much excitment and passion for the topic I read it until the end.

If I tell you who gave the answer you will run off and read it, so I don't and expect you to be interested enough in following the link to the answer.

sales pitch in railsstart-tutorial to make me buy into it #scnr

I was fighting a little bit with getting Michael Feather's delta-flora to run, but made it finally. My starter level of ruby knowledge made it not much simpler to get it to run :). But in the end I succeeded doing the following steps.

I found this repo, which seems not to be the newest, but one (if not the only one) which provides some ways of refactoring for ruby.

A very good talk by Jim Weirich, where he shows how to pull the meat, the actual business logic out of a rails app to make it testable in a fast manner concludes with a very interesting idea.

I know that the calling of functions can be quite noise-less, no parantheses and commas. But it also leaves me baffled at times. I can't get my head around this one either.

Emily Bache in her talk "Catch Dancing Ponies — Try Approval Testing" makes me balance my attitude where I try to prevent intergration tests, finding the right amount is the thing to do, I guess. Using this TextTest seems to be one way.

One method three different return types

Don't promisify fs.exists since this does not play by the rules of node style callback params, where the first one should be err and then data. It seems this does return only the data, which promisify understands as an error and does throw right away. Instead do what the node js docs suggest too and use fs.access instead, like so: promisify(fs.access)(aPath, fs.R_OK). See it in action [here in the cosmowiki].

I had been fighting for the last years, always again to make WebStorm run all my tests the way I want. I moved tests into the src folder then back into a tests folder. The latter is painful, since I have to keep the structures of two folders in sync that way, which is just inefficient, especially when I refactor so much, which I think is simply necessary and the right thing to do.

Since lots of things changed in babel6, it has become a platform there is some stuff you need to do to set up your project to use babel6. All is best described in "The Six Things You Need To Know About Babel 6".

Lots of links to further reading on design patterns and a good short introduction on why they are important. http://codebetter.com/jeremymiller/2005/09/01/learning-about-design-patterns/

My laziness actually pulls me strongly towards #noEstimates. I guess it's because the "no" means I have less work to do. Which I could kind of back up with the argument Robert Weissgraeber gives at the beginning of his talk, which is that we should remove all unnecessary work, all waste.

I am about to probably hit some RoR ground and I am already preparing myself, by listening to Uncle Bob

Uncle Bob nicely shows the parallels between accountants and TDD. One value gets put on the asset side and the other on the liability side, they add up to be 0. And then he questions why accountants meet their deadlines, even though they do things twice. Accountants do this for five hundred years, its a "law". We still need to get there with TDD, but we are on the best way and I second that and try to do my part with the JSCodeRetreat.

https://www.youtube.com/watch?v=TfZmuS01CNs