iBrasten

It shouldn't surprise anyone to learn that I haven't been able to work on Scruffy -- the Ruby-based SVG graphing engine -- in a very long time. And yet, it seems like people continue to download and use it more and more. Since my need for a graphing library is nonexistent for the foreseeable future, I don't think I'm the best person to continue working on Scruffy at this point. Software is best written by those who need it.

I do not intend on handing Scruffy to any random person, but if anyone out there thinks they can make a case for themselves you're welcome to contact me. In general, I'm keeping an eye out for someone who has been using Scruffy professionally for some time and has ideally already made significant code changes to Scruffy for their projects.

I'd also like to find someone who has a similar vision for Scruffy as I do. I never intended for Scruffy to be simply a Gruff replacement. Gruff is good enough for what it does. Today, most Scruffy usage involves rasterizing the SVG graph to an image. At the time this was a necessary evil, but I think we're rapidly approaching a time when Scruffy could serve straight SVG. This is, I believe, the ultimate goal for Scruffy and opens a bunch of new possibilities ( layout and theming via CSS, dynamic graph updates via JavaScript, etc ).

I'll be maintaining control of Scruffy for the foreseeable future as I'm not currently aware of anyone I'd trust to take it. But I'd love to hear from anyone who thinks they may be that developer.

There are quite a few little topics to catch up on since I've last posted, so I'm going to try and break them up into fewer, smaller posts. This post is just a general overview of what I've been up to over the last few months.

A brief detour into Perl-land

Just over six months ago I took a contract working in Perl. I had never worked in Perl and quite honestly had never intended on working in Perl. Still, the project sounded fun and I enjoy the opportunity to learn new [to me] things. It also provided the opportunity to work for/with a guy who is basically the Perl version of Tobias Lütke or Rick Olson. It's difficult to turn down an opportunity to learn a new technology from one of the best that technology has to offer.

Six months of Perl development later, I'm able to say that Perl doesn't suck as much as I'd always thought. The language itself is tricky, and this seems to have produced an awful lot of horrible Perl code "out there." I discovered, though, if you know how to write good Perl you can produce some decent looking code. With the project soon coming to an end, I'm saddened that I'll not be able to continue using my newly-acquired skills. Getting comfortable with Perl took me a little time, but I think I was just starting to [relatively] rock at it! If the right opportunity came along, I would not be opposed to working in Perl again.

My language-crush on Ruby did not disappear, however. The mental separation of working in Perl and playing in Ruby gave me a chance to play with some personal projects in my spare time -- free of the outside influences of a Ruby-based project. All of which leads me to my second topic...

Merb, Merb, the musical fruit...

This isn't a very elegant way of putting it, but: Merb. Kicks. Ass.

I had honestly begun to feel a bit disenchanted with Rails when I took the Perl project. I quickly discovered that I was not as eager to build a random Rails application in my spare time when I no longer had any financial incentive to work with it. I'm not complaining; I completely respect that DHH did not develop Rails to make Brasten Sager happy. Rails is what DHH needs it to be, and in my completely irrelevant opinion it's still the second-best framework for my purposes.

This post is more of a personal narrative than any kind of technical article, so I'll skip the bullet-point list of Reasons I Like Merb. Instead, here's the one-paragraph explanation. Every time I created a new Rails application I often ended up writing the same code (or copying from a previous project) to solve a whole list of minor annoyances. Merb largely solves all those things for me right out of the box. The Merb guys obviously write web applications the same way I do and they've written a framework that feels the way I want a framework to feel.

Of course, your mileage may vary.

More posts hopefully coming soon, stay tuned!

So, web clips are much much cooler than I anticipated. You can change up your dashboard weekly or daily based on interests at the time. For example, clipping out a little Flash object yesterday gave me quick access to a particular fund-raising effort I wanted to track:

Just one thing I can't figure out though... is there any way to package a web clip into a widget that can be uploaded or otherwise transfered to another computer? If you know how to do that, leave a comment!

Heavily modified, but based on the RubyRobot theme for TextMate (worth checking out).

HTML/XML colors are intentionally higher contrast than normal since, in my experience, I'm often looking for specific attributes/values or Ruby code.

Slight differences between NetBeans and TextMate versions, obviously, due to different syntax colorization rules. NetBeans pictured below:

• FadeToGrey - NetBeans
• FadeToGrey - TextMate