PSA: Secure your build processes

I need to say this because there’s too much moaning and grinding of teeth going on about npm packages loads of projects depend on.

If you have a project with dependencies, do yourself a favor and have an in-house mirror for those. It’s even more important if you’re a software shop which works primarily with one technology, which I presume is a very common case.

I’m not too node.js savvy, but in the Java and Maven repositories world, we cover our backs using either Nexus Repository (which appears to work with npm, too) or Apache Archiva.

That way, when we “clean install” the last checked in code for final delivery into the QA and deployment teams, we don’t run into crazy issues like having it not build because someone decided to take their code down – or had it taken down by force.

In a Netflix chaos monkey-like approach, try to foresee and forestall all causes for unreliability at go time, not only with this but any other kind of externalized source of services. You, your family, significant others, pillow, boss, co-workers and customers will all be happier for it.

Use LetsEncrypt

I’ve successfully updated my SSL certificate for this website, and automated the transaction as a result of the first repetition of the maneuver.

It’s a really nice way to keep your site secure, and it pushes you towards automating the renewals by having a relatively short certificate life span. Plus, it’s free.

Receiving the alert is very refreshing; I still had 19 days to renew my certificate, which would’ve given me plenty of chance to do it even if I’d not had a shellscript handy waiting only for a good chance to test it and schedule.

Keeping your client-server communications secure is a must-do; even if most of what I write here will eventually see the light of the day, much damage can be done to my image if the site was compromised; and this is just a personal website. If you have a website where clients log in and trust you their data, and for some reason you do not have secure connections enabled, do yourself a favor and fix that problem.

Notes on Java 8

Enum types are constructs which represent sets of known values. They are useful, but are something of a kludge in a way that reminds me of the String class shenanigans.

Enums types are declared like other composite types, like class or interface. They have their own keyword. Unsurprisingly, it is enum.

Now the use for them is clear: it avoids the need of having a load of “public static final” fields laying around, and gives them common functionality, like a “static T[] values()” which returns all the possible values, or a static “T valueOf(String)” which returns the value with a name matching the String parameter.

They can be used to build finite state machines, and can be used with the “switch” construct. They help avoid silly-in-hindsight but maybe-really-serious bugs by catching typos: all values must be declared, if a match was made with a String literal a typo would create a branch of never-used-code.

Another neat feat is that they can return their name as a String, and can be compared to each other – the order in which they’re declared determines which value is “first” and which is “last”.

Now, enums are actually classes with shenanigans added. Even though it’s never specified, an enum type is a class which extends from java.lang.Enum<E> and has some methods (which I suspect are injected at compile time, it would be nice to confirm by looking inside a .class file; for the record, clever use of reflections would make creating a generic method which is invoked for the special, shared functionality rather trivial)

As it’s a class, you can write other methods and declare variables in it.

But you can’t build an enum by hand – extending java.lang.Enum<E> is illegal. Even though it’s not final. Which is an annoying inconsistency and lack of elegance. Was it necessary to implement like this? It’s very likely, as there are many really smart people working on the Java language. It’s not pleasant, though.

Enums are treated like special citizens, and even have particular data structures and algorithms tuned to them (EnumSet and EnumMap); which further reminds me of the shenanigans that go on with the String class, what with special in-memory representation and all.

This are not bad things in and of themselves – the way that Enums and Strings break out of the pattern of the language; they don’t fit with the mental model that would arise out of studying the rest of the architecture, though, so care needs to be taken, that they won’t come back to bite you.

Argument for learning to develop with emacs

You may have read my thoughts on why people should learn to code with a good CLI environment at hand.

I’ll one-up myself – it’s good to have emacs at hand.

You have all the features of the shell – well, you have the shell itself, if you want to. But you have even more extensibility, because you have other aspects to work with than apps: you have text editing as a programmable activity.

So besides having and being able to easily create tools to work on data at one level (files), you have and can easily create tools to work on data at another level: content.

So, emacs is not necessarily the only environment which one-ups a good CLI, but it’s the one I know and I can get behind.

