Smart things

I’ve had my suspicions about home automation and IoT (“Internet of Things”), where your lights become internet connected (requiring firmware updates), your house becomes even more connected with the inevitable security risks that this brings. Where your family and home have to become accustomed to whatever system you have in place, possibly modifying their routines to fit the technology. My DIY skills are limited, my time even more so. I have what is becoming a niche smartphone and no appetite for fiddling to get things to work. It had to be cheap and – most importantly – it had to have SAS. SAS (“Spouse Acceptance Factor“) was fundamental. Automation invites suspicion from your family, who will be subject to its sensors which suggests a creepiness I didn’t want to have to defend.

SmartThings logoSamsung’s SmartThings has emerged as the best system for my family. It is relatively cheap, is an open system permitting integrations outside the SmartThings immediate ecosystem and has integrated itself into our home seamlessly. SmartThings isn’t restricted to the USA, as other tech. companies tend to. Whilst UK availability is limited, it is there via Currys/PC World and direct from Samsung. As a user, you add Smart Apps to your SmartThings ecosystem which join your “things” together to add useful functionality. Typical examples are turning lights off when there is no motion, raising an alarm when there is unexpected movements, etc.

I’ve set up a few neat automations, such as detecting when the freezer has been left open for a suspiciously long period (hopefully avoiding replacing another freezer-full of food) and turning outside lights on. As with anything IoT, one has to be careful about security so I’m not going to identify my specific configuration so patterns can’t be identified which may actually add risk.

Whilst SmartThings has a distinct ecosystem of branded sensors which include presence sensors, motion sensors, door opening/closing, moisture and power consumption/switching, a purchase win for me was the open nature of its interactions with similar IoT products such as Philips Hue (an otherwise expensive and rather pointless lighting toy) and ZigBee or Z-Wave IoT components such as light switches, thermostats, panic buttons, … the list goes on. This is not just an investment in what is an interesting idea from a single company, it can be extended should Samsung’s support of the system waiver. IoT is too new to go “all-in” on a company on the off-chance, I need reassurance that the product will remain supported and if there is interaction/integration with other components, even better.

Cost-wise, SmartThings is bearable. £200 for a starter system and an average of £30 per extra sensor is fairly reasonable, I’ve bought a few extra bits to extend the reach of my automations. It requires no rewiring, no fixings, no expertise. The consumer is able to pick a pack off the shelf and get started. But will it save money in the long run? It is possible to set up orchestrations that turn lights off when no-one is around (a bug-bear of mine), alert when power consumption is too high or when the freezer door is left open. Integrating with lighting requires expensive bulbs at least, or integration with the expensive Philips Hue system. As with purchasing LED lights throughout the house, are you really going to make the money back through savings? When do you stop buying sensors? The starter pack is almost the gateway drug, offering you the basic tools needed to introduce new ideas of automations – and cost.

Despite being one of the promoted benefits of SmartThings and the possibilities of IoT, I don’t think it’s reliable as a security system – certainly where security is a fundamental aspect of the purchase. I love that you can set it to silently and intelligently arm to differing levels of security based on whether you’re likely to have gone out, or retired for the evening. Even better that it automatically disarms itself if “things start to happen” in the morning, or you return home. We have never had to manually set this and mostly haven’t bumped against this intelligent arming/disarming. Unfortunately, the automatic disarming when you return is based on whether it detects your presence sensor or mobile phones before you “break” the security sensors. If you’re too quick and open the door before your phone logs in or it detects your key-fob, it sets off an intrusion condition.

As a Windows Phone user, and a happy one, (well, until Windows 10 Mobile) any smart-home system needed to support my ecosystem. All too often, devices and developers based themselves around so-called apps on either iOS or Android. The presence of SmartThings on Windows Phone was the clincher. Yes, it was expected that the app wouldn’t be as well rounded as its iOS or Android equivalent and it has mixed reviews, but it is fully functional. I do worry about a system that is fundamentally oriented around mobile phone apps and not offering an alternative interface from the hub itself, but the app has mostly performed brilliantly. Where the gap between big-screen accessibility and lack of app accessibility opens up, a labs tool called SmartTiles adequately fills this gap.

