Forem: Martin Gaston

On avoiding getting distracted by squirrels

Martin Gaston — Sun, 19 Jan 2020 19:49:03 +0000

My master made me this collar. He is a good and smart master and he made me this collar so that I may tal--SQUIRREL! - Dug

At the start of 2019 I wrote a list of self-learning goals which I then proceeded to largely ignore and abandon for the year because other stuff got in the way. It's not that I wasn't spending time working on learning some skills, it's more that I was getting distracted by little bits all of the time.

To contextualise this, consider Redux; you've got to do a bit of Redux work on a codebase. Perhaps start with Dan Abramov's quintessential Egghead course, but then you've got to move on to all the middleware because the internet says so. So you've gone through Redux Sagas, or Thunks, or a weird mix of both of them in the case of one codebase I was working last year. Then you ship some shabby Redux, so then you've just got to read up on design patterns and architecture for peace of mind. Someone will mention Elm, which is worth looking into. And then someone who is trying to be helpful will tell you not to bother because of React Hooks, which is great advice other than the fact you really do have to use Redux anyway because the codebase you are already working on is using it.

This is all well and good, but what if learning all of that context around Redux doesn't actually progress you any further to the goals you're looking to pursue? It all feels a bit, well, unstructured. While I'm sure there's plenty of benefit from doing such things, in the short-term maybe you've ended up over-investing in areas you don't particularly need right now. These are all squirrels.

A relatively common bit of advice I've heard and read is that you should focus your learning time on starting and finishing actual projects, and I think there's some sound logic to that. Outside of the other benefits of actually getting something done, which might also lead to something down the line, it also gives you an educational tether. Once you've invested a couple of months in building an awesome Django project it's perhaps more likely that you'll continue forward with it, rather than dipping your toes into any number of web frameworks - which I often find quite tempting. I am really good at starting a bunch of projects and much less accomplished at finishing them.

The internet is a magnificent tool and there is an embarrassment of riches when it comes to affordable courses, tutorials and guides, but actually working out how to navigate a path through all of it can be massively challenging.

I'd love to learn more about understand and map out a full pedagogic journey, but that's a problem for another day - right now I actually need to do some deeper (rather than wider) learning.

With that in mind, these are the resources I'm looking to go through in 2020:

Objection! Let's play with primitives in JavaScript

Martin Gaston — Fri, 02 Aug 2019 14:53:22 +0000

I like to spend lazy weekends eating my body weight in Pringles, playing videogames and also really digging into some of the fundamentals of programming languages to get an appreciation for what's going on. I've been fascinated by methods and primitives in JavaScript lately, spurred on as I look to branch out a deeper understanding of standard data types in both object-oriented and functional patterns.

While you certainly don't need to worry about a lot of this - it's really something the language largely abstracts away from you behind its individual implementation - it's nice to get a sense of what's going on.

I'm going to be using JavaScript for most of this, but also with little cameos from Ruby and Elixir, though you certainly don't need to know either of those languages.

Let's play with some JavaScript:

const foo = 'foo'
typeof foo
// 'string'

Consider the humble string, a proper salt of the earth, workhorse of data type. Strings are model citizens. They work hard all day and don't ask questions, and as long as they've got enough cash left over to take the family on a couple of holidays a year they're pretty contented.

Over on the fields of JavaScript, a string is one of its six primitives, which are kind of like the language's Infinity Stones - string, number, boolean, undefined, null and symbol. Primitives in JavaScript are immutable, although can be replaced by other primitives with assignment. Primitives are lightweight, like the delicious Total 0% of data types, and don't have methods or properties - or the extra processing needs that come with them.

Wait a second, woah woah woah thank you very much, how come you can do this then?

foo.toUpperCase() // "FOO"
foo.length // 3

Well, with the exception of undefined and null, each primitive also has a complementary primitive wrapper object that, perhaps unsurprisingly, wraps around it - so that'sString, Number, Boolean and Symbol.

When you're as smart as Kyle Simpson (❤️) you can actually dig deep into what's going on under the hood, but essentially the String object (which still has its own constructor) will create an object - so not a primitive - around a given string primitive, which is still accessible with the valueOf method. This, I believe, is also loosely analogous to the implementation of primitives in Java, but I'm certainly no expert there: the most I know about Java is the FizzBuzz Enterprise Edition.

const bar = new String("bar")
typeof bar // 'object'
typeof bar.valueOf() // 'string'
bar.valueOf() === "bar" // true
bar === "bar" // false

Now, JavaScript will also handle this wrapping (also commonly called boxing or autoboxing) automatically when you attempt to access a method or property on a primitive, and then immediately following its evaluation it will automatically fling this new, temporary, single-use object off to the garbage collector.

const hello = "Hello!" // variable bound to string primitive
hello.shout = hello.valueOf().toUpperCase().concat("!!!!!") // create a String wrapper object and add a shout method, which is evaluated immediately and is then sent to the garbage collector
// "HELLO!!!!!"
hello.shout // creates a NEW String wrapper object, where shout doesn't exist, so returns undefined

Alas, poor String! I knew him.

You should also never ever EVER (probably) use these constructors in real-life, as even though it might make sense that creating these objects manually - especially for repetitive loops and the like - would be more efficient, the reverse is actually true. Implementations of JavaScript have worked out how to use the single-use wrapped objects way more effectively, which is a peculiar mishmash of timesaving and functionality that makes JavaScript such a hot and cold pleasure to deal with.

const { performance } = require('perf_hooks') // only needed for Node

function test_string(str, desc) {
  const t0 = performance.now()
  for (let i = 0; i < 10000000; i++) {
    str.length
    str.toLowerCase()
  }
  const t1 = performance.now()
  console.log(`${desc} took ${(t1 - t0) / 1000} seconds`)
}

test_string("Hello", "Wrapped string primitive");
test_string(new String("Hello"), "Instantiated String object");

// Wrapped string primitive took 0.011956994999200105 seconds
// Instantiated String object took 1.9173262799978257 seconds

Let's put JavaScript to one side and take a look at some other implementations. How's our little foo doing over in the ancient zen gardens of Ruby?

foo = 'foo'
foo.class # String
foo.class.ancestors # [String, Comparable, Object, Kernel, BasicObject]

In Ruby, all data is represented by objects. This helps Ruby become an elegant object orientated language, and Ruby coders to easily unwind in the evening without having to decompress out these particular day terrors. "Ruby follows the influence of the Smalltalk language by giving methods and instance variables to all of its types", says the language itself.

By tracing the String object through its ancestors, we see that it - and every object in Ruby - inherits from BasicObject.

