Rails Underground

Charlie Nutter on JRuby

It's taking a while to go through all the excellent talk proposals and try to fit in as many as possible into the schedule. In the mean time, I had a quick chat with Charlie Nutter, who will be speaking at the conference. Charlie is co-lead on the JRuby project. [The JRuby homepage is undergoing a revamp over the next week or so. You can find other information on the wiki or the codehaus site.]

MC: Firstly, can you tell us a bit about yourself and your work?

CN: Well, about 5 years ago I went to my first Ruby conference, and liked the language so much I looked up JRuby. When I found that an old friend of mine, Tom Enebo, was leading the project, I started to contribute. At the time I was a "Java EE Architect" but in early 2006 Tom and I and other JRuby community members really started trying to make JRuby solid. Later that year Tom and I joined Sun Microsystems, and I have been working on JRuby ever since. Over the past couple years, I've also tried to be an advocate for JVM languages and Java/JVM improvements that would make language development easier. So I'm a JRuby co-lead on one hand and a JVM languages advocate on the other. It keeps me pretty busy.

MC: I didn't realise JRuby has been going for such a long time! I know its just marked 3 years or running rails, and the 1.3 release is imminent... can you tell us the latest JRuby news?

CN: Latest is subjective; we've had thousands of commits and hundreds of bugs fixed in just the past few months. A few months ago, we released JRuby 1.2, which included more bug fixes and improvements than the previous 3 releases combined. It was also the first JRuby release that started to be convincingly faster at running Rails than "Matz's Ruby Implementation" (MRI). A number of long-standing bugs were fixed, and both memory and performance were a lot better than the previous release.
This week, we've released hopefully the final RC for JRuby 1.3.0, which is mostly a bugfix release. JRuby 1.3.0RC1 was rushed out the door for RailsConf largely to release fixes for Google's AppEngine for Java, which works fine with JRuby. Since RC1, we've had enough additional fixes that it probably was more of a beta, but for RC2 we've actually branched and will release 1.3.0 final next week.
Perhaps the most interesting recent news is that JRuby adoption seems to be accelerating very quickly now. We're seeing job posts, big production site announcements, and I know of at least two announcements coming next week that will further boost JRuby's profile. And we're not standing still...this summer's work on JRuby 1.4 will have a new focus on improving performance (via an improved compiler and upcoming Java 7 features) and improving Java integration (bringing Ruby and Java object models closer together). Expect to hear more about that soon.

MC: Do you find there is a common use for JRuby? Why do developers typically decide to use it?

CN: The majority of JRuby adoption is from Java-based organizations that want to start using Ruby or Rails internally. It's generally too great a political struggle to get MRI introduced into any large existing production setup, and if JRuby supports all the Ruby libraries and code you want to run, you don't have to fight that battle. We hear from banks, telecom, financials, governments, and others that are running sites on JRuby, and every conference we go to we learn about another half-dozen we didn't know about before.
There's also a growing number of folks using JRuby to get better X, where X may be performance, available libraries, memory utilization, multi-core scaling, and so on. While we've always focused on being a compatible Ruby implementation first, we've also tried to give people solid performance, real parallel threads, and access to everything the JVM has to offer. Many people are starting to recognize that and move to JRuby.

MC: "Being a compatible Ruby implementation" must be a bit of a challenge - defining what Ruby is can be quite hard - If you define it as "Whatever Matz says it is", it can still depend on the point release and sometimes the patch level... Can you tell us a bit about RubySpec and how it fits in with your work?

CN: Ruby is, as you probably know, a language without a formal specification. That means we have generally had to cobble together a test kit over the years in order to know whether we're "compatible". Early on, that meant pulling in Rubicon, a set of test cases Dave Thomas wrote when working on the Pickaxe books. Over the years, we've also pulled in MRI's test suite (which is surprisingly small), a test suite called "ruby_test" written by Daniel Berger, a small suite called "BFTS" written by Ryan Davis and Eric Hodel, and finally RubySpec, which I'll come back to. We've also accumulated a very large corpus of our own test cases. JRuby now runs far more tests than any other Ruby implementation, even if you assume there's a lot of duplication.
RubySpec is a project started by the Rubinius team a couple years ago. It's basically an rspec-like set of acceptance tests/specs (I won't debate nomenclature) for all of the Ruby language, core classes, and standard library. It's not complete, but it is of a comparable size to all the other suites we run against JRuby, and much cleaner. Because RubySpec started somewhat after JRuby had surmounted the biggest compatibility hurdles (like running Rails), it has been mostly an additional tool for us to keep improving compatibility. But we fully support and appreciate RubySpec and try to contribute new tests and specs as often as possible.

