FiveRuns Blog

Welcome to this week’s Rails TakeFive interview, our ongoing interview series featuring insight and commentary from notable members of the Ruby and Rails community. This week, we’re happy to be joined by Reuven Lerner, noted developer, Web/database consultant, author, and writer at GigaOm’s Ostatic open source blog.

FiveRuns: Welcome Reuven! Let’s get started by talking a bit about Rails 2.1. What about the new release excites you the most? Gem dependencies? UTC migrations? Better caching? And as a follow-up, what are the most important things in your mind to get done for the next major release?

Reuven Lerner: I must say, I’ve been very impressed with the Rails 2.1 release. I had read through a number of blog posts describing new features before the release itself, so I wasn’t that surprised to see what was in there.

But there’s a difference between reading about the new features and using them, and I’ve generally been quite impressed with the additions. Some of the features that you mentioned are quite useful. For example, I really like the gem dependencies, and have used them to help me when installing an application on a new server. UTC migrations seem like such an obvious feature in retrospect, but I guess it took a while for the community to realize what might happen when you have more than one developer hacking on the database.

Hands down, though, my favorite new feature in 2.1 is the improved caching support, and particularly the integrated support for memcached. I had been using memcached with Rails 2.0, and it worked well — but only after I spent many hours reading through the documentation for various versions of cache_fu, acts_as_cached, and memcached-client. My favorite part of the caching support is the “cache” method, which looks in the cache for a particular piece of data. If the data isn’t already in the cache, you can provide a block that tells Rails what database query to use to get the data; that value is then stored in the cache for the next time around. This feature should make it a no-brainer for everyone to use memcached in their applications.

What would I like to see in the next version?

First of all, I’d like to see even better integration of memcached. The “cache” function is, as I wrote above, useful and powerful. But while I find the syntax to be logical, it’s also a bit ugly. I’ve been thinking that it might be easier to integrate the memcached support into ActiveRecord, such that I can do a Foo.find(:cache…), with the :cache symbol indicating that I want to retrieve the value from the cache if possible. Most of my uses of memcached are with the database, and I’m going to assume that this is true for others, as well. The one fly in the ointment with memcached support is the weird restriction that memcached imposes on keys: They may not contain spaces. One of my main uses for memcached is to cache parameter values that have been set by a site administrator. Because the parameter name is simply a text field in the database, it can include spaces. (I find that this greatly improves usability for my non-technical clients.) I managed to get around this problem by monkeypatching the String class, adding a String#to_mkey method that replaces space characters with underscores. I would think that memcached could perform this search-and-replace operation on its own — but if it can’t or won’t, then I would like to see Rails take care of it. Another weird problem with memcached is that you sometimes need to invoke “require_dependency” if you’re unmarshalling cached objects. This seems to be a well-known problem in the Rails community, and so I was able to find and solve the problem in relatively short time. But I shouldn’t encounter such weird problems at all, and I’d like to think that Rails is smart enough to deal with this automatically.

I would also like to see better support in migrations for foreign keys and other constraints that PostgreSQL groupies like myself take for granted. It’s nice to say that you can execute raw SQL commands from within migrations, but it always seems like cheating when I have to go outside of a DSL.

Finally — and I know that I’m beating a dead horse here — I would really like to see some built-in support for users, roles, and permissions in future versions of Rails. I realize that there are many in the Rails community, including the core team, who argue that by leaving out such functionality, it lets everyone implement users and groups in a way that’s effective for their needs. But I find this to be a fairly unconvincing argument: Nearly every application needs to deal with users and groups in some way, and it would be a tremendous relief to have it built in. Even if Rails doesn’t include actual functionality for users, groups, and roles, perhaps it could include a standard API for working with plugins that handle this functionality.

That is, Rails itself wouldn’t come with a user-role-group system. But it would have a standard plugin interface that would allow a variety of different authentication schemes to connect to it. And this standard interface would also allow developers to write to a common API. Rails loves to describe itself as “convention over configuration,” but for anyone who has to deal with user registration and authentication, there’s a heckuva lot more configuration than convention.

