On Telescope 0.5 and Dogfooding

by David Humphrey

Winter 2020 Teaching

This term I'm teaching a bunch of introductory web programming classes (WEB222), and also the second open source course (OSD700, DPS911).  I really enjoy teaching all of these courses, and doing them together is an interesting challenge.

The courses are completely different, and exist at opposite ends of the students' time at Seneca (early semester vs. final).  Having my head in both the beginning phase of web development and also in real-world software on GitHub, is a fantastic way to build my skill and empathy at working with the students.  In a given day I'm as likely to spend time helping people learn how to use Arrays as I am debugging complex Arrays of asynchronous Promise chains talking to Redis, deep in a node app.

This term I'm working on doing some updates to the web curriculum, partly informed by my (better) understanding of where the students need to be by the time they get to the upper semesters.  I'm, also starting to think about the summer term, and a new course I've been asked to lead on Progressive Web Apps (PWA).  This course will be jointly offered with a university in Denmark, and we'll be hosting their students and professor for a few weeks in July/August.  I'll write about it more in the coming weeks, but I'm excited by the challenge of something new.

Telescope

Every time I do the second open source course it looks different.  This time my students wanted to keep going with the Telescope project they started in the fall.  Telescope is a blog aggregation system, built to replace our old blog planet.  I'm happy to let them take this approach because the project uses so many interesting modern technologies and techniques, including:

  • Multi-process node.js web apps
  • Redis
  • Job Queues
  • Docker, Docker Compose, and hopefully Kubernetes
  • GatsbyJS, React, and the requisite Frontend Universe
  • REST APIs and GraphQL
  • Modern web tooling (eslint, Prettier, Jest)
  • SSO with SAML2
  • XML Parsing
  • Continuous Integration, Automated Testing, and Continuous Delivery
  • Security (secrets management, SSL, sanitization of user content)

The list goes on.  It's fun code to work on, and the app is starting to "work."

This week they got the staging box up (thank you Josue, Calvin, and Miguel) .  You can try it at http://dev.telescope.cdot.systems/planet if you want.  We don't have the real frontend yet, but I've ported over the old Planet UI to work on the new backend.

Community

One of the areas I want to push the students in relates to community involvement.  A common problem I'm seeing is confusing being good at development with being good at open source development.  If the former is primarily about computers, the latter is primarily about people.

We went from 60 students in the fall to under 10 in the winter, so those that are still active on the code suddenly have a lot more responsibility and code to maintain.  We've also added some new teammates who haven't worked on the code before.  This is an excellent opportunity to highlight pain points in our docs, workflow, and culture.

To that end, there's been quite a bit of auditing recently on our docs and developer experience (thank you Cindy, Julia, Rafi, and Ana), and if you're interested in working on the project with us, begin with the README and CONTRIBUTING guides.  See if you can follow along, and if not, please file an issue.

I've had the students run a weekly Triage Meeting, to go through our backlog and help keep reviews and issues moving forward.  They've been doing a great job burning through old issues, and keeping detailed weekly notes for those not in attendance.

I've also been receiving lots of requests from students not in the course to have me help them with open source and provide mentoring.  I've been using the Telescope project as a way to funnel new Seneca people into open source, since it gives the open source students a chance to work at mentoring, reviewing, and working with people who are remote.  We've had a number of early semester students get their work merged this week, which is wonderful.

But we haven't yet reached the point where everyone feels comfortable to work as a community instead of as a collection of individuals.  This takes time, and requires trust to be built.  I'm hoping that in the next few weeks we'll move from "these are my issues" and "this is my PR that needs review" to "these are our issues" and "these PRs need our review."  Every day there's a bit more activity on Slack, a few more people asking questions, and increased confidence for people to file issues instead of assuming they just did something wrong.  

A Challenge for the 0.6 Release

One of the areas where we struggled during 0.5 was in student blogging.  This is a bit surprising, given that we're building a student blogging aggregator app.  I've long known that blogging is a great thermometer for student work: if you have nothing to write about, it's usually because you didn't do enough.  The inverse is also true, and blogging is easiest when you're busy doing cool work.

To help smooth out some of the problems I've seen this month, I'm going to try an experiment in the coming release (0.6), which I'm codenaming "Grade A Dogfood."

"Grade A Dogfood"

For the 0.6 release (and onward), I'm only going to mark student work that can be accessed via Telescope itself.  If I can't do the following, I'm not going to assign grades for a release.  The requirements are as follows:

  • I have to be able to go to our staging server at http://dev.telescope.cdot.systems/.  If I can go to https://dev.telescope.cdot.systems/ instead, that's a bonus.
  • The site that runs there has to be a GatsbyJS app.  If the data it hosts comes from our GraphQL API, that's a bonus
  • I have to be able to login using our fake SSO service, and it needs to show me that I'm logged in somehow
  • The data hosted in the GatsbyJS app has to be live, and continually updated
  • I have to be able to read everyone's 0.6 blog post describing what they did, and what I need to mark

If our dogfood isn't good enough that I can eat it, I'm not going to mark it.

If the students are good (and I believe they are), they'll use the triage and planning meetings to focus their work, and divide things up among all the team members; they'll also enlist the community for help.  Hopefully I won't go hungry!