MC: Another metric you spend a lot of time on is performance and benchmarking. There are many different comparisons of various Ruby implementations (some of which are still 'works in progress'). How would you say JRuby performs compared to other implementations?

CN: We haven't spent as much time on performance as a lot of implementations (especially some newer ones) but I'd say JRuby is at least on par with Ruby 1.9 for running Rails and faster for many smaller tasks. Part of the problem of measuring performance is that it varies so much from application to application. We still get reports of people with Rails apps significantly slower than on MRI while at the same time others report their apps are many times faster. There's no reliable benchmarking suite available for Ruby yet, so we usually have to guess at what the problem might be.
However I will say this: we consider poor performance in JRuby to be a bug...not because we're cocky, but because in almost every case of poor performance it has been something we were doing wrong. So if we can isolate the problem down to a specific piece of code or a specific method, we can usually fix it and often exceed Ruby 1.9 performance at the same time.
Another complex aspect of performance measurement is that most applications depend on code not measured by the microbenchmarks people usually publish. For example, JRuby has scored better on Antonio Cangiano's "shootout" for well over a year, and yet just recently started running Rails faster. Why? Because Rails is not limited by Ruby execution performance as much as by the performance of the core classes. It's easy to get Ruby code to run fast on a given impl, especially early on. But getting all the core classes to perform better is a very slow process, and any one class or method can cripple an entire application.

MC: One last question! If anyone out there wants to help contribute to JRuby, what would you recommend?

CN: We love contributors, and so does our community! The quickest way to get started would be to visit jruby.org, which has links to downloads, howtos, mailing lists, IRC, bug trackers, and articles about JRuby. Installing JRuby is simple: provided you have a Java version installed (1.5 or higher), you just unpack JRuby and it's ready to go. And if you want to help fix bugs, or find a bug you'd like to report, it's easy to check out JRuby from github and build it. All this is detailed in articles on jruby.org, or you can contact us directly via email, mailing lists, or IRC.

MC: Brilliant! Thanks very much for taking time out to chat, it was a real pleasure; and I'll be looking out for those announcements next week!

CN: excellent, thank you!

Yehuda Katz on Rails 3 and beyond

While I have your attention, I have a few bits of information! :)  I'd like to thank everyone who has submitted a talk proposal for the conference - it's going to be a real challenge to pare down the selection to the ones that we can fit in.  I'll be trying to sort this out over the next week or two, so please bear with me if you are waiting!
A couple of people have asked me very nicely if it is too late to submit a proposal. If you want to try, please do, spots might become available depending on speaker circumstances, etc.

But, enough of that for now, here is the latest chat with one of our conference speakers: Yehuda Katz, member of the core teams for Rails and jQuery, lead developer of the Merb project, core contributor to DataMapper contributor to Rubinius and Johnson, creator of Thor, Moneta.....:

MC: Firstly, Many thanks for taking the time to chat! I know you're very busy. Could you tell us a bit about yourself, and what you are spending your time on at the moment? 

YK: Sure. My main focus at the moment is continuing work on Rails 3. At the moment, that involves significant refactoring of ActionController and ActionView. We've made significant progress, and are already seeing architectural benefits from the improvements. In my spare time, I'm currently working on Moneta (a key/value store abstraction) and improving Rubygems (with better gem resolution, lower start-up costs, and bundling). I also have been sinking some time into JRuby, which is proving to be a very stable, fast and reasonably agile alternative Ruby implementation.

MC: Rails 3 is generating a lot of excitement. What changes do you think will make the biggest difference to developers?

YK: For power users and plugin developers, the internals of Rails have become significantly improved, and it's now possible to make many more kinds of changes to Rails without invasive monkey-patching or real patching. This includes things like overriding the controller's rendering system, swapping out template backends, and having configuration options scoped to an application instance rather than globally.
For application developers, we will be able to leverage those architectural improvements to create interesting features. This includes improving engines, bringing ActionMailer in line with ActionController, a new Queue system baked into Rails, more flexible and powerful routing, and easier integration with the world of Rack components.

