Raptor: A Forthcoming Ruby Web Server for Faster App Deployment

This post is by from Ruby Inside

Click here to view on the original site: Original Post

Raptor bills itself as a new Ruby “app server” and it claims to blow everything else out of the water performance-wise (by between 2-4x!) whether that’s Unicorn, Puma, Passenger, or even TorqueBox on JRuby. The bad news for now is there’s no source or repo yet and only a handful of people (including me) have been given a sneak peek, although a public beta is promised on November 25th.

The history of Ruby webapp deployment

The deployment of Ruby (and therefore Rails) webapps was a painful mess for years, a state I lamented 7 years ago in No True ‘mod_ruby’ is Damaging Ruby’s Viability on the Web. Thankfully, shortly thereafter a number of projects came out to make life easier, the most famous being Phusion Passenger (then known as mod_rails) in April 2008.

Things have continued to improve gradually over the years, with Passenger getting consistently better, and new approaches such as those offered by Unicorn and Puma, using JRuby, as well as proxying through Nginx, coming into the picture.

Enter Raptor

Raptor, a new entry to the burgeoning world of Ruby Web servers, boasts some compelling features. “Visibility” is cited as a key feature so that you can look ‘into’ your app and analyze its performance as easily as possible using a JSON API (so building your own tools around the API should be simple). Raptor also uses the HTTP parser from Node which itself was derived from Nginx’s HTTP parser; both are renowned for their speed and stability. Raptor boasts a zero-copy, concurrent, evented architecture which makes it efficient memory and IO-wise – so even if you have slow clients or a slow network, these won’t bring your app server to a stuttering standstill.

Another feature that jumped out at me is integrated caching. Raptor doesn’t rely on an external services like memcached or Redis at all, but is truly internal and optimized specifically for Web workloads. If you’ve never set up caching before, this could provide a big boost as with Raptor it’ll be available “out of the box”.

The initial results seem promising. Fabio Akita has already shared some early benchmark results which broadly mirror my own experience (disclaimer: as someone with rather little experience and authority in benchmarking, my benchmarks are oriented around Raptor’s own benchmarking suite) but, as always, YMMV and such benchmarks are often criticized.

The waiting game..

The team behind Raptor promise they’ll be releasing some interesting blog posts soon about the technology behind it, including how the cache is implemented and has been optimized, how the zero-copy system works and how it’ll benefit your code, and similar things. So keep an eye on rubyraptor.org, especially around November 25th.

rbenv: A Simple, New Ruby Version Management Tool

This post is by from Ruby Inside

Click here to view on the original site: Original Post

rbenv is a new lightweight Ruby version management tool built by Sam Stephenson (of 37signals and Prototype.js fame).

The established leader in the Ruby version management scene is RVM but rbenv is an interesting alternative if you want or need something significantly lighter with fewer features. Think of it as a bit like Sinatra and Rails. It’s not about which is the best, it’s about which is better for you and your current requirements.

What’s the deal with rbenv?

Compared to RVM, rbenv is light. For example, it doesn’t include any mechanism to install Ruby implementations like RVM does. Its sole job is to manage multiple Ruby “environments” and it allows you to quickly switch between Ruby implementations either on a local directory or default ‘system-wide’ basis.

With rbenv, you install Ruby implementations manually or, if you prefer a little help, you can try ruby-build, another project of Sam’s that provides RVM esque recipes for installing seven popular Ruby implementation and version combos.

rbenv primarily works by creating ‘shim’ files in ~/.rbenv/shims which call up the correct version of files for each Ruby implementation behind the scenes. This means ~/.rbenv/shims will be in your path and there’s no threat of incompatibilities between libraries or systems like Bundler and rbenv.

The key thing to be aware of, however, is that if you install a gem that includes ‘binaries’ (or any generally available command line scripts), you need to run rbenv rehash so that rbenv can create the necessary shim files.

How to Install rbenv

Firstly, it’s worth noting that by default rbenv is incompatible with RVM because RVM overrides the gem command with a function. This means to get the full rbenv experience you’ll need to do a rvm implode to wipe away your RVM installation or, at the least, remove/comment out the RVM loader line in your .bash_profile and/or .bashrc.

The installation instructions for rbenv are likely to change fast due to its youth, so I suggest the README. However, rbenv has just been made into a homebrew package on OS X, so if you’re a homebrew user (and if you’re not, check out my screencast), try:

brew update
brew install rbenv
rbenv rehash

And then add this line to your ~/.bash_profile or equivalent:

eval "$(rbenv init -)"

When you open a new shell now, you can run commands like rbenv and rbenv version to see what’s going on. rbenv versions should return nothing since you won’t have any rbenv-enabled Ruby installations yet, so move on to the next step..

