The intersection of technology and leadership

Category: Development (Page 3 of 18)

Number of commits in git

I have been working on a project that required me to work out the number of commits in a git repository. I thought github would show that in their display, but could find no such statistic once you get over a certain number. The only number I could find that indicated it was over 1000.

Git commit count on github

Searching around, there are a few solutions including most recently:

git rev-list HEAD --count


git shortlog | grep -E '^[ ]+\w+' | wc -l

The Karma Test Runner’s dreaded Script Error

I have been using Karma Test Runner for javascript testing and like using PhantomJS as the test browser as it runs headless and is super fast. However every so often, I encounter the dreaded line:

Error: Script error

The error often looks like this in the console:

Error: Script Error

Since I work often in small cycles of test-code-commit (or just code-commit), my solution is often to rollback and try again. I thought I’d spend some time trying to work out how to get better diagnostics. A bit of digging around and the suggested way is simply to change browsers that give you a view of the javascript problem.

You do this by changing your karma configuration. In my karma.conf.js file I would tweak the value as below:

Karma.conf.js for different browsers

I then run the test again, and look at Chrome’s in built javascript console and look for errors:

Missing resource

Voila! A HTTP Not Found (404) for a resource I had declared in one of my require scripts. In this example, I intentionally added it in to cause that error, but this technique is useful for when you just can’t work out why something is not working.

Base web project with angular, require, grunt and karma

I was looking for a project that had a good basis for a build that included angular (JS MVC framework), require (for modules), grunt (for build) and karma (for automated tests).

I came across this one in the end that looks like it will do the job:

I tried angular-seed-requirejs but it lacked tests, angular-seed didn’t have a nice build script and angular-seed-coffeescript and angular-grunt-coffeescript all lacked tests with karma.

It took me a while to find but this project seems to do what I want right now.

Implementing Continuous Delivery Workshop Prework

