Friday, 30 December 2016

Meeting Cost Timer - An answer to long meetings, maybe? Probably not.

Have you ever wondered how much a certain meeting costs.  Maybe you've got stand ups that run long every morning, or a fortnightly team meeting that is just a waste of everyone's time? I have and I've joked with people about writing an app that times in Dollars rather than in minutes.  I finally wrote and published it, you can find it here: (It's running in a free Heroku instance so you'll have to forgive the load time.)

I can't promise you that this will help your meetings be shorter.  I also can't suggest that if you use it you wont come across as pretentious and unlike-able.  But you can have fun joking about it with your friends or even use its existence to start a conversation.  

Good luck. 

Friday, 11 November 2016

Vagrant SSH and Windows

I've set up Vagrant to do development under Ubuntu on Windows machines twice recently. Both times I've had a spend some time remembering how to get the vagrant ssh command to work.  It's a pretty simple thing but since it's caught me out twice I'll document what I did.

* Install Git. You've probably got this installed if you're using your machine for software development.
* Add the ssh executable to the path environmental variable. This is in C:\Program Files\Git\usr\bin\

The vagrant ssh command should now work.

This was written 2016-11-12

Saturday, 8 October 2016

Pet Peeve: Statements not wrapped in braces

Jumping into a new code base I've had time to stew on some of my pet peeves when it comes to coding style. Maybe this is just me being a pedant, but statement that aren't wrapped in braces really grind my gears. I find this particularly prevalent with one line if statements, but it pops up with other cases (while, for, using in C#, etc) from time to time.

The reason that this works at me particularly is that these statements have removed one of the visual cues native to the language and sit outside of the typical visual flow of the code. I rely on the flow and visual cues to quickly parse the flow of a piece of code.

In the worst case the removal of this visual cue increases the likely hood of making a simple mistake because the operation of the program can be accidentally changed, for instance adding a log line directly below the if statement will cause what was previously in the statement to be run consistently.

Rant Over.

P.S.  I'm hardly going to shout you down for using statements without braces. I just don't like them is all.

Monday, 25 April 2016

ToDo is a code smell

As a general rule I don't like comments in code. They smell. There is one type of comment that really gets under my skin. The ToDo comment.

These are the worst. They're explicitly indicative of a problem in the code. There are only two reason that ToDo slips into your repository. Either the developer who wrote the comment:

  • Was not thorough enough to finish the job or,
  • Not brave enough to bring it into the light of day as a Technical Debt backlog item.
Those two rules both provide caveat for using ToDo comments. 
The latter case presumes that there is an issue tracking system. If the team you're working in does not have one of these then you should probably stop reading blogs and get to fixing that. 

In the former case is see ToDo as acceptable for documenting unfinished work while it's on going. In this case the code should be rejected in peer review for any ToDo comments, stopping them being a smell in production code. Even better than peer review is having a linter/style checker break the build because if there are any ToDo comments in the code, stopping as soon as they get into the repository.

If your process is mature there is no excuse for having ToDo comments in your code.

Saturday, 19 March 2016

Solving jQuery not found issue with webpack-bootstrap & babel

Recently I was trying out es6 classes with React using Webpack and Babel to build and transpile the code. I got all that working, by switching out the react-loader for babel-loader. I had problems when I added bootstrap into the mix, console was reporting that there was problems locating jQuery (Uncaught ReferenceError: jQuery is not defined). This is because the previous Webpack config I had been using had been using the Webpacks plugin architecture to load jQuery. This is not compatible with the Babel loader that I needed to transpile the es6 classes. I was able to get around this by loading jQuery as a global and referencing it from a cdn.

Saturday, 5 March 2016

Intro to React - Slides and Demo code

I recently gave a presentation giving a high level overview of React JS.

The presentation was quite high level.
Introducing the JSX syntax and the component model.

I am enjoying working with React and look forward to diving deeper into development with it and speaking more about it.

Below you can find the slides and the demo code I used during the presentation.


The presentation is hosted out of google docs. You can see the slides here

Demo Code

I've put the code I showed in a repository on Git Hub. 

Sunday, 24 January 2016

Setting up React tests with Mocha and Webpack

Writing unit for React classes written with ES6 is a bit less simple than for plain old ES5 JavaScript. The extra compilation steps mean that the production source files and the test code both need to be compiled before running.

To perform this role I'm using Webpack.  Webpack provides bundling and compilation bringing my source code (test or production) down into one big ES5 file.

To get Mocha tests running with Webpack.

Getting a basic test running

To get a basic test running, nothing  more than vanilla ES5 Java Script.
  • Include the Mocha loader (npm install mocha-loader)
  • Navigate to your test directory. 
  • Run "webpack mocha!./testroot.js testBundle.js"
  • Create an empty html file that includes testBundle.js after the body. 
  • Open the html file.

Using a config file

Obviously we want to use more than just Vanilla.js we want to include React and ES6 components. 

To do this I'm using a second config file, in addition to the one used to compile the client in to bundle.js,  This is in the root directory of the project next to the webpack.config.js file.

You can run webpack using this config file by specifying the config file explicitly.  "webpack --progress --colors --config ./test.webpack.config.js"

Open the html file from before, make sure it points to the same testBundle.js that you're config is spitting out.

Now you can start including and testing your React components.

Friday, 15 January 2016

Build Speed a less talked about Micro Services feature.

I was deploying a small app, you could call it a Micro Service, today to our test/demo environment at work and found a bug where I hadn't implemented a shared API correctly.

  • I realised my mistake.
  • Walked over to my development machine (the test/demo environment is physically and logically separated from the rest of the network).
  • Fixed the bug. 
  • Ran tests.
  • Pushed to CI. 
  • Took the installer generated from the CI build walked back over.
  • Installed the update. 
All in less than 5 minutes.  

I always hear about how Micro Services are quick to deploy, resilient to failure and scale-able, but rarely do I hear about the fact that they're quick to build.  This speed is because the compile time is lower and the test time is lower.  Overall it means that working on a Micro Service, or a small application in general is just more productive from a development point of view. 

Micro Services is the buzz word at the moment so you probably didn't need another reason to consider them as an architecture. But just in case you did, here it is . 

Tuesday, 12 January 2016

React Router Context Issue

I've been playing with React and using React Router to build a demo app.
The last couple of times I've sat down to work on it I've been struggling with what given hindsight seems like a very simple issue. 
The issue I was having was that after a user had logged in they would not be redirected to the page they wanted to view.  They would have been authenticated successfully but the redirect was throwing an exception because the router object in the context was undefined. 

The suggestions on how to fix this is to add this method to your React class.

   router: React.PropTypes.object.isRequired  

This will check that there is a router object available in the context and make it available through


If router is not available within the context object it will raise a warning in the console.

Failed Context Types: Required context `router` was not specified in ...   

This is what I was getting.   Lots of searching brought me to this issue on the Redux project that pointed out that in 1.0 the router context was changed to be location and history objects in the context. 

I went to bed and slept on this issue.  when I woke in the morning I though to check the versions of React Router that I was using vs the version in the example app (from react-router code base) that I was working from.

It turns out the issue was because my code was targeting 1.0.3 which as of 08:00 2016-01-12 Newcastle N.S.W. time is the version that is installed when running

npm install --save react-router 

I changed this to "2.0.0-rc4" in my package.json file re ran npm install and now it's all working.

The moral of this story is that with the wild and fast evolving world of web frameworks, even if you've gotten the latest from npm you don't necessarily have the latest as far as the project is concerned.