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.

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.

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.

Don’t get me wrong; I think the switch to Java was a leap forward for the industry; I just wish people would have jumped to a better language.

Who cares about programming languages? Languages are a tiny part of the overall development stack. The PERL language is showing its age, but CPAN continues to make PERL a great choice for many UNIX applications. Ruby is interesting, but it’s Rails that attracted the industry’s attention. Objective-C would be nothing without Apple’s fine compliment of frameworks. Microsoft recognized the value of stacks over languages when it designed .NET’s CLR to support many languages. And finally, Java’s decade-long success as a server-side development platform wasn’t due to any stand-out features of the Java language — or even Sun’s marketing¹. Its success was due to being a compelling development solution for server applications:

• Develop on your favorite system (Windows, Solaris, or Linux)
• Deploy on your business’ favorite system (Windows, Solaris, or Linux)
• Roll-out with confidence due to standardized server deployment artifacts and environments (JavaEE)
• Enjoy the easy stuff being easy with built-in support for internationalization, threading, and asynchronous processing

Development stacks don’t “win” based on their language — they win based on the ecosystem of developers, frameworks, and libraries that surround the language.

¹ I find the idea that Sun’s marketing significantly impacted Java’s adoption to be laughable. During those early years, while Sun was the tech media’s darling child, Sun was also actively antagonizing its developer community, whose members were building open source alternatives to the expensive enterprise solutions being pushed by Sun and its industry partners.

To which I say: yawn!

First, the device is just plain ugly. Who wants to be seen pulling that out of their bag on the train ride to work? Anyone who is willing to drop $500 on a consumer electronics item expects it to be stylish. Even if “stylish” is asking too much, the device should at least not look like something dreamed up during the early 1980s. I know that the ’80s big glasses are back and the ’80s fashions are influencing today’s leading designers, but the ’80s look for electronics was dorky — even in the ’80s.

Speaking of people willing to spend $500 on consumer electronics, who is the target audience for this device? What is the value proposition of this device — or any ebook reader? Are ebooks going to be cheaper than printed books? Maybe a little, but so far ebook prices aren’t compellingly lower than traditional books. Certainly they are not low enough to overcome the risks associated with DRM content.

Convenience? I don’t see it. Most people read one book at a time, so the ability to carry dozens of books with you isn’t compelling. Also, for readers who consume one book at a time, trading the print edition for the ebook reader isn’t a big savings in space or weight. Finally, if I’m on the train, sitting in a Starbucks, or in the park reading the Biography of FDR, I want everyone to know that I’m reading the Biography of FDR. Yes, it’s snobbish, but so the are people who read biographies of presidents.

Some commentators are speculating that the Amazon Kindle could do to books what the iPod did to music. Not going to happen. The consumer’s relationship to books is very different than the consumer’s relationship to music. A CD holds an hour’s worth of entertainment. A book holds a day’s worth of entertainment. Musical selection is subject to mood, so the availability of a wide variety of albums or songs is great. Books are less subject to those pressures. What’s more, I don’t see digital books as having anything to offer above print books. Consequently, the ebook reader is not a compelling replacement for print books.

In fact, I assert that the whole term “ebook” is leading everyone on the wrong direction. Replacing books is not the ebook reader’s killer app. Where I do see very intriguing possibilities for ebook readers are in books for boomers, reviving periodical old media, and — most importantly — in new media.

Books for boomers. An advantage that ebook readers have over print is that ebook readers can change the size of the book’s typography. This is a huge benefit for people like my parents who love to read, but whose eyesight isn’t as sharp as their 20-something and 30-something children. Unfortunately, increasing the size of an ebook’s type makes the ebook content harder to read for long stretches by increasing the number of line breaks that the reader has to consumer per unit of content (e.g., 100 words). An obvious solution to this would be to have the ebook reader behave like MobileSafari and enlarge content without reflowing it when the screen is rotated into landscape.

