A Rubyist visits Kiwi Pycon

It's an interesting experience going to a python conference for me, particularly when I was speaking at it as well. I have done some Python, but I'm mainly a Ruby person, which made there being something of a competition going on between the two, at least in the minds of some of the practitioners, all the more entertaining.

It feels very reminiscent of the Emacs VS Vim debate, the languages are so similar that it's really a bit ridiculous the comments that get flung back and forth on occasion. It seems to be the Pythonistas declaiming Ruby though, as I don't notice Rubyists really commenting on python. Apparently the Python people still think ruby is all monkey-patching and crazed metaprogramming, something that I think Ruby has managed to outgrow over the last few years as more people realise it's a bad idea.

Coming out of Kiwi Pycon I think the best thing to do would be for the languages to steal more ideas from each other, they're so similar in capabilities that things seem to transition back and forth very nicely. The web programming talks at Pycon seemed to be lagging about a year and a half behind Ruby in terms of what the new cool thing is, while the more sciencey areas are still where Python is dominant.

Audrey Roy's talk really reminded me of how strong Ruby has become in terms of deployment tools, from capistrano to Chef and Puppet we have some really powerful and well built tools. Unfortunately they're not making their way into Python land as well as they should due to a certain amount of resistance to the language. I hope more python people will try them out though, as they really are very good and it's not the kind of tool where it really matters what language it's in.

I got to hang out with Mark Ramm, who is currently tasked with restoring Sourceforge to its former glory, for a few hours on Friday night and he was a fascinating guy. It sounds like there has been some really good development happening over there in the last few years in terms of building up to being a toolset that really empowers open source. Mark also gave some of the best talks of the conference including an excellent session where he powered on despite the departure of his laptop from the realms of the living.

My talk on the clouds went pretty well. It was a lot higher level than the other talks that had happened so far with only a couple of slides of code. The other morning talks had seemed to follow an "All Code. All The Time" policy and I was a little worried that I'd missed the level of the event, but then there were a bunch more higher level talks later on. I got a decent amount of positive feedback and one guy who came up, looked slightly disappointed, and said, "I thought there would be more python". On balance, I'm pretty happy with that.

I ended up busting out my recently purchased remote for my presentation and also lent it out a couple of times as there wasn't one supplied, which was probably a slight oversight as I think that the speakers using it were able to give much better talks. After borrowing it, Eric Light said it was his first time speaking like this and then proceeded to give a very slick talk on all the ways he managed to screw up contracting out a web development job.

Overall, it was a well run conference and attracted an impressive number of people for a language specific event in NZ and the organisers have my congratulations. I really enjoyed the chance to hear a lot about all the cool but slightly different things that are happening over in python land and I didn't feel like I was hearing mostly things I already knew like I have with some of the more broad conferences I've attended recently.  I would have liked slightly more coffee vouchers.

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.