Weekly developer news – May 4th 2018

So, welcome to the next edition of developer news. Sorry there wasn’t one last week. It was a case of a lot of client facing work last week combined with the fact that out of the items I had been monitoring, nothing really stood out as worth pointing out.

Here are the top items from this week that I think are worth taking a look at.

1 : Why GET requests should be idempotent

First up is a tweet that has gained a lot of coverage illustrating why GET requests should be idempotent. I’ll let you read it for yourself, but it involves browser tabs automatically opening and closing your garage door! There’s a lot of follow up discussion both on Twitter itself as well as on Reddit.

I spend a lot of my time working with developers, and pretty frequently get involved in helping teams define a sensible API structure. It’s something that can be so easy to wrong if you don’t approach it from the right perspective.

I recently encountered an API where every single endpoint was a POST request, and rather than being designed around application behaviour and data, it was a direct representation of the screens within each mobile application. Needless to say, that is a massively difficult API to maintain!

2 : TSB issues caused by poor testing and scoping

Next, is an Reuters article on the recent TSB bank outage here in the UK. The article goes into detail following comments from some contractors familiar with the issues and codebase. From the sound of it, it comes down to poor testing, poor scoping, and rushing features out the door.

3 : On Long Variable Names

Finally for this week is a stack exchange post asking for research on benefits of more expressive variable names in a codebase, something they found has helped them read existing code. (I really love the fact that the URL for this is truncated..)

Again, there’s also a pretty sizeable discussion around that post on reddit too.

It’s something I have always been a fan of. Not to make variables needlessly long for the sake of it, but to make them the right length to convey their meaning.

I have worked with so many developers that seem afraid of anything other than really short variable, function, or class names. When questioned on why they went for a short name, the typical response is well, that would make it longer. yes! it would, but it would be far more readable if it was not truncated unnecessarily.

I think the whole short variable name thing is another one of those things that has just become common practice, without most people really stopping to question readability of code after the fact.

So, that’s it for this week.

If you have any articles, announcements, tutorials, or anything else you think should be included next week, then just drop me an email.

Weekly developer news – April 20th 2018

So, welcome to the next edition of developer news. Here are the top items from this week that I think are worth taking a look at.

1 : How Netflix does failover in 7 minutes

First up is a post by Netflix senior engineer Amjith Ramanujam on how they are able to perform a failover in just 7 minutes in the event of an AWS region becoming unavailable. Netflix are always very good about sharing how they manage their massive infrastructure, and maintain great availability. It’s always good to see companies publishing this kind of insight.

2 : ReactOS 0.4.8 release

Next, is an announcement from the ReactOS team, on a new release 0.4.8. If you haven’t heard of ReactOS, not to be confused with ReactJS of course, it’s an open source re-implementation of MS Windows. This release has a number of improvements including experimental Vista and Windows 7/10 support.

This is an interesting project I like to monitor for a couple of reasons. Firstly, it’s a massive open source undertaking to provide a Windows compatible operating system. There are a number of interesting lessons about reverse engineering, and also a number of interesting decisions on whether to port functionality as it is in Windows, and interesting to see where there can be improvements.

For me, it’s not a project I have need to make use of as such, but see the development of it as something I can certainly learn from.

3 : Microsoft builds it’s own customised Linux kernel

Next is a writeup following a small Microsoft press event announcing a new secure IoT product line, Azure Sphere. Whilst the details of this are interesting and may be worth experimenting with, the main point of interest for me here, is that for the first time ever, they have decided to launch a custom Linux kernel and distribution, because it is best suited to the task at hand.

4 : Hyperledger project makes bug bounty program public

Next up is the open-source blockchain project Hyperledger, announcing that they have now made their bug bounty program public. Whilst I think blockchain as a technology is like many others certainly over hyped, I think there are genuine use cases, and it’s a technology that will see development. So, if it’s a technology you have been interested in getting to grips with, maybe this program could be motivation for you to get started.

So, that’s it for this week.

If you have any articles, announcements, tutorials, or anything else you think should be included next week, then just drop me an email.

Weekly developer news – April 13th 2018

So, welcome to the next edition of developer news. Here are the top items from this week that I think are worth taking a look at.

1 : Microsoft Open sources Winfile

First up is a Microsoft releasing the source code for their original Windows File Manager (Winfile). I always like it when companies open source their production code, as it provides a great insight into what the code and dev practices look like in other teams and organisations. I always recommend developers try to study other code, look for the good and bad points, and try to understand some of the decisions behind the code.

2 : Oops we dropped the production database

Next, is a post mortem from travis-ci on a production incident that resulted in their systems being temporarily unavailable (for 5.5 hours). The cause was some test code being accidentally run against their production servers. The integrations tests run a query which truncated all data in the database, meaning they had to restore from backups.

There are a whole bunch of lessons to be learned here around test and environment management as well as around system monitoring and detection of issues, so this post mortem is definitely worth taking a look at.

3 : Automated canary analysis at Netflix

Next is an article from Netflix describing a new open source project named Kayenta . This is something they use for their ‘canary analysis’ i.e. something they use to help verify a release that is in the process of being rolled out to ensure that it’s safe to make available to everyone.

Netflix engineering are known for their approach to testing and verification in production in order to make their production systems as robust as possible. It’s an approach that forces you to make those systems work for you as opposed to just hoping nothing goes wrong, and then trying to pick up the pieces when it does.

Whilst I have looked at their open source projects before, and have found them obviously tailored towards their specific deployment needs, I’ve found there is certainly a lot to take away from their projects in terms of principles, even if code-wise you need something that’s a slightly different shape.

4 : Stanford creates open source architecture for low latency video calls

Finally for this week, is a project by Stanford called Salsify.  It’s a project that claims to deliver improvements over Hangouts, Skype etc for video calling that takes into account both the network transport and video codec. As someone who has worked a fair bit on various video streaming and analysis products, I always enjoy looking at developments in this space.

Skype used to have a more P2P model, but after the Microsoft acquisition went more server based, which does give benefits, especially as far as mobile is concerned, where networks are very unstable.

It will be interesting to see if this project continues to develop and generate any interesting innovations. They are committed to open sourcing their findings, so I’ll certainly be keeping an eye on it.

So, that’s it for this week.

If you have any articles, announcements, tutorials, or anything else you think should be included next week, then just drop me an email.

Weekly developer news – April 6th 2018

So, welcome to the next edition of developer news.

1 : Apple looking to drop Intel chips from 2020

First up is a Bloomberg article reporting that Apple plans to start using it’s own chips across the Mac range from 2020. It would make sense given that they use their own chips for their iOS based products.

The article also talks about plans known internally as their ‘Marzipan platform’ which will allow iOS apps to run on Macs. I must admit, it’s hard for me to see how there could be a great user experience with something designed for a very different form factor, so it’s something I’ll be interested in seeing if it does materialise.

2 : Visual History of Eve

Next, is a walkthrough of the history of Eve. If you haven’t heard of Eve, it was / is an experiment to develop a more visual, literate style of programming environment. A richer development environment that allowed for different styles of development and debugging. The Eve project as a funded startup was shutdown early this year after failing to find someone to invest in it’s future.

As someone that tried many of the different incarnations of Eve, it’s a shame to see development stall. I hope that it does continue in some shape or form. It would be great to see many of the ideas around literate programming make their way into more mainstream languages and development tooling.

3 : Stanford study on Working From Home

Next is an article describing the results of a 2 year study by Stanford into the effects of working from home.

The study was expected to highlight the different trade offs in home / office based work, but instead found that there were productivity benefits from working from home.

For me, home working is essential as I work with many clients across the UK. I do see it becoming increasingly more acceptable with clients that I work with, which more often than not have some offshore capabilities anyway.

It’s also something that I personally find does make me far more productive, but that doesn’t mean it was easy to get to that point. I know many developers that really don’r get on with working from home, and would much prefer set time in an office Monday to Friday.

4 : Panera Bread and security

Finally for this week, is a blog post discussing the Panera Bread security breach, and highlights failed attempts to raise security issues with them.

As I have said before, security issues are real, and becoming publicised more, and likely exploited more in our world of big data.

As a developer, it’s something that we definitely need to be aware of in all of our own development, and even when selecting third party libraries, components and frameworks that we use. It’s something that doesn’t stand still, so even when our work is ‘done’ we may well have to go back and ensure it remains secure.

So, that’s it for this week.

If you have any articles, announcements, tutorials, or anything else you think should be included next week, then just drop me an email.

Weekly developer news – March 29th 2018

So, welcome to the next edition of developer news. Yes, I know it’s Thursday, not Friday, but tomorrow is a bank holiday here in the UK, so I’m off, but still wanted to push out a news post this week.

1 : Test Driven Development in TypeScript

Firstly, is a shameless bit of self promotion. After talking to one of my students on the Java TDD course about test driven development using TypeScript, I decided to create an article to detail the tech stack in terms of what I use for unit testing under TypeScript. As well as that, it’s a simple walkthrough of how I tend to approach TDD.

2 : Package versioning proposal for Go

Next, is a proposal for package versioning in Go. It’s something that has been missing in Go, with other third party alternatives popping up, including the popular Glide. Whilst Go is often criticised for how it deals with packages and versioning, the language maintainers would argue they would rather go for a well considered solution instead of rush just to get something out early. I think that argument does hold merit, but it has been a long time, so hopefully things will start moving forward on this.

3 : Google Cloud text to speech

Next is an announcement from the Google Cloud team on a new cloud text to speech offering they provide, powered by their DeepMind WaveNet technology. If you want to give this a go, then checkout the main cloud text to speech page where you can try some examples of this in that page itself to see what it sounds like. With voice platforms becoming more popular, it’s certainly something worth looking into.

4 : ReactJS update on async rendering

Finally for this week, is a blog post from the React team on async rendering. Async rendering hasn’t launched yet, and it has been in progress for quite a long time now. If you are working with React, it’s worth looking at this post which discusses the lessons learned during the development of this, and contains some things to start thinking about for your applications ready for when this does launch.

So, that’s it for this week.

If you have any articles, announcements, tutorials, or anything else you think should be included next week, then just drop me an email.

Test Driven Development in TypeScript

Unit Testing TypeScript

I was recently asked by one of my students on my Java TDD course whether I had any material relating to test driven development and TypeScript.

I’m a big fan of TypeScript, and I do have a number of things planned relating to TypeScript for my new soon to be released membership site over at TheDeveloperCollective.com, but didn’t have anything quite ready to release over there, so decided to create this article in the meantime.

If you haven’t heard of TypeScript, then you can head over to the typescriptlang.org page for more info, but basically think of it as JavaScript combined with (optional) typing. Typing as in type safety, not more fingers on keys.

It’s a typed superset of JavaScript that can be compiled to JavaScript, and for me is something I have found can give a real development efficiency and quality boost, though it’s not without challenges of it’s own.

So, in this post, I want to talk about how we could unit test and therefore TDD a pure TypeScript project.

There are a few different approaches we could take.

We could for instance just use the TypeScript compiler to emit JavaScript files, and stick with plain JS testing, but that kind of defeats the purpose of using TypeScript if we don’t extend it to our test code too. I have seen this done, more commonly on mixed JS and TypeScript projects, but why wouldn’t we want the type safety there too?

You could also use the excellent babel for transpiling the code, but again, I think that is overkill for this particular use case.

Instead, I’ll demonstrate a relatively simple approach using the ts-node library to integrate with the mocha test framework.

My Environment

As far as my environment is concerned, I’m currently running the latest version of node.js, which at time of writing this is 9.8.0. For my IDE, I’m using Visual Studio Code, because it has excellent TypeScript support, so I get nice help from IntelliSense as I’m working.

I’m also assuming for this article that we want to be running our tests under node.js, rather than in a browser of any form. To be honest, even when testing JS/TypeScript that would be run in a browser, I would normally test in a node.js runtime as it’s far easier to manage, and quicker to run and work with.

Creating a project

For this article, I want to demonstrate setting all of this up from scratch, introducing code in a test driven way, though if you have an existing project you are working with, you can follow the exact same approach.

For this demonstration, I’m not being massively original, but I’m going with a simple calculator. It’s a simple example everyone should be familiar with, and demonstrates testing something that has it’s own internal state.

The techniques demonstrated could be applied to any kind of problem.

So, let’s get coding.

My first step is to create a new project. I’ll create a new directory for my project, and just use npm to create a skeleton package.json file.


After filling out a bit of info, we will have a basic package.json we can start working with.


