“This is a guest post from the The Las Vegas Ruby Group regarding a recent workshop they hosted for the #VegasTech community.”
Last weekend a few of us from the Las Vegas Ruby Group (@LVRUG) gave a two day workshop teaching people the basics of Ruby and the Ruby on Rails framework. It was a crash course in learning to code and basic computer skills were the only prerequisite; a tall order without a doubt, but we were up for the challenge. This is a recap of the event. We learned a lot from the experience and thought sharing our experience would be beneficial to the #VegasTech community. We look forward to holding another Ruby Weekend and think the two day crash course format could be applied to other languages and help grow the local developer base and make the technical community stronger.
Why We Did It
While it’s not quite feeding the homeless, an event like Ruby Weekend is a great way to give back to the community. Often local entrepreneurs reach out to @LRVUG in their efforts to find a technical co-founder for a startup. We’re happy to accommodate; facilitating connections is an important purpose of any quality user group. While we can only afford to give founders a few minutes during the meetup, I typically recommend they come to PT’s for the unofficial part two of the meetup to continue a more casual conversation. Unfortunately, it’s all too common @LVRUG can’t help, there simply isn’t the developer bandwidth in the group.
Response From The Community
We announced Ruby Weekend in early December and received a great response from both the local community and the Ruby community as a whole. Thanks in large part to a retweet from David Heinemeier Hansson (DHH), creator of Ruby on Rails. We even had a couple fly in from Canada to take advantage of the opportunity. The 20 seats were spoken for within a week. There were another 20 on the waiting list, something which made last minute cancellations easy to fill.
We sold the seats, were well received by the community, now it was time to deliver. We meet at /usr/lib one week, hammered out an agenda and broke up the responsibilities. Then we met for a very dry run one Sunday night and than another more serious dry run about a week before the event. One thing is certain: none of us had ever taught a class and we didn’t have much business teaching 20 people with zero experience in just two days. Luckily, there was a wide range of skill level among us and it actually made for a good team of creating Ruby Weekend’s curriculum.
After the event we asked those who attended to complete a brief survey. We wanted honest feedback, so it was completely anonymous. One question more than any other can sum up whether or not Ruby Weekend was a success.
That was the same person who answered ‘No’ to both questions; clearly we had one unhappy camper. However, this person also gave some of the best feedback in the open ended question at the end of the survey and was generally appreciative of our efforts.
And here is where people place their skill level before Ruby Weekend:
The Ruby Weekend website was pretty clear this was a workshop for people with no or very little programing experience, yet we still had a few people who were familiar with programming concepts.
For those interested, we’ve published the full survey results here: http://rubyweekend.com/RubyWeekend_Survey_Results.pdf
We Did A Lot Right
Before we get into some of the lessons learned, here are some of the positive comments from those who attended. Overall we are very happy with the workshop and response from those who attended.
“You gave us so much excellent info. The projects were perfect for this level and the overall build was great to see.”
“I thoroughly enjoyed the experience and learned a ton! “
“All the guys were very friendly and helpful. “
“Everything I expected and more. You guys are great fun and super presenters!”
“You had great presenters. Jeremy was especially exceptional. “
“With this being the first event, it was a great success. A lot of materials were covered and there was enough support from the instructors to get us through troubleshooting.
Going into the weekend, we knew we’d learn a lot and make mistakes Here is a recap of how we’d do things differently next time.
1. Allocate Even More Time – When crafting the schedule, we knew it was important to place some time buffers in there. I thought we had at least twice the amount of time we’d need. It turns out we probably needed about twice that amount. During the weekend, only Jeremy finished his presentation as expected and he had to limit the questions people could ask in order to do it. That resulted in the following comments:
“It seemed somewhat slow and remedial the first day, and then really advanced and fast-paced the next day”
“As far as app building in the 2nd half of the day, I felt the instructors were telling us to “copy this code and make sure this works” instead of making sure we understand why this works. I would venture to guess that 90% of the attendees didn’t understand what was going on by the end.”
“The pace was brisk to say the least, but it had to be that way due to the time constraints. Could almost do with doing this over two consecutive weekends with some tasks to keep people fresh during the week. “
2. Focus Specifically On Beginners – Before the weekend began, it was clear there would be a steep learning curve. However, we underestimated the number of questions people would ask and where they would be tripped up. Furthermore, those with more experience asked questions which confused others. I didn’t realize this was happening during the workshop.
“Break up into 2 groups – one for people with programming experience in other languages and one for people with no experience. The experienced people asked questions that made me feel more lost. As a non programmer, it felt like the basics are still way over my head. Would have been nice to keep on the basics learning until the concepts clicked…”
Also, diving into specific method names, and focusing on advanced method techniques are not helpful at this stage. We understand that when learning something new, chances are, afterward 90% of the information is not retained. Being able to give a more clear path as to how beginners can recap in their own way would be much more beneficial.
3. Simplify The Apps – During the weekend, we built three applications. One in pure Ruby and another two using Ruby on Rails. Given the time constraints, we should have lowered the bar. Our Ruby app could have been simpler and we probably could have spent all of day two on a very basic rails app.
4. Syntax Clarification/Aid – According to our survey, most people prefer to write the code as the weekend progressed. No surprises here.
However, we underestimated the number of typos and syntax errors people would have during the weekend. It was common for one or two people to hold up the class because of a typo and sometimes their bug was hard to find. Offering PDF’s of the code would have been helpful.
Also, we used common naming conventions and because this was a crash course, people had less time to connect the dots. A simple and common practice in Ruby was a bit more confusing than we expected.
For example, the following code:
May have been better demonstrated by showing which ‘name’ was related to another. For example:
5. Setup Was a Challenge – In order to minimize complication from version and operating system differences, we decided to create a Virtual Machine image and have everyone run on the same environment (https://github.com/LasVegasRubyGroup/RubyWeekend-VirtualBox-Image) . We had everyone, but three people up and running in about 30 minutes. When creating the Virtual Image, we assumed a 64 bit operating system and three out of the 18 had a 32 bit operating system. Had we create a 32 bit image, we’d have been much better off.
The virtual machine was also rather slow. We didn’t notice it so much the first day, but the second day when building the rails apps, it was much slower than we’d like. Throwing a bit more virtual RAM to the VM might have saved this. We could ensure that as a minimum requirement, people have at least 20GB of free HDD space. Allowing for VM install, and VRAM of 4GB.
6. Develop Using The Workshop’s Environment – While it might be obvious at this point, we used our local machines when developing the apps for the course. This became a bit problematic, because the Virtual Machine offered slightly different versions of Rails. While this was not a major hurdle, getting 18 people to change versions took precious time away from the workshop.
7. One Driver, One Presenter – The last half of the second day we used a different format, one person was the presenter and another operating the computer and followed along with the class. This was a great formula and one we’d use for all the presentations next time. The two main benefits of this are
- It forced the presenter to always call out instructions to the driver (and the rest of the class).
- The presenter can focus on the class and making sure everyone is on the same page and the driver can focus on keeping the appropriate material on the screen.
8. Tech Support Is Key – I would recommend having about one person for every 5 people who are attending the class. There were definitely times were a lot of people would have errors and it was great to be able to quickly help. While we didn’t think about it much before the event, it’s worth noting there were times when many people needed help spotting a bug in their code and typically it was a typo.
9. Breaks are a must – We knew we would need time for lunch, but with so much information, and limited space, people often needed to get up to stretch, take a phone call, restroom break, or whatever. Scheduling 10 or 15min breaks several times throughout the day is a must, and should be well noted during when creating the schedule.
The Next Ruby Weekend
There will be another Ruby Weekend in Las Vegas, but we’re not exactly sure when. It will likely be before July and we’ll take the lessons learned from the first Ruby Weekend and make the next one even better.
A big thanks to all those who came out to participate; you all helped us learn a lot, too.
Pawel Szymczkowski and /usr/lib for helping us find a great venue to host the event.
The Beat Coffeehouse for opening an hour early on Saturday to helping us get off on the right foot and avoid a scheduling snafu.
Mike Ball for coming out and providing additional tech support.
Taylor (guy from /usr/lib) for helping us get the virtual image working on the netbooks.
Keep the momentum going,
Judd, Russ, Jeremy, Bob and Jason
Judd – @juddlillestrand, ScripSmart.com
Russ – @cloudsplitter, TheShopLV.com
Jeremy – @jeremywoertink, LoveAdvice.tv
Bob – @bobfirestone, BobOnRails.com, MainStreetChamber.org
Jason – @jarhart, Yeres.me, Originate.com
About The Las Vegas Ruby Group
If you live in Las Vegas and want to learn more about Ruby and Rails, you should join the Las Vegas Ruby Group. We host an event every Wednesday; alternating between a formal meetup with presentations and a casual hack night where any programing language is welcome.