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 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.
One method three different return types
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:
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
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.
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/
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.