Week 5 Update

Since class was canceled on Monday, and I’m looking to get my blog post for the week taken care of before the very busy weekend I’m about to have I’m afraid I haven’t got much to say regarding the class, so instead I’ll speak on another topic I’ve been sitting on to post about when I need a prompt. Hackathons are a pretty neat part of dev culture, and knowing that we’re encouraged to attend hackathons as a part of our event participation credits, I felt that would be an appropriate subject!

As of this posting, I’ve actively participated in two, been involved in one from the outside, and will be volunteering for one next weekend (BrickHack). Of the two hackathons that I’ve had the opportunity to be a part of, one was a spectacular experience for me (RIT’s iOS App Challenge in January of 2016) and the other was a really poor experience that left a lot to be desired (RIT’s RIT48 challenge my Sophomore Year). RIT48 was my very first hackathon and I was pulled into a team by a classmate of mine to help out with some dev work. We settled on designing an infrastructure to help put food that would otherwise be discarded in the hands of college students. Users could post the location (on RIT’s campus) of an event with leftover food, as well as detail what kind of food was still available, then active users who were geographically nearby would receive a text notification telling them where they could find free food. We used Firebase’s API and an SMS messaging service to accomplish this, along with a web interface that exposed the posting service to users. We used github to version control our software, and our team was comprised of myself, another dev and a designer. I’ll spare the in-depth details of our development process, but the end result was an application that was functional, well designed, and easy to expand upon to use on other college campuses. Unfortunately we did not win, and a lot of my disdain for that experience was due to poor management, but I still think the experience was a valuable one for demonstrating to me that hackathons aren’t so much about “hacking” a system (like I had initially though) but instead were dev sprints like I had experienced in classes. In addition to this, our idea and application has been expanded by RIT’s Student Government and turned into RIT’s Food Sharing initiative.

The second Hackathon was last month so the experience is still fresh in my mind. RIT’s iOS App Challenge gave it’s participants Apple products and tasked them with creating a multiplatform application. I had the pleasure of working with other students I had done projects with in the past that I knew I worked very well with. Our final product can be seen here. We used GitHub to version control our software, as well as a few other image editing tools, and various open source projects to explore the capabilities of our hardware. The most valuable part of this hackathon experience was the fact that I learned Swift (the language for iOS app dev) in only a few days and was able to put together some pretty impressive code for this project. I’m very glad that I was comfortable enough with learning a new language from scratch to pull off a project like this and I would absolutely look forward to working in a similar environment going forward. This was a far better experience than the previous hackathon and the big takeaway for me was the fact that I was able to approach a hackathon with no experience in the language being used, teach myself the language, and still write good, solid code in such a short time frame. Knowing this definitely gives me a lot of confidence going forward for “going in blind” to more hackathons.

Besides the two listed above, while I was on co-op I had helped Hitachi Data Systems with their very first internal Hackathon. I did some work with helping to chose the theme, some suggested projects, as well as looking over all the end results and helping to judge. This gave me a very unique perspective on the hackathon process and it was a very enlightening experience to see it from the other side. There’s a lot that goes on behind the scenes to make these events take off, and being a part of that was definitely a valuable experience. In this case, having that background in hackathon experience will help going forward, especially when having the perspective of what a client (similar to the judges) are looking for when exploring a product.

With these points in mind, I’ll tie it all back into my experience with this class by saying this: Linux and FOSS dev in general is a completely new field of learning for me, and knowing how well I was able to adapt in a short time frame for hackathons in the past, I’m confident I’ll be able to get over the initial learning curve associated with the class (albeit with a lot of help from my classmates). I’m excited to continue learning for this class, and I think it’s a matter of continuing to dip my toes deeper and deeper into the topics we’re covering in class until I eventually get comfortable enough with it to tackle some of the larger problems (and larger bugs!) the class will be ramping up to in the coming weeks.

Week 5 Update

Meetup 1

This past Tuesday of Week 4 of classes, I tried to organize a trip to University of Rochester to attend a RocPy event as a part of attaining our meetup credits for HFOSS, but due to weather, I had to cancel.

To make up for it (and stay on track for meetup credits) I carved out some time on Friday (2/19) to attend an RITLUG meeting. I spotted both jflory7 and WilfredE from our class at the meetup as well.

The presenter discussed the significance of Package Managers on Linux systems to help manage dependencies. Before the existence of package managers, programs that relied on existing technologies either had to include all their dependencies in the product (creating MASSIVE files for complicated programs) or hope that the user remembered to set up their dependencies first. These design patterns lead to some computers having multiple instances of the same dependencies installed at the same time, or programs failing to run due to missing dependencies that users didn’t recognize the need for. To solve these problems, Package Managers were created to track what existing technologies exist on the computer, and recognize which programs require these dependencies. This means that you can download a project or application, and automatically get it’s dependencies with it, and the next time you download a project or application that utilizes one of these dependencies, the Package Manager will recognize that you’ve already installed it and prevent a dual installation of the same technologies.

