Open Source, Atom Failures, and the Wild Wild West

Devon Bull
Jul 27, 2017 · 3 min read

My class at the Turing School of Software and Design was recently given a task: make an open source contribution in 3 days. We were broken into groups and assigned a project: in my case Swagger. Swagger is a tool that allows teams to quickly simulate, document, and collaborate on potential API endpoints. You can set up http endpoints and responses very quickly without writing much code.

The Swagger UI repository uses React/Redux, Webpack, and Lodash (amongst many other things). For simplicities sake we decided on a group member to open a dialog on an open issue in the section labeled “good first contribution”. Getting setup on each group member’s machines took a bit, the ReadMe indicates how to run the project locally with Docker and it worked seamlessly. However, as students who had never actually used Docker, much less understand what it was, the instructions led to confusion: where was the code? After noting the docker commands the instructions then start listing the npm commands to run but again: where was the code? I’m embarrassed to say I stuck with it for a minute before realizing I needed to clone it down like any other Github repository 😅.

The Swagger UI codebase was enormous from our perspective. In fact finding/understanding the function listed in the GH issue to modify took us over a day. Perhaps Swagger should list the file to modify in the issue? Following a React prop up from the component that invoked it was a dizzying whirl of folders, files, and a custom store for plugins/components. The store was what really threw us for a loop, we’ve built React/Redux projects before and had never seen anything like it. It’s seems to be a stroke of genius given the size of their project. In fact the issue we worked to fix was to make the method that retrieved React components from the store case insensitive as the nature of the project had multiple naming conventions.

At this stage in the project I started experiencing weird issues with Atom. We’ve all heard rumors or experienced brief periods of unresponsiveness from Atom but this was new: total and repeated failures. It simply could not handle the multitude of files when performing searches. As this was as good time as any I made the jump to the Microsoft VS Code Editor. I’m not going back. Opening and searching files is lightyears faster than Atom, and it has a ton of features to enhance productivity.

Better equipped I jumped back into the Swagger UI codebase to try and tackle a different issue related to presenting the model of a potential API response. The issue was to make a new button on the page that can control the view of each response. Currently it defaults to a “Example Value” of the JSON. You have to change the view each time you open an endpoint in the current state. Unfortunately I ran out of time. Making a new button, attempting to style it (they use SASS and we learn SASS later this week), and trying to modify the Redux store proved to be a little too much for such a short time and with the Turing schedule.

One interesting thing I ran across: Javascript decorators. It took a lot of research but from what I can tell they are an es2017 proposal. More to come on that in the future!

Devon Bull

Written by

Adventurer, tech entrepreneur, student at Turing.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade