bgror

How Santiago Pastorino Went From Ruby Newbie to Rails Core in 2 Years »

Created at: 08.10.2010 05:14, source: Ruby Inside, tagged: Interviews

Just a month ago, David Heinemeier Hansson welcomed Rails' newest core team member, Santiago Pastorino. Strikingly, Santiago only started to contribute code to Rails earlier in the year and it's not every day that DHH is trumpeting someone else's productivity, so I had to catch up with him and learn his story.

When did you first get into Ruby programming and how did it occur?

I started around mid 2008 when I decided along with my friend José Costa to start our company WyeWorks. I wasn’t deeply familiar with Ruby and Rails at the time since we had to do a bunch of stuff to keep the company alive and focused on what we already knew.

We both came from the Java world but we started to tire of it and felt we needed a change so we analyzed what we thought were the more productive and fun technologies to work with. At that time we felt attracted to Ruby on Rails as well as Python and Django. José had the chance to work a bit with Rails so we took that experience plus a brief study of other alternatives and finally we chose Rails for its elegance. As we started building projects for clients, we got more and more attracted to it and that’s how we finally decided that we were going to focus 100% in Rails development.

Other than Rails, what are some of your favorite libraries, tools, or gems?

Rubinius - it's awesome, I'm actually using it in development. Sinatra as a lightweight Web microframework is impressive. As a JavaScript framework I like JQuery, but I want to take a look at vapor.js which sounds interesting ;-) Then DataMapper, Devise, Bundler, RSpec, Cucumber, Webrat/Capybara, and Nokogiri my favorite gems.

You recently joined the Rails Core team even though you only started to contribute to Rails this year (2010). How did that process play out?

I started to contribute to Rails in February this year in a BugMash that was held by that time, though I've been always attracted to work in open source projects. I enjoyed working with Rails and the good vibe that I felt among the BugMash participants and the core members who jumped into #railsbridge to help. After that BugMash I kept on contributing in a fairly simple way, by running tests every once in a while and trying to fix what failed and the warnings that came up.

One day I was in the #rails-contrib IRC channel and Yehuda Katz showed up and asked who wanted to help him with a task. Without knowing what was it I offered myself and I was then presented to the first challenging task that consisted of the back porting of SafeBuffer and all the stuff related to html_safe that Yehuda had recently incorporated to Rails 3.

Excited about that task, by the confidence that the core guys gave me and the great vibe of the whole community, I kept on contributing even more tackling as much tickets as i could on LightHouse. Meanwhile I was working that way I was helped a lot and I really appreciate that, by the Core Team Members mainly Yehuda, José, Carl, Jeremy, Michael and David. Then Yehuda gave me access to control the LightHouse tickets and to the Rails CampFire. Over time I continued contributing and Aaron Patterson, who was one of the guys I bother the most to push my stuff told me that he had seen enough so he would ask Yehuda to give me commit access. That's how i got to be a committer. One month from that I was integrated to the "core."

The fact that I was invited to be a part of the Rails Core Team really surprised me. It was unexpected until I read Yehuda in CampFire saying that the guys with commit access should join the core team after the release of Rails 3 and David was OK with that. I'm very thankful for this opportunity.

As a newly prolific contributor to Rails, what do you advise to people who want to contribute to Rails but haven't done so out of fear or even not knowing what to do?

My first advice would be to start by running the tests and go through the LightHouse tickets. Believe it or not, there are so many things on LightHouse and I think it’s a great starting point. It’s not so hard as it may seem, the most important thing is to persevere. Sometimes it took me a whole day to fix some bug and stuff like the back port that Yehuda asked me to do took us three whole days because with José we were just starting and we had no idea what to do.

What are your goals going on from now? Are you planning on having a big role in Rails 3.1 and beyond?

Yes, I’ll try to dedicate as much time and effort as I can into Rails 3.1 and beyond. At WyeWorks we feel that open source (and Rails in particular) plays an important role in our business. To understand the framework in depth gives us great value and it’s another way of showing our clients what we can achieve. I'm glad that more companies like Plataforma (run by my friends José Valim and George Guimaraes) and Engine Yard are putting so much effort on OSS. So it could be awesome if more companies join this nice strategy.

IronRuby Q&A – What’s Down With Microsoft’s Ruby Implementation In 2010? »

Created at: 23.03.2010 02:27, source: Ruby Inside, tagged: Interviews Windows Specific

IronRuby is an open source Ruby implementation being developed at Microsoft with the .NET CLR in mind. It's reasonably mature and as well being a regular implementation, it provides the ability to use Ruby directly within the Web browser through Microsoft's Silverlight Flash-esque framework. Windows seems to get a bad rap in the Ruby community so we thought we'd turn the spotlight on some of the cool things IronRuby's doing nowadays.