I also heard the Red Hat name pop up a bunch which was neat! Further confirmation that the company I’m working for post-grad has some serious clout in the FOSS world!

This meetup also dispelled a lot of the preconceptions I’ve had about Linux users. In the past, a lot of the Linux users I’ve met were VERY pretentious about it, and used it as a method of asserting their superiority over Windows/Mac users but there was another first-timer who stopped by, and everyone was very happy to help him understand the basics of finding an appropriate distro. Additionally, while there was plenty of “Hey I’m aware of this unique technology that not a lot of people use and I’m mentioning it for hipster cred” it was all in good fun. I’m glad to see that everyone was pretty welcoming and I’ll look forward to stopping by at least once more later in the semester if there’s a cool topic being discussed!

Meetup 1

Smoke Tests pt 2

So today (Friday 2/19) I got together with jflory, JustBobbyThings and WilfredE on doing some of our networking tasks between the XO laptops.

We had a lot of troubles with getting the XO laptops to work on RIT’s network initially. We were all connected to the same wireless signal, with all our devices registered and were independently able to access web pages (like wikipedia and google). Despite this, our laptops couldn’t “see” eachother in the neighborhood view. We suspect this is due to the way RIT’s network is configured, but after about a half hour of wrestling with it, we all connected instead to an unsecured nearby hotspot. This enabled our laptops to communicate with one another and enable collaboration on documents! WilfredE and I both collaborated on the same Write activity, and were able to share images and text between our laptops wirelessly.








After collaborating in Write, we set up Measure to test the distance feature that the XO laptops have. When we both joined the same activity, and began the program, both of our computers emitted a noise, which the other listened to, and responded with. Through what I can only imagine is some complicated sound dynamics math, the computers were able to determine the distance between them pretty accurately!

We learned that the RIT network is AWFUL for allowing the XOs to communicate, but once you’re able to connect to a non-RIT supported wireless access point, the XOs can be utilized as intended!

Smoke Tests pt 2

Bugfix Assignment

EDIT: It got merged!! The pull request was approved and implemented on the course website, so it’s pretty cool to see my contributions to the class page whenever I visit it in the future.

This week, I was able to work out and complete my submission for the Bugfix assignment found here: https://github.com/ryansb/ofCourse/pull/69

I contributed to the class page’s repository fixing an issue with the coloration of links. Initially, these links were the same color as the base text so it was impossible to tell which text was click-able and which was plaintext. My change introduces additional specificity to the CSS that sets link colors to be different from the base text color to give it priority over the “normal” base text color. I began this process by posting a bug in the repo’s bug tracker near the beginning of the semester, and asking questions about how (and where) I should make my changes to fix the issue. Once I got in contact with Ryan (the owner of the repo) he was able to give me a wide variety of helpful tips for getting a development environment set up so I could make and test changes to the source code. Unfortunately, all the conversation that wasn’t done within the comment section of the bug on github was done through IRC that I no longer have access to (so I can’t post snippets of the IRC conversation). However, the jist of it was to stall Anaconda (a python environment), clone the repo locally, create a virtualenv to work within (conda create -n <PROJECT NAME> python=2.7 anaconda), ACTIVATE the virtualenv (activate <PROJECT NAME>) , and use the command “pip install -e .” before beginning to make my edits to the source code. Unfortunately attempting to make these changes on a windows machine (I haven’t got a working linux environment set up, since I do all my dev on RIT’s lab computers) lead to problems that went beyond Ryan’s expertise so he suggested the next best thing: use Chrome’s devtools to make and test the changes, download the edited CSS files, then replace the changed files in my local git repo before creating a pull request. That strategy not only made more sense to me (I was unsure of what each of the individual commands did at a deep level) but also was easy and quick for me to take care of. I made my relevant changes, downloaded and replaced the CSS file, then uploaded my pull request to the link I posted above. Hopefully it gets accepted for that sweet, sweet extra credit!

Now that I have a small contribution to an open source project done, I would love to contribute to something more major, but without a linux environment, I think the barrier to entry for windows-focused development is a little too high. I’ll keep on the lookout, but with class work stacking up, I’m not positive I’ll have the time unless an open source project in a field I’m experienced in pops up (if anyone reading this knows of any projects in C++, games in Javascript, or anything to do with HTML I would love to hear about it!)

Bugfix Assignment

Week 4 Blog Post

