Cymen Vig

Software Craftsman Update

Tue, 12 Feb 2013 21:08:00 -0800

JavaScript

I’ve been working as a Software Craftsman with 8th Light for a little over seven months. The projects I’ve worked on have been interesting. All of them have involved JavaScript to some degree. I enjoy working with JavaScript but I’ve also started to see where frameworks can cause pain and where event-heavy code can become difficult to work with when the tools lag behind the practices. I want to spend some time digging into PhantomJS to see if it is possible to hook into events to make debugging easier. I spent some time digging around but it is early days.

I’m also interested in see if it would be possible to get more information on memory usage. Identifying DOM leakage is difficult. And of course identifying it on webkit is only going to help for browsers based on webkit however it would be a start. I would expect there to be more tools to help with this but I want tools I can run on the command line and have interfaces which can be used with tests.

In short, the developer tools with Chrome and other browsers are phenomenal however sometimes things seem more painful than they should be. Note that I am not blaming the tools but rather pointing out it seems like some don’t exist yet.

Apprenticeship

I took on a novice apprentice named Andrew beginning in January, 2013. It has been challenging his pipeline full while keeping up with all the other regular duties however it has also been rewarding to see the apprenticeship from the other side. He has made great progress with picking up TDD and with programming in general.

Waza

At 8th Light, we have Friday afternoons to work on whatever we would like to. I have been spending my time working on Abacus which is an invoicing system. The front end is written in Backbone.js with Mustache templates and the backend is in Ruby on Rails. The purpose of the system is to produce a PDF which has the invoice. I’ve started to move that to Clojure and iText after becoming frustrated with Prawn (Ruby PDF generation). Prawn is very capable however it has been hard to keep it from turning into a big ball of mud. I’ve also been working on putting Cucumber tests on the application using poltergiest (PhantomJS wrapped to use with Cucumber). The idea is to make it easier to simplify the backend so that it doesn’t have the requirement to generate PDFs and make it possible to refactor the application without breaking it.

Dell Studio 15 versus MacBook Pro 15 Retina

Tue, 12 Feb 2013 20:53:00 -0800

During my apprenticeship at 8th Light I used a Dell Studio 15 notebook which had 15.6 inch LCD with 1920x1080 resolution. I upgraded the hard drive to a solid state disk (SSD) once they came down in price and it came with 8 GB of RAM and a quard core Intel i5 CPU. The configuration I brought on the Dell Outlet also had a 9 cell battery. It ran Ubuntu well and overall worked great except for the touch pad. Occasionally, it would go wonky and just stop working and it didn’t seem as sensitive on the edges as some of my other notebooks. It had a more modern “seamless” touchpad which might have been part of the problem.

When I became a craftsman with 8th Light I chose a MacBook Pro 15 Retina with 16 GB of RAM (not possible to upgrade later) and a 512 GB SSD. The screen resolution at the optimal retina setting is not that great. The LCD panel can display 2880x1800 pixels however the slider on the display settings limits it out at 1920x1200. The optimal setting is 1440x900 which is great when my eyes are tired and looks really nice with fonts and vector images but just feels small. What I like about the display is that I can scale between 1440x900 and 1920x1200 when I feel like it and I’m not sacrificing quality with the lower setting like I would if I ran a lower resolution on my Dell notebook LCD.

The biggest difference between the two is the touchpad. The MacBook Pro has a phenominal touchpad. It is big and it is sensitive and I really wish my Dell Studio 15 had this touchpad or one even a faint glimmer of it. By comparison, the Dell touchpad feels like a dollar store special. Of course there are other nicer things on the MacBook Pro however I would expect that given the price difference. But it really only comes down to the touchpad between the two. I simply can’t explain how bad the Dell one is compared to the MacBook Pro. Note that I do believe this is partly due to the particular touchpad on the Dell. Other Dells and ThinkPads with the non-seamless touchpads have been decent. But even those are a far cry from the MacBook Pro touchpad.

Now if only it was easier to get Ubuntu running on the MacBook Pro Retina!

Challenges finished, on to Craftsman

Wed, 11 Jul 2012 10:37:00 -0700

I completed my apprenticeship challenges on July 6th, 2012. To recap, I began an apprenticeship in Software Craftsmanship at 8th Light with Doug Bradbury as my mentor on February 1st, 2012. I came to 8th Light because I suspected test-driven development was the right way to go. At the time, there were three main reasons I wanted to make a change: improving the quality of my work by reducing bugs, improving the accuracy of my estimates and the approach to meeting the estimates and improving the approach to long term maintenance. These concerns came out of other projects I worked on and I hoped that TDD would help me with my goals.

I am happy to say 5 months later that I do indeed think TDD will help. I accepted a position with 8th Light as a Software Craftsman on Monday. I look forward to continuing to work toward my goals and am very curious about the other methods in use at 8th Light.

I would like to thank Doug, Paul, Micah and the rest of 8th Light for their commitment to software craftsmanship. If you are reading this and are curious about 8th Light or any of these topics, I encourage you to stop by on a Friday at noon (check university.8thlight.com to confirm there is a scheduled event and RSVP so we have enough food). You can talk to employees and other people involved in the industry, grab some food and hear a presentation and spend the afternoon pairing on open source projects or on a topic you’d like to work on.

Challenges

Fri, 22 Jun 2012 16:15:00 -0700

Today I received my challenges from Doug. As mentioned earlier, I cannot discuss what they are so this blog is likely going to go silent for a couple weeks.

I rode my bike in again today and it was fun if slightly sweaty. I have to remember to take it easy as I get closer to the office. Unfortunately, on the way home I had a flat rear tire. I was carrying everything except a pump as the small one I’d purchased didn’t work. I walked to a bike shop, brought a pump and patched the tire out front with my kit. This worked out fine although I can now appreciate why some have more than a passing interest in small pumps.

Wrapping up the pairing tour

Thu, 21 Jun 2012 19:12:00 -0700

I spent the week continuing to pair with other craftsmen. It has been a good experience particularly in seeing the kind of projects that are being worked on in detail. In two days one can get a good feel for a code base even if it feels like a fleeting glimpse.

Monday was spent with Dave Moore at a client site. We had an interesting problem related to migrating data. First we fixed some bugs though but it was a good day.

Tuesday was spent with Eric Meyer at the same client site. We worked on getting some content in line with the style guide which turned out to be a bit tricky.

Wednesday was spent with Paul Pagel at the 8th Light office in Chicago. We worked on an refactoring an internal tool starting with the backend. The aim was to get to a point in which we could change on a view worked depending on three specific states. We got most of the way there.

Thursday was spent with Li-Hsuan Lung at the 8th Light office in Chicago working on a client project. The story we worked on involved changing how reporting worked. It was difficult as a presenter that takes data and formats it for presentation (it is consumed by a view) was being overloaded in some fairly complex ways. It felt like it was doing too much but we couldn’t refactor it before we accomplished what was needed by the story plus there was other refactoring work in progress that would likely change it significantly down the road.

Tomorrow I’ll receive my apprenticeship challenges. I’ll have two weeks to complete them. There is a lot of secrecy around the challenges and I don’t know what to expect and I can’t reveal what they are. So it should be an interesting two weeks.

Today I also rode my bike into work for the first time. Most of the way I was on Milwaukee Avenue which has a decent bike lane for the majority of the route. It was a good experience.

Prawn or wkhtmltopdf?

Thu, 14 Jun 2012 20:14:00 -0700

One of the internal projects I’ve been working on for the past couple months at 8th Light needed a PDF. At first, the PDF only needed to be one page long. With that requirement, choosing to reuse an HTML view by convert it to a PDF by rendering it via webkit with wkhtmltopdf seemed like an acceptable trade off. However, a month later we needed that PDF to support multiple pages. While wkhtmltopdf does have some paging support it is difficult to use. One has to apply CSS classes to prevent breaking over elements (so an element is not split over multiple pages) or use JavaScript work arounds. Perhaps there are other options but this is what we faced:

poor/difficult multiple page support
footer/header support depending on how the wkhtmltopdf binary was compiled
cross-platform issues with the binaries: the binary needs to run on Linux 32 and 64 bit along with OS X and be statically compiled with Qt – one gem worked out for us on OS X, another worked for heroku and the other Linux systems except 32 bit Linux (not 100% confirmed)

It was clear that moving from wkhtmltopdf to Prawn or some other PDF generating solution that provided more control had to happen. What wasn’t clear was how painful this would be. It turned out to be fairly straight forward to figure out Prawn and reproduce the HTML and CSS view used with wkhtmltopdf in Prawn. I still haven’t figured out how to have more control over one side of a table border but I can control paging with repeated header and footer areas along with page numbering.

The question in my mind is should we have gone with Prawn right away? Given our designers are used to working with HTML and CSS I think there was a lot of value to using wkhtmltopdf initially to let them tweak the layout without having to learn Prawn. But I would not rely on wkhtmltopdf after that – once the design started to solidify I’d translate it to Prawn. There is of course the risk one could create something with CSS that would be very difficult to create in Prawn but if people experienced with both are on the project that risk would likely be a lesser concern.

