Without further ado:

• Recommended Ruby Books
• Recommended Rails Books

A few people may disagree with the choices, but I think most experienced Ruby and Rails programmers, who’ve read those books, will concur with my recommendations. I’m quite confident that these are, all things considered, some of the best books available on the subject.

A word to the publishers

As tempting as it is to collect Ruby and Rails books, these days I don’t feel I can economically justify the act of purchasing every Ruby or Rails book put out there. So if you are a publisher or an author, and you’d like for me to consider your book, you are certainly welcome to send me a review copy. I will definitely read it, but only include it on these lists if it’s either outstanding or as good as the existing ones. If it’s a programming book that’s not related to Ruby/Rails, yet is really good, I would consider reviewing it on my blog.

No related posts.

Programmers are not all that different. Cross-training in other languages and frameworks can only improve one’s overall mastery of the craft. When it comes to Ruby frameworks, the two most popular choices are Ruby on Rails and Merb. They’re often seen as being contenders, but this truly isn’t a zero-sum game; learning both is a very sensible move. They both enable you to write web applications in Ruby, and are somewhat similar, so learning one after you know the other shouldn’t be very challenging. In the many cases people learn Merb after they’ve had some experience with Rails, but either way, acquiring a solid grasp of both frameworks provides developers with extra flexibility. Often people who learn both, will end up mostly just using one or another, depending on their individual preferences. But it’s worth knowing them so as to be able to write both CRUD-style applications that fall within Rails’ solution space, and more complex, edge cases where Rails’ opinions will end up contending with yours.

Among the reasons to give Merb a chance, is its focus on performance, a smaller memory footprint and an extreme level of modularity, which enables you to pick and choose which components you’d like to use.

Merb is not as mature as Rails, of course, but it has reached version 1.0.x and with it developers can have greater confidence in a more stabilized API. Now is perhaps the best moment to get involved and learn more about this rising framework. Not surprisingly though, Merb finds itself in a similar spot to the one that Rails was in a couple of years ago (in terms of weakness of documentation when it comes to getting started). Thankfully, this point is being taken seriously and there’s been some major progress in terms of improving the documentation for Merb. Below are some useful links to get you started with Merb.

Merb has an official API documentation, a wiki, a google group, and a community site called Merbunity for news, projects and tutorials. The irc.freenode.net #merb channel is also a useful and welcoming spot. Furthermore, there is a Peepcode PDF draft called Meet Merb. If you want something even more substantial, on the book front there are several titles coming out in the near future. These include Merb in Action, The Merb Way, Beginning Merb and Merb: What You Need To Know. There is also an open source Merb book, whose development is led by Matt Aimonetti. It’s a work in progress, but probably a very good starting point, which just happens to have the added bonus of being free. And if your interested in Merb, don’t miss InfoQ’s interview with Yehuda Katz, who’s Merb’s lead developer and one of the sharpest guys we have in the Ruby community.

Finally, if you are a professional developer who wants to quickly progress with Merb and bring their skills to the next level, do not miss your chance to attend a three day intensive course on Merb, which is being offered by Yehuda and Matt in Phoenix, AZ between January 19 and 21 (2009). Registration has been open for two days already and 20 out of the 30 available spots have already been snapped up. The remaining seats won’t last more than a day or two, so if you are interested, don’t delay (sign up now and you’ll also benefit from an early registration price).

2009 is almost here, so why not take the opportunity to learn Merb this year?

No related posts.

Disclaimer

Just as with the previous shootout, before proceeding to the results, I urge you to consider the following important points:

• Engine Yard sponsors this website, and also happens to sponsor, to a much greater extent, the Rubinius project. Needless to say, there is no bias in the reporting of the data below concerning Rubinius;
• Don’t read too much into this and don’t draw any final conclusions. Each of these exciting projects has its own reason for being, as well as different pros and cons, which are not considered in this post. They each have a different level of maturity and completeness. Furthermore, not all of them have received the same level of optimization yet. Take this post for what it is: an interesting and fun comparison of Ruby implementations;
• The results here may change entirely in a matter of months. There will be other future shootouts on this blog. If you wish, grab the feed and follow along;
• The scope of the benchmarks is limited because they can’t test every single feature of each implementation nor include every possible program. They’re just a sensible set of micro-benchmarks which give us a general idea of where we are in terms of speed. They aren’t meant to be absolutely accurate when it comes to predicting real world performance;
• Many people are interested in the kind of improvements that the tested VMs can bring to a Ruby on Rails deployment stack. Please do not assume that if VM A is three times faster than VM B, that Rails will serve three times the amount of requests per minute. It won’t. That said, a faster VM is good news and can definitely affect Rails applications positively in production;
• These tests were run on the machines at my disposal, your mileage may vary. Please do test the VMs that interest you on your hardware and against programs you actually need/use;
• In this article, I sometimes blur the distinction between “virtual machine” and “interpreter” by simply calling them “virtual machines” for the sake of simplicity;
• Some of the benchmarks are more interesting for VM implementers than for end users. That said, if you think the benchmarks being tested are silly/inadequate/lame, feel free to contribute code to the Ruby Benchmark Suite and if accepted, they’ll make it into the next shootout;
• Finally, keep in mind that there are three kinds of lies: lies, damned lies, and statistics.

Ruby implementations being tested

All of the Ruby implementations that were able to run the current Ruby Benchmark Suite have been grouped together in one main shootout. This group consists of Ruby 1.8.7 (p72, built from source, and installed through apt-get), Ruby 1.9.1 (from trunk, p5000 revision 20560), Ruby Enterprise Edition (1.8.6-20081205), JRuby 1.1.6RC1 and Rubinius (from trunk), all of them were tested on Ubuntu 8.10 x64, plus Ruby 1.8.6 (p287. from the One-Click Installer) on Windows Vista Ultimate x64. The hardware used for this benchmark was my desktop workstation with an Intel Core 2 Quad Q6600 (2.4 GHz) CPU and 8 GB of RAM. JRuby was run with the -J-server option enabled and by specifying 4 Mb of stack (required to pass certain recursive benchmarks). The best times out of five iterations were reported, and these do not include startup times or the time required to parse and compile classes and method for the first time. Several of these new tests also have variable input sizes.

The MagLev team provided me with an early alpha version of MagLev for the purpose of testing it in this shootout. Since this VM is not mature enough yet to run the Ruby Benchmark Suite, I used custom scripts against an old version of the Ruby Benchmark Suite on Ubuntu 8.10 x64. MagLev was tested, along with Ruby 1.8.6 (p287), on the same machine as that of the main shotoout, though the benchmarks were different (even when they had the same names as the ones in the main shootout).

MacRuby 0.3 and Ruby 1.8.6 (p114) were tested on Mac OS X Leopard using the previous version of the Ruby Benchamrk Suite. Since my MacBook Pro died (sigh), for this benchmark I used a Mac Pro, with two Quad-Core Intel Xeon 2.8 Ghz processors and 18 GB of RAM.

IronRuby (from trunk) and Ruby 1.8.6 (p287) were tested on a previous version of the Ruby Benchmark Suite on Windows Vista x64 on the same quad-core used for the main shootout. The MagLev, MacRuby and IronRuby numbers reported here were the best times out of five iterations, and include startup time. IronRuby on Mono was not tested because I couldn’t get it to work on my machine, despite having tried several IronRuby versions and two different Mono versions. Please also notice that Ruby 1.8.6 (p287) was tested twice on Windows, once for the main shootout against the current Ruby Benchmark Suite, and a second time to compare it with IronRuby, against the old benchmarks.

Note: As tempting as it is, do not compare implementations that belong to different shootouts directly to one another. It would be very disingenuous to directly compare VMs tested with different benchmarks and/or different machines. The only comparisons that make sense are the ones within each of the four groups.

Main shootout

The following table shows the run times for the main implementations. The table is fairly wide, so you’ll have to click on the image to view the data in a new tab.

Green, bold values indicate that the given virtual machine was faster than Ruby 1.8.7 on GNU/Linux (our baseline), whereas a yellow background indicates the absolute fastest implementation for a given benchmark. Values in red are slower than the baseline. Timeout indicates that the script didn’t terminate in a reasonable amount of time and was (automatically) interrupted. The values reported at the bottom are the total amounts of time (in seconds) that it would take to run the common subset of benchmarks which were successfully executed by every virtual machine. When our baseline VM generated an error, others were used, starting with Ruby 1.8.7 on Vista (for color coding purposes only).

The following image shows a bar chart of the total time requested for the common subset of successfully executed benchmarks (those whose names are in blue within the tables):

More interestingly, the following table shows the ratios of each Ruby implementation based on the baseline (MRI):

The baseline time is divided by the time at hand to obtain a number that tells us “how many times faster” an implementation is for a given benchmark. 2.0 means twice as fast, while 0.5 means half the speed (so twice as slow). The geometric mean at the bottom of the table tells us how much faster or slower a virtual machine was when compared to the main Ruby interpreter, on “average”. Just as with the totals above, only those 101 tests, which were successfully run by each VM, where included in the calculation.

More concisely, here is a bar chart showing the geometric mean of the ratios for the various implementations tested:

I prefer to let the data speak for itself, but I’d like to briefly comment on these results. Just a few quick considerations.

Working off of the geometric mean of the ratios for the successful tests, Ruby MRI compiled from source is twice as fast than the Ruby shipped by Ubuntu, and by the One-Click Installer on Vista. The huge performance gap between ./configure && make && sudo make install and sudo apt-get install ruby-full should not be taken lightly when deploying in production. These numbers also reveal what most of us already knew: Ruby is particularly slow on Windows (800-pound gorillas in the room, or not).

Performance-wise Rubinius has more work left to be done to catch up with Ruby 1.8.7 and other faster VMs, particularly if we take into account the number of timeouts. But it has improved in the past year and I think it’s on the right track.

Ruby Enterprise Edition is about as fast as Ruby 1.8.7 compiled from source, which is reasonable considering that it’s a patched version of Ruby 1.8.6 aimed at the reduction of memory consumption (a parameter which wasn’t tested within the current shootout).

Speaking of excellent results, Ruby 1.9.1 and JRuby 1.1.6 both did very well. It looks like we finally have a couple of relatively fast alternatives to what is a slow main interpreter. According to the results above, and with the exception of a few tests, on average they are respectively 2.5 and 2 times faster than Ruby 1.8.7 (from source), and 5 and 4 times faster than Ruby 1.8.7 installed through apt-get on Ubuntu or Ruby 1.8.6 installed through the One-Click installer on Vista. Again, this does not mean than every program (particularly Rails) will gain that kind of speed, but these results are very encouraging nevertheless.

MagLev

There has been a lot of buzz about MagLev since Avi Bryant’s first benchmarks were shown a few months ago. Here we finally see it being put to the test. The table below shows the times obtained by running MagLev and Ruby 1.8.6 (p287) against MagLev’s set of benchmarks based on the old Ruby Benchmark Suite:

And here are the ratios:

You’ll notice how MagLev swings from being much faster than MRI to being much slower. I believe there is much room for improvement, but at almost twice the speed of MRI, these early results are definitely promising.

MacRuby

These are the times for MacRuby 0.3 on Mac OS X 10.5.5:

And of course, the ratios against the MRI baseline:

MacRuby is relatively new, so these are not bad results. More work is required, but it’s a good start.

IronRuby

Finally (I promise these are the last ones), here are the two tables for IronRuby and Ruby 1.8.6:

IronRuby is slower than Ruby 1.8.6 on Windows, which in turn is much slower than Ruby 1.8.7 on GNU/Linux. This is not very surprising. This project has been focusing on integrating with .NET and catching up with the implementation of the language by improving the RSpec pass rate, as opposed to performing any optimizations and/or fine tuning (as per John Lam’s presentation at RubyConf 2008). We’ll measure its improvements in the next shootouts.

Conclusion

Overall I think these are great results. Ruby 1.8 (MRI), with its slowness and memory leaks, belongs to the past. It’s time for the community to move forward and on to something better and faster – and we don’t lack interesting alternatives to do so at this stage.

I hope that for the next shootout, MagLev, MacRuby and IronRuby will be able to run the benchmark suite, so that they can all be tested and directly compared with each other. I also hope to include Tim Bray’s XML benchmark, some sort of “Pet Shop” sample Rails and Merb application and, above all, include memory usage statistics.

You can find the Excel file for the main shootout here. That’s all for now. Feel free to comment, subscribe to my feed, share this link and promote it on Hacker News, Reddit, DZone, StumbleUpon, Twitter, and Co. Putting together this shootout was a lot of work, so I definitely appreciate you spreading the word about it. Until next time…

Update (December 10, 2008): This article has been updated to correct a couple of major issues with yesterday’s results. I adjusted my commentary as well, in light of the corrected figures.

Update (February 7, 2009): Thanks to Makoto Kuwata, a Japanese version of this article was published in the Rubyist Magazine.

No related posts.

Merb: A few days ago Merb 1.0 was released. Congratulations to Ezra Zygmuntowicz on this important milestone, the Merb community and Engine Yard (who finances the project). Merb 1.0 wasn’t even out yet when some people had already started commenting on the fracturing of the Ruby community that this new framework might bring with this, and the impact that this high visibility “competitor” might have on Rails. I believe that having more than one widely adopted web framework will only benefit the Ruby community. Furthermore, it’s important to remember that this is not a zero-sum game. Ruby programmers are perfectly capable of learning two frameworks and using one or the other, depending on the project at hand. This is particularly true if we consider that Merb, for all of its advantages – and disadvantages – when compared to Rails, is not totally different from its forerunner. If you are an expert Rails programmer, you should be able to become proficient in Merb in very little time. To help with this process, the Merb community needs to concentrate on the documentation now, given that the API is finally stable.

Rails Myths: David Heinemeier Hansson began a series of posts about Rails Myths. I like the idea of seeing common myths addressed straight from the horse’s mouth. Over the past two years, Rails has received quite a bit of backslash and old fashion FUD, so it’s important to set the record straight, whether the myths are entirely fabricated or if there is some element of truth to them. Whether you agree with David or not, it’s also nice to hear two sides of the same story. In fact, at the beginning of my book I debunk a few myths, just to set the record straight regarding what some readers may have heard surrounding the framework. It was a fun part to write.

My Book: Speaking of my book, Ruby on Rails for Microsoft Developers, I’m getting closer to the finish line. I’m about to complete Chapter 9 (out of eleven chapters). The initial schedule I was provided with has been extended slightly so that there will be sufficient time to properly review the content and ensure that it’s up to date with the final release of Rails 2.2. Some people wondered what the “Microsoft Developers” part means. Is it for people that work at Microsoft? Is it for .NET programmers? Is it for people who develop on Windows?

The truth is that “Microsoft Developers” is probably just a marketing term that Wrox selected as a catch-all for of the aforementioned categories of programmers. As an author I’m trying to serve all of them well, by providing a guide that sneaks in much of the Rails culture and softens the migration path by using an Operating System, and to a certain extent, tools that they’re already familiar with. In my opinion one of the major obstacles when switching to, or trying, Rails when coming from the Microsoft world, is the culture shock. The documentation and most books assume that you are familiar with *nix systems and tools, and this can be frustrating for those who are forced not only to learn a new language and framework, but also an entirely new set of tools. As it’s targeted at Microsoft developers, the book obviously makes quite a few references and comparisons to the .NET world, where they fit. This is done so that the many .NET programmers amongst the group of so called “Microsoft Developers” will find the book particularly useful. Yet the book remains generic enough so that it can be used by any programmer (particularly Windows users), even those without any knowledge of the Microsoft .NET Framework or ASP.NET.

Python books: While on the subject of books, I wanted to mention that the final version of the Pylons book is available online. Despite the much less fancy UI, the book pretty much does what the Django Book did in the past. And both are available in print as well (The Definitive Guide to Django: Web Development Done Right and The Definitive Guide to Pylons). Pylons is a Python web framework that can be viewed as a Ruby on Rails clone, in a far greater way than Django could ever be considered.

Another thing I want to mention is that I received a copy of Expert Python Programming. I haven’t gotten to far into it yet, but from what I’ve seen so far, things look good. I hope to be able to read it through, over a weekend in the near future and then provide a proper review. Stay tuned.