Installing Implementations for rbenv

If you have ruby-build installed, getting, say, Ruby 1.9.2-p290 installed is easy:

ruby-build 1.9.2-p290 $HOME/.rbenv/versions/1.9.2-p290

If you prefer to download tarballs and do your own Ruby installs, however, you just need to set the directory prefix at the ./configure stage in most cases. For example:

./configure --prefix=$HOME/.rbenv/versions/1.9.2-p290

Once you’ve installed a new Ruby in this way, you need to run rbenv rehash in order for rbenv to create the ‘shim’ binaries necessary to make the correction version of Ruby available on the path at all times.

The RVM Splashback

In the interests of completeness, it’d be amiss to not mention the minor drama that kicked off on Twitter and Hacker News about rbenv’s release.

rbenv made its way on to Hacker News where, surprisingly, many people railed against RVM. This, coupled with a slightly antagonistic tone taken by rbenv’s README (which has now been taken away), led RVM’s maintainer Wayne E Seguin to vent some pressure on Twitter:

Sam quickly clarified his position:

Nonetheless, Wayne took a little time off, and a campaign to encourage donations to Wayne for his work on RVM was kicked off on Twitter (by Ryan Bates, I believe). The campaign went well, taking RVM’s donations from $7468 to $11370 (at time of writing), a jump of almost $4000 in a few days.

Part of the complaint made in rbenv’s README was about RVM’s “obnoxious” redefinition of the “cd” shell builtin. Essentially, RVM would create a new function which called “cd” but also took into account any .rvmrc files present in each directory so that it could change Ruby version automatically. While there was some validity to this concern, Ben Atkin took some time to write a blog post correcting some of the misinformation on this point.

In the end, however, all seems to be well, and Wayne is already making regular commits to the RVM project again just days later. Hopefully the outpouring of support from the Ruby community for RVM over the past couple of days has shown Wayne that RVM still has a significant user base, most of who aren’t going anywhere new anytime soon. If you want to help out, of course, you can still donate to the RVM Pledgie.


If you’re happy with RVM, there’s not much in rbenv to really leap to. It’s just a lighter and more modular way to achieve the basic functionality that RVM provides while missing out on a lot more (although you can use rbenv-gemset to get some basic gemset-like features).

If, however, you want something “lighter” than RVM, rbenv is certainly worth a look. Its approach feels cleaner and more transparent at a certain level, and if this is of utmost importance to you, you may prefer it. I suspect for the most part, however, RVM’s well-deserved dominance of this area will be maintained.

[ad] Code School is the interactive online marketplace where you can learn to code directly in the browser and the home of the famous “Rails for Zombies” course (which is free to take!) Other courses include Rails Best Practices, jQuery Air: First Flight, and Functional HTML5 & CSS3.

Watchr – More Than An Automated Test Runner

This post is by Joe Fiorini from Ruby Inside

Click here to view on the original site: Original Post

Watchr is a development tool that monitors a directory tree and triggers a user defined action (in Ruby) whenever an observed file is modified. Its most typical use is continuous testing, and as such it is a more flexible alternative to autotest. It is maintained by Martin Aumont and available on GitHub.

Watchr works by allowing you to specify the path to the file or files you want to monitor. When the file is changed it executes whatever block of Ruby code you give it. As the README states its most common use case is as a replacement for autotest. After using Watchr for a couple years now, I have learned that it’s much more than that. For example, it has helped me automatically copy a setup script to a virtual machine while building it and to update large blocks of content in a database.

How I Used Watchr to Automate Shopify Theme Development

I recently started a Shopify project with a colleague (Shopify is a hosted platform for building ecommerce sites). Users can edit their store’s look and feel through a web-based admin interface. This may work for most shop owners, but I’ve grown accustomed to editing text in Vim and working at the command line. Fortunately, Shopify has a very nice API for uploading templates to your store. Watchr to the rescue! I fired up my editor and not long after I had a very helpful script:

require 'shopify_api'

watch('templates/.*\.liquid') do |match|
  puts "Updating #{match[0].inspect}..."

def upload_template(file)
  ShopifyAPI::Base.site = "http://{key}:{secret}@{domain}.myshopify.com/admin/"
  asset = ShopifyAPI::Asset.find(file)
  asset.value = File.read(file)

With this script all I have to do is save the file I’m working on and Watchr uploads it to Shopify for me. How does it work? The directory structure on my file system mirrors Shopify’s template structure. All my script has to do is read the file and send the path and contents to the server. Watchr uses OSX’s native File System Events API to listen for changes to files matching the path string I pass into watch. When a matching file changes, it executes the block and hands in the path to the changed file (or files).

