For HackVT 2016 myself and 4 other developers, cleverly known as Team TBD, created CodeShepherd. A collaborative IDE with course material built-in designed to help connect programming educators with students. In this post I’ll go into how we came to decide on this project and talk about the technologies and architecture behind it.
Planning to Plan
Prior to the hack we had a spreadsheet with a several ideas of what to build. We roughly evaluated each project on: what problem does this solve, what flow could we build for the demo and would it be interesting to work on? The rough idea for CodeShepherd was on the list but we weren’t able to agree on it before the event so we arrived without knowing what it is we would be doing for the next 24 hours.
The keynote speaker was a woman named Christine Braun who runs a program teaching robotics to children. In her talk she mentioned that a real challenge in education is a lack of qualified people to teach technology skills. This gave us the answer to “What problem does this solve” for CodeShepherd so we settled* on that and spent the next hour white boarding the flow and design.
* – Full disclosure: I was the last hold out for choosing a different project. Shows what I know.
The Stack
The team was made up of Java and JavaScript developers so our tech stack choices generally fell along those lines. The backend service was written in Java using Spring and MongoDB. Frontend was JavaScript with React and WebRTC for video. For collaboration we used Slack and Bitbucket. Build, deploy and hosting was done with Maven, CodeShip, Heroku and Firebase.
The Backend
Our backend service exposed a REST API for loading current class and student information, interacting with the Learning Registry API and evaluating student code submissions. It is a Spring Boot app using not one but TWO REST frameworks (it is a hackathon after all). Part of the API was defined using RAML which then generated JAX-RS endpoints. This proved to be somewhat of a hassle as the current RAML -> Java code generators do not support adding custom annotations to generated classes. This led us to an epic mid-hack refactor of our project from a single module maven project to a multi-module to house our customized code generators.
commit 9f80e737a52dbdd4119af599574baac237ae1c21
Date: Sat Oct 15 04:37:15 2016 -0400
i am stupid and refactor during a hack
After that we wrote any remaining endpoints using Spring MVC.
MongoDB was chosen mostly out of ease. We all had familiarity with it from our day jobs, there are free hosted options available and we wouldn’t have to spend time worrying about schema design (again, hackathon).
The Frontend
Frontend assets were stored and deployed along with the backend as a single monolithic app. The collaborative text editor was powered by Firepad and Ace. Firepad uses Firebase to sync and store data. The rest of the frontend was put together using ReactJS.
For the video chat we used a WebRTC wrapper library called PeerJS. This required an additional backend service to negotiate the video connections. For that we used the PeerJS’s PeerServer. Unfortunately we did not get that deployed to Heroku for the demo so it was running on one of our development laptops.
Build Deploy
From the get go we had our app in git with BitBucket and deployed on Heroku. I highly recommend both of these services for any hack project. They offer great free tier services and are super easy to use. Deploying your app to some sort of hosting greatly eases collaboration. No more worrying who’s machine (or machines) will be needed for the demo or not being able to see the current state of the app because your workspace isn’t stable.
About 2/3 of the way through we set up CI and automated deployment using CodeShip. This was my first time using the service, but again, super easy and good free tier. We used two long lived branches in our repo: master and live. Development happened on master and was merged with live when it was ready to be deployed. CodeShip automatically picked up merges to the live branch, ran our build and deployed the resulting artifacts to Heroku. This once again made collaboration and development much simpler since we didn’t have to pause to talk about who was ready to commit what, where when or manually run a deployment.
Conclusion
There you have it! We used the tools we were most familiar with and pulled off a fully functional application in 24 hours. Everything we used offered a free tier or was open source. With the a wealth of such projects it’s never been easier to build an awesome hackathon project!
Bur.net 