Saturday, 14 November 2015

Require is like new; An argument for DI in Node.js

As I continue my journey in Node.js I have been looking into unit testing. I typically practice TDD but while I was getting started with Node and everything was simple I was happy to play with manual testing and restarts.

I picked Mocha as a test framework. One thing I noticed quickly looking at Mocha was that the examples were simple, adding a few numbers together or checking the type of a return value.
 
Having come to Node from C# I had require littered through my code like they were using statements,  When I tried to implement some tests against the basic logic I had put together I quickly ran into a problem, that was not covered by the simple Mocha examples.  The problem arose because require is not a using statement, it directly provides code from other modules meaning that the code referenced is invoked in the tests.

I went looking for ways to mock out the require statement. As I was looking it occurred to me that mocking require is possibly not the best way to do it. In C# terms require has more in common with a static factory than a using statement.  I feel that require is not something to mock out, rather it's something to isolate.

By bringing the require statements for external modules out of the main code body the code can be broken up into a modular architecture making the system more testable and more resilient to regression issues.

Require is the best reason I have seen on my Node.js journey to include Dependency Injection in a project, even if it is a hand rolled.

Wednesday, 21 October 2015

Manual package install in atom

I was having problems installing atom packages at work (on a Windows 7 machine) and I really wanted to have syntax highlighting in my React project.  Turns out it's really simple to manually install a package. 

Download the package you want. It's probably in GitHub.  I wanted the Atom React Package.

Extract the zip file and put it in the packages folder.  You can find this folder from the install packages screen:
 

Open a command window in the folder you just put in the packages directory. 

Run apm link 

Restart Atom and you're done.

Saturday, 22 August 2015

Symbol Hound - The search for devs.

During the course of the last week myself and a college came across an exception in our logs. The exception was from JSON.Net complaining of an unexpected character in the JSON string.  The character in question was the ^@ symbol.  A Google search for this symbol shows up very unhelpful results, you could try Carrot @ or Carrot At.

We went looking for ways to search for symbols in Google, in our searches we came across http://symbolhound.com a search engine for developers. It doesn't ignore symbols so a search for ^@ yields much more useful results and reveals that its a null character. It's a useful tool for debugging and development questions, you can even set it as one of the search options in Firefox.

Saturday, 8 August 2015

IoT Identity

The first IoT topic I want to look at is Identity.  Identity is critically important when selling an IoT product. It doesn't seem such a big problem when playing with half a dozen Raspberry Py's in the back room of your house.  But when customers start sending back error reports and/or hardware knowing exactly what they're talking about becomes very important.

This problem starts with the what is Identity?

Consider the example of a taxi management system.  We've all been in a taxi lets make the meter a smart meter.  It knows all about the taxi, speed, distance tally, fair total, etc and can be tracked at via a web service.  What the problems the system solves is not important for the example, what is important is that the system is installed into the car as an after market component and that it provides data about the taxi to a central service.

And now we come to the question of identity.

The first question to ask is "When do you need to identify a device?" There are three cases I regularly encounter:
  • In reports and dashboards. 
  • To the central service and each other.
  • In Exception Cases
The next question is "What do you use as identity?"

The when cases break easily into two groups based on who is consuming the information.  The first case is the output of the system, we can assume that whoever designed this system wants to be able to see accurate information about the fleet.  So they're going to want to use their names for the vehicles, "Taxi 67", "Billy's taxi", however they refer to them. So the first identity is the clients language, something easy for humans to understand.  I'll call this the real world identity.

The second when case is when identifying the to other software.  In that case some sort of unique identifier that is easy for software to understand. Probably a GUID.  I'll call this the software identity.

The third when is when something has gone wrong.  The easy answer for this case is just keep using one of the previous two identifiers.  The problem with the easy answer is that when an IoT solution is in production minimal down time is important.  To achieve minimal down time it's common to have a collection of "known good" spare units is held in a state ready to be physically swapped for and configured to replace any problematic unit. `

This would mean that now the software identity and real world identity are potentially associated with a different piece of hardware. This makes fault finding difficult if the problem is hardware or firmware related.  So obviously to solve this problem we need to introduce the concept of a hardware identity as well.

So to correctly identify an IoT device we need to know the real world identity, the software idenitity and the hardware identity at any given point in time.

Building an IoT product is hard.  Making an IoT solution work in production is harder.  Before deploying make sure you've gone through all the possible exception cases and have a good plan for maintenance, because no system ever survives first contact with the enemy customer.

Friday, 10 July 2015

IoT series introduction

IoT is all the rage at the moment. It seems that every second pod cast and blog I see these days is talking about IoT in some way or another.  I guess this one is no different.

