Day In Review

We started the morning off with an iteration planning meeting. I was able to demo the nearly complete workflow which was good. After the meeting I was able to pin down the workflow, with all acceptance tests, integration tests, regression tests, and unit tests for the feature around the payments. I was able to delineate between system errors (exceptions) and user input errors (sad paths that lead to error messages) which is good because it allows the user interface to provide a feedback loop for the user while blowing up loudly if the system does not work as expected.

I was also able to pair with Brian today and do some really nice refactorings. The controller action for payment went from 19 lines to 7 lines, which was great. We were also able to build a validations module for the input in order to move some of that responsibility away from the controller. I started working with the UI and plan on continuing UI work and hopefully be finished before lunch tomorrow.

Day In Review

Today I put a workflow in place to go end to end and back with a payment. It felt good since this story was so large and took so long to accomplish. I am not, however, finished and I still have a good amount of refactoring to complete. There are a few abstractions left to make this code feel nice and clean. Specifically, my controller actions feels very procedural and it should be delegating a lot of what it does to other modules. Once I refactor and tighten up the workflow (ie: make the UI feel less clunky) then I will be able to call this done.

I feel happy with my code so far since it put in place modules that will be able to support all kinds of future (and unknown) transactions. That means that the development time for future types of payments should be shortened. We have our IPM tomorrow morning and I plan on demoing what I have available at this time.

Day In Review

This morning was spent working with pulling a gem from a git repository and having it work within the current project. Specifically, the gem was the payment API wrapper that I had been working on recently. We need to pull this gem from a private git repository since the code is not intended to be open sourced. Once I was able to have the gem pulled, resolving its dependencies, and working in the current environment I started writing a workflow to accomodate the gem.

When a user submits their banking information it will hit a payments controller. This controller will pass off to a payments interactor that will send a call to the payment API. Once it receives a response it will create a Transaction object to encapsulate all of the important payment data. This data will then be persisted for future use and reference.

(Retro) Day In Review

Friday morning I continued on working ACH payments. The gem is a separate entity so at this point it's a matter of setting the up for the workflow that will lead up to the use of the gem. I plan on continuing this into next week and then adding functionality to the gem as the customer requests it.

For waza in the afternoon I worked on jukebox. I had started the like aggregation needed for the song like weighting algorithm that I hope to implement sometime in the future. Unfortunately, I stalled on jukebox work because I ran into problems with Protocols and Defreords.

Day In Review

The Iteration Planning Meeting for the project I am joining happened this morning. It served as a good introduction for me to the app that I will be working on shortly. I was able to see many of the workflows available and familiarize myself with the features that are in the pipeline.

After the iteration meeting I continued working on my payment API wrapper. I finished the basic functionality needed to plug into the app, that is to say it accepts check payments. I plan on starting to include the API wrapper tomorrow.

Day In Review

I continued wrapping the payment processing API today. I ran into come issues with my integration test post-refactoring which lead me down a small rabbit-hole. Thankfully, I was able to pull myself back out before I lost too much sanity. Afterwards, it felt good to end the day totally green (specifically with unit and integration tests). Tomorrow, there is an iteration meeting and I am excited to introduce myself to the team by showing some of the functionality I have been working on.

Since the team uses JRuby, I've been running my test suite against JRuby before commits. I would develop in JRuby but it feels too slow for quick feedback loops (MRI, however, is blazingly fast). I feel as though clojure can evaluate at a quicker pace than JRuby and I'm curious to benchmark this to see if my feeling is true. If it is true it might be worthwhile to investigate the differences and see how they utilize to the JVM (I've been interested in the JVM lately for a variety of reasons).

Day In Review

I began implementing an API wrapper around a payment processing and verification service. The workflow involved building up the required xml, shipping it off, and then making assertions based upon the return values. The code can get overly complicated if one is not careful to separate concerns and build out modular pieces. The code itself is meant to abstract the API away from the main app in order to assure loose coupling.

I generated integrations tests when building. Thankfully, the service offers a sandbox server to test against. This meant that as I built the functionality I could fill in steps for the integration test to follow up to and including the interaction with the sandbox server.

(Retro) Day In Review

I've been without internet this weekend since I moved to a new apartment and am yet to have the cable guy visit. Before I start I need to give a quick shoutout to the Starbucks on Broadway and Sheridan for their wifi :) .

Friday morning I put some more time into the new internal 8th Light application I have started. The start of this project is exciting because there are many new idea that run counter to the canonical rails development. I've enjoying playing with some ideas and letting them fall into place with a red/green building and refactor cycle. Some of the abstractions took two or three attempts to feel right, but I am starting to finish up some of the beginning features and pass acceptance tests. Moving forward I will be finishing the first iteration's features and take a little bit of time to put a polish on the UI so it is not bland html.

Friday evening I had the opportunity to visit the University of Chicago for a hack night. It was a great experience because myself and two other 8th Lighters were able to share ideas with the students. I enjoy any opportunity where both parties are excited to share ideas two-ways and this was one such opportunity.

Day In Review

I continued working on the interactions between columns on the story board. There are many server and client side modules that all serve these interactions so the change I want to make alongside the decoupling I am doing as I go is getting tough. Fortunately, I was able to leverage the power or prototypes to add metadata to objects that were subclasses of backbone objects. This means that I can retain the inheritance and those benefits with attached metadata that lives outside of that child-parent object structure.

I also paired with Paul on an autocomplete feature. We ran into some walls in development, but I believe we were on the right track. One takeaway I had was to select your dependencies carefully. If you include a dependency that itself is a collection of dependencies don't then include a single dependency that clobbers what exists in the collection. It's important to be cognizant of the ramifications of included dependencies.

Day In Review

Interactions between story board columns is rough and I am beginning to think that the architecture is going to need to change for the story board backbone views. Instead of having 5 story collections it will all be condensed into one collection that each of the five column views shares. Then, we can attach some meta-data (that will not synchronize with the server) to each story and let the column views use the meta-data to decide which stories to accept and reject when rendering. Although I liked the five ignorant collections with one per view it is not useful for multi-view interaction and every spiked solution I have attempted so far has felt very hacky.

I also planned the beginning iteration for Abbacus today. I spoke with craftsmen and apprentices about the architecture of the application and what they thought would be good practice when starting.

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.

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.

Day In Review

I feel as though the design of my server is starting to pay off. After I did some very useful refactorings to my server it started to feel flexible and easily extensible. I was able to add a DB Persistor fairly easily. Implementing the DB Persistor was another story.

I first thought that I wanted to serialize my objects into strings to avoid any type problems in the database. There is an awesome library named Gson which serializes java objects into JSON. The user specifies the types expected upon deserialization and it works like a charm. There was one rough spot, however, and that is with interfaces. If you serialize an object nested with references to interfaces then deserialization becomes hell. The deserializer does not know how to recreate the concrete implementation of the interface since the deserialization type only contains nested interfaces.

In the end, I avoided that mess by making my database hold references to Object. I then type-casted when pulling references back out and it worked no problem.

Day In Review

In the morning I continue working on my HTTP server, working towards finishing the large story of my iteration. I had everything working except for one little pesky bug which in turn stopped me from completing my iteration. Of course, after my iteration I found the problem and had everything working. When I was reading the input stream of an incoming HTTP packet I had an if statement that asked if the input stream was ready to be read. This would fail ~1/100 times which allowed it to go unnoticed for a long period of time (and allow me to pass my acceptance test). In the end I added a while loop that sits and waits until the input stream is ready to be read.

In the afternoon I had my IPM with Paul. I made my stories smaller in scope and in points in order to avoid missing an iteration again. I will also be narrowing the scope of my recent blog post 'Students, Take Notice.' The new post will focus on acceptance testing for small school projects.

(Retro) Day In Review

On Friday I spent the morning working on my HTTP Server. After 8th Light University, we had a discussion about what the University events should look like moving forward. I felt like it was a productive meeting to discuss the changing style of the event (as more and more attendees are present). We also had a quick meeting for Artisan.

Afterwards, I took a look at the Jukebox code base in an attempt to try to implement a new feature. On the to-do list was a feature request for a hammertime to pause the system upon completion. The idea being that if a standup hammertime plays then the users will not want jukebox to continue afterwards to it can be quiet for standup. I plan to revisit the little work I had on this when I have some free time.

Day In Review

The day started with the bi-weekly Hosemonster IPM. Thankfully, the iteration is slow enough and laid back enough for us apprentices to take part and have the opportunity to learn. It's nice to both take time to learn about process, good code, and simultaneously deal with a live client. I enjoy the feedback of an IPM because the direction of the application comes forward while at the same time the client and team work out the details of the big picture. It's nice to see both of those perspectives come together at one time.

After the IPM I attacked a bug in the PDF generation for Work Orders. When the app split into two apps (Hosemonster and Limelight-Hosemonster-UI) there was a weird break in the templating for the PDF generator. I felt accomplished when I tracked the bug down because I was able to restore the previous functionality and remove a superflous function from the namespace. The solution felt cleaner and I was proud of that.

I also paired with Wei Lee on a big of refactoring in preparation for plugging in the graphs we had been working on for quite some time.