Day In Review

I was able to get the backbone storyboard into place today. It was a lengthy process of trial and error and tuning what was already in existence. I plan on refactoring some of the rougher edges in order to make the code more robust and readable. I also plan on taking on the merge to get this branch back into master fairly soon. From what I understand there are many conflicts to fix since this branch if fairly old and ~50 commits behind master. I've also been rough drafting and thinking about my upcoming technical blog post.

Day In Review

I spent the morning moving portions of the storyboard over to backbone. Some of the behavioral responsibilities will be staying in the their original storyboard classes for the time being since they are scattered responsibilities without a home in the new structure. Moving forward I hope to find the right way to express these behaviors within the confines of the backbone architecture.

In the afternoon I was able to pair on the jukebox project with my waza time. I'm hoping to implement a 'like' (that term may change) feature. When users like a song it will change the weight used when selecting songs. Currently, there are some fairness rules about picking songs between different users, but I plan on disregarding that in favor of democratic song selection. The feature has two tasks. First, we need to set up the app to collect likes per song, limiting a single song like to one per user. Second, we need to develop an algorithm for weighting the random song selection.

When thinking about the weighting algorithm it became apparent that the ratio of number of users in the system to number of songs in the system should invoke some kind of sensitivity on the weights. I also liked the idea of using that ratio in tandem with a logarithmic choice selection, meaning that there is a quick rise in song frequency when first receiving likes, but then the frequency starts to level off with the accumulation of likes. Fortunately, I've deferred the algorithm's implementation for the time being because the system first needs to have a like aggregation workflow in place.

Day In Review

The Backbonification (the term of choice at 8th Light) of the Artisan Story Board has been interesting so far. I'm enjoying the opportunity to approach the work I have to do in a iterative modular fashion. As I finish tasks I can start to put them into place independently of the work that is still yet to be done. This is afforded to me by the structure of Backbone.js, which I'm finding to be a really nice library to work with.

I'm also enjoying the opportunity to demystify the storyboard, to an extent. Backbone allows the responsibilities to fall into place naturally and it works out nicely. On one occasion did I have a little trouble finding the correct way to move forward. I have lots of redundancy in two views, namely a view of a story in the backlog and a view of a story on the story board. I first approached the problem with inheritance, but I didn't like my solution. The base class was useless, it was a view without a render method. I then moved away from inheritance and tried to use the Builder pattern to construct the common view and allow each individual view to work from there. I then backed away form this idea because it didn't feel natural. Ultimately, I went back to inheritance but forced the base class to implement the render algorithm but defer certain data plugins to the child classes. I then forced the base class to be abstract (not truly possible in javascript) by forcing an exception to be thrown when instantiating the base class. I like the new design and I feel as though it's a good pattern moving forward.

Day In Review

I completed the iteration dedicated to my HTTP Server. During my iteration meeting Paul and I discussed the one logical error in the architecture. Instead of relying on one Client Implementation to interface with an application, we should interface with one to many Clients and allow the routes file to specify which client a verb + path route will hit. This made sense because rails works in very much the same way (Rails, however, has a little more leeway since duck typing allows routes to hit an arbitrary method on a controller whereas I am using the Command Pattern to interact with a Client interface).

This makes the wiring a little trickier because instead of the user specifying the single Client to use, the server must now find all Client Implementations within the Application's jar file. This is, however, possible since java reflection offers the ability to ask for base classes. I plan on revisiting this in my free time, hopefully this weekend.

Moving forward I am going to be working on moving the Artisan Story Board to Backbone.

Day In Review

I have a 1.0 version of my HTTP server available for use. You can find it and download the .jar on my github. I feel fairly pleased with how the server has turned out. I was able to put together a simple Client app to pass all of the cob_spec acceptance tests. I also benchmarked my server and was able to handle 10,000 requests in ~16 seconds. I hope to improve on this performance moving forward by tweaking a couple of implementations. I also hope to introduce relative paths for the command line arguments because the absolute paths are a bit ridiculous to pass in to start the server.

