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.

I’ve been meaning to take a look at React Native for a while, but I’ve been pushing it back due to how good web apps are now.

However, the new year is bringing with it the urge to learn and make something new.

What is React Native

React Native is a framework for building native mobile applications using a single codebase. After working with mobile applications and trying to keep both an iOS and Android code base inline, the lure of just having one codebase to maintain is pretty strong.

What is Expo

Expo is a set of tools for helping to create React Native applications. With it being the suggested tool from React Native docs, it seems to be the best way to start and maintain a React Native application.

Not Git Bash!

Setting up the Expo CLI and getting your first application running is super easy. The instructions can be found here.

One piece of advice that had me stumped for a little while though; don’t use git bash! The expo init command doesn’t work with git bash, but it works just fine with cmd.

Testing on a phone

I’m far from an expert but I do have some experience with native Android development. Running your local application on a device feels a lot smoother than I remember Android Studio feeling.

By running ‘npm start’, Expo wil start up and give you a QR code to scan. Scanning this with the Expo client app will download the Javascript for your application.

This is so much quicker and easier than starting up Android Studio, enabling your device for debugging, and connecting physically.

Tunnel not LAN

Expo is really impressive when it comes to testing on a device, scan the QR code and you’re off.

However, it turns out it is not idiot proof. You can choose to access the app through your network or through tunneling. For a while I couldn’t get it to work through the LAN option on my network. But then I remembered that my router has two channels, it helps to have devices on the same network when trying to connect via the network I guess.

React Native Debugger

Another feature that really impressed me were the debugging capabilities.

Initially I assumed it would be easiest to debug the application with some text on screen, but React Native allows you to debug on your computer.

Shake your device to bring up the developer menu and select remote debugging to use the chrome developer tools. For other debugging options check out here.

First thoughts

React Native has massively impressed me. I’ve not gone deep in to it yet, I’ve not had to drop down in native code or anything, but if I needed to make a mobile application this would defintely be my starting point now.

My next big challenge though is to come up with an app idea to make my millions!

It’s been a while since I’ve written a blog post.

I’m not normally one for putting a lot of stock in to the new year. However, this year I’m excited for the year to come and learn new things.

GraphQL, AWS and agile processes are all things I’m aiming to further my knowledge in.

Good luck to everyone for 2019!