Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 17:59:00 GMT)

The 8-Hour Rails Code Audit

Posted by Tue, 20 Oct 2009 12:13:00 GMT

While our team is typically focused on larger client and internal projects, we do get an opportunity to assist businesses on a much smaller scale. Whether this be through retainer-based consulting or through code audits, we have seen a lot of Ruby on Rails code over what has nearly been… five years!? We’ve been able to compile a fairly extensive checklist that we use in our code audit process that we’ve decided to streamline it into a smaller product.

Historically, this service has ranged anywhere from $2000-6000, depending the size and scope of the projects, but we want to help smaller startups1 and projects outline a roadmap for how they can begin to refactor and optimize their existing code base so that they can be more efficient at the start of 2010. So, we’ve scaled things down into an extremely affordable flat-rate package where we work off of a pre-defined number of hours.[2]

Through the end of 2009, we’re now offering the 8-Hour Rails Code Audit package for just $1000 USD (details).

We’re currently limiting this service to just two projects per week, so reserve your spot now.

1 Larger projects are welcome to benefit from this service and custom quotes are available upon request.

2 As always, we’re happy to discuss longer engagements.

Related Posts

Rails Code Audit Tips - Filtered Parameter Logging

Posted by Tue, 17 Jul 2007 03:50:00 GMT

It’s been a month since I posted, Audit Your Rails Development Team and now I find myself sitting in a hotel room in Mankato, Minnesota with Graeme after a long day of walking through the documents that we delivered to our client after conducting a Rails Code Audit and Review. Our client felt that it would be a great idea to have us visit with six of their employees and walk through the various topics that we brought up in our process. We’ve been doing several of these audits recently and are thought that it would be a good idea to begin sharing some problems that we’ve discovered across projects.

As much as we like to find lots things that we’d recommend improving in Rails applications, we also want to make sure that as many projects as possible avoid some of these common oversights. So, expect to see more posts related to things that we find through our Code Audit and Review process.

Today, I’d like to point out a potential security problem that is often overlooked by developers and system administrators.

Log files.

Does your application request any of the following information from your users?

  • Social security number
  • Credit card date (number, expiration date, etc..)
  • Passwords

BY DEFAULT, all of this data is being written to your production log file. Even if you’re encrypting this data in your database, request parameters (get/post) are all written to your production logs without any encryption. Log files are also notorious for having insecure file permissions, so if you’re on a shared host, other accounts on the server might be able to view them. Regardless of how secure you think your server is, this isn’t data that you want sitting around.

Lucky for you, Ruby on Rails has an easy solution to this problem! All that you need to do is use the filter_parameter_logging method in your controller(s). We generally add something like the following to our application controller.


  filter_parameter_logging :social_security_number, :password, :credit_card_number, 'some-other-param' 

This will replace the value from the parameters with [FILTERED], which solves this problem rather nicely.

So, it would be our recommendation, that if your application is storing any sensitive data, that you take advantage of this simple solution. Be sure to read more about filter_parameter_logging before you implement this for various usage examples.

Stay tuned for more tips and tricks. If you’re interested in contracting us for our Rails Code Audit and Review service, give us a call.

Tomorrow, Graeme and I will be meeting for another day with our clients and then we fly home to Portland, Oregon in the evening. We survived our first tornado warnings, which was exciting as we don’t get those on the west coast. ;-)

Audit Your Rails Development Team

Posted by Sun, 17 Jun 2007 20:05:00 GMT

Several months ago, a few of your colleagues decided to join forces with you as you had come up with a concept for an innovative web application, shared the ideas with your friends and relatives, and began developing a business plan. After a few months of performing some initial market research, working on your pitch, and raising some initial funding, you decided to bootstrap the project and start designing and developing the product.

During your research phase, you came across several articles about this exciting new technology called, Ruby on Rails. You were impressed with many of the sites that were being developed on this new framework as well as the community that surrounded it. Your team decided that it would be a great idea to follow this trend and use Rails as the platform for your new product.

