Photo of Jamie & Lion

The personal site of Jamie Knight, a slightly autistic web developer, speaker and mountain biker who is never seen far from his plush sidekick Lion. View the Archive

A physical controller for Hue smart lights

TL:DR I’m using an Xbox controller to control my smart light. Code is on GitHub.


I received a set of Phillips Hue smart lights for my birthday. I really like them. I have been working on a proper review; but this post is about my first hue hack. Physical controls.


App controlled lighting is awesome. When I want it, I have complete control of my lighting. But I don’t always want complete control. Often I want something simple and more importantly something fast.

For those situations I wanted a physical controller. Something where I can turn on a preset or an individual lamp easily.

I wanted something physical for ease of use. I want to use this thing to check for monsters at midnight when unlocking my phone is too fiddly and slow.

Hue has a product for this (the Hue Tap) but its pricey and I wanted too build something more expressive.

Why the Xbox controller

I picked the Xbox controller for 3 reasons:

  1. I have one
  2. I knew of a node library to control it (thanks Andrew)
  3. it has enough buttons to do fun stuff.

How does it work

When I press a button on the controller, it trigger an event in a node.js app.

The node apps then sends the preprogrammed command to the hue bridge which in turn controls the lights. Source code can be found at:

The Controls.

The control scheme is has 4 areas. Presets, Individual controls and group light switch.

The dpad maps to presets:

The coloured buttons and shoulder pads are used to control individual lights.

And finally, group light switch.

Usage Patterns

I’m using the presents most, but the Individual light control comes in handy when I want to just light my bed or desk etc.

Where Next

I have a few ideas too extend and enhance the system.

  1. Wireless controller – I need to buy the little wireless dongle so I can go cable free.
  2. More than lights – I also want to control TV volume and fan from the same controller. This can be done via an OS X system event API and a wireless mains switch.
  3. Multiple rooms

final words

If you have any question feel free to email me, or leave a comment. If you spot a bug please open an issue in GitHub.

Published: 25 August 2014 | Categories: , Permalink

The Future of the Mac Mini

I like the Mac Mini, its small, fast and quiet. Just what I want for under the telly.

It could be smaller though. It could also be faster, but I don’t think its likely to get both smaller and faster.


The Mac Mini uses laptop chips; the same chips as the retina MacBook Pro for the one I have. However, those chips are not the most power sipping, running 44w or so.

If Apple updates the Mac mini today to the equivalent haswell chip it would get ~16% faster and the graphics power would double perhaps triple.

This would be nice. If it stayed upgradable1 that would be perfect. I already game on my Mac mini, and better graphics would be nice.


What if Apple swapped to using the processors from the MacBook Air? At 15w these chips run much cooler and sip power. The Mac Mini could get far smaller.

I don’t think it could get quite as small as the current Apple TV. But Pehaps it could get much thinner or change shape into a small round puck.

This would be a totally integrated device. Like the inside of the MacBook Air, everything soldered down except maybe the storage.

If it cost £339-399 with the same guts as the 11” MacBook Air, that would be compelling.

Final words

I have been drafting this post for a while. Since i started Apple accidentally released a reference to a Mid 2014 Mac Mini on the tech support website. So hopefully something is coming soon.

I like the Mac Mini and I hope it has a long and exciting future, hopefully the next step of its evolution will be with us soon.

1 My 2012 2.6ghz Mac Mini has two drives (256gb SSD, 1tb HDD) and 16gb of RAM. Both were easy to install, and could be further expanded in the future.

Published: 30 July 2014 | Categories: , Permalink

Getting started building a software project

I started writing this to help out an organisation I was informally advising. Just a bit of input really. I figure, by posting it publicly its open for comments and updates. It also means I can find it when I want to refer to it in the future.

So, lets assume, your an organisation and your writing a funding bid. What options are there for getting software built?

For the purpose of this article, lets assume there is no off the shelf software you can use. So you need to building something from scratch?

What are the options?

Two decisions, many combinations.

In my opinion, when building software there are two decisions you have to make early:

1: Where are the team coming from? What structure will they operate within?
2: What methodology will the operate under?

Those two decisions are intensely interrelated. But before we dive in, a disclaimer:

This article is incomplete and probably biased. It’s just the options I am aware of, its intended as a handy starting off point, not a full guide.

Business Structure.

In my mind there are three option for gaining the efforts of a group of developers:

1: hire
2: outsource
3: partners

1: Hire.

If you need developers in an ongoing fashion, and you require complete control. Hire some. Either as staff (e.g., PAYE etc) or by doing fixed length contracts (contractors). You could even split the work up, and farm it out to individual freelancers in units as small as an hour or two.

Normally, alongside a developers you will need to also hire a designer, and sometime a project manager of some description.

2: Outsource

Outsourcing means having another business handle a business operation on behalf of your organisation. For example, many places outsource HR, or security.

One method for having custom software written is to go to a software development company, be the client and simply pay them.

You do give up control, but you are also buying yourself a degree of insurance again you own bad decisions. The outsourcing company, will probably have hired people (see option 1) which they are reselling as functional teams.

The normal method would be to go to an agency. Different agencies will take projects in different fashions. Many will ask for a Request For Proposal (RFP).

3: Partnering.

Sometime, you could build a ragtag team with developers who are being “lent” towards you aim. For example, if your organisation is group of charities and businesses perhaps those group members could give up a small amount of developer time.

Often, when partnering occurs, the management process remains within the organisation. (who will often hire a project manager, or a single lead developer).

So those are the three options I am aware of for business structure. Next, what about methodology?


Methodology is about how the software is developed. There are 2 prevailing methodologies in the software development world:

1: Problem Upfront, Solution Upfront (Waterfall).
2: Problem Upfront, Solution on the Fly (Agile)

1: Waterfall.

Waterfall is the transitional software development practice. My experiences of it are more limited (i practiced waterfall development when I ran + Lion, I have never experienced it in a large project).

From my experiences, waterfall means that all the planning is done upfront. Both the definition of the problem and the definition of the solution.

With a waterfall project, a big spec is written (normally by someone non technical) which is bided on by agencies or given to an internal team to “build”. Its not uncommon for designs to be commissioned and completed before the development team have even been hired.

2: Agile.

Agile takes a number of forms and I am not an expert. I have 3 years of agile experience within the BBC, but that is all, so my viewpoint here is limited.

The basic principle of Agile (see disclaimer above ;)) is that you define the problems upfront (often with “User Stories”) and then tackle each small element of the story piece by piece. Building something in layers. Using the output of one story to influence the development of the next story etc etc.

In the agile world, there are different methods (scrum, kanban etc), but they all boil down to similar tenets. Such as, estimation, thin slices, and defining the solution to the problem as closely to the problem entering development as possible.

Scrum teams work in sprints, often of 2 weeks or so. At the end of every sprint the aim is for value to be delivered to the user. So for example, an early sprint’s goal may be “Have a user system with avatars and secure signup”. Within that sprint a series of users stories (e.g. problems) may be developed. For example, the stories in a sprint about a user system may include “As a user I would like to be able to sign up” “as a user I would like to be able to sign up” etc etc.

The planning of the detail of those tickets (the definition of the solution) is done before the sprint starts, but not too far ahead.

I have probably murdered the definition of agile enough for now, but I believe thats the core of it. If you know better, please leave me a comment :D

Putting it all together.

So those two decisions, the WHO and the HOW can be combined to give you development options. I have enumerated a few below:

Who: hire a team How: Agile
Who: oursourcing How: Waterfall
Who: Partnering How: Agile

And so on.

And finally…

With all that said, what are my thoughts? How should you build a software project.? I’m afraid the answer is I don’t know. So instead of trying to make something up, here are my experiences with the combinations I have experience off:

Who: outsourcing How: Waterfall

This is how + Lion operated. I worked with a client to develop a spec and help them define their solution, or they came to me with a project to be built. I managed the build, building some parts myself, and subcontracting other parts as required.

Who: inhouse How: Agile (Scrum)

When I was working in the BBC Radio & Music team, we built the first version of iPlayer radio. I worked on an agile team named eno, as a front-end developer.

This was my first introduction to agile and it was impressive. The team operated with a very good technical project manager (an ex dev) who helped to organise sprints and provide updates to the wider business. The TPM also arranged releases and did work keeping the ticket management board up to date.

Who: Partners How: Agile (Kanban)

When I was working in platform engineering, business as usual support was provided by a team called the eagles. The eagles was the combined support of a number of scrum teams, each team contributed one team member per sprint to join the eagles team which operated using the Kanban model.

For BAU work, where tickets come in, are of differing sizes, but generally are smaller tasks, kanban worked well. I fondly remember the thrill of delivering tickets every couple of days. It’s enjoyable to see some work release a mere hour or so after its completion (in a scrum teams, releases were normally made once per sprint).

However, for project work (getting a new software build of the ground) kanban was more complicated. My experiences of kanban in this environment are less positive. While in theory planning could itself be a ticket (e.g., a ticket called “plan the user system”) it was way to easy for tickets to end up being co-dependent. This could mean that while there were 40 or more tickets on the backlog at any one time. Only perhaps 3 could be worked on.

My opinion is that it is better to start projects with scrum, but maintain projects with kanban.

Wrapping up.

I hope this article it useful. It’s not exhaustiveI’m and I’m sure its wrong in many places, but hopefully it gives a feel for the options which are out there.

Published: 28 July 2014 | Categories: , Permalink

Older Articles