Hobo 0.7.5 is a fairly small release in terms of new features, but does tidy up a few things and fixes some bugs that were causing people trouble. The bigger news is that there’s a whole bunch of new documentation now available.

To upgrade simply

or grab the files from github or the svn repo and update your plugin directories.

A highlight of some of the changes.

• Autocompleters and in-place-editors have been broken for a while. They’re working again now
• Some incompatibilities with older REXML versions have been addressed. DRYML should now work with REXML versions 3.1.4 to 3.1.7.3
• The “permission denied” page should be working again.
• The Clean theme works much better in IE6 now.
• We’ve squished a pagination bug that was messing a few people up

There’s a bunch more little changes — see the changelog for the full low-down.

Then on the tidying up side, there are two major changes. First, we’ve moved to gems for the whole of hobo. Installing the hobo gem should get you hobosupport, hobofields and will_paginate. As a result of this the hobo command no longer tries to fetch anything with subversion.

And we’ve made a change to the structure of the git repo. Because Hobo is really one project, with some sub-components available as spin-offs, it is really much better to have the whole thing in a single repo. So github.com/tablatom/hobo now also contains hobosupport and hobofields in sub-directories. The separate repos on github for HoboSupport and HoboFields will be deleted soon. The one downside is that you can no longer follow “edge Hobo” by using git sub-modules, because git doesn’t support partial exports. We’ll provide some rake tasks to make that easier at some point.

And then there’s the docs.

We’ve got the very beginnings of a complete reference to the Rapid tag libraries. At the moment it’s just generated from the source-code but all we need to do now is start adding in-line documentation comments. The format is probably not ideal either - it doesn’t lend itself to easily searching the whole library. We’ll improve that too in time.

The manual has been extended to include a fairly comprehensive guide to customising Hobo’s RESTful model controller.

James has added some great insights into working with DRYML in the third part of the POD tutorial and with some additions to the DRYML guide.

And finally there’s our first HOW-TO: adding an admin sub-site to a Hobo app. We’ve got a bunch more of these planned which should be very useful.

So! We’re making good on our promise to concentrate less on features and more on making Hobo accessible to others. Mind you, having said that, there’s a cracking new feature in the pipeline…

Hobo 0.7 is now available, both as a gem on rubyforge, and in via the repo trunk.

• CHANGELOG

Template tags and non-template tags are now unified. This is really a huge improvement to DRYML. We’ve also switched to dashes instead of underscores for tag and attribute names.

Got any existing DRYML code? It doesn’t work any more. At all :-)

Fortunately, happiness is only a rake task away:

From the changelog:

A rake task hobo:fixdryml has been added which does a pretty good job of converting Hobo 0.6 DRYML source-code to the new style. It will change every file in app/views/**/*.dryml, and keeps a backup copy of app/views in appviewsbefore_fixdryml. If you pass it CSS=y and ID=y it will ‘dasherize’ css classes and IDs too, which is the new Hobo convention. You can also pass DIR=… if you want to point it somewhere other than app/views. It won’t fix anything in erb scriptlets, e.g. use of the tagbody local variable. Expect to do some manual fixes after running the task (good job you’ve got that thorough test suite eh?)

We’ve switched to Rails 2.0 RC2 for our testing. Be warned - there’s a breaking change in Rails that might absorb some of your time as it did mine. It’s a change to fixtures - the default if you don’t give a value for a created_at or updated_at field, is now Time.now. It used to be nil like any other field.

There’s now only one significant feature that I want to add — fixing themes and CSS — before the push to 1.0 begins.

But before that, next up is beta.hobocentral.net!

With so much fun happening in git land, ActiveScaffold has officially cut it’s ties from Subversion and moved completely over to Git. All git related repositories can be found at the following URL:

http://github.com/activescaffold

The advantages of using Git are too numerous to identify in a short article, but among them are the following:

- Contributing will be easier for all: you can create your own fork of ActiveScaffold to add a feature or fix a bug. Then submitting your patch is as easy as sending a pull request.

- You don’t have to wait for ActiveScaffold core to accept your changes before updating to a newer version. With git, you can pull updates from core and merge them in with your changes.

- Git is super, super fast. I mean REALLY FAST. It’s incredibly space / bandwidth efficent, too.

- Branching is painless in git. Merging your branches is also painless.

- The concept of a “core team” is diluted. ActiveScaffold core doesn’t have to agree with your awesome save-the-world do-everything feature. Just fork and then build it. If it rocks, other people can use your version.

So, if you haven’t already, come join us on the git bandwagon. There are plenty of easy ways to install git now – packages exist for OS X, Windows, and many distros of Linux.

Yeehaa!

The big feature back in Hobo 0.6 was “new DRYML” — A substantial improvement to the mark-up language that introduced the idea of “templates” - tags that can be given multiple, named blocks of content instead of just a single “tagbody”.

As I’ve mentioned a couple of times, we’re now working on another improvement to DRYML that unifies template tags and “normal” tags, and we’re switching to <tags-with-dashes> while we’re at it.

I’ve got all the DRYML tests passing now, and I’ve written a Rake task that does a pretty good job of automatically updating all your existing DRYML source to the new style. I’ve now got to put this new stuff through the wringer by making sure the test suites of our existing Hobo apps are all still fully green. Then Hobo 0.7 will be released!

I’ll then have my decks clear to move on to beta.hobocentral.net and you’ll finally have some documentation so you can find out what on earth I’m talking about :-). Obviously I’ve not managed to put the time into documentation that I’d hoped to in November, but I’d still like to make good on my promise by getting something out. Looks like the deadline is tomorrow :-). Wish me luck!

Over in the forums, finnhiggins is letting us know that keeping up with the all the changes to Hobo is a lot of work.

Hobo has some fantastic ideas that the rest of the Rails community could learn from, but keeping them all tied into a single package that is a very difficult dependency to track is making them pretty inaccessible to developers for the moment. Some more decoupling during development would be killer, IMHO.

“Can we have this in its own plugin?” is a very often heard request from the folk following Hobo. One that we’ve been saying no to.

Why?

The reason we’ve given is that there are a lot of interdependencies between the different parts of Hobo. Keeping all these parts separate will add an overhead to the development effort — possibly a significant overhead when you take into account all the extra management associated with having multiple sub-projects. And for what? There would be benefits for those who don’t want to use all of Hobo, but not so much for those who do. If you put it like that it doesn’t sound too tempting.

I’m going to say it plainly — we got it wrong.

James and I have just been chatting this over and come to the conclusion that the benefits of a collection of de-coupled Hobo “modules” far outweigh the costs:

• The development overhead of keeping things separate is something we should be doing anyway. A monolithic code-base is just going to get increasingly unwieldy.

• A collection of plugins will be more enticing to newcomers — it’s easier to adopt Hobo features one by one than to go the whole hog in one go and say “this one’s going to be a Hobo App”. (This exact point was made by a DRYML fan on the blog ages ago — hey, we get there in the end!)

• It’s easier to document and to learn smaller plugins with well defined interfaces to each other.

• We think and hope that smaller modules with more sharply defined purposes will be more likely to encourage quality contributions from all you ace developers waiting in the wings :-)

• It’s easier to benefit from other projects. Say we decide that ez_where or Ambition are much better than Hobo’s (lame) find extensions, we can drop that plugin like a hot-coal and grab the new shiny one. In other words — Hobo needs to stop trying to be the best at too many things.

Yep - we’re doing this!

The truth is that the Hobo code-base is already fairly well structured, so there’s really not as much work involved as one might fear.

We’ve had a bit of a scribble on the white-board and the initial stab at a logical breakdown looks like this:

• Model layer

  • General model extensions (Field Types?): Rich types, ‘fields do’ declaration, migration generator. (note that the migration generator needs the field declaration stuff, so it wouldn’t make sense in a plugin of its own)

  • Extensions to attribute assignment semantics.

  • def_scope

  • Permission system

• Controller layer

  • Resource controller (hobo_model_controller), including web-methods

  • Data filters / search

  • Autocomplete support

• View layer

  • DRYML + core tags

  • Rapid tag library

So that’s looking like a set of 9 plugins/gems. The idea is that any of these plugins can be used with or without any of the others, subject to some dependencies of course (Rapid probably won’t work too well without DRYML!)

We’ve pretty much convinced ourselves that this is the way forward now for Hobo. It’s going to have an impact on the documentation schedule, because it makes no sense at all to write docs before breaking things down. On the other hand, documenting Hobo in small chunks will make the job much easier and should mean you’ll get well documented parts of Hobo even sooner.

I’m planning to launch into this work pretty much immediately. Big change coming!

So here I am at the Ruby Fools conference in Copenhagen, and I did say we were going to try and have some new stuff ready by now. We’re nearly there. Stay tuned over the next few days.

