Teaching Kids Webdev

What is scouts?

I’m a scout leader in Australia.

When they hear “scouts”, some folks think of “boy scouts” going camping, hiking, and constructing things with wood and rope. Or they think of “girl scouts” and their cookies.

Scouts Australia is an organisation that is inclusive of everyone, regardless of gender, sexuality, race, or ability. Scouting is available to youth aged 5 through to 26, and adult leaders from 18-years onwards. And while we do go camping, hiking, and do construction, we also do pretty much anything else you can think of. One of our values is that we are “youth leading, adults supporting”, meaning that youth get to set their own program, with the guidance and support of their adult leaders.

In keeping with the times, Scouts Australia recently overhauled our scout award scheme, through which we recognise achievements of youth in various skill areas. We’ve made it far less prescriptive, which has encouraged a much broader spectrum of activities to meet the criteria for each award.

One of the six new “Special Interest Areas” we have is “STEM & Innovation”, and naturally, that encompasses Information Technology under its umbrella.

My history in scouting

I was a scout as a kid, and, in addition to outdoor skills, it taught me life skills, such as how to plan a healthy menu, assemble a shopping list, cook, budget, decide what to pack for several days of camping, pack and tie down a trailer, and lead a group of my peers in the absense of direct adult involvement.

I decided to take a break from scouting when I turned 18, to focus on university where I was studying Computer Science. But 3 years later, I realised that I was spending all my time in front of a screen, either for work, study, or recreation, and that I could use an escape. Returning to scouting was an obvious choice, as I remembered it helping me to keep active and get outdoors.

So in 2008, I became a scout leader, and I initially worked with scouts aged 11-15 years old. Over the years I’ve branched out to become a leader of adults, helping to train other scout leaders, and an activity leader, helping to facilitate state-wide events for scouts of all ages.

Ironically, while becoming a leader met my initial need to get away from the screen, I’ve since come full circle, and now spend quite of my scouting time staring at my computer, using my IT skills in service of scouting. I use open data and free and open source software to make topographical maps, and have been developing and administering websites and web apps to facilitate various scouting events, usually using Python and Django. While a few of my scout leader friends are also proficient IT folks, much of this work fell to me, and in any case, none of us were going to remain in our current scouting roles indefinitely, so it made sense to do some succession planning

ScoutHack inception

As a youth leading, adults supporting organisation the obvious choice was to prepare to hand down these responsibilities to the organisation’s youth members. This approach has the advantages that it can be used as an opportunity to teach real world tech skills to youth, and to give them the agency to influcence to influence the direction of this IT infrastructure, if indeed they deem it to remain relevant.

So in mid-2021, amidst recurring COVID lock-downs in Melbourne, my friend and fellow scout leader, Luke, suggested we run a tech camp to teach kids the basics of website development, with a side of sysadmin/operations if we got the time. Taking inspiration from GovHack, a hackathon the two of us have both participated in and run for several years, we coined the name “ScoutHack”, and began weekly Jitsi video meetings to plan a two-day camp.

We decided that our syllabus should teach basic HTML, CSS, and the beginnings of some flavour of server-side scripting language. This is an ambitious undertaking, given that we only had a weekend, and were expecting youth as young as 11, of varying skill levels, but we reasoned that even if we had to walk them through the entire process step-by-step such that they didn’t retain many of the finer details, it would be enough to give them all a taste of web development, such that they could pursue it further (possibly as part of a ScoutHack 2.0 event) in future.

Event logistics

One of the first questions that arose after we’de decided what we wanted this event to achieve was: what resources did we need to make this all happen?

We wanted the event to be accessible to as many people as possible, so that meant not assuming youth would have their own computers to bring. Fortunately, Andy, a member of our leadership team, has access to a fleet of Toshiba Tecra M10 laptops. Having been manufactured in 2011, they are now older than some of the youth who use them, and are certainly not the fastest machines, but we reasoned that if we installed Linux on them with a relatively lightweight desktop environment, they’d be quite capable of running a web browser and a text editor or IDE, which was all we needed.

*[IDE]: Integrated Development Environment

We also wanted to give youth members an authentic, user-friendly developer experience, by giving each participant a separate external monitor, so they could display both their code and their web browser simultaneously. After some scrounging, we managed to get together a fleet of servicable VGA monitors, keyboards, and mice, to complement our laptops.

The next problem we had was power. Some of these monitors were quite old, and despite being LCD, were not particularly power-efficient. Luckily we managed to book a recently built activity centre at a scout camp. This was a single building with bunks for over 20 people, bathrooms, a kitchen, central heating, a huge hall for us to use as both classroom and dining area, and brand new electrical wiring. After doing all the maths, we determined that if we carefully distributed our infrastructure across the several different electrical circuits, we’d be able to run everything without tripping any circuit breakers!

One of the challenges with this campsite, though, is that it’s out in the sticks, and has neither an internet connection, nor reliable cell coverage. How do we teach kids about web development without internet? We run a local server, of course! We could get each participant to run a local web server and browse to their website via http://localhost, but we wanted to give them the feeling of hosting their website where others could get to it, so came up with bigger plans.

Server-side tech details

We managed to rustle up an old rack-mount server, a couple of rack-mount network switches, and a bunch of network cables.

We decided that we wanted scouts to experience full admin access to their own Linux server, on which they could run a web server, install packages, and store their files. To do this, I opted to build a Ubuntu container image which runs an SSH server, and creates a standard user account with full sudo access to that container. Each scout would get their own identical container.

To grant access to the containers, I set up sshpiper. sshpiper is a reverse proxy for SSH, which uses a person-in-the-middle technique to work out which SSH server a client is trying to connect to, based on things like the client’s requested username or SSH key. This allowed me to expose sshpiper on port 22, the standard SSH port, of the server, and then have it tunnel connections through to each scout’s respective container based on the username they authenticated with.

Next step, was giving each scout their own website! I opted to use Traefik (or Træfik) as a reverse HTTP proxy. I set up local DNS so that the LAN had a TLD of .scouthack, and gave each scout a subdomain of this, based on their username or first name. This subdomain would point to the server, and when Traefik got a request on port 80 with that hostname, it would route it through to port 80 on that scout’s container.

*[DNS]: Domain Name System *[LAN]: Local Area Network *[TLD]: Top Level Domain

After this was all set up, it was a matter of instructing the scouts to SSH to username@username.scouthack, enter their password (which for simplicity I set to their username; don’t hate me, it was a calculated risk!) and then run a web server using python -m http.server 80, and then browse to http://username.scouthack to see their website, once they’d created it.

Great, that’s the server side largely sorted. Now, how do we get these kids up and running to actually log into this system, without going into detail about the nuances of SSH etc.?

Client-side tech details

I set up the laptops using Xubuntu (i.e. Ubuntu Linux, with Xfce as the default desktop environment). Using Clonezilla, I was able to create an SOE image of the first laptop, then use IP multicast to duplicate that over the network to all other laptops at once, taking less than hour to do over 20 machines. Gosh I love computers sometimes!

The SOE I’d built was pretty basic: aside from the basic Xubuntu Desktop packages, which included Firefox as our web browser, I only needed to add Visual Studio Code with a couple of extensions, install an SSH server so I could manage the machines remotely if necessary, and call it done.

*[SOE]: Standard Operating Environment