Like most things in our industry when something new comes along it's not really new, so much as something that's been around for years re-imagined or re-badged in some way. It's no different for IoT.  The company I work for has been doing IoT in one form or another for the last 15 or 20 years, we just didn't call it IoT.

What the recent popularity of IoT has done is bring alot of new blood into the area, which means alot of blogs and tutorials going through the basics of putting together a board with some lights and sensors. What these blogs don't talk about is some of the problems that begin to be encountered in a live IoT system.

I intend to address that by writing about some of the experiences that I have had while working in a company with a strong greenfield and brownfield IoT product offering.

Saturday, 11 April 2015

Smart Watch Thoughts.

I've been wearing a smart watch for a bit less than six months now.  With the release of the Apple Watch recently and the rampant success of the Pebble Time Kickstarter I thought I'd relay my experience and how I feel about smart watches these days. 

When I bought my watch, Samsung Galaxy 2 Neo, it was more of an impulse buy/retail therapy purchase than a commitment to an emerging technology.  I was of the opinion that the Smart Watches were are dead end in the tree of technological evolution. 

That said over the last six months I have become very fond of the watch. There are features that I always expected to use, some that I am surprised to use and some that I am surprised not to use.

The key advantage to the watch that I believe will cut across brands and models is the notifications.  The ability to read a text message without having to pull the phone out of your pocket is great, being able to triage the other notifications as they come in so as to minimise interruptions to what's going on in the world outside the phone is even better. But the really great thing about them, something that I don't think is mentioned enough, is that they're silent.  The watch vibrates, but since it's touching your skin it doesn't need to be at the intensity of the phone so you don't get that buzzing sound that is very noticeably not silent, and since you're notified via your watch it means that the phone can be on genuine silent mode. This last point is the reason that I now think we'll see the watch stick around, it's taking personal computing and making it more personal.  

Finally a quick run down of what features I liked/didn't like:

Features that were always going to be bad:
  • 2 day battery life. (Still better than 18 hours)

Features that I thought would be good but were not so much 
  • Heart rate monitor - unreliable, battery consuming.
  • TV Remote - just harder to use and more fiddly to get to than the TV remote is to find.

Features that surprised me:
  • Dick Tracy style calling. Sometimes I don't know where my phone is and my watch is telling me that I have a call.  Pretty convenient to be able to say stuff it I'll take it on the watch.

Features that were always going to be good,
  • The pedometer
  • Media controls. 
  • Find my phone.
  • And of course in the end it's quite good at keeping time. 

In the end I am still not convinced that in 10 years time everyone will be wearing a smart watch the way that everyone carries a smart phone, but I'm also not convinced that they're a technological dead end.  I suppose only time will tell. 

Friday, 27 February 2015

Windows 8.1 on Minnow Board Max

Looking around at the tutorials getting a Minnow Board Max set up running Windows 8.1 appears more complex that it really is. 

 The following will run though the few easy steps that we took to get A Minnow Board Max running with Windows 8.1 Embedded Industry Pro Evaluation and cover the pitfalls that took this job that should have been a few hours (mostly waiting for downloads and installs) and turned it into 5 man days over 3 calendar days. 

The TL;DR; version of this is 
  • Use Rufus to create a bootable Windows install USB drive. 
  • Install Windows onto a hard drive not a SD card. 