First off though, I better deflate your expectations a bit. I don’t know if this was my fault for wording the last blog post badly, but a few people seem to have gained some pretty wild expectations about what’s coming. Terms like “fully documented” and even (gasp) “version 1.0″ have been bouncing around. Sorry folks, there’s good stuff coming but I never meant to give you that idea. Apologies for any confusion.

What is coming is this — we are turning the corner and focussing our energy on making Hobo into something everyone can use. That means breaking it up into parts, and writing more documentation and tests. The process has begun, and the first installment is on the way. Here’s what we’re about to put out. (If you know where to look you’ll know that some of these things are in fact available already. We’re just holding off from the ‘official’ release so we can promote the new stuff properly in a few places).

• Hobo 0.7.4
• HoboSupport as a separate gem (core Ruby extensions). With full docs!
• HoboFields plugin. This is something a lot of people have asked for — the migration generator as a separate plugin. HoboFields will be well documented too :-)
• Significant improvements to the current Hobo tutorial (the POD classified ads application)
• An entirely new tutorial — this is the one I delivered today at the conference. It goes through the full development of an app for tracking an agile development process (sort of a mini Mingle). Runs to 13 pages when printed.
• A DRYML guide covering all of the basic facilities that DRYML provides.
• A revamped hobocentral.net
• Very nice online access to the source-code and commit log (from a service you may have heard of)
• A very nice ticketing system that won’t drown in spam like the last one (also from a service you may know)
• Possibly some other stuff I’ve forgotten because this is all off the top of my head and it’s kinda late.

So it’s not 1.0 and it’s not fully documented but I hope it’s enough to demonstrate that we’re serious about moving Hobo in the right direction now. And like I said, it’s nearly ready. Watch this space.

I’ve just released Hobo 0.8.3. Various bug fixes, plus a few nice new features, including much better support for multi-model forms. See the changes for the details.

Please remember that Rubyforge takes a good while to get with the program, so gem update hobo might not work for a while. You can download the gem files from Rubyforge manually though.

Enjoy!

I’ve just released Hobo 0.8.2 — mostly a bugfix release. As always it’s tagged in the git repo and the gems are on Rubyforge (so you can just gem update hobo). See the changes for the lowdown.

Enjoy!

We’ve tagged and packaged the newest official ActiveScaffold release, version 1.1. This version comes packed with a host of features and fixes from version 1.0.1. And like many other versions in the open source world, this is mostly just an excuse to tell you that you should upgrade.

• Rails 1.2.x: This will probably be the last version of ActiveScaffold to support the Rails 1.2 branch. Trunk may break backwards compatibility any time now.
• Rails 2.0.1: Please upgrade to 2.0.2, otherwise you’ll have trouble with subform field overrides (see Rails changeset 8385).

• Subversion tags/active_scaffold
• Subversion tags/1.1.0_rc1
• .zip download

I’ve just released Hobo 0.8.2 — mostly a bugfix release. As always it’s tagged in the git repo and the gems are on Rubyforge (so you can just gem update hobo). See the changes for the lowdown.

Enjoy!

There’s a ton of new stuff in Hobo 0.8, mainly in the area of DRYML and the Rapid tag library. This post is the first in a short series that will give an overview of what’s new, what’s changed and why.

This is the big change in 0.8 — we’ve started using generators (gasp!) to create the automatic pages. If you’ve not been following along, you might wonder why the gasp. Well, we’ve always been quite opposed to using generators to automatically create a user-interface for your app. The reason being is that generators are really nothing more than copy-paste code re-use. Which as I’m sure you know is a terribly evil sin : ). The point being that if you’ve got five copies of something, and you want to change it, you’ve got to change it in five places, which is both tedious and error-prone.

Having said that, there’s one thing that generators are really great at, and that’s helping you learn. When you’re new to Rails itself, for example, it’s really useful to be able to look at the restful controller created by the scaffold generator. You learn at a glance how you’re supposed to use the provided API.

When it comes to DRYML, a natural first step when wanting to customise something in the UI, is to look at the source for that tag definition. The problem is that lots of the tags within the Rapid library are very unusual. Unusual in the sense that they’re not like the kind of tags that you would typically define in your own application. That’s because these tags have been written with no knowledge whatsoever of your application, they’re entirely generic. A good example is <show-page>, which does a remarkable job of presenting a reasonable looking page for any model that you throw at it. OK so you want to customise your <show-page>, so you go look at the source. Uh oh. All the logic for handling that generic magic is right there in the tag definition. As a result, we’ve noticed people copy some of these generic tricks into their own apps. This is really not a good idea — your app does not need to be generic, it’s specific to what you are doing.

