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.

Rspec 2 at Wellrailed

I gave a talk to Wellrailed at the end of October on Rspec 2 which drew the largest crowd that Wellrailed has had in a while. I was hoping to put a shiny video of the event up here, but unfortunately the sound didn't come out. Here's a brief recap of what I said instead.

I had two distinct segments in my talk in that I started off talking about TDD for a while to try and convince people of it before moving on to the nitty gritty of Rspec 2. So that they could really understand some of the philosophical stuff that goes on in Rspec and how it's best to work with it. Using a tool right is by far the best way to avoid coming across difficult problems.

There was quite a spread of Rails and Rspec experience in the crowd from a couple of people who knew very little Rails all the way up to people with massive test suites that wanted just any useful extra things I could throw their way. I think I managed to give everyone something but it is one good point about larger gatherings like Rails camp (Tickets available now for Rails Camp NZ) that you have enough people to split up and focus on things a bit more.

One of the things that seems to be happening with Rspec is that it's getting a larger number of nuanced ways of matching things that make test failures easy to understand. It's much easier to see what's gone wrong if the error message is " should be valid but is not" rather than "false should == true" as would happen if you just asserted the result of valid. By having an intuitive error you'll start thinking about what might be wrong and the possible fix sooner which speeds development up. Unfortunately this plethora of options does make the system much more scary for someone just picking up the framework.

It was also a great opportunity for me to pick up some new shiny Rspec tricks. I'm particularly happy with the addition of importance filters for managing which groups of tests run when in Rspec. Being able to easily have you default autotest not run slow tests or ones that rely on some external resource is a vast improvement for anyone who has had to deal with the growth of their test suite on a larger project.

I continue to happily proselytise TDD. It's great that more and more people are open to it and joining in and I didn't have anyone loudly disagreeing with the concept for a change.

Well

(Yeah, the slides are pretty horrible. In my defense I mostly stayed on a couple of the more content free ones while I talked. Going to have to look at making better ones now that I've read Presentation Zen though)

Agragr - Rails Rumble 2010

Last weekend was my third Rails Rumble. Michelle, Kelly and I set out to build a social news aggregator aggregator. We called it Agragr.


Agragr is only really one page. We worked to pack in as much information as possible to give people a fast overview of news as it comes in. The simplicity and density of the information on the page along with the convenience of it polling for new news and notifying you in an non-obnoxious manner is nice. I can leave it open when I go out and when I come back I know exactly what new stuff popped up without trawling through links I've already read on a multitude of different sites.

This Rumble was much more pleasant and relaxed than the previous years. We had a smaller idea and didn't end up cutting features on Sunday like we have in the past, we even had time to do some testing and caught a few of the weird little bugs that snuck in. Delivering something that's complete and useful is a much better feeling than pushing out something with niggling bugs.

Having a team of three was also surprisingly convenient. With a designer, a javascript dev and a Rails dev we didn't end up stepping on anyones toes and always knew who to ask about something. Filling out the team might have let us broaden our target, but we've learned that that can be pretty dangerous when you only have 48 hours.

I've normally learned a lot from doing the Rumble. That was slightly less true this year, although there was a good deal of shiny new Rails 3 things that it was a good chance to use. The new scoping and Arel methods made writing all the filters much much easier and cleaner than filtering has been in the past.

This Rumble was fun and relaxed. For any future Rumbles I'll probably continue with the idea of building small functional utilities that I'll use instead of epic beginnings of larger projects. Less stress and you can sleep, so you don't lose the next few days of the week to recovery.


The following is a brief log of what I did during my waking periods of the competition:

Phase 1(First 13 hours)
Set up server, source control, base app and tell people where everything is to start putting layouts etc.
Wrote migrations and some simple models.
Generated seeds for default topics and sources.
Wrote RSS parser for HN, rake import tasks, and Json importer for Reddit.

Phase 2(Central 19 hours)
Fixed RVM and passenger issues.
Wrote all the front end stuff for spitting out links.
Worked out all the session details for storing filters and topics.
Sorted out cron tasks for server.
Worked on scoping all the filters with shiny new Rails 3 database methods and scoping.
Generecised importers so that we can easily add future RSS feeds and Reddits.
Fiddled with timestamps a whole bunch to get the right things popping out on the page when it's polled.

Phase 3(Final 4 hours)
Wrote a bunch more filters.
Sorted out some bugs with updating topics and filters.
Testing and helping with bits and pieces.
Tagged final release.

10 Reasons You Should Go to Rails Camp

Rails Camp is an event where a bunch of Ruby hackers get together for a weekend out of reach of the Internet to hack, drink and be merry. I'm currently organising RailsCamp New Zealand for March 18th -21st 2011, but this list could apply to any Rails Camp. (side note: it would also be great if events like this sprang up for other languages as well)

10) Projects

