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 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?

It is not the best of both worlds. Cedric skims over the most important detail for testing. He off-handedly says “All you need to do is provide a default implementation for your getter…” to be able to test the classes. How does he think developers will implement that “default” functionality? It will be performed by either constructor-based injection or setter-based injection!

So with Cedric’s getter-injection, developers still have to implement the exact environment Cedric was trying to avoid plus he has ensured that unit tests won’t accurately reflect how the classes will behave in their container.

I would have to say that it is the worst of both worlds. Sorry, Cedric.