Saturday, 13 September 2014

UCOSP Update, Week 1

Welcome to the first post of my UCOSP updates blog. I will be giving weekly updates about my contributions to the Freeseer project as a participant of UCOSP.

UCOSP (Undergraduate Capstone Open Source Projects) is a program where undergraduate students from universities across North America can contribute to an open source project and receive university credit. I am grateful for being chosen to represent University of New Brunswick at UCOSP, and I'm looking forward to contributing to the Freeseer team this Fall.

First a little bit about me. I am in my last year of my B.C.S. degree at UNB. I tend to be most interested in backend development and scripting languages, which makes Python a good fit for me. One thing I've noticed about studying Computer Science is that the classes are very theoretical and won't necessarily prepare you for software development 'out there'. So, I've been looking for any opportunity to contribute to software development projects, whether it be through a work term placement or an open source project. I'm particularly drawn to open source software development, because I've been an ardent user of open source tools, whether it be Linux, programming languages, DBMS's, or app frameworks, so I recognize that open source software and open source contributors have a positive impact on the world. Therefore, when I first heard about UCOSP, I applied almost immediately. 

So, I suppose what comes next is a status update.

Setting up my development environment:

I spent the first part of my week figuring out how to set up my development environment, after a few false starts trying to get Freeseer working in OSX (some libraries did not play nicely with the otherwise stable Yosemite beta), I decided the best way to go was to install a VM of Xubuntu. The only issue I have is Virtualbox does not want to recognize my MBA's internal camera, so I can't use Freeseer with a camera for now.

Deciding what to project to tackle:

Looking over the issues on freeseer's github, I noticed there was a story to create a GUI freeseer client that could control multiple instances of freeseer servers (github page). I thought tackling this issue would be a good way to contribute, because I have some experience developing REST API servers and clients, and am still interested in learning more about them.  In my most recent work term I worked on a team that was developing a REST API for a SIEM platform. Part of my time was spent developing a functional testing framework (using pytest) for the REST API server, which involved writing an API client in python. With that experience fresh in my mind, I'd like to do something similar for the Freeseer team. I also considered that there may still be some work to do on the server side before development of the clients can take place, and I already have some ideas about what needs to be changed or refactored.

One caveat about the issue I've chosen is that I'm (very) unfamiliar with front-end development in Python. The last time I did any front-end development was in my first year work term, and it was in Visual Studio's WPF (a dark time for me :) ). I do however have a voracious appetite for learning and am up for the challenge.

My progress:

This week I pulled the newly merged code for the REST server, and poked around, seeing how it worked. I noticed that there were a few places where some refactoring could take place. Mainly I noticed that the REST server and the recording api endpoints are very tightly coupled. This would make adding new endpoints unrelated to the recording api somewhat difficult. So I decided for the two weeks leading up to the sprint I would work on refactoring this code. After familiarizing myself with Flask, the backbone of our REST server, I moved the recording api endpoints from the server.py module to its own module called recording.py. I then opened a Pull Request for this work. I probably won't ask for this code to be merged until I'm done refactoring the REST server.

Next week:

Next week I want to move some more of the code found in server.py to the recording.py class. I noticed that all of the setup code for the server, found in the configure() function of server.py, was really code to prepare Freeseer to make use of the recording endpoints and not to setup the REST server. Therefore, I will move that code into recording.py, a more logical place for that code to be kept. My goal is for that recording api configuration code to only be fired if a user calls a recording api endpoint. There are ways to accomplish this using Flask, so it shouldn't be too difficult to do this week. The end result will be a REST api server that is more loosely coupled and modular, and will make the addition of new api endpoints easier.

Future:

After the refactoring is complete (should be done before the Toronto sprint), I will begin my work designing and developing the Freeseer GUI http client.

No comments:

Post a Comment