force Grunt to fail when source files are not matched

Grunt is a great build tool and has revolutionised the way front-end developers work. However recently I discovered a drawback using the file function from the core of Grunt.

The problem stemmed from a project which had been moved around and refactored heavily, when moving from one build system to the next, various files and directories needed to be moved and restructured. As part of this some directories had moved and changed places. In the process the Gruntfile had also been refactored with the updated directory path.

That’s when the troubles started. The new build, built, but the files it built, just didn’t work. After some digging, the team discovered that some of the files that were being copied, and minified, were not actually being copied and minified on the build system. Everything was included when building locally on the OSX, but when the build was compiled on the remote CI system, something was going wrong.

The cause was our old friend case insensitivity on the OSX.

You see OSX, unlike other flavours of unix will tolerate incorrect casing on directory names, this means if you reference a file with the wrong case it will work on mac whereas it wouldn’t work on another linux system.

Take the following example :

/tmp/jQuery/jquery.min.js

can be referenced on OSX as :

/tmp/jQuery/jquery.min.js OR /tmp/jquery/jquery.min.js

In of itself, this is not actually a problem, until you discover that as part of the default behaviour, Grunt, FAILS SILENTLY when it cannot find a reference to a file. It appears to be a contentious issue in Grunt land as some want it to remain so in order that they can glob for files and if none are returned carry on as normal.

However from my point of view with complete file paths, it seems stupid to return success when the file is missing.

After much Googling and reading Git issues and stackoverflow, the work around seemed ugly but straightforward. If you don’t want Grunt to fail silently on missing files you can include this code in your Gruntfile.


var gruntWarn = grunt.log.warn;

grunt.log.warn = function(err) {
if(err.indexOf("Source file") !== -1 && err.indexOf("not found") !== -1) {
grunt.warn(err);
} else {
gruntWarn(err);
}

};

Basicallly you are intercepting the standard warning function, listening for missing file errors and failing the build if you find them, or passing the warning through to the old warning function if it’s not what your looking for. Not pretty. Probably should be in the Grunt core. But that’s software sometimes.

sleep monitor only by code mac osx

Visualising your progress by having monitors running, displaying automated testing runs, is a valuable tool in software development.

However, one concern that arises when adopting this approach is the use of energy. Powered off monitors are cheaper to run than powered on monitors, there’s no argument there.

Showing this progress during the day though is valuable so we do it, but there is something we can do something to minimise our environmental impact, turning off those monitors automatically at the end of the day and switching them on automatically. Not only does this help save energy but it also is a prompt for developers to go home, a central part of sustainable pace of development.

So we have a mac that turns on at 8am and off at 8pm which has a selenium slave that runs our tests in firefox on it.

Problem is using the normal, mac sleep schedule crashes the running selenium slave. So every time we come in in the morning we have to restart the slave. Not great.

Being programmers we decided to fix this with code. The best approach seemed to be, to only switch the monitor off not sleep the whole system. Next problem is macosx doesn’t by default let you do this. So we had to solve it by creating a launchd deamon to run an ssh script on the mac at 8pm.

The bash script (screenSleep.sh) we stored in a local directory and looks like this:


#!/bin/bash
WAKEUP=$(date -v+12H "+%m/%d%/%Y %H:%M:%S")
echo $WAKEUP > /tmp/screenSleepWakeupTime.txt
pmset schedule wake "$WAKEUP" > /tmp/screenSleepOutput.txt
sleep 5
pmset displaysleepnow

Basically, it takes the current date, and adds twelve hours (8pm->8am). Then it runs the pmset command to schedule a wakeup. Then it waits 5 seconds to give the system a chance to catch up. Then it sets the display to sleep.

The launchD daemon looks like this and was stored in /Library/LaunchDaemons/de.razorfish.displaySleep.plist :


<?xml version="1.0" encoding="UTF-8" omit-xml-declaration="yes" indent="yes"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>de.razorfish.displaySleep</string>
<key>OnDemand</key>
<true/>
<key>RunAtLoad</key>
<false/>
<key>Program</key>
<string>/Users/{your user}/screenSleep/screenSleep.sh</string>
<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>20</integer>
<key>Minute</key>
<integer>00</integer>
</dict>
</dict>
</plist>

Important things to note:

<string>de.razorfish.displaySleep</string> has to be the same as the file name.

The script has to be saved by root as it will be run as root, only root can run these commands.

To load the launchD daemon you need to run:

"sudo launchctl load /Library/LaunchDaemons/de.razorfish.displaySleep.plist"

If you want to see if it loaded run :

"sudo launchctl list"

If you totally fuck it up don’t worry, run “sudo launchctl unload /Library/LaunchDaemons/de.razorfish.displaySleep.plist” and start again.

How to reboot your organisation culture

I was recently reminded of some consulting work I did last year, for a large well established company that was looking to reboot its technical unit to meet the challenges of competing with the modern day giants like Google or Apple.

Recommendations ranged from small tweaks to large overhauls, but there was one recommendation I felt was most important to the company. It was about developing a vision for the unit, something they could all stand behind but also interpret in their own way.

This straightforward principle turned out to be pretty sticky as it was viewed by the client as ‘fluffy stuff’ which had no practical realisation.

Fortunately timing was on my side, the German world cup victory was fresh in everyone’s mind and a story was circulating in the English media which caught my attention in the form of an article on a British airways in-flight magazine, called ‘How Germany reinvented football’.