MC: So, there are many changes that will allow functionality and applications to be plug-able. Do you think the focus of rails development will shift from the core to the efforts of the wider community?

YK: There will be two parallel results. First, the Rails core will focus more effort on making sure that the core of Rails both remains an excellent set of defaults for users building web apps *and* becomes a viable backbone for other kinds of interesting work. This requires intense work in the core of Rails itself, and will need to continue even after Rails 3 is shipped as we move forward. Second, I personally anticipate more community activity around leveraging those new capabilities. So it's not so much a focus shift from Rails to the community as it is a renaissance of efforts on both fronts.

MC: I was going to ask specifically about what is in store for rails after 3.0... There seems to be a hint there that you may be looking at rails in a broader context than just web apps?

YK: Rails is certainly going to become potentially more useful in the context of all HTTP applications (not just HTML), but I don't see it moving outside the realm of HTTP at all. The great thing about Ruby is that it's very easy to make code interoperate; for instance, Sinatra is excellent for taking an existing Ruby project and exposing it to the web. I think it makes sense for Ruby projects to be as good as possible in their own spaces without trying to become too generic.

MC: So have you got any other clues about the sort of changes that might be in store after rails 3? How is the development timeline decided upon, and what sort of timescales into the future does the core team look into?

YK: It's hard to say at this point, but what should be clear is that Rails 3 is just the first fruits of the reinvigorated work on the core of Rails. We have four very exciting Google Summer of Code projects, some of which might make it into a 3.x version of Rails (although I hope they all make it into Rails 3). My personal expectation is that Rails 3.x will be driven, as usual, by the needs of the community, which will now be somewhat focused around the new integration points we make available starting with Rails 3.
In terms of timeline, we're trying to release as soon as possible, without waiting for a mythical perfect release, but we definitely need to get the integration points stable to deliver on the promise of a stable plugin API.

MC: Thanks, I'm really looking forward to trying out the new features... One thing I'm really excited about is the stuff you talked about in the 'Russian Doll' talk... I've only managed to see the slides so far, though. This idea of plug-able applications looks like it could bring some huge benefits to developers.

YK: The Russian Doll stuff is really interesting, because the work that needs to go into Rails is really separate from the end feature we want to enable. In Rails, we need to add stuff like allowing multiple Rails applications in one process (via an application object), improve the system for pulling out templates off the file system or other locations, improved bootloader process, and a more robust and powerful router. Those features are pretty much unrelated to the idea of mountable applications, but will enable interested members of the Rails Core team and members of the community to build a working, standard system on top.

MC: You had some slides in that talk referencing Django... I think we have just enough time for one last question...What do you think rails can learn from other app frameworks like Django, and do you think the rails community is engaged enough with the wider community & 'the enterprise'? (I'm thinking of the message of Bob Martin's RailsConf keynote)