I say “mostly performed” because there was a short period where the app on Windows Phone stopped displaying my “things”. The system itself continued to work, executing my routines and reacting to conditions, but I couldn’t have a look at my “things”, I just got a blank screen. So not terminal, but annoying. I did contact the UK support team and I was very impressed with their response. It was both prompt, helpful and supportive. I was dreading the “we’re working on it” stock response, but received a personal response that was reassuring that despite the smaller app-market, I (along with the others affected) as a Windows Phone user was important. The app was fixed – and actually improved – soon after.

Another attraction to the SmartThings platform was its accessibility for developers to play around with their “things”. As a developer, you use a web-based IDE, editing a small script written in Groovy, atop the JVM. Very little knowledge is required, other than the usual coding techniques such as events, asynchronous patterns and reminding yourself that you might not be in the state you expect to be in. The “things” expose an abstracted API that is a breeze to work against. The SmartThings hub and cloud effectively marshal the messaging and hosting of your app, transparently executing code in the cloud or the hub as it sees fit. I have my first app in private testing already.

IoT and home automation, in my eyes, remains a gimmick. It is still immature, with limited integration across vendors’ products. We’ve still to learn how an increasingly connected home remains secure, both digitally and physically. It’s expensive in financial terms and is fundamentally dependent on Spouse-Acceptance-Factor. If your spouse doesn’t agree to having a key fob or the “app” on her phone (which has to be “Smart” and not a BlackBerry), then the system breaks down quickly. Within these negatives, SmartThings has pitched itself well. It is relatively cheap, has low-impact on the family and widely supported across smartphones and the ecosystem of IoT devices. I’ve had automations running for over a month and they were extremely easy to install, configure and have required no interaction. Disappointingly so, if you like playing and tweaking!  Like Windows Phone did, “it just works”. This is a system I would recommend a non-IT pro user to install.




Search the Bible and Taggloo Library

Taggloo has previously been updated to include results from selected books held in the Taggloo Library in translation results. Whilst this was useful, Taggloo now goes a step further in search.

Book search

You can now search a Book within the Taggloo Library using the search-form at the top-right of each page. This allows you to discover words and phrases without going via the route of Translation.

A subtle improvement that has already been made available is the highlighting of search results in the text, so when searching for “thie”:

Highlighted search result

Underneath, Taggloo fully supports any number of books and articles which will hopefully be made available soon. If you have any content that you wish to be published, get in touch.

Alas, the translation and searching is slower than I’d hope. This is being worked upon to strike a balance between performance and affordability. Hopefully there’ll be some modest improvements soon!

Translate and search the Taggloo Library (and The Manx Gaelic Bible)

There is a wealth of Manx Gaelic literature available for access both on paper and on the web. Taggloo launched a Library service last year, with what is possibly the best starting point for any library, The Bible. The Bible is a time capsule, showing us how the language was used when it was the primary language of the island – even before people started to use their own language in a written form themselves.

Using the Library function, it’s a short jump to providing the ability to search and translate the Taggloo corpus. You can enter a word or phrase for translation as you usually would and receive the results. If you’re interested in a deeper translation and understanding of the word or phrase in literature such as The Bible, you can Extend your search by selecting the book(s) you want to search and clicking the Search button.

Taggloo Library Translation and search

The translation and search has been deliberately broken into two steps, which was a carefully considered pattern to balance convenience with performance. Searching an entire book (or set of books) can be taxing on the indexes so results from books are held back unless you need them.

Once you’ve performed your search, you can expand the results as you would translations by word or retrieve the entire set of results.

Ayns y toshiaght

Below each result will be the translation (if available) and the book, allowing you to click to jump to that point in the text.

The Library function can support many texts with differing levels of translation. The next step in the Taggloo story is to provide the tools to allow additional texts to be added into the Taggloo Library, providing even greater insight into the words and translations of Manx Gaelic.

