FiveRuns Blog

In this week’s Rails TakeFive, we’ll take a slight departure and offer up a podcast interview with James Cox, founder of smokeclouds, a UK-based Ruby on Rails and scalability consultancy and contributing editor to InfoQ and Todd Barr, VP Business Development at FiveRuns. In this podcast, James and Todd discuss some of the challenges with working with Rails, talk about some of the missing pieces, and draw upon their experiences with open source projects to opine on the future of Ruby on Rails development.

Rails TakeFive with James Cox and Todd Barr

James Cox is the founder of smokeclouds, a UK-based Ruby/Rails and scalability consultancy. He focuses on the architecture and usability of web applications. He has wide-ranging experience diving into legacy code, helping small sites bloom into big trees and generally trying to stay out of the way. Lately, James has been focusing on getting to grips with best-practice techniques with performance testing and trying to define the right ways to know if an app can grow.

Todd Barr joined FiveRuns as VP of Business Development from Red Hat, where he built and grew the partnership and certification programs for ISVs, achieving over 1000 certified applications for Red Hat Enterprise Linux in the first two years. In his most recent role, Todd’s team was responsible for building Red Hat’s global go-to-market campaigns, along with channel and partner marketing. Previously, Todd was with the corporate venture capital group at Dell and was an early sales and marketing employee at CitySearch.com (now part of IAC). Todd blogs about open source, marketing strategy and closed-loop marketing at marketingfree.typepad.com.

Yes, we already live here!

via Hugh MacLeod.

I wrote a block of code the other day that had to do with authentication. The use case is that sometimes users authenticate by email and password, and occasionally (in the case of a forgotten password or first login) users can authenticate with a token that is sent via email allowing them to change their password.

So this is what I wrote:

def authenticate(email, password)
  ...
end

def authenticate(token)
  ...
end

and then I tried logging in with an email and password. Oops! The Ruby veterans are out there laughing at me. There is no method overloading in Ruby.

I guess my initial reaction was disbelief. Coming from .NET, overloading methods is something you do just about every day. On one hand, it makes perfect sense not to have the feature in Ruby because method overloading and typing of method arguments are very closely related, but on the the other hand, I am only talking about a variable number of arguments, which has nothing to do with typing.

Here is what I ended up with:

def authenticate(*args)
  if args.size == 1
    ...
  else
    ...
  end
end

It’s not the prettiest of solutions. Here is another way, where args is a hash:

def authenticate(args)
  if args.has_key?(:token)
    ....
  else
    ...
  end
end

#usage
authenticate(:token => 'zA3sDV')
authenticate(:email => 'foo@asdf.com', :password => 'password')

I am definitely thinking that the second way is cleaner. I better get going, I have some code to refactor ;-)

We spread our wings again this week and head to Barcelona for a Rails TakeFive interview with Xavier Noria, noted author, lecturer, co-founder/CTO of ASPGems, and one of the most significant members of the dynamic languages community in Spain.

FiveRuns: Welcome Xavier, and thanks for taking the time from your busy schedule to share your thoughts about Ruby on Rails. To start, what was your first “ah-ha” moment with Ruby on Rails and when did you know that the framework was a good fit for you?

Xavier Noria: Writers say the first sentence of a book is the most important one. It delivers a promise, a first impression, it creates expectations.

For me David’s screencast was a first sentence like that. The point of the screencast was not scaffolding, any developer knew that part of the demo was just automated code generation, the point was details here and there that were interesting enough to suspect there was something into it.

By then I was working in a Java-based software company, though I had already been around dynamic languages for a few years in my spare time. We talked about Rails with Madrid-based enterpreneur Agustín Cuenca and he thought it was worth giving it a try as well. So we got a project, an application to manage salesmen commissions for Svenson. That was 2005.

I did an immersion, working hard alone and reading AWDwR from cover to cover along the way. And once I was able to see the whole picture I knew for certain Rails was, indeed, a breakthrough in web development: best-practices came built into the framework, the application was trivially well-structured, zero configuration, transparent persistence, LOCs and timeframes were amazing and delivered with quality, the application source code was beautiful, we could easily adapt to project changes… we got a list of clear benefits validated by our own experience.

