Homenet Pre-Requisite Setup on Raspberry Pi

Node JS



Install and set to auto-start: http://blog.denwilliams.net/2017/04/22/pm2-raspbian-autostart/




sudo apt-get install mosquitto


Getting Flic Buttons Running on the Raspberry Pi 3 - Take 2

Clone it to the Pi:

sudo apt-get install git
cd /opt
sudo git clone https://github.com/50ButtonsEach/fliclib-linux-hci

Create the data folders:

sudo mkdir /var/lib/flic

Create a systemd start script:

sudo nano /etc/systemd/system/flicd.service


Description=flicd Service

ExecStart=/opt/fliclib-linux-hci/bin/armv6l/flicd -f /var/lib/flic/flic.db -s -h hci0 -w -l /var/log/flic.log



sudo systemctl enable flicd



Autostarting PM2 on Raspbian

This seemed to be the best way to get it to work:

sudo env PATH=$PATH:/usr/local/bin pm2 startup systemd -u pi --hp /home/pi

Then use pm2 start... to add any services to autostart, then pm2 save to remember the currently running instances on reboot.

Typescript Function Types

I keep having to look this up again, so for all my future references…

Inline params:

class MyClass {
  myMethod(callback: (x: string) => void) : void {

function myFunction(callback: (x: string) => void) : void {

As an interface

interface MyCallback {
  (x: string): void;   

class MyClass {
  myMethod(callback: MyCallback) : void {

function myFunction(callback: MyCallback) : void {

With generics

interface Action<T> {
    (arg: T): void;

interface Func<T,TResult> {
    (arg: T): TResult;


Some interesting food-for-thought listening today with Scott Hanselman talking about punishing staff for mistakes, and the culture of accountability and needing someone to blame.

It’s definitely true in many workplaces that the first question often asked when something going wrong in production is along the lines of who caused this rather than how did this happen, or the preferred question - how could we have prevented this.

Some of the more severe examples of punishment included docking pay from employees to discourage others from making the same mistake. While it might be possible to argue that (ignoring the obvious damage such actions would do to morale) it could indeed discourage future mistakes, the company and team are none the wiser of the real reasons why. Sure the person made a mistake, but was there insufficient communication between teams, or was there technical knowledge limitation at play? Were the task requirements relayed effectively? Was it just an honest mistake?

Which brings us to how could we have prevented this. People make mistakes. As long as software development involves people there will be mistakes made. If someone makes an honest mistake and it makes it to production who’s fault is it? It’s everyone’s. And no one’s.

It’s everyone’s as it’s a team effort. Even it was just a classic human error. A typo, or a decimal point in the wrong place it’s a team effort in getting the feature out! is the test coverage sufficient? Are there sufficient processes in place to pick up on these mistakes? Were things rushed or forced? Does the team have enough resources? Are team members over worked and exhausted? The answer will rarely be simple, but taking the time to understand why will always serve you best in the long run.

It’s no one’s as it’s important to remember that we are all people. We all make mistakes, some more than others. We can make improvements and reduce future occurrences, but don’t shoot yourselves over it. Just make sure you take the opportunity to improve yourselves over it.

So the next time a mistake is made in your company, just take a step back and think what your objective is. The mistake has already been made, nothing will change that. The most valuable outcome is in reducing future incidents of any kind.

Check out the podcast here: http://hanselminutes.com/526/punishment-driven-development-with-louise-elliott