I am 5 months into a 6-month software engineering internship at Code.org. The latest project I completed was the migration of our main code-dot-org repo from using an outdated fork of the johnny-five package that hadn’t been touched since January 2018 to the latest release of its upstream.
johnny-five is an open source, firmata protocol based, robotics programming framework! Its API documentation is available at: http://johnny-five.io/api/
It supports Code.org’s Physical Computing module that use the Adafruit Circuit Playground.
Code.org has researched benefits of physical computing which include:
- Inclusion of and engagement with girls and students from underrepresented groups in computing
- social emotional learning
- learning efficacy
- real world applicability in a world of non-linear proliferation of devices
Here is a timeline of the Code.org johnny-five fork:
- March 2017: Forked mainline johnny-five to add first Code.org customization – Round scaled sensor values
- January 2018: Last Code.org customization – Add RGB.pulse method (v0.1.1-cdo.2)
- September 28 2022: Updated to latest release of mainline johnny-five (v2.1.0)
- October 2022: Re-implemented 3 Code.org customizations
- October 20, 2022: Released as v2.1.0-cdo.1
- October 27, 2022: Migration to updated johnny-five!
It was time to upgrade because the version of serialport that the outdated johnny-five package was dependent on was causing pesky errors:
So the first task was to create a copy of the outdated johnny-five repo, name it johnny-five-deprecated and point all references in the main code-dot-org repo to it. Then I updated johnny-five to the latest release of its upstream v2.1.0.
I had to learn how to link the updated johnny-five locally with my local code-dot-org repo in order to develop and test Code.org customizations. The recommendation was to use yarn link or npm link, but neither worked. So then I read online about yarn add which adds a copy of the local repo as a node_module and that did the trick!
Once I linked the two modules, I had build errors which required updates in webpack – fixing node dependencies and adding johnny-five to a list of packages that ship in ES6 and need to be transpiled for our purposes. A senior engineer to helped me with these updates.
Once I was able to build and then run the code-dot-org dashboard locally, I could finally start adding customizations, the reason why we forked johnny-five in the first place! There were three customizations I re-implemented:
- A performance fix to use setTimeout fallback so pulse functions are not CPU hogs. PR
- Adding RGB pulse function. PR
- Rounding scaled sensor values. PR
Once these were implemented, I published to the NPM registry and added the latest release on GitHub.
This was quite a challenging project overall, and I learned many lessons from it. The most important takeaway for me was that a good pull request tells a story. I relied upon notes and comments from Brad, a Code.org engineer who had done most of the prior work in johnny-five back in 2017-2018. His detailed notes guided me throughout the re-implementation process. I didn’t feel alone even though I was the only engineer assigned to this task.
I also appreciated that he included alternate paths he didn’t choose and explained why he didn’t choose certain options.
- Fantastic notes and comments – Brad’s RGB pulse PR
- Alternative paths not taken – Brad’s original shim solution for pulse function being a CPU hog
Overall, my journey with johnny-five presented many roadblocks and challenges, but ultimately, we were able to migrate successfully. Along the way, I learned many lessons and I’m proud to have contributed to the maintenance and support of the Code.org Maker Kit module whose future is looking bright!