magic_number = 3
magic_number.class.ancestors # [Integer, Numeric, Comparable, Object, Kernel, BasicObject]

So, all data types in Ruby are objects, and there's no wrapping/autoboxing going on behind the scenes, and even the JavaScript-style concept of primitives is non-existent.

Because everything starts life as an object, this means you can reopen a class and add your own methods, which I am legally required to tell you can be pretty dangerous: you should always always always make sure you ensure your code is maintainable and sticking your snout into the standard library is a great way to cause a total meltdown in real life. With that said, it's still pretty cool.

class String
  def shout
    self.upcase << "!!!!!"
  end
end

"hello".shout
# "HELLO!!!!!"

Elsewhere, in more functional languages, the concepts of objects and classes is usually a distant memory - so accessing methods directly on your data types is a no-no. If we follow our venerable foo over to Elixir, we can see that instead of accessing properties and methods we're now passing our data types as parameters to functions in the String module.

foo = "foo"
is_bitstring(foo) # true
String.upcase(foo) # "FOO"
String.length(foo) # 3

This is just a brief stop in Elixir, but it's great to see that our foo is doing well, even though we can barely recognise them from those early JavaScript days - they just grow up so fast!

Understanding the Java Classpath: Building a Project Manually

Martin Gaston — Sat, 27 Jul 2019 10:37:40 +0000

This is the second post in a series looking to understand Java projects. Earlier, we looked at how Java actually gets installed onto a macOS system, and now we're going to build a basic app. Then we'll move on to incorporating the same app with help from Gradle, a popular build tool, and we'll finish by incorporating our project into the IntelliJ IDE.

Our directory structure

We're going to be compiling a totally jazzed up version of Hello World, and our overblown example will make use of packages, libraries and tests because it's a more indicative of a project we'd spot in the wild. This project is intended for people who have worked a little with Java and isn't going to dwell much on syntax outside of tooling.

We'll be loosely following the conventions of the Maven standard directory layout, which is admittedly a little overkill for our tiny app - but we're also going to charge ahead with it because it's indicative of the conventions we'll commonly run into when working with Java. Here's how that looks:

.
├── bin
├── lib
│   ├── jfiglet-0.0.8.jar
│   └── junit-platform-console-standalone-1.4.2.jar
└── src
    ├── main
    │   └── java
    │       └── space
    │           └── gaston
    │               ├── greeter
    │               │   └── Greeter.java
    │               ├── helloWorld
    │               │   └── HelloWorld.java
    │               └── textEffects
    │                   └── Bubble.java
    └── test
        └── java
            └── space
                └── gaston
                    ├── greeter
                    │   └── GreeterTest.java
                    └── textEffects
                        └── BubbleTest.java

Let's unpack what we've got here:

bin will contain our compiled .class files
lib will hold our third-party libraries. In this case we're using JFiglet and the JUnit test runner, which we'll get back to later.
src will house our .java source code. Within src you have subdirectories main and test , which both have a java subdirectory to denote the language, and then the standard Java package hierarchy. Eventually, after months of digging, you finally stumble upon our actual .java files.

Just a quick caveat: I haven't checked the lib folder into Git so you'll need to grab the JFiglet and JUnit .jar files from Maven if you're looking to build this project yourself. This is, partially, to expose how fiddly it is to manage dependencies manually and help us understand how, later on, how awesome it is that other tools can come to our rescue.

.java, .class and .jar

Okay, so I threw around quite a few filetypes just then. I think it's entirely common to be hidden from a lot of these specifics by our IDE, so here's a quick summary of what each of those types does:

A .java file is a plain-text file of human-readable Java source code - though admittedly that 'readable' designation is, ahem, rather debatable when it comes to certain aspects of Java syntax. Basically, .java files are the files we squishy human flesh monsters sling our code in.
A .class file is compiled Java bytecode that can be executed by the Java Virtual Machine, an admittedly snazzy tool which runs our Java programs. These cold, mechanical files are the ones the computer likes read.
A .jar file is an archive of .class files (and other necessary resources) all neatly zipped up for convenience.

javac and java

Two of our JDK binaries are responsible for compiling and running our code: javac and java. In short, javac is responsible for turning our .java files into .class files that java can run.

If we put together a totally barebones HelloWorld.java, we can then feed it as an argument to javac and run it with java:

public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Oh no, not another Hello World example...");
  }
}

Without multiple .java files, external libraries or output directories to worry about, compiling and running this is as straightforward as sending the file path to javac and then running the output:

$ javac HelloWorld.java
$ java HelloWorld
Oh no, not another Hello World example...

Notice how the .class file will be currently be compiled into the same directory as its companion source code, and that we call the HelloWorld class directly with java with no .class extension - the latter would trigger a dreaded java.lang.ClassNotFoundException error, but that's a story for another day. It turns out we use java to run Java classes, not Java .class files.

Classpath

Another potential error we might see right about now is a java.lang.NoClassDefFoundError, which usually comes about because there's a .class file that was created at compile time (with javac) but has got lost somewhere when we're trying to run it with java.

Be warned to those of a fragile constitution, the next word is enough to give you the vapours. This frightful concept has dashed the hopes and dreams of event the strongest minds, adventurer. Abandon all hope all ye who enter... the classpath.

Let's zoom in our our main .java files:

.
├── greeter
│   └── Greeter.java
├── helloWorld
│   └── HelloWorld.java
└── textEffects
    └── Bubble.java

Our Greeter.java, HelloWorld.java and Bubble.java are all being stored in different packages (which, in Java, also means different directories) and have requirements of their own. HelloWorld includes both a Greeter and a Bubble, with Bubble itself an adapter to the third-party FigletFont class from the JFiglet .jar in our lib folder.

Over in our test folder we've got tests for Greeter and Bubble, which includes classes from JUnit in lib as well as requiring the actual Greeter and Bubble classes to test.

Welcome, friends, to dependencies.

Java, while pretty smart, needs to know where to go sniffing for all these requirements - hence the classpath. We can get the scoop right from the horse's mouth:

The default value of the class path is ".", meaning that only the current directory is searched. Specifying either the CLASSPATH variable or the -cp command line switch overrides this value.

Also:

Setting the CLASSPATH can be tricky and should be performed with care.

Which is just charming. Essentially, our classpath needs to contain the path to our .jar files to the top of our package hierarchies. It can be set either via environment variable, which you shouldn't do, or with the much better option of the -cp flag.

It also helps explain a common Java gotcha, where you try and run java without cd'ing into the directory first.

$ java bin.space.gaston.helloworld.HelloWorld
Error: Could not find or load main class bin.space.gaston.helloworld.HelloWorld
Caused by: java.lang.NoClassDefFoundError: space/gaston/helloworld/HelloWorld (wrong name: bin/space/gaston/helloworld/HelloWorld)

