General

The first DrupalCamp in England was held this weekend (1st March 2025) in Cambridge. I drove down on the Friday with Chris Maiden to attend (and speak!) at the event.

We arrived early at the event and and started the day with a much needed coffee (or two) and started chatting with the other attendees.

The opening session was a keynote from Baddý Sonja Breidert, who talked about AI, the success of Drupal and the Drupal CMS system, and about the success of the Drupal community. 

I've been thinking about this article for a while but it is only recently that I have been able to sit down and really have a think about it properly. Or at least collate all of my thoughts into a single article.

Over the last couple of years the term "AI" has become a sort of marketing term that is banded about (and abused) by all sorts of companies with the intent of trying to make life easier.

In this article we will define the term AI in the context of programming, look at some services that you can use to produce code, and go through some pros and cons of using AI systems to code.

After installing the RTL-SDR on my Clockwork uConsole (running a Raspberry Pi CM4) I was looking for something to try out the device to see what it could do. The GNU Radio Companion is still a bit baffling at the moment so I was searching for something with a lower barrier to entry.

One thing that caught my eye was a project on GitHub called dump1090. This is a "Mode S" decoder that uses the RTL-SDR to decode transponder information from Aircraft. Whilst the package is quite old now, it is still being minimally maintained. The dependencies are quite small and so it tends to compiles quite nicely without too many additional packages or issues, event on the limited hardware of the CM4.

DrupalCamp Scotland returned after a small hiatus of 5 years on the 25th October 2024 and saw nearly 50 people attend the university of Edinburgh Paterson's Land building for a day of talks and sessions. I had the honor of being invited to speak at the conference, which was the first physical speaking session I've had since 2019.

I arrived early to the conference on a sunny Friday morning after driving up the night before. After a cup of coffee and a lovely chat with a few people we started the conference.

I was reminded recently about how a GitLab engineer managed to delete the prod database, and that got me thinking about one of my biggest (production) mistakes.

It's been at least 5 years since this happened so I think it's safe to tell the story of when I dropped a production database of one of my clients.

At the time I was working on a (pretty large) Drupal website for an international organization. The site consisted of an extensive content area and allowed users to make anonymous purchases through the website, which were sent to a CRM every night. It was hosted on the Acquia platform and used BLT to perform the day-to-day development operations on the site.

A development environment is an essential part of any web development project. It allows the website to be run outside of the production environment so that features or bugs can be worked on without disruption to the live website.

I've used local development environments to build websites for a number of years and I have striven to adhere to a set of rules that make life easier. These rules aren't a rigid set of requirements, but following them can make life easier for everyone on the development team. I have seen developers spend many hours with broken local development environments that could have been better spent actually working on the project.

I started to put together these rules after I inherited a website project from another company. This website came with the requirement of using a certain local development stack, which was required for the hosting provider.

Having a web presence is essential for all businesses, and if the website contains a contact form then it is essential that it correctly sends contacts to that business. Contact forms are useful as it allows users to easily contact you directly through your website.

I have recently had a very frustrating time trying to get into contact with a number of different companies due to their contact forms not working correctly. I think the overall success rate was about 40%, which is a terrible response rate.

One company I (eventually) got in contact with were very thankful that I pointed out that their contact form didn't work since they wouldn't have known otherwise. They only realised after the fact that they hadn't been getting any emails.

The Marp suite of tools is great for creating presentations from simple Markdown rules.

I've previously written about how to get up and running with Marp, but as I have been using it for a while I have come up with a few things that might be useful to know about if you are getting to grips with it.

Here's a list of what I'll be talking about.

1. Using HTML In Slides
2. Adding Speaker Notes
3. Using Spot Directives
4. Using Images
5. Generate A Presentation From A Document
6. Jump To A Slide
7. Creating Custom Themes

Marp or Markdown Presentation Ecosystem is a collection of tools that allows the generation of presentations of different formats from a markdown template. The tools are written in JavaScript and have a number of options that allow presentations of different styles and formats.

This tools stood out to me as it has syntax highlighting built in and allows the creation of presentations using markdown. The presentation can also be altered using standard CSS styles.

I've spent many hours fiddling with presentations in Keynote and Google Slides, so I wanted something that would be simple to use and generate the presentation files I needed.

I was talking with a fellow programmer the other day about a poor test that we were reviewing and we got onto the subject of what makes a poor test. The test in question had a reliance on a previous test being run, and the problem we encountered was that on some systems the dependent test was run after this test, which caused it to fail.

This also caused some headaches in local development as it couldn't be run in isolation. We had to ensure that both tests were run, in the correct order.

After fixing the tests so that they could be run independently I created a list of some common problems that programmers might come across when writing tests. These rules can be applied to most coding test, not just unit tests or behavioural tests.