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.

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 Linux.conf.au and Webstock. Includes swag comparison:

http://blog.3months.com/2010/03/26/webstock-vs-linux-conf-au/

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.

Getting Started with Rails

I was asked today what resources I would recommend for getting started with Rails.

Firstly, learn some Ruby. Ruby is a very deep language with a lot of really cool stuff you can do to get the most out of it. You can really make a choice here between learning a lot of Ruby straight away or just learning enough that you can start tinkering in rails. You could easily create an entire Rails application without touching any of the metaprogramming tricks or fancy shortcuts that Ruby provides, it is way cooler if you do use them though.

There are, of course, docs pages for both Ruby and available for day to day use but they're not exactly learning tools. So I'll take the time to describe some of the more explanatory resources available.

Learning Ruby

A good first look is Ruby in 20 minutes.

After that you can try and dive into rails and rely on docs or, if you want a lot more depth in your exposure to ruby, then Programming Ruby by the Pragmatic Programmers(affectionately known as the pickaxe due to its cover) is a very good bet. It has nearly everything you'll ever need to know and is a good read.

Learning Rails

The Pragmatic Programmers also publish what is essentially the definitive introduction to Rails. Agile Web Development With Rails is now in its third edition and reading it cover to cover would not be time wasted.

A second, and free, resource for rails developers are the Rails Guides a collection of detailed guides to most of the major parts of Rails. They're maintained well, although often checking the "edge" version of the guides is necessary to find ones that are currently in draft state. If you can't get your hands on the book, then the guides are probably the best replacement.

The other major area to pick up on before calling yourself a Rails developer is testing. The tradition in the Ruby and Rails community is to test as much as possible. While Rails comes with test::unit, a test framework called Rspec has become the dominant framework in community and is worth taking the time to learn sooner rather than later if you intend to stick with Rails, the website has reasonably easy to follow introductory guides. Cucumber is another testing system that is often used in conjunction with Rspec to create a wider range of tests, you can afford to leave it out for longer though although it is worth learning about(and using) eventually.

Broadening and Maintaining Your Skills

A number of very good alternative resources have sprung up for rails, one of the best is Railscasts. Which, at the time of writing, has nearly 200 detailed videos available for free regarding a variety of Rails related topics. If you're having trouble with a particular aspect of rails then check if there is a video available on Railscasts.

Peepcode do some very nice longer Rails videos on important topics and are well worth a look, although they charge for the videos so it's worth having a clear idea of what you want to know about.

Ruby5 is a convenient podcast for keeping up with Ruby and Rails related news. Although, it's often easier just to check the topics listed on the website rather than spend the time listening to the podcast itself.

IRC channels can mostly be found on freenode with #rubyonrails having a significant pool of people who alternate between happy and grumpy at an exciting pace. #railsbrain also features good people and is likely to be friendlier to newcomers.

There is also a significant pile of blogs related to Rails floating around they're generally pretty easy to find and the best posts will generally float to the surface. At the same time it's good to be cautious of any blog posts that Google finds you as Rails has moved a lot in the last few years and many of the blog posts it finds are no longer relevant.

Hopefully these resources can put you on your way to being a Rails developer.

Scrum Introduction at RailsCamp

I did end up giving a talk at RailsCamp on Scrum. I'd had a few conversations about client management the previous day so I pitched it at a reasonably introductory level. The audience that showed up was probably about half familiar with scrum and half not. I think we got through a pretty good overview of the Scrum process and the experienced folks caused a lot of really interesting discussion.

Scrum

View more presentations from breccan.

During the talk estimating/sprint size and client trust became a significant part of the discussion. A number of people had issues with picking an amount of work and suggesting that that amount of work should be concrete for the sprint. I mentioned a few ways of minimising or accepting this and there are probably many other methods:

• Set stretch targets at sprint planning by putting some targets in the sprint at the bottom of the sprint backlog. This way there's something to do if you run out, they should only be done if you really finish the other tasks and there's no penalty for not reaching them.
• Regardless of having slightly less work, there's almost always something else for developers to be doing. From refactoring time to working on side projects there's never likely to be a shortage of work.
• Clients are going to be happy with consistent work and meeting the goals they've started with. If velocity needs to change that should be worked out before the sprint.
• Developers are most likely going to be happier if rules agreed on at the beginning of the process are kept throughout, changing things at odd times is likely to have odd flow on effects.
• Any change to these rules can be easily addressed according to team desires during the retrospectives and planning for the next sprint.
  

My general belief is that by maintaining consistency in process and methods, clients and teams will have a more comfortable feel for what's happening in the project. All parties are likely to trust each other more. Parties that trust each other(where the trust is justified) are more productive than groups that are trying work everything through an adversarial state of requirements and contract negotiation. Scrum occupies a similar position in development to manners in general society by allowing people to have a set of behaviours that allow for smooth communication without intimate knowledge of each other.

The talk also spawned a talk on Kanban a project management system with some interesting properties that I might blog about sometime(it also has inbuilt support in cucumber).

Railscamp post up on 3months Blog.

I posted a write up of some of the cool stuff from Railscamp to the 3months blog.

Read it at - http://blog.3months.com/2009/12/02/rails-camp-melbourne/