Andy Crouch - Code, Technology & Obfuscation ...

Automate The Small Stuff

Photo: Unsplash - Franck V

Sometimes as part of your regular development process, you have tasks that you repeat a lot. Or you have long commands or groups of commands to run that need a lot of repeated typing. When working with teams I’m often surprised when they do not live by the mantra of “do it once manually, do it twice, automate it”.

Modern development environments need the use and knowledge of the command line (cli). This means it is easy to automate every repeatable task imaginable. When should you automate a task? When:

  • You do it more than twice.
  • You do it infrequently.
  • It requires multiple steps.
  • When it is easy to get wrong and where the result is not easily reverted.

As an example, I am currently working on a project that is using a lot of uuid’s. For testing and seeding purposes I am generating and pasting a lot of these. So I created the following call:

echo $(cat /proc/sys/kernel/random/uuid) | xclip -selection clipboard

This command generates a uuid and adds it to the clipboard. This means I can flick between my terminal and code and create and paste in a new uuid with only a couple of keystrokes. It means I do not have to use a browser-based generator or my mouse or anything else that takes me out of my flow.

(As an aside there are a variety of packages on Linux that will generate a uuid such as uuidgen. The above approach requires no extra packages. Instead, it uses the kernel’s random number generator.)

For short snippets such as the above, I create functions that I can call in my shell. Often in projects, there is a possibility to automate a project-specific task. In these instances, I always create a shell script. The script is checked in with the project so other team members can utilise them. I find it can be helpful to use action names with these scripts such as “hydrate-database”. I wouldn’t use a technology-specific term so that the implementation doesn’t matter. As an example, on my project, I have created and Although I have Knex installed globally, there is currently a bug which means that I have to use the project-specific version to generate files. So now I call:

$ ./ file_name

Instead of

$ ./node-modules/knex/.bin/knex migrate:make file_name

It may seem trivial but as your project grows it makes things easier. It also means that you don’t have to think too hard about tasks or perform repeated tasks that slow you down or break your concentration.

I’d love to hear about the ways in which you automate the small stuff so please contact me via twitter or email.

Everything Is Still Broken

Photo: Unsplash - chuttersnap

Happy New Year!

Or is it? I don’t want to start the new year with a negative post but the ongoing state of software is unsustainable. It is also unfair on paying users to expect them to put up with it. Products are being released that are unfit for purpose, insecure and unreliable. This is at a time when people more than ever have bought into the tech dream. They are sharing on social media and managing their life with a large number of apps. Everything from managing their shopping lists, consuming their entertainment to family planning.

And yet as an industry, we expect them to put up with terrible UI’s, bugs, breakages and security breaches. All the while we expect them to continue paying a subscription fee so we can build more features for them to endure. As users, we never ask for our subscription fee back if it goes wrong. Why? If you are paying for fine dining and your food was under or overcooked, you would complain. If you arrived on your holiday to find that your hotel was a building site, you would get your money back. So why are we happy to accept broken apps?

Scott Hanselman wrote a pice eight years ago called Everything is broken and nobody’s is upset. I will wait here for a moment while you go and read it.

How many of you can relate to what Scott outlined in that post? Not so much the actual software and services that were breaking. More the common thread that every app you try somehow has an issue or lets you down.

In a similar approach to that article, here are the stupid issues I have had to deal with this week:

  • Notion. On mobile takes three attempts to open and takes nearly a minute to load the first page. On any platform, it will not allow me to “Duplicate” a page with a lot of subpages. It tells me that the page is too big.
  • All 4 mobile app. It stopped playing every time it needed to play a commercial.
  • American Airlines Payment Page. I upgraded some seats and wanted to give them £300. Their payment page will only allow you to enter an American address. A preset state and required zip field blocked me from doing so.
  • Chromecast. It never streams a whole film without failing even though I am casting from a Pixel 3. It’s not just my phone either. My wife has a Moto G and my son an iPhone and they both suffer the same.
  • My Fitness Pal seems to show ads fine but when you are searching for foods to log it regularly causes the app to stop working.
  • Station. Adding many Google accounts doesn’t work. It looks like it has worked but it confuses the accounts when you try and switch between them. Also if you keep pages open to read later (their core USP) then say goodbye to your RAM. At one point this week it was eating 45% of mine.
  • Bluetooth. Four sets of headphones and one Android phone. Every time I turn on a pair they can not reconnect without repairing.
  • Visual Studio Code. On Manjaro, every time I try to use it after hibernation the UI breaks. I get random UI elements all over the screen and have to restart it.

