FiveRuns Blog

As a company offering products for Ruby on Rails developers, we sometimes have to work through customer issues that are specific to certain Rails releases or Rails Edge commits. Among our daily work tasks, frictionless switching between different Rails versions is important.

Below, I’ll quickly outline our internal approach to his. It’s nothing groundbreaking, but I have noticed many developers using the tedious and time consuming gem uninstall rails;gem install rails -v old_version;gem uninstall rails;gem install rails; procedure. There is a better way.

As a starting point, you will need a copy of the Rails git repo. Since the Rails code base was moved from Subversion to git, it actually makes switching even quicker:

demo:~$ git clone git://github.com/rails/rails.git

Once I have cloned the repo locally, I can checkout a specific release tag or commit. Before I do this, let me highlight that I have the two latest Rails releases installed locally via RubyGems:

demo:~$ gem list | grep rails
rails (2.1.0, 2.0.3)

In this example, I need to quickly investigate a potential issue with an older Rails release, let’s say version 1.2.4. Inside the Rails repo, I checkout this specific tag:

demo:~$ cd rails
demo:~/rails$ git checkout v1.2.4
HEAD is now at 478cd82... Tagged 1.2.4 for release

Git does all this locally, so it also works offline. The local git repo contains the full Rails history back to its first svn commit.

Now that Rails 1.2.4 is locally checked out, I create an empty Rails app using this version. Once the skeleton has been generated, I manually freeze this version of Rails in into the vendor/rails subdirectory of the new application. This second step is necessary to avoid any conflicts with the Rails versions in my RubyGems environment:

demo:~/rails$ ruby railties/bin/rails ~/test124app
create  
create  app/controllers
create  app/helpers
create  app/models
...
demo:~/rails$ cp -r . ~/test124app/vendor/rails

Inside the skeleton app, I quickly verify that I’m using the specific Rails version I intended to use:

demo:~/rails$ cd ~/test124app
demo:~/test124app$ script/about 
About your application's environment
Ruby version                 1.8.6 (universal-darwin9.0)
RubyGems version             1.2.0
Rails version                1.2.4
Active Record version        1.15.4
Action Pack version          1.13.4
Action Web Service version   1.2.4
Action Mailer version        1.3.4
Active Support version       1.4.3
...

At the same time, the latest two Rails releases are still available in my local RubyGems installation:

demo:~/test124app$ gem list | grep -e "rails\|active" 
activerecord (2.1.0, 2.0.3)
activeresource (2.1.0, 2.0.3)
activesupport (2.1.0, 2.0.3)
rails (2.1.0, 2.0.3)

Now, I can happily test away with this Rails 1.2.4 app and at the same time work on my other Rails 2.1 apps – without any conflicts or RubyGems hassles. This concludes my little excursion about quickly switching between Rails versions. I hope it is useful to some.

If you are developing with Rails, please have a look at our free developer tool FiveRuns Tuneup. It helps you understand where your actions spent their processing time and where to improve performance bottlenecks during development.

Welcome to the Rails TakeFive interview series, FiveRuns’ ongoing effort to gather and share points of view from the Ruby on Rails community. This week, we’re happy to welcome three developers from TechCrunch, more specifically CrunchBase, a structured wiki project featuring technology companies, people, and investors that anyone can edit.

TechCrunch developer and recovering robot soccer addict, Henry Work pulled together fellow developers Mark McGranaghan, who recently left TechCrunch to head back to school to “graduate”, and their fearless intern Rob Olson to talk about Ruby on Rails and their use of the framework on CrunchBase.

And, just to let you know, CrunchBase is looking for Ruby developers. Just ping Henry if you’re interested!

FiveRuns: Thanks for taking the time to join us, guys! Let’s start off by talking about Rails 2.1, which was recently released with the help of over 1400 contributors. What about the new release excites you the most – time zones? Gem dependencies? UTC migrations? Better caching? And as a follow-up, what are the most important things in your mind to get done for the next major release?

CrunchBase: Time zones? Gem dependencies? Nay, we’re excited about the small things. Steadfast intern Rob thinks that Comment.last makes using Rails a little bit sweeter, especially from the console. Coming up, Henry’s excited about naming local variables inside collection partials, as well as setting conditions on join tables.

UTC migrations are great but they only resolve migration number conflicts. The following scenario has bitten us a few times:

• Henry creates a migration and runs it
• Gallant intern Rob creates a migration and runs it
• Both Henry and Rob push their new migrations to GitHub
• Henry easily runs Rob’s migration
• Rob curses and has to roll back his migration before running Henry’s

The other downside of UTC migrations is it’s less easy to find them in TextMate! Cmd-T then typing the migration number is basically muscle memory at this point.