I was able to use reflection to reference the Client Implementation. This turned out to be simpler than I had imagined, it involved loading a jar and then referencing the class in its specific package. I ran into one minor bug with the data passed in the PUT and POST types. I fixed my 'Analyst' to handle the edge cases and now feel confident after passing the cob_spec.

Acceptance Testing For Student Projects

As a college student majoring in Computer Science one can expect multiple short to medium length projects per class. Almost all (almost being 99.99%) students will, at some point, feel as though they have finished an assignment only to find that during their last sprint towards completion they had broken a feature. We all know the drill, we think we have finished and start checking our input and output against what it required. Then we notice that some tiny detail is now broken. When this would happen to me, and it almost always did, I would have a feeling of despair sink into my stomach. If it was the night before the project was due I would put on a pot of coffee and prepare for the proverbial all-nighter. This does not have to be the way college projects go. In fact it should not be and that is because all programmers have acceptance testing as their disposal.

Acceptance tests, "act to verify that the system is behaving as the customers have specified" (1). What does this mean to a student, since they have no customers? Think of it this way: as a student you must approach assignments as if it were your job, as if your financial stability and your reputation were at stake. Your teacher is your customer. You want to make sure that your customer is happy and for that reason you want acceptance tests to assure their happiness. In fact, how can you assure yourself the highest grade possible other than by proving that you deserve the highest grade possible? How can you assure your customers' happiness other than proving that their desires are fulfilled?

Of course you want the highest grade possible and of course you want to avoid all the terrible emotions and time that go in to fixing a project that had been previously working. The first step towards school project zen is to pick an acceptance testing framework. Then, begin to translate the requirements into a high level system requirement. Think to yourself, how will the user use the system? Let's look at a quick example from when I was in school. One of my projects involved writing a Chained Hash Map implementation. We needed to be able to add, delete, and lookup within the Hash Map. Excellent. Here is an example of high level design.

I write these first since these are the features I need to have implemented. As I code I am actively working towards completing these high level goals one step at a time. In fact, since this is a chained hashmap let's write one more test because we thought ahead.

I start at the top and work my way down. Notice how these steps are agnostic to implementation. The only way they point is towards succeeding in satisfying the client, not towards low level implementation. As I progress I write the steps in to fulfill the scenarios I have laid out. Best of all, as I move from one feature to the next I can assure that I have not broken previously working functionality. When I'm done I have assured my project's completion and my professors' (customers') happiness. Be sure to read up on your framework because each specifies their scenarios differently. Also, each framework glues their scenarios to their test code differently.

The beauty of acceptance testing is the quick warnings it can provide. When you are working and come to a stopping point just run your acceptance tests. If you have a failure see if it can be resolved quickly. If it can not, at least you now know (ahead of time) that the path you were heading down is the wrong path for completion of your project. Acceptance tests offer a red light to bad coding paths and a green light to good paths and ultimately project completion. Next time you receive a programming project take the time to write up acceptance tests, your future self will be thankful that you have.

1) Martin, Robert C. Agile Software Development. New Jersey: Pearson Education, 2003. Pg 13.

Day In Review

Today, my server and tic-tac-toe game went their separate ways. My Server received the name HT(TPS) Report, which is a reference to the most excellent movie, Office Space. My tic-tac-toe game is now a single jar and the TicTacToeClient, which implements the Client interface of my server, now lives inside that jar. That means that applications are able to use my server as a dependency and register themselves for the server.

I also have text file routes now. The user can specify a routes file and pass that in on server initialization. The end of the day involved me getting my head around the next feature. I will be allowing the user to specify a jar with a package that contains their Client Implementations and pass that, as a command line parameter, to the Server on initialization. I will then be using reflection to get the Class and make instances of that Class when necessary.

I also added command line arguments with JArgs. I highly recommend JArgs, it's lightweight and very effective.