05 Feb 2021
Recently one of my team asked me how they were doing, and to be fair I think they’ve been doing
great. The challenge though is that they started as team leader right about the time that
COVID-19 hit. Working for an online supermarket, around March 2020 was definitely challenging,
but in some ways it actually made things easier. When there is a fire to put out, it’s easy to know
what to do next - you put the fire out! And after that? You put the next fire out!
Certainly, there are challenges for being a team leader during a crisis. Perhaps people in your team
are stressed or losing their cool. You might have stakeholders shouting at you to fix things quicker.
Maybe you have to take shortcuts that you know lead to technical debt, but that will get things
fixed quicker.
Calming people down, and protecting your team are important skills for a team leader. Knowing when
to make pragmatic technical decisions is something all developers should know. And recognising when
your stakeholders are crying wolf and you can push back on fixing their fire is important. For us,
back in March, it was pretty clear that this was a real crisis and we needed to do all we can to help.
Read More...
02 Dec 2020
In a previous post I talked about swapping the in-home device (IHD)
supplied by my electricity and gas company for one produced by Glow.
This connects over wifi and gives access to the raw data coming from your smart meters over MQTT.
To collect this data and integrate it into my
house monitor I needed to listen to the MQTT
topic and expose the data to Prometheus.
This was quite similar to my previous project to expose statistics from my router, but as this was processing
JSON data being exposed over MQTT it was a lot simpler than parsing raw text over SSH. As before I created a
GitHub repo with my usual Python linting, testing and build scripts set up.
Connecting to MQTT is straightforward, using the Paho MQTT library. When they’ve
set up your MQTT account Glow’s support team will supply you with a topic name that you can use, along with the username
and password you set, to connect. The code below shows how to do this. We’ll cover the on_message callback next.
Read More...
18 Nov 2020
As soon as you make the leap from developer to manager one of the most immediate changes you notice, apart
from the crushing uncertainty of not knowing what it is you’re supposed to be doing, is that your calendar
will fill up quicker than you can say “let’s schedule 30 minutes to discuss that”.
Clockwise is a new tool that has proliferated around the managers at work which
claims to solve your meeting woes by taking over the scheduling and booking rooms for you. It’s like having
your own PA, only without, you know, actually being important enough to justify one.
Technically Clockwise is a browser plugin which integrates with Google Calendar. Every day at 4pm it looks at
meetings occurring over the next week and rearranges them to resolve conflicts, and to try and create blocks of
“focus time”. Focus time is a chunk of meeting-free time, two hours or longer, in which you can get stuck into
work, rather than having a series of 30-minute gaps where it’s hard to achieve anything.
Read More...
04 Nov 2020
When my electricity provider, nPower, upgraded me to a smart meter I was excited about getting access to more
data about my electricity and gas usage. Unfortunately, it turned out that the extra data provided by the
connected meters was only available to the power supplier, and not to me as a consumer. They provided a little
device with a screen (known as an IHD, or in-home device) which displayed the current and daily/weekly/monthly
usage, but little else. No mobile app, no ability to dig into your historical usage, and definitely no API access.
While I was disappointed and frustrated about not having access to what I consider be my data, I left it as I
had more important things to worry about (i.e. kids). With my recent project to look at collecting more data from
my house, I wanted to revisit this, and collect the data.
There are two meter standards in the UK, SMETS1 and SMETS2. SMETS1 is the older standard, which is no longer being
rolled out. SMETS2 is the current standard, which operates quite differently to SMETS1. The main benefit being that
if you switch provider your smart meter will continue to work, something that wasn’t true with the earlier standard.
If you’re unlucky enough to have a SMETS1 meter you can ask for it to be upgraded. Fortunately, I had a SMETS2 meter.
The way these meters work is that both the electricity and gas meters broadcast their readings locally over a ZigBee
network. This is picked up by your IHD, and displayed live. The electricity meter also listens to the gas readings
and every so often uploads them over a mobile phone connection to a central data broker. This is then forwarded on
your supplier. smartme.co.uk has much more detail on this process.
The key point is that your data can not only be forwarded on to your supplier, but you can grant access to other
companies too. Enter Glow who act as what is known as DCC Other User and use
smart meter data to help companies do research and development. They also provide more tools for consumers to use
their data.
After installing the app you need to go through a security verification process. This involves uploading
details of your electricity meter and address (by taking photos of your bill), a photo of some photo id, and a
selfie video of yourself saying “I’m My Name, and I accept the terms and conditions”. After that, your details
are sent away for a manual verification process, which in my case took two days. I also received an email
asking whether I was planning to buy their
display. When I said yes
they said they wouldn’t process my application until it arrived. This was a bit frustrating as it meant I couldn’t
use the app in the meantime. Once the device arrived the application was processed quickly.
Read More...
28 Oct 2020
Today I wanted to share one of the more interesting debugging experiences that I’ve had. This
happened quite a few years ago when I was involved in migrating a set of websites over to use a single
login. The idea was that as soon as you landed on a site and your session wasn’t logged in, you would be
bounced over to an authentication site, which would bounce you back again. The two sites communicated
via a backchannel, and if you were logged in on the authentication site the main site would log you in too.
If not then you’d browse as a logged-out user, and when you logged in you were bounced over to the
authentication site with your credentials passed via a backchannel. If successful then you were logged in
on both sites, otherwise an error was displayed.
The backchannel communication was all encrypted with preshared keys, and when the user was bounced to the
authentication site they were also given an encrypted token to ensure that a bad actor couldn’t attempt to
hijack another user’s session. The exact details of the token aren’t important, but they included the user’s
session-id, details of the site they landed on, and the time they were bounced (to prevent against replay
attacks).
Everything was working great in testing, and we gradually rolled the change out to more and more users.
Eventually, we started getting reports of a small number of users not being able to log in. We
were able to determine that they landed on the main site ok, and were bounced to the authentication site,
but never arrived there.
Read More...