FiveRuns: We’ve heard over and over that the GitHub community is what SourceForge should have been ;-). Now that the Rails repository has been moved over, can you talk a little bit about the benefits of GitHub and how SCM and agile development go hand-in-hand?

CrunchBase: Thanks to intrepid intern Rob, we’re now fully on Git, GitHub, and Lighthouse. Though it feels like we’ve been branching and merging with Subversion since grade school, Git’s been working out well. Mark makes a good point here about how lightweight both Git and GitHub are: you can quickly — or dare we say ‘agily’ — checkout projects and see what they’re about. And that’s probably the most important thing to us; a sleek, lightweight SCM and a power repo like GitHub allows us clone, branch, merge, and deploy faster. That time adds up.

FiveRuns: Spurred on by the recently announced Ruby Hero Awards, who is your own personal Ruby hero, and why?

CrunchBase: Ezra Zygmuntowicz – great hacker with great taste, entrepreneurial, supportive of the community that grows around his projects, fearless—like intern Rob.

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

CrunchBase: Mark, who owns the most programming books by far, will take this one:

Scheme

• Simplicity
• Elegance
• Taste
• SICP
• Functional style

Arc

• Brevity
• Discarding onions
• Challenging Assumptions

Mark also notes: “less code, in a functional style, building on and creating the right abstractions.”

FiveRuns: Beyond Merb, there are a great number of alternative frameworks for Ruby, including Nitro, Waves, Sinatra, Ramaze, and even the microframework Camping. Do you have any experience working with these frameworks? What have you seen so far that you really like? Dislike?

CrunchBase: Beyond Merb? We love Merb! McGranaghan closely follows the mailing list and is apt to say things like “that would be a perfect project for Merb.” As for the others, we are obviously excited to see/hear/read about the various web frameworks being created with Ruby. Sadly, we’ve only perused the occasional article. We’re still focused on learning as much as we can about Rails. We’re all about a year into Rails in terms of experience.

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

CrunchBase: Unflinching Intern Rob has this to say about Obie and HashRocket: “HashRocket, ultra-productive in 3 days, is a definitely intriguing. I think every company wishes they could push out that kind of productivity in three days. At TechCrunch we would like to see if their three day game plan can work for bigger projects as well. We would still be going from concept to completion in three days but completion would mark completion of one or more features, not the entire product. Basically every three days set up a game plan for three days from now. Anything that can’t be completed within three days either needs to be pushed back or broken into more manageable pieces. It would take multiple sets of 3 day pushes but it would help by keeping us focused and on a regular release cycle.”

CrunchBase is the free directory of technology companies, people, and investors that anyone can edit. It is developed and maintained by TechCrunch with the support of the tech community. Helping us out on this interview from the CrunchBase team are developers Henry Work, who joined CrunchBase to rewrite the site to its current version. Henry is a former team captain for the Northern Bites, Bowdoin College’s 4-Legged League RoboCup team and winner of the 2007 RoboCup World Championships. Also, Mark McGranaghan a student, developer, and entrepreneur who recently left TechCrunch to “graduate”. And, Rob Olson, Intern for TechCrunch and student at UCI studying Computer Science.

Our customers keep sharing their excitement about Phusion’s Passenger as a reliable and usable platform for Rails deployment. We have noticed an even increased interest after the Passenger 2.0 release at RailsConf 2008. It is great to see the community tackling hard deployment problems and pushing the status quo.

Recently, we’ve been getting more questions from customers looking to use FiveRuns Manage to monitor Passenger environments. The good news, since the initial Passenger launch we have made sure that FiveRuns Manage supports monitoring Rails applications deployed on Passenger out-of-the-box.

Compared to a static Mongrel cluster configuration, a typical Passenger environment is highly dynamic. Depending on your request load and configuration, many Rails processes get spawned and terminated. Our Rails instrumentation is aware of this quite different temperament compared to statically load-balanced Mongrel environments. Also, our per-app service pricing model translates directly over to Passenger.

From our perspective, Passenger 2.0 has improved its default configuration . For example, the default setting for PassengerPoolIdleTime is now at 300 seconds. For certain monitoring edge cases, we still recommend doubling this time-out by adding below setting in your Passenger configuration:

PassengerPoolIdleTime 600  

As outlined in our initial mod_rails post, FiveRuns Manage monitors Rails applications in dedicated Passenger installations, where you operate your own Apache environment. In these cases, FiveRuns Manage can already monitor the Apache Web Server directly via mod_status with metrics like requests per second or the number of active worker processes. Combined with the in-depth Rails metrics Manage also provides, it gives you a detailed picture of your current production environment.

For future enhancements, we’re looking at how FiveRuns Manage could leverage some of the bundled Passenger utilities like passenger-status or passenger-memory-status, which have to be executed with root privileges. We’re also investigating Rails monitoring in shared hosting environments, like Dreamhost.

If you are looking for a monitoring approach for your Passenger-based Rails apps, feel free to give our free, 30-day trial of FiveRuns Manage a try. We’d love to know what you think.

Welcome to this week’s Rails TakeFive interview, our weekly discussion about Ruby on Rails with noted developers from throughout our community. This week, Ari Lerner of CitrusByte and among other things, creator of PoolParty, a framework for maintaining and running auto-scalable applications on Amazon’s EC2 cloud.

FiveRuns: Hi Ari – thanks for joining us! Our own Adam Keys recently gave a talk at RailsConf titled Oh, the Fail I’ve Known. In the talk, Adam outlined a few different kinds of fail: learning failure (the knowledge was available but you didn’t have it), technological failure (you did have the right tool), problem failure (barking up the wrong tree), and so on. If you don’t mind, give us an example of the fail you’ve known?

Ari Lerner: The crumbling foundation fail:

We’ve all been there, the last remaining hours before a deadline and you just can’t get this one feature to work quite right, your specs are falling behind and you haven’t slept in 2 days. You figure you can hack up the remaining features before the meeting even though you know it is just a hack.

What is wrong with this approach is that those features that you implement and hack together end up as artifacts, end up staying in your code. Without a solid foundation for the feature you are constantly hacking against a poorly written weak base. Before you know it, the next crunch time is just around the corner and you are building hacks on top of your original hacks… and so it goes.

I’ve befallen this issue more times than I would like to recount. It can be a struggle, but don’t give up on best practices and the process. The application is really, in the end only as strong as your weakest line of code.

FiveRuns: Now that the Rails repository has been moved over to Github, can you talk a little bit about the benefits of Github and how SCM and agile development go hand-in-hand?

Ari Lerner: Git’s introduction into my workflow has not only revolutionized how I operate as a developer, but how my entire team works together. It is not the only distributed version control system in the world, but the power and flexibility it provides certainly makes the SCM process enjoyable.

I’ve also never felt as connected to other developers on my team as I have when working with Git. The SCM encourages discussion in a way that non-distributed VCSs cannot.

As a development shop, Github allows us to watch our commit frequencies, easily find our points of weakness, open new projects, and then share those with the world. In fact, it’s so incredibly useful that it’s replaced Google as my homepage – that’s how much I appreciate it.

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

Ari Lerner: Knowledge is never a bad thing. Derek Silvers’ public departure from Rails last year summed up my feelings about other languages simply: It’s the most beautiful PHP I’ve ever written, all wonderfully MVC and DRY, and I owe it all to (Ruby on) Rails. With that in mind, I’m constantly learning new languages and techniques, reading through others’ code, and paging through science journals for this knowledge. Amongst several other worthy contenders, the language that has impacted me the most is Prolog. Conceptually foreign, it’s a language that engages both sides of the brain. I’ve recently been writing more C/Objective-C and sifting through yacc/lex.

Ruby – possibly my favorite development language – is incredibly powerful, but it’s ultimately a programming language. I don’t think that Ruby has made me a better programmer, but it has given me the tools to make that process easier. Just as Wesley outsmarts Vizzini in the classic poison scene of “The Princess Bride” with knowledge outside of the scope of the issue at hand, using knowledge outside of my comfort zone only makes me stronger.

FiveRuns: Beyond Merb, there are a great number of alternative frameworks for Ruby, including Nitro, Waves, Sinatra, Ramaze, and even the microframework Camping. Do you have any experience working with these frameworks? What have you seen so far that you really like? Dislike?

Ari Lerner: Rails, Django, Drupal, and others are all great tools – when wielded properly. I think that developers often get mired down when trying to use their one-size-fits-all-tool-of-choice when approaching a problem, and need to think critically about these tools and how to use them. You wouldn’t bring a butter knife to fight a dragon, nor should you… so why use beefy Rails to build a video transcoder when you can use Sinatra?

I have had quite a bit of experience working and contributing to Sinatra and have had the opportunity to push several applications into production. Not only are they maintainable and self-contained, but they are fun to write! I mean, how can you hate the

get '/' do
 "This is the return response from the root body"
end

You can’t.

The trend is growing in the alternative-framework community to slim the framework down and include only what is necessary. This is a great asset for these little frameworks. I hope the trend continues and I look forward to seeing what comes out next.

FiveRuns: Amazon + Rails seems to be a prevalent choice right now,looking way back to the first instances as early as 2006, and seeing how far we have come. Can you talk a little bit about the benefits and challenges here?

Ari Lerner: Amazon’s Web Services is probably the technology that excites me the most at the moment. The unprecedented flexibility enables developers to play, explore and harness the growing landscape of cloud computing. The last time I felt the joy of working with a new technology, I was writing “Drug Warz” on my Ti-83. If you have not yet looked into it, I highly suggest you take a peek.

Now to answer your question!

Cloud computing is all the rage today. Just as Rails revolutionized the web development framework, cloud computing is the next logical step in hosting, but it’s not going to solve all hosting issues. The non-technical challenge is to recognize it is just another weapon in your development tool-belt. The developer is the real secret sauce.

The largest technological challenges are configuration and maintenance of the EC2 instances. there is software on all sides of the spectrum that can aid in automating this process that can aid in automating this process, from my own open-source PoolParty to commercial RightScale that aids in support.

Amazon’s EC2 makes it tempting to throw away proven techniques of deployment and management, but breaking the encapsulation of the methodologies just spells disaster. I am always in favor of using all the right tools available, but in their proper place.

I think it would be a mistake to have your application aware of its own hosting environment. You don’t want your software knowing it is running on a cloud, it should do what it does best… be the application.

Ari Lerner is a solutions architect at CitrusByte in Los Angeles, Ca. He is a core contributor and has been working with Rails since version 0.6. He has recently released PoolParty, an open-source approach for managing and scaling cloud-computing instances. He graduated from the University of Arizona with a degree in Computer Science and in Theatre Arts.

Welcome to this week’s Rails TakeFive interview, our weekly discussion about Ruby on Rails with noted developers from throughout our community. This week, we’re honored to be joined by Ryan Bates, the producer of Railscasts, the free Ruby on Rails screencast series.

FiveRuns: Welcome Ryan, and thanks for taking the time to join us! We’ve asked several folks recently about Rails 2.1. With over 1,400 contributors, clearly a community effort. What about the new release excites you the most? And, what are the most important things in your mind to get done for the next major release?

Ryan Bates: By far my favorite feature in Rails 2.1 is named_scope. Rails has long had the power of scoping finds, but I don’t think it reached its full potential until now. named_scope cleans up my code considerably in every application I’ve worked on.

Second, I would have to say gem dependencies. In the past it’s always been a struggle juggling gems and plugins around for apps. Now specifying which gems an app requires (and in which environments) is so easy. I can see plugins going away in favor of gems.

For the next major Rails release, I’m excited about Active Model. That’s the abstraction of various Active Record and Active Resource functionality. This would, for example, make it easy to add validations to custom models which don’t have a database back-end.

FiveRuns: Some have said that the GitHub community is what SourceForge should have been! Now that the Rails repository has been moved over, can you talk a little bit about the benefits of Github?

Ryan Bates: Wow, I’m glad you asked this. GitHub has improved my coding more than any other tool recently. Not only because it introduced me to Git, but because it brings the social aspect into coding like never before.

There’s a saying that goes something like this. You should program for people first, computers second. It’s easier to go the extra mile for readability when you know others may be watching.

Also, one of the best ways to improve your own code is to read other code. GitHub makes it easy to follow master programmers and learn from their code.

On top of all this, it makes coding more enjoyable. Now I look for excuses to code because it’s so much fun to put my project on GitHub and share it with the world.

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

Ryan Bates: While not necessarily a language, I have been learning a lot more about the command line and specifically Z Shell (zsh) lately. Here is a tool I use every day, but never made the most of until recently. Once you know what commands you have available, it’s amazing how much can be done by just piping a few of them together in the shell instead of writing a 20 line Ruby script.

I find Ruby and the command line work well together too. Working with files can get a little clumsy in Ruby. Now I sometimes call out to the shell in the middle of Ruby to do the job.

FiveRuns: Spurred on by the recently announced Ruby Hero Awards, who is your own personal Ruby hero, and why?

Ryan Bates: Chris Wanstrath. I have long been a fan of errtheblog.com. Oh, and GitHub. Need I say more?

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

Ryan Bates: Hashrocket’s 3 day launch is inspirational. As a programmer, it’s very easy for me to get caught up in how best to code something without actually coding it. I forget this important agile principle: Do the simplest thing that could possibly work.

Time constraints are a great way to enforce this. Next time when you need to add a feature, set the timer for an hour (give or take) and get started. If you haven’t made some good progress when the buzzer goes off, then perhaps you need to take another look at your problem and approach it from another direction or break it up. It’s too easy to waste hours or more in the “planning” stages to determine how best to code something.