EDIT: Smoketests Part 2 here: https://spg1502igme582.wordpress.com/2016/02/19/smoke-tests-pt-2/

So after the failed attempt at heading out to the RocPy meetup on Tuesday night (due to like 4 feet of snow) my original plan to write about that meetup has been shot!

Instead, I’ll talk about our long-term goal of using the XO laptops in this course, and my struggles with the XO laptops so far. First and foremost we received our XO laptops in class on Monday and started discussing how they fit into our courses and briefly touched on the end goal of creating an activity targeted at teaching math to 4th graders. While I’m not entirely sure the route I’ll take to accomplish this (a lot of my ideas are going to be dependent on the graphical capabilities of the XOs) after exploring some of the activities preinstalled on my XO, I’m confident there’s enough to work with to put something cool together. I have around two years experience teaching students aged anywhere from 7 – 17 so I’ve worked with kids in the target age group and I’m hoping to pull on some of my experiences to help guide my project. One major challenge is ensuring the activity is entertaining and engaging enough to hold the student’s attention long enough to function as an instructional tool. In my experience, students this age have a much easier time focusing on one instructor teaching the entire class, rather than having each student focused on their own screen during a class. With this in mind, I will tentatively say that I’d like to utilize the XO laptops not as stationary learning tools with a teaching activity on them, but instead as a mobile platform that allow the students to interact with other student’s laptops in a unique way. Hopefully I could do this by grouping student’s laptops together, displaying numbers and mathematical functions on each, then asking the students to line them up in an order that produces a valid mathematical function (i.e. an equals sign, a plus sign, a 2, a 5 and a 7 could be organized into 2 + 5 = 7). The hardest part of approaching a problem like this is ensuring that each of the individual laptops communicates in a sensible way, and ensuring that all the data on all the displays is valid.

So far the Smoke Test assignment has been a bit of a pain point for me. I tried to run through them on Monday after we received our laptops, but I was missing various activities so I was unable to do a few of the smoke tests. Additionally, my laptop SEEMS to be unable to connect to RIT’s mess of a wireless network (WPA2 straight up denies any connection to the XOs) so a few other features (like downloading missing activities) have been impossible for me to do so far. I’m going to keep trying at it and try and work out some of the kinks for now. Hopefully once I’ve familiarized myself with the system a little more I’ll have less troubles, and I’m confident when I am more comfortable with Sugar’s environment I’ll be much more adept at developing for XO.


Week 4 Blog Post

IGME 582 Week 3

I’m writing this post a bit early, but I’m choosing a topic that relates back to our previous litreivew assignment to hopefully keep it relevant to what we will be talking about this week. Between January and August of 2015 I was on co-op with Hitachi Data Systems working on their Hitachi Content Platform and I wanted to look back on that experience in relation to Steve Webber’s What is Open Source?  and some of the points he touches on regarding the structure of large groups contributing to the same codebase.

In Steve Webber’s chapter, he touches on some of the channels through which contributors to a project communicate, ask questions, and plan the future of the project. In large part, he commends communication through technology in large part because it scales well. He says “Put 25 people in a room and communication slows down, whereas an email list can communicate with 25 people just as quickly and cheaply as it communicates with 10 or 250.” And I think that’s an excellent point for projects as large as Linux, but in my experience with Hitachi (and as well with smaller teams for school projects) communicating through technology poses a lot of problems.

Primarily is availability of individuals, if your team is made up of 4 people, the likelihood that any one person is available online to answer your questions as soon as you ask it is fairly low. In all honesty the other members of your team are working on their own projects during the weekday, or are busy with their own lives on the weekends, and I wouldn’t expect anyone to put that aside to answer a question for me right away. On larger projects, however, if you have an established IRC channel, you can post a question and you’re likely to get an answer within minutes from someone who is just “hanging around” in the IRC. This is a pretty huge advantage of technology, being able to quickly address a large group is a unique perk of technology that you wouldn’t have in a smaller environment.

Secondly, when I was working at Hitachi, it was far easier for me to walk over to a team member’s desk and talk to them face to face when I had a question. It gave us the opportunity to draw on the whiteboards what we were talking about, as opposed to trying to type out what you were trying to communicate in an IRC chat. Since most every member of the team wore many hats, it was a safe bet that any individual member of my team could answer the questions I had, nobody was particularly specialized in their contributions to the project. I think the face-to-face communication that comes with communicating offline is hugely valuable to me as an individual, as I’m a very visual learner. On the other hand, this wouldn’t work if you were collaborating on a project with a large number of people. On larger projects, individuals can be more specialized in what they contribute to a project, and if you have a specific question, you’d likely need to search out that person. This becomes far easier with a distributed communication system, you can post a message in an IRC chat or send out an email asking about a specific feature of your product, and the individual with the right experience can seek you out as an individual and share their expertise with you. At Hitachi, because everyone was well versed in the entirety of the project, each individual acted as an expert in the system as a whole, but that’s not something I’d expect of a larger project like Linux where individuals can be more specialized. In the lens of a project as large as Linux, using technology as a communication tool is vital, and the advantages of communicating face-to-face are lost.