FiveRuns: Bruce likes to talk about “backpacking” through other languages. What others have you dabbled in and/or are you learning right now? How have these travels impacted your work in Ruby? Your overall approach?

Reuven Lerner: I’ve worked with many different languages over the years, and my feet are firmly in the high-level language (known to some as “scripting languages”) camp. I could work in C or C++, but I’ll do almost anything I can to avoid such work — and I’ve successfully done it for more than 10 years, so I’m pretty happy.

For a long time, Perl was my default language. I wrote lots of code in Perl, wrote columns about Perl, spoke at Perl conferences, and even wrote a book about Perl called Core Perl, which was published by Prentice Hall back in 2000. I disliked the Perl inclination for clever, terse code, particularly when it came at the expense of readability. My Perl code was pretty readable, and CPAN meant that you could jump in and start to write an application immediately.

As time went on, though, I began to sour a bit on Perl. First of all, I really wanted “real” objects. And while the Perl object model is good enough for many things, it’s not nearly as completely integrated as Ruby’s objects. Secondly, I feel like Perl 6 is going in a direction that I don’t really like — not that it matters, given that Perl 6 is taking a heckuva long time to develop. It’s always possible that I’ll work in Perl 6 at some point, but I am really wondering who is going to use Perl 6 outside of the small community of Perl 6 developers. Then again, I was skeptical that Perl 5 would catch on, so perhaps I’m wrong on this front, too. I also became increasingly frustrated with Perl’s hazy typing system, in which numbers become strings and vice-versa. For many years, I thought that this was a feature. But I’ve come around on this, increasingly liking the strict typing that Ruby and Python demand. Indeed, I think that Ruby and Python do the right thing: Variables don’t have to be declared, and can contain any value you want. The value has as type, though, and that type won’t change. I don’t think that Perl is going to change anytime soon on this front, a we can see from the recent “smart match” operator, which really gives men pause.

I actually spent a year or two doing a lot of work in Python, convinced that I would switch much of my work to that language. I did a big project in Python, and I decided that while I like Python quite a bit, it’s a bit too formal and stilted for my taste. If I hadn’t discovered Rails, I’m guessing that I would be a Django developer.

But as it happens, I discovered the one-two punch of Ruby and Rails, and immediately felt like I had come home. I think that the Ruby community has swung the object-oriented pendulum a bit too far, with too much emphasis on metaprogramming. But the language, attitude, and community are more in tune with my development interests and style than Perl. Indeed, the syntax of Ruby is enough like Perl for me to be able to write many things automatically, something that I can’t say for Python.

This might come as a surprise, but I have also been doing a growing amount of PHP work in the last few months. (Yes, I would love to work exclusively in Rails. But being an independent consultant doesn’t always guarantee you the freedom that you might imagine!) I have always pooh-poohed PHP, and I still think that there are a number of serious problems with the language. PHP is growing up, and has learned from at least some of its mistakes. I wouldn’t say that its object model is as powerful as Ruby’s, and there is still a long way to go. But it is now possible to write PHP code that can be taken seriously. Moreover, the PHP community has managed to make the language execute quickly in a minimum of RAM, something that I know the Ruby community is working hard to attain. Working with PHP has given me a greater appreciation for Ruby — but it’s not nearly as bad as what you might think, and it’s even possible to create useful and interesting applications with PHP.

Like all Web developers, I’ve been reading and working a great deal with JavaScript in the last year or two, more than I ever imagined would be possible. I was never a big fan of JavaScript, and I still think that functions within functions within functions can get a bit hard to read, as well as tiring to write. But libraries like Prototype have made JavaScript not only palatable, but fun to work with, allowing me to ignore most browser dependencies. The browsers have also improved their support for JavaScript — increasing execution speed, improving standards compliance, and just making the language more stable.

Even if I could ignore JavaScript nowadays, I’m increasingly inclined to say that I wouldn’t want to. I never really imagined myself as a client-side or GUI programmer, but JavaScript is making all of us do client-side work in some way or another, and I don’t think that this a bad thing.

