Pairing Tour: Day 7

Today I got to pair with Doug Bradbury on some Rails work. Doug is currently working on a new project, so we got the chance to lay some of the foundation of the app. All of the stories for the iteration are currently blocked because they are dependent on work being done by other developers, so we got they rare opportunity to spend the day refactoring. For this Rails app we are trying to use the Boundary, Interactor (Control), Entity pattern inspired by Uncle Bob. The goal of this is to make our tests much faster. By decoupling our business logic from our delivery mechanism, we will produce a better design that is easier to test. So we started by refactoring a controller action to not depend on an Active Record model. The required us to isolate the calls and return values from active record in our interactor (business logic module). Once we finished this we decided that we wanted to remove the dependency on Active Record from our interactor.  So we started to abstract the calls to Active Record into Database transaction objects. These objects represent one transaction with the database in the same way that application interactors represent one business rule. So, we created one Transaction class title FindAuthorizationByNameAndUid. The name of transaction itself clearly represents what this module is supposed to do. It can be implemented using Active Record or any other persistence mechanism. Most importantly, it can be easily mocked out in tests my an in-memory equivalent. By the end of the day we were able to remove Active Record models from the interactor and put them into transaction objects. The refactoring of the code was really easy. Since our interactor was already tested, we made all the refactors that we wanted and the tests still passed. However, we were unable to refactor our tests to not use active record objects. This is little bigger of a task because the in-memory test double must be built first. So, I'm going to pair with Doug again in the morning to see if we can find a good way to test the interactor without using the Database. All in all, it was a very enlightening day on how to decouple application logic away from Rails.

Pairing Tour: Day 6

Today I got the opportunity to pair with Craig Demyanovich. The first part of the day we attended a project retrospective facilitated by Uncle Bob. The retro provided a lot of context as to the history of the project, the team members, feelings about progress and the goals of the project. Essentially, the project is a "great big redesign in the sky". They have decided that their current application is no longer meeting the needs of the business, especially in the area of extensibility. As their business has grown, there has been an obvious desire to extend their application to serve more markets are more consumers. However, the architecture of their current system isn't able to support the growth of their business. So they have decided to redesign a new one. In some ways the new system is rebuilding the old application, but in many other ways, the new system is a "platform" in which to build other applications on top of. I say platform in a very loose way, because it's not really a platform. However, they have utilized service oriented architecture with the mindset that many other applications will need to consume the business logic that they are building right now. This is intelligent way to approach the problem of future extensibility. The complexity of the SOA has caused a few pain points along the way, however, the team seems to be handle the application very well by practicing the disciplines of TDD, pair programming, and continuous integration, all of which are new to the company. The team has done a remarkable job of coming into a fresh project and practicing disciples that they did not use on previous projects. The second half of the day, Craig and I were able to work on a few stories for the application. Close to the end of the day, we ran into an issue with the Ruby Date class. Our problem was simple, we needed to check that a given date was less than or equal one year from the current date. Here was our first try.

(Date.current - given_date) < (Date.current - 1.year)

However, this didn't work at all. The expression on the left side takes the current date and subtracts the given date, with yields a Rational, representing the amount of days between them. The right hand side takes the current day and subtracts one year, which yields a Date one year ago. So in the end we were comparing a rational to a Date which blew up. Our next try was 

(Date.current - given_date) < (Date.current - 1.year.ago)

This time the right hand side takes the current day and subtracts it from 1 year ago. However, this doesn't work either because 1.year.ago yields a DateTime object as opposed to a Date object, so this blew up too. So we massaged this a little to get it to work.

(Date.current - given_date) < (Date.current - 1.year.ago.to_date)

Finally! Both sides of the expression produce a Rational object which can be compared to each other!

Pairing Tour: Day 5

Today I got to pair with Brian Pratt. Since Brian was transitioning from one client project to another today, I got to sit in on the IPM for Brian's new project in the morning. Most of the stories picked out for the next iteration were front-end features and refactorings to prepare for a new UI design. So, in the afternoon we picked up one of the UI stories. This is a shift from my normal work, so it was a good learning experience. We had to use mock ups and a demo app as a template in which to redesign the header and footer of their website. This doesn't sound terribly complicated, but every one knows that HTML and CSS never like to play nice. We got caught up on a few styling issues throughout the day, but by the end of the day were able to successfully implement the design. I definitely learned a lot about working with designs and mock ups, as well as a few CSS caveats today. Although, one thing is for sure, I'm glad that I'm a developer and not a designer. On another note, I'm making some great progress in my refactoring of Jasmine, the BDD framework for Javascript. Over the weekend I was able to get all of the preexisting tests passing again. Now that the system is working as it was before, I believe that my next steps are going to be redesigning the internals (refactoring out the "Env" God object) and rewriting all the tests. Currently, Jasmine is tested with Jasmine. The source is used to test the source. This seemed cool to me at first, but now I'm convinced that it is a really bad idea. For instance, I can break all of the tests in the system by commenting out one line (the "describe" definition). This will essentially turn describe into a noop, leaving the system with no tests. So, I'm going to rewrite the tests without Jasmine. Also, there are some pretty nasty SOLID violations in there as well, so I would like to take a golden hammer to a few of those files. Should be fun.