Website Launch Checklist

Launch day is one of the scariest and most stressful times in web development. Getting everyone on the same page in terms of what's going to happen and when it's going to happen goes a long way in making the entire process smoother.

Things are less likely to go wrong and people are less likely to start throwing recriminations around if the processes for deployment and dealing with issues are well documented.

The following is a list I've been building up in my notes of some of the things that should be done in preparation for launching a new site or major revamp.


Client/Product Owner 

• Site and content has been signed off by appropriate people.
• Any potential downtime and exact release times have been confirmed and communicated to everyone involved. Involved means everything from developers to people in marketing who organised that snazzy TV promo.
• Everyone knows who's in charge of what and where notifications need to go for any immediate problems. This process is organised with designated communication points so that the deployment team don't get flooded with notifications if things go wrong.

Look and Feel

• Images have appropriate Alt Text for both accessibility and SEO.
• Pages have sensible Titles.
• Pages have Appropriate Meta Tags.
• Favicon is in place.
• Friendly error pages, particular 404 and 500 error pages.
• Contact Us page has appropriate details.
• Copyright info is in place.
• Someone has gone through checking for spelling and grammar errors etc.
• At least some manual testing has occurred to catch any outstanding issues, e.g., weird edge cases or black text on a black background.

Server Setup

• Backups are running at appropriate intervals and the steps that are needed to recover using them are documented.
• Transfer DNS at an appropriate time. Make sure something is in place to handle delays in propagation. 
• The "www." subdomain is redirecting appropriately, or the reverse if you prefer www. domains
• Monitoring service is checking site uptime (Pingdom or similar).
• Something is capturing application errors and reporting them (A service like Airbrake or something better than the default system logging).
• Deployment process is automated, fast and takes one click or command. You need to be rolling out quickly and any fixes need to be able to go out fast and reliably as well.
• Set up resource monitoring (Munin or similar).
• Make sure the site comes back up after power cuts/crashes.
• Penetration testing if necessary. Level of security testing should be agreed well before launch as it will affect release schedules.

Dev Tasks

• Analytics are in place.
• Larger sites have a sitemap.xml for bots to read.
• Automated tests are in place. The level of automated testing being used should have been decided early in the project.
• Testing has occurred across browsers that are being supported. Browser support decisions should have been made at the beginning of the project.
• Devs know what the expected release load will be and they have resources in place to handle it.
• The site should be load tested for the expected load. At the very least, it should be checked with reasonable load for any performance anomalies.
• Set up a robots.txt 
• Run a website performance tool such as Yslow over the site. 

Other Tasks

• Put a catch-all email address on the domain.
• Wrap-Up and review meeting with the team.
• Write a case study and/or take some pictures to add the site to your profile.
• Party

Did I miss anything? Leave a comment and tell me about it.

Ruby on Rails Coding Standards

This is a list of Rails coding guidelines that I've been putting together and generally suggesting are good practice for Rails development for a while, as well as a couple of Gotcha's that it's very easy to miss. Hopefully some people will find it interesting or useful.

Basic Stuff:

• Two Spaces, No tabs
• Keep lines to a reasonable length(80 characters is classical but 100-120 is probably acceptable with screen sizes these days)
• Method names should be intuitive and meaningful
• Variable names should be intuitive and meaningful
• Don’t commit commented out code - It makes everything confusing and it’s in the version control anyway
• Comment when necessary - If comments are necessary check that your code couldn’t be simplified first
• Maintain application style - If it’s a new application then be Railsy.
• If you want your application to survive then prioritize making the code easy to understand and navigate.

Code:

• Skinny Controllers, Fat models - If a controller method is more than a few lines long then think very carefully about what you’re doing.
• Views should have very very little ruby in them and certainly shouldn’t touch the Databases.
• If something requires more than one commit then do it in a branch. Almost everything should take more than one commit.
• Use plugins only if they’re exactly what you need. Do not cargo cult.
• In Ruby Regexes \A is the beginning of the string and \z is the end, ^ and $ also match the beginning and end of lines. You almost always want \A and \z, especially in input validations.
• Try to keep initializers limited to config.
• Make sure your calls to the database are including everything they need to in the original call, N+1 problems are way too common in most rails apps.
• RESTful controllers, they’re much easier to navigate and generally more secure.
• Ternaries (?:) are good if they fit on one line (remember the short lines rule).
• ||= is good
• def self.method to define singleton methods not class << self
• Select the appropriate columns in a database call if you don’t need everything and the table has lots of data.
• Migrations go up AND down - they maintain database structure not data.
• Test first all the time unless you’re prototyping. If you’re prototyping then either you throw the code away afterwards or you have to convince someone else to write tests for all of it.
• Blocks should be {|x| ... } on one line and do |x|...end on multiple lines. .
• One line if statements when appropriate.
• A ridiculously large number of Railsy plugins use single table inheritance for things that it will turn out that you want to search over, avoid them if you want to be able to scale at all.

Security:

• Rails has built in SQL Injection protection if you do :conditions => [“something =? “, thing] - Use it
• h() to escape user inputted content in all pre Rails3 apps.
• Use attr_accessible to whitelist variables that should mass-assignable.

These are guidelines, break them if you have a good reason. Feel free to leave any extra suggestions, I've probably missed stuff.