At XP2013, Christian Trabold and I will be giving a tutorial on Implementing Continuous Delivery. In order to prepare for the workshop we ask you to bring a computer and do the following before the workshop:

  1. Install VirtualBox (
  2. Install Vagrant with minimum of v1.2.1 (
  3. Ensure that you have at least 2.5GB of free space on your hard disk
  4. Ensure that your USB port is working so that we can provide the image via a portable Hard Drive/Stick.
  5. Make sure you don’t use local ports like 8080 and 8153 (We need these ports for accessing the apps on the VirtualMachine)

Making google analytics work with requirejs

We were trying to template google analytics and make it part of our requirejs setup. When we did what we thought was obvious to wrap it in a module and declare a dependency on it, it seemed to fail quite miserably.

The trick was that we missed that you needed to export a global variable. This means in the javascript file initialising google analytics we had to add the following code block

var registerGoogleAnalytics = function(accountId) {
  var _gaq = _gaq || [];
  if (window) {
    window._gaq = _gaq; // export as global
  _gaq.push(['_setAccount', accountId]);

  // rest of google analytics initialiser script...

Some links that helped us working this out:

Making jade and mustache templating work together

One our frustrations using jade and icanhaz (a javascript front end mustache implementation) was that when we were trying things that were obvious to us, jade would simply fail to template and we weren’t sure what was causing it.

Fortunately small TDD cycles and experimentation made us realise that it was the combination of new line characters and mustache code made jade work/break.

We would try something like this:

script(type="text/html", id="my_checkbox", class="partial")
    input(id="{{code}}", checked="checked", name="{{code}}", type="checkbox")

The set of statements above would be valid mustache (once converted to HTML) but jade complains because the {{name}} is on its own line. The fix was to use the pipe (|) character to force jade to recognise a line break. It looks like this now

script(type="text/html", id="my_checkbox", class="partial")
      | {{name}} 
      input(id="{{code}}", checked="checked", name="{{code}}", type="checkbox")

Simple, but not particularly obvious from the examples in their documentation.

A builder pattern implementation in Javascript

We’re using the builder pattern on our javascript project, as it useful for starting off with a set of defaults, but is clear when we want to override particular values. Although there are a few places on the net that describe who uses the builder pattern in javascript, they don’t really provide an implementation.

Here’s one that works for us:

var Builder = function() {
  var a = "defaultA";
  var b = "defaultB";
  return {
      withA : function(anotherA) {
        a = anotherA;
        return this;
      withB : function(anotherB) {
        b = anotherB; 
        return this;
      build : function() {
        return "A is: " + a +", B is: " + b;

var builder = new Builder();


var first = builder.withA("a different value for A").withB("a different value for B").build();

var second = builder.withB("second different value for B").build();

var third = builder.withA("now A is different again").build();


Independent Refactoring is Irresponsible

Both Michael Feathers and Rachel Davies recently recently wrote about attempts to make refactoring a more explicit step in the development process by adding a particular refactoring task to the board.

It got me thinking about my latest project, a green-field application where, in the last week, I think we almost tripled our estimated velocity. You might think that we gamed the estimates, bloating figures to make us look good, but we did not. We still used relative complexity to estimate essential work that must be done. We did learn a little bit more than the week before, but the biggest change was actually some preparatory refactoring. Before I explain why it worked, I’m going to take a slight detour.

I remember working with one client who spun up a “refactoring team”. It sounded great at the outset – a legacy application that had plenty of code as they knew the development team cut corners to meet their milestones. Rather than completely halt new development, they split out a small team who would refactor mercilessly. This team spent one whole month renaming classes, adding tests, adding patterns here and there, fighting the big cyclomatic complexity numbers and then claiming victory on their poor opponent (the codebase). The result after the refactoring team… new feature development slowed down even more.

When investigating why feature development slowed down, we discovered the following:

  • New, and unfamiliar designs – The refactoring team did some wonderful work cleaning up certain parts of the codebase. THey made some places consistent, introduced a few patterns to tackle common smells and honestly helped reduce the codebase. What they neglected to do was to inform the other developers of the new design, where they now needed to look for the same functionality and the intention behind the newly named classes. Instead, the developers working on new functionality struggled to find the huge, very finely commented code they were familiar with and then when they tried to apply their old technique for fixes, failed to do.
  • Immediately irrelevant refactoring – With most codebases, there are parts that change a lot, parts that change a bit, and parts that almost never change. In my experience (disclaimer: not researched) those parts that change a lot and are highly complex end up as a huge source of bugs. Those parts that don’t change can remain ugly and still be perfectly fine. In the case of this client, a lot of effort spent refactoring ended up in areas where new functionality wasn’t being added.
  • A divide in cultures – I heard a few snarky comments during this time from the new feature development team about the refactoring team, basically implying most of them to be developer-divas whilst they had to do all the grunt work. The result… by outsourcing refactoring, the new feature team basically cared less about the codebase and I’m sure they weren’t helping the clean up with the code they added.

Image taken from Will Lion’s Flickr stream under the Creative Commons licence

My reading on lean thinking taught me that you need to Build Quality In and that separately quality from the product ends up costlier and results in poorer quality.

The answer… is actually quite clear in Martin Fowler’s book on Refactoring:

Refactor because you want to do something else (i.e. add function, or fix a bug)

I return to my current situation. We achieved the tripling in velocity because we spent time thinking about why adding a new feature was so cumbersome. I’ll admit that I spent a lot of time (almost a day) trying to add part of a new feature, attempting a few refactors and rolling back when they did not work. I was trying to get a feel for what steps we did most often, and attempted several approaches (most failed!) to make it simpler, clearer and added the least amount of code. We did settle on some patterns and we realised its benefits almost immediately – adding a new feature that previously took us a day to implement now took us only an hour or two with tests.

I find that sometimes the most satisfying part of software development is actually reshaping existing code so that the addition of a new feature is just a single method call, or just a single instance of a class. Unfortunately I don’t see this often enough.

« Older posts Newer posts »

© 2021 patkua@work

Theme by Anders NorenUp ↑