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?

Software Freedom Day 2010

I spent yesterday at Software Freedom Day(SFD) Wellington. SFD is technically based on the four freedoms that the GNU people have, which I somewhat disagree with as I favour the less precriptive MIT style licences, but that's a discussion that I'll avoid for now. Regardless of what philosophical underpinnings are technically behind the event, it's a great day and people talked about a number of cool or inspiring things.

The highlight for me was hearing about the use of Moodle and Mahara in schools. I really care about education and seeing open source tools being leveraged in schools, where they can assist in learning, customising features and cutting costs, is really great.

Talking of open source in education, there's a big empty spot for open source in the student management system area of education that isn't being covered by anyone at the moment apparently. The teachers I know all seem to be permanently complaining about whatever tools they're currently using for this, so it's probably something that needs looking at. Have to know more about what's required though but could make an interesting side project if I get round to it (People should remind me that I already have too many side projects).

Also on the education front we had a bit of a discussion of the issue of getting more kids(particularly girls) into tech at an early age. Which reminded me to check the progress of hackety hack the open source Ruby program that's working towards helping teach kids to code, originated by Why the lucky stiff. Hackety Hack looks like it's going quite well so I'll take a shot at stick my little cousin in front of it next time I see him.

The talks on Freebase and Opencog lead into a great discussion of various ways of interacting with data and extracting meaning from the web. Freebase is great for providing a decent amount of metadata in a lot of areas. While Opencog either as a whole or as some of its subprojects seems to have a lot of potential for really pulling meaning out of the masses of data that people simply don't have time to add metadata to appropriately. Also, AGI is just really fucking cool.

I also quickly pitched Railscamp and the idea of Camp during the lightning talks, so hopefully that'll get some interest.

Anyway, Software Freedom Day happens every year and is worth going to even if you aren't a GNU loony.

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.