I like to parallel programming to drawing. When starting a drawing you first sketch out the scene with a light pencil. It’s not perfect, but the lines are easy to erase and change if necessary. The sketch is also very fast which makes it cost little. This is important in case you start drawing from the wrong perspective, you can catch this early and start over without much loss.

Ryan Bates has been involved in web development since 1998. In 2005 he started working professionally with Ruby on Rails and is now best known for his work on Railscasts, the free Ruby on Rails screencast series.

Welcome to this week’s edition of Rails TakeFive, our ongoing interview series of insight and commentary from notable members of the Ruby and Rails community. This week, we’re happy to welcome Jacques Crocker, a Rails developer from Palo Alto and the man behind RailsJedi.com.

FiveRuns: Welcome Jacques, and thanks for joining us! Let’s kick it off by talking a bit about Rails 2.1, which was recently released with the help of over 1400 contributors. What about the new release excites you the most? And as a follow-up, what are the most important things in your mind to get done for the next major release?

Jacques Crocker: Rails 2.1 was an amazing point release. One of my biggest pain points for a long time has been gem dependencies. 99% of all my Capistrano deployment failures up until recently were because one gem or another was installed on my local machine but not on the server. In fact, I was halfway done writing my own little gem dependency management plugin that was in use on several of my sites before I saw the edge Rails announcement and subsequently ripped out all traces of my version of the code.

Also, named_scope was a very nice addition to the core. I was already using the excellent scope_out plugin on all my projects, however it had some quirks that have all been smoothed out after switching over to named_scope.

The most immediate need I see for the next release of Rails is to be able to split up large rails projects into separate projects that can easily share code. As soon as any Rails project gets up to 25-30 controllers, it starts to lose a lot of the fun it had when it was 5-6 controllers. But if your Rails project was instead maybe 4 independent but related applications, each with 5-6 controllers then I think development would be a lot more enjoyable for large projects. The trick is allowing these projects to reuse common functionality without becoming too interconnected so they can be swapped out and shared easily. Rails Core needs to address this if they want to take on the real scalability problem, that is scaling a large code-base.

I’d also love for them to ditch migrations altogether and integrate PJ’s auto_migrations plugin.

FiveRuns: You’ve recently written about Phusion Passenger. Tell us a little about your experiences with it so far.

Jacques Crocker: Yep, I’ve been using mod_rails extensively since RailsConf. Given the meager amounts of memory most virtual servers provide, I see Phusion Passenger as a massive benefit since you no longer have to worry about running X numbers of mongrels, and can rely on Passenger to scale up and down as needed. In addition, the use of Enterprise Ruby has decreased memory usage on my servers fairly dramatically (20-30%).

Deployments with Passenger have been a big improvement over the old mongrel/nginx process. It cut my Capistrano config in half, as I used to have all the nginx load balancing config, and mongrel setup as part of my deploy.rb. Now it’s just a simple git update, gem install, migration, and server restart. I’m even exploring the possibility of running any pending migrations automatically as part of the application initializer.

I’m also really excited about the Rack support, giving us an easy way to deploy other Ruby frameworks (like Merb). Rails 2.2 should bring Rack compatibility as well. That should enable a consistent deployment platform for all Ruby web frameworks.

FiveRuns: On that note, let’s talk about Merb – they are all about being agnostic—ORM-agnostic, JavaScript library agnostic, and template language agnostic – what does this mean? And what does it mean to be “thread-safe”? Is there promise in implementing Merb alongside of Rails, say, for processing?

Jacques Crocker: I think Merb is a natural response to some of the wrong choices the Ruby on Rails team made in picking libraries to promote. While Rails initially got me into Prototype and Scriptaculous, I quickly grew frustrated with the framework and made the switch to JQuery. In fact, every time I fork my base Rails project, by default it has JQuery for Javascript, HAML for views, and Sass for stylesheets. I have a suspicion that within a year, it might also include DataMapper as a replacement for ActiveRecord.

I was extremely happy to see that Merb decided to implement “slices”, which is similar to Rails Engines, a hugely mistreated Rails plugin. Engines could have been revolutionary had it been encouraged and integrated by the Rails Core. I’m hoping that merb-slices will demonstrate to the Rails Core team that pluggable, self-contained apps are really the only way we’ll be able to manage our applications’ rapidly growing complexity.

The whole “thread-safe” concern, for me, has been rendered mostly irrelevent. With Mongrel clusters (and now Passenger), the core threading issues have been fairly easy to work around. As for mixing Merb and Rails on the same application, it’s probably a bad idea. If you need an alternative for some fast processing alongside Rails, Sinatra would be an even lighter, faster alternative.

FiveRuns: Beyond Merb, you mentioned Sinatra, but there are a great number of alternative frameworks for Ruby, including Nitro, Waves, Ramaze, Camping, ... What have you seen so far that you really like? Dislike?

Jacques Crocker: After Erik Kastner’s excellent session at RailsConf this year, I starting using Sinatra on some toy projects and have been impressed with it.

Just being able to create all your controller actions in one file is great for small projects, as you don’t have to explore your project directories whenever you need to find something. Plus I love the fact that I can still use HAML and Sass, which drastically reduces the size of the HTML and CSS needed in the view.

The major downside of course is the lack of Rails plugins, which can save a lot of time implementing complex features like tagging and S3 file uploads and can be extremely time saving for even really small projects. However I think the Sinatra community is growing fast and will eventually have stable ports of all the most popular Rails plugins.

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

Jacques Crocker: Obie has been a huge inspiration for me. I’ve been involved in rapid startup bootstrapping for a few years now, and it was great to see Hashrocket succeed in delivering rapid development projects as a packaged service.

I took part in last year’s Rails Rumble (building PubBud) and I think the capability is there for anyone to be able to build a significant web application in a few days time, given the right vision and tools. This year there are going to be way more teams, and a lot of excitement as people have been getting much better at building Rails apps fast. I’m looking forward to competing again.

The single best tip I can offer for “ultra-productivity” is to create and continuously improve upon your own Rails new project skeleton. In that skeleton app, collect all the most useful rails plugins, stabilize them, and make them your own. Add in base stylesheets and ui components (I use blueprint) so the views don’t slow you down. Also add in common helper methods that you frequently use.

They key is to use this skeleton often, that is use it to create a new web app. I try to start a new Rails project from my base project at least once a week. Most of the time I leave it after hacking for 3-4 hours, but each time I end up improving on the base project and extracting pieces of functionality into my asset library.

This was one of the ways I was able to implement OpenSourceRails in a single weekend. All the major features – file uploads, tagging, bookmarking, ratings – were stuff I’ve implemented before and were part of my library. Having a collection of tried and true pieces of functionality along with a well structured and familiar base project will be a big time saver on any new project.

Jacques Crocker is a Rails developer from Palo Alto and blogs at RailsJedi.com. He also runs OpenSourceRails.com, a gallery for open source ruby on rails web apps.

The FiveRuns dev and support teams live in Campfire.

As I wrote a while back, our Campfire ‘Development’ room is constantly filled with team chat, subversion/git commit messages, and CruiseControl build statuses. Piping all of this information into one centralized team-viewable location has been awesomely valuable. That being said, we’ve kicked it up a notch.

Say hi to CampTweet.

This simple Ruby script broadcasts your Twitter statuses (tweets), Summize Twitter search results, and RSS/Atom feed items into the Campfire room of your choice.

Here’s how you can use it on your team.

1. Install the gem

sudo gem install camptweet

2. Generate the camptweet daemon script

camptweet .

This will generate a camptweetd file in the current directory. By default, the meat of it looks like this:

Camptweet::Bot.new do |camptweet|
  camptweet.twitter_users = ['bdainton']
  camptweet.twitter_search_terms = ['fiveruns']
  camptweet.feed_urls = ['http://github.com/repositories.atom']
  camptweet.campfire_subdomain = 'mycompany'
  camptweet.campfire_use_ssl = true
  camptweet.campfire_room = 'Room Name'  
  camptweet.campfire_email = 'foo@mycompany.com'
  camptweet.campfire_password = 'foo_password'
  camptweet.verbose = false
  camptweet.logfile = 'camptweet.log'
end.run

Update the above config to list the Twitter screen names of your team members, the simple (one-word) terms for which you’d like to search on Summize, and any RSS/Atom feeds for which you’d like the latest items in the feed to be pumped into Campfire.

3. Start up the script

nohup ./camptweetd &

That’s it.

Here at FiveRuns, we’ve been using this tool to centralize our team tweets, product and company mentions on Twitter, and a number of dev-and-support-relevant feeds (including project card updates in Mingle, forum and GetSatisfaction activity, and build system status).

If your team is using Campfire, give CampTweet a try. It’s neat.

Coming off an awesome RailsConf, we’re picking back up the FiveRuns TakeFive interviews, our ongoing series of insight and commentary from notable members of the Ruby and Rails community. This week, we’re pleased to have Jeff Cohen, co-founder of Softies on Rails share his views on Ruby on Rails with us.

FiveRuns: Welcome Jeff, and thanks for taking the time to join us. Let’s get started with a question spurred from the recent Ruby Hero Awards. Who is your own personal Ruby hero, and why?

