Rush The Shell

I just read the latest posting from Adam Wiggins, very cool dude, hard-core Rubyist, and friend. He has a new project called Rush, the Ruby shell. Adam is one of the guys behind Heroku, which is a pretty amazing pure web browser-based IDE/deployment/hosting solution for Ruby on Rails, if you haven't seen that yet.

Anyhow, like many of us, Adam seems like he just wants to use Ruby for everything. And when I say everything, I mean EVERYTHING. Writing bash scripts.... sucks. Destroying the sanctity of your Ruby code with

`bash-shell-command /ugly /madness`

is not hardly any better. My man is trying to help us do away with all that, by applying a friendly familiar Rubyness, not just caging the ugliness away.

Here is a little taste of Rush, from the Rush site:

How about killing those pesky stray mongrels? Before:

kill `ps aux | grep mongrel_rails | grep -v grep | cut -c 10-20`

After:

processes.each { |p| p.kill if p.command == "mongrel_rails" }

But rush is more than just an interactive shell and a library: it can also control any number of remote machines from a single location. Copy files or directories between servers as seamlessly as if it was all local. bash and ssh, we love you, but your era is past.

Example of remote access:

local = Rush::Box.new('localhost') 
remote = Rush::Box.new('my.remote.server.com')
local_dir = local['/Users/adam/myproj/'] 
remote_dir = remote['/home/myproj/app/']
local_dir.copy_to remote_dir 
remote_dir['**/.svn/'].each { |d| d.destroy }

I have not had a chance to play with Rush yet, but I'm sure I will be. Unix shell scripting is not syntactical sugar, that is for sure, and Rush looks pretty sweet.

Everybody Into The Pool

A few weeks back, I indulged my current obsession with grid computing, and Amazon's EC2 and S3 services in particular, with a lengthy post. I mentioned how friend Ari Lerner and I had built a really neat solution, and were going to put all of our processing farm goodness into a nice neat gemified package. Well, mostly thanks to Ari, we now have a new Ruby gem called ProcessorPool that uses EC2 and S3 to do all the hard work for you.

Based on Sinatra, with a bunch of S3 goodness mixed in, the ProcessorPool gem makes it staggeringly easy to exploit the power of the EC2 grid. More info about it is available at the Blog @ CitrusByte, and you can also check it out on RubyForge here.

All kinds of fun applications await you in the pool... image processing, video/audio transcoding, heavy computational stuff, long crawls of content... and it is fun to delegate to a pool of worker machines in the EC2 cloud.

Come on in... the pool is fine.

Getting To Usable

I read a great posting last night from Matt Rogers, founder of startup Aroxo, on a strategy for usability testing. Suddenly, I was flashing back a few years to the early salad days of web usability...

When I first read Steve Krug's tiny masterwork "Don't Make Me Think", I was very excited; at last, a nice practical approach! After the pedantic and overly academic work of guys like Jakob Neilson, Krug's book hit me like Dr. Seuss taking out Dick, Jane, and Spot.

Somehow, Rogers' post reminded me of that sudden flash of clarity in the fog. Yes, we can DO this! Gentlemen and ladies, start your testing...

You Got Your DS In My Robot

The French press may be reeling in financial scandal, but the cool kids there are still concentrating on what is really important: drinking wine and controlling an open source robot with a heavily modded Nintendo DS.

The Pekee Mobile Robot and a whole bunch of DS hacking. That in itself just sounds like hours of fun. But then can you just imagine real-world robotic battles in your living room, fought remote controlled by DS. Can I preorder now?

C'est Manifique!

Ruby.NET, We Hardly Knew Ye

It comes as not entirely surprising that the Wayne Kelly of the Ruby.NET project from down under has finally given up the ship. Microsoft had already grabbed the spotlight with IronRuby and the DLR. Despite some early gains, it seemed that development momentum had peaked, until Ruby.NET finally made its way up onto Google Code and a "real" open source project.

How, how will John Lam and team proceed without Ruby.NET around? I seem to recall a conversation I had with John when we were at RailsConf, and he was telling me since his M$ cannot look at open-source source code due to patent issues, they were unable to look at the MRI code in order to implement IronRuby. He said they WERE able to look at the Ruby.NET code due to some weird licensing thing. Does this mean they have now had their way with Ruby.NET, and they are done with it?

The DLR is a very cool concept, but it seems like is a lot more than many developers want, particularly polyglot ALT.NET folks who just want to add some capabilities most easily implemented in the Ruby-language, more than they want to switch over to pure Ruby.

Reading further in the mailing list thread, it seems like others in the Ruby.NET project are not quite ready to throw in the towel quite yet... but is it already too late for them?

Recaptcha On Rails

UPDATED Oct. 15, 2009 with most current info

I hate implementing captchas. You know, those annoying things that your users think are deciphering hieroglyphics. I have hated them because I do not want to install a whole massive assemblage of software like ImageMagick/RMagick just to provide some basic protection from spam and bots.

To avoid this, I had hacked together a simple implementation using some free public captcha. However, a client recently turned on SSL on their signup page, and my free public captcha gave a nasty error cause of the domain name in the SSL certificate not matching the domain of their site. How cheap!

I needed a new solution. I waded thru pages of search results with the dreaded RMagick sotuions. But then, lo and behold, I discovered there is a fantastic simple plugin for Ruby on Rails from Ambethia that supports the marvelous Recaptcha.

Recaptcha is a really neat project that uses crowdsourcing to implement a form of human OCR on old books that defy machine OCR. They need human scanners, and we need proof that the people signing up on the site are human. Perfect match!

Less than 10 minutes later I had the plugin installed, implemented, and deployed in production. It is that easy. Here is a four step process that will have you up in moments:

Step 1 - Install the Recaptcha plugin

script/plugin install git://github.com/ambethia/recaptcha.git

'Nuff said.

Step 2 - Set Your Recaptcha Account Data in Rails
OK, so I lied. You need to tell the plugin what your account info is, and if you do not yet have a free Recaptcha account, you will need to sign up for one. Once you do, save your keys into config/initializers/recaptcha.rb

ENV['RECAPTCHA_PUBLIC_KEY'] = 'youractualpublickey'
ENV['RECAPTCHA_PRIVATE_KEY'] = 'youractualprivatekey'


Step 3 - Display The Recaptcha Widget In Your View
You will need to display the Recaptcha widget somewhere. In my case, it was the signup page for the site. Just put this view helper where you want the widget to appear:

<%= recaptcha_tags %>

If you are using SSL, use this instead:

<%= recaptcha_tags :ssl => true %>


Step 4 - Validate The Recaptcha
You need to make sure that the user entered the proper values for the Recaptcha. Just add this to the controller action that the view submits to:


If you want to display any Recaptcha errors right along with any model errors of the model you are trying to control adding using the Recaptcha, you could do this instead:



You may have guessed by now that it took me longer to write this posting than to implement Recaptcha using the Ambethia plugin. Hey, that is just the kind of guy I am. It was just so cool, and such a quick solution to a common problem, that I couldn't help myself.

Let the digitizing begin!