Crowd Computing

Last year, I was a part of the inaugural HackGT. This is an annual hackathon sponsored by Georgia Tech, which seeks to gather programmers from all around the country for one weekend to develop the best app they can. The grand prize is $60,000. The prize drew a lot of interest, but what compelled me to participate was the presence of a variety of big companies with new technologies. One such pre-announced presence was Intel, with an early look at the Edison board I wrote about last week. The board fascinated me, and the ability to hack on one for a weekend before it was even available for purchase ensured my name would be on the HackGT signup list.


If this word is unfamiliar to you, its time to learn. Hackathons are spreading, becoming more frequent at software companies, schools, clubs, even cities (see HackATL) because of their tendency to produce minimum viable product prototypes in a short amount of time. Essentially, a hackathon is just a gathering of programmers with the resources needed for extended programming times. Often these hackathons feature diversions and entertainment to allow for breaks, food and drink so you never need to leave, and caffeine and/or alcohol for those late night coding sessions. At the end of the 24-72 hour span, apps created by the participating teams and individuals are presented to judges in order to determine winners. These winners could be awarded prizes, or have their idea produced, or may even be offered a job.

Crowd Computing

Crowd computing was my HackGT project, done over a 48 hour period with 2 teammates. (See how much more sense that makes after the intro?)  The idea was to create a big data platform on a tiny board. These Edison boards were great, but they lacked space and computational power compared to traditional computers. In theory however, their price meant that there would be many of them. The number of boards combined with a tendency to be used for passive computation made them ripe for use in cloud computing. Essentially, jobs that couldn’t be run on one board could be run on LOTS of boards working together. A simple website would allow for you to enroll your board in the program by installing a tiny script. This script reports to the webserver every couple minutes to verify the availability of resources on the board. When a job submitted to the website needed boards, yours could be chosen, and the un-utilized resources would be used to compute a portion of the job. When a few dozen boards contribute as such, the resultant power is pretty astounding.

Our app leverages the Map Reduce framework common in big data applications, with a tiny twist. since the boards are hardly big enough to function as nodes, we had to use something with a little more power as the master node. The webserver played that role, allowing for mapper scripts to be run on it that distribute data and a reducer script to the Edisons. From there, the boards would each execute the reducer script on their small portion of data, then return the output to the webserver along with an id which denotes which board the data belonged to. In our proof-of-concept demo we used a very simple example. A single Edison would first attempt to sort the entire text of  War and Peace alphabetically in a very short python script. Simply allocating the space for the novel alone was a struggle, and once the sort process began, the ram began to overflow and the board rebooted. This was expected. This task is simply too large for the memory and computational capabilities of the device. For contrast, we uploaded the same task to our webservice, to which we had registered 6  boards. A mapper script was created along the following lines:

def map(text):
words = text.split(' ')
letters = dict()
for word in words:
#map each word to a list by its first letter
letters[word.lower()[0]] .append(word)
return letters

This split the book into 26 arrays by the starting letter (plus a few for symbols) for every word in the book. Now, we had smaller chunks we could work with. The webserver sent a single array of data to each device, along with the index of the array. Since “A” comes first, a machine would receive all the words beginning with “A”, plus an ID of 0. The device also received a short python script, which told it to sort the list, then communicate the results and original ID back to the webserver. This process repeated until all the arrays of words had been sorted and returned. At that point, the web server would run it’s handler, which sorts the lists by ID. Since “A” had an ID of 0, “B” was ID 1, and so on, the result was a completely sorted novel in a short period of time. In our example it took around 15 seconds to sort the entire book. When some of the devices are in use it may take longer to lobby for access to CPU time and memory, but the idea remains the same.

Where are we now?

The code is on my github. It was just recently open-sourced, and there’s a reason it took this long. The code is VERY sloppy. One of the downsides to hackathons is that programming competence tends to decrease with tiredness. After 36 straight hours of working on the code, we began to make VERY bad mistakes. compound that with a teammate leaving in the middle of the night and frustration with new technologies and poor internet connection, and you get a mess. I’m not entirely sure that what is on github will actually work anymore, and I know that what was on the webserver no longer works. However, over the course of the next few weeks, I intend to revisit it and clean up large sections of the code, hopefully producing a live website soon enough. Please feel free to contribute and fork, or just stay tuned for a beta invite if you own an Edison board (and if you don’t you totally should).

