By complete coincidence, this year I had the chance to appear on 3 podcast channels. I want to thank Paulo Silveira, Charles Max Wood, Lucas Caton, Fellipe Azambuja, and Ramon Sanches.

The first one actually came out late last year, in November, on Ruby Rogues with the topic “Ruby Conf Brazil and Building Communities” where Charles Wood and I talked a bit about the history of the Ruby community in Brazil — how I tried to get it started, what I attempted, the blog, talks, events. We also covered more specific points like a small overview of the Ruby language and my view on not limiting yourself to a single language or technology. If you’re new to the Ruby community, it might help give you an idea of how we got to where we are today.

The second one came out in February, on Paulo Silveira’s podcast Hipsters Ponto Tech, and the topic was “Carreira em Tecnologia”. The legendary Guilherme Silveira and Sérgio Lopes joined in, and in that conversation we touched on the main aspects for anyone starting a programming career. Take a look at the comments too, since several other points of view, opinions, and tips came in from listeners. Fun fact: this one was a bit of work because we recorded an earlier version, but since Paulo was still in the early days of the podcast, he refined the process and asked us to re-record the one that ended up being released. The format and topics changed a bit to be more focused, which made the conversation better. Some of the topics I covered in the first attempt I ended up revisiting in the podcasts later in this list.

The third came out in mid-May at the invitation of Lucas Caton, who introduced me to Montanha and Ramon from the podcast Dev na Estrada, and the topic was “Vale a pena? Ruby on Rails com Lucas Caton e Akita” where I again revisit some of the history of the international Ruby community and why Ruby on Rails is different from every other community, and why it’s still worth investing your time in this ecosystem.

The fourth came out at the end of May when Charles Wood invited me back to Ruby Rogues with the title “My Ruby Story”, but this time for me to tell a bit of my personal story. How I started my career. How I got into Ruby specifically. The historical context in the tech world over the past 20 years.

The fifth and most recent came out today, early June. I’m back again with Montanha from Dev na Estrada in an “Interview” to revisit some of the Ruby Rogues theme about the beginning of my career. But while on Ruby Rogues I move very quickly over the beginning and jump to the last 10 years where I focused more on Ruby, in this one with Montanha I focus much more on the very start of my career, particularly the 90s and a brush over 30 years ago up to 10 years ago. The earlier ones are long (about 1h each on average), but this one in particular is VERY long (almost 2h!) — apologies for the length. But Montanha started with “tell us from the beginning”… I tried to summarize and only mention a few points, but even so it ended up REALLY long!

Did anyone get to listen to any of the podcasts? What did you think? Leave your comments below.

Configuration Management is a tricky subject. For non-starters, when you’re a developer and you have few boxes to take care of, you can usually get away with just managing them manually. People are probably just used to pop in a CD, double-click the “install” program and click “next”, “next” until the end, then you manually log in to backup (when you remember it), and sometimes you do apply some security updates when you remember about them.

But then you have more than a dozen machines, things start to get uglier, you end up making more mistakes, forgetting important steps, and all of a sudden managing machines becomes a nightmare. You end up being woken up in the middle of the night because you forgot to install some crucial component, and so on and so forth.

The same way you need testing, continuous integration tools when you’re a developer, you also need automated, reliable and flexible tools for the system administrator role. That’s where tools such as Chef kick in to help.

From Opscode Inc., we have Adam Jacob (CTO) and Jesse Robbins (CEO) to talk about the new contender in the automated system administration field, Chef, already in use by many companies which are pushing the cutting edge to maintain their datacenters.

AkitaOnRails: To kick start this interview, it would be great to have more background info about you guys. So, how did you end up in the configuration management space?

Adam: I’ve been a systems administrator for 13 years, and for a majority of that time I was working for companies who did a lot of mergers and acquisition work. Every couple of months we would acquire a new company, and it was my job to help figure out how to absorb those companies into the whole. I got really good at looking at an application I had nothing to do with creating, and figuring out what needed to be done to make it scale (or at least make it run.)

One thing we couldn’t do was tell the people who had built the applications that they needed to be radically altered (in many cases, they weren’t even around anymore.) What that meant in practice was we needed to have a very flexible, modular underlying architecture – everything we did had to be in service of the application, not the other way around. By necessity that meant becoming a tools developer – if we didn’t have the tools we needed, we would never be able to do the job in front of us.

Eventually I co-founded a consulting firm called HJK Solutions. We built fully automated infrastructure for startups – everything from OS installation to application deployment, all fully automated (including Identity Management, Monitoring and Trending, etc.) Over the course of the next two years we built infrastructure for 12 different startups, whose products ranged from electrical car fleet management to online dating.

So I come to configuration management through the trenches – as a line-level systems administrator trying to make my life easier, as a consultant helping others to reap the benefits, and now as a tool builder trying to move the state of the art forward.

Jesse: Jesse Robbins is CEO of Opscode (makers of Chef) and a recognized expert in Infrastructure, Web Operations, and Emergency Management. He serves as co-chair of the Velocity Web Performance & Operations Conference and contributes to the O’Reilly Radar. Prior to co-founding Opscode, he worked at Amazon.com with a title of “Master of Disaster” where he was responsible for Website Availability for every property bearing the Amazon brand. Jesse is a volunteer Firefighter/EMT and Emergency Manager, and led a task force deployed in Operation Hurricane Katrina. His experiences in the fire service profoundly influence his efforts in technology, and he strives to distill his knowledge from these two worlds and apply it in service of both.

AkitaOnRails: What’s the story behind Opscode, what’s its mission, and what’s the story for Chef’s creation?

Opscode: The story behind Opscode really starts when we met Jesse. He had written an article for O’Reilly Radar about Operations being the new secret sauce for startups. He and I met for coffee, became friends, and stayed in touch. Jesse understands operations culture at a visceral level, and he’s very well connected to a huge community of like-minded people that I didn’t even know existed.

As our consulting company grew, we reached a crossroads – we clearly had a nice business going, and it wasn’t difficult for us to find more work. What was difficult was finding people who had the skills to actually deploy a new infrastructure, and to adapt the stack we had developed for a new application. We couldn’t avoid the fact that there was a couple of weeks of very high-touch work that was required to get the entire infrastructure up and running for a new client.

We tried to recruit Jesse during this period, since he was one of those rare people who could do that initial high-touch engagement. He turned us down – primarily because he saw what we did: we could build a consulting company that was huge, but it would still be down to us in the trenches every day. Unless we could get over that hump, there were probably less stressful ways to make a living. :)

So we started looking at what was stopping us from being able to get that initial part of the engagement done as quickly as possible. What was stopping us from literally having a customer fill out a questionnaire, and letting that data drive 95% of the decisions about the infrastructure?

It turned out the answer was, in a word, “everything”. The entire stack of open source tools we were using had been built in a different era, and they saw the world through a very different lens. We needed everything to have an API, we needed everything to be more open with its data, and we needed everything to be flexible enough to handle the next evolution of application architectures (whatever that may be.)

Once we had that revelation, the next step was figuring out what a ’new stack’ would really look like. If we could start from scratch, what would we take with us, and what would we leave behind? Amazon had done such a great job showing us what an API over the bootstrapping process could look like, and the kind of benefits that could be had from the approach. So assuming something like that existed for bootstrapping, what about the next layer of the stack (configuration)?

We started experimenting with Chef during this period of questioning. We started working on Chef with the goal of putting ourselves out of business – making the barrier to entry to having a fully automated infrastructure so low that any developer or systems administrator could just do it. We built a prototype, showed it to Jesse, and he agreed to come on board.

Opscode was born then, and our mission came out of those experiments: we are bringing Infrastructure Automation to the Masses. We want to tear down the barriers to entry that stop people from having really great, repeatable, automated infrastructure. Our role is to bring developers and systems administrators the best tools possible, so that they can build the systems they have always wanted.

We raised 2.5 million from DFJ in January of 2009 on that vision, and have been at it ever since.

AkitaOnRails: I’d like to say that only amateur sysadmins do everything manually, but I think most small to medium corporations at least still do everything manually or with random scripts spread all over the place. The notion of “configuration management” is still new to a lot of people. Could you briefly explain what it is, and why it is important?

Opscode: To me, “Configuration Management”, at its core, is all the stuff you have to do to take a system from “running an operating system” to “doing its job”. When a systems administrator configures a system by hand, and posts her notes on a Wiki, she’s practicing the most primitive form of Configuration Management.

Now, having those notes is better than nothing – when she needs to do that task again, she can at least go back and read them to remember what she did last time. She still has to do it over again, though – and the repetition gets tiresome. So she starts writing scripts that encapsulate that knowledge in code, so that now she only has to run a series of smaller commands.

Time passes, though, and entropy sets in. The systems begin to drift from where they were when the systems administrator wrote the scripts. Next thing you know, the scripts don’t run anymore, or if they did, the configuration they build is wrong. Our intrepid admin then starts editing the scripts, or making new ones, to deal with the system when it’s in this new state. This is the stage we call “tool sprawl” – you have a tool for each different phase of a system’s observable life-cycle.

Modern configuration management tools solve this problem by providing a framework for describing the final state a system should be in, rather than the discrete steps we should take to get there at any given time. Rather than writing a script that lists the commands to install Apache, write the configuration file, and start the service, you would describe that “apache should be installed”, the configuration file “should look like this”, and the service “should be running”.

When the configuration management system runs it looks at each of these descriptions individually, and makes sure that they are in the proper state. We no longer care what the initial state of the system is – the configuration management system will only take action at each step in the process if the system is not in the state you described. If you run it again, and nothing has changed, the system takes no action. (Configuration management geeks call this property idempotence)

This means that you can describe your systems once in code, and as they change over time, simply update that code to reflect what you want the state of those systems to be. The impact of this model on the daily life a systems administrator cannot be overstated – it makes everything easier.

It also has huge impacts outside the systems administrators world. You now have a living document that describes how all your servers are configured – you can share it, you can put it in revision control, you can print it out for an auditor. Business processes that previously required manual intervention frequently can be boiled down to discrete changes. The more you work in this way, the more the impacts spread throughout the organization.

AkitaOnRails: Even though the Ruby community probably compares Chef to Puppet, I think one of the most widely used systems is CFEngine2. How does Chef compare with CFEngine2?

Opscode: Cfengine 2 is where almost everyone in the configuration management world cut their teeth. Mark Burgess is responsible for the academic papers that outlined the idea that each part of the system should be idempotent, and his work in studying how real-world systems can be managed at scale has done more to impact the evolution of configuration management than any other individual.

In addition to the idea of idempotent resources, Burgess introduced the larger concept of “convergence”. The basic idea here is that if you have the description of how every finite resource should be configured, given enough time, those resources will bring the system into a compliant state. The order in which the resources run fundamentally does not matter – eventually, they will all wind up in the right place.

While this model works at a fundamental level, it has some pretty dramatic inefficiencies. Cfengine applies resources based on their type – all the files are managed at once, then all the services, then all the packages. You can control the order they are run with the ‘actionsequence’, but each system gets only one order. So if you need to have a file copied, a package installed, and a service restarted, it’s easy enough to model. When you start getting into more complex configurations, however, it becomes more and more difficult to get an actionsequence assembled that allows you to configure your entire system in a single run.

This is not a bug in Cfengine – it’s by design. Convergence is the answer – it’s okay that it has to run more than once, it will get there eventually. If you are thinking too much about the order things should happen in, you’re probably not thinking about idempotent descriptions.

In my experience, though, this was frustrating at scale. It meant that the amount of time it took to configure a system increased as the configuration became more complicated, and your ability to model complicated interactions in the system became increasingly opaque.

For the era in which it was written, this problem mattered a lot less. If it takes you 6 to 8 weeks to get a server even ordered, then another week to get it racked, stacked, and the OS installed, the fact that Cfengine needs to run 3 times to configure it doesn’t matter very much. (You have lots of bigger problems!) In a world where many of us can go from bare-metal to running operating system in 5 minutes, either via our own install systems or an API call to AWS, it starts to matter a whole lot.

Chef takes a different approach. We start with the idea of an idempotent “resource” – a package, a service, etc. We add the idea of “actions” – these are all the different states you might want to request a resource to be in. Then you put these resources into “recipes”, which are evaluated in the order they are written. You can then have recipes rely on other recipes having completed before they are run, giving you the ability to say “make sure Apache is installed before you configure my Web Application”.

The goal is that, with Chef, you can always bring the system into the proper state with a single Chef run. It sees convergence as a response to a bug – a system that is 1/2 configured is, in fact, broken. If the cause of the bug is environmental – a network service is not available, for example – then running Chef again will likely fix things. If the issue is that you haven’t specified the order that you want resources to be configured in, though, then it’s a bug in your recipes. If you can’t write a recipe to configure your system in a single Chef run, it’s a bug in Chef.

This also has side-effects for reasoning about the system at scale. Given the same configuration and attributes, Chef will always behave the same way, on every system. As you add more and more things to the system, it’s still easy to reason about when, and how, they will be configured.

Interestingly enough, Cfengine 3 implements a system that is very similar to Chef. Rather than a single global actionsequence, it uses a ‘bundlesequence’, where bundles are roughly analogous to Chef’s concept of a recipe.

Another major difference is that Chef allows you to ’look up’ at your entire infrastructure when configuring a system. This ability comes in handy when you want to do things like configure a monitoring system, or a load balancer. You can ask Chef questions like “what are all the servers running my application in production”, and use the response to configure your system. (You can see an example of this on our blog)

From a systems architecture point of view, Chef and Cfengine are actually fairly similar. They both push the majority of the hard work of configuring a system out to the systems themselves. This is highly advantageous at scale – the Chef and Cfengine servers are really glorified file transfer systems.

We differ pretty deeply on our approach to what a language for configuration management should look like, but I’ll talk more about that in a later question.

Cfengine is at work in some of the largest data centers in the industry, and it fundamentally altered the landscape of systems management. While it’s not the tool I want anymore, you can’t understate the impact it’s had on the design of every configuration management tool that came after it – including Chef.

AkitaOnRails: Chef has a lot of components to it. Could you briefly describe all the main components that work together? The client side, the server side, cookbooks?

Opscode: Sure! The most important part of Chef is the cookbooks – they are where you actually describe your configuration. They collect recipes, and all the assets needed for the recipe to run (files, templates, etc.). Cookbooks are very often share-able, and lots of cookbooks already exist.

Chef can run your cookbooks in two modes – a client/server mode (chef-client), or a stand-alone mode (chef-solo). When you run chef-solo, you pass a URL to a tarball full of the cookbooks you want to have run. There is no more infrastructure than that – put your tarballs someplace you can download them, and go nuts.

In client/server mode, each Chef client is configured to talk to a Chef Server. The Server stores information about each client (a whole lot of it – things like IP addresses, loaded kernel modules, and more), and distributes the cookbooks they need to configure themselves. It also provides a REST API and an interactive Web UI, so you can easily alter the configuration of your systems centrally. Finally, all the data the server collects is indexed and searchable – you can then use this in your recipes to configure services that require complex, dynamic configuration. (Some examples would be dynamically discovering a master MySQL server, or finding all the memcached servers in a cluster)

AkitaOnRails: What would you say about Chef’s maturity? CFEngine has more than a decade of usage, which is difficult to beat. Would you say that it’s “mature enough”? Meaning, it’s already in production in companies of many sizes, its APIs don’t change too much and my cookbooks will probably work if I upgrade to newer version of Chef?

Opscode: Chef is a little over a year old – it was first released to the public on January 15th, 2009. Since then, 42 different developers have committed to the project, around 5 of whom work for Opscode. It’s been in production use in the Engine Yard Cloud from the day it was released. Since then, it’s seen adoption by companies and universities of all different sizes, from small startups to huge enterprises with very heavy compliance requirements.

So it’s definitely “mature enough” for real world use – lots of people are using it, and relying on it, every day. Balancing that knowledge with the reality that the project is fast moving and evolving is important, and we try and do it in a number of ways:

1. The recipe syntax is considered basically “complete”. If we do make changes, they are backwards compatible to previous Chef releases. Short of something truly amazing coming along that radically alters the shape of the universe, this will remain true.
2. We test a lot. Chef has over 2000 unit tests, and functional tests that cover the entirety of the REST API, and much of the individual resources (we’re aiming for 100% feature test coverage.) There are more lines of code testing chef than there are lines of code in Chef proper.
3. If we do break backwards compatibility, we try and make it happen only when we bump the minor revision. If you have an 0.7.x version of Chef installed, it should always work with other versions of Chef in the same release cycle.

Most of the work in Chef currently is around adding more functionality, not in changing the way existing functionality works. It’s safe to use Chef today – in the future, you’ll just keep getting more good sauce to add to the mix, rather than having to deeply re-factor the way you do things.

Finally, the Chef Community is truly epically great – we have lots of people who are spending significant amounts of their time with Chef. Even if they aren’t contributing code, they are answering questions, they are writing documentation, they are hanging out on IRC and offering you cupcakes. It’s a group of people that are focused on solving real world problems, and helping each other to do the same. It’s by far what I’m proudest of, and I think it has a significant impact on whether Chef is ready for prime time. The bench is really, really deep.

AkitaOnRails: Chef uses Ruby directly, which some would say it’s both a blessing and a curse. It’s probably perfect for Rubists, but I feel that most sysadmins are used to Bash, Python and are not very flexible on change. Why did you choose to use Ruby instead of a simpler language?

Opscode: The answer to the question of why we use Ruby directly for the configuration language comes in two parts: why we extended a 3GL rather than build a declarative DSL or a complete modeling language, and why we chose Ruby as that 3GL.

First, why we extended a 3GL. Tools like Cfengine and Puppet build a declarative DSL for configuration management – a custom language, which provides a model within which systems administrators or software developers can work to automate their system. Other tools like Elastra’s EDML and ECML, OpsWare’s DCML, or Bcfg2 give you an XML schema to describe how the system should behave.

The issue with these approaches is that, by definition, they must build an abstraction for every task the end-user may want to perform: an impossible feat. The level of complexity inherent in automation, coupled with the inability to break out to 3GL language constructs when necessary, result in a system that can only target a subset of the total complexity, rather than enable users to find innovative solutions to their specific problems. By leveraging Ruby, adding support for other use cases is a matter of adding new sets of base classes while maintaining consistency and approachability in their interface design, because the full scope of the language is available.

Our goal with Chef was to keep the simplicity that comes from having the focus be on idempotent resource declaration, while giving you the flexibility of a full 3GL. In practical terms, anything you can do with Ruby you can do with Chef – and since Ruby is a 3GL, that amounts to essentially anything.

Larry Wall, the creator of Perl, has a quote that I love:

“For most people the perceived usefulness of a computer language is inversely proportional to the number of theoretical axes the language intends to grind.”

Since we wanted Chef to have the maximum amount of usefulness, we have actively tried to remove as many theoretical axes as possible – a belief that we can imagine the total breadth of the problem space being one of them. There is more than one way to do it with Chef, and the only valid criteria for rating the success of your automation project is whether it solves your problems in a reliable way.

In practice, you need to know very little Ruby to use Chef. Here is an example of installing the program “screen”:

package "screen" do
 action :install
end

The same thing in Puppet:

package { "screen":
 ensure => present
}

And in Cfengine 2:

packages:
 screen action=install

While all of these systems require learning the syntax, at a base level, there isn’t much difference between them in terms of raw learning required. The difference is that when you hit a limitation in Chef, you have the ability to innovate easily, and when you hit those same limitations in other tools, you do not.

We chose Ruby because of its fairly unique ability to create new syntax easily. Tools like Rspec are fine examples of ways you can manipulate Ruby for fun and profit that are very difficult to duplicate in other tools. We wanted to make sure that, even though you were “in” a 3GL, you didn’t have to go through any extra hoops to make the simple things work. Ruby was the language that I was comfortable enough in, that I knew had the ability, to make that a reality.

That said, one of our goals is to extend the ability to write Chef recipes into other 3GL’s. We have an example of doing this already with Perl – and we made no changes to the Chef source to accomplish it. You can see the demo here on CPAN. It works by using Chef’s JSON API to ship the compiled resources over to the Ruby library for execution, and over time we’ll be extending those interfaces. You’ll be able to have recipes written in Python interoperating with recipes written in Ruby and Perl.

AkitaOnRails: Does Chef have (or for that matter, need) something like Augeas, which Puppet is trying to support?

Opscode: Augeas is neat. Chef doesn’t have Augeas support today, and the reason is that nobody has needed it badly enough to write the integration. One reason is that, with Chef, it is quite easy to dynamically add to a resource (like, say, a template) or search for particular systems that match a criteria. This means that the use-case for Augeas (which edits files in place) is less necessary – you can often get the data you need to render a template, rather than needing to build it up over time with incremental edits.

We think this is a better practice in general, as it ensures that all the systems you are managing can always be restored to a working state from nothing but the cookbook repository. If you use Augeas to allow idempotent changes of individual lines of a configuration file, it encourages the behavior of individual administrators editing files in place, which is a configuration management anti-pattern.

AkitaOnRails: Sysadmins used to CFEngine complain about Ruby’s dependencies and overall weight. Because for Chef to run you need Ruby installed. Not all distros have Ruby in the same version (although most already migrated to 1.8.7). Then you have the problem of weight. I am not familiar with Chef, but Puppet can grow to hundreds of megabytes. What they don’t want is to have clusters of Chef machines (which, by themselves, also need maintenance, adding to the overall complexity). How do you deal with datacenters with thousands of servers? I know it’s difficult to measure precisely, but what would be a reasonable ratio between Chef servers x managed servers?

Opscode: When you are evaluating the scalability of configuration management systems, you want to look at two different axes. The horizontal one, which is the number of systems that can be managed by a single configuration management server at a particular rate of change, and the vertical, which is how much of your infrastructure can be automated by the tool.

On the vertical axis, I think Chef is the clear winner, for reasons I think are pretty well summed up by my answer to question 7. I would put Puppet second, and Cfengine last.

On the horizontal axis, Cfengine is the clear winner. It’s written in C, and it has the thinnest possible server component – it does nothing but authenticate clients and serve files, essentially. I know first hand of data-centers that are running huge numbers of servers off a single cfengine server.

One important metric to keep in mind when discussing the horizontal scalability of a configuration management solution is that the most important metric is the rate of change. All the tools we’ve been talking about are ‘pull’ based – the clients check in at an ‘interval’ with the server, and apply a ‘splay’ to ensure that not all the systems check in at once. A common out of the box configuration is an interval of 30 minutes, with a splay of 15 minutes. (This means a server checks in every 30-45 minutes, depending.) If you are comfortable increasing that interval, you will get more scalability out of fewer resources (by lowering the amount of concurrency.)

So when anyone says “I have 10 thousand servers on a single configuration management server”, ask them “at what interval?”.

Chef scales like a web application. The server itself is quite thin, and is responsible for authenticating clients, transferring files, storing node state, and providing a search interface. It scales horizontally by adding new Chef Servers as necessary. The API is RESTful, and there is no session state between the clients and the server. (At least not in Chef 0.8+) When you encounter scalability problems with Chef, the tools you apply are the same ones you apply to any well designed web application.

You asked specifically about memory utilization – Chef does quite well in this regard. Individual server processes usually are between 14-50MB resident. The client itself, running in daemon mode, is usually around 28MB resident.

In our testing, the current bottleneck in a Chef server is CPU. Chef is smart about how it handles file transfers – we only transfer files that have changed on the server. To support this we calculate a checksum for each file requested, and we currently don’t cache the results. We’re planning on fixing this for the next major release of Chef (0.8.0) which should shift the bottleneck over to RAM.

With Chef 0.7, you should be able to support thousands of clients at a half-hour interval and fifteen minute splay on reasonable commodity hardware. The changes in Chef 0.8 should bring that number up dramatically – I’ll get back to you with some benchmarks once the patches are in. :)

AkitaOnRails: Probably related to the previous question, seems like specially after Sarbanes Oxley there’s been an increasing interest in stuff such as ITIL, CoBit. Have you ever seen successful implementations of those in the Web-style infrastructure? I mean, I can see them succeeding in Banks, Aerospace and Defense, etc but I fail to see them working as advertised in a very dynamic environment such as Web services hosting. What are your experiences regarding this issue?

Opscode: Well, I think you can think of ITIL in the same way you think about the classic ‘Waterfall’ model of software development. For some kinds of projects and companies, it is essential – it’s hard to imagine working a different way. Most often these are companies with huge manufacturing or quality control concerns – medical health, aerospace, banking and finance, etc.

The same thing applies to ITIL – the larger the concern, and the more stringent the requirements, and the longer the lead time, the more the processes they describe start to make sense. Like all large process, though, they tend to de-emphasize the human element – people have roles to play, and forms to file. :)

In the Web Ops culture, things are different. I’ve never seen a successful marriage of ITIL and Web Ops, and the reason is that the domains are so very different. If there is a bug on the website, it’s better to ship the fix now than wait for a release management process to ensure that the site won’t have any more issues based on your fix, for example. It’s also a bad cultural fit – in the best Web Ops teams, the focus is heavy on communication, agility, and respect, rather than process, formalism, and tooling. The shift you start too see in the really great Web Ops companies is that their operations personnel become enablers of the organization, rather than end-line blockers of change (to keep stability high.)

In general, I think the 4 steps outlined in visible ops for emergency management are not bad ones, but the devil is always in the details. The guy you should really ask about this is Jesse – he’s largely responsible for Amazon’s operational culture, and knows what it means to start hacking on that sort of thing from within huge organizations.

AkitaOnRails: Awesome, I think this is a wrap. Thank you very much for this interview!

But then you have more than a dozen machines, things start to get uglier, you end up making more mistakes, forgetting important steps, and all of a sudden managing machines becomes a nightmare. You end up being woken up in the middle of the night because you forgot to install some crucial component, and so on and so forth.

The same way you need testing, continuous integration tools when you’re a developer, you also need automated, reliable and flexible tools for the system administrator role. That’s where tools such as Puppet kick in to help.

This time I’ve interviewed Luke Kanies, from Reductive Labs, former contributor to the famous CFEngine tool and creator of Puppet, one of the most acclaimed configuration management tools for 21st century datacenters.

AkitaOnRails: To kick start this interview, it would be great to have more background info about you. So, how did you end up in the configuration management field? I understand that you have a long history with CFEngine development, right?

Luke: I was a Unix admin going back to 1997, always writing scripts and tools to save myself time, and around 2001 I realized that I shouldn’t have to write everything myself – that someone somewhere should be able to save me time. After a lot of research and experimentation, I settled on Cfengine, and had enough success with it that I started consulting, publishing, and contributing to the project.

AkitaOnRails: What’s the story behind Reductive Labs, what’s its mission, and what’s the story for Puppet’s creation?

Luke: After a couple of years with Cfengine, I had a lot more insight but was frustrated because it still seemed to be too hard – no one was sharing Cfengine code, and there were some problems it made you work really hard to solve. The biggest issue, though, was that its development was very closed – it was difficult to contribute much more than just bug fixes.

I got frustrated enough that I stopped consulting and looked for other options. I worked briefly at BladeLogic, a commercial software company in this space, but in the end I decided that the insight I had and the lack of a great solution were a good enough start for a business that I decided to morph my consulting company into a software company and write a new tool.

AkitaOnRails: I’d like to say that only amateur sysadmins do everything manually, but I think most small to medium corporations at least still do everything manually or with random scripts spread all over the place. The notion of “configuration management” is still new to a lot of people. Could you briefly explain what it is, and why it is important?

Luke: It’s surprisingly difficult to describe it succinctly, but for me, there are two key rules: You shouldn’t need to connect directly to a given machine to change its configuration, and you should be able to redeploy any machine on your network very quickly.

These two rules combine to require comprehensive automation and/or centralization for everything that goes into making a machine work. Annoyingly, they also immediately introduce dependency cycles, because your automation server needs to be able to build itself, which is always a bit of a challenge.

AkitaOnRails: I think one of the most widely used systems is CFEngine2. How does Puppet compare with it? Meaning, what do I have as value added when switching to Puppet, and what are the known caveats?

Luke: There are multiple important functional differences. The biggest is Puppet’s Resource Abstraction Layer , which allows Puppet users to avoid a lot of the detail they don’t really care about, like how rpm, adduser, or init scripts work – they talk about users, groups, and packages, and Puppet figures out the details.

We also have explicit dependency support, which makes a huge difference – it’s easy to order related resources and restart services when their configuration files change, for instance.

The language is also a bit more powerful. Like Cfengine, we have a simple custom language, but Puppet’s language provides better support for heterogeneity, along with a composite resource construct that allows you to easily build in-language resource types like Apache virtual hosts that model more complex resources consisting of multiple simple resources.

AkitaOnRails: Puppet has a lot of components. Could you briefly describe some of the main ones that work together? The client side, the server side, recipes?

Luke: Most people use Puppet in client/server mode, where the central server is the only machine that has access to all of the code, and it runs a process capable of compiling that code into host-specific configurations. Then each machine runs a client (including the server), which then retrieves and applies that host-specific configuration. This has nice security implications because you’ve not shipped your code to every machine on your network.

If this model doesn’t work for you, though, it’s also easy to run Puppet stand-alone, where each machine has all of the code and compiles it separately. Multiple Puppet users do this for various reasons. This stand-alone ‘puppet’ executable is a standard interpreter – it can be used to run 1 line scripts or thousands of lines in a complete configuration.

Beyond this, we’ve got a few other interesting executables, such as to access our certificate authority functionality, and an interesting executable called ‘ralsh’ that provides a simple way to directly manage resources from the Unix shell, without having to write a separate script.

AkitaOnRails: What would you say about Puppet’s maturity? CFEngine has more than a decade of usage, which is difficult to beat. Would you say that it’s “mature enough”? Meaning, it’s already in production in companies of many sizes, its APIs don’t change too much and my recipes will probably work if I upgrade to a newer version of Puppet? I think the 0.x version makes some people nervous :-)

Luke: Really we should have called a version from 2007 1.0, but it’s hard to know how stable a release is going to be until it’s been out for a while. :)

It’s obviously tough to match Cfengine’s long life, although they’re somewhat forcibly migrating to Cfengine 3, which is a complete rewrite, so that maturity isn’t worth quite as much right now.

However, Puppet’s been in production usage around the world since 2006, and it’s currently used by more large companies than I could reasonably name – Twitter, Digg, Google, Sun, Red Hat, and lots more – and our community and customer base consider it to be mature. For the line came some time early last year, when I found that the vast majority of issues people had were user issues on their part, rather than some flaw or shortcoming in Puppet.

In general the APIs are quite stable, and we’ve done quite well, I think, at maintaining backward compatibility when the APIs have had to change. The point about API stability in a 1.0 release isn’t so much to differentiate it from previous efforts as to make a promise for the future. This especially matters for companies like Canonical, who want a release that they can support on Ubuntu for five years.

AkitaOnRails: Puppet has its own language and you can use Ruby for the advanced cases. It’s probably perfect for Rubists, but I feel that most sysadmins are used to Bash, Python and are not very flexible on change. Why did you choose to use Ruby instead of a more widespread language? What do sysadmins need to realize to shift paradigms?

Luke: Part of it is that most people don’t really need to know any ruby to be effective with Puppet. Sure, you can get some more power if you do, but if you’re not a language person, you’re perfectly functional with just Puppet.

Another nice thing is that we have a pretty smooth scale in terms of Ruby knowledge – you can start out writing ERB templates or five line extensions to Facter, which is our client-side querying system, and grow smoothly through to writing custom resource types.

In the end, I chose Ruby because I was most productive in it. I likely should have chosen Python, given its speed benefit and popularity at Red Hat and other places, but I found I just couldn’t write code in it. I started thinking in Ruby after only a few hours of usage, so it was impossible for me to turn away from it.

AkitaOnRails: Sysadmins used to CFEngine complain about Ruby’s dependencies and overall weight. Because for Puppet to run you need Ruby installed. Not all distros have Ruby in the same version (although most already migrated to 1.8.7). Then you have the problem of weight. Puppet can grow to hundreds of megabytes. What they don’t want is to have clusters of Puppet machines (which, by themselves, also need maintenance, adding to the overall complexity). How do you deal with datacenters with thousands of servers? I know it’s difficult to measure precisely, but what would be a reasonable ratio between Puppet servers x managed servers?

Luke: It’s as impossible to tell you how many clients a Puppet server can handle as it is to tell you how many clients a Rails server can handle – it all depends on the complexity of the tasks. Google scaled to 4500 client machines on a single server, but most people tend to add another server at around 500-1000 clients.

It’s true that it’s hard to keep memory usage down in a Ruby process, but we’ve made great strides in our recent releases by doing things like deduplicating strings in memory and being more efficient in our code paths. Really, though, we’ve spent a lot more time on features and bug fixing and less time on optimizing – until recently, we’ve been a small development team, and we just didn’t have the bandwidth for it.

Now that my company, Reductive Labs, has some investment, we’ve been able to add three full time developers, which is going to really help in this area.

As to dependencies, this is one area we break strongly from the Ruby community – we don’t require a single gem, other than our own Facter tool (and it’s usually not shipped as a gem). Rubyists tend not to worry too much about package dependencies – they just put it in vendor, as I’m fond of saying – but that doesn’t work when you have to deploy thousands of copies. So yes, you might have to install Ruby, but there won’t be any other dependencies you have to deal with, which greatly simplifies it.

It’s generally as tough to know how you’ll need to size your puppetmaster as it would be to size a web server – it depends on how complicated the workload is. In general, somewhere between 500 and 5000 clients, you’ll need to have a second server, but most people probably find it closer to 500. Really, though, if you’ve got 3000 clients hitting a service, you probably want to make it horizontally scalable for stability in addition to performance.

AkitaOnRails: Security is a big concern nowadays, Puppet was worried from the beginning on the handshake procedure between clients and server, can you describe it a little bit? Also, is there any built-in recipes for hardening machines, for example? Or at least any desires to add such tools in the future?

Luke: Puppet uses standard SSL certificates for authentication and encryption, including a certificate signing phase. By default, the client generates a key and a certificate request (CSR) and then uploads the CSR to its server. This upload, along with the later certificate download, are the only unauthenticated connections that are allowed by default.

From there, a human normally has to trigger the client’s certificate to be signed, but many organizations, including Google, automatically sign client certificates because they trust their internal network.

As to automatic hardening, there aren’t any recipes that I’m aware of right now, but it’s something that I’m definitely interested in. Years ago I was a big fan of TITAN, which is a hardening package for various *NIX platforms, and it was part of the inspiration to write Puppet – I’ve always wanted a portable, executable security policy.

AkitaOnRails: The puppetmaster uses Webrick by default, but the documentation also describes using Mongrel or Passenger. Are there any real gains in using those? Is it more for convenience or do we have performance/robustness improvements?

Luke: Holy cow Webrick is slow. It’s really fantastic for proof of concepts – get up and running in minutes. Once you get beyond that proof of concept, though, you really need to switch to Mongrel or Passenger. If you get more than one concurrent connection in webrick, your clients start to suffer, but you can scale to far more with the other solutions out there.

AkitaOnRails: Are there any client cases you are allowed to talk about? Meaning, more details on the kind of infrastructure, difficulties, caveats, best practices?

Luke: The possibilities here are pretty open ended. Google uses Puppet to maintain their corporate IT, which means they’re running it on thousands of laptops and desktops which is pretty different. MessageOne, a division of Dell, is really interesting in that their developers have to ship Puppet code to manage the applications that they ship, so if an app isn’t trimming its logs or backing itself up, it’s a bug that the app developer has to fix rather than the sysadmin. This really helps to bridge the divide between dev and ops, which has worked out really well for them.

Otherwise, there are lots of stories and best practices, but I’m afraid that would be a whole second article. :)

AkitaOnRails: I’ve seen Andrew Shaffer talk about Agile Infrastructure for a couple of years now, but I still think most IT organizations are unaware of this concept. Can you elaborate on what it means to be Agile outside of the development field?

Luke: I think Agile Infrastructure has even less adoption than Agile Development. The vast majority of IT shops haven’t changed practices significantly in years and are largely unprepared for the growth in server count that they’re experiencing. They mostly try to scale by adding more people, which we call the meatcloud, rather than scaling their tools and practice.

AkitaOnRails: Probably related to the previous question, seems like specially after Sarbanes Oxley there’s been an increasing interest in stuff such as ITIL, CoBit. Have you ever seen successful implementations of those in the Web-style infrastructure? I mean, I can see them succeeding in Banks, Aerospace and Defense, etc but I fail to see them working as advertised in a very dynamic environment such as Web services hosting. What are your experiences regarding this issue?

Luke: In general, I think these kinds of high-level policies are great for filings but aren’t so great for actually solving problems. The bigger a company is and the more public they are, the more likely they are to care about ITIL et al, but it doesn’t really help them solve problems outside of PR in my experience. You can be ITIL compliant and dysfunctional, or completely out of compliance but in fantastic shape. Considering that the best standards are derived from implementation and best practice, which few of these are, I don’t have a lot of hope for these being adopted by the best shops out there.

My personal experience is that very few companies ask or care about these standards, and the ones that do usually do so in a kind of checkbox way, in that they want to make sure they can check off things like CMDB but they aren’t really that concerned with the specifics.

AkitaOnRails: I think this is it! Thank you very much for this conversation!

This time I had some time with Joshua Peek. He was recently announced as a new member of the Rails Core Team.

He got the honor because of his hard work for the upcoming Rails 2.2, solving the thread-safety issue within Rails. Because of his Google Summer of Code project, guided by Michael Koziarski, they were able to make Ruby on Rails truly Thread-Safe, which could be a great boost for virtual machines with native-threading support, such as JRuby.