These simple Watchr scripts have saved me time and, more importantly, frustration. With just a few lines of code I can automate away tedious parts of my day while following my preferred workflow and not compromise efficiency. Watchr is not just about running my tests, it’s about improving my workflow as much as possible.

More Info

Want some more information? Check out Watchr on Github, check out the docs, or read the wiki for some more examples. When you’re ready to get started run gem install watchr and write your first script.

Editor’s note: I just noticed that Ric Roberts wrote Watchr: A Flexible, Generic Alternative to AutoTest for Ruby Inside back in 2009. You might find that post useful too.

Joe is a Software Craftsman at LeanDog Software where he helps run their Ruby
delivery practice on a boat in Cleveland, OH. He blogs about
software-related topics at http://blog.densitypop.com and tweets as

RubyGems 1.5.0 Released: Now Supports Ruby 1.9.2

This post is by from Ruby Inside

Click here to view on the original site: Original Post

rubygems.pngRyan Davis has announced the release of RubyGems 1.5.0. It comes just a month after the release of 1.4 which, notoriously, didn’t work with Ruby 1.9.2. These problems have now all been ironed out and Ruby 1.8 and 1.9 users alike can safely upgrade (fingers crossed).

RubyGems is the popular (and official – as of Ruby 1.9) Ruby package manager with which most significant Ruby libraries and tools are distributed. The 1.5 release sees it pick up a few bug fixes and some enhancements, including:

  • Ruby 1.9 support
  • Post-build hooks that can cancel the gem install
  • Gem.find_files is now 40% faster (on Ruby 1.9)
  • Better errors for corrupt Gem files, including paths
  • A new UPGRADING documentation file to help with Ruby 1.9-related issues
  • gem update no longer erroneously tries to update RubyGems itself by default

To upgrade to RubyGems 1.5.0, run:

gem update --system

Alternatively, you can learn more in the new UPGRADING documentation, or if you don’t already have RubyGems for some reason, you can download it from RubyGems.org.

UPDATE: RubyGems 1.5.0 and Bundler are not the best of friends! If you’re depending on Bundler tonight, don’t install RubyGems 1.5.0 just yet. However, a 1.5 compatible version of Bundler is due within the next 24 hours. A new version of Bundler has been released, supporting RubyGems 1.5.0. Upgrade now 🙂

[ad] Spreadable is a powerful ‘tell a friend’ referral tool you can easily plug into your site. It brings your app powerful viral social tools you and your users can use to spread the word about your work.

Rails Ready: Ruby and Rails on Ubuntu in One Line

This post is by from Ruby Inside

Click here to view on the original site: Original Post

How would you like to get a full Ruby on Rails stack up on Ubuntu with one command?

Now you can by running Rails Ready. Rails Ready is a setup script that gets Ruby and Rails running on a fresh install of Ubuntu with one command (Tested on Ubuntu server 10.04 LTS (Long-term Support)).

Adam Stacoviak

Rails Ready is essentially just a shell script but one you might find useful if you’re running Ubuntu (or – update – CentOS) and want to get the installation process done and over as quickly as possible. It follows on rather nicely to our last post: Ruby Installer: Ruby and Rails on Windows in a Single, Easy Install!

If you have the time or you’re installing this on your main development machine, however, I would recommend following Ryan Biggs’ RVM based instructions (or my equivalent screencast) because RVM gives you more developer-level control later on (such as gem sets). UPDATE – Josh has been working hard and says that Rails Ready “now asks you if you want to build from source or install RVM” – nice!

Nonetheless, if you want to get a new Ubuntu (or CentOS) box running Rails as quickly as possible, Rails Ready is worth a try. The short version:

wget --no-check-certificate https://github.com/joshfng/railsready/raw/master/railsready.sh && bash railsready.sh

Before running the above, though, be aware of the ramifications. You should probably take a look at https://github.com/joshfng/railsready/raw/master/railsready.sh yourself to see if it’s suitable for you.

Parslet – A Simple PEG Parser Framework for Ruby

This post is by from Ruby Inside

Click here to view on the original site: Original Post

Screen shot 2011-01-12 at 2.32.49 AM.pngParslet is a new “simple parser framework” for Ruby built by Kaspar Schiess. It follows the PEG (parsing expression grammar) style of parsing and its primary goals are to be simple, testable, and to have extensive and powerful error reporting features (something that Kaspar states Treetop sorely lacks).

If you’ve already used Treetop, you might wonder what the hoopla is about. The key difference is that Parslet does not generate code to represent the parsing grammars you create as Treetop does – it works directly from rules defined using standard Ruby syntax (Treetop has its own Ruby-esque grammar language). Parslet’s error messages are also significantly nicer than Treetop’s when you inevitably run into trouble with your grammar as they’re generated by Parslet itself and don’t spring from Treetop’s internally generated code.


