Ruby in 2012

Matt Aimonetti

Ruby is more popular than ever, but it’s also not as trendy as it used to be. students1 asked a few questions to about his vision of Ruby in 2012 and for the future.

is a well-known Rubyist, technical writer, speaker and active open-source contributor. He currently works as a software architect for LivingSocial. Prior to joining LivingSocial, Matt worked for Sony PlayStation.

How does Ruby fit in with the future, as you see it?

: This is a really hard question. If I could predict the future, I would probably already be rich. Ruby is a very powerful and flexible language.

Very much like Python, Ruby is a great glue language, a great language for the web and overall a language that allows you to get a lot done before you hit the language limitations.

The ecosystem also keeps growing and there seems to be more and more people focusing on performance and documentation which are two things Ruby could still improve a lot on.

I think it’s quite obvious that the pendulum is swinging back and server side code is going to be more and more API oriented with smart clients consuming these services. Ruby is great for that because services need to be easy to write, easily to maintain, well documented and flexible. I wrote a DSL to do just that using Ruby and it would have been harder in any other language.

So, to answer the question more directly, I think that Ruby will keep on playing a major role in web development but at the same time, developers will become more and more polyglot and might switch back and forth between languages.

I have talked to people that think that Ruby is falling by the wayside, even to the point where they say that Rails is killing Ruby. What do you think?

Matt Aimonetti: I wouldn’t say that Ruby is falling by the wayside, what’s going on is that Ruby outgrew the startup world where it became very popular a few years ago. However, you now find Ruby (and Rails to that matter) in a lot of more established places thanks to its efficiency of development, strong focus on testing, active community and great ecosystem.

When some people say that Rails is hurting Ruby, I think what they mean is that for them Ruby’s fate is directly related to Rails’. If Rails doesn’t manage to stay the web framework of reference, it might hurt the language. This is certainly not entirely wrong. Without Rails, Ruby wouldn’t have been as popular, but at the same time, there is much more to Ruby than Rails and I think that as a community we need to seriously start looking at all the great things we can do with Ruby outside Rails.

What is your opinion on Node.js? Is this the future? Do you think Node.js will beat Ruby in web application development?

: This is a question I often get. I personally like node.js, I think it’s fun, easy to get started and with CoffeeScript, writing JavaScript (JS) is almost fun. That said, Node is really young, not very well documented and relies extremely heavily on callbacks which can be quite confusing at times. My experience with Node is limited, but as my personal project started growing, I started struggling to keep my code simple and easy to maintain. Because I already know Ruby quite well and because equivalent tools exist in Ruby land, I don’t see a real need to use Node besides being the new cool framework.

But the project is fast growing, the cross-platform focus is welcomed and I think that for some developers, Node.js can be a great solution, especially when developing simple web APIs.

Will it “beat” Ruby? Well, a framework and a programming language are two different things. Will it beat Rails in popularity, that’s a possibility due to the fact that JavaScript is becoming very popular. However, some of the issues I mentioned earlier might prevent Node.js to become as popular as some people seem to believe. Finally, at the end of the day, if a JS framework becomes a better solution than anything else I use, I will certainly switch. But so far, I don’t see that happening.

Do you think Ruby is the best programming language to be introduced to newbies to get them started in programming?

Matt Aimonetti: I do believe Ruby is a great language to learn some of the basis of programming, especially Object Oriented Programming. It allows students to get easily started and to build things quickly. However, different people learn differently and are attracted to other things and parts of Ruby can be quite hairy. To properly learn a language, you also need to have a way to practice and quickly see the fruit of your labor. That’s why If you are a designer, I might suggest you start with JavaScript and then move on to a better designed, high level programming language like Ruby or Python. Finally, you need to look at your motivation being learning a new language.

If you want to learn programming because you want to work in this field, consider starting learning a language which will allow you to easily start working (hint: there are a lot of Rails positions out there waiting for you). But don’t stop there, keep learning new languages and way to solve problems using code.

How to become a better coder? I still feel it’s hard to get involved contributing to OSS, could you give us some advice?

Matt Aimonetti: I personally get better when I practice a lot and when overcoming problems I didn’t know how to solve before I started. Open Source contribution is a great way to get feedback and learn from others. I think that with tools such as Git and GitHub, OSS contribution has become much easier than ever. That said, a lot of developers think that their contributions have to be significant, and, that’s in my mind, a mistake. Start by contributing documentation, examples and helping others. File bug reports and try to reduce them to an easier to handle case. That might seem trivial to you, but it’s extremely useful, it will teach you a lot about the project you are involved with, its design, the pros/cons and how an OSS project is run. Doing that will help you debug and diagnose problems faster and when added to the design knowledge and communication skills you would have acquired, you have all the ingredients of a good developer. Another thing I like to do is to pick something that seems absolutely impossible for me to do. If you only know Ruby, memory management and writing code C might seem hard. Give yourself a reasonable time frame and a challenge such as 6 months to have a small C program that will do X, Y and Z. Keep it small and simple and don’t forget to have fun. At first it will be hard, but don’t give up, keep trying until you learned something you thought was impossible. When you will go back to writing Ruby or whatever language you write, you will look at things from a different angle.

Finally, the last thing I would suggest is to never feel too comfortable in your daily programming tasks. If you are to the point where you just execute and aren’t challenged, you might want to consider talking to your supervisor about giving you more challenging tasks.

Are you excited about MobiRuby? Do you think it will become a viable platform for iOS development?

Matt Aimonetti: MobiRuby is being developed on top of mruby, the new Ruby implementation written by Matz that’s targeting embedded device and offering an alternate for Lua and to some extent JavaScript. I’m quite excited about mruby and its potential and I wrote about both mruby and MobiRuby a couple days ago. Basically, from my view point MobiRuby is an interesting project but it will have to overcome some serious challenges described in details in my blog post. My hope is that thanks to the Ruby language, MobiRuby will be able to transcend Cocoa/Android API to offer an easier, simpler API making mobile development more fun and more easily accessible.

This is quite a big challenge, but I do believe this is something that can be done and that might change the way mobile development is done.

I hope you found this article useful. What are your thoughts? Feel free to ask questions and do give your opinion in the comments section of this post. Matt would only be too happy to reply. Thanks!

Technorati Tags: , ,

  1. Thanks to Michael Kohl, Samnang Chhun and Victor Goff.

(Powered by LaunchBit)

The Ruby movement

The Ruby movement

This guest post is contributed by Matt Aimonetti, a Senior Engineer at Sony Playstation in San Diego, CA. Matt has been active in the Ruby community for many years, he developed or contributed to a lot OSS libraries and frameworks, spoke at users groups and conferences in the U.S. and abroad. Working with startups, fortune 100 companies and traditional companies, he had the opportunity to be involved with really captivating Ruby, MacRuby, noSQL/lessSQL, Rails and Merb projects. Matt is currently writing a MacRuby book for O’Reilly, available for free online.

Matt Aimonetti An art movement is a tendency or style in art with a specific common philosophy or goal, followed by a group of artists during a restricted period of time, or, at least, with the hay-day of the movement defined within usually a number of years.1

The programming world is much closer to the art world than you might think. Painters, sculptors, architects, singers, writers, cinematographers and photographers are recognized as artists, while programmers/coders/hackers are not there yet. One could argue that programming is more of a craft than an art, but instead of getting into semantics, letís look at “programming movements” the same way we look at “art movements”.

Art is about expressing and generating feelings. Various styles and techniques can be used and when artists work on a piece, they do not target the entire world but often limit their focus. Authors often try to express something personal and communicate their own world view to their audience. Keeping that in mind, letís see how this applies to the Ruby language and its creator: Matt Aimonetti, Matsumoto Yukihiro aka Matz.

Matsumoto Yukihiro
Matsumoto Yukihiro

Any good designer/artist starts by learning from exemplars. In the dead cold of a late German autumn in 1705, an impoverished young musician named J.S. Bach took a 6 month, unpaid leave from his job and walked 250 miles to study the work and ideas of maestro: Dietrich Buxtehude. Now fast forward to 2010 and take a look at well known Japanese artist Takashi Murakami’s creations.

Superflat creation for Louis Vuitton - Takashi Murakami, 2003
Superflat creation for Louis Vuitton – Takashi Murakami, 2003

You can see how masters like Henri Matisse and Andy Warhol have helped him create his own style.

La gerbe' Henri Matisse, 1953
La gerbe’ Henri Matisse, 1953

Murakami’s Superflat creation for Louis Vuitton, clearly follows Warhol’s pop-art steps with a strong influence from previous artists like Matisse, Tezuka and others. Watch one of the video clips Murakami produced for LV.

The same thing goes for programming languages. When designing his programming language: Ruby, Matz was strongly influenced by Perl, Smalltalk, Python, Eiffel, Dylan, Lisp and many more languages. But at the same time he created his own programming language with its own design values, own desiderata/objectives and own priorities.

Programming is not a religion. And neither are art movements. When you reflect on art movements, you might like impressionism better than expressionism but you know they are both art movements. When you study their contexts a bit more, you understand the motivations behind each movement better. Don’t believe even for a second that Ruby is a perfect language nor that it will be the last programming language you will need to learn. Programming languages, very much like art movements, are not set in stone, they evolve and spawn new movements. But regardless of what happens, if they grow to be important enough, programming movements influence new languages and keep on living through them.

Alright, enough armchair philosophy. Let’s look at the Ruby movement values and the problems its designer was trying to address.

In his OSCON 2003 presentation, Matz explained what his motivations in creating Ruby were. He started by stating that languages influence human thoughts much more than we think. And that the good programming languages should help developers:

  • program better.
  • think smarter.
  • finish your job faster.

He defined a few principles that he felt needed to be put in place to help program better/reduce stress in programming:

  • Principle of least surprise (the developer should not be surprised by the way an API works).
  • Principle of succinctness (shorter code is easier to write, read and maintain).
  • Principle of human interface (the language should be written for the developer, not the machine).

This, in a way, is the Ruby manifesto. It is not uncommon for art movements to define their rules, perspective and even publish manifestos. The futurists, surrealists and dadaists for instance had their own manifestos while others like the cubists let art critics explain their movements. In his presentation, Matz clearly defined the core values that he refers to when he is thinking about making a change somewhere. Each language has its own set of values and they are sometimes in opposition from one language to the other. It’s up to you, the developer, to see how these values fit your project and your team. Unfortunately, there is not (yet) a perfect language that everyone you can use for everything.

If you are reading this article, you are probably already part of the Ruby movement or you are looking into it. The two first things you should probably remember are:

  • to learn and understand Ruby’s values.
  • to be curious about what other “movements” value and how they approach challenges.

f you do that, you will first understand the pros and cons of the language, and you will understand why some aspects of the language can seem odd to you. (For more info, read the post I wrote about the discussion I had with an ex-Java developer).

Look at other engineering movements, not only programming languages:

Look at how architects design buildings, how musicians compose music, how NASA designs rockets. By understanding the main design goal, the list of objectives and the scope of each approach, you will be able to understand, value and criticize each movement.

Don’t limit yourself to using idioms and pushing keys on your keyboard without understanding the “why” behind the “how”. Ruby wants you to become a better programmer, that is part of the language’s objectives. Better Ruby developers mean a stronger influence on the Ruby movement and improvement brought by the community synergy. If you find something that is not right with Ruby or its community (I have my own list), you should try to understand why it is like that and ask yourself what you can do to help. Don’t think for a second that you are not smart or expert enough. Be passionate and get involved to improve yourself and the movement as a whole. Take for example artists learning from outside their paradigms. Picasso and Matisse were friendly rivals, they shared the same interest in primitivism and African art and influenced each other while being part of different movements. Directors like Quentin Tarantino, Martin Scorsese, John Woo, Steven Soderbergh, Brian De Palma, Wim Wenders, Oliver Stone all have different styles but all admit to have been directly influenced by Jean-Luc Godard and the Nouvelle Vague movement. Most modern music movements love to borrow from each other to create interesting new trends.

So when you work on your code, when you are looking at other programming language, think about art and remember that a movement always benefits from borrowing ideas from other movements. Don’t forget that one’s own little programming world is transient, metamorphic and therefore should remain fun, challenging and welcoming. Educate yourself, stay open minded and help take the Ruby movement to the next level.

Recommended reading (not Ruby specific):

The Design of Design The Design of Design

Hackers & Painters Hackers & Painters

The Pragmatic Programmer The Pragmatic Programmer: From Journeyman to Master

The Passionate Programmer The Passionate Programmer

So – what do you think? If you have ideas, sites, resources, etc. that I haven’t mentioned, please post them as comments here.

Post supported by Sticker Mule: Sticker Mule prints custom stickers starting at $69 for 100. They aspire to be every Ruby developer’s favorite sticker printing service. A $25 off coupon (RL01) is available for Ruby Learning readers through October 31st, 2010. Enter code RL01 during checkout.

Technorati Tags: , ,

Rails and the Enterprise

If you have been in the Rails community for a little while, you have more than likely noticed the love/hate relationship that is entertained by the community vis-à-vis the Enterprise.
Some people hate the enterprise and publicly tell it to go f*ck itself (49:39), on the other hand, these same people are also proud to mention that some major players in the industry use Ruby and Rails.

The truth is that even though Ruby and Rails could still be more Enterprise ready, it is already a great combo that big corporations can start using today, and lots of then already do! Let’s look at the state of Rails and the Enterprise.

So where are we at?

  • First things first, Rails was not designed for the enterprise or for the enterprise’s needs. It was extracted from a successful startup project and has grown with the contribution of people using Rails daily. But Rails is also based on Ruby which became very popular and started to be used in different places, including NASA, for instance.
  • 37signals still does NOT need “Enterprise features” and therefore don’t expect any 37signals engineers to write an Oracle Adapter or a SOAP layer for ActiveResource and push for their adoption.
  • Rails is far more than a framework used by 37signals. It is an Open Source project with code being contributed daily by people on other projects. Most of the code does not directly benefit 37signals.
  • The Enterprise is evolving: economic crisis, a new generation of developers, new management, insane deadlines. Ruby and Rails have quickly become very attractive for the Enterprise and having big companies acting as startups is often something a lot of managers dream of. As a matter of fact, here is a quote from Sony Computer Entertainment America’s President & CEO, Jack Tretton: “Be like a multi-billion dollar company on the outside, and act like a startup on the inside”. This change has taken a while because the Enterprise is a big mammoth (or insert another of your favorite gigantic, slow-starting animal here), but it’s happening.
  • Communication with/in big companies is not as straight forward as when dealing with startups who need/thrive for the outside attention and who don’t have all the red tape of a PR department, etc. Here is a simple example: I work for Sony Playstation. My job description mentioned Redis, MongoDB, EventMachine and many other technologies I did not know Sony was using in production. I did not realize that my default production stack would be built on Ruby 1.9. Communicating when you’re a part of a big company is more challenging than when you are a team of 5 engineers working on a cool project, and therefore a lot of people don’t know what technologies are being used by Company X or Company Y.
  • Rails is used by lots of big companies. It might not be obvious and you might have to look at the job offers but people like AT&T, Sony and many others are always looking for talented Ruby developers. And, even though Java and .NET are still ruling the Enterprise kingdom, dynamic languages are slowly but surely catching up. Rubyists are climbing the social ladder and are now in positions to push the language they love.

Understanding the Enterprise’s needs

It’s kind of hard to define “the Enterprise’s needs”, however I can testify that the needs and requirements of a so called “Enterprise app” are slightly different than those encountered when you work on a startup app.

What the Enterprise needs/wants:

  • reliability
  • support
  • performance
  • advantage over the competition
  • integration and transition path


I think that it was proven many many times that Rails scales and can be very reliable as long as you know what you are doing. We are not talking anymore about a buzz framework that just got realized and that cool kids play with but rather, a stable platform used by some of the most popular web applications out there.