Rails Camp is a great place to start a project, work on something or just help out on cool things. You know everyone else is a valid target to be recruited into your latest scheme to build an open source can opener and you can kick off quickly because everyone has at least one language in common. A weekend is plenty of time to get something cool built when there's a bunch of skilled people around and plenty of urge to build things. Depending on how much the organisers have chased up sponsors there might even be prizes for best thing.

9) Price

Rails Camps are cheaper than conferences. Lots cheaper. A bunk bed and decent quality food for three days does not need to cost much. So you can save money or spend that extra cash on visiting Rails Camps that are further away.

8) Hacking

At Rails Camp people write cool programs for fun. So even if you don't want to build a whole project there are plenty of little things you can do. Write an app to swing the vote on the shared music player toward the excellent Rick Astley or an AI for some kind of crazy Rails based game.

7) Time

Rails Camp just keeps going until the end of the weekend. You don't get kicked out of the auditorium and herded to dinner, you can keep doing whatever and run off to sleep when you want to. If you're in a talk and everyone gets really excited about TDD then that talk can go till 3AM if you want it to.

6) Fun

Rails Camp is fun. There's plenty of freedom and only the lightest of self-organised scheduling. So everyone can do what they want, which leads to more happiness. Nothing like a conference where you suddenly find you don't care about whatever the next event is and you find yourself stuck eating the leftover cookies from morning tea, instead you can wander over to someone building something, explore the countryside, play a game of werewolf or whatever.

5) No Internet

There is no internet. You get to escape for a while, you tell people you're going to be at Rails Camp and then you get to really focus on the event. Also, unlike a conference, you'll find that everyone starts talking to each other instead of liveblogging the event or tweeting about the weather.

4) Relaxation

It's an event with a lot of freedom. You're going to be in nice surroundings and out of the city. Stuff will be happening all through the weekend so there's no pressure to be up at a certain time. If you miss someone's talk you can just grab them and ask a couple of questions anyway, it's not like they're going to leave before the weekend is over.

3) Learn

There are lots of really good developers who come to Rails Camps and it's one place where they're all happily doing things and easy to access. Whether you go to talks, work with people on something or just ask a question. People there are knowledgeable, friendly and willing to talk about things that they might not be willing to share at a more public venue. With a centralized focus on one language there's going to be far more of direct interest and use to you than there might be at a broader event as well.

2) Drinking

You can drink, most people like drinking.

1) People

People who go to events like this are awesome and great to be around.

You want to be awesome too don't you?

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.

Summer of Tech Hackfest

Wandered down to the aftermath of the Summer of Tech hackfest on Saturday. The hackfest featured 6 teams of students building applications from 11AM to 4PM in Rails, PHP and .net. There were clearly a number of talented individuals present, but what I found most interesting was the different approaches and goals of the teams depending on their technology.

The Rails teams both created applications from scratch. A very simple beginning to a bug tracking application and a significantly more involved first step to building a course search and management tool for searching for and selecting a course load based on a set of constraints. I liked these, particularly the second one as it was a useful thing that didn't currently exist(and still doesn't, they're nowhere near done).

The PHP teams both seemed to be writing extensions for existing CMS'y things. Good stuff there, but without knowledge of what the systems already did it was hard for me to judge. The tacking on bits and pieces to other things amused me in the way that PHP always does though.

The .net teams were probably the most technically impressive in this particular case (I believe it may actually be a language that the Universities teach). One team produced a twitter client, which seemed of reasonable quality though I still have no real knowledge of what exactly was already present in .net for it. The other .net team was the stand out though, with a multi-player pong implementation over tcp/ip that suggested a particularly impressive development pace to get out the door in 5 hours. And Pong would win on geekery points anyway.

Everyone appeared to have put in a solid effort and the mentors I talked to were positive about the day. Hopefully some of the teams will continue with their projects, I'd particularly like to see the finished course selection site. Really, I suggest to everyone they should have side projects.