So if you need to build a parser (or think you might), check out Parslet – it has a great homepage with some useful documentation. Installation is simple (gem install parslet) and Kaspar has put together a “getting started” tutorial that walks through building a basic grammar for a teeny-tiny programming language. It concludes with a complete example of a programming language interpreter in a mere 49 lines.

RubyMine 3.0 Released: An Improved Ruby and Rails 3.0 IDE

This post is by from Ruby Inside

Click here to view on the original site: Original Post

rubymine.png JetBrains (of IntelliJ IDEA fame) has today released RubyMine 3.0, the latest version of its cross-platform Ruby and Rails IDE. It follows on almost 18 months to the day from RubyMine 1.0. Back then we noted that the public reception of RubyMine was strong and JetBrains have only made it better since then.

If you’re not already familiar with RubyMine, it’s a cross-platform Ruby and Rails IDE based upon IntelliJ IDEA (to me it’s always seemed faster than the Eclipse-based IDEs) that runs on Windows, Linux, and Mac OS X. It comes with a custom Ruby debugger, as well as version control integration (SVN, Git, Perforce and CVS) and support for several test systems out of the box (specifically RSpec, Cucumber, Shoulda, and Test::Unit).

Sounds great, right? The only downside: it’s a commercial product clocking in at $69 for a personal license and $149 for a commercial license, though free licenses for “open source projects” and “trainers and educational institutions” are available.

If you are familiar with RubyMine, RubyMine 3.0 is a significant update that comes with complete Rails 3.0 support, RCov code coverage report support, a significantly improved Ruby debugger, enhanced editor support for Less, SCSS and Sass, Mercurial support, JavaScript debugging support, and more.

[suggestion] Interested in learning how to create your own programming language or just how parsers work? Check out Marc-André Cournoyer’s Create Your Own Programming Language now. Even Matz said it’s “the book I want to read”!

Infinity Test: Flexible Continuous Testing with Multiple Ruby Implementations

This post is by from Ruby Inside

Click here to view on the original site: Original Post

Infinity Test is a new library by Tomas D’Stefano that pitches itself as a “flexible alternative to Autotest.” If you want your project’s tests (both RSpec or Test::Unit are supported) to be automatically run when changes are made, this is a great place to start.

The big benefit of Infinity Test is the support for testing across multiple Ruby implementations, powered by RVM (a candidate for Ruby project of the year, if ever there were one). For example, if you have some Test::Unit tests that you want to be run on Ruby 1.8.7, JRuby, Ruby Enterprise Edition, and Ruby 1.9.2, you could run:

infinity_test --test-unit --rubies=1.8.7,jruby,ree,1.9.2

There’s also a configuration file system with its own DSL to build more complex automated testing systems with customized notification systems and callbacks.

[ad] Ruby Inside’s newest sponsor is Recurly, a recurring billing service. They promise “subscription billing in 3 easy steps” and you can start a free trial right now. Their API is Ruby friendly and on GitHub!

The 3 Step Guide to Slick Local Documentation for all your Ruby Gems

This post is by from Ruby Inside

Click here to view on the original site: Original Post

A couple of weeks ago, I wrote about RubyDoc.info, a “good looking, up-to-date Ruby documentation” site powered by YARD. Well, as of YARD 0.6 you can get the same greatness that RubyDoc.info provides applied to your local machine’s collection of gems in just a few steps. Try it out – you won’t regret it.

Step 1: Install YARD. Install the yard gem with sudo gem install yard or similar.

Step 2: Run the YARD server. Run yard server --gems. Take note of the hostname and port given in the output.

Step 3: Get browsing. Visit, where the IP address and port should be replaced with those provided by the YARD server. This URL should work for most of you though.

How does it look? Here’s the overall view of all installed gems:

And here’s a specific gem’s documentation:

There’s a lot more to YARD than merely serving up documentation – it’s primarily a tool for generating it from both RDoc and YARD-enhanced RDoc formats. Learn more at Loren Segal’s YARD 0.6.0 release post or from the GitHub project.

Pusher: WebSocket-powered Realtime Browser Push Service for Rubyists

This post is by from Ruby Inside

Click here to view on the original site: Original Post

Pusher is a new Web service from New Bamboo that makes it easy to push data to users of your web applications “live”, outside of the request response cycle. They’ve embraced Web Sockets technology and built a REST API to which you can post events. Its flexible channels are based on a publish/subscribe model and you can send events as JSON which communicate with all connected browsers.

Websockets are part of the specification for HTML5, and are essentially long-running native TCP connections in the browser. These allow a client to establish a connection to a server, and have immediate feedback when there are events they need to be notified of. Websockets make your applications more dynamic, and break them out of the traditional stateless request-response cycle. Your applications can therefore rely on maintained state in the browser which will be kept fresh with messages from your server.

Pusher makes adding Websockets to your application a quick and easy process. Pusher provides a simple Ruby gem) for interacting with its REST API, which includes authentication. There’s lots of documentation on the site, along with some more in-depth tutorials. Pusher also provides simple tools for debugging the socket connections to your application. Their event-based abstraction is handled in a Javascript library which also includes support for a flash fallback option.

Or.. try the DIY approach

The tools for creating a similar systems yourself are widely available, and it’s pretty easy. Ilya Grigorik recently put together a walkthrough of creating a simple Web Sockets server in Ruby using EventMachine. There are plenty of other open source solutions for message pushing generally like Juggernaut and Cramp.

In many cases running your own standalone socket server gives you a lot of flexibility for more bespoke deployments. However, maintaining these socket servers, debugging the various issues that come up, and keeping up with the specs is not something everyone wants to be doing. Given the popularity of utility-based hosting providers such as Heroku, Pusher is an interesting option for a de-coupled socket service you can use to keep your infrastructure lean.

Disclaimer: New Bamboo is a sponsor of Ruby Inside for their Panda service. I only noticed this had happened after working on this post (!) but a disclaimer is required nonetheless 😉

3 New Date and Time Libraries for Rubyists

This post is by from Ruby Inside

Click here to view on the original site: Original Post

In the UK there’s a cliché that goes: “You wait hours for a bus, and then three come along at once!” So it went with these three Ruby date and time libraries. They all made an appearance on RubyFlow last week and are all useful in their own ways, depending on how you’re working with dates and times.

ice_cube – Fast querying and expansion of event recurrence rules

ice_cube is a library by John Crepezzi that provides “fast querying and expansion of recurrence rules in Ruby.” What this means is that you can create schedules powered by date recurrence rules that can be quite complex (e.g. every 4 years on a Tuesday in the first week of November). Rules like these are defined by chaining methods together, rather than using natural language.

To install:

gem install ice_cube

To use:

require 'ice_cube'
rule = IceCube::Rule.yearly(4).month_of_year(:november).day(:tuesday).day_of_month(2, 3, 4, 5, 6, 7, 8)
schedule = IceCube::Schedule.new(Time.now)
schedule.add_recurrence_rule rule
# => [Tue Nov 02 05:04:38 +0000 2010, Tue Nov 04 05:04:38 +0000 2014, Tue Nov 06 05:04:38 +0000 2018]

ice_cube also supports exporting rules into iCal and YAML formats as well as a natural language equivalent.

John has put together a PDF presentation that shows off more usage, and there are some simple examples on the official site too.

tickle – A natural language parser for recurring events

tickle is a natural language parser for recurring events by Joshua Lippiner that stands in contrast to ice_cube’s method driven approach. It depends on the popular chronic natural language date parser and appears (through my experience) to be for Ruby 1.9+ only.

tickle lets you throw it things like every 4 days starting next saturday, every other week, the tenth of the month and similar (there are a lot of examples on tickle’s GitHub page). You pass these to the Tickle.parse method and you get the next occurrence of the rule.

To install:

gem install tickle

To use:

require 'tickle'
Tickle.parse('every 4 days starting next saturday')
# => 2010-05-01 12:00:00 +0000

tickle isn’t particularly mature yet and it only makes it easy to get the next occurrence of your rule, but the developer suggests that once an event has occurred, you automatically run Tickle again to get the next date. In this way, it seems tickle is well suited for situations where only the next occurrence needs to be stored and the rule can be kept in a separate database column or similar.

business_time – Time and date offsets based on “business time/hours”

business_time is a new library that works with the concept of “business time” or “business hours.” Rather than just letting you perform operations on dates by absolute numbers of days or hours, you can now work with business days and hours of your own definition. business_time depends heavily on Active Support.

To install:

gem install business_time

Note: business_time depends on Active Support (gem: activesupport)

To use:

require 'active_support'
require 'business_time'
# Examples "from now"
# Using user supplied dates
my_birthday = Date.parse("August 4th, 2010")
# Add a day to not count as a business day
BusinessTime::Config.holidays << my_birthday
# Overlapping days are OK
6.business_hours.after(Time.parse("August 3rd, 3:00pm"))

Visually Inspect Ruby Object Models with DrX

This post is by from Ruby Inside

Click here to view on the original site: Original Post

When you want to inspect your objects in Ruby, Object#inspect, p, or awesome_print are all valuable. You’re stuck with plain-text, though, and primarily designed to look at object data rather than object models. If you want to drill down into parent classes, see object and class relationships, etc, then, check out DrX, a visual object inspector for Ruby!

