Poster Child

Above is the poster we submitted for the College of Charleston Math and Science Poster Session. Working on the poster made us reflect on what we had done and what we have learned this semester when working on Jupyter notebooks. We feel like we had a good experience in open source, even though we had shortcomings. The session itself was an interesting experience. I especially thought it was interesting explaining our work to those who are not computer science oriented. We found ourselves surrounded by students of all branches of science and it was really cool to see their hard work as well.

Chapter 9

In my experience, software documentation is pretty hit-or-miss. It can be very technical and difficult to read but more informative. Other times its user friendly and readable and almost like an online tutorial. Sometimes there is not useful documentation at all. All three of these are possibilities when working with open source software. Jupyter notebooks is a large project and has some great documentation that can be seen below:

https://jupyter-notebook.readthedocs.io/en/stable/

There are six major sections of the documentation with installation and UI Components being the ones we used the most. We found the documentation to be user friendly and readable with plenty of diagrams and screenshots. We never felt bogged down by technical language and we could usually quickly find the answer to what we were looking for.

Chapter 8

The focus of chapter 8 of Software Development: An Open Source Approach is on the user interface.  The chapter stresses the Model View Controller (MVC). In this pattern, the software is split into three parts: the model, the view, and the controller. The model is the part of the program that contains the actual logic and operations that the program carries out. The view is part of the software that the user sees and interacts with. The controller connects the two domains and makes sure models and views are not communicating directly with each other.

UI security was another focus of chapter 8. While there are many ways a UI can be insecure, SQL injection was mentioned as the most common form of a threat. SQL injection is when a malicious user is able to insert SQL code into input and it is run by the program. This means the developer must be careful to limit what can be input  by users.

8.1a
The use of a default password is incredibly insecure. The program should force the user to create a password on the spot. There should be no period of time where the default password is in use. Many users would simply put it off and use the weak default password. The password should be long and contain different types of characters. This makes it considerably more difficult for the password to be guessed.

8.1b
The most common way I have seen to recover a password is through email. The program or service has the user's email address. The user can request an email be sent to them when they forget their password. The password change is done through a channel only the user has access to.

Reflections on my Progress and my Plans

We currently are stuck at a bit of a road block in our contributions to Jupyter notebooks. We want to add a progress bar to provide users with feedback when they are uploading files. As it stands, the user has no way to tell if the program is uploading the file. We know that this is done in Javascript and we have found a progress bar plugin online. We have the plugin working outside of Jupyter. However, we are not sure where it goes within the dozens upon dozens of JS files within Jupyter notebooks.

We reached out to more experienced contributors about a week and a half ago and have yet to receive a response. This is disappointing because other contributors were quick to help us when we were working on the accessibility issue. We read about poor communication being a common pitfall when working on open source projects, so this setback was not entirely unexpected.

Working on this issue has really made me appreciate just how large of a project Jupyter is. I have worked on large projects before in the CIRDLES lab, but Jupyter notebooks still dwarfs anything else I have ever seen. This means I spend most of my time working on the project figureing out how code works and how files interact with each other. This can be frustrating since I can spend hours with the code and not actually add anything.

Chapter 6

The following are exercises from chapter 6 of Software Development: An Open Source Approach.

6.1

function get_employer ( ) {
return $employer
}
function set_employer ( $new_employer ) {
$this->employer = $new_employer;
}
function get_contact_person ( ) {
return $contact_person;
}
function set_contact_person ( $new_contact_person ) {
$this->contact_person = $new_contact_person;
}
function get_contact_phone ( ) {
return $contact_phone;
}

function set_contact_phone ( $new_contact_phone ) {
$this->contact_phone = $new_contact_phone;
}

6.2

function __construct ( $f , $1 , $a , $c , $s , $z , $p1 , $p2 , $e , $t , $status , $employer , $contact , $contact_phone ) {
$this->f = $f;
$this->1 = $1;
$this->a = $a;
$this->c  = $c;
$this->s = $s;
$this->z = $z;
$this->p1 = $p1;
$this->p2 = $p2;
$this->e = $e;
$this->t = $t;
$this->status = $status;
$this->employer = $employer;
$this->contact = $contact;
$this->contact_phone = $contact_phone;
}

That Could Be Me in X Years!

This was my third time attending the College of Charleston Computer Science Alumni Symposium. The past two years I was glad I went and always had some sort of takeaway from the presenters. This year was no different.

There was a lot of advice for those not as close to graduation as I am. This advice was about things like study habits, networking, and keeping personal projects. Still, it is always good to hear this advice and I think it can still be useful going forward.

There was some advice about the initial job search after graduation. I am currently searching for a job, so I found this advice useful. One piece of advice that stuck out to me was not to be aftraid to take an internship. They often turn into full time jobs, and if they don't then you simply have more for the resume.

All in all, the event was more than worth my time and I'm glad I went. I recommend it to any CofC computer science student.

Release Early and Often

Chapter 9 of Teaching Open Source is titled, "Release Early, Release Often." The chapter is short, only a page long. however, it describes one of the most important principles of open source software. Developers should release new versions of their software in small increments. This means that there is less that can go wrong with new releases. When there are inevitable bugs and broken code upon releases, the problems should be easier to find and fix since there are few changes since the last version. Releasing early and often also shows that there is progress being made on development. Working on one big release and not releasing any updates may make the project appear to be dead. Releasing often keeps users and contributors engaged and interested in the project.

Release early and often works well as a principle in the agile development cycle. Releasing incremental updates is much more engaging with the community than the waterfall method and its large, all encompassing releases. After all, keeping the community engaged is an important part of open source development.

The Doc is in!

In chapter 8 and 9 of Teaching Open Source, we read about documentation. Within Jupyter there are not a lot of comments within the code. This can be problematic, and forces us to wait on the replies of more experienced contributors when trying to understand a piece of code. This slows down our progress and the progress of other contributors when they have to take time to answer our questions. There is documentation in the project's Github page, especially when it comes to installation. Lack of documentation is a common occurrence in open source software. We experienced this problem last semester too when working with Tanaguru. There was very little in the way of installation, and much of what there was outdated. Lack of documentation is a common pitfall in open source projects and we should all work harder to contribute.

The exercise involved commenting and documenting on our code within the open source project. Our first issue involved correcting some accessibility problems.We commented on code we changed with explanations of the color values we changed to make some text and buttons more visible. The code that we edited and fixed now stands out somewhat in the source code due to the lack of comments made by other contributors.

Planning to Meet Charleston

Along with my group member Ethan Hendrix, I am planning to attend the SC Linux Users Group. The group is focused first and foremost on the Linux operating system. They also have discussions on other forms of open source software. I find this interesting due to my work with open source in the CIRDLES lab. I would like to learn more about Linux as well. Right now, I only have experience with Ubuntu running on a virtual machine. I would like to run Ubuntu primarily on my machine in the near future. The group holds meetings on the second Saturday of each month and the next meeting is March 10.