Expecting the typical ‘hero’ above all odds narrative that the press tends focus on to attract readers, I was presently surprised by an anecdotal and factually led piece. It focussed on the well researched, planned and executed structural changes Jurgen Klinsmann had introduced into the German national side to focus on training, commerce, organisation and vision.

Fascinated, when I got home I did some more research and read further around the subject. In one bbc article I found the masterstroke behind what he had done that had made his restructuring so successful.

…but we still had to decide on our playing style.
To do that, we quizzed everyone we could.
We held workshops with German coaches and players, asking them to write down on flip charts three things: how they wanted to play, how they wanted to be seen to be playing by the rest of the world and how the German public wanted to see us playing.
If we could define all of that, we thought we could lay out how we wanted to work and then, from there, sort out the training and paperwork behind the scenes.
What we ended up with amounted to 10 or 12 bullet points laying out our proposals. We then announced that it was our intention to play a fast-paced game, an attacking game and a proactive game.
That last term was something the Germans did not really like because they did not really understand what proactive meant. We just told them it meant we did not react to what our opponents did, we played the way that was right for us.

As soon as I read that I realised Jurgen had been to ‘Agile’ school and knew exactly how to reboot an organisation, build consensus and align vision, whether it’s a football team or a hospital or a software development organisation.

Armed with my new found anecdote and practical application I returned to my client to show him how he too could be the Klinsmann of his technical organisation. This of course ended in him telling me that he was running a company not a football team and the two were completely different.

Luckily for me, a lesson learned and a great anecdote is worth more than hollow victory.

Displaying automated test runs

It’s important to display your progress, this is a key tenant of lean and agile and is the underlying principle behind things like scrum or kanban boards.

As software developers we tend to hide all the clever things we do with code to only our screens, which often hides or mask problems but also robs the world or the rest of our company of seeing the great things that we can achieve with computers.

One anti-pattern i’ve encountered is to have an automated build running which runs selenium tests in the browser on a screen that is not visible to the team or on a monitor that is turned off.

The visual information of watching tests running in the background is useful, if a test hangs maybe you spot it while walking past to get a cup of coffee, if a test passes but the screen looks broken, maybe it catches your eye while on your way to the toilet.

The passive information is highly valuable, and provides a sense of progress, visibility and ownership to the tech team. Plus they don’t just sit around looking like they are surfing hacker news all day.

Can we have a basic wage in our companies?

In his later tenure as Apple leader Steve Jobs famously only took a salary of one dollar. The message? He was there for a love of the company not financial gain, and every employee should be there for the same reason. The fact that he owned billions in stock in Apple and various other enterprises giving him a comfortable cushion should his fortunes ever change and one of his risks backfire was rarely mentioned, but Continue reading

open letter to the British government on privatisation of the NHS.

Mrs. Thatcher was wrong, the markets are not the answer to everything.

Something’s work well with markets, somethings get caught in a race to the bottom, the NHS is one of them.

The core issue is the incentives are wrong, when you have a privatised NHS the incentives are and always will be money.

Not people.

A key decision has to be made, what is the core incentive of the NHS? Money or keeping people healthy? One of these focuses on the short term one on the long.

When money is the core incentive then people will stay sick. A company that makes money when people are sick, will keep making people sick, so they can continue to make money! If they cure everyone then they will have no way to make money anymore so it’s obviously not in their best interest, there’s no escaping the core incentive of a company. No matter what regulations you throw at it.

However an organisation where people are the main incentive, where the organisation is incentivised by people. Measured over the course of their life how little amount of time they are sick, then people will start getting better as the incentive will move from treatment to prevention.

A privatised NHS will fail, because at it’s core it’s got the wrong incentive.

Thoughts on the British political system.

If we managed the English football team, like we manage government, every time we lost a game, the entire team and the manager would be swapped wholesale with the reserve side for the next game. In what universe does that make any sense!?!

We really need to find a better way to manage government.

Hero’s : the negative side

We all love a good story, and nothing is quite as compelling as a hero story.

superman

You know the fella, he’s got a bright red cape, blue spandex body suit and red pants. On the outside – ok, I don’t really understand that bit either. Whatever.

Anyway you can picture the scene : there’s a skyscraper, in a terrorised country, run by a dictator and a surprise earthquake triggered by a super villain leaves it perilously close to collapse, on the brink of destruction.

Cutscene. A woman and child scream in panic on the roof top! Oh my god! The emotional factor! What will happen to our poor victims?

Just in the last moment our hero swoops in, saves the day with his superhero strength, props up the skyscraper and then flies off to deal with other such similar potential tragedies.

And they all live, happily ever after. The woman and child safe, free to go back to their cancerous jobs burning e-waste for precious minerals, and the superhero gets that warm fuzzy narcissistic glow from being a hero.

The end.

Except it’s not. It would be lovely if that was the end of the story, but of course the real story here is the construction story.

How did a skyscraper without sufficient earthquake protection get built in the first place?

In this story, there’s a structural engineering firm, a project management firm, some shady financial shell companies (that make it impossible to really tell where the money for this project came from in the first place) and they’re all suing the shit out of each other to avoid getting the blame.

But we focussed on the hero story, because it’s easier and more palatable and we don’t really have to think very hard about it. Obviously it doesn’t matter that this focus predestines us to repeat the same mistakes, over and over and over again, until we learn that the hero, is a symptom of the problem, not a solution to it.

Don’t fall for the easy story, if someone says to you the the word: hero, rockstar, superstar or guru, then chances are your organisation has some deep deep organisational problems and you’re building skyscrapers without earthquake protection.

Simple principles built on solid foundations.