The interesting bit: he is just 19 years old and 4 years ago he wasn’t even a programmer. He started on Ruby with Learn to Program and he is now a Rails Core member. Let’s get to know him.

AkitaOnRails: Ok, so let’s get started. First of all, it would be good to know more about yourself. Like how did you find Ruby, why you got hooked by it, and what are your “hobbies” in the tech area 

Josh Peek: Like most people, I originally found Ruby through Rails. At the time, I was only doing simple web design like html, css, js. I had no programming experience. I think I bought some php book, but I could never get into it. So I heard about this “Rails” thing and looked into it. I learned quickly that I really needed to learn how to program and learn Ruby, so I got the Pickaxe and Agile Web Development with Rails book and went from there.

AkitaOnRails: This is interesting, one of my goals of interviewing you is because I figured you are pretty young and there are lots of young programmers who feel that learning Ruby is difficult. And you say you never programmed before Ruby, so how was this learning curve for you?

Josh Peek: Yeah, I’m currently 19 and I started programming Ruby about 3 years ago. Before I read the pickaxe, I found this little Ruby programming book by Chris Pine. It was really helpful to get into programming. The hardest thing about programming for me, was wrapping my head around OOP. It’s really something you just need to work with to truly understand.

AkitaOnRails: Oh, and I forgot to ask, where are you from? Do you study CS?

Josh Peek: I’m currently living up in Chicago, IL where I attend college as well. Yes, my current major is Computer Science

AkitaOnRails: When you started programming with Rails, what were the things that most annoyed you, if any?

Josh Peek: Hmm, I can’t really think of anything that “annoyed” me. It was never a problem because you could either monkey patch the issue or fix it and get it out to the entire Rails community.

AkitaOnRails: So you started working with Rails as a freelancer? Did you build any open source gems, plugins as well?

Josh Peek: Yeah, I started as a freelancer. I technically still am. I used to publish a ton of Rails plugins. I think I went a bit overboard at first. I really don’t have any of those around anymore, but it would be fun to go through them and see how much my views on programming have changed since.

Right now, all my current plugins and code are at github.com/josh. I tend to just post any personal project I’m working on, on Github even if it’s not done or I think it will be useful at all.

AkitaOnRails: Ok, so the main dish Thread-safety! You said you were not particularly ‘annoyed’ by anything about Rails, but you decided to tackle on this challenge anyway, how did it all start?

Josh Peek: I did want to do a Google Summer of Code project for a while now. However when it came to signing up I did things really last second. I asked around the core team and a few ideas came up, one of them was thread safety.

I wasn’t really even that interested in doing it, I actually wanted to work in ActiveModel as my project. However the thread safe project was the only one that was accepted, so I was stuck with it. Before the project started, I had zero experience with threads.

I didn’t even know what a mutex was for, however I welcomed it as a learning experience.

AkitaOnRails: Maybe it would be interesting if you could give us an overview of how the Google Summer of Code works, I mean, what are their goals, how do you participate, how difficult it is. Some Brazilians are probably not familiar with it.

Josh Peek: Google Summer of Code is a program setup by Google that sponsors students to work on open source projects. The student creates a project proposal for the organization they want to work with, Ruby Central in my case, and it gets approved by them.

You also work with a mentor from the organization. Michael Koziarski (Rails Core) originally suggested that I do the project and so we “arranged” for us to work together.

At the end of the program, you submit your code and if you have completed the project you get paid $5000. And I think $500 of that goes to the open source organization.

AkitaOnRails: And you completed the project?

Josh Peek: Yes.

AkitaOnRails: Cool, and how long is the program?

Josh Peek: Around 3 months I think.

AkitaOnRails: Ok, back to the more technical stuff. There is something that bothers me a little bit. Of course it is a lot of work to make Rails thread-safe and this is something people were really looking forward to. But on the other hand, the MRI doesn’t use native threads, which essentially means that they are never truly concurrent, is that correct? Maybe other projects such as JRuby could benefit? Is there any real benefits for the MRI itself?

Josh Peek: Correct. JRuby is the only true solution if you want real thread concurrency. Ruby 1.9 does support “real” threads. However most of the internal C code is not thread-safe so there is an interrupter around those methods, but I’m hoping that maybe Ruby 2.0 will be fully thread-safe.

AkitaOnRails: You probably ran tests for both MRI and JRuby? Did you get improved performance/responsiveness because of the new thread-safe code? Or does it add up some new overhead instead?

Josh Peek: Our tests showed some slight improves in MRI, however the app we were testing was a simple test app. We didn’t have a real app we could benchmark since nothing else was thread-safe at the time. JRuby did show some nice improvements, again it wasn’t a real app though.

AkitaOnRails: Did you only aim for the thread-safe parts or did you also found and fixed other kinds of bottlenecks in the framework? You probably went through the entire code over and over and you already know it upside down, right? 

Josh Peek: I did a lot of work on preloading caches on boot up. The easy way out would be to just put a mutex around those caches and call it done. However, I had some extra time so I rewrote a ton of ActionView code.

Preloading means that we are building the cache on boot so it doesn’t need to be modified (or synchronized) while it’s serving requests and this should also benefit non threaded apps as well.

And it’s a huge win for Passenger, if you are using the copy on write feature, since caches built during Rails boot will be shared across multiple process.

AkitaOnRails: Awesome, the Phusion guys will like to hear about that. And I know some people will be lost about mutexes, could you explain a little bit about it for the audience?

Josh Peek: The big issue about running multiple threads is shared memory. If two threads try to access and modify the same object, it can cause some major problems. A “mutex” is a type of lock that “synchronizes” your threads so only one thread can access that piece of memory at a time.

However, this does have a performance impact because other threads have to stop while one is accessing the shared memory.

AkitaOnRails: I think it is awesome work, specially for JRuby. Did you talk to Charles, Nick or someone from the JRuby Core? I remember that I interviewed Charles and he said that even though they were pushing harder on the optimization of the JRuby runtime, the performance of Rails apps were not improving that much, so the next step would be to try to figure out how to modify Rails itself to behave better. Have you heard anything about this?

Josh Peek: Yes, we worked with Charles on some JRuby specific optimizations. He was a lot of help and he answered any of my questions relating to how JRuby synchronizes threads and what operations are atomic.

Nick Sieger actually volunteered (before GSoC) to tackle the ActiveRecord connection pool. Really a big thanks to Nick, I really didn’t have the experience to tackle that problem and he did a great job on it.

AkitaOnRails: Ok, even though the Ruby VM can’t have true concurrent threads, they actually have to deal with concurrent resources, in this case database connections, so a pool was necessary. Was it too much trouble to implement? Was it something that you had to do from scratch or there were prior work on connection pools for Ruby?

Josh Peek: Well, I think you better of asking Nick this question. But here is what I understand about it: The previous AR connection implementation did support threads, however it was easy to max out on the allowed number of db connections if a server got blasted.

The connection pool basically recycles old connections and prevents AR from establishing too many. You can actually set his max in your database.yml file with the “pool” option. I think the default is 3.

AkitaOnRails: And how does the mentor role work? I mean, did Koziarski guide you on specific points he wanted you to take a look on?

Josh Peek: Koz really help me stay on track. He did a lot of code auditing, and pointed out specific places I should look for problems in the large Rails code base.

AkitaOnRails: From the outside it probably feels ‘easy’ to say ‘ok, we just added thread-safety into Rails’, but this is not something like an external gem or plugin, you actually have to tackle the guts of the framework. How can you be sure you actually touched every part of the code that needed concurrency safety measures?

Josh Peek: That’s really what is hard about making code “thread safe”: there is no real way to be sure. You can write a bunch of unit tests and say ‘look, I can prove it’s fine’. However, the big issues are out of the way. From now on, we’ve decided to classify any further thread safe issues just like normal bugs.

AkitaOnRails: Do you think it is ready for prime-time? Or are you still tweaking it?

Josh Peek: I think it is ready for those people who have been waiting for a thread-safe Rails. People should start to audit and test their own apps for thread-safe issues and if something comes up, we’ll fix it in core. It’s really hard to test this stuff unless real people are testing real apps against it.

AkitaOnRails: At least, “Rails is not thread-safe” is not a good enough reason anymore to not use Rails. This should shut up a few pundits. This Rails 2.2 is going to be interesting, debunking some of these criticisms. Another one is “Rails doesn’t support i18n”, thanks to Sven. What else do you like the most about the next Rails release?

Josh Peek: My next little project within Rails is switching over to Rack. Rails 2.2 will include a Rack processor which lets your use it with any Rack server. However we are not fully switching over to Rack, yet. In 2.2 rack is opt-in.

./script/server will still run the old CGI processor. I hope to see CGI deprecated in the next release so we can be Rack only for 3.0.

AkitaOnRails: What are the benefits of going for Rack? It may not be so obvious for some people on why change code that is working already (the CGI bit).

Josh Peek: There should be some performance benefits, however that wasn’t enough to convince. Right now we have a ton of CGI hacks in Rails. This should clean up a lot of that.

What I really love is the standardized interface to Rails. This means a more universal API for writing ActionController related plugins that will work on any compatible Rack framework. I hope this means more Rails plugins will just work with Merb and vice versa.

AkitaOnRails: Having finished your GSoC project granted you the keys for the Rails official repo, is that correct? How does the Rails Core organize itself? Is each person responsible for some particular bit, or everybody else looks after everything?

Josh Peek: It seems like everyone has their own little responsibilities depending on what they were just working on. Since I just rewrote a ton of ActionView, I pretty much assume any issues or tickets related to it. I don’t think anyone has a pre-determined area though. People change their interests and that’s fine.

AkitaOnRails: But now can you ‘git push’ anything you want into Edge? And by the way, you mentioned you messed a lot with ActionView, but what exactly you changed there?

Josh Peek: Yeah, I’ve had commit access a while before the GSoC project (just before we switched to git). ActionView had to be refactored to support the preloading approach I was talking about earlier. So ERB templates are pre-compiled and cached on boot instead of at runtime.

AkitaOnRails: So, in 3 years you went from zero to Rails Core, solving the “thread-safety issue” and still having time to study and work on your freelance projects. How does it feel, looking back in retrospective? Did you ever thought you would contribute so much?

Josh Peek: 4 years ago, I really never even saw myself programming. I definitely never thought I end up on the Core Team of Rails.

AkitaOnRails: After so much you learned, what are the areas in computing that interests you the most? Web Development, any other area such as compilers, OS, etc? What do you intend to do next?

Josh Peek: I still really love Web Development. I recently tried some iPhone programming, but I’m not sure how I feel about it yet.

I’d love to try some lower level stuff. I still haven’t had a chance to use the Ruby C API, and I hear it’s really nice. Lately I’ve been doing a lot of work on a javascript project that’s soon to be announced and open sourced.

AkitaOnRails: Oh, and by the way, are you also a Mac user? :-) And I think this is it! Any other remarks about what we talked or something you would say to the Brazilian Ruby community?

Josh Peek: Yeah, I’ve been using Macs for about 6 years now. I’m not one of those people who switched after they discovered Ruby :-)

Josh Peek: And think thats pretty much it, … I was suckered into doing a talk at RubyConf this year, for the GSoC thing. So you’ll probably hear about about “thread safety” there. It’s probably the last time I’ll ever want to talk about Rails and threads again.

Thanks for the questions.

AkitaOnRails: Ok. So, let’s start. First of all thank you for your time. This is very funny because we are like 5 hours apart. You’re in Paris right now, but I understand you were in Argentina. Can you tell us what you are doing now?

Luis Lavena: Yeah, funny indeed. Right now I’m Technical director of an interactive and design agency with offices in NY and Paris. My job is to bridge the design field with the technology one, mostly on web based application development.

I’m from Argentina, live there, family and friends. I moved a few months ago to boost some developments and get first steps of the new organization in place.

I’m from a small province named Tucuman, northwest area of Argentina (1200 kms from Buenos Aires to be exact)

AkitaOnRails: Awesome, have you ever been in Brazil? Do you have contact with other Latin America Railers?

Luis Lavena: Even though Brazil is so close from Argentina I have never been there, which is a shame. I have several friends that lived there over the years.

I keep in touch with several Rubists and Railers of Latin America, but most with the ones in Argentina due to several meetings we had during the years RubyArg mailing list has been working.

AkitaOnRails: I am very interested in understanding how the Railers are organizing themselves in Argentina as we, in Brazil, are a growing community as well. Do you see new programmers going straight to Rails or is it the usual move from Java/others to Rails? Are companies adopting it, or Rails (and Ruby in general) still has a long way to go there as well?

Luis Lavena: Well, there is a huge number of developers that came from Java and dotNET stuff (mostly Java) and they are playing with Rails, there is also lot of developers that do Ruby for administrative stuff or even creating games with it.
Companies that develop software still need to adopt Ruby/Rails for their business, the biggest problem with that is the lack of support shaped as companies like Sun or some consulting services for Java. (or even Microsoft).

AkitaOnRails: Going back to the past, how did you start in programming in general? Did you study computer science, or were you dragged in there in some other way? And, finally, how did you stumble upon Ruby and Rails?

Luis Lavena: It’s funny, I started programming back in 1989, playing with sprites and GOTO’s with BASIC on a Z80 computer.

I officially didn’t finish my degree on CS, since job and fun stuff distracted me away from it. I first met Ruby back in 2001, loved its syntax, enjoyed its verbosity but it was not mature enough for my needs, at least not in Windows.

Even though I was using Python for so many years, I internally used Ruby to manage several stuff, from simple scripts to later rake tasks that helped us build our tools.

With Rails it was kind of different, since we started to look for alternatives to Zope and we bet on Rails at that time (0.10 or 0.12 at that time, if memory plays nice with me).

I can say I don’t regret the bet on Rails at that time.

AkitaOnRails: It is very interesting to see professionals like you moving out from your zone of comfort toward something ‘unknown’ as Ruby and Rails. Most programmers are very defensive and even aggressive on trying to find justifications for not using neither. Did you feel like that back then? What drove you towards Ruby?

Luis Lavena: Well, I’m used to change languages to fit my needs.
Keep in consideration that our first choice was pre-J2EE era or dotNET stuff, we analyzed which would provide us better solutions in the long run and we decided to avoid them.

Java stuff sounded at that time, and until today, expensive for business. Argentina is not a country where you will find customers with huge budgets to invoice them the cost of using tools designed for other markets.

Banks and such can pay the luxury of have everything running with J2EE, but that doesn’t work when you try to go smaller and agile. (mostly based on experiences with the market flow in Argentina).

AkitaOnRails: It is even more daunting considering that you decided that you wanted Ruby on Windows, you probably didn’t find anything reasonable and decided to tackle the problem yourself. Is that how it happened?

Luis Lavena: I’ve been forced to use Windows for many years, mostly related to hardware development in the video broadcast field. Moreover, I’m a BSD user and Linux one, even played some years with Macs and lately with OSX.

So that restriction forced me to build most of my tools around that limitation.
Ruby allowed me to enjoy that limitation by being expressive, which made me more productive in that field.

Ruby is not capable of handling my main requirements for video processing, but it still powers 70% of my environment, along with Open Source Software and Freeware.

I’ve been using Ruby for so long, that I thought the community, now that it’s growing, would maybe value the experience and the willingness to help in this particular scenario.

So instead of just scratching my itch in the shadow, I decided to contribute back and help others that search for the same stuff. So you can say I’m trying to balance my karma.

AkitaOnRails: Americans probably don’t understand this but in emerging countries such as Brazil, people don’t actually have much choice, most are not educated enough (cof english cof) and so they find lots of barriers. The last resort for everybody is Windows. I think it is the same thing in Argentina. Railers here don’t simply migrate to Macs or Linux, I would say that at least 90% of all developers are locked in to Windows for one reason or another. Is it the same in Argentina, I presume?

Luis Lavena: Even though I don’t like it, I must agree. Thankfully the Universities started to change that some years ago, giving talks and been more open to Linux community, which grew a lot.

Still, there are plenty of users and developer that are locked in to some corporate / mid-size environments or they require to run Windows for some proprietary hardware or such.

So, we (as the community) can’t get to those developers without being more open minded or provide tools that ease the path between their current environment and alternative tools.

AkitaOnRails: But for some reason there seems to be near to zero interest from the community on supporting Ruby on Windows. I mean, there are people like you, some RubyGem developers who go through all the trouble of making available a binary for win32, but it is not enough it seems. How did the One-Click Ruby Installer begin, did you create it or you inherited it?

Luis Lavena: Yeah, I agree with you, but I cannot blame them, after all, everybody just scratches their own itch ;-)

I’ve inherited One-Click Installer from Curt Hibbs, who also inherited from Andy Hunt and other contributors.

The truth is that for many years I’ve been using my own version of Ruby, compiled in-house, so we had control over it. We didn’t patch it in any way, we like to have the whole process documented and automated, so we can take a look to the specific components updated that introduced conflicts.

One-Click Installer, on the other hand, relies on some builds made by the current ruby-core developers and maintainers, which make the process of finding the proper dependencies a bit hard. That build also imposed other problems, but that will require more time to explain

AkitaOnRails: Haha, I want to dive in to the more technical stuff so people can better understand the current situation on Windows. How different is Ruby on Windows compared to Ruby on Linux, for instance? The most obvious thing is that any Gem with C Extensions without proper binaries for Windows will fail. Trying to execute shell commands will fail and RubyInline as well. What else?

Luis Lavena: Hehe, that’s just the tip of the iceberg, let me show you one example. Let’s say that you have a package ABC that was built for your current distribution of Linux. That specific version of Linux links to a common runtime that handles the basic commands like file handling, console, etc. That is often called CRT (C Runtime) and on Linux, glibc.

So, your distro of Linux is linked to this glibc version A.B.C. If your distribution upgrades glibc version (like from 2.2 to 2.5) then you’re forced to:

1. upgrade all your installed packages, or
2. build everything from scratch.

I’ve even heard of some of these upgrades go so bad that users are forced to start from scratch. Windows, on the other hand, cannot break 2 billion applications just because of a change of CRT, so they keep old versions and maintain compatibility in the MSVCRT.dll file (where the base version is 6.0).

A plus for Windows is that you can have several CRT co-existing in your OS, the bad thing is that you cannot safely link to one CRT and use components that link to another version without worrying about segfaults and such stuff.

I tried to condense this information in a post some time ago. So you can see, the lack of development tools is not the worst problem dealing with Windows development.

AkitaOnRails: Interesting. And another thing is the Visual Studio compiler vs MinGW. Can you give us a glimpse on why you chose MinGW? Is it just because VS is commercial and developers would have to pay?

Luis Lavena: Visual Studio is great, but only when you can pay for it. The free versions lack some stuff that is very useful, like Profile-Guided Optimization (PGO) which is being used to build Windows binaries of Python, as an example.

The thing with VS, even the free versions, is that you’re not allowed to distribute them, I think it is even illegal to link to the download URL/page of it. So even for our automated sandbox project, Visual Studio would be required to be manually downloaded, installed and configured.

Thankfully in the latest versions you don’t need to install Platform SDK kit, which was 1GB. VS versions link only to the latest version of MSVCRT, which then force us to relink every library that ruby depends on with it (and Ruby source code depends on lots of externals).

Also, Ruby doesn’t use the safe CRT version of string copy functions, so you need to use a compiler flags just to avoid them… So after weeks of hard work getting it built with VC8 and every dependency, you end with something that performs almost the same, since there is no performance gain (but now you have less hair).

MinGW, on the other hand, was closer to a Linux environment, so most of the tools worked out of the box. The good part was that we didn’t need to build all the dependencies with it, since by default everything links with MSVCRT (the default CRT on Windows). MinGW also provides some cross-compilation tools that lets you build, using Linux environment, shared libraries (dll) and executables for Windows.
I can consider that a plus, dunno what others think about it

AkitaOnRails: Wow, this is really overwhelming and I recommend anyone interested in the details to take a look at your blog. But all that said, you now have everything in place, a proper process and such, I assume. If I am a Windows C developer and I want to contribute, where should I go first, I mean, so I can know what tools to use, how to build stuff and so on?

Luis Lavena: That’s the good part! Gordon Thiesfeld and I have been working on two packages for new One-Click Installer: Runtime and Developer Kit.

Runtime ships the minimum Ruby+RubyGems so you get started, and it can also be used as modules for other installations. The DevKit provides the MinGW environment so you create Ruby extensions or even install the ones that are not pre-built for Windows but they are easy to get it.

This DevKit will not only let you get easily working with Ruby on Windows (and have access to some great and cool Rubygems) but also lets you contribute back to Ruby project. How? Easily, the Ruby Installer project (on Github) is self-hosted. What does it mean? It is possible for you to replicate our development environment anywhere, hack your changes or even debug Ruby’s own C code and contribute back to the community. We have been doing that for several months, and it’s working, how cool is that?

AkitaOnRails: That sounds awesome, I didn’t know that, and I bet lots of developers didn’t also. So I hope C developers reading this can get up to speed with this now. Another detail: RubyGems. How difficult is it to port a Gem with C Extensions to provide a Windows binary when you install it?

Luis Lavena: Oh, that requires that some developers don’t fall into platform specific tricks to make their tools work. One example, that is also a bad practice, is to use hardcoded paths…

Another one is to rely on the existence of some external tools, which sometimes are not available or developers/users didn’t install it. And I’m not talking about Linux-Windows platform issues, even between Linux distros that is a problem.

Installing Gems on RubyInstaller from Luis Lavena on Vimeo.

AkitaOnRails: So it is pretty much dependent on the quality of the original Gem, right? The cleaner the code the easier to port it, of course. But does your DevKit provide some shortcuts to achieve that? And what about RubyInline, does it simply break down?

Luis Lavena: Yeah, I’ve learned over the years that you shouldn’t assume anything about the environment your application is supposed to run, in that way, you avoid those mistakes.

Thankfully RubyInline is playing nice with Ruby Installer (One-Click Installer that uses MinGW) for a few versions back (Thanks goes to Ryan Davis to include those patches).

The current, VC6 build of One-Click Installer is not safe, since you need VS6 to work, which is no longer available. I’ve heard of users enjoying Sequel, Ambition and ImageScience on Windows thanks to those patches.

AkitaOnRails: Correct me if I am wrong, but isn’t it a way to embed C code snippets mixed in Ruby code? This means it will natively compile this snippet to run? How does it achieve this in a Windows environment that doesn’t have compilers by default?

Luis Lavena: We managed to sneak some patches to Hoe and RubyInline that “bundles” the pre-built extensions into the gems, so users don’t need a compiler in those cases.

Anyway, right now using VC6 build of Ruby requires man power to maintain those gems and keep up with new releases, which takes time. Up until now I was the only man in the show (since we own some VC6 licenses). Building everything for everyone is a burden I’m looking forward to drop into DevKit.

AkitaOnRails: Are you the ones maintaining the Windows versions of Gems or each Gem developer takes care of his own project? Is there a central repository for Windows-ready Gems? Is the DevKit already available, by the way?

Luis Lavena: For some projects I’m the only one maintaining gems for Windows, for others I only had contributed patches and other users manage the builds. There is no central repository for Windows gems since I want RubyForge to be the central one.
In any case, I’m pushing MinGW specific ones based on github forks here:

gem list --remote --source http://gems.rubyinstaller.org

The devkit is already available, but we are wrapping it into a good Windows Installer package. You can get your hands dirty and grab the sandbox project from Github to get your environment, or simply download the packages.

AkitaOnRails: So, as far as tools and processes are concerned you're doing a great job. But then there is the Ruby code that, by itself, is a big challenge from what I hear. You mentioned to me that it doesn't even look like C. What are the biggest problems? Technical or getting help from the Ruby-Core mailing list, or both? And what about test suites, how are you squashing compatibility bugs?

Luis Lavena: To be honest, sometimes peeking into Ruby C code gives me headaches. There are lot of macros and definitions and macro conditions that happens in the middle of a if .. else block… The hardest part, besides tracing the bug is getting feedback from ruby-core. Several times I've expressed my concerns about it on mailing lists, #irc and on my blog.

Several times I asked if it was OK to get some errors in the unit tests of Ruby itself and sometimes got answers, but sometimes didn't. Thankfully we no longer need to base our testing quality in bundled unit tests of Ruby. We started to find issues with the Ruby implementation on Window using the Ruby Specs created by the guys at the Rubinius project and that most of the Implementations (IronRuby and jRuby) actively contribute and use as foundation of their interpreters.

AkitaOnRails: So, speaking of which, RubySpecs how far is Ruby on Windows from passing it through? Or is it already?

Luis Lavena: Well, that's a big tasks. First we started making MSpec to work properly on Windows, since RubySpec require some audit to remove some hardcoded paths in it. So we started to add guards around things that are not supported or don't even work on Windows in MRI.

That takes longer since we need to review the results on each platform, dig into the Ruby documentation (that is sometimes lacking) or take a deep breath and look at the C code to find what is actually doing.

If we had more man power, maybe we could finish guarding all the code and get a clear running specs on Windows. Right now there are many that just break or segfault.

AkitaOnRails: You should document this process so people can help, if you didn't already :-) Now speaking of more practical stuff: Ruby on Windows, today, is it a viable runtime to run Rails apps on Windows? Even production apps? You worked with Zed Shaw on Mongrel for Windows, right? Did you try the newest FastCGI support from Microsoft for IIS?

Luis Lavena: Hehee, documentation, documentation, it's totally overrated. We planned to have several screencasts in the RubyInstaller website, but it just remains as 'coming soon' for now.

Not only you can develop Rails applications in Windows (as I do too), but I know several companies that run it side-to-side with IIS or even Tomcat.

Even 2 years after Zed created it, Mongrel still rules the scene of Ruby web servers. I didn't do too much to Mongrel itself, since Zed created something that worked out of the box on Windows with small tweaks.

I created something to run Mongrel as a service (mongrel_service), which helped several people to sneak in Ruby and Rails into their corporate environments, even talking to MSSQL Servers.

I personally didn't test the FCGI support on IIS, but I was the one fixing it to be bundled with One-Click Installer so some users could enjoy it. We could say it works.

AkitaOnRails: About performance, Windows seems to have an inherent condition: in the same machine when I start, let's say, a simple IRB in Windows, then I dual boot to Linux and run it, it seems to open up much faster (not exactly a scientific experiment :-). What is your experience around Ruby performance on Windows?

Luis Lavena: There are performance issues related to the C code being generated by the compiler, and issues related to the OS and I/O handled by it. Loading IRB on Windows could be requiring RubyGems in the background, which in turn needs to scan and load all the gems specifications. I try to keep RUBYOPT=rubygems out of my environment variables.

AkitaOnRails: By the way, why I have the impression that I see RUBYOPT=rubygems being recommended in every windows tutorial I see?

Luis Lavena: RUBYOPT=rubygems is the part of the magic we must avoid.
On Linux, if you start creating a script and you need a gem, you start with:

require 'rubygems'
require 'some_gem'

The same should be done for Windows, it is not painful, it's good practice. RUBYOPT is a shortcut that I dislike, I haven't seen a Linux distro that enables that by default, and I dislike that being set on Windows. (of course, that's my personal point of view)

So to avoid falling into standard testing procedures, I keep using a simple but good sudoku solver that exercise recursion, array and conditions of the VM instead of being IO bound.

You can see that, with funny results on my blog (see "Rubinius, RubySpecs, and speed." section of the post).

The main thing is that VC6 make it slow. Then you have I/O bound stuff (I/O stuff on Windows is not as good as Linux). I consider the default VC6 build of Ruby on Windows painfully slow. On the other hand, the MinGW one is snappier but I still think that there is a huge path for improvement.

AkitaOnRails: So, overall, Ruby on Windows is always evolving which is great, runs great on Windows, which is remarkable, but it could use some more help, right? Do you think more Windows C developers would help? I mean, adding more hands would help improve its quality?

Luis Lavena: Definitely!

AkitaOnRails: What kind of developers, I mean what one should know to help?

Luis Lavena: Dunno if Ruby "core" will accept that, I lately only hear the fork word around MRI ruby. Moreover, we can squash bugs in the Ruby for Windows implementation, but we cannot improve the quality too much since those changes would affect other platforms too.

The bad thing is that there is no clear separation by platform of specific code, everything is around a series of macros and compilation conditions that makes it hard to track (for the non-sadistic developers).

AkitaOnRails: Which reminds me of the Phusion guys with their Enterprise Edition which is a fork of MRI. Did you try to take a look on the copy-on-write GC patches from them? Maybe have it on the Windows version? Ruby on Windows itself is a 'fork'. You end up having to synchronize your trunk with theirs, is that how it works?

Luis Lavena: Honestly I didn't have time to look at Enterprise Edition, even though I followed all the posts and the discussion of those patches in ruby-core. The funny thing is that the latest releases of the Ruby 1.8.6 branch are giving me headaches (more than looking at the C code). They cannot even complete the self-tests and segfault with some extensions like the mysql gem.

AkitaOnRails: Yes, it has been causing a lot of fuzz around the community, and it should. Hope they can get around it soon. Well, I think I already took a lot of your time. Is there any subject you would like to tackle, or at least some message for your younger brazilian community?

Luis Lavena: Yeah, don't be afraid to ask questions, don't feel ashamed for using Windows as Platform. You can accomplish great applications using Windows, and you can infiltrate more easily into corporate environments with it.

AkitaOnRails: Oh, which reminds me of one last question that everybody asks me all the time – and I shall forward it to you, as you're a Windows developer: what are your tools of choice to edit Ruby/Rails projects?

Luis Lavena: I mostly use Free or Open Source stuff, so I've been using Komodo Edit (not Pro) and Programmer Notepad, since sometimes I use them to work on C, FreeBASIC and Assembler code for embedded hardware.

Lately I've been using a lightweight Editor called Intype that ships with some bundles to mimic TextMate, but I really don't take advantage of them. I used NetBeans for a while, but after 500MB I just closed it :-)

AkitaOnRails: Haha, and what would you recommend for a beginner Rails programmer?

Luis Lavena: To get started NetBeans is good, but with practice they will learn that even notepad is enough to code.

(PS: We are already including Enterprise patches for latest issues on MinGW build! :-)

AkitaOnRails: Haha, right. Well, I think this is it. I think this will reach a broader audience and call the attention of Windows developers out there. Thanks a lot!

Luis Lavena: Thanks to you Fabio.

AkitaOnRails: So, let me first explain that my main goal when I interview high profile people like you is to bring good information for our growing Rails community in Brazil. It is always good to ask about your background, how did you get into Rails and what was your experience with it.

Blaine Cook: I started with Rails on a small personal project back in December 2004, after Evan Henshaw-Plath (rabble) got really excited about Ruby & Rails.

Shortly afterwards, I started working on Odeo. I really like Rails, and I’ve really enjoyed my experience with it. Building web-apps used to be a real pain (i.e., boring) because you ended up building the same pieces over and over again.

Rails fixed that. There were frameworks before, but Rails reframed the question in a humane way, and we see that in all the other frameworks that have been created afterwards.

AkitaOnRails: So, what were you doing before Rails then? Enterprise Java? Microsoft stuff? Other open source projects?

Blaine Cook: I mostly did PHP and Perl, in the context of open source projects and consulting jobs.

AkitaOnRails: So, Odeo and Twitter are your biggest projects in Rails then? Before digging into Twitter, can you tell us how was your work for Odeo?

Blaine Cook: Sure – Odeo was fine – the big problem there was with focus. Podcasting hadn’t been proven (and the form that podcasting takes now is much different than what people envisioned in 2004 / 2005), so it was a struggle to gain traction for the product.

We had all sorts of cool things built, many of which are just becoming products now. Things like multi-track mixing on the web, video messaging (like seesmic), etc.

AkitaOnRails: This is an interesting side-subject: podcasting. I do a Brazilian Rails podcast with a friend and nowadays people are very acquainted with podcasts. What was the vision 3, 4 years ago about what podcasting would become?

Blaine Cook: I think that’s fairly similar, but it seems like most of the traction (i.e., listeners) for podcasting is established thru radio shows that are seeking a wider distribution.

I think there was a sentiment that podcasting would be much more popular amongst bloggers in general. Everyone was going to have a podcast.

But in reality it’s a medium with far fewer publishers than blogging.

AkitaOnRails: You helped start Odeo, I mean were you one of the creators? Or were you hired to solve their problem? And why did you leave Odeo?

Blaine Cook: No – I started at Odeo a few months after development had started. I never really left Odeo – the product was sold, and the company continued on as Obvious. Twitter was a side-project at Odeo.

AkitaOnRails: Ok, and Twitter is big nowadays. Could you give us a glimpse of how the whole idea of “What are you doing” started? Did you think at that time that it would become such a success as it is now?

Blaine Cook: Twitter was started as a side project at Odeo, but really it was an idea that Jack had been kicking around in various forms for several years.

He and Noah Glass (the founder of Odeo) created a small sub-company within Odeo to work on it, in spring 2006. Initially, I hated the idea, mostly because it was intended to be SMS-only.

It’s hard to say looking back, but at the time I’d say Twitter was a long shot; I think that its success had a lot to do with luck and openness.

AkitaOnRails: So, maybe one of the biggest reasons for Twitter’s success was also its Achilles’ heels? I mean the paramount API based access it has today?

Blaine Cook: Yes, absolutely.

AkitaOnRails: So, getting to the hairy stuff, it is quite obvious that Michael Arrington dislikes Twitter, period. And especially he has something against you personally, at least considering the tone of his articles on Techcrunch. Can you comment on that?

Blaine Cook: Not really; I don’t know why he has a grudge. It’s mildly annoying, but in the end it makes Techcrunch look more like a gossip rag and less like a respectable news outlet, so it’s his loss.

AkitaOnRails: And not only that but it also seems that some tech related news media wants to correlate Twitter’s instability with the fact that part of its front-end is powered by Ruby on Rails, hence the discussion “Does Rails scale?”. As a Railer this seems quite obvious that relating Rails and instability generates lots of pageviews. Do you think that’s the case?

Blaine Cook: I think that’s at least part of it. Obviously page views are a huge draw.

AkitaOnRails: Maybe it would be good for someone like you to explain to our audience the difference between ‘performance’ and ‘scalability’ as it seems that most people don’t know the difference between the two.

Blaine Cook: Performance and scalability are very different things. Performance is like the speed limit; it’s a question of how quickly you can get from point A to point B. In this case, we’re talking about how quickly you can get a page rendered and delivered to the user.

Scalability is a question of how many users you can handle. Highways intrinsically don’t scale, for example, because when they’re full, you get traffic jams. In web architectures, what we aim to provide are systems that will expand (usually by adding more hardware) to handle more traffic.

Obviously they’re related – if you have a traffic jam, then the effective speed limit is lower than the theoretical limit. But increasing the speed limit won’t make traffic jams any better.

There are a whole bunch of ways to make traffic less congested – adding more lanes to the highway, encouraging people to use public transit, or better yet encouraging people to work closer to home.

Likewise, there are many techniques for making web sites more scalable, and most of them don’t involve making things much “faster”.

AkitaOnRails: Great explanation. Twitter was involved in some not very good controversy since last year, and I think you were not involved in most of them, but maybe you could shed some light on those issues as some people don’t follow every news story all the time. The first one being that interview where Alex Payne complained about Rails not supporting multiple databases. David Hansson ranted about it. Then Dr. Nic came to the beginning of a solution. Can you explain this matter for our audience?

Blaine Cook: Sure – it’s true that Rails doesn’t support multiple databases out of the box, but this is easily fixed. I think the interview with Alex didn’t get into the details very well, and mis-represented our challenges.

If it was just a matter of supporting multiple database connections, that’s something that’s easily solved. The real problem was much more complex, and had to do with custom sharding for our particular dataset.

Eran Hammer-Lahav has an excellent series (parts 1, 2, 3) in which he describes some of the challenges associated with building microblogging sites to scale.

None of the things he describes in the article are hard to do with Rails. In fact, I think that David (Hansson) is wrong when he says that Rails isn’t flexible – it’s actually much more flexible than most other frameworks.

AkitaOnRails: That’s right. And then the other recent controversy is, of course, because of TechCrunch again, where they state that Twitter only has like half a dozen servers and that’s why it falls down frequently. Can you roughly describe how is Twitter’s hardware architecture?

Blaine Cook: Twitter has a lot of servers, definitely more than half a dozen. I can’t go into more detail about the hardware setup, but I can say that the back end is an asynchronous messaging-based system. Starling (the queue server that I wrote that Twitter released in January) is the mechanism used to pass messages between processes.

The biggest problem is that Twitter deals with many, many often expensive API requests due to the frequent polling required to stay up to date with your friends’ most recent tweets. The big challenge was to come up with an inexpensive way to make those expensive API requests cheap.

We used memcache extensively, and had a whole bunch of caching in place well over a year ago, but it wasn’t enough.

AkitaOnRails: Last year Alex and Britt spoke at RailsConf I think about Scaling Rails where it felt like Twitter’s problem would end soon. It was mostly about caching and optimizations like that, and one of the main messages was “cache the hell out of it”. I saw you speaking this year about database sharding and how different it is to architect for 1k people and for 1 million people and that you can’t predict what to do before that. Twitter still goes down sometimes, so what changed between last year and now about Scaling Rails?

Blaine Cook: Yes – we knew for a long time that database sharding was important, but for various reasons weren’t able to move forward with it.

The thing with sharding is that until someone comes out with something like what Google has (and I don’t mean Bigtable), the sort of shape your application takes before sharding is very different than the shape afterwards. Sharding makes doing some things harder, and is generally expensive.

