FiveRuns Blog

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.

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.

Yes, we already live here!

via Hugh MacLeod.

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?

On the RubyLearning.com blog, FiveRuns developer Bruce Williams was interviewed by Satish Talim. In this post, Bruce shares his thoughts on the Ruby programming language and the community at large.

RubyLearning.com is a thorough collection of Ruby Study Notes for those who are new to the Ruby programming language and in search of a solid introduction to Ruby’s concepts and constructs.

Thanks to Satish for the opportunity!

FiveRuns partner Atlantic Dominion Solutions is a premier web development firm that specializes in the use of Ruby on Rails to solve real business problems. A few months ago, ADS launched the Mantis service to provide continuous monitoring and management for Rails apps deployed onto Amazon EC2. Combining ADS services, RightScale and FiveRuns, ADS Mantis customers can have their EC2-deployed Rails applications continuously monitored, and rely on the the ADS team to prevent and, when necessary, quickly respond to issues.

Mantis is just one example of the great work ADS is doing to support the growth of the Ruby on Rails community. In this podcast, Robert Dempsey, Project Director of ADS discusses Ruby on Rails, the efforts ADS has taken to support the Rails community, application scalability with Amazon EC2, and how ADS is using FiveRuns to monitor their customers’ application environments.

FiveRuns interview with Robert Dempsey of ADS

We can’t say it enough – our customers are doing some terrific work with Ruby on Rails – developing valuable web applications that perform simply and beautifully. Investment Instruments builds Web-based tools and services for the residential real estate market. Today they have two sites: Rentometer, a tool that lets tenants compare rents in their and other neighborhoods, and Rentomatic, an online network for landlords and tenants. Through the tools provided on the site, Rentomatic creates happier landlords and happier tenants.

In this podcast, Jeffrey Krause, CTO and co-Founder of Investment Instruments discusses how Ruby on Rails has helped the company develop their applications faster than they could with other languages, and how they use FiveRuns Manage to gain visibility into the performance of their systems and debug bottlenecks before and as they occur.

FiveRuns interview with Jeffrey Krause of Investment Instruments

Nice post from Dennis Howlett at ZDNet on FiveRuns and our Ruby on Rails application monitoring service. In the article, Michael Coté comments that facilitating conversations with the Rails community and helping developers solve real performance problems with their Rails applications is the ticket to scalable Rails management.

Investing in and betting on a future filled with Rails production applications is what we’re all about. By providing the tools and conversation to help facilitate Rails adoption we hope to continue to help customers such as Investment Instruments and Blue Box Group save time and money in their development and production operations. And, we hope, set up FiveRuns as the go-to source for Rails application performance management. As Dennis points out in the post, the company that can successfully build up the dialog with the Rails community will outrun any incumbent systems management player that tries to enter the market.

Taming Ruby on Rails with FiveRuns.

Every once in a while, we like to highlight some of the awesome work our customers and partners are doing with Ruby on Rails, so we’re kicking off something new this week. Blue Box Group is a dedicated and virtual hosting company focused on Ruby on Rails. They specialize in working with Ruby on Rails developers on everything from small deployments on virtual servers, to large 10+ server clusters pushing close to 45 million hits a day.

In this podcast, Jesse Proudman, the CEO of Blue Box discusses the unique challenges his customers face with scaling their Ruby on Rails applications, and how he uses FiveRuns Manage to troubleshoot scalability issues, streamline database performance and nip problems in the bud before they present themselves to the general public. Take a listen and let us know what you think!

FiveRuns interview with Jesse Proudman of Blue Box Group

The second annual Austin on Rails FiveRuns SXSW Happy Hour was held Monday night and and a good time was had by all. Thanks again to Austin on Rails and SXSW for helping us throw the best party of the week!

Here are the pics. Enjoy!

The week, FiveRuns welcomes Ryan Garver, CTO at ELC Technologies to the Rails TakeFive series. ELC Technologies is a software-consulting firm based in Santa Barbara, California, that has the biggest team of Ruby on Rails developers bringing new applications to global 2000 companies and startups. They are also a FiveRuns partner.

FiveRuns: Welcome Ryan. 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?

Ryan Garver: I started using Ruby on Rails after developing a decently large PHP application about three years ago. I felt like everything I had developed in PHP was custom, right down to the directory structure. It was maddening.

At the end of the project I knew there had to be a better way to develop web applications. I looked at a number of newer web frameworks including TurboGears, and Django. (I had an affinity to Python at the time.) Along the way I tried Rails. By the time I had completed the DHH screencast and built a small sample app, I was hooked. Ruby felt much more like English than programming, and at the time I was only just beginning to get a glimpse of some of the tricks the language and Rails held.

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?

Ryan Garver: I think with any new thing in technology, if you develop a good thing, it’s only a matter of time until the suits start showing up. What we do as programmers is in high demand and very profitable. When something like Ruby and Rails comes along and undermines the current thinking on time to market and developer efficiency people will start to pay attention. I consider this a sign that we are doing something right and that the world at large is beginning to notice.

As far as how this impacts the future of Ruby, I suspect that the primary focus will remain around Rails. Ruby will feel the trickle-down effect from that community. The biggest place where I see a need for change (primarily driven by the enterprise) is Rails ease of deployment. Capistrano is great, but most big IT departments are not designed like a startup where every developer is a systems administrator and has the keys to the production machines. JRuby is doing some neat things in this department by supporting Java-based deployments, which by now have a long history in the enterprise. This strategy is very appealing to many enterprise customers, but using Ruby can restrict what Ruby libraries you have available so there is still a cost. I expect that moving deployments to something that more closely models the WAR file approach is right on the horizon. Keep you eyes on EngineYard’s mod_rubinius and the others out there trying to make this better.

FiveRuns: When is Ruby on Rails an appropriate choice for application development in the enterprise?

Ryan Garver: I think as soon as you have a web-based project on a tight deadline you should take a look at Rails. In my experience, Rails consistently outperforms other technologies in terms of time to market and longer-term maintainability.

FiveRuns: Is the Rails ecosystem missing any key tools that could make life easier for developers, and maybe expand adoption of the framework?

Ryan Garver: Deployment is the first thing that comes to mind. I give Rails a hard time on the deployment issues, but really my problem is with how it integrates with larger organizations. Rails deployment is great if it’s me and a few other guys deploying an application on a server. We start to run into problems when the developers are not intimately involved in the deployment or when the server is shared with multiple applications. It can be done, but it could be easier. As deployment is improved I see Rails really stepping into the mainstream in a big way.

FiveRuns: What do you make of Twitter’s ongoing performance woes, most recently around Macworld, the Super Bowl and the primary season? Seems like within the community it is widely recognized that Rails has nothing to do with it. But outside of the community, the perception is very different.

Ryan Garver: Whenever there is a high profile example of a failure people will hang on to it. This is doubly so in the technology community. We are a judgmental lot. This is an important part of our heritage and it allows us to deal with making big decisions about technology and methods that need to be evaluated on many different and often conflicting levels. We’re good at it. The side effect is that we tend to hang on to familiarity and notice negative features of alternatives more than positive. To me Rails’ benefits overpower the negative press by an order of magnitude at least. Twitter may be struggling with explosive growth, but at the end of the day they released and continue to be a success. It’s hard to count this as a failure of Rails.

One thing to realize is that up until and including Rails 2.0, performance was a secondary driver for the core team. The primary focus was on maintainability and efficiency as a developer. The next release of Rails is being focused much more on the performance metrics and should shut a few of the naysayers up.

Ryan Garver is CTO of ELC Technologies, a software-consulting firm based in Santa Barbara, California, that has the biggest team of Ruby on Rails developers bringing new applications to global 2000 companies and startups. He holds an MS in Computer Science from the University of California, Santa Barbara.

This week, FiveRuns welcomes Pat Eyler, noted Rubyist and writer to the Rails TakeFive series.

FiveRuns: Welcome Pat, and thanks for taking the time to share your thoughts. What was your first experience with Ruby and/or Rails and how did it come about?

Pat Eyler: In late 1999 and early 2000 I’d written a couple of ~5000 line programs in Perl for a client. While I was happy with my code, I thought there was some significant room for improvement. Shortly thereafter, I picked up a copy of The Pragmatic Programmer and just loved it. I especially liked the idea of learning new languages to become a better programmer, so when I saw a copy of the Pickaxe book by Dave and Andy I bought it immediately.

At first, I read through it planning on becoming a better Perl programmer by learning Ruby. Instead, I fell in love with Ruby and gradually did less and less work in/with Perl.

By 2001 I’d moved to Seattle, and (along with Doug Beaver and Ryan Davis) co-founded the Seattle.rb—perhaps the best known Ruby Users Group in the world. That was also the year I went to my first RubyConf. From that point on, there was really no looking back.

FiveRuns: People always talk about “convention over configuration” as a paradigm that is central to why Rails works as well as it does. Can you say a little more for the newbies out there about why this is so important?

Pat Eyler: I think this is a pretty interesting idea, and one that is applicable beyond Rails. Perl has its “TMTOWTODI” (There’s More Than One Way To Do It). Python seems to posit that there should be one and only one way to do it. I like to tell people that Ruby presents many ways of doing things, and the Ruby community guides you to the best way for whatever it is that you’re doing. In some ways, “convention over configuration” is an extension of that.

Imagine buying a car. Certainly, you want options, but can you imagine the added time, expense, and confusion that would exist if you had to pick an option for every part of the vehicle?

If you can reduce the effort needed to configure your application, set up your framework, or use your library by adopting a set of conventions (hopefully based on the conventions of the larger Ruby community), then your users will be able to get more done. They be able to dive right in and get things working instead of focusing on getting things going.

FiveRuns: What do you think about the progress JRuby is making? Is this going to increase adoption with more mainstream developers?

Pat Eyler: The JRuby team is making amazing progress. I’ve seen a better than 25% performance increase in the new 1.1 branch. They are closing out bugs and adding features. JRuby is looking really healthy, and really attractive for rubyists stuck in a Java-dense environment. I’m not going to be surprised to see JRuby faster than and more stable than the 1.8 Ruby implementations.

I think another side of the progress is less well known. Tim Bray has talked a lot about the dearth of good developer tools (read, an IDE) for Ruby, and JRuby seems to have driven the development of these tools further and faster than most of us would have thought possible. While a lot of Ruby hackers are perfectly happy with vi/emacs/TextMte there are people who want more, and NetBeans and Eclipse seem ready give it to them.

I’m interested in seeing what other tools seep into Ruby because of JRuby’s Java/Enterprise heritage. I think there’s room for some exciting system management and monitoring tools to name just one niche.

FiveRuns: What do you think about Curt Hibb’s opinion that by running Ruby under the ever-present JVM it is now much easier to sneak Ruby into companies through the back door, especially since Ruby can call and inherit Java (and vice versa)?

Pat Eyler: Well, I’ve been sensitive to the phrase ‘sneaking Ruby into the …’ ever since I interviewed Hal Fulton, and a reader got worked up over it. I think a better way to look at it is that JRuby reduces the barriers that keep companies from adopting Ruby.

In some cases, the interoperability with Java will be the feature that does it. In others, it’s just the fact that Ruby on the JVM is easier to install, manage, etc. that will get Ruby’s foot in the door. I think this could be especially true for the Windows environment—especially if IronRuby proves to be too slow out of the gate or too non-standard.

And, I’ll answer a question you didn’t ask: What do you think about Rubinius?

FiveRuns: Thanks, Pat! What do you think about Rubinius?

Pat Eyler: I think Rubinius is going to drive a lot of ideas into Ruby and into the Ruby community. Rubinius is a next generation VM for Ruby which is written (mostly) in Ruby. At this point it’s still slow and incomplete (think of JRuby in 2006 and early 2007), but it’s maturing fast.

Since the core of Rubinius is written in Ruby instead of C, it’s a lot easier for rubyists to grok. That should result in more people hacking on the system and trying out new ideas. As some of these ideas prove themselves, I see them being adopted into Ruby.

Another benefit of Rubinius is that it’s drawing interest and investment from a number of companies. Like Sun’s investment in JRuby, this helps legitimize Ruby and will encourage the development of tools and libraries that will benefit the rest of the community.

Perhaps the biggest benefit that Rubinius brings to the larger Ruby world is the Rubinius test suite. To be fair, there are a lot of folks from JRuby and other Ruby implementation projects working on this too. One of Ruby’s weaknesses has always been the lack of a specification and test suite, but now we’re getting close to having one.

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

This week, coming from sunny Orlando and the sold-out acts_as_conference event, we’re happy to bring you this week’s Rails TakeFive insights from Robert Dempsey.

In addition to his full time work at leading Rails development firm, Atlantic Dominion Solutions – ADS, Robert is the founder and Director of Rails For All, a not-for-profit organization dedicated to promoting the use of Ruby on Rails. FiveRuns is proud to count ADS as a partner.

FiveRuns: Welcome, Robert. What was your first “ah-ha” moment with Ruby and/or Rails and when did you know that the framework was a good fit for your organization?

Robert Dempsey: Our first experience with Ruby on Rails was converting a PHP app. We had done three months of PHP development and recreated the entire thing in Rails in less than one month. It was at that time that we decided to move 100% to Ruby on Rails development. That was more than two years ago. Interestingly enough, as Rails has matured as a framework, we have matured as a development firm, moving from waterfall methodologies to agile development. Rails and agile mesh perfectly.

FiveRuns: People always talk about “convention over configuration” as a paradigm that is central to why Rails works as well as it does. Can you say a little more for the newbies out there about why this so important?

Robert Dempsey: When people ask me why they hear that Rails apps are built so much faster than using other languages/frameworks, I state “convention over configuration” as the main reason. While the statement is a poke at Java applications and the large amounts of XML files they use, it is very important. When we create a Rails application, we can expect there to be a certain folder structure put in place, with each file type (model, view, controller, etc.) being in its proper folder. While that seems like such a simple thing, it becomes huge when you join a new team or take over an application from another team. There is less learning curve as you already know what is where. You don’t have to learn new conventions, they are already spelled out for you.

FiveRuns: When is Ruby on Rails an appropriate choice for application development in the enterprise?

Robert Dempsey: Wikipedia defines enterprise software as, “software that ‘solves’ an enterprise problem (rather than a departmental problem) and usually enterprise software is written using Enterprise Software Architecture,” which it defines as “the description of the current and/or future structure and behavior of an organization’s processes, information systems, personnel and organizational sub-units, aligned with the organization’s core goals and strategic direction.” Rails definitely fits into that broad context. As an example, we created a claim tracking system for a large US-based insurance company using Rails. Enterprisey? Definitely. The goal of software is to model business processes and to solve business challenges. Folks are doing this all day for companies of varying sizes using Rails.

FiveRuns: John K. Waters recently summed up a panel from QCon San Francisco in which he asked “So why is this free, open, easy-to-use, passionately advocated Web-app framework having such a hard time gaining serious traction in the enterprise?” What do you think?

Robert Dempsey: While I have heard of Rails and other open source projects being shot down due to the inability to buy a license or get support from a large vendor, I think the main reason there isn’t more rapid adoption of Rails in the enterprise is due to the paradigm shift that Rails requires. Rails follows a certain set of standards, methodologies, and ideas that may not fit with established practices. However, Rails is only three years old. Give it more time, and we will see increased use of it. Rails 2.0.2 has large performance improvements, as does Ruby 1.9. Both will keep getting better while adoption increases. The more stories we hear about proven, large-scale Rails applications, the more it will be accepted. Did I mention that we wrote a claim tracking system for an insurance company? That seems “enterprisey” to me.