Finally, I’ll mention a language that most readers have probably never heard of: NetLogo. I’m biased, since NetLogo is developed by the research group at Northwestern University where I’m working on a PhD in learning sciences. And it’s not meant to be a general-purpose programming language, although it is Turing-complete, and you can do all sorts of neat things with it. No, NetLogo is a modeling language, meaning that you are expected to use it to create computerized simulations — typically of scientific, mathematical, or social phenomena. NetLogo’s programming model has a distributed feel, even though it’s not distributed; you create various types of “turtles” on the screen that represent different types of agents, and then tell the turtles how they should move and otherwise interact with one another. It’s a very different type of programming than anything else I’ve ever done, and the models library that comes with NetLogo is itself highly instructive and interesting, offering hours (or even years!) of discoveries.

FiveRuns: We’ve blogged a little bit about this recently, but do you have any experience that you can share playing around with Phusion Passenger?

Reuven Lerner: I downloaded and began to use Phusion Passenger several weeks ago, and I’m extremely impressed and pleased. I’m using it on an application that’s about to go live, and while I can’t tell you whether it’s really faster than lighttpd or Mongrel, it just feels comfortable and nice to be back in the Apache world. I’ve been using Apache since before it was released, and the last few years of working outside of Apache have been interesting, but also frustrating. The fact that I can now use Apache on my server, and configure it in the “usual” way is not only comforting, but also helps me to organize my server under a single configuration directory (for Apache), rather than multiple directories and software configuration files, each of which is responsible for a set of ports on my server. I don’t know if I’m the best person to speak about “best practices” for deployments. I feel like I’ve come full circle in the last few years; I spent several years working with Time Warner’s Web sites, where we had very established development, staging, and production servers. That disappeared from my life for a few years, as I either worked on internal projects that didn’t have different servers, or with small organizations that couldn’t or didn’t set them up.

The fact that Rails has built-in support for development and production servers, and even lets me configure the environment differently for each environment, has been a dream come true. And Capistrano has certainly been a huge help on this front, allowing me to deploy to multiple servers with little or no effort. But as for a true best practice? Well, aside from develop-test-deploy, I’m not really sure if there’s a better way to go about things. The tools could be a bit smoother, and perhaps Capistrano could warn me if I’m trying to deploy something that doesn’t pass all of my tests. But I think that for most of my needs, the tools do the right thing at the right time, allowing me to focus my attention on application development, rather than the ugly and annoying aspects of deployment.

FiveRuns: On that note, let’s talk about Merb. They are all about being agnostic – ORM agnostic, JavaScript library agnostic, and template language agnostic – what does this mean to you?

Reuven Lerner: I’m not really that familiar with Merb, other than downloading it, playing with it a tiny bit, and reading about it. The premise is an interesting one, offering developers a toolkit with which they can create their own Web framework, rather than a complete and ready-to-go framework. In some ways, it seems to me that just XML is a language that can be used to create markup languages, Merb is a framework that can be used to create frameworks.

In some ways, this is a highly attractive option: While I like Prototype and script.aculo.us quite a bit, I have sometimes wanted to work with YUI or Dojo, either because they had some useful widgets or just on a lark. Using a non-Prototype JavaScript framework with Rails is theoretically possible, but I don’t think that it’s really practical. Merb, by contrast, seems to really encourage such experimentation.

I’m also a bit fascinated by the idea of using a different relational-object mappers. I happen to like ActiveRecord, but I recognize very well that it’s slow, and that another mapper might work better for my purposes. I’ve been using SQL for a long time, and it’s still sometimes easier for me to express my ideas in raw SQL. And yes, ActiveRecord lets me do that with find_by_sql, but it’s just not the same. I thus see Merb as a “what if?” sort of framework—a kind of edge-edge Rails, allowing us to explore alternatives without being constrained by the decisions that were already made by the Rails core team.

Merb might grow to be popular for actual application development, but I have to wonder if its impact will really be felt by developers, who will be able to compare different pieces of functionality in ways that would be unthinkable with Rails.

