While I was interviewing Zed Shaw (you can read the interview here), he said a lot of good things about Luis Lavena, who’s been doing great work for Ruby on Win32 systems.

Since I don’t know much about Ruby on Windows (other than it often being seen as a second class citizen), and even less about Luis, I wanted to talk with him about what he’s doing and how it’s going to help Ruby. A short email exchange quickly grew into a great conversation that I wanted to share with you.

Luis, how did you find your way to Ruby?

Luis Well, found by first time ruby around 1999, when looking for portable languages (Windows and Linux) to migrate our desktop-only solutions.

Found it stylish, clean, descriptive and natural. At that time Ruby didn’t offer an ORM and web framework, so we couldn’t use it as a platform for that project. After a bit of analysis we opted for Python — Zope.

Still, we used a lot of ruby internally (first plain scripts and later Rake) to build and automate all our process here.

We required a change of vision near end-2004 and started looking for alternatives. Heard about Rails and that was powered by Ruby. We didn’t watched the screencast, jumped directly to do a ‘gem install’ and start playing with it. Later, we found the screencast, but we fell in love with Rails without even watching it.

We started the process of migration our solutions to Ruby (and Rails) in mid-2005 — a path we don’t regret at all.

I love Rake, so I’m glad to see that you use it too. Can you give me some examples of how you’re using it?

Luis For lot of things: compiling and linking our applications and libraries (we use mostly FreeBASIC and a bit of VC); tag them into subversion; package them with installer scripts and tools; generate binary deltas of these files with previous versions and upload them to our auto-update server.

In order to appease our thirst for testing with static types languages, we have created a few tools that mimic Test::Unit from Ruby (Have I mentioned that we love Ruby?), and run these tests from Rake before we commit changes or ship the applications.

When we find that we’re repeating a step by step procedure, we create a Rake script instead. We even use it to customize our Windows XP deployment at office, integrating fixes and generating ISO images.

You guys are using Ruby and Rails for production work, yet a lot of people say it’s not ready for the enterprise. Are they wrong? What makes it work for you?

Luis Hmm, Production and Enterprise — we hear a lot of things about the two.

I’d like to describe both terms from my point of view (because both are subjective). We call something Production-ready when it is stable, predictable and could be *shipped* (as a product for
vertical markets). Different applications will have different needs, so a production environment for one company is not the same another.

From the start we analyzed the Ruby deployment options for our projects, just as we have for other frameworks and tools.

• Plain WEBrick and its memory leakage is a no-no. Even the GC of Ruby (1.8.4) is not good for production.
• FastCGI is obsolete and unstable. Based on that, someone could mark RoR as a toy instead of what it is, a powerful tool.
• Mongrel is a mix Ruby and C that does its job, and does it well.

The big Enterprise word is often used with Java, where everything must be BIG so big companies spent thousands of dollars on licenses. For me, Enterprise means “a product that could SCALE well”. Nothing in the IT world is written in stone. So requirements change over time. The cost of responding to these changes should be minimal and not require downtime.

Ruby and RoR are a good solution, you just have to know the platform. A lot of criticism around RoR came from people that played with it after watching the screencast — no serious analysis, no work in production, no optimization, nothing. To ask in the air will have empty answers.

For us, Ruby on Rails (RoR) lets us build fast, clean (especially clean) prototypes within hours or days, not weeks or months. Then we can move from prototype to final product within weeks, even for big projects (like migrating a whole application from Zope to RoR).

I could say that Rails, and Ruby, do their job, do it well, and in an elegant way.

Most of your work is on Win32 platforms, how much does this affect your view of Ruby and Rails? (Or your use of it?)

Luis We are forced to use Windows due to special hardware requirements (the cards we use only have drivers for win32).

Using Ruby is kind of difficult, there are a lot of solutions on the *nix front ranging from load-balancing, web serving, securing and tunneling of communications, memory caching tools, etc.. On win32 we must find the equivalents, if they exist, and integrate them with Ruby and Rails. Sometimes we need to write our own software to meet our needs.

Some developers will recommend we should use cygwin, but emulating a *nix environment in Windows isn’t productive. Native tools are the fastest and most stable solution. We already have our own bugs to trace, so we don’t want to spend time tracing bugs in something that should be considered stable.