When people say “sharding” or “denormalization”, what they mean is “duplicating data in particular ways to make certain lookups faster.”

That always involves additional cost. If you’re building a new app that will either never see hundreds of thousands of users, or if you don’t know if it will or not, it’s generally not worth sinking lots of money into hardware and engineering time to build a “scalable” architecture.

The reality is that most developers know SQL and can build CGI applications using PHP or Rails or whatever, but relatively few have experience taking those straightforward, normalized data sets and breaking them up into much more complex sharded systems.

AkitaOnRails: Of course, sometimes people feel like they will actually build the ’next’ Twitter. I interviewed Ezra, from Engine Yard, at RailsConf and he seems to acknowledge that the friends-of-friends graph is a problem so complex that whoever figures it out will make a ton of money I mean, isn’t it the case that traditional SQL designs don’t work all the time?

Blaine Cook: Of course – the question is, what else are you going to use? Google has an architecture that lets them spend infinite amounts of money to build denormalized lists of everything, and access those lists quickly. There are a number of projects – HBase, Hypertable, CouchDB, and many others – that aim to solve these problems, but none of them are ready for production use.

The reality is that 10 years ago, people were building web applications with tcsh, and now we have better tools.

AkitaOnRails: Where is Twitter hosted? For some reason I saw Engine Yard pitching a lot about scalability issues throughout the whole RailsConf this year. Do you think this whole “Rails doesn’t scale” meme is making Railers worried about future prospects? Even though it was not supposed to scare that much as we do have higher traffic websites such as Scribd and YellowPages in the top of the list – though the architectures are world apart, of course. What do you think about this issue?

Blaine Cook: I’m not sure, but I think Twitter actually does more traffic than YellowPages or Scribd; the API is a real killer.

AkitaOnRails: Ah, I see, Alexa and others don’t account for API request, right?

Blaine Cook: Twitter is hosted at NTT / Verio. I think there was a blog post about it in February. Right, Alexa doesn’t account for API / SMS / XMPP traffic at all.

As far as the perspective that Rails doesn’t scale – I think it’s an unfortunate side-effect of Twitter’s issues, to be sure, and I think some people worry about it. To put things into perspective, though, Friendster was written in Java to start, and switched to PHP. Myspace was written in ColdFusion and transitioned to ASP.NET.

When people run into problems scaling sites they often think that the language is the problem, but I think it’s rarely the case.

Ruby is slower than PHP or Java (depending on which framework you use) or, well, most languages, but it’s getting faster. And “slower” really only translates to additional cost.

AkitaOnRails: Which reminds me of the last controversy which was Twitter switching off from Rails. The case is that you already have a mixed environment, right? Most pundits think they ‘know’ how to solve Twitter’s problems, though they have absolutely no idea what they are talking about. Some blame Rails, others blame MySQL (“go to Oracle”, they say). Can you elaborate on that?

Blaine Cook: Right – the majority of our development was in Ruby / Rails, but there was code in other langauges. Python, Java, and there were some experiments with Scala. Which ignores the fact that we ran significant portions of our infrastructure on non-Ruby code – Apache, Mongrel, MySQL, memcached, ejabberd, etc. are all great applications and critical to building scalable sites.

Oracle definitely has some of these things figured out, but it’s much easier to hire for MySQL, and Oracle licensing and support fees are nothing to scoff at.

Building your architecture around a system that will only get cheaper with time, rather than more expensive, is always a good idea.

AkitaOnRails: And I have to ask, can you disclose some meaningful numbers, or orders of magnitude, such as tweets per day, average downtime, or something like this, just so we can have an idea of the size of Twitter’s problems? Coming from someone that has actually had to deal with such a huge situation – which most people probably will never have to face -, what would you say are Ruby/Rails’ strongest features for you?

Blaine Cook: Sadly, no – there are plenty of estimates on the web, most notably compete, and Dave Winer’s fan-out numbers.

I think Ruby’s best feature is that it’s fun to develop with. It never stops being fun, either. It’s an expressive and powerful language. Rails just makes web development painless, compared to doing everything by hand. That’s something that shouldn’t be underestimated, or whose value forgotten.

On top of that, they’re really flexible. We needed to build a denormalization tool, for example, and doing it in Ruby was just as easy / hard as any other language, except when it came to tying it in to the rest of the system – no search and replace, no subclassing or anything. Just turn it on, and it works.

AkitaOnRails: Finally can you tell us why you left Twitter? What are your new endeavors? Twitter survived WWDC last week which is saying a lot considering such huge events would usually bring it down in the past.

Blaine Cook: I’m moving to the UK, and Twitter is / has moved into a position where their primary focus is reliability. When I left, the hope was that their system was stabilized, and the roadmap was clear as far as putting them in a better position overall. At the time, they’d had an extended period of uninterrupted uptime, and had survived with flying colours SXSW. Unfortunately, it didn’t last, but it looks like things are better again.

I’m not yet ready to reveal what’s next, but I have a number of exciting things going on. I’ll continue maintaining Starling and xmpp4r-simple, and I’m still active with the OAuth spec. working group.

AkitaOnRails: In the end, Twitter became almost part of our culture already (at least in our tech world). People complain when it is down because now they depend on it so much. People like Michael Arrington, Robert Scoble, Leo Laporte are always complaining, saying they would move to Pownce or Jaiku, but they are still around. Do you have any guess on why Twitter users are so loyal?

Blaine Cook: Nope! I think the really rich landscape of tools that you can use to interact with Twitter on your own terms is a really big part of it. A lot of the users are personally invested, and they want to see that investment pay out.

AkitaOnRails: Ok, I think this covers everything. Any closing remarks for our young Brazilian Rails community?

Blaine Cook: The web is remarkably young, and there’s plenty of space for really amazing things to happen. I’m always excited to see what people are working on, and what’s possible with this whole Internet thing. For all of Arrington’s petty and misinformed comments, I think sites like Techcrunch and Mashable and Silicon Alley Insider are interesting because they present a never ending stream of amazing things that people are building on the web.

The financial focus is unfortunate, as there are plenty of apps that survive and provide income for their founders without ever needing to scale to galactic proportions.

The bottom line is that there’s plenty to do, and don’t worry about scaling or business model or anything – unless you’re passionate about what you’re doing, none of it matters.

If you are passionate about what you’re doing, there’s a really good chance you’ll figure the details out.

AkitaOnRails: Fantastic! Thank you very much for your kindness, I am sure my audience will enjoy it. And just to let you know that we, Brazilians, do tweet a lot! :-) Thanks!

Blaine Cook: Excellent, glad to hear! No problem, thanks for being a great interviewer.

Hongli Lai and Ninh Bui , from Phusion, shook the Rails world a few days ago. They unleashed the Holy Grail of Rails deployment: mod_rails which was received with much fanfare, and they deserved it.

They finally settled the big issue that embarrassed Railers in the past. This will also relieve dozens of hosting services that were clueless on how to solve this equation. Now, those two computer science students are above them all with this clever solution. And they have more to come.

I was very fortunate to be able to interview them. I think this is the second interview, InfoQ broke the news first with this other interview which I highly recommend to understand more of the inner gears of Passenger. They are very easy going and it was a pleasure to talk to them.

AkitaOnRails: I think the first thing I’d like to know are your backgrounds. Which one came first? mod_rails or Phusion? Meaning, did you have a company named Phusion that ended up developing mod_rails, or mod_rails was the reason to build a business around it?

Phusion: Well, as you’ve probably read by now, we’re both computer science students at the University of Twente and we’re currently in the final stages of finishing our bachelor degrees. From the beginning, we had already inferred that study can’t teach you everything, so over the years, we’ve also been doing a lot of work both commercially as well as for the open source community.

After becoming familiar with each others skills, philosophies and personal traits and from our past experience in working in IT, we thought it would be a good idea to combine our forces into a company that we could call our own, and so Phusion came to be.

So Phusion actually came before Passenger (mod_rails). More specifically, our intent was to start a company that strictly provides top-of-the-bill IT products, ideas and services to support our clients’ businesses. Passenger coincidentally happens to be our first product, and from what we’ve been hearing from both the community and companies, it seems to be perfectly in line with our company’s philosophy.

Also, after doing years of (web) development in other languages/frameworks such as PHP, J2EE, ASP.NET, etc. we’ve really come to appreciate Ruby on Rails. We think it’s really elegant and easy to use. Unfortunately deployment seemed to be out of line with the rest of the Rails experience, especially the convention over configuration part. This is why we’ve created Passenger: we want the deployment experience to be just as smooth.

AkitaOnRails: Is Phusion a consulting company or a product company? Right now you released one of the most interesting projects in Rails land so far, which is mod_rails. Now you’re preparing to release Ruby Enterprise Edition. Any new products in your pipeline that you could tell us about?

Phusion: Well, Phusion is primarily a service oriented company and we think our mission statement answers this question best:

“To exclusively provide top-of-the-line products, services and ideas, in order to support our clients’ businesses.”

If our clients’ businesses require consultancy, then we’re able to provide that as well seeing as we’ve had quite a few years of experience in that particular line of business.

In order to achieve this mission, it is crucial for us to be well-versed in a variety of skills and we’re well aware of the saying “jack of all trades, master of none”. It is for this reason that our team comprises of only highly skilled people from those parts of the industry that are of particular interest to our clients’ businesses. The reader will probably note that this allows for a dynamic configuration in organization as well as keeping the work challenging: we don’t believe in keeping people around forever for no rational reasons, so it is crucial for our employees to keep learning within our organization (hence the alias, “the computer science company”). This not only opens up a lot of doors on the innovation side, but also results in people becoming masters in several areas. So “jack of all trades, master of none” may hold true, we believe “master of a lot of areas” could just as easily hold true. Needless to say, this is crucial since computer science and IT cover such a wide area, and this particularly holds true for our clients’ businesses.

Ruby Enterprise Edition has actually been called to life as a result of Passenger: it strives to dramatically reduce memory usage of Ruby on Rails applications that are run through Passenger.

As for new products, we’re currently working on a few subscription-based web services. Our friend David Heinemeier Hansson has recently given a talk on startups which elaborates on the reasons why one would want to follow such a path. We’d highly recommend the reader to check that out and for strategic reasons, we’d like to leave it at this for now.

Hongli Lai

AkitaOnRails: For a long time the whole Rails community was rather too much comfortable with the Mongrel solution. When Zed Shaw ranted about the community, it was a wake up call and from there we saw alternatives emerging overnight such as Thin and Ebb. What did you think about that situation back then?

Phusion: From what we understand, solutions such as Mongrel, Thin and Ebb fall under the same conceptual category. That is, for the end-user, they work in a similar way, even though they are technically different. In other words, Thin and Ebb seem to be like “Mongrel, but faster/smaller”.

Passenger however has taken an approach to deployment that’s different from Mongrel et al: it intends to make deployment as simple as possible, and to lower system maintenance overhead as much as possible. For example, while Passenger handles this automatically, Mongrel, Thin and Ebb all require the administrator to manage clusters. As you’ve stated, the tech savvy have already become quite familiar with the latter, but one also needs to take the newcomers into account. For them, it’s quite an obstacle to overcome to just simply deploy an application. If we were to consider the backgrounds of these newcomers, many of them are probably already familiar with the PHP way of deployment, that is, in an upload-and-go manner. With Passenger we’ve tried to accommodate these people, as we think that this is important to the growth of the Ruby on Rails market. That doesn’t however say that we haven’t taken issues such as robustness, performance and stability into account.

As a matter of fact, independent tests have already shown that Passenger is on par or faster than the aforementioned solutions. Another problem is that shared hosts are already running Apache as their main web server, and we’ve already seen what configuration needs to be done in order to get a Mongrel cluster up and running with Apache… Needless to say, this is quite tedious and error-prone, even for many tech savvy to say the least. Passenger literally reduces this process to a matter of seconds instead of minutes. This should not only save a hosting company a great deal of time but should also keep their server administrators sane (and from our experience, they’re the last people you want to offend ;-)).

Also, setting up a Mongrel-like cluster requires quite some resources on a shared host, and it is for reasons such as these that the costs of shared Ruby on Rails hosting plans are usually higher than that of PHP hosts. Passenger however, takes on this issue as well by providing improved efficiency over the aforementioned solutions, especially in conjunction with Ruby Enterprise Edition. Early testing has already shown that the latter has resulted in a dramatic reduction in memory usage and we’ll elaborate on this soon.

If we consider these factors, it becomes apparent that Passenger (in conjunction with Ruby Enterprise Edition) has the potential to unleash a revolution within shared hosting. Not only in cost-reduction for hosting companies (and hopefully consumers), but also in increasing the popularity of Ruby on Rails.

AkitaOnRails: mod_ruby seems to have stalled for a long time and needs some love. It is said that it works reasonably well for small websites but lots of ‘black magic’ in Rails makes it not suitable for mod_ruby. What makes mod_rails different than mod_ruby, in the fundamental way they operate with complex frameworks as Rails?

Phusion: We’re not really able to comment on that, because we’re not intimately familiar with mod_ruby. However, mod_ruby is not actively maintained, and there are a lot of negative comments about mod_ruby in general (such as on the Ruby on Rails wiki). It also seems that nobody really uses it. It is for these reasons that we’ve never really given mod_ruby a try.

From the aforementioned and what people often tend to forget, is that only delivering a(n excellent) product will not suffice. Marketing and promotion are really important for a product’s acceptance. We’ve not only done a lot of development, but also spent a lot of time in promoting Passenger. The fact that we’re having this interview right now is probably the result of our promotion campaign, so we’re quite happy with that. In this regard, mod_ruby doesn’t seem to be actively promoted, and perhaps this is one of the reasons why it’s relatively unknown.

AkitaOnRails: why do you think it took so long for someone to come up with a solution for an Apache module that could operate similarly to the usual mod_php or mod_python? What did you think was the most challenging aspect in the development of mod_rails?

Phusion: Well, as you’ve stated, we believe that experienced Ruby on Rails developers don’t consider deployment to be a problem; probably annoying at most. They’ve automated/standardized the deployment process for a great deal with Capistrano scripts. Newcomers however see deployment as an insurmountable problem. Consequently, we end up having a situation in which the people who can solve the problem either don’t see a problem or aren’t motivated enough to fix the problem, while the people who do see the problem cannot solve it.

Furthermore, from our personal experiences, newcomers usually want to see immediate results. It’s very demotivating for those people to continue using Ruby on Rails if they have to manage tons of obscure configurations and clusters to ‘just successfully deploy an application’. This leads to very intelligent conclusions, such as that “Ruby on Rails sucks”. ;-)

The most challenging aspect is probably cross-platform support and to elaborate on this in a nutshell:

• We have to support a whole bunch of Unix-based systems, like Linux, BSD and OS X. Passenger works on a fairly low-level (i.e. it uses advanced Unix system features), and different systems tend to behave in subtly different ways such that they can break Passenger if we’re not careful.
• A lot of challenges are created by MacOS X and Apache. There are literally tons of different ways in which Apache can be compiled and installed, and this is especially true on MacOS X. Every single Apache installation can be slightly different, and we have to support all of them. We had to write hundreds of lines of Apache auto-detection code in order to make the installation as smooth as possible. And support for OS X-specific things such as universal binaries didn’t make the challenge any easier.

Ninh Bui

AkitaOnRails: the usual Shared Hosting approach with Rails involves FastCGI, I think that’s where mod_rails will make a big impact first. In the VPS arena people are usually more comfortable just loading up a mongrel cluster, maybe a monit or god to monitor them or even use Swiftply to better control mongrel instances. There’s some tweaking involved in having permanent Ruby interpretors running, that’s mainly because of the fact that if at some point the VM needs more memory, it will allocate as much as it needs, but not return it back to the OS. Does mod_rails have something to avoid a monitoring system like Monit or is it still needed?

Phusion: We’ve taken this challenge into account as well. Rails applications that have been idle for a while are shut down, thereby releasing all of their resources to the operating system. Furthermore, it is possible to use Passenger in conjunction with monitoring tools such as Monit. If Monit kills a Rails process, then Passenger will automatically (re)start it when needed, as if nothing bad ever happened.

AkitaOnRails: I understand that mod_rails operates more or less like a manager for a pool of Ruby VMs. You have a minimum and maximum number of processes allowed, mod_rails starts as many as it needs depending on load and if a process is sitting idle, it will kill it after a timeout period. Most of the time a minimum amount of processes will stay running. Is that how it operates?

Phusion: It is as you describe it, with the exception that there’s no such thing as a minimum amount of processes. The reason for this is that, once an application for a certain Rails directory is spawned, that application process cannot be reused for a different Rails directory. This makes the concept of a minimum amount quite useless, except in servers that only host a single Rails application.

Of course, not having a minimum amount of processes will mean that the first request after the idle timeout will undergo a performance penalty and be slow. We’ve solved this issue by using spawner servers. Spawner servers cache Ruby on Rails framework code and application code, and they can reduce the spawn time by about 50% and 90%, respectively. You might have noticed these spawner server processes in the output of ‘ps’. The secret in reducing spawn time would lie in altering the idle timeouts of these spawner servers. We are currently working on a series of articles, in which we elaborate on the spawn times of Rails applications, what the exact roles of the spawner servers are, and how system administrators can optimize server settings to reduce spawn time.

Much of the magic that resides in Passenger still needs to be unveiled and we’ve only just started, but this is mainly for the interested people out there, i.e. the tech savvy. There is a saying in Dutch that summarizes the thought behind why we haven’t done this up till now: “Goede wijn behoeft geen krans”, which would roughly translate to that a good product does not need any supporting elaboration. A scientific publication on the other hand does need this kind of elaboration and it is also for this reason that we’re writing these articles as well.

AkitaOnRails: By staying in the same memory space as Apache itself you don’t have the overhead of a FastCGI or HTTP call over to a mongrel instance. Does this difference account for much in your benchmarks? Usually, in your experience, how much faster is mod_rails right now compared to a bare bone mongrel cluster running the same apps? Are the gains in speed constant or it varies enough that it is not really measurable?

Phusion: This is actually not true: the Rails processes don’t reside in the same memory space as Apache. Instead, they really are separate processes, that each can be individually shut down without affecting all the others. It is not a very good idea to embed a Ruby interpreter in Apache because of various issues, such as stability, heap fragmentation and unnecessary bloating of a process’s VM size. From what we understand, mod_ruby takes the approach of embedding Ruby inside Apache, and we suspect that this is one of the reasons why people are reporting so many problems with it.

Our own tests have shown that Passenger’s performance is faster than a Mongrel cluster behind Apache+mod_proxy_balancer. Independent tests have shown that Passenger’s performance is either on par with or slightly faster than Mongrel cluster and this seems to be perfectly in line with what we’ve been able to infer. So far we haven’t seen any tests in which Passenger is slower than a Mongrel cluster. The speed gains are not constant: they are dependent on the specific application.

Phusion folks at Fingertips

AkitaOnRails: Ruby Enterprise Edition, for what I understand, is the outcome of that ‘copy-on-write’ series we talked about. Essentially a way to patch the Ruby VM to enable a modified GC that won’t mark every object, thus allowing COW to do its work and save a considerable amount of memory. You stated 33%. I would assume that it is ‘up to 33%’, right? What’s the usual range of saved memory you experience in your tests? What affects this the most in typical Rails apps, any gotchas worth mentioning for Rails developers?

Phusion: The mentioned 33% is not a maximum, but an average. We’ve tested with real-life applications such as Typo, and so far we’ve inferred an average memory saving of 33%. The actual memory savings is dependent of the specific application so your mileage may vary.

There are no gotchas for application developers. If their application works with Passenger, then Ruby Enterprise Edition will work as well, without any need for complicated configuration options. In other words, it’s a transparent augmentation. In any case, we can guarantee you that memory usage will be no higher than when you use standard Ruby.

AkitaOnRails: I understand that you will talk more about the Enterprise Edition at RailsConf but I was hoping that you could disclose a little bit more about it. You are just finishing the second batch of donations for Enterprise licenses (I donated! :-). First things first: when are you going to release it? Is this product supposed to stay commercial only or do you intend to collaborate the GC patch back to the Ruby trunk one day?

Phusion: Thanks for donating, and as for the latter: yes, it is our intention that it will one day be merged back upstream. The alert reader will probably notice that we’ve dodged one question like Neo dodged Agent Smith’s bullets in the Matrix: skilled, except for the last bullet, that one actually hit, but enough about that ;-).

AkitaOnRails: “mod_rails” is actually the alias for “Passenger”, some people are asking if this is going to stay Rails only or if you intend to make it Rack-compatible so other frameworks as Merb and Ramaze could run under its control. Is that possible? Are you considering it?

Phusion: Let’s just say that we would prefer you to call it Passenger instead of just mod_rails eventually. ;-)

AkitaOnRails: Apache is the powerhouse for Web servers and it makes a lot of sense for an Apache module like that. Maybe I am speculating too much, but do you think it is possible to refactor it into other web server’s modules like nGinx or Litespeed? Because of the lack of a good mod_rails in the past, the Rails community drifted away to other alternatives. Is it reasonable to expect non-Apache modules?

Phusion: It’s technically possible. To keep you guys in suspense and to keep you speculating on such matters, we won’t dive into this further for the time being. ;-)

Passenger being installed!

AkitaOnRails: The way it is right now, it feels like mod_rails is a drop-in replacement for whatever strategy we had before using Apache. Are there any gotchas worth mentioning for anyone planning to migrate? I think complicated mod_rewrite rules would be the first thing?

Phusion: There’s a minor gotcha. By default we override mod_rewrite the best we can. This is because Rails projects come with a .htaccess file by default, and this .htaccess contains mod_rewrite rules, which result in all requests being forwarded to CGI or FastCGI.

This is trivially solved by deleting the default .htaccess and by enabling a configuration option which tells Passenger not to override mod_rewrite. This allows the developer to use arbitrary mod_rewrite rules to his liking.

Other than that, the remaining gotcha would be that rails deployment has become quite boring thanks to Passenger, or so people say. ;-)

On a final note, we’d like to thank all you guys out there for the love and (financial) support on Passenger. We really appreciate it!

With kind regards we are, your friends at Phusion,

Hongli Lai

Ninh Bui

He answered everything in colorful detail and we speak a lot about his open source projects, performance, scalability and, of course, lots of Git and Github stuff. Hopefully it will make people even more excited about how the Ruby/Rails community is moving things forward all the time.

aos leitores brasileiros: assim que tiver tempo irei traduzir esta entrevista.

AkitaOnRails: Ok, so, where are you from?

Chris Wanstrath: Right now I live in San Francisco but I grew up in Cincinnati, Ohio. I moved to San Francisco in 2005 to work for C|NET where I did PHP for a while on sites like gamespot.com, mp3.com, and tv.com

In 2006 I moved over to the chowhound.com site within C|NET to work on Rails, which is something I had been doing on the side for a while. While I was there P.J. Hyett and myself worked on chowhound.com then built chow.com, which we launched later that year. Then in April of 2007 we both left C|NET to form our consulting company, Err Free.

In December of 2007 we launched FamSpam, which is a site for keeping in touch with your family. It’s basically a simplified version of Google Groups with emphasis on participating in a thread at least once a week and easily finding photos or other file uploads.

While P.J. and I were working on FamSpam, Tom Preston-Werner and I were working on GitHub on the side. We started in October working nights and weekends on it. We basically wanted an easy, pretty, and feature-rich way to throw our Git repos up and share them with people. Then as we got more into it, we realized how things like the dashboard could change the way we deal with open source contributions. After that, all the social features began to fall into place. Github private beta launched in january, and in april we saw the public launch

AkitaOnRails: Wow, Cool, you are a very busy guy indeed, I want to go on in details within each topic you mentioned but first I knew you worked for C|Net because of your memcached keynotes. I have 2 questions: you were a PHP programmer, what made you switch to Ruby on Rails? And then, working for a high profile network like C|Net exposed you to very demanding public websites. How did you figured out about leveraging memcached with Rails and then your cache_fu plugin?

Chris Wanstrath: I started doing Rails at the start of 2005 and got my first PHP job in February of 2005. (before that I was doing asp and Perl, which I don’t like to talk about). So really, I never considered myself a “PHP programmer” over a Rails programmer. I really liked websites and I knew I could get paid doing PHP, so that’s what I did. In the meantime, I was constantly doing Ruby on the side.

When C|Net started doing Rails, I knew it would be a perfect fit for me. I really liked PHP and loved Gamespot, but it was just silly for me to spend all night playing with Ruby while doing PHP professionally.

In fact, one of the things that got me hired at Gamespot was my pure PHP yaml parser called SPYC (simple PHP yaml class). It was inspired (obviously) by _why’s syck yaml parser. I wanted an easy, extension-free way to deal with YAML in PHP because I was so spoiled by Ruby.

I think today the CakePHP and Symfony frameworks use it, and do their config stuff in yaml. But even when writing PHP I wanted to be writing Ruby. The main reason I picked up ruby in the first place is because I knew PHP, and I knew Perl, but I wanted something I could use to write both websites and command line scripts. Perl was great for scripts, and PHP was great for sites, but I was just tired of using them both

So while I was learning Python, Rails popped up.

As far as cache_fu goes, I was very interested in some of the “scaling” aspects of running a website while working at Gamespot.

While good OOP design and stuff like that can be learned by anyone writing enough code, you can’t really learn about scaling unless you’re working on a big website. There are just too many tricks and moving parts, and it’s too hard to simulate the load in a controlled environment.

So while at Gamespot, like I said, I tried to learn as much as possible about things like MySQL replication, clustering databases, sharding databases, and memcached based on how the smart guys at C|Net had set it all up over the years. They had a lot of machines serving a lot of traffic so it was perfect

At Chowhound, we were re-writing an old static html site in Rails and were worried about the transition from flat files to dynamic database calls and page generation. It had a fair amount of traffic from a group of rabid fans, and we knew the new “web 2.0” look of the site would not sit well with the old school users, so we at least wanted the site to be performant in order to give them one less thing to complain about. So we basically took a lot of what I had learned at Gamespot, and what information was freely available on the internet in mailing lists and discussions, and tried to do a more Rails friendly way of object caching with memcached.

Ruby is just so good at cleaning up repetition and creating friendly apis. So cache_fu does fragment caching and object caching, because in bigger sites you end up using both for different purposes which is how it was at Gamespot too, basically.

AkitaOnRails: Nice. And it is not very common for me to find people that have dealt with really big websites. Can you give us a glimpse of what kind of load your Rails apps did have to handle? Some pundits I know complain about the vanilla Rails distribution and recommend lots of tweaks like dumping ActiveRecord altogether and several other hacks. Do you have to hack Rails a lot in order to achieve the scalability you need or do you think most of it is good enough so you can avoid too much tweaking?

Chris Wanstrath: I wouldn’t really consider Chowhound to be a big Rails site anymore. Now that you’ve got scribd and twitter and friends for sale and Yellowpages, Chowhound doesn’t really make the list.

We ended up doing a lot of premature optimization on that site, and not enough real world optimization. I learned a lot of lessons there that I’ve applied to other sites along the way. However, I recently had the chance to work with the friends for sale guys on their Facebook app which gets millions of page views a day and handles an insane amount of db records.

To my knowledge, the only AR hack we did was apply Pratik Naik’s partial updates patch. This was because, with so many rows and such large indexes, you want to avoid modifying indexes when you don’t need to, so saving only the changed columns/attributes can have a real big performance gain. Luckily, partial updates are now in Rails Core.

In my experience, you spend a lot more time trying to scale SQL before you even need to address AR. And once you get to the AR part, it’s usually your application code. Fetching and saving too many records in before/after_save callbacks, full row writes like I was just describing, and generally not being a good SQL citizen. I would only ditch AR completely if I felt like I had no control over the SQL it generated. Which, as anyone knows, is not the case – you have a lot of control over it.

There are times, however, when AR is overkill and you really do need speed. On Github, we need to authenticate you every time you try and pull or push a repository over ssh. Loading an entire Rails environment, or even activerecord, was noticeably slow, so we switched to using sequel in a simple ruby script. Because we don’t need AR’s massive featureset and nice OOP capabilities for such a simple single row find, this made a lot of sense for us.

AkitaOnRails: I agree with that, that’s what I experienced too with regards to AR. So, and you’re also the author of several other famous Rails plugins like will_paginate, Ambition, the original Sexy Migrations. Can you comment briefly about each. Am I forgetting any other plugins? Some of what you did became the ‘de facto’ standards for Rails development, some people here use these plugins without really knowing you made them all.

P.J Hyett at SXSW'06

Chris Wanstrath: Err the blog is actually two people, P.J. Hyett and myself. I did not write will_paginate – P.J. wrote the original version then Mislav Marohnić re-wrote it. Mislav is now the maintainer. But I still get all the credit, which is fine by me.

As far as the other plugins go, there’s mofo, ambition, sexy migrations, cache_fu, acts_as_textiled, fixture_scenarios_builder, and gibberish.

Mofo is a microformat parser based on Hpricot. It’s up on Github and unfortunately doesn’t get enough love from me these days, but as far as I know it’s still the gold standard for microformat parsing in Ruby.

It was the first gem that I released which doubled as a Rails plugin, which is how I think most plugins should be distributed in the future. Gems already have a solid distribution system and versioning scheme, and if Github becomes a gem source then there’s almost no reason not to release plugins as gems

Sexy migrations were inspired by Hobo. Unfortunately their version was hobo-specific, so I wrote a plugin-friendly version. DHH later wrote his own version and rolled it into core, making a grand total of 3 distinct sexy migration implementations.

Gibberish is a pretty fun localization plugin I wrote pro bono for a client, just because I felt like the APIs of all the existing localization plugins were so difficult to work with. Hopefully, with the help of anyone interested, we can begin localizing Github in the near future.

Ambition was inspired by dabbling in Erlang. I read a blog post explaining that mnesia’s query syntax, which is all list comprehension (basically Ruby’s version of the Enumerable module), was made possible by the ability to walk the parse tree and build an mnesia query that way.

So I started playing with the parse_tree gem to see if I could do the same for Ruby. It’s now, of course, a full fledged framework for generating arbitrary queries for any RubyGem based on Enumerable. For simple queries, I really like treating tables as arrays, it feels very natural.

Acts_as_textiled was the first Rails plugin I released. It’s a testament to Rails that the plugin still works on edge today. The only other notable thing that Err started is the “vendor everything” term, which is now a part of Rails through config.gems.

That, and the Cheat gem (and site).

Tom Preston-Werner

AkitaOnRails: (Of course, pardon me P.J.!) And this raises another curiosity of mine: where did the name “Err” come from? It is both for Err the Blog and Err Free which is your company. And you mentioned P.J. and Tom. And you’re all full time Railers, right? How did you team up with them and decide to start your own company? Many times people ask me about entrepreneurship and you’re another good example.

Chris Wanstrath: “err” is kind of a play on “Typo,” which was the popular Rails blogging engine when we started our blog, so it may be kind of confusing, but I actually am cofounder of two distinct companies.

There is Err Free and Logical Awesome. Err Free is Ruby & Rails consulting and training. P.J. and I own the company, and we use it to do client work, speaking gigs, corporate training, that sort of thing. It also owns and operates FamSpam, which we use with our own families.

Logical Awesome, however, was founded by me and Tom. This is because I was developing FamSpam with P.J. and GitHub with Tom at the same time, separately. Today, however, P.J. is a part of Logical Awesome and is one of the GitHub developers.

Tom works at Powerset and doesn’t actually do much Rails for GitHub, he mainly does flash, haxe, C, css, design, and ruby. And because he’s the author of God, I make him write all the config files, too. As far as deciding to start a company, I am someone that needs to be involved in whatever I’m involved with on every level. At C|Net, there is only so much input you can have on a website that employs 30 people especially when there are dedicated product and “vision” people, whereas with Github, it’s just me Tom and P.J.

If the site is slow, confusing, sucks, or doesn’t improve your workflow, I can take responsibility for that. But if it’s fast, simple, awesome, and life changing, I get to take responsibility for that, too. Which is very rewarding.

It also means, when you’re cofounder of a mostly technical company, the discussions are a lot more logical. I saw decisions made at C|Net that directly contradicted a/b statistics we had gathered. At Logical Awesome, that would never happen. It is neither logical nor awesome. Basically: I wanted to find the ideal company so I found good people and started it.

AkitaOnRails: Ok, so we come to the main dish of the day: Github! I can’t think of a better example of an innovative product that leverages so well the power of Git. I am very curious to understand how did you come up with this idea? At the same time, lots of people still can’t understand why Railers as a whole started using Git so massively all of a sudden. Mercurial, Bazaar guys are very uncomfortable. What do you think Git has that attracted Railers in flocks like that? Or at least what do you think Git has that no other have? I started evangelizing Git here in Brazil last year after listening Randall Schwartz, and recently someone asked me what would be my pick for a Rails killer-app and Github popped out of my mind, right away. So you do have good mind share as well.

Chris Wanstrath: Github is super exciting to me because it’s really a website just for me. Tom and I are pretty similar in that we both have a fair amount of open source projects, all of which get used and patched by people we’ve never met.

Handling this the old fashion way was fine until me and P.J. started working on FamSpam… as my free time decreased, so did my ability to maintain my open source projects. And really, that’s a definite workflow problem. Sometimes when you can’t find enough time to do something, you just need to make the something take less time.

Github was literally written for chronic, god, ambition, will_paginate, and the rest of our projects. We wanted to make it dead simple for people to contribute, and really, it’s just not possible without Git.

I had started using Git right after viewing the Linus tech talk in May 2007, which is really good at explaining Git from a very high conceptual level. So when this time problem came up, I had already been using Git for a few months and Tom had serendipitously been trying to solve the same problem.

We talked after a local San Francisco Ruby meetup, at a bar of course (where all great ideas and partnerships begin), and decided to work on the problem together. I’d been playing with an err-specific Gitweb, but Github is obviously much more ambitious in its scope.

As far as the adoption of Git, I have no idea what single thing tipped it. When we began working on the app in October, we were worried about ./script/plugin and tarballs and windows and svn mirroring. we weren’t even sure we could build a business around Git, because subversion was still so utterly dominant.

As we all know, however, Git tipped at the start of 2008 and everyone somehow found the time to try it out. It maybe takes, like, two seconds to realize how much faster it is, and then a few more seconds after that to realize how much more awesome it is. So it’s not much of a surprise that it is grabbing converts.

As for the Rails community, it’s definitely because of the projects. When Merb, Rubinius, and Ruby on Rails all switch to Git, you have no choice. This is where the community is headed. As for other languages, we have a large number of non-ruby projects on Github. PHP, Java, Javascript, Lisp, Python — there are a handful of Django forks, for instance, the io and nu programming languages are also hosted on Github.

So really what it comes down to is early adopters, I think. Nu is a lisp written on Objective-C, very new and very cutting edge. The people using it right now are people who realize how powerful and awesome it is to run such a dynamic language on such a mature and stable platform. And naturally, the forward thinkers behind nu know that Git (and distributed source control) is an equally powerful, equally cutting edge concept.

With Prototype and Scripatculous moved over, and rumors of other Javascript frameworks switching, it’s only a matter of time before Git becomes even more widespread.

I think the Railers just like to blog a lot.

As far as other solutions go, it’s Rails vs Django all over again. If you use Mercurial, that’s fine. The two are so similar (yes, Git does work great on Windows) that as long as people move to distributed source control, it’s still a win.

Oh, but wait, Mercurial doesn’t have Github :-)

AkitaOnRails: There you go :-) And I wonder what were the challenges of putting something as Github together. It is not a simple Rails web app, with very fast, pure Ruby code. You’re probably dealing with thousands of system calls to Git command liners, several background jobs, maintenance, security. What do you think were the biggest challenges while assembling Github before recently releasing it to the public?

Chris Wanstrath: Well you pretty much nailed it right there… scaling Rails is the easy part. scaling sshd, Git, Git-daemon, and our background jobs is the hard part.

We call Git directly many times per page, we need to process jobs that get entered from many different places (create a repo on the website, push a repo through ssh), we need to be secure (ssl and ssh for all private repos at all times), we need to make sure it all runs fast (memcached for both Git calls and the db), we need to make sure you’re “in the loop” with a news feed aggregating information from all different sources within our system (almost 1m rows in the feed table when we launched).

So it definitely has not been easy. Not to mention that ssl is essentially the “slow flag” for http, so we need to make sure we’re going fast because things like your dashboard already have a speed handicap. As an example, sshd stores its keys in an authorized_keys file. Well, we weren’t even done with our beta yet and the keys file was over 4 megs of just plain text. So we had one of the C gurus at Engine Yard patch sshd for us to do mySQL based lookups, giving us faster searches and no pricey appending / writing of a massive file

Matthew Palmer is the said guru, and we plan to make that code open source in the near future.

We’ve also got post-receive (when you “Git push”) hooks running that we host and deliver – so if you push, we’ll POST to an arbitrary url for you with json of the commits. But you can also give us some info and we’ll post to campfire, irc, twitter, or lighthouse for you with custom payloads.

Since we have flash, flash with haxe, Python, c, ruby, bash scripts, lots of Javascript, and some forthcoming erlang under the hood, it’s definitely an interesting mix.

We are fortunate to be hosted on Engine Yard , though. If we didn’t have them we’d be screwed. Their awesome cluster setup with GFS means we can host our potentially 100s of gigs of repositories on a shared, raid’d drive with redundancy and backups. If we were running Github on a barebones VPS, I dont even know how we’d share access to those repos. It wouldn’t be fun.

They also have a lot of experts available 24/7, which is great because I have a tendency to forget to sleep and work until 7am. A lot of the pain of running a heavily unix-dependent site is taken away by those guys.