The proof of concept was so good that I quit my job and founded ASPgems with Agustín and other partners.

FiveRuns: Tell us a little about the Rails community in Spain. What you love about it, how it is grown, and what challenges the group sees ahead of itself, in both the near and long term.

Xavier Noria: Juanjo Bazán talked in a previous interview about the Spanish community as a whole.

More closely, there are several companies working in Rails in Catalonia, such as Moterus, Tractis, Linqia, Railes.net, we ourselves ASPgems (we are distributed, some over here in Barcelona, Madrid, Valencia, and Logroño), as well as freelancers like Simon Moore, or Francesc Esplugas to mention just a few of them. Quite healthy and growing.

In Barcelona we knew each other through, you know, mailing lists, dinners, conferences and such, but now there’s a Rails user group. We have a monthly meeting at Linqia where we get together, chat, and have a talk or two. Good stuff.

We are working on Barcelona’s candidacy for the forthcoming Euruko 2009 with the aid of people from all over the country.

FiveRuns: Best of luck on that. Barcelona is amazing in the Spring. Let’s switch gears a little and talk about projects. What is the coolest and/or most innovative Rails project that you have seen in recent memory?

Xavier Noria: There are tons of modern websites built on Rails. As of this writing take for example Github or fire eagle as recent and relevant work.

In a more pragmatic view I think doc-rails is an excellent proposal for agilizing the maintenance of the documentation. That’s crucial in my view because, you know, everyone checks http://api.rubyonrails.org. I go there everyday! And everyone tries to understand the source code.

The current published and internal documentation are useful but need some love, ranging from better coverage to consistent typography and style. Now if you are motivated and qualified to work on it you have a more efficient way to contribute than regular patches. Please check Pratik’s original announcement if you are interested.

And as for companies, Obie’s Hashrocket is certainly something innovative. I wouldn’t call it recent in Rails-time, but well recent enough :-). The idea behind the company is brave and original. I wish Hashrocket the best.

FiveRuns: In his RubyConf 2007 Keynote presentation Matz stated that “The suits people are surrounding us” – is this increasingly the case with the community, and what does this mean for the future of Ruby?

Xavier Noria: Ruby is an open source project driven by its community, and Matz is its creator and language designer. That’s what matters to me.

I love to see suits around, the same way I love to see alternative interpreters, better libraries, new web frameworks, positive book trends, etc. It means Ruby is getting mainstream as a dynamic language. I don’t really care about the popularity of the tool I like, but a richer ecosystem is a good thing, so that’s welcome.

FiveRuns: Do you have any secret techniques, tools, or other Jedi strategies that you can share with our readers?

Xavier Noria: Be passionate about what you do. That’s the real driver. If that holds everything follows.

Well, being passionate is not something you can develop for any given topic, so I’ll say it the other way around: try to work on something you are passionate about.

Now, if your choice is programming in Rails, read books, follow blogs, watch screencasts, everything. Rails is big and evolves at a fast pace, try to keep up-to-date as much as possible. Contribute to the community, help people who are learning, share tips, share code, share experience, learn from other’s work. Read Rails source code.

I think programming is like any other area in life where you need to study and practice such as in playing tennis, chess, pool, piano, whatever. Study and practice. Try to be as proficient as possible in Ruby, JavaScript, CSS, HTTP, everything relevant to what you do. Read their musts. Master your tools technically, and use them to internalize them.

Learn other programming languages, other frameworks, other paradigms. You can’t be an expert at everything but it will give you a healthy perspective.

Be ready to look at your work from the user’s view, no matter if she is the end-user of a website or a developer using your library. Put yourself in their shoes. Forget how clever your program design is, forget the cool trick you figured out to be able to provide that feature. It’s not about you or your code, it’s about the user.

