Category Archives: Programming

Every dependency is a vulnerability

Not so long ago, we all got comfortable with the idea that great chunks of the programs we were writing should be implemented by libraries pulled in from third parties — using CPAN, Maven, NPM or what have you. It was the reuse we’d always dreamed of. Happy times, right?

Not so much, I now think.

Continue reading

Semantic Versioning is a terrible mistake

When I first heard about Semantic Versioning, or SemVer, I thought it was one of those ideas that’s so obviously right that we were all going to benefit from someone having just codified it and written it down.

Continue reading

Proposal: a controlled vocabulary for attitudes towards pull-requests, forks and bug-reports

Yesterday I read Just Say No, a post by Jeff Geerling who maintains a bunch of popular devops project on GitHub. His position, which I am totally sympathetic to, is that maintaining a project is a lot of hard and mostly uncompensated work, and so:

That pull request that’s 100 lines and’ll take you an hour to review? No.

That issue that’s requesting you to pull your project just in a slightly different direction? No.

That little opportunity that you’ve been waiting for but you just know you can’t do right now? No.

Again, I am sympathetic. I agree, mostly. Yet at the same time, I hate to imagine being the guy who spent multiple days on a PR to something of real value, only to have it insta-rejected with “Sorry, I don’t have time to review this”.

Continue reading

From the depths of time: a 30-year-old bug with a funny explanation

It was 1990 or possibly 1991, and I was working for System Simulation on an Application for Windows 2 – which at that time was a rather exotic extra that a few adventurous people were running on top of their MS-DOS systems. There was no graphical development environment in those days: you’d compile your program using the command-line C compiler cl, and compile your resources (dialogue boxes, menus and suchlike) using the command-line resource compiler, rc.

Continue reading

Testing with Jest: how to mock an import used by the module you’re testing

I am writing a Jest/RTL test for a React component that invokes another component. I want to mock that second component so I can have it do things like invoking callbacks that the first component passes to it.

But there is nothing specific to React about this requirement: it comes up for non-React modules, too. I have an approach that I have shown to work using trivial modules and I want to document it here for myself and anyone else who finds it useful.

Continue reading

I miss my Commodore 64

Building modern software is so complicated. So many layers where things can go wrong. Vagrant, VirtualBox, Docker, Maven, JVM, Vert.X, Spring, Node, NPM, Cypress, Chai, SSH, tunnels, git, GitHub, Jenkins, Travis, the list goes on and on.

I understood everything about my Commodore 64. Now I barely understand NPM. I know there are good reasons why things are the way they are. But that doesn’t mean I don’t lament what we’ve lost.

 

Major releases are disasters, and should be avoided whenever possible

If you use semantic versioning in your project — and you should — then you fix bugs in patch releases (e.g. going from v2.4.6 to v2.4.7), and add new features in minor releases (e.g. from v2.4.6 to v2.5.0). These are both unambiguously good things to do: downstream projects that use your project can happily and blindly upgrade to your new versions knowing that everything is compatible and nothing will break.

But when you issue a new major release (e.g. from v2.4.6 to v 3.0.0), that’s because you made an incompatible change. Now the maintainers of downsteam packages have to stop and think and read your release notes before they can be confident whether it’s safe to upgrade, or whether (as with all the various React-related libraries’ major versions) they’re going to have to rewrite their code first. Most often, they won’t have the time or energy to do this for all the many dependencies their project has.

Continue reading

Passing laws and adding BIB-1 diagnostics

Years ago, I was a member of the Z39.50 Implementers’ Group. We’d gather from all around the world, maybe 30 or 40 of us, and meet for several days to discuss and vote on possible extensions to this venerable (and still important) information retrieval standard.

A common item of business was approving a new diagnostic code. Continue reading

Scottkit is born! Only seven and a half years late!

Those of you who have been reading this blog since 2nd March 2010 — just three days after the blog was born — might remember the fourth post I ever made here: Learning a language vs. learning a culture, on my switching from Perl to Ruby. Way back then, I wrote about “ScottKit — my first non-trivial Ruby program”. Here it is!

Continue reading

React error-message of the day

This just in:

Failed context type: Invalid context `paneset` of type `Paneset` supplied to `Paneset`, expected instance of `Paneset`.

Oh, the joys of front-end development!

(My best guess: I have two slightly different version of stripes-components library that provides the <Paneset> component in my application, and somehow I’ve got hold of one from the wrong instance.)