AkitaOnRails: Interesting, Erlang? I’d like to know what you are up to with it. Going back, I think I saw a Rails trunk Git clone at Github way before DHH announced it a few days ago. I think it was Michael Koziarski who first did it, without much fuzz. Were you planning this together with the 37signals guys, or the switch of the Rails Core to Github was something that happened naturally? And do you have any kind of partnership with the Lighthouse guys as well, because you already have some hooks to manage Lighthouse tickets through Github commit messages, right?

Chris Wanstrath: The Erlang stuff will be very cool, I promise. We’ll make a big fuss about it when it’s ready. As far as the Rails thing goes, koz did indeed have a mirror of his Git-svn repo at Github during the beta. It was unofficial. Then in february he wrote a post explaining that the core was thinking about moving to Git.

When I saw the post I emailed him and we talked a bit about what it would take to move Rails to Github, which was obviously something I love on a huge number of levels. He said he would get back to me, and then a few weeks later the Core team contacted us and wanted to discuss the move. The rest is history.

I really respect the work the Lighthouse team does. The bug tracker is great, and the new redesign is even better, but we don’t have any official partnership with them. We wrote the post-receive lighthouse hook because we wanted it, Rails wanted it, and a huge number of our users wanted it.

AkitaOnRails: Many others started moving to Github during the Beta. I think Merb was more obvious because of Ezra’s being involved in Engine Yard. Dr. Nic started using it for the Textmate bundles. Can you point to any other high profile Rails related projects hosted at Github right now?

Chris Wanstrath: Merb was actually the reason Github went into beta. We launched the beta so they could start using the site for their 0.9 rewrite of merb-core. As far as popular projects, the best thing to do is check http://Github.com/popular/watched and http://Github.com/popular/forked. Datamapper, Rspec, and Mephisto are some of the popular ones.

AkitaOnRails: Are you using vanilla Git code, or did you customize it in any way to better fit your environment? Have you ever talked to Junio Hamano or any other Git core maintainer? With Github probably eating up a lot of your time, how is Chow and FamSpam going right now? How are you managing all those products all at once?

Chris Wanstrath: We’ve patched Git-daemon to record statistics, which we’ll soon be surfacing on the website soon in the form of better, more granular activity. You’ll be able to see how many times your project was cloned, popular projects in the last 24 hours, all time most cloned projects, that sort of thing.

We’ve emailed the core Git guys about the site, just to say thanks for writing Git and to let them know about Github, but haven’t really had an occasion to chat with them about anything in particular. If I ever run into any of them, I’ll definitely be buying them a few drinks, though.

I don’t actually work at Chow anymore. My last day at C|NET was almost exactly one year ago, so my Ruby time is spent on FamSpam, Github, open source, and doing occasional client work.

FamSpam is going well. Now that Github is launched, there are a handful of features we want to get in and all. Luckily, however, the site is very polished and has been running smoothly without the need for much intervention. What we’d really love to do, because it’s really just a great Rails-based mailing list, is try out some different concepts.

Maybe one for open source, or a version for little league teams – anyone who needs to keep in touch and have their email workflow and document sharing streamlined. For right now, however, I try to spend as much time as possible on Github. There are so many places we want to take it.

AkitaOnRails: I probably more than exceeded my interview time (sorry about that), but this conversation is super-interesting. One project I just remembered is Sake. To me Sake is very neat because many people complain about “how difficult and complex” the Git command line is, and Sake-like solutions make the workflow a lot easier. For instance, my entire Git workflow for Rails projects is only 4 small sake tasks like Git:update and Git:push. If I am not mistaken someone at Err did Sake, right? Are you still evolving it?

Chris Wanstrath: Yeah, I wrote Sake. It’s not a Rails plugin but it was written to help in Rails development. The “Git tasks” for Sake are becoming quite popular, as Git really just facilitates a better workflow. If you want to implement it, or different branches of that workflow, you can pretty easily just wrap up a few commands into a rake task or bash script.

And while bash scripts are great, sake tasks are portable. A lot of sake was inspired, very loosely, on Git – you can pull in sake tasks from any text file, whether it’s on the web or local, and sake comes with its own daemon for serving your tasks.

So you could share tasks over wifi, or something, the same way you could share Git repositories over an adhoc network. Sake is up on Github, so feel free to add features you feel should exist.

AkitaOnRails: Another thing I would like to hear your opinion about. I recently made a presentation on Rails Deployment strategies for beginners. The most common simple architecture revolves around Apache/Nginx/Litespeed + Mongrel/Evented Mongrel/Thin/Ebb. It is usually a matter of load balancing between a Web server using some kind of IPC to distribute the load back to Ruby VMs running your Rails app.

Now we have mod_Rails. What’s your opinion on having all those choices, do you have any particular recipe you like or it depends on each application’s needs? Did you have time to test mod_Rails? I think Hongli Lai is doing great stuff in regards to things like mongrel_light_cluster and his efforts on making Ruby’s GC more copy-on-write friendly, did you take a look at that?

Chris Wanstrath: The nice thing about Engine Yard is they get to take care of all that stuff for me. So while I used to spend a lot of time benchmarking and playing with different solutions, like Mongrel vs Emongrel, I just let the experts take care of it so I can focus on Github..

So no, I haven’t played with mod_Rails yet because I’m not in the situation where I could deploy it even if I wanted to use it. Which is in my opinion the best situation to be in, and pretty much the reason mod_Rails was written.

AkitaOnRails: And by the way, are you going to make any presentation at RailsConf this year?

Chris Wanstrath: I am. I’ll be talking about “Beyond cap deploy”, which will pretty much be an in-depth look at the Github architecture, and then I’ll be on a panel with Ben Curtis, Geoff Grosenbach, P.J., and Tom about being a “profitable programmer” w/ side projects.

AkitaOnRails: I am very pleased to have the opportunity to talk to you.

Chris Wanstrath: Yes, you too. Thanks!

He also posted a great screencast about Microsoft’s new alternative MVC framework and I thought it would be great to have him at my blog to talk about technology and web frameworks. As I said before I think that we should not become alienated about what’s going on in other fronts and Scott is a very forward thinking and open minded person as well.

AkitaOnRails: First of all, let me congratulate you mr. progman.exe :-) I understand that this was something you’re very excited about. Can you tell us a bit more about your transition to Microsoft and your new duties?

Scott Hanselman: I’m working for Simon Muzio who runs www.asp.net, www.iis.net and large content-packed sites like that. I like to think my job is writing a book that will never end, where that book is blog posts, articles, screencasts, videos, talks, etc. I’m a teacher at heart, so while I took the title “Community Liaison” I like “Teacher.”

AkitaOnRails: Tell us about your history. How did you start in the computer world? Did you always develop more toward Windows or did you have a background in the Unix world as well? And before your recent departure to Microsoft you worked for Corillian. What was your role there?

Scott Hanselman: This blog posts talks about my early years in school.

See that book on the right there? That’s how I learned to program. This book was THE book in 1984. I typed in the whole book on a Commodore 64.

And a VERY influential teacher that set me on the right track.

Marianne Mayfield is my fifth-grade teacher and the reason I’m in computers today. She was at my wedding, at graduations, at family events. Twenty years later and we are still close. When I was young, she recognized that I was “at risk for trouble” and sat down with my family in order to find a way to get me back on track. She saw that I was transfixed by the Apple II in our classroom and set it up so we could sneak the computer out of the school as long as it was back by Sunday night and no one noticed.

(click links above for more details)

Scott Hanselman: I was the Chief Architect at Corillian, working with other engineers and architects throughout the company, planning, designing, coding the next generation of Corillian’s Online Banking Platform.

AkitaOnRails: I applaud your Team Hanselman campaign to help fight Diabetes. I understand that you have Diabetes as well and that, fortunately, you managed to have it under control nowadays. Can you tell us this story and the goals of your campaign?

Scott Hanselman: My personal story is here :

I currently take three shots a day of Symlin while also wearing an Insulin Pump 24-hours a day, even while I sleep. The pump saves me from an additional six shots a day, which I took for 8 years before the pump. I test my blood sugar by pricking my finger between 8 and 10 times a day – that’s about 46,500 finger pricks so far, and miles to go before I sleep.

And there’s a good explanation of diabetes here :

Here’s where the analogy gets interesting. Remember in the analogy we are flying from L.A. to New York, except we only get to check our altitude seven times. And, we only get to change altitude (take insulin) less than ten times. But, when I check my blood sugar, I’m actually seeing the past. I’m seeing a reading of what my blood sugar was 15 minutes ago. And, when I take insulin, it doesn’t start lowering my blood sugar for at least 30 minutes.

The campaign ended up raising over USD$30,000, and that money will be applied to research, education and programs surrounding diabetes.

AkitaOnRails: “What in the world were you doing at a RailsConf?” That’s what I think people from outside of the Microsoft blogosphere would ask you :-) So, are you just curious about Rails, or do you actually develop Rails-based apps? I am very interested to learn your opinions about Rails. How did you find it? What do you think is best about Rails? And more importantly, what do you think Rails could have improved?

Scott Hanselman: I’m always trying different programming languages and frameworks. I’ve been doing Rails on and off for about 18 months, but it hasn’t clicked for me yet. I’m sure it will soon. The MVC pattern is very old…I was doing it in Java over 10 years ago, and certainly the pattern goes back 30 years. I think that Rails is a good framework considering its young age. I think it’s Ruby that is the real magic though and I find the Ruby aesthetic to be very in line with my own.

AkitaOnRails: Then, following my biased preferences, the next article I like is your screencast over the CTP ASP.NET MVC framework. I see that this new framework resembles Rails a lot. Of course, it may just look like that because both implement MVC2. But on the other hand, it uses very similar Rails idioms everywhere. It lacks a little bit of ‘convention-over-configuration magic’ but from what I saw, it looks much better than doing conventional ASP.NET. What do you think about it? Can you summarize it a little bit for those that don’t know this product yet? And what do you think will still improve in it?

Scott Hanselman: If one points at Rails and says “that’s MVC” then everything else looks like Rails, sure. Any good MVC framework needs to not only follow the pattern as appropriate but also abstract away HTTP (assuming it’s a web framework) in a clean, but not complete, way. The ASP.NET MVC implementation still has some baggage that it will always have to carry because ASP.NET WebForms came first and wasn’t designed from scratch with testability in mind. That said, it’s all about alternatives. Use the framework that makes you happy and you feel most productive in. Some fraction, maybe 20%, of ASP.NET devs will prefer MVC. Now they have a MS support choice with good integration with C# 3.0

at RailsConf'07

AkitaOnRails: And what would be tech world without discussions and flame wars? I understand that most .NET developers don’t even pay attention to Rails or other frameworks. I even heard that there are some developers questioning things like “Why yet another web framework if ASP.NET is already there?” Meaning, why reinvent the wheel and divide attentions? I particularly think that this new MVC is the way to go, but it is undeniable that the old ASP.NET has much more acceptance and support. How to reconcile both point of views?

Scott Hanselman: That’s just FUD (fear, uncertainty, and doubt). Think what they like, this Framework is just about alternatives. WebForms is great, and if you’re doing Line of Business (LOB) apps with complex grids and such, it’s not going anywhere. However, if you’re an agile shop with a penchant for TDD and have been frustrated by ViewState, then check out ASP.NET MVC. There’s nothing to reconcile. Some people take a car, some a motorcycle, and others walk. As long as you get from point A to point B and feel good about the journey.

AkitaOnRails: Speaking of flame wars, there is probably one subject that gives me the creeps: the paranoid conspiracy theories regarding Miguel de Icaza and Mono. A lot of people actually believe that Miguel is ‘selling’ part of the open source world to Microsoft. Have you ever used it? What do you hear throughout the community and what’s your opinion about this matter?

Scott Hanselman: Yes, I’ve used Mono and I think it’s a great way to get your .NET application working on Linux or Mac. I think Miguel is brilliant and a fine dancer. I hear in the community that they are happy Mono exists and that it’s available as an option.

AkitaOnRails: I will probably be cursed for this one: but I am not ‘strongly’ against Microsoft as some fundamentalists are. It is public and notorious that Microsoft is a big corporation and as such it did its share of ill conceived deeds. A lot of them were already settled in court. So, it’s more complex than people usually think. I prefer to assume that inside Microsoft there is a lot of very smart people.

Scott Hanselman: I stay out of legal stuff. Microsoft is a huge company with a lot of smart people, but it’s really many medium sized companies working together (usually). I can’t speak to “ill conceived deeds.” I can only say that I do my best every day to not be evil, as do my coworkers. There’s no evil master plan in my group.

AkitaOnRails: I particularly like the roadmap for Windows Server 2008 (with it’s minimalist approach, finally having only what you need installed). Last year you were experimenting with IIS 7 and its new FastCGI support. I think it was primarily intended for PHP support but it could theoretically handle Ruby on Rails as well. Have you tried Rails there? I think Microsoft is clearly going after the low-end with Windows Server 2008 + IIS 7, against the inexpensive Linux+Apache boxes. I think they won’t be able to reach them in terms of prices but what do you think of it as an internet service contender?

Scott Hanselman: I have little power in that arena, but every time someone will listen I’m pushing for a nice inexpensive Web Server SKU. I’m a huge fan of IIS7 and I’d like as many people as possible to check it out. I haven’t tried IIS7+Rails but I’ve heard rumors of folks getting it working.

AkitaOnRails: There are a lot of new features in .NET 3.5. LINQ is the one that interests me the most. Can you give us a brief description of why it’s so interesting? And what do you think are the best improvements of the 3.5 version? Are you already using Orcas? What’s your opinion? Oh, and are you aware of the Sapphire in Steel project?

Scott Hanselman: LINQ is interesting because it’s its own Domain Specific Language for querying objects of all kinds, and it’s living right inside VB and C#. It’s a MUCH smarter compiler and it’s a joy to work with. I’ve installed Sapphire In Steel and I know a few people who are digging it. I’m looking forward to Rails on .NET.

AkitaOnRails: One of the advantages of the Microsoft .NET strategy was being prepared since its first day to be language-agnostic. Now we have the DLR that was derived from the works in IronPython and not IronRuby. But there is yet another cool language that not many people are aware of: F#, the OCaml inspired language. Have you tried it?

Scott Hanselman: Yes, and I’ve done two podcasts on it, one with Robert Pickering, author of a book on F# and one with Dustin Campbell, an enthusiast. I’m stoked it’ll be a first-class language inside VS.

with John Lam

AkitaOnRails: I am not against technical comparisons, we have to do such things to decide our steps in projects. But I am against pointless challenges. Rails is far from perfect and I am the first say it. That said, it is great for an specific niche of web development. I usually recommend that good programmers should expand their horizons and learn as much new stuff as possible. You can’t know everything perfectly but it’s always good to be aware of the possibilities. You wrote something around these lines. What do you think about it?

Scott Hanselman: Rails is good for what it does in its niche. You don’t create Windows Desktop apps with Rails and that’s fine. That’s why we don’t compare Rails to WPF, we compare it to Web Frameworks. Comparison is good and there’s always good to be found on either side. I avoid flame wars as well. It’s pointless. If the shoe pinches, don’t wear it. But, try as many shoes as you can!

AkitaOnRails: Last year you wrote an interesting post about the future. Google is this big giant, Amazon released surprisingly good products in the last few months like S3, EC2, SimpleDb. I am not well aware of the current Microsoft Live’s strategy. Can you say something about where is it heading to?

Scott Hanselman: I’m not in that group so I have no insight outside of what’s already been said. However, I do still hold to my predictions in that post!

Computing will be moved into the Cloud. It’s already happening, we’re 20% there. The idea has been around since the beginning, and it will, in my opinion, continue to come up until it actually happens and we build Skynet. One of these compute clouds will no doubt end up in orbit.

AkitaOnRails: And of course, I kind of ‘have’ to ask you this: do you use Windows Vista? How has it been for you given that there’s a huge underground campaign against it? Do you think it is as bad as everybody else says? I can’t comment because I never tried it outside of my virtual machine (I am a Mac guy), but they did sell 100 million licenses.

Scott Hanselman: Sure. I run Vista 64-bit on 3 machines, and Vista 32-bit on 2 machines. It was rough for the first 3 months while the driver support sucked, but now it’s fine. I’ve got 2 vista machines that haven’t been rebooted in months, just put to sleep and woken up. Once you get good video drivers, you’re usually cool.

Folks give Vista a hard time but they forget the wide range of hardware it has to run on. OS X only has to run on Macs, and a narrow range at that. Vista has to run on millions of combinations of hardware. Third Party Drivers are by FAR the thing that crashes Vista the most and it gets blamed. That’s why I run 64-bit and use only signed drivers. I’ve been thrilled with 64-bit. Works great.

AkitaOnRails: Ok, this is it :-) Thanks a lot!

It was Avi Bryant that evangelized the neat idea of “turtles all the way”, meaning that for a language to be called ‘complete’ it should be able to extend itself. So, the ideal world would have Ruby being extended in Ruby, not in C. JRuby goes as far as it can building up a sandbox for Ruby code to run under the JVM. As cool as it is, we still rely on Java to fully extend it.

Enter Rubinius and its author Evan Phoenix , currently a full-time employee for EngineYard. Rubinius borrows heavily from Smalltalk’s concepts of a virtual machine and does as little as possible in C just for the bootstrap and all the rest is developed over pure Ruby.

Rubinius answers lots of questions about going forward over the current Ruby MRI but also raises several other questions that I hope we can nail down today in this interview with Evan himself.

So let’s get started.

AkitaOnRails: It is a tradition now in my interviews to ask about the background of the programmer. What was your path? I mean, what made you come in to the programming world and how did you get into Ruby?

Evan Phoenix: I started programming in high-school with a friend of mine. We started a small computer company doing odds and ends and I really got into it. I had gotten into Linux a few years before that, so programming became a natural extension of using Linux.

When I applied to college, I declared myself as a Computer Science major on the application, so I’ve been doing this since about then I guess.

As for Ruby, I got into it in about 2002, when I first moved to Seattle. A friend had just found it and was writing some fun stuff in it and I picked it up on his suggestion. Eventually, I found the seattle.rb, and have been working in Ruby since.

AkitaOnRails: EngineYard seems to have great faith in the future of Rubinius. How did this relationship start? Can you tell us what are EngineYard’s expectations regarding your work for them?

Evan Phoenix: The relationship started mainly with them approaching me about working for them, on Rubinius. So they saw promise in Rubinius on their own, from my presentations and such, and approached me.

Their expectations are that I make Rubinius the best Ruby VM it can be. That’s my basic mandate with them. They’re pretty much the ideal stewards of the project. They allow me to work at the pace I want, they understand the rigors of the work I’m doing, and give me a lot of freedom.

AkitaOnRails: Now let’s get into Rubinius. For non-starters how would you define Rubinius? We all know that this is an alternative Ruby implementation, so maybe it would be good to point out what makes it different than the MRI. What are the project main goals?

Evan Phoenix: One of the primary goals is to have as much of the system written in Ruby itself. With MRI, none of the core classes are implemented in Ruby, all are in C. So we wanted a system that was easier to work with, and thus written in Ruby itself.

Another thing we’ve done is enrich the number of things which are objects, which adds considerable power. An easy example is the CompiledMethod class which Rubinius has. It contains the bytecode representation of a method and can be inspected, manipulated, etc, just like any other object. This opens a lot of new doors with regard to how problems can be solved.

AkitaOnRails: It’s not so obvious to the brazilian audience when we speak of “Squeak”, “Garnet”. Smalltalk is probably less known here than Ruby. The point is that it is well known that you were inspired by the way Squeak is implemented. This led to features like “Cuby”. Can you explain what is so great about the way Squeak is implemented and how it is helping you in the Rubinius project?

Evan Phoenix: Well, we’re currently in the process of developing Garnet/Cuby, so those tools aren’t in use really yet. But almost the entire system architecture of Rubinius is modeled off the original Smalltalk-80 Virtual Machine. It defined things like CompiledMethod, etc, which I took name for name into Rubinius.

In addition, the execution model of Rubinius is almost identical to Squeak. A good example is the way in which the system calls methods and figures out how to keep track of where to return control to when a method call returns. All that information is kept in first class objects called MethodContexts. In a language such as C, that information is stored on a process’s memory stack. By keeping the data in first class objects, we’re able to query them directly to find out information about the running system. It also vastly simplifies how the garbage collector works.

AkitaOnRails: Today you have shotgun. I read somewhere that you consider it ‘cheating’ because this is not an interpreter for Ruby written in Ruby, which will lead to Cuby. It’s more kind of a bootstrapping to ease development. What’s the current state of shotgun, can we use it outside its purpose of developing Rubinius?

Evan Phoenix: Shotgun is a virtual machine written in C that provides instructions and primitive operations for running a Ruby-like language. Shotgun itself actually has no knowledge of parsing, compiling etc. It has a very simple way to load code in, and a way to execute it. You could easily write a new language which targets shotgun, in fact, Ola Bini and I have talked a few times about writing a simple lisp-style language that would run directly on shotgun.

The primitive operations it provides are kinda like syscalls in a unix system. They provide very low level operations which are built on. For example, there is an add primitive which adds two Fixnum objects together and puts the result on the stack.

AkitaOnRails: This is a personal curiosity. The MRI today uses a simple mark and sweep garbage collector (GC) whereas Java uses a highly customizable generational GC. What did you choose for memory management on the Rubinius VM?

Evan Phoenix: Rubinius uses a generational GC, combining a copy collector for the young objects, with a mark/sweep collector for the old. It’s proved to work quite well for us. The trick has been tuning how long an object exists before it is promoted to the old object space. We’ve only tuned it a little. There is a lot more work that could be put into the GC, and it’s architected to only interact with the rest of the system at a few places, so its logic can be completely replaced if need be without disturbing anything else.

AkitaOnRails: We have parties that favors green threads, we have parties that are all go native threads. How are you dealing with threading issues in Rubinius? Will we still have the same kind of global locking that MRI has today?

Evan Phoenix: At the moment, Rubinius only has green threads, built on the first class MethodContext objects. It currently uses libevent to allow threads to wait on IO objects quickly.

The plan (likely for 2.0) is to support native threads as well as the current green threads. You’ll be able to allocate a pool of native threads that the green threads can all share. So perhaps you have 100 green threads, you could allocate 10 native threads for them to split time between. Because of the architecture, it’s trivial to migrate a green thread between native threads.

As for the global lock on native threads, no, we don’t consider a global lock a solution for using native threads. If there is a global lock, there is no reason to use them over green threads. Because so much of Rubinius is written in Ruby, we have an easier time of figuring out how to properly lock things to keep all the objects in the system safe. We haven’t really even started this work, but it’s been talked about quite a bit.

AkitaOnRails: The current goal is probably to make Rubinius as compatible with the MRI 1.8 as possible. Did you already start any work toward YARV compatibility already? And speaking of YARV, it is the official virtual machine and bytecode compiler for the next release of Ruby. Is there any chance to make Rubinius and YARV byte-code compliant or this is not a short-term goal?

Evan Phoenix: We’re actively working toward being 1.8.6 compliant. This a big goal because there is a lot of functionality in there. We’re going to do a 1.0 release of Rubinius once it’s able to run all the specs that 1.8.6 runs and properly runs Rails 1.2, which is a good benchmark.

No, we haven’t done any work yet toward YARV compatibility, but because of how things are architected, we’ll likely just be able to have —yarv flag that you pass to Rubinius to have it use YARV compatible versions of things.

We aren’t currently working toward a common bytecode format between Rubinius and YARV, mainly because there is nothing to be gained by doing that. YARV’s bytecode format is largely internal to YARV only, last I looked, you couldn’t easily save it out to a file. Rubinius operates primarily off .rbc files, which contain a serialized CompiledMethod, and thus contain bytecodes. That being said, they are actually similar and could be unified if we saw the need to.

AkitaOnRails: Performance is always subject for a lot of discussion and it is still premature to talk about performance under Rubinius, as it is still work in progress. But I read in your blog that it is quite fast already, even surpassing MRI in many tests. How is performance evolving?

Evan Phoenix: Currently, our performance is evolving slowly. This is mainly because it’s not a priority for people writing the kernel of Rubinius (the majority of the Ruby code which makes it up). As we get closer and closer to being compliant, we’ll begin tuning things. That being said, I do write code to make Rubinius faster here and there. We went ahead and implement fast math operations to speed up the simple math that people commonly do. We have a simple profiler which can easily be turned on to give developers feedback about how their code is run.

AkitaOnRails: One of the main problems for any alternative implementation to Ruby is that it has a lot of C-based extensions, including a handful of core libraries. So if you want to stay “pure-Ruby” you have to re-implement all of them in Ruby. The JRuby guys had to go through something similar. Are there any cross-project collaborations already in this regard?

Evan Phoenix: Actually, that’s not entirely true. We also saw that the landscape of Ruby includes a lot of C extensions. To make migration to Rubinius faster, we’ve written a layer into Rubinius which allows all those C extensions to run (nearly) unmodified, only requiring a simple recompile. These are so that things such as ImageScience, RMagick, postgres bindings, etc can all be used under Rubinius without having to be rewritten.

AkitaOnRails: Still about C code, I know it is difficult to deliver a bytecode virtual machine and still be dependent on non-managed C code. Java has some jury rigging toward JNA, .NET has pinvoke. Do you plan something similar for Rubinius so that it can more or less easily speak with C libraries?

Evan Phoenix: We actually directly support a mechanism called FFI (Foreign Function Interface), which allows a developer to bind a C function directly as a method call. Here is a simple example:

module LibC
 attach_function nil, :puts, [:string], :void
end

LibC.puts "hello!"

The attach_function line is the primary interface into FFI. You simply indicate which library the function is in (in this case, nil is used because it’s included in the existing process), the name of the function (puts), the types of arguments it takes (just 1, a string), and finally, the type it returns (void, ie, nothing).

Using this, you can tie directly to C functions without having to write C wrapper code.

AkitaOnRails: You are very right when you say that formal language specs too early in the game can make it difficult to evolve the language. Ruby as been growing for 10 years now, and it feels that this is the right time to start thinking of something like this, so that we can have a baseline from where every other alternative implementation could start. Do you see any efforts towards this end?

Evan Phoenix: We’ve been actively working to develop a set of specs (in rSpec format) for 1.8. These form the primary mechanism with which we test how Rubinius is doing. These specs are being actively used by JRuby and IronRuby to test their respective Ruby environments. We’re currently in the process of moving these specs into a generic Ruby spec project to try and begin moving things toward a more formal standard.

AkitaOnRails: Another recurring question is about Rails, of course. Any new Ruby implementation today will have to face the inevitable question: does it run Rails already? :-) Rails is serving kinda like a ‘mini test suite’ and baseline for most implementations. How is Rubinius performing on this matter?

Evan Phoenix: When we run Rails, we know we’re close to a 1.0. :)

AkitaOnRails: You have a very interesting approach toward open source management: everyone that sent you a good patch gains commit access to the repository. How is this working for you? Isn’t it a bit ad hoc or people tend to follow your lead and your list of priorities?

Evan Phoenix: It’s actually working out great so far. By being spec/test oriented, new people have a place to start, either writing missing specs or making existing ones pass. Those become great intros into the whole system for them. They then begin to explore a bit more and commonly find more and more they’d love to help with. Because we have a lot of work to do in a lot of different places, people don’t have to worry about my priority list, since it’s usually involving things which others don’t need to be actively concerned with.

I really can’t say enough about the people who contribute. The one patch barrier has proved to work great because while we’ve now got over 60 committers, not once have I had to pull commit rights from someone. Sure, people mess up, but in every case, the person has corrected the behavior and/or code.

AkitaOnRails: One byproduct of this commit access approach of yours is the integration of rSpec into the Rubinius project so that you have a nice requirements tool and test suite. Do you practice Behavior Driven Development? Or this is covering just a small sub-set of the project?

Evan Phoenix: I’m largely a testing newbie, simply following the guidelines set by Brian Ford, the primary spec keeper of the project. It has proved to be a great tool for viewing how the project is progressing.

AkitaOnRails: As many other Ruby projects, Rubinius is also managed over GIT. There’s been a lot of fuzz around Git and Ruby these days. Do you think there is a new trend here? Why did you decide to go with GIT?

Evan Phoenix: Yeah, I think that GIT is picking up as a trend, because of the features it offers over subversion mainly.

The big reason we decided was it’s feature set. One big feature I love is local branches, allowing a person to manage a number of outstanding changes without trampling on each other.

We haven’t yet, but we plan to exercise the great merge / public branch capabilities.

AkitaOnRails: We heard from Ezra’s recent interviews about your new experiment on multi-VM. That would be a blessing for deployment without we having to deal with several processes in a mongrel cluster. Can you describe this feature and pin point its advantages?

Evan Phoenix: It’s pretty experimental currently, but it will only get more stable over time. The idea is that you can spin up a whole new VM in the current process. This new VM is completely separate from other VMs, living in its own native thread and having its own garbage collector, etc.

There is a mechanism for VMs to communicate with each other though, and this allows them to coordinate work. This would mean that a primary thread could accept new connections, then pass them off to a new VM to actually process. This allows you to process connections in actual parallel, in addition, because the VMs are completely separated, this even works for non-thread safe applications like Rails.

AkitaOnRails: Ezra also mentioned about a possible mod_rubinius in the making. How is it going? This definitely makes the Rubinius stack even stronger. Together with Merb, Rubinius plus multi-VM capabilities plus mod_rubinius would be a killer deployment package.

Evan Phoenix: Yes, a mod_rubinius project is just beginning. The multi-VM code and mod_rubinius overlap a bunch, so you’ll be able to have VM pools for sites, all managed through apache. We’re hoping that mod_rubinius can really simplify the Rails/Ruby deployment picture. It will operate similarly to mod_python, allowing a VM to remain running between requests, and likely even run background tasks.

AkitaOnRails: How long do you guess we are from a fully MRI-1.8 compatible release?

Evan Phoenix: We still don’t have a firm date, mainly because what fully compliant MRI-1.8 is is still unknown. We are still adding specs, working to properly define 1.8. That being said, we’re really hitting a stride and progress is advancing rapidly. We’re very close to properly running Rubygems. Ezra recently was able to run Merb on top of Rubinius, running under webrick.

I’m going to be doing a 0.9 release this week, because we’ve made so much progress since 0.8. My big hope is that by RailsConf in May, we’ll be running Rails. But don’t hold me to that. This is open source after all. :)

AkitaOnRails: Thanks, I think this is it.

Evan Phoenix: Thanks for your patience!

The Ruby Way is the undisputed must-have book in any Rubyist bookshelf. Rather than being a ‘reference’ book it explains what it takes to really dive into the intricacies and marvels of the Ruby programming style.

Today I am very happy being able to engage in a conversation with one of my favorite authors, Hal Fulton. This was a great chat and I know people will be delighted as well. He is one of the Ruby veterans and certainly has a lot of experience to share. So, let’s start:

AkitaOnRails: First of all, it is a tradition at my blog to ask for the guest’s background. How long have you been in the programming career? How did you first get there? What inspires you about the computer world?

Hal Fulton: I started college as a physics major, but I found that I was taking computer courses for fun. I switched to computer science and the rest was history.

Unlike most younger people now, I never was really exposed to computers until I was sixteen, because personal computers were much less common then. I was hooked right away. I saw the computer as a “magic box” that could do anything I was smart enough to instruct it to do. Really I still feel that way about it.

AkitaOnRails: This is almost a cliché already but I have to ask: you were one of the ‘first generation’ Rubyists. How did you come to find Ruby and what was it that ‘clicked’ for you about the language?

Hal: I was on a contract at IBM in Austin in the fall of ‘99. In a conversation with a friend across the hall, I complained that I was never on the “ground floor” of any new technology — I was always a late adopter. And he said, “Well, you should learn Ruby then.” And I said: “What’s that?” So I got on the English mailing list and started to learn Ruby (version 1.4).

My experience before was with very static languages. I had started (like many people in the earlier days) with BASIC, FORTRAN, and Pascal. Then I learned C, C++, Java, and various other things along the way. But I was never exposed much to LISP, and I never knew Smalltalk. So the whole concept of a dynamic language was a little foreign to me. I had always known that I wanted more power, but I wasn’t sure exactly what I wanted. I tried to envision macros that would give me the kind of flexibility I wanted, but it seemed like the wrong solution.

Then I learned Ruby, and I felt that I had taken not just a single leap forward, but three leaps. It was clear to me that this was very similar to what I had been looking for subconsciously.

AkitaOnRails: The Pickaxe is another must-have book, but it serves the role of a complete ‘Reference’ book whereas your book is about inner underpinnings and foundations of the language – heck, you spend 40 pages just talking about String, if this isn’t detailed enough I don’t know what would be. What was your intent when you wrote the 1st edition, how it came to be?

Hal: I met Dave Thomas and Andy Hunt online on that mailing list. At that time, their excellent book The Pragmatic Programmer had just come out, and they were working on the Ruby book. I was one of the reviewers of that book – helping to iron out little inaccuracies and problems.

A little later, Sams Publishing went looking for someone to write a book. At that time, the English mailing list had very few native speakers of English, so I had a good chance of being picked. I submitted a proposal, and they liked it.

The Pickaxe wasn’t on the shelves yet, but I had intimate knowledge of its contents. So when I put together the proposal for the book, I tried to make sure it was not in direct competition; rather, I wanted it to be complementary. If you look on the “praise page” of the first edition, there is a quote from me, saying “This is the first Ruby book you should buy.” But privately I was already thinking: “And I know what the second one should be, too.”

AkitaOnRails: As detailed and complete as you try to be Ruby has several subtleties and nuances that are hard to capture. Was there anything that you didn’t cover at that time that you would’ve like to spend more time with?

Hal: There are certainly some subtleties with classes and modules, reflection, metaprogramming, and that kind of thing, that are not mentioned or not stressed. But in general a programmer shouldn’t be “too clever” when writing code anyhow.

The most glaring omission, I think, is that there is no coverage of writing C extensions. In the first edition, I simply ran out of time, energy, and space – I couldn’t cover that. In the second edition, I omitted it because I thought the C API was going to undergo radical
changes as we approached Ruby 2.0 – more radical changes than the core classes, for example. I think this is turning out not to be true, however.

AkitaOnRails: You probably stumbled upon many Ruby students and enthusiasts that were learning Ruby through your book. By your experience, what do you think people get most amazed about the language, and what are the features that bite them initially?

Hal: I think the conciseness is one really attractive feature. Take a look at this single line of Ruby, which creates two accessors for a class:

attr_accessor :alpha, :beta

How would you do that in C++? Well, you would declare two attributes; then you would write a pair of “reader” functions and a pair of “writer” functions. What’s that, at least seven lines of code right there? But then what if you want to be able to assign different
types to these? Now you have to get into overloading. It quickly becomes a nightmare. Meanwhile, in Ruby — it’s still just one line of code.

AkitaOnRails: What do you like the most about Ruby that sets it apart from other similar languages?

Hal: One of the best features about Ruby is dynamic typing. Variables don’t have types; only objects have types (or should I say, classes). Static typing was so ingrained in me that I assumed it was the right way. But when I gave it up, I felt as if I had removed weights that I didn’t know I was wearing.

Its regularity is also an appealing feature. For example, a class in Ruby is in a sense a “special” thing – but not nearly so special as in (for example) C++. A class is “just an object,” so you can do things to classes that you can do to other objects – such as pass them around, store them in arrays, test their values, and so on.

AkitaOnRails: And what would you improve if you were the guardian of it?

First of all, I’m glad I’m not the guardian of it. Matz does an excellent job, and he is much smarter than I am. I think there are some issues with reflection and dynamic programming that need to be cleaned up — exactly how, I’m not sure.

I look forward to a truly usable virtual machine, and I look forward to some form of method combination (pre, post, wrap). I admit, though, there are small syntax and core changes I would like to make – mostly pretty minor.

For example, I’ve always wanted an “in” operator that would be syntax sugar for calling the include? method – for example, “x in y” would mean “y.include?(x)” – this operator would be essentially the same as the set membership operator in mathematics (instead of the reverse) and would sometimes make code more readable and even make parentheses unnecessary sometimes. I’ve used the “in” operator in Pascal since I was 18; Python has it, even SQL to an extent. I wish Ruby had it, too.

Many times I’ve felt a need for a data structure that would be accessed like a hash, but would preserve the order specified in the code. For example, imagine a kind of “dynamic case statement” — we pass in possible matches and code to execute (as procs) for each of those matches. (It would have the advantage over a case statement that we can control the number of case limbs and their associated code at runtime.) Let’s implement it as a method called “choose” that we call in this way:

choose regex1 => proc { handle_case1 }, regex2 => proc { handle_case2}

Now, what’s the problem here? The syntax fools us into thinking that regex1 somehow precedes regex2 – but when we iterate over a hash, the order is not guaranteed to be the same as in the code. (That is a property of hashes, of course, not a bug.) So we can’t control or predict the order in which these are applied. And I have found several other cases where I wanted such a thing – an associative array, a set of tuples, that had a convenient syntax for literals and had an order.

There are two usual responses to my desire for an “ordered hash.” Some people say that I’m crazy, that a hash isn’t ordered and that’s that. Some people say I could always make my own class that behaved that way – which is true, except that I wouldn’t have the convenience of representing it as a “first-class citizen” in Ruby syntax. After all, a hash “could” be represented as a second-class citizen as well – I could say

Hash["a",2,"b",4,"c",6]

instead of saying:

{"a" => 2, "b" => 4, "c" => 6}