Xavier Noria studied math, worked as a proof-reader of math textbooks for six years and then switched to the software industry. He joined the R&D department of iSOCO and has loved dynamic languages since he read the Llama book in 2000. Xavier is a CPAN author and president of Barcelona.pm. He teaches dynamic languages at the University of Barcelona as a part-time lecturer. Xavier co-founded Rails software company ASPgems in 2006. He has contributed some humble bits to Rails, is a committer in doc-rails, and author of the plugin model_auto_completer.

One of the most exciting technical posts I’ve read recently is this post from Ezra on his GitHub fork of the Rails source. In this branch, he’s built in Rack adapters for a number of web servers and he’s given some serious love to ActionPack, speeding up request handling by trimming cruft and moving a number of parallelizable operations out of The Rails Mutex. I think that this post of his is particularly important for several reasons, one of which I’ll highlight here (I’ll save the others for later blog posts).

As software development projects advance from fledgling napkin sketches to production deployments, bits and pieces are invariably distilled into standalone libraries or components of some kind. These libraries have substantial test suites that always rake green. They’re proven. Reliable. They become known quantities that you don’t ever need to touch because they don’t ever break.

And so, over time, they become black boxes.

However, all sizable projects…heck, even small projects…amass some code cruft over their lifetimes. When a product’s codebase gets sufficiently large, developers who know about its warts naturally start salivating over the prospect of rebuilding it from scratch. The Rails source is not exempt from this reaction. Over time, members of the community have responded to deficiencies in the Rails internals by either contributing to the framework directly or by building out alternative platforms.

Ezra’s progress in his fork of Rails is, imho, an example of how to beautifully bridge these two approaches; he saw some issues with the framework, he worked on producing an alternative (Merb), and now he’s rolling his improvements back into Rails. In doing so, he’s taking a surgeon’s knife to some of the Rails black boxes, breaking them open and breathing new life into components that we normally just don’t touch.

I find that mindset inspiring: Nothing is above reproach. Take a deeper look. You can make it better.

Here at FiveRuns, as the dev team continues to add capabilities to our Manage product, we’re eating our own dog food, monitoring our production boxes with our own software. It’s giving us tremendous insight into all aspects of our service, and has enabled us to target the issues in our own black boxes.

FiveRuns developer Adam Keys joined Jason Seifer and Gregg Pollack in this week’s Rails Envy podcast. Tune in and hear the guys talk about git-me-up, Ezra and Rack, and more.

I got a shock last week when I tried to write a simple bit of Array initialization code in Java. I couldn’t remember how to do it. This may not seem awful to you but I worked professionally with Java for 11 years until last year. I prided myself on my depth of knowledge in J2EE minutiae. Sure, I purposefully switched focus to Ruby last year but to lose my Java skills just 8 months later seemed ludicrous at first glance.

However in retrospect, it’s not surprising. A language’s syntax is somewhat arbitrary: for 100 different programming languages, there’s 100 different ways of declaring a method. Semantics is not Syntax. Interface is not Implementation. In 10 years, I’ve learned loads about crafting good software (data structures, algorithms, patterns, architectures, etc) and plenty of system-specific knowledge which will be resume dead weight in 10 years (need someone with ATG Dynamo 4.5 experience? Call me).

My point is this: take care to keep the deep semantic knowledge you gain while designing and developing software. These fundamentals of software engineering will serve you well for decades. Don’t fear the loss of syntax and other ephemeral knowledge. This type of knowledge is capricious; to hold on to it longer than necessary is a waste of mental energy. Times and systems change, and so must we.

I always get a kick when someone I’m working with is able to simplify their work to the point of reducing the amount of code to get as much or more done. I don’t know about other fields, but it’s a interesting case that in software development – less is often more (pardon the worn cliche). It may be counter-intuitive to some, but it actually makes a lot of sense when you look at the bigger picture. Assuming you keep the essence of what the product is supposed to do in-place, then reducing the total amount of code actually frees up the mental cycles of all the people involved the development and release of a product. Some of the finest developers I know get all proud when they’re done and there is less code than when they started!

While I’m certainly less qualified to say this, I think there’s similar forces at play in the user experience of a product, i.e. when the user flow is simplified but accomplishes the same thing. I don’t know for certain that it’s always good – but intuitively it seems as if it is.

