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.

Reflections on my Progress

When we first developed our timeline, we were conservative in our estimate of how many issues we could tackle within Jupyter Notebook. We noticed that bugs in the project get fixed very quickly, so we were worried bugs we worked on would be finished by someone else. We are now ahead of schedule because of this.  For our next task, we have decided to tackle adding a file upload activity indicator:

https://github.com/jupyter/notebook/issues/3139

Right now, the user does not get any feedback when they are uploading a file. The user has no way of knowing the program is doing what its supposed to. Our task is to add this feedback. We have discussed a few different approaches to accomplish this. One approach is a loading bar. This would provide the most feedback to the user since they would get a visual of the progress the program is making. However, this would be difficult for us to implement due to the involvement of graphics and our lack of knowledge of the components that upload the files. We would have to find or create the graphics to create a loading bar. We would have to thoroughly understand the process the program goes through to upload files to be able to properly represent its progress visually. Because of these foreseen difficulties, this will not be our first approach. Instead will will start with a simple text box message that appears when the file starts uploading and disappears when its finished.

This bugs me

6.4 Find the oldest bug that’s still open in your chosen project. Write a blog entry describing the problem, with a theory about why the bug hasn’t been resolved yet. (Bonus points if you can actually resolve the bug.)

https://github.com/jupyter/notebook/issues/56

Jupyter Notebook's oldest open issue was first created on April 28, 2015. It involves creating keyboard shortcuts to simplify help requests involving some called "mimebundles." I do not have a full grasp on the issue since I have no idea what a mimebundle is. It appears that many contributors feel that returning information in a mimebundle would be better suited to program as a whole instead of returning information inline as it does now. Both new and experienced contributors have worked on this issue. It has been edited and updated several times over the years. It was last discussed just a few months ago in December of 2017.

6.5 Figure out how to create a new account on the bug tracker of your chosen project. You’ll need that account very soon.

Jupyter Notebook does not use a specific bug tracker. Instead, they are posted to Github as issues. Issues often do not last longer than a few days, so this system seems to suit the project. However, this can make it difficult to claim a bug since someone else might just fix it before you. We will need to act quickly to be able to contribute to the project. We can also communicate through Gitter and Slack to discuss the project and bugs with other contributors.

Reflections on Open Source in Today's World

Why isn't open source hot among computer science students?

This article strives to address misconceptions held by those who are new to the computer science field. The author surveyed 26 attendees of a hack-a-thon for high school and college aged programmers. Personally, I believe this is too small of a sample, but I found my self agreeing with the points she makes. First she points out that novice programmers would rather work on their own projects than contribute to an open source project. When I was a freshman and software, I had several small projects which were nothing more than toys. I could have learned a lot more my attempting to contribute to an open source project. The author also points out that many new programmers do not feel that their skills are up to snuff. Contributing to a an open source project is intimidating and it can be difficult to figure out what is the best way to contribute early on. However, I have noticed that many open source projects are welcoming and have easier tasks set aside for on-boarding new developers. The last point the author makes is that young programmers often believe proprietary software is simply better than open source software. This is not true and its easy to point to examples like Firefox to show what open source is capable of. I am relatively new to open source, but I hope to contribute to open source projects in some capacity for a long time to come.

Can anonymity and accountability coexist?

The author starts by pointing out how anonymous communicative has always existed outside of the internet such as whistle-blowing, voting, and crowd sourcing. These forms of communication can lead to a more open flow of ideas. This thought is continued in the authors first example of reddit (my favorite website) allowing the free flow of creative and imaginative ideas through anonymity. However, as a regular user of the site, I have seen how anonymity has allowed the flow of dangerous or malicious ideas that would never be shared outside a cloak of anonymity. The author points out that there often is a lack of accountability. The author believes there should be other forms of non-anonymous communication to go along side anonymous communication channels.

I'm Git'n it

Git vs Github
Git is a version control tool that is run from the command line or terminal. It allows multiple people to contribute to one project at the same time. It it is also helpful for retrieving past versions of a project if a developer is unhappy with recent changes to the project. Github is a collection of repositories where code is stored. It is where code is pushed to and pulled from when we use Git. Github has a social aspect in that most projects can be viewed by anyone. Many projects on Github are open source.

Previous Experience with Git
I have used both Git and Github for a few years now. I first learned it for my work in Dr. Bowring's CIRDLES lab. I remember there being a steep learning curve, and I often had difficulty keeping my branches up to date when others committed work. I got the hang of it with the help of my team members.