As I mentioned earlier, most people aren’t interested in carrying more than one or two books at a time and books aren’t particularly heavy or bothersome. Additionally, books tend to be read start to finish, so ebook readers don’t offer a lot of advantages. Finally, most ebook content will be encumbered by DRM, which means that consumers will need to worry about whether their ebook purchases will be readable in 3, 5, or 20 years. (Yes, 20! If you spend $150-$200 on the Harry Potter series or Lord of the Rings as ebook content while in your 20s, you want to know if you’ll be able to reread them or read them to your children one day.) However, newspapers are the exact opposite of books in all of these areas. They are somewhat cumbersome (though not bad) and they are a bother to read. They are big, they get ink on your hands, and most people read newspapers by jumping around to the content that interests them. Finally, almost nobody has the strong expectation that they should be able to read today’s newspaper article in ten years. Most people have a “read and discard” relationship with newspapers and magazines. Thus, an ebook reader is nearly a perfect match for periodical traditional media. The content could be searched, cross-linked, and have “Related Articles” to facilitate scanning for the bits of interest.

I would be willing to pay the WSJ, NYTimes, Chicago Tribune, Oak Park Leaves, and Crain’s Chicago Business each small monthly fees to have subscriptions to their latest content ready to be sync’d to my ebook reader every morning in an appealing format that takes advantage of the device. I say “sync’d” because I don’t want to be tethered to the Internet to enjoy my content throughout the day. Just like I listen to podcasts while offline, I want to read content offline.

There. I just saved the newspaper industry. But they shouldn’t be too happy: the same things that make an ebook reader great for periodical traditional media make them great for blogs. Sync everything in the morning, read it on the way into work and home again. Searchable, cross-referenced, and waiting to be consumed at my leisure. No Internet connection required after synching.

While I’m talking about myself, I should note that all of the stuff I said before about why ebooks aren’t a good replacement for books don’t apply to me. In my backpack I currently have six (6!) books.

1. Essential SNMP
2. Pro Nagios 2.0
3. Java Management Extensions
4. CSS: The Missing Manual
5. GUI Bloopers 2.0
6. Agile Web Development with Rails

Notice a trend? Yes, they are all technology books. Sure, six is a bit excessive, but I haven’t unpacked from my day trip to Bloomington yet. Anyway, I commonly find myself carrying two or three computer books in my computer bag. Having all of these books available in an ebook reader would be more convenient to carry around. Many computer books — particularly those that follow the “cookbook” or “recipes” format — are specifically intended to be consumed by jumping around to the sections of interest. Computer books are often referenced later, so an ebook reader’s ability to search the books would be invaluable. Finally, I rarely care if a computer book will be readable in 5+ years. The information in it will probably be obsolete. Not all technology books are like that, of course, but many of them — I would venture to say most of them — are like that. So the DRM on ebooks wouldn’t be terribly concerning. Unfortunately, full-length technology books are almost never available in ebook format. (Although more are available as PDFs, which is encouraging.)

Running with this idea of technology books in ebook format, the finish line would seem to be plugging into the O’Reilly Safari service or similar online book lenders. I don’t currently use the Safari service because it’s restrictions are incompatible with my book usage. I don’t read books online. Articles are a comfortable length to be read online. Books — even chapters in books — are not. I want PDFs that I can print. Not just HTML pages — real PDFs that have had the tender ministrations of a print designer, including good typography. Just give me the pages directly from the book. I’m getting off topic. My point is that the Safari service would be compelling if I could dump the books on my bookshelf to an ebook reader. Slap on whatever DRM makes the publishers feel comfortable as long as I can comfortably read several chapters in one sitting and view the diagrams.

One more thought of how an ebook reader could be useful is during research. Academic journal articles, books, and so on. The ebook reader could help researchers by allowing them to “highlight” (or underline, if you’re like my wife) relevant material and provide a mechanism to copy those quotes into another application and provide full APA, MLA, Turabian, and Chicago citation styles. That would be very, very convenient.

All of this is to say that I am the target demographic for ebooks and the ebook providers are still completely failing to convince me. Until the ebook providers seriously think about ebook readers as devices unto themselves instead of as simply a mechanism to display existing books they will miss out on opportunities to make really amazing solutions.