Being based on the .NET CLR presents some unique challenges for IronRuby. So far IronRuby passes 86% of the RubySpec (compared to a 98% pass rate for the MRI on Windows) but this number is creeping up every week. To learn more, I caught up with developer Jimmy Schementi of Microsoft to ask some questions about the project and its workings.

grantmichaels: There are ~150 native extension gems for Ruby, some of which are prolific and often depended upon by other gems. Does your Ruby implementation support FFI (foreign function interface) at present, and/or how much of a priority is running native extension gems going forward?

Jimmy Schementi: IronRuby does not support the Ruby C API which extensions depend on today, and there are no plans to support it either; it’s too difficult to support 100%. However, we do have plans post 1.0 to support FFI, as native code interop from Ruby is very important to IronRuby; it'll make the implementation able to talk directly to native code when running on .NET or Mono. Keep in mind the Win32API is supported in IronRuby, so you can call Win32 functions without writing C#. Today IronRuby developers have to write some C# code which can interface with non-Win32 native code, through the platform invoke APIs, which turns out to be not any more work than using FFI would be, but it does require breaking outside of IronRuby. From there IronRuby lets you consume the C# code without an interop layer.

Passing RubySpec tests is fundamentally important for a modern, robust Ruby implementation. Has this compliance lowered the theoretical performance ceiling of your implementation considerably?

Of course, but can you think of another way? I think every language implementation will tell you that during the very early stages of development they were blazing fast, but as they got closer to implementing compliant Ruby functionality, performance suffered, or it just got harder and harder to keep the implementation at the same level of performance. But that's understandable for a language like Ruby; it puts the burden of cleverness on the language, rather than developer writing applications in Ruby.

Keep in mind though, RubySpec is not for performance testing. And while the ruby-benchmark suite is a fine benchmark suite, the most beneficial performance improvements for IronRuby have come from analyzing and optimizing actual programs, like Rails, RSpec, RubyGems, Cucumber, IRB, etc. RubySpec did play a role here, as it helped make sure we didn't degrade in compliance while using the real applications for performance tuning. Also, we have analyzed MSpec (RubySpec's test runner) on IronRuby for startup and throughput performance.

Closures, continuations, and tail-call optimizations are often discussed in terms of programming language VM's. Which of these attributes are implementable at present, which are expected to be implemented, and which are not possible by design?

Closures aren't really a VM feature, as they are just a block of code executing in a context. As the Dynamic Language Runtime is a language-implementing tool, it does support closures, but IronRuby does not use them; they are forked in IronRuby, though we'd like to put our updates in the next version of the DLR.

