Pairing Tour: Day 4

Today I had the opportunity to spend the day with Dave Moore on some client work. We were able to work on a few interesting stories throughout the day. Dave is currently on a team that is working on internationalizing a Rails application. I was able to pair with Dave while we tried to internationalize the social media widgets on the site, specifically the Facebook login, button, like button, and login window. This can be accomplished through calls to the FB API. However, we were seeing a very specific bug with Facebook's Api. When we opened the application in a specific language, say German, the Facebook button would render in German, no problem. Also, we could click on the login button and the FB Connect window would show up in German, no problem. Also, once we changed languages on our application, say we switched to French, the buttons would render find in French, all through the FB API, no problem. However, after changing languages in our application, the FB API login window would not change languages with us, even though the FB button was changing languages with us. After some searching we deduced that FB renders it's buttons solely off of the API calls you make to it, which can change on every page refresh. However, it renders it's login window based on the language that was specified when we first logged in, so we would see the window in German even though we had switched to French. We were able to track that FB was storing the locale information that we first gave to it within a cookie on the browser. So, our first instinct was to attempt to mutate the FB cookie every time we changed languages in our application. However, after some searching we found that altering cross domain cookies is not allowed. So, at this point we were essentially stuck. Facebook is going to render the login window based on the first API made to it. I definitely learned a lesson today about 3rd party dependencies. Even though they are extremely convenient at times, they come at a price of freedom. When you use a 3rd party library, you lose the freedom to manipulate every detail, and as I learned today, that can be a high price to pay.

Javascript Woes

Ever since I attended GeekFest at Groupon on Tuesday, I have been interested in working with Javascript a little more. The talk was about sharing code between client and server via Node.js. It really got me curious about what that would look like on real project. However, I've not had the opportunity to try it out yet. My exploration into Node.js and Javascript over the past week has led me down a very dark and desperate path. The first woe that I encountered in my exploration was modules. As I tinkered, I began to realize that defining and loading modules was a very fragile process. I was quickly dismayed. I did some googling and found and library called RequireJS. This library implements AMD protocol for Javascript modules, which is great because it offers a standard definition that Node and Browsers can use. So, in theory, one could write one application that runs in both places. I was happy again. Then I decided to explore some previously existing Javascript projects to see how they handle modularization. I took a look at Jasmine, the BDD framework for Javascript. As I was browsing their code, I realized that they didn't attempt to use any sort of module loading like I hoped. Instead, they compile everything into one file, test against it, and distribute it as such. This isn't a bad method per se, but I think that it is possible to do better now that the toolset for Node has matured. Also, I was really displeased to see that Jasmine has a lot of Ruby files floating around their repository (mostly rake tasks). This also isn't bad per se, but once again, the Node toolset has matured and I think its possible to do better now. So, with that in mind, I decided I wanted to hack on Jasmine a little bit. First, I deleted all the Ruby files. Second, I decided to reorganize the project structure to separate Node specific files from Browser specific files. Now, I'm trying to convert all of Jasmine core into Node modules via RequireJS. This is when the headaches started. As it turns out, it is hard to test a testing framework. For instance, when I change the test Runner, not only does that break the tests, but it breaks the runner that which shows me that the tests are broken. I know, headaches. Anyways, I'm continuing to refactor Jasmine and learn more about Node. I'm hoping that soon I will have enough grasp to write a simple Todo's application where code is shared between client and server.

Pairing Tour: Day 3

Today I continued my pairing tour with Steven Degutis. I worked with him on a client's Rails app. However, this particular client has a very interesting setup with their application. They have brought service oriented architecture to the Rails world. Their application is actually multiple applications communicating with each other via HTTP requests. This may sound pretty messy, but they have managed to isolate the service calls into gems, which are managed and tested on their own. So each service (i.e. Rails app) has its own gem that wraps all the HTTP calls so that the user of the service is none the wiser. This really doesn't seem to bad. However, in practice it hasn't turned out so well. The have experienced some pain in adding features to the services. Adding a feature to a services means updating all of it's clients as well. This is not an inherent aspect of SOA, but it is a sign that they have broken the Common Closure Principle. They are starting to see that many of these separate modules all change together, which means that they should be kept together in the same package. Unfortunately, there is no simple answer to solving this problem. Bring the clients and services together into the same package is going be very difficult, especially since both clients and services are Rails apps. So, I definitely learned a lesson about the CCP today. On another note, pairing with Steven was a fun time. He is very discipled. He sticks to his principles well. And, he is very fast. I don't think I have ever seen anyone type and maneuver around Vim like he does. I definitely leaned a lot by pairing with him. I'm not pairing with a Craftsman tomorrow, because it's Friday, so I get to work on some Open Source stuff. I've been interested in Jasmine, the BDD framework for Javascript lately, so I'm planning to work on that.