5 Things We’ve Learned from Organising Ruby on Rails Workshop

Last semester, we have ran an Introduction to Web Development with PHP workshop series in MMU. The objective of the event is not just to teach them how to use PHP to make web apps, but to empower them to self-hack more – to make things on their own.

Unfortunately, we didn’t achieve that objective. So we started to think of ways to help us get closer to our objective when we run another workshop.

So this semester, we decided to run Ruby on Rails workshop, and we want to run it a lot better. Before the workshop begins, Bruce, the workshop director wrote this blog post to explain how.

Fast forward to now, we have finished conducting the 3 weeks long Ruby on Rails workshop, so, did the changes work? Yes.

Commitment Deposit Works

We didn’t charge a single cent for participants of PHP workshop. 80 students joined the 1st session, but at the end, only 20 remained for the 4th one. We have also asked them to present what they have done in our Hackerspace weekly meetup, none came.

The effective way to learn things is by doing it, not just by listening to lecture, try the tutorials out, but by actually using it to solve problem – to make your own web apps. Otherwise it’s just as good as you have learned nothing.

So, in Rails workshop, we have decided to ask students to put down a deposit of RM50. The deposit will only be returned at the end of the workshop, only if they have managed to complete their own projects, and not just the example app we build in tutorial.

In short, it worked. 10 students have came to Hackerspace and presented what they done. This is a huge improvement over the last workshop we did!

Allocating Time for Own Project

In PHP workshop, we did not ask the participants to think of what they wish to build. Instead, we just asked them to follow through our tutorial and call it a day.

That wasn’t empowering at all. So this time, we asked them to think of a web app they wish to build, of reasonable difficulty. Then in each session, we allocate 1 hour for the lecture/demo, 1 hour to work on their final project, with guidance and help from mentors.

Some of them already have a startup they want to do, some of them just cincai came up with a project just to get back RM50. But either way, they have managed to apply what they have learned from the workshops, to work on their own problem.

People just feel more empowered when they work on their own thing. You will remember things better, not when you are simply just following others’ foot prints, but when you figure out your own paths.

Use Cloud Development Environment

Most of the students in MMU use Windows, and Ruby on Rails just don’t run well on it. So we asked students to install Virtual Box, Vagrant, and Git so they can develop Rails app on Windows.

Unfortunately, the installation is not straightforward at all. Most students don’t understand what is Vagrant, what is VM, what is going on, how the whole dev environment works, wondering why commands don’t work (confused between in Windows and in VM SSH).

Hell, Lenovo laptops don’t allow virtualisation without enabling it in BIOS, we didn’t know that!

It was frustrating and confusing.

One of our students just can’t run anything, because their OS is 32-bit and the RAM is just 2GB. So we have advised her to use Cloud9.

Again, it worked! They quickly caught up to 2nd lecture. They didn’t need to set up anything, and simply need to focus on Rails. After all, our workshop was never about teaching them how to configure virtual machine, Vagrant, and confused between which environment they are typing their commands in. Using cloud development environment has helped us  to stick to our focus – Rails!

Use Labs Maybe

When we conduct the workshop in classroom, we have issues getting power supply to every laptop (we have enough power extensions, actually), and fast Internet connectivity to all the participants (later solved with Apple Airport Express).

So for last few sessions, we have decided to try using one of the labs in FCI. Each seat has power sockets, and LAN cable, so we have solved the power supply and internet speed issue.

However, our group formations have broken up. All the students were facing the projector screen and lecturer, and the groups we have formed earlier? Gone.

It’s a trade off. If we can solve the power supply and Internet speed issue, actually we did later on, we should try to use classrooms as much as possible. It’s just better for the social experience.

Mentors-mentees ratio

In PHP workshop, we have a small mentor to mentee ratio, as a result, each student gets too little attention from each mentor. Not very good.

So this time around, we know we only have 5 mentors (actually 3, 1 have to skip first 4 sessions because his replacement classes clashed with the workshop, and 1 bailed out last minute), so we decided to take in only 25 students.

Despite our effort to keep the ratio small, we still didn’t manage to pay each student enough attention. If possible, in our next Rails workshop, we may need to recruit our alumni to help out as mentors.

Conclusion

We have managed to iterate on our format in order to really get to our core objectives. And we can still see further steps it can be improved upon. The feeling of growth is a great feeling to have.

We are really happy that students have managed to complete the course, built their own thing, and hopefully can make a living out of what they learned.

To those who will be conducting workshops in near future, we hope that you will not make the same mistakes we did, and feel free to emulate some of these practices that we have found works!

Thanks for reading 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *