Tailwind, the CSS framework, the song…

Tailwind is a CSS framework created by Adam Wathan, and beloved by many. I’ve found it’s really helped me understand CSS grid in particular, and has made building responsive layouts really easy. It sometimes comes in for criticism because it is based on utility classes, meaning you mostly skip the ability to attach styles to elements via CSS selectors (a fundamental feature of CSS). However, when it’s used with a content framework that provides components (like Laravel’s Blade), they can effectively take on that role and prevent repetition. One of the consequences of using Tailwind is that you often end up with lots of classes in HTML class attributes.

Anyway, Tailwind is cool and I like it, so I decided to write a song about it, in the same vein as my previous effort for The Good Ship Laravel.

The arrangement in Logic Pro

It’s all about a hapless, design-challenged developer (could that possibly be me??) having trouble with their styling and layout, and thinking they should give this Tailwind thing a go as a way to help them solve it. They give Tailwind a try, it takes them a while to get to grips with it, but they finally figure it out and all is rosy.

The “I ain’t got no style; I got Tailwind” line was the first line that came to me, followed by “I got classes…”, giving me most of the chorus, but the verses took a while longer. I wrote the music for the chorus first, then worked backwards to make a verse that led into it nicely. There’s a break in the middle that seemed really obvious (“When my mode is getting dark…”), straight out of many other songs – there’s nothing revolutionary going on here!

I played the guitar parts for the chorus (which is a simple C, Am, G), and eventually found a sequence for the verse that worked well (C, F, Dm, G, then Csus2, G at the end). I wrote a very melodic bassline on keyboard. Logic Pro’s Drummer took care of the brush-style drums – I didn’t spend too much time on them. Unfortunately I then found I simply couldn’t play the chord changes in the verse smoothly enough, so I enlisted the help of musicalduo on Fiverr, who did a great job of it. He also played a really smooth version of the bass part, which I hadn’t asked him to do. So my guitar playing only appears in the chorus, and I need to practice more!

I don’t rate my singing (I would love to work with someone that can sing!), but Logic’s Flex Pitch editing works wonders. I also really like using it for vocal harmonies – figuring them out using Flex Pitch, then re-singing them, just as I did for The Good Ship Laravel. I had a cold for a couple of weeks and early versions sounded like I was holding my nose, so I re-recorded them when I was feeling less bunged up! I’ve discovered that you can get away with really bad backing vocals, so long as they are in tune!

I have some other, older songs I’ve not released, one about npm, one about being an open source maintainer, and a half-finished Whitney Houston-style belter about composer… PRs welcome!

Lyrics

[Verse]
I’m trying to build an app that looks good
It’s all taking much more time than it should
Classes and styles going ‘round in my head
turns out it’s not as easy as I originally said.

I’m finding my breakpoints, feeling defeated
and all this old stuff will have to be deleted
One thing is clear from all this confusion
I’ve had to come to an unfortunate conclusion

[Chorus]
No, I ain’t got no style;
I need tailwind
I got problems, maybe more than a few
I need tailwind
Oooooh, I ain’t got style;
I need tailwind
Not sure what I’m gonna do
I need tailwind

[Verse]
You might think I’m crazy, but I’m gonna read some docs
I’ve gotta figure out how to arrange all these blocks
It looks great on my Mac, but explodes on my phone
and judging by Stack Overflow, I’m not alone

I ask, “hey Adam, you got any ideas?”
He says, “yeah, get Tailwind to mop up those tears”
So I’m going with the flow, flexing my grid
trying to figure out what those tutorials did, but still,

[Chorus]
I ain’t got no style;
I’ll try tailwind
I got problems, maybe more than a few
I’ll try tailwind
Oooooh, I ain’t got style;
I’ll try tailwind
Not sure what I’m gonna do
I’ll try tailwind

[Middle]
When my mode is getting dark
and my layouts fall to bits
I keep trying all kinds of things
until suddenly everything clicks

[Verse]
My grid’s all cool unlike my previous wreck
I don’t have to keep my units in check
I love my pretty colours, my text is so clean
I hate to think of what it might have been, but now 

I’m slicing up my blade into little tiny pieces
It’s the moment for components, it’s all utility
I’m loving how it works everywhere, especially on my phone
Tailwind’s really in several classes of its own