Thankfully none of these things stopped us. But the lack of interest of some OSS developers to provide working win32 versions slow down all the process. This is a bad thing. Think about it, helping get the right support for a tool on win32 not only helps the person who reported the problem, but open the doors to other developers to try the solution. Also it broadens the user base, think about no-cost beta testers.

For example: we cannot take advantage of load-balancing from lighttpd without losing performance because it uses cygwin — use Apache for an Intranet is like using a mammoth to clean crystal glasses at your house.

One of the things Zed said about you was that you’re doing a lot of work on improving Ruby and Ruby libraries for the Win32 platform. Can you tell me about what you’re doing?

Luis To be honest, I do not believe that I’ve done a lot of work. Currently we need to cover our needs: web serving, load balancing, native win32 services, installation procedures, low level serial and usb access.

Lots of projects/libraries are so clean that including support for Win32 on them is easy. Other projects need more work, sometimes on the code view and sometimes on the developers. If it’s just code, contributing is easy. When the developer can’t (or won’t) support Win32 we have taken a radical approach — instead of forking the project, we create our own implementation.

We know this is reinventing the wheel, but instead of trying to retrofit Win32 support into some projects, we rewrite them completely to be platform agnostic as far as we could test it.

I can’t disclose too much information about these projects right know, but we will offer alternatives (and powerful ones) to other users locked in win32 environments.

What are some of the big issues with Ruby on Win32?

Luis Well, some ruby projects that use compiled C extensions lack correct makefiles or code to support win32 transparently. Thankfully the Ruby way of structuring projects reduces the number of these scenarios, but they do exist and some requires lots of hacking.

The best thing about this process is the wonderful community around Ruby — prompt answers from developers (and users) to questions regarding compilation, good practices, advice and suggestions. Even comments on bug are taken with good humor! (something that often hits programmers’ ego)

What’s the state of Ruby in Argentina and the rest of South America?

LuisTo be honest, I cannot answer that clearly. You see, most of the languages (Ruby, Python) and tools/frameworks (RoR, Zope, etc.) come from English pages, sites and communities.

Spanish-speaking developers need to handle the translation of documentation, syntax, blogs, tips, etc to be productive with the tool/language. The amount of translation required leaves developers with less energy to share/contribute with a spanish community that is just getting started.

I can’t say that users don’t try to overcome this, but the problem exists, and the average developer/programmer is intimidated by the language barrier.

So, Ruby in Argentina? Well, I’ve found a few developers to share it with. My personal belief is that the need (or hunger) for new languages and technologies should be stimulated in college/university (at least should be here in Argentina). Something that will take a few years to produce results.

What are your 5 favorite libraries/frameworks for Ruby (whether in the standard library, or off the ‘Net)?

Luis Tough question. In no particular order:

• RubyGems, for providing a standardized distribution way.
• Rails, well, no need to tell why is my favorite, right?
• Rake, task :solve_everything do one_step_at_time end
• Mongrel, for offering good and simpler alternatives to our problems.
• Fire-Ruby, for good access to a powerful database engine.

What’s next for Ruby?

Luis Get YARV stable, then a JIT-compiler to get fast native speed.

What’s next for Ruby on Win32

Luis RubyCLR as the tip of the iceberg regarding ruby and win32. The door it opens into Windows is attractive for any developer wanting cross-language tools (C#, BOO, others) from Ruby side.

What’s next for Rails?

Luis I really don’t know, I can’t think of a specific feature! So far, it solves 145% of our problems.

What’s next for Luis?

Luis Still lot of work to be done, but hopefuly later this year we will release our main product, infoBOX, on two platforms: Windows or Linux, 100% compatible, even between them. After that, vacation!

---

Luis Lavena is 26 years old, and a native of Tucuman, Argentina. He specializes in digital & professional video, from camera to bits, as consulting partner for cable networks and TV stations with his company Multimedia Systems, a developer of software and hardware solutions for broadcasters.

Pat Eyler is an Infrastructure Engineer for the LDS Church by profession, a Ruby geek by choice, and a writer by night. He enjoys reading, cooking, spending time with his family, and helping to build the Ruby community.