🐥 YellowDuck.be

🔗 100 percent code coverage is not as good as you think

2026-03-11T14:00:00Z

When I see people talk about code coverage, there are usually caveats that you don't need to worry about 100% coverage. Some argue that it ends up being a victim of Goodhart's Law1, others say that you get diminishing returns. Some will say that full code coverage is just a by-product of the proper development process, which should be your focus. Others will point out that some things just don't need test coverage. "Be pragmatic!", they'll say.

But lately, since AI agents have become more common, I do see people starting to shoot for that perfect 100%. Some feel that since they can just throw AI at it, they might as well ask for it. Others think of it as a hedge against the unexpected things their agent might do, that it's just the kind of guardrails you need in this kind of workflow.

There's a fundamental point that's missed here.

Continue reading on blog.1-800-rad-dude.com

#reading-list #development #ai #testing

🔗 Getting started with Typst

2026-03-11T09:00:00Z

Typst is an open-source project that can be built into a pretty small binary, that is very easy to install or even use in Web. Typst is managed and built by a company, a company, the main product of which is Typst editing Web App.

So there are two possibilities for working with Typst: use online Web App or install Typst locally and work with it from your favorite editor. I will briefly cover these two ways with their pros and cons in this chapter.

Continue reading on sitandr.github.io

#reading-list

🔗 Thinking Elixir podcast 295: Is Your Type System Leaking?

2026-03-10T18:00:00Z

News includes José Valim’s deep dive into Elixir’s type system cutting worst-case checks from 10s to 25ms, a new Dashbit post on type systems as leaky abstractions, Oban Pro teasing Workflow UI improvements, MDEx v0.11.6, Livebook Desktop on Linux, and more!

Continue reading on podcast.thinkingelixir.com

#reading-list #elixir #linux

🔗 Enum ordering in PostgreSQL

2026-03-10T14:00:00Z

Rather than adhering to alphabetical order, when using order by with an enum column, the sorting adheres to the order in which the values were listed when the enum was created.

create type application_status as enum ( 'submitted', 'under_review', 'accepted', 'rejected' );
create table applications ( applicant_name text, status application_status );
insert into applications values ('George Washington', 'accepted'), ('John Adams', 'under_review'), ('Thomas Jefferson', 'under_review'), ('Aaron Burr', 'rejected'), ('Thomas Pinckney', 'submitted');
select * from applications order by status; -- applicant_name | status -- ------------------+------------- -- Thomas Pinckney | submitted -- John Adams | under_review -- Thomas Jefferson | under_review -- George Washington | accepted -- Aaron Burr | rejected

Continue reading on til.hashrocket.com

#reading-list #database #postgresql #sql

🔗 Hidden issue with whereFullText and refresh database in Laravel

2026-03-10T09:00:00Z

The whereFulltext method in Laravel allows developers to perform full-text searches on columns indexed with FULLTEXT in MySQL and PostgreSQL (docs). This method is useful for searching large datasets efficiently, especially for text-based searches. However, while it enhances search performance, it has some caveats, particularly when used in tests with RefreshDatabase.

Continue reading on dev.to

#reading-list #laravel #php #database #postgresql #mysql #sql

🔗 Pattern matching: matching, not assigning

2026-03-09T18:00:00Z

You come to Elixir with an assignment model in your head. You see = and your hands move faster than your brain. Then a match fails, or a function head doesn’t run, and you think you made a mistake.

Pattern matching is not about storing a value. It’s about selecting a shape. When the shape doesn’t fit, the match fails, and that failure is useful. It’s how Elixir chooses which path to take.

The mental model is simple: = is a match operator. Pattern matching selects structure and binds names. The pin operator turns a binding into a test.

Continue reading on grox.io

#reading-list #pattern #elixir

🔗 Laravel Boost – AI tooling for Laravel

2026-03-09T14:00:00Z

Laravel Boost is designed to enhance your development experience by providing powerful tools and integration capabilities. With the ability to work seamlessly within your editor and alongside Laravel applications, it aims to streamline the development process and improve productivity.

Many developers seek ways to accelerate their workflow, and Laravel Boost offers solutions that can help achieve those goals efficiently. By leveraging the features of this tool, you can focus more on building exceptional applications while reducing the overhead of repetitive tasks.

Key Features

Deep integration with popular code editors.

Tools that assist in the Laravel development cycle.

Accelerated build pipelines and deployment processes.

Enhanced debugging capabilities.

Continue reading on laravel.com

#reading-list #development #laravel #php #tools #ai

🔗 Cross-site request forgery

2026-03-09T09:00:00Z

Cross-Site Request Forgery (CSRF) is a confused deputy attack where the attacker causes the browser to send a request to a target using the ambient authority of the user’s cookies or network position.¹ For example, attacker.example can serve the following HTML to a victim
   
 
and the browser will send a POST request to https://example.com/send-money using the victim’s cookies.

