Rails VUWIT workshop
View more presentations from breccan.
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.
Subscribe to:
Posts (Atom)