intertwingly

As I proceed with updating Agile Web Development with Rails to support Rails 2.x, I have become impressed with how Rails has become even more focused on scaling down than it was in Rails 1.x.  Some of the credit goes to Rails itself (changes in scaffolding, migration), but much of the credit goes to making sqlite3 the default.

What I mean by scaling down is to places where I would not have previously thought it was worth the time or effort to build a web application.  In many cases, I am talking single user, single table applications whose usefulness may last only a few months or even days.  The ability to go from concept to running code preloaded with live data in five minutes or less is truly a game changer for me.

I am having difficulty expressing the concept, but I have two examples that I can express in code.  It is said that Rails itself was factored out of live running application, and perhaps after I create a few more examples, I will be able to fully see the commonality and be able to build a generator and/or a small wizard application (built on Rails, natch).

The six steps to a running application are rails application, cd application, ruby script/generate scaffold table attrs..., rake db:migrate, load data, ruby script/server, and tweak.  The keys being scaffold, load, and tweak.

Errata

The first example is errata.  Pragmatic Programmers hosts a simple errata page that contains input that has been received to date beta of books.  As I’m working (sometimes offline), I like having the ability to annotate these records as to whether I have made the fix, am deferring the suggestion for now, or (for whatever reason) the fix is resolved another way.

So I define a model for an erratum consisting of three groups of attributes: ones that show up in the index and on the individual edit page, ones that are in the xml file but I’m not concerned about for the moment, and additional  attributes that represent annotation.

The “tweaks” include defining a virtual attribute in the model for a “beta_page” that combines the title_release_reported_in and pdf_page fields into one, highlights errata which were first seen within the last 24 hours, filter the index to only show issues which haven’t been categorized, turn off session support (as this is a single user application), and some minor CSS.

Loading is as simple as an xml parse of the input document, some minor type coercions, name mapping, and filtering, and into the database it goes.  This step can be rerun multiple times as it will only replace the columns which were originally sourced from the document, and will only add new rows when a new errata_id is encountered.

this code does all that and launches a server.  Up and running in five minutes indeed.  And additional reports are easy enough to add later.

Agenda

The second example is agenda.  The ASF Board meetings each have an agenda that is of the same basic format as the minutes, but with room for individual directors to leave comments and to “pre-approve” individual reports.  As an officer, director, and secretary, I need to interleave reporting, participating, and recording activities all the while coping with a document that is in a decidedly non-linear format.  I’ve been able to cope using browser tabs and having a second monitor has been a real blessing, but having a single application that enables me to navigate within the document and record comments inline would be helpful.

Once again, there are three groups of attributes involved: ones that show only in the index, ones that show both in the index and on the individual report pages, and ones that represent annotations.

Tweaks include color coding the rows based on the status of the report (missing, ready for review, approved with comments, and simply approved) and changing the flow in the controller to move onto the next report after an update is made.

The loading step is the most difficult one here as it involves some gnarly regular expressions and, in the case of Additional Officer Reports and Committee Reports requires two passes.  The actual interaction with the database is trivial.

The “market” for the above application is likely only “one”, or at most a dozen or so (directors plus guests), and as such would probably still remain unwritten except for the fact that I was bored on a plane ride out and this gave me something to do.  Future work would include expanding to the “prep” stage (i.e., highlight which reports are ready but have not been reviewed by me just yet), and to the “publish” state (first pass generation of the report based on the agenda and annotations).