Finally: One of the reasons why I so enjoy working with Rails is the fact that it comes with almost everything I need to start working, right out of the box. If I need something, then it’s often (usually) available as a gem or a plugin. I have so much to do that I’m willing to give up a bit of speed if it means greater convenience and time hacking. So I don’t see myself as the ideal audience for Merb.

However, I do think that the people who are developing Rails, and thinking about what should be included in version 2.5, and even version 3.0, should be playing with Merb a great deal, using it to find the best ideas and practices so that the mainstream Rails community can take advantage of what they find.

FiveRuns: Obie Fernandez’s startup Hashrocket, which has been blogged about extensively, is all about being ultra-productive in 3 days. What are your own tips around, to paraphrase Obie and 37Signals, getting real—on steroids?

Reuven Lerner: Oh, how I wish that I could really give advice on how to be hugely productive! People seem to think that I accomplish a lot, and I guess that this is sort of true. (For those who don’t know, I’m the father of three young children, a full-time Web/database consultant and trainer, and a PhD student at Northwestern University. As if that weren’t enough, I’ve been working on an e-learning startup over the last year or so.)

So if I have any “secret” to share about my productivity, it’s a combination of doing things that I do quickly and well (i.e., programming and writing), and sleeping very little at night. I started to sleep very little back when I was in college, editing the student newspaper at MIT. Except for a few years of 9-to-5 work, I’ve been pushing my limits ever since.

But enough about me. What can I suggest that people do to become more productive, or even “ultra-productive”?

I think that the key is to be good at learning new things, and at synthesizing those ideas into an established practice. A lot of classic learning studies have shown that experts — that is, people who have done a task, or seen a problem, hundreds of times — can understand, describe, and solve the problem more quickly and accurately than novices. So in many ways, you can become ultra-productive by seeing the same sorts of problems, again and again. When I first speak with a consulting client, it’s not unusual for me to say, “Ah, I’ve done this many times before.”

The thing is that Web development means learning new skills all of the time. If you’re just going to try to become really good at one set of skills, or at solving one set of problems, then you’ll soon find that the world passes you by. The key to being a good developer is to constantly be improving your skills, learning new languages, frameworks, and techniques and then fitting those into your established work habits.

A key element of being ultra-productive is thus getting really good (and really fast) at learning new technologies, and assimilating them into what you already do. It’s not at all unusual for me to learn about a new technique on a Monday, try it on a Wednesday, and find myself mentioning it to a client on a Friday.

Being able to turn on a dime like that has been extremely helpful in my work, and makes me (I think) a better consultant, as well as a better programmer. How do you become good at learning new technologies? Like any other skill, it’s something that you need to practice a lot. The Pragmatic Programmers say that you should learn a new programming language every year, to keep yourself thinking in new ways. I don’t know if I’d go quite as far as that, but I do agree that you should constantly be challenging yourself to learn new programming techniques, libraries (gems), and other ideas. After a while, you’ll get to the stage in which you can read about a new technique and know how to integrate it not just into a generic program, but into your actual work. But in order to get to that point, you need to read and learn a lot. I read a lot of books and blogs; my kids know that I’m never without a book in my hand, or 2-3 in my backpack (in case I get stuck somewhere).

If you work hard at learning new things, then each new nugget that you learn becomes that much easier for you to integrate, which makes you a more productive person, as well as a more interesting and well-rounded one.

Reuven M. Lerner has been an independent Web/database consultant for 13 years, offering development and training services to companies in North America, Europe, and Israel. For more than three years, his platform of choice has been Ruby on Rails with PostgreSQL, although he uses other languages and technologies as necessary.

He co-founded one of the first 100 Web sites in the world, has written the monthly Web/database developer column “At the Forge” in Linux Journal since 1996, and wrote Core Perl for Prentice-Hall back in 2000. He currently writes for GigaOm’s Ostatic open source blog.

Reuven lives in Modi’in, Israel (halfway between Jerusalem and Tel Aviv) with his wife and three children. He is also a PhD candidate in learning sciences at Northwestern University, creating a collaborative online learning community for authors and users of computer-based simulations.

When not hacking, writing, teaching, or playing with his children, Reuven enjoys making ice cream, walking, and reading.