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.