DrX bills itself as a “small object inspector”, but its key features are that it shows results visually (in a GUI interface) and that it focuses on showing the object model behind your objects, rather than the data contained within. A visual example of a DrX session should give you the idea:


Once DrX is installed (more on that in the next section), you just require 'drx' it into your app (or even within irb) and then use the Object#see method to get DrX into action:

require 'drx'

Even this rudimentary example will bring up an interesting graph. The DrX author does, however, provide a more interesting example to show off DrX’s introspective features:

s = "wizard of oz"
def s.strong
"<strong>" + self + "!</strong>"

Installation and Prerequisites

Depending on your setup, DrX might take some serious work to get going. If you’re running Linux and are heavy on your development experimentation, you might have everything ready to go. Just try gem install drx and see if the above examples work in irb.

Failing that, DrX uses Tk for its GUI work in order to be cross-platform and also requires GraphViz to be present. Install these with your package manager of choice and ensure that your Ruby installation has the Tk bindings installed (again, easier said than done).

On OS X 10.6 (Snow Leopard) I discovered that the stock Ruby installation does not include the Tk bindings, even though Tk is present otherwise. Rather than mess it up, I relied on the always-wonderful RVM and installed Ruby 1.9.2-preview1 (rvm install ruby-1.9.2-preview1). With this, Tk worked “out of the box” and gem install rbx was OK. For the Graphviz dependency, sudo port install graphviz did the trick and also “just worked.” If you’re one of the anti-Macports crowd, though, you might need to find a different approach.

Vagrant: EC2-Like Virtual Machine Building and Provisioning from Ruby

This post is by from Ruby Inside

Click here to view on the original site: Original Post

vagrant_chilling.pngVagrant is a Ruby-based tool for building and deploying virtualized development environments. It uses Oracle’s open-source VirtualBox virtualization system along with the Chef configuration management engine along with lots of Ruby goodness to automate the creation and provisioning of virtual machines for development purposes.

If you thought rolling out new VMs using Amazon EC2 was easy, Vagrant brings an even simpler system to your local development machine. From the command line, starting is as easy as:

sudo gem install vagrant
vagrant box add base http://files.vagrantup.com/base.box
mkdir vagrant
vagrant init
vagrant up

Be warned, though – as a 370MB download, adding that box image isn’t a quick process! Once you’ve got it though, you can keep rolling out VMs based on it at will.

Note that VirtualBox is a separate dependency for Vagrant. Vagrant does not come with VirtualBox built in or anything like that. Download VirtualBox for your OS if you want to try Vagrant.

Beyond the basics of getting a VM running, Vagrant can take care of port forwarding, distribution, environment setup, SSH access, shared folders and, importantly, the provisioning of software onto the VM using Chef. If you want to automatically roll out a VM with Apache 2, Rails, Phusion Passenger, or the like, Chef and Vagrant will take care of it for you. This is powerful stuff!

In terms of documentation and having a straight forward official homepage, Vagrant sets a solid benchmark. There’s a straightforward guide to getting started with Vagrant, lots of documentation, and a 12 minute getting started video/screencast. Great work guys!

New Relic RPM Officially Supports Rack and Sinatra – Finally!

This post is by from Ruby Inside

Click here to view on the original site: Original Post

NewRelic_inline.pngNew Relic’s RPM, an application performance monitoring and reporting system, has today announced it has added full support for Sinatra and Rack-based Ruby applications to its traditionally Rails-centric service. It’s been possible to hack in support for non-Rails apps into New Relic before, but this move brings them officially into the fold with all of the features only Rails apps used to be able to take advantage of.

New Relic’s press release on the news includes a typically “press release sounding” quote from Ryan Tomayko, but as a key contributor to Sinatra and Rails, and as a GitHub employee, it seems worth quoting:

Rack has given Ruby web developers a tremendous amount of freedom to innovate and experiment with new ways of building web applications.

Developers are increasingly turning to Rack and lightweight frameworks like Sinatra for small utility apps or for latching performance critical features onto an existing site. The ability to monitor and profile these applications using New Relic RPM fills a huge visibility gap for us.

So there you go. New Relic have also updated the “agent” that’s used to communicate between your apps and their servers and added some Ruby specific features including enhanced visibility in garbage collection, developer mode profiling, “enhanced” JRuby support, and Phusion Passenger queue time capturing (this sounds particularly useful for tweaking your stack).

As always, New Relic RPM is free to use at a “Lite” level and if you’re a new user, they’ll give you a week of “Gold” level features for free to sweeten the deal. You can keep running at Lite after that though if you don’t want to pay. The “Bronze” plan starts at $50 per month (on an annual basis) per host but they also have an “on demand” Amazon EC2 style pricing structure starting from 10 cents per hour.