So we don’t want DRYML generators because we don’t want DRYML to become WETML, but we would really like a generator-like approach to making DRYML, and Rapid, easier to learn. Here’s what we came up with…

The parts of Rapid that were very generic: the pages, cards and forms, are now generated. You can go look at the source code. You’ll find very simple code that’s been tailored to your application and is a good guideline for how you should write your own tags. But there’s a twist. The problem with generators is — what happens when things change. Easy! We just generate again and overwrite the old tags. Huh? What about my edits? That’s the twist - you don’t make any.

The generated taglibs are all written out under the directory app/views/taglibs/auto, and the rule is — you don’t edit anything within that directory. Instead, you use the powerful features that DRYML gives you to customise those tags. You can either extend them, which you’d probably do in application.dryml (using the new <extend> tag), or, you just call them and use DRYML’s parameter mechanism to tweak things to your needs.

This post is just to give you a heads-up of the thinking behind this feature, not to document how it all works, but here’s a quick example. Suppose you have a Story model, which has a title, and Rapid has automatically given you a show-page that uses that title as the main heading. But that’s not exactly what you want — you want the heading to always start with “Story:”.

So you mosey over to app/views/taglibs/auto/rapid/pages.dryml and find the tag definition for this page. It might look like this:

That is much easier to understand than the old fully-generic definition of <show-page>. If you never saw it, take my word for it - it was scary : ). We can clearly see that <show-page> is calling <page>, adding a title, a couple of css classes to the <body> and some main content using the <content:> parameter. The content section itself is also very straightforward — we can see a header and a body, a link back to the owning project, the heading in an <h2> tag, the edit link, and so on.

OK so we want to add that “Story:” prefix to the heading. Well we can clearly see that the <h2> in question is parameterised — the parameter is heading. So, thanks to the magic of DRYML, we can simply create our app/views/stories/show.dryml as follows:

Now that’s not quite as obvious as simply hacking on the generated file, but once you get used to DRYML’s parameter mechanism, it’s really very easy. The beauty is what happens when you change your app. Say, for example, you decide you don’t want an edit page for stories, so you remove that action in the controller. The page generators are re-run automatically, and the edit link will disappear from your show-page. You’ve got the best of both worlds: the ease of learning that you get from generators, and the flexibility to change that Hobo has always had.

I’m pretty excited about this change. I think it will take the ease of working with Hobo to a whole new level, and we really haven’t compromised any flexibility. How’s that for change we can believe in ;o).

I’ve just tagged v0.8 in the git repo, and released the 0.8 gems on rubyforge.

• Change Log

Enjoy!

Expect breaking changes as always (until we get to 1.0 of course), and expect more than normal, because this is a fairly big release.

I’ve created a page on the github wiki to collect advice for upgrading your existing apps. That page will grow over the next few days, but to get you started, here are the main things you definitely need to do.

Upgrade gem to 1.2 (you don’t have to do this but it’s so much faster)

Add the github gem server as a source (so you get will_paginate)

Now you can upgrade Hobo

You need to run some generators again. Be careful not to overwrite your code! The ‘d’ option to see the differences is useful. You might want (with the user model in particular) to just create a new blank Hobo app with the hobo command and compare the files manually. Run these generators:

• hobo
• hobo_rapid
• hobo_user_model
• hobo_front_controller

From there, go check out the page on the wiki

I’ll follow-up shortly (heh) with a post about what’s new in 0.8.

I finally succumbed

• http://twitter.com/tablatom

I’ll pretty much only be using this to let anyone that’s interested know what I’m up to with Hobo at a given time. Don’t expect to see “brushing my teeth” or anything like that : )

This is going to be pretty much write-only, too. I’m not good with distractions. So apologies in advance if I don’t respond to your responses.

A few days ago we announced our intention to break Hobo up into various self-contained sub-projects. I just though I’d give you an update on our plans.

The first plan was to get started with the big break-up ASAP. That would obviously push back the documentation I’ve been promising to do. The idea was to provide a reasonable level of documentation for each sub-project as it was released.

Slight change of plan :-)

I’m not in the #hobo channel all that often, but James is, just 2 meters to my left. So I’m well aware that there are a bunch of you that are determined to keep making progress with Hobo with docs or without.

With that in mind, I’ve come around to the idea that getting at least some docs out there for you folk is really the top priority. I think the best way to address this issue quickly is with some example code.

