Dead Ink Vinyl

For most of this year, I’ve been taking notes at conferences using Field Notes notebooks. I love their pocket sized dimensions and they have just enough pages to comfortably hold everything from a conference that I’ll want to remember later. However, for QCon last week I decided to try typing everything into Evernote. The fact that I can access my notes on my iPhone makes the notes just as portable ex post facto, and saved my Field Notes for more worthy pursuits.

Evernote worked out very well, and now I can share my notes online just by putting all of them into their own notebook (folder) and making it public.

So without further ado: my notes from QCon.

Overall, I thought QCon was excellent. While the quality of the speakers was somewhat varied in the sessions I attended, I never felt my time might be better spent checking out a different session, which puts it ahead of most conferences. (I’m a big fan of voting with my feet.) QCon is certainly on my short list of conferences to attend next year. Also on my list are (in no particular order): C4, WWDC, RailsConf, eRubyCon, and 360|Flex.

I really like The Rails Way by Obie Fernandez. It’s not an introduction to using Rails—look to Agile Web Development with Rails and RailsSpace for that. Instead, The Rails Way was written as a “day-to-day reference for the full-time Rails developer” (page liv) and weighs in at a hefty 851 pages, plus the preface material. It has served me well so far and it is the first resource I pick up when I need to delve into a new area of Rails development.

When I needed to develop a model plugin for Rails, The Rails Way provided an excellent overview of the process. Between that and a review of acts_as_taggable_on_steroids, I was able to get my plugin up and running very quickly. Then I wondered about writing tests for the plugin so that I can have confidence it continues to work when I upgrade to the next version of Rails. For the first time, The Rails Way failed me:

As you can imagine, testing of plugins is a lengthy topic that is primarily of interest to plugin authors. Unfortunately, I must leave further analysis of the subject out of this book for reasons of practicality and overall length. (page 649)

The book already has 851 pages, but another dozen couldn’t be spared for this topic? How does that work? In all seriousness, I wasn’t overly upset—I understand that there are limits to what can be included in a book. I would have written it off as a minor inconvenience, but I couldn’t find any good Web sites that covered the topic well. Additionally, the tests that were included with the plugins I downloaded were a bit on the lean side and didn’t provide a good example from which to work.

Fortunately, PeepCode came to my rescue. PeepCode has an excellent PDF about writing Rails plugins. It covers the common patterns for each flavor of plugin and is very thorough in its explanation about why the code is written in the manner described. It’s over 100 pages long, so I haven’t finished it yet—or even gotten to the section on writing plugin tests—but it has already proven to be the best resource I’ve found concerning Rails 2 plugins. I recommend it without hesitation for anyone seeking to write their own plugin or understand someone else’s plugin.

Steve Yegge wrote a long and somewhat rambling—but painfully insightful—article entitled Portrait of a N00b. It starts by discussing the phases of a software developer’s professional development, from toddler to teenager through to adulthood. Steve puts forward that a developer’s relationship to metadata (comments, static typing, modeling) changes over time from an over dependence on metadata to a distaste for it. He then goes on to discuss consequences of this insight.

The article really hits its stride in the section “Creeping bureacracy”. If you’re short on time, jump down to that header. I found myself laughing and nodding at these pearls of wisdom:

I think that by far the biggest reason that C++ and Java are the predominant industry languages today, as opposed to dynamic languages like Perl/Python/Ruby or academic languages like Modula-3/SML/Haskell, is that C++ and Java cater to both secure and insecure programmers.

and

Perl, Python and Ruby fail to attract many Java and C++ programmers because, well, they force you to get stuff done. It’s not very easy to drag your heels and dicker with class modeling in dynamic languages, although I suppose some people still manage. By and large these languages (like C) force you to face the computation head-on. That makes them really unpopular with metadata-addicted n00bs.

While the whole article sent my neurons firing off in dozens of different directions worthy of blog entries, I’m going to concentrate on this bit:

Java has been overrun by metadata-addicted n00bs. You can’t go to a bookstore or visit a forum or (at some companies) even go to the bathroom without hearing from them. You can’t actually model everything; it’s formally impossible and pragmatically a dead-end. But they try. And they tell their peers (just like our metadata-addicted logical data modelers) that you have to model everything or you’re a Bad Citizen.

Hello, my name is David and used to be a metadata-addicted n00b. Joking aside, Steve is absolutely right.

I think Java became the garden of frameworks due to its early positioning as an enterprise software platform. Enterprises are strange beasts. Internally developed enterprise software has a tendency to live a long, long time. A decade, often more. Take a moment and pause to think about what you were doing 10 years ago today, and then think about how much technology has changed in that time, too.

One of the problems faced by enterprise software that isn’t typically encountered outside of enterprises is that the systems, protocols, and interfaces that an application was originally written to run on or collaborate with will have been replaced. Vendors are replaced, authorization systems change (database to directory to single sign-on), databases are upgraded, CORBA loses favor to EJB and then to SOAP, and so on. Consequently, the fathers of Java emphasized abstraction—don’t get too close to your touch points, because they may be changed tomorrow. Let’s call this “abstraction at the edge”.

I think that a lot of Java developers—myself included—took abstraction too far. Instead of abstracting at the edge, we started abstracting everything. Rather than creating opinionated software, the Java development community promoted and embraced frameworks that competed to be the most general and all-encompassing. Rather than solving problems, the Java community invested its energy in building problem-solving engines.

This is important because as Java developers have started jumping into new communities—I’m thinking of .NET, Flex, and Ruby on Rails—they have brought their framework addictions with them. NHibernate and Spring.NET are gaining momentum within .NET communities and you can’t look sideways at Flex without tripping over a new Flex MVC framework¹. The Rails community has been very successful at resisting the inventions of “metadata addicted n00bs” because the big names in the community have taken a strong positions against abstraction.

I might be growing up faster than Steve’s timetable for growth, but I’m tired of frameworks that try to do everything. I just want to get things done.

¹ Here’s nine for you: Cairngorm, PureMVC, ARP, MVCS, Flest, Model-Glue: Flex, ServerBox Foundry, Guasax, and Slide. List compiled from here and here.