What you'll need.

  • Get the required hardware
    • MinnowBoard Max.
    • Micro HDMI to HDMI Converter and/or Cable.
    • HDMI Monitor. 
    • 5v Power supply. 
    • USB Keyboard and mouse.
    • Micro SD card. (Or other media to install on, Micro SD car is not fast enough)
    • USB drive (I used a 2nd micro SD card in a converter).
    • 2nd machine running Windows to create the bootable drive.  I used my Windows 7 Pro development machine.
  • Get the required software


  • Create a bootable USB drive.


    • Use Rufus to put Windows 8.1 onto the USB drive and to make it bootable. 
    •  Use GPT and UEFI settings.
    • Make sure that the file system selected is Fat32 at this point
    • Start Rufus, it might take a couple of minutes to run.

    Run the Windows 8.1 installer.

    • Insert the USB drive, Keyboard and mouse and the Micro SD card into the MinnowBoard-Max and connect the Monitor Via the HDMI adapter and/or cable.
    • Power on the Minnow board and you will see a screen outlining available drives. fs0 and fs1 will be available.

    • fs0 is the SD card fs1 is the bootable USB drive
    • Type: 
      • fs0:
      • cd efi
      • cd Boot
      • bootx64.efi
    • Follow through the steps of the Windows Install Wizard.  
    • Use the Wizard to format the micro SD card in the MinnowBoard-Max. 
    • Follow through the remaining steps of the Windows Install Wizard.  
    • And your Done!
    • Power off the MinnowBoard-Max and remove the bootable USB drive. 
    • Now the MinnowBoard-Max will boot to Windows when you power it on.

    Pitfalls. 


    • Not starting out with a 6 pin connector for the serial interface. This connector helps to debug problems with the HDMI connection. Such as ...
    • The biggest pitfall that we encountered was using micro HDMI to VGA converters that didn't play nicely with the MinnowBoard-Max.  When booting we got output over the serial connector.  Linux distros complained that there  "no suitable video mode found, booting in blind mode". In some cases we could get Linux to work over serial but not over the HDMI.  Windows would show some pre start up screens and then go blank.  I'm not sure if this is a problem with all adapters or just the ones that we used. 
    • Micro SD cards are not fast enough to run an OS off.  We moved to an old spindle hard drive and had much more success. 
    • Windows 7 does will not run on the version of UEFI that is on the MinnowBoardd Max.

    Saturday, 24 January 2015

    A Tool To Help You Estimate - Kind of

    I think of Estimation is a necessary evil, but an evil all the same.  I read something once to the effect of, and unfortunately I'm paraphrasing as I can't find the original, "An estimate should inform a decision. If it is not informing a decision you should ask yourself why you're estimating in the first place." I can't remember where I read it, or who to attribute it to, but the premise resonates with me.  I've stuck the original quote up at work and bring it up if I'm asked for a frivolous estimate.  Obviously I don't feel the need to look at it, which implies that I'm not asked for frivolous estimates all that often.

    Given how I feel about estimates (evil) I was greatly amused by this comic from Commit Strip the other day. It reminded me of a small app that I wrote, when I was first starting out developing software, to randomly generate estimates for me.  The original was crude but it gave me a laugh.  I've made a less crude version and published it to my sandbox here.  I hope someone else can get some enjoyment out of it.

    If you're looking for another distraction I greatly recommend Commit Strip.

    Saturday, 17 January 2015

    Communication - The most important software development skill

    I recently listened to an episode of Dot Net Rocks featuring John Sonmez focusing on working on your career.  One key point that John brought up was that the key skill that we as developers can need in today's environment is the ability to communicate effectively.  I've been pushing this same point of view for a while.  As I went though university I was aware the communication was important, but the scale of the importance didn't dawn on me until I worked with someone who was truly lacking in communication skills. For the purpose of this blog I will call him Thomas (not his real name obviously, it's actually part of mine).  

    Thomas' integration with the team was a daily struggle, we could not exchange ideas or build a working relationship.  The team worked hard to include him and provide avenues for him to join in discussions that were work related and non work related.  I can only assume he was also working towards this goal, if he was, it was hard for the rest of us to see. Despite all efforts there was a general failure getting him to integrate and become part of the team.

    This lack of integration withe the team impacted on more than simply the relationship with the team.  Not being able to communicate restricted his ability to learn from the rest of the team, as well as inhibiting his ability to grasp the concepts required to develop applications using Domain Driven Design principles.  Our developers have drunk deeply of the DDD Kool-aide and it is the backbone of our the way we design software. 

    The lack of social and communication skills meant that the only interaction with the rest of the team was in code review. Given the problems with grasping concepts it should be no surprise that code reviews were consistently negative.  This took a big tole not only on Thomas but on the rest of us as a team.  For Thomas he stopped enjoying work, it's hard to enjoy being somewhere where all your interactions with people are them being critical of you, I'm sure we can all relate to this at an anecdotal level and there is actually research to back it up.  The ideal ratio is nearly 6 to 1, positive interactions to negative, bear in mind that these don't all have to be related to your work.

    So Thomas' productivity went from low to lower and the rest of the team's productivity also took a hit. There were assorted meetings, official and unofficial, within the team and with external parties (human resources, and multiple levels of management) as to how to fix the problem.  We asked how we could draw him out, what activities could we do to include him, was there ways to improve his work so that hey would get positive interactions in his code reviews.

    In the end I have no solution for you as to how to fix the communication problem, his story ends in a very predictable manner, eventually Thomas found work somewhere else and moved on to a new company and hopefully a new beginning and the rest of the team learned a lesson about the importance of communication and relationships in the workplace.

    I think about Thomas from time to time and hope that he's doing well, wherever it was that he ended up.  I hope that he did manage to learn something from us, we all learned a lot from him; Communication is one of, if not the, most important skill in succeeding in today's software development workplace.