With that goal in mind, we’re announcing a new project today — beta.hobocentral.net (don’t go there now, there’s nothing there yet!).

We’re going to build a new version of hobocentral.net in Rails + Hobo. It will have the current features: blog, forums, documentation (cough) etc. In time we’ll add a whole host of new features like the long-promised tag library, user-extensible documentation and more. This is going to be an open-source project, and it’s going to serve a dual purpose. As well as getting us a better hobocentral.net, the code will be extensively commented and the whole thing will server as a decent real-world example of how to build a Hobo app. The documentation will be implemented by the documentation. It’s all a bit meta-circular, which you gotta love :-)

The point of the beta.hobocentral.net domain is that we can whack this app up really soon, and continue using the existing Wordpress based site until the new one cuts the mustard.

There is one small hold-up I’m afraid (groan). We’ve got this little outstanding DRYML issue with CamelCaseTags. From James’ experience trying to explain template tags on #hobo, it’s clear that this needs to be cleaned up right now. So I’m going to work on that first (right now in fact), and then start on beta.hobocentral.net

You should see the first cut of beta.hobocentral.net go up next week, delivering on my promise to provide some documentation in November!

Streamlined has moved to Github. We’ve already moved all of our other open source here at Relevance to our Github account, so it was long overdue to move Streamlined. The old SVN repo will be phased out and deleted within three weeks, so please plan accordingly.

Github has got be one of the best things to happen to open source and Git in the last year. It takes code collaboration to a new level of sexiness. Please do send pull requests with Streamlined patches and feature ideas, and someone on the Streamlined team will take a look.

We’ll be treating the master branch as the ‘stable’ area, and we will fire up new branches for long-term experimental work. So if you want to use git submodules to track Streamlined, feel free to point them at the master branch. You can also use the new script/plugin support from within Rails 2.1+ to install directly from Github:

Oops — forgot to mention that Hobo 0.6.3 requires Rails 2.0 RC1

To freeze:

If you want to use the hobo command, or if you don’t like freezing Rails, you’ll need the 2.0RC1 gems:

Also note that Hobo 0.6.3 has a new version of lowpro.js that needs Prototype 1.6 (Rails is on Prototype 1.6 now). You might need a

There may be a few bugs related to the switch to Prototype 1.6. These can slip through because most of our tests are in applications that have not been upgraded to Prototype 1.6 yet. Stay tuned.

You believe me, don’t you?

OK, OK — I missed my self imposed deadline. November came and went and you folk are still left perusing the source-code. I checked the “November is docs month” post and I did say “no guarantees” :-) Such is life. I have no idea how November managed to get so busy but it did.

On the whole though, I’d have to say that things are looking pretty darn good for this little project.

Hobo 0.7 is essentially ready — I’ve even written the changelog. This release features the long dreamt of (by me and James at least) unification of template tags and, er, the other kind of tag, you know, the normal ones. There is no um-ing and er-ing any more because now there’s just tags. They’re template-like if that’s what you want, and not if you don’t. It’s really rather nice, and makes DRYML feel pretty much done, baring all the little clean-up jobs and performance enhancements between here and 1.0. That’s a big deal.

I’m fairly confident in saying that beta.hobocentral.net, a.k.a. annotated Hobo-app goodness, is going to be out before you know it. I’ll be starting on it first-thing Monday.

And finally, our financial stability seems to have had a bit of a boost with a new client on the scene who are interested in using Hobo for a chunky-sized web-app. I might be able to share more about them at some point.

The first release candidate for ActiveScaffold v1.1 has been officially tagged. Why should you bother updating? Bigger version numbers are better, of course! One of the new features in this release, though, is a a brand spanking new changelog. Peruse that to get some idea of what we’ve been up to since 1.0. I’ll give you a hint: a little bit of everything, including file uploads, improved customization options, and even a touch of speed and security.

We’ve been holding back on releasing v1.1 largely because of how much we could possibly still do. It’s time for us to admit that we (like you?) will probably never finish our lists. Despite with the problems and missing killer features we still know about, this version represents a significant upgrade to v1.0, and we want to give people a chance to update without chasing trunk.

So what’s our goal with this release candidate? We want this to be a smooth upgrade (with extra features and fewer bugs) from v1.0, so we’d really appreciate if you could find some time to try out 1.1 RC1 and file bug reports for any exceptions, regressions, or backwards compatibility problems you encounter.

• Subversion tags/1.1.0_rc1
• .zip download

I recently updated the ActiveScaffold sortable plugin and resolved a handful of issues. While I was at it, I decided to create a screencast to show off ActiveScaffold and how easy it is to setup.

The video shows my old github copies of the repositories. The urls to get the repositories are as follows:

ActiveScaffold

ActiveScaffold Sortable

If you grab the latest edge Streamlined bits, you’ll want to make sure you have the test/spec gem installed. All the tests now use test/spec’s describe-style goodness, but it will take a while still to convert all the tests to have more meaningful behavior-driven names.

There is a lot to tell you about. I could blog on and on. In fact I intended to. But you know what, I’m supposed to be on holiday! So, I’ll cut straight to the chase and get off this computer :-)

For your hobo-ing pleasure there are three new goodies today, and I’m finally making good on my “Docs Month” promise (December is docs month!). The more I put time into documenting Hobo the more I realise what a huge task it is to produce in-depth documentation. But the beginnings are in place.

Please see the docs page for:

• The new Hobo tutorial!
• The source-code to beta.hobocentral.net!

Both, of course, are at an early stage.

And, just in case two christmas presents are not enough, Hobo 0.7.1 is out. Hobo 0.7.1 features the new Clean theme as the default along with hugely improved default pages and much more besides. The out-of-the-box Hobo app with no work at all in the view layer is starting to look really good.

So go gem update hobo or svn up your plugin directory, and don’t forget to read the changelog

Happy Christmas! See you next year.

This release is mainly about fixes - problems recently reported in the forums with the migration generator and validation error pages have been fixed. Of course we sneaked in a bunch of new features too, and James has been busy making the Clean theme even nicer.

Oops I did it again. Stopped blogging that is. Hands up who thought this blog had died?

Of course those who wanted to know if the Hobo project itself was still active, if they knew where to look, would have headed over here and would have found things to be very much alive. That’s all very well but I really must start blogging more!

OK where were we? About the time of the last post I was just about to head off to Railsconf with some very interesting news. As often happens in life, and even more often with anything related to software development, things didn’t quite pan out the way we expected. I do have news though, oh yes, even better news than I had before in fact.

At Railsconf we announced our plan to form the Hobo Foundation, a non-profit organisation to act as a conduit for companies that want to help Hobo succeed, and a way for developers to put some serious time into the project while still paying the rent. The driving force behind the idea was a company over in Washington D.C., Barquin International, who were to be the initial sponsor. The more we talked to Barquin, the more apparent it became that these guys really wanted to take Hobo seriously. They’re using Hobo in some very critical projects, the first of which rolls-out next month. To cut a long story short, we’ve arrived at a perfect solution which gets Hobo very much on track, and gives Barquin a close link with the on-going development: they’ve contracted me to work on Hobo full-time! The Hobo Foundation lives on in spirit, but for now this is by far the best arrangement for everyone.

That’s right folks, progress is about to take a big leap forwards. You know what this means don’t you? It means all those warm and fuzzy things like a solid test suite, lots of documentation, continuing to separate out all the major sub-components like DRYML into their own projects. Good things are coming!

I want to say a big thank-you to the folk at Barquin for supporting open-source and creating this great opportunity for the Hobo project. Barquin does a lot of work for the US Federal Government, and to be honest, this is the very last place I would have looked for a company willing to stick their neck out for some exciting new technology. It turns out Barquin are not your average government contractor. They’re firm believers in client-centred agile practices, and that approach recently won them (shameless sponsor plug!) the “Small Business Contractor of the Year Award” from the US Department of Agriculture.

Here’s looking forward to really getting stuck in and making Hobo as good as it can be. Maybe I’ll even find time to blog more :-)

(p.s. In fact I’ve got a whole load more to tell everyone about, so do expect more posts over the next few days.)

I’ve been thinking back to the months leading up to ActiveScaffold 1.0 and about how much the project really owes to those generous sponsors who encouraged a few devs to contribute to the open source community. That was great!

Could it happen again? I think so! We still maintain ActiveScaffold as we have time (props go to Tim for the push to support Rails 2.1), but I think the project could really benefit from another sprint of activity. There are a few things that would help the project to remain stable and would ease community contributions, such as versioned documentation (rdocs!) and a full test suite. But that’s my bias—what do you think it needs next?

If you like the idea of an ActiveScaffold code sprint and would consider being a sponsor (large or small!) would you please fill out a quick survey?

Thanks!

This patch version is just a quick fix for some rendering issues with Rails 1.2.x.

• Subversion tags/active_scaffold
• Subversion tags/1.1.1
• .zip download