DEV Community: Mark Railton

Comparing strings that may or may not contain diacritics in PHP

Mark Railton — Fri, 06 Aug 2021 23:30:42 +0000

Today I ran into something that really had me scratching my head, I had to compare a string from a form against a string from the database. Clearly that's not where the issue was as it's a pretty simple thing in PHP, what had me scratching my head was that I needed to account for diacritics possibly being in 1 string but not in the other.

I spent quite some time looking online but eventually took to twitter and asked the wondrous PHP community for help

Ok, taking a complete blank and need some #php help. Need to compare 2 strings that may or may not contain diacritics. Example, Seán matches Sean. Don't know why I can't figure this one out, anyone any ideas?
— Mark Railton (@railto) August 6, 2021

Within minutes I had a couple of people offering suggestions and health conversation ensued. I settled on a solution by Derick Rethans That uses the Collator class from the intl extension. I took the example provided by Derick and tweaked it just a bit to suit how I wanted it, snippet of which is below

$c = new Collator( 'en' );
$c->setStrength( Collator::PRIMARY );

if ($c->getSortKey($newUser['firstname']) !== $c->getSortKey($existingUser->firstname)) {
    return null;
}

To give a bit more context on this, Let's say we have a user called Sean. Sometimes people called Sean will spell it Sean but others may spell it Seán with the Irish diacritic Fada. Both of these people are called Sean and both spellings are seen as correct, however when doing a direct comparison in PHP (or any other language really) you'll end up getting a mismatch if you try using the equals operator. For the task I've been working on, it was important that we allow for the same person possibly having the Fada in their name in the database, but then maybe not entering it another time in a different form.

Thanks to Derick, Ben and the others that posted possible solutions on the twitter thread. It really helped and thankfully I was able to move on with the task.

Using Tailwind CSS and PurgeCSS with Symfony Encore

Mark Railton — Sun, 30 Aug 2020 21:08:38 +0000

This was originally posted on my own website at markrailton.com

Recently I've started playing around with the Symfony framework as a more lightweight alternative to Laravel (in case you didn't know, Laravel contains a lot of functionality that many apps don't need and has a lot of magic in the background).

One thing that I really liked about Laravel was Laravel Mix, and how easy Mix made it to integrate the utility-first CSS framework Tailwind CSS and Purgecss (used for getting rid of CSS that's not needed). When I first started looking into Symfony Encore I found a nice guide on the Tailwind docs about getting Tailwind up and running on Encore. This was fantastic, but, there was a massive issue. The default CSS that was being generated was way in excess of 2MB in size, something that's simply far too big. Yes, TailwindCSS has support for PurgeCSS built in, but that means that you need to run your npm run dev or similar command each time you make a change that would involve changes to css.

I started to look further and came across a guide by Roberto Segura on how to integrate Purgecss with Encore. I'll detail the steps below that will allow you to get TailwindCSS integrated to Symfony Encore using Purgecss to reduce the amount of CSS that's generated. This will assume that you have installed Symfony Encore but nothing else.

First, let's install the dependencies, TailwindCSS, PostCSS and PurgeCSS:

npm install -D tailwindcss postcss-loader purgecss-webpack-plugin glob-all path

Create postcss.config.js in the project root with the following content:

module.exports = {
    plugins: [
        require('tailwindcss'),
    ],
};

Update the top of your webpack.config.js file like so:

const Encore = require('@symfony/webpack-encore');
const PurgeCssPlugin = require('purgecss-webpack-plugin');
const glob = require('glob-all');
const path = require('path');

(for some reason Encore defaults to using var, so I updated that too)

Next, update the Encore configuration chain in webpack.config.js to include PostCssLoader:

Encore
    ...
  .enablePostCssLoader()
;

So that we're not constantly having to run npm run dev during development, we will add the PurgeCSS inside an if check where we make sure to only run it on production (npm run build)

if (Encore.isProduction()) {
  Encore.addPlugin(new PurgeCssPlugin({
        paths: glob.sync([
            path.join(__dirname, 'templates/**/*.html.twig')
        ]),
        defaultExtractor: (content) => {
            return content.match(/[\w-/:]+(?<!:)/g) || [];
        }
    }));
}

Next, you need to update your assets/css/app.css to load Tailwind:

@import "tailwindcss/base";

@import "tailwindcss/components";

@import "tailwindcss/utilities";

Now, by running Encore, your CSS will be generated with TailwindCSS and only the required CSS will be created:

npm run build

You can also use the watch command to keep an eye on your CSS and JS files so that you can get fresh copies of your assets built each time you make a change, simply use:

npm run watch

A simple act goes a long way

Mark Railton — Mon, 27 Apr 2020 08:34:10 +0000

This was originally posted on my personal site here

Four years ago I was taking part in a coding boot camp called Code Institute. At the time I had already been working as a web developer for just under a year and a half, but I was self taught and felt extremely limited in what I knew and was able to achieve. I've been meaning to do a write up about my time with Code Institute, but that is not this post, hopefully soon though.

Today I want to talk about Boggle, a word game that I was never really that good at, but always enticed by. If you've no idea what I'm talking about, then maybe take a look here.

When I was taking part in Code Institute's boot camp, the 2nd stream of study was Python, a language that, until that point, I knew nothing about. During the Python module there was a sort of mini project, to build a clone of the game Boggle that would draw the 4 * 4 grid of letter tiles and also give a list of valid words that could be generated via the 16 characters that were on screen.

I honestly can't remember how long I spent working on the game (I didn't put it under git until after I completed it), but I know it wasn't all that long. I completed the basic requirements and put it up on GitHub then promptly forgot about it, until this week. A few days ago I got an email from GitHub saying a new pull request had been opened against the project and, if I'm honest, it really took me by surprise. I had completely forgotten about the project and wondered why anyone would be looking at it, never mind submitting a PR against it, after all, there wasn't even a readme on the repository to explain what it was.