Language Popularity: If you take a look at the TIOBE Index, you’ll notice a few interesting things: Ruby has dropped two positions since last year, and it’s now the 11th most popular language in the world. This shouldn’t be cause for concern though, as shown by this Ruby graph. Python on the other hand is increasing in popularity and moved from the 7th to the 6th most popular language. Interestingly, according to the index (the results of which are educated guesses only), Python would seem to be more popular than C#. I find this to be true, in terms of online activity within an increasingly vibrant community, but in my opinion, the job market hasn’t caught up yet. In fact, at least in Toronto, when there’s a Python opening it’s pretty much an event that’s worthy of being discussed on the local Python mailing list. C# openings are much more common. This may be different in Silicon Valley, of course. It would also seem that Delphi has experienced a huge come back, moving from the 11th position last year to the 8th one this time around. It’s hard to imagine that Delphi has had a similar level of adoption as C# and thus has become more popular than Perl, JavaScript and Ruby. Delphi is a great solution for Win32 programming, but I don’t quite believe this overly optimistic outlook. And if this is the case, where are all the Delphi jobs and buzz?

DB2: This interview shows a few good reasons why even smaller and medium sized companies are increasingly adopting DB2. And while the video doesn’t mention it, IBM is coming out with an updated version of DB2 Express-C 9.5. This new version, 9.5.2 or 9.5 FixPack 2, is going to introduce exciting new features, including an engine for full text search.

The Great Ruby Shootout These days you hear a lot of talk about parallel programming. Intel promotes it and despite their bias, it’s plausible that parallel programming will become important as the CPU market heads towards an increasingly larger number of cores, as opposed to focusing on the frequency of said CPUs. In the world of Ruby, this translates into multiprocessing, as opposed to multithreading due to the infamous GIL (Global Interpreter Lock). This means that Ruby will most likely approach the problem similarly to how Python 2.6 did with the multiprocessing module, which is a process-based interface. The obvious exceptions are JRuby and IronRuby, which establish a 1 to 1 relationship between green threads and OS threads.

For the shootout, it would be interesting to see some multithreaded code, so as to get a better sense of how well JRuby and IronRuby compare to MRI and 1.9, when more cores are available. In fact, the long-promised shootout will be performed on a quad-core machine with 8GB of RAM. If Charles Nutter, John Lam, or any of their team members would like to contribute some programs that are able to take advantage of “native” multithreading, I’d be very happy to include them in the Ruby Benchmark Suite, to be used for my shootout.

The repository requires some love and refactoring, since it needs to be split in two types of benchmarks. The simpler one will evaluate the execution time minus the startup time, while the more advanced benchmark will also exclude the time required for parsing and loading modules, classes and methods in the AST. It would also be nice to test each program with variable input sizes and report these results accordingly. Right now I’m very busy with the book, but as I become more available, I’ll start working on this.

Finally, I want to point out a very interesting article about performance and UIs. Slow is indeed a very relative concept, and it’s important to understand how to analyze and respond to the user requirements when it comes to the responsiveness of an application as a user interacts with it.

Hardware: I finally bought a Trackball made by Logitech and the Microsoft Ergonomic Keyboard (Microsoft makes great hardware). I don’t have wrist problems, but I’d like to see how these two affect my extensive computer usage. I plan to report my experience as soon as I’ve had a chance to use these input devices for a while, since I know this is a topic that interests lots programmers (many of whom end up being victims of RSI, and some of the IRS ). I also bought a bad-ass color laser printer which is quite handy when you’re a programmer and you are writing a book. I’ll let you know how it goes. What I didn’t buy, but still think is awesome, is the Flip minoHD. It’s the equivalent of an iPod for the world of camcorders. $235 for a camcorder that’s so perfectly compact, and yet that can record in HD, is a pretty sweet deal. I’m considering it for Christmas, assuming it reaches Canada by then.

No related posts.

I joked about this and said that “Arc is the infogami of programming languages”. Infogami was a project started by Aaron Swartz, that was claiming it was going to revolutionize the web “like the Macintosh did for computers” (if I recall the quote correctly). Despite the great expectations and the grand announcements that were made, the project (launched by what was a YCombinator startup) never really flew. But I digress; the point is that Arc, like infogami was wrapped in layers of expectations, like a scallop with bacon, but the delivery and the outcome were less than stellar.

Don’t hold this against Paul (or Aaron); projects fail or have rocky starts all the time. It’s the nature of software and of this business. Don’t jump to conclusions too quickly and assume that Arc has failed and is dead, either. Paul seems to have long term plans for the language. Many popular languages today were absolutely obscure to most developers for their first several years. Should Arc become the great language many had hoped for, people will have no qualms in adopting it in 1, 3 or even 5 years time.

I think that Paul is trying to distinguish between what the core features of the language are and its libraries, and his aim and focus is currently directed towards the former; a core that he wishes to change and evolve with a certain degree of freedom. From many of his writings, it is apparent that Paul has set out one clear cut criterium for the features of his language: whatever changes are made, need to make Arc concise. Concise doesn’t mean terse or unreadable, it means powerful and expressive enough to enable the language’s users to write a certain program with much less code than what’s required by other commonly adopted languages, and if possible, even by the most popular dialects of Lisp.

This approach to the design of the core language is far from off course. For example, Ruby’s conciseness is one of its most appreciated characteristics and one of the prominent features that sets it apart from compiled languages like C or Java. But a powerful and well designed programming language is not enough. That’s not really what developers are after.

Programmers are looking for solutions to existing problems and pains. They want tools, and this includes languages, that are good at helping them while they try to implement certain types of software. The languages may be general purpose, but if they don’t represent an advantage over other alternatives in a particular domain, they are hardly used.

In short, libraries and the ecosystem surrounding programming languages are often as important as the languages themselves.

In a somewhat related “ask News.YCombinator” question, Clojure was mentioned as a possible “next big thing” for the Lisp world. As you can imagine, the subject of Arc was brought up and Paul stepped in with a few comments. Two significant ones specifically focused on the subject of libraries, trying to address what is currently perceived as one of Arc’s big weaknesses, whereas it’s a strong point for Clojure, which can rely on all the existing code available for the Java world (since Clojure targets the JVM).