What’s so special having the content editing be programmable is a layer of power further from tweaking your environment and adding tools to your toolbox. This is like tweaking the toolbox, so that you can have some tools work better.

The effect is so strong that people who work with emacs often find themselves more and more working from within emacs. So you don’t have an environment from which you call the editor to do some work with. You have an editor from which you work, and as code is text, you have a powerful tool in which to build powerful tools to better build powerful tools.

This is highly desirable.

An argument for learning to code with CLI environments

There’s a difference between working in the command line and working in a desktop environment which I think is crucial to software developers’ formation.

When you’re working on a desktop environment, there’s a particular flow that shapes the way you interact with your programs and files: you’re working on a physical space, and to use your tools, you go to them, then get your data into them, use them, then get your data out, back into your desktop. For instance, if you want to take some data from a text document and perform numerical analysis on it, you’d go about it thus:

  • Go to the place where you launch programs from, and open an editor
    • browse for the document with the data
    • get the data out, presumably by copying it into your system’s analogy of a clipboard
  • Go to the place where you launch programs from, and open a spreadsheet program
    • paste the data
    • use the spreadsheet on it
    • store the resulting document where you want to do it

The important part here is that you go to the tool then get the data in the tool.

In the command line, it would be a little different.

You would point the relevant tool at the document, extract whatever data you need, and point another tool at the resulting documents if you still need it. It’s the difference between:

  • Navigate “Start menu -> programs -> accessories -> Notepad”
  • Navigate the menu “File -> Open”
  • browse for the document


  • Type “editor name_of_the_document” or “editor /path/to/the/document”, or in the worst case scenario, “/path/to/editor –option-or-options /path/to/document”

There are some workarounds to this situation, like having default applications being able to open a file, or right-click and selct “Open With…”; but those actions feel very ad-hoc.

Thus the command line feels more like you’re reaching for a tool and using it where you need it.

A consequence of this is that when you write an application for use in the command line environment, no matter how simple it is, it feels as if you’re changing your operating system to suit your needs. When you develop simple desktop applications, it feels as if you’re building environments to put your data into.

From this peculiarity of each environment stem patterns of use. Tool chaining and piping feel like “reach for this, apply on file/data, then reach for that and apply it on the results”, which helps you think about the whole process seamlessly. Building tools to put into a chain means that they could do only very simple things, and still be very useful. Thus are early developers encouraged.

Customizing the whole system… is very encouraging, of course, and having “commands” or “actions” at your disposal which you’ve built yourself, as opposed to having “containers” into which to put the data for work, is very empowering.

There may be some way of chaining programs in a desktop environment, or creating simple software in such a way that it feels like you’re changing the whole system. I have not encountered either.

The most powerful feelings around desktop environments I’ve done stem from manipulating the PATH variable and having some daemons doing fun stuff around the UI, the kind of stuff that would give you pause and wonder whether my computer’s behaving oddly or if you’re imagining things. Doing this in a command line environment is par for the course, but feels no less empowering.

I am not talking from nostalgia here – grew up using GUIs, not CLIs. Indeed, even though my first programs were CLI-based, as I was using them from a GUI, the feelings of changing my environment to suit my needs didn’t come along until I’d started deploying software in a Solaris environment and started automating things.

When I discovered the feeling of changing the PS1 variable, customizing the .bashrc or .profile, creating aliases… it was then that I started being prolific in my CLI-program writing for practical purposes. It seeped into my other operating systems / work environments; I routinely create a directory for shortcuts to the programs I run, I tend to run programs with the “Run” option of the OS I’m using (Win+R in widnows, Win + program name in Ubuntu, Ctrl+Alt+T and run the program from the shell in most other linuxes, Command+Spacebar + program name in MacOS), write UI gadgets or other empowering shenanigans.

I think that much of this would’ve started earlier if I’d had a powerful command line as a primary tool for using the computer at the time I started learning how to code. I don’t mean to disparage GUIs; I just think the kind of feeling delivered by a good CLI and the patterns of use they encourage can be of great importance when starting to code, enough to make it at least a great complement to GUI-based computer usage and software development practices at the time of learning.