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.

A Weekend With Node.js

Last weekend was the Node Knockout which I talked about my preparation for last week. 48 hours to develop an application in Node.js. My friend Michelle and I set out to learn Node.js more than win the competition. We did a little fiddling before hand but nothing particularly major. Our particular application was a MUD, something we thought would provide an interesting mix of server challenges and general complexity as well as being amusing to us(we first met on the Discworld mud many years ago).

Working with Node.js is a different mindset from most other application work I've done in the last couple of years. The event driven model requires more thought to get state right, particularly as Javascript's notoriously awkward scope becomes so much more prominent when building a full server application rather than just responding to events in the browser. There is power there once you get going though, and we definitely started churning out functionality towards the end of our 48 hours.

By the end of 48 hours we had an evented server that was serving telnet on port 8000, a webserver and Socket connection on 80 and a crossdomain.xml file on 843. All of this in the context of a single Node instance. This was also where the power of something like Node.js really becomes apparent, we had managed to implement a relatively powerful server supporting a wide array of interaction options in a shared space that a number of people could inhabit at once.

(We also managed to create a suitably crazy design with a late ring-in to do some photo-shopping and logo creation.)

The server was able to handle a number of players all talking to each other and interacting in that space without any particular issue or noticeable performance effect. This is an excellent example of how the Node.js style leads to higher performance by default rather than needing to optimize processes for performance later.

Node.js is straight-forward to deploy given that you run the server as part of the application in most cases so it's easy to move it around and put it in convenient places. Unfortunately we didn't have much access server wise as we had a choice between heroku and a locked down joyent instance on solaris which meant we couldn't do some of the more complex ideas we had for separating out our server processes a bit. But it's definitely something to take advantage of for quick apps in the future, it's rare for efficient and easy to deploy to go hand-in-hand.

I've still got an ongoing gripe with the state of naming in Javascript. Everyone seems to be terribly afraid of using too many letters in their method and variable names, probably due to Javascript's history as something that weighed down the client when they had to download the files to their browser. For more complex apps that don't need to be optimized for size people really need to think about improving communicability over code size, it's much much easier to read complete words the describe what something is.

In the end it was fun, I learned a good deal and, as always, I enjoyed the 48 format. I highly recommend 48 hours of something to learn it and doing at the same time as a bunch of other people means there's an active IRC channel full of all the same problems at once.

If you're interested our code from the weekend is on github, as far as I can tell we had written ~1700 lines of code that were part of the final deploy.

My First Day With Node.js

Today I spent a good number of hours playing with node.js the hip new concurrent evented javascript server that runs on Google's V8 javascript server.

I've been meaning to play with it for a while given its recent popularity and a couple of weeks ago I casually committed to taking part in the Node Knockout(a node.js event inspired by the Rails Rumble) next weekend. Competitions like this are a good way for me to convince myself to learn new stuff and they're fun. The first Rails project I spent a decent amount of time thinking about was for the Rails Rumble a couple of years ago.

So far playing with node has been quite entertaining. I've managed to set up a tcp/ip server running chat and some minor interactiveness in a few hours, with most of those hours having been taking up with upgrading my javascript skills to deal with more complex things than some fancy browser manipulation. I haven't done any serious load testing but it performed well and took up minimal resources under my very basic attempt at hitting it with a few users trying to spam each other.

One of the big issues I initially had was getting stuff to split into separate files nicely instead of massive scripts running the entire system. But that turned out to be relatively straight forward to fix once I got a better idea of what was going where and a handle on module system that node provides.

My biggest rant about node and to a certain degree JavaScript so far today has been the lack of sensibly descriptive naming in a lot of the code floating around. It certainly didn't help my initial understanding that the example chat app had server.js and fu.js with the server initialization occurring fu.js. It reminds me how much I love that the Ruby community has favoured very descriptive names for things.

So far I've enjoyed the change in headspace as well as doing some "serious" programming with JavaScript for a change. I certainly think most people will find their Javascript skills will improve from spending some time with node.js. Hopefully a couple more evenings and I'll have learned enough to not completely embarrass myself during the node knockout. At least there's not going to be any insane last minute problems getting the server setup right.

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.

Slides from my presentation on RoR to VUWIT

Rails VUWIT workshop

View more presentations from breccan.