The first of these comments included the following quote:

Powerful libraries are a cheap way to make a new language the language du jour. (Think Rails.) They’re not the critical ingredient if you’re trying to make something to last; they may even hurt. — Paul Graham

And the second one, further explained what his position was:

The dangers of libraries are that they distract one’s attention from the core language, and that they could conceal or perpetuate flaws in the core language. I’m not saying that languages *shouldn’t* have powerful libraries, btw, just that they may not be 100% upside. — Paul Graham

Read that first quote again. I agree with the initial part of it, but find the conclusion is not supported by the facts. Paul himself brought up the example of Ruby and Rails, so let’s explore this further and see what Arc could learn from Ruby’s experience.

Ruby was a very good programming language that for a long time was hardly used outside of Japan. Beside the scarcity of documentation in English, one of the major untold challenges of the language was that it didn’t really solve a particular problem. It was a beautiful general purpose language and that was it. Sure, quite a few smart early adopters realized the potential of the language, and it started to gain some momentum amongst Perl developers, as a possible Perl successor. But let’s face it, for most people Perl was good enough.

Ruby’s core didn’t really change in 2006, when a large majority of the development community acknowledged the merits of the language. Ruby in 2000 and Ruby in 2006 were not really that different. What was drastically different about the two was the ecosystem surrounding Ruby. And the fact that Ruby now offered an incredible solution for those developers who desired to address the problem of web development. Matz was right, Rails is Ruby’s killer application.

But let’s not stop here. Paul agrees that Ruby’s growth rate has been exponentially increased thanks to Rails. So much so that he mentioned it as an emblematic example of a “cheap way” to bring a language to the front of the class. He concludes however, that this is not really the right approach or the critical ingredient needed to create something that lasts. He even goes so far as to say that it may end up hurting the language. And in this, I absolutely disagree.

I disagree because the history of Ruby and that of a few other programming languages shows how the arrival of a community of interested developers has always had many more benefits than drawbacks, provided that a minimal leadership for the projects existed. Taking an accelerated course in Ruby History 101, we’d discover that Ruby already had its own group of fans and a growing English speaking community. Ruby was able to stand on its own merits. What Rails did was inject an incredible amount of attention towards Ruby from developers, companies and the tech oriented media.

What was the effect of all this on Ruby? Countless libraries were written for the language; thousands of companies, particularly startups, adopted Ruby as their language of choice. There was a spur of alternative new Ruby web frameworks (like Merb, Ramaze, etc…) and also a dozen alternative implementations that attempt to improve upon the shortcomings of the language’s main implementation and, in a few occasions, to integrate Ruby with other existing VMs (e.g. with JRuby and IronRuby). There were a grand total of two generally available books on the topic, yet now bookstores are filled with Ruby-specific books, not just ones about Rails (something I predicted to my wife back in 2004). Perhaps more importantly, Ruby is now also widely used outside of the web development world as the truly general purpose language it was intended to be. Every time a DSL is needed, Ruby delivers. There are very popular conferences for the language held throughout the year and companies (e.g. Engine Yard) and VCs are investing money in the future of Ruby. mod_ruby wasn’t working for Rails? Along came Mongrel (and several other alternatives) and now even mod_rails to address the deployment issues.

Paul, I’ll take this flourishing community and ecosystem if its downside is just a sea of newbies asking silly questions in forums. Rails has shown the world what Ruby is capable of, and by doing so, it also presented Ruby’s faults in a clear light. Only this time, there weren’t 100 people ready to jump in and fix it; there were 10,000, several companies and millions of dollars to back it up. To me this is a critical ingredient to make something last.

I understand that Paul isn’t rushing when it comes to Arc, and that he wants to perfect his language before letting a large crowd gather around it, but the risk here is the alienation of early adopters and letting many people who were genuinely interested in the project down. Arc like Ruby did (and unlike Clojure), cannot rely on a wealth of existing code. To ensure its bright future Arc will therefore need to make up for this with, yes, a well designed powerful core, but above all with a growing set of libraries, a growing community and if possible, at least one easily identifiable area where Arc shines in resolving one problem better than other existing languages are capable of doing. Based on the trend of the development world, this killer application will probably come in the form of a Rails or Seaside equivalent for Arc. There isn’t a mad dash, Arc is still very young after all, but it would be a mistake to underestimate the importance of such a critical component for the future and success of this language.

No related posts.

This edition begins with some bad news: Several vulnerabilities that affect the main Ruby implementation have been discovered. There is no reason to freak out, but they are serious. An ill-intended person could take advantage of these vulnerability and execute arbitrary code. Matasano has a few practical examples which illustrate the vulnerabilities in question. To learn more head over to the official advisory. Unfortunately, the suggested upgrades (except those for Ruby 1.8.7) are currently not working for many Rails developers, who’re reporting segmentation faults. The Phusion team has created a patch that was reported to be working, but it would be nice to see the Ruby Core Team verify and incorporate it quickly. If you’re running a version of Ruby that shipped with Mac OS X, don’t upgrade yet. Instead wait for Apple’s Software Update.

RubyGems 1.2 was released and it’s much more responsive than previous versions of it were (no more bulk updates just to install a new gem). To upgrade run: sudo gem update --system (without sudo if you are on Windows). After a substantial refactoring, Mocha 0.9 – a framework for mocking and stubbing – was released this week. A new BitNami RubyStack version was released (1.2 beta) as well, which adds a lot of goodies to the package, including but not limited to NGINX, Thin, Rack, EventMachine and so on. Speaking of EventMachine, check out EventMachine: Fast and Scalable Event-Driven I/O Framework published by InfoQ. Last week they also published an interview with yours truly, in regards to the Ruby Benchmark Suite. I regret that the shootout testing hasn’t started yet as promised, but Murphy’s law got in the way.

For those interested in improving their language-fu, there were a numbers of interesting articles: Using select, reject, collect, inject and detect, Enumerating Enumerable, Macros, Hygiene, and Call By Name in Ruby Eliminating code duplication with Metaprogramming. Also noteworthy, this piece on working with Microformats from Ruby.

A Ruby Community Announcements group was started in order to provide a fast ML for announcements only. It’s for those who’d like to stay in the loop, but wish to avoid the high volume of messages in Ruby-Talk.

The erubycon conference about Ruby and the Enterprise will be held between August 15 and 17 (‘08) in Columbus, Ohio. They still have a few seats available, so if this topic is of interest to you, grab a spot while you still can.

Finally, if you’re hiring Ruby talent or plan to look for a Ruby job any time soon, take a peek at these 15 fundamental questions for Ruby interviews. They’re somewhat basic, but the article is a good staring point nevertheless.

ALT.rb

From the world of alternative implementations and frameworks, I found this article on Rubinius FFI, an introduction to MacRuby as a replacement for RubyCocoa, and the announcement of Merb’s run_later” method for backgrounds tasks, all to be informative.

To keep the good times rolling, the second edition of This Week in Rails is available on the official Rails blog.

Possibly related posts:

1. This Week in Ruby (June 16, 2008)
2. This Week in Ruby (April 28, 2008)
3. This Week in Ruby (April 21, 2008)

As announced a few days ago, This Week in Ruby is being split into two parts: This Week in Ruby and This Week in Rails. The one you are reading is the Ruby edition, while Riding Rails – the official Rails blog – will host the Rails one. Links to and from each post will be provided, in case you don’t follow both blogs.

Ruby

The Ruby community has shown a clear interest in Behavior-Driven Development (BDD), so if you haven’t taken the plunge yet, check out Ben Emson’s introduction to RSpec Stories. Those who’re already well versed with RSpec, will enjoy an article by another Ben, in which RSpec’s DSL internals are explained in detail so as to cover an example of creating macros with RSpec.

The Pragmatic Programmers published a series of screencasts about The Ruby Object Model and Metaprogramming. So far they’ve received glowing reviews, including my own, hence I highly recommend that you evaluate them.

A couple of weeks ago I announced the creation of a Ruby Benchmark Suite project. The next shootout will take place starting from the 24th and I should be able to get the results up on this blog by the 30th of this month.

While working on modifying his RX Ruby Tokenizer to be included in the Ruby Benchmark Suite, Tim Bray reported a few considerations on the sad status of REXML and Ruby 1.9. It’s definitely an interesting read, and it’s important to increase the awareness about the current pains of working with Ruby 1.9 and REXML.

Yesterday, Tim also had a post titled Deletionist Morons about the controversy surrounding the proposed deletion of Why the lucky stiff’s wikipedia entry. The Ruby community at large vouched for Why, who is clearly one of its biggest, and definitely most original, contributors.

Finally, the fun Ruby article award of the week goes to Ilya Grigorik for his Tumblr, RMagick and a Photo Frame!

ALT.rb

RailConf’s presentation regarding MagLev has been an attention grabber in the world of alternative Ruby implementations. A video of Avi Bryant’s demo is now available online, as well as a somewhat older interview with InfoQ. You can read Chad Fowler’s take as well as mine.

MacRuby 0.2 was released about 10 days ago. For those not familiar with this project, it’s an Ojective-C based implementation of Ruby 1.9 for Mac OS X. The general idea is to have a Ruby version that lets you write Mac applications that perform reasonably well. In the upcoming shootout we’ll be testing this early release as well.

Those of you still working in Java, but interested in the possibility of using Ruby’s testing tools and frameworks, should pay attention to the release of JtestR 0.3. As you can imagine, this works thanks to JRuby’s interoperability capabilities with Java. If this alternative Ruby implementation for the JVM appeals to you, you should probably also read Thomas Enebo’s interview about the future of JRuby. Speaking of interoperability, at Tech Ed (that’s a Microsoft event), John Lam demonstrated a cool prototype for the integration of IronRuby and ASP.NET MVC.

Readers interested in contributing to Rubinius, should take a look at this write-up about getting started with hacking on Rubinius.

Web Frameworks

At the latest Toronto Rails night (which I didn’t attend, but I soon will be as I’m moving downtown), Rowan Hick presented Merb, and has now made his presentation
available online. Speaking of Merb, Engine Yard Express is a new free product that lets you try out an Engine Yard “slice” wrapped up in a VMware image, and both Merb and Rails are supported.

The 2008.06 version of Ramaze was released last week. Aside from switching from a numeric release scheme to a date-based one (which I personally like much more), this is a major release that introduces over 450 patches and a few changes to the internal API.

To keep the good times rolling, the first edition of This Week in Rails is available on the official Rails blog.

No related posts.

Ruby

Two days ago JRuby 1.1.2 was released. Amongst several bug fixes and improvements, this release is characterized by a focus on performances. Startup time, threading, method calling and YAML symbol parsing have all been drastically improved.

Huw Collingbourne of SapphireSteel, has announced that he’ll be releasing a complete book on Ruby, chapter by chapter, free of charge online. After reading the first chapter, I can attest that it’s excellent. Keep an eye on it, as new chapters get added.

