I’ve given over maintenance of RestClient to Julien Kirch (archiloque). He's got a 1.1 release now in Gemcutter/Rubyforge, with some hot new features:

Pony is a little project I started a year ago for quickly and simply sending mail from Ruby. The project showed a lot of promise, and many people were excited about it (as you can tell by the 30+ forks on Github); but I never found the time to take it to its full fruition.

Ruby gem repositories are a bit of a headache right now. The current options:

• Rubyforge - In addition to being a gem host, Rubyforge has lots of features you may (but probably don’t) care about. Sourceforge-style projects, revision control, mailing lists, and so on. gets in the way of the one thing you certainly DO care about: publishing gems. Putting gems on Rubyforge is a very manual process (though Jeweler and others offer automation workarounds). Gem propagation is slow, as long as 24 hours to propagate to all mirrors.
• Github - Publish gems to gems.github.com by bumping your revision number and then git push. (Deploying with git push makes sense to me, naturally.) Typically they get built within ten minutes. Github is good for diversity since every fork can have their own gem, but this is its strength as well as its weakness. Having a canonical place to look up the primary version of a gem, in particular for automated dependency resolution, makes Rubyforge still the top pick for publishing major gems.

So essentially RoR is a programming language that is only now coming of age. And what struck me at Railsconf was that as a community they are taking cloud computing as a given. This is how you deploy apps. Period.

[…] The Ruby community is essentially skipping traditionally on-premise installed software. The dominant model for RoR application deployment is cloud, with platforms such as Slicehost (now part of Rackspace Cloud), Engine Yard and Heroku. Cloud services such as New Relic, FiveRuns and Scout provide the de facto standard monitoring and management frameworks, and cloud-based GitHub is the standard code version and developer collaboration tool for the RoR generation.

Moreover, training courses and educational books, such as Oreilly’s Learning Rails , use cloud platform Heroku as their standard learning environment. Meaning that a new generation of developers, for whom Ruby is their first or early programming language, are growing up with cloud platforms as a natural part of life, just as my kids are growing up with Google Docs, Wikipedia and smartphones as a natural part of life. Imagine that.

It’s no secret that I try to avoid requiring ActiveSupport when I can. But one thing I do really like about it is the time capabilities. Stuff lke this:

In Part 1, we built QFeedReader, a simple and scalable web-based RSS reader backed by DJ.

Queueing is a critical tool for building truly scalable web apps. Don’t do any heavy lifting in the web processes (mongrels); instead, put jobs on a queue, let background workers do the work, and then display the results to the user in another request.

My favorite feature of Ruby’s gsub is the ability to pass a block:

"1|2|3".gsub(/\d/) { |m| m.to_i+1 }    # => "2|3|4"

gemweight.rb is a script to calculate the memory use and load time of a given gem. This is a pretty off-the-cuff measure - it doesn’t consider dependencies loaded (or not loaded, if the gem loads them on demand). But I thought it was mildly interesting nonetheless. Results for some common gems:

A slow but inexorable shift is happening in the Ruby world. Ruby, and its halo of libraries and frameworks, is transitioning from a snot-nosed upstart and into an accepted technology.

Want to fire off a quick email from your Ruby script? Finding ActionMailer to be overkill, but Net::SMTP to be…um, underkill? Envious of PHP’s mail(), which sends an email with a single function call?

The file manipulation routines in Ruby’s stdlib are a bit of a mess. Operations are scattered among different classes - File, Dir, and FileUtils. Methods often aren’t where you expect them - like File.directory? but not Dir.directory?. But worst of all, they aren’t object-oriented. You’d want to make calls like f.size or f.directory?, but instead you’re stuck with File.stat(f).size and File.directory?(f).

John Nunemaker created HTTParty, a library for making web requests. So the options for making web calls from Ruby are now:

The new RubyGems doesn’t update the index every time, so gems install very quickly. Add the --no-rdoc --no-ri options and they install instantly. Excellent.

Rack is one of the most important developments in the Ruby web space in the past year. I suspect it’s been slow to get attention because the benefits are a bit subtle. Witness the Rails core team being confused about Rack just a few months ago. So if you don’t get what the deal is with Rack, don’t feel bad - you’re in good company.

Mongrel, Thin, and every other web application server I’ve ever used all suffer from a similar deficiency: they daemonize too early. That is, they daemonize prior to trying to boot your app, which means any error - even a really obvious, immediate boot problem - will silently feed into the log as the process dies, without so much as a peep on the command line.

A friend of mine, who is a Ruby developer but a little less immersed in the Ruby culture than I, was recently boggling at the excitement around the new VMs (Rubinius, JRuby…) and new frameworks (Merb, Sinatra…). “Wait,” he said. “They’re replacing Ruby, and they’re replacing Rails. So what the heck defines the Ruby on Rails community, if both Ruby and Rails are replaceable?”

I was rather taken with inject when I first started getting serious with Ruby. It allows you to turn ugly, imperative-style loops requiring temporary variables into functional-style expressions. Like this:

Yesterday I had a chance to tinker around with a new project using Merb, DataMapper, RSpec, and Thin. Merb + Thin means your app serves up pages twice as fast, with half the memory. Merb + DataMapper means your app is threadsafe. RSpec + DataMapper means your tests are completely independent of the database - which means no db:test:prepare step, so the tests run lightning fast and without fragile database dependencies.

REST is part of the Ruby Way. Which is why I’m surprised that every time I go to access a RESTful resource, I find myself writing some sort of ad-hoc rest client. Net::HTTP is too low level - you’ve got to write at least three or four fairly dense lines of code even for a relatively simple GET or PUT.

git-wiki is a wiki written in less than 200 lines of code using Sinatra as the web framework and Git as the database. Quite clever. Check out how they store the CSS at the end of the file using __END__ - a Ruby trick I was previously unawrae of.

The unix shell (bash) and remote login (ssh) are centerpieces of the server and app deployment process. While building Heroku, however, Orion and I became aware that these tools are pretty far out of step with modern, agile development practices.

There appears to be no documentation for Ruby’s readline support. What’s worse, it’s written in C, so you can’t (easily) read the source to find out its interface.