Essentially all applications that use cookies for authentication need to protect against CSRF. Importantly, this is not about protecting against an attacker that can make arbitrary requests² (as an attacker doesn’t know the user’s cookies), but about working with browsers to identify authenticated requests initiated from untrusted sources.

Unlike Cross-Origin Resource Sharing (CORS), which is about sharing responses across origins, CSRF is about accepting state-changing requests, even if the attacker will not see the response. Defending against leaks is significantly more complex and nuanced, especially in the age of Spectre.

Why do browsers allow these requests in the first place? Like anything in the Web platform, primarily for legacy reasons: that’s how it used to work and changing it breaks things. Importantly, disabling these third-party cookies breaks important Single-Sign On (SSO) flows. All CSRF solutions need to support a bypass mechanism for those rare exceptions. (There are also complex intersections with cross-site tracking and privacy concerns, which are beyond the scope of this article.)

Continue reading on words.filippo.io

#reading-list #http #html

🐥 Monitoring the progress of creating an index in PostgreSQL

2026-03-08T18:00:00Z

Creating an index on a large table can take minutes or even hours. For GIN, trigram, or multi-million row tables, it can feel like nothing is happening at all.

PostgreSQL provides built-in visibility into index creation progress. You don’t need external tools — just the right system view.

The `pg_stat_progress_create_index` view

PostgreSQL exposes index build progress via:

PostgreSQL

The key view is:

SELECT *
FROM pg_stat_progress_create_index;

This shows all currently running CREATE INDEX operations.

If nothing is building, it returns zero rows.

Example output explained

A typical query looks like this:

SELECT
    pid,
    datname,
    relid::regclass AS table_name,
    index_relid::regclass AS index_name,
    phase,
    lockers_total,
    lockers_done,
    blocks_total,
    blocks_done,
    tuples_total,
    tuples_done
FROM pg_stat_progress_create_index;

Important columns:

`phase`

Tells you what stage the build is in. Examples:

initializing
building index
waiting for writers before validation
index validation
waiting for old snapshots

If you're using CREATE INDEX CONCURRENTLY, you’ll see additional validation phases.

`blocks_total` and `blocks_done`

These indicate:

Total table blocks to scan
How many have been processed

Progress percentage:

(blocks_done::float / NULLIF(blocks_total, 0)) * 100

This is usually the most reliable indicator during the scan phase.

`tuples_total` and `tuples_done`

Shows:

Estimated total rows
Rows processed so far

Useful, but block progress is often more stable.

Monitoring concurrent index builds

When using:

CREATE INDEX CONCURRENTLY ...

PostgreSQL performs multiple scans and validation steps.

You’ll see phases like:

building index
waiting for writers before validation
index validation
waiting for old snapshots

If it appears stuck in:

waiting for old snapshots

That usually means a long-running transaction is preventing completion.

You can inspect active transactions:

SELECT pid, state, query, xact_start
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY xact_start;

Calculating progress percentage

A simple progress query:

SELECT
    relid::regclass AS table_name,
    index_relid::regclass AS index_name,
    phase,
    ROUND(
        100.0 * blocks_done / NULLIF(blocks_total, 0),
        2
    ) AS progress_percent
FROM pg_stat_progress_create_index;

This gives you a clean percentage during the main build phase.

When progress appears frozen

Common reasons:

Very small maintenance_work_mem
Disk I/O saturation
WAL bottlenecks
Waiting on long-running transactions (concurrent builds)
CPU-heavy index types (e.g. GIN with trigrams)

If blocks aren’t increasing, check:

SELECT wait_event_type, wait_event
FROM pg_stat_activity
WHERE pid = <index_pid>;

This tells you whether it’s waiting on:

Lock
IO
WAL
Buffer pin
etc.

Estimating total duration

A rough estimate during build:

SELECT
    blocks_done,
    blocks_total,
    now() - backend_start AS elapsed
FROM pg_stat_progress_create_index
JOIN pg_stat_activity USING (pid);

You can extrapolate remaining time from block progress.

Version requirement

pg_stat_progress_create_index is available since:

PostgreSQL 12

If you’re on an older version, you won’t have native progress tracking.

Practical workflow

When building a large index in production:

Run CREATE INDEX (or CONCURRENTLY)
Monitor pg_stat_progress_create_index
Watch for blocking transactions
Track I/O saturation
Increase maintenance_work_mem if needed

This gives you visibility instead of guessing.

Final thoughts

Large index builds are expensive operations. Monitoring progress:

Reduces uncertainty
Helps detect blockers
Allows time estimation
Makes concurrent builds safer in production

If you regularly build large GIN or trigram indexes, having a monitoring query ready in your toolbox saves a lot of stress.

