Robby on Rails

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. :-)

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.

• Start a brainstorm now!

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

• I need some music suggestions. Help?
• I have writers block. Help me come up with some blog topic ideas?
• what can i do right now?

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

In case you missed the tweet from Alex ...

Our team just designed, developed, and deployed a new site for, Boxcar, our streamlined deployment environment for Ruby on Rails applications.

Feel free to take a tour to learn more about our product plans, which currently start as low as $59/month.

If you have a project that you’ll be launching in the coming months, get in touch with us. :-)

As mentioned in a recent post, I’m hoping to share some lessons that were learned throughout the process of launching a client project. Over the past few years, we’ve been part of several dozen client projects and the big launch date is always an anxiety-filled, yet exciting point for the client and our team. I wanted to provide a quick list of a few the things that our team considers vital before launching that next big project. While most of these things might seem obvious, it’s still good to cover the basics and I hope a few people find it helpful.

Hosting

Our company has been offering Ruby on Rails hosting for nearly four years and a few years longer with the PHP5 and PostgreSQL world. Given that, we’ve seen customers come to us at the last minute before they launch and wanting to get things setup and deployed right away. Quite often, this is their first experience deploying a Ruby on Rails application and there has historically been a semi-steep learning curve to do this. It’s really encouraged that you get this stuff figured out ahead of time. If you’re lucky, some hosting companies might offer cheaper plans so that you can begin to get things setup a few months or ahead of time and upgrade your plan prior to the big launch. This is how our Rails Boxcar hosting plans work.

We’ve seen a lot of customers avoid engaging with a hosting company more than a week or two before their launch because they want to reduce their monthly expenses, but the reality is that if you end up saving yourself a few hours of work by not scrambling at the last minute to get things setup, the hosting costs will pay for themselves. Several of our customers have learned this the hard way and as a result, this has resulted in extra stress that might have been avoidable if things had been ready earlier on.

The basic process that our team is to get a real deployment environment setup as early in the design and development process as possible. Often times, this will be 4-6 months before launch on larger projects. In our process, we aim to have a staging environment that mirrors our production environment. We tend to use a Boxcar Lite plan for our own client projects and get the deployment process working and automated. When it’s time to launch, we can easily upgrade the Boxcars with more resources to one or more Plus plans.

If you’re in the market for a hosting company, do keep us in mind, but if we can offer any advice, be sure to find out how you can scale upwards to meet your initial 3-6 month growth targets. Don’t worry about planning too far ahead in the future, until you see how traffic picks up and how the application and databases perform, you’ll be spending a lot of time guessing without data. If you’re new to this and aren’t sure, I’d encourage you to speak with a Ruby on Rails deployment specialist.

A few things to consider here:

• Get your Capistrano or Vlad deployment tasks setup early. Make sure everything works and set it up to work with multiple deployment environments. (staging, production, etc.)
  • Use Boxcar Conductor with your Rails Boxcar. (Boxcar Conductor on github)
• Use the HTTP Basic Authentication, which is available in Ruby on Rails to keep peeping toms (competitors, search crawlers, spammers, etc.. ) out of your project while you’re deploying to your staging environment. We tend to give out a .htaccess user/pass with this method to the stakeholders so they can access the site whenver they need to.
  • Rails documentation on HTTP Basic Authentication: view docs
  • Watch a Railscast for using HTTP Basic Authentication: watch screencast
• Get your automated tasks (cron jobs) setup way before launch. Verify that things are working here at the right times
  • Extra-credit: Check server time settings to make sure you’re not running big tasks at time periods when heavy traffic is expected
• Make sure your hosting provider has monitoring setup. It’s good to gauge uptime % from launch
  • Extra-credit: Setup your own monitoring with Pingdom or similar service to make sure you know when things are down. (You can audit your hosting provider this way!)

There are a handful of really great hosting companies out there for Ruby on Rails. Be sure to do your homework early! This isn’t something you want to do at the last minute.

Reminder: Keep your project releasable at all times.

Search Engines and Analytics

Before the big launch, be sure that you have outlined a consistent pattern for managing the HTML page titles on each page. Getting targeted traffic to your new web application is (usually) vital. Our team has adopted a basic pattern that we use throughout the application. This way we don’t have to go through at the last minute and figure out where titles are and/or aren’t being set.

In a previous post, I shared a basic plugin that our team uses on projects to manage page titles on a view-by-view basis.

Additionally, be sure to take advantage of using descriptive permalink URLs.

Another tip is to setup your application with analytics (google analytics is free!) If there is one thing that I wish we had setup from day one on every project in the past, was a set of conversion goals. So, be sure to get into your analytics account and prepare your application so that you can track these goals from the moment your application is launched. Collecting as much data about your visitor’s usage habits is going to help you in the coming weeks and months as you tune things based off of feedback and this data. Also, after you begin to introduce changes, you can analyze these metrics to verify that you’re improving things and not the opposite.

