Author: Robert Watkins

My name is Robert Watkins. I am a software developer and have been for over 20 years now. I currently work for people, but my opinions here are in no way endorsed by them (which is cool; their opinions aren’t endorsed by me either). My main professional interests are in Java development, using Agile methods, with a historical focus on building web based applications. I’m also a Mac-fan and love my iPhone, which I’m currently learning how to code for. I live and work in Brisbane, Australia, but I grew up in the Northern Territory, and still find Brisbane too cold (after 22 years here). I’m married, with two children and one cat. My politics are socialist in tendency, my religious affiliation is atheist (aka “none of the above”), my attitude is condescending and my moral standing is lying down.

ExtJS’s Grid Clipboard plugin is borked by design

I’ve been meaning to write this for nearly a year, but I held off hoping things would change with the next release. They didn’t, so I’m writing this: the Clipboard plugin for the Ext.grid.Panel class – which provides cut-and-paste support for the enhanced table widget – is borked by design. It does stupid things, and Sencha says it should do the stupid things. In this post I share what these things are, and how I’ve overriden the default behaviour to do something hopefully less stupid. Warning: this is a rant.

Continue reading “ExtJS’s Grid Clipboard plugin is borked by design”

Upgrading to ExtJS 6.2

Sencha recently announced the general availability of ExtJS 6.2. People who regularly read my posts (hi, to all three of you. 😉 will be aware that I’ve been working with the ExtJS library for a number of years now, while building a suite of apps of some not inconsiderable size1. It’s probably not the largest ExtJS app in the world, but it’s up there. And when you work on an application for a number of years, you’ll need to upgrade its framework from time to time.

Every time I’ve done this, the process has been a bit different. This time, it’s different in a good way – it was easy.

Continue reading “Upgrading to ExtJS 6.2”

Configuring a Multi-Branch Pipeline in Jenkins – Adventures in Learning

In my previous post, I had demonstrated how to configure a Jenkins Server using Docker. The next step is to create a Jenkins job to build some software. Now, we could just do a simple freestyle job, or a basic Maven build – but that will require configuration of Jenkins every time we want to make a new project, and that makes managing the Jenkins Server via Docker more annoying. So, instead, I’m going to use the Cloudbees Bitbucket Branch Source Plugin and create a Bitbucket Team/Project job that will create the rest of my Jenkins jobs automagically for me. A similar plugin exists for GitHub, though I haven’t looked into it.

Continue reading “Configuring a Multi-Branch Pipeline in Jenkins – Adventures in Learning”

Setting up a Jenkins Server with Docker – Adventures in Learning

With the upcoming end-of-life for Bamboo Cloud, I’m in the market for a new build server setup. For this1 experiment, I’m returning to an old favourite – Jenkins – paired with a potential new favourite – Docker. In this post, I describe how I’ve set up a Jenkins server in a Docker container, using the Multibranch Pipeline plugin to automatically configure a simple build2.

Continue reading “Setting up a Jenkins Server with Docker – Adventures in Learning”

Configuring OpsWorks with Chef12 – Don’t forget Security

This is very much in the aide-mémoire category – when setting up an AWS OpsWorks stack with Chef 12, remember to set up the security groups.

Continue reading “Configuring OpsWorks with Chef12 – Don’t forget Security”

Don’t bother with Bitbucket Pipelines – yet

As a previously fairly (but not completely) satisfied user of Atlassian’s Bamboo Cloud product, I was upset (like many others) to find out that it was being sun-setted. But they’ve got a new product to replace it – BitBucket Pipelines, currently in beta. So I gave it a try.

For those who can’t be bothered to read below the fold: don’t bother checking it out.

Continue reading “Don’t bother with Bitbucket Pipelines – yet”

Should repository managers ever ‘unpublish’?

As a result of the recent kerfuffle about left-pad being unpublished from the NPM repository, and the subsequent “internet breakage”, I had a twitter discussion with Charles Miller about the right for unpublish to even be an option.

First, let me make something clear: having provided an unpublish option, npmjs.com was ethically, if not legally1, obliged to respect Azer Kuçulo’s decision to unpublish. The fact that this caused downstream problems doesn’t change that. But what this post is about is:

Should the unpublish option have been available?

And yes, I think it should be.

Continue reading “Should repository managers ever ‘unpublish’?”

So… NPM doesn’t care about intellectual property rights?

The NPM organisation, a for-profit company, has just demonstrated that it doesn’t care about the IP rights of contributors. As a organisation built entirely on the contributions of others, this is a worrying precedent.

Background

Azer Koçulu had developed and distributed, via NPM, a module called
left-pad. It’s a simple library, consisting of 11 lines of code, that does what it says on the box – pads a string by adding spaces to the left.

This module then got picked up and used by lots of other modules. Apparently it had been downloaded nearly 2,500,000 times in the last month.

Koçulu had another module, called Kik. He received a cease-and-desist order from a lawyer complaining about trademark violation. He disputed that, and the lawyer then went to NPM. NPM decided to transfer the ownership of the Kik module – not remove it, but to assign ownership to a third-party.

Not surprisingly, Koçulu was annoyed by this. So he yanked all of his modules – about 250 of them – from NPM. Including left-pad.

This broke lots of things – heaps of projects around the world started to see failures due to the missing dependency on left-pad. In many cases, these were secondary dependencies – where ProjectA breaks because it depends on ProjectB, which depends on left-pad.

There is no question that this is a messy situation. But the fix that NPM decided on was worse. They un-unpublished the most recent version of left-pad, apparently at the request of a new owner.

What NPM should have done

It’s fine that someone can claim the left-pad module – if it’s been abandoned, it’s up for grabs. Nothing particularly wrong with that.

But the new owner only gets access to the name – they don’t suddenly get rights to the previously published code. Nor can NPM assign them the rights – by their own terms of service, they lose those rights when a module gets unpublished.

The new owner should have taken the couple of minutes it would have taken to fork the left-pad code base (which, under the WTFPL license used to distribute it, would have been perfectly fine), then packaged it up and submitted to NPM as a new module. They could even have re-used the version number, which would have solved everything.

In the case of Kik, NPM could have expelled the offending module. They could have claimed a safe-harbour provision and left it there. But they should not have assigned ownership to a third-party. And they really should not have double-downed on their transgression by doing it again.

Summary

NPM does not care about the IP rights of its contributors. They have shown they are willing to transfer IP to third-parties, and even to transfer IP they’ve explicitly had their rights to distribute removed.

I would suggest not publishing anything to NPM.

%d bloggers like this: