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.
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.
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.
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.
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
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
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.
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.
A logarithmic axis is useful for displaying data with a large range of values. Sometimes these values are already on a log scale – e.g. the Richter scale is a log scale, as is decibels. You can plot this on a normal linear numeric axis. But sometimes your values can’t be easily converted to a log scale. Maybe you’re plotting wealth distribution. Or, in my case, particle size distributions, where the sizes can range from metres down to microns. When dealing with something like this, you need a log axis.
Well, it’s been three-and-a-half years, but I’ve finally got around to getting to a point of writing an iOS app. I wouldn’t hold your breath waiting to get a copy, though – it’s purely for my private use, to aid in monitoring and administering the IES project.
After doing enough tutorials and similar exercises to be comfortable in building the app and the UI, I got around to trying calls to the AWS infrastructure. This proved a bit more difficult than I anticipated – hence this aide-mémoire. This isn’t going to be useful for non-iOS developers, and I doubt it’s going to have anything new for more seasoned iOS developer; only iOS noobs like me need bother.
But there’s just one problem… you have to use the embedded web server started with the
sencha app watch command. Which is fine if all you’ve got is a webpage, but if you’re dealing with web services (as so many web apps do), it’s a bit restricting – at least if you don’t want to configure your app or server to allow cross-site scripting.
But Live Update is too awesome to forego! What to do?
Quick _aide-mémoire_ so that I don’t forget. When upgrading from ExtJS 4 to ExtJS 5, if you’ve got any components that use a custom template, and expect `childEls` to be configured correctly, you need to add a `data-ref` to the generated HTML.
Quick aide-mémoire so that I don’t forget. When upgrading from ExtJS 4 to ExtJS 5, if you’ve got any components that use a custom template, and expect
childEls to be configured correctly, you need to add a
data-ref to the generated HTML.