We won’t worry about some of the details just yet, such as test command. We will add those once we are ready. The main entry of index.js also isn’t important as we are only going to be executing code via unit tests.

NPM Packages

So, first things first, let’s sort out our dependencies.

For this example, I want to use mocha as the test framework, with chai for assertions using the expect style of assertions.

You could use different assertion style or library. It really is up to you as to which you prefer. For me, I like both expect and should, with should for me being slightly more natural, but expect being more consistent, especially when concerned with null or undefined values.

We will of course, also by using the typescript package, as well as a node runner for typescript, ts-node. If you haven’t encountered this before, then ts-node is worth taking a look at. As well as helping us run our tests, it also has an interactive REPL which can be really useful during development.


So, we are using npm install, telling it to update the devDependencies section of our package.json.

You will notice from above, as well as the packages mentioned, we are also installing the type definitions for chai and mocha, so that they will play nice with our TypeScript compiler and IDE to give us the most benefit of using TypeScript.

If this all goes well, you should see an output that looks a bit like this:


ok, so now we have our base setup, we can start looking at some code.

Starting with the test

We are taking a test driven approach, so the logical place is the test. Let’s start by creating a test file, making sure we can execute tests, and then working towards our first failing test!

I want to keep my application source code and test source code in different directories. You don’t have to. I am seeing trends where people do like to keep them in the same directory, with a different suffix, maybe .spec.ts, .test.ts, or some variations involving underscores etc. It’s really up to what you prefer and what your motivations are.

So, I’ll create a src and a test directory

Next, I’ll create a test file, which can just be empty for now

Now, let’s make sure we can execute tests.

For this, let’s edit the test line in our package.json, and change it like so:

We can now verify that we can run tests, like by running

You should see a test run with unsurprisingly 0 tests passing as we don’t have any yet!

We can also execute mocha, and have it watch our test files for changes by passing the -w option to Mocha like so:

You should see the same output as before, but this time, mocha will not terminate, and will instead monitor for changes.

So, now we have our tests running, albeit with no actual tests to execute, but the important thing is we have verified this process works.


Now we can start to develop our test and application code together.

If you want to skip straight to the full test and application code then you can see all of that below, but to illustrate how I would go about creating that in a test driven way, see the screencast below, where I will rapidly iterate between test and app source code to develop a basic calculator class.

Completed test and application code

ok, so hopefully you have watched the video above, but if you wanted to jump straight to the code, that’s fine too, but I think the video is worth a watch later if you have a spare couple of minutes.

So, here is the completed test code


And now the application code being tested


So, hopefully there’s nothing too surprising there. As mentioned before, I’m using mocha as the test framework with chai expect for assertions.

It’s obviously only showing really basic functionality as far as the application code itself is concerned, but not matter how complex the application code is, the same approach can be used.

And all of this is being done in pure TypeScript. Aside from any dependencies we are pulling in, there is no straight JS. We are using type definitions for mocha and chai in order to integrate them nicely into our TypeScript project.

I hope if you are looking to setup a new TypeScript project, or start adding tests to an existing TypeScript project, this example is useful to you.

If you want to download the source code for yourself, then just checkout the git repo here – https://github.com/thedevelopercollective/tscalc

Weekly developer news – March 23rd 2018

So, welcome to the next edition of developer news. It’s been an interesting week, with a number of new announcements that I wanted to highlight.

1 : Java 10 Released

Firstly, is as the title suggests, an announcement that Java 10 JDK is now available. You can see the downloads and release notes etc on the massively ugly and painful to navigate Oracle site. Key features to note from this short term release (LTS release is coming in September) are local variable type inference, improvements to garbage collection as well as improvements to system information returned when running in a Docker container.

2 : Magic Leap Creator announced

After much hype, and press coverage, largely due to the sums of money raised as investment, Magic Leap are now allowing developers to get their hands on the first public release of their SDK named Lumin SDK. Their SDK allows development of AR applications using Unity, or Unreal Engine, and provides a number of simulators and tools to make development easier. For me, it’s still a technology I am monitoring rather than actively engaging with, but I’m very excited about the possibilities this kind of technology could enable.

3 : Amazon GameOn SDK

Next is another gaming related SDK. This time from Amazon, with their announcement of their GameOn SDK. This SDK provides AWS based services for managing cross platform gaming features such as leaderboards, and competitions, and looks like an easy way to provide these kind of community focused features.

4 : State of Clojure 2018 Results

Finally for this week, are the results of the annual state of Clojure survey. Clojure is a language I have used on production systems before, and one that I do really like even though the opportunity to use it in production doesn’t come up too often. For the right team though, I think it can be an excellent choice. This year’s survey shows continued use of Clojure and seems to indicate that there is still growing demand for these skills.

So, that’s it for this week.

If you have any articles, announcements, tutorials, or anything else you think should be included next week, then just drop me an email.

Weekly developer news – March 16th 2018

So, welcome edition 23rd of developer news. Sorry there wasn’t a post last week if you were looking out for one.

There are a couple of reasons for that, but the main one is, there wasn’t really anything that I felt was worth highlighting. There was the usual kind of background news and recycling of news, comments, and opinion, but nothing that really caught my eye as something worth digging into or highlighting.

But, this week, I do have some items to share.

1 : Updating a 50 terrabyte PostgreSQL DB

First up is a medium article, from a system administrator at Ayden discussing how they dealt with updating a pretty sizeable database by anyone’s standards.

It’s a nice illustration of the thinking that has to happen when things get that big, and it does go into some detail on migration approaches and architecture.

2 : SQLite language choice

This second item, is an article that has been shared a lot both publicly and privately from the SQLite team discussing why it’s written in C. It’s not necessarily new information to many, but it’s good to see a language discussion that doesn’t revolve around purely style of syntax.

3 : Rust’s 2018 Roadmap

Next is a post from the team behind the Rust language, publishing their roadmap for the Rust language development for 2018. It’s not a language that I’m familiar with in terms of day to day usage, but I always like to monitor other language developments. I like to expose myself to different language, system designs, and like to look at differences in approach to my own, either opposing or complementary.

4 : GitHub doesn’t want to monitor your code

Finally for this week, is an article by GitHub regarding a proposed EU law which relates to the automatic monitoring of uploaded content for copyright infringement.

It’s a proposal mainly aimed at people sharing media, music, videos etc, but code would come under the same category, and many people, including GitHub don’t like that.

There lots of discussion around the web, and many different views, with some people seeing it as a positive proposal, others not liking the ‘monitoring’ side of it. GitHub obviously don’t want the overhead and complexity of having to do this. To detect copyright infringement of uploaded code automatically is a massive job, and one which is very likely to give false positives.

So, that’s it for this week.

If you have any articles, announcements, tutorials, or anything else you think should be included next week, then just drop me an email.

Weekly developer news – March 2nd 2018

So, welcome edition 22 of developer news on a very snowy day here in the UK!

I might be snowed in, but still have internet, and there’s still developer news!

1 : Flutter beta 1 released

First up is a new framework release. First one worth point out for a while, and it’s a new mobile UI Framework developed by Google that they announced at Mobile World Congress 2018.

The article gives a good intro with some videos too, and describes how this framework allows for both developer productivity and great on-device performance.

It support creating native apps on both iOS and Android. You can see the project page itself at flutter.io.

2 : IoT security

This second item, because you can never have enough of security vulnerability news, is another look at real world security flaws in a number of IoT devices. As developers, it’s worth considering how and where our code will be deployed, and ensuring we do all have good security practices.

3 : AWS certified developer exam beta

Next is Amazon, launching a beta of their new certified AWS developer exam. If it’s something that appeals to you, then you can register your interest at that link.

I also like to be in a position to demonstrate my development expertise, skills and learnings. There are many many ways to do this, and sometimes some kind of certification can be useful, particularly where third party platforms and ecosystems are involved, so if you are looking to do more on AWS it’s worth looking at.

4 : Quitting Google

Finally for this week, is an article titled “Why I Quit Google to Work for Myself“. This article has been shared all over the internet, private chats this week, with many comments on Reddit and HN.

It’s a good look at what being a developer in a massive metrics driven organisation can look like.

Having worked in many types of development organisations, it’s always interesting to read about other people’s experience in different types of org. Some places are more suited to certain types of developers at different times than others, and I think it’s very healthy to acknowledge that.

So, that’s it for this week.

If you have any articles, announcements, tutorials, or anything else you think should be included next week, then just drop me an email.