Articles

I got into mechanical keyboards a few years ago, around the same time that I started to work from home. Since then I have collected a number of different keyboards of different sizes and orientations, mostly in a drive to have a nice feeling keyboard, increase productivity and reduce my RSI.

Whilst keyboards look similar to the uninitiated there are quite a lot of different factors that go into the mechanical keyboard. In fact, there are so many different terms used in the mechanical keyboard world that might need some explaining before you get into things.

In this article I will look into some of the different types of keyboards available by breaking down some of the terms used. I'll then give some recommendations on where to get started, and what to avoid.

This is an introduction and is by no means a complete picture of every sort of keyboard available.

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.

Creating queues using the core queue classes in Drupal is fairly straightforward. You just need a mechanism of adding data to the queue and a worker to process that data.

As the data you add to the queue is serialised you can add pretty much any data you want to the queue, so the only limitation is rebuilding the data once you pull it out of the queue.

There are some situations where the core Drupal queue system needs to be altered in some way. You might want to separate the data into different tables, or have a different logic for creating or storing the queue items, or even integrate with a third party queue system for manage the queues.

When writing data to the queue database system Drupal will convert the information to a string using the PHP serialize() function. When the information is pulled out of the database the queue system will unserialize() the data to convert it back into the original information.

When you first start using the queue system you will probably use an array or the PHP stdClass object to store the information on your queue. Whilst this works, the information they contain is pretty free form and makes testing or working with the data a little cumbersome.

A much better way of storing data is by creating an object of a known type and using that as the storage medium for the queue.

I've talked a lot about the Batch API in Drupal recently, and I've mentioned that it is built upon the Queue API, but I haven't gone any deeper than that. I wrote about the Queues API in Drupal 7, but thought I would bring my understanding up to date.

A queue is a data construct that uses a "first in, first out" (or FIFO) flow where items are processed in the order that they were added to the queue with the first item added being processed first. This system has a lot of different uses, but is most important when it comes to asynchronous data processing. Drupal and many modules make use of the queue system to process information behind the scenes.

The difference between a queue and a batch is that the batch is for time sensitive things where the user is expecting something to happen. A queue, on the other hand, is more for data processing that needs to happen behind the scenes or without any user triggering the process.

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.

I've seen lots of "our team" pages over the years, but one of the ones that stood out to me the most were those that had an interactive element to them. For me, it adds a bit of personality to the page and makes it feel more alive than a bunch of silhouettes of the directors.

I remember seeing a team page a while ago that had a number of little images of the team that looked at the mouse pointer as it moved around the page. Each face in the picture looked in all 8 directions as my mouse pointer went around the screen. This caught my interest so I had a look to see how it worked.

The page used a combination of a fixed image dimension and background positioning to show show parts of a single image. By combining this with a little bit of JavaScript the page created an interactive image without having to load lots of images. The image can also be simple as it just needs to be a square collage of 9 images, one for each direction the mouse lies in, and a central one to look straight ahead.

I was scrolling through The Pi Hut website recently and my eye was drawn by a case for the Raspberry Pi Computer Module 4 (CM4) that looked like a modified Nintendo Gameboy. I had bought a CM4 for another project, but as that project wouldn't be delivered for a few months I was looking for something useful to do with the CM4 in the meantime.

The GPi Case 2 from Retroflag is a case that accepts the Raspberry Pi Compute Module 4 (CM4) and is used as an emulation station. Using the right software, it is possible to add files to the system that allow you to play games from a variety of different platforms. If you go for the WiFi CM4 you can also connect Bluetooth controllers to the unit and even use WiFi to transfer files.

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.

This is the sixth article in a series of articles about the Batch API in Drupal. The Batch API is a system in Drupal that allows data to be processed in small chunks in order to prevent timeout errors or memory problems.

So far in this series we have looked at creating a batch process using a form, followed by creating a batch class so that batches can be run through Drush, using the finished state to control batch processing, processing CSV files through a batch process and finally adding to running batch processes. These articles give a good grounding of how to use the Drupal Batch API.

In this article we will look at how the Batch API is used within Drupal. The Batch API in Drupal is either used to perform a task, which I will call "direct", or to pass on the batch operations to a hook, which I will call "indirect". These aren't official terms you understand, I'm just using them here to separate how Drupal uses the Batch API.