But I am glad for the expressiveness of the latter syntax.

AkitaOnRails: Your second edition covers Ruby 1.8. Are you researching into Ruby 1.9 (YARV) already? Being a Ruby veteran, what do you think of the directions Matz and Koichi have been choosing for the next version? Is it satisfying for you? For you, what are the good, the bad and the ugly about Ruby right now and the next version?

Hal: There have been minor points where I disagreed with Matz from time to time. But as I said, I am glad he is in charge. I like YARV from what I have seen so far. I am anxious for it to be 100% stable so that I can really get a feel for how it works.

AkitaOnRails: Your book is in the second edition, and it is a huge book, covering not only the language itself but a few 3rd party components as pdf_writer. Are you working on a 3rd edition? Maybe we will have “The YARV Way”?

Hal: I am not working on a third edition, and I think it would be very hard to write one. The second one was harder than I expected – although much content was re-used, it still had to be re-examined line by line – and more than 50 errors still crept into those 800+ pages.

I once joked that if there was a 3rd edition, it might have to be two volumes. But really, that might not be such a bad idea – basic concepts and core classes in one volume, standard and third-party libraries in the second. But that’s idle speculation. There is a kind of add-on for the book being planned – but I won’t mention that until we know more details. Ask me in a few months.

As for YARV – I think Ruby will always be Ruby. We may change the inside, but the name will remain the same for the foreseeable future.

AkitaOnRails: Around 2002 Ruby was not widely adopted and only a handful of hobbyists and enthusiasts were using and helping to improve the language. Yourself, David Black, Nathaniel Talbott, and a lot of big guns from what I call ’the first Ruby generation’. But in 2004 came this full fledged web framework called Rails that made Ruby publicly known and acknowledged, attracting many great minds but also a lot of trolls and amateurs. I hear that some in the first generation regret it because what was once a peaceful and insightful community became very noisy. What are your thoughts about this sudden celebrity status that Ruby gained and its side-effects?

Hal: Well, Ruby isn’t a private club. I wonder if the Japanese felt any offense when Europeans and others started to be interested in it? I think that we’ve certainly lost a little bit from the old days, but I don’t waste any time thinking about it. We’ve gained quite a bit also. And it’s interesting that the “friendliness” of the community has scaled better than many of us expected. Ruby is still Ruby, and Rubyists are still Rubyists. It’s just that there are more of us now – also more projects, more activity, more opportunities. That can only be a good thing.

AkitaOnRails: Do you work with systems development in pure Ruby or do you use Ruby on Rails for web development today? What’s your occupation or day job?

Hal: I’ve done a little work with Rails here and there, but I’m more of an old-fashioned generalist. I’m not a web guy. Many younger programmers, of course, seem unaware that there is any other kind of programming to be done. But if you were writing a compiler or interpreter, a custom web server, any kind of daemon or background networking app… would you reach for your Rails book? Of course not.

I’ve done system-level work in the past, but I can’t imagine Ruby ever being appropriate for the kinds of things I did back then. For those things, we used C (the universal assembly language). In my day job, I’m happily coding Ruby every single day – telecommuting for a Dallas
company called Personifi. I’d describe my work as internal applications and tools – a lot of text analysis and indexing, a little number-crunching and a lot of word-crunching.

AkitaOnRails: Here in Brazil we have a lot of people that were initially attracted by the Rails hype machine, now they are struggling to learn the Ruby language. Metaprogramming, Closures, Mixins, make them go nuts. Do you have recommendations for new comers?

Hal: What would be a good way to start experimenting with the language? Well, you can keep a copy of The Ruby Way nearby. :-)

Really, I only have three recommendations. First of all, the mailing list or newsgroup is a powerful source of information, and there are still friendly and knowledgeable people there who will answer your questions. Second, there are millions of lines of Ruby source
out there. Study it and learn from it. Third, and most important: Just play around! You don’t really learn a language by reading about it, but by using it.

AkitaOnRails: By the way, are you already writing a new edition? :-)

Hal: I’m not, and I can’t see ahead that far. But wait six or seven months, and I do hope to have a little surprise for you…

AkitaOnRails: In the light of the current Zed episode, he said a lot of thing specifically against the Pickaxe. One of the things is his claim that the Pickaxe didn’t mention clearly all the meta-programming stuff. Then I was talking to ‘arton’ – a Ruby book author from Japan – and he reminded me: americans and japanese seem to do Ruby differently. He said that they don’t usually do all that meta-programming in the level that Rails does, for example. As you said, they don’t try to be “too clever”.

Now, I don’t want to be apologetic because I don’t think Dave needs it, but this explains a lot given that the Pickaxe mostly only had japanese sources to rely on back in 2001. I personally learned most of my Ruby reading the Rails source code at first (and books like yours later). What do you think about this? (meaning, about the Zed episode in general, and about the different american/japanese programming styles?)

Hal: As for Zed, I won’t take any sides in that discussion. Zed can say whatever he wants, and usually does. I’m sure there is some truth on both sides of any controversy.

As for metaprogramming – well, I think those capabilities are in Ruby for a reason. They are meant to be used. But any tool has both appropriate and inappropriate uses. It’s impossible to generalize and say “this is always bad,” but certainly metaprogramming can be misused.

As for Rails itself, I have no doubt there is both good and bad code in it. I suspect the developers working on it would admit as much. And it is possible that they have used “too much magic” here and there, though I couldn’t say specifically where. But could Rails exist without metaprogramming features? Not in its current sense — not in any meaningful sense, I would argue.

AkitaOnRails: I interviewed Avi Bryant, from Seaside fame, and one of his mottos is that ‘a language is not finished until it can extend itself’ or ’turtles all the way down’ as he says. Meaning, that Ruby still relies a lot on C extensions to this day. Of course, the initial motivations for Ruby are different than Smalltalk. On the other hand people like Evan Phoenix are pursuing this very goal: make Ruby be extensible using pure Ruby. What do you think about this new direction?

Hal: I like the idea of “Ruby in Ruby” in general, though Matz does not. And I am impressed with what I have seen of Rubinius so far – I think it is an important project and will grow more important.

If it’s possible to move toward an elimination of C extensions without sacrificing speed, I suppose that’s a good thing. I am not sure if it is possible. We might at least create a “Ruby in Ruby” that does not rely directly on MRI (Matz’s Ruby Interpreter). But I don’t expect to see the “original Ruby” replaced any time soon.

AkitaOnRails: This was a very insightful conversation, thank you!

Peter speaks about Ruby on Rails, business, novices and, as a last-minute exclusive, he comments on the recent Nuclear Zed episode that shocked a lot of people in the community. Just to clarify, Peter answered my questions before New Years Eve, it’s only the last question that was added today.

Once again, I deeply apologize to the brazilian audience because I didn’t have time to translate this into Portuguese today, but I will do very soon. Stay tuned.

AkitaOnRails: For the Ruby community Peter Cooper stands for Ruby Inside. I personally enjoy reading your website as it accumulates most of the important Ruby and Rails news out there. Let me thank you again for adding my blog to your sidebar list. But how did it start? What do you think were the most important steps you made to build its good reputation?

Peter Cooper: Ruby Inside began as a vehicle for promoting my forthcoming (now released) book, “Beginning Ruby.” The name itself came from a comment made in an interview Geoffrey Grosenbach did for the Rails podcast where someone adapted Ruby into the old “Intel Inside” slogan, which sounded like a great name for a blog covering Ruby issues. Initially, the blog was simply to promote the book, but it quickly turned into a digest of news from the whole Ruby community. I think the key to its success was that the larger Ruby blogs at the time, the O’Reilly Ruby blog being a good example, were posting less and less as their writers were getting more and more Ruby work. Ruby Inside filled a gap of providing heavily digested news from the whole Ruby community, with only one or two posts per day, allowing Ruby developers to keep up to date with things, but without having to subscribe to hundreds of blogs.

AkitaOnRails: Looking through your LinkedIn profile I see that you’ve been quite involved with internet-based business for the last 10 years. You also describe yourself as a ‘serial entrepreneur’. Entrepreneurship is something very difficult here in Brazil, mainly because of economics and overwhelming bureaucracy involved. How difficult is it there in England to open and run your own business?

Peter: It’s very easy to start up in business in the UK. Depending on what you want to do, you can just say you’re a business right away, without filing any papers (although you do have to call the tax office to let them know!), and operate as a “sole trader.” Registering a business officially, however, is quite easy too and gives you a number of legal protections and a more professional image. Getting funding and so forth isn’t particularly easy here, compared to the UK, but if you’re willing to bootstrap, then the UK’s very good for easy banking, fast communication, and trading with the rest of the world. With the natural advantage of the English language, the US market is easy to target from the UK.

AkitaOnRails: Your other most well known products should be Code Snippets and Feed Digest. Can you introduce both of them to our Brazilian uninitiated? How did the idea occur to you? It was something like ‘scratching your own itch’ or it was something totally unrelated and maybe following some trend that you identified? What tools did you use to build them? Many people are interested to know what does it take to build a successful product. What do you think it takes to be a good internet entrepreneur?

Peter: Code Snippets was the first del.icio.us-style “tagged” public code snippet repository. In fact, I believe it was the first Rails application to use tagging at all, as I wrote the earliest code which was appropriated into a number of following tagging libraries. The site was launched in early 2005 and I sold it in February 2007 to DZone. Feed Digest is a service for mashing up, processing, and re-publishing RSS and Atom feeds into other formats, such as HTML, JavaScript, Flash, images, and so on. I sold it to a Russian company in the summer of 2007.

Both businesses / sites were a result of “scratching my own itch” as you say. I needed a system to store code snippets in a tagged way, and del.icio.us was not suitable for this, so Code Snippets came out of a 24 hour coding marathon, was publicly released, and then grew to thousands of users over time. Feed Digest evolved from an earlier service called RSS Digest that I created to scratch another itch, republishing my del.icio.us links onto the header of my blog. It grew far beyond that though, and now has over 25,000 users and serves perhaps about half a billion requests each month. I no longer own or have a direct interest in either of those projects now though, but I must be doing okay on the chart of people selling Rails apps!

AkitaOnRails: I congratulate you on your recently published book, from Apress, Beginning Ruby, from Novice to Professional. As Larry Wright states in his review, he is right that the Pickaxe is a good Reference book, but you take a different approach in being more careful about actually ‘teaching’ the environment. It does fill a gap as there are more and more people interested in learning Rails but lacking an introductory book to learn Ruby itself. Please, describe your book for our audience as I think many Brazilians don’t know about your book yet. What’s its target audience? What do you talk about?

Peter: The book is currently only available in English, unfortunately, so the US has definitely been the biggest target market so far. Content-wise, the book is very reminiscent of the “classic” programming tuition books I was brought up on in the 1980s. It takes a very “walkthrough” approach, with the installation of Ruby coming first, followed by a walkthrough of all the main concepts regarding object orientation, Ruby’s syntax, and the basic data types. Eventually, by the end of the book, the reader has gone through file operations, database usage (there’s even an SQL primer), developed a text adventure game, built a simple Rails application, and so forth. It’s very much a book you’d go through, as a beginner, from beginning to end, and then move on to more advanced books like the Pickaxe or The Ruby Way. Hopefully we will see it in Portuguese one day!

AkitaOnRails: And speaking of beginners, again I think it amusing to read at your LinkedIn profile: Does “left school at 16” count? If so, I’m in. Education is great for most, but overrated if you’re a grafter. I dropped college to work in the Internet bubble as well (though not as an entrepreneur, which I regret). I don’t recommend people to just drop college as I did, of course, this is a personal choice and everybody should take an educated decision about their own future. But there are a lot of people – at least here in Brazil – that praise certifications and diplomas much more than hands-on experience. Sure, there are very good certified developers, but there are more bad developers that actually ‘believe’ in their own certifications as a graduation for competency! I don’t see any correlation between diplomas and good developers. What is your opinion about this matter?

Peter: I have a lot of respect for people who take the academic route, and feel that in general they turn out to be better at their jobs than the less well educated. One of the downsides to being indoctrinated in academia, however, is that people with many degrees, certifications and diplomas often act like technological automatons, only understanding one course of action, not able to think dynamically on the fly, and unwilling to try radical new directions. There is a lot of room in the world for people like that, but on the other foot we also need a lot of “crazy” people who try things that initially seem idiotic or radical.

The other problem with people who brag about their certifications is that in many cases they are just proving that they managed to pass a test. Passing a test and having a lot of knowledge doesn’t necessarily mean you develop good problem solving skills or can work as a true developer, architecting solutions from scratch. For example, a builder might be excellent at building houses, but he’s likely to be very poor at actually designing buildings, which is an architect’s job. In IT, especially within smaller companies, it’s often necessary for developers to fill both architectural and development roles, and many people with certifications, but little real world experience, struggle with the design of systems.

AkitaOnRails: We are both Ruby and Rails evangelists, of course, but as myself I don’t see you as a ‘blind’ developer, meaning, the kind that needs to make everything else look bad just to justify putting Ruby up on a pedestal. I actually believe in the ‘right tool for the job’ approach. Not even DHH states that Rails is the solution for every use case. That said, I think Rails is the best approach for a niche of web development. Recently I involved myself – and I regret it – against a troll rant from a Brazilian .net advocate. I don’t dislike .net, far from that. Anyway, do you see yourself involved in rants like this? Or you do try to avoid them altogether? What is your opinion about ‘X vs Y’ type of discussions?

Peter: I think it’s possible to play interesting political games in any situation. As a regular human being I do have, of course, biases and preferences, but it’s important to recognize these for what they are and still be able to see the big picture. I believe in trying to use the right tool for the job (or, more accurately, the most efficient tool for the job – I’m not going to learn a whole new language just to solve one problem), so Ruby Inside runs on WordPress , a PHP-based weblog platform. In terms of bias, I’m certainly rather anti-Microsoft, although I do acknowledge that their approach to the development of GUI applications is light years ahead of everyone else.

I don’t try to avoid or become embroiled in X vs Y types of discussions, although I do tend to play devil’s advocate when they come up. It is important to remain as scientific and objective as possible in these situations, but I’ll certainly let a little bias show from time to time, as any human would. For example, I (and I’m far from alone on this, although a lot of people seem not to want to rock the boat publicly) am not particularly keen on David Heinemeier Hansson’s overprotection of the terms Ruby and Ruby on Rails, and especially the Rails logo to the point where he rejects the Rails logo’s usage on books that he has not personally worked on. I’m not afraid to show some bias and reference issues like these from time to time.

AkitaOnRails: This leads to another question: everyday I see people here asking us “Why should I choose Ruby on Rails over X?” Personally, I think there is no clear answer for that. Being experienced in many platforms like ASP.NET, Java, PHP, Perl, I did my choice based not only on raw performance (which Ruby lacks, for now), not even a mature library set (which is evolving fast, though). Some reasons were based solely on me being happier with this platform. I do think Ruby enables me to write more ‘beautiful’ code as Marcel Molina Jr. explains. But “Beauty is in the eye of the beholder”. What’s your take on this matter? Being an experienced programmer in other platforms, why did you choose Rails?

Peter: I was a Perl developer before I came across Ruby and Rails, and when I did see Rails, the first thing I did was try to clone it in Perl. Unfortunately, I’m definitely not in the top 10% of programmers, by any means, so my attempt was messy. I tried using Rails directly, reluctantly, with a self promise not to get suckered in to learning a whole new language, but merely to develop what I needed to develop at the time. Of course, the rest is history and I’ve been converted over to Ruby entirely, due to its consistency, ease of use, and the way it just feels like a “natural” language.

Back in 2004, Ruby’s library set was poor, RubyGems wasn’t popular, and there weren’t many books available, so it seemed like a poor choice, but these things have all changed very rapidly, and I’d say Ruby’s library set in 2007 competes very strongly with, say, Python, and while the raw numbers are behind those of Perl’s CPAN, the quality and modernity of Ruby’s libraries exceed it. Ruby is now a strong choice.

AkitaOnRails: I have to extend this theme because I think it is relevant as we see more and more switchers to Rails. I see 2 kinds of developers coming on board: the first being experienced programmers that were not satisfied with their current day-jobs and tools and wanted to try something new and refreshing. The second being novice developers that think Java or .NET have a higher learning curve than Rails. The latter worries me a little bit because some tend to think that Rails is too easy to be considered professionally and some even get frustrated in finding out that Ruby is not Basic, and you do have to make an effort to learn its way. You do training as well, what is your experience dealing with newcomers?

Peter: I have not dealt with anyone who’s completely new to Web application development, so I cannot give a strong answer. However, I certainly don’t feel that people are choosing to learn Ruby or Rails because it’s perceived as “easy.” Indeed, I think it’s the more experienced developers who consider Rails to be easy, and that’s why they’re giving it a go. Beginners tend to just go with whatever is in fashion at the time or what’s the most popular. There’s no shortage of newcomers to all of the major languages right now, it’s just that Ruby is now getting its fair share at last.

AkitaOnRails: 3 years ago the majority of developers predicted the “demise” of Rails as a viable alternative. Today we just saw Rails 2.0 out of the door and the Rails community growing faster and stronger each day. Now people do think of Rails as the contender to beat. I think this is a good thing because we tend to move faster (develop more gems, innovate more) when we are under pressure. Do you think people are accepting Rails more or do you still see barriers for Rails adoption, at least there in England or Europe in general?

Peter: I disagree with your assertion that three years ago a majority of developers predicted the demise of Rails. I think there were just a lot of defensive programmers choosing to disregard it. I also don’t think the majority of developers on other platforms see Rails as something to beat. There’s actually a lot of blindness in the branches of the programming community to the efforts being made in other branches. The majority of .Net developers don’t care about, and most likely haven’t heard of, Ruby or Rails. Developers on dying platforms, such as Cold Fusion, are more familiar with Rails, simply because they’ve been looking for alternatives, but Java and .Net are still taking on new developers at a far higher rate than Ruby and Rails. There is a large difference in what the blogs and other online media want to report and what’s actually happening out there.

AkitaOnRails: There were many things that Ruby was lacking and now we just saw Ruby 1.9 released. It is still no stable 2.0 but this is a clear sign that the language is evolving fast as a mature platform. Free performance is always welcome, but this release will break many things. Are you already using 1.9 or do you feel it’s still not ready for prime time?

Peter: I’ve played with Ruby 1.9 a bit, but I don’t routinely use it. I don’t consider myself a programmer in the academic sense. I like to be aware of, and dabble briefly with, technologies on the fringes, but I’m not one of these super-programmers who downloads, say, Erlang or Haskell and tries to learn it in a weekend. Ruby 1.8 will definitely remain my main Ruby interpreter for at least a few months yet.

AkitaOnRails: Our Brazilian community is still very young and small, I usually describe it as the US community from 2004 ~ 2005. We still didn’t reach critical mass. How are things going there at England or Europe? Is your community big enough that the market started to demand Rails related professionals already?

Peter: The market in the UK is still very small. There was literally nothing in 2005 but things have grown quickly in the last couple of years, although it’s still perhaps 1000th the size of the market for Java or .Net services. There are usually a handful of Rails related jobs floating around, but so far I’ve found that Rails is a technology that agencies are using for their clients behind the scenes, rather than something being actively demanded. I am not directly involved in the UK Ruby or Rails communities, however, so I cannot provide much more detail than this.

AkitaOnRails: This is just for amusement: if you were DHH or Matz what would you like to change in Rails or Ruby? Or maybe, where do you see both of them leading to?

Peter: If I were DHH, then Rails probably wouldn’t exist, simply because I think a lot of his excellent evangelism of Rails is driven by some craving of fame. At a more practical level, though, I would make Rails less opinionated and more customizable, simply because a lot of the opinions are too rigid to be practical in the real world. The initial opinion of relying on the database to provide information about model structure was a good one, but then along came migrations.. and suddenly we’re defining table layouts in code after all, often in many tens of different files! Why not just put the attributes into the models directly and let Rails take care of the schema changes transparently? DataMapper does this, and ActiveRecord is starting to look backwards in comparison with its bizarro approach.

On the Ruby side of things, I think Matz has done an excellent job technically, although whereas DHH scores high on the PR scale, Matz seems reluctant to promote Ruby at all. I think this is both because this sort of modesty is a honorable trait in Japanese culture, but also because Ruby is something he developed to scratch an itch, and another million or so developers using the language won’t benefit him significantly. He’s a great guy, but he lacks the craziness of Larry Wall (Perl) and the authority of Guido van Rossum (Python) and is incredibly lucky that he can rely on a very strong and vocal community to promote Ruby. One benefit of Matz’s hands-off approach is that people feel that they can take authority over various areas of the language and community for themselves without having to answer to a higher authority.

In terms of the technical side, the only thing I’d perhaps do if I were in control of the development of the Ruby language would be to make heavy pushes towards more functional constructs in Ruby 2.0. JavaScript and Perl 6 are taking strides into the world of functional programming, and Ruby needs to follow. I’d also be considering concurrency very strongly and making this a major focus for new language feature developments.

AkitaOnRails: What would be your recommendation for novice Railers here in Brazil? I mean, for those that wants to learn both Ruby and Rails but may need some guidance to start?

Peter: Well, if you can speak English, then naturally I’m going to suggest my book “Beginning Ruby” published by Apress! Unfortunately I’m not familiar with Portuguese resources for learning Ruby or Rails, although I’m sure you are! One free resource I would definitely recommend to newer developers is Chris Pine’s “Learn to Program.” It’s available as a print book, but a more raw version is available to read free online.

AkitaOnRails: Now, speaking of information, we had a very explosive new year beginning. Zed Shaw literally exploded in rants, cursing and every form of aggressive communication. As I stated in my previous article I was personally shocked at first, but I read it through – trying to filter down all the hatred, and uncivilized manners – and there’s actually some information buried there. What is your take about this episode?

Peter: Personally, I think Zed is spot on. I don’t like the way he has specifically attacked a few people personally (Kevin Clark, for example) for minor infractions. His language is harsh, and he clearly has a lot of vitriol. Behind all the swear words and chest beating, however, is a lot of truth. I sympathize with his main arguments, especially those raised in the “round two” update published on January 3rd.

Zed touches on the way some people form into elitist, ego driven gangs, such as Rails Core and the caboo.se. I was involved with the caboo.se for a while myself, and I have a great respect for many of its members (Courtenay Gasking and Amy Hoy, for example), but the whole thing stank too much of elitism to me, and I’ve distanced myself from all of this Rails related online socialization. I could recall quite a few pathetic condescending incidents from members of these communities myself, but unlike Zed I leave quietly. I think one of the biggest causes of the tension, gang-forming, and general childishness is that many of the people involved with these gangs have no social life outside of this community. This probably explains why parlor games like Werewolf and general goofery are so popular at the conferences, as opposed to, say, actually revolutionizing the field.

Lastly, Zed is spot on with his comments about the “Programming Ruby” book, more commonly known as the “Pickaxe.” I tend to remain politically correct on this subject, especially as I have a competing book, but the Pickaxe really is stunning in its mediocrity. It sells well because it has first mover advantage and name recognition, and no-one else has bothered writing a better reference book (The Ruby Way is excellent, but it’s not a reference book). For having the only printed Ruby reference book, Dave Thomas deserves credit, but it’s still mediocre.

AkitaOnRails: For the good or the bad, I have mixed feelings about this whole episode. I won’t judge anyone yet. Let’s see how it unfolds. And of course, I really appreciate Peter Cooper’s patience with me, kindly answering all my questions. Thanks a lot!

As I promised after the Avi Bryant interview, here’s a great conversation with Adrian Holovaty, well known creator of the Django web framework written in Python.

For me this is an important piece because I always say that technology doesn’t have to be about divorce. Technology is about integration. I am a full-time Ruby on Rails developer and evangelist, but above all, I try to be a ‘good’ programmer. And good programmers acknowledge good technology and their creators’ achievements. And Adrian’s Django is such a remarkable achievement that deserves its attention and success.

So, as my very first post of the year (published at 0:01hs!), I would like to celebrate the great minds of our ‘development’ community, wishing that the good developers use their time creating great technology instead of wasting it in useless flame wars.

AkitaOnRails: As I always do, let’s start by talking a little bit about yourself. How long have you been a programmer?

Adrian Holovaty: Let’s see — I’ve been tinkering with computers since I was a little boy playing with the Commodore 64 in the mid ’80s.

One early program I wrote was for the TI-85 calculator in my high-school math class. By the time I graduated, a whole bunch of students were using it, because it had all the formulas and stuff.

I didn’t take any of this stuff seriously until college, when I minored in computer science. But I didn’t end up finishing the minor, which is something I’ve always been bummed about.

My college major was journalism, as I originally wanted to be a newspaper reporter, but after I took a job with the Web site of the campus newspaper (The Maneater – best name for a newspaper ever!), I realized I would have a lot more fun working online than with a dead-tree product.

So I ended up finding a way to combine journalism/news and computer programming, and I’ve had a number of jobs doing exactly that!

AkitaOnRails: And what led you to the computer world?

Adrian: I guess it was in my upbringing, as my dad has been a computer programmer since the ’70s, back in the punchcard days. I remember seeing all sorts of those punchcards in our house when I was growing up.

AkitaOnRails: And, of course, how did you meet and fall in love with Python?

Adrian: My Web development path was (I think) pretty typical, at least based on the experiences of my friends and colleagues. I originally learned how to write Perl CGI scripts in a college Web development course. Then I taught myself PHP because somebody recommended it to me.

After doing Web development with PHP for a few years, I got kind of tired of it. At that time, I was working with Simon Willison at a newspaper Web site in Lawrence, Kansas. Simon and I were both getting tired of PHP and decided to “dive into Python” (pun intended) by reading Mark Pilgrim ‘s excellent book of the same name, which was released around that time. This must’ve been late 2002.

We immediately fell in love with Python. And when I say “immediately,” I really do mean it. It was like a revelation, some sort of divine moment. It was the programming equivalent of love at first sight.

So Simon and I decided that, from then on, we were going to code everything in Python. That’s one of the perks of working for a small Web development shop — we could make those kinds of snap decisions! 

AkitaOnRails: I was first introduced to Python around 2000 as well. But it was through web development using Zope. I think it got a lot of attention at the time. Did you ever try it?

Adrian: No, I never tried Zope. Still, to this day, I’ve never tried it. And I’ve been told that’s a good thing, because evidently it turned some people off of Python back then, for whatever reason. (Their newest version is supposed to be a ton better, but I haven’t tinkered with it, either.)

AkitaOnRails: You’re right, and it is kind of amusing because a lot of pythonists from Brazil still use Plone (I think it evolved from Zope but I haven’t tried it either). So, We all know that Django was born out of necessity when you were developing websites for World Online. Please describe how you began there and what the everyday work is like. Maybe what led you to Django during your work day?

Adrian: Sure! Well, generally when people think of newspapers, they think of crotchety, old-fashioned editors and reporters scribbling in paper notebooks with pencils. This Kansas newspaper that I worked at was the complete opposite of that. It’s beyond the scope of this interview, but for a number of reasons that newspaper Web site attracted (and still attracts, to this day) a really great development team — one that I would stack up against any team 10 times its size.

We were doing “Web 2.0” stuff back in 2002 and 2003, and we were building Web apps in days, not weeks or months. This was mostly due to the journalism environment – newspaper people like deadlines. 

So we were in this culture of “Web development on journalism deadlines,” and we needed some tools that let us create Web applications quickly. We looked around at some existing Python libraries at the time (2003), and we ended up deciding to write our own stuff.

We didn’t set about to make a framework – it was a very classic, clichéd path, actually! What happened was, we built a site with Python. Then we built another one, and we realized the sites had a fair amount of code in common, so we did the right thing and extracted the common bits into a library.

We kept doing this – extracting and extracting, based on each new Web application that we created – and eventually we had a framework.

AkitaOnRails: As a side-note, actually this is kind of interesting! I would love to hear what do you think World Online has that attracts good developers like yourself! Just a summary would be ok. That’s the kind of insight brazilian companies have to learn better. Letting you do Python is probably one of them 

Adrian: Yeah, it kind of comes down to empowering the employees. My boss, who led the Web team, delegated all the technology decisions to me and Simon. That kind of culture really encourages quality work, because it makes everybody on the team more invested.


AkitaOnRails: You’re right. Traditional companies would rather have a more hierarchical (and bureaucratic) approach, with a dumb manager holding the whip. But I digress. So, I particularly dislike language x VS language y or framework a vs framework b kind of comparisons. Instead I’d like to hear what do you think is great about Python – the language and the platform – and Django. What are the features in Django that you hold dear to yourself, I mean, those bits of functionality that you actually think for yourself as ‘the’ greatest ideas?

Adrian: Well, I love abstractions – like, I suspect, any programmer. At its core, Django is just a set of abstractions of common Web development tasks. It gives me joy to create high-level abstractions, to encapsulate a large problem in such a way that is made simple.

What I really like about Django is the depth and breadth of abstractions that it provides. And in most cases (I hope!), they’re clean, easy to use and understandable.
Let me give you an example of an abstraction: creating an RSS feed.

When you create an RSS feed, you don’t want to have to deal with remembering angle brackets, and the exact formatting of the feed — you just care about the items in the feed. So Django provides a very simple library that lets you give it a bunch of items and creates a feed from them.

So that’s an obvious example, but what really excites me are the higher-level abstractions, like the concept of an “admin site.” Django comes with a completely dynamic application that makes a beautiful, production-ready CRUD site for your database. There’s no code to write – it’s only a small bit of optional configuration.
There’s also something called Databrowse, which is an abstraction of the concept “Show me my data, as intelligent hypertext.”

So whenever I’m explaining Django to someone, I always end up saying, “It’s just a bunch of abstractions of common Web development tasks” – from low-level HTTP wrapping to higher – and higher-level concepts. The higher you get, the more productive you can be. I apologize if this is too conceptual!

As for Python — what can I say? It’s gorgeous. It’s like poetry. It’s so clean, so logical, so regular, so obvious. And the import system is to-die-for.

A lot of people say Python code is easy to read/understand because of the consistent whitespace and simplicity of the language. I agree with that, but I think it’s also due to the elegant import system. Why? Because if you want to know how any Python module works, just look at the code, and look at the modules it imports. As the Zen of Python says, “Namespaces are one honking great idea – let’s do more of those!”

AkitaOnRails: Tech communities are great because they are so energetic and passionate. On one hand you have those that contribute and make the technology grow faster. On the other hand you have the pundits and trolls that like flame wars. Do you burn yourself sometimes, or do you tend to avoid this kind of discussion? Specifically, some time ago you and DHH were together at the Snakes and Rubies presentation. I think it was great because it didn’t end in yet another flame war. What’s your opinion on this kind of open (not flamed) discussion?

Adrian: The answer to this one is obvious – clearly constructive discussion is more productive.

At times, I’ve had my passion for Python/Django get the best of me, but I’ve gotten a lot better over the years. I’ve realized something: At the end of the day, what really matters is the sites people create with these tools, not the tools themselves. If you’re going to judge someone, judge the sites that person makes, instead of the tools that person uses.

These days, if I am involved in any sort of discussion like that, it’s usually to try to calm people down. 

AkitaOnRails: Well said. Going back to features, you mentioned ‘Databrowse’ before, I would like to know more about it. I think Django didn’t have it by the time I first tried it. Is it a new feature (or am I the one lagging behind?  Can you elaborate more on this construct?

Adrian: Databrowse is still quite under the radar! Here’s the use case.

Say you have a lot of data in your database, and all you want to do is look at it.
Here are your current options: You can drop into the psql or mysql prompts and run a bunch of SELECT queries, but that gets tiresome. You could run something like PHPMyAdmin, but that’s more of an administration tool than a tool for browsing. You could use some sort of external application that lets you browse your database tables, MS Access-style, but that’s in the realm of the desktop app.

Databrowse automatically creates a Web site that displays your data, so you can click around to your heart’s content.

The other thing it does is point out interesting, non-obvious queries. For example, if you have a table that has a DATE column in it, it will automatically create a calendar view of that table.

The point isn’t for people to use this to make public-facing sites – the point is for people to use this to explore their own data, with no effort required.

Another use case comes from the journalism world. I used to work with a guy named Derek Willis at the Washington Post newspaper. His job at the time was to acquire huge datasets and place them on the newspaper’s intranet, so that reporters could search and browse the data in their research.

Derek didn’t want to have to hand-roll a Web app each time he got a new dataset, so he used Databrowse to make intranet sites that displayed his databases — with little-to-no effort.

This comes back to what I was saying earlier about high-level abstractions. Databrowse is a particular type of abstraction, and it’s really cool that we include something like that for people to use, if they need it.

AkitaOnRails: Sounds great, I am looking forward to using it. In a degree it feels like Dabble Db – albeit inside your own app. I think you already met Avi Bryant ? I just interviewed him and it was a very insightful conversation. Have you ever tried Seaside? (out of curiosity I have a photo of you and Avi looking at his macbook sitting down in the grass, what was that?)

Adrian: Yes, it was inspired by DabbleDB – it’s essentially a very toned-down DabbleDB-ish thing for your own data. But I shouldn’t even say that, because DabbleDB is a whole universe more sophisticated than Databrowse. DabbleDB is awesome. 

Yes, I’ve met Avi a number of times and always enjoy his company. We even played some music together – he is a fantastic harmonica player!

The photo you’re referring to was taken at Foo Camp in 2007.
I haven’t tried Seaside, but it’s on my to-do list. If I were ever developing an application like DabbleDB that needed to maintain a ton of state, I would turn to Seaside first.

AkitaOnRails: I see, I feel that good musicians tend to be good programmers as well. So, my first congratulations for you is about your new book on Django that was just released. I think it is a very big milestone for the Django community. More than that you were able to make it available online under a Creative Commons license.

How did you get involved in this book? Was it difficult to convince the publisher to have the book readily available online? I ask this because at least in Brazil this is one idea that is VERY hard to push over to publishers. Tell us more about your writing experience, challenges and quirks along the way.

Adrian: Thanks very much. There’s not much to the story here – co-conspirator Jacob and I got contacted by the Apress folks, who were interested in publishing a Django book, and we did it. Well, I should amend that: It took us a long time , but we did it. 
It wasn’t difficult to convince Apress to let us make the book available online. They had previous experience doing so with Mark Pilgrim’s Dive Into Python book, and they’re generally cool people.

In retrospect, publishing the book online was a fantastic decision. Not only is the final book available online, but we made chapters available online as we wrote them, with a really nice per-paragraph commenting feature that let readers submit typos, corrections and suggestions on a very granular basis. We got a ton of fantastic feedback for which we’re immensely grateful. Having experienced this, I wouldn’t want to publish a technology book any other way.

AkitaOnRails: Now, my second congratulations is because of that Batten Award for outstanding achievement in online journalism. ChicagoCrime.org looks great and is a very good example of a mashup done right. Unfortunately our local government and public institutions have very little to almost no data available online for us to use. Where did the idea come from? How was its development?

Adrian: Thanks – and don’t let that site scare you away from visiting the beautiful city of Chicago. 

AkitaOnRails: haha, I live in São Paulo. Can’t be worse ;-)

Adrian: The idea for chicagocrime.org came when I was bumming around the official Chicago Police Department Web site and found that they publish crime data – although in an interface that’s more suited for searching than for browsing. I thought, “Wow, this is some great data!” and was writing a screen scraper within about 10 minutes.

Around that same time, I was tinkering with the Google Maps site, which had just launched, to see if I could embed Google map tiles into my own Web pages. I figured the crime data would make for a great mapping application, so I put the two together, and one of the original Google Maps mashups was born. While I was developing the site, HousingMaps.com (Craigslist + Google Maps) came out, so it beat me to the punch of being the first real Google Maps mashup – but chicagocrime.org came soon afterward.

The thing I’m most proud of is the fact that chicagocrime.org was one of the sites that influenced Google to open its mapping API. Back when HousingMaps, chicagocrime.org and the original crop of mashups came out, we were all reverse-engineering Google’s JavaScript!

AkitaOnRails: I know that you probably have 2 great passions in your career: one is Python-based development, or course, and the other is journalism (dunno the correct order here ) You’ve made yourself quite a reputation on the online media. You’re working at the Washington Post right now, is that correct? I read an article at the OJR where you explained about technology being used to empower the journalist. Do you intend to be a reporter someday or you’re more into the back-end of journalism? I think you have a strong opinion about the future of journalism in the Internet Era, don’t you?

Adrian: Well, I would say my main passion is music, but it’s hard to make a living doing that. (Django is named after the famous jazz idol Django Reinhardt)

I’m no longer working at the Washington Post. In mid 2007, I was awarded a two-year grant from the Knight Foundation to create a local-news site. So I founded EveryBlock in July. We’re a team of four people and are working hard to make a really cool application.

But, yes, going back to your question, I certainly have some strong opinions about how journalism is practiced on the Internet. This is probably out of the scope of this interview, but you can read my essay/rant awkwardly titled A fundamental way newspaper sites need to change for a taste.

AkitaOnRails: Now, that’s news to me  Didn’t know you started your own company (sorry, I still have to catch up with the Python community). Can you tell us about your new endeavor?

Adrian: Hey, I can’t blame ya – we’re staying under the radar. There’s not much to say about EveryBlock at this point other than it’s chicagocrime.org on steroids. It’s like chicagocrime, but for more cities than just Chicago and more information than just crime. 

AkitaOnRails: You should try it for Brazil :-)

Adrian: Thanks to Django’s internationalization framework, that is entirely possible. 

AkitaOnRails: Yeah, and by the way, (digressing a little) I would recommend the brazilian movie Elite Squad now that I know you’re interested in crime related data ;-)