So, be sure that you are doing the following:

• Have implemented descriptive page titles and urls
• Are ready to track your site visitor’s usage habits from the starting gate
  • Conversion goals for obvious things like: sign-ups/registrations, viewing your product tour, contact requests, etc.

When Things Go Wrong / Tracking Exceptions

What happens when things go wrong? We’ve been amazed by how many projects we’ve seen have been in production for months/years and lacking something that seemed so obvious. Exception notifications! All too often, we’ve seen teams totally unaware that things were failing for their customers and not being reported to anybody. The easiest way to track exceptions in the past was to use the exception_notification plugin that the Rails team manages. You can have this plugin send your development team emails with a backtrace and all the goodies that’d normally show up in a 500 error. At a minimum, you should be using something like this.

• Tip: Make sure your hosting environment can send out emails! (otherwise, you’ll never know about these problems…eek!)

However, in the last year, the Rails community has seen two options, Exceptional and Hoptoad introduced for managing exceptions. Our team has only used Exceptional so far, because our good friends at Contrast invited us to be early beta-testers for their new service. We love the Exceptional’s integration with Lighthouse, which is the bug/issue tracking application that we’re currently using. With Exceptional, our team is able to search through and track exceptions in our application and have a good meter on the overall health of our application. This solution works so much than the email-based approach because we can track which exceptions have been opened and sent to Lighthouse and if they’ve been closed by someone already.

I’ve heard great things about Hoptoad as well, but have yet to test it out. Would be interested to read a comparison between the two and am curious if there are other services for this currently.

Non-default 404 and 500 pages

Honestly, this is one of those things that we tend to forget about until the last minute. When you’re launching a new project, you’re bound to have a bug and/or a few broken links not accounted for. What you want to avoid is having your customers end up on an unhelpful page that looks like this:

It doesn’t take too long to put something together that is a bit more helpful for your visitors.

So, do yourself a favor and add a ticket for your designers to design a custom 404 and 500 pages to replace the defaults that are provided by Ruby on Rails in public/.

Hold your client’s hands

If you’re working with startups, do remember that this is quite possibly their first launch. It’s important to remember that they’re going to be going through their own spectrum of feelings and it’s our job to help get them through the process with an eased mind. Show them that you have things covered, that things are ready to go, alert them when things pop up… in a nutshell. Keep them informed about the challenges and do what you can help to manage their stress. If they’ve just contracted you for an extended period of time to help get their big idea designed and developed, remember that this launch is just the beginning of the race for them. They have a big journey ahead of them and you just helped them get their new car engine built. Make sure they know that things are likely to breakdown along the way, need to be refueled (refactor! refactor!), and need service repairs. The worst thing you can do is set the expectation that nothing will go wrong once their application is released into the wild. They need to budget for this early on so that they can pace themselves after launch. (this is a big topic definitely worth of it’s own post)

Just remember that this should be a big celebration for your team and client. Remember to celebrate! (and then follow it with a retrospective)

In Conclusion

As mentioned, these are just a handful of things that we have learned to avoid overlooking (through trial and error). I’m hoping to share more thoughts on launching in the near future and would love to hear from all of you on things that you’ve come across. What works? What doesn’t work?

What is on your checklist for launching successful projects?

Related Articles

• The Art of Delivery, part 2
• Agile development begins within…
• Audit Your Rails Development Team
• Embracing Chaos, part 1

I’m sure that most of you heard the news that Google is releasing a new web browser named Chrome. Their comic for the announcement was very refreshing and entertaining read. Granted… nobody that I know has seen it (as of today)...

For me, I’m really interested in seeing what they’ve done to hopefully improve some of the short-comings of the user experience through their interaction design process. For example, tabs containing their own url/search fields sounds refreshing (I really dislike the hierarchy currently). Also, I’m really looking forward to their dashboard-like default page.

From a web development standpoint, it definitely raises questions about what we’ll be able to do in the coming year(s).

What are your initial thoughts on this? Discuss…

Update: Gary came across this amusing quote from a response by a representative at Microsoft.

“The browser landscape is highly competitive, but people will choose Internet Explorer 8 for the way it puts the services they want right at their fingertips … and, more than any other browsing technology, puts them in control of their personal data on-line,” Hachamovitch said. (read article on CNN)

I’m really not sure what that even means. Don’t we already have our online services at our fingertips? I suspect CNN interviewed the wrong person.. because this person said nothing.

Update #2: Only a PC version available… OSX / Linux are in development. Oh well…

