Accounting for Multiple Platforms in a 1:1 BYOD Environment

When students are bringing their own devices (1:1 BYOD), the classroom becomes a jungle of OS's and platforms. While G Suite can level this playing field 95% of the time, teaching programming presents unique challenges.

And let's face it, as a technophile, IT Manager, and my school's programming teacher, I have both a natural interest and a professional need to work on the problem. Computer programming is unique from other subjects in that you both do and don't need class equipment. On one hand, programming concepts from design processes and code patterns to pseudo-language structures don't need a line of actual code to teach; I use a whiteboard for them by and large. On the other hand, students need to get their hands dirty and their brows furrowed over actual code that requires some tooling. Whether it's a text editor and browser or a full-stack IDE, they need something to code in!

This is where the plot thickens in a 1:1 classroom. There are only a few applications that are usefully similar on Macs and PCs; even fewer if - as I do - you want Open Source. Once you bring in wanting to use version control for the assignment workflow it gets even stickier. This isn't my old high school "computer lab" of the early 2000s where rows of identical IMB 486s were each provisioned with the same system so a teacher could use screenshots and set instructions to get us from A to B. Not to mention bypassing having to install all that software! This is wrangling literally a dozen different systems with their own specs and configurations.

Moreover, I am wary of the "$1000 pencil" phenomenon. I got to sit down with Allan November and discuss the issue in 2017. I think about it every time a new service or device comes across my inbox. I really can't be rewriting my lessons and assignments to account for a new learning environment every couple of years. Nor is it sane for the school to shell-out unnecessarily.

Ultimately I have three solutions for three different cases:

1. All-in-one cloud-based editor and stack: Repl.it

I started using Repl.it to teach python to Grade 8 students. Repl.it has been great for this since (1) they have OAuth SSO so the kids can use their persistent school Google account session to move seamlessly into the platform - trust me this is huge for 13 year olds; (2) the environment contains the interpreter and editor so the students don't need to be at the point of an abstract understanding of files, the OS, etc. to write and run code; (3) Repl.it's new educational program lets me write and deliver lessons and assignments (complete with starter code) all in the platform. I keep copies on Github, but for now it's worked out well.

Although a scaled use of Repl.it will cost you, I have managed to easily use it for one class each year without a problem. Their system supports many languages and because it's web-based, it's obviously cross-platform.

2. Cloud-based IDE remote-editing files hosted in a cloud-based stack: CodeTasty + code.coastmountainacademy.ca

For my Grade 10 Web Design course, I needed students to have a more featured editor that could handle all the assets and structure of a basic modern website, but also access to a web server for developing their assignments. As importantly, I needed a way to access their work for assessment and evaluation. Although there are options for self-contained server stacks for both Macs and PCs, and great IDEs too, I didn't want to support so many different variables. It's a barrier to learning when each students' screen looks a bit different from my examples and so much time gets spent just tooling everyone up when at Grade 10, I'm not dealing with 100% power-users. I also didn't want to be having students submit zipped folders of each assignment for me to open locally.

What I did was leverage the dirt-cheap cloud hosting options out there. A minimal cloud sever instance costs less than a premium Starbucks beverage per month, and could be used for many types of projects beyond the Web Design course. Coupled with the excellent free-tier offering from CodeTasty, a cloud-based IDE that can do SSH key login and remote editing, and it made for a slick browser-based system for students to learn in. It was consistent across platforms, easy for me to assess (by simply visiting the student's live website), and it gave the students a taste of a modern webdev professional's workflow.

An added bonus to this is the accountability and pride/ ownership students got from 'seeing their work in print'. Regularly pointing parents' browsers at their student's website and keeping everything published made for a more authentic experience all around.

If you've got the admin-backing and sysadmin chops to set this up, I highly recommend it.

3. Github's Atom editor and local *AMP stack to learn in a Git-driven team workflow

To teach my Grade 11 and 12 programming courses, I had a tall order: I wanted essentially a freelancer's setup on each student's machine so they could work like one. Although many schools use Java to teach advanced programming courses (python being another strong contender) I feel strongly that webapps are the future, that they can learn Java and C++ in their undergrad, and that you can never start too early on databases; so PHP & MySQL are it for me at this level.

Because this is the big leagues, I admitted that the CodeTasty solution wasn't powerful enough. Github is a big part of these courses and CT's Git integration required command line use. Students were going to do everything with a Github-centred workflow, so requiring the use of command line Git when Github has a great GUI called 'Desktop' out seemed crueler than I needed to be. Meanwhile, the Atom editor has great integration with Git and is cross-platform.

Caveat: the first week of Grade 11 is spent installing software (Atom, Github Desktop, and XAMPP) and getting it to run on everyone's machine. The second week is spent getting student brains around version control, Desktop, and Atom. I don't get to really teach any programming until week three, and they're not fluent with the whole "clone assignment repo, edit-commit-repeat, pull-push-repeat, submit" thing until week four at least. All that setup time is worth it though when by the final week you have students rebasing branches, managing each other's PRs, and generally acting like professionals for their homework. I asked a good friend of mine who manages a team of programmers in industry what he thought of putting git in front of secondary students and he wanted to know how long until he could hire one.

For my part, Github has a beta-level education-focused sub-platform called Github Classroom. The naming threw me for a while because it works nothing like Google Classroom and is in fact just a teacher-facing tool to batch-create and manage student repos. I found their help videos baffling too, but perhaps they'll be useful to you. For assessment, I use Git myself to clone into students' assignment repositories once they declared them submitted (with a final commit titled "SUBMISSION") and run them on my local stack. For database data I ask for an SQL-backup within the repo to restore into my local server for the assessment. Since I remain the 'owner' of all student repos when GH Classroom duplicates them from my prototype, I'm able to assess (for and as learning) students' practice and progress at all times.

Once students are fluent with a workflow like this, leveraging the cloud server instance becomes a lot of fun too. Students can work collaboratively in a hosted repo, push to Github, and then pull it down to the server for testing, or work directly on the cloud with CodeTasty and then push from there to Github to keep everyone else in the loop - though that requires them to take on the command-line.

All in all I've devised three ways to make 1-to-1 a strength of Coast Mountain Academy's programming program. Hopefully you're encouraged to try something cool using one of the approaches described here. As always, find me on twitter or /r/innovatED to continue the conversation!

This article is my 2nd oldest. It is 1344 words long