Remember the annotate_models rake task? Dave Thomas wrote it many years ago and it corrects one of the flaws in ActiveRecord: it describes the schema for a table as a comment inside the Ruby model file that it maps to. Unfortunately Dave hasn't had time to maintain it, so a couple of years ago I cleaned up some bugs and re-published it as a pastie. Then Cuong Tran made it a gem and put it on Github, and since then, there's been a whole lotta forkin' goin' on!
I recently pulled in a bunch of the forks into ctran's master branch, and just pushed it to Gemcutter as version 2.4.0. Just run gem sources and make sure http://gemcutter.org is in your list -- otherwise do gem source -a http://gemcutter.org -- and sudo gem install annotate and it'll install a binary called annotate in /usr/bin. See the README on github for more info and have fun!
One caveat: ImageMagick installs a tool called annotate too (if you're using MacPorts it's in /opt/local/bin/annotate). So if you see
Usage: annotate imagein.jpg imageout.jpg
then put /usr/bin ahead on the path and you'll get ours instead.
I'm currently working on a large app where certain things have to happen when records are created, updated and deleted, such as:
- Publishing to an activity feed
- Generating emails
- Adding entries to a changelog
- Generating tasks and reminders
Further, the requirements state that admin users should be able to configure which of these actions happen for which objects in the system, who they go to, what the text is etc...
At first this looks like a great place for ActiveRecord Observers. However, after working with Observers there are a few things I dislike - namely that you can't easily apply observers to all of your models, and you can't selectively turn them on and off in tests. To remedy that problem, I created ActiveModelListener.
ActiveModelListener is a simple, global ActiveRecord event listener framework, using a middleware-esque architecture that can easily be turned on and off.
ActiveHash is a simple base class that allows you to use a ruby hash as a readonly datasource for an ActiveRecord-like model.
ActiveHash assumes that every hash has an :id key, which is what you would probably store in a database. This allows you to seemlessly upgrade from ActiveHash objects to full ActiveRecord objects without having to change any code in your app, or any foreign keys in your database.
It also allows you to use #belongs_to in your AR objects.
ActiveHash can also be useful to create simple test classes that run without a database - ideal for testing plugins or gems that rely on simple AR behavior, but don't want to deal with databases or migrations for the spec suite.
ActiveHash also ships with:
- ActiveFile: a base class that will reload data from a flat file every time the flat file is changed
- ActiveYaml: a base class that will turn YAML into a hash and load the data into an ActiveHash object
ActiveApi allows you to define a schema in Ruby, and use that schema to convert ruby objects to xml. An example looks like this:
Schema.version(:v1) do |schema|
schema.define :article do |t|
t.attribute :id
t.string :title
t.date :published_on
t.has_many :comments
end
end
[Updated: added instructions "If you are using a widget in rails, you now need to inherit from RailsWidget"]
Erector has been around for almost 2 years now, but we've always been a little reluctant to market it heavily. One reason has been that the API was a little inelegant. Another is that Rails integration wasn't as seamless as we'd like.
With today's release of version 0.6.3, we have hopefully fixed both of those problems. With the new RailsWidget we've got a clean separation between core Erector functionality and the magic we need to make it work with Rails. We've renamed "render" to "content" so we don't conflict with the standard Rails render method. And we've changed the API for smoother lifecycle management -- the constructor is about initializing the widget, and the refurbished "widget" method is about setting it up to emit its HTML.
The bad news is that you'll have to change your existing code. The good news is there's an update guide, which you'll find below the fold in this blog post.
Please visit our Google Group to register comments or complaints, our project web site for full documentation and FAQs, and feel free to clone or fork our GitHub repo.
(Why 0.6.3 and not 0.6.0? Because we had to work through some glitches in the new deploy process with GitHub and Jeweler and whatnot. We're only human...)
AutoTagger is a gem that helps you automatically create a date-stamped tag for each stage of your deployment, and deploy from the last tag from the previous environment.
Let's say you have the following workflow:
- Run all test on a Continuous Integration (CI) server
- Deploy to a staging server
- Deploy to a production server
You can use the autotag command to tag releases on your CI box, then use the capistrano tasks to auto-tag each release.
Interesting Things
When you specify a gem from a custom source, and it has dependencies on a separate source, you need to list both sources in geminstaller.yml.
This comes up when you are installing a gem from github and that gem depends on other gems from rubyforge. You can specify multiple sources by adding more --source attributes.
(Update -- version 0.3 released 2-Oct-07. Release notes are here.)
We use subversion for our source control. We love it. But we've noticed a few flaws, and a few weeks ago I decided I'd had enough and wrote a wrapper for it that fixes a few of the most glaring ones:
- Externals get messed up pretty frequently. If you remove or rename an external, the old one gets left around on disk, and if you convert an external to a "real" directory or vice versa then the next update simply fails.
- Externals are updated in series, not in parallel, meaning that if you have a lot of externals your updates can take an excruciatingly long time.
- Externals are updated even if they're frozen to a specific revision number, which wastes even more time on update.
- If you want a clean checkout -- say, for an automated build -- the only way to do it is to do a full checkout, even if 99% of the files are already there on disk.
- The
cocommand is not compatible with the convention of putting files under/trunk, requiring you to type out your whole repository URL followed by/foo/trunk foo - The name of the executable is hard to pronounce -- either "ess vee enn" or "seven", but nobody says "seven" except when they're saying "seven up", which is, I admit, a pretty good pun, but come on, how much cooler is it to say, "sub"?
The current version of sub fixes all of the above (except for converting directories to and from externals, and I'm going to make that work pretty soon).
Install with
sudo gem install sub
Help text is below the fold.