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:

• Simplicity
• Elegance
• Taste
• SICP
• Functional style

• 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.

We just added a Rails application dashboard to FiveRuns Manage that summarizes high-level application metrics. If you are a current user of FiveRuns Manage, you can now easily assess your Rails application’s health with a quick glance. If you are not currently a FiveRuns Manage user, it’s easy to start a free 30-day trial by clicking here.

Here’s how it works. This single-page view presents what we consider the most relevant data about any monitored Rails application. It highlights important metrics for sysadmins and also provides starting points for developers to improve an application’s performance, if necessary.

On the left “Performance” column, users find average global metrics and associated sparkline graphs for the selected time period. The page default is 6 hours but can span a range from 1 to 24 hours. Following any of these metrics takes users to the detailed, interactive metric graphs in Manage.

As a complement, the right “Analytics” column lists the ten slowest actions and the ten most invoked actions of this application. Combined, both tables provide developers valuable indicators where to spend their energy to improve the overall application performance.

Following these links sends users to the application analytics page that breaks down action performance into more granular detail. For example, developers can learn how much time an action spends using specific models or rendering specific partials. We published a popular Rails application performance optimization post a while ago that explains in detail how to debug typical performance bottlenecks with the application analytics pages in FiveRuns Manage.

Developers need to evaluate the priority of performance issues of particular actions. That’s why both average response time and the number of invocations together are important. The below screenshot shows an example scenario where the slowest action of an application is not even listed in the list of most frequently called invoked actions. Here, the index action of the MetricGraphsController is the slowest one. However, it only gets invoked twice during this 6 hour time window. In order to improve overall Rails application performance, engineering resources might be better applied to another actions that get called much more often.

As a FiveRuns Manage user, you will see the new app health pages whenever you select an application or cluster from the application map. They are the new starting points for exploring the performance of your Rails applications in production and will greet you whenever you check on your Rails applications.

If you’re not yet using FiveRuns Manage to monitor and tune your production Rails applications, please check out our free 30 day trial.

Heading to OSCON 2008 this week? Be sure to check out talks from a couple of our FiveRuns developers.

Join Adam Keys on Wednesday, July 23rd at 11:35 for What Has Ruby Done for You Lately. Ruby has lots of neat features for writing small, beautiful programs. But, borrowing features from other languages makes it even better! Learn how continuations, pattern matching, and actor-based concurrency can help you write Ruby programs that do more with less code.

Join Mike Perham on Friday, July 25th at 11:35 for How Not to Build a Service. FiveRuns launched the Manage monitoring service targeting the Ruby on Rails market in 2007, but not without making plenty of mistakes in the process. This talk will discuss the social, technical, and business lessons learned over the last year.

Hope to see you there!

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.

So, RailsConf was awesome. Portland was great. But, you’re still wanting more? Hmmm, RailsConf Europe is right around the corner… But, how to get there?

We’d like to help. FiveRuns wants to send you and a guest to RailsConf Europe, September 2 -4, 2008 in Berlin! Entering the contest is easy.

Just download FiveRuns TuneUp, our new, free Rails application profiling tool and upload an application profile (a “Run”) to the FiveRuns TuneUp service between now and August 8, 2008. Current TuneUp users are free to upload Runs, too. We’ll conduct a random drawing out of all the Runs submitted, and if your name is chosen, you and a friend will be on your way to Berlin – airfare, hotel and RailsConf passes included!

So, download TuneUp now, and start Running your way to RailsConf Europe! Hope to see you in Berlin!

Official Rules. Contest open to existing or new users of FiveRuns TuneUp. Download FiveRuns TuneUp at tuneup.fiveruns.com and post a run between July 10 and August 8, 2008 at tuneup.fiveruns.com. On or about August 8, 2008, FiveRuns will conduct a random drawing from all of the users who submitted Runs. The winner will receive two coach class roundtrip tickets to RailsConf Europe 2008, accommodations in Berlin, Germany, and two full conference passes to RailsConf Europe 2008. Airfare accommodations will be roundtrip from the international airport closest to the winner’s home to Berlin, Germany. Flight must depart winner’s international airport on August 31, 2008 and depart Berlin, Germany on September 5, 2008.

One of the lingering issues we’ve had to deal with over the last year in the Manage service is ActiveRecord’s reluctance to talk to more than one database. It’s really quite stubborn in that regard and while there are a few solutions out there, none of them worked quite like we wanted. Some required intrusive application-level code changes, some didn’t offer the features we needed, so we bit the bullet and wrote what we needed.

Specifically we needed two features to scale our mysql database: application-level sharding and master/slave replication. Sharding is the process of splitting a dataset across many independent databases. This often happens based on geographical region (e.g. craigslist) or user account (e.g. flickr). Replication provides a near-real-time copy of a database which can be used for fault tolerance and to reduce load on the master node. Combined, you get a scalable database solution which does not require huge hardware to scale to huge volumes. DataFabric extends ActiveRecord’s standard connection handling to provide these two features.

To install, invoke the usual magic:

gem install data_fabric

Add DataFabric to your Rails 2.1 gems listing in config/environment.rb:

config.gem "data_fabric"

Annotate your sharded models with your desired sharding and replication setup:

class Auction < ActiveRecord::Base
  data_fabric :shard_by => :city, :replicated => true

Let’s assume we are sharding based on the city associated with the request (i.e. the Craigslist model). You’ll need to add the necessary database connections to your config/database.yml for each city based on the naming convention DataFabric uses. See the README for details.

Finally your application controller will activate the city’s shard for each request:

class ApplicationController < ActionController::Base
  around_filter :select_shard

  private
  def select_shard(&block)
    DataFabric.activate_shard(:city => @current_city, &block)
  end
end

Now, whenever you do anything with the Auction model, it will only affect the current shard. Auction.find(:all) will find all auctions within that shard. The converse is also true: you can’t do anything with the Auction model until you set a shard. Note that you can just set the replicated flag without the shard_by flag; DataFabric will act just like Rick Olson’s Masochism plugin.

We’re releasing DataFabric on github for others to use as they see fit. Take a look at the README on github for technical details and code samples. We’ve used it successfully with ActiveRecord 2.0.2 and 2.1. There are some areas which can be painful to deal with, notably migrations and fixtures, but we have both working in production here so you can overcome. :-) I’ll give you a hint: the example application might help.

Good luck and let us know what you think!

Just in case you missed it…

In the latest Ruby on Rails Podcast, FiveRuns Rubyist/Raconteur Adam Keys interviews Geoffrey Grosenbach of Nuby on Rails and Peepcode.

Click here for a listen.

And remember, please don’t show the whale.

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.

FiveRuns developer Eric Falcao gave a talk on Client Side Performance Measurement and Optimization with Rails at this week’s Austin on Rails meeting.

In the talk, Eric discussed his new Clientperf project and some tricks for client-side Rails application performance optimization in the typical Rails/Mongrel/nginx stack.

You can find the slides here.

Enjoy!

We’re pleased to announce that the FiveRuns blog has been included in Guy Kawasaki’s Alltop Ruby site.

If you’re not familiar with Alltop, the site aggregates RSS feeds from “all the top” sites on the web around a particular topic – everything from Startups to Space to Sports. Or in our case, from the Geekery category, Ruby. You can read the FAQ here.

It’s an honor to be included, along with some of the most notable Ruby and Rails blogs on the Web.

I recently moderated a session at RailsConf 2008 called “Top 10 Ways Rails Annoys IT”. The title was contentious, but the goal was to identify and resolve the operational challenges of Ruby on Rails applications. We focused on ways Development teams can work with IT and Operations groups to manage the new Rails deployment processes.

In our discussion, communication between groups surfaced early as a common culprit. The hand off of a new application to a data center team involves plenty of touch points, with any architecture. A good Ops team will have already provisioned hardware, configured the server OS, secured the systems and made databases accessible. But what about Capistrano? Rake? Puppet? Oh, you were planning on nginx with virtual hosts? Do the folks in IT read Russian? Of course they’ve moved off CVS and are prepped to pull code from your Subversion repository, right? What? You’re using Git now?

Ok, so you get the idea. An agile dev team’s technology adoption rate may be high, but their IT peers are often on a more conservative track. Rails can be something of a moving target in general, especially for Ops teams not involved in the day to day environment changes. Examples were raised in our forum of corporate IT being often bypassed in a pinch, by outsourcing hosting and developers pushing to production directly. This has advantages of expediency and simplicity, but what is also happening is that dev is assuming a larger deployment responsibility. Even specialists within Dev teams are now identified as framework performance, availability or database optimization experts, roles formerly the responsibility of sysadmins and DBAs. They have to consider migrations, server resources, upgrades, etc. Jeremy Kemper mentioned this in the core team’s panel discussion. Planning the mechanics of code updates or deciding an efficient number of Mongrels is likely not the best use of programmer resources.

While dev is becoming more involved in the production realm, the same can be said for IT’s involvement in new languages and frameworks. 37signals announcement of Mark Imbracio as their new IT lead includes his creds as a “talented Ruby programmer”. It doesn’t take long browsing Deploying Rails Applications to note the authors are skilled coders, even creating a new cloud provisioning framework. Ten years ago the sysadmins were Apache gurus, load balancing specialists and maybe experts at helping identify database bottlenecks. They were not as likely to be involved in the programming architecture of a Java app they maintain though.

So could IT functions be absorbed outright into Dev? Or will the folks at Engine Yard and Heroku eliminate the need for server provisioning and production optimization? If we achieve drag and drop Rails deployments will we need IT to serve the applications at all? To borrow a phrase, “IT cycles are neither create nor destroyed, although they may be rearranged”. Someone is always responsible for buying hardware, optimizing server environments, indexing databases and any other classic Operational task. They may shift teams internally or be outsourced, but somewhere these tasks are still an engineer’s responsibility.

Dev and IT teams are working (or becoming) closer to each other than ever before. Perhaps as Ruby and Rails deployment and administration tasks normalize, we’ll see Engineering roles separate again. Currently, the gap still seems to be shrinking.