I will stop now as I am boring myself.

So why have things not improved since Scott wrote his piece eight years ago? I am not alone in thinking about this. Nikita Prokopov recently published a great article on Software Disenchantment. In it, he talks about badly designed, slow, untested software. He also talks about why companies allow their products to go out in such an unfinished state. It’s a very worthy read.

As an industry we have some growing up to do. I can not think of another professional group of people that behave in this way.

We need to start by focusing on users. Every user is unique but we treat them as a defined standard. We give little thought to users that are older or who have disabilities or accessibility issues. Teams spend excessive time focusing on creating UX journeys that result in conversions. Few teams spend equal time on defining enjoyable experiences. Nor experiences that are enjoyable and seamless for all their users. User-centred design is key to a successful product. Great UX experiences will result in conversions.

We need to realise that while MVP’s are a perfectly good idea they need testing. A common thread in the startup mentality is that a developer can do everything. Build it quickly, release it and the users will come. We have seen this with the idea of Devops and it is not working as sold. Great developers write code and solve problems. Great testers ensure that what developers produce works and are fit for purpose. Great Infrastructure teams ensure it is working in an optimal fashion 99.9999% of the time. Teams need to have the right balance. It’s not right to expect one or two people to do it all.

The tools used for developing products need improvement. It is over 75 years since Plankalkül was designed. That’s a long time for such little progress. Languages and stacks today vary in quality and achievable productivity. They all still allow you to write code that results in basic errors. Why? Vast numbers of programs are CRUD based database front ends. Why is this not a solved problem? Why do we focus on disagreeing on the difference between language X and Y? Or the difference between object-oriented and functional programming? Let’s set about building a common framework of solid, risk-free tools that enable fast development of common functionality. Let’s also focus on making that framework work across the most common OS’s and hardware.

We are lucky enough to have some immensely intelligent minds within our industry. We also have a large number of people that do care about users and stability and experiences. Let’s embrace those people. They don’t want to slow down projects. They don’t want to prevent revenue generation. They want to be proud of the technology they build and they care what users think. Their knowledge, idea’s and passion will result in far more happy users and revenue as a result.

Think back to the last website or application that made you feel surprised or happy from using it? Now think about the experiences in the last few weeks that were negative. Is it not time to expect more of the former?

I am keen to hear your thoughts around the current state of affairs so please contact me via twitter or email.

2019 Retrospective

Photo: Unsplash - Denise Johnson

“So this is Christmas and what have you done?”

This is the last post I will write before Christmas as the end of the year has snuck up on me. As I have tried to in previous years I wanted to write a reflective post as 2019 has been a big year for me.

As far as this blog goes, I have managed to hit my target of writing a post a week. Apart from the week’s I have been travelling with the family I have posted every week. Looking back through the posts, I have not had the chance to share so much technical detail. A lot of posts have been brain dumps of thoughts of issues I had been dealing with. That summarises what I have been dealing with for two-thirds of the year. I plan to move back to writing more technical howtos and articles for 2020. I also need to promote the blog more.

I started the year wanting to work on some side projects I wanted to complete. Overhauling my .dotfiles, learning Elixir & Pheonix in more depth and some small FOSS apps were on the list. Sadly, I didn’t complete any of them in any detail as my time was dominated with my day to day roles. These are still relevant and I will carve some time out in early 2020 to pick these up so expect to see some posts on them. I did make a fulltime move to i3 and Manjaro as a daily driver and I couldn’t be happier. I should probably write more about that.

Leaving Open Energy Market was a big decision but the right one after 5 years. I do miss the awesome technical team I had there but I realise now that I was burntout. I had to walk away from the wider business. It has taken a few months but I am now fired up and thinking and working in a balanced and productive manner. Time and perspective have been great in helping me to see it was the right move.

Starting up my consultancy has been a massive step for me. I have been lucky enough to have had a steady stream of clients from the get-go. In 2020 I need to work on growing the brand and marketing our services. I also need to be harder with clients and ring-fence my time slightly better. I have a lot to learn in this space but it is so energising and inspiring to be working with such talented people in positive environments.

