Gorp
Primarily due to the help of wycats and nzkoz, I’ve got a decent feedback loop going between ongoing book development and ongoing Rails development. The root problem is that given the rate of change of Rails, every single tutorial and book out there is atrophying due to either intentional or unintentional changes to Rails.
My, admittedly selfish, goal is to be aware of any such change that affects either the current edition of AWDwR, or the one under development. In 2.3, there appears to be an intentional change that I’d like to dispute. In 2.3.4, there appears to be an unintentional change that others agree is broken. In 3.0 there is a change is still under investigation. Also in 3.0, there is an intentional change in the API for adding new templating systems. Trying Ruby 1.9.2pre doesn’t get very far. Trying rev 24965 yesterday revealed some things I haven’t yet sorted through. And so it goes...
The issue I’m facing is not unique. It will certainly apply to Rails Guides. In the interest of enabling the replication of the modest success I have made to date for other scenarios, Yehuda asked me to split out the code that enables the scenario from the scenario itself. That’s now mostly done: and available now as gorp. In case you are wondering, the name doesn’t mean anything, it simply is a metasyntatic-variable, i.e., a placeholder for a real name.
Truth be told: the only real value in it is that it happens to work. For creating projects, it sucks compared to Rails templates. For testing web applications, it isn’t in the same league as Webrat. The unit/test style of defining a scenario in one file and a set of verifications should be revisited in favor of a more RSpec like approach. But while I will say that while it does each of these separate things poorly, it does manage to do each and to produce and self-verify a single HTML page result which shows the output of each command.
How this evolves from here: I don’t know. Perhaps it will attract developers and get a life of its own. Perhaps equivalent functionality will be implemented in any of the above projects and this project will no longer be necessary. Perhaps I will continue to be the only user of this code.
But one thing I would like to see is that this (or something like it) scale down so that it would be appropriate for expressing small test cases like this one.