Got some new business cards at work today. They’re pretty nice.
A few months ago I integrated the Node Security Platform into the continous integration system we use at pHQ. This week it picked up a vulnerability for the first time (don’t worry, its since been patched 😉) which meant that I was alerted to the vulnerability and provided with a link to read about ways to mitigate the risk involved until a patch was available. Had we paid for a subscription to NSP it would submit a pull request to update the package(s) with the fix as soon as it was available.
In the case shown in the screenshot above you can see that the pHQ platform didn’t directly rely upon the vulnerable package, but had 5 dependencies which included it one way or another. If you’re not automatically checking for vulnerabilities then you may not find them as you probably don’t know how many packages you indirectly depend upon!
If you’re not using node something like Snyk may support your language.
As Software Engineers our job may be seen as producing features for users, but we have a duty to ensure that what we develop is secure and won’t put peoples money or personal information at risk. A dependency vulnerbility checked is one great tool to have in the box.
Last week I was promoted to Lead Software Engineer at PepperHQ.
As part of the meeting we discussed what I want to achieve in the year ahead. There’s a lot and I’m looking forward to it.
I’m going to try to be a bit better at keeping the blog up-to-date with details of my day-to-day work going forward.
This weekend I was trying to resolve an issue with an accidental purchase one of my relatives made on ViaGoGo. We realised the mistake the same day as the purchase, and I set about trying to get a refund.
Being the somewhat impatient person I can be with matters like this, and knowing that different channels of communication often result in different outcomes, I decided to send ViaGoGo an email and a direct message on Twitter at the same time.
A few hours later I got a response via both email and twitter (strangely enough, they replied by email first). The email I recieved was a pretty bad copy/paste job that started with “Dear mrs , ” Yes, lowercase Mrs. Yes, without my last name. The email told me that tickets were unrefundable and that they considered the case closed.
Meanwhile, on Twitter, I recieved a well written response and the offer of a full refund — which was then processed the same day.
The cynic in me thinks that perhaps companies are more likely to work with you when they know you have a public platform to complain about them on. But perhaps this isn’t the case, perhaps the different responses is just a function of speaking to different people in different roles (Community Manager vs Customer Support) or just people in different moods on that day.
Either way, I always seem to have recieved better customer service when I use a Social Network.
A little while ago I was curious about how software that uses Transaction Logs works, so I built a toy to-do command line application to get some hands on experience.
Transaction Logs are used when you want to have metadata detailing each action that has taken place on a system but then actually use those logs as the data for the system. Therefore to build up the state of the system at any time you can simply “replay” each action that took place before that time. This enables you to time travel as well as know exactly what happened for user 54 to go into his overdraft.
Above you can see every feature of
todo-log (I did say it was a toy application!) being used from the macOS terminal.
add command you can store a todo item with both a title and some additional body text. This todo item is then assigned a short code — shown in red above — which can be used as the unique identifier to manipulate it in other commands. The transaction detailing the addition of the todo item is saved to a JSON Lines (
ls command, without parameters, displays a list of all the todo items which are outstanding at the current time. Some basic formatting is applied including showing a friendly date (e.g. “two hours ago”) for the creation time of a todo-item.
Deleting a todo item is simple, just pass the shortcode of the item to the
rm command. The command doesn’t then delete the add transaction from the
jsonl file, instead it adds its own
remove transaction detailing the time of deletion and the todo item involved.
log command just prints out the raw
.jsonl to the terminal for inspection. In the above screenshot you can see the format of both the
Finally, passing a positive integer parameter to the
ls command goes back in time by that number of transactions. In this example you can see what the state of the todo list was before the previous
rm command was issued. Everytime
ls is called it simply builds up the current state of the system by rerunning each of the actions detailed in the
.jsonl file — to go back in time we just ignore the last
n lines, where
n is the number provided to the command.
You can have a look at this fun little project over on my Github.
Though I only spent a couple of hours on it, and it doesn’t do much, I feel like working on this gave me a greater appreciation of what transaction logs can be used for and the challenegs around them. Systems like RDBMS transaction logs and Apache Kafka are much more interesting to me as a result.
Sometimes the easiest way to learn about something and become more interested is just to jump in and build something