Brad McConahay

After recently using the Ruby-based s3sync tools to handle backups to Amazon’s S3 service, it seemed a good time to give the Ruby programming language a fair shake and see what all the hubbub was about.  I had a little exposure to Ruby a couple years ago using a book tutorial to create a blog in Ruby on Rails, but didn’t really learn much about the language itself in that process.  And having recently discovered The Dev Show podcast on the 5by5 network, it’s also possible their extreme Ruby bias started rubbing off on me!

Speaking of which, has anyone else noticed that all Ruby podcasters and screencasters sound like they’ve been neutered and reprogrammed by aliens to be void of all but the most mildly pleasant Xanax-laced emotions?  Very even keel and NPR-sounding, as you drift… off… into… Roooooooby…..

It always helps to have a real application when learning something like a new programming language, and having recently completed an upgrade to my Perl Module for the QRZ Callbook API, it seemed that porting it to a Ruby Gem might be the perfect goal.  Armed with “The Ruby Cookbook” and “The Ruby Programming Language” in my Safari Books account, and some free time during the holidays, I began.

The first problem encountered was trying to use Ruby on Debian, the epitome of stability in my opinion, and my server environment of choice for that very reason.  The Ruby package for Debian had already been installed on the system in order to use s3sync.  But when trying to do something as simple as listing the remote Ruby Gems, it produced a fairly cryptic error.  Researching the error eventually led to this post from one of the Debian package maintainers. The reputation of Ruby’s instability was immediately showing itself.

Compiling Ruby from source seemed the only realistic way to move on.  I installed the latest version, 1.9.2.  It seemed like a good idea at this point to make sure s3sync and s3cmd were still working, only now they were producing fatal errors.  Research confirmed that the s3sync tools simply do not work with Ruby version 1.9.2.  So I installed Ruby version 1.8.7 from source instead, and thought very seriously about abandoning the project.

Eventually I did finish and publish my new Ruby Gem and felt a little less behind the programming curve afterward.  (Read: keeping up with the youngstahs)  I do like the language a lot – it feels like you can accomplish many things in fewer lines than other languages, and that the code is very clean and legible.  And it does seem that there’s something just plain fun about it, similar to the way OS X feels good in a can’t-necessarily-put-your-finger-on-it way.  And RVM (Ruby Version Manager) appears to be a slick (and fun) way to manage an otherwise unstable version environment.

Fluency in both Perl and jQuery seemed helpful since most concepts in Perl translate fairly well to Ruby – such as the array and control structures – and the endlessly chained object oriented methods feel a lot like jQuery.

Time and energy-allowing, I’ll probably take a more serious pass at Rails; I have an application in mind.  I abandoned Rails the first time when it became clear that incorporating it into our Apache-based server environment at work wasn’t realistic.  This time the approach will be with an application that’s more standalone in nature.  And after learning about Passenger, I have at least some confidence that maybe Rails and Apache can co-exist better than used to be the case – and it might not even be slow!  We shall see…

Occasionally I find myself trying to explain why I can’t switch from one technology to another. Invariably, it’s been so long since trying to switch that I can’t remember the reasons why, and I end up unable to explain myself. One of the these technologies is Google Mail. While it’s on my mind, I thought I might document the reasons here before I forget again.

I’ve been using Google Apps for both work and personal Email for several years, and I love it for many reasons. The web-based interface does come in handy from time to time – it’s the only way to search for messages and administer the account – but, there are a few pieces of functionality implemented oddly enough that I can’t use it as my main interface for mail. So I continue to just use it as a back-end via IMAP with a mail client native to whichever operating system I’m using at the time.

Until last year, threaded messages was one of these stoppers. Thankfully, Google finally offered the option to turn that off. Google’s products often remind me of 37 Signals in that they believe they know more about what you need than you do. The result is that they offer limited configuration options; forced message threading was a glaring example of that.

But, that still leaves two annoyances I’m unable to move beyond…

1. The date on the message listing shows only the date, and not the time of day – unless the message was received on the current day. Further, if you want to know the time the message was received, it’s two clicks away. After viewing the message, you must click “show details”, as though the time of day the message was received is of little value. When trying to switch, I was amazed at how often I needed to know that, and how annoying it was when it wasn’t immediately visible in the message list. I would like the option of having something brief like “2011-01-01 2:37p” on each and every listing.

2. When replying or forwarding a message, instead of including the basic header info listed above the quoted original message, it only says, “On Jan 01 2011, Bob Smith wrote:”. The million dollar question this leaves is: who was copied on the original message? Am I really the only person who finds it highly useful to know who was copied on the original message? (Apparently so.) This really makes it feel like a toy rather than an enterprise level interface. And this isn’t just a problem with Google. Most free email clients, like Mozilla Thunderbird and Apple’s Mail client for OS X, have this same problem to one degree or another. Some will use the full header info with forwarded messages, but not replies.

Oddly, Microsoft seems to be the only maker of email clients that understands this. So in the meantime, I continue use Outlook on Windows, and Entourage on OS X. And there’s no decent equivalent for the Linux desktop the last time I checked – same problems.

There’s also the bigger issue of any web-based interface with not being able to just arrow down through each message in the list and see a full preview of the message, but I think I could get past that.

While reading tech news stories, I often see writers mention that RSS feeds are becoming irrelevant due to the increasing popularity of Twitter and Facebook, and the ability to get news through their feeds.  They would have you believe that RSS feeds and readers are on the way out, but I think quite the opposite is true.

It’s definitely possible that Twitter, or Facebook, or some new service will figure out a different way to format article links and titles embedded in updates in a predictable way that some new type of aggregator will be able to save for you.  But why would anybody do that when RSS is already ubiquitous.  Until these social networking feeds become strictly channelized, it’s tough to pull out every article from all your favorite news sources.  Even then, it still feels very kludgy to try and form the output of a Twitter feed into something as useful as RSS already is.

On a larger scale, I’m not convinced that the Twitter model will last in its current form anyway.  I’ve heard people whose opinions I respect say that Twitter will soon be the “new dial tone.”  It would be fun to think so, and I believe its style of communication will carve out a permanent place on the Internet, I just don’t think people will find it useful for everything.  Like so many technologies before Twitter – blogs, push, frames, chatrooms, and even RSS comes to mind – they’ve all found a their uses within the big picture, but they haven’t overtaken as some completely new and dominant paradigm like these writers would seem to imply.  They also say that the new attention-scattered generation is why Twitter will eventually take over, but it doesn’t appear that teens really care about these services more than their older counterparts.

Honestly, I’m not sure they know the scope of what they’re saying when they flippantly mention that RSS is becoming irrelevant.  Based on past experience, I wouldn’t look for the little orange RSS icons to go away any time soon.

(syndicated from blog.netcrafters.com)