#database #tools #postgresql #sql

🔗 My AI adoption journey

2026-03-08T14:00:00Z

My experience adopting any meaningful tool is that I've necessarily gone through three phases: (1) a period of inefficiency (2) a period of adequacy, then finally (3) a period of workflow and life-altering discovery.

In most cases, I have to force myself through phase 1 and 2 because I usually have a workflow I'm already happy and comfortable with. Adopting a tool feels like work, and I do not want to put in the effort, but I usually do in an effort to be a well-rounded person of my craft.

This is my journey of how I found value in AI tooling and what I'm trying next with it. In an ocean of overly dramatic, hyped takes, I hope this represents a more nuanced, measured approach to my views on AI and how they've changed over time.

This blog post was fully written by hand, in my own words. I hate that I have to say that but especially given the subject matter, I want to be explicit about it.

Continue reading on mitchellh.com

#reading-list #development #ai

🔗 On cognitive debt

2026-03-08T09:00:00Z

People are talking about cognitive debt, the idea that AI-generated codebases are at risk of falling into a state where nobody knows how they work. This threatens to leave them inextensible, unobservable, and hard to debug.

Here's Simon Willison citing Margaret-Anne Storey, as discussed by Martin Fowler.

"Cognitive debt" is a lovely term for this: it describes an important phenomenon that is much to be avoided. It is absolutely happening with AI-driven codebases--the links above have examples, and I've felt it in my own projects.

I suspect, however, that:

When you control for the size and scope of the project, cognitive debt tends to be at least as bad, and usually worse, in pre-AI codebases than in AI codebases;

This fact is obscured because so much of what is normalized as traditional engineering work is in fact either managing crippling cognitive debt or avoiding it at enormous cost;

The best users of AI are already pretty good at avoiding cognitive debt, and we’re only going to get better at it.

Continue reading on www.natemeyvis.com

#reading-list #development #ai

🔗 Upgrading Amignosis: Phoenix and Elixir with Claude Code

2026-03-07T18:00:00Z

My company, Amignosis, website is a simple Phoenix LiveView web app. It was on Phoenix 1.7.21 and Elixir 1.18, and I wanted to upgrade it to Phoenix 1.8.3 and Elixir 1.19. So, I decided to try Tidewave with Claude Code, to do it for me.

Continue reading on petros.blog

#reading-list #ai #elixir #phoenix

🔗 How to run a technical due diligence?

2026-03-07T14:00:00Z

Chances are that in your position as tech leader, you’ve performed technical due diligence on another company.

Or maybe you’ve been on the receiving end, having to answer enquiries from consultants or fellow tech leaders.

Lastly, you might be among those who have never taken part in such a process ever, and you might even wonder what the hell technical due diligence is.

If you’ve always been afraid to ask for fear of looking dumb, you have two options. Linger in your secret ignorance, hoping nobody will find out, or keep reading.

Continue reading on makemeacto.substack.com

#reading-list #development

🔗 Fair queue distribution with Laravel's balanced queue

2026-03-07T09:00:00Z

Laravel Balanced Queue, created by YanGusik, manages queue distribution across user groups with per-user concurrency control and multiple partition strategies to prevent queue monopolization.

Continue reading on laravel-news.com

#reading-list #laravel #php

🔗 Everything I was lied to about Node.js came true with Elixir

2026-03-06T18:00:00Z

I've been a NodeJS developer for a few years now. I loved the simplicity of the language and the community around it. The fact that I could re-use libraries between my frontend and backend was magic. But as my applications grew in complexity, I started to realise much of what I was told about NodeJS was a lie.

Recently I started investigating the Elixir, Erlang, Gleam and BEAM ecosystem. I was impressed by the simplicity and power of the runtime. I realised that much of what people say about NodeJS is actually true about Elixir.

Continue reading on dylans.link

#reading-list #javascript #frontend #elixir

🔗 Go feature: Modernized Go fix

2026-03-06T14:00:00Z

The go fix is re-implemented using the Go analysis framework — the same one go vet uses.

While go fix and go vet now use the same infrastructure, they have different purposes and use different sets of analyzers:

Vet is for reporting problems. Its analyzers describe actual issues, but they don't always suggest fixes, and the fixes aren't always safe to apply.

Fix is (mostly) for modernizing the code to use newer language and library features. Its analyzers produce fixes are always safe to apply, but don't necessarily indicate problems with the code.

See the full set of fix's analyzers in the Analyzers section.

Continue reading on antonz.org

#reading-list #golang #tools

🔗 Things I check before opening a PR

2026-03-06T09:00:00Z

What is a programmer but a series of PRs (pull requests)? I optimize PRs to introduce the best code I can, be easy to review, and document my work so I can make sense of it in the future. Here are some things I always check before opening a PR.

Continue reading on www.jakeworth.com