FiveRuns: What do you think about Curt Hibb’s opinion that by running Ruby under the ever-present JVM it is now much easier to sneak Ruby into companies through the back door, especially since Ruby can call and inherit Java (and vice versa)?

Robert Dempsey: While I have seen a number of very successful projects that combine Ruby on Rails and Java, each running on their own servers in their own environments, I got very excited when I started to use JRuby and Glassfish. It was great to be able to package up an entire Rails app and with a few clicks of a mouse have it deployed to an application server, which in this instance was Glassfish. Rails deployment has always been an issue, one which Java solved a while ago. Further, Java has a lot to offer. If I can use the best of Java and code in Ruby then I have two tools in my belt that will help me create serious business applications. If the JVM and JRuby makes it easier for us to get Ruby in the door then I am all for it.

FiveRuns: Is JRuby going to increase adoption with more mainstream developers?

Robert Dempsey: I’m very excited about JRuby. There are many Java shops that are looking to introduce Ruby and JRuby is the way that can happen. I believe that much like Rails helped increase the use of Ruby, so too will JRuby. I have always been a big proponent of the right tool for the right job. Both Ruby and Java have their place. When used together, they bring the best of both worlds to the table. As for attracting mainstream developers, that might take a while. I have seen in-house Java developers sneaking Ruby in using JRuby, and I am sure that ThoughtWorks is working with it quite a bit, but that is the extent of what I have heard, so far.

FiveRuns: Have you ever been part of a “Big Rewrite,” as Chad Fowler has put it? What advice would you give to anyone about to take on such a project?

Robert Dempsey: We started to work with a company on a “Big Rewrite” project. Before getting into it we wanted to ensure that the client was doing it for the right reasons, and that there was buy-in on all levels of the organization. In this case, those right reasons included the current code base being unstable and difficult to maintain, the current code is many versions behind and they wanted to start fresh with a new language (and liked Ruby on Rails), and Rails fit the application. We also started into the project as if we were working on a brand new application that has never existed. We created a fresh set of requirements written as user stories and put them into a backlog, in preparation for client prioritization. My advice is to approach a project thus: ensure you are doing it for the right reasons, get buy-in from all impacted parties, start with a fresh set of requirements, and refer to old code as reference material only.

Beginning a career in IT more than 9 years ago, Robert Dempsey transitioned to web application development in 2001, teaching himself PHP and VB.NET. In 2005 he dove into learning both Ruby and Ruby on Rails. What he found caused him to change the focus of his company, Atlantic Dominion Solutions to a full-service Ruby on Rails development firm. In March of 2007, Robert launched the not-for-profit Rails For All, with the purpose of giving back to the community that had given him so much. Robert gives frequent talks at local Ruby and Java user groups, teaches the basics of Ruby on Rails, publishes articles for Amazon Web Services, and mentors new freelancers.

Welcome to this week’s installment of Rails TakeFive, FiveRuns’ ongoing series of insight and commentary from notable members of the Ruby and Rails community.

This week, we’re happy to have Jeffrey Krause, CTO and co-founder of Investment Instruments Corporation, share his views on Ruby and Rails. Investment Instruments is a provider of two Rails-based services to the residential rental marketplace, Rentomatic and Rentometer. Rentomatic and Rentometer increase transparency in the residential real estate market to strengthen relationships between real estate managers, their tenants, and the professionals who support them. Investment Instruments is also a FiveRuns customer.

FiveRuns: Welcome, Jeffrey. What was your first experience with Ruby and/or Rails and how did it come about?

Jeffrey Krause: My first experience with Rails was in early 2005. Investment Instruments developed an early version of our rent management application, Rentomatic (formerly iiproperty) using some ‘older’ technologies and were evaluating tech for our next version – we looked at the standard lineup: Microsoft, PHP, Java, and of course the tiny underdog. While evaluating Rails I was instantly giddy with excitement. I learned more and dug deeper. I created demos for our team, gave the early convention over configuration pitch, and described the vision behind Rails. I think they were convinced more by my passion for Rails than the fledgling technology – but we’ve never looked back.

FiveRuns: We’ve seen job listings that amusingly seek “a Rails expert with 5 or more years of experience.” What does the job market look like these days for Rails developers?

Jeffrey Krause: I saw the same thing with Java back in the 90s and still smile. It’s a very competitive marketplace for Rails developers and if you’re in the position of trying to hire developers and you don’t have any Rails expertise in house then you’re in an even worse position – mostly because inexperienced developers can demonstrate and code ‘basic’ Rails apps which are difficult to evaluate by nontechnical people. We have a fantastic team, but it took us several years to assemble it and we needed to look globally.

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?

Jeffrey Krause: Yes, but I’ve never thought this was bad. I’m pleased to see Rails mature and enter the ‘enterprise’ and a larger marketplace. I would hope that we are also adding to this environment. We’ve developed a ‘real world’ financial transaction based system which needs to be available and predictable – our customers depend on us daily.

FiveRuns: Rails definitely has an international following – any cultural differences in terms of uses of or attitudes towards Rails that you’ve observed in your travels?

Jeffrey Krause: We have a distributed international development team for our Rentomatic service, and have had one since our start. We did a blanket search for developers, and a large percentage was international and well qualified. Having worked with other international developers on several projects I would say there are less cultural differences with Rails because there are structured conventions and standard working methodologies built into the platform. Global is good.

FiveRuns: Have you ever been part of a “Big Rewrite,” as Chad Fowler has put it? What advice would you give to anyone about to take on such a project?

Jeffrey Krause: I’ve been involved with it many times and from all sides of the table. I’ve inherited projects to rewrite projects, had other engineers rewrite my code, and have rewritten my own code. I’ve also seen the ‘big rewrite’ happen with Rails apps as well – meaning a large complex site developed in Rails rewritten in Rails again. It’s hard to generalize in these cases but I would say remember the 80/20 rule and the majority of the effort is often hard to predict upfront. Many times the complexity of the site/application tends to be hidden, it can be in the minds of the original developers, cryptically coded in obscure functions, never having worked predictably in the past (because it’s complex), or just plain and simply overlooked. To counter this effort we spend 20 percent of our development time re-factoring existing code and processes.

As a co-founder of Investment Instruments, Jeffrey Krause has continued his long history of successful entrepreneurial ventures drawing on over 17 years of experience designing and building web-based applications and systems for dozens of companies. As CTO, Jeffrey leads user experience design and technology development. Prior to Investment Instruments, Jeffrey co-founded several companies providing consulting, design and technology support for public and private sectors. As co-founder and co-owner of Blacksquare, an interdisciplinary design and technology firm, Jeffrey has been a designer and consultant for some of the most notable architects in the world including Frank O. Gehry, Morphosis, and the Jerdi Partnership.

Jeffrey holds a Master of Science in Architecture Studies Design and Computation from MIT. He is a former Professor of the University of Hawaii and has published on the subjects of technology and design. He has won numerous Web and Design Awards.

The Austin American Statesman just ran a fantastic article on the Austin on Rails organization, highlighting the buzz that Rails is getting in our hometown. This is a great lesson for other communities with upcoming Rails groups and further testament to the benefits of Rails.

We’re happy to have helped out Austin on Rails with this press attention and look forward to continuing to support our local developers. As you know, FiveRuns is all about developing great tools for Rails developers and operations folks, and we’re building an awesome team of some of the best minds in the Rails community.

Look for us at the FiveRuns/Austin on Rails Happy Hour at SXSWi in March. Hope to see you there!