Saturday 27 September 2014

UCOSP Update, Week 3

Hello everyone, this will be a terse update.

What I worked on this week.

I wrote a project proposal for the work I would like to accomplish this term. The document (WIP) is available here.

I spent most of this week catching up on the assignments and homework I neglected in Toronto, but I was able to sit down Friday and Saturday to research and write a project proposal. Originally I was planning on working on a GUI Client for the REST server, however, my sprint mentor Joseph pointed out that there was a lot of work that needed to be done before we can begin development for the client. After researching RESTful best practices and noting any gaps in the existing REST server, I realized that there was an entire semester worth of work that could be done. So for my project I will implement these best practices. Furthermore, I will research and implement away for the server to stream video to clients. I think that will give me enough work to last me for the semester.

Next week

Next week I begin researching and implementing authorization for the REST server.

Until next time.

-Brenden


Tuesday 23 September 2014

UCOSP Update, Week 2

Hello loyal readers.

This week was a fantastic experience. I travelled to Toronto to attend the UCOSP code sprint at Mozilla. I got to meet the other students contributing to the Freeseer project, as well as all students participating in UCOSP. We were also given a tour of the Mozilla building, and given a very inspirational talk about considering the importance of what we create as software developers. All in all it was a fantastic weekend and I am grateful once again for UCOSP covering most of my costs.

Here's what I got accomplished this week:

What I worked on this week:

This week I continued my refactoring of the REST server. Now all methods specific to recording endpoints live in the recording.py module, and methods meant to be shared by all api endpoints live in the server.py module. At this point, the REST server has the same functionality as the it did when developed by bohnje, however, it has been decoupled significantly, and as a result is much more modular. This will make the development of new apis much easier.

Now each API is separated logically and contained in a "Blueprint" which is an object that allows us to extend the REST server app object with functions and endpoints pertaining to that specific API. For example, in the recording api, the functions called to set up and teardown the recording api endpoints is contained in the recording.py Blueprint object, and will fire on the first call to the REST server automatically.

Furthermore, I got a number of comments from Thanh Ha and Michael Tom-Wing about style issues, which resulted in some more changes. I've taken note of their comments and will make more of an effort to follow the PEP8 and Google Python Style guides.

I had a great conversation with Freeseer mentor Joe Yeung about what I should work on for the rest of the UCOSP program. While I was considering developing a GUI Client for the REST server, Joe pointed out that there is still a lot more work that needs to be done on the REST server before we start thinking about clients.

Next week:

For next week, (this week really), I will be writing my project proposal. Essentially, I am going to research best practices for RESTful services, and see what needs to be added to our REST server as a result. Joe pointed out that at the very least, we need to implement some form of authentication, but my research will also point out other things that need to be implemented or improved. 

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.