Visit the code HERE

That’s all for this week. Next week I will wrap up my discussion on the Edison for now with my latest and current project: “Rest Easy”. Until then, raise a glass and code on.


The Backlog

It’s finally time for my return to regular posting. Over the last year, the rest of my life caught up with me and conspired to keep me away from any and all free time in which to work on this blog. Just since my last post, I have graduated, gotten engaged, moved twice, and started a new full-time job! It’s been a pretty busy 6 months. On the bright side, thanks to the long hiatus, I have a lot of material to cover over the next few blog posts. Last semester I completed 4 long-term projects in a variety of languages and platforms, and already at work I’m learning spark, chef, scala, postgres and more. There will certainly be no shortage of topics. Additionally, before choosing my current job, I ran the gauntlet of interviews with several companies, meeting lots of cool people in the industry. In particular I want to give a shout-out to the Microsoft team in Charlotte, NC. You guys were the first readers I ever met in person, and I hope to make it interesting for you in the coming months!Without further adieu…

The Meal Manager

I have discussed this software previously, but this semester, some SERIOUS work got done. At Georgia Tech, you are required to complete your degree with a “capstone” project: a semester-long project simulating a real company development cycle. My team chose to develop the meal manager in to a working app, and after a semester’s worth of frustration, hard work, and learning experiences, the payoff was tremendous.

Actually details the contents of my kitchen right now...

This is what you see when you first open the app

viola. It might not look like much, but there is a lo going on here. First, if you compare to the original screenshots, you’ll see my baby got a face-lift. We decided to model the UI after the Windows 8 “metro” patterns, using matte colors and lots of squares. The UI is also now completely configurable through settings, allowing for different color schemes and “look-and-feel”. Additionally, you may notice that a lot of the grid-like structure from the initial app has been replaced by the more modern stack panel look. Behind the UI, the changes are much larger.

This is making me hungry...

More Squares and a lot of recipes.

This screen is where you browse recipes. This picture only shows a few, but our database now contains 48,438 unique recipes! One of the benefits of working as a team was the ability to work on multiple high-priority long-term tasks simultaneously. One of the teammates graciously volunteered to be our data scientist, and set about scraping recipe sites for recipes. Additionally visible on this page are the search and filter controls. The “have” vs “all” radio buttons are especially helpful here. They control a filter on all displayed recipes, determining whether or not to display recipes which meet the criteria, but require ingredients not currently in your pantry. Someone wanting a meal to make right now would use the “have” button, search for some tags or ingredients they like, and choose a recipe. On the other hand, someone planning meals for the week could look at the “all” view of the same search to find recipes they can plan for.

Speaking of planning…

Built this calendar control by hand. APPRECIATE IT!!!!

Double the views for double the fun!

This is the planner view. When you want to make a recipe in the future, you can plan it from here or the recipe view, and it will appear on the calendar. The calendar also has two view modes for different use cases. Some people want to see the whole month at a time, other just need to know the upcoming week. As such, pressing the “Change view” button will swap between a full month view, and an agenda style view of the upcoming 7 days. The information on the calendar is preserved across views, so don’t worry about choosing a favorite yet. It’s OK to love them equally, I know I do.

I don't have a witty comment here. Forgive me

Shopping made easy

This is the end result of your valiant planning effort. The Shopping list view lets you select a date range, and it will create a list of every ingredient required to make the meals planned in that time, excluding those already in the pantry. Currently it is a binary system, only concerned with having/not having rather than quantities, but there are systems in the works to correct that.

So what’s left?

We worked hard on this.

There were really a TON of branches...

Look at all those branches converging

It took some time to mesh as a psuedo-company, but once we got rolling, the biggest limitation was the time we had together. Given another semester, this code could probably be production-ready. However, we managed to make a fair bit of progress. I have dubbed this build a “minimally viable product” and ready for beta-testing. There are several bugs, a few features we wanted but didn’t get to, and I’m sure some which we haven’t even thought of. In the next couple weeks I will be migrating the software from using a shared development Database to a local database included in the installer. After that, the Beta test begins. We have a few people who have volunteered, but if you would like to join the beta and help us out, comment below and I will notify you when the build is ready.

It’s a new year, and one in which I hope to write here a lot more, so please stay tuned. Most importantly though, and as always, raise a glass and code on.


Ever watched an old spy movie? I’m talking your classic heists: expensive loot, black tights, ski masks, and the inevitable laser security grid. What if you could own one of those for yourself? For my bartenderbot project (which I am now affectionately calling pi bar) I have been tasked with creating a novel sensor. Since the nature of the product leads to inebriated users, the system needs to be fairly idiot-proof. As such, I am creating a laser security grid for cups.


Beware the laser array

Cup Security

The cups used in this application have a fairly limited size range. The code hard-scales recipes to max out at 12  oz to prevent overflow on Solo cups and shakers, and the smallest drink that makes much sense is 1 oz. As such, we can make some assumptions regarding our cups volume from another property, like height.  This laser security array will read that height (approximately) and give us a best guess of cup size. It is in no way precise, but it will hopefully prevent drunken users from pouring a 12 oz Long Island Iced Tea in to a 1 oz shot glass.

So where do lasers come in to this? EVERYWHERE.  The new design for the cup platform will look like the museum floor around the priceless sculpture centerpiece.  One side of the platform now consists of a  small project box with 3 inconspicuous metal washers sticking out of the side at various heights. The other side looks identical, minus the washers. Instead there are small holes in the box, with no visible parts.



The super secret dark boxes contain 2 cardboard sheets, keeping the insides as dark as possible. This is important for the tiny light dependent resistors (LDRs) nestled in the back. The LDRs are wired to 5V, through a simple comparator to grab an amount of light from their resistance levels. These resistors supply 25 MegaOhms of resistance in relative darkness, and close to 0 Ohms in direct light. I think you can see where this is going. When there is no cup on the platform, all three lasers hit the LDRs head on, supplying our detector circuit with the information we need to determine a cup’s presence. When at least one is blocked, we know SOMETHING is in the way. Using this, we can tell approximately how tall our vessel is to be! 3 lasers allows us to detect a shot glass, low ball and highball.  We are ignoring specialty glasses like martini glasses and margarita glasses for now for simplicity. But this can’t solve all our problems. You see, glasses are often made of glass. Glass is used in many applications for its ability to NOT block light.  So how does the system handles glasses?



LDRs are not binary. They are analog (which is another whole problem which will probably get its own blog post once I solve it), meaning they have a large range of resistance, dependent on the AMOUNT of light, rather than the presence. So when a laser passes through a glass, as long as it is weakened, it will be OK. Since glasses are often made of glass >1 micron thick, the scattering of light due to the change in the speed of light is quite noticeable.  Pinholes on the sensor box will allow directed, uninterrupted laser to hit the LDRs head on, but scattered light will hit with much less intensity. A circuit can be used to measure the voltage drop from the increased resistance and “call it” at a certain point. That point is called a threshold. This threshold will need to be experimentally determined due to the near infinite variety of drinking vessels.


Project Progress

The laser array has eaten up a fair amount of my time, but this weekend should be a productive one for the pi bar. The design has been created, so a rudimentary parts list is ready for shopping. Once a large amount of PVC and lumber can be acquired, the machine should begin to take shape. I hope to be posting a blog entry with a frame soon, so keep tuned, and keep coding.

Spring Break Pokemon Games

Hey everybody, I’m back! The past few weeks have been a whirlwind of school work and emergencies which finally let up just in time for spring break. Because of my limited time, I was not able to work on my recipe manager or the BartenderBot (much) but I promise I come prepared.  I had mentioned before that I had a tradition of programming digital versions of my favorite drinking games over spring break. Last break I coded Horse Races, and the one before that I made Circle of Death, both of which have a post earlier. This time, I made….

The Pokemon Drinking Game

Most of you know that I love Pokemon, drinking, and programming, so this just made sense. The game itself was designed as a board game some time ago by a user named “raith”. The game has seen many modifications, eventually resulting in the Pokemon Drinking Game 2.0, a circular board based game with many drinks, complicated rules, and a guaranteed good time. The numerous rules to keep track of made this game quite difficult while intoxicated (which occurs about 1/4 of the way through). My version lets the computer worry about movement and turns and instead farms out only the drinking.

Watch the dots move....

The game in mid-play

Making it Work