Jeff Cohen: Without hesitation my vote goes to Geoffrey Grosenbach. The official Ruby on Rails podcast had a big influence on me when I first started learning Rails. It was one of the few sources of information I had available to me when I was trying to understand what Rails was all about, and the podcasts just hit the spot every time. His innovative approach with PeepCode screencasts has set the standard again. He’s also one of the living examples of the “Matz is nice, so we are nice” standard that the Rails community would do well to emulate more often.

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

Jeff Cohen: I’ve found two danger areas where my productivity curve begins to like that deep chasm Gandalf fell into. The first is overdesigning. It’s too easy to build more than you really need. I think I’m being smart, but I’m just wasting time. So I recommend: write tests (or specifications, whatever you want to call them) first. You’re less likely to get too clever. However, you should write them at the highest level of abstraction that you can get away with. High-level tests are good. They give you the freedom to innovate. Testing at too low a level tends to lock me into the “usual” way of solving the problem. The more high-level the tests are, the more creative the solution code can become.

The second productivity gravity well is any UI design work that doesn’t involve coding. Draw on a napkin or photoshop something all you want, but it really means nothing until you see it on the screen. So don’t prototype anything paper if you can avoid it. Start with simple, raw HTML. Inline the styles if you have to. The goal is to go from idea to browser as fast as possible. Make it ugly, just make it work. You can refactor it later into real HTML/CSS/ERB templates once you’re happy that you’re on the right track.

FiveRuns: 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?

Jeff Cohen: It was the fall of 2005, and my friend Brian Eng in the next cube over asked me if I had ever heard of this new thing called Rails. Now, this was back before there was even a 1.0 of Rails - I think it was version 0.13. We were both working as .NET developers at the time. I enjoyed .NET development for desktop applications, but didn’t really get the hang of ASP.NET so I always kind of shied away from web development, even though that was what I really wanted to learn how to do. Anyway, we started learning some Ruby on Rails to see what the buzz was all about. We helped each other figure things out, and pretty soon I had a simple one-model web application running in my browser. It was eye-opening. I used the Ruby One-Click Installer for Windows, the Rails gems, and about 10 lines of code in Notepad. The whole convention-over-configuration thing was just awesome. Rails was easier, more logical, and simply more enjoyable for me than ASP.NET. Within a year, I walked away from my 12-year-long Microsoft-based career to accept a full-time job doing Rails development. But the thing was, I was lucky to have someone like Brian introduce Rails to me, and to learn from. I would never have made the switch alone. So nowadays I try to spend time helping others when they decide to switch to Rails, too.

FiveRuns: Along those lines, do you have any specific recommendations for people switching to Rails from another language or framework?

Jeff Cohen: First, they should learn Ruby apart from Rails. When I see ugly Rails code, a shallow understanding of Ruby is often to blame. The better you get at Ruby, the better your Rails code will automatically become. Second, learn how to model your domain properly. I know Ajax is fun to do, and it’s also easy to put all your logic into your controllers. But the best Rails apps also have a rich, cool domain model. Their models are the gears for the application. The controllers decide which gear needs a nudge, and wonderful things seem to happen. Finally, read! Get a couple books, read blogs, and read other people’s code. Don’t just Google for code snippets and then ask for help when you get stuck two minutes later. You really need to learn the basics first. And once you’ve starting to get your feet under you, start helping others who are just starting out. You inevitably learn something yourself, and it’s a way you can immediately begin to give back to the community.

FiveRuns: Let’s talk a bit about Rails 2.1, which was recently released with the help of over 1400 contributors. What about the new release excites you the most—and as a follow-up, what are the most important things in your mind to get done for the next major release?

Jeff Cohen: I was glad to hear from people who went to RailsConf that Jeremy Kemper spoke about how the core team is focusing less on new features these days, and more on security and scalability. I think the overall feature set of Rails is quite strong. If anything, I want less. I cringe a bit when I see pleas for more configurability. I don’t think that’s what we need right now. Rails must remain good at its core purpose: database-backed web applications. I want it be very opinionated. I love conventions that make things really easy for the 80% case. But one thing I do wish for, is an easier way to share code among Rails applications. Plugins work well up to a point. I think most people would like an easier way to share an entire MVC “molecule”: a model-view-controller capsule that can be shared among applications. It’s not an easy problem to solve, and it’s not like I have a solution for it yet, either.

Jeff Cohen has worked with object-oriented programming languages and frameworks for more than 15 years. A former MCSD, he co-founded the SoftiesOnRails blog at www.softiesonrails.com in 2005. He is the founder of Purple Workshops, and is currently writing a book with Brian Eng titled Rails for .NET Developers to be published by Pragmatic Bookshelf this fall.

What’s happening in Ruby on Rails production environments these days? Here a few links, thoughts and tips toward a better Rails deployment. What did I miss? Let me know.