At this point, you began soliciting freelance developers and/or firms to hire for the design and implementation of your project. Eventually, you make a decision and break ground on building the product.

Let’s jump forward to the present day.

You’ve been in heavy development for quite some time. Your product has gone through a series of design changes and you’ve recently begun to allow other people to begin testing the application. You’re receiving a lot of bug reports as people use the system. Your development team quickly fixes them as they appear, but you’re noticing a trend in the development process.

The speed of implementing new features is drastically slowing down as your development team is spending most of their time fixing bugs. Along with that, they are becoming frustrated by the project because they can’t keep up with your new feature requests while trying to keep up with your growing number of bug reports. You’re becoming concerned about the stability of the product and are slightly suspicious that your developer(s) might not be as good as they suggested they were.

Did you hire a bad development team? Chances are, you may not be able to tell. You’re not a developer, so reviewing their code would almost be a waste of time. How would you know if they were doing a good or bad job? Your developers reassure you that things are going to work out in the end, but it’s going to take longer then originally planned. Along with this, your partners and investors are anxiously waiting for you to launch the product, but something feels wrong. You’re worried that launching it too soon could be the quick death of the entire project if it all comes to a screeching halt due to unforeseen bugs and problems with the application. This wasn’t how you pictured the launch of your exciting new product and you feel a lack of confidence in the entire process.

What can you do?

Before I get into that, let’s discuss some of the possible causes for this situation.

  • Your development team may have grossly underestimated this project.
  • You might have pushed too many features into the initial release of the product and your development team might not have done a good job of helping you determine what you need, not just what you want.
  • Your development team might not emphasize testing enough in their process.
  • Your development team may have begun to take a lot of short cuts in an effort to hit your launch date(s)
  • Perhaps you asked for quick turnarounds on new features before an investor meeting… maybe this happened on several occasions.
  • Your development team might not be very good with Ruby on Rails, maybe this was their first Rails project.
  • ...and so on.

At this point, the big question is… what’s the problem?

Can you answer this question yourself? Can your development team answer it? If not, what do you do? How can you get an accurate understanding of how stable the code base of your application is?

Answer: An independent code audit and review

Why is this a good idea? Well, when you have an independent team review your code, you get the benefit of having a fresh perspective.. and often times, an independent team can be much more critical and provide an honest assessment in a very short period of time. This is especially true if they have a lot of experience with the technology. For example, PLANET ARGON has been conducting code audits on existing projects for over two years. We’ve designed a process for checking existing code bases for mistakes that we’ve either made ourselves in the past or found in other projects that we’ve reviewed.

In fact, our process currently walks us through the following areas of your Rails application.

  • Security of the application
  • Privacy of users’ personal data
  • Adherence to the conventions of the Ruby on Rails framework
  • Scalability of the application
  • Performance of the application and data model
  • Testing framework and process
  • User interaction (when applicable)
  • Information Architecture
  • Model-View-Controller (MVC) implementation and organization

Not only does this process provide you with our analysis, but we also provide you with our advice as to where your development team should focus their attention next. If your team is lacking experience in the areas that we recommend they focus on, we’re also here to help them through this with our consulting services. We’re currently assisting several Rails development teams with their testing process, refactoring, user interaction design, optimizing their site, improving their deployment strategy, and plan the implementation of new features.

In general, most freelancers and firms could/should provide you this service, but it should not be performed by your existing development team. They have a bias towards their process and this is your chance to get a second (or third) opinion on the work that you’ve been paying them for. If you’re spending several tens/hundreds of thousands of dollars into this product, an independent review of your investment should be something to seriously consider.

There are several different scenarios that could lead you to deciding to have an independent firm perform a code audit. In fact, I’d encourage you to always get an outside perspective of your team’s work.

You can learn more about our Ruby on Rails Code Audit service on our website or by giving us a call at +1 877 55 ARGON.