Pairing tour: Second day with Micah Martin

Thu, 14 Jun 2012 16:43:00 -0700

Micah and I paired for a second day focusing on the project we’d worked on the day before: a Clojure program that loads data sets, processes them into one or moere data structures and then runs algorithms on these data structures. That all sounds a bit mysterious but I don’t know how much detail I can go into. I was curious on the train ride out to Libertyville if we’d get to a fulfilling point at the end of the day. We did via tests. Micah is likely going to try it on data this evening and I’m curious to know how it works out (just because the tests are passing doesn’t mean the job is finished: the performance of the algorithm is critical).

Pairing tour: Micah Martin

Wed, 13 Jun 2012 21:49:00 -0700

Micah and I paired today at the 8th Light office in Libertyville. We worked on an interesting project that involved loading data into memory to create data structures that will allow extremely fast querying. We are working in Clojure which I’m happy to use again but realized today I’m very rusty on. I wrote my HTTP server in Clojure and it took a while to figure out some basic things but then it clicked and I learned enough to complete the task quickly by reusing the same idioms in Clojure over and over again. However that was couple months ago. Thankfully, I was able to explain to Micah what I wanted to do and he helped me fill in the blanks when it was my turn at the keyboard. I didn’t seem to slow down progress too much!

The work in Clojure was particularly interesting because while loading a large amount of data from disk we needed mutability. For this we chose to use atoms after trying some other options. We also tried type hinting and it seemed to cut the run time of one operation from around 60 seconds to 37 seconds which was quite an improvement. It was a lot of fun to pair with Micah and to work on a difficult problem in which performance is critical. I’m looking forward to tomorrow.

Pairing tour: Second day with Josh Cheek

Tue, 12 Jun 2012 20:18:00 -0700

Josh and I paired for a second day at a client site. As mentioned yesterday, the project is composed of many parts that communicate together to create an application. Each part is a Rails application or a Ruby gem that wraps a Rails application.

Today we picked up a story related to the one we’d worked on yesterday. It required that we change things in a number of different parts. Our final change for the day was a bit daunting: we only knew a Ruby gem wrapped a complicated part of the system and we needed that complicated part to do a specific thing in a specific case. In other words, we needed to send in something to a black box and have it give us an expected response depending on our input. Thankfully, this turned out to be a fairly straight forward change.

Pairing with Josh has been both productive and fun. We finished or made up on a number of stories. It was interesting to get a feel for his coding style. He has created a number of Ruby gems including:

deject: Simple dependency injection
surrogate: Better mocks including appropriately RSpec matchers, help insuring mock doesn’t get out of sync, and more! Josh wrote a blog post going into the why.
pbcopy: Copy to the system clipboard on OS X from Ruby code just like the pbcopy command.

Next on the pairing tour is Micah for Wednesday and Thursday.

Pairing tour: Josh Cheek

Mon, 11 Jun 2012 16:42:00 -0700

I met Josh downtown for the first of two pairing days. On the way in, I ran into Craig, Chris and Mark who were also onsite at the same client. The project is a large web application that relies on a number of compartmentalized Rails applications. The setup was interesting and not without some minor issues.

Josh picked up a 3.3 point story and we started working on it. The compartmentalization meant it took a little while to figure out where things were and how they tied together but pairing makes that all much easier. One of the interesting side effects of the compartmentalization is that when communicating from one Rails instance to another the controller input gets converted to strings. So for example, a boolean value of true gets converted to the string ‘true’. However that was not true in testing depending on where we were injecting values. So the code ended up looking a bit like this:

    if (params[:my_boolean].to_s == 'true')
      ...

The to_s would handle the case where the tests injected a boolean value and the case where the controller action parsed the input to a ‘true’ string.

I did think the setup was interesting as it compartmentalized testing. I only read a small portion of the code base but I could imagine that if it were all combined into one large application it would be painful in other ways. So it’s not really a case of good and bad but just knowing what the trade offs are and being prepared for them.

While coding with Josh I was thrown off a couple times by RSpec matchers that I didn’t know about. It was exciting to learn about some of them and it was clear that I should learn some more RSpec. At the end of the day, we had completed the 3.3 point story and Josh paired with another person on another 0.5 point story to set some configuration data. It made me happy that our work implemented the required functionality without overly complicated tests or an excessive number of lines of code (each line was warranted).