I attended my first Windy City Rails conference last week, and it was a good time. Got to meet some of the folks from other local companies as well as a few from San Francisco. Every talk brought something good to the table, but here’s the few biggest takeaways I had.
Noel Rappin — Testing as a Mindset
The author of the best practical Rails testing book naturally gave a great talk on how to make test-driven development practical. He touched on what I think is a common pain point, that while there’s no shortage of “How To Do TDD” material, few provide practical help in the real world. Too often you see talks that are too abbreviated or articles that are too simplistic. You’re then left with a skeleton of a process, notions of what the beginning and end ought to resemble, but a vague notion at best of how to break down complex behavior.
‘Red, Green, Refactor’ is a slogan, not an instruction manual.
Chris Ball — Mind the Front End Gap
This was a gentle introduction to Ember, by way of displaying how Ember and Rails share a lot of the same core concepts and philosophies. He gave some great guidelines for how to think about your front end app. Things like letting the UI drive the design of the API instead of the other way around. And to keep your resources flat, letting Ember manage nested resources for you.
Kyle Crum — Communicating Code
This was less of a revelation and more a reinforcement of the importance of code clarity. My biggest goal when working (after making sure it actually works) is that the code is easy to read and does as much as possible to convey intent.
Naming is the most obvious part of that. Being terse can be a hard habit to break, but Ruby’s syntax is beautiful in that it wants to be read like natural language. There’s a sense of fulfillment, not unlike after cleaning a messy room, when you refactor a meaty method down into a clearly named one liners. The end result is something that is easy to test because each step is isolated. It’s easy to grok if you’re able to give that atomic piece of logic a name. And it’s easy to change when the underlying business rules change, because in that process you’ve abstracted out the concept of what that step represents and can change the implementation under the hood.
Have a comment or question? Send us a note. It won't be shown here and email isn't required, unless you'd like a