Throughout our design and development process, we’re working around areas of the site that are not yet implemented but we also want to be able to allow our clients to demo their application. In an effort to manage their expectations, we need to be careful about what we link to. If a page/widget isn’t ready to be demo’d yet, we should avoid providing pathways to get interact with or navigate there. However, when we’re implementing HTML/CSS for pages, it’s sometimes makes sense to not hide certain things on the screen.

For example, let’s suppose that you’re working on the primary navigation of an application. You know what the other sections are going to be, but you’ve only implemented a few of them so far. Your HTML/CSS person is working on the design for the navigation and wants to have them be proper links… even to pages that don’t yet exist.

One option, which is quite common, is to provide a link with href="#". This works to some extent, but when people click on things, they naturally expect something to happen in response.

This approach doesn’t mesh well with our team as we don’t really want to field any questions like, “the navigation links are all broken. Nothing happens!”

So, a pattern that we’ve been using for a while is to trigger a javascript alert for every link within an implemented area that is linking to something that isn’t yet implemented.

Let’s take a really basic javascript function like:

# public/javascripts/application.js
function unimplemented() {
  alert("NOTICE\n\nThis feature is not implemented yet. Please check back again soon!");
}

This allows us to do the following:

  <a href="javascript:unimplemented();">link text</a>

When someone clicks the link, they’ll see a typical javascript alert message. This informs our clients/beta testers that we’re paying attention to what works and what doesn’t.

Let’s take it a step further and push this into a view helper.

# app/helpers/application_helper.rb
def link_to_unimplemented( link_text, *args )
  link_to_function( link_text, 'unimplemented()', *args)
end

Now, we’re able to use link_to_unimplemented and pass any arguments that you’d pass to the default link_to view helper.

<%= link_to_unimplemented( 'link text', { :class => 'link_class_name' } ) -%>

Now our web designers can go about their work and use this helper as necessary.

An nice benefit for doing this is that we have a pattern that we follow so that we can rely upon to make sure that we don’t forget anything. This is the equivalent of adding @TODO@s throughout our code base.

If we search through app/views for ‘link_to_unimplemented’ we should be able to prevent missing any broken links. In the next screenshot, I’m using grep with colorized matches.

As you can see, we have something left to implement in that area of the application. :-)

This has been one of those lightweight patterns that we’ve been able to adopt and it’s definitely helped manage the expectations of our clients throughout our development process.

I’d love to hear your thoughts on this. How does your team handle things like this?

Related Posts

• Designers, Developers, and the x_ Factor
• Spice up your Terminal with colored grep pattern results

Today, I thought that I’d give FogBugz a quick trial. A few of our Rails consulting clients use it and I’m hearing that others are as well.

Along the way, I’m bringing one of my favorite tools so that I can share some things thoughts (visually) along the way.

Signing up for a free trial

My first impression of FogBugz was, “nice homepage design… but what is that screenshot of?”

I’m not a designer, but the interface in the screenshot isn’t jumping out to me as something that you’d expect to see in a modern web application. While I appreciate the default browser colors for links (this is really important)... I think they could have found a better way to distinguish which bug links you’ve previously viewed. It’s very likely that you’ll most bugs many times, so having the color be different might not make sense in the same way it would when reading content on a web site. Again, I’m not a designer and I’d be curious to hear from a designer on this. Just something that I initially thought.

Okay, this sign up form seems really easy to start with. I’m used to free trials being really simple to get going. So, I enter in my sub-domain selection and provide my email address on the following page so that they can confirm that I’m legit.

(several minutes later…)

Okay, this process required me to jump from my browser to my email to my browser back to my email and then back again to my browser. It’s really frustrating for an application to force me to go back and forth between my browser and email client. I think the initial email is something I can cope with, but I found it a bit silly to have to wait for another email to receive a link to login to my new account, especially considering I already knew the URL as that was the first thing that I provided. The application could have provided the link (or redirected me) to the following form, which I had a few things to comment on.

At first glance, this might not seem like much… but I’m becoming more and more disappointed by the choice of language that we’re using in applications. First of all, this is the first time that I’ve seen this page. I’m not changing my password… what you’re really asking me to do is, “Create (or set) a password.” There are other verbs that you could use here, but change really isn’t appropriate. Also, choose doesn’t work here either.

  chose; choos·ing.
  –verb (used with object)
  1.    to select from a number of possibilities; pick by preference:  

What am I choosing from? Again, you’re asking me to create a new password.. not change one and definitely not choose one, unless you’re implying that I should choose one from a collection of ones that I already use.

One might argue that we can make an assumption about what they mean, but it’s simple problems like this that can seriously confuse people that use the software we design and develop. As people interact with minor problems like this, their perception of the software as being helpful and friendly… can quickly deteriorate.

Okay, so that was my first several minutes of getting into my new FogBugz account.

Coming soon… Robby will share his thoughts on managing bugs with FogBugz.