Third, Hitachi as a company has release dates that need to be adhered to, and (to my knowledge) Linux does not. Linux rolls out updates and patches as they arise, but these aren’t expect to happen at regular intervals. Because of this, Hitachi’s development cycle would be unfit for exclusively online communication. There’s too great a chance of a message or email about a feature needing completion being forgotten or deleted by mistake, which would lead to an incomplete project at release time. The weekly check ins that project leads do kept each individual on task, and ensured that any forgotten projects or features didn’t slip through the cracks. With a project like Linux, the flexible release times leave room for a feature to take extra time to develop and potentially be forgotten about. Hitachi’s dev cycle couldn’t support missed deadlines, because as a business they need to meet the expectations of their customers.

With these points in mind, I appreciate the contributions that communication through technology provide to a project like Linux, and as I contribute to more and more projects and acquire more experience in this style of dev I’m sure I’ll come to appreciate them more, but at the time of writing, I’m still a proponent of face to face communication as my preferred method of collaborating. Weekly standups, face-to-face conversations, whiteboard discussions of project architecture and checking in with teammates are all aspects of dev that I value highly that are made more difficult (though not impossible) with communication happening exclusively through technology.

IGME 582 Week 3

My history with git

So as my first generic blog post (now that I understand that firstflight didn’t count as one of our weekly blog posts!) I thought it would be appropriate to cover my history with Git – a critical tool for FOSS dev.

In my freshman year one of my professors mentioned how critical Git knowledge was in software dev and how important it was to have a good understanding of its usages and syntax. I shrugged it off as something we’d learn later and didn’t think much of it.

Later that year we were introduced to our first version control software – TortoiseSVN and thankfully one of my team members understood version control enough to guide me through it (I committed to master a dozen times before I got lectured on why that’s a bad idea for an unpolished feature). TortoiseSVN wasn’t particularly kind for me and I was a bit scared off of version control because of it. Afterwords I avoided version control until my Junior year.

As a Junior in Game Design & Development, students take a game design course where we do three individual five-week development sprints in small groups. My team was lead by a student who had extensive experience using Atlassian’s Bitbucket software for version control. After telling my teammates that I hadn’t used git, or any version control since my freshman year, they immediately got on my case about learning it, and just how critical it is to development. I spent some time going through github’s tutorials and understood the basics just enough to get by. I used git in a pretty formulaic manner – I pulled the code, made my edits, committed the changes and let the project lead deal with conflicts.

At this time, I understood how to USE git, but not how git controlled the code, because I had a lot of trouble wrapping my head around how version control worked.

After the first semester of my junior year I had my first real co-op (rather than just summer camp jobs teaching grade school students to code) where I worked at Hitachi Data Systems on their Hitachi Content Platform software. At HDS, git was used very heavily along with a lot of other industry-standard tools for development like code reviews and a Slack for my team. Learning git in this environment was a bit of a trial-by-fire but after a few weeks of asking questions whenever I was unsure about what I was doing I started to pick up on the quirks of git and all it’s fancy ins and outs. By the end of the co-op I considered myself git-proficient in HDS’s environment, but I wasn’t positive I could apply what I had learned to HDS on my own projects (would the same commands work the same way? was HDS’s git environment set up in a proprietary way that would make my git experience defunct?).

After my co-op ended I returned to RIT for the first semester of my senior year and began working on two major projects for class, the first was website design for an interactive web course, and the second was a team based game development class where myself and four other team members collaborated on a 3D game engine I wrote to make the classic phone game Snake in 3D. The first class was relatively simple, I was working off my own code and was able to easily manage my git repository (as I was the only one committing to it), and it was a good way to re-use all my git knowledge from my co-op and re-affirm that despite my worries I still understood git.

The team project was a whole different beast. I was the only team member that actively understood terminal git and it was pretty satisfying to be the go-to team member to help people through their git issues as they ran into them. Because of this, I wound up being responsible for fixing almost all of the conflicts. It was a lot of work, and I had to do a lot of Googling to master all the weird git commands that would resolve conflicts and merge branches as I wanted, but it was totally worth the experience. After that class and all the complexity of working with multiple team members all building their own understandings of git, I’m comfortable with saying that I’m experienced enough with git to use it for any number of projects, as long as I don’t have to resolve everyone’s conflicts!

My history with git