, , , , , , , , , , ,

A couple of days ago, I had the enormous pleasure of contributing to the first Girls In Tech event in Singapore.  The event had a dual design and development focus with keynotes in the morning and practical workshops in the afternoon, interspersed with a guerilla Tai Chi session in the cafeteria of our kind hosts and co-presenters Google.

I was doing one of the afternoon workshops and the title was “Software Development in the Small, the Medium and the Large” which was a slightly shaky analogy about the applicability of software for a variety of extra activities beyond the obvious solution to the business problem.  In addition to fundamental software development (via Ruby) I was covering automated testing (RSpec), build automation (Rake), Continuous Integration (Travis CI) and a little bit of Infrastructure-As-Code (AWS).

The constraints I had with running this workshop were:

– I didn’t know final numbers because there were multiple streams running in parallel and people voted at the start of the workshop streams.  In the end, I had about 20-25 people.

– I didn’t have a good handle on the level of development experience of the participants.  Attendees for the day had nominated whether they were attending due to interests in “design”, “development”, “both” or “other”, but beyond that it was difficult to ascertain how many people were complete beginners versus those who had some experience with software development.  I was expecting a lot of university students with a smattering of languages and in the end, this was who appeared.

– Most importantly, I didn’t know what sort of hardware people were going to turn up with.  I had hoped it would be a see of MacBooks or *nix lappies, but in the end more than 50% brought Windows-based devices.

Thankfully, most of my stuff scaled our reasonably well.  I had learnt nasty lessons from getting Ruby installed on Windows machines in the past so my mitigation strategy was to complete all the workshop exercises via a browser in some form or another:

  • Source code was accessed by forking a GitHub repo.
  • Code editing was done by using the browser-based GitHub editor (not ideal, but still better than Notepad).
  • We used TryRuby.org as an IRB for Ruby experimentation.
  • Travis CI for… wait for it… CI!
  • The only thing I ended up needing people to use their laptops for was SSHing to a Bitnami RubyStack-based AWS instance to deploy the Sinatra app we had been working on.

Generally this setup worked well.  I ended up having less time than I thought for the workshop for various extraneous reasons, but I managed to get some part of the group across the finish line at the end with a deployed Sinatra app running the code they’d been working on earlier in the workshop.

However, there were a few unexpected things that tripped me up.  In some cases, I fixed them on the fly.  In some cases, I have ideas about how I would run the workshop differently.  In other cases, I’m still a bit in the dark.

  1. Although I think the whole GitHub-as-editing-environment worked well for most of the workshop, there were a bunch of people asking me “but how do I run my tests” before I’d naturally got to the point where I was ready to talk about Travis CI.  Going forward, I think I’d rather wear the cost of having the participants install Virtual Box + Vagrant before the workshop starts and then give them a fully configured Vagrant box so allow them to “ruby”, “irb” and “spec” to their heart’s content.  Now that I know Virtual Box comes for Windows as well, it would solve the SSH-from-Windows issues as well.
  2. TryRuby.org seemed like a good idea 12 hours before the workshop started, but wasn’t all that useful for the sort of playing the workshop participants needed to do.  Specifically, I needed them to be able to execute code like “Time.new.getlocal(‘+08:00’)” which works with MRI 1.9.2 but fails within TryRuby (reportedly also running 1.9.2).  To be fair, my only test on TryRuby.org was checking the version and assuming everything else would be OK, so I need to be more thorough next time.
  3. I still didn’t manage to debug all the Windows Putty/SSH issues so some of the Windows’ folk didn’t manage to connect to their AWS instance.  I forgot about the Java-based SSH client you can now use as an AWS terminal – that would have been a better way to go.
  4. Right at the start, I insisted people pair on the solution.  A great way to increase the overall quality of the work being done and reduce the number of PEBKAC errors that needed my attention.  Even with this though, I’m eternally grateful that I had a colleague (Rick) along to also spend some more time with people
  5. I never got around to including branches of my repo to allow people to catchup to the rest of the class if they’d fallen behind.  Given the number of things I covered in a fairly short period, it would have been nice to give the audience an easy way to skip forward to a version of the repo with completed test, running code, etc.
  6. Travis CI never ceases to impress me with it’s ability to do one thing extremely well.  Yet in one case, it’s GitHub integration didn’t seem to work for one of the audience.  It found their GitHub account with no problems, but couldn’t see their repo, so couldn’t built it 😦  I never got around to sorting that one out.
  7. At the last minute, I asked a colleague to write a little self-service tool for the participants to self-allocate one of the pool of AWS instances I configured for the day.  I was a bare bones Node.js app running on an extra AWS instance and worked a treat – thanks Paul.