However, the Common Language Infrastructure does provide a big part of what a closure is; the block of code, which is called a Delegate. Delegates are essentially function pointers, though they are first-class objects in the CLR, so the can be part of a method signature, stored on other objects, garbage collected, and have any other properties that objects have. Coupled with DynamicMethods, which allow for at-runtime IL (the CLR's intermediate language) generation and conversion to delegates, IronRuby is able to directly invoke CLR code, as well as expose Ruby methods as delegates for CLR code to use.

Although continuations are not part of the ISO CLI, though Mono now supports microthreading and coroutines on top of the CLI. which allows them to implement continuations. Microsoft's CLR does not support continuations, so IronRuby does not have support for the "callcc" today. IronRuby could support true continuations only when running on Mono, but only if IronRuby users pushed for it, and even then we'd really like to avoid different behavior based on the runtime.

IronRuby does not have any support for tail-call optimization. Tail-call optimization is supported by the CLR, but it's not automatic; IronRuby must detect this and correctly emit the opcode for tail-call optimizations, and even then the code needs to fit a specific criteria for the just-in-time compiler to recognize the opcode. However, the CLR's way of supporting it is not why IronRuby doesn't support it; in real Ruby code you'd probably never see tail-call optimization happening, so we haven't seen a need for optimizing this. Tail-call optimization's main benefit in functional languages is to reuse the caller's frame by replacing recursion with a loop, rather than creating a new frame for each recursive call. In Ruby this optimization would be irrelevant if a block or proc was used in the caller, since a new frame would be required for each.

How integral is dynamic feedback-based optimization to reaching a high level of performance? Do you feel it will be possible to maintain acceptable speed into the future without embracing these strategies or are there less well-known alternatives which are potentially more effective?

If by "dynamic feedback-based optimization" you mean "inline caching", then it is very integral to performance of IronRuby. The Dynamic Language Runtime, which IronRuby uses for a target syntax tree, code generation, and interop with the CLR, uses "polymorphic inline caching", which means it caches all call signature a method encounters, turning subsequent calls to the same method (with the same signature) into a cache lookup for a delegate representing the method.

What are your thoughts on the Ruby programming language in the context of distributed programming?

As the number of processors are becoming more and more crucial to the overall speed of CPUs, Ruby needs to make distributed programming a first-class concept in the language to ensure it's continued usage in this changing computing landscape.

The Ruby language is very expressive, and I have no doubt the distributed programming paradigm will fit seamlessly into Ruby's syntax. Ruby's first-class closures and syntactic-sugar around them (blocks) are a natural way of expressing parallel operations. Also Ruby's enumerators and future features like a lazy-array provide the right tools to make parallel programming even easier.

However, Ruby does not have native thread support, so anything that will run truly in parallel will need to run cross-process. While this will work great for MRI, other implementations will have to find ways to make this work well on their platform. I see this as place where the various implementations of Ruby can step up and provide a native runtime-based way of running programs in parallel. For IronRuby, we could utilize the Parallel Extensions libraries to build any Ruby-based parallel support on-top of. In fact, these libraries could be used directly from IronRuby today. For more information about writing parallel software on the CLR, there is a detailed paper as well as a good amount of examples.

Which of 1.8.7 and 1.9.x is your implementation compatible with?

IronRuby 1.0 targets compatibility with the latest patch-level of 1.8.6. IronRuby does have a "-19" flag to enable any Ruby 1.9 features implemented along the way, but it will be disabled for the 1.0 release.

IronRuby 1.x will drop 1.8.6 support and only target the latest version of 1.9. There won't be a specific version which targets Ruby 1.8.7, but those features will probably be the first set of things implemented in the 1.x branch. IronRuby 1.0.x will be a servicing branch for IronRuby 1.0, and that branch will continue to only support 1.8.6.

Do you think further acceptance of Ruby is driven equally by spending man-hours working on performance and by meeting an international body’s specification?

As a Ruby implementer, I welcome a specification for Ruby that everyone agrees on as what makes Ruby the excellent language it is, as long as it doesn't hinder adding future features to the language. Having a specification will probably make it easier for implementations to achieve acceptable performance, because they can design their system with all the requirements of Ruby in sight.

What are your team’s goals for the next quarter, the next year?

IronRuby 1.0 will be released withing the next quarter, with the goals of improving startup significantly, getting RubySpec passing at over 95% across the board, and ensuring compatibility with popular application test suites and scenarios. We will also invest some time in taking advantage of the new features in .NET 4 and Silverlight 4, as well as a push to ensure compatibility with the latest version of Mono.

For the next year, the IronRuby team will focus on 1.9 compatibility, explore tooling options in Visual Studio 2010, and support Ruby and Windows developers to make IronRuby a premier Ruby implementation for Windows.

Besides any obvious platform niche, why might someone benefit from electing to use your Ruby Implementation?

When you ignore the platform niche all implementations of Ruby are pretty similar. In fact, it's the underlying platform that gives one flavor of Ruby advantages over another. For example, MRI has extremely fast startup compared to other flavors, but lacks the rich graphical libraries that Java and .NET have. In the end it’s all about what’s most important to the Ruby user, and in IronRuby’s case there are lots of platform-related benefits, some of which include .NET's integration into the native Windows GUI system, running Rails on Windows through IIS — along-side other ASP.NET website, running in the browser through Silverlight, and the Parallel Extensions library I mentioned earlier.

How much of an advantage is it that you aren't also responsible for maintaining the VM?

Well, for starters it's one less place we have to be responsible for bugs, though working-around any bugs is our responsibility. We don't have to worry about VM issues across different platforms, as the CLR and Mono take care of that for us. Mono is extremely fast in fixing any bugs we discover, like a matter of days, which definitely beats fixing them ourselves. From a ecosystem point-of-view, other things that built on-top of the CLR get interop with Ruby code for free, like running in the browser through Silverlight/Moonlight, and CLR-based debuggers (like MDbg, Visual Studio, and MonoDevelop).

Windows Vista and aboves with .NET pre-installed, most Linux distributions pre-install Mono or it's readily available via packages, and Mono is also easily installable on Macs. Despite that, a number of Rubyists somewhat disregard IronRuby for having any relationship whatsoever to .NET. Are they throwing the baby out with the bathwater?

I'd say so, but they don't necessarily need to "switch" to IronRuby; all Ruby implementations have their own uses. Ruby is unique in that it runs almost anywhere, giving Rubyists a plethora of tools to choose from to solve their problems, while still writing code in Ruby. In fact, this ubiquity makes Rubyists more valuable developers. As Ruby becomes a more accepted language for .NET shops to use, Ruby developers will be in high demand.

[job] Northwestern University (Chicago, IL) is looking for a Rails developer at the Feinberg School of Medicine on their downtown Chicago campus. Experience with BDD, Agile, and CI essential.

Vim For Rails Developers Screencast »

Created at: 22.02.2010 04:04, source: Rails Inside, tagged: Interviews Screencasts

Vim as a Rails IDE is a professional screencast by Ben Orenstein that walks you through using Vim (a popular open source text editor) as a Rails IDE of sorts. It costs $9 and runs at almost 37 minutes long. I asked him for a review copy and promised I'd share my impressions here.

The Good

First, Ben has done a good job producing this screencast. It's an interesting introduction to using some Rails specific addons for Vim, such as Tim Pope's Rails.vim and Michael Sanders' Snipmate, a collection of TextMate-style snippets for Vim. (You can get both of these for free and check them out without getting Ben's screencast, of course!)

The Bad

This screencast does seem to be Ben's first professional production, though, and it shows in a few ways. The screencast doesn't go to any lengths to satisfy people who aren't already reasonably familiar with Vim, and instead focuses on providing Rails specific knowledge and shortcuts to existing Vim users. If Vim is totally new to you or you can't get much beyond :q!, you'll want to give this a miss.

Given the required level of familiarity with vim, it's also weird that Ben spends the first 5 minutes of the screencast emphasizing the importance of being able to type quickly and presenting tips on how to bring up your words per minute.

But There's More Good Than Bad..

Once Ben gets on to the Vim and Rails specific knowledge, though, his style is well suited to the screencast format. The sound quality is good and Ben is very easy to understand. He avoids needless jargon and his demonstrations are relevant and concise. He covers the quick navigation of a Rails project from within Vim pretty well and also looks at using TextMate-style snippets, project level searching, and multi-line commenting.

Ultimately, there's more than $9 of value in here if you have a vague familiarity with vim and want to get a good boost along the road to becoming a "power user" when it comes to Rails. At $9 it's a fraction of the price of TextMate by any means..

The Interview

I asked Ben some questions to get a feel for the background of the screencast and his interest in Vim:

Why would you recommend vim above, say, TextMate for Rails developers?

Well, are you an efficiency junkie? TextMate is a great product, but I don't think modal editing can be beaten in terms of speed and minimal distance to done.

I do think TextMate has some great features, like its Cmd+t file finder, and snippets. However, these can and have been ported over to vim. You can replicate the Cmd+t by installing fuzzyfinder_textmate, and I cover a plugin to get TextMate-style snippets in the screencast.

What's your history with text editors, particularly with Ruby/Rails development?

I got a lucky recommendation from a friend early on, and had the good fortune of learning vim straight off. I was immediately struck by how well it was built for speed: the most common tasks were incredibly fast to perform, often requiring only a single keypress. After a year, I started writing a lot of Common Lisp. If you're going to do this, Emacs is pretty much the only editor worth considering, so I made the switch. I was amazed by how difficult this process turned out to be, and I wrote Switching Editors is Just as Hard as Switching Languages about my struggles. I loved Emacs' customizability, but I missed vim's efficiency of keystrokes.

Finally, I started writing Rails code professionally full-time made the happy leap back to vim. I wish I could script vim in elisp, like Emacs, but otherwise I couldn't be happier with my editor.

Any last thoughts?

I think it's absolutely vital that people customize their editors like crazy, and constantly refine those customizations to let them work faster. If the idea of switching editors for a week wouldn't make you miserable, you're not spending nearly enough time molding your environment. Personally, I keep my entire vim configuration (and all my other dotfiles) in a git repository. Every machine I work on has exactly the same highly-tailored environment, and I'm immeasurably more productive for it.

The screencast is a collection of the plugins and techniques that have carved out a home in my repository and a permanent place in my repertoire.

Ben's screencast can be found here.

Tweet This Post

A Video Interview With Ruby’s Creator, Matz »

Created at: 27.01.2010 03:20, source: Ruby Inside, tagged: Interviews

Ruby's creator and benevolent dictator Yukihiro "Matz" Matsumoto has done a video interview for InfoQ at the QCon enterprise software development conference. You can watch the video on InfoQ's page (or, if you're a member of InfoQ, download an MP3).

In the interview, Matz talks about what he'd do if he were recreated Ruby from scratch today, lazy evaluation, Erlang, actor models, typing, his opinions on alternative Ruby implementations, and continuations.

Matz also recommends reading O'Reilly's Beautiful Code (Amazon link) but humbly advises against reading Chapter 29 - a chapter that he contributed to the book.

[jobs] The Ruby Inside jobs board has blown up this month with 14 jobs currently active. They span from New York to Chicago, Akron, Birmingham, and Portland, so check them out if you're looking for something new to do.