Adrian: Noted! I’ve added “Elite Squad” to my MOVIES_TO_WATCH.TXT :-)

AkitaOnRails: Going on. Many great websites are already deployed over Django. Your own works at World Online, Washington Post being some of them. Another big name is Kevin Rose’s Pownce (the creator of Digg). You, Kevin and other influential people usually meet during conferences, don’t you? What do you think influenced him to try Django? Another great thing about Pownce has to be Leah Culver. A programmer like her is simply unheard of here in Brazil, which is a pity. You should make her the official Django cheerleader!

Adrian: I’ve never met Kevin Rose, but from what I’ve read, I believe Leah chose to use Django because either it had been recommended to her, or she liked Python, or something. I don’t know the backstory. I haven’t met Leah, either, but she was cool enough to travel to Lawrence, Kansas, for our last Django sprint a few weeks ago (which I couldn’t attend in person, unfortunately).

AkitaOnRails: It is not a rule written in stone, but in Rails community we ‘tend’ to praise Mac related tech. Of course, it is not a requirement for any language and Linux is as good. But what can I say? I am an Apple fanboy  I would like to know what’s your development environment. What tools do you use to develop your Django-based websites?

Adrian: I recently switched to a Mac after several years of using Linux on the desktop, but don’t read anything into that — I’m not a fanboy by any means, of either Linux or Mac. I miss Linux, to be honest, and in a number of ways I’ve been unimpressed by OS X’s Unix features. (Basic stuff such as readline support in the default Python is broken, etc.)

The nice things about the Mac make it worth the switch, though. Even after having used the Mac as my primary machine for 6 months, I’m still impressed that I can just close the laptop and it’ll go to sleep automatically. That never worked with Linux!

AkitaOnRails: I ask this because many people looking at Rails and Django are Java and C# programmers that are used to have a full blown IDE. I usually say that any common text editor does the job, and if you really want power vim and emacs are a perfect fit. What do you say?

Adrian: I’ve never used an IDE to program, so I’m the wrong person to ask.
Actually, I misspoke – I used an IDE-ish thing in college to program assembly. It showed the contents of the accumulators and that stuff.

AkitaOnRails: Oh, I almost forgot to ask: did you and Guido van Rossum ever met? I would like to know your opinion about the Python 3000 development. Is there anything that’s in the new version that you really anticipate?


Adrian: Yes, I’ve met Guido a number of times and was even lucky enough to have dinner with him once! It’s almost silly and unnecessary to say this, but he is incredibly smart.

I really like the new concepts and features in Python 3000, and I had the opportunity to participate in a sprint at Google Chicago a couple of months ago. My favorite feature is the migration to Unicode strings by default, because it forces the encoding issue front and center.

AkitaOnRails: Finally, what was all the fuss about Django being versioned 1.0 or jumping straight to 2.0? I didn’t follow the discussions, just read some headlines a while back. And what can people expect for the next release of Django? I understand that you don’t go big bang releases that changes the game, but what do you see getting released in the next few months in terms of new features?

Adrian: Ha – this is an amusing story. I’ve gotten worn out by people constantly asking “When is 1.0 coming out? When is 1.0 coming out?” My response always is, “Why do you need an arbitrary number assigned to the product? Many people are using the current version, so don’t hold back. Version numbers are pretty meaningless.”

So I suggested on the django-developers mailing list that we assign the version number “2.0,” as if to reinforce the fact that version numbers are indeed arbitrary. But, having given it some more thought, I’ve changed my mind on that. The amount of confusion it would cause would not be justified by the amount of rebellious pleasure I would get out of it.

As far as upcoming features, there are a number of ongoing branches of the Django codebase that will all eventually be folded into the main trunk. One is a branch called newforms-admin, which dramatically improves the amount of customization developers can make to the Django admin site. Another is queryset-refactor, which is a refactoring of our database layer, again, to make it more extensible. Other than that, there are a few small features that we need to wrap up, and it’ll be time for 1.0.

AkitaOnRails: Haha, I think you’re right, I don’t like this ‘cult of the dot-oh’ as well, it’s pretty meaningless for an open source project that’s constantly evolving. But some people do have some concerns specially in a more enterprisey-like environment. Anyway, and for those that want to see Django in action, what are the websites that you recommend people visit? Some of the Washington Post, maybe? Of course, some of the great features – as the admin site – are only for admins (duh)  But people like to see ‘living’ things instead of a bunch of tutorials.

Adrian: As an aside, I see that Rails David just wrote a rant about the same topic.

Good Django-powered sites? Let’s see – there’s Tabblo, a photo-sharing and editing site that has some really nice interactive features. There’s Curse.com, the massive online-gaming site. There’s lawrence.com, a site I helped build, which is one of the best local-entertainment sites in the world (if I may say!). And there’s a site (I forget its name) that will print a paper book from a series of Wikipedia articles that you specify – that blew my mind, the first time I saw it.

AkitaOnRails: So, I think we are done :-) That was a very pleasant conversation. I wish you have a great New Year.

Adrian: Thanks for the great questions and conversation, and happy new year!

As I always say – and Avi is good at pointing out —, Ruby has its drawbacks – most of them being improved on Ruby 1.9, JRuby and Rubinius. Avi gives us good reasons why Smalltalk is yet another great platform to learn, bringing back decades of evolution and maturity. So, here goes, the unabridged version of the interview.

And stay tuned! I hope to have Evan Phoenix, Hal Fulton, Peter Cooper and Adrian Holovaty as my next guests. Lots of material to begin 2008 in great style.

AkitaOnRails: Some people still try to make the case in favor of Smalltalk as it being the “purest OO language out there”. Even this being a fact, do you think that this alone is compelling enough to make a case against every other language, like Ruby which is kind of a multi-paradigm language? I hope you’re not pesky about ‘language pureness’ :-)

Avi Bryant: Actually, I am pesky about it – not from an academic or aesthetic point of view, but from a pragmatic one. “Pure” languages make a lot of things easier: development tools, VMs, and infrastructure like distributed object systems or transparent persistence all get much simpler and better when you have a small, consistent language.

One experience I had, for example, was being hired to port my client library for the GOODS object database from Smalltalk to Python; I spent a huge amount of time dealing with special cases in the Python semantics (is this a class? a type? a new-style class? implemented in python or in C?) that simply never came up in Smalltalk.

Ruby does pretty well here, better than most in the scripting language space – I wouldn’t call Ruby “multi-paradigm”, by the way – but it could stand to do better.

AkitaOnRails: I think you once said that you only consider a language “finished” when it is fast enough to extend itself. This is very true for Smalltalk, Java and other platforms. Ruby is undoubtedly lacking in its current position. That was one of the reasons we now have parallel efforts like John Lam’s IronRuby, Charles and Thomas’ JRuby and Evan’s Rubinius. One of the most criticized points is that Ruby doesn’t have a formal spec for the language or its core libraries. You also said that the Java VM is not suited enough for Ruby as Strongtalk would be, for example. Does this still hold today as we see JRuby 1.1 on the horizon?

Avi Bryant: It still holds. JRuby currently seems to benchmark on par with MRI, and the best numbers from any Ruby implementation are maybe 3X MRI on average. I think we can do 25X MRI for basic language feature benchmarks (message sends, block evaluation, etc), which should be enough to make Ruby implementations of the standard libraries feasible. Even if the net result was a similarly performing system, the side benefits would be extremely valuable.

AkitaOnRails: I remember that you started the Smalltalk.rb initiative a while ago, and if I am not mistaken it was an effort to make Ruby translate into equivalent Smalltalk code so it could run in any of the available Smalltalk VM implementations out there. Is this project still going on, do you still think it is feasible to pursue such a goal?

Avi Bryant: I still think it’s a worthwhile and realistic goal. The project is still going in the sense that I’m still talking to people about how to make this happen, but I’m not able to spend time writing code for it myself at the moment. I have some reason to hope this project will progress more concretely next year, but we’ll see.

AkitaOnRails: Some time ago I read a snippet of an IRC transcript between you, Evan, Chad and even Charles. You started talking about standardizing primitives (they are C-based in MRI today). My bet is that Rubinius is the project destined to be the “next big thing” for the Ruby community. To me it seems that you and Evan collaborate a lot, is that correct?

Avi Bryant: I wouldn’t say that, but Rubinius is certainly the Ruby project that most closely aligns with my own interests and goals at the moment, and it’s great to see how much effort is being put into it. Engine Yard also deserves a lot of kudos for their financial support of the project.

I have high hopes that the work Evan and crew are doing will be of great benefit not just to Rubinius but to all of the Ruby implementations – which is why I was advocating for a standard primitive set.

AkitaOnRails: You know a lot of people, I wonder if you ever talked with Koichi Sasada himself to input some of your ideas for the YARV project as it’s going to be the “official” Ruby virtual machine out there a few months from now.

Avi Bryant: No, I don’t believe we’ve ever spoken. I would certainly love to meet him some day.

AkitaOnRails: Then, we get one level up to applications. Your Seaside framework is pretty amazing. You’re very right about WebObjects as well. As a Java programmer I always pitied that it never got mainstream. Today it’s mostly relegated to Apple related websites, while lesser Java frameworks took the front. Tapestry and Cayenne are trying to top WebObjects’ features but seems they are nowhere near yet. Do you still program some Java? What is your opinion on current mainstream frameworks as Spring, JSF? For non-starters, what was it in WebObjects that makes it different than the rest?

Avi Bryant: I don’t do any work in Java any more (thankfully), so I can’t really give a qualified opinion on the state of frameworks there right now. However, the main thing I think WebObjects did right was to focus on the state and behavior of the application, rather than on the mechanics of URLs and HTML and HTTP requests.

So rather than worry about what a field was named, you would just say “this field is bound to this instance variable in my model”, and rather than worry about what URL a link went to, you’d say “this link triggers this method on my page object”.

Transitioning between pages was done by constructing a new page object and setting it up directly in Java, rather than constructing a URL that was going to be parsed to build a page. That directness and general style is something that very heavily influenced Seaside.

AkitaOnRails: Many people may not immediately understand it as a word that is new to most of them: “continuations”. Meaning that instead of manually controlling the flow between events, with manual marshaling and unmarshaling of objects, you program as a cohesive and continuing flow. Can you explain this in a way that a novice would understand? What are the benefits and drawbacks of this approach?

Avi Bryant: Well, it’s really all about being able to get modal behavior in a web app. In a desktop application, for example, you might occasionally have a call like “file = chooseFile()” or “color = pickColor()” that opens a modal dialog, gets a result from the user, and keeps going from there.

Seaside’s use of continuations is just to allow exactly that kind of interaction in the context of the web. The tricky bit is that because of the backbutton, the user might go pick a different color from the same dialog later, and the “pickColor()” call has to return a second time. This is confusing to think about, but mostly it Just Works.

From an implementation point of view, what we’re doing is saving a copy of the stack at the point the call is made so that we can come back to it later, more than once if need be.

AkitaOnRails: You started these concepts in the Ruby world with IOWA. Once upon a time there was a framework called Borges that was also discontinued. Then Koichi mentioned taking continuation support from the next Ruby. Do you think the Ruby world is taking a step back with lack of support for continuations?

Avi Bryant: Continuations are a great abstraction, and allow a lot of interesting experimentation with language semantics. However, I wouldn’t consider it a tragedy if they disappeared from Ruby; there are more important things to worry about. From a web perspective, I think that AJAX is starting to replace a lot of the use cases where having server-side modal logic used to be important – Dabble DB, for example, barely uses Seaside’s continuation features at all.

AkitaOnRails: Your blog has a peculiar name, HREF considered harmful. You probably got your inspiration from Edsger Dijkstra/Niklaus Wirth’s Goto Statement Considered Harmful paper where Edsger made his famous case against GOTO. At the assembler level it is impossible to not JMP all the time (at least not without some macro help) but at a C level you can avoid GOTO’s altogether. Even Basic had both GOTO and GOSUB and you could just ignore the former. I am being simplistic here, but now you’re kind of saying that URLs play a similar role in a way that they disrupt the normal flow, going back in unpredictable ways and so on. On the other hand the Internet would not be what it is without URLs. How do we deal with this conundrum?

Avi Bryant: I don’t think it’s a conundrum. I think your analogy is a good one: it’s impossible to not JMP all the time, and it’s also impossible not to use URLs all the time, but we don’t have to always be aware of either one. Back when everyone wrote in assembler, people probably obsessed about having meaningful or “pretty” JMP labels the same way they obsess about having pretty URLs today. I think we need to allow ourselves to make the same leap up in abstraction level on the web that we did with higher level programming languages.

That’s not to say we should never be thinking about URLs: any website needs to export meaningful URLs to be referenced and used externally, just like any C library needs to export meaningfully labelled function names so that it can be linked into other programs. But that’s as far as it needs to go.

AkitaOnRails: Components were a big deal in the early 90’s, with RAD tools and so forth. Today it seems that they are showing up slowly, with initiatives as JSF and ASP.NET. Rails initially packed a very crude support for ‘components’ but it was dropped very early on as a bad thing (because of the jury rigged way it was implemented). Nothing new came to replace it what feels like there wasn’t enough need for it at the Rails level. On the other hand Seaside is heavy in componentization. Can you expose a little bit about the differences in this approach?

Avi Bryant: “Component” is one of those terms like “MVC” or “open” that gets used to mean so many different things it’s hard to talk seriously about it. One concrete feature of Seaside’s approach is that each piece of UI is quite independent of what other pieces of UI may be on the page.

There’s no central controller which is responsible for request processing, choosing a template, or so on – all of those responsibilities are distributed among many smaller objects. There’s also no chance of naming conflicts because you don’t directly name links or form fields, so you can have many copies of the same form/widget/etc on the same page without any confusion.

This allows a level of modularity that’s very hard to reproduce in most traditional frameworks.

AkitaOnRails: Another thing that might shock some people is that there is no traditional templating system in Seaside, no code mangling between HTML tags all over the place. Instead all HTML is abstracted in a object hierarchy that renders itself. In the Rails world there are a few alternatives that attempt some of that, like HAML, Markaby. What do you think are the fundamental differences?

Avi Bryant: The HTML rendering API is a very core piece of Seaside, and a huge amount of the framework was designed with that underlying approach in mind. I think that’s the main difference when compared with HAML or Markaby, which are meant to be dropped into other frameworks.

Once you get rid of templates and switch to programmatic HTML generation, the design space just completely changes, and you need to re-evaluate almost every other decision that you made – this was a process that I went through with Seaside between the initial release, which used templates, and the 2.x versions, which don’t.

So I think we’ll have to see a framework that takes, say, Markaby as a starting point and asks “where can we go from here” before we can make any real comparisons.

with Adrian Holovaty, from Django fame

AkitaOnRails: You also touted the shared-nothing vs share-all dilemma. And you obviously have a strong case because this is not just techno-babble but you do have a successful product running on top of that vision. Do you still think it pays off to sacrifice a little bit of performance for more clean code and productivity? In a way it’s sort of what DHH himself said about Rails when people said it was slower than PHP or Perl. Actually this also has to do with your talk about being a “heretic” in a way that you’re doing things in a different way than we all are now. Can you elaborate on that?

Avi Bryant: “Share nothing” is great advice for making the maximum use of your server resources. For sites like yahoo.com or Facebook, that’s clearly very important because your business depends on serving millions of users every day.

“Share everything” is really hard on your servers, but it makes maximum use of your developer resources. For a startup like Dabble DB, where we have 4 developers, that’s really important. And since our revenue model only requires serving thousands of users every day, not millions, it’s ok to spend a little more per user on server hardware. It’s been a very worthwhile tradeoff for us.

AkitaOnRails: And speaking of DHH, you’ve probably met on several occasions. You’re both opinionated guys with antagonist visions. Smalltalk vs Ruby. Seaside vs Rails. Share-all vs Share-nothing. One could feel tempted to draw you two as Superman vs Batman kind of dispute. Though I know that smart people don’t fight over pesky stuff. What do you think of him and his ideas, how do you think both communities could cooperate if there’s any chance for that?

Avi Bryant: I have a lot of respect for David. The only time I’ve felt antagonistic towards him was this last summer at Foo Camp. We were playing a game of Werewolf, and I was a werewolf and he was a villager. Now, as a werewolf the best thing you can do is get the person nearest you to trust you, and that happened to be DHH. And it worked – Kevin Rose was totally on to me but David managed to persuade him not to lynch me, and I ate them both and won the game. Pn3d!

Anyway. There’s probably a lesson in there somewhere. Also, in a fight between me and DHH, Neal Stephenson would win.

AkitaOnRails: Finally, Brazil still has a young and growing community. Any closing regards for our audience??

Avi Bryant: Olá and good luck! I’ve been told Rio is even more beautiful than my home of Vancouver, and I hope to visit some day.

Don’t miss the TWiT podcast interview with Avi!

Taking clues from the venerable Apple WebObjects he set his way to implement Seaside and his very successful web product, Dabble DB. Check out who the man is, what are his opinions and why he is so relevant to the Ruby and Rails community even though he advocates another language and another framework. Sounds strange, but when Avi speaks, you listen.

He was very kind to provide me a very long interview. It is so long I divided it into 2 parts. This is the first Part. I will release the second one in a few days. Hope you all enjoy it.

AkitaOnRails: Great. I am kind of nervous. Up until now I only interviewed Ruby and Rails advocates including Matz and DHH, this is the first time I am looking for an outside point of view.

And I know you’re very opinionated about Smalltalk and Seaside, but at the same time you have very strong ties to the Ruby community. May I start asking you more about Avi Bryant, the person? Meaning, what’s your history in the programming field?

Avi Bryant: I started programming quite young; it was something I did with my brother and father for fun, mostly writing games in C on the early Mac. As I got closer to college age, my interests turned more to theatre and film, and so when I started university it was essentially as a film major.

But in the long run computer science sucked me in, and I ended up graduating with a CS degree and working in a software engineering lab on campus. That was when I first started programming seriously, and particularly where I got especially interested in software tools.

This was around the time that the very first builds of Mac OS X – when it was essentially still just NeXTStep, without Aqua or Carbon or anything – started to become available, and since I had always programmed for the Mac I set out to learn Objective-C and Cocoa. That was my first exposure to “real” OO, and it was intoxicating.

At the same time, I was doing some web consulting on the side for some extra money, and so I was looking for a language that reminded me of Objective-C but was more dynamic and better suited for the web, and so eventually stumbled across Ruby, which fit the bill nicely.

I was still enamored with all things NeXT and Objective-C, and so when I started to work on web tools for Ruby I took NeXT’s WebObjects framework as my model, and ended up with IOWA, which is very close to being a port of WebObjects to Ruby. I presented that at the first RubyConf, which was, I think, in 2000.

RubyConf was collocated with OOPSLA that year, which I was also attending to give a talk on my research from the software engineering lab. Now, when OOPSLA started out, it was full of Smalltalkers, and even though the mainstream of OO software development – and thus the main focus of OOPSLA – moved on to Java and C#, the Smalltalkers kept coming. But instead of participating in the rest of the conference, they’d just set up a semi-official “Camp Smalltalk” with their own projector and their own schedule and hack and demo Smalltalk stuff all day.

I had of course been aware of Smalltalk, as the source of a lot of the ideas behind things I was interested in – Objective-C and Ruby, obviously, but also TDD, wikis, even the Mac to some extent – but I had never gotten anywhere with actually using it; the environments were too different, the documentation too sparse, etc.

Sitting for a day at Camp Smalltalk was the boost I needed to get past that. And once I got a taste of Smalltalk, I couldn’t let go – I started right away on a port of IOWA to Smalltalk, and convinced my next couple of clients on web projects that I should use Smalltalk instead of Ruby. This port became Seaside, and over the next several years I built up a consulting business around Seaside training and development.

Smalltalk web development may seem like a small niche to build a business around, but the fact is that nobody else was doing it at the time (for that matter, nobody else was doing web development in Ruby at the time either – that situation is a little different now).

Some people to mention in this history – Julian Fitzell was my early partner on the web projects, and we worked together on the first version of Seaside. Colin Putney was one of my early clients, who had come to me based on my work in Ruby and I had to work hard to convince to use Smalltalk; he’s now a confirmed Smalltalker and works with me on Dabble DB. Andrew Catton worked with me at the software engineering lab, and was a frequent collaborator on various other projects over the years.

A few years in, a little fed up with consulting, Andrew and I started to work on a product on the side, and that project became Dabble DB. Last summer, we were lucky enough to get funded to work on that full time, and that’s what I’ve been doing since.

AkitaOnRails: I see that you like the fact that Smalltalk is not “mainstream” in the Java-sense of the word. I can see the advantages and I agree with it. It’s like “we are a small group of very smart people”. Much like Apple’s own “Think Different” campaign. On the other hand the masses tend to like big bang marketing and support. What do you think of this culture clash? The most important part is: here in Brazil the market is very closed off to non-widely-commercially-supported tech. Meaning most of them don’t like anything different than Java or .NET. How do you convince your customers about using Smalltalk – if this is actually a matter there in the US?

Avi Bryant: Yes, that’s a tricky balance. Some of the people I knew in the early days of Ruby’s popularity – post-Pickaxe, but pre-Rails – have complained about how much more popular Ruby has gotten lately, because inevitably the signal-to-noise ratio goes down on the mailing lists and at the conferences. Smalltalk doesn’t have that problem – in particular, Smalltalk has a nice mix of very experienced hackers – people like Dan Ingalls, who has been writing language implementations for more than 30 years, and has just an amazing depth of knowledge to share – and young troublemakers like myself. When you get too popular too quickly, you get a huge influx of young, inexperienced, energetic people, and the voice of experience tends to get drowned out. Not that new ideas aren’t valuable – they’re essential – but I think in this field we tend to overlook history far too much.

As for using non-standard tech, I think the best way to look at it is as a competitive advantage. Paul Graham points out that on average, startups fail, and the same could probably be said about software projects in general. So if you want not to fail, you have to do something different from the average, and using better technology is a great way to do that.

But you clearly have to be in a situation where results matter more than policy – it’s almost impossible to sell an enterprise IT department on a Smalltalk project. On the other hand, a small business owner couldn’t care less what technology you use when building a custom app for him – it’s not like he has an army of Java developers who are going to maintain it.

In general, the closer the alignment between the person who will be using the app, and the person who is writing the checks, the more they’ll care about having something that actually works, and the less about the buzzwords it involves.

That was my strategy when doing Smalltalk consulting, and that’s also our strategy with Dabble DB – we sell to users, not to CIOs.

AkitaOnRails: That’s exactly how I think. Which boils down to you having a startup. I can understand being fed up by consulting work, but what led you to choose to open your own company to sell your own products? I heard that Tim Bray is also an investor for your company? Many people wouldn’t like to lose their comfortable job positions for something as risky as this. What was the reason for this direction in your career?

Avi Bryant: When we were consulting, it became clear to Andrew and me that a) most companies, especially small businesses, couldn’t afford to hire us, and b) even those who could, they could only hire us for the very most important projects. The only way we were going to scale our business, and help as many people as possible, would be to effectively replace ourselves with software: build a product that would let them do the simple projects themselves.

We didn’t abandon everything to go and build this, however – we kept our existing clients (in fact, we took on some new ones to get a little extra capital to hire a web designer, etc), and we worked on the product on evenings and weekends, where we could.

As the product got further along, and it became more and more clear that there might be something worthwhile there, we started to work on it more in earnest, but still keeping some cash coming in with consulting.

Eventually, when the product was ready to launch, we knew we couldn’t handle Dabble DB customers at the same time as our consulting clients, and so we had to drop them entirely. That was when we took some investment from Ventures West and from Tim Bray.

So it was a fairly gradual transition, which made it a lot easier to do.

AkitaOnRails: But even then, were you doing Smalltalk/Seaside consulting only? Or were you working on different languages/frameworks for customers and Smalltalk afterwork? And for non-starters how would you briefly describe Dabble DB? I hear that you’re about to release a companion product for it, right? Can you describe them?

Avi Bryant: During that period, the consulting was all around Seaside, yes – there were some dark times earlier when I had to take some Java work :-)

Dabble DB is a hosted web app for small businesses and teams who need some kind of custom data management – maybe they need custom project management, or a custom contact database, or a custom HR application, or event planning, or just their DVD collection, but for whatever reason the off the shelf software doesn’t do what they need. Dabble lets them interactively build very rich reports on their data, with structured grouping and filtering, simple calculations and subtotals, and display it as a table, or a chart, or a map, or a calendar. You can then share these reports with people, or invite them in to enter or modify the data itself.

The companion product you’re referring to is, I think Dabble Pages. This is really just a new feature set on top of Dabble DB, which all Dabble customers get. What we’ve found is that in any organization there are usually a small number of people who want the full power of the Dabble DB user interface, and want to build new reports or add fields or restructure their data, etc. But there are also a much larger number of people who just want a simple web page where they can enter new data or view a report. So Pages lets that small core group build something for the larger group. It’s sort of like a souped up version of WuFoo or other form builders, but with Dabble DB as the administrative back-end.

It makes Dabble DB almost into a web development tool, in the sense that the administrative users really are building simple applications for the other people in their organizations – but without any whiff of programming, so of course the applications are very limited.

AkitaOnRails: Changing subjects a little bit, one thing that I do admire about you is your relationship with the Ruby/Rails community. Those are different paradigms and technologies, but you never dive in flame wars like ‘Smalltalk is better than Ruby’ just for the sake of it. On the contrary, to me it feels like you do like Ruby, as you presented at RailsConf about the possibility of running Ruby empowered by a modern VM like GemStone’s. But, you did switch from Ruby to Smalltalk. What was it that ‘clicked’ for you about Smalltalk? Continuations? The whole coding-in-runtime? The tighter environment integration?

Avi Bryant: So, first of all, I very much do like Ruby, and Dabble DB includes about 3000 lines of Ruby code (I just checked) along with however much Smalltalk (and a sprinkling of Python).

What clicked about Smalltalk was a few things: one was simply the maturity, both of the community and of the technology. Smalltalk implementations have been refined over the last 25 years, and they’ve really benefited from it.

One of the major benefits, in my opinion, is that Smalltalk VMs are fast enough that it’s reasonable to implement all of the standard libraries – Array, Hash, Thread, and so on – in Smalltalk itself. So there’s no barrier where you switch from your Ruby code to the underlying C implementation; it’s “turtles all the way down”. This may not seem like a big deal but once you have it, it’s really hard to give it up.

Rubinius, of course, is moving in this direction for Ruby, and mad props to Evan and everyone else working on that project. For me, the Smalltalk environment is also key.

In some ways it’s the same things I talk about with Dabble DB: you don’t have to choose one way to organize your data, you can have one view that’s grouped by date and another filtered by customer and another where a map is the only way to understand. In Smalltalk, you don’t have to choose one file layout or order of methods and classes in your code; you’re constantly switching views on what’s basically a database of code.

My friend Brian Marick hates this, because you lose any “narrative” that might have existed by putting the code in a certain order in the file, and it’s hard to get used to, but for me, it’s the ultimate power tool for hacking on a large code-base.

That’s it for Part 1. Stay tuned for more Avi, talking about Smalltalk and Ruby on Part 2 of this interview, to be released in a few days.

It’s been a while since my last international interview, and I am back with none other than one of the people responsible for bringing Ruby to the .NET platform. That’s correct, I’ve been covering a lot about JRuby and Rubinius but we can’t neglect that one of the biggest platforms out there in the market is receiving the Ruby treatment as well. So I invited John Lam , who kindly answered several questions regarding this endeavor.

Remembering that IronRuby – named after IronPython, the first of the main open source dynamic languages built on top of .NET – is a true open source project, and also has a 3rd party addon for Visual Studio.NET, so programmers used to the VS.NET workflow can get onboard with a lower learning curve ahead of them.

Despite opinions against Microsoft just for the sake of arguing, the fact remains that Java and .NET represent the biggest corporate development market today. And this is also a fact that the Ruby meme is spreading in a very fast way. Being built to run on top of both the JVM and the CLR represents Ruby being enabled for market niches that it wouldn’t reach otherwise, and this is a huge win. I talked a little bit about this in my article (in portuguese): For myself to win, the other one has to lose. There are very intelligent people at Microsoft, John Lam being one of them.

That said, let’s get started:

AkitaOnRails: First of all, I always ask my guests about their careers: what was your path up until now? Meaning, how did you get yourself involved in computing, what drives you into it?

John Lam: I wrote a lot of software before I graduated from High School in 1986. I shipped a bunch of commercial software for the Commodore ‘platform’ (aka PET, VIC-20, C-64/128) back in the day. In 1986 I decided that there was no future in computing (which shows why folks shouldn’t take my opinions seriously :)) and decided to study the physical sciences in University. I graduated in 1995 with my doctorate in Organic Chemistry and decided that there was no future in chemistry (which, if you look at how the reverse engineering of life today is based a lot on cross-discipline interaction with other branches of life sciences, shows why folks shouldn’t take my opinions seriously :)).

Once I decided to work in computing again, I took up an obscure new development platform called Delphi which shipped in 1.0 form around the time that I re-entered the field. I spent a bunch of time working on integrating Delphi with COM, which is where I originally hung my hat. The dark side of COM pulled me into its orbit and I’ve been working on Microsoft related stuff since then.

AkitaOnRails: I see that you’re at Microsoft since January 2007, is that correct? How did you get in there, were you hired with the IronRuby project in mind? Is this your main assignment today?

John Lam: Yes, I started in January. Before joining the company, I worked on an open source bridge between Ruby and the CLR called RubyCLR. When I decided to start promoting that work at conferences, I crossed paths with the DLR team at Microsoft. Mahesh Prakriya graciously donated half of his talk at Tech Ed in 2006 so that I could talk about RubyCLR. After much hand-wringing/mind-conditioning I wound up accepting their offer to work full time on a Ruby implementation on top of the DLR and we (my wife, two kids and dog) arrived in Redmond in January.

AkitaOnRails: What were the motivations behind starting IronRuby? How did it start? Were you the original and sole developer of a .NET
implementation of Ruby?

John Lam: We want to demonstrate that the DLR is truly a multi-language dynamic language runtime, so we had to build a number of languages on top of it. Ruby certainly fit the criteria: dynamic, strong user community, lots of attention, so it made sense to implement it. IronRuby has definitely forced a lot of design changes to the DLR, making it less ‘Pythonic’ which is a good thing for other folks who are interested in building a dynamic language on top of our platform.

I’m definitely not the sole developer on IronRuby. We have two great devs working on the project: Tomas Matousek and John Messerly and they’re doing awesome work. Our tester, Haibo Luo, is doing great work to make sure that we ship a high quality implementation. Haibo’s work will be released along with IronRuby, which means that the community can also benefit from his test suite.

AkitaOnRails: Not many people here are familiar with the DLR and Silverlight, can you briefly describe them for non-starters? What makes a ‘DLR’ different from a ‘CLR’ besides jumping from “C” to “D”? :-)

John Lam: The DLR is a platform that layers on top of the CLR. This means that we can run anywhere that the CLR can run, which of course includes Silverlight. Silverlight is our cross-platform browser-based platform that runs on Windows, Mac and Linux (via the Moonlight project). We ship a cross-platform version of the CLR which means that you’ll be able to run DLR-based languages with just a 5MB initial download into your web browser.

AkitaOnRails: This is delicate: I once read Ola Bini and Charles Nutter criticizing the “Microsoft Way”, meaning that it would be extremely hard – if not impossible – for you to write a 100% complete Ruby 1.8 implementation on top of .NET without being able to peek into the source code. The reason being the company policy toward open source licenses. Was that the case?

John Lam: I think that IronPython is the existence proof that you can build a compatible implementation of a dynamic language without looking at the original source code. In our work with IronRuby, I can tell you that not being able to look at the source code hasn’t prevented us from figuring out how Ruby accomplishes some feature – it’s all about designing the right experiments.

AkitaOnRails: I also saw that IronRuby is going to be released under open source-compatible license from Microsoft, making it probably the first true open source project ever from Microsoft, meaning that you would not only allow people to take a look at the source code but also to contribute back to it. How far is this?

John Lam: The Microsoft Public License was officially sanctioned by the OSI in early October. IronRuby, IronPython and the DLR are all released under this license.

We’ve already accepted contributions back in from the community, and are continuing to accept more contributions from the community.

We’re actually not the first Open Source project at Microsoft that accepts contributions back from the community. That honor belongs to the ASP.NET AJAX control toolkit which is an enormously successful project with > 1M downloads to date.

AkitaOnRails: The DLR was originally conceived as an experimental way to run Python on top of .NET. Did this make it easier for a Ruby implementation or do you feel that Python and Ruby were different enough to guarantee lots of tweaks into the DLR to make it feasible?

John Lam: It’s fair to call the original version of the DLR the “Python Language Runtime”. Adding Ruby to the mix forced a lot of additional changes to the DLR, the most significant being the refactoring of the runtime to migrate all of the Python specific idioms (which were thought to be general but turned out not to be the case) into IronPython.dll. What remains is a core which our the 4 languages developed by MSFT (IronRuby, IronPython, Managed JScript and VB) continue to use effectively today.

AkitaOnRails: Is it a goal to be 100% compatible with MRI 1.8? Or are you going toward a sub-set of the Ruby implementation? This would make it possible to write .NET programs in Ruby, using the full set of .NET libraries and frameworks as ASP.NET, Windows.Form, LINQ, etc. Or are you planning on a full blown MRI compatible implementation, enough to be able to run an entire Rails application?

John Lam: Our #1 priority is being as compatible as possible with MRI 1.8.×. The one feature that we will not support is continuations, which is consistent with JRuby. Other than that (and in the absence of a Ruby spec), compatibility will be judged by whether we can run real Ruby applications and community developed Ruby test suites. Obviously Rails is an extremely important Ruby application, which we will absolutely run on top of IronRuby.

.NET interop is our #2 priority. We will integrate with the .NET platform, and allow you to write Ruby applications using the rich set of .NET libraries. Obviously things like Silverlight, WPF, LINQ, WinForms, and ASP.NET will be supported.

AkitaOnRails: Ruby grew as a collective and low profile effort that really exploded 3 years ago because of Rails. That’s one reason no one ever bothered to write a formal specification and test suite. You have Alioth, you have the current YARV test suite. Did you have a hard time because of this lack of formal specs? Are you in contact with people like Charles from JRuby, Koichi Sasada from YARV or Evan Phoenix from Rubinius? What do you think of all these efforts going on in parallel? Is there any way you can contribute with one another?

John Lam: We’re using the Rubinius spec suite today, and plan on shipping it along with our sources to ensure that we catch compat bugs early in the process. I’m guilty of not participating as much as I would like to in talking more with Charlie, Evan and Koichi about collaborating on specs. We’re focused on getting the core language up and running today, and, like a lot of other fast-moving projects, have been neglecting to document the things we have learned. Once the pace of the project slows down a bit, I’ll be able to spend more time engaging with the other implementers.

AkitaOnRails: Ruby has a lot of known deficiencies. Koichi is trying to improve on some of them for Ruby 1.9. How are you tackling problems like lack of native threading, simple mark and sweep garbage collector, no virtual machine and thus no byte-code compilation, performance issues, lack of native internationalization (Unicode), lots of C-based extensions.

John Lam: We get a lot of things for ‘free’ by running on top of the CLR. Native threading is supported in IronRuby. We use the CLR garbage collector, which is a world-class GC. We compile natively to IL, and our IL can be GC’d as well which is goodness for long-running server based applications. We will obviously support CLR strings, which are Unicode strings and we will also support Ruby mutable strings which are based on byte arrays. We will not support C-based extensions at all, instead we will be porting the existing C-based libraries in the Ruby Standard Library to C# (or Ruby).

AkitaOnRails: Are there any benchmarks comparing IronRuby with the MRI? Do you think you’re already outperforming it? Are there any issues today around Ruby performance over the DLR? Or more interestingly: is there any comparison between Ruby on DLR and C# or VB.NET over the CLR?

John Lam: We are faster than MRI in the YARV benchmarks, but that number changes daily. One great thing about our team is that we have a performance regression test suite that we regularly run across all of our code. This makes it trivial to pinpoint a build that causes a regression in performance, even if we postpone that work for a while.

We have done zero performance tuning so far; we’re just using features that exist in the DLR today, like polymorphic inline caches for efficient call-site method caching. As our implementation matures, we will tune IronRuby to perform well on application-level benchmarks (not just microbenchmarks which are useful to us but not so interesting to real customers). The DLR (and CLR) is becoming faster all the time, and any dynamic language that is built on top of the DLR will benefit from these improvements.

Obviously, languages like C# and VB.NET are faster than Ruby today. But we are confident that we can significantly narrow that gap over time.

AkitaOnRails: What about tooling? I saw you tweaked your Visual Studio.NET to have the Vibrant Ink that we – TextMate users – are used to, and it looks nice. I even saw a screenshot of code folding of Ruby inside of Visual Studio. How is its support for Ruby?

John Lam: Right now our team isn’t involved in VS integration. However, the good folks at Sapphire in Steel are doing great work at integrating IronRuby into VS.

AkitaOnRails: You mentioned in an interview the possibility of Ruby running on top of Silverlight. How feasible is this today?

John Lam: We demonstrated IronRuby running on top of Silverlight at RubyConf. The talk should be posted soon. We’re planning on rendezvousing with Silverlight in time for their next CTP (late this year / early next year). At that time, you will be able to code in Ruby that runs in your browser.

AkitaOnRails: Microsoft is learning on how to deal with the open source community. Do you think the adoption of technologies as Python and Ruby are helping the company to understand the open source way? What do you think still has to improve? Meaning, if you could, what would you change?