The Pragmatic Programmers put out a series of screencasts for sale. The most relevant series for Ruby programmers is Everyday Active Record. The first two episodes (a half an hour long, each) are out and can be purchased for just $5 a piece. The preview — and Ryan Bates’s reputation — lead me to believe that they are entirely worth their very reasonable sticker price. Speaking of screencasts, a new one about merb-slices was released on Merbunity, check it out if you’re into Merb.

There were two important releases last week, Mack 0.5.5 — which features a new rendering engine with support for Haml and Markaby — and DataMapper 0.9, a major reworking of the ORM. A third release, which is perhaps just as welcomed, was launched by _Why who included a few graphical improvements for Shoes, his GUI application toolkit. Definitely neat stuff, which I invite you to take a look at if you’re working on a Mac.

Peter Cooper published 21 Ruby Tricks You Should Be Using In Your Own Code. You probably know already most of the common ones at least, but they’re quick and fun, so if you haven’t checked out the post yet take a moment and do so. Other must-read tutorials and articles were Ruby && DTrace! (really neat results), Ruby EventMachine – The Speed Demon by one of my favorite Ruby bloggers, and Will’s Guide to Mashing-up Remote Databases using Page Scraping.

In a post made a couple of days ago, Robert Fischer opened up a can of worms by bringing up the issue of Ruby and XML libraries. As most of you know REXML is far from being issue-free (performance in primis), and in The Status of Ruby’s libxml Robert uncovers that the author of LibXml Ruby is unable to actively pursue the development of his extension. This issue concerns me, but if I’m working with databases, I prefer to take advantage of DB2 Express-C ’s fantastic pureXML features, which give me the sort of speed, flexibility and stability that I won’t find in a Ruby library anytime soon.

Before highlighting some of the news from Rails-land, I wanted to inform you that a new version of The Great Ruby Shootout will surface in June, as I intend to test a couple of special new entries.

Rails

Today, RailsConf 2008 started and it certainly stands a great chance of being dubbed an exhilarating event. A few people enquired to see if they could meet me there, but unfortunately I couldn’t make it. Chances are that you’re reading this post from RailsConf. If that’s the case, say hi for me and don’t forget to visit the nice fellas from Engine Yard, Morph (my sponsor), Phusion and GemStone. Oh and also, feel free to pass around the url of this entry.

Rails 2.1 RC1 is out, so you’ll find this article on upgrading to Rails 2.1.0_RC1 useful. Fabio Akita released a new version of his popular tutorials, Rolling with Rails 2.1 (part 1 and part 2). And if you are looking for an advanced authentication/authorization system for Rails 2, take a gander at Lockdown on RubyForge.

My friends at SeeSaw implemented a series of Rails Widgets which can easily be installed as a Rails plugin. Feel free to use them and/or contribute, in order to add further support for simplifying and reusing common UI elements. Speaking of shiny things, check out this Ruby on Rails icon pack; very pleasing to the eye, in my opinion.

RubyInside published a list of 28 mod_rails / Passenger Resources To Help You Deploy Rails Applications Faster. As DHH forecasted, “this could definitely become very popular, very fast ”.

New Relic released their RPM solution for monitoring and improving the performances of Rails applications to the general public. You can get it here.

And finally, some great news just came in, IronRuby is running unmodified Rails. “Excellent” (said in Montgomery Burns’ voice, complete with characteristic hand gesture).

No related posts.

Ruby

The tickets for RubyKaigi went on sale yesterday. RubyKaigi is the Japanese equivalent of RubyConf and will take place from the 20th to the 22nd of June.

Yehuda Katz blogged about Benchwarmer, which is an improved DSL for doing benchmarks. The repository can be found on GitHub.

That mad man, commonly known as why, has released another interesting proof of concept, aptly named Unholy. It’s a Ruby to PYC converter that aims at compiling Ruby sources to Python bytecode, making it possible to write Ruby code and run it on CPython. Not only that, but with a patched version of decompyle, it’d be possible to obtain Python source code that could be used, for example, on Google App Engine. Don’t expect to run Rails on mod_python anytime soon, though.

The Rails community may favor Macs, but there is no denying that there exist a huge amount of developers using Ruby and Rails on Windows. As a matter of fact, the One-Click Ruby Installer is the most popular project on RubyForge with almost 2.4 Million downloads, and Instant Rails is not doing too bad either, having surpassed the half a million mark. However, there is now another easy way to get the whole stack that’s required to run Rails on Windows (also available for Mac and Linux), and it’s called RubyStack. Unlike InstantRails, this is an actual installer and it includes: Ruby, RubyGems, Rails, MySQL, SQLite, Subversion, ImageMagick, Mongrel, Apache 2.2.8, PHP 5 and phpMyAdmin. The company, BitNami, also recently published a tutorial on how to add Aptana RadRails and Ruby Debug to the stack. If you’ve tried RubyStack, please leave your comments and opinions in the comments section.

Alternative implementations

Adam Fine, of Israel.rb, has a nice Ruby implementation roundup. You can read and comment on it here.

A couple of weeks ago the IronRuby project received a healthy dose of criticism (including my own) within the mailing list. A lack of openness and status updates, made contributions harder and portrayed the project as progressing at a deadly slow pace. I’m glad to report that the team has reacted in a proactive manner and embraced a more open approach where, for example, code reviews are now published in the ML. IronRuby has changed pace, or at least that’s the perception, and in an open source project this is also important. Now I’m confident that we can expect good things from this project. Meanwhile, you can try IronRuby in your browser, courtesy of Oleg Tkachenko.

