Explore the other side & learn a new language
If you want to become a better programmer, my number one advice is to learn another programming language. The further away from your comfort zone the better.
thoughts and inspiration on designing, programming, and writing for the web
If you want to become a better programmer, my number one advice is to learn another programming language. The further away from your comfort zone the better.
Data providers can be a perfect fit to assert a lot of expectations without writing a full test for each, but they can slow down your tests unnecessarily.
4 Jul 2023 via frantic.im
You stop to count how many tools and parsers work on your codebase: TypeScript, esbuild, swc, babel, eslint, prettier, jest, webpack, rollup, terser. You are not sure if you missed any. You are not sure if you want to know. The level of pain is so high you forget about anything else.
We've come a long way, but we're not there yet.
It's been an odd few days with the changes on Reddit and Twitter – the only two major social media platforms I browse.
Platforms are great portals for discovery, but a guarantee for longevity is not their strong suit. And while the fediverse is interesting, my Mastodon experience feels more like a detox than something that stands on its own.
Estimating software projects will never be my strong suit, but I've learned using numbers from the Fibonacci sequence to judge the size sets me off to a good start.
To estimate a task (in hours or days), I only use numbers from the Fibonacci sequence:
1, 2, 3, 5, 8, 13, 21, 34, 55…
The further along the Fibonacci sequence, the bigger the difference with the next number becomes. This aligns well with how we should estimate, because the bigger the task, the more unknowns there are.
A lovely essay by Henrik Karlsson on writing, blogging, and the power of the internet.
When writing in public, there is a common idea that you should make it accessible. This is a left over from mass media. Words addressed to a large and diverse set of people need to be simple and clear and free of jargon. […]
That is against our purposes here. A blog post is a search query. You write to find your tribe; you write so they will know what kind of fascinating things they should route to your inbox. If you follow common wisdom, you will cut exactly the things that will help you find these people.
Next on my PHP wishlist are nested properties. This idea is less realistic than others, it's more me thinking out loud. I don't have a good syntax proposal for this, and I'm not even sure it's the best solution for my problem. But it's the best I've come up with so far.
I published an article on the Mailcoach blog explaining the setup around customizable themes for newsletter archives.
I relied on CSS custom properties and HSL colors to allow users to customize their newsletter archives without fiddling with too many options.
Colors are often defined in RGB, but RGB is difficult to transform without custom functions. We ask the user to define the primary color in HSL instead. The benefit of HSL is that it's easy to control a color by tweaking the parameters.
I had the pleasure to have a conversation with Brent on PHP Annotated about event sourcing.
We talked about event sourcing in general, benefits, difficulties, and how we're using it in production.
From Jeremy Keith:
Your app should work in a read-only mode without JavaScript.
Without JavaScript I should still be able to read my email in Gmail, even if you don’t let me compose, reply, or organise my messages.
I like this take on progressive enhancement. JavaScript is the language for interactivity on the web. Reading does not require two-way communication.
When event sourcing, the stream of events is your source of truth where all data is derived from. A promise often made in event sourcing pitches is that you can destroy your data and rebuild (replay) it at any time. In my experience, it's a lot more nuanced than that.
Today I was looking for a way to create a custom Laravel validation rule without the overhead of a new class. The rule I needed would only be used in one place, so wanted to keep it close to (or in) the request class.
Upon re-reading the validation docs, I learned that Laravel supports closures as rules.
class JournalEntryRequest extends Request{ public function rules(): array { return [ // … 'lines' => [ function (string $attribute, mixed $value, Closure $fail) { $debit = collect($value)->where('type', 'debit')->sum('amount'); $credit = collect($value)->where('type', 'credit')->sum('amount'); if ($debit !== $credit) { $fail("Debit and credit don't match."); } if ($debit !== 0) { $fail("Amount must be greater than 0."); } }, ] ]; }}
Just what I needed!
Caleb Porzio released this podcast episode earlier this year, but it's been simmering in my head ever since.
The gist is to take things as far as you can before asking others. Instead of opening an issue, open a PR. Instead of replying "I don't know", find out. Before asking a question, write down the problem to make sure you've considered evey angle yourself.
Dealing with interactions this way gets things done more effectively, gives you the opportunity to learn something, and turns you into a nice person.
Last week, we launched a redesigned for Flare, our Laravel error tracker.
I contributed to the app UI, but most of the work was done by Digital With You, who provided us with the design, and the team that implemented it: Alex, Freek, Rias, Ruben, and Sam.
Check it out for yourself! Or read our launch post for all the nitty gritty details.
Thanks to my colleague Sam I recently learned about the form
attribute on the <button>
element.
By setting a form
attribute, the button becomes a submit button for a form on the page with that ID, without having to nest the button on the page.
This could be useful for a logout link, used on different places.
<nav> <!-- … --> <button type="submit" form="logout"> Log out </button></nav> <footer> <!-- … --> <button type="submit" form="logout"> Log out </button></footer> <form id="logout" method="POST" action="/logout"></form>