Working well

I’m hoping that frequently working on smaller projects like some custom-built Docker images will help me get into good development habits. Things like maintaining a Change log, adhering to Semantic Versioning principles and working with git properly instead of just branching and merging can all very easily be overlooked for the sake of speed or at the hands of general laziness.

After some digging around and reading this afternoon, I’ve found a git semver plugin, remembered about change log generation and toyed around with Makefiles for tagging and releasing which I’ll hope to put to the test this week.

Go lighter, go faster

I’m aiming to write something every day this month but in actuality, I write things most days — just not here. Usually it’s work and code so most people won’t find it all that interesting; at least it should provide me with some material to write about.

I mentioned my attempts at shaving vital grams off my bikepacking gear yesterday. Today, I’m going to write about applying the same principle to the development workflow that I’ve switched to this year, namely Docker.

For the uninitiated, Docker is a way of packing the code you write into self-contained units. These containers are built on top of a base operating system and these can vary greatly in size.

I’m currently building my own suite of custom containers, configured for exactly how I like to work, starting with PHP-FPM, nginx, Redis and Postgres along with Node for running Gulp build tasks and the ELK stack (Elasticsearch, Logstash, and Kibana).

I have yet to deploy Docker to production, let alone be approaching implementing any form of continuous deployment practice but ultimately smaller containers will lead to faster deployment times and tighter feedback loops which are all good things.

Crumbs!

I was sure that I’d previously set out my thoughts on this matter but I can’t seem to find them anywhere. Therefore be advised that there follows something of a rant.

I despise the term “breadcrumb” when used in the realm of web design. As far as I can fathom, it was coined by Jakob Neilsen — he of the usable but terribly designed website — to describe the hierarchical indication of your location within a site structure. The term refers to the Grimm fairy tale Hansel and Gretel where the siblings left a trail of crumbs that they could follow in order to find their way back out of the forrest where their evil stepmother planned to abandon them.

All well and good. Apart from one thing: when Hansel and Gretel used breadcrumbs as a navigational aid, they got lost. It was only when they were using pebbles that they successfully escaped the maze of trees.

Metaphors aside, a trail of where you’ve been is not the purpose of the “breadcrumb” device. Returning to where you’ve been is the job of your browsers back button. The “breadcrumb” is supposed to indicate the ancestry of the current page — the category or section to which the page belongs.

What have I done?

No, this isn’t related to my impending fatherhood.

Being something of a mullet developer, you won’t really see anything of what I do day-to-day unless I make a mistake. Web designers and front-end developers have their portfolios to show off whereas we back-end developers tend to have little-to-nothing to show for our efforts.

To this end — and to serve as familiarisation with a distributed version control system — I’ve started taking an active interest in GitHub. My first repository contains several classes that together constitute my PHP Utility Belt: functions that I need to have easily to hand for most projects.

Getting the basics right

I almost missed this story about a how mistyped opening PHP tag exposed a bunch of Tumblr data. This wasn’t sensitive data like usernames and passwords but rather the slip revealed database-related information and private API keys related to the running of the site.

I was a little concerned with the misinformed comments in the article and the speculation as to the performance costs and overheads involved in parsing ini files. The fact remains that no matter where in your system you store your configuration files and what format you keep them in, they still need to be readable by your public-facing webpages to be of actual use. However, in this case simple, best practise methods would have mitigated the security lapse.

Keep sensitive details protected
Store your configuration files at a level above your web root so that they are inaccessible to a HTTP request if their location is revealed. If you don’t have access or permissions to write to a secure directory then protect your configuration with .htaccess — either denying access outright or by using a password, preferably using Digest authentication and not the weaker Basic method.

Never edit directly on the server
Some people persist with this practice despite the inherent issues. You’re using version control for a reason right? Deployment of files goes in one direction only: from development to staging and then to live.

Test your code before you put it live
You don’t have to have a full-featured test harness integrated into your deployment chain — running a quick check using the -l flag with the PHP command line binary should suffice.

This is obviously not an exhaustive list of best practices but, as the title of the post suggests, sticking to these points should be enough for you to avoid dropping a clanger.