After registering, I chatted with other developers in my company to determine what sessions would be of greatest benefit to the teams using or investigating Flex. I shuffled those in with some sessions I really wanted to attend and the resulting schedule is below.

Data Visualization with Flex

Customizing the Flex Framework

Continuous Integration with Flex, FlexUnit, and Ant

Optimizing ActionScript 3.0 Performance

Inspire Session: The Dawning of the Age of Experience

What Makes a Design Seem Intuitive?

Pixel Perfect Precision

XD: Prototyping Rich Internet Applications with Fireworks CS3

XD: Adobe’s Approach to Application Design

Optimizing Flex Applications

Designers and Developers CAN Love Each Other

Creating New Flex Components

Flex on Rails

I look forward to seeing some of you there!

The first items aren’t that interesting. A 360|Flex folder and an Effective UI graph pad I picked up off a table while at that conference (thanks, guys!). I plan to use the graph pad to layout some screens for an upcoming project at work and want to keep it handy in case inspiration strikes. I’m still waiting for that inspiration.

Then I pulled out a two inch thick collection of papers I’d printed (duplex, to conserve paper). On top of the stack is D-Click’s Adobe Flex Coding Guidelines. I really don’t like placing opening braces on their own line. Drives me nuts. (For my money, the Sun Java Coding Conventions can’t be beat.) But, when in Rome, do as the Romans do. I recognize that being consistent (especially across developers on the same team) is more important than the merits of any single convention, so I’m trying to learn new habits.

Next up are printouts of six chapters from Adobe’s Building and Deploying Flex Applications (PDF here). I have only built Flex apps inside of Flex Builder, so I still need to learn the command line tools. My company is big on “repeatable builds”—meaning that any interally-developed production applications should be easy to regenerate from source without developer involvement. In practice, this means that the application must be built with a command line build script (Make, Ant, etc.). Besides, I get nervous when I’m overly dependent on an IDE. I like code completion, syntax highlighting, and refactoring, but I really like to know that I can do it all from vi or Notepad and the raw Flex SDK if desired or needed. Hence my interest in the Building and Deploying Flex Applications book. And I mean book! A full printout would weigh in at 400+ pages! So I picked the most important parts to me and just printed those.

The first chapter is Chapter 3 (Flex Application Structure). I just finished reading this chapter last night. Not a lot to say here. It’s good to have the layout with which I was familiar due to Flex Builder reinforced in print. Next up are Chapter 4 (Applying Flex Security), Chapter 7 (Building Overview), Chapter 9 (Using the Flex Compilers), Chapter 13 (Using ASDoc), and Chapter 14 (Creating Applications for Testing).

Then I come to printouts of various O’Reilly articles about Ruby on Rails that I intend to read Any Day Now™. Rolling with Ruby on Rails Revisited, Cookin’ with Ruby on Rails: May, Cookin’ with Ruby on Rails: Designing for Testability, Cookin’ with Ruby on Rails: More Designing for Testability.

And finally, I have Greg Hamer’s presentation slides for introducing Cairngorm at 360|Flex. I suppose I can take this out of my bag. I have the general idea of how Cairngorm works. I’m still waiting to write an app large enough to make playing with Cairngorm worthwhile. Okay, that’s not quite right. I’m still working on my first Flex app ever. I’m plugging into the 37signals Backpack API. When I’m done with that, I might look at refactoring it for Cairngorm just to get that experience under my belt.

And that’s wy my computer bag weighs a ton. What’s in your computer bag?

1. The database is not the application—get your head out of 1990.
2. Java is dead—that’s right, I said it!
3. ColdFusion is dead and buried—sorry to burst your bubble.
4. Rails will rule—the choice of a new generation.
5. RIA has a bright future—HTML must die.
6. REST wins—big Web Services were a tool manufacturer’s wet dream, and now we’re all waking up.

I will go into each of these in more detail over the coming weeks. Hold the flames until I get to elaborate.