I was also lucky enough to get involved with Zinc this year as a fellow. Zinc is an organisation that aims to find solutions to the most important societal problems faced by the developed world. Their missions bring together researchers, specialists and founders which result in some unique companies that actually could address some of the more interesting and vital issues facing humanity. This is something I will write more about next year and is something I urge more people to get involved with. Again, meeting such passionate and energetic people, driven to really make the work a better place for everyone, has been inspiring on many levels.

On a personal level, the year has been mixed. We started the year learning how hard the impact of social media can be on teenagers. Supporting my son through a rough period was something I do not wish on any parent. It is not something I have written about but it has lead me to think hard about the value of social media and its impact on society. Once through that, we did get to finally travel to two places that we have always wanted to go. February saw us finally hit New York and be lucky enough to wander around Central Park in the snow. August saw us travel to Bali which was a stunning and beautiful experience.

So 2019 has been a mixed year but I feel I have come away from it a better person in a better position. I realise I am incredibly lucky to be able to say that and to have travelled and worked as I have this year. I am also incredibly lucky to be supported by my amazing wife and son. I am excited to head into 2020 and the new decade to see what they will bring. I hope everyone that reads this blog with any regularity has a great Holiday Season and that 2020 brings happiness to you all. I will be back on the 7th of January.

If you want to, please contact me via twitter or email.

Vim-Plug Plugin Manager

Photo: Unsplash - Steve Johnson

One of the projects I have been trying to do all year to overhaul my .dotfiles. I have a raft of customisations and settings that I have amassed over the years. Non more so than for Vim.

My .vimrc file is full of quick fixes and random solutions and settings. A lot I have forgotten about or are for plugins I no longer use or need. So as I am coding a lot more at the moment and living in the terminal I figured it was a great time to sort it out.

The first thing I have changed with my shiny new .vimrc is the plugin manager. I previously used Vundle and hook up plugins as git sub modules. A few years ago this was a great solution. But, managing git sub modules is more involved than it should be. After reading what the best option was right now for managing plugins I have opted for Vim-plug. This is a super simple plugin manager that removes the need for sub modules.

To install vim-plug you just need to download it and add it to your autoload directory. You can do this on Linux with the following command:

curl -fLo ~/.vim/autoload/plug.vim --create-dirs \

(Other OS’s are detailed on the projects Github page.)

You then need to add a section to your .vimrc file to define the plugins you want to manage. You define the plugins by adding a ling that starts with the word Plug followed by their Github repositories. An example will explain it better:

call plug#begin('~/.vim/plugged') 

Plug ''
Plug 'tpope/vim-eunuch'
Plug 'airblade/vim-gitgutter'

call plug#end()

As you can see you can use either the full url or the shorthand url for the plugin repo. Vim-plug also allows you to defer the loading of plugins and has many different features. The project has a good tutorial and lots of examples.

Once you have added a plugin to your configuration you can install the plugin using:


And if you decide to remove the plugin after trying it then delete the entry for the plugin in your .vimrc and run:


To update the plugins you have configured then just run:


That is all there is to it. It is super simple and easy. It is also really fast as it uses parallel downloads where possible.

If you have any good plugins to recommend for Vim please contact me via twitter or email.

Changing A Git Repository's Origin Settings

Photo: Unsplash - Luke Chesser

This week I completely managed to screw up some git settings for a project. I learnt that you can simply update the origin when using a service such as Gitlab/Github/Bitbucket. This can be useful as well if you are transferring code or repository ownership.

Firstly you need to see what remotes you have configured with:

my-test-project $ git remote -v

This will output a list of the configured remotes such as;

my-test-project $ git remote -v
origin (fetch)
origin (push)

There are two remotes configured based on where to fetch from and where to push to.

If you are not using ssh your output will almost certainly be based on https:

my-test-project $ git remote -v
origin (fetch)
origin (push)

To update the remotes you first remove the existing entry:

my-test-project $ git remote rm "remote_name"

So if the example we are using it would be:

my-test-project $ git remote rm origin

You can then add the new remote details using:

my-test-project $ git remote add "remote_name" "remote_path"

In our example that might look like:

my-test-project $ git remote add origin

Hopefully this is a helpful but if you have question please contact me via twitter or email.