bin, you see, isn't part of the Java package hierarchy, but does need to be on the classpath if you're outside of the folder. So both of the below would work:

$ cd bin
$ java space.gaston.helloworld.HelloWorld

$ java -cp bin space.gaston.helloworld.HelloWorld

Bringing it all together

With all that in mind, we can start to compile our files into the bin directory. From the top of our project directory, we can get to work.

1. Compiling our `main` folder:

$ javac -d bin -cp lib/jfiglet-0.0.8.jar src/main/java/space/gaston/greeter/Greeter.java src/main/java/space/gaston/helloWorld/HelloWorld.java src/main/java/space/gaston/textEffects/Bubble.java

We're now using the -d flag to specify where our compiled files should end up. We're manually feeding each of our .java files to javac, so we don't need to add them to the classpath, but we do need to add our JFiglet .jar file so that Bubble can compile.

2. Compiling our `test` folder:

$ javac -d bin -cp lib/junit-platform-console-standalone-1.4.2.jar:lib/jfiglet-0.0.8.jar src/main/java/space/gaston/textEffects/Bubble.java src/test/java/space/gaston/textEffects/BubbleTest.java src/main/java/space/gaston/greeter/Greeter.java src/test/java/space/gaston/greeter/GreeterTest.java

We need to add both the JFiglet and JUnit .jar files to our classpath, and now we've also got to feed in each test file and the file its testing to the compiler. We could effectively consolidate steps 1 and 2, but it's good to break them up for demonstration purposes here as I think it helps illustrate what's going on.

Our bin file will now look like this - notice that the directory structure of our .class files must maintain the same package hierarchy as the .java source files:

.
├── BubbleTests.class
├── GreeterTests.class
└── space
    └── gaston
        ├── greeter
        │   └── Greeter.class
        ├── helloworld
        │   └── HelloWorld.class
        └── textEffects
            └── Bubble.class

3. Running our tests:

$ java -jar lib/junit-platform-console-standalone-1.4.2.jar -cp bin:lib/jfiglet-0.0.8.jar --scan-class-path

╷
├─ JUnit Jupiter ✔
│  ├─ BubbleTests ✔
│  │  └─ helloReturnsAsciiHello() ✔
│  └─ GreeterTests ✔
│     ├─ greetWithArgumentSteveReturnsHelloSteve() ✔
│     └─ greetWithNoArgsReturnsHelloWorld() ✔
└─ JUnit Vintage ✔

Our version of JUnit can be run on the command line. We're passing in the --scan-class-path flag to automatically have JUnit look for all tests on our classpath, so this requires adding the bin folder to the classpath (because we're at the top of our project folder) as well as JFiglet, which is still required by Bubble.

Also, yay, the tests pass.

4. Running our main app:

$ java -cp bin:lib/jfiglet-0.0.8.jar space.gaston.helloworld.HelloWorld

  _   _          _   _             ____    _
 | | | |   ___  | | | |   ___     / ___|  | |_    ___  __   __   ___
 | |_| |  / _ \ | | | |  / _ \    \___ \  | __|  / _ \ \ \ / /  / _ \
 |  _  | |  __/ | | | | | (_) |    ___) | | |_  |  __/  \ V /  |  __/
 |_| |_|  \___| |_| |_|  \___/    |____/   \__|  \___|   \_/    \___|

No, I have no idea either why we tasked it to output 'Hello Steve'.

So, great. We've got that working. But, gosh, wasn't that a bit much for even a simple, totally contrived application? Can you imagine that literally every time you make a change to the app and need to recompile? I don't know about you, but if I had to work like that for over a week I'd be permanently stuck looking like I was cosplaying Edvard Munch's The Scream.

In the next post, the cavalry will march in to bail us out of a lifetime of perpetual build horror.

Has this post been useful for you? I'd really appreciate any comments and feedback on whether there's anything that could be made clearer or explained better. I'd also massively appreciate any corrections!

Draw the Rest of the F**king Owl: Approaching Software Design as a Beginner

Martin Gaston — Fri, 19 Jul 2019 15:31:29 +0000

I've always found the discussions around software design some of the most intimidating aspects of programming. With the best of intentions, I still flinch a little when I hear the phrase design pattern. I think one of the reasons for all the fervent dogma around this aspect of software design is how one size doesn't fit all, and even with all these so-called best practices at the end of the day it's a human problem. Albeit one we try to act like we can definitely solve with methodologies. The way you structure a project in your mind, while potentially being enormously successful in your own practice, might not be anywhere near the most productive way for somebody else.

Yay for individualism! But this can be anathema in an office, where projects are precisely timed, judged and turned into lots of whizzy graphs to show off at various and endless important meetings. We also want our efforts to be reproducible, and the overall processes to be largely understood so we can effectively estimate against it. Stop crushing my free spirit, The Man! Boo!

But wait, it's not all doom and one-day agile development workshop coaches. We do need a common shared context of information for communicating with other developers. One of the trickiest parts of getting started in any specialised field, in my opinion, is growing the knowledge and confidence to articulate your thoughts. When I started with pair programming at a coding bootcamp, I found frustration easily crept in between the gaps of knowledge and communication: many of us knew where to start solving a problem, but found it extremely difficult with how to discuss it. I still regularly find myself resorting to muttering about 'that thingy' or doing 'some stuff' with the 'whatsit'.

Developing this internal monologue - in my mind, reader, I am Jane Austen and my code is a novel - is as useful for your own personal code development as it is for working in a team. For instance, I recently realised my first few steps in design as a software developer could be neatly summed up by this meme:

I knew where I was (two circles) and I knew where I wanted to end up (the owl), but I'd be royally danged if I could think of literally anything that could help get me to move between steps 1 and 2. So I'd just sit there, trapped in my own analysis paralysis until someone else came along and helped push me along the path. I was often mentally blocked in a world where everything was either a thingy, a whatsit or a finished owl.

TDD - wait! come back! I'm not going to try and sell you an eBook or offer any agile coaching services! - is often prescribed as a tidy cure to this ailment. As a fan of the classics, I've recently started reading an endearingly dog-eared copy of Kent Beck's Test Driven Development by Example and it's done a really good job of helping me actually break through this barrier from time to time.

There's plenty of sage advice within the book (I'd say it's definitely worth picking up a copy), but the key benefit I've been able to extract from it, with the way my my works, is in making my feedback loops shorter - reaching for the little change and starting to build the mountain of my application from many, many molehills.

