tech

Use Makefiles to quickly run common commands

14th May 2018 by Ben Leave a Comment

A tip I picked up from work is the use of a Makefile to set up short aliases for commands you run often, but that are a pain to type, or you can’t remember. I find this particularly useful as I code fairly intermittently these days, so it’s easy to forget the exact syntax of certain commands.

A good example is how to run unit tests. This varies from project to project, but is something you’ll probably want to do fairly often.

To start, create a blank file called “Makefile” and put it at the root of your project. Then insert the following code:

[code]
SHELL:=/bin/bash

unit-test:
[TAB]./vendor/bin/phpunit
[/code]

Change /bin/bash to the location of Bash, and modify the ./vendor/bin/phpunit line to do whatever you’d normally type in to run your unit tests.

You’ll need to replace [TAB] with a Tab character. Spaces won’t work. Make is strict in this regard.

Save and exit the file. Now open a Terminal, go to the root of your project, and type:

$ make unit-test

All being well, this will run your unit tests.

In the Makefile, “unit-test:” indicates the label you’ll need to run after “make” to run the command. You can add multiple lines and multiple labels – for instance:

[code]
echo-ab:
[TAB]echo ‘A’
[TAB]echo ‘B’

echo-cd:
[TAB]echo ‘C’
[TAB]echo ‘D’
[/code]

If you have lots of commands, this method can get a bit messy. It’s handy for small projects where you only have a few things to include but can’t always remember them.

Always be shipping

26th August 2017 by Ben Leave a Comment

Building software is fun.

It’s great to develop something from nothing, or extend something to do more than it did before.

I think coders want to build things the best way they can. But in practice, that doesn’t always happen. Shortcuts can be taken, perhaps due to time pressures, or major requirements popping up late into a piece of work. Sometimes, you need to make changes to software that are quite different to what it was built for to begin with.

But software changes, and we can’t always anticipate how it’s going to change. In fact, we probably shouldn’t worry too much about how it might change in ways we simply don’t know about yet. (It’s a bit different if it’s your product, such as a hobby project, and you know some of what you’ll be adding later – and can build for those things accordingly.)

Perfect code

We shouldn’t be aiming for perfect code. Equally, we shouldn’t be happy with crappy code, but that’s not the point here.

Delivery – shipping a product or feature – is vital. It doesn’t matter how beautiful your code is if you never ship.

It definitely matters if you build a mess of a system that will be painful to work with in the future. But we shouldn’t be agonising over making everything perfect before anything is shipped.

I know there are developers who will find some of my code from years ago and say “what was he thinking?!” And to be honest, if I read it today I’d probably think something similar. I’m sure I could think of ways to improve the code I worked on back then that I didn’t think of at the time.

But the important thing is that the code shipped, we could monitor how things went in production, and we could get stuck into other projects.

Continuous improvement

Continuous improvement is a wonderful thing. Some of my favourite projects have been framework migrations. I’ve migrated from a proprietary framework to Zend v1; I’ve migrated from a basic home-grown set of PHP classes to an MVC framework; I’ve managed a migration from Drupal to Laravel. More recently, I’ve worked with a team who have been migrating from a FuelPHP monolith to a service-oriented architecture.

With large-scale migrations or any major refactoring, breaking off components of the application and migrating them piece by piece is an excellent way to minimise risk, keep momentum going, and avoid a seemingly infinite end date. The concept of “dropping” a massive new upgrade on a given date for an entire customer base is extremely risky, and runs the risk of being rolled back if it all goes pear-shaped.

Testing

There’s a phrase I have in my head at all times as a reminder of why “big bang” launches are so dangerous:

It is difficult to know when testing is complete.

Testing is not something you start and finish. Testing is an ongoing process, a discipline, that can incorporate a selection of the following at various times:

Automated unit tests
Automated integration tests
Manual exploratory tests
Manual functional tests
Manual or automated regression tests
Manual UI tests
Non-functional tests (a large category)

Testing helps to highlight everything from catastrophic failures to tiny UX quirks. But having tests doesn’t mean your big bang implementation will be fine – especially in a big, complex system.

Scrum

In Scrum, the output of a sprint is a potentially shippable product increment. Whether you ship or not is up to you. But the point is that you can ship if you want to. This capability should be available to the Product Owner.

When a development team thinks they have 6-12 months, or years, to deliver a project (or maybe there’s no end date at all), it’s can be very tricky to keep the team focused. Agile accepts that requirements change frequently. This in itself is not an instant issue. However, when you have a long-running project that isn’t shipping anything, and constantly changing requirements, especially when development is already in progress – that’s a recipe for disaster.

Always be shipping

There’s a lot of different things I’ve discussed in this post, but it boils down to one simple thing. Always be shipping.

Stop adding a day here and there to perfect something that already works fine (and has unit tests that pass).

Start getting stuff out the door.

How to minimise CRUD front-end code duplication in Laravel 5.4 / Twig

20th July 2017 by Ben Leave a Comment

CRUD (Create/Read/Update/Delete) is something that developers do quite a bit of. Frameworks can help with this, but there’s still a fair amount of code you’ll need to write for every CRUD screen you put together.

One particular area is the difference between Create and Update. For many of the projects I’ve worked on, Create and Update are often very similar. They aren’t identical, but if there’s enough overlap between them, you can minimise duplicate code with the following setup.

How to display errors in Laravel 5.4 with Twig / TwigBridge

11th July 2017 by Ben Leave a Comment

As Laravel ships with Blade, the Laravel manual gives templating examples in Blade.

For displaying basic variables in a Twig template, it’s pretty simple:

[code language=”html”]
{{ title }}
[/code]

However, it takes slightly more effort to display form validation errors.

Why I custom code my personal sites

25th September 2016 by Ben Leave a Comment

The static route

When I built my first website, I wrote all of the HTML by hand. At that point, it was just HTML. It was annoying to replicate the navigation bar across every page, even though I only had a few pages to update.

I tried a few different methods, such as using frames, and adding the common code via Javascript. I also tried reducing the number of pages on the site that I needed to update, by adding a dropdown and opening some of the pages in a new window, sans navbar. The Javascript method stayed on the site for quite a while.