I was looking for a spell check extension for VS Code to make writing this blog easier. After finding Code Spell Checker, I recommend it as a must have extension.

Once a spelling mistake is identified, you get the classic green squiggle, then Ctrl + . will bring up the spelling suggestions menu.

The extension has made writing in VS Code an awful lot easier. I didn’t look for a spell checker to make coding easier, but it has had that bonus side effect.

I’ve never really thought about spelling mistakes in code before. Obviously if I spot a spelling mistake I’ll fix it, but I’ve never really thought about the impact on speed of development. However, recently I’ve been doing a lot more work with Javascript. A couple of times already, Code Spell Checker has caught a misspelled variable name. Code Spell Checker will even catch spelling mistakes in camel cased names. With JS being dynamic, these spelling mistakes would have only been caught at run time and I would have had to track down the bug.

I’ve been building a React app recently that uses AWS Cognito for its authentication. Several of the components were using the same Auth logic to check if they should render or not.

To remove the duplication and keep my authentication logic in one place I created a Higher Order Component.

Signing in with AWS Cognito Javascript SDK

I wanted certain pages of my React application to be only reachable by authenticated users. For authentication I’m using Cognito from AWS along with the Amazon Cognito Identity SDK for JavaScript.

The AWS JS SDK makes it really easy to interact with Cognito from your JS application. Signing up users, verifying users’ emails, and signing in users are pretty straightforward but those are for blog posts for another day.

To check if a user is signed in, you create a user pool to get the current user. Then if there is a current user, get their current session.

var poolData = {
    UserPoolId: '', // your user pool id here
    ClientId: '' // your app client id here
};
var userPool = new AmazonCognitoIdentity.CognitoUserPool(poolData);
var cognitoUser = userPool.getCurrentUser();

if (cognitoUser != null) {
    cognitoUser.getSession((err, session) => {
        if (err) {
            console.log('error:', err.message || JSON.stringify(err));
            // redirect to sign in page
        }
        // handle authenticated user
    })
} else {
    // redirect to sign in page
}

This is pretty straightforward but you don’t want to be duplicating this code on every page that you want to check if a user is authentication on though. This is where Higher Order Components for React can help out.

Cross cutting concerns

Application requirements that are needed throughout an application but aren’t necessarily part of the main application are sometimes referred to as cross cutting concerns. Logging and security are good examples of cross cutting concerns.

Using the decorator pattern is a good way of dealing with cross cutting concerns. This allows you to keep your actual application logic clean while adding, potentially multiple, decorating pieces of functionality around it.

Higher Order Components

A Higher Order Component is like a higher order function in Javascript. It is a function that takes a component and returns a new component.

Acting just like the decorator pattern, a Higher Order Component can be used to add logic or cross cutting concerns to components while keeping the original component clean.

Creating a Higher Order Component

For my needs, a Higher Order Component will allow me to add my Cognito authentication logic to multiple page components cleanly. In the example below, the Cognito user check is in the componentDidMount function. If the user and session is valid, a boolean check in the state of the component is set to true. If the user check or the session doesn’t return successfully the component will redirect to the sign in page.

In the render function, it checks the loggedIn boolean in the state, then if true, it returns the component that was passed to the Higher Order Component.

import * as React from 'react'
import * as AmazonCognitoIdentity from 'amazon-cognito-identity-js'
import { withRouter } from 'react-router-dom'

const withAuth = Component => {
    class WithAuthUser extends React.Component {
        constructor(props) {
            super(props);

            this.state = {
                loggedIn: false,
            }

            this.onSession = this.onSession.bind(this)
        }

        onSession(err, session) {
            if (err) {
                console.log('error:', err.message || JSON.stringify(err));
                this.props.history.push('/signin')
            }
            this.setState({ loggedIn: true })
        }

        componentDidMount() {
            var poolData = {
                UserPoolId: '', // your user pool id here
                ClientId: '' // your app client id here
            };
            var userPool = new AmazonCognitoIdentity.CognitoUserPool(poolData);
            var cognitoUser = userPool.getCurrentUser();

            if (cognitoUser != null) {
                cognitoUser.getSession(this.onSession)
            } else {
                this.props.history.push('/signin')
            }
        }

        render() {
            if (this.state.loggedIn) {
                return (
                    <Component {...this.props} />
                );
            } else {
                return null
            }
        }
    }

    return withRouter(WithAuthUser)
}

export default withAuth

To use a Higher Order Component

To use a Higher Order Component you import the component like any other component;

import withAuth from './withAuth'

Then wrap it around the component you want to apply the decorating logic to;

const ExampleComponent = () => {
    <p>My component!</p>
}

export default withAuth(ExampleComponent)

For some more examples of Higher Order Components in React, you can check out the documentation for them here.

I think retros are great. I think the idea of reflecting on how the work is going and coming up with ideas for continuous improvement is awesome.

However, I find that running the same retro format every time can make retros lose their impact. They are at risk of the team just turning up and going through the motions.

