Introduction
For the past two years I’ve been working at ECS as a member of the DATA team. Our primary job is to develop and maintain RESTful APIs for the school. Our APIs are starting to be used all over OSU, from the search page to the campus map.
I joined ECS the end of my sophomore year. It was very exciting for me because this was my first job as a software developer. I had had some small jobs before, but this was the first time I was being paid to code!
I have learned a lot at ECS about programming and software engineering in practice. Classes do not come close to approaching what a real job is like. They do not come close to preparing you for working on a real code base. Even the capstone series doesn’t really prepare you.
Titus Winters defines software engineering as programming integrated over time. Over the course of my two years at ECS I feel like I’ve gotten a taste of what real software engineering is like.
Although I am not quite finished with my degree, I’ve decided that it is time to move on.
I’m grateful for all the time and connections I made with my coworkers.
I worked with the incredibly talented José Cedeno, who has since left OSU. I worked with fellow students Jared and Tso-Liang, who later went on to become full-time employees. I worked with Takumi and Shujin. We recently welcomed two new students: Ian and Ian, and I’m confident that they will carry on the DATA mantle.
What we accomplished
When I started at ECS, we had two public apis:
- Directory – Search for LDAP directory entries using first / last name, email or username.
- Locations – Search for OSU locations including buildings, dining locations (with open hours) and extension offices.
Now we have ten, plus a few more that aren’t public, and plans for even more. Of course, I can’t take credit for most of those–that goes to the rest of the team–but it does show that our team is growing fast. We are also responsible for maintaining all those APIs.
In the time that I’ve worked here, we’ve gone from a mostly manual deployment process to a completely automated one.
When a pull request is merged into master in one of our repositories, it automatically kicks off a build in Jenkins. Jenkins builds the project, runs the unit tests, and if the tests succeed, it deploys to our development server. Once that’s done, our integration tests run against the live API. If everything seems stable, we tell Jenkins to kick off a build of the production copy, which goes through the same process and deploys to the production server. The API servers are all run inside docker containers for increased security.
This process is called continuous delivery, and I played an integral part in building the infrastructure for it.
—
One of the highlights of the year was participating in the OSU IT Hackathon.
The first year that the hackathon happened, I had classes all day, so i wasn’t able to contribute much. The second year, I was away on an internship. But finally, this year i had the entire day free and was able to see the project through from start to finish.
Together with Jared, Tso-Liang, AJ, Takumi, and Ian, we built a prototype of an integration between the campus map and the course schedule, showing markers on the map for each building that you have a class in.
We even won the grand prize!
—
Other things I’m proud of:
- Together with José, I designed and built an API from scratch for securely storing encrypted data.
- I worked on 3-legged OAuth integration, which will enable us in the future to build apis that enable access to personal information like, for example, just hypothetically, course registration data.
What I learned
- I got to play with technologies that I never would have on my own: Jenkins, Vagrant, Docker, Ansible, Groovy, and Gradle, to name a few. If you want to go into DevOps, having experience with these tools is vital. You’ll see them pop up a lot.
- I experienced what it was like to work with a team over a long period of time, as part of a large organization.
- I saw first-hand how a codebase evolves over time, over a period of several years. I saw how we modified our apis to adapt them to changing requirements and new sources of data; how they sometimes failed, and how we learned from those failures to improve them and make them more robust, sometimes re-architecting them in the process. I experienced technical debt, shifting plans, and real software engineering.
- I was part of a hiring committee, which was an enlightening experience. I’m sure my experience sitting on the other side of the table will help me during my quest for a job later down the road.
The future
Looking forward, it feels like the DATA team is going to expand and expand to become a central part of OSU.
Data and APIs are the future. A lot of data at OSU is tied up in private databases, only exposed through clunky web pages. Good, open, APIs enable developers to create applications that nobody has even thought of yet. They allow people to create mash-ups of services like we did in last year’s hackathon project, which taught Alexa how to answer questions about people and places on campus using our APIs.
One of the thing I had really hoped we would complete before I left is the catalog API. We released a preview of this in 2016, but ran into difficulty getting permission to use the data, so the project was temporarily shelved. Hopefully we will pick it up again soon.