Git and Ubuntu
When I first began installing Git on my Ubuntu virtual machine, I expected there to be some sort of difficulty due to my past experiences. I can recall very few times when installing anything on Ubuntu didn't involve some sort of hiccup. I was almost surprised when installing git took only seconds and worked just as I expected it to.

Joining the Project

After looking into our original three choices for our FOSS project to work on, we thought we would work on Yoda-Pa. However, we found that there was a very small number of issues to working, meaning our overall body of work for the rest of the semester could potentially be small. We looked at other projects and decided on Jupyter Notebook. Jupyter notebook is an open source notebook project with a thriving community and hundreds of well documented issues to work on. Some issues are even tagged specifically for newcomers to work on to get a feel for the project.

Joining the community was easy. I joined the community mailing list with my google account to receive updates on the project as a whole. I also joined the Jupyter gitter for chatting with others working on the project. There is also a stack overflow page for solving issues related to Jupyter. Overall, it appears the community is thriving and welcoming to newcomers.

H/FOSS Experiences and Reflections

Installing Open Source Software

I had some experience installing open source before, so I knew to expect some difficulty going in. I installed MIT's Yoda-Pa personal assistant on my Ubuntu virtual machine. The process was not too much of a hassle. The only issue I ran into was installing pip to make sure I had the correct dependencies and the correct version of python. Their website's documentation lacked detail and was somewhat ambiguous. I give credit to Yoda-Pa; their documentation was both up to date and detailed, which seems to be a rarity when working with open source software.

The Cathedral and the Bazaar

I found the metaphor of the cathedral and the bazaar to be true in my own experiences. In my experience as a Windows user, I feel like I'm often given one reality, or set of rules. Just like going to church and listening to the priest. The more experience I have with Linux systems, the more I feel I can truly use the system the way I want to, albeit with a little more work. I found the release early, release often component to be interesting. I know from experience working in the CIRDLES lab that this is often easier said than done. You and your team have to buy in to the idea completely. The upsides allow problems and wanted features to be addressed quickly. The author also talks about the benefit of many developers working on an open source project can wrangle in the complexity of large systems. The project leads must make sure that there is some sort of guidelines to contributing to project as far as documentation to make sure the code remains maintainable.

Ethics of Free Software and a Rebuttal

Meyer points out that free software often is and should be an ethical think to be a part of. However it is rare to see free software because developers simply need money to make a living. Throughout the article, Meyer is critical of Raymond, who wrote "The Cathedral and the Bazaar." He believes that Raymond's attempts to profit from the open source movement are unethical. He also criticizes Raymond's beliefs about Americans' rights to own guns. I agree with Meyer, but I do not think this article was the place to discuss gun rights. In the end, Meyer believes both commercial and free software are here to stay and both should work towards helping humanity.

One of the first things Raymond says in his response is that Meyer's truths are not proven, only that Meyer says they are "self-evident." Raymond does not like Meyer's commercial software developers, especially Microsoft. He does not think that developers have any obligation to help people and that they are fine just trying to maximize profits.

My H/FOSS Preferences

The first step in this course will be to select an open source project to work on throughout the semester. Specifically, we were looking for a humanitarian free and open source project (HFOSS). However, we found that many of these projects were either not kept up or were not looking for help. So we opened up our search to regular FOSS projects. For now, we narrowed our search to three projects:


MASTER HASH – MasterHash is a password manager that allows a user to have an almost infinite amount of passwords while only using their main one. What will make this product different from others on the market is that it will all be stored in one encrypted file which will allow easy transport. The software is written mainly in Java, with the GUI written in JavaFX.

YODA-PA – Yoda-pa is a small, fun, personal assistant via the command line.

SUGAR LABS – Sugar Labs® is a volunteer-driven member project of Software Freedom Conservancy, a nonprofit corporation. Originally part of the One Laptop Per Child project, Sugar Labs coordinates volunteers around the world who are passionate about providing educational opportunities to children through the Sugar Learning Platform. Sugar Labs® is supported by donations and is seeking funding to accelerate development.

Introduction

Hello!

My name is Drew Bigelow. I am a senior computer science major at the College of Charleston in Charleston, South Carolina. From this point on, this blog will be used to show my progress in CSCI 462 - Software Engineering Practicum. The course is instructed Dr. Jim Bowring.