This week the internet exploded in drama after 11 lines of code got unpublished from npm. If you didn’t read about it, the summary is that the developer of left-pad removed his package from npm, after npm renamed another package of his because of some name conflict with some other company’s trademark or so. Lots of other packages broke because of this due to the missing dependency. What is interesting here, is that this removed left-pad package consists of a single function (only 11 lines of code). How can that tiny package break the internet?

Code coverage is a useful metric of the quality of your code. It shows how much code is being covered by unit tests. It doesn’t necessarily mean that the unit tests are well written, but no metric can probably tell you that. However, aiming for a specific code coverage, let’s say 70%, is a good practice, because failing to meet the goal might mean somebody didn’t write enough unit tests.

I don’t do a lot of .NET programming these days. At work we deal mostly with JavaScript. However, C# is still the language I’m more fluent in and, also important, a language that I really like. That’s why sometimes I like to code a bit in C# at home. That can be either on Windows or on a Mac with Mono. The problem with Mono is that things can always be a bit different and require some extra effort.

You may have noticed that a lot of GitHub projects have some badges in their homepage, showing for example the status of their latest build. For a node (JavaScript) project, you can use a few more badges to show the world that everything is in order.

It doesn’t matter if you’re using a simple editor or a full blown IDE, if you want to be more productive you have to spend time to learn some keyboard shortcuts. Here’s a few keyboard shortcuts I use frequently when I work with Atom.

Here’s a small tip that puzzled us at work the other day for a while. How do you use chai-as-promised together with chai-string?

In the previous post, I talked about static code analysis and how it can be useful in enforcing and maintaining a consistent coding style, but also in catching subtle bugs and code smells. The focus was on two tools, jscs and jshint. What other tools and techniques can you use?

Reading code is hard. It’s often difficult to understand what the developer was trying to express when he was writing that function. If you keep your old projects around, go ahead and open them. You’ll probably struggle to read even your own code. It might even look as if somebody else wrote it.

This is a long post, be advised! It goes through the adventures we have had at work with automated browser tests in JavaScript. It has been a journey full of challenges and knowledge build up, a journey that still goes on!

Sometimes, the photos I take with my phone don’t have the correct EXIF tags set. This gets annoying because those tags are used by photo organizers to determine when a photo was taken. If the photo doesn’t contain the date in the EXIF tag, the organizer application will use the file’s timestamp, which could change if you copy paste the file, move it around, move it to another computer, restore it from a backup and so on.