[Chorus]
No, I ain’t got no style;
I got tailwind
I got classes, maybe more than a few
I got tailwind
Oooooh, I ain’t got style;
I got tailwind
Maybe you’d like to try it too
We got tailwind

[Outro]
Oooooh, I ain’t got style;
I got tailwind
Oooooh, I ain’t got style;
I got tailwind

Bridging Laravel Scout to Eloquent

Laravel Scout provides an interface to external search engines such as Algolia and Meilisearch. These are typically remote indexes of the same data that you’re storing locally, but with far faster and more powerful searching and ranking capabilities. However, they have some limitations on how you can express the search itself (allowing only a single string value), and what you can do with the search result (because it comes back as a Laravel Collection and not a Query Builder). This makes it difficult to do things like perform a complex search remotely, and then filter the result further via Eloquent operations, perhaps involving different parts of your database. A typical Scout search might be:

use App\Models\Order; $orders = Order::search('Star Trek')->get();
Code language: PHP (php)

This gives us a bunch of Order instances, but we had no opportunity to ask it to do things like load relations or filter the results while it was doing it.

Fortunately it’s not difficult to bridge these two worlds. The resulting Collection contains model instances, so we can extract their IDs and use them to construct an Eloquent search that selects the same records, but locally this time (Scout already did the heavy lifting of figuring out which ones we wanted):

$builder = Order::query()->whereIn('id', $orders->keys());
Code language: PHP (php)

This isn’t ideal (because it will fetch those records a second time), but it will be reasonably efficient because the IDs it searches on are exact matches for primary keys in the database.

We now have a builder that will select the same records as the Scout search did, but we can continue adding to it before requesting the final results.

$result = $builder->where('orders.name', 'like', 'a%') ->with(['orderItems', 'customer']) ->get();
Code language: PHP (php)

So that’s how we can get to use Eloquent features on top of a Scout search.


After finding out that this bridging wasn’t built-in, I submitted a PR to add it, but sadly it was rejected. With the PR code in place, the syntax would have looked like this:

use App\Models\Order; $orders = Order::search('Star Trek') ->toEloquent() ->where('orders.name', 'like', 'a%') ->with(['orderItems', 'customer']) ->get();
Code language: PHP (php)

To be fair, this isn’t much of a saving in the external syntax, but it is more efficient because it can get the record IDs directly from Scout without having to load the models from the database. I don’t think that efficiency gain can be obtained from outside Scout’s own code.

I hope that helps someone!

Git & SSH sitting in a tree…

I do work for a bunch of different clients, who variously use GitLab and GitHub. For many years I put up with the incessant problem of accidentally signing my commits as the wrong user. It’s just so easy to forget to set the right GPG key and email address when you just want to get on with a project. It’s not the end of the world, but it’s annoying.

Often the same thing goes for the SSH keys you use to push and pull from your git repo; it’s a bit too easy to be lazy and use the same SSH key across multiple clients, when a little isolation would be a good idea from a security perspective.

What if you could work some magic so that identities and GPG and SSH keys are set to the right values right from the start, for every project for each of your clients? Read on…

This whole setup reminds me very much of a post I wrote in 2009 (13 years ago!) on the “holy trinity” of DNS, TLS, and virtual host wildcards that allow you to dynamically host vast numbers of previously undefined sites without having to touch your web server config at all, a classic example of convention over configuration.

First of all let me introduce you to .gitconfig. This file usually sits in your home directory, so for me on macOS that’s /Users/marcus/.gitconfig. This file contains your global git defaults, and is an easy-to-read config file in an “ini” style (and no, those are not real values!):

[user]
    name = Marcus Bointon
    email = marcus@example.com
    signingkey = AC34DF5B434BB76
[github]
    user = Synchro
    token = f693251e52043a23fe5fbd955cff56ff
...

You’ll find lots of other sections in here, which you can read about in the git config docs. But we are only really interested in one option: includeIf. This directive conditionally includes another git config file into your settings, and one of the things you can make it conditional upon is the path to your project. This is useful. I typically set up my client’s projects in the macOS default Sites folder within my home directory. Each client gets a folder, and each of their projects lives within that. This provides a tidy location to put a separate .gitconfig file that can be applied to all of their projects. It ends up like this:

~/.gitconfig
~/Sites/
    client1/
        .gitconfig
        project1/
        project2/
    client2/
        .gitconfig
        project1/
        project2/

