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.
Sunday, July 25, 2010
Wednesday, May 26, 2010
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.
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.
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.
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/
http://blog.3months.com/2010/03/26/webstock-vs-linux-conf-au/
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.
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.
Subscribe to:
Posts (Atom)
