Lately I’ve been thinking about the length of my blog posts. I humbly assume that they’re somewhat interesting to my readers, given the numerical growth of my audience, but almost each of the articles is a long essay or analysis that takes up a fair deal of time for both me and you. I believe that this prolixity is often entirely worth it, just as I don’t mind investing time in reading essays by Paul Graham or Steve Yegge. However, I’ve been wondering if I’ve set this expectation of writing something in-depth or not writing at all, for myself. The downside is that busy readers may have to skip quite a few of my articles, and I end up posting less frequently and necessarily limiting the number of subjects I can touch on.
With Twitter’s boom, an entire field of people with short attention spans, and very busy lifestyles being common, it is clear to me that people tend to prefer information in small, easy to swallow pills whenever possible. That’s why nano-publishers, who technically don’t add much to the discussion, tend to be so popular. 3,000 word articles are nice, and sometimes required, but perhaps I’ve been missing out by not allowing myself to post short considerations, incipits of discussions or content that can be quickly read, even if it’s never going to become a classic must-read computer science paper.
The inspiration for this came to me when analyzing my feeds. Out of hundreds of feeds, the only blog I constantly end up reading post-by-post is the one by Seth Godin. The ironic thing is that if you ask me what I think about it, I would tell you that what he says appears to me as common sense. I agree with him most of the time, he thinks out of the box and provides inspiration in the form of good suggestions, but his blog is not a Purple Cow. Yet, a lover of long essays like myself, follows his blog because the format that he’s adopted is simply effortless to read. He proposes small bites of thought and usually nothing more, but they are good bites, and that’s often enough. I’m busy yes, but I can spare those few seconds that it takes me to read Seth’s posts.
I wonder if I should adopt a more “relaxed” style for this blog, in which short thoughts about programming get published alongside longer ones. This post contains 417 words, in case you are curious.
If you enjoyed this post, then make sure you subscribe to my RSS Feed.
This is the third episode of This Week in Ruby, please consider subscribing to my feed in order not to miss any weekly installments.
Phusion Passenger
This week there were a few announcements that will change the history of Ruby. The first of them was the release of Phusion Passenger. For those who spent the last three weeks in a cave, Passenger is the name of mod_rails for Apache and, at the moment, it’s the most talked about piece of software in the Rails community. Let’s put this in perspective to better understand how important it is. A few years ago the recommended way of deploying Rails applications was the employment of Apache or Lighty with Fastcgi. Eventually the community realized that it was less than ideal, and a disaster for those who were using Typo or other Rails applications on most shared hosting plans. Most people then favored the option of using a cluster of mongrel processes, proxy balanced by Apache, Lighty, NGINX, etcetera.
There are other available variants for this configuration, and even some alternatives, but overall most people will agree that the concept of a proxy balancer plus a Ruby web server has been the recommended solution for a while now. It definitely works, it’s stable and scalable, and will probably continue to satisfy many users. There are, however, three disadvantages of this configuration: 1) The setup is not complex, but it’s definitely more complicated for newbies, when compared to what PHP developers are used to. It’s not an “upload and run” solution; 2) In order to work, it requires a decent amount of RAM, and root access to the machine doesn’t hurt either; 3) Most shared hosting companies are unwilling to offer it to their customers. That’s where Passenger comes to the rescue. It’s as easy as it gets (pretty much zero configuration), the company claims a lower memory footprint when used with their soon to be released version of Ruby (called Ruby enterprise edition), and finally it’s ideal for shared hosting because it’s just an Apache module like the ubiquitous mod_php.
As such, Passenger can be that vital missing piece for the wide adoption of Rails on the web. Try it out and if you decide to use it for your projects, don’t forget to feed the two brilliant minds who came up with it by donating here.
GitHub
Amongst other important announcements, is the launch of GitHub, where the Rails community seems to gather now. Think of it as the Facebook of Rails hackers. Aside from Rails, Merb and Capistrano, further projects are continually moving there. Some are even leaving Rubyforge despite their recent addition of a Git option. Both the ORM Sequel and the Ruby VM, Rubinius got on GitHub, even if the latter is only copied over by post-commit hooks.
Ruby Web Frameworks
As we approach the release of Merb 1.0, you may find the official wiki a useful resource and want to consider contributing to expanding it. And if you are interested in Merb thanks to its being leaner and faster than Rails, you may want to read Matt Aimonetti’s informal benchmark, that claims about 70% improvement over Rails for a dummy application.
Sinatra 0.2.0 was released, as a much improved version of the ultra-lean web application framework for Ruby. Very interestingly, an article was published that covers its usage for creating simple Facebook applications. A recommended reading for those who don’t need Rails’ overhead for simple apps.
This week RubyInside covered a new RESTful framework similar to Rails, called Mack. The amount of web frameworks for Ruby is constantly growing and this is due to the ease of creating DSLs in Ruby and the fact that Rack, made the integration with web servers dead easy. Do we really need all these web frameworks? Probably not, but natural selection is a powerful tool and this is interesting stuff that’s worth a test drive anyways.
Rails 2.1 will soon be released, if you are curious about the improved support for Time Zones, don’t miss this well explained overview by Geoff Buesing. The new features are just plain awesome and will make the trouble of upgrading worth it.
Ruby
A few other announcements were made this week in Rubyland. The most important, was the release of the 2.0 version of RDoc, which significantly improves ri performances (hallelujah).
Peter Cooper, who never sleeps, made the announcement of a Ruby community for link sharing, called RubyFlow. It could be a good replacement for ruby.reddit.com, given the clear anti-ruby bias that can be experienced on Reddit.
The first of 8 books on Ruby coming out soon was published this week. In fact, FXRuby: Create Lean and Mean GUIs with Ruby was finally published. I started reading the first few chapters and it’s very straightforward. If you are into desktop apps, consider getting it. In my opinion it’s a quick read.
Finally, please note that the registration for the fifth batch of the popular free online Ruby course by Satish Talim is now open. This course will start on the 3rd of May so sign up now if you are interested.
If you enjoyed this post, then make sure you subscribe to my RSS Feed.
Starting today, Amazon will be shipping the hardcover version of “The Last Lecture”, by Prof. Randy Pausch and Jeffrey Zaslow. While I wait for my copy to arrive, I feel the need to express a few thoughts on the subject of this book. Over the past several months I’ve been following closely Randy’s story and was often tempted to write a few lines about his touching message and courageous attitude towards life and death. The release of this book is a good opportunity for me to do so, because I’d rather prefer my words to be a heartfelt thank you letter - while Randy is still alive - than a brief eulogy to be published when, sadly, he’s no longer physically with us anymore.
Randy Pausch is a popular Professor of Computer Science, HCI, and Design at Carnegie Mellon University, an ACM Fellow, and the founder of the Alice project (an educational software that’s designed to teach computer programming to young students. You can donate here.). He’s also a married man and the father of three small children. In August of 2007, Randy was diagnosed with terminal pancreatic cancer and was told that he would have very little time left to live. Grimly, he was given an estimated 3 to 6 months of remaining good health.
On September 18, 2007, Randy gave a lecture at CMU which made him famous worldwide. The talk was titled “Really Achieving Your Childhood Dreams”, and it was given as per tradition, as a hypothetical final lecture in which top academics are asked to summarize important lessons that mattered to them, as though it was their last chance to do so. For Professor Pausch however, this was actually the case.
His lecture is truly brilliant and provides important suggestions on how to achieve satisfaction in life, by living to the fullest. If you haven’t seen it before, please make sure you do, today. It’s not the usual self-help mumbo-jumbo, and it’s not a sad, depressing lecture either. It’s uplifting stuff that will motivate you and, to a certain extent, change your life if you’re listening carefully enough. I know it has had a deep impact on my own life, even if I’ve never had the chance to meet Randy and I’ve not (thankfully, so far) had any close relatives or friends die as a result of pancreatic cancer.
I love how, throughout his lecture, Randy manages to maintain an optimistic outlook on life, while at the same time not being in denial about his condition, or the future that his family is facing. His proactive, positive attitude, even when approaching death, is nothing short of inspirational. And I’m talking about the type of inspiration that you get after hearing a recording of Richard Feynman. Without even trying hard to inspire many, this man ended up doing just that for the millions of online viewers and TV spectators who watched the condensed version of Randy’s lecture on Oprah.
Here is a man who, with humility and dignity, decided to fight an aggressive disease for which there is no cure, by living his life to its fullest and having fun until his last day. Rather than screaming “why me?” or feeling depressed by how unfair his situation is, he’s opted to accept his condition no matter how unfortunate it is. While at the same time working diligently to make the best of the present, and to ensure a future for his wife and kids in which they are taken care of.
You can’t control the cards you’re dealt, just how you play the hand. — Dr. Randy Pausch
It’s humbling, to say the least, when one start to think about the countless day-to-day opportunities that each of us has, just by the sheer fact that we don’t have an immediate “death sentence” over our heads. It makes you think about the value of time and the fact that most of us have no reason to feel sad or over-worried about the small problems that affect our daily routines. His lecture, and his ultimate lesson, are about embracing life and never giving up.
For those of you who have access to North American TV, tomorrow ABC will air an hour long Diane Sawyer feature entitled “The Last Lecture: A Love Story For Your Life”. Please, if you can, try not to miss it.
But it’s not just inspiration and the power of dreams that I want to talk to you about. We, as a society, have a very skewed perception of what constitutes a real threat. Terrorism is one of the most unlikely causes of death in America and yet it has received a huge deal of press coverage and public attention. Mad Cow Disease, Avian Flu, Africanized bees, just to name a few, are all very unlikely to affect you. Yet, in the collective mind they are perceived as huge risks, because they’ve been portrayed as such by the media. We have a huge elephant in the room though, and it’s being ignored. That elephant is cancer. Cancer is the second highest cause of death in the US, after Heart Disease, and in 2005 alone, it was responsible for taking the lives of 559,312 people. Or to look at it from another angle, 22.8% of all US deaths occurred as a result of cancer. 1 in 2 men, and 1 in 3 women, will statistically develop cancer in their lifetime. This means that if you’re married or have a life partner, there is a greater chance of one of you developing cancer, than of neither of you being affected. These numbers are astonishing, absolutely astonishing.
Society, as a whole, really needs to stop and reflect for a moment on the impact of cancer. Cancer is literally killing millions of people, and we are unnecessarily playing Russian roulette. The odds are against us. Any of us can get cancer, no matter how healthy we try to be. Cancer research has done a lot in terms of improving the survival rates of specific types of cancers. But others are, by and large, left in the dark, with very little funding and research going towards them. The five-year relative survival rate for melanoma went from 82% to 92% in the past 30 years, breast cancer went from 75% to 89%, and prostate cancer from 69% to 99%. Overall, considering all the types of cancer, in the past three decades, we’ve gone from a 50% chance of survival to a 66% chance. Those are all excellent results, and they essentially mean that if you get any of the cancers mentioned above, you have a fighting chance of surviving thanks to the research that’s been done and the funding that’s been put forth.
But not all cancers are created equal. Do you know what the survival rate for pancreatic cancer is? 4-5%. If you get pancreatic cancer, you may as well consider yourself dead - and usually within the span of a few short months. Over the last 30 years there have been extremely few advances in the field of pancreatic cancer research, and a truly severe lack of funding. I’m an atheist who doesn’t believe in prayer, but I do believe in science and that when you put money towards research, results usually follow in a fairly systematic manner.
Randy has been strongly advocating for the Pancreatic Cancer Action Network. I ask you to join me in donating to this very worthy cause, because donations can, and will, make a very real difference. I’m not good at telling other people what they should do with their hard earned money, but if you can, please contribute to this cause, as it will help to make Randy’s last few months worth of incredible effort all the more valuable. Many tech people donated to Ron Paul, Kucinich, Obama and other valuable political campaigns, now let’s make sure that the same happens for another type of very important cause - and let’s do it while Randy is still alive to witness our support.
The following is Randy Pausch’s public service announcement on behalf of the PANCAN:
The first edition of This Week in Ruby received a warm welcome from the community. A week later, here we are with a second installment of the series. I’ll attempt to repeat these posts approximately every week, so feel free to follow along by subscribing to my feed.
The Ruby community is a tremendously active one. In only seven days, there have been so many noteworthy items popping up, that it would take me hours just to mention them all. I’ll try to pretend that you, the reader, have been on a week-long vacation in a remote place without internet access, and on your return you asked me, “Hey, Antonio what happened in Ruby and Rails land while I was away?”
Some fun on April Fools’ Day
We kicked off the week on a lighthearted note, by fully embracing the endless opportunities offered by April Fools’ Day. Most of the spoofs and jokes were aimed at making fun of Ruby on Rails, one way or another. Testimony to the self-irony that we, as a community, certainly have. I personally announced the soon-to-arrive release of a fictitious (of course) framework called Ruby on Crack. Which was supposedly much faster and productive than Rails. At the heart of the joke were the fake endorsements, chocked full of double-meanings (with apologies to Matz, David Heinemeier Hansson, Dave Thomas, Ezra Zygmuntowicz, Obie Fernandez, Zed Shaw, Tim O’Reilly, Guido van Rossum and Paul Graham). I found the SQL on Rails April Fools’ gag very funny and extremely elaborate. Their screencast is comedic genius and their site a spoof in every minute detail. In my book, on that day, they took the cake. The joke itself was from two years ago (as pointed out by a commenter below) but it resurfaced again this year. The hilarious trend continued with Cobol on Cogs and for the ASP.NET and PHP nostalgic, with Acts as ASP.NET and RHAP (Ruby Ain’t Hypertext Preprocessor). Avdi Grimm even found the final solution to the whole Monkey-patching diatribe: Ninja-Patching, “When you really want to catch a coder by surprise, a monkey doesn’t cut it. What you need is a Ninja.”.
mod_rails
Last week I mentioned Passenger (aka mod_rails). This week Hongli Lai published some interesting benchmarks that compared it against Mongrel and Thin for three Rails applications (Typo, Petstore and El Dorado). While still synthetic benchmarks, the results where very encouraging and showed how Passenger was on average faster than Mongrel and roughly on par with Thin. Even just the perspective of having performances that are somewhat comparable with those of Mongrel, would be great news, given that it’d highly simplify the deployment process of Rails applications with Apache. Ninh Bui has announced that the official release date for the project is expected sometime this week and that meanwhile they are working with companies like Twitter and Dreamhost to ensure that the module is fully tested. Speed is only one of the project’s aims in fact, with a lot of focus put on stability and robustness, too. They also caught the attention of Engine Yard who is interested in discussing a possible partnership and contributions to the Rubinius project.
Git
By now you should be aware that the Rails community is fully embracing Git, and github.com is only part of the reason. Michael Bleigh has even created a small library called ruby-github to simplify access to the GitHub API. David has announced that Rails is moving to Git and the ticket tracking system is being switched over to Lighthouse. As David pointed out, this means that both the tracking system and version control are to be run by Rails applications, which is a good bonus if you subscribe to the philosophy of “eating your own dog food”. For those who are still git-challenged, Kurt Schrader has a collection of helpful links to get you started. And if you need a simple issue tracker for git, version 0.1.2 of Ditz has just been released, too.
Conferences
Confreaks has now published the remaining videos from MountainWest RubyConf 2008. They’re very interesting and highly recommended. All of them.
In case you missed the Ruby Fools conference, held on April 1st and 2nd in Copenhagen, you can read an interesting personal account by 41Concepts. The conference also took place on April 3rd and 4th in Oslo.
Speaking of conferences, Sam Ruby will be presenting on Ruby 1.9 at this year’s OSCON. In a recent short post, he mentioned his plans for his talk and really nailed one of the problems that will hinder Ruby 1.9’s adoption, in his own words:
My tentative conclusion at this point based on observations of efforts to get products like Rails working on Ruby 1.9: the biggest obstacle to Ruby 1.9’s adoption is the sheer number of mostly working but essentially unmaintained gems that virtually everybody in the Ruby community depends on. — Sam Ruby
The Rails Jedi posted about two Mac OS X applications for accessing Rails docs in the most efficient way possible. Nookkit.app and RailsBrain are real timesavers, and I highly recommend them to Mac users.
SapphireSteel has announced the Public Beta of their Visual Rails Workbench. With the release of Ruby in Steel 1.2 Beta 3, they have in fact included their drag-and-drop visual environment for Rails. I didn’t have a chance to try it out, but if you are on Windows you may want to give it a shot, starting with reading their online articles.
The ink for printing Ruby and Rails books never runs dry, as I pointed out in my post 7 soon to be released Ruby and Rails books. It turns out that in the months of April and May alone, there will be 8 new Ruby/Rails titles. Check them out, especially if you are looking for updated material relating to Rails 2 or, in the case of the pickaxe 3, to Ruby 1.9.
The guys from Rails Envy, published episode 25 of their Rails podcast. If you are not familiar with their fun podcast, I recommend that you listen to a few episodes by subscribing to it through iTunes.
Ruby
There were countless interesting Ruby articles in the last week, but I’d like to point out the following:
More remarkably, in the land of alternative Ruby VMs, Jruby 1.1 has finally been released, after months of hard work. The authors are already thinking about what lies ahead for the project. If the subject interests you, feel free to grab a few slides from various presentations on the topic.
If you enjoyed this post, then make sure you subscribe to my RSS Feed.
With the amount of good Ruby and Rails books already on the market, you’d think 2008 would be a shy year when it comes to publishing new titles, but nothing could be further from the truth. The following books are all to be released this month or in May, and there are many more coming out this summer.
Do we really need another 7 titles on the market within 2 months time? Interestingly, the answer is yes, for two main reasons. First, most of them serve a specific purpose, rather than being generic introductions. Second, we have a hole in the Ruby and Rails book market. Ruby 1.9, despite being a development release, has been out for a while. More importantly, Rails 2 differs enough from Rails 1.2 (covered by most books out there) to require new tutorials for those who approach Rails for the first time and perhaps even for those who wish to upgrade.
I think that the Pragmatic Programmers made a mistake in deciding not to upgrade their Agile Web Development with Rails, 2nd Edition because they left newcomers in a difficult spot. Developers who are experienced with Rails, will just get Obie’s The Rails Way and be fully covered, but those who are new and would like to get started with Rails don’t have many choices. They can get the Pragmatic Programmers’ Rails title mentioned above, but it’s a bit obsolete now and that means extra effort on their part to follow along, installing an old version of the framework, and then figuring out some way to move to the new features that were introduced by Rails 2.0 (soon to be Rails 2.1). As a matter of fact, when people ask me for a good Rails 2.0 introductory book for programmers, I can’t really name one. So far I’ve suggested getting Dave Thomas’ book or RailsSpace: Building a Social Networking Website with Ruby on Rails, and then moving to The Rails Way when they are ready to take it to the next level. But it’s not an ideal scenario at all.
Alright, to the titles then:
Title: Programming Ruby: The Pragmatic Programmers’ Guide (Third Edition)
Available: May 15, 2008
Notes: Currently in beta, it’s going to be the first book that fully covers Ruby 1.9 and its core and standard libraries.
Title: Simply Rails 2.0
Available: May 15, 2008
Notes: It’s the second edition of an already “gentle” introduction to Rails called Build Your Own Ruby on Rails Web Applications. It covers Rails 2, and if well written, it may be that missing guide for newcomers to Rails and beginner programmers, that I was talking about.
Title: Practical REST on Rails 2 Projects
Available: May 5, 2008
Notes: It’s marketed as a practical intermediate/advanced title for creating RESTful applications. The topic and target audience make it interesting for many web developers.
Title: Agile Testing with Ruby and Rails
Available: May 19, 2008
Notes: It’s supposed to extensively cover TDD and BDD with Ruby and with Rails 2.0.
Title: Advanced Rails Recipes: 84 New Ways to Build Stunning Rails Apps
Available: May 15, 2008
Notes: Currently in beta, it’s a Rails 2.0 cookbook by one of the most prominent developers in the community (Mike Clark).
Title: Deploying Rails Applications: A Step-by-Step Guide
Available: May 15, 2008
Notes: Currently in beta, it’s the book that should alleviate the pain of Rails deployment for many. Ezra is one of the biggest experts in the field, so I have great expectations for this title.
Title: FXRuby: Create Lean and Mean GUIs with Ruby
Available:May April 15, 2008
Notes: Currently in beta, it covers cross-platform development with FXRuby, the Ruby wrapper for the FOX toolkit. The author, Lyle Johnson, is also the author of the gem.
I can’t speak firsthand for any of these books, having not had the opportunity to read them yet, but knowing some of the talent behind them I certainly have high hopes.
If you enjoyed this post, then make sure you subscribe to my RSS Feed.
After several months of keeping it under wraps, I’m happy to officially announce my own web framework to the world. It’s called Ruby on Crack and will be released by RailsConf 2008. The name of the framework was chosen because I wanted to push the idea of a complete break from the existing Ruby frameworks, a clear cut, if you will.
Rails is great, don’t get me wrong, but it’s very opinionated. If you need to get things done in a different way, coding in Rails can become a burden. More reasonable from this viewpoint is Merb, but it’s still somewhat too close to Rails. Ruby on Crack is very different. A programmer using Crack no longer has strong opinions or is constrained within the rules defined by the framework. The only guiding principle is FUD (Fast Useful Development), but you get to decide your own specific style of web development. The framework is very modular and each component is connected to another one through a unified API called PIPE.
According to my preliminary tests, using Crack makes you 5 to 10 times more productive than using Rails. Not only that, but speed wise, you’re running much faster with Crack. Ruby on Crack ships with two extremely fast web servers, as opposed to WEBrick with Rails, called Purebred and Fat. Purebred handles requests by spawning new threads, while Fat uses an event based approach. From what I’ve seen so far, they easily outperform any other existing webservers, to the point that I was able to serve a sample app at a rate of 10,000 requests per second on commodity hardware.
Part of the speed boost that Crack can give you, is due the highly efficient, thread-safe and powerful ORM called Freebase. Even Datamapper is really slow compared to Freebase. On average, Freebase smokes ActiveRecord (it’s 4 to 5 times faster) and it can take advantage of advanced database features which are not supported in ActiveRecord, Datamapper, Og or Sequel.
I don’t want to reveal too much right now, but Ruby on Crack is truly a revolutionary approach to web development and makes you value the true power and colorful nature of Ruby. All of this will be explained in detail in future posts, and the code will be released into the wild for all to enjoy within the next couple of months. It took a lot of effort to get my team to work on Crack, but the results are rather satisfying. Don’t just take my word for it though, here are a few testimonials from prominent figures in the community who’ve had a chance to use the closed beta of Ruby on Crack:
“Those who use Crack can really appreciate the beauty of Ruby.” — Matz
“Fuck You” — DHH
“Incredible framework. I plan to publish a book about it ASAP, and I’m sure that it’ll be the first in a long series of books that I’ll write while using Crack.” — Dave Thomas
“Crack is what we really needed at Engine Yard.” — Ezra Zygmuntowicz
“Wow, what an eye opener. Crack made web programming fun again.” — Obie Fernandez
“You ass#$!@ m0#@#!@&%$” — Zed Shaw
“Once you have tried Crack for the first time, you realize how addictive it is. I simply can’t go back to Rails anymore.” — April Pesce
“Web 3.0 will belong to those on Crack.” — Tim O’Reilly
“If there is something that the Ruby community got right it’s Crack. I wish Python programmers were on Crack too!” — Guido van Rossum
“This is truly innovative and a godsend for startups. Give us about 6 years and we’ll have Arc on Crack too.”- Paul Graham
If you enjoyed this post, then make sure you subscribe to my RSS Feed.
One of the main advantages of Ruby’s growing community, is the speed at which exciting news pops up. This post briefly covers must-read highlights for new developments in the Ruby and Rails communities throughout the past week. I’ll attempt to repeat a “This Week in Ruby” post approximately every week, so feel free to follow along by subscribing to my feed.
Rails 2
Craig Webster published the first part of an easy to follow tutorial entitled Getting Started with Rails 2.0. The nice thing is that it also covers version control through Git, which is becoming extremely common in the Ruby/Rails community. Speaking of trends, a study by Gartner predicts that the Ruby language will reach 4 million programmers within the next 5 years. Numbers that would definitely position Ruby as a mainstream programming language. Incidentally, Obie Fernandez published an interesting survey of major corporations and large companies which are embracing Ruby on Rails. A very impressive list that is destined to grow quickly as Ruby’s implementation and ecosystem improve.
The official Rails blog has a post about a few changes in the core Rails team which brings the number of hackers down to 6, and establishes a Core alumni group of “retired” Rails core programmers. The small team seems to be busy, as Rails 2.1 is about to be released with some new exciting features, such as migrations based on UTC timestamp, named_scope, gems as plugins and much more as outlined by this caboo.se post.
On the deployment side, there are a few exciting happenings. Apple has published the third part of their tutorial, titled Deploying Rails Applications on Mac OS X Leopard. HighScalability.com has an article about an incredible service offered by Heroku that offers one-click, hassle free, cloud computing based Rails deployment. Their service is still in beta, and takes advantage of Amazon web services, but from what I’ve seen so far their secure and scalable deployment is as easy as it gets and it’s going to be a welcomed addition to the deployment options available to Rails programmers. Even more interestingly, a Dutch company called Phusion put up a demo about their Passenger project. Phusion Passenger, aka mod_rails, is a module for Apache that will bring ease of deployment, stability and performance to Rails. The company claims that according to their tests, mod_rails should be slightly faster than using Apache+Mongrel, it handles Rails processes automatically by spawning them depending on the effective traffic, and they are working with the largest hosts in order to ensure real world performance and stability when under heavy loads.
James Golick continues his series of “Plugins I’ve Known and Loved”, this time covering Ultrasphinx, a plugin for the uber-fast search daemon Sphinx.
Nicolas Sanguinetti wrote a script, that attempts to speed up the process of setting up an empty Rails project. I don’t find the procedure particularly boring so I don’t plan to use it, but it might be useful to some people.
Ruby
Peter Cooper, of Ruby Inside, has an article about two re-implemenations of the Ruby language. They are both named Sapphire, adding further to the confusion. The first one is a real fork, which was apparently born from the author’s dissatisfaction with the current management of the MRI, and the desire to have better support for Windows along, of course, with extra features like Aspect Oriented Programming, Unicode, etc, etc… The second one appears to be a new language, a stripped down and “stricter” version of Ruby that is supposed to be more Smalltalk-like and would be running, at least in the beginning, on the .NET platform. They are both worth mentioning, but currently I honestly fail to get excited about them. Ruby has an implementation problem, not a design one, in my opinion. However, we’ll see what they are able to deliver. In my book, a good implementation of a Ruby like language would be far from being frowned upon.
Remaining in the field of new implementations, InfoQ has an article about a neat new addition called HotRuby which is able to execute opcodes generated by the Ruby 1.9 VM (aka YARV). HotRuby is an incomplete and tiny (40 KB) implementation, faster than Ruby 1.9, that runs on JavaScript and Flash.
For those interested in Ruby and compilers, Vidar Hokstad has published the first two parts of a tutorial called “Writing a compiler in Ruby bottom up” (part 1 and part 2). Even if you are not into compilers, it’s a rather interesting read.
Sun reaffirmed their commitment to Ruby this week, by announcing the Ruby Development Center on the Sun Developer Network. I like Sun’s serious efforts and fast paced development of both JRuby and NetBeans (whose 6.1 beta is now out).
A new project hit the frontpage of programming.reddit.com: StrokeDB. Odd name, I know, but if you are interested in CouchDB, you may also take an in-depth look at StrokeDB. It’s a project that sounds rather promising if properly implemented. In their own words: “StrokeDB is an embeddable distributed document database written in Ruby. It is schema-free, it scales infinitely, it even tracks revisions and perfectly integrates with Ruby applications.”. The developers had a talk at EURUKO 2008, the European Ruby conference that took place this past weekend. Videos from the conference are not up yet, but meanwhile you can equally enjoy the videos and slides from MountainWest RubyConf 2008 on ConFreaks, which has published a talk by Evan Phoenix and Ezra Zygmuntowicz, respectively about Rubinius and Merb.
Finally, last week I spotted a bug that made Ruby 1.9 (built from trunk) significantly slower than Ruby 1.8. After a bit of investigation I was able to single out that the problem concerned Mac OS X only. With some testing by Chris Shea, the exact culprit revision was isolated and the core team has already worked on a fix. It was a very prompt and impressive response by Matz and his team.
RubyGems
Eric Hodel has announced the release of RubyGems 1.1.0. Aside from bugfixes and a couple of minor features, the most welcomed improvement is a significant speed boost that makes the tool faster. If you’d like to hear Eric talk about Rubygems and his involvement with the Ruby community, this week InfoQ published an interview with him (the interview itself is from RubyConf 2007 though).
This is my first episode of “This Week in Ruby” so feel free to provide feedback if you found it useful or if you have suggestions for improving it. Thank you for reading!
If you enjoyed this post, then make sure you subscribe to my RSS Feed.
Jay Fields has a nice post about the goodness of Enumerable#inject in Ruby. Like anyone who enjoys functional programming, I appreciate the concept behind inject and its possible usage. Your language may implement it with a method called inject, a function fold or reduce, but the concept is the same. I think that there is nothing inherently evil about using Enumerable#inject in your code, however one must be very careful and question whether there are simpler alternatives available. Abuse of creative usage of inject or cleverness is often paid for in terms of the readability of the code and can’t be discouraged enough. Another good reason not use inject is when performance counts and we are dealing with large datasets. In Ruby 1.8 in fact, inject is much slower than an equivalent solution implemented with the each iterator or other available methods. People will tell you that this doesn’t matter, but in the real world, having a method take twice as long because you opted for inject rather than each, is not always justifiable or acceptable.
For example, the following snippet benchmarks four different methods for summing the first n natural numbers. It benchmarks them for n = 10, 102, 103, 104, 105, 106, 107 and 108. Please note that the problem at hand can be solved arithmetically, like Gauss did when he was 10, but it will serve us well to test differences in the raw speed of the compared methods provided by Ruby.
The sum_with_while is admittedly ugly, and entirely not idiomatic. No Rubyist would write the method in that way. It’s there though, in order to have a non-iterator, loop-based solution which doesn’t rely on methods from the Enumerable class. It will give us some perspective. Also, the choice of reopening the Integer class, rather than writing methods that accept n as an argument, is entirely arbitrary and doesn’t affect the benchmark in any way.
These results are not surprising. The ugly sum_with_while method is just slightly faster than the sum_with_inject one, while sum_with_each and sum_with_times are significantly faster than sum_with_inject. For n sufficiently large, each is (linearly) about 1.5 times faster than inject. Again, nothing new, if you have done some number crunching with Ruby, you already know a few tricks and the fact that inject is notoriously slow.
Just out of curiosity, I decided to see how things have improved with Ruby 1.9. Here comes the surprise: ruby 1.9.0 (2008-03-21 revision 15825) [i686-darwin9.2.0] yields the following results.
Look carefully, the good news is that while has been sped up by a factor of 3. You may notice that the execution time of the methods which employ inject, each and times are essentially the same in Ruby 1.9. This could be considered good news too, if we didn’t take a look at the previous output. All three methods in Ruby 1.9 are 2 to 3 times slower than in Ruby 1.8. each and times were both faster than while and are now 10 times slower! Forget about inject for a second, which after all can be avoided; but idiomatic Ruby code uses each iterators all over the place. Am I missing something, or Houston, do we have a problem? This loss of performance, if confirmed, should be considered as a bug.
To expose the extent of this regression, let’s see how JRuby 1.1RC3 (with the -J-server option enabled) performs:
sum_with_while (the quickest one of the lot) in JRuby is 2.5 times faster than Ruby 1.9, or almost 8 times faster than Ruby 1.8. inject, each and times are 10 to 13 times faster in JRuby than 1.9.
Believe it or not, even Rubinius is faster than Ruby 1.9 (excluding while):
Upon further investigation, the issue has been confirmed on Mac OS X, but it doesn’t exist on Linux. From within a virtual machine running Ubuntu on my Mac, I got the following results:
Conclusion: the inject, each and times methods are much slower in Ruby 1.9 on Mac. As you can see from the comments, this seems to be caused by the fact that the function sigsetjmp() was introduced during revision 15124 and it happens to be much slower on Mac OS X than it is on Linux.
If you enjoyed this post, then make sure you subscribe to my RSS Feed.
You may have heard about Google launching their AJAX Language API. Translations on the fly via Javascript: sweet! Google Translate is not that bad, usually. It still messes up quite a few things in translation, but overall it’s still pretty acceptable.
Google uses statistical learning techniques, as opposed to a rule-based approach. From their FAQs:
Most state-of-the-art, commercial machine-translation systems in use today have been developed using a rule-based approach, and require a lot of work to define vocabularies and grammars.
Our system takes a different approach: we feed the computer billions of words of text, both monolingual text in the target language, and aligned text consisting of examples of human translations between the languages. We then apply statistical learning techniques to build a translation model. We’ve achieved very good results in research evaluations.
It’s a very hard problem to solve and the quality can be so-so at times. However, I’m going to unveil the most ridiculous bug I’ve ever encountered using this system. Do you notice anything strange in the following translation from German to English first, and from German to French second?
GERMAN: Output: 4 – 600 Ohm Made in Austria!! Funktionstüchtig! Die Kopfhörer haben einen Spitzen Sound der unverfälscht wieder gegeben wird!! Die Qualität der Kopfhörer ist einfach Spitze.
ENGLISH: Output: 4 - 600 ohms Made in USA! Funktionstüchtig! The headphones have a peak sound of the genuine will be given again! The quality of the headphones is simple tip.
FRENCH: Output: 4 - 600 Ohm Made in France! Fonctionne! Les casques ont un peu de son authentique sera à nouveau! La qualité des écouteurs est facile de pointe.
Clearly you should see an issue here. In case you don’t, I’ll be more explicit:
“Google Translate” sometimes changes the country mentioned within the source language to the main country of the translation language. That’s a pretty big bug they have right there. Certain terms should be translated verbatim using dictionary mapping, especially something as simple and hardcoded as countries.
While we are on the topic of Google bugs and anomalies, I’ll add a small oddity to the mix. I must prefix this part of my post by clarifying that I respect all ethnicities and colors and have good friends from all over the place. I am against racism, but not against discussions about racism. I won’t publish anyone’s racist or offensive comments, be warned. What this post does is merely point out Google Suggest’s selective behavior, which of course gets picked up by Firefox’s Google search box in the top corner, too.
Google suggestions are based on the number of queries received and the number of results for any given query. This means that entering words in Google Suggest will reveal the most likely queries starting with that given term(s). In Google’s own words:
Our algorithms use a wide range of information to predict the queries users are most likely to want to see.
For example, if I write “money is”, Google will suggest: “money is the root of all evil”, “money is debt”, “money is power”, money is everything” and so on.
I’m an Italian programmer, so I tried “programmers are” and got the hilarious suggestion that “programmers are lazy”. Alright, what about “Italians are”? Here are the results:
Some people are racist, that’s nothing new. These are stereotypes, for and against Italians, and this shouldn’t surprise anyone. And you can’t really blame Google either for what people have been typing in the most. Google is suggesting, automatically, based on the most popular queries. Okay, that’s for Italians. What about other nationalities? The most common stereotypes are all well represented. Americans, French, German, Spanish, Chinese, Indians, etc… What about “whites” in general?
Sad, I know. The picture doesn’t change too much if you are looking for “Christians are”, “Muslims are”, “Jews are”, “gays are”, “Cops are”, “men are”, “women are” and so on.
Google won’t suggest anything if the queries are not popular enough. This means that “Caucasians are” is not going to yield any suggestions, but “Caucasians” (alone) will. Google could do a couple of things: either blacklist the few dozen racial terms which are popular enough to show up in the suggestions, or simply decide that by policy, suggestions are automated and therefore, if you are looking for stupid queries based on race, you shouldn’t get offended by the suggestions that you receive back.
A few years ago there used to be very reprehensible suggestions against black people, as one would expect given the results for the other ethnicities and nationalities, and the racism that unfortunately still exists today. A while ago though, Google did something rather odd. They removed “blacks” from the list, possibly after receiving complaints, and left everyone else in the suggestion engine. If you search for “blacks are” you won’t find any suggestions. And I’m pretty sure it’s still as popular as it ever was, and just as queries containing “whites are”, “Greeks are” or “Christians are” are. On top of that, even if you just search for “blacks” the engine will not suggest anything. To further convince you, even if you were to search for an unusual term like “purples” you’d still get two suggestions: “purples 80s” and “purples wxsand”. If this exclusion was the right thing to do, then Google should do the same for other groups as well. If it wasn’t, then why favor only one group?
I don’t know if we should consider this a form of “selective racism”, but it’s odd and I thought I’d point it out even if the subject is very delicate and risky. If you think about it, it’s not even a racial problem, it’s more of a question of how to make software engineering decisions that properly and equally handle potentially offensive outcomes for some of your users.
If you enjoyed this post, then make sure you subscribe to my RSS Feed.
Django seems to have reached its tipping point, that critical mass which will enable its momentum to skyrocket. Getting here took a while though; partially because of a lack of hype and partially due to Rails’ very prominent presence in the market. Now this well deserving framework has finally begun to be widely adopted and considered as a valid alternative to Rails, for agile web development. Why do I care about what other people are going to use? I care because I’m deeply passionate about technology that works and that keeps things as simple as possible - as such forms of innovation always should. Independently from their adoption, promotion, and the differences in their approaches, both Django and Rails have at their core, a lot of substance and can greatly simplify and improve the way a web developer’s creative process flows.
Stating that Django has reached its tipping point is a bold claim, but I can present some evidence to back it up. I will use Rails and Ruby as a comparison for Django and Python - but don’t construe this as a race between the two frameworks. Rails is still the most popular and will probably continue to be for a long time. I’m only comparing the numbers to get an idea of where Django stands right now.
Visiting irc.freenode.net, I’ve noticed that the Python (#python) channel is often more populated than the Ruby one (#ruby-lang), and the same goes for Django (#django) and Ruby on Rails (#rubyonrails). For example, right now I see 517 members for Python and 354 for Ruby, 382 for Django and 298 for Rails. Django and Python consistently have more hackers in their chats than Rails and Ruby. This doesn’t say too much, given that the average developer doesn’t hang out on irc, but it’s still somewhat indicative of Django’s growing community.
Moving to newsgroups/Google Groups, things start to change a little. As I write this, there are 12,457 subscribers for comp.lang.python and only 6,935 for comp.lang.ruby (with 1,857 members in ruby-talk-google). “Django users” has 8,178 members versus the 13,355 of “Ruby on Rails: Talk”. So far this month, the Django group has had 1,244 messages versus the 2,890 of the Rails one. By looking at these numbers, without any pretense of being too scientific in our comparative methods, we get the impression that the Rails community is almost twice as big as the Django one, which sounds about right. On the other hand we also get that the Python community is larger than the Ruby one (confirmed also by the irc results above). In looking at these numbers, Rails also has the advantage of being the most used Ruby framework by far. In Python-land, Turbogears (3,303 members), Pylons (1,333 members) and good old Zope split the pie too, even though Django remains the most popular choice. Guido van Rossum’s blessing for Django was just the icing on the cake.
By observing the TIOBE Index, we see that Python is in 7th position versus the 10th position where we find Ruby. Perhaps more interestingly, Python has had a +0.70 delta since last March, while Ruby a -0.11%. Again, this is certainly not an exact science, my friends. TIOBE accuracy is often disputed for good reason, but I think it’s still an indicative factor.
Speaking of less than entirely reliable things, Alexa (django vs rails), Compete, and Google Trends (yes, rails is a very generic term) all confirm the anecdotal evidence that Rails is still far more popular. That said, the values start to be at least somewhat comparable.
5 books on Django announced to date and more lined up to be released this year, I’m sure. There are now many books in print that cover Rails (my recommendations here), but the sudden spur of Django books reminds me of Rails a couple of years ago and will surely help widen Django’s popularity. Watch closely because things will move fast in Django-land.
If you enjoyed this post, then make sure you subscribe to my RSS Feed.
because they left newcomers in a difficult spot. Developers who are experienced with Rails, will just get Obie’s 
and be fully covered, but those who are new and would like to get started with Rails don’t have many choices. They can get the Pragmatic Programmers’ Rails title mentioned above, but it’s a bit obsolete now and that means extra effort on their part to follow along, installing an old version of the framework, and then figuring out some way to move to the new features that were introduced by Rails 2.0 (soon to be Rails 2.1). As a matter of fact, when people ask me for a good Rails 2.0 introductory book for programmers, I can’t really name one. So far I’ve suggested getting Dave Thomas’ book or 
, and then moving to The Rails Way when they are ready to take it to the next level. But it’s not an ideal scenario at all.
. It covers Rails 2, and if well written, it may be that missing guide for newcomers to Rails and beginner programmers, that I was talking about.
and 
(available for free 
), with two further titles lined up: 
and 
(which I’m currently reviewing for Pearson, as it’s in the process of being written - and I must say, I think it’s going to be a very good one).
