GDPR cookie scanner

I came across the GDPR Expert service via this HackerNews thread. It is a service that helps website owners with the GDPR compliance. Behind the scenes, there is this open source tool, which scans for cookies and provides the details about the vendor and purpose of each identified cookie. The database includes more than 10,000 known cookies.

Very handy.

Unraveling the JPEG

It always amazes me how little do we know about everyday things around us. Today I came across “Unraveling the JPEG” article, which is a deep dive into the JPEG format. JPEG images all around us, but how much do we really now about them? I bet you even the most technical web developers and designers will have their hands full with this, let alone all the non-technical people who snap selfies on a daily basis.

Not only the article itself dives into the technical details, but it also provides an inline JPEG editor, which you can use to play around with the data and see how it affects things. Great job!

Notes to Myself on Software Engineering

I came across these “Notes to Myself on Software Engineering“, with which I agree wholeheartedly. Some of these I’ve learned “the hard way”. For most of these, I wish I knew them earlier. They would make my life a lot easier. Here a few to get you started, but make sure to read the whole list, as many of these apply to other areas of IT and life in general.

It’s okay to say no — just because someone asks for a feature doesn’t mean you should do it. Every feature has a cost that goes beyond the initial implementation: maintenance cost, documentation cost, and cognitive cost for your users. Always ask: Should we really do this? Often, the answer is simply no.

Invest in continuous integration and aim for full unit test coverage. Make sure you are in an environment where you can code with confidence; if that isn’t the case, start by focusing on building the right infrastructure.

Simple things should be simple, complex things should be possible. Don’t increase the cognitive load of common use cases for the sake of niche use cases, even minimally.

Because code is communication, naming matters — whether naming a project or a variable. Names reflect how you think about a problem. Avoid overly generic names (x, variable, parameter), avoid OverlyLongAndSpecificNamingPatterns, avoid terms that can create unnecessary friction (master, slave), and make sure you are consistent in your naming choices. Naming consistency means both internal naming consistency (don’t call “dim” what is called “axis” in other places) and consistency with established conventions for the problem domain. Before settling on a name, make sure to look up existing names used by domain experts (or other APIs).

Career progress is not how many people you manage, it is how much of an impact you make: the differential between a world with and without your work.

Software development is teamwork; it is about relationships as much as it is about technical ability. Be a good teammate. As you go on your way, stay in touch with people.

When we find ourselves in a conflict, it’s a good idea to pause to acknowledge our shared values and our shared goals, and remind ourselves that we are, almost certainly, on the same side.

SCAR: static website deployment on AWS

SCAR is a deployment stack for static websites. It’s not exactly a single-click process, but it is as simple as possible. The name is the abbreviation from the Amazon AWS services which are utilized for the deployment: S3, CloudFront, Amazon Certificate Manager, and Route 53.

The whole thing is built via the Amazon CloudFormation, and shouldn’t require much of tinkering with the services or reading lengthy documentation pages. This bit should also motivate you to try it out:

How much will this cost?


For most sites, it will likely cost less than $1 per month. The cost for a Route 53 hosted zone is fixed at $0.50/month; the remaining CloudFront and S3 costs depend on the levels of traffic, but typically amount to a few cents for small levels of traffic.

Falsehoods programmers believe about Unix time

A while back I blogged a collection of “Falsehoods programmers believe about …“. One of those things was time. Today I came across a nice addition to that – “Falsehoods programmers believe about Unix time“.

These three facts all seem eminently sensible and reasonable, right?
1. Unix time is the number of seconds since 1 January 1970 00:00:00 UTC
2. If I wait exactly one second, Unix time advances by exactly one second
3. Unix time can never go backwards
False, false, false.

All three of these are false and for the same reason – leap seconds. The article provides a nice and easy explanation of how and why that happens.