Beck frequently reminds us not to jump ahead too far - I think the book helps demonstrate a framework for thinking more than anything else, and frequent reminders to maintain an active todo list is a useful guides for practising pacing and scope. He also reminds us there's no point in being too dogmatic about everything: if there's an obvious implementation, then just write it. Keeping a todo list also encourages me to doodle more, which occasionally helps me figure out my next steps. And that's super cool!

Here's the exact moment I realised, on a slightly grim-coloured, off-brand Post-it® note, how HTTP server responses are kind of numbered in the order you might process the request, which blew my mind:

Once we start with a failing test, and then make it run, Beck introduces three strategies to start progressing towards making our code work the way we want it to:

Fake it: Return a constant and gradually replace constants with variables until you have a fully-baked implementation.
Use Obvious Implementation: Just type in the real implementation.
Triangulation: The most conservative strategy, where we only start to generalise our code when there are two or more examples. This helps to eke towards the right path if you're getting lost on your design, which I frequently am.

Right now, I like to consciously think about which one of these strategies I'm employing and really actively think about it.

Something else I really liked about the book is that it helped me think more about the rhythm of development - speeding up and slowing down as appropriate. I've always been accidentally partial to a bit of speed archaeology, which helps me blaze ahead in the first few hours but quickly creates more problems than it solves.

The other thing I like about working like this - short, intentional steps - is how it's an incremental approach. Trying to memorise two dozen complicated design patterns and the exact right time of when to use them is both exhausting and overly intimidating. So most of the time I try and guide myself with a far simpler set of strategies, and then I can reach for a design pattern when I get a sense that my code is missing a certain... something.

Finally, one of the biggest challenges about your approach to design is that it doesn't sit still. These things ebb and flow regardless of matter how many Gang of Four patterns you've had tattooed across your back. When I started developing in React I couldn't even get half-way through Googling my problem before someone was telling me about a presentational or container component, and now Dan Abramov has updated his blog post on the pattern to include the following caveat:

I wrote this article a long time ago and my views have since evolved. In particular, I don’t suggest splitting your components like this anymore. If you find it natural in your codebase, this pattern can be handy. But I’ve seen it enforced without any necessity and with almost dogmatic fervor far too many times. The main reason I found it useful was because it let me separate complex stateful logic from other aspects of the component. Hooks let me do the same thing without an arbitrary division. This text is left intact for historical reasons but don’t take it too seriously.

Partially related: reading Dan Abramov's blog is a wonderfully humbling experience which brings frequent joy into my life.

Trying to separate out my sense of intimidation from design with some real-life approaches is what worked for me, but the frustrating beauty of it all is that it might not work for anyone else. If it feels painfully new to you, like it does with me, I'd recommend just trying a bunch of stuff out. When you start to find those methods which resonate with you, eventually you realise you're actually drawing the owl.

Has this post been useful for you? I'd really appreciate any comments and feedback on whether there's anything that could be made clearer or explained better.

Just My Type: Rolling a fresh TypeScript project with Jest, ESLint and Prettier in 2019

Martin Gaston — Sat, 06 Jul 2019 18:19:03 +0000

TypeScript's motto is that it's JavaScript that scales, and one area where that's definitely true is in the extra work you have to do in order to spin up a project. Ba-dum! The time investment isn't so bad when you're setting up something you'll be working across for months on end, but when you're looking to just spin up a repo to learn, experiment or solve a few katas it can be a bit of a fiddle to get everything up and running over and over and over again. I just want that beautiful static typing 😭

If you'd like to just skip all the setup and get stuck in, you can find this starter template on GitHub.

Install Dependencies

Get ready to install this hearty wedge of dependencies. I'm using npm:

$ npm init -y && npm i -D jest typescript ts-jest @types/jest eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin prettier eslint-plugin-prettier eslint-config-prettier

TypeScript's own getting started requests a global installation, but I like to avoid these whenever possible. We'll throw in a script to get access to the TypeScript compiler, tsc, elsewhere in our config.

Add Configuration

1. `package.json`

Outside of the standard npm init -y template, nip into your package.json and add a couple of updates to your scripts to easily get access to our test runner and the TypeScript compiler.

  "scripts": {
    "test": "jest",
    "tsc": "tsc"
  },

2. `jest.config.js`

We're using ts-jest with our project so we can feast on TypeScript's type checking directly from Jest. A quick little $ npx ts-jest config:init will produce the below:

module.exports = {
  preset: 'ts-jest',
  testEnvironment: 'node',
};

3. `tsconfig.json`

By default, the TypeScript compiler can produce a hefty configuration file - it's got really informative comments so it helps the output not get too overwhelming. You can build one by running $ npm run tsc -- --init, and the options below are how I like to have mine setup right now:

{
  "compilerOptions": {
    "target": "ES2015",                       
    "module": "commonjs",                     
    "outDir": "build",                        
    "rootDir": "src",
    "strict": true,
    "esModuleInterop": true
  },
  "exclude": [
    "node_modules",
    "test"
  ]
}

4. `.eslintrc.js` and `.pretterrc`

As of the start of this year, the TypeScript team formally adopted ESLint as the linter de rigueur of the TypeScript space.

If you're interested, the typescript-eslint team talk about the inherent challenge of parsing TypeScript and ESLint together in their repo. It's a pretty fascinating topic!

Wedging ESLint together with Prettier - my favourite code formatter - and TypeScript is probably the most involved step. The brief overview is that we configure ESLint to disregard the rules that Prettier is concerned with, then roll Prettier in with our linter so they can run together as a single step.

We also need to point our ESLint config to our tsconfig.json file and set up a few other options, such as the sourceType and ecmaVersion settings.

Here's how that looks:

.eslintrc.js

module.exports = {
  parser: '@typescript-eslint/parser',
  plugins: ['@typescript-eslint'],
  extends: [
    'plugin:@typescript-eslint/recommended',
    'plugin:prettier/recommended',
    'prettier/@typescript-eslint',
  ],
  parserOptions: {
    project: './tsconfig.json',
    ecmaVersion: 2018,
    sourceType: 'module',
  },
  rules: {
    // Special ESLint rules or overrides go here.
  },
}

Over in .prettierrc I just like to pop in my preferred options:

.prettierrc

trailingComma: "es5"
tabWidth: 2
semi: false
singleQuote: true

And now we've got the one-two combo of ESLint and Prettier helping sure our code looks swell and operates properly. We're ready to actually write some code!

Hello World!

I like to separate out code in a src directory, with tests in test. So a quick $ mkdir src test will set that up, and our previous steps will have TypeScript transpile everything in our src directory to a JavaScript build directory when we npm run tsc.

But to really make check everything is working, it's time for a quintessential rite of passage:

test/sayHello.test.ts

import sayHello from '../src/sayHello'

test('sayHello can greet a user', (): void => {
  const user = { name: 'TypeScript' }
  expect(sayHello(user)).toBe('Hello TypeScript!')
})

And then to make that pass (and to check it's all working) we can throw in some of our fancy TypeScript features:

src/sayHello.ts

interface User {
  name: string
}

const sayHello = (user: User): string => `Hello ${user.name}!`

export default sayHello

$ npm test

 PASS  test/sayHello.test.ts
  ✓ sayHello can greet a user (4ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        1.206s
Ran all test suites.

Fantastic! We've created a fine little environment for playing with TypeScript.

And, just to make sure we haven't set up any conflicting rules in our ESLint config, we can run a quick check:

$ ./node_modules/.bin/eslint --print-config src/sayHello.ts | ./node_modules/.bin/eslint-config-prettier-check
> No rules that are unnecessary or conflict with Prettier were found.

TypeScript is a really fun language to work in, but getting into a place where you can run the config quickly makes it far more pleasurable to get started. Feel free to share your own tips and tricks of configuring your TypeScript environment - I'm still learning the language myself, so would love to know how other people like to setup their repos!

Bonus 1: Add a Git Hook

One really neat part about the JavaScript ecosystem is that husky and lint-staged make it incredibly straightforward to run our linters and test suites as we're committing directly to git, wrapping us in another comfy blanket of consistent, tested code. While it's possible to get these up and running without introducing another pair of dependencies in our project, I think the time saved is absolutely worth it.

If you run $ npm i -D lint-staged husky these features are just a quick addition to our package.json away. Smoosh the below options somewhere within the file:

{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{ts,js,tsx,jsx}": ["eslint --fix", "jest --coverage --findRelatedTests", "git add"]
  }
 }

Now, when we git commit our files we'll automatically run our linter and any tests that directly relate to what's in our staging area.

Bonus 2: VS Code Settings

I find people who use VS Code generally have excellent taste, but I tend to flick between it and Vim depending on whether I'm settling down for a while or just nipping in to a file to make a couple of tweaks. VS Code is prepared to do a lot of our heavy lifting, but as we've already configured so much elsewhere it's worth letting VS Code know it can ease off a bit.

First, grab the ES Lint extension for VS Code. Then add the below to your settings.json:

"eslint.autoFixOnSave": true,
"eslint.validate": [
    {
        "language": "javascript",
        "autoFix": true
    },
    {
        "language": "typescript",
        "autoFix": true
    },
    {
        "language": "javascriptreact",
        "autoFix": true
    },
    {
        "language": "typescriptreact",
        "autoFix": true
    }
],
"eslint.alwaysShowStatus": true,
"editor.formatOnSave": true,
"[typescript], [javascript]": {
    "editor.formatOnSave": false
}

This tells both VS Code to take a break and ESLint to stop lounging around and do some work when it comes to JavaScript and TypeScript, and now our linting config should dutifully kick in and autoformat whenever we save. Neat!

The Life-Changing Magic of Refactoring

Martin Gaston — Fri, 05 Jul 2019 22:12:51 +0000

There's a drawer underneath my desk I use to store all the little bits and bobs I randomly accrue, rarely use but don't really feel like getting rid of. But the contents of this drawer also have a naughty habit of escaping this space, then promptly spreading around my desk, office and eventually the rest of the flat.

In a perfect universe I'd find a way to efficiently store all this junk. Still, there's no need to be too dogmatic about it. This is the real world. Sometimes you've just got to cram half the contents of your living room into a cupboard because you've got guests coming over.

In our coding lives, this is called refactoring: applying small changes to our code in order to spruce up our design without changing the core functionality. Still, refactoring? I find the word a little cold, almost mathematical - it gives me feelings of a scholarly, scientific process. I think it sounds precise and clinical and, well, like it's absolutely no fun whatsoever. It feels like work.

There are fantastic reasons why many smart people have helped create a common language around code smells and refactoring patterns, of course, and it's not just so that you can try to look smart when you write blog posts. Having shared conventions means you can discuss them in teams, and a common rubric for communicating these ebbs and flows of moving code around creates the comforting dependability of a context. I am incredibly glad the discourse around software design exists, that the software engineers of today can stand on the shoulders of giants and I dream of being able to make even a fraction of the positive impact of these luminaries.

Sometimes, though, all these raw smarts can be a bit of a drag. With so many formal and complicated-sounding names, even approaching a discussion about a refactoring pattern can be intimidating for new programmers. Then they're often explained with some too-good-to-be-true examples that are hard to contextualise within your current work, which has always left me reeling - how do I apply that beautiful pattern to my actual code? I also think it's really hard to see why you should use a refactoring pattern until you've been stung by it. I'm intimated into sheer indecision.

But, really, refactoring is just doing a bit of tidying up. It's deciding to do the dishes before you're down to your last big plate, or making sure you've loaded the dishwasher before bed so you don't have to deal with it in the morning.

I'm terrible at examples, so let me pluck out quite literally what I'm working on as I write this. I was rushing to implement a feature to pass a test (if Java can find an "app.port' System Property then a server will bind to that port number) and threw in the below:

public static void main(String[] args) throws IOException {
    Connection connection;  
    if(System.getProperty("app.port") == null) {
        connection = new Connection();
    } else {
        int port = Integer.parseInt(System.getProperty("app.port")); 
        connection = new Connection(port)
    }  
    Server app = new Server(connection);  
    app.start();  
}

The tests pass. Awesome. I won't pretend that 75% of me wasn't super ready to just git commit and go for lunch. But no! There was time for a spot of cleaning.

So, first - I don't like doing anything in main other than setting up classes, so I felt like extracting most of the if statement would make the code easier to read for Future Me.

public static void main(String[] args) throws IOException {
    var connection = makeConnection();
    var app = new Server(connection);
    app.start();
}

Sure, that's just moving code around. But chunking our code down into smaller functions usually has the side-effect of making our work easier to test, maintain and extend. Now, my next step was to make all that boolean logic a little more expressive and more communicative of our intent.

private makeConnection() throws IOException { 
    if (hasSpecifiedPort()) {  
        int port = getPort();  
        return new Connection(port);  
    }   

    return new Connection();
}

private static int getPort() {  
    return Integer.parseInt(System.getProperty("app.port"));  
}  

private static boolean portIsSpecified() {  
    return !Objects.isNull(System.getProperty("app.port"));  
}

We've just extracted something in our extraction! Wow. Achingly meta. But now makeConnection doesn't really have to worry about what Java System Property we're fishing for, or the specifics on obtaining it. It simply... gets on with it.

Our if statement has also been tweaked to just bail early if it matches. That's a little refactoring I really enjoy because it gets us out of our braces, which - as someone mid-way through Invisalign right now - is a good thing indeed.

That's only a couple of simple steps, and if I'm being honest IntelliJ did most of the work there. But after doing just a couple of little steps, I was ready to git commit. Then I had a sandwich. It was delicious, thank you.

"Wait", you might be thinking. "Don't you have any more extravagant examples of, say, refactoring an Elixir module using Structs and Protocols to achieve polymorphism?" you plead, teary-eyed, coincidentally thinking about the immediate last project I was working on. "Please," you beg, "aren't there some more complicated patterns you could apply?"

And, well, sure. There's plenty of example of those, most of which are birthed from the tome of Refactoring. Yet I argue that, sometimes, that's not the point. Especially when deadlines, project managers and the need for lunch breaks come into play. We should celebrate each of our little wins, not worry too much about how a few dozen of those wins makes for a fascinating example of before and after.

I'd say it's always worth doing the little nips and tucks we can achieve today rather than trying to train ourselves to do the bigger, meatier, more interesting refactorings we promise we'll do tomorrow - a tomorrow that, if we're being honest, might never happen.

Refactoring is a broad church, but I think it's worth remembering how it always comes down to just taking that one item off that chair in your house you use for piling stuff onto; the one that you tell yourself is just being used to hold that pile of books temporarily.

The little changes? That's how we spark joy.

Getting Started With a Java Environment on macOS

Martin Gaston — Fri, 28 Jun 2019 16:32:33 +0000

Alright, real talk: I finished my first Java project as a like, totally professhional developer without having much of a clue about, well, anything to do with the Java build/tooling ecosystem. I pressed enough buttons in IntelliJ for things to run, and (thankfully) they ran, and I spent the rest of the project perpetually swaddled within IntelliJ's gentle embrace.

Winging it? Nah, I call it falling with style.

Basically, I found comprehending Java tooling seriously perplexing. So before kicking off my second Java project I wanted to forge a better understanding of just what the heck was going on.

Over the course of a few posts we're going to learn a little more about how Java is installed on our local machine before building a straightforward (and only somewhat contrived) Hello World application, making use of external libraries and multiple files so we can make some sense of a standard Java directory structure and how to build our application from the command line. Then we'll move on to incorporating the same app with help from Gradle, a popular build tool, and we'll finish by incorporating our project into the IntelliJ IDE. At the end of this series we should all have a much more comfortable knowledge of what goes on under the hood of all our tooling, and way more confidence to tinker with our project builds.

First steps: the absolute basics. Time for a forensic journey. The first time I quickly fudged my way through installing OpenJDK 12 and I can't even tell you how I did it. Downloading OpenJDK, as far as I can tell, gives you a directory of unloved binaries which virtually zero guidance on what you're supposed to do with them. I felt like ~~Ted Danson~~ Steve Guttenberg in Three Men and a Baby.

**tl;dr:* copy the uncompressed OpenJDK directory - e.g. jdk-12.jdk - into /Library/Java/JavaVirtualMachines/ and you'll be good.*

But whyyyy? Let's unmangle that.

Caveat: this is specific to macOS right now. Linux and Windows will inevitably be different, and likely have a swathe of gremlins of their very own.

Where is Java actually installed?

Strap in, because descending through an installation of Java is like staring Cthulhu in the face for a fortnight. Descending into its heart of darkness is a guarantee that you're going to end up as Kurtz. You've been warned.

Let's start at the top:

$ java --version
openjdk 12 2019-03-19
OpenJDK Runtime Environment (build 12+33)
OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)

And then we can peek inside our java.home system property from within jshell.

jshell> System.getProperty("java.home")
$1 ==> "/Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home"

Alright, cool. We've got Java installed. It's the latest version, and it's blissfully not the Oracle JDK. Things are looking rosy. So presumably our shell will point to our java.home directory?

$ which java
/usr/bin/java

OK. But that file is 74 bytes, which if you ask me a tell-tale sign a symbolic link. This ain't our first rodeo!

$ greadlink -f $(which java)
/System/Library/Frameworks/JavaVM.framework/Versions/A/Commands/java

Well, that's new. And if we have a peep within the JavaVM.framework directory we can see all our familiar Java files.

$ ls -lh /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/ | grep "java"
-rwxr-xr-x  1 root  wheel    57K 21 Mar 06:07 java
-rwxr-xr-x  1 root  wheel    74K 21 Mar 06:07 java_home
-rwxr-xr-x  1 root  wheel    57K 21 Mar 06:07 javac
-rwxr-xr-x  1 root  wheel    57K 21 Mar 06:07 javadoc
-rwxr-xr-x  1 root  wheel    57K 21 Mar 06:07 javah
-rwxr-xr-x  1 root  wheel    57K 21 Mar 06:07 javap
-rwxr-xr-x  1 root  wheel    57K 21 Mar 06:07 javapackager
-rwxr-xr-x  1 root  wheel    56K 21 Mar 06:07 javaws

These aren't symbolic links, so that's good. Things still don't seem to be lining up, mind. But a little more digging on Stack Overflow suggests these are stub applications which determine the version of the JVM to use. Have you ever seen anything like that before? Because I haven't.

Some more internet trawling reveals java_home, which according to its man page:

returns a path suitable for setting the JAVA_HOME environment variable. It determines this path from the user's enabled and preferred JVMs in the Java Preferences application. Additional constraints may be provided to filter the list of JVMs available. By default, if no constraints match the available list of JVMs, the default order is used. The path is printed to standard output.

Only I'm fairly sure Apple removed the Java Preferences application yonks ago, but no matter. Did they just sort of half-remove the Java support from the OS, keeping us lightly tethered to an unloved, unmaintained ghost in the machine? That's an open question: I have no idea. I only know we wouldn't be Java developers if we cared for such consistencies. Let's just boot it up.

$ /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home

Alright! Fantastic. We finally got to /Library/Java/JavaVirtualMachines. I've only lost part of my sanity, so I'll take this as a win. java_home seems to prioritise more recent versions of the JDK by default, so if you've got 12 installed it will supersede 11 when you run java, javac, jshell and the like. You can look at all your currently installed versions with the -V (capitalised) flag.

$ /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
    12, x86_64: "OpenJDK 12"    /Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home
    11, x86_64: "OpenJDK 11"    /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home

Meanwhile, the -v (lower case) flag will return the path to said JVM, which can then be set as the JAVA_HOME environment variable. JAVA_HOME, when set, takes precedence over the default ordering of /usr/libexec/java_home.

$ export JAVA_HOME=$(/usr/libexec/java_home -v 11)
$ java --version
openjdk 11 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

Want to relive the halcyon days of JDK 1.6? Go right ahead. Have a blast. No, I'm OK - I'll stick around here, cheers. Of course, running the export command in your shell will only last the lifetime of that shell instance. For a more permanent solution you'll need to nip into your .bashrc/.zshrc or equivalent.

I'm assuming that the default choices of /usr/libexec/java_home mirror what happens when you run one of the stub applications in /System/Library/Frameworks/JavaVM.framework/. Or, you might have spotted that there was also a java_home binary in the JavaVM.framework directory earlier. Wait a second...

$ greadlink -f /usr/libexec/java_home
/System/Library/Frameworks/JavaVM.framework/Versions/A/Commands/java_home

Look, I did warn you that it would be messy. But at least now we know a lot more about how Java is running on our system!

In the next post we'll start looking at the challenges of compiling and running our first Java application. I'll update this post with a link when it's live!

Understanding Java Objects, Abstract and Concrete

Martin Gaston — Fri, 17 May 2019 13:46:02 +0000

I've been working a lot in Java lately, but only when my project required me to adopt some of the famous object-oriented design patterns did I realise how totally unsure I was of what was going on at a fundamental level, so I found it a real challenge to keep up with all the terminology. I felt like I had hit a brick wall.

I decided to invest some time in unpacking some of those building blocks - so let's blow the doors off some of this Java jargon. I'm hoping that if you've ever felt in a similar position that these notes might be able to help further your own understanding of Java's sprawl.

Java Jargon #1: Creating Objects

In Java, almost everything is an object - such as String, ArrayList and HashMap. Objects are created from classes. Think of your class code as an instruction manual for Java to produce an object.

Creating an object requires creating an instance of a class - so the phrase instantiating a class is often used by people who want to sound especially smart. But you can use both terms interchangeably, depending on who you're talking to or if you're trying to win a game of Scrabble.

To formally create an object/instantiate a class, which is to say what we have to do in order to stop the compiler from going full on Mr Resetti at us, we follow a three-step process: declaration, instantiation and initialisation.

Declaration is achieved by specifying the type and the name of a variable, so we could tell Java Dragon viserion;, which would get everything prepped and primed to accept a Dragon type. But at this point our object is currently closer to my checking account than a fearsome dragon: it's empty. Nothing in it. Zip, nada, nill or, specifically, null.

Always watch out for null. If I had kids, I wouldn't like to see them hanging around with null.

For the record: Java also has both primitive and reference variables, which we can wave our hands at now but can potentially create some additional bother every now and then, generally when it comes to assignment and comparison. But, hey, we're programming in Java so it's probably safe to assume we're all kind of into a spot of bother every now and then.

Anyway, we're ready for steps 2 and 3 - instantiation and initialisation, which like to rock up as a pair:

viserion = new Dragon();

The new operator instantiates the class, allocating the required memory behind the scenes and then returning a reference (the address) of that memory so our viserion variable knows where to send anyone who comes knocking. Calling new also requires a call to a constructor, which is where the parenthesis enter the scene. The () part handles initialisation, which goes sniffing out a class constructor that matches the signature and finally gets our object fully setup and ready to come out.

Constructors in a Java class have the same name as the class and no return type. If we take a look at our Dragon class we can see that it has two constructor signatures: one which can respond to a zero-argument constructor, which will in turn call our two-argument constructor that requires a Stomach and Mouth argument with defaults.

public class Dragon {
  private Stomach stomach;
  private Mouth mouth;

  public Dragon() {
    this(new BigStomach(), new BigMouth());
  }

  public Dragon(Stomach stomach, Mouth mouth) {
    this.stomach = stomach;
    this.mouth = mouth;
  }

  public eat(Food food) {
    mouth.consume(food);
    stomach.digest(food);
  }

  public dracarys(Target target) {
    return mouth.breatheFire(target);
  }
}

Constructors are mandatory for classes, but if one isn't explicitly defined then the compiler will treat the class to a zero-argument default constructor totally free of charge.

We've also split declaration and instantiation/initialisation of viserion across two lines, which isn't necessary - we can also declare all of our assignment on a single line if we'd like. We don't even need to assign our objects to variables, either, and can instead use them directly in an expression. Let's bring all of that together and create another Dragon:

Dragon drogon = new Dragon(new GiantStomach(), new GiantMouth());

We're declaring a reference variable drogon, instantiating our Dragon class with new and then initialising it with our constructor which responds to the Stomach and Mouth signature. We're also instantiating two new objects, GiantStomach and GiantMouth, directly in our constructor call.

Now, how about a real example? Look at how ArrayList features three constructor signatures in the Java source code:

// Constructs an empty list with the specified initial capacity.
public ArrayList(int initialCapacity) {
  if (initialCapacity > 0) {
    this.elementData = new Object[initialCapacity];
  } else if (initialCapacity == 0) {
    this.elementData = EMPTY_ELEMENTDATA;
  } else {
    throw new IllegalArgumentException("Illegal Capacity: "+ initialCapacity);
  }
}

// Constructs an empty list with an initial capacity of ten.
public ArrayList() {
  this.elementData = DEFAULTCAPACITY_EMPTY_ELEMENTDATA;
}

// Constructs a list containing the elements of the specified collection, in the order they are returned by the collection's iterator.
public ArrayList(Collection<? extends E> c) {
  elementData = c.toArray();
  if ((size = elementData.length) != 0) {
    if (elementData.getClass() != Object[].class)
      elementData = Arrays.copyOf(elementData, size, Object[].class);
  } else {
    this.elementData = EMPTY_ELEMENTDATA;
  }
}

Yikes, that was quite a lot to take in. Consider it work on the foundations. If you're anything like me, you often know this stuff without actually, you know, knowing it, so it's nice to have a refresher.

Java Jargon #2: Concrete Classes

This word pops up all over the place and I've found you're supposed to know what it means by default. For the record, I didn't really know what it meant for months.

To summarise it in a sentence, a concrete class is any class you can create (instantiate) with the new keyword. Concrete classes have all of their methods implemented, regardless of however many interfaces they implement or classes they extend.

There's no specific language keywords needed when it comes to making something concrete, but you'll probably see the word pop-up a lot in UML diagrams and people shooting the breeze about object-oriented programming, so it's nice to know what's going on so you can take part in the conversation.

Our Dragon class is bona fide, 100% certified concrete, which is totally easy to do when you're not using anything abstract. I find it easier to think of classes as concrete by default and only really in terms of concrete and abstract when using either inheritance (via extends) and interfaces (via implements).

Java Jargon #3: Interfaces

If a concrete class is an instruction manual, an interface is a blueprint - it's a list of unimplemented method signatures that, by stating we will implement the interface, our class is pledging to support. When a class opts to implement an interface, this is often said to be a contract - because the class that's implementing is essentially promising to include these methods.

Not fulfilling an Interface contract will also have the compiler visit you in the dead of night, provided you're compiling your code at night. It won't be happy about it.

A Java class can implement many interfaces, as you can see with ArrayList:

public class ArrayList<E> extends AbstractList<E>
        implements List<E>, RandomAccess, Cloneable, java.io.Serializable {

You'll spot a lot of the '-able' interfaces when you work in Java - here we can see Cloneable and Serializable, and you'll see these pop up time and time again, but for now we'll focus on List. Notice how List uses the interface keyword instead of class:

public interface List<E> {
    int size();
    boolean isEmpty();
    //... there's plenty more empty methods

Neither size() nor isEmpty() are implemented in this interface. We couldn't create a List object from this interface with the new keyword, which is why it's not a concrete class. But, by implementing List, ArrayList pledges to follow the contract and ensure it knows how to respond when sent requests for any of the interface method signatures.

Interfaces are like a little bow tie for some of your classes - they add a neat degree of formality, which the type checker respects. You can use interface names as the type for your reference variables, too, which means any class implementing that interface will be allowed to be assigned to it.

Java Jargon #4: Abstract Classes

Abstract classes can have both implemented and unimplemented methods, but they're not concrete because they can't create an object with the new keyword. However, subclasses can use the extends keyword to inherit their functionality.

Many of Java's List collections inherit from the abstract class AbstractList:

// AbstractList.java
public abstract class AbstractList<E> {
  //...
  public boolean add(E e) {
    add(size(), e);
    return true;
  }

  public abstract E get(int index);

Notice the abstract keyword used to denote both an abstract class and an abstract method: use of the latter requires declaration of the former. Also notice how the abstract method get lacks braces and features a semicolon, similar to the way we declared our interface methods earlier.

ArrayList is a subclass of AbstractList, and so has to implement a get method but will inherit the add method:

// ArrayList.java
public class ArrayList<E> extends AbstractList<E>
        implements List<E>, RandomAccess, Cloneable, java.io.Serializable {
  // ...
  public E get(int index) {
    Objects.checkIndex(index, size);
    return elementData(index);
  }

If ArrayList did not implement its own get method while extending AbstractList it would have to declare its class abstract in order to satiate the compiler, which would mean it could not create objects using the new keyword and would also be unable to reach that much-desired concrete status.

Wrapping Up

We've taken a look at what makes a concrete and abstract class in Java, which meant familiarising ourself with how classes are instantiated. We moved from a simple example Dragon class to looking at some slices of source code from JDK 12, taking a look at how ArrayList extends AbstractList and implements ArrayList.

Understanding these building blocks creates a massively useful foundation for getting to grips with the strict object-oriented nature some of Java's most prominent design patterns.

Where's my inheritance? Understanding the Liskov Substitution Principle

Martin Gaston — Sun, 12 May 2019 09:20:50 +0000

What's the Liskov Substitution Principle? In the SOLID team, Liskov must have been subbed on more times than Olivier Giroud during his Arsenal tenure. In all seriousness, Barbara Liskov is a totally awesome pioneer of computer science whose Wikipedia page is well worth a read.

The design principle, essentially, specifies that a subclass should be substitutable for its superclass. Let's stop right there just to clarify some of that jargon:

Superclass: The parent class (object) being inherited from.
Subclass: The child class receiving (via the extends keyword) the inheritance.

Yeah, we're talking about inheritance. Now, you probably do what I do when you hear the word inheritance: format your computer and run for the hills. It's the safest way.

Inheritance is powerful, sure. Having easy, natural access to all those Array and String methods in JavaScript is great. Getting all that functionality from descending from Object in Ruby is pretty awesome. I'm usually pretty delighted to use inheritance when it's baked into the language spec. But maybe it's also too powerful, like the Hulk, and when it loses control it smashes up your application and breaks your heart. I don't think we should always avoid inheritance, but I do think being nervous around it is a healthy, survivalist instinct. It's fire.

To illustrate the situation, let's totally violate the Liskov Substitution Principle. Let's create tests for a prominent and respectable business tycoon, who can give interviews and work for their enormous fortune. Then let's build a quick class to pass our contrived example.

liskov.test.js

const Liskov = require("./liskov");

describe("Tycoon", () => {
  const tycoon = new Liskov.Tycoon();
  it("Gives Long Interviews To Big Newspapers", () => {
    expect(tycoon.interview()).toBeTruthy();
  });

  it("Goes to work for their fortune", () => {
    expect(tycoon.work()).toBeTruthy();
  });
});

liskov.js

class Tycoon {
  constructor() {
    // initialisation
  }

  work() {
    return true;
  }

  interview() {
    return true;
  }
}

Awesome! What an impressive display of industrious capitalism. Now let's create a child Socialite class of our Tycoon, who should be able to neatly get swapped in to any instance we might want to use our Tycoon to do glamorous interviews or enterprising work.

class Socialite extends Tycoon {
  constructor() {
    // initialisation
    super();
  }

  work() {
    throw new Error("Sounds horrible");
  }

  interview() {
    return true;
  }
}

Drat. Our industry, the backbone of our economy, will totally collapse if we try and swap in our Socialite class!

We're inheriting our classes, then, but their intended behaviour is all different even though they can often look the same. Commonly, inheritance is used to refer to IS-A relationships that can inherit via (language permitting) class or interface. Academically it can boil down to the Square/Rectangle problem, and in real life in can be neatly distilled to everything breaking two minutes before you were due to go home for the day.

Violating the Liskov Substitution Principle is great way to realize how the real-world concept of objects doesn't directly map to object oriented programing, which totally kind of scared me when I first realised it as it would totally undo some of those contrived 'intro to OOP' examples, rife with analogy, we're so used to seeing.

In its place within the SOLID principles, Liskov Substitution sits quite happily alongside the Open/Closed Principle, which states that a class should be closed for modification - in short, we should override the original class to add new functionality to our application. Our fancy new subclasses can bring additional functionality to the party, but they'll still be able to hit all of the same notes as the classes they're descending from.

It's always worth remembering not to over-engineer ourselves, though, and not to add the complexity of these patterns until they're needed to scale our application further. Together, and used in the appropriate situations, the Liskov Substitution Principle is another design pattern that can help us plan for the inevitability of change in our applications as they grow.