This point is something the Rails community can be proud of. We have lots of forums, blogs, books, local meetings, conferences… Yes, Rails is OpenSource and you can’t buy yearly support from the core team but you will find all the help you need out there. (If you can’t, feel free to contact me and I’ll direct you to people who can help, and if you are new to Rails, take a look at


Based on my own experience, the level of performance we have using Ruby and Rails is more than enough for the Enterprise world. This is especially true with Ruby 1.9 greatly improving performance and Rails3 optimizations.
If you really need part of your code to run as fast as C code, writing a C extension for Ruby is actually quite easy and will solve your speed issues.

Advantage over the competition

Rails comes with certain ways to do things, conventions that will get you up and running in much less time.
Ruby as a language is natural, intuitive and easy to maintain. By choosing the right tools for your project, you will definitely be able to get more done in less time and increase your business value faster. Let’s not forget the strong value of testing in the community that will push your team to write tested code and more than likely improve the overall code quality of your products.

Integration and transition path

This is probably the part that is the most challenging when you live in the Enterprise and look into using Ruby & Rails.
I was recently talking to someone from Google who used to do a lot of Ruby before joining the Mountain View-based company. We were talking about how he loves Ruby but had such a hard time integrating with existing Enterprise solutions. He mentioned how he got frustrated by the lack of great XML tools, bad/complicated SOAP libraries and a few others I can’t remember. The truth is that when my friend was using Ruby this all was true. REXML and soap4r are useful but might not perform that well. Luckily as the community has grown, new tools have come up and today Nokogiri (developed and maintained by AT&T engineer’s Aaron Patterson) can easily be used instead of REXML and many libraries are known to be better than soap4r such as savon, handsoap and others.
The other good news is that major IT companies such as Apple, Microsoft and Sun(RIP) have adopted Ruby and you can now write your code in Ruby and use native libraries from other languages such as Java, .NET or Objective-C.
The transition path can be done smoothly without having to commit to a total rewrite.

Database-wise, Oracle is still a viable option for Rails developers thanks to the Oracle ActiveRecord adapter (by R.Simanovskis). Note that your DBA might curse you for not doing optimized queries using bind variables and all the Oracle Magic spells, in which case you can use Sequel, a great ORM supporting Oracle, and some of its unique features.

Deployment-wise, you can deploy on IIS, Tomcat, Glassfish, Apache, Nginx, or almost anything mainstream you are already using. Using Passenger, deployment is as easy as deploying a PHP app and you also get a series of great tools such as Capistrano, Vlad etc…

So basically, thanks to passionate Rubyists working ‘for the man’ such as Aaron Patterson, Raimonds Simanovskis and others, using Ruby in the Enterprise is much much easier. Ruby and Rails were not initially designed with the Enterprise in mind but with time, the integration has become smoother and both parties can now enjoy reciprocal benefits.

Upgrading to Snow Leopard

Last Friday, Apple released their new OS version: Snow Leopard.
Upgrading to SL is very easy and even gives you back quite a lot of HD space.
However a few things have changed in the OS and you need to understand what is going on so you won’t get frustrated with the updating process and won’t be wasting time fighting with the system.

Snow Leopard

The key change for us Ruby developers, is the fact that, in Snow Leopard, all the interpreted languages (including Ruby) are now running in 64-bit by default (obviously, only if you have a 64-bit machine).
For pure Ruby applications and libraries this shouldn’t pose any problems. But if you are migrating from a Leopard environment where you compiled C extensions for 32-bit only, these gems won’t properly load in Snow Leopard.
Same thing goes for libraries you might have compiled in 32-bit mode and that you might want to use on your migrated system.

Something else you need to know: Snow Leopard now comes bundled with Ruby 1.8.7 instead of 1.8.6.
This should not be a problem since Rails has been running on Ruby 1.8.7 for a long time and Rails 3 will require Ruby 1.8.7 and prefer Ruby 1.9.2.

Here is a quick rundown of common tasks you might have to do to migrate properly.

Install Snow Leopard developer tools

On the Snow Leopard DVD, under “Optional Installs”, install “Xcode.mpkg”. Use all default options.


$ sudo gem install -r passenger
$ sudo passenger-install-apache2-module

Press Enter when prompted. Passenger will compile and install its Apache module.
Press Enter when prompted the second time too.

$ cd /etc/apache2

Open httpd.conf in your text editor (if you use TextMate, try running mate httpd.conf from the command line) and look for a line like “LoadModule passenger_module” and some lines following that have “passenger” in them too. Delete them. If you don’t see them them, move your cursor to the end of the file.

Then insert these lines:

LoadModule passenger_module /Library/Ruby/Gems/1.8/gems/passenger-2.2.4/ext/apache2/
PassengerRoot /Library/Ruby/Gems/1.8/gems/passenger-2.2.4
PassengerRuby /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby


To avoid weird issues with MySQL, it’s strongly recommended to upgrade to the 64-bit version.
Start by shutting down mysqld if it’s running. (Depending on how you installed MySQL, you might be able to use the preference panel, or use
sudo /opt/local/share/mysql5/mysql/mysql.server stop
if you installed it using MacPorts)

Now install the Mac OS X 10.5 (x86_64) version of mysql from here

When the disk image opens, first install “mysql-5.1.37-osx10.5-x86_64.pkg”. Use all default options.

Next install “MySQLStartupItem.pkg”. Use all default options.

Next install “MySQL.prefPane”. Double-click to install it. Choose to replace the existing preference pane when prompted. (Apparently the preference pane is still 32-bit.) At this point you can click “Start MySQL Server” to start the server and verify it works.

Unmount the MySQL disk image.

Since you are upgrading from Leopard, your mysql gem is compiled for 32-bit only and therefore needs to be recompiled.
However, it’s not that simple, the mysql gem is a bit of an exception. Under Snow Leopard when you do a gem install for a C extension it tries to build the extension for two architectures: i386 (32-bit) as well as x86_64 (64-bit).
The problem is that the binary from is not universal and therefore we need to force the C extension to be only compiled in 64-bit.

$ sudo env ARCHFLAGS="-arch x86_64" gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config

note: You shouldn’t have to set the ARCHFLAGS to compile any other gems.


You should be all set. However, if you are relying on any libraries you compiled on Leopard, you probably will have to recompile them.
MacPorts users shouldn’t think that it will be automatically done for them.

You have different options to upgrade your ports.

The easiest way is to upgrade MacPorts:

$ sudo port selfupdate
$ sudo port sync
$ sudo port upgrade --force installed

Other native gems

Check this script to get a precise list of gems requiring to be reinstalled and some help with the upgrade process. Basically, you just need to reinstall the few gems using C extensions.

Community Highlights: IronRuby

<style type=”text/css” media=”screen,projection”>{padding-bottom: 1em; color: #555; font-size: italic} span.matt-aimonetti{color:#336699; background-color:#F4DDA6;}{padding: 1em 1em 3em 1em;} span.Jimmy{background-color:#F4DDA6; color:#336699; font-size: italic}


As Rubyists migrate from Ruby 1.8 to Ruby 1.9, new Ruby
implementations are gaining in maturity.
Recently, IBM’s Antonio Cangiano wrote an interesting article comparing the performance between Ruby 1.8, 1.9 and IronRuby on Windows which surprised quite a lot of people.

Unfortunately, IronRuby isn’t very well known in the Rails community yet.

Here is an interview with Jimmy Schementi, lead developer for IronRuby, to help give you a little insight.

iron ruby logo

Matt: Hi Jimmy, thank you very much for taking the time to answer our questions. Could you please introduce yourself?

Thanks for sending me questions; it’s great to see the ever-increasing interest in IronRuby!
I live in Seattle and work at Microsoft on a small team making an open-source implementation of Ruby called “IronRuby”. I personally split my efforts between making the IronRuby codebase better, integrating IronRuby with .NET-related technologies like Silverlight or ASP.NET MVC, getting our monthly binary releases are in order, discussing IronRuby with the community, and making sure Microsoft’s management knows how awesome Ruby is.
But I’m definitely not alone on the core team. John Lam fueled the interest of a .NET-Ruby implementation with the RubyCLR project, and started the IronRuby project. Tomas Matousek is the brains behind the IronRuby compiler, and gets credit for all the compiler code and the recent performance gains. Jim Deville is the man keeping IronRuby working with tons of tests and a fantastic test infrastructure. Shri Borde is our manager, and he spends his non-managing time fixing the libraries and hosting the infamous “IronRuby pair-programming” sessions. And of course all the IronRuby contributors over the past two years have been an enormous help.
Matt: As a follow up on a recent blog post, could you tell us know how you learned Ruby and maybe give some advice or an important point not to miss for people wanting to learn Ruby?

I heard about Ruby from my Computer Science professor/advisor Gary Pollice, who taught all the programming language classes at Worcester Polytechnic Institute. I was searching for an expressive programming language for making games, and Ruby was a perfect fit. A couple years later I worked for the same university building a computer-tutoring system called Assistment, where myself and a couple of other people fed up with the Java codebase ported it to Ruby on Rails. It was a success, and is now a Rails system. That’s where I really learned everything about Ruby and became extremely interested in how Ruby worked.
I learned the most from Ruby when I had a substantial Ruby project to work on, since I got to see its expressiveness making me more productive on a large scale. I’d still suggest trying to learn Ruby on small things here and there, but you’ll really be amazed if you use it for something larger.

Matt: IronRuby certainly looks very interesting, can you run Rails on it?

Yes, at RailsConf 2009 I showed IronRuby running non-trivial Rails applications. IronRuby can run Rails on WEBrick, as well as on the web-server that comes with Windows, IIS. For the database you can use SQLServer Express (which is free), or any .NET based database, like the recent csharp-sqlite port. Here’s a detailed post the IronRuby on Rails talk at RailsConf 2009:

Matt: Are there any limitations that our readers should be aware of before starting to develop on IronRuby?

The main limitation is that IronRuby does not support any of the C-based Ruby libraries, and only after 1.0 will we consider building an interop layer between the Ruby C API and IronRuby. In the meantime, people have been porting their favorite C-based Ruby libraries over to C# so it can be used from IronRuby, like Hpricot.
While this seems like a large limitation, most of the C-based libraries Ruby code depends on have an equivalent API in the .NET framework, which IronRuby has direct integration with, making either using directly or porting really easy. For example, the Rails app I showed at RailsConf did image resizing directly with the System.Windows.Drawing APIs rather than ImageMagick.
If your code does not depend on anything outside of the Ruby standard library that is C-based, you should have no problems. Take a look at the documentation for running Rails on IronRuby to make sure things go smoothly:

Matt: What are the pros/cons of using IronRuby versus the standard Ruby (Ruby1.8 or Ruby1.9) on Windows?

IronRuby is a very fast Ruby interpreter/compiler due to our own tricks we pull to make Ruby fast, the tricks the DLR does to make dynamic languages fast, and the CLR’s just-in-time compiler which generates very efficient code. We’re definitely aiming to be the fastest Ruby implementation on Windows. The most recent performance work we did was only in the core libraries (“Array”, “Hash”, etc), and that helped IronRuby surpass Ruby 1.8.6 on Windows and gets much closer to Ruby 1.9.1. IronRuby is continuing to investigate ways of gaining performance in each release.
IronRuby is also a very 1.8.6 compliant Ruby implementation. There is a “-19” flag for any 1.9 specific features you might need, and a “-20” flag for any Ruby 2.0 features we might have in there, but there are no guarantees on those; we only test the 1.8.6 behavior today. We pass ~85% of the RubySpec test suite, the best test suite for Ruby implementations to verify their correctness. However, the numbers I’m more concerned with are whether specific Ruby libraries’ test-suites work. We pass Rails, RubyGems, Rake, and RSpec’s test suites at well over 90%, and fix compatibility issues when asked about them, so please let us know if your applications run into any compatibility problems.
Other than the limitations that I mentioned in the previous question, you should have no problems. I love people to try running their Rails applications on the latest IronRuby bits hosted on GitHub, and please report any issues you find on

Matt: Are they any extra advantages to use IronRuby?

The most notable advantage is that IronRuby works in Silverlight, a subset of the .NET framework which installs as a browser plugin in Mozilla-based browsers (eg. Firefox on Mac and Windows), Webkit-based browsers (eg. Safari on Windows), and IE (on Windows, duh). The Mono project is implementing an open-source version of Silverlight called “Moonlight” so Linux developers can run Silverlight applications, which I talked about at OSCON 2009. This enables you to write Ruby in the browser instead of JavaScript, for controlling HTML or vector graphics. The best place for documentation/examples today is on the Gestalt website, a little portal designed to bring awareness to Ruby and Python in Silverlight: The IronRuby website is in flux at the moment, but clearer documentation is on its way. I also built a little Ruby on Rails plugin called “Silverline” to make it really easy to use Silverlight from Rails. Worth checking out if you want to use Ruby as a client scripting language.
IronRuby has direct integration with the .NET framework, so anything that is in, or run on, the .NET framework can be used directly from IronRuby. .NET namespaces are exposed as Ruby modules, .NET classes as Ruby classes, and you can call methods on them just like you call Ruby methods. This makes it really easy to build pieces of your system in a static language (if it makes sense to use, like for a high-performance message queue, game engine, etc) and then interact with it through Ruby.

Matt: Why is Microsoft interested in a Ruby project? What advantage do they find in sponsoring such a project?

I see it as a “you scratch my back, I’ll scratch yours” situation. Microsoft sponsoring IronRuby helps the Ruby community by making Ruby a first-class language on Windows and .NET, also giving the .NET crowd the choice of using Ruby, and in return the IronRuby project helps promote innovation in the languages that drive Visual Studio purchases (C#, VB.NET, and F#).
As a kind-of related side-note: some people feel it’s a bad thing that there are so many implementations of Ruby, kind of like MRI is so bad that others had to fix it, but I completely disagree. IronRuby, JRuby, MacRuby, and most of the other implementations accomplish the same thing for their respective communities; building a bridge between Ruby developers and themselves. Rather than needing to recreate MRI, most have been inspired by it and wanted to bring the language to their platform. It’s a great thing for the Ruby community because it gives access to more platforms, operating systems, and libraries than any other language.
Anyway, back to the question: as an example of how IronRuby has helped language innovation, the next version of C# will now have a “dynamic” keyword, indicating that the variable statically-typed as “dynamic” (=P) should perform dynamic dispatch on any method calls, rather than verify the method call at compile-time. This infrastructure uses the Dynamic Language Runtime directly, so C# can use Ruby objects just like they were defined in C#, or any other dynamic-enabled object.

Matt: How will IronRuby make Rails developer lives easier and what are the plans for the future of IronRuby?

My hope is that IronRuby can benefit existing Rails developers by making Windows a great option to develop and deploy on. By building a Rack adapter specifically for IronRuby and IIS (like I showed at RailsConf), Rails applications can tie directly into the same web-server pipeline that ASP.NET does, significantly reducing the overhead deploying via IIS+FCGI gives you today. This makes deploying Rails applications on IIS just like deploying ASP.NET apps, so system administrators don’t have to learn a whole new framework; to them it’s just ASP.NET. Then any existing ASP.NET shops who want to offer Rails applications to their customers can, with the same infrastructure and deployment know-how. This is bringing choice to the technologies you choose to deploy on Windows, just like how Microsoft has helped make PHP run well on IIS.
The only definite future plans for IronRuby is continue pushing on performance on compatibility, as well as continue supporting the latest version of Silverlight and Mono. 1.0 will be released when the community is happy with the state of those metrics, and future work should be driven by what IronRuby users want. If you start using IronRuby and want a feature either by 1.0 or post 1.0, please post the request to the mailing list or to CodePlex. We have tons of hopes and dreams for what IronRuby can do in the future, so please come help out!

Matt: Is there anything you would like to add or share with the readers?

Thanks to Matt for the interview, and thanks to the readers for getting this far! Go grab the 0.9 release from, or the latest source from, tell us if you have any problems with it, and we hope you’ll help IronRuby get to a 1.0 release.

How do I learn Ruby & Rails?

This is a question I get quite a lot.

Where should I start? What should I do? What can I do to become a better Ruby/Rails developer etc.. (more common questions)

I wish there was a “simple/right” answer to these questions. Something like: “Read this book and you will become an awesome developer”.
Unfortunately, things are not that simple. We are all different and we learn differently, we also come from different backgrounds.

So instead of telling you what I think is the best way to learn, I decided to ask the community.
Here is a quick compilation of some of the responses I received:

What the community says:

How did you learn Ruby and/or Rails?

  • DHH DHH: I learned Ruby by programming in anger. Attempting to make something real. Not just a toy program.
  • David Black David Black: I learned ruby via pickaxe and lots of practice and both reading and answering questions on ruby-talk.
  • Evan Phoenix Evan Phoenix: reading code WHILE writing code
  • Yehuda Katz Yehuda Katz: I tried impossibly hard things to force myself to learn.
  • Laurent Sansonetti Laurent Sansonetti: I learned ruby via pickaxe, reading the posts on ruby-talk and then reading MRI’s source code
  • Ninh Bui Ninh Bui: I was quite a java fanboy back, writing struts + j2ee enterprise apps, Hongli forced me to look at Ruby over a weekend and I learned the Ruby basics. I then learned Rails by googling, reading books and source code.
  • Tim Connor Tim Connor: the rails community habit of obsessively blogging was probably the biggest help
  • Lar Van Der Jagt Lar Van Der Jagt: Ryan Bates’ railscasts for sure. The Rails Way once I knew enough to dig deeper. What I wish I’d done tho is work with experts!
  • Arun Gupta Arun Gupta: The Rails guides and Agile Development with Rails book.
  • Geoffrey Grosenbach Geoffrey Grosenbach: After I had read a few tutorials, I started by spending a few hours reading through the API docs. Even if you don’t understand everything, it’s a fantastic way to become familiar with what’s available.
  • Nate Todd Nate Todd: I learned MVC with a few CakePHP apps first. It helped me learn best practices in a language I was familiar with.
  • Chris Wanstrath Chris Wanstrath: I learned Ruby on Rails by writing apps and reading the framework’s source.

What advice would you give?

  • Bob Martens: Get involved in the community in some way. They know more than you. 😉
  • Ismael Celis: understanding the relationship between the parts of MVC. Loads of people coming to Rails don’t know what a design pattern is.
  • @jeromegn: I find the best trick to learn RoR is to simply try building something. Rails docs and learning Ruby in parallel helped me the most
  • @johnbender: knowing why instance vars are available in templates, etc. Essentially knowing the basics of ruby would be my initial advice
  • @ryandotsmith: writers read. Find popular projects on github (i.e. radiant ) and study their specs.
  • Sunil Karkera: understanding MVC in Rails was the most important thing for me when I started.
  • Luke Burton: basic screencasts showing something impressive being achieved in small amounts of code were a great start
  • DHH: Pick a real project and program in anger. That’s how I’d recommend learning any language including Rails and Ruby.
  • Anthony Green: Accept that there’s a Rails Way and you need to learn it. What helped me most ? – the community.
  • Kent Fenwick: Learn by doing a REAL project. Pick something you want to build and slowly chip away at it.
  • Trevor Turk: learn by reading and writing code… meaning you should try to build something you want instead of dumbly following tutorials…
  • Ryan Bates: Rails is made up of many technologies (HTML, CSS, Ruby, OOP, SQL, etc.). If you’re struggling with Rails, focus on weakest part.
  • Geoffrey Grosenbach: And there are many examples throughout that will help a new developer get a feel for the philosophy of Rails. Many people have learned from the Rails from Scratch series at PeepCode
  • @eifon: A good grasp of MVC is invaluable as is knowing some Ruby before you start.
  • John Yerhot: don’t be afraid to ask questions and use support channels – irc, mail list, rails bridge, etc…
  • Roy Wright: use the same version of rails as is in the book you are using.
  • @brianthecoder: read other people’s code
  • Ninh Bui: I learned by having discussions with a lot of people, I can definitely recommend that
  • Chris Wanstrath: Stop asking other people for advice and start coding something.

Different opinions but very interesting answers.
I tried to compile some of what I thought were great resources that helped me and/or other people I talked to.

Never heard of Rails or Ruby, what is it?


Start by watching one of the many screencasts/presentations about Rails.
Rails and software developed using Rails are written in a programming language called Ruby.
If you are new to software developer, you can quickly learn Ruby and I would recommend a great book called Learn to program by Chris Pine.
Ruby is a very elegant and intuitive language that you will be able to pick up quickly while learning new tricks for many years.
However, don’t expect that after installing Rails, you will have a Drupal clone in Ruby.
Rails is a web framework, in other words, a tool to help you write your own web application quickly and efficiently.

Tip: The Ruby website has a lot of information and resource to get started.

I hacked some PHP/Perl/<insert language here> scripts but I don’t know anything about MVC or Object Oriented development:

Here it really depends on how you learn things. Are you a “How” or a “Why” person?
A “How” person will learn by being shown how to do something and will then reproduce it and learn from it.
A “Why” person needs to understand why things are done a certain way so they can re apply their knowledge on other challenges.


The good news is that Rails uses many conventions and if you pick them up, you will quickly get things done and feel rewarded by what you have done.
That’s great for “How” people, but “Why” people might have to be a bit more patient and start playing with the framework before that can fully understand everything.

“How” people should definitely watch Ryan Bates’ excellent railscasts and read the Rails guides
“Why” people might want to read Ruby Programming Language and The Well-Grounded Rubyist, aka Ruby for Rails 2nd edition

You should also check the Rails wiki and contribute info that might be potentially missing.
(If you have a problem that is not covered/discussed in the wiki, try to solve it and then post your solution. If you come across the same problem at a later time, you will be able to quickly find how you solved it. By contributing, you will also save other developers’ time.)

Start reading Ruby/Rails related blogs, subscribe to rubyinside RSS feed and visit your local Ruby group.

Tip: Start a blog and keep track of what you learned. That will help you and other people facing the same challenges

I started writing a Rails app but I feel limited by my knowledge of the framework and the language

That’s a normal stage, don’t give up! Here are a couple of great reads: The Ruby Way and The Rails Way.
the Ruby Way should satisfy primarily the “why” people, while the Rails way should primarily please the “how” people. I’d recommend to read both.
Don’t hesitate to ask questions, check google, use twitter, blog comments, mailing lists. Try to find some local rubyists to share knowledge with.
Pick a topic you would like to know better and prepare a talk for your friends/local Ruby group or write a blog post about it.
One thing for sure, don’t be ashamed or discouraged. Persevere, it’s worth it (or get out, relax for a while, and then come back and give it another go).


A good way to improve your Ruby/Rails skills is to look at other people’s code. Check GitHub and see how people have solved the same problems you are facing.
You can also attend a Ruby/Rails training, a lot of companies offer classes around the world.
RailsBridge is trying to reach out to people aspiring to become better developer, check their site.

Tip: I often use apiDock when I’m looking for documentation on a method/class.

I wrote a Rails app, I adopted and understood the Rails conventions and I feel comfortable writing new apps.

party dog

Congratulations, you should be proud of what you have accomplished! But don’t stop learning!
Did you write tests for your application?
Do your tests really test your application, or are they just there to make you feel better (i.e: change your code, are your tests still passing? they shouldn’t)?
Do you use plugins? Did you look at their code? Do you understand how they work?
Could you write your own plugin? What about a Ruby gem?
Also, how are your javascript skills? What about CSS and DBA stuff? focus on your weaknesses.

I would strongly suggest contributing code at this point. Contribute a patch to one of the many GitHub projects, or even Rails, you will learn a lot!

Tip: Check out Gregg Pollack’s Scaling Rails series

I wrote a couple of Rails app, I even wrote a plugin/gem.

That’s great, by now you probably are very familiar with Rails and Ruby.
You might want to dive in a bit deeper. Maybe check how to wisely use metaprogramming and/or check on how to write C/FFI extensions.
Why not look at Ruby’s source code to learn how things really work?


It’s also probably a good time for you to start learning new languages to see how other communities do things.
Look at other frameworks and try to understand how and why people chose other conventions/ways.
Play with Python, Java, Scala, Clojure, Objective-C, Ocaml, Scheme or whatever language sounds interesting to you.
You don’t have to master other languages, but you should try to understand the reasoning behind each approach and understand the pros/cons.
It will honestly help your Ruby skills and broaden your horizons.

Tip: Prepare a couple of talks and send proposals to various conferences. (Don’t limit yourself to Ruby conferences)

I know Ruby and Rails like nobody else, I could even quote Rails and MRI’s source code by heart. (just ask a LOC)

Then I hope you are helping with the Ruby 1.9 efforts, contributing code to other implementations (IronRuby, JRuby, MacRuby, Rubinius) and helping with Rails 3 🙂

If you are reading this post, you are probably in one of the above categories.
Pairing and tutoring are great ways to learn, it’s all about karma. Helping others will help you becoming a better developer.
Feel free to leave advise, links and info in the comments.

Community feedback for the future of Rails

A few months ago, we announced the creation of a “forum” to discuss the future of Rails and what the community is interested in. Since then, many important suggestions/topics were addressed, many features were completed or started.
My goal in this post is to give you a quick overview on the status of the uservoice forum.

rails uservoice

Suggestions mentioned and completed:

  • Nested Model forms
    This is something that was actually started before we put the forum together and this feature is now available since Rails 2.3.x

  • Rails magazine
    Olimpiu Metiu already released two issues of his Rails Magazine. The PDF versions are available for free but you can also purchase the print version.

  • Better Wiki
    A lot of people have put efforts in building the new wiki and I’m sure a lot more content will be provided. We have also made the wiki available for translation.

Accepted/started suggestions:

  • Improved performance
    This is something that already started in the Rails3 branch, go check the work done by Josh, Yehuda, Carl and others to make Rails perform even better.

  • Public and plugin API
    This is something that’s particularly important for 3rd party developers and therefore plugin users. There is still a lot of work to be done with 3rd party developers and “advanced users” before we can get a fixed API. However, once we will have this API, Rails updates and plugin compatibility should be much smoother.

  • Slices/Engine
    Rails 2.3 came with the ability to have engines in your plugins and if you were at RailsConf, you might have attended Yehuda and Carl’s talk on mountable apps. Thanks to some work done on the router and Action Controller, you should be able to mount a Rails app inside another one sometime in the future.

  • Easier to read code
    The refactoring has already started and the internal code should be cleaner and easier to read. Remember that Rails is 5 years old, such a task isn’t easy.

  • Better support for non relational databases
    Thanks to Action ORM and some more refactoring, non RDBMS and other data stores will be better supported.

  • Unbind Test::Unit and Prototype
    Agnosticism is a big theme in Rails 3. Even though, Test::Unit and prototype will be the default, Rails won’t make any assumptions about users using one framework or the other. Watch David’s keynote at RailsConf for more information.

  • Make Action Mailer consistent with regular controllers
    This task was started as part of the work done on Abstract Controller.

Don’t forget that you can still make your suggestions and/or pick one that is already listed and start working on it!