I'm not a fan of the summary option on body fields in Drupal. I've never really got on with how users interact with it or the content is produces.

The field type I'm talking about is called "Text (formatted, long, with summary)" and it appears as an add-on summary field to a normal content editor area. It comes as standard on Drupal installs and appears on all body fields. The field type has it's uses, but I often find that the content it produces is unpredictable and doesn't have a great editing experience. I have even written articles in the past about swapping the summary field to a fully fledged wysiwyg area for Drupal 7, which worked on the project I implemented it on.

Let's look at the body summary field in Drupal and see why I have a few problems with it.

I have been a web developer for quite a few years, and one constant that is an unfortunate story in the industry is the rescue project. This is a web project that has been mismanaged by an agency or developer in some way so that the site is at a critical point. Either, the site is unable to launch or it has already been launched and suffers from serious issues. Projects in this state are caused by a variety of factors, and can be challenging and difficult to turn around.

Some agencies, quite understandably, won't go near rescue projects as they can be extremely tricky to manage. The client will have already invested money in getting the site in the first place, so spending money to fix the site can be a little painful for them. This is especially the case for small business sites, clubs or charities without any extra funds.

There are lots of ways to draw objects using the Tkinter Canvas element, but making the canvas elements interactable adds a lot to the applications you create. There are a few things to take into account when binding events like what events to trigger on and how to find out what item triggered what event.

In this article I will address how to set events, how to react to their output and how to find out what element triggered the event.

Let's start by creating a very simple application that contains a Canvas element. In that Canvas we create an oval element that we can use for the rest of the examples.

Vissles recently sent me their new LP85 keyboard to review, and I've spent a few weeks giving the keyboard a go. I have already reviewed the V84 mechanical keyboard from Vissles just a few months ago and that keyboard has been my daily driver ever since. I was therefore very interested in testing out this new product. The LP85 is a low profile keyboard with optical switches that come in a sleek aluminium chassis. Instead of the usual mechanical switches that make a physical connection, optical switches break a beam of infrared light to activate the key press. As there is no physical switch being clicked this means that optical switches last longer than mechanical ones.

A calculator is a great application to create when learning how to code as it contains many of the things that most GUI applications will have, including behind the scenes processing of results. Things like triggering events from buttons, accepting user input, and producing output from that input are pretty standard in GUI applications and a calculator has all of them. There are also a couple of features in Python that makes building the application pretty simple. In this article I will look at designing and building the interface using Tkinter, followed by creating the code to process the entered sums into a result.

The Canvas element that comes with Tkinter is quite versatile. Out of the box you can draw simple basic shapes like squares and circles, but also lines and more complex shapes made up of points. You can even add text and images to the canvas.

This article will go through all of the different types of items you can draw using the Tkinter Canvas object.

Before getting into that, it's important to understand how coordinates are used on a canvas object. Drawing items on a canvas requires the use of an x and y coordinate to pinpoint where the item is to be drawn. All points are relative to the top left hand corner, so a coordinate of 0,0 would be right in the top left corner.

When creating Drupal modules I like to keep the hard coded components to a minimum. This helps when changing parts of the module in the future as hard coded links and other elements will require manual intervention and slow down maintenance. Sometimes, though, this isn't an option as you just need to have a few routes in your *.routing.yml file that point to controllers or forms within your module.

I had a situation today where I was looking to load all of the routes that are contained in a module. I could then construct a page of links that would handily point to different parts of the module or feed those links into a sitemap. This meant that I wouldn't need to hard code this list into a controller, I just needed to load all the routes and print that list out instead. Especially handy if I ever added or removed a route as that would mean that list would update without me having to do it manually.

I recently saw a design of a physical clock that inspired me to go about creating one using Python and Tkinter. The clock was essentially a wall of letters with lights behind that light up depending on what time it is. Without the lights the clock looks like a jumble of letters, it is only when the light is on that the relevant time is displayed.

The original clock was of a proprietary design so I set about creating one that was based more on an open source clock design that I found. That clock design I found didn't display the AM or PM of the time, so I ended up tweaking that design a little anyway.

Changing time into different formats is quite a common thing to do in programming. I have seen examples that change times into Roman numerals and other formats, but I realised I hadn't seen any code that changed the current time into a sentence. This means converting a numeric time value into a sentence that can be read. For example, the time 9:05 can be read as "it is five past nine", or if the time is 9:00 then it would read "it is nine o'clock". At it turns out, there are only a few rules that govern doing this.

SOLID is a set of object oriented design principles aimed at making code more maintainable and flexible. They were coined by Robert "Uncle Bob" Martin in the year 2000 in his paper Design Principles and Design Patterns. The SOLID principles apply to any object oriented language, but I'm going to concentrate on what they mean in a Python application in this post.

I originally wrote about SOLID principles with PHP as the basis of the article, but as the lessons here can be easily applied to any object oriented language I thought that I would re-write it with Python in mind. If you are familiar with only PHP or Python then this will be a good learning resource on learning the other side.