John Lam: Microsoft is a big company and we’re working very hard on working together with the Open Source community. IronRuby is one of the most visible Open Source projects in the company, and we’re helping to pave the way for other teams that want to engage with the Open Source community. Change happens incrementally at big companies and it’s been fun being a part of that change!

AkitaOnRails: Silverlight was released over an open source license as well, so that the Mono guys were able to run it very quickly over Mono. Are you close to Miguel De Icaza? What do you think about Mono? An IronRuby running on top of it means a multi-platform Ruby that can run over Linux. If you ever get 100% compatibility with MRI and Rails, this means running over Apache+mod_mono on Linux and over IIS on Windows, everything developed under Orcas. Are there any plans for this kind of integration and end-to-end solution?

John Lam: Actually, Silverlight is not released under an Open Source license. The DLR, IronPython and IronRuby are all released under the Microsoft Public License, which makes it possible for Miguel and his band of merry men to just ship it on top of their Moonlight implementation.

I love how pragmatic Miguel is. We showed IronRuby running on top of Mono at RubyConf and that was largely due to the Mono team fixing a bunch of bugs at the last minute so that we could demo (thanks!). DLR + Iron* tends to push the C# and the CLR pretty hard. We’ve uncovered bugs in the Microsoft C# compiler, and we’ve uncovered bugs in gmcs under Mono as well. But thankfully, both the C# team and the Mono team have been great at fixing those bugs to unblock us.

AkitaOnRails: I think, that’s it for today. Any closing remarks for the Brazilian audience?

John Lam: Thanks for sending along a great set of questions! Good luck with your Ruby adventures and I hope you’ll have a chance to check out IronRuby in the future.

This is another big interview. This time with Jamis Buck, the programmer that helped David Hansson himself right at the beginning of Rails, at 37signals.

Today most renowned for his achievements in Capistrano and a lot of other Ruby libraries as sqlite-ruby bindings and Net::SSH. Jamis was very kind to give us the opportunity to know more about his career and the beginnings of the Ruby on Rails story.

AkitaOnRails: Ok, so let’s get started. first thing I always ask my guests: what’s your background? I mean, when, how, why did you start on computer programming? Did it begin the classic way, as a hobby, or was it a more recent thing because of career or something else?

Jamis Buck: I started programming when I was in the 10th grade, when my mom got a brand-spanking-new Tandy personal computer. It had all of 20 megs of disk space, and came with GW-BASIC. I’d done some programming before, turtle-graphics and a bit of BASIC, but that Tandy was when I got serious about it. I taught myself GW-BASIC from the little reference book the computer came with and wrote a few simple games and utilities. Then I taught myself Turbo Pascal and Turbo C++ in 11th and 12th grades, and it’s gone from there :)

AkitaOnRails: Then you decided to go for CS in college? I read at your profile in WorkingWithRails that you’re a repentant Java programmer? How long have you been programming in Java?

Jamis Buck: Yeah, I then jumped into Computer Science when I got to college. I graduated a bit late, in 1999, after working full-time for the university (BYU) as a programmer for a couple of years. That was where I did all my Java work. We were actually doing web-apps in C, which was not as insane as it sounds! But then we had a change of leadership when a new CIO came in, and he basically issued a blind mandate: “learn Java, ditch C!” So we had to massively retool and get certified and so forth. I was on the team that led the research into what Java tools we should use, and so got a lot of experience that way. I did Java work full-time there for about 2 years, until 37signals came along in Feb 2005 and made me a better offer, and I’ve never looked back!

AkitaOnRails: Wow, so you jumped right in from Java in the university to Rails at 37signals? This is a little earlier than I expected, but as you already mentioned it: how did you get in touch with the 37signals guys? How did you start on Ruby being so overwhelmed with Java before?

Jamis Buck: Well, I’d been involved with Ruby (primarily as a hobby) since about 2001. I’d written a few libraries, like the sqlite and sqlite3 bindings, and at RailsConf 2004, I met DHH. I did a bit of work at the conference there to make Rails speak to sqlite databases. After that, around November 2004, I think, David asked if I would be interested in doing some consulting for 37signals. In December and January I did a few odd jobs for them like adding SFTP and time zone support to Basecamp. And then in February they flew me to Seattle to attend the Building of Basecamp workshop there and they made me an offer.

AkitaOnRails: I understand that 37signals is a small company in terms of number of employees and most of its inner power comes from this very fact. Did it change much since you began, I mean, in the last 2 ~ 3 years? What did you like the most back then and what do you like the most right now?

Jamis Buck: Well, when I came on, I was the 5th employee, and the second programmer. Previous to my coming, David did all the programming and sysadmin work, so I think it was a big relief to him to have someone to share the load! About a year later, we hired two more programmers, and we’ve since hired two more people, including a full-time sysadmin. The changes have been for the better :) I like having a real sysadmin. I can’t tell you how much I hated being a sysadmin, since I had little idea what I was doing!

AkitaOnRails: You seem to be the kind of guy that like the kitchen-sink because you’ve been involved with ‘low-level’ stuff like sqlite-bindings, Net::SSH and so on. Is this the kind of thing that excites you the most? Or it’s just a coincidence and you actually rather do GUI work as well?

Jamis Buck: I actually swore, some years ago, that I would never be a web-app developer :) I’ve always preferred writing the tools as opposed to writing the apps. But I’ve really enjoyed writing web-apps at 37signals. The team is great and the toolset (Rails!) is amazing. I still do enjoy writing libraries (working on Net::SSH and Net::SFTP v2 right now, in fact) but apps aren’t so bad either :)

AkitaOnRails: But back then when you were literally second-in-command you didn’t have much choice, did you? I bet you did some of the Basecamp interfaces? And you mentioned that you didn’t like much of the sysadmin work because you didn’t know what you were doing, but now you probably are an expert because Capistrano rocks in this field. I remember it being called SwitchTower before. Can you tell us its story?

Jamis Buck: I’ve done quite a bit of the work on all of the apps, some more than others. I don’t actually write the UI’s (that’s the domain of Jason Fried and Ryan Singer), but I’ve plugged them in and made them work.

I learned a ton about sysadmin work from when I had to do it. I’m still a major newbie at it but I learned more than I ever thought I’d learn about how mysql really works, for instance :)

When I first released Capistrano, a year and a half ago or so, it was called SwitchTower, but around March 2006 I got a C&D from a company that had the name trademarked, and so I had to scramble for a new name. The Rails Core Team helped immensely at that time, they offered a TON of suggestions for names. Marcel eventually IM’d me and suggested “Capistrano” which just clicked for me and I went with it. I got some flack from some people, who thought the name was lousy, but I laugh now because most people that use cap today probably came to it after the name change and never knew any other name, and they don’t even think twice about it.

AkitaOnRails: You are probably very overwhelmed now because of the Capistrano 2.0 release. It is a major departure from the 1.4.1 if I understand correctly. You rewrote a lot of stuff, had to break backward compatibility. Do you feel you got what you wanted with this release or are you aiming for more in a 3.0 release?

Jamis Buck: Cap2 is pretty much just what I wanted it to be. There are few minor tweaks in the pipeline, but nothing significant. It is about 90% backwards compatible with Cap1, so most people should have no problems switching. And since the 2.0 release, the maintenance load for cap has been really small. I’m very pleased with it. I still need to get busy with documentation though :) That’s the thing that still holds a lot of people back.

AkitaOnRails: What is it that you like the most about cap? You obviously use it at your own deployments at 37signals. I fantasize you having a bunch of shell scripts more than a year ago and then weaving them together to build what was the first release of Capistrano.

Jamis Buck: Prior to SwitchTower/Capistrano, we had a tool that David had written for deploying Basecamp. Back then, Basecamp ran on a single server, so deployment was little more than “svn up”. Later, we moved Basecamp to multiple servers and launched Backpack, and we realized we needed something more powerful for deployments. So I was tasked with writing something and Capistrano was the result. The thing I like most about it is how it takes the tedium out of being a sysadmin. The “cap shell”, in particular, lets you immediately and easily execute arbitrary commands on multiple servers, simultaneously, which is really handy. Of course, “cap deploy” is nice too :)

AkitaOnRails: I remember one episode where David reported about a 72 hours glitch that let Basecamp out. Were you involved in that episode? :-) Headaches like this seems funny when you remember about them now, but obviously not so funny at the time.

Jamis Buck: ha, yeah, that actually happened a few days after I was hired :) We were adding UTF-8 support to Basecamp and the database migration did not go well. We pulled an all-nighter. Quite the introduction to 37signals’ culture :) Fortunately, that kind of thing hasn’t happened since, though we’ve had our share of other emergencies, of course.

AkitaOnRails: Lessons learned? I think that’s the most important outcome of these situations :-)

Jamis Buck: The main lesson I learned that time: when you’re mucking with charsets, make sure you test it on as many non-Latin1 alphabets as possible :) Naturally, we tested it a lot before we deployed, but we didn’t really think to check any Russian or Japanese data that was in our database after the test, which seems obvious in hindsight. We did try some non-Latin1 alphabets during testing but the ones we tried just happened to work in spite of the bugs. Another lesson learned: no matter how hard you prepare, something’s going to fall through the cracks!

AkitaOnRails: I headed a group of very committed volunteers and got your Getting Real book translated into Brazilian Portuguese a while back. I believe you were involved in it too? This book is iconic to picture the 37signals spirit I guess. Do you really move the way it’s written? :-)

Jamis Buck: I was actually not too involved in the composition of the book, though I gave some feedback during the writing process. But yes, that book describes our own processes. There really isn’t anything in that book that we don’t actually do.

AkitaOnRails: How do you operate? I believe that not everybody work in the same physical location? Do you do a lot of remote work? How many programmers/sysadmins/designers are there now?

Jamis Buck: Chicago is definitely the “heart” of 37signals: Jason, Ryan, David, and Sam all live and work there. We have an office there as well, and the Chicagoites go there pretty regularly to work (though they also work from home some, too) Matt Linderman is our writer, he lives and works in NYC. Mark Imbriaco, our sysadmin, lives and works in Chesapeake, Virginia and Jeremy Kemper is another programmer, living in Pasadena, California now. The distributed nature of it works very well for us. I really love working from home, it lets me be more involved in my kids’ lives, for instance, than I would otherwise be.

AkitaOnRails: I hear you’re from Provo, Utah? It is a coincidence as my current boss, Carl Youngblood, is also from there and also studied at BYU :-) You don’t possibly know each other, do you?

Jamis Buck: I actually live in Caldwell, Idaho now, but I was in Provo for about 8 years and yes, I do know Carl! We were both in the Utah Ruby Users Group. He’s a great guy.

AkitaOnRails: You attended many conference for the Ruby community. I don’t remember if you wrote any books. Are you writing some now?

Jamis Buck: I was originally going to write a book about Capistrano for Apress, but that’s fizzled. I’m not actively involved in any book writing at the moment, and don’t really have much interest in it, honestly. I much prefer writing software! And I try to post to my blog once in awhile, too.

AkitaOnRails: Yes, the buckblog, it has lots of great tips that I like to read. Did you start it because of Rails or you already had a Java blog back then?

Jamis Buck: I started it pre-Rails. If you read the early articles, you’ll see they were pretty eclectic. I was still trying to figure out this whole “blog” thing :) I’ve since come to focus on software-development and use my family blog for more personal posts these days.

AkitaOnRails: I was a Java programmer myself and I still try to maintain myself informed about what’s going on in other communities as Java, some PHP, Python. What do you think or feel about other frameworks and technologies as CakePHP, Avi Bryant’s Seaside or even Django?

Jamis Buck: Honestly, I’m a bit ashamed to admit that I don’t keep up on other frameworks as much as I should. Seaside has some neat ideas and my desire to improve my Smalltalk programming skills has made me want to poke into that further. But other than that, I haven’t shopped around much (to my own personal detriment, I’m sure).

AkitaOnRails: And still about Java, I am very excited nowadays about JRuby. I interviewed Ola Bini and I’m also kind of stalking Charles Nutter. Did you know the guys? Did you got interested in trying it?

Jamis Buck: I know who they are, and I’ve met Charles at a few conferences, but I’ve never really had a chance to talk to them in depth. JRuby definitely sounds exciting. I’m very curious, in fact, to know whether it can support Net::SSH or not since that would mean you could run Capistrano under it. But I’ve not had a chance to actually try it out.

AkitaOnRails: Insisting on the Java subject, I posted a while back about some discussions about Design Patterns pointing to flaws in languages, and I just read a post you wrote about Dependency Injection and your Net::SSH library. What do you think about Design Patterns now that you’re a full-time Ruby programmer?

Jamis Buck: Design Patterns are wonderful. They give us a language to talk more concisely about programming. It is so much easier to say “use a factory method” than to circumlocate and confuse each other. As for specific design patterns, some are more useful than others in different environments. As I wrote in my post, Dependency Injection is just not something you need in Ruby, but in environments like Java, it can be a life-saver.

AkitaOnRails: About 37signals again, you are very committed to Apple products. I saw that video on Apple Education with Jason and David. And now we see that Leopard will bring not only Ruby but also Rails, Mongrel and even Capistrano. How is your relationship with Apple?

Jamis Buck: I wouldn’t say there is any “relationship” with Apple. We’re big fans of their designs and interfaces and I think that reflects in our own work. Apple itself is including Rails, Mongrel, and Capistrano in the wake of those tools’ successes. Mac OS X really is a powerful environment for programmers and adding those tools “out of the box” makes it even more so. It makes sense to include the popular Ruby tools, too, since Ruby is going to be a first class citizen when it comes to developing OS X applications, thanks to the adoption by Apple of the Cocoa bindings for Ruby.

AkitaOnRails: You obviously use a Mac for your work. What are the tools you use the most besides Textmate?

Jamis Buck: Well, Capistrano :) Firefox w/ Firebug, Parallels (for IE testing), iTerm (though I’m looking forward to the new Terminal.app in Leopard), Campfire is indispensable, AdiumX, NetNewsWire, Knox (for simpler encrypted filesystem access). I still fall back and use vim pretty often too, for quick edits. There are probably others :) But I can’t think of them off the top of my head.

AkitaOnRails: There are a lot of talk about GTD nowadays. I think I saw your profile at 43folders. Are you into this kind of organization philosophy as well? How do you maintain your routine organized? Many people (myself included) have a hard time differentiating work from hobby and keeping ourselves within the project’s deadlines and such.

Jamis Buck: I’m not a GTD fanatic. I guess I try to be pretty pragmatic about it. I’m terrible about procrastinating, though. Mostly, from 8-5 I try to focus on the tasks that have been assigned to me and outside of that, I work on my hobbies… which happen to overlap work sometimes :) I’m really the wrong person to ask about being organized! If it weren’t for my wife, I think I’d get very little done, actually.

AkitaOnRails: What are you most interested nowadays besides Rails, Capistrano? Not only technology-wise. Any hobbies?

Jamis Buck: I’ve lately become very interested in military history, which has lead me to read about the American Civil War among other things. My wife and I are really enjoying Harry Potter #7 right now, too :) And I’ve become quite attached to my Nintendo Wii lately, as well! I used to be quite into role playing games, but haven’t done that for a few years. I’ve still got a ton of books for D&D, though, and maybe someday I’ll dust them off :) I enjoy spending time with my kids (Nathaniel is 5, and Katie is 3). We’ll be going camping for a few days in a week or two, actually. Always something to keep me busy!

AkitaOnRails: Haha, I see. And do you travel a lot? Outside of the US, I mean.

Jamis Buck: Not really. Last year I went to London for the first time, for RailsConf there, and this year I went to the Czech Republic. But aside from that, I’m really a homebody. I’d kind of like to do more traveling, but I don’t like to travel alone and having kids puts a damper on the spontaneous “get up and go” aspect of travel. We do occasional road trips and stuff, though, which is fun.

AkitaOnRails: Do you hear what’s going on the Ruby/Rails communities around the world? What do you feel about the meteoric rise of Rails in the US? 37signals, of course, was the fuel for all this and the reason we – both Rubyists now – are talking today.

Jamis Buck: I hear some news, but I’ve trimmed my newsfeed quite a bit. I think I only subscribe to 30 or 40 feeds these days. It was really exciting to go to the Czech Republic and see the excitement there about Rails. It reminded me a lot of how things were in the US a couple of years ago.

The rise of Rails has been incredible. There have been growing pains, of course. With wider adoption you begin to accumulate people who aren’t passionate about the tool, and only want to learn it for the resumé, or because a client has asked for it, and I think that dilutes the waters quite a bit. But there will always be a core of passionate users and that’s what makes the community so wonderful. It’s been a really amazing experience to have been a part of that core, almost since the beginning of Rails.

AkitaOnRails: You have the rare opportunity of seeing all this from a VIP perspective near Jason and David. And of course, yourself, being one the propellers of the community. Many people think of David as an arrogant :-) I can perfectly understand his opinionated point of view. What do you think of it, from the perspective of someone who actually know the man?

Jamis Buck: David is one of the most confident people I have ever met. My biggest frustration with him is that he’s RIGHT so often. He’s a very clear thinker and jumps right to the core of the issue, which can be very disconcerting if you aren’t used to that. All those attributes combine, I think, to make people who don’t know him consider him “arrogant”. But he’s not arrogant. He doesn’t put people down in order to raise himself up. He’s just extremely gifted, very smart, and doesn’t beat around the bush. I’m very honored to be able to know him. I’ve learned a lot from both him and Jason.

AkitaOnRails: I don’t know if I got it correctly but Jason Fried was the one that started 37signals? Can you give us a small glimpse on the origins of the company? I know that David is not from the US, how did they get to meet each other?

Jamis Buck: Jason co-founded 37signals, in the late 90’s. It was originally a design consultancy. In 2003, Jason started to work on a project in PHP, and asked around online whenever he got stuck. David responded to his queries several times and Jason finally just asked David if he would write the project. David came on part-time for awhile, then, since he was still finishing school. But eventually, Jason wanted to write Basecamp, and David did all the work on that, part-time, in Ruby. His experiences with that, of course, led to Rails. And eventually David become a partner in the company. That was in 2004, if I remember correctly.

AkitaOnRails: Great. And coming back about you. Now that Capistrano 2.0 is finally released, are you involved in some new open source tool?

Jamis Buck: With Cap2 out the door, I’m really focused on rewriting Net::SSH and Net::SFTP. Some frustrations with their limitations in writing cap2 has made this necessary :) The only “new” thing to come of this is Net::SCP, which is an implementation of an SCP client in Ruby and which I will release when I release v2 of Net::SSH and Net::SFTP.

AkitaOnRails: Oh, and speaking of which, I remember that the former Cap 1.4.1 didn’t play very well on Windows boxes. Is that correct? Any advances in this field or do you feel that supporting Windows is just too much?

Jamis Buck: Well, as far as I know, cap 1.4.1 worked fine on Windows machines. The limitation was that you can not deploy TO Windows. Deploying FROM Windows works fine. And as for making cap deploy TO Windows, I have no plans. The difficulty is that Windows is not a POSIX environment, which is one of the fundamental assumptions of Capistrano, regarding the target machines.

AkitaOnRails: Ah, yes. I never tried that, therefore my confusion. You’re right. Well, I think I already got a lot from you. Anything that you would want to say to the Brazilian community? :-)

Jamis Buck: “Stay passionate” :) Keep the passion for Rails burning, it’s what makes the community worth belonging to.

AkitaOnRails: Couldn’t be better. Any plans for coming here?

Jamis Buck: Ha, none in the immediate future :) I’ve got a baby coming in September, which puts a damper on travel plans :) I’d love to visit Brazil someday, though.

AkitaOnRails: Didn’t know that. Congratulations!

Jamis Buck: Thanks.

AkitaOnRails: Well, thanks a lot for your time. It was a very insightful conversation. I know people will enjoy this.

Jamis Buck: Thank you very much, Fabio. I’m grateful for the opportunity!

This will be a fun interview. My guest this time is my boss. He’s not only an employee of Surgeworks but an active Ruby contributor and participates mainly in the Utah Rails User Groups (URUG). Many of his values and ideas resemble my own.

Carl Youngblood has worked professionally as a software engineer for over ten years, and is currently the Rails Practice Manager for Surgeworks, a software engineering consulting firm (where I happen to be as well :-). In addition to his work at Surgeworks, Carl is an owner of Confreaks, a company that records conferences, seminars and workshops, and is a director of the Mormon Transhumanist Association. He received a bachelors degree in Portuguese from Brigham Young University and a masters degree in Computer Science from the University of Washington.

AkitaOnRails: So, let’s get started. This is very strange to interview someone you already know. But let me try. Before talking about Ruby. The first thing most of my readers get intrigued is about your Portuguese skills. Can you tell them what led you to it?

Carl Youngblood: Yes. My first introduction to Portuguese was as a Mormon missionary in Brazil. I arrived in Sao Paulo having only received a two-month crash course in Portuguese. When I got there, it seemed like I had to learn everything over again – this wasn’t the language they taught me! :-) But after spending two years in Brazil in a context in which it was imperative to converse with other people, I learned Portuguese well. However, I would say that my skills were primarily in conversational Portuguese. Later on I discovered Portuguese literature and developed my written skills further.

Upon returning to the States, I decided to do a double-major in Portuguese and Computer Science. I decided on Portuguese because I enjoyed the language so much, and felt like I had a real talent for it. I chose CS because I have been in love with computers ever since I was 12 and got my first Commodore 64. Or maybe it was 10 years old. I can’t exactly remember.

AkitaOnRails: Where did you stay during these 2 years here in Brazil? What were your responsibilities here?

Carl Youngblood: I spent time in Monte Mor (a small town just outside of Campinas), Campinas, Marilia, Umuarama, Maringa and Campo Grande.

AkitaOnRails: But did you do anything computer related here during this period? People here would be interested to know what do you think of our country, being an outsider that really spent a serious amount of time around us. What’re your personal impressions about the country, the people, the culture, our local habits? Maybe a few words about the good and the bad :-)

Carl Youngblood: My first 4 months were spent mostly meeting people in the streets and in their homes and trying to teach them about our church’s doctrines. Just to clarify, Mormon is a nick-name given to my church because they believe in a book of scripture called The Book of Mormon, along with the Bible. But the full name of the church is The Church of Jesus Christ of Latter-day Saints. Anyway, I spent the first four months teaching people and helping to conduct church meetings, and walking A LOT – we walked about 15 miles a day, and I frequently remember waking up in the middle of the night with pains in my legs :-) After the first four months, I was called to work in the mission office in Campinas as Historiador da Missão – a secretary of sorts. Here my computer skills came into play.

After spending four months in Campinas as mission historian, I was called to help open up a new mission in Marilia, and spent another four months working in that mission office on the computer.

I didn’t really develop any amazing software for the mission, although I did help design an Access database that promptly fell into disuse after my departure :-)

Overall I really enjoyed my time in Brazil. I discovered how much I enjoyed learning another language, and this newfound fascination led me to study this language later at the university level. The Brazilian people I met were for the most part very friendly. It was not uncommon to be invited into peoples’ homes and offered food before we even knew them, and they were usually willing to give you the shirt off their backs. I also really like Brazilian music, especially Brazilian Popular Music (MPB). Tom Jobim is my hero, along with other legends like João Gilberto, Luiz Bonfá, Vinícius de Moraes, and other more modern artists like Caetano Veloso, Gilberto Gil and Djavan. It was wonderful to discover a whole world of music and literature that opened up to me when I learned Portuguese. The food was good too, although I missed a few items from home, like corn chips and peanut butter, strange as it sounds.

On the other hand, I frequently noticed a profound lack of ambition. Most Brazilians we met were content to have a roof over their heads, food in the fridge and a TV. Of course, my observations are bound to be skewed a little by the fact that I mostly interacted with the poorer class of people who did not live in closed highrise apartment complexes, which were difficult for us to make house calls in, unless we had a prior appointment. One of Brazil’s most difficult problems is the large disparity between rich and poor and the consequently small middle-class. When Brazil abolished slavery (one of the last countries to do so), little or no effort was made to assist emancipated slaves in transitioning towards gainful employment in the new economic system, which led to the development of many autonomous shanty towns that were nearly completely isolated from the more “respectable” centers of commerce. This isolation continues today. It is not uncommon to see a wealthy suburb right next to a sprawling slum, as if each were ignoring the existence of the other. Overall though, Brazil is really making headway and the standard of living is improving dramatically.

One event that I distinctly remember was the advent of public internet access and the WWW in 1995 while I was in Maringa, I believe. I had often commented to my brother back in the days of text-based bulletin-board systems that it would be cool to create a markup language that allowed computers to render graphics over a modem connection. When I saw the WWW in 1995, I said, “Somebody stole my idea!” :-)

AkitaOnRails: Haha, so you were involved in online activities since before the advent of the Web per se? And, you went to college after this 2 year period here?

Carl Youngblood: I was involved in modem-based BBSes in our local town of Provo, UT since about 1990 or so. My brother ran a BBS called London after Midnight. He was sort of into the goth/cyberpunk scene (or at least wanted to be :-) ). We mostly used them to pirate games, before I grew up and realized that other people were trying to earn a living off this stuff.

I had already done one year of college as a music major (Clarinet performance) before I went on a mission. After the mission I returned to college and changed majors.

By the way, we were also connected to a worldwide network called Fidonet, where we participated in newsgroups and had delayed discussions. Every night our computer dialed up a system in Nevada to download the new messages.

AkitaOnRails: Oh, that’s cool. Going back to this subject, I was into BBSes as well because of my neighbor. He hosted a hacking BBS called Medusa and we played a lot brute-forcing against passwd files, using Blue boxes and so on. (Damn, we’re confessing a lot of crimes here, hope we’re not going to litigation for that ;-)) Getting back on track. So were you also caught in the period of the Internet Bubble? Doing PHP websites and so on?

Carl Youngblood: Haha, good point. Those BBS days were fun. We felt like we were on the cutting edge. Yes, I was involved in the Internet bubble. Omniture (called MyComputer.com at the time) was in the middle of an acquisition by NetObjects. However, before the acquisition took place NetObjects’ share price had plummeted to the point where they were valued at half of the acquisition cost, which basically meant it wasn’t going to happen. MyComputer.com laid off a bunch of people, but I left a couple months before that happened. My boss, speaking after the fact, told me that I would have been able to keep my job (I was one of the first employees), but I saw signs of trouble and had another opportunity, so I took a job at Legato Systems developing mirroring drivers in Windows of all things :-)

AkitaOnRails: Same thing for me here in Brazil. I was involved with a dotcom company that went bankrupt but I was able to get out a few months earlier. Anyway, so you went straight to low-level programming. How many programming skills do you have? From low-level assembler all the way to Ruby not to mention Pascal, VB, PHP, etc?

Carl Youngblood: Legato eventually closed down their office in Orem, Utah, at which point I went back to school to get a masters degree. I began thinking I was going to do a masters in Portuguese and eventually work as a professor at a University after getting my PhD. However, I found myself constantly working on software projects, even while I was teaching Portuguese classes and doing my graduate studies. I eventually decided I should face the obvious and continue my passion of software development. So I switched over to the Computer Science department and began working towards a masters degree in CS. All this was at Brigham Young University in Provo, Utah.

I first learned Pascal and C++ in high school Computer Science classes. My first professional experience was as a C++ programmer developing Windows applications using MFC. I then got a job doing PHP/MySQL development for Omniture. After that I was doing C-based windows drivers but also doing Ruby, Perl and PHP work on the side. Drivers are really a totally different beast because you don’t even have the regular ANSI C libraries available to you. So the C syntax is the same but that’s about it. I later got a job at Boeing doing more C++ development on Linux platforms, all the while nurturing my Ruby/Rails skills with side projects. I also learned functional programming with
Scheme, as well as a few other languages like OCaml, Prolog and ZPL during my masters degree. I wouldn’t call myself anything but a beginner in most of those other languages, but they definitely opened up my mind to new development paradigms.

AkitaOnRails: You’ve pretty much followed the paths described by Pragmatic Programmers as David Thomas and Chad Fowler: learn new languages, specially ones with very different paradigms. Did you already know their work around these recommendations? Or was it just a natural curiosity thing that led you to learn so many languages?

Carl Youngblood: Well, the CS programs I’ve studied in (BYU and the University of Washington) did a good job of giving us at least some exposure to a wide range of concepts and languages. I really am grateful for my education because it introduced me to ideas and concepts that I probably would not otherwise have studied. I had also read the Pragmatic Programmer and tried to follow the advice of always learning new things and exposing myself to new languages. I am also somewhat of an information junkie. I am nearly addicted to my RSS feeds, and I feel an incredible anxiety if I start to get behind on my reading—almost as if I’m being left behind while the world reinvents itself. The truth is that I usually don’t miss anything extremely revolutionary by being away from the computer for a few days, but sometimes it feels like it.

Or rather, I worry that it might happen. :-) It can be a problem. It’s hard to strike a balance, especially with a wife and kids to pay attention to.

AkitaOnRails: You’re right. That’s another thing that I always shout at my blog posts: being well informed, all the time. There’s no excuse with tools like RSS aggregators nowadays. And if an American went all the way to learn Portuguese and still being a technology specialist like yourself, there’s even less excuse for Brazilians to avoid improving their English and read more.

Carl Youngblood: I’m not sure if you’ve heard the theory of maximizers vs. satisficers. I read about it on somebody’s blog, taken from a book (can’t remember which). Sometimes I … worry so much that there must be a more elegant solution out there that I can’t ever decide when it’s good enough and get down to the actual business of coding.

AkitaOnRails: hm, yes I believe I read something about this.

Carl Youngblood: That is a problem in this era of rapid innovation. It’s always a moving target, and sometimes you just have to say something is good enough for now and move on.

Joel Spolsky talks about this and compares it to the military tactic of laying cover fire and firing while advancing. Rarely is a new technology or buzzword all it promises, but it keeps the competition struggling to keep up.

In general, it seems like society is advancing toward ever-increasing levels of abstraction. Rails is a good example of this. Its whole mentality is to predict as much as possible the things that the developer will be wanting to do all the time and make convenient abstractions for them. But I’m sure this is only the beginning. We can expect future frameworks to do more and more of the heavy lifting for us, which will in turn enable us to accomplish more and more with less and less effort.

AkitaOnRails: Yes, this is a good very point. Because people tend to ‘fall in love’ with one particular super-new technology and forget about all the rest. This leads to pure obsession. And after a while, this ‘new trend’ is forgotten altogether and you just wasted your time.

Carl Youngblood: Yes, we need to stay current on new technologies but try not to get too dogmatic about them. Chad Fowler’s recent address at the MountainWest Ruby Conference talked about this.

AkitaOnRails: Hey, sorry for the pun, but coming from someone with such a formal dogmatic religious formation like yourself, this is a very refreshing thing to listen: not being too dogmatic. In the end its all a matter of common sense, but even common sense has to be trained. Hence the need to be always informed, constantly studying and keeping an open mind toward new stuff while not closing the eyes to all the rest.

Carl Youngblood: I believe that one’s belief structure should never be so rigid as to not allow for modification. I should always be willing to re-examine my beliefs in light of new evidence and be willing to reject or modify beliefs that seem wrong or misinformed upon closer scrutiny.

In defense of my Mormon upbringing, although it is a fairly conservative religion, it does place a high value on education, which inevitably leads to enlightenment and often to a modification of one’s prior beliefs. Fortunately my fellow parishioners still welcome me, though some of my beliefs may be a bit unorthodox and are different from those I had when I was younger.

AkitaOnRails: We do need more of this way of thinking here in Brazil: pragmatics. Anyhow, coming back again, you were very busy for a long time. Learning Portuguese, finishing your major in CS, working in Internet companies, traditional companies. And all the time Ruby was sneaking somewhere, waiting. When did you finally realized you wanted to do more Ruby? Was it during some project at your day-job, or something you decided by yourself?

Carl Youngblood: I think the real awakening was the meteoric rise of rails and 37signals evangelization of the whole getting real mentality. I attended the Building of Basecamp seminar in Seattle and went to the first RailsConf. I was really inspired by Nathaniel Talbott’s speech about homesteading.

One thing that really struck me about my experience at RailsConf was that I saw colleagues there who started using Ruby at the same time I did and whose names appeared on the ruby-talk mailing list alongside mine. The main difference between them and me was that they decided to get actively involved, to develop open source projects of their own, and to build a reputation for themselves in the community, while I dabbled in Ruby as a mere hobby. Fast forward four or five years and they were running their own companies and really making a career for themselves in Ruby. Railsconf was a wake up call for me in which I realized that I needed to be more involved in the Ruby community.

So I decided to release some prior work of mine as a gem and give a presentation at our local MountainWest Ruby conference. I released the SBN (Simple Bayesian Networks) gem. Preparing my presentation and code was stressful but worth it.

Some colleagues and I are also working on a conference recording business called Confreaks. We are hoping to do a better job of recording and disseminating technical conferences for posterity’s sake. It’s a shame that all these great conferences are going on and nobody is recording them.

Anyway, my increased involvement in the community has really helped to boost my career and allowed me to code in Ruby as a day job.

AkitaOnRails: But where were you at the time Rails started to call attention to itself? Did your job allow you to have enough time to dedicate to Ruby or you switched jobs by then? I mean, were you not satisfied by the current state of your career and the technologies you were using? What was your ‘inflection point’? Just seeing RailsConf and the news around Rails?

Carl Youngblood: I was working for Boeing when Rails first came out. It was a comfortable low-pressure job on a DoD project with a long drawn-out timeline that allowed me time for study. I was already in the habit of staying current on technologies (Ruby in particular) and reading a wide range of blogs regularly. I would have accepted a Ruby position at any time but they were still fairly hard to come by. At my request, my boss paid for me to go to RailsConf, so I was already really interested. I had also been working on a freelance project that I had written earlier in PHP, and offered to rebuild it in Rails at a heavily discounted rate just to gain experience with Rails. So I guess you could say that I have been really interested in all things Ruby ever since 2000 but only recently has the job market begun supporting full-time Ruby positions.

AkitaOnRails: And your first endeavor towards Ruby was your SBN open source project and the Mountain West keynote? Can you describe what it was like? At least for me, when I want to ‘say’ something, I get very excited and particularly anxious to have it written (in my case, my blog posts). I can imagine that you hardly slept before the conference. :-)

Carl Youngblood: Yes, I was up many late nights preparing for my presentation. In fact, most of my late nights were spent getting the code ready for human consumption. Knowing that the world at large is going to use your code makes you want to spruce it up a little more, write more unit tests, etc. So I spent the month or two before the conference working on the code and only had about a week to prepare my actual slides. My presentation material was fairly technical, so I ended up writing down my presentation in the slide notes, just to make sure that I didn’t explain something wrong during the pressure of the actual presentation. Had I had more time, I would have liked to have memorized the key points so that the presentation could be a little more natural, but overall I was pleased with the way things turned out. I was also working on the Confreaks project to record the conference, so I was busy on two fronts, not to mention my day job.

AkitaOnRails: And by that time were you still at Boeing? Or were you already at Surgeworks? How did you get into Surgeworks to work on Rails full-time?

Carl Youngblood: Around the time I was finishing my CS Masters degree at the University of Washington while working for Boeing, I received an offer from a friend of mine to return to Utah and work for him as CTO of a Construction Lending Company called Construction Capital Source. One of my main responsibilities would be to develop a construction lending system in my technology of choice, which just so happened to be Rails. I took the bait and had a great time there for about a year and a half. But the company went through some difficulties with the recent crash of the sub-prime lending market. Although their customers are only A-paper borrowers with excellent credit ratings, the sub-prime market has cast a pall on the entire industry, and our investors got scared. I ended up leaving my position and accepting a job at Surgeworks as their “Rails Practice Manager,” which means I supervise all the company’s Rails projects, hopefully while still getting to spend at least half my time coding, although at the moment it hasn’t exactly worked out that way. We have been getting a lot more work coming in since I started, so a lot of my time has been spent writing proposals and project estimates so far, but I’m starting to settle into a groove.

AkitaOnRails: But how did you know about Surgeworks? I remember that you mentioned you already knew Dane Falkner from another occasion?

Carl Youngblood: Dane and I both attend the local Ruby users group meetings in Salt Lake City, so I knew him from there. Upon leaving CCS, I posted a message on the URUG list and was happy to see that there are a lot of Ruby positions available. I don’t think I’ll have trouble finding Ruby work in the future for as long as I’m interested in coding in Ruby :-)

AkitaOnRails: That’s very nice. There are a lot of local user groups there. We still are starting local groups here in Brazil. What can you say about the growth and enthusiasm of the community? What do you see for Rails in the time being?

Carl Youngblood: In my experience, the key to a successful users group is having one or two dedicated individuals with the passion to organize and promote the meetings and line up interesting presentations. If you do that, people will attend. Our local groups have gone through ups and downs depending on the level of the organizers’ enthusiasm. Another thing that seems to help is providing content that is geared towards various skill levels. Making sure that you welcome and help beginners is important. The community is still growing, as evidenced by the many regional Ruby conferences that are cropping up around the US.

I was excited to see DHH’s planned features for Rails 2.0 and his more measured rhetoric as opposed to the first Railsconf, which some folks commented seemed more like Nuremburg rallies :-) I think Rails will continue to mature and has at least 2-3 more years of great success before being eclipsed by some new paradigm breaker.

AkitaOnRails: This is important and maybe you can lay some ideas. Many of the core Ruby and Rails contributors in Brazil, from our local forums, user groups, blog and websites still don’t have the opportunity to work full time on Rails. So they have little to no time to devote do Ruby yet. I believe that there was a time like that there in the US. What do you think was the turning point for the community to flourish?

