When I was at RailsConf a week and a half ago, I had the pleasure of attending a Hackety Hack demonstration put on by Brian DeLacey, one of the original Hackety Hackers, maintainer of a blog about Hackety, and all-around good guy. There, I got to meet Evan Farrar, who I’d previously only talked to via the Scribble mailing list. We talked about various Scribble-related things, and eventually got to curves. We both agreed: curves in Scribble were just terrible. To refresh your memory, here’s a snippet of how you might scribble out a smiley face:

scribble(100, 10) do |s|
  s.line(100, 60)
  s.jump(150, 10)
  s.line(150, 60)
  s.jump(80, 70)
  s.curve(125, 90, [80, 80], [100, 90])
  s.curve(170, 70, [150, 90], [170, 80])
end

This creates the pleasant visage you see to the right.

I said last Monday I’d mention when the make_resourceful Rails plugin, which Hampton Catlin, Jeff Hardy, and I have been working on, is released. Well, as of yesterday (the 25th) around midnight, it was. See Hampton’s blog post for the official announcement. The main points are as follows:

• Very alpha release. The API is subject to change, although it probably won’t for the most part.
• There’s a Google group.
• Install with ./script/plugin install http://svn.hamptoncatlin.com/make_resourceful/trunk.

For those who didn’t catch my last post about it and are too lazy to go back and read it, make_resourceful is a plugin that allows you to factor out all the repetitive REST code that clutters up the controller a surprising amount. It manages this by automatically creating typical RESTful actions, while allowing plenty of room for user customization.

actions

Since I first started contributing to Haml, I’ve made sure to keep it separate from Rails as much as possible. I wanted Haml to be able to run just fine without ActionPack. This meant refraining from the use of any Rails helpers or extensions, as well as some fancy footwork to make the Haml/Rails integration seamless when Rails is being used, and nonexistent when it’s not.

I also made sure to expose a simple programmatic interface to Haml, so developers could integrate it into their own projects. The syntax was similar to that of other Ruby text filters like RedCloth¹:

Haml::Engine.new("%p Foobar").render #=> <p>Foobar</p>

This allowed for the easy creation of various bits of code using Haml. There have been hamlize rails helpers written. In the official gem, we have a haml executable that uses this to process files or standard input (I use this to Hamlize every XHTML or XML file I write). I believe several people (including myself) have independently created Radiant filters for Haml using this.

I just (well, as of last night) got back from RailsConf 2007, which I was attending courtesy of Unspace as a sort of thank-you for working on Haml. It was great fun. I got to meet many awesome people, including Hampton Catlin, with whom I’ve been working on Haml for a long time but whom I’ve never seen in person, as well as the rest of the Unspace team; various folks with whom I’ve talked on the Haml, Scribble, and Hackety Hack mailing lists; a couple members of the Rails core team; and too many other people to list here.

I also went to lots of engaging (and a couple boring) talks. By far the most interesting of these was a talk on a soon-to-be-released plugin called make_resourceful. The basic idea is to DRY up the code in RESTful controllers. Even with the new Rails support for REST, there’s some code that’s just always repeated. For example, for even a minimalistic update:

def update
  @person = Person.find(params[:id])
  if @person.update_attributes params[:person]
    redirect_to person_url(@person)
  else
    redirect_to :back
  end
end

Now, that’s not terrible. It’s only six lines. Most of the other typical RESTful actions (index, show, new, edit, create, update, destroy) are similar in length or shorter. But they’re all the same; the code is repeated over and over again. And when you get to having nested resources the code gets messier:

Yesterday, my old middle school had a “Career Day,” where a bunch of folks from different careers went to the school and set up a little table to talk about their career. They sent a letter off to the UW(University of Washington) CSE department asking for volunteers to talk about Computer Science, where it got forwarded to the undergrads list, where I read it and said, “Hey! That’s my middle school! I should help out.”

That was also around the time Hackety Hack had been released, and I thought it would be really cool to take in a laptop and let kids hack around on it. Programming is definitely the most glitzy part of computer science; that’s why intro CS courses focus on it rather than something more academic like graph theory or counting. I figured it would also be the most likely to interest kids, even kids of a slightly younger age than Hackety reccomends (the youngest were around 10, I think).

It turned out to generate quite a reasonable amount of interest. The structure of Career Day was to set all the tables with the various careers (there were about ten in total) up in a circle, bring the kids in grade-by-grade, and allow them to wander around looking at whatever interested them. My table with nothing much but some promotional DVDs and mousepads and the laptop running hackety was a little overshadowed by the Digipen table with the colorful display board, computer streaming videos of games, and even robot, but I did get a fair number of people wandering over to see what was what. I usually had at least one person Hackety Hacking away, occasionally with a gaggle of other kids surrounding them. In the course of watching them and helping them with their hacking, I learned some interesting things.

Girls and boys were about equally represented

Update: Check out the Scribble Google Group for additional news and information.

Update 2: Also use the Scribble Launchpad Site Group to make bug reports and stuff like that.