#reading-list #development #best-practice

🐥 Why prefer const arrow functions over function declarations in TypeScript?

2026-03-05T18:00:00Z

In modern TypeScript codebases, you’ll often see functions defined like this:

const doSomething = (): void => {};

instead of:

function doSomething(): void {}

Both are valid. But there are good reasons why many teams prefer the const + arrow function style as a default.

Predictable execution order

Function declarations are hoisted:

doSomething(); // Works

function doSomething(): void {}

This can hide ordering problems and make large modules harder to reason about.

Arrow functions assigned to const are not callable before initialization:

doSomething(); // ReferenceError

const doSomething = (): void => {};

This makes execution order explicit and avoids subtle refactoring issues.

Immutability by default

Using const makes it clear the function reference should not change:

const doSomething = () => {};

Treating functions as immutable values aligns well with modern TypeScript practices and reduces accidental reassignment.

Safer `this` behavior

Arrow functions use lexical this, meaning they capture this from the surrounding scope.

class Example {
  value = 42;

  method() {
    setTimeout(() => {
      console.log(this.value); // Works
    });
  }
}

With a traditional function, this would be undefined or unexpected unless manually bound. Arrow functions eliminate an entire class of common JavaScript bugs.

Better fit for functional patterns

Arrow functions integrate naturally with higher-order functions:

const double = (x: number) => x * 2;
const result = numbers.map(double);

This style scales well in functional and compositional code.

When to use function declarations

Function declarations still make sense when:

You intentionally rely on hoisting
You want a clearly named recursive function
You define class methods

They’re not wrong — just more situational.

Conclusion

Using const with arrow functions promotes:

Explicit execution order
Immutability
Safer this semantics
Consistency across modern codebases

For most TypeScript projects, it’s a sensible default. Use function deliberately when its behavior is exactly what you need.

#javascript #typescript

🔗 Your Go tests probably don't need a mocking library

2026-03-05T14:00:00Z

No shade against mocking libraries like gomock or mockery. I use them all the time, both at work and outside. But one thing I’ve noticed is that generating mocks often leads to poorly designed tests and increases onboarding time for a codebase.

Also, since almost no one writes tests by hand anymore and instead generates them with LLMs, the situation gets more dire. These ghosts often pull in all kinds of third-party libraries to mock your code, simply because they were trained on a lot of hastily written examples on the web.

So the idea of this post isn’t to discourage using mocking libraries. Rather, it’s to show that even if your codebase already has a mocking library in the dependency chain, not all of your tests need to depend on it. Below are a few cases where I tend not to use any mocking library and instead leverage the constructs that Go gives us.

This does require some extra song and dance with the language, but in return, we gain more control over our tests and reduce the chance of encountering spooky action at a distance.

Continue reading on rednafi.com

#reading-list #golang #testing

🔗 Why senior engineers let bad projects fail

2026-03-05T09:00:00Z

When I was a junior engineer, my manager would occasionally confide his frustrations to me in our weekly 1:1s. He would point out a project another team was working on and say, “I don’t believe that project will go anywhere, they’re solving the wrong problem.” I used to wonder, “But you are very senior, why don’t you just go and speak to them about your concerns?” It felt like a waste of his influence to not say anything.

So it’s quite ironic that I found myself last week explaining to a mentee why I thought a sister team’s project would have to pivot because they’d made a poor early design choice. And he rightfully asked me the same question I had years ago: “why don’t you just tell them your opinion?” It’s been on my mind ever since because I realized I’d changed my stance on it a lot over the years.

The answer is that being right and being effective are different.

In large companies, speaking up about what you see as a “bad project” is a good thing. But only in moderation. Sometimes the mark of seniority is realizing that arguing with people who won’t listen isn’t worth it; it’s better to save your counsel.

Continue reading on lalitm.com

#reading-list #golang #development

🔗 Thinking Elixir podcast 294: compile times, language servers, and Python, oh my!

2026-03-04T18:00:00Z

News includes Expert LSP releasing its first RC, Elixir v1.20 compile time improvements up to 20% faster, Livebook Desktop moving to Tauri with Linux support, a new erlang-python library for ML/AI integration, and more!

Continue reading on podcast.thinkingelixir.com

#reading-list #python #ai #elixir #linux

🔗 Software estimation – building takes longer than you think

2026-03-04T14:00:00Z

For software engineers, this scenario is all-too familiar…

Partner: Hey can we build this feature?

Dev: Yeah that should be easy.

…3 weeks later…

Partner: Hey where’s that feature?

Dev: Turns out there was a bit more to it than we thought.

Why is this so common? When it comes to software estimation, why do we consistently underestimate how long something will take, and more importantly, why do we continue to do so even when we should’ve learned our lesson? Well, it’s more complicated than you think. winks insufferably

Continue reading on revelry.co