Tonight, for a minute, I was able to forget about the worries I have about my kids being exposed to excessive television. We watched Nanny McPhee for movie night. In the finale, Colin Firth fell in love, and as the music rose, my daughter lay back onto my chest and clapsed her hands together, fully captivated by the moment and emotion. It was beautiful to see from a not yet two year old. But, more than that, I saw the future with her, experiencing movies and their power to entice and create a new world for just a moment. I think I’ve forgotten that part about entertainment, it often feels so utilitarian, and tonight I let myself be captured by the pure joy of it too.
This discussion about “bad APIs” was thoughtful and made me think of what a good one looks like. As I just wrote a book on the Github API I thought contrasting bad API with what I consider to be a good one makes sense.
Paul Graham’s initial article was an interesting spark but the follow-up where he defends himself by talking about how he shouldn’t waste time defending himself is a great online bonfire. Mr. Graham is an engaging writer, no doubt appealing to his demographic, the analytical programmer type (in which I group myself), with his exacting and bulletproof prose. The flip side is a lack of beauty; he is no Hemingway or Marquez or Kundera, if he had that, it faded when he started focusing on startups to the detriment of his painting.
I’m almost done wrapping up my O’Reilly book “Building Tools with GitHub” (available in early release, btw). This book was originally going to include a section on the history of Git and other DCSes. But, the story of the book shifted and I removed this passage. It seems fitting to post this today (Oct 21st, 2015), the day to which Marty travels into the future on “Back to the Future II.”
After a week or two of hacking with Go for just a few short hours, I
can unequivocally say I love it. I resisted learning Go because I
thought static typing would make me less productive. I love(d) monkey
patching with Ruby! There is (was) so much freedom that to get
something running quickly all I needed was to see “OK” after running
ruby -c. Little did I know the mindspace occupied by that nagging
worry in the back of my head saying “remember to write unit tests!”
And, “I can almost certainly be sure that all my variables are spelled
correctly.” Turns out there was a huge cost to be paid for this
freedom, because my code was often buggy, and I never got around to
100% test coverage. Static type checking removes that issue for me and
now that I have aligned my brain around struggling a little bit more
during compilation, my code just works once I am past that phase. With
Ruby all the problems were in the runtime phase, my problems are
rarely there with Go.
[This post explores troubleshooting network issues you might find when using docker with boot2docker, and in doing so illustrates the network topology of services running inside of docker and a VM host like VirtualBox]