I had a look at the submitted change and initially thought about just closing it and maybe deleting the project seeing as I clearly didn't use it. The next day I got another email, the change author had added a message to the pull request thanking me for the project and that he had used it to play boggle on a conference call with around a dozen people and it had made scoring simple. I looked at the committed changes again and realised I'd made a pretty big error when creating the game. The physical game uses a grid of 16 dice, each die has 6 letters. In my version of the game however, I wasn't using the concept of dice, instead I was picking 16 random characters out of the English alphabet, so theoretically it was possible to get combinations of letters in my version that were not possible in the physical version.

After poking around at the code I realised that the changes made much more sense in the context of how the physical game is played. Not only had this person modified it to use dice instead of just random characters, he'd also added in the score for each word to make things even easier. At this point I decided that I'd definitely pull in his changes as they really made sense and made the game more complete. I asked for 1 relatively minor tweak and once that was done I merged the change. I also decided to finally include a readme and license for the game, two things that are pretty much a requirement for anything that's on GitHub these days.

So, why am I writing about this? Well, the whole thing got me thinking about how what we do as developers, whilst maybe insignificant at the time, has the ability to impact others in a way that we can't even begin to think about. The author of the pull request, a guy called Brian from Missouri whom I'd never met or even spoken to, had searched online for 'Python Boggle Solver' and my code repository was the first that came up in the search results. Not only was my code the first result that came up, but it was useful for what he was wanting to achieve. What made it even more 'real' for me, is that he was using code I wrote to help with breaking the monotony of not being able to leave home and spend some time playing a game with others during a conference call.

The simple act of opening a pull request let me know that code I created around 4 years ago was able to help someone, and during these difficult times, it gave me a much needed boost. If you have come across some code or a blog article recently that's helped you, please consider just dropping a note of thanks to whomever created the code or article, you never know, it might just make their day.

Creating migrations when changing an enum in Python using SQLAlchemy

Mark Railton — Sun, 29 Mar 2020 16:41:26 +0000

This was originally posted on my own blog here

Recently at work I've spent some time working on a scaffold project that we'll be using for API projects that we'll be building.

For a number of reasons we've decided to use Python as our backend language and Flask as our API framework. One of the things I love most about Flask is that it's very unopinionated and let's you build what you want, pretty much how you want.

One of the features I've been working on is an audit log. For data integrity purposes we decided to use an enum field for the event type value in both the code itself and also in the database. Like many Flask applications, we're using SQLAlchemy as an ORM and Flask-Migrate to automatically create Alembic migrations. Using a SQLAlchemy model with the field type set to an enum equal to the enum used in the code, I had expected Flask-Migrate to automatically create a new migration any time we added values to the EventType enum class, however this is not the case.

After some searching around, I discovered that this is a known issue with Alembic and that migrations for enum changes have to be created manually. I've got a sample migration that I created manually below as well as some steps so you can see how to handle adding or removing a value from an enum in Flask. Note that this migration is specifically written to work with PostgreSQL as that is the database engine that we use.

Make changes to the Enum in the relevant model
Create an empty migration file

flask db revision -m 'Add Logout_Success to AuditEvent'
Populate the new migration with code to create the changes, note you will need to add values for the existing and new options ensuring to keep the revision and down_revision numbers that already exist in the new migration file

"""
Add Logout_Success to AuditEvent

Revision ID: 08720b8a9d11
Revises: 810eac468f83
Create Date: 2020-03-25 12:19:09.432635

"""
from alembic import op
import sqlalchemy as sa

# revision identifiers, used by Alembic.
revision = '08720b8a9d11'
down_revision = '810eac468f83'
branch_labels = None
depends_on = None

# Enum 'type' for PostgreSQL
enum_name = 'auditevent'
# Set temporary enum 'type' for PostgreSQL
tmp_enum_name = 'tmp_' + enum_name

# Options for Enum
old_options = ('LOGIN_SUCCESS', 'LOGIN_FAIL')
new_options = sorted(old_options + ('LOGOUT_SUCCESS',))

# Create enum fields
old_type = sa.Enum(*old_options, name=enum_name)
new_type = sa.Enum(*new_options, name=enum_name)

def upgrade():
    # Rename current enum type to tmp_
    op.execute('ALTER TYPE ' + enum_name + ' RENAME TO ' + tmp_enum_name)
    # Create new enum type in db
    new_type.create(op.get_bind())
    # Update column to use new enum type
    op.execute('ALTER TABLE audit ALTER COLUMN event_type TYPE ' + enum_name + ' USING event_type::text::' + enum_name)
    # Drop old enum type
    op.execute('DROP TYPE ' + tmp_enum_name)


def downgrade():
    # Instantiate db query
    audit = sa.sql.table('audit', sa.Column('event_type', new_type, nullable=False))
    # Convert LOGOUT_SUCCESS to LOGIN_SUCCESS (this is just a sample so may not make sense)
    op.execute(audit.update().where(audit.c.event_type == u'LOGOUT_SUCCESS').values(event_type='LOGIN_SUCCESS'))
    # Rename enum type to tmp_
    op.execute('ALTER TYPE ' + enum_name + ' RENAME TO ' + tmp_enum_name)
    # Create enum type using old values
    old_type.create(op.get_bind())
    # Set enum type as type for event_type column
    op.execute('ALTER TABLE audit ALTER COLUMN event_type TYPE ' + enum_name + ' USING event_type::text::' + enum_name)
    # Drop temp enum type
    op.execute('DROP TYPE ' + tmp_enum_name)

Hopefully this will be of use to someone.