Issue #1026

The team has momentarily split up. We had an unproductive number of people working on issue #1149, so I am now working on issue #1026. The problem issue #1026 addresses is that some gcode command parameters sent by the user via the terminal need to be uppercase and others not. Currently, the user needs to know what to uppercase and what to lowercase. The request is to make these commands and their parameters not case sensitive. The solution discussed by the community is to make a configurable list of gcodes to not uppercase.

OctoPrint - First Bug

As of now I am working with two of my fellow CSC486 class mates on the OctoPrint project - Kye Hoover and Ishwar Agarwal. Our first bug fix for OctoPrint is bug #1149. This issue is a request for arrow buttons next to the print object layer slider bar. The layer slider bar allows the user to scroll through the layers of an object the user wants to print. The problem is that this interface does not work well when incrementing one layer at a time. Arrow buttons would give this ability to the user. Additionally, key bindings to the incrementing function were requested.

At first glance the code for the slider bar appears to be contained in three files - bootstrap-slider.js, gcodeviewer.jinja2, and gcode.js. The jinja file holds the HTML for the slider bar which has a function in the gcode.js file which calls the slider class in the bootstrap file. Our team is still in the brain storming solutions stage, so my next post will be on what we've come up with.

OctoPrint - Setting Up & Getting Ready

Installing OctoPrint for development is very straight forward. The process comes down to cloning the repo, setting up a virtual environment in the developer's branch, and starting the server. A friend of mine has the detailed instructions on his blog so being the friend that I am I will just leave a link to his post here -

https://hooverkblog.wordpress.com/2016/03/21/octoprint-development-setup/

My next step is to complete the developer tutorials and then hopefully find an interesting bug to fix or plugin to write. For those interested, the link to the developer tutorials is given here -

http://docs.octoprint.org/en/master/plugins/gettingstarted.html

OctoPrint

I'm switching gears from OpenMRS to OctoPrint - http://octoprint.org. OctoPrint is host software for 3D printers. It is a smaller FOSS project than OpenMRS and the community response time has a better track record. What makes OctoPrint an especially interesting project to me is that it is written partly in python and uses flask for it's web development (a language and web development tool that I am both very familiar with). My next will post will cover the installment procedures.

Dropping OpenMRS

I've decided to drop the OpenMRS project. My two biggest issues with the project were the setup and the community's communication. The problem with the developers' setup is that there are many different ways to setup OpenMRS and some of these methods are outdated. The documentation for setting up is incomplete, which led me into issues I didn't know how to fix. Several weeks in I found success in launching a local instance of the reference application using vagrant -

https://wiki.openmrs.org/display/docs/Developer+How-To+Launch+a+Local+Instance+of+the+Reference+Application

A friend also working on, and struggling with, setting up OpenMRS showed me this after communicating with the main contributor of the project. This method works very well, but it is not mentioned on the developer's setup page. All this is just to say that the online documentation seems to be outdated.

Finding issues to work on didn't appear difficult at first. The issues tracker made it easy categorize and find issues. The problem I ran into was the documentation on most issues and lack of communication from the community on the specifics of the issues.

The OpenMRS project is a great cause, and I would encourage experienced open source developers to join the effort. However, for a novice FOSS engineer this project was just too much hassle.

Communication

This post is a quick self-reflection on my communication skills and deficiencies. Communication is important in any FOSS project, especially in project as big as OpenMRS. I would say when it comes to communication I am friendly, to the point, and cooperative. I often get along well with team members in coding projects. I think programmers are generally easy to get along with. Where I struggle in communication is dealing with people who don't know what they don't know. I try to be clear and honest with people when I think they are out of line, but I struggle with assertiveness towards overly assertive people. Ideally, it would be nice if every coworker I ever work with was honest and clear about what he/she doesn't know or is unclear about, but I know this is not going to be the case. As it is, I need to work on my confrontation skills.

Class Contract

The purpose of this post is to discuss the contract, regarding peer collaboration, constructed by the professor and students of the CSC486 class. If I could sum up the contract we came up with in my own words I'd say it boiled down to 6 obligations:

1. Effective communication

2. Quality contribution

3. Organized documentation

4. Organized workflow

5. Supportive teamwork

6. Clear goals

As discussed in class, the theme of these obligations is finding the right balance between experience and product. Personally, think the emphasis in this class should be on the product, and as such I think there should be more weight on obligations 2, 3, 4 and 6. Communication and teamwork are important, but in a class of upperclassmen I think a deficiency in these areas is more easily spotted and righted than a deficiency in product. If a student has a complaint about let's say, someone in his/her team contributing too much or too little, he/she is capable of resolving the problem right then and there and should do so as he/she would in the workplace. In the case of project output, however, spotting deficiency is deceptive. How does a team know which aspects of the project need more attention? Do they know what their end product looks like and are they on the right path to achieve it? I think these questions are trickier than how to resolve teamwork issues, and more grading emphasis should be given to them and questions like them.