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
On my most recent plane trip, I got a chance to read Taiichi Ohnos Workplace Management: Special 100th Birthday Edition
I found the book sometimes jarring, perhaps it’s just the conversational style and the translation that means it’s a bit halting. The constant references to manufacturing terminology also makes it slow to digest, but I find it fascinating to see how many of these ideas easily translate into the world of software as well. The book touches upon a little bit of thing when he goes on to analyse the difficulties of the “white collar workers” and how it’s much harder for them to “go to the gemba” to see the results.
Much of the advice is still appropriate today. Many take aways reinforce many of the ideas espoused by many of the lean movements such as tool makers should not be separated from the tool users, or they end up creating tools that are not useful. The idea that improvement cannot be mandated centrally, away from the “gemba” but must be done by the people “on the gemba”.
The book also starts off with his attitudes towards people being human, the the problems that we have with our own mental models or misconceptions that lead us to be wrong. Chapters like “The wise men mend their ways” and “If you are wrong, admit it” are good examples of how to cope with these human traits.
The book is a short read, and is full of nice little soundbites. Probably my favourite out of the book is:
“There are so many things in this world that we cannot know until we try something. Very often after we try we find that the results are completely the opposite of what we expected, and this is because having misconceptions is part of what it means to be human”, in the Chapter: “If you are wrong, admit it”
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);
After presenting at the recent Quarterly Technology Briefing in London, Manchester and Hamburg I had a very good question from one of my colleagues about what feedback I found most valuable.
Our feedback forms were quite short with two quantitative questions (out of a 1-5 scale), and three or four free text questions. Although the quantitative questions gave me a good indication of general feedback from the audience, it is not specific enough for me to really understand what things to do more of, or things to do less of. It reminds me of a traffic light system some conferences used (red, yellow, green) for evaluating conference presenters. Fun, quick, but entirely useless to know why people put numbers down.
Although the free text answers to feedback forms take more time to read, the feedback is much more helpful, particularly around getting an understanding of where expectations for a session matched or didn’t match, and useful suggestions or ideas to focus more on. I can take this feedback and actually do something about it for a different presentation.
For conference organisers, or if you’re putting feedback forms together for your own workshop, please don’t leave feedback as a binary, or based solely on numbers. Although there are advantages to getting quicker to an evaluation, you don’t really know why people rated something well or not well. Ask open ended questions and provide these to speakers unedited and raw.
I think if conferences really wanted speakers to get better as well, I think having some peer presenters sit in a session and provide targeted feedback would be even better. I could imagine something like this could focus solely on the mechanics and/or execution of the presentation and give timely, helpful feedback to improve the session and the presenter.
Last year, I decided to backup my data in the cloud. I liked the idea of Crashplan because it encrypts stuff before shipping it off to the cloud. It runs in the background, and as long as you have a reasonable upload speed, backing up things like SLR photos aren’t so painful.
Unfortunately I rebooted my machine today, and found that my backup service was no longer working. I scoured their twitter stream, their website to see status, but it all looked good. I figured something must have changed on my machine. I forgot that I had installed JDK7 earlier in the week on my machine, but didn’t really link the two events because I barely need to restart the mac.
Fortunately this post told me how to reconfigure crashplan to run on Java 1.6 again. Thanks interwebs.
I’ve had this book sitting around for a while, but I thought I should get around to reading it. The snow in London and the cold weather gives me a perfect reason to get through a little bit more reading. The Coaching Bible: The essential handbook
The book is largely domain agnostic, although the coaching examples they use tend to be focused on a business context (i.e. not life coaching, sports coaching or agile coaching). I think that makes it quite accessible to any person interested in developing coaching skills, but aren’t necessarily looking to be a full-time coach themselves.
They introduce this “Multi-modal” coaching model made up of four different perspectives a coach can focus on:
, the idea here is that coaches are working with people who are working in a larger environment that drives their behaviour. It’s useful to step back and view this larger context, and explore it as part of the coaching conversationsI agree with quite a number of the other chapters in the book and I think they offer quite a number of practical examples and advice on items a coach focuses on, such as “Building the Alliance” with a client (agree on how/when to meet, develop an agenda, establish goals and how to measure progress) and the importance of identifying the “Mind-Body-State” necessary for both you as a coach, and the coachee to have a healthy conversation.
One of the most useful resources for a new coach is also found in the appendix, referring to core competencies outlined by the International Coach Federation.
Martin Fowler just posted an article I wrote, “An Appropriate Use of Metrics“.
Go on. Read it 
It ties in really well with his recent article about ThoughtWorks Eliminating Sales Commissions.
Last year, I announced the digital version of The Retrospective Handbook being released. As much as I feel digital books are important, I am one of those people who like reading using a physical copy of a book. It’s great for you, and it’s also a great way to give one away. And now you can too!
The print copy of the book is now available via Amazon (all the links are below). Buy one for you, your team or as a gift today.
I bought a NAS drive a year or two ago and I was trying to upgrade the firmware to the latest version, 1.60. Unfortunately along the way the firmware update managed to fail and I ended up with a bricked NAS. The result was a RED LED light blinking at me six times in a row upon reboot requiring. I tried quite a few combinations before I was able to restore anything. I’m writing them out here, step by step, just in case it helps someone.
Pre-requisites
I work on a mac, but the only software they provide to reset firmware effectively runs on windows. Fortunately I had a windows netbook still around that I could use to reset it.
Boot the machine using TFTP
This approach for booting the machine remotely is well-documented here, but unfortunately their linked software didn’t work for my case. A kirkwood one floating the internet and listed on this forum post seemed to work best for me.
The steps that worked for me included:
Reset the firmware
At this point, I figured, the machine is rebooted, now you have to apply some firmware. I downloaded the latest, and then waited to see if the machine would come up for an update. At this point, you need to make sure you follow the Force Firmware Update post instructions.
One extra step that I ended up having to do was in response to a “Couldn’t connect” problems. At this point, another post pointed out that I needed to remove my static IP I had set earlier. I changed the windows box, fired up the NasNavi (to obtain a different IP and to establish a connection to the Linkstation) and then I could follow the firmware update.
I rebooted the machine, and it still flashed red, but trying to go through this cycle again, at some point – I don’t remember when I saw yellow blinking lights. I counted them, and they informed me and, according to the manual, the machine was resetting its firmware. Yay! A little bit more waiting, and I had to repartition the drive and it was blue lights all on again.
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.