YK: The most interesting thing in Django is their embrace of multiple applications, as well as their built-in administrative "application". On the other hand, their grudging, slow support of WSGI (the inspiration for Ruby's Rack) is something Rails must be sure not to do. Thankfully, Rails' participation in the larger Rack community has been inspiring and transformative.
In terms of the enterprise, I certainly think this is something we need to do, but it will likely need to be driven by companies with some skin in the game. Bootstrapping that process is difficult when so many community members are refugees from that world, but I definitely anticipate efforts to engage the enterprise in a discussion about the benefits of Ruby coming from various avenues. I only hope that those efforts really sell the power of Ruby, and try to avoid encouraging people to write Java or .Net with Ruby syntax. There's much to be gained from fully embracing Ruby as a language, with its idioms and libraries.

MC: We're out of time! That was great - lots of food for thought there Thanks very much for taking time out to chat!

YK: No problem. It was great chatting with you.

There are a few more interviews planned, and you can find previous talks with Geoffrey Grosenbach, Maik Schmidt, and Dr Nic in the interviews section.

E-mail Typo

I added a couple of e-mail links to a few pages earlier, but introduced a typo. The correct e-mail address is , repleat with the correct number of R's! Sorry about that! (And thanks to the several people who pointed it out so quickly!

Short Update

The deadline for speaker applications is approaching! There have already been some superb proposals put forward, but room for one or two more.       

As well as a great selection if speakers and topics, I'm hoping that it will be a great opportunity to meet up with people from far and wide. So far, the furthest delegate is travelling 3,500 (5,600km) miles, and the furthest speaker is travelling over 10,000! I'm sure there will be plenty of opportunity to meet people, and I'm hoping to include some information about Railsbridge and other community projects during the conference and/or at a to-be-arranged event the day before.

We're still looking for sponsors too, so if you think you can help out, please get in touch!

Talking to Maik Schmidt: Enterprise Rails

Time for another interview with one of our speakers: Developer and author Maik Schmidt. For more, see the Interviews section. If you are interested in speaking yourself, please check out the speaker applications page for more details.

MC: First thing: Thanks very much for taking the time to chat!

MS: You're very welcome!

MC: Can you tell us a bit about yourself, and your experiences with ruby?

MS: I am 36 years old and I live in the west of Germany.
I've worked as a software developer for more than 16 years now and I've mainly worked for big companies, that is I have created lots of big enterprise applications using Java and C++. In 2000 I have bought the first edition of the Pickaxe and I've liked Ruby from the beginning. Since then I've started to sneak it into as many projects as I could and in the last years I have written more code for the Ruby platform than for the Java platform, for example.
I have used Ruby not only for creating web applications with Rails but also for standalone enterprise applications.

MC: You've also written two books on Ruby and Rails in the Enterprise, right? And I think you have a third one on the way?

MS: That's right. I am the author of "Enterprise Integration with Ruby" and "Enterprise Recipes with Ruby and Rails" (published by The Pragmatic Bookshelf). Both titles contain the essence of all the things I have learned during the last years and I've written them for people like me, that is for software developers that want use Ruby (and Rails) in typical enterprise environments. For example, they explain how to process large XML documents effectively or how to participate in asynchronous messaging systems.
A third one is on the way and I cannot say too much about it (contract signing is still in process), but it will be no Ruby book. After writing two Ruby books I wanted to do something completely different. Not because I do not like Ruby any longer (quite the opposite), but because I wanted to learn something new.

MC: Intriguing... OK, so let's talk about Rails and the Enterprise: When you talk about developing in the Enterprise, what do you mean? What would you say defines an enterprise environment? 

MS: The best definition I have is from Martin Fowler: "Enterprise applications are about the display, manipulation, and storage of large amounts of often complex data and the support or automation of business processes with that data."
So, first of all, enterprise applications usually have to process large amounts of data, which can be a problem by itself. But for me the biggest challenges have always been on the organisational side, that is clarifying requirements with many different departments and integrating with countless existing systems, servers, and databases. Ruby is not a perfect candidate when it comes to processing large amounts of data, because the current platforms are all relatively slow compared to other platforms. But Ruby really shines when you have to glue together existing applications or when you have to create small domain specific languages to describe fairly complicated business processes in the most elegant way. And when it comes to developing web applications that use your existing back-end infrastructure Rails is a powerful ally. 

MC: And presumably dealing with a heterogeneous system is a factor too - lots of different file systems, databases, interfaces, environments, etc.? 

MS: Absolutely! I've often found surprisingly simple solutions to seemingly complicated integration problems, because Ruby really is sufficiently platform-independent. There are still some minor quirks on the Windows platform, but when you live in the Unix world everything is really fine.
Hiding most legacy stuff - no matter how heterogeneous your environment is - can often be solved by simply creating new services (preferably REST services, of course). As the saying goes: "There's no problem that cannot be solved by introducing another layer of indirection"
The same is true for databases. It's really surprising how many problems can be solved with a solution as simple as ActiveRecord (its API is simple, that is).

MC: So, I don't know if you saw the Core Team Q&A at RailsConf last week... One of the questions was "Will Rails 3.0 be Enterprise-ready?" Koz said "No," I think it was Jeremy Kemper that said "It already is," and Yehuda said it was a contentious issue... Having already had a lot of experience of using Rails within an enterprise environment, how would you answer the question?

MS: It heavily depends on the task you have to solve. In most regards Ruby is Enterprise-ready and I have proved it several times by deploying applications in really big enterprise environments. Currently, I am working on a product for Vodafone (http://widget.vodafone.com) that is already available in several countries.
But there are still many areas that need improvement before Ruby and Rails are enterprise-ready in general. For example, Ruby needs a better runtime environment, but I am fairly sure that JRuby will fill this gap shortly. Rails needs much better support for internationalisation (this has been the biggest problem in my current project) and a slightly better release management.

MC: Yes, I guess JRuby goes a long way to giving Rails projects an entry point into the usually tightly locked-down and subject-to-slow-approval-processes application environments within the enterprise... Has the recent rails i18n work helped?

MS: We started developing the application when i18n has not been a part of Rails (before the 2.0 release), so we have used good old gettext. We could integrate gettext and its tools into our whole development process without any problems. Tool support is a very critical issue when you develop large applications in an international environments. Right now we support English (UK, Ireland, South Africa), German, Dutch, Greek, Italian, Spanish, and Portuguese locales and all translations are provided by employees of local Vodafone companies. Of course, none of the translators is a software developer and so they need intuitive tools for writing the translations. gettext is absolutely mature and we never had any problems with it.
Of course, rails-gettext was not perfect (for example, it's not possible to translate ActiveRecord's validation messages as flexible as we need to), but we could solve nearly all our problems with monkey patching. When we started to migrate our application to a more recent Rails version, of course, we had a look at its new i18n features. Unfortunately, they did not solve the problems we already had with gettext and it even made some things worse, especially on the organisational side of things. As I said before: tool support is critical when you have to support multiple locales.

MC: That's food for thought... and gosh, I'm taking up all your evening! Thanks very much for the chat I look forward to continuing it at the conference!

MS: Thank you! I am looking forward to seeing you at Rails-Underground!

Handy resources for people new to Rails

I have a couple of updates planned for this week, stay tuned! In the mean time, I've been speaking to a bunch of people fairly new to rails, so I thought I'd point out a couple of great places to visit if you are new to rails and are looking for some good places to start. (There are, of course, plenty more, but you have to draw the line somewhere) :-

Great Pod/Screencasts

1. Railscasts. Ryan Bates gives realy excellent screencasts covering many rails topics. These really are very good :) Eifion Bedford has converted many of these into a text version.
2. Rails Envy. A useful round-up of weekly ruby and rails news, and you can find lots of good links in the show notes.
3. Ruby on Rails Podcast. Great interviews and chats with ruby luminaries and entrepreneurs.
4. Rubyology. Code Monkey, Chris Matthieu has been hosting this podcast for a long while now, and there have recently been some great round table discussions worth listening to too.

Handy Information Resources

1. RailsGuides - great resource for learning rails.
2. Stack Overflow - helpful programming Q&A community site.
3. Rails Tips, "One man, feverishly posting everything he learns."
4. Ruby Inside and Rails Inside - all the ruby and rails news that's fit to print.

Community Links

1. If you live or work around London, the London Ruby User Group has regular evening events and lots of interesting chat. Further afield in the UK is the North West RUG and the Scottish RUG. [Update: And Leeds Ruby Thing!] Further still, try looking on the meetup site.
2. Rails Activists - The 'official' group, working to empower rails users, and working on projects to improve the rails platform.
3. Railsbridge Another community of rails developers hoping to strengthen and broaden the rails community through various projects and activities. 
4. I started compiling a list of other regional conferences that people may be interested in, but soon found a great list.
5. Rails on IRC
6. The Ruby Forum also containing several others), and the Rails Forum are both good places to chat & ask questions.

There has been a lot of debate over the past few weeks about the Rails community, how to make it more inclusive and welcoming, and how people can help out.
Railsbridge just got going a few days ago but is a great example of how many people there are within the rails community with a great enthusiasm to help. Already in the works are mentoring programs, kids educational activities, courseware and workshops.

I'm hoping to find out more about these sorts of efforts, and include activities during the conference that will help people find ways to get involved. If you have any suggestions, please .
Any glaring omissions? Leave a comment! [Update:

Speaker Proposals Deadline approaching!

There's more to come this week, but here is a quick reminder that the deadline for speaker proposals is 18th May - Next Monday! Many thanks for the excellent proposals that have already been submitted :)