What I hope to get out of a retro

My aim when I run a retro is to check in on how the team are feeling everything is progressing and to come out with an action to work on until the next retro. How many actions and what they look like is a topic for another day though.

The retro idea

I’m sure most people have come across the retro format of “stop, start, continue” or a theme close to it.

“Stop, start, continue” is an excellent format and I often run retros with this format. However, even with positive teams, I find a lot of people struggle to put anything in the continue column, and when they do they rarely vote to talk about those points.

I propose a retro format where the only category of talking points is “continue”. Hopefully this should force people to remember what went well since the last retro. Furthermore, if the positive points are the only talking points available, the discussion will have to be on them.

Extreme programming

I’ve been in a lot of retros where we capture positive points but when it comes to discussion time, some people believe “there is no point in taking about the positives”. I think this is wrong. Just because something is good, it doesn’t mean it can’t be even better. Or if it’s not nurtured, that positive may not happen again.

I really like the extreme programming idea of, if something is good, do more of it and take it to the extreme.

How to run it

Starting a retro with a check in activity can really help to make sure everyone is engaged with the meeting. A quick check in I like to run is, going around the room, everyone is to say how they felt about the last sprint in one word.

Then ask people to write down all the positive things since the last retro on post it notes. As many as they can in 10 minutes or so.

Once everyone ideas are down, ask people to stick them on the wall, while giving a very brief description of them. Getting people to group any tickets they have as they stick them up can be beneficial here.

To decide which points to talk about, dot voting can be very helpful. Each person gets three points to put on any tickets they want to talk about, all the on a single ticket of they prefer. Then the tickets with the most points is the topic of discussion.

It’s great to try and get some actions out of the discussion so the team is improving s little bit each retro. I’ll be covering how to capture and track to actions in another post.

Be positive

Hopefully by mixing up your retro formats it’ll help keep the team engaged and get the creative juices flowing to help come up with great actions.

Also, if the team is going through a bit of a tough patch, by focusing on the positives, it might help to avoid the retro from becoming a bit a moaning session.

Tired of opening multiple terminals to run processes? Then you should check out concurrently on npm!

What was my issue?

Recently I’ve been working a lot more with JavaScript. This has been great, I’m finding the js world a lot more mature recently.

I’m loving the tooling around JS. Particularly tools such as Parcel JS and good old Express.

However running multiple terminals for different processes was causing me a headache. When writing with others on a project, having to know multiple commands to run the development environment also creates a cognitive overhead that shouldn’t be there.

What is concurrently?

Concurrently to the rescue!

Concurrently is an npm package that allows you to run multiple commands concurrently. A very well named package this one.

How I used it

I’m never really a fan of installing packages globally, and I wanted to use concurrently via npm scripts so I installed it as a dev dependency.

npm install concurrently --save-dev

Then with the concurrently command you can pass multiple other commands at the same time, remembering to surround commands with quotes.

concurrently "my process" "my other process"

To add as a npm script, remember to escape the quotes

"start": "concurrently \"my process\" \"my other process\""

Other features

You can find the full documentation here

There are loads of options that look useful such as killing other processes of one dies and changing how the prefixing works.

However, since my original issue was to simplify starting a dev environment when working with others remotely, using wildcards to list commands to run looks great.

For example;

concurrently "npm:watch-*"

Anything that can speed up my development time is good by me, so go give concurrently a try.

As Javascript continues its march to world domination, it’s great to keep up with all of the new tools. However, if you are like me, then some of the build tools can be pretty daunting.

Webpack and Gulp are awesome and really do add a lot of value but I’ve found they can take a long time to setup and configure. So when I heard about Parcel I had to give it a go.

What is Parcel?

Parcel is a web application bundler that promises to be zero configuration and fast.

The zero configuration was the real draw for me. Build times are important in software development, but when you are measuring builds in seconds, the hours/days I’ve lost to other bundlers is more important to me.

Out of the box it supports a lot of the JS/front end world’s big names. SCSS, Typescript, Vue and more are all there.

It even has hot reloading just like create react app.

Setup

Setup is super easy.

Install Parccel globally

npm install -g parcel-bundler

Then run Parcel with your entry point, for example

parcel index.html

Simple.

Build

When it’s time to build your application, you just need the build flag;

parcel build index.html

This will place the built application in a folder called dist at the package.json level. I’ve not seen a way to change that, but I guess that’s the point of a zero configuration system.

The demo

If you are giving Parcel a try, one thing to keep in mind is that the simple example on the homepage doesn’t work out of the box.

I lost a bit of time to this but found a Github issue in the end. The Parcel homepage example is using postcss-modules, but Parcel doesn’t support that out of the box. It looks pretty easy to add, but it seems a strange choice to include it in the first example.

What’s next?

ParcelJS has massively impressed me. With a mountain of frameworks and tools I want to learn, I can see myself leaning on it quite a bit. For example, I really want to put some time in to Typescript and Parcel will mean I can spend more time in Typescript and less on seeting up the project and bundler.