Deveiate

I’ve been playing around with the Webkit-based HTML view that TextMate provides for HTML command output, especially to see if I could use its fancier features to make an RSpec runner that was a little shinier and had some features I find myself monkeypatching into the default TextMate runner for every project.

I’m in love with the ‘Resources’ view that bleeding-edge WebKit’s Web Inspector includes, so I set out to adapt the progress-bar half of the page to reflect the status of examples, and ended up with something I’m pretty happy with.

After many weeks of pointless tweaking and perfectionist procrastination I released BlueCloth 2 yesterday, but the announcement seems to have been swallowed by the ruby-talk list server (I tried to post it twice). I’ve posted it here if anyone’s curious.

I’ve been working for the last 7 months or so on an RDF library for Ruby based on the Redland C library. I tried to use the bindings for it that are distributed under the redland-bindings package, but like with most SWIG-based bindings to C libraries, I found it brought me out of thinking in Ruby whenever I had to call into it. It’s not the author’s fault — a custom binding for any language takes time and a sense for its idioms — but I felt like RDF and Ruby could mesh better than the functional interface could express. I felt like scratching the itch I was feeling would not only help me learn more about Redland and RDF, but it would make the barrier to entry lower for other people interested in using Ruby together with RDF.

So I started Redleaf, and it’s pretty much at the point I wanted it to be for a 1.0 release. There’s still a few features that Redland has that aren’t accessible from Redleaf (graph contexts and transactions are the big ones), and I haven’t even tried it under 1.9 yet. I’m also pretty sure my string translation back and forth from Redland’s unsigned char *s to Ruby’s char *s will cause problems down the road (with UTF8 data, maybe?). Ruby 1.9’s strings-with-encoding are looking pretty good for that, but I have a lot of code to port before I can make the leap to 1.9.

Mostly what’s left to do is documentation work. The API docs are pretty solid, but the manual is only about 20% done. While I think I can probably release without having it done, I’d at least like it to cover the library well enough that people can start using it without too much experimentation.

So I’m off to write some more docs. Hopefully I’ll be far enough along by March that I can release it then.

We recently decided to ditch ActiveRecord for our domain classes at work for Sequel. We’ve already been using Sequel for a great deal of the database work we’ve been doing lately with our usage and trending analysis tool for our NetApp GX and our render farm, and it’s really a solid piece of work that makes interacting with a database a breeze. It’s nice to be working with datasets for this kind of stuff instead of having to pull out tons of objects just to grab a sample of a single column and throw them away again. Sequel lets you use all the features of your database, but the easy stuff is just as easy.

We’ve been feeling the pain of trying to track ActiveRecord updates, and it keeps making moves further away from being a useful library in environments other than Rails. I’ve been using Sequel::Model for this site’s back end, and the ORM parts of it are just as clean and powerful as the core. We’ve already done conversions of our most-complex and most-connected classes, and we’ve spiked out all the stuff we weren’t sure of and in every case the code shrank, things got a lot less magical, and the functionality stayed the same or improved.

A salute to Jeremy Evans, Sharon Rosner, and all the other people that made Sequel so great. It’s going to be a lot of work, but I’m looking forward to it.

The last two years has given me renewed respect for PostgreSQL, too. It’s performing like a champ under a steadily-increasing load (~ 8M inserts/day), and its partitioning, tablespacing, and triggers make doing data-warehousing stuff relatively painless. It’s in big part due to the genius of our DBA that set stuff up for us initially, but it was partly his enthusiasm for it that made me motivated to dive in and start learning more.

Hopefully I can convince Mahlon to write up the work he’s been doing with partitioning and tablespaces at LAIKA.