The intersection of technology and leadership
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.
Searching around, there are a few solutions including most recently:
git rev-list HEAD --count
or
git shortlog | grep -E '^[ ]+\w+' | wc -l
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:
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:
I then run the test again, and look at Chrome’s in built javascript console and look for errors:
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.
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: https://github.com/StarterSquad/angularjs-requirejs-seed
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.
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:
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]);
_gaq.push(['_trackPageview']);
// rest of google analytics initialiser script...
}
Some links that helped us working this out:
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")
li
label(for="{{code}}")
{{name}}
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")
li
label(for="{{code}}")
| {{name}}
input(id="{{code}}", checked="checked", name="{{code}}", type="checkbox")
Simple, but not particularly obvious from the examples in their documentation.
Building quality into the build often means ensuring that certain patterns don’t exist in the code (like console.log). This grunt plugin allows you to fail the build if a regular expression is found in the files you specify.
Feedback appreciated.
More details here: https://npmjs.org/package/grunt-regex-check
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();
console.log(builder.build());
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();
console.log(first);
console.log(second);
console.log(third);
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:
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.
© 2024 patkua@work
Theme by Anders Noren — Up ↑
Recent Comments