by sebastian de deyne
A few years ago we built a tiny web tool to view a site’s DNS records. I still use it on a regular basis when I need to do a quick lookup.
Some cool tidbits:
ip or visit dnsrecords.io/ip to display your current IP address
I’ve attended this talk twice this year and it hit just as hard the second time. Happy to see it available online. Start watching already!
I occasionally send out a dispatch with personal stories, things I'm working on, and interesting links I come across.
Just a Twitter account I’ve been enjoying lately. Small worlds posts a tiny sci-fi story every day (with lovely visuals!)
Follow @smllrworlds on Twitter.
A short & sweet overview of get(), cursor(), chunk(), and lazy() to retrieve models from the database. It’s a tradeoff between speed and memory usage.
When building a CRUD interface in an event sourced system, you’ll come across the dilemma of how granular your events should be. Should you have a large PostUpdated event, or granular TitleUpdated, ContentUpdated, and AuthorUpdated events?
At Laracon US we announced we’re working on a new course at Spatie: Full Stack Artisan.
In Full Stack Artisan, we’ll dive into building Laravel applications with Inertia, React, TypeScript, view models, our Laravel Data package, and more.
Last week I took a break from working on course content to set up branding and a landing page.
Personal websites are often blogs these days: a chronological stream of thoughts, news, and articles. However, some content is worth more than a post stuck and lost in time.
If I need to publish content about an emerging API, I need a couple of things. I need reference documentation so that people who want to try it out understand how to use it. This reference is evergreen content, and I will update it as the API changes. It is helpful to have, right up front, information about the last time we updated the content and the version of the spec, or browser to use for testing. I also want to let people know that we’ve shipped this experiment, so I need a news post pointing to my reference material, explaining that this thing is here, and asking people to try it out and give us some feedback. I will not update the news post; what I might do, however, is write another news post when the spec and implementation changes to let people know the progress. These news posts are my paper trail.
Food for thought for my own site. I have a bunch of old articles I wish were more discoverable as pages outside of the “blog” format.
Jeremy Keith has an interesting take on how AI affects how we interact with search engines as content creators.
Previously, Google had a mutually beneficial agreement with websites: websites provided content, and Google brought traffic. Now, Google is using our content to generate and host their own.
What a lovely project! Project E-Ink builds a large e-ink display that displays the front page of the newspaper.
{.short}
I have a strong attraction towards e-ink. I think it’s because despite being state of the art technology, e-ink doesn’t feel “digital”. In the case of this display: it’s there, it’s connected, but it’s static. It’s up to date but doesn’t grab your attention.
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.
This makes it cheap and easy to add more test cases. For an in-depth introduction to data providers, I recommend this excellent article on the Tighten blog.
class AddTest extends TestCase
{
/** @dataProvider values */
public function it_adds_values(int $a, int $b, int $result): void
{
$this->assertEquals($result, add($a, $b));
}
public function values(): array
{
return [
[1, 1, 2],
[1, 2, 3],
[5, 5, 10],
// …
];
}
}
Data providers run setUp for each value. If you need a clean slate for every test, there’s no way around this. If you don’t, data providers make your tests slower than they need to be.
Consider a heavier integration test that migrate & seeds the database in setUp().
class MyTest extends TestCase
{
public function setUp(): void
{
parent::setUp();
// Migrate and seed database values…
}
/** @dataProvider values */
public function it_does_something(string $value): void
{
// …
}
public function values(): array
{
return [ /* … */ ];
}
}
Each case in values() will re-seed the database. If this isn’t needed, you’re better off looping over the values yourself.
class MyTest extends TestCase
{
public function setUp(): void
{
parent::setUp();
// Do some heavy lifting…
}
public function it_does_something(): void
{
$values = [ /* … */ ];
foreach ($this->value() as $value) {
// …
}
}
public function values(): array
{
return [ /* … */ ];
}
}
We recently updated a few tests in a project we’re working on, and it almost doubled the speed!
With a data provider:
Time: 00:08.517, Memory: 92.50 MB
OK (43 tests, 43 assertions)
In a loop:
Time: 00:04.448, Memory: 70.14 MB
OK (1 test, 43 assertions)
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.