Code2013

There’s a neat #code2013 thing going around twitter at the end of the year. I started to put mine together and was surprised at how much I got around this year:

#code2013 java scala clojure C angular spine node coffeescript ruby android

Scala

I started out the year pretty excited about Scala. I went to CodeMash and attended a session with Bruce Eckel and a Play workshop with James Ward. Later I talked with Josh Sureth at Pittsburgh TechFest and saw some intriguing code. That exposure encouraged me to use Scala and Play for my vagrant talk at CukeupNYC. I’m still interested in the actor-based approaches to concurrency, but I haven’t had a good excuse to build something interesting.

Javascript

My burning interest after CodeMash was triggered by a session I attended purely based on hallway hype. John Lindquite blew me away with his AngularJS demo. I ended up doing a few tutorials, building a throw-away app for a lightning talk and getting a good feel for the framework. Then we had a need for a prototype that was a near-perfect fit for a client-heavy javascript app where the DOM needed to change on every user interaction. AngularJS was a dream and I put together a pretty sweet working prototype in a week. I’m so grateful I had Huey Petersen around that week to help me whenever I got stuck. Great experience.

For the backend of the prototype I got to play a bit in Node. I ended up getting stuck for almost a day (very precious on a week-long project) on an issue. Troubleshooting that gave me a good feel for how Node is architected and the patterns it’s trying to push. I’m vaguely interested in doing more investigation, but I’m still skeptical about a “typical” server being run in Node. I have to say their build chain and package management tools are pretty sweet and well thought out.

2013 was almost the year of javascript, and probably for the last quarter it’s been where I spent most of my time. I find that interesting because I started the year with the bias I’ve carried against javascript for years - it’s so easy to make a mess of things. It’s funny thinking about it, since the first major project I “owned” after school was a test automation framework written in server-side jscript. I have to thank Joel Byler for getting my enthusiasm back - once we started doing a little TDD using JSTestdriver, I felt far more comfortable riffing on javascript and assembling reasonable solutions that weren’t multi-page-nested-function-calls-of-obscurity.

I ended up using jasmine for the Angular project (with karma - awesome tool), and have carried that forward to the end of the year using it to test a spine app. I still don’t like BDD style unit tests, but there’s not much value fighting that tide if I have to work with other people.

SpineJS has been somewhat interesting. I do like how it tries to make binding to elements pretty intuitive and coffeescript does pretty-up the code. Coffeescript suffers from the ruby-disease of “Should I use parentheses here???”, which just makes it hard to make idiomatic coffeescript and remember all the parsing rules. I think all of these javascript MV-whatever frameworks are a good thing in the long run, since they are encouraging web devs to think about how javascript should be organized. It’s pretty entertaining to watch the evolution of MVC - how we’ve gone from smalltalk => itty-bitty MVC widgets - java swing => small MV with optional (and usually confused) controllers - to rails => just embrace giant controllers - and now every JS framework is taking the idea and twisting it a bit differently. As an industry I wish we could come up with better terms - working on a rails app with a JS front-end makes talking about models, controllers, etc kind of difficult.

Java

I still spent most of my year hacking in java. I’m starting to push away, just because there’s very little for me to learn here. Sure java8 will provide closures and some new solutions, but since enterprises are begrudgingly still moving to java6 - what’s the point? I’ve done my decade+, I know more about the JVM than anyone has a right to know, and I’ll probably have opportunities to hack java until I die. Let’s see what else is out there.

I did get to work with Dave Shah and Michael Lemley on the OCB mobile app for our ATDD talk. That was a great experience. Dave and Mike have encyclopedic knowledge of the android APIs and lots of scars with the various test frameworks around android. We built a simple little thing for a local business and they adored it. Front-to-back it was a great LeanDog project and I hope we get to do more like that.

C

I worked on a small C bugfix at the beginning of the year. It’s worth mentioning for a couple reasons. One was that I couldn’t build the code locally - it was an embedded system and the weeks it would have taken to get a build working would have made this obscenely expensive for the client. I’d love to take on an embedded C project with TDD, I’m just perversely interested in the idea. Anyway, since I couldn’t build it locally, I copied the code somewhere else and extracted a function I could build and test. And I rolled some pretty hacky unit tests. It was fun, simply because it felt ridiculous. It also reminds me of how far I’ve come. When I did my CS degree, we also did C programs that you often couldn’t run locally - or they wouldn’t have the same effects on a windows 95 machine at least. So you telnet’d into a university machine, ftp’d your code over, ran the code and got something like:

$ ./a.o
Segmentation fault

I’m really surprised I made it through college sometimes. It’s a whole different world from now - you didn’t even google things back then - you re-read the book, printed out pages of code, pored over them with a pencil and hoped for insight. I’m usually grateful I learned these skills, but knowing something about unit testing would have saved many brain cells.

The best part of this bugfix: I needed to generate a random number so I pulled in stdlib for the rand function. This blew the image size up to the point where it couldn’t run on the hardware. So I had to roll my own RNG. I’m sure it’s vaguely random :) Embedded is so cool because of the real-world constraints - I love the way it bends my brain and reminds me that knowing 100 elegant ways to do something may not matter one bit when the rubber hits the road.

Ruby

I think ruby is where I built most of my skill this year. I built my first gem, pinch_hitter, helped on a few other libraries, and wrote a lot of test automation code. I benefited greatly from attempting my finances app based on Uncle Bob’s Clean Architecture ideas. I also listened to 30+ ruby rogues podcasts, did exercism.io exercises, and went to most of the CleRbs as well as Steel City Ruby. I learned a bunch about metaprogramming while working with page-object and other testing gems. Jessica Kerr’s fp4rd talk helped take my FP to a level where I felt pretty good about getting into a real FP language.

Clojure

I’ve been hacking in clojure for a couple weeks now. On the one hand, I love how it’s different. Clojure is the first lisp-dialect I’ve really tried to understand. On the other…I’m not sure when I’ll be at a level when I could use it for something real. There’s so many apps I want to write, versus languages I really want to learn. I think this might be a case of hitting that 20 hour mark, where future learning would require a lot more effort.

Python

I literally wrote my first python on December 30th of 2013. Matt O’Donnell paired with me and had me up to speed pretty quickly on a Django app. I feel pretty confident I could be competent in a few hours - it’s close enough to every other language I know well that I’d only be stumbling on syntax and looking up framework functions. That’s a cool feeling - is it true? If it is, then I’d say that I might be able to call myself a polyglot developer. Which makes code2013 a pretty special thing for me.

Published: January 01 2014

  • category:
  • tags:
blog comments powered by Disqus