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

Slides from my Rails Underground 2009 talk

Posted by Fri, 24 Jul 2009 14:37:00 GMT

Hello from London!

Am currently enjoying the talks at Rails Underground 2009 in London and had the pleasure to be one of the first speakers at the conference. My talk covered a collection of what our team considers best practices. Best practices that aid in the successful launch of a web application and covered a few Rails-specific topics as well.

I’ll be sharing some posts in the coming week(s) that’ll expand on some of these topics as promised to the audience.

Since I covered a wide range of topics, I decided to share my slides online. They won’t provide as much context (as I’m not speaking as you’ll look at them), but they might hint at some of the topics that I covered. There was a guy video taping the talks… so I assume that a video of my talk will be posted online in the near future.

Until then… here are the slides

Aliasing resources in Ruby on Rails

Posted by Tue, 23 Jun 2009 05:00:00 GMT

Earlier today, a friend working on a project asked me how we approached routes on our website. If you take a quick peak at our website, you’ll see that we have URLs like so:

When we launched our new site a few months ago, we were working off an existing code base. We have a model named, TeamMember and a corresponding controller. When we decided to come up with new conventions for our URL structure, we opted to ditch the normal Rails conventions and go our own route. What we weren’t sure about was how to alias resources in our routes nicely. After some digging around, we came across the :as option.

So, our route was:

  map.resources :team_members

Which provided us with:

  • /team_members
  • /team_members/robby-russell

We simply added :as => 'who-we-are' to our route:

  map.resources :team_members, :as => 'who-we-are'

...and we got exactly what we were looking for in our URLs.


* /who-we-are
* /who-we-are/gary-blessington

If you look at our site, you’ll notice that we did this in a few areas of our application so that we could define our own URL structure that was more friendly for visitors and search engines.

Anyhow, just a quick tip for those who want to change up their URLs with Ruby on Rails.

p.s., if you know where I can find this documented, let me know so that I can provide a URL in this post for others. :-)

Speaking at Rails Underground 2009

Posted by Thu, 18 Jun 2009 12:40:00 GMT

It’s time to find my passport again…

Waiting at Gatwick Airport

I’ve been invited to speak at Rails Underground, which is being held in London, UK from July 24-25th.

My talk, which is tentatively titled, “Launching Ruby on Rails projects, a checklist”, will expand on several ideas that came out a previous article on the topic. Additionally, I plan to share some of the lessons that we’ve learned at Planet Argon as we’ve launched projects over last several years.

I'm speaking at Rails Underground!

If you’re able to make it, I encourage you to register for the event before it’s too late. Take a quick peak at the list of speakers. I’m grateful to the event organizers for the invite and look forward to seeing/meeting all of the attendees!

Also, for those of you in the London area. If you’re seeking a design and development team that specializes in Ruby on Rails and want to schedule a meeting with me while I’m visiting, don’t hesitate to get in touch with us. I’m planning on staying a few days extra around the conference dates to visit some of our existing clients and would be happy to meet you.

Estimating versus Timeboxing, part 1

Posted by Wed, 10 Jun 2009 22:29:00 GMT

As if delivering projects wasn’t hard enough. Delivering projects on time is even harder. As practitioners, we’re all responsible for measuring up the obstacles in front of us and are accountable to those measurements. At least, we should be.

One of those measurements is time. Time is a funny thing. People have a lot of interesting things to say about time. Some say that it’s one of the most valuable things that we have… but I’ll avoid diving into a philosophical discussion for now.

What I wanted to talk about was project estimation. Specifically, estimates for deliverables. For the past several years, our team has put a lot of effort into becoming more accurate in our time estimating skills. Despite analyzing how often we over and/or underestimate the time each of us believes it’ll take to complete a task, we find ourselves coming back to the drawing board.

A few things that we’ve learned.

  • Tasks that we believe will take a few days/week/more to complete are often underestimated
  • Tasks that we believe will take less than a few hours are often more accurate or overestimated
  • Too many tasks were completed with a bigger budget than was necessary (lower ROI)
  • A lot of time was spent working on requirements refining to get better estimates

When we began to step back from this and look for patterns, we found that several of the tasks that we would budget hours for (versus estimate hours for) were proving to be more accurate. This approach is most commonly known as timeboxing. With timeboxing, we can place a dollar value on a specific task and work within that constraint. For example, with our clients, both parties can come to the conclusion that, “we believe that it’s worth up to $800 to implement this new functionality.” With that, we’re able take that dollar amount and figure out how many hours to box ourselves within.

The underlying question to our client with each change/feature request is, “How valuable is this to your business at this point in time?” Whereas, with a typical approach to time estimates, a client comes to you with a list of changes/features and you provide them with time estimates. “We estimate that it’ll take 6 hours at $200/hour for feature X and we’d do it like this…” The client will have to evaluate your estimate and figure out if it’s worth $1200 and make a decision. They can respond with, “no, that’s too expensive, can we do it for less?” The following steps would entail your team trying to find ways to reduce your estimate.

While these two paths might seem very similar, it’s been my experience that the standard approach to estimating takes more time for negotiating the terms of the agreement.

However, with timeboxing, you are asking your client to provide you with an initial budget. This will completely change how you respond to the feature request. When you have a timebox, from the moment that you begin to evaluate the request, your brain will add the necessary constraints to keep things within scope.

Through this process, we’ve revamped our estimating process so that as we’re building our iteration costs for clients. For each deliverable, we break down a series of objectives/tasks and apply timeboxes to each of those while knowing what the budget is for the deliverable as a whole. Usually, the deliverable is directly related to the request that came from our client with a budget. The process is completely transparent and our team is responsible for working within those constraints.

..and as we’ve learned from Ruby on Rails, constraints can be extremely beneficial.

While I don’t have all the answers yet, my goal is to share some of my experiences and lessons on the topic. I’d love to hear about how you’re adopting timeboxing in your project planning and estimating process.

Anyhow, just some thoughts that I wanted to share. More to come…

Read Related Articles

Hello, HeyBrainstormr.com

Posted by Wed, 03 Jun 2009 22:28:00 GMT

If you follow me on twitter, you might have heard that we launched a little project that we’ve been cooking up at Planet Argon. (news post)

HeyBrainstormr is a lightweight web application that we created so that we could start a brainstorm on a specific topic and solicit ideas from each other. That’s all it does. Nothing more. Nothing less.

We know that having an open brainstorming session requires there to be zero criticism and opted to keep the process anonymous so that even the quiet people could share their ideas. :-)

what can i do right now? : Brainstorming for the rest of us. : HeyBrainstormr

We’ll be posting more details about it on our blog in the near future, but wanted to invite all of my readers to give it a whirl.

I have a few topics that I started (and tweeted about). Feel free to share your ideas on them. :-)

We hope that you find it as fun as we have.

82,520 minutes on Phusion Passenger

Posted by Fri, 10 Apr 2009 09:10:00 GMT

It’s been over 83,520 minutes since I made the switch from using mongrel as my development environment web server to Phusion Passenger. I’ve been extremely impressed with it. Our team has all switched over and haven’t really hit any obstacles in the transition.

Since some people asked me to let them know how this trial period worked out, I felt it was my duty to encourage you all to try it. You can check out my previous post, Switch to Passenger (mod_rails) in development on OSX in less than 7 minutes or your money back! to get rolling.

Additionally, if you’re looking for a streamlined Ruby on Rails deployment environment that includes Passenger, check out Rails Boxcar.

Older posts: 1 2 3 4 5 6 ... 19