Pass the fork

Teams often work on shared code, shared resources and in shared time. We have ways of managing this, such as source control, one of the first requirements for software development maturity (falling within Levels 2 to 3 of the CMM for Software). However, not everything is easily integrated into such a process.

Developing on the example of source control, source control presents challenges that the mature team will be able to identify and overcome through the use of best practices or their own devised and agreed processes. Shared assets such as legacy systems, premium-licensed resources or even databases often exist outside of source control leaving the team requiring confidence that one developer’s work on that shared asset won’t affect others.

Meet the fork.

The DB Token of Power ("The Fork")

With the fork, a team member can wield power of access to a contended or non-source controlled asset such as database schema changes, SharePoint server configuration, leverage of a single-user licence service or other lock-required activity. The fork acts as a physical action and visual cue in the physical world, representing the reality within the virtual or abstracted world of source code, databases and servers. As a team member reaches for the fork, their wishes are explicit (“I have the fork”) and may be “blocked” by any other team member (“Oi, hang on, I need to do something first”). Without the fork, no changes may be made – or would be expected to have been made by the rest of the team.

Use of a token in this manner is predicated on the collaborative capabilities of the team, perhaps requiring that the team are co-located, small and cohesive. Such team environments aren’t always possible or available. Teams that are not co-located, are perhaps too large (spanning more than one pod of desks) or lack a cohesiveness that is conducive to casual conversation would inhibit the use of such a token; though in this case, one must answer much larger questions about why are these people working on contended assets?

There are alternatives. Use of a shared chat channel for the team such as Slack with an agreed protocol (even descending to the “claim” protocol introduced in The Walking Dead TV Show) would overcome the overly-large, distributed and communication-inhibited team; though this would require a level of buy-in or enforcement by a commonly accepted leader.

We’ve used the fork to great effect. Merging of sensitive assets such as Entity Framework .edmx files (this project has not yet made it to Code-first) can result in a whole world of pain if two developers tackle two work items that are either contradictory or contended. It’s simple and promotes added cohesiveness within the team. Our token was chosen based on what was sitting in one of our drawers and this remains a shared experience within the team and contributes to our mutual social credit.

Of course, you don’t need to use a fork, any token will do, so long as the understanding across the team is consistent and mutual. Such tokens have been in use for years. Ever since the 19th century, and remaining in use even amidst today’s modern computer-controlled signalling, railways have used the token to guarantee safe access to controlled sections of track to prevent collisions.




Source control your relationship

pipe-cleaner-people-1177056-640x480An interesting parallel was drawn by a colleague recently between relationships with your significant other and source control. Both need total engagement by all parties and both can quickly unravel when a lack of commitment or adherence to the agreed guidance and conventions isn’t all it could be.

There is the sitcom-esque “commitment issues” whereby either party is afraid to really commit to a relationship either monogamously or sealing the deal through marriage. Programmers who exhibit a tendency to hold on to their code, avoiding regular commits, store up problems both for themselves and their team.

Maybe your other half feels that she has been put on the shelf, forgotten about and fleetingly appearing in your life as you pass by over dinner or scanning the repo. And you better make sure you get your [file]names right first time if you want to avoid a rapid appearance of irreconcilable problems.

Source control remembers everything you did, all your commits, experiments (branches) and log comments (not as private as one might like). “She” is equally able to remember all your mistakes with unnerving accuracy. Your branches (experimental flings) are on your permanent record, as are your seemingly innocuous comments logged (“I’m fine”). When differences approach the irreconcilable, you start reaching for the Patches.

Any experiments you may have on your branches/flings, are always a time of nervousness to merge back into the trunk/relationship and can rarely be fully re-integrated. Conflicts and lost assets are inevitable. “She” prefers exclusive checkouts, you might prefer a more … distributed approach.

Perhaps where the metaphor starts to fail is the real-world relationship’s difficulty of reverting commits. A programmer can quickly back out of some embarrassing moments in code with a right-click, returning silently to the state of their source and team relationship as if nothing happened. On the other hand, “she” remembers all your mistakes and your attempts to repair them.

By the way, to save embarrassment, this tongue-in-cheek parallel is drawn with no reference to any relationships past or present, real or imaginary. So, no need to perform any Diffs here.


Introducing Agile to the corporate dark matter development team

Photograph of team with joining handsThe challenges of the Agile team within the traditionally-managed and hierarchically structured organization are discussed extensively in research. Artefacts of the burgeoning, hierarchical organisation such as company policy (“we don’t do it that way here”), imposition of arbitrary and incompatible standards, command-control management and poor project manager integration all contribute to inhibiting Agile operationalisation (1, 2, 3).

Alongside this research, I have come across some of these challenges, along with a few others surrounding the personal nature of the team. As a new member of a team, and having been indoctrinated by a fine Scrum trainer, it would be easy for me to lose friends and disenfranchise people had I preached to my new team about how they were doing it wrong and how Scrum would fix all.

But this is not about rehashing problems. Instead, I’ve compiled some lessons which may help others.

In introducing these, I could conclude right now with … Take it slowly

Understand why the team do what they do

It would be ignorant and offensive to assume that archaic processes continued to be followed due to lack of awareness or skill. There is likely to be a valid reason for filling out release forms, why users don’t get engaged or solutions are dictated before the problem is understood. Taking some time to observe and understand through casual discussion is ideal for encouraging titbits of information to be revealed which could explain the history of internal practices and procedures. Perhaps the reason is long forgotten or no longer relevant. Judgement should be withheld, lest you be judged yourself.

Prepare your tools

Creating a new process is made much easier if there are tools surrounding the process that allow the team to fall into the pit of success. I’ve used JIRA in these situations, which has been a first step in formalising tasks from which a backlog may be created. As requirements come in, the task of distilling tasks into User Stories (using the spirit of the terminology if not the definition) and then sharing them out to the team without the dogma of story points, retrospectives or stand-ups has allowed a degree of task ownership and collaboration to emerge over the medium of the tool. JIRA has an API, so if the wider organisation insist on their legacy tool to be used, it can be integrated within a wider process.

Embrace, Extend …

Stopping short of the entire terminology reputedly used internally by Microsoft, I’ve found that it is the team that determines the success of Agile, not the method. Therefore, I’ve embraced the Agile dogma such as Scrum, and extended it – or rather – evolved it, according to the personal nature of the team. During forming, storming and norming, personalities within the team are explored within a professional context, allowing me to learn a lot about the individuals and their motivations. Attempting to mandate process according to Scrum-doctrine will only serve to extinguish Agile all the more quickly and perhaps professional relationships within the team.

Know the assumptions of your method

Methods such as Scrum make sweeping generalisations across industries and fail to state their assumptions. Outside of the software development company, multi-project developers who have to balance ongoing support requirements are widespread. Scrum, and the admittedly useful and revealing metrics that fall out of it, assume that 100% of the time of developers is spent on the code. It’s all about the Story Points, NUTs or even breeds of dog (“that will be 2 Labradors and a German Shephard”) but this does not take into account time spent outside of the project. At any given moment, the **** could hit the fan robbing the project of velocity which would be unaccounted for in the retrospective reports. Equally, how well does Scrum work within a portfolio? Models like SAFe claim to allow multiple projects managed using Scrum-like techniques, but this is not necessarily the same contended resources.


The key to the success that I’ve seen with this is to introduce Agile principles gently. No great switch was needed from which all projects would be Agile. Each project slowly became more Agile than the last and the surrounding individuals (managers, Business Analysts, etc.) are understood first and introduced second. The Business Analyst is perhaps your greatest chance of success of implementing Agile concepts within the hierarchical organisation so they need to be brought on-board at their own pace. I’ve learned to listen and understand first, based on which, one can start to make the case using what can be highly adaptive models that are made to fit the team, not vice-versa.