With a long interest in psychology, I’ve noticed that changes like this, whether in code or in user experience, appear to me to follow a similar ‘cognitive pattern’, i.e.

• first you understand the material – e.g. existing code, tests, what the user’s goals are
• then you develop counter-examples – e.g. alternate implementations, designs, that are close to what is needed
• then you transcend & include to form a new result – e.g. take some new approaches / ideas and include in what’s necessary from the old.

In the software space, there are some solid approaches to enable this, e.g. test driven development, which enables this same pattern by letting you carry forward the tests that apply to the old while you blend in some new. However, in the user experience space the approach is more subjective and therefore subject to interpretation, i.e. I’ve have never seen and don’t expect to see an automated test for the qualitative aspects of user experience.

As we have been working on our new version of FiveRuns Manage, we have found and taken advantage of a number of opportunities to apply this idea – to reduce the amount of code, to simplify both technical and user experiences. These small moments of moments of elegance are part of what make the work rewarding.

Welcome to this week’s Rails TakeFive interview, our continuing effort to bring together Ruby and Rails aficionados from throughout our community to share their thoughts on all things RoR. This week, we’re happy to be talking to Michael Slater of BuildingWebApps.com. A project of Collective Knowledge Works, Inc., BuildingWebApps.com creates platforms for organizing and sharing the knowledge of a community. The first community upon which they have focused is their own: Ruby on Rails developers.

FiveRuns: Welcome Michael, and thanks for taking the time to join us. Let’s start by talking about your introduction to Ruby on Rails. What was your first “ah-ha” moment with Rails and when did you know that the framework was a good fit for you?

Michael Slater: I was leading a research group at Adobe in mid-2006, working on a variety of photo management and sharing projects. The developers I was working with were experienced Java folks, and they began talking about how much more productive they could be with Rails. That got my attention, and we started a Rails project. Unfortunately, it was not a good fit for Adobe’s conservative mindset, and neither was I. I ended up leaving Adobe to dive into Rails myself, and went back to coding after 15 years in management. It was a lot of fun. Rails was a perfect fit for my desires as an independent developer.

A few months later, one of my Adobe colleagues, Christopher Haupt, also left, and the two of us founded Collective Knowledge Works, Inc. We’re building a new platform for building web sites that are focused on serving a community of people with a specific interest. It’s a combination of content management and community, with some extra twists. Ruby on Rails has been a perfect fit for our needs; it enables us to build and iterate quickly.

FiveRuns: So in your work at Collective Knowledge Works, you have been exposed to a pretty wide range of Ruby on Rails developers. What would you say is the coolest and/or most innovative Rails project that you have seen in recent memory?

Michael Slater: I think MicroPlace is pretty exciting. It enables anyone to support small businesses in the third world in an efficient way. This is a really interesting way for us to use some of our western affluence to help others who live in much more difficult circumstances but share our entrepreneurial spirit. It’s very nicely designed, and it’s also interesting that it’s owned by eBay. So it’s an example of Rails getting some traction at one of the largest “old” web companies.

FiveRuns: Where do you go for Rails-related news and insight? Any particular website, blogs, forums, etc. that are of particular value?

Michael Slater: If I can be forgiven a little bit of self-promotion, the resource I use the most is our own site, www.BuildingWebApps.com. This is built on our Collective Knowledge platform; we’re using it both to give back to the community, and to provide a proving ground and exploration vehicle for our technology. We aggregate the best content from all around the web, as well as publishing our own original articles, podcasts, and screencasts.

There’s a lot of great blogs in the Ruby and Rails world, and I read a lot of them. Part of our goal at BuildingWebApps.com is to tag and rate the posts from these blogs, to provide a more organized, central resource. I like Peter Cooper’s rubyinside.com for general Ruby information. For Rails, I always enjoy Jamis Buck and Michael Koziarski’s writing at therailsway.com. Other blogs I get a lot of value from include Jay Field’s blog.jayfields.com and Josh Susser’s blog.hasmanythrough.com. The Rails Forum site is also a great resource.