We’ve been keeping an eye on New Relic since early 2008 and they seem to have gone from strength to strength over the years. Early on, FiveRuns‘ RM-Manage was still a better option than RPM (in my opinion) but with FiveRuns going the way of the dodo recently, New Relic have become the main game in town when it comes to Ruby webapp performance monitoring (though Scout are giving them a run for their money in certain areas).

Harmony: JavaScript And A DOM Environment In Ruby

This post is by from Ruby Inside

Click here to view on the original site: Original Post

harmony.pngHarmony, from Martin Aumont, is a new Ruby DSL for executing JavaScript and DOM-using code from within Ruby apps. Why’s that cool? Well, it enables you to build your own Ruby-level unit tests for JavaScript code within your Web applications – everything can be under one set of test suites!

Harmony sounds like a significant piece of engineering, but really it’s a wrapper that stands on the shoulder of giants in the form of Johnson, which provides the Mozilla Spidermonkey Javascript runtime to Ruby, and env.js, a DOM environment recreated in JavaScript.

Harmony’s “Hello World” example:


HolyGrail: The Rails Plugin

If you’re using Rails, HolyGrail is a plugin that brings the power of Harmony to your apps (so far in functional tests only). Some example tests with HolyGrail:


Note: This Harmony is not to be confused with the awesome Harmony CMS that esteemed Rubyist John Nunemaker is working on..

Hammertime: Ruby Interactive Error Console

This post is by from Ruby Inside

Click here to view on the original site: Original Post

stophammertime.png Hammertime (GitHub repo) is a new interactive error console for Ruby by Avdi Grimm, modelled after those found in the Squeak/Smalltalk and LISP environments. It fills some of the same roles as ruby-debug, except in a less intrusive and more Ruby-esque fashion. Be warned though.. currently it’s for Ruby 1.8.x only.

Installation is via RubyGems (gem install hammertime) and the library is activated in your app with require 'hammertime'. That’s it; you’re good to go. Once activated, any exception raised in your app will result in a Hammertime prompt appearing where you can choose from a number of options, including:

  • Continue (process the exception normally)
  • Ignore (proceed without raising an exception)
  • Permit by type (don’t ask about future errors of this type)
  • Permit by line (don’t ask about future errors raised from this point)
  • Backtrace (show the call stack leading up to the error)
  • Debug (start a debugger)
  • Console (start an IRB session)

For more info, a walkthrough of a basic debugging process using Hammertime is shown in Avdi’s Hammertime blog post. I get a feeling that if this is refined with the extra features Avdi’s planning (such as making retries easier from the console and, perhaps, support for exceptions raised in native code) and Ruby 1.9 support is added, Hammertime could become a standard debugging tool in any good Rubyist’s toolbox.

[job] Snapizzi is currently looking for a Ruby and Rails developer to join their team. Alternatively, check out one of the other 11 jobs on our Ruby jobs board!

Rackamole: Rack-Based Monitoring For Your Ruby Web Apps

This post is by from Ruby Inside

Click here to view on the original site: Original Post

rackamole.pngRackamole (GitHub repo) is a Rack application that lets you to monitor the interactions between users and your own Rack-based application (e.g. any Rails or Sinatra app). As well as pumping out information to the console or a log file, there’s a Web interface called Wackamole to give you the skinny on your app activity.

Rackamole’s creator, Fernand Galiana (also of ZiYa charting library fame), says that Rackamole is well suited for determining what parts of your application you need to work on next. It traps and records feature usage, performance issues, and application exceptions, and by integrating as a middle layer between your HTTP server and your Web app, it can work with almost any backend system out of the box.


Above: Wackamole and Rackamole in action

As well as logging data and presenting it through Wackamole, Rackamole also has a built-in e-mail notifier so you can be alerted when certain actions occur that need your attention. In this way, it’s sort of like a New Relic-lite or like FiveRuns’ now defunct Dash system. MongoDB fans might also appreciate that Rackamole also has support for logging to a MongoDB database out of the box.

Amp: A Revolution in Source Version Control (in Ruby!)

This post is by from Ruby Inside

Click here to view on the original site: Original Post

amp.png Amp is a new Ruby based project that aims to “change the way we approach VCS” (version control systems). Currently it’s basically a port of the Mercurial version control system – a common alternative to the Git system that’s more popular in Rubyland – but it aims to abstract things to the point where it could be used in place of Git, Bazaar, SVN, CVS, Darcs, and so forth.

The creators of Amp believe that while there are lots of great repository formats out there, none of the official clients are “truly good software” and so they’re aiming to build something that abstracts away all of the pain into a heavily customizable Ruby library and client. Even now you can add your own commands to Amp or adjust those that already exist, meaning you can totally customize a powerful source control tool to your own taste.

