Or, why I dislike squash merges. Tralfamadorians have the ability to experience reality in four dimensions; meaning, roughly, that they have total access to past, present, and future; they are able to perceive any point in time at will. Kurt Vonnegut The code usually tells you the what and sometimes the how. It doesn’t often delve into the why. That’s where the git commit messages come in. Squash merges tend to at worst eradicate them and at best jumble them into one single large commit message comprised of every squashed message.

I had a VPS on a popular developer-centric cloud platform. It started out life as Ubuntu 14, several years ago, and predates my learning about IaC, Terraform and Ansible. After starting work at a hosting company, I thought I may as well migrate my stuff over. And so, the headache of how to do so without forgetting anything began. I use it for my personal projects and there’s a lot of old stuff on there.

It wasn’t waterfall. It wasn’t scrum. It was both and it was neither and it was doomed to fail from the get-go. Once you’ve been doing this for a while, you’ll understand that pretty much every aspect of the discipline, at least in a professional setting, has a trade-off. To put it as simply as possible, we can’t have everything, we can’t do everything. At some point time, money, deadline pressure, prioritisation of other projects or one from a myriad of other concerns will cause us to have to make some tough decisions.

I was getting errors from Certbot invalid response from .well-known/acme-challenge It took a lot of messing around but the problem lay with a Cloudflare setting. SSL/TLS -> Edge Certificates -> Always Use HTTPS Redirect all requests with scheme “http” to “https”. This applies to all http requests to the zone. Certbot requests the verification over HTTP, as Cloudflare was rewriting it to HTTPs, it wouldn’t come through to where it had set up the temporary server in the Nginx plugin to serve the acme-challenge.

Businesses are usually around for longer than individual employees’ tenures. At some point, someone else has to take over your workload. If you have an owner mindset rather than a custodian mindset this is difficult. Handovers are not easy. Trying to cover all bases and think of everything you might need to get from someone during their notice period is going to result in at least some of their knowledge being lost.

Framework choices can be critical. The wrong choice is going to cause a big increase in the amount of technical debt a project has and can harm the onboarding process for new employees, which already carries a high opportunity cost. Problematic choices: Flavour of the month Too dated Custom All of the above carry a high chance that you won’t be able to find a new hire that knows the technology involved.

Opportunity costs are so often missed in a myriad of different areas. For software engineering we of course have them too. If you’ve not read The Mythical Man Month, you may have at least heard its central premise: Adding resources to a late software project makes it later Or perhaps more likely: 9 women can’t make a baby in 1 month When a resource is added to a project, someone from the existing team needs to take the new person under their wing and help them get up to speed.

I’ve seen some criticism of Git recently, on Twitter, with a ton of likes, suggesting a large amount of people have a difficult time using Git. Git is not that hard. It really isn’t. I think the problem stems from two main approaches. ### Problem the first: Shying away from the command line The command line reveals all but can be daunting for the beginner. I’d come from TortoiseSVN and then Kiln’s Mercurial equivalent before starting down the git-path.

I read the advice here some time ago, and I’ve been following it by and large. However, only recently I discovered how to enforce a line limit when git-commit starts up nano: ~/.gitconifg: [core] editor = nano -r 72 The problem is that doesn’t help limit the summary to 50 characters, which is what you need for log, shortlog, Github and general readability. I’ve now expanded this into a full replacement for git’s commit template.

Logging is an important thing to get right. It is a window into what’s happening in your application, right now and [x] days ago. Keeping a close eye on the error logs allows you to find bugs that users haven’t reported, or haven’t noticed. Doing logging right involves a few different strategies in conjunction with each other. # UTC All The Things (TM) Your server and application are both running UTC, right?