FiveRuns: Is Rails still waiting for its killer app, or are we already there with Basecamp, Highrise, Twitter, Hulu, Revolution Health, and of course BuildingWebApps.com?

Michael Slater: I don’t think the killer app concept really applies here. We don’t need a killer app to drive adoption of the platform—there’s thousands of smaller apps that prove the value of Rails.

That said, it would be helpful to have a “big hit” that was built in Rails, something that was one of the ten or twenty highest-traffic web sites. The lack of such a site is one thing that feeds the skeptics and gives pause to some companies considering Rails for projects that they dream of reaching these kinds of volumes. It’s not so much a killer app that we need as much as a proof of Rails’ ability to scale to very high traffic levels. I have no doubt it will happen; it’s just a matter of time.

FiveRuns: There was a great article recently on the Rails community in Austin and the Austin on Rails user group specifically. Are you part of a local user group? Tell us about your local community, what you love about it, how it is grown, and what challenges the group sees ahead of itself, in both the near and long term.

Michael Slater: I live in Sebastopol, an hour north of San Francisco in beautiful Sonoma County, and creating a developer community up here has been challenging. I ran the North Bay Ruby User’s Group for a year, and it’s been hard to get enough attendees; we haven’t quite been able to reach critical mass. Our big local tech center is the headquarters of O’Reilly Media, and they’re almost entirely a Perl and Python shop. But I have met a couple of great people through that group.

Occasionally I make it down to the San Francisco Ruby User’s Group, and I’ve found it to be fun and useful. That group is large and vibrant, with most meetings hitting the limit of the meeting space. It’s great to see what other people are building, hear some war stories, and swap ideas. It’s also nice to meet people in person who I’ve met via email, or whose blogs I’ve been reading.

Michael Slater is President of Collective Knowledge Works, Inc. He is an entrepreneur and software developer with 30 years of experience creating innovative products. In addition to developing and managing BuildingWebApps.com, he operates BoatingSF.com, a resource for boating on San Francisco Bay.

Michael was previously Director of Technology Strategy at Adobe Systems. He joined Adobe when it acquired Fotiva, a venture-funded startup he cofounded to create a better user experience for consumers moving to digital photography. Fotiva created one of the first tagging-based products for organizing photos. Prior to Fotiva, he was President of MicroDesign Resources, where he created the Microprocessor Report newsletter and the Microprocessor Forum conference. From 1987 through 2000, he published hundreds of articles on computer technology and presented dozens of seminars and conference keynotes. Michael began his career as an R&D engineer at Hewlett-Packard and was an independent engineering consultant from 1980 through 1987.

Michael is the author of several books, including Organize Your Photos with Photoshop Elements 3.0, The Photoshop Album 2.0 Book, RISC Microprocessors, and Microprocessor-Based Design.

What Books Do Great Ruby/Rails Developers Read?

Which ones do they recommend? Which ones do they bring to work, share with their team or ask to have purchased for the office? What’s on the rest of our staff’s reading list? Well, I’m the guy that buys them for FiveRuns, so here’s a snapshot of our bookshelf.

Programming Ruby: The Pragmatic Programmers’ Guide by Dave Thomas and Andy Hunt
The Ruby Way by Hal Fulton
The Rails Way by Obie Fernandez
Deploying Rails Applications by Ezra Zygmuntowicz, Bruce A. Tate and Clinton Begin
Best of Ruby Quiz by James Edward Gray II
The Ruby Cookbook by Lucas Carlson and Leonard Richardson
The Ruby Programming Language by D. Flanagan and Yukihiro “Matz” Matsumoto
Agile Web Development with Rails by Dave Thomas and David Heinemeier Hansson
High Performance MySQL
The Wisdom of Crowds by James Surowiecki
Design Patterns in Ruby by Russ Olsen, with Forward by Obie Fernandez
The Cathedral & the Bazaar by Eric S. Raymond
Winners Never Cheat by Jon M. Huntsman
Pulling Strings with Puppet: Automated System Administration Done Right by James Turnbull
Advanced Rails by Brad Ediger
Ruby for Rails: Ruby Techniques for Rails Developers by David Black

So which are we missing?