This game has so many complex rules, movements, turn skips, and history checks that the vast majority of my planned architecture was useless. Unlike a project for school, or work, or fun, this project was for use within the week. As such, clean-code got thrown out in favor of making it work. That is not to say I will not revisit it and clean it up, but for the time being, it is pretty ugly.  Here’s where we sit. There are 3 java packages involved, and they should be clearly named.

Backend – This package contains the control class which controls (duh) everything about game logic, along with any necessary models.

Tiles – There were so many custom tiles needed for weird behaviors, I made a new package of just those custom Tile models.

UI – This houses the GameFrame, which displays the playable part of the game.

These packages do not necessary adhere to their strict responsibilities, but once again, speed and function were emphasized. The Control class is a rather monolithic class, keeping track of all turns, players, tiles, and UI text and screens. All other models are used to store relevant data and have a few important methods. The most important is the Tile class’s landed() function. This method takes a Player (provided by the control when a player lands on a tile) and operates on that player upon the call. This aids in skipped turns or forced moves, along with several more complicated consequences in the specialized tiles.


Unlike any of my other posts, I am pleading to you for help. As I’ve described, the code is ugly, but the far bigger issue is that there are logic failures. The game “plays” and will track you to the end (though the victory image has not been added) but some of the tiles exhibit unwanted behaviors. I am aware of at least one tile where a re-roll results in a move, one which sets the next turn’s movement modifier incorrectly, and a couple other bugs, but they are rather hard to pin down where they occur.

So how you, the reader, the drinker, the good time guy can do to help is play. I have hosted the code in its usual spot on my github (here), and it is free to be grabbed and compiled. If you could play through the game and keep a list of bugs you find, I would love to finish off making this game work. Leave some bug reports in the comments, message me, or if you know me, come up and let me know where you saw problems.  Once the logic is working, I will chip away at the design and appearance until I am satisfied.

As always, code on, and thank you for your help.

Architecture: More Than Drawing Buildings

Chances are, if you are in the habit of speaking to programmers, you will hear someone referred to as an “Architect”. Surely, This person is not the designer of the building, still deeply involved with the company inhabiting it. Surely of all the places in a corporation in which to place such a person, the development team would not be the first choice.  And yet, no dev team would be complete without at least one architect.In case you haven’t figured it out, the architects I am referring to deal with the code architecture. Their job parallels that of a traditional architect in all ways but the medium. Where a traditional architect explores viable designs for the building appearance, the code architect is concerned with the appearance of the code. Just as the traditional architect can draw from Gothic, Renaissance, or Modern structures,  a code architect uses design patterns to match the desired appearance of the code. Design patterns should be familiar to those who have perused code banks before. Patterns such as the Factory Pattern, Singleton Pattern, and  FlyWeight Pattern (more here) are the frameworks off of which code architects build the structure of their application. These applications may have a unique structure by the end, but often include large sections adhering to one or more patterns.

Why do I care?

I am in a unique situation for this question. As a student, I have seen and written MANY poorly architectured programs. I am myself guilty of the monolithic class, every violations of SOLID principles known to man and beast, and cyclical dependencies galore. What sets me apart is that I have seen the error of my ways. At my first development job, I got to work with a veteran of code architecture. He encouraged me to separate concerns, abstract business logic away from models, and write an enterprise software that was maintainable and scalable. The difference in my code was astounding. No longer did I have multi-thousand line classes. No longer need I worry about changing constructors or variable names. The architecture allowed me to create concrete references, set it and forget it.

But… That’s a lot of work…

I know the pain. For instance in my current project I am designing a Pantry Manager/Recipe box/Meal Planner. If I want to make a new button on the UI that saves an item to the pantry I must follow a checklist:

My Recipe Box Architecture

My Recipe Box Architecture

  1. Create Class (in this case some thing like pantryItemModel in the Models Project)
  2. Create method in the relevant Manager (in this case the PantryManager in the Manager Project)
  3. Add method definition to Manager Interface (IPantryManager in the Interfaces Project)
  4. Create method in relevant Data Access Object (DAO) class  (PantryDAO in the Data Project)
  5. Add method definition to the DAO Interface (IPantryDAO in the Interfaces Project)

