Much ado about null – Larry Garfield

Much ado about null

Submitted by Larry on 13 May 2022 – 11:24am

null has a controversial history. It’s been called “the billion-dollar mistake” by its creator. Most languages implement null, but those few that do not (such as Rust) are generally lauded for their smart design by eliminating a class of errors entirely. Many developers (myself included) have argued that code that uses null or nullable parameters/returns is intrinsically a code smell to be avoided, while others (also myself included, naturally) have argued that is too draconian of a stance to take.

Anna Filina has a very good three-part series (properties, parameters, and returns) on how to avoid null in PHP generally. Alexis King has a related post (excuse the Haskell) on how to avoid needing edge cases like null in the first place.

However, I want to go a bit deeper and try to understand null from a different angle, and tease out the nuance of why one would really want to use it, and thus what we should be doing instead. To get there we’ll have to go through a tiny little bit of type theory, but it will be quick and painless, I swear.

Continue reading this post on PeakD.

Xdebug Update: April 2022 – Derick Rethans

Xdebug Update: April 2022

In this monthly update I explain what happened with Xdebug development in this past month. These are normally published on the first Tuesday on or after the 5th of each month.

Patreon and GitHub supporters will get it earlier, around the first of each month.

You can become a patron or support me through GitHub Sponsors. I am currently 46% towards my $2,500 per month goal. If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

In April, I spend 29 hours on Xdebug, with 27 hours funded.

the original (another 1331 bytes)

TailwindCSS Tips – Matthew Weier O’Phinney

I’ve been dabbling in CSS my entire career.
In the early days, it was relatively simple, as our browsers were fairly limited.
But over the years, CSS has become more and more capable, allowing styles to target only tags with specific tag attributes, only apply at specific screen sizes, and even perform complex layouts using things like flexbox and grid.
I take a bit of time every now and then to understand these things… but since I don’t use CSS a ton, it’s hard to keep up.

As such, over the past decade, I’ve tended to use CSS frameworks, and generally Bootstrap.
Every couple years, a new major version is dropped, and I have to learn new structures and components, and struggle to get things to look the way I want.
Worse, when I use these frameworks, injecting custom CSS often means understanding how the framework is already styling components so I can ensure things don’t conflict.

The last couple years, I’ve been keeping an eye on TailwindCSS.
I’ve been a bit skeptical, as its declarative, utility-first approach looks a lot like doing CSS inside your html, which, honestly, feels off.
I’ve typically subscribed to the idea of semantic html, which advocates separating style from markup.
Having styles directly that mimic CSS directives associated with every tag feels like an unholy mix, and a far cry from semantic html.

And then there’s the hype.
The original author and project lead of Tailwind is a huge hype man, and hype tends to turn me off.
That’s on me, not them, but having been in the business for over two decades, I’m finding I’m more and more likely to discount hyped products and projects, because I’ve seen them come and go so frequently; there’s often an indirect relationship between the amount of hype and the long-term viability of a project.
I’ve also often observed that hype serves as a way for users to deflect reasonable critique, and the more vehement the user base, the less interested I am in engaging with them because of this.
Clearly, YMMV, but it was definitely something keeping me from really investigating Tailwind.

However, recently, in helping out the PHP Foundation, I volunteered to setup their static website, and the team requested using TailwindCSS, so I dove in.

And I discovered… I kind of love it.

This is one of those “I’ll be googling this in the future” posts.

How it works

I won’t go into how to get started with Tailwind; their docs do a great job of doing that for you.
However, I will give a quick overview of how things work, so you can see (a) where I’m coming from, and (b) what you’ll be doing when you start with Tailwind.

The way I’ve always learned to do CSS is to first write html, and then write CSS to style that html the way you want it to appear.

<div class="box"> <h2>Title</h2> <p>Some content</p>
</div> <style>
.box { margin: 0.5rem; background-color: #333333; border: #000000 padding: 0.5rem;
} .box h2 { background-color: #dedede; padding: 0.5rem; color: #111111; font-size: 2rem; min-width: max-content;
} .box p { padding: 0.5rem; font-size: 1.2rem; min-width: max-content;
}
</style>

Tailwind instead provides a ton of “utility” classes, targetting just about every CSS directive.
You then add these html classes to elements to style them:

<div class="m-2 p-2 bg-neutral-600 border-black"> <h2 class="min-w-full p-2 bg-neutral-300 text-4xl text-neutral-800">Title</h2> <p class="min-w-full p-2 text-xl">Some content</p>
</div>

Behind the scenes, you run the Tailwind CLI tool, and it analyzes your html to generate CSS for you.
You can even have it watching for filesystem changes to files you’re interested in (templates, JS scripts, etc.), and it will regenerate the CSS automatically.

Tip 1: Layers

Out of the box, Tailwind does a CSS reset that removes all styles.
This is great, because it means that any changes you make, you can anticipate exactly what will hapen.
It’s also a pain in the ass, because everything is unstyled: your headings look just like your paragraphs, your lists look just like your paragraphs, and there’s no way to tell where one paragraph ends and another begins.

So, the first thing you’ll want to do is define your base styles.
Tailwind has a very specific suggestion for where and how to do this: in the “base” layer.

Opening your site CSS file, you’ll see these directives when you begin:

@tailwind base;
@tailwind component

Truncated by Planet PHP, read more at the original (another 14308 bytes)

CI Pipelines for dockerized PHP Apps with Github & Gitlab [Tutorial Part 7] – Pascal Landau

In the seventh part of this tutorial series on developing PHP on Docker we will setup a CI
(Continuous Integration) pipeline to run code quality tools and tests on Github Actions and Gitlab
Pipelines
.