You may remember, from a few editions ago, that I mentioned Dan Berger and his fork of the MRI, called Sapphire. DevFi has an interview with him in which he expresses quite clearly his intentions and rationale behind the decision to fork Ruby. Better support for Ruby on Windows, attention to correctness and testing, improving the standard library and a faster evolution of the language, seem to be the main reasons.

Sticking with the name Sapphire, Huw Collingbourne has a nice writeup on Multiple Inheritance, modules and mixins. While his language isn’t a fork of Ruby but rather just inspired by it, Ruby developers will find the article interesting as well, because it covers what Huw perceives as being issues when it comes to Ruby’s modules.

In JRuby-land, on the heels of Java One, Nick Sieger has announced JRuby-Rack which can be used to run Rails, Merb, or any Rack-compatible framework inside a Java application server.

Merb

According to this post Merb is running on Rubinius (if we exclude the ORM layer). Both projects are promoted and sponsored by the same company, so it’s natural that we’ll continue to see better integration.

Two new bundles for Merb and DataMapper are finally available for TextMate users. You can download and read about them here.

A post by Michael Klishin created quite a bit of controversy. Entitled State of Merb on road to 1.0: the good, the bad and the ugly, this kind of status update can be very appealing, as we head towards version 1.0 of Merb. Unfortunately “the ugly” in this case is the tone of the post, which made the author appear immature, due to the gratuitous bashing of Rails developers. It is unfortunate that the author of this nice mapping of a Merb server’s boot process, opted to convey his enthusiasm through blind antagonism. Let me reassure you though, that this is not representative of the Merb community as a whole; which is welcoming, definitely enthusiastic, but far from disrespectful of other projects. Merb developers believe in their project and the technical advantages that it offers over Rails, and have no qualms in stating so either. But they do so in a factual manner, as opposed to vague attacks against people who opt for a different framework.

Rails

Through his Twitter account, David announced that “Rails 2.1 RC1 has been tagged and the gems are on the beta servers”. Now is an ideal time to test it out. If you need some help, this screencast should do the trick.

The fourth part of a tutorial on Routing in Rails 2 was recently published. If you haven’t done so, follow the links to part 1, 2, 3 and 4.

Emacs fans may be interested in this screencast, that shows how to use Emacs with Rails. Other interesting highlights this week were: Write your Rails view in… JavaScript?, Community Engine (a Social Networking plugin), the release of El Dorado 0.9.2 (which adds a group chat option) and finally after_create :pimp, which automatically pings Google (and possibly other services) once the contents of your Rails app have been updated.

Rails deployment

Ron Valente has a guide on setting up a Rails server through Ubuntu 8.04 using Passenger. While Jim Neath, published Using Capistrano with Passenger (mod_rails).

For those interested in cloud computing, I found this article on how to create a “poor man’s” Content Delivery Network with NGINX, Varnish, Merb and Amazon S3, to be very compelling.

Meanwhile the VC funding spree of Ruby/Rails hosting companies continues, with a $3 Million round of financing being handed out to Heroku by Redpoint Ventures.

This week, Ezra’s Deploying Rails Applications: A Step-by-Step Guide finally hit the press. I ordered my copy from Amazon and it shipped yesterday. At about the same time, Advanced Rails Recipes: 84 New Ways to Build Stunning Rails Apps was published but, at least in my case, hasn’t shipped yet.

Railscasts 100th Episode Contest

Ryan Bates had a contest for his 100th Episode of Railscasts. Yesterday night he announced the winners. Congratulations to them and to all of those who participated. What’s really interesting though is that now there are several hundred Rails tips out there. You can read (and in some cases watch) all of them by following the links on the contest page.

All this material should be enough to keep you busy until next week. Please feel free to provide comments and feedback on this series.

Possibly related posts:

1. This Week in Ruby (April 21, 2008)
2. This Week in Ruby (April 28, 2008)
3. This Week in Ruby (May 5, 2008)

Rails

For some, the greatest Rails news this week was the announcement of a third edition of the Agile Web Development with Rails book. It’s currently in beta and will be finished by October, much to the anticipation of many, I’m sure.

Another interesting development, this time based on actual code, was announced through a post by Ezra Zygmuntowicz, entitled Hey Rails, nice Rack!. Basically, he’s working on “porting Merb’s rack machinery to rails” and it’ll eventually be merged with Rails’ core.

Three Rails related articles caught my eye in particular over the last few days. The first is 5 little-known Rails methods. I’d like to think that most Rails developers already take advantage of them, but if you don’t, it’s a good idea to learn about them now. The second is Building a Social Network Site in Rails, which is not a step-by-step guide, but rather a list of useful resources for building such a site. And finally, I liked Database agnostic != database ignorant in which the author provides a very basic intro to SQL joins and indexes. A much needed piece in the Rails community.

Ruby

The big news in this realm is that GitHub has began serving RubyGems. You can follow the instructions here, and read a nice interview with Chris Wanstrath, too.

JRuby 1.1.1 was released and I’m constantly more impressed by the speed of development of that project. Speaking of which, Charlie Nutter has published an excellent overview and status update of the various alternative Ruby implementations – and don’t miss the video of John Lam’s presentation on IronRuby’s status and DLR.

RubyLearning published a guide to Yahoo! Web Services in Ruby. And by the way, the same site is looking for ways to promote their free Ruby eBook.

Three interesting Ruby articles I want to point out are A Look at Ruby Debuggers by InfoQ, a tutorial about building Mac apps with RubyCocoa and XCode and a screencast on video transcoding and uploading to Amazon S3. Nice stuff.

In the alternative web frameworks arena, Mack 0.4.7 was released as further proof of the development speed of this project. This week Feather was also announced and it’s an open source, lightweight blog engine written in Merb.

Until next week…

No related posts.