Each .gitconfig file only needs to include the differences from the defaults that are set in the primary config file that lives in your home dir. To set up the GPG signing key and email for all of their projects, the file would contain this:

[user]
    email = remotedev1@client1.example.net
    signingkey = 434BB76AC34DF5B

Back in our primary file, we would add this conditional statement to automatically pull in this extra config whenever git is operating in this folder:

[includeIf "gitdir:~/Sites/client1/"]
    path = ~/Sites/client1/.gitconfig

And that’s it as far as GPG goes – commits will now be signed with the key and email address that are specific to this client, so when you set up your next project for them, you won’t have to do anything to set it up; it’ll Just Work™.

But what about SSH? The chances are that your client will have asked you for an SSH public key to add to their repo to provide you with sufficient access, but setting the GPG key doesn’t do anything towards selecting an SSH key for that purpose. You could do that using environment variables (which can be quite annoying) before, but fortunately, git 2.10.0 added the core.sshCommand config option that allows us to specify the SSH command that git uses for file transfer operations, and that can include a -i parameter to select an SSH identity (and -C to use compression for a possible speed boost). Add this to your client’s .gitconfig file, using the path to your client-specific identity file (not the public key which has a .pub suffix) like this:

[core]
    sshCommand = "ssh -i ~/.ssh/id_ed25519_client1 -F /dev/null"

Side note: I do hope you’re using Ed25519 keys for SSH; they’re newer, smaller, stronger, and faster than RSA keys, and they’ve been supported in OpenSSH since version 6.5 in 2014, so if your server doesn’t support them, you probably have bigger problems, or maybe you’re just running RHEL… I hope you’ve seen the post-quantum features of OpenSSH 9.0 too. The SSH client config file (usually found in ~/.ssh/config) is also really useful for twiddling per-directory or per-server configs that you can just set and forget.

Once you’ve done that, your commits will now be signed using your clients’ GPG key, and pushed to their repo using their specific ssh key, and you won’t have to change anything when you start new projects for them, so long as you put them in the same folder.

“What about my IDE?”, I hear you ask. Not to worry, most IDEs use your system’s git and ssh configs, so all this should work just fine with PHPStorm, VSCode, etc.

While I’m sure some bright spark can make this even more dynamic to automate this across clients, I find new clients are rare, but projects turn over fast enough for this to be a real win for getting that first commit signed and pushed correctly, first time.

The Good Ship Laravel

I like writing songs about open source, but I’ve never actually released any or posted them publicly, mainly because my singing is fairly terrible, and trying to find others will to sing about these things seems hard! I really liked “the Wellerman” sea shanty craze of 2021, I had a thought that I should make use of the the nautical theme that runs through a lot of Laravel’s nomenclature to write a shanty of my own, that wasn’t just another cover of the Wellerman. It also occurred to me that I could semi-speak the words (in a pirate voice of course!) instead of outright singing, and that made it feel a bit less daunting. I wrote the intro first, and I liked the storytelling aspect, though as intros go it’s quite long. The first verse came quite easily as I built a list of words and kind of ticked them off the list. The timing and rhyming structure is straight Limerick, which makes things very easy. The main melody was just the result of doodling on the keyboard for a bit. I was pleased with the sailor/Taylor rhyme for the chorus, but it took me ages to come up with the rest of it. I had several failing attempts at a melody for the chorus, eventually just singing something that the words fitted, and then turning that into an accordion line, then building out everything else around it.

The instrumentation was very simple – it’s a sea shanty so we need simple folk instruments – accordion and cajon, and then a plucked upright bass to fill it out. In the final chorus I threw in some lovely blatty brass and a bit of piccolo, since the top end was kind of empty.

The Logic Pro arrangement

I recorded the vocals for the intro in July 2021, but re-recorded them later for consistency. I sang the first (lowest) line of the chorus vocals, and then did something I’ve done before – copy the track, and then use Logic’s Flex Pitch editor to shift notes around to make harmonies, generally upwards, since I’d sung a low line to start with. Having found harmonies that worked, I then re-sang the new line, as a heavily edited one doesn’t sound quite right, especially when pitch shifts are quite large. I then repeated the process for a second time, giving me a three-part harmony for the chorus. Flex Pitch let me correct pitch, but also timing – the harmonies sound so much better when they line up in time too. The low line was only possible for me to sing because at the time I was recovering from COVID and a very nasty sore throat, so while I was feeling much better, my voice was much deeper then usual, and I could hit much lower notes! Overall I found the singing much easier than the other things I’ve tried to sing because it was pitched much more comfortably for my voice.

Software & Hardware

  • Apple Logic Pro X
  • Behringer UMC404HD USB audio interface
  • Aston Element dynamic microphone
  • Adam Audio TR5V monitors
  • KRK RP10S subwoofer
  • Arturia Minilab Mk II MIDI keyboard
  • Behringer DSP8024 Ultra-Curve Pro (room correction)
  • Mackie Big Knob passive volume control

Instruments & effects

  • Accordion, cajon, upright bass, piccolo, seagulls and waves from Logic’s standard sample library
  • Brass section from Logic’s Studio Horns instrument
  • Rowing boat sample I found from some ancient soundfonts collection
  • iZotope RX7 noise reduction
  • SSL Channel Strip (EQ, compression)
  • Logic standard compressor, EQ, de-esser
  • Logic “Space Designer” reverb
  • One of Logic’s default mastering configs for final output
Intro:
I was cast adift in development seas
a shiver of bugs a’circlin’ me
Naught but a pair of oars and my IDE
to keep my app from drownin’

I spied at last a distant sail
I signalled for ‘elp to that caravel
As she hove to I made out her name
’twas the good ship Laravel!

Verse 1:
Gather ye round my developers
and I’ll spin you a yarn most eloquent
a tale of passport and breeze,
socialite and jetstream
a cloud full of vapor and elegance

We’ve resources and models and more
controllers and actions galore
Fortified with some rum,
and a sack of enums
we’ll build an app clients will adore


Chorus:
Train your telescope on that far horizon
Don’t get marooned on development island
We’re gonna build an app so well
On the good ship Laravel

Get on board now, every sailor
dance to the tune of cap’n Taylor
You’ve never built an app so well as
On the good ship Laravel

Verse 2:

With livewire on top of your scripts
and laracasts dishing out tips
We’ve got the best pest
to chase the rats from your tests
and artisan helping you ship

The framework’s the star, that’s for sure
but there’s packages of treasure to explore
but the best bit’s the crew,
and you can join too –
everyone’s welcome aboard

Chorus2:
Train your telescope on that far horizon
Don’t get marooned on development island
We’re gonna build an app so well
On the good ship Laravel

Get on board now, every sailor
dance to the tune of cap’n Taylor
You’ve never built an app so well as
On the good ship Laravel
The good ship Laravel

An explanation for non Laravel folk!

A shiver is the collective noun for sharks. An IDE is an integrated development environment such as PHPStorm or VS Code; think MS Word, but for programming. An app, in this context, is a web application built in PHP. Sail is the name of a Laravel feature for managing local development environments. A caravel is a 15th century Portuguese sailing boat, exactly the kind of vessel that a stranded pirate might encounter, and also the word that gave inspiration for Laravel‘s name. “Hove to” is a sailing manoeuvre used to more or less stop a boat by pointing the sails in opposing directions, very useful when picking up castaways. A yarn is a story, often nautical, and a thread, but it’s also the name of a Javascript package manager. Eloquent is the name of Laravel’s database abstraction layer. Passport, Breeze, Socialite, and Jetstream are all Laravel features for building authentication workflows. Real clouds are made of vapor, but Laravel’s serverless service is called Vapor, and runs in the cloud. Elegance? Well, it mostly rhymes with eloquent, and is something that any framework aspires to. Models, controllers, actions, and resources are all important parts of a typical web app built in an object-oriented style; I was planning to have a line about “plundering” to go with resources, but that didn’t make it. Fortify is another Laravel authentication feature. Enums are a common programming language feature, but notable because they were added natively to PHP 8.1 recently. Telescope is an in-app debugging utility. Horizon is a queue monitoring extension. Cap’n Taylor is of course Taylor Otwell, the creator of Laravel. Livewire is a toolkit for building dynamic, interactive web interfaces for Laravel apps. Laracasts provides an amazing library of training material for Laravel and related technologies, and also a great forum. Pest is a relatively new system for building automated tests that Laravel uses. Artisan is a command line tool that helps automate numerous development tasks. The crew is Laravel’s development team, but also the enormous and diverse community of developers that make Laravel far greater than a typical framework – it’s home for many of us!