Thursday, December 30, 2010

Goals for 2011

Release Rabid Tech's first app.

Contribute to more open source.

Have Rails Camp NZ go well and also make it to the Aussie ones again.

Start building up some more passive income streams, small weekend apps that actually monetize etc. I have a new todo app idea that I'll have a look at building sometime soonish(The todo app market is clearly not saturated enough).

Edit my Nanowrimo novel from this year and look at trying to actually finish it. We've got a decent bunch of people carrying on from nano this year so might be able to get some more momentum behind it this year. My writing has improved each year as well.

Read more and widely, particularly:
  • Some Proust
  • One of Chinese four great classic novels, probably Dream of the Red Chamber given I already have some familiarity with Romance of the Three Kingdoms and Water Margin
  • More History in the areas I'm unfamiliar with. Byzantine to start with.
  • Finish Structure and Interpretation of Computer Programs including most of the excercises.
  • More Steinbeck
  • Godel, Escher, Bach: An Eternal Golden Braid - I've been meaning to read this for ages.
  • A few more biographies - I really enjoyed Richard Branson's this year.
  • My usual mixture of Sci Fi and Fantasy.
Blog more - at least twice monthly.

Watch more good movies, with a minor focus on getting up to a convincingly large portion of the imdb top 250 list. I'm up to having watched 112 of them so far and I'm finding the more obscure or older films that place on the list to be particularly enjoyable.

Do some more teaching Rails to people, either mentoring or more workshops.

2010 Achievements

A few of the interesting things I did in 2010 in more or less chronological order.
  • Started off flat out for the initial release of Sponsafier. By far the highest traffic site I've worked on with peaks of 26000 hits per minute.
  • ate up a week and had lots of interesting things, including the first time I came across Albany High school and their awesome open source infrastructure.
  • Had an intra-office showdown between myself and Mike Lowery on Agile Bob's agile question contest. Plenty of trash-talking was had. In the end I came out victorious on the basis of being more novel and/or crazy.
  • Attended Webstock, got a sweet bag. Rives was pretty awesome too.
  • Became a Certified Scrum Professional (Which, apparently, is better than a Certified Scrum Master even though it doesn't sound like it).
  • Started thinking about planning for Rails Camp NZ
  • Organised Rails Bootcamp
  • Attempted the Milford Track. It was slightly damp.
  • Made Technical Lead at 3months
  • Ran a Rails Workshop at Victoria University
  • Worked a lot and posted lots of overtime, outside stuff went down a bit though.
  • Settled on a location and started working on selling tickets for Rails Camp
  • Created a MUD in Node.js for the Node Knockout
  • Resigned from 3months to start Rabid Tech
  • Did the Rails Rumble and created a news aggregator
  • Did some contracting while getting going with Rabid Tech, unfortunately it took up a lot more time than I meant it to and delayed other things.
  • Attended the NZ Open Source Awards - I had code in three different finalists.
  • Gave a talk at Wellrailed on Rspec 2 and TDD - Unfortunately the videoing didn't work.
  • Wrote a novel for Nanowrimo - Lots of editing still to do.

Sunday, December 12, 2010

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.

(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)

Monday, October 18, 2010

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.

Thursday, September 30, 2010

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?

Sunday, September 19, 2010

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.

Tuesday, September 7, 2010

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.
  • 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.
  • 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.

Tuesday, August 31, 2010

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.

Sunday, August 22, 2010

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.

Sunday, July 25, 2010

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.

Saturday, May 8, 2010

University Students and Rails

My mentee from the summer of code is vice-president of the VUWIT society at Victoria university and invited me up to talk about Rails, so on Wednesday I went up to the university and spent about three hours teaching 40ish students Rails.

I made some changes to my slides and the general format of the talk so that we could get through more stuff. I focused more on scaffolding the app up initially and then working on some basic stuff to relate movies to reviews and work with the two in combination. The scaffolding approach was definitely a lot more successful than going with building the app up from scratch in terms of getting to a point where stuff could happen sooner.

In general it felt much smoother than my last practical session on Rails and I think we covered enough material for people to be able to get started with Rails decently. Having consistent versions of Ruby and Rails is particularly good when you're trying to run something with a large group of people and when things go wrong you can often broadcast the fix to everyone.

The big problem this time wasn't the content but the lack of anything big and impressive looking. It's relatively easy to explain to people who've worked with large apps in PHP or J2EE why the architecture and style of Ruby and Rails is good and avoids problems they will have come across.

For students who haven't worked on (m)any large apps, doing some basic functionality in Rails just looks like a bunch of really simple stuff and they're not impressed or excited by simple things. It seems I have to try and strike a balance between informative teaching and showing off tricks to convince people that stuff in rails is cool.

I'm not willing to take a "here's some magical code for you to copy paste and now you're an awesome programmer" approach to it as I think that leads to a bit of a cheap high, I certainly don't want people to be encouraged towards cargo culting code. I do give people code to copy out but only after I've explained the function and goal of each piece(with the exception of some config stuff).

I'm currently considering, for the next time I do something like this, either spending 15 minutes going nuts on the projector and adding as much functionality as I can very quickly with lots of integration with other services, or spending a few minutes showing how intolerably horrible some of the other solutions to these problems might be. The showing off idea is probably better, but pulling out scads of bad code to insult might be more fun for me.

In the end, the biggest sale will probably come later on if they happen to want to do something that could use Rails. As long as people have the groundwork they're much more likely to pick it up then, a project is really what you need to do to learn Rails properly anyway.

Wednesday, April 14, 2010

Rails Bootcamp Wrapup

Last Saturday Nahum Wild and I ran a Rails Bootcamp (kindly sponsored by 3months and youdo) here in Wellington aiming to introduce developers to Rails in a workshop like format. For both of us it was our first shot at a workshop like format instead of straight presentations and we learned a lot in the process.

We decided to run the workshop on Rails 3 beta instead of 2.6 since we thought it would be more use to new developers to learn what would be current in a couple of months than something that would be changing almost as soon as they learned it. It's hard to say whether this was a good idea or not though, the rails beta was unfortunately still a little bit too liquid to be able to handle easily and the support across operating systems led to us having multiple different versions of ruby deployed amongst the developers. Luckily, it's unlikely to be a problem again for quite some time.

We aimed to start generally helping people install rails(getting up to the stage of a running server and database) from about 9:30 and start the workshop proper at 10:30. This went reasonably well getting everything installed, mostly via RVM for mac and Linux and a set of detailed instructions for the windows people. Strangely windows turned out to be the most problem free for installing on. On the other hand Linux was nightmarish when dealing with some of the requirements for rails 3 and ruby 1.9.2, a complete reversal of the ease of installing the stable versions.

We started with a brief talk and some disclaimers about beta software etc. I then got into the actual coding with a whirlwind tour of ruby, introducing the bare minimum necessary to be able to do what we would need that day in rails and getting them to play around in IRB a little. Some people would have preferred more depth, ruby is a complete language on its own though and teaching it properly concepts and all would have easily eaten a workshop all by itself. Really though, Ruby is very accessible and I hope that people will be able to pick it up from docs and bits and pieces(although I do recommend going back and looking at its more advanced features later on).

Once we'd gone through some basic play in IRB I moved on to getting started with Rails. My goal was to get a basic CRUD version of a registration for a site going in Rails. I coded on a projector using gedit with a file tree down the side so people could see what I was working on and where. This seemed to work reasonably well and I only opened files in vim by accident(habit) twice.

I avoided using scaffolds as I think they're a little too magical to be much use for learning and one of the major things I'd heard from people who had learned Rails was how really getting the hang of MVC and to a lesser degree REST had been the hardest part of understanding Rails apps. So I wanted people to be working with a more nuts and bolts level of Rails. I worked through generating the models, writing and running migrations, generating and controllers and writing actions, setting up the routes to writing the views.

Progress was slower than expected and I did at one stage accidentally create rather a lot of chaos by leaving off a rather important s from generating the controller. It took a good 10-15 minutes to sort out all the oddities that caused and I got further confused by a change in how resources deal with pluralization that I hadn't known about(working on the edge is exciting). Once we'd sorted it all out everything seemed to run smoothly again and we'd managed to see just how magical rails can be at times with its guessing what you might be meaning when some incorrect pluralizations worked and others didn't.

Around this point in the day(2pm'ish) we realised that we had far too much material to fit into the day given our current pace. It's very easy to forget how much is actually going on when you're familiar with a language. We slightly modified the depth of the presentation and slightly later I redirected my attention to just getting things prepared for Nahum to be able to pick up with his portion of the demonstration, unfortunately this lead to a bit of extra chaos.

I decided to whip out the last few aspects of the site that would make it functional, edit and delete and some links. This went well until we hit delete which I hadn't really thought about, but doing it with a HTTP delete actually requires javascript, which the lack of a default application layout in the new rails generator means it never ended up being included. After a couple of minutes of confusion regarding this I went with just showing off a named route to the delete method in the controller, which meant we at least covered a relatively important part of the router functionality that I hadn't got around to earlier. Although, the routes.rb file is particularly well documented in Rails.

I handed over to Nahum and he went on for another couple of hours with some data manipulation and a very brief overview of some of the stuff we hadn't had time to cover in depth. By the time he finished we'd been coding or talking about code for a solid nine hours.

Overall, the response to the workshop was very positive and I learned a hell of a lot and will be looking at a number of changes that would make it work better. In particular we need to look at splitting it out into more of a series of smaller workshops so that things have time to digest and people can have a chance to work at their own speed.

Possibly setting up an application and fiddling with particular bits one at a time to see their effect would also allow us to work more smoothly. It is, unfortunately, very difficult to give people much in the way of things to do on their own until you've got the full set of code in place to go from the model to the controller to the view. People only started being able to work on their own near the end of the rails segment. It was pretty great to get to the point where we started seeing the apps differentiate and have odd new things added.

I'm looking forward to doing a non-beta version of the workshop with some non-beta software in the near future and getting a chance to see how I can apply the improvements I've thought of since the bootcamp.

Friday, March 26, 2010

Milford Track

I was told the Milford track was very relaxed and easy, this is probably true most of the time. Our particular attempt featured significantly more unpleasant rain than usual.

Day 1 (5.5km)

Walked to first hut, track was easy and scenery was idyllic.

Day 2 (8km)

Over night nearly two meters of rain fell on the track, the river rose significantly and a few slips occurred. This included a slip in Milford that cut off the exit of the track and meant those already at the last hut had to be helicoptered out.

For us, the river rising meant we were trapped at the first hut for the day although we did wander up the path a bit later to survey some of the damage. Over night the track had gone from an amazingly manicured and graveled track to something muddy and familiar to most kiwi trampers.

(The bridge was no longer in a particularly useful place and the stream had moved onto the track.)

Day 3(28.5km)

We were told at this point that we would not be allowed to finish the walk due to the lack of ability to leave at the other end. The best they could offer us was going to the second hut that day and then all the way out the way we came on the last day.

Although we knew we had to end up at the second hut that day we also wanted to get over the pass, so we did a longer day and made it up and over the pass to the pass hut before coming back to the second hut. Unfortunately the weather was terrible on top and we had close to no visibility up there.

Day 4(22km)

There was a chance if the rain had kept up we would have been helicoptered out, it stopped about 2AM though and we were destined for an unpleasant walk out as it started up again in the morning.

We only had to be back at the dock by 5pm to catch the boat. So we hung around at the hut until about 10:30 hoping the rain would stop.

Armed by the knowledge that a boat would be waiting we tramped out in a non-stop manner and hit the dock before 3pm. Just in time to see the boat pull out into the middle of the lake to give the barge room to be loaded by helicopter. We spent the next half hour staring forlornly out at the boat bearing hot coffee and tea, and getting buffeted every couple of minutes by the helicopter dropping things off.

Eventually the barge left, the boat came back and the coffee was hot.

New Post comparing linux conf to Webstock up on the 3months blog.

I have a new post up at the 3months blog talking about some of the stuff from and Webstock. Includes swag comparison:

Monday, February 1, 2010

Cutting Corners

Someone reminded me that there was little discussion of cocktails in a blog with cocktails in the title. This post rectifies that issue.

I advocate regularly for taking the quick fix over a difficult solution when it seems appropriate. There are a huge number of cases where good enough is just right. But you need to pay careful attention to whether it's really the case that something is good enough, not quite right or just plain inefficient.

My favourite cocktail is the Manhattan. In its proper form it contains:

2-3 parts Rye whiskey
1 part Sweet vermouth
Dash of bitters
A Maraschino Cherry

Made right it's brilliantly balanced drinking with some fantastic flavours. Unfortunately, there is a large risk of making it too sweet and a number of bars don't stock the exact ingredients or would prefer to use cheaper ones. Instead they introduce a few modifications to try and make the drink anyway. Some of the modifications can be plain wrong, bourbon sometimes replaces the rye whiskey and sends the drink way into the too sweet category. While others are OK if used sparingly but should not be used to excess.

Some of the common modifications that seem to spring up in relation to the Manhattan include: cheaper Canadian whiskey(often Canadian Club) instead of actual rye, Maraschino liqueur instead of the cherry and low quality or aged vermouth(as a relatively low alcohol drink, vermouth does not age well and turns into a syrupy mess over time). The problem with these changes isn't that any one of them ruins the drink(although it certainly lowers the quality) it's that they all add sweetness so one cheat I can live with, more than that and you have an overpriced sickly mess in your hand.

When I was in Melbourne recently I went to a bar with some friends and at some point ordered a couple of Manhattans. The venue seemed like it was of a standard to cope with making a decent cocktail; however, I got something back that fitted the definition of sickly mess. They'd clearly replaced the cherry with Maraschino liqueur and probably replaced the rye with Canadian Club. It was also garnished with an obscenely large slice of lemon rind. It was quite possibly the most disappointing cocktail I've ever had.

It's a sign of skill to be able to cut a few corners and still get everything to an acceptable standard. Learn to balance these things, be a perfectionist or give people free drinks.