One of the points that’s constantly stressed on Amp’s rather well designed official site is that the project is actively looking for new contributors and help. They have a repo on GitHub if you want to fork and issue pull requests, as well as an IRC channel on Freenode, #amp.

caliper-logo.png[ad] Find duplication, code smells, complex code and more in your Ruby code with Caliper! The metrics are free and setup takes just one click. Get started!

Racksh: A Rails-Console-A-Like for Rack-Based Ruby Apps

This post is by from Ruby Inside

Click here to view on the original site: Original Post

Have you ever yearned for something like Rails’s script/console or Merb’s merb -i in your other Rack based apps? If so, then Marcin Kulik‘s racksh, inspired by Heroku’s console, might be for you.

Racksh is a console for Rack based ruby web applications. It allows you run a console in the context of an application environment for Rails, Merb, Sinatra, Camping, Ramaze (or even your own framework) provided there is a rackup file in the root directory.

When you run the racksh command, it loads the whole application environment just like a Rack web server, but instead of running the app it starts an irb session where you can invoke commands.

$ racksh
Rack::Shell v0.9.4 started in development environment.
> Article.all
=> # returns all articles...

As of version 0.9.4 (released this week), racksh uses Bryan Helmkamp’s rack-test to simulate HTTP requests to your Rack application via the $rack variable.

$ racksh
Rack::Shell v0.9.4 started in development environment.
> $rack.get "/"
=> # returns a Rack::MockResponse

Racksh also allows you to apply configuration through a .rackshrc file. This can be used to set headers which will be used for requests, or to make additional setup requests (e.g. to make sure a user is logged in).

Install as a gem from Gemcutter, or get the source from Github.

gem install racksh -s http://gemcutter.org

For more details, check out the project’s README, and these recent posts on Marcin’s blog.

MagLev Alpha Released: A New, Scalable Ruby Implementation

This post is by from Ruby Inside

Click here to view on the original site: Original Post

maglev.pngMagLev is a new(ish) Ruby implementation built by Gemstone Systems that focuses on providing an integrated object persistence layer and a distributed shared cache – a truly scalable Ruby implementation. Maglev has, however, had an air of vaporware about it, having been hyped up in early 2008 and only available to a small group of alpha testers till now. That changes today with the first public, alpha release!

Back in early 2008, MagLev program manager Bob Walker did an interview with InfoQ about the project where he said that 8 people were working on MagLev, so this is a pretty big deal for them. Developer Avi Bryant then did a short presentation at RailsConf 2008 where he gave a comprehensive overview of what MagLev is along with some live demonstrations.

Why Should You Care?

In short, MagLev is cool for a few reasons. Two key ones being that 1) MagLev runs on the SmallTalk virtual machine which, it is claimed, should yield significant performance increases for a language like Ruby, and 2) a MagLev environment allows multiple Ruby processes over multiple machines (if you wish) to use the same objects simultaneously for easy scalability. Avi’s video is great if you want to get a grasp on it:

MagLev presentation at RailsConf 2008 from Monty Williams on Vimeo.

Developer Monty Williams is keen to stress that this is an alpha, not a beta, so you can’t expect it to run Rails or any gems that require C extensions. That said, it does run Sinatra, Rack, and RubyGems, plus a significant effort has been put into passing the RubySpec, so it’s not as if it’s a crippled implementation as such.

If you want to learn more, consider following the MagLev team on Twitter @MagLev and checking out the official mailing list “maglev-discussion.”


The suggested installer didn’t work out for me, but MagLev is available from GitHub to clone and install. Bear in mind that MagLev will only work on 64 bit versions of OS X, Linux, and Solaris, so if you’re in the 32 bit club, there’s no point in going any further (yet).

Another limitation is that it seems it demands an already installed Ruby 1.8.6 p287 (and specifically that version!) for you to do anything fun. Luckily, if you have Ruby Version Manager (a.k.a. RVM) installed, in theory you can have that up and running within a couple of minutes with rvm install ruby-1.8.6-p287 (unless you’re on Snow Leopard it seems, lol.. it’s a total error-a-thon here on mine for now – may update if I get a solution).

To install MagLev from GitHub:

git clone git://github.com/MagLev/maglev.git
cd maglev

.. then follow the note about adding the path to your .bashrc or .bash_profile and running Rake in a new prompt (though still under the maglev project directory).

If you get any further with doing something interesting like, say, getting an IRB prompt up successfully on this, do post a comment 😉

caliper-logo.png[ad] Find duplication, code smells, complex code and more in your Ruby code with Caliper! The metrics are free and setup takes just one click. Get started!