Carl Youngblood: I think more than anything else, the incredible success (especially the marketing success) of Rails has been the largest contributor to this change. But that didn’t stop passionate Ruby developers from blazing their own trails before then. I think the thing that needs to change first in Brazil is the 9-5 just-a-job mentality. People need to start taking some of the recommendations from the Pragmatic Programmer to heart and making time for extracurricular skills-honing activities, including ruby meetings. This is what folks in the US did and I think something similar will be required in Brazil. I think there is also a cultural difference that is partly to blame. I don’t want to claim that either system is superior, but I think Americans (at least the ambitious types who are in the Ruby community) spend more than 40 hours a week focusing on their craft, whereas I think many folks in Brazil look at software development as something that just pays the bills.

Of course there are many programmers here with the same mentality.

AkitaOnRails: Speaking of passion, David always states about the sense of aesthetics of the community, their inherent sense of beauty towards coding. Did you sense that when you first started? Many say that’s one of the reasons for the Ruby and Rails community being so Mac geared. What do you think about this?

Carl Youngblood: I agree. Matz often quotes a Chinese proverb that says something like “the beginning of wisdom is naming things correctly.” Ruby people tend to spend a lot of time focusing on semantics and making sure that code is not only useful but elegant. I think when you are seeking to maximize your level of abstraction and hence your programming power, these kinds of issues are very important and can provide a huge productivity increase.

Apple seems to reflect a similar mentality in their designs.

AkitaOnRails: I think its nice to mention that I was pretty surprised to see that almost everybody at Surgeworks are Apple-fans. I never expected that. I guess Apple is gaining into the developers workspace as a valuable productive tool. Well, and I know I already pushed you for too long :-) Any other remarks for the Brazilian audience?

Carl Youngblood: I think a lot of Surgeworks’ passion for Apple comes from Dane, who is a big fan. My main advice to my friends in Brazil is to recognize the importance that your individual effort can make. You have a relatively strong IT industry for South America and a burgeoning open source community. I have been very impressed with some of the more vocal Brazilian techies like yourself, Fabio, who have shared their opinions on the Internet. Change is not brought about by the masses, but by thoughtful courageous individuals who break free from the status quo. The more Brazilians take that to heart, the sooner Ruby jobs will start to appear. I am reminded of a quote along these lines:

“Never doubt that a small dedicated group of people can change the world; indeed it is the only thing that ever has.” (Margaret Mead)

AkitaOnRails: Very nice. Well, I think we can wrap it up for today. Thanks a lot! I think people will like this.

Carl Youngblood: Great! Thanks for taking the time, Fabio.

Meet Ola Bini , a young, dynamic and important contributor to this amazing project. Ola is member of the JRuby Core Team and currently works at ThoughtWorks to help assure the continuing success of JRuby.

I had the opportunity to chat for more than an hour with him. So, another great interview for our website.

AkitaOnRails : Hi. Ola, you’re ready?

Ola Bini : Hi there. Yeah, sure, let’s get started!

AkitaOnRails : Super! First of all, thank you very much for accepting my invitation, I understand you’re very busy. And that’s exactly why it will be interesting to talk to you, as you’re involved in a lot of exciting stuff.

Ola Bini : hehe. Yeah, hopefully I’ll be able to tell you about it too.

AkitaOnRails : Now, second, congratulations for both the achievement of the release of JRuby 1.0 and of you moving to London and becoming a Thoughtworker.

Ola Bini : Thank you! I’m very happy about both occurences.

AkitaOnRails : I always start my interviews with a little overview on the origin of the programmer, or how did you get into the tech world. Young programmers have lots of questions and doubts and I think this helps getting them in perspective. Could you tell us how you started? What made you choose programming?

Ola Bini : Well… I guess my father was an influence. I started programming Basic on an Apple IIc when I was 7 or 8 years old. I had fun from the beginning, so my father helped me out, he gave me my own computer and so on. So basic was what I did first, but C was the first real programming language I learned and actively used.

AkitaOnRails : Game programming?

Ola Bini : Yeah, game programming and demo programming the first few years. Picked up C, most of C++, Assembler and Pascal before I was 16. I actually dropped out of High School, since I got an offer to work as a programmer in Stockholm, which is how I started doing it professionally.

AkitaOnRails : Just for fun?

Ola Bini : Yes, the game and demo programming was just for fun.

AkitaOnRails : Oh, so you started working on programming very early in your life.

Ola Bini : Yes. I got a full time job programming Java at the age of 18.

AkitaOnRails : So you jumped very fast from C to C++, Pascal and Java.

Ola Bini : Yes. Java was easy after C and C++. Pascal I never really liked, but I had to learn it since most tutorials about graphics programming used it.

AkitaOnRails : So your first job was around graphics?

Ola Bini : Actually not. It was web programming with Java, JSP, PHP, ASP and other such technologies, for a department of Karolinska Institutet, doing web systems for distance learning.

AkitaOnRails : Yes, by the way, you mentioned Stockholm. Are you from there? Sweden?

Ola Bini : No, I’m from a small place called Kode, which is about 60km north of Gothenburg. Yes, I’m from Sweden. Moved to Stockholm at 18.

AkitaOnRails : Wow, I believe your parents were very shocked having you dropping school to work so early. Have you ever graduated?

Ola Bini : Well, not shocked really. I didn’t really learn much during that school period, so it didn’t come as a surprise to my parents. And nope, no graduation for me.

AkitaOnRails : And I believe this was the 2000 internet bubble era? As you mentioned web tools.

Ola Bini : Actually, it was 2001, directly after that bubble, so I was lucky to get a job.

AkitaOnRails : I see. You have a lot of Java background, how did you start working on Java? And how did you become interested in Ruby?

Ola Bini : Yes, I’ve never been fond of Java as a language, and I’ve always been interested in other languages. So I learned Lisp quite early and fell in love with it. A few years back, 3 or 4 I think, I discovered Ruby and tried to convince my employer that we should replace various perl and bash scripts in our environment with Ruby. That didn’t work so well, but I continued talking about Ruby and using it in my spare time, and one and a half year ago they finally caved in, we made a Rails pilot and it was a clear success.

AkitaOnRails : Was there any particular event that led you to Ruby, or you found it by accident?

Ola Bini : I think it was accident. Especially since I don’t remember the exact point of it at all.

AkitaOnRails : Lisp has a completely different heritage from structured languages like C. I guess you liked the functional aspect of it?

Ola Bini : Yes. And the malleability. I’m very fond of the macros in Common Lisp, and also like the very no-nonsense structure of a Lisp program. The fact that there is no real division between data and code. The functional aspects are pleasing, but not the main reason for my like of it.

AkitaOnRails : Coming back to JRuby. I read from your blog that you’re working on JRuby since early 2005? How did you become a JRuby Core Team member? Did you know Charles or Thomas before?

Ola Bini : Late 2005. And no, I didn’t know them from before. I started contributing small things first, and then last March and April I did some larger things. I continued helping out, and soon after Charles and Tom got hired by Sun they decided that I would make a good addition to the core team.

AkitaOnRails : Were you still working in JRuby on your spare time or did it become a full-time endeavour?

Ola Bini : I have never been able to do JRuby full-time; sometimes I’ve been able to work on it during lulls in my regular work, but most of it has been strictly spare time. Until now, of course.

AkitaOnRails : There are a lot of doubt and fear in the mind of inexperienced Java programmers here. They “fear” to have lost time learning Java. They “think” that Ruby is a lesser language, and so on and so forth. I think the problem is that most of them think that they only need to learn one language only. This is a two-fold question: first, you mentioned that you dislike Java. Can you elaborate on what exactly? And second, what do you like about Ruby?

Ola Bini : I would like to begin by saying this: it is very hard to be a good programmer while only knowing one language. Knowing several programming languages of different style is imperative to use a language well. Knowing lisp makes me a better Java programmer. My former co-worker Lars have told me that learning Ruby makes him a better Java programmer. So, learning another language is in fact something you can do, and should do, to make you a better programmer in Java, for example.

AkitaOnRails : I couldn’t expect a better answer.

Ola Bini : So, Java: I think the language overly verbose, the type system is inconsistent and quite annoying at times, and there is no way to compress code. When refactoring, you end up with more lines of code for the same functionality. Also, there is lot of clutter in a typical program.

I don’t think generics have improved this situation. I think that Ruby have almost all the power I’m used to from Common Lisp. In some cases you can do amazing things with the metaprogramming capabilities. Ruby is like clay, it can be formed into whatever you want, and Java is marble. Also, I like that Ruby have enough of a heritage from Perl to be pragmatic and easy to use; it’s fast to get started with and you are productive in a very short amount of time.

AkitaOnRails : Ruby is an excellent language, no doubt. Ruby 1.9 is growing to become better. Are you updated in their development? I personally have a few things I’d like to have in a new version, as native UTF-16 top to bottom, a better and unified Datetime handling, at least less C dependency, a generational garbage collector, a better way for IDEs to introspect and debug into the code maybe as Smalltalk does. Now that you touched most of the language, what do you think you’d change if you had the opportunity? Or you’re satisfied with its current state?

Ola Bini : No, I’m not satisfied, which is one of the reasons I work on JRuby. There are some features of the Ruby language which I think makes it hard in some cases. The file system operations aren’t abstract enough; very unix-centric.

The threading system is dangerous since it provides features a “real” threading system and GC can never give you. (things like critical= and ObjectSpace I would like to see gone).

So, a better GC, more tunability, a better threading system, no global locking. But right now, I feel that the fact that we have several implementations of Ruby coming up, the features will prove themselves. If Rubinius makes the right choices for these things, Rubinius will get more users than MRI/KRI in the long run. I agree about better UTF support, of course. Anyone who’s not from the English countries know this.

AkitaOnRails : I was trying to reach Evan Phoenix. Charles mentioned Rubinius as well. How do you think both projects can collaborate? What gaps Rubinius close for JRuby, for example?

Ola Bini : We are trying to cooperate. Especially with testing and implementing more of the core library in Ruby. Evan is moving to LA this week, so that’s why you won’t reach him.

AkitaOnRails : Yes, so I heard. And speaking of which, I would be personally terrified on working on something as big as JRuby. The part that frights me the most are the C-coded ones. There are several core features of Ruby totally coded in C. How difficult was this to you? Can you tell us about some particular issue about this that left you scratching your head?

Ola Bini : Well, yeah, parts of MRI can be fairly “interesting”. They do things like modifying the argc and argv to varargs methods. The problem with the C code is that they heavily use pointers, all over the place. Sometimes they wrap non-Ruby objects in a VALUE pointer, which is just hackery. But it’s usually not that hard to figure it out, since I’ve been doing lots of C code in my days.

AkitaOnRails : The JRuby implementation proved to be very successful but not without its hassles. Unicode, SSL, Regex, YAML. For example, you described differences in the Java’s regex implementation and the Ruby MRI’s version at your blog. What were the most difficult parts on the porting process, feature-wise, from your point of view? Where was the heavy-lifting?

Ola Bini : There are basically two things that were the “worst” in getting something that works. The first was all the corner cases. Strange behaviors that isn’t really specified, but just behaves that way because of the implementation.

Have you tried using super within a block, where the surrounding method takes * args and you modify args? Threading proved problematic too. And the other main area is, as you say, extensions. It’s basically impossible to run anything significant without porting several extensions. Just a few number of these we needed, for example: strscan, yaml, zlib, enumerable and regexps are problematic. We have three different engines right now. The Java one, the JRegex (which is the one we use), and one called REJ, which is the MRI regexp engine ported to Java. (REJ isn’t used)

AkitaOnRails : Before JRuby actually started gaining traction (mainly because of Rails, I guess) they were pretty much stalled. It was trying to cover Ruby 1.8.2 if I remember correctly. So much of this stuff were not yet covered at that time?

Ola Bini : Yes, that’s true. Most of the progress we have made, was done from January of 2006 and forward. The support was there. Large parts of the parser was working fine, but almost no extensions, and many parts of the language were still at the 1.6 level.

AkitaOnRails : I remember reading in your blog about a way to run a Mongrel Cluster entirely inside a single JVM. Was that just a proof of concept or do you see Rails apps being deployed this way? What would be the advantage of using Mongrel in the JVM space? Or the main traction for Rails is the Goldspike plugin and the JRuby-Extras tools?

Ola Bini : I did it first as a proof-of-concept, but I think it’s a viable solution. But mostly, I thought it was interesting to do as something for people coming from the Ruby crowd. People who are used to the Mongrel approach. I wanted to give them a better solution than starting 10 JVM’s. And that’s in core, the jruby server is a generalized tool that can be used in other circumstances too.

AkitaOnRails : But Goldspike doesn’t require Mongrel to run. So we have 2 ways of running Rails apps in the Java space.

Ola Bini : Absolutely. And I think that the Goldspike route is the superior one. But Ruby is all about choice and flexibility.

AkitaOnRails : I guess we will come to that again when talking about Mingle. Which brings me to ThoughtWorks. Tell us this story. How did you know them? How did you get on board?

Ola Bini : Well, the name have been familiar for a long while. They’ve got a good reputation, as you know. About last April a friend of mine got hired. We talked some and it seemed like a good place. We decided that I should apply. She did a recommendation and I was there and interviewed in August. Everything went quite well, except that they didn’t have enough revenue at that point, so they couldn’t hire me. Then we took up contact again in February, started talking about Ruby and ThoughtWorks Studios. I came back, did a quick interview with Cyndi, and the rest was basically logistics.

AkitaOnRails : Cyndi Mitchell?

Ola Bini : Yes. She’s one of my bosses. (The structures here aren’t really clear… =)

AkitaOnRails : She presented a keynote at RailsConf if I remember correctly.

Ola Bini : Yep. She did. She was also the one who put my name and number on the big screen. =) I was there with her and Roy and Martin Fowler, and some other ThoughtWorkers.

There’s a flat structure, yes, which means I don’t have explicit bosses, but bosses that manage over different areas of my time, so to speak. So Chad Wathington takes care of my RubyWorks work, Cyndi handled all employee logistics for Studios, and Alexei Vorontsov is Project Manager for RubyWorks. All of them bosses to me, so to speak.

AkitaOnRails : Nice. I also read that you’re working a lot in Mingle. This is another important milestone as this is probably the first commercial JRuby app with total support from a big company. Please elaborate on what is Mingle and what are your responsabilities in this project.

Ola Bini : Absolutely. So, Mingle is a an agile project management system. It aims to be more flexible and more close to the agile methods that agile people would love to practice more of. My responsibility is deceptively simple: it is my task to make sure that JRuby will work out, fix problems and help out when making the application bi-implementational, so it runs on both JRuby and MRI.

AkitaOnRails : Does it have anything to do with CruiseControl?

Ola Bini : No, not at this point. As far as I know, there will be integration at some point, but I’m not involved in that.

AkitaOnRails : Ok. You’re also involved in every single Java and Ruby conferences out there. I always wondered how guys like you find enough time to 1) actually present good stuff at the conferences; 2) find enough time to bring exciting open source projects as JRuby; 3) still have a day-job and be productive. You have to have 48 hours each day (and I’m probably disrupting your workflow right now =) How do you get yourself organized?

Ola Bini : Actually, we try to share conferences between the core developers. For example, I will take TSSJS while Charles and Tom take vacations. Presenting good stuff helps us share material among each other. Also, Charles and Tom, and now me, are actually working on this as our day job, where evangilizing is an important part.

Organization is harder. I usually keep lists on tadalist. That works well enough for me. That’s all the organization I’m actually using. But I tend to be highly chaotic, which works fine for me.

AkitaOnRails : haha, but you have to be on the computer more hours than the average programmer to accomplish all this.

Ola Bini : hehe. Well, yes. I’m not far away from computers during my waking hours, that’s for sure. Especially not with the book writing, which eats seriously into my time for other things. =/

AkitaOnRails : And speaking of being workaholic and evangelization. You are also writing a new book about JRuby. It is scheduled to be released in a few months. Tell us more about it.

Ola Bini : Well, it’s a book about JRuby on Rails. It’s aimed to be quite practical, giving concrete examples on how do achieve things. There is quite a lot of JRuby information buried in it, of course, but it’s not a general book about JRuby.

APress will publish it, and according to the current schedule, it will be released in October. Pat Eyler is my tech reviewer. And that’s about it. =) It’s going to be about 250 pages long, containing 4 JRuby on Rails projects developed from scratch.

AkitaOnRails : Haha, and I imagine that it is difficult to write about a moving target, isn’t it? JRuby is still evolving as well as plugins such as Goldspike, that you need for Java deployment.

Ola Bini : Of course. In some cases I had to revise parts substantially, and in other cases I had to write lots of stuff for JRuby, just to get it finished for the book. So, in some ways, me writing the book has improved my work on JRuby too, giving me input on things that need to be fixed, and so on.

AkitaOnRails : Yeah, do you see a JRuby 1.1 release coming soon?

Ola Bini : Hopefully a JRuby 1.1 release will be out within 2 months. It’s possible that it will take longer, due to the summer being down time for some of us. But JRuby have a tendency to move fast and have many releases, so I should count on it within 2 months.

AkitaOnRails : Rails brought a lot of interest in developing using Macs. Textmate is the primary reason. I saw some of Charles presentations and I believe he was using Emacs. What are your primary tools for developing both JRuby and your Rails apps?

Ola Bini : Actually, Charles and Tom usually use vi for presentations, and Netbeans when doing development. I’m more oldfashioned. I work on a Mac, but I’m too much of a Lispnic to use anything else than Emacs. So Emacs, with my something like 10.000 lines of E-lisp code is my main tool.

AkitaOnRails : Hey, won’t you release your Emacs bundle as an open source project as well? :-)

Ola Bini : hehe. No, I don’t think so. It’s full of cruft and many things which are highly specialized for me. That’s really the point of Emacs: you create your own little world.

AkitaOnRails : I think that lack of stronger tools and IDEs are still an obstacle for mass adoption by switchers coming from Java or .NET. Do you feel the same way or do you see adoption growing regardless of that?

Ola Bini : I think you are right, but I don’t see it as a rational objection to switching. But there is coming lots of good support for Ruby now, if you want it. Eclipse, Netbeans, IntelliJ, jBuilder. There are many options and they seem to get better each day.

AkitaOnRails : But, you’re not dropping Emacs any time soon ;-)

Ola Bini : hehe. Nope. That’s not going to happen.

AkitaOnRails : And finally, what do you see in your future with JRuby? Any other personal project that you want to invest more time? Or you’re 100% full-time on JRuby for the time being?

Ola Bini : Well, I believe that JRuby and JRuby related projects is going to take much of my time. If I get some spare time, I would probably try to concentrate on my music; but if you wanted computer related projects there are three things I would want to do: Jio, a Java implementation of Io; CLaJ, a new Common Lisp implementation on Java, based on Lisp In Small Pieces, with the explicit goal of being both performant, maintainable and compliant. And finally, I would love to be able to do more AI things.

AkitaOnRails : You say you don’t like Java that much, but 2 out of 3 are Java related :-)

Ola Bini : You have to make a difference between Java, the language and Java, the platform. The platform is outstanding, and I want all languages to have a base like that. And yes, the projects are Java based, which means I’ll sacrifice myself for the sake of others… =)

AkitaOnRails : Good point. And as Steve Jobs would say “there’s One More Thing™”: I try to bring a lot of advise from experienced people like you to programmers beggining their careers. They have lots of questions. What would you recommend for this new generation of programmers? (Although I think you are very young yourself.)

Ola Bini : This shouldn’t come as a big surprise after this interview: my advice would be to learn more than one language. Simple enough. Something functional, or with a desperately different concurrency model. Lisp, Smalltalk, Erlang and Ruby are all good choices for a Java/C/C++ programmer to learn. And yeah, I guess I am. I’m 25 now.

AkitaOnRails : As Dave Thomas said in the Pragmatic Programmer: learn at least one new language every year.

Ola Bini : Absolutely. That’s good advice. I can’t top it. =)

AkitaOnRails : By the way, out of curiosity, do you speak English in Sweden?

Ola Bini : No, not very much. I speak English when the other person doesn’t understand Swedish, or if someone in our company doesn’t understand Swedish (out of courtesy).

AkitaOnRails : I thought so, you have very good English.

Ola Bini : Thanks. We work with English from the 4th grade in Sweden, so most have a passing ability at least.

AkitaOnRails : That’s another thing I evangelize here in Brazil: to learn English as best as you can. Liking it or not, English is the language of the technology world.

Ola Bini : Yes, without question. English is very important. And after that, I guess Chinese is. Based on simple numbers.

AkitaOnRails : Absolutely. How’s your mandarim? :-)

Ola Bini : hehe. My mandarin and cantonese are totally nonexistent. But I guess that’ll come… =)

AkitaOnRails : I guess ThoughtWorks has an office at China as well, doesn’t it?

Ola Bini : Yeah, we have two. It’s possible I’ll move there for 6 months next year. But I don’t have any facility for human languages. English is the only language I know well, except for Swedish.

AkitaOnRails : No way, tell me about it. That’s a scoop!

Ola Bini : Hehe, it’s possible, but not certain. We are looking at where the RubyWorks team should be placed, and China is probably the best location for me. I will move to San Francisco later on, but I need to work for ThoughtWorks for 1 year to get an L1 visa first.

AkitaOnRails : China? Best for you? how come?

Ola Bini : Since most of the RubyWorks team will be there or in Bangalore.

AkitaOnRails : Ruby, with JRuby, is getting near its birth place (Japan). Curious. Well, I guess I already disrupted your work hours a lot. Another great interview is finished ;-) Any closing remarks for the brazilian audience?

Ola Bini : hehe. Thanks. Nope, I think I’ve said it all now! =) I hope to get to Brazil at some point or another, so don’t be too harsh on me when I arrive!

AkitaOnRails : Cool. Its been very nice talking to you. I hope we can exchange more ideas later on. Thank you very much!

Ola Bini : Thanks! Keep me posted on what happens. Bye.

As I reported on my last post, on April 24th I was very fortunate to interview two great celebrities from the Ruby world: Chad Fowler and David Black. I love to chat with experienced people because I learn so much.

David Black was a great guest, we had a very nice conversation where I pushed a little bit more of the subject that I like to discuss: programmers careers. David is one of the founders of Ruby Central and he has his own company called Ruby Power and Light which offers training and consulting services. He is also the author of the excellent Ruby for Rails book, from Manning.

So, here goes:

AkitaOnRails : Once again, I’d like to start with the usual questions of all interviews: how did you get into computer stuff? What hooked you up into programming? It is curious because I learned that Geoffrey Grosenbach was graduated in philosophy and Chad was a musician!

David : I’m a musician too (I play the cello). I’ve got an undergraduate degree in Art History and German, and a Ph.D. in Cinema Studies as for how I got into programming….

It was when I was 13 (which was 1972). My school had a PDP-8, and the university where my parents taught had a PDP-10 which they let me use. I was totally obsessed with it. Then I stopped doing it for quite a few years… and then after I got my first PC, I got back into it (around 1990). I started using unix in 1990, and linux in 1993

AkitaOnRails : Now, that is interesting, I asked Chad the same thing implying that he got interested in programming around the PDP-10 era. I think the beard deceived me :-)

David : Yeah, I’m not sure he was even born when I started programming.

AkitaOnRails : I wasn’t, I was born in 77. And by the time I got interested in computers, the original Macintosh was just released. I love to be young at this era but I always wanted to deal with PDPs, punch cards. I like ‘technology archaeology’.

David : I still have paper tapes in my basement.

AkitaOnRails : I am assuming that you, Chad, Dave Thomas are very close friends. Are you? Or do you only work together organizing the conferences at RubyCentral? I understand that all of you started RubyCentral back in what, 2001? I heard that you kind of inherited it. Did you meet them at that time or you’re long time friends?

David : I met them both (online) around late 2000. I had not known them before. What happened with the 2001 conference was this: there was a guy named Guy Hurst who had come up with the idea and done most of the organizing of the event. But he wasn’t able to follow up on it (various work-related things had taken precedence).

But Dave didn’t want it to be cancelled, since it was going to be the first such Ruby event and having it actually happen was important. He didn’t have a lot of time for it, though, so he asked me and Chad to take it over and see it through to completion, which we did.

Then we decided that we should have a parent organization for future conferences. For the first conference, I just deposited the money in my bank account and kept track of it (separately!). That was not a very scalable approach to handling finances so we created Ruby Central in 2002.

AkitaOnRails : Yeah, Chad mentioned that. I already knew some of this (it’s kind of a legend by now). But do you hang around together? Do you work together? For some reason I see the 3 of you more like the “Founding Fathers” of Ruby outside Japan.

David : We’re all friends. Chad works more closely with Dave than I do, since he’s done books for the Pragmatic Bookshelf and taught for the Pragmatic Studio. Chad and I have been involved in a lot of collaborations — Ruby Central (the third director is now Rich Kilmer, by the way), various websites, etc.

AkitaOnRails : As some people, I heard about Ruby around the same time I was experimenting with Python and Zope, and it was back in 2001. But I have to confess that I only turned my attention to Ruby once Rails was released. You’re into Ruby since the beginning of its history in America. I already heard about your “by accident” story and I find it very amusing, please tell us about it.

David : It was, I think, early november, 2000, so the Pickaxe had been out for literally about a week or two. I was in Borders bookstore, near my house, looking through computer books. There was this book called Programming Ruby. It made me curious, so I pulled it off the shelf. It was instant love. I don’t think I even put it down on the way to the cash register. Ruby immediately had the feeling of being exactly what I wanted, even though I may not have known I wanted it and here I am, 6.5 years later.

AkitaOnRails : That’s what amuses me. It’s like looking for a nice bottle of wine, a gorgeous piece of art. A novice can’t just walk into a store and evaluate by instinct alone without further background. What do you think you had at that time that made you “fall in love” with Ruby?

David : I don’t know. I don’t think you can explain love. I think I was kind of getting tired of Perl… and Python wasn’t really attracting me but I didn’t anticipate finding Ruby — it was a very pleasant surprise.

AkitaOnRails : Yes, that’s my point: you were experienced in other stuff that made you “feel” something for Ruby. Many young programmers I met can’t understand this. Many of them think that they only have to learn one language only. Do you meet this kind of programmers there?

David : Interesting question. I think most of the programmers I meet know more than one language — because a lot of people are just starting with Ruby, and most of them have done some programming before. Actually I think it’s too bad that people seem to think that for every language you love, you have to hate ten. In recent years, I’ve probably become too specialized. Ruby has given me so much to do!

AkitaOnRails : I believe you’re mostly famous now because of your Ruby for Rails book. I like the title because to me it outlines the point that to excel as a Rails developer a strong Ruby knowledge foundation may be critical. Do you think that way?

David : Yes, definitely I wrote the book because I had started to see people asking questions like, “Do I have to learn this ‘Ruby’ thing to do Rails?” It reminded me of all the confusion over Perl and CGI. People thinking that Perl and CGI were synonyms. It seemed like I wanted people to understand exactly how Ruby and Rails relate to each other. And to understand that when you develop Rails applications, you are writing Ruby programs. So it makes no sense to me when people say that you should ‘start with Rails’, as if Rails development could be conducted without Ruby. Of course you can get a Rails app up and running just by cutting-and-pasting from other apps, but that’s not development.

AkitaOnRails : Yes, I see the same thing here, and in fact I see many people writing Rails apps without knowing basic stuff like what is a closure for.

David : Even though not every Ruby technique will be used in every Rails program, the more Ruby you know the more options you have and I think people also get interested in Ruby itself, even if they learn about it first from Rails.

AkitaOnRails : I read somewhere a statement from DHH that you were a very important mentor for him, in the beginning of his ideas about Rails. So, if DHH is the father of Rails, you would be its grandfather? How do you think you influenced him? How was this relationship with DHH?

David : I don’t think I influenced him before Rails. I’m definitely not that much of an influence on Rails. Have you talked to Hal Fulton? I seem to remember that DHH credited the Ruby way (Hal’s book) with being a big influence.

AkitaOnRails : Who is he?

David : Ah ha! Hal is one of the great Rubyists and great Ruby authors.

AkitaOnRails : Hm, my bad. I should’ve known about him.

David : See, he doesn’t do Rails, so he’s not as well known to the younger generation as he should be. He was working on ‘the Ruby way’ by the time I discovered Ruby, I believe (or close to it).

AkitaOnRails : You’re right. I know the ‘Ruby Way’ book, but it’s on my queue of to-read books yet.

Ah ha, I just found the foreword for your book, from DHH: “As I was learning the language, I often consulted the Ruby-talk mailing list. One voice in particular seemed to know Ruby well and appeared to have the ambition as well as the ability to help others understand it more fully. That voice belonged to David A. Black, the author of this book.”

David : Hmmm, maybe I did influence him but I would not put myself in the direct Rails ancestry.

AkitaOnRails : Haha, I understand. You drive a company called Ruby Power and Light. Please tell us about it. I understand that it is a very recent company (2006) and that you were teaching before that. What made you switch careers? You seem to be very good at teaching and mentoring, so I heard.

David : I taught in the Department of Communication at Seton Hall University for 13 years. It was a great career in many ways – I’m very glad I did it – but things changed. Ruby started taking over my life!

What happened was this: in the fall of 2005, I was starting a one-year sabbatical. by that time, I was working on ‘Ruby for Rails’, and was getting more and more involved in other aspects of Ruby. So, instead of taking the sabbatical, I resigned. It made sense, my interests had shifted, and the time was right to try something new. In my new career, I do a lot of training — so my teaching skills are still put to good use.

AkitaOnRails : But is your company a consultancy? Mentoring services? Development per se? What is your core business?

David : It’s training and consulting — and sometimes a mixture, when a development team wants to learn Ruby and Rails and also wants help getting started on a specific project. And I also do training through sub-contracts with training companies, as well as through my own company.

AkitaOnRails : I see many Rails-based startup-like products coming out today, like Twitter. It seems pretty obvious that Rails is well suited for rapid pace development that this kind of business requires. But do you see the big iron companies seeing the advantages of Rails? As a consultant do you do Ruby or Rails related business for this kind of company?

David : I’ve done training and consulting at some large firms, though it’s often because they want to develop in-house tools, not necessarily public-facing applications. It’s hard to say exactly what type of company will end up embracing Rails. I suspect that many won’t — but a lot will. I guess that’s a fairly safe prediction.

AkitaOnRails : And how was the Ruby career before Rails? Was it a niche-kind of solution, or did many companies use it?

David : Lots of people used it for lots of things, but it was definitely not huge outside of Japan. It was significant, and growing, but still relatively small. Rubyconf 2004 had about 65 people… and Rubyconf 2005 had 200. That gives you some idea but the Pickaxe, in 2000, was certainly also a huge force for Ruby.

AkitaOnRails : I inquired Chad about this, but some people see Ruby 2.0 almost as ‘vaporware’, on the same level as Perl 6. On the other hand, for example, we see really fast development in the JRuby side. Do you think Ruby is walking slower than it could? (sorry Koichi) Or is Matz just being careful and true to its original direction? What do you see in the future for the platform?

David : I don’t think it’s vaporware — it’s just a big project, and they’re doing it very carefully. The jRuby stuff has Sun behind it, of course, so it’s getting a big boost.

It’s impossible to predict, of course, but I think we will see a big 1.9 version by the end of the year, as Matz has said, and then 2.0 fairly soon after that. But who knows?

By the way, you might find it interesting to look at some of the talks from early Rubyconfs. He doesn’t have 2001 but he has the others. You’ll get a great look at the kinds of things people were doing with Ruby in those years.

AkitaOnRails : I will definitely take a look, and it’s a great recommendation for our readers. And do you follow the 1.9 development closely? I mean, the official mailing lists and so forth? Have you ever been in Japan? How different is the development culture around Ruby and, for example, around Rails?

David : I’ve never been to Japan, though I’d love to go. I really don’t know much about Rails in Japan. As for Ruby, it’s very interesting: a lot of the japanese Rubyists speak english and participate on english-language lists and conferences, but of course a lot of them don’t — so there are certainly aspects of Ruby culture over there that are inaccessible to me.

As for 1.9: I don’t follow it as closely as I should. I compile it now and then to have a recent one available, but to be honest 1.8 and Rails are keeping me very busy!

AkitaOnRails : I think Matz and DHH are very interesting personalities. Being Japanese myself I can understand Matz and his careful evolution around Ruby. And being raised in the West I can understand DHH’s rants and ‘opinionated’ stuff. This community have very interesting and conflicting founders. What do you think of our current community, do you follow all the new developments? Gems, plugins, and so on?

David : Well, that’s several different questions (community, plugins, gems) I love our community. I love it for many reasons, but mostly because I think people are really nice and very interested in what others are doing.

AkitaOnRails : I meant that many of the developments do reflect the characteristics of their authors. WhyTheLuckyStiff for example.

David : Yes, definitely — we have lots of people with interesting backgrounds (like musicians) and styles. By the way, have you ever seen this picture ? That’s from Rubyconf 2002. It’s all the japanese Ruby books that were in print at the time. Masayoshi Takahashi brought them over (creator of the Takahashi Method for presentations).

AkitaOnRails : I didn’t know about this particular picture. Very nice.

David : Yes, we were all blown away! “So it really is big in japan!”, we realized.

AkitaOnRails : Haha. For me, I am very proud that at least in the US, Ruby has grown very fast and strongly. But I do have a small fear that its another bubble. Many say that Ruby could become the next Smalltalk.

David : It’s not. It’s the first Ruby. People are always trying to figure out what Ruby “really” is. A new Perl, the next Smalltalk, a Lisp dialect, Python with ‘end’ statements….. it’s just Ruby. It has a style all of its own.

AkitaOnRails : As Ruby became famous overnight, it got exposure. And now some elephants in the room may become issues. I see complaints that one of these elephants is the over reliance on C development inside the core Ruby libraries. Are we going to see the core libraries rewritten in pure Ruby? Do you think it even matters?

David : I wouldn’t say it was overnight …

AkitaOnRails : You’re right, I meant, after the Rails stuff.

David : It’s interesting — there have been several attempts to write Ruby in Ruby over the years. I think that would be good, because it would make it easier to write implementations. I’m not sure how close anyone has gotten. I haven’t followed those developments very much recently. a lot of it is fairly easy, but of course not all of it.

AkitaOnRails : Yes. Today I see Charles’ JRuby and Evan Phoenix’s Rubinius. Have you ever tried them?

David : I’ve looked at jRuby a bit, and I’ve followed the Rubinius story (from its days as Sydney). I think they’re both really interesting projects, and it’s great to see that kind of work going on.

AkitaOnRails : At least here, in my home country, Java is the bread-and-butter of every professional programmer. People learn it at college. For me and for veterans like you, there was once a time when we just learned and hacked into stuff. “Hey, look at this piece of code, looks nice”. I learned a lot of languages, concepts and so on and so forth in the last 20 years. But today I see many kids just thinking “what can give me a better career?”. And just that. I’m not trying to be an idealist – as Chad said, it’s about economics – but don’t you think people in our area should try to enjoy what they do a little bit more? How does it work for you?

David : Well, I’m in a great position at the moment: I took my hobby and turned it into a career. I think the ideal thing would be for people to use tools, especially languages, that they enjoy. But of course people can’t just say to their boss, “we’re using Ruby now!” Hopefully people who use Ruby, as their careers continue, will be in a position to create more and more opportunities for others.

By the way, I agree about the ‘what can give me a better career’ thing — and it’s not just in computers. When I was teaching college I saw the same thing: students were less and less interested, I believe, in academic study for its own sake. They only wanted pre-professional training. So even trying to teach them, for example, media history could be difficult, because they couldn’t connect it directly to a job credential. I sympathize; it’s definitely hard to get jobs, and people are worrying about it at younger ages.

AkitaOnRails : I don’t personally like the concept of Software Factories: I think of software development more like working on a painting. You can use some help in the laborious activities, but the painting is very tied to its painter. Software development became very complex, very expensive, and managers want to break things down to individual tasks and roles. So, no single programmer is held responsible for the whole. I think that platforms as Ruby provides a way to take away some of this complexity and bring the software back to the developer. What do you think about it?

David : I think that’s possible, partly because working with Ruby is typically so productive — so a single person, or a small team, can come up with something quickly that has real functionality. At the same time, I don’t think a language can, on its own, change the development culture. But perhaps it can attract people who want that culture to change, and it can facilitate the change. It also depends a bit on what’s going to happen later; the code has to be maintainable, of course, and not only by one person!

AkitaOnRails : So, what can we expect from RubyCentral? You already have RailsConf US and EU. Have I heard of India? Maybe Latin America?

David : No specific plans yet but it’s not impossible. Last year we started our Regional Conference Grant Program. and there are now a lot of regional conferences…. though they don’t all have grants from us. Sometimes they ask us, and we agree, but then they get lots of sponsorship money so they don’t need us any more. But we certainly encourage and try to support regional events. It’s much better than just having one or two that try to do everything.

AkitaOnRails : Is it a kind of sponsorship program?

David : Yes

AkitaOnRails : US-only?

David : No. We supported EuRuKo (the euro conf). The only main rule is that the event really has to need the money. That’s why we don’t fund them if they have money from sponsors.

AkitaOnRails : So, It was a great pleasure talking to you. By the way, I am amazed about how kind everyone from the Ruby/Rails community is. I contacted many people and they were all very receptive. That’s one thing I like about this community.

David : Yeah, it’s a nice bunch.

AkitaOnRails : So, thanks a lot. Glad to talk to you.