God forbid I need a new manager or DAO, because then I have to alter the Manager and DAO Factories in the FactoryProject. As you can see, the method call is passed down the chain. This seems unnecessary at a first glance; why not just write the method from the DAO in the UI? It is all about scalability. When the project grows, it is likely to change. The data fetching and saving however is likely to remain constant. By abstracting the business logic away from the data logic, changes can be made on the front end which use the same methods from further back. The structure also allows for project isolation, wherein no class knows about anything but what is needed for its function.

How could this benefit me?

Once the checklist above is complete for all data fetches and saves, the benefits become clear. Now when I want to save a new item in the pantry, I simply gather the form data into a new PantryItemModel, and pass that up the chain with something like this:

//domain call
private void savePantryItem(PantryItemModel pantryItem){
IPantryManager manager = ManagerFactory.getPantryManager();

With a set of domain calls for each user control, I can rule the WORL- ahem. I mean: I can rapidly code the UI and all gather all necessary data for display or saving. A couple long nights of setting up the architecture turns all the business logic and tweaking in to a few hours work. Mistakes happen, bosses change their minds and clients complain. Isn’t it better to change the wallpaper, rather than rebuild the wall?

Blog Stuff

I would like to formally apologize for my drop-off in posts lately, and let you know whats next. My bartenderbot project has hit a brick wall in the form of limited time. The next step is the construction of the frame for testing, and until I can find the time to hit up Home Depot for some resources, and then construct said resources, the project remains on my shelf. As such, the desire to code has manifested itself in the form of my Recipe manager thingy (which needs a name BTW) so updates on that are coming soon. Until then, grab a drink and code on.

Blast from the past, My first coding project

I’m going to be honest here, I’m updating for the poor HR representatives that have to look at this blog for research after reading my resume at the GT career fair. In order to give some personality to this mysterious author who’s thoughts you read so diligently, I have decided to write about my first real coding project!A little background, when I graduated high school, I KNEW I wanted to do Aerospace Engineering. Until orientation at GT (we call it FASET) at which point I decided I KNEW I wanted to do BioChemistry. I believed that new path was the one for me until I took a wonderful class in Computer Science. At that point, I was sure that I had been hasty before, so I waited an entire semester before realizing that this time I REALLY KNEW. So what magical class was so powerful as to make me change majors again and stick with it?

It was Jython

For the uninitiated, Jython is a special blend of the programming language “Python” and some common java libraries. This allows beginner programmers (like myself at the time) to create very clean object-oriented python code in a neat IDE with a console,  and makes visual animations easy.

Jython code in the JES IDE

Jython code in the JES IDE

Jython was my first experience in coding, and it saw my first “Hello World” program, very basic number programming, image manipulations, and eventually animations.  The final project of this class used a unique aspect of Jython called “Turtles”.  You see, in the parallel version of this class which was required for CS majors, the end of the class involved controlling small robots with attached pens around in a pattern. These robots were called ScribblerBots, but they were relatively expensive. Instead, our class made use of the visual libraries provided by java to create small turtles in a picture. The turtles could then be commanded just like the robots, moving and drawing lines, but they could also be used for animation.  By using an array of turtles, each with a certain job, the turtles could change the background to create animation, they could change colors to act as an animated object themselves, or they could drop images on to the screen to create new visual objects.

Our Final Assignment

We were expected to use everything we learned throughout the year to create an animation which satisfied several requirements. As best I can remember them, the minimum  requirements were:

  • Use at least 4 different turtles on the screen at the same time
  • Make at least one turtle change color and size
  • Make a turtle draw, move, stop drawing, and move again
  • Use a randomizer to change at least one attribute of one turtle.  (I went a little crazy on this one)

Beyond those requirements, the assignment was very free form, and we were encouraged to be creative. I took it to heart.

What Horror Hath I Wrought?

Screenshot of the animation

Screenshot of the animation

Pokémon. Registered copyright or trademark or whatever, but let’s be real, it was Pokémon. My goal was to recreate a Pokémon trainer encounter and subsequent battle. For those that have a JES environment (get it here) you can download my code and watch it with full randomness at the usual place. Feel free to download and parse it to see how it works, but remember this is my first real coding work.

For those who have no interest or capability to parse the code and execute it natively, I have a screen recording of the execution.

I hope you enjoy the movie and stay tuned for more!