Of course, Ezra’s book, Deploying Rails Applications is finally out. The PDF drafts have been nice, but having the final copy book on the desk can’t be beat. I’ve had a to buy more copies for the office, in the hopes of hanging on to mine longer.

I got to spend time with Blaine Cook last week. In addition to being a sharp and friendly guy, he’s also a creative brainstormer. He probably knows as much about scaling Rails as anyone out there.

What’s the top Google hit for “Ruby Rails Performance”? Zen and the Art of Programming has a top 10 list of performance tips and some great work on Ruby implementation comparisons.

Sometimes in the torrent of performance focus, it’s forgotten that managing your app is a superset of managing performance. You can learn a lot about your Rails app’s timing, behavior, its databases, operating systems, observe trends, set alerts and more with FiveRuns Manage. Yes, a plug. Tools make the job easier. Check us out!

What do wet kittens have to do Rails management? Nothing. Well, I did pull the link from the Bar Camp Orlando guys who know their Rails stuff. But mostly it was just great pics.

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.

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.

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.

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?

We are excited about the release of mod_rails for Apache. Its innovative approach brings another promising Rails deployment option to the community. The Phusion team behind it has taken an open approach to developing and educating the community. This first release not only looks solid and well tested, it is also well documented.

After using mod_rails in a test environment for a couple of days, I see two typical usage scenarios:

1. As a Mongrel replacement on dedicated servers: If you run a Rails application on a dedicated server or virtual slice with a pack of Mongrels, you can simplify your deployment and remove an indirection. This especially applies if you already use Apache with mod_proxy_balancer. Instead of juggling all Mongrels and their respective ports, you can configure your environment exclusively through Apache’s httpd.conf file. Need more Rails instances to handle the load? Just increase RailsMaxPoolSize and restart Apache. Done.
2. As a new infrastructure for shared hosting: If you are a shared hosting provider that wants to offer reliable Rails application hosting, you now have a real option with mod_rails. FCGI never reliably worked in shared environments for Rails hosting. That situation inspired the development of mod_rails in the first place.

Rails Instrumentation

So, how does mod_rails work in conjunction with our Rails instrumentation? The short answer is: “It just works.” Since our instrumentation is written in Ruby, it is independent of the actual Rails container. Whether it’s Mongrel or mod_rails doesn’t matter.

The long answer has to distinguish between the two usage scenarios above. If you have a dedicated system, like in the first scenario, you can just switch from Mongrel to mod_rails and the FiveRuns instrumentation continues to run. We have one suggested configuration adjustment (see below) but that is optional.

Technically, our instrumentation still works in shared hosting environments, as described in the second scenario, but our current client architecture has not yet been enabled for these setups. The FiveRuns client not only collects Rails data but also other metrics from the operating system, web servers and databases. As a system service it initially needs root privileges for installation to become a system service (during runtime it operates with lowered privileges). However, in shared hosting environments users typically cannot install system services and execute long running processes. We plan to address this in the future.

Suggested mod_rails configuration adjustments

As a Mongrel user, I’m used to long running Rails processes. For example, in my test environment I run four Mongrel instances. I typically start those four processes up and then they continue running, under optimal conditions, until I deploy an application update or have to conduct general system maintenance.

Unlike Mongrel, mod_rails handles Rails instance creation and destruction much more dynamically. With its default settings you can observe mod_rails spawning and destroying Rails process instances within minutes. To me, this approach allows to dynamically allocate server resources in a memory efficient way. This seems especially important to shared hosting environments but not so much to dedicated server environments.

That being said, if you are moving from Mongrel to mod_rails and use FiveRuns Rails instrumentation, you might want to change the following mod_rails default option:

  RailsPoolIdleTime 120  

This parameter describes after how many idle seconds mod_rails will shut down a Rails instance. The default is 120 seconds. We recommend increasing this option to at least 600 seconds to streamline operations with the FiveRuns client. If you desire more Mongrel-like behavior in your dedicated environment consider increasing this option up to 3600 seconds or more.

Another default configuration parameter you will want to adjust is the following:

  RailsMaxPoolSize 20

It defines the maximum number of Rails instances mod_rails will create. In my test environment I typically use four. However, this number will be different for any environment. When moving from Mongrel to mod_rails you should initially use the same number as in your Mongrel environment. Please also note that RailsMaxPoolSize is a global configuration option. If you host multiple, distinct Rails applications with Apache this maximum will apply to all Rails instances across all applications.

Who is switching?

For us as a Rails management provider the interesting question is who will switch to mod_rails in their production environments? Please leave us a comment why you would switch to mod_rails or why you wouldn’t leave Mongrel.