Cymen Vig

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!

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.

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.

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.

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.

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).

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.

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.

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:

1
2
    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).

I’m trying out Twitter Bootstrap Modals and they are great however figuring out how to fall back to support browsers with JavasScript disabled seems like a pain. I went down a rabbit hole of trying to use partials that render partials. It’s certainly possible but I ended up reverting as it seemed like a overly complicated and painful path. A possible solution lies in taking the path of defining the fallback form first and then progressively enhancing it to a fancy modal. Perhaps there is a reason the common phrase is progressive enhancement instead of retrograde fallback.

I spent Thursday pairing with Brian Pratt. We jumped around on a number of studio client projects. These are done working from the 8th Light office. In this case, the Chicago office which I’ve spent most of my time with 8th Light at.

The afternoon focused on a big iteration meeting with a client. I stayed for part of it but then paired with Nick to finish some work on an internal project and did a Kata with Joe Shipley – a new apprentice visiting with Cory from 8th Light Floriday.

The rest of the afternoon was spent working on the internal project. We have an iteration meeting for it on Friday and I still have a big story to complete. There have been a number of smaller issues though that have prevented momentum on it. I’m also somewhat unsure that it is a good story: it came out of a number of compromises in order to get some bare minimum functionality within a set limit of time. I think some of the trade offs are not good as they may end up being painful in the long term. I’ve yet to communicate that though which I should do now.

I spent Tuesday and Wednesday with Colin Jones at the 8th Light Libertyville office. The first day was spent on a lot of smaller tasks and the second on somewhat bigger stories. It was interesting to see how Colin interacted with the client team. He has a long history with the client and the team has a lot of internal tools and processes that are not used at 8th Light. My fears about vim configurations were unfounded: I think Doug has one of the more complex setups and when I used it most we were using his laptop screen instead of an external monitor (at 8th Light when pairing one typically uses a large 1920x1200 resolution Apple or Dell monitor and two sets of keyboard and mouse).

It was also interesting to feel the velocity of a project that has been running for a long time with a somewhat unwieldy code base size. The mixture of size and meta-programming seemed to increase the complexity of working on the project by quite a bit. I’ll stop at this point as I don’t want to go into too much detail.

Working with Colin was a pleasure. It was particularly interesting to see his personal workflow and how careful he is in wording his communication with others (we were working remotely) to ensure clarity. Once or twice he apologized for this but I actually thought it was inspiring. The adage about apologizing for the length of a letter because one didn’t have the time to make it shorter definitely applied: concise yet clear communication is difficult to achieve yet certainly worth aspiring to.