🐥 YellowDuck.be

🔗 Claude Code skills: automate repetitive Linux tasks with custom skills

2026-08-24T17:00:00Z

Most people assume Claude Code figures out every task by reading your prompt. However, it can automate repetitive sysadmin tasks using skills—structured folders containing instructions, allowing for rapid execution of recurring tasks. This article delves into the essentials of Claude Code Skills, including installation of pre-built skills from Anthropic’s marketplace, creating custom skills, and testing their effectiveness. Readers will learn how to structure a SKILL.md file effectively, ensuring that Claude identifies and utilizes skills seamlessly. It outlines best practices for writing skills, common mistakes to avoid, and troubleshooting tips to enhance automation and streamline workflows within Linux environments. Whether you're managing repetitive tasks or developing new skills, this guide offers practical advice for leveraging Claude Code effectively in system administration.

Continue reading on www.tecmint.com

#reading-list #best-practice #ai #linux #sysadmin

🔗 Reviewing AI code is not a viable argument

2026-08-24T13:00:00Z

A strong skepticism towards LLM Coding Assistants arises from their fundamental flaws in code generation. Thomas Depierre critically examines the argument that thorough code reviews can mitigate the issues with AI-generated code. He highlights that relying on these tools often feels like mentoring an inexperienced intern. The inherent limitations of LLMs, including inaccuracies and inconsistent performance, lead to excessive human review that may not yield the efficiency promised by proponents. Empirical evidence underscores that a senior developer can only effectively review a limited amount of code in a fixed time frame, severely hampering productivity. As such, the suggestion to simply review all AI-produced code raises more questions about its practicality and effectiveness than it answers. The call for empirical research on the efficiency of human reviewers handling LLM output remains critical for validating such tools' efficacy in software development.

Continue reading on www.softwaremaxims.com

#reading-list #development #best-practice #ai

🔗 A PDF parser from the 80s beats Claude (and they use it internally)

2026-08-24T08:00:00Z

Tesseract, an OCR tool from 1985, outperformed modern AI models when parsing complex PDF files, as highlighted in Fayner Brack's article. After struggling with a scanned CIA PDF using advanced models like those from Google and Anthropic, Brack discovered that Tesseract was ten times faster and more accurate. The article reveals how Claude integrates Tesseract via PyTesseract, relying on a combination of heuristics and manual engineering to achieve optimal results when dealing with different types of PDFs. The best practices for PDF parsing, including diagnostic checks and choosing the right tools for scanned versus born-digital documents, underscore the importance of selecting appropriate technologies. Ultimately, Brack demonstrates that sometimes the oldest tools can be the most effective, challenging the notion that newer models always outperform them. Engineers know the value of utilizing the right tool for each specific task, rather than uniformly applying AI solutions everywhere.

Continue reading on fagnerbrack.com

#reading-list #pdf #best-practice #ai

🔗 Modernizing my dotfiles

2026-08-23T17:00:00Z

The latest update on the author's dotfiles reveals a quest for better organization and efficiency. After almost a decade of use, a recent hardware defect prompted a weekend overhaul focused on improving structure and automation. Goals included cleaning folder structures, updating the Brewfile, and creating a private repo for sensitive configurations like SSH keys. The author drew inspiration from other dotfile experts, simplifying their setup while utilizing tools like Dotbot for symlinks. This modernized system now incorporates AI-driven scripts for smoother workflows and aims to package all settings for version control. The meticulous effort transforms their configurations into a more maintainable and user-friendly setup for future projects.

Continue reading on stefanzweifel.dev

#reading-list #tools #git #mac #dotnet

🔗 How to achieve pruning when querying by non-partitioned columns in PostgreSQL

2026-08-23T13:00:00Z

Can querying by non-partition key columns really benefit from partition pruning in PostgreSQL? This article details techniques to improve performance when filtering by non-partition key columns, using practical examples to illustrate how clever indexing and database constraints can lead to effective pruning. The author highlights key strategies—like utilizing local indexes and communicating with the database optimizer through check constraints—to achieve significant performance gains. Insights are drawn from a real-world scenario where event logging across multiple partitions showcases the challenges and solutions offered by a well-structured database design. Readers interested in optimizing PostgreSQL queries for better speed and efficiency will find this guide particularly useful.

Continue reading on hakibenita.com

#reading-list #database #best-practice #postgresql

🔗 Sanding UI

2026-08-23T08:00:00Z

Sanding UI explores a practical approach to refining user interfaces through hands-on testing. Jim Nielsen emphasizes the importance of iterative clicking to identify and address subtle usability issues in web development. One example highlights a common UI problem where a gap created by flexbox led to an unresponsive area between a radio button and its label. Instead of utilizing a gap, he fixed this by applying padding directly to the label, ensuring full interaction. Nielsen likens this process to woodworking, honing a piece until it feels right. His method encourages developers to embrace the tactile nature of UI design, repeatedly testing and refining until the experience feels seamless. This piece resonates with developers looking to enhance UX by focusing on the small, often overlooked details that impact user engagement and satisfaction.

Continue reading on blog.jim-nielsen.com

#reading-list #frontend #css #best-practice

🐥 Faster, leaner MySQL backups and restores with mysqldump

2026-08-22T17:00:00Z

mysqldump is a perfectly fine tool for many production workloads — until your database grows large enough that backups take too long and restores take even longer. Before you reach for a more exotic solution, there are several flags and session-level variables that can make a meaningful difference with zero infrastructure changes.

This article focuses on plain MySQL, but shows where to wire up these settings when you use spatie/laravel-backup and stefanzweifel/laravel-backup-restore in a Laravel project.

Where to configure this in Laravel

Both packages read dump and restore options from config/database.php, inside the dump key of your connection:


// config/database.php
'mysql' => [
    // ... standard connection settings ...
    'dump' => [
        'excludeTables' => [...],
        'useSingleTransaction' => true,
        'add_extra_option' => '...', // passed to mysqldump (backup)
        'options' => '...',          // passed to mysql client (restore)
    ],
],

add_extra_option is forwarded to mysqldump by spatie/laravel-backup.
options is forwarded to the mysql client by laravel-backup-restore.

Everything below maps directly to one of those two keys.

Dump-time optimisations

Exclude noisy, non-essential tables

Some tables accumulate millions of rows that are useful for debugging but worthless in a restore. Excluding them shrinks the dump file and cuts restore time dramatically.


'excludeTables' => [
    'telescope_entries',
    'telescope_entries_tags',
    'telescope_monitoring',
],

Laravel Telescope is the classic example: it can easily outweigh the rest of your schema combined.

Use a single transaction

--single-transaction

In spatie/laravel-backup this is:


'useSingleTransaction' => true,

This wraps the dump in a START TRANSACTION so InnoDB tables are read from a consistent snapshot without locking them. Essential for any live database.

Increase `--net-buffer-length`

--net-buffer-length=16777216   # 16 MB (default is 1 MB)

mysqldump groups rows into multi-row INSERT statements. The default maximum per statement is 1 MB. Raising it to 16 MB reduces the total number of statements in the file, which directly cuts parse and execution time during a restore.

Pair it with --max_allowed_packet on the server side:

--max_allowed_packet=512M

Without this, large packets are silently rejected.

Skip unnecessary LOCK/UNLOCK statements

--skip-add-locks

mysqldump normally wraps each table dump in LOCK TABLES … WRITE / UNLOCK TABLES. This is redundant when you are already using --single-transaction and when you disable table locking at restore time (see below). Removing these statements makes the dump file smaller and the restore faster.

Suppress MySQL 8 column statistics

--column-statistics=0

MySQL 8's mysqldump emits ANALYZE TABLE statements to update column statistics after each table is imported. On large tables these can block progress noticeably. If you run your own statistics collection after a restore, suppress them.

Compress the dump on the wire

--compression-algorithms=zlib

Compresses data in transit between mysqldump and the MySQL server. Useful when the client and server are on separate hosts, reducing network I/O. For socket connections the benefit is minimal, but there is no downside.

Skip binary log tracking (GTID)

--set-gtid-purged=OFF

If you use GTID-based replication, mysqldump normally writes SET @@GLOBAL.gtid_purged into the dump. During a restore this can conflict with an existing gtid_executed set. Passing OFF omits that statement and keeps restores clean on secondary or development databases.

Avoid table-level locks

--lock-tables=false

When using --single-transaction, table-level locking is already unnecessary. Explicitly disabling it avoids a redundant flush.

Use `--quick` for large tables

--quick

By default mysqldump buffers an entire table in memory before writing. --quick streams one row at a time, keeping memory usage flat regardless of table size. Always enable it for any production database.

Restore-time optimisations

These are passed to the mysql client via an --init-command, which MySQL executes before the dump is processed:

SET sql_log_bin=0;
SET foreign_key_checks=0;
SET unique_checks=0;
SET autocommit=0;

In config/database.php:


'options' => '--init-command="SET sql_log_bin=0; SET foreign_key_checks=0; SET unique_checks=0; SET autocommit=0;"',

`SET sql_log_bin=0`

Disables binary logging for the session. There is no point logging every INSERT from a dump file into the binlog — it inflates the binlog and slows the restore. Safe when you control the import and are not relying on the binlog to propagate changes to replicas. This also reduces the amount of disk space needed for the restore.

`SET foreign_key_checks=0`

MySQL enforces referential integrity row-by-row during inserts. In a full dump, the parent and child rows are all present — you just may not have inserted the parent yet when a child arrives. Disabling this check lets MySQL trust the dump and skip the per-row lookups, which is one of the most impactful restore optimisations available.

Re-enable it (or restart the session) after the restore to verify the restored data is consistent.

`SET unique_checks=0`

Similar rationale: MySQL normally verifies unique constraints on every insert. A correctly generated dump has no duplicates, so this check is redundant overhead. Disabling it reduces index update cost during the restore.

`SET autocommit=0`

Turns off the implicit COMMIT after every statement. Combined with the large INSERT batches produced by --net-buffer-length, this means the storage engine can batch many rows into a single transaction, dramatically reducing fsync pressure.

Putting it together


// config/database.php
'dump' => [
    'excludeTables' => [
        'telescope_entries',
        'telescope_entries_tags',
        'telescope_monitoring',
    ],
    'useSingleTransaction' => true,
    'add_extra_option' => '--set-gtid-purged=OFF --lock-tables=false --quick'
        . ' --max_allowed_packet=512M --net-buffer-length=16777216'
        . ' --compression-algorithms=zlib'
        . ' --skip-add-locks --column-statistics=0',
    'options' => '--init-command="SET sql_log_bin=0; SET foreign_key_checks=0; SET unique_checks=0; SET autocommit=0;"',
],

These settings are safe for the vast majority of production MySQL 8 setups. The restore-side flags assume you trust the dump and will verify data integrity via application-level health checks afterwards — which is standard practice regardless of how you import.

The backup side produces a smaller file, faster. The restore side skips redundant constraint checking and batches commits. Together they can reduce both phases by a significant margin without changing anything about your infrastructure or your backup tooling.

More info

#laravel #best-practice #mysql #devops

🔗 Why Elixir is the best language for LLMs

2026-08-22T13:00:00Z

On a significant benchmark, Elixir outperformed all other languages in large language model (LLM) problem-solving capabilities. Despite being a low-resource language compared to Python or JavaScript, Elixir achieved a 97.5% success rate in solving problems, vastly ahead of second-place Kotlin at 89.5%. The article highlights the strengths of Elixir, including immutability, verified documentation, and a stable ecosystem, all contributing to its efficacy in LLM contexts. The author points out that these features allow models to effectively reason about code, making Elixir an excellent choice for AI-assisted programming.

Continue reading on codemyspec.com

#reading-list #development #ai #elixir

🔗 The Go architecture behind intelligence API

2026-08-22T08:00:00Z

Can a Go-powered authentication layer achieve sub-50ms P99 latency? Autheona claims it can, using advanced concurrency techniques and local SQLite caching. The article dives into their architecture, which eliminates bottlenecks by executing multiple validation checks concurrently via Goroutines, avoiding traditional I/O delays. By replacing external database calls with a custom in-memory policy management tree and deploying asynchronous PostgreSQL batching, they demonstrated speed and scalability, even under heavy load. They also explained the economic implications of latency for businesses, revealing potential revenue losses due to increased authentication processing times. The detailed breakdown of their system architecture, including the use of AWS Graviton instances and embedded SQLite, highlights how efficiency and smart design can drastically improve user experience and conversion rates. This is a must-read for developers keen on optimizing backend performance for high-concurrency applications.

Continue reading on autheona.com

#reading-list #golang #development #database #devops #auth

🔗 First-party image processing in Laravel 13.20

2026-08-21T17:00:00Z

Laravel 13.20 introduces first-party image processing through an immutable, driver-based API for transforming images. This new functionality allows developers to handle uploads, storage, URLs, and raw bytes directly in the framework without relying on third-party libraries. The Image facade provides methods for various transformations like resizing, cropping, and format conversion while ensuring that each transformation returns a new instance. Additionally, enhancements such as a #[WithoutMiddleware] controller attribute and separate Redis prefixes for sessions make for a more efficient development experience. This release builds upon the existing Eloquent and queue functionality with features designed to streamline image handling and improve application organization.

Continue reading on laravel-news.com

#reading-list #development #laravel #php

🔗 Work loudly

2026-08-21T13:00:00Z

Working remotely strips away visibility, making it harder to showcase contributions effectively. "Invisible work is, for every practical purpose—promotion, credit, getting pulled into the interesting projects—work that didn’t happen," notes Ben Balter. He emphasizes the importance of working loudly, making one's work visible in real time rather than in a post-project summary. By sharing issues, PRs, and progress updates publicly, individuals invite collaboration and prevent miscommunication that can occur when decisions are made behind closed doors. Visible work leads to better recognition and helps others contribute effectively, breaking the cycle of solitary problem-solving. Those who navigate this landscape successfully can transform their careers and their teams by ensuring their efforts are noted and valued as they happen, rather than waiting for a performance review. This article advocates for proactively communicating work to build a stronger professional presence and collaborative environment.

Continue reading on ben.balter.com

#reading-list #development #best-practice

🔗 The git history command deserves more attention

2026-08-21T08:00:00Z

The git history command is an experimental feature that simplifies managing changes in Git. It includes three subcommands: fixup, reword, and split. The fixup command allows users to correct an old commit while automatically updating all branches that contain that commit. reword lets users edit an old commit message and intelligently rebases dependent changes. Lastly, split enables interactive selection of changes from a commit, dividing it into smaller commits. These features enhance user experience without switching to alternatives like jj and are integrated into the core Git distribution. Despite having limitations, git history offers significant improvements for managing a Git workflow and holds promise for future enhancements as user needs evolve.

Continue reading on lalitm.com

#reading-list #development #best-practice #git

🐥 Speeding up our PHP test suite with a GitHub Actions matrix strategy

2026-08-20T17:00:00Z

Our test suite had become a bottleneck. Every push to develop or main triggered three separate CI jobs — unit tests, feature tests, and integration tests — each running sequentially after the previous one finished and each downloading the same apt packages from scratch. The result: slow feedback loops and a lot of redundant work.

This post walks through the changes we made to fix that.

The Problem: Three Jobs, Lots of Duplication

Before this change, the CI pipeline defined three independent jobs:

phpunit-unit:
  name: "PHP Unit Tests"
  steps:
    - name: Install packages
      run: |
        sudo apt update
        sudo apt install -y package-a package-b package-c
    - name: Execute tests
      run: php artisan test --parallel tests/Unit

phpunit-feature:
  name: "PHP Feature Tests"
  steps:
    # same apt install block...
    - name: Execute tests
      run: php artisan test --parallel tests/Feature

phpunit-integration:
  name: "PHP Integration Tests"
  steps:
    # same apt install block again...
    - name: Execute tests
      run: php artisan test --parallel tests/Integration

Each job was:

Checking out the repo independently
Setting up PHP independently
Installing Composer dependencies independently (even with caching, cache restores take time)
Running apt-get install with the same packages — every single time, with no caching

Step 1: Collapsing Three Jobs into a Matrix

The first change replaced the three separate job definitions with a single phpunit job that uses GitHub Actions' matrix strategy:

phpunit:
  name: "PHP Tests (${{ matrix.suite }})"
  runs-on: ubuntu-latest
  strategy:
    fail-fast: false
    matrix:
      include:
        - suite: unit-a
        - suite: unit-b
        - suite: feature-a
        - suite: feature-b
        - suite: Integration

All suites run in parallel, with fail-fast: false so a failure in one suite doesn't cancel the others mid-run.

The Execute tests step became a single parameterised command:

- name: Execute tests
  run: php artisan test --parallel --testsuite=${{ matrix.suite }} --coverage-clover test-coverage/coverage-${{ matrix.suite }}.xml

Why More Suites Instead of Fewer?

The original split was coarse: all unit tests ran together, and all feature tests ran together. One large bucket would hold everything up even when most of the tests in it finished quickly.

By naming suites explicitly in phpunit.xml, we got finer-grained parallelism:

<testsuite name="unit-a">
  <directory suffix=".php">./tests/Unit/GroupAdirectory>
testsuite>
<testsuite name="unit-b">
  <directory suffix=".php">./tests/Unit/GroupBdirectory>
  <directory suffix=".php">./tests/Unit/GroupCdirectory>
testsuite>
<testsuite name="feature-a">
  <directory suffix=".php">./tests/Feature/GroupAdirectory>
testsuite>
<testsuite name="feature-b">
  <directory suffix=".php">./tests/Feature/GroupBdirectory>
  <directory suffix=".php">./tests/Feature/GroupCdirectory>
testsuite>

This keeps each matrix leg roughly balanced in terms of test count and makes the overall wall-clock time shorter than when one slow bucket holds everything up.

Step 2: Caching apt Packages

The most wasteful part of the old setup was reinstalling the same system packages on every runner, for every job, from scratch. apt-get install isn't slow in absolute terms, but multiplied across five parallel jobs and every CI run, it adds up.

We replaced the raw apt install block with awalsh128/cache-apt-pkgs-action:

- name: Install packages
  uses: awalsh128/cache-apt-pkgs-action@latest
  with:
    packages: package-a package-b package-c
    version: ${{ hashFiles('.apt-packages') }}

The version key is tied to a .apt-packages lockfile committed to the repo. The cache is invalidated only when that file changes — not on every push — so the common case is a fast cache hit rather than a full install.

Any post-install configuration that previously lived inside the install block becomes its own named step. The action calls it only on a cache miss, so it doesn't run unnecessarily on cache hits:

- name: Post-install configuration
  run: # your configuration command here

The Downstream Effect: Coverage Merging

Any job that previously depended on the three separate job names now depends on the single phpunit job:

some-downstream-job:
  needs: [
    "phpunit",   # was: phpunit-unit, phpunit-feature, phpunit-integration
    ...
  ]

And the coverage merge step includes one file per suite:

./clover-merge -o coverage.xml \
  unit-a/coverage-unit-a.xml \
  unit-b/coverage-unit-b.xml \
  feature-a/coverage-feature-a.xml \
  feature-b/coverage-feature-b.xml \
  integration/coverage-integration.xml

What This Changes

Before	After
3 jobs, one per test type	5 jobs, all parallel
`apt install` on every run, every job	Cached apt packages, invalidated only on lockfile change
Coarse path-based test selection	Named testsuites in `phpunit.xml`
~3× duplicated job boilerplate	Single parameterised job definition

The wall-clock time for the PHP test stage drops because the legs run concurrently and the apt install step is usually a cache hit. Maintenance is easier too — adding a new suite is a two-line change: one entry in phpunit.xml and one entry in the matrix include list.

#php #devops #github #testing

🔗 Learning Elixir: Error Handling with try/rescue/catch/after

2026-08-20T13:00:00Z

Error handling in Elixir can be approached with two toolkits for different scenarios. try, catch, rescue, and after serve as a safety net for unexpected failures, while tagged tuples like {:ok, value} and {:error, reason} are for predictable issues. Elixir 1.20.1 introduces constructs that allow developers to handle exceptions like RuntimeError and ArgumentError. Understanding when to use these tools is essential since overusing them contradicts Elixir's philosophy of "let it crash." This article covers practical guidelines for implementing error handling effectively, demonstrating how to rescue exceptions, define custom error types, and clean up after errors gracefully.

Continue reading on dev.to

#reading-list #development #best-practice #elixir

🔗 Film: Final Frontier Patagonia

2026-08-20T08:00:00Z

100 riders journeyed through 3,000 kilometers in 24 days, traversing one of the world's last great wildernesses. The film SouthBound captures the spirit of the inaugural edition of Final Frontier Patagonia, featuring cyclists who faced unimaginable physical and mental challenges as they made their way to Ushuaia. It’s more than just a biking adventure; it’s a powerful tale of endurance, friendship, and the unyielding human spirit amid Patagonia's breathtaking landscapes. Each rider's story reflects not just the road challenges, but the internal battles we all face in pursuit of our dreams.

Continue reading on www.gravelstoke.com

#reading-list #sports

🔗 Learning a few things about running SQLite

2026-08-19T17:00:00Z

SQLite may seem simple, but it's a full-fledged database that can be complex. After using it on a Django project, the author highlights several lessons learned. Key takeaways include the importance of running ANALYZE to significantly improve query speed, especially for larger datasets. Initially surprised by slow queries, the author found that this one command transformed a 5-second wait into a mere 0.05 seconds. The write locks became problematic during clean-up tasks, prompting the use of smaller batches. Additionally, the author shares backup strategies using restic and litestream, revealing the challenges of managing backups effectively. Despite its simplicity, ongoing learning with SQLite proves essential for better database management.

Continue reading on jvns.ca

#reading-list #database #best-practice #django #sqlite

🔗 Git rebase -i is not that scary

2026-08-19T13:00:00Z

The fear of git rebase -i often grips junior developers, but it’s time to demystify its true nature. When executing git rebase -i HEAD~4, nothing destructive happens immediately; it only opens a text file where you can manage commits. This process is essentially a plan to revise commit history, and everything can be undone with git rebase --abort if needed. The article clarifies how rebasing creates new commits while preserving the old ones, accessible via git reflog. Conflicts during a rebase are unavoidable but are often easier to resolve since they involve only one commit at a time. Developers are encouraged to explore interactive rebasing freely, particularly during their own feature branch development, to maintain a clean project history. Understanding this tool can significantly enhance a developer's confidence and efficacy with Git, making the workflow smoother and more efficient.

Continue reading on cachebag.sh

#reading-list #development #best-practice #git

🔗 The integration loop

2026-08-19T08:00:00Z

Handing everyone an LLM subscription gives them a model. A shared, self-hosted agent provides a configured environment with company context, connected tools, and clear boundaries. The article argues why companies should own this layer rather than rent it, outlining practical steps to start small. With implementation costs decreasing, businesses now face the challenge of deciding what is worth building. This shift calls for more autonomy and faster iteration, emphasizing that judgment and decision-making are increasingly valuable in the development process.

Continue reading on madewithlove.com

#reading-list #development #best-practice #ai

🔗 Supercharge your PHP apps with Go-powered PHP extensions

2026-08-18T17:00:00Z

Can PHP really become faster without diving into C? In this article, Alexandria Daubois explores how Go-powered PHP extensions can enhance performance in Laravel and Symfony apps. The talk showcases building a custom PHP extension using FrankenPHP, eliminating the need for C code. Daubois details the creation of an in-memory LRU cache and how to integrate it as a native feature in Laravel through a custom cache driver. Readers can expect a hands-on approach focusing on real code and PHP internals, gaining insight into the flexibility of both frameworks and PHP's core runtime. This exploration hints at the immense potential for boosting performance in PHP applications without traditional complexities.

Continue reading on phpconference.nl

#reading-list #golang #development #laravel #php

🔗 Go releases are exciting (especially 1.27)

2026-08-18T13:00:00Z

Go 1.27 introduces some thrilling changes and enhancements for developers. It offers improved performance and new features that make developing applications even more efficient. One notable inclusion is the capability to handle generics more effectively, streamlining code and reducing the boilerplate necessary for complex types. The focus on performance optimizations ensures that applications run faster, enhancing user experiences. As Go continues to evolve, the latest release proves to be a useful upgrade that developers will appreciate.

Continue reading on kerkour.com

#reading-list #golang #announcement

🔗 Laravel facade pattern explained: build your own custom facade

2026-08-18T08:00:00Z

The article dives deep into how Laravel's facade pattern operates and its significance in the framework’s architecture. The commonly used facades, which may appear as static method calls, actually resolve to real objects in Laravel’s Service Container. This structure not only simplifies code readability but also enhances the framework's testability and flexibility. Readers learn about facades' inner workings, why they're not static, and when they're the right choice. The piece culminates in a practical guide on creating a custom facade, helping developers grasp both the theoretical and practical aspects of facades in Laravel. By the end, developers are equipped with the knowledge to use and implement facades efficiently, ultimately fostering a better understanding of Laravel's dependency injection and service management systems.

Continue reading on laraveldailytips.com

#reading-list #development #pattern #laravel

🐥 Advanced debugging in Elixir with IO.inspect

2026-08-17T17:00:00Z

When writing Elixir, most developers quickly get familiar with IO.inspect/2 as a quick way to see what's happening inside their code. But what many overlook is that IO.inspect is far more powerful than just "print this variable to the console."

In fact, with the right options and placement, IO.inspect can become a precise, highly targeted debugging tool, one that doesn't interrupt your program flow and works seamlessly with Elixir's functional pipelines.

This post will walk through both the fundamentals and advanced patterns for using IO.inspect effectively. By the end, you'll know how to control output formatting, label your prints for clarity, debug concurrent processes, and even integrate conditional or file-based inspection.

The Basics of `IO.inspect`

IO.inspect is defined like this:

IO.inspect(item, opts \\ [])

item: any Elixir value you want to inspect.
opts: keyword list of options for controlling how the term is printed as defined in Inspect.Opts.

By default, it writes the inspected value to the standard output (:stdio) and then returns the term unchanged.

That last part is key. Because it returns the term, you can drop it anywhere in a function or pipeline without breaking the flow.

Example:

defmodule Demo do
  def run do
    IO.inspect(%{name: "Alice", age: 30})
  end
end

Prints:

%{age: 30, name: "Alice"}

Caveat: When `IO.inspect` Is the Last Call in a Function

Because IO.inspect returns its argument, it also means that if it's the last expression in your function, that inspected value becomes the function's return value.

That's fine if you intend to return it, but it can lead to subtle bugs if you were only printing it for debugging and expected a different return.

Take this example:

def fetch_user(id) do
  Repo.get(User, id)
  |> IO.inspect(label: "Fetched user")
end

Here, the function returns the user struct as normal, which is fine.

Now, consider:

def log_and_return do
  IO.inspect("Done!")
end

This returns "Done!" instead of, say, :ok.

If you want to print something but return a different value, make the return explicit:

def log_and_return do
  IO.inspect("Done!")
  :ok
end

Or if you're in a pipeline:

value
|> IO.inspect(label: "Debug")
|> do_something_else()

Rule of thumb: if IO.inspect is the last expression in a function, be explicit about what you want to return.

Strategic Placement With the Pipe Operator

Because IO.inspect returns its argument, it fits perfectly in the middle of a pipeline:

users
|> IO.inspect(label: "Before filtering")
|> Enum.filter(& &1.active)
|> IO.inspect(label: "After filtering")
|> Enum.map(& &1.name)

This lets you peek into the data flow at exactly the point you want, without rewriting your code into intermediate variables.

A neat trick is to place multiple IO.inspect calls at different stages, each with a distinct label, so you can see how the data changes step by step.

Using Labels for Clarity

Without labels, multiple inspection outputs can be hard to tell apart. The label option solves this:

IO.inspect(data, label: "After filtering")

Prints:

After filtering: [%{name: "Alice"}, %{name: "Bob"}]

When debugging a pipeline with several inspect points, labels make the output self-describing. This is especially useful when you're debugging multiple similar data structures in the same run.

Pretty Printing and Formatting Output

Sometimes, especially with large maps or deeply nested lists, the default single-line output is hard to read. That's where formatting options defined in Inspect.Opts come in.

Option	Description	Default
`:pretty`	if set to `true` enables pretty printing.	`false`
`:limit`	limits the number of items that are inspected for tuples, bitstrings, maps, lists and any other collection of items, with the exception of printable strings and printable charlists which use the `:printable_limit` option. If you don't want to limit the number of items to a particular number, use `:infinity`. It accepts a positive integer or `:infinity`.	`50`
`:printable_limit`	limits the number of characters that are inspected on printable strings and printable charlists. You can use `String.printable?/1` and `List.ascii_printable?/1` to check if a given string or charlist is printable. If you don't want to limit the number of characters to a particular number, use `:infinity`. It accepts a positive integer or `:infinity`.	`4096`
`:width`	number of characters per line used when pretty is `true` or when printing to IO devices. Set to `0` to force each item to be printed on its own line. If you don't want to limit the number of items to a particular number, use `:infinity`.	`80`
`:charlists`	when `:as_charlists` all lists will be printed as charlists, non-printable elements will be escaped. When `:as_lists` all lists will be printed as lists. When the default `:infer`, the list will be printed as a charlist if it is printable, otherwise as list. See `List.ascii_printable?/1` to learn when a charlist is printable.	`:infer`

Example:

data = for i <- 1..100 do
  %{id: i, value: String.duplicate("x", i)}
end

IO.inspect(data, pretty: true, limit: 5)

Prints:

[
  %{id: 1, value: "x"},
  %{id: 2, value: "xx"},
  %{id: 3, value: "xxx"},
  %{id: 4, ...},
  %{...},
  ...
]

Here, we can see the first five entries, and the rest are summarized with ....

Coloring and Styling Output

Elixir's inspect options support syntax coloring, very handy when your terminal is full of logs.

Example:

IO.inspect(data,
  syntax_colors: [
    atom: :blue,
    string: :green,
    number: :red
  ],
  pretty: true
)

This makes atoms blue, strings green, and numbers red in your console output.

Colors can be any IO.ANSI.ansidata/0 as accepted by IO.ANSI.format/1.

If you want to use the default colors (like what is used in IEx), you can use IO.ANSI.syntax_colors/0:

IO.inspect(data,
  syntax_colors: IO.ANSI.syntax_colors(),
  pretty: true
)

Note: The colors are only visible if your terminal supports ANSI colors.

Conditional Inspection

Sometimes you want to inspect only if a certain condition is true, for example, when a debug flag is enabled or when a value crosses a threshold.

Here's an example with a debug flag:

def debug(term) do
  if Application.get_env(:my_app, :debug) do
    IO.inspect(term, label: "Debug")
  end
  term
end

You can use this function like this:

users
|> Enum.filter(& &1.active)
|> debug()
|> Enum.map(& &1.name)

You can toggle the output by setting config :my_app, :debug, true or false.

Capturing Inspect Output Instead of Printing

If you want to get the inspected form of a value without printing it, use inspect/2 (without the IO. prefix):

string_representation = inspect(data, pretty: true)

This is useful if you want to:

Write the debug output to a file
Send it to a logging service
Include it in an exception message

Example:

File.write!("debug.log", inspect(data, pretty: true))

You can also redirect IO.inspect output to another device:

IO.inspect(data, label: "Debug", device: :stderr)

Debugging Concurrency and Async Code

When you use IO.inspect in asynchronous code, the output may arrive out of order, making it hard to follow. Adding identifiers or timestamps can help.

Example:

tasks =
  for id <- 1..3 do
    Task.async(fn ->
      IO.inspect(self(), label: "PID #{id}")
      :timer.sleep(100)
      id * id
    end)
  end

Enum.map(tasks, &Task.await/1)

Prints:

PID 3: #PID<0.112.0>
PID 2: #PID<0.111.0>
PID 1: #PID<0.110.0>

Including the PID or a unique request ID in your label helps you trace which output belongs to which process.

Advanced Trick: Inspecting and Pattern Matching in One Go

You can combine pattern matching with inspection to see exactly what's being matched:

%{id: id} = IO.inspect(user, label: "User before insert")

This inspects the user variable before pattern matching extracts the id.

You can also place IO.inspect inside a guard to conditionally print:

case user do
  %{role: :admin} = u -> IO.inspect(u, label: "Admin user")
  _ -> :ok
end

In this last example, "Admin user" will only be printed if the user has the role :admin.

Using `dbg/2` for Richer Inspection

Since Elixir 1.14, we have dbg/2, a built-in debugging helper that works like IO.inspect but also shows the code expression that produced the value.

You can use it like this:

users |> Enum.filter(& &1.active) |> dbg()

Which prints:

users #=> [%{active: false, name: "Alice"}, %{active: true, name: "Bob"}]
|> Enum.filter(& &1.active) #=> [%{active: true, name: "Bob"}]

This makes it much easier to understand where in your code the inspected value is coming from, especially when you're inspecting multiple similar-looking values.

You can also pass options similar to IO.inspect:

dbg(users, label: "Active users", pretty: true)

Here are the key differences with IO.inspect:

Shows the code expression automatically.
Output format is slightly more verbose.
Same return behavior, returns the inspected value, so you can keep it in a pipeline.
Best for interactive debugging during development.

When `IO.inspect` Is Not Enough

While IO.inspect is a fantastic quick-and-dirty tool, there are times when you need more powerful debugging:

IEx.pry: drops you into an interactive REPL inside the running process.
:observer.start/0: Erlang's GUI for monitoring processes, memory, and more.

The trick is to know when to reach for IO.inspect and when to switch to one of these other tools.

Setting Default Options for `IO.inspect` in IEx

When using IEx, you can configure the default options for IO.inspect. You can do this using the IEx.configure/1 function:

IEx.configure(
  colors: [
    syntax_colors: [
      number: :light_yellow,
      atom: :light_cyan,
      string: :light_black,
      boolean: :red,
      nil: [:magenta, :bright]
    ],
    ls_directory: :cyan,
    ls_device: :yellow,
    doc_code: :green,
    doc_inline_code: :magenta,
    doc_headings: [:cyan, :underline],
    doc_title: [:cyan, :bright, :underline]
  ]
)

You can easily put this in your .iex.exs file so that it's applied automatically every time you open the shell.

Creating a Reusable Inspect Helper

Here's a neat way to wrap IO.inspect/2 into your own helper module with preferred defaults. This way, you can keep consistent inspection output without repeating options everywhere:

defmodule MyApp.Debug do
  @moduledoc """
  Convenience wrapper around `IO.inspect/2` with sensible defaults.
  """

  @default_opts [
    label: "DEBUG",
    pretty: true,
    limit: :infinity,
    width: 120,
    syntax_colors: IO.ANSI.syntax_colors()
  ]

  @doc """
  Inspects a value with default debug options.

  This is pipe-friendly: it returns the given value unchanged
  after inspecting it.

  ## Examples

      iex> [1, 2, 3]
      ...> |> Enum.map(&(&1 * 2))
      ...> |> MyApp.Debug.inspect()
      [2, 4, 6]
  """
  def inspect(term, opts \\ []) do
    term
    |> IO.inspect(Keyword.merge(@default_opts, opts))
  end
end

You can use it like this:

result =
  users
  |> Enum.filter(&(&1.active?))
  |> MyApp.Debug.inspect(label: "Active users")
  |> Enum.map(& &1.name)
  |> MyApp.Debug.inspect(label: "User names")

This way:

You get pretty printing (pretty: true) by default.
Lists and maps are not truncated (limit: :infinity).
A label is always shown (DEBUG unless overridden).
You can still override any option per call.
It works fine when it's in a pipeline.

Handy Visual Studio Code snippets

To make using IO.inspect faster and more consistent, you can configure editor snippets in Visual Studio Code so you don't have to type repetitive boilerplate each time.

In Visual Studio Code, open:

Code -> Settings… -> Configure Snippets -> Elixir

and add the following snippet definitions:

{
  "inpsect": {
    "prefix": "lin",
    "body": "IO.inspect($1, label: \"$1\", pretty: true)",
    "description": "IO.inspect with label."
  },
  "inpsectSelectedText": {
    "prefix": "sin",
    "body": "IO.inspect($TM_SELECTED_TEXT, label: \"${TM_SELECTED_TEXT/(.*)/${1:/upcase}/}$0\", pretty: true)",
    "description": "IO.inspect with selected text as label."
  },
  "pipeInspect": {
    "prefix": "pin",
    "body": "|> IO.inspect(label: \"$1\", pretty: true)",
    "description": "IO.inspect with pipe."
  },
  "pipeInspectWithFileReference": {
    "prefix": "pinf",
    "body": "|> IO.inspect(label: \"$TM_FILEPATH:$TM_LINE_NUMBER$0\", pretty: true)",
    "description": "IO.inspect with pipe and file reference."
  },
  "inspectFromClipboard": {
    "prefix": "cin",
    "body": "IO.inspect($CLIPBOARD, label: \"${CLIPBOARD/(.*)/${1:/upcase}/}$0\", pretty: true)",
    "description": "IO.inspect clipboard content."
  }
}

With these in place, you'll have short prefixes to insert commonly used IO.inspect/2 patterns:

Prefix	Description
`lin`	`IO.inspect` with label
`sin`	`IO.inspect` using selected text as label
`pin`	`IO.inspect` in a pipeline
`pinf`	`IO.inspect` in a pipeline with file and line reference
`cin`	`IO.inspect` clipboard content

This way, you can quickly drop in debug output with consistent formatting, colors, and labels, without breaking your flow.

Suppose you are transforming a list of user maps and want to check intermediate results inside a pipeline:

users
|> Enum.filter(&(&1.active))
|> IO.inspect(label: "After filter", pretty: true)
|> Enum.map(& &1.email)

With the snippet defined above, you don't have to type all that. Just type pin, hit Tab, and you get:

|> IO.inspect(label: "", pretty: true)

You can immediately type your label (e.g. "After filter") and continue coding. This keeps your debugging consistent, colorful, and fast, without breaking your flow.

Best practices

Use labels liberally, unlabeled output is harder to parse.
Limit output for large collections, use limit and pretty.
Avoid leaving it in production unless intentional.
Wrap it in helper functions when you want conditional control.
Tag concurrent output with PIDs, timestamps, or request IDs.
Credo can be used to detect unintentional calls to IO.inspect in a CI/CD pipeline.

Conclusion

IO.inspect may look like a humble debugging tool, but in Elixir it's a powerful way to see what's going on without breaking your code's flow. By combining it with labels, formatting, conditional output, and process context, you can get precise insights into your program's behavior, all without leaving your editor.

#pattern #best-practice #elixir

🔗 My notes on three years of coding with AI

2026-08-17T13:00:00Z

How has AI shaped the coding landscape over three years? Mike Zornek shares his journey from casual use to heavy reliance on tools like Copilot and Claude Code. Starting with a light-hearted rap song generated in 2023, Zornek transitioned to utilizing AI for actual development tasks while grappling with the ethical implications of AI-generated pull requests. Throughout this time, he emphasized the importance of human oversight and the need for clear communication about AI's role in the coding process. His experiences reveal both the challenges and opportunities presented by AI in software engineering, encouraging engineers not just to adapt but to actively engage with these emerging technologies as they evolve.

Continue reading on mikezornek.com

#reading-list #development #best-practice #ai

🔗 1Password for Claude: give Claude access without giving up your credentials

2026-08-17T08:00:00Z

AI agents are evolving into powerful tools that can perform tasks on behalf of users, but the challenge of securely accessing accounts remains. The article introduces 1Password for Claude, which allows Claude to complete browser tasks that require logins without exposing user credentials. Built on a zero-exposure architecture, it ensures that credentials are not stored in the model, and every authentication request requires user consent. This innovative approach aligns with a new security model where users can grant AI agents the access they need for specific tasks while keeping credentials invisible to the agent.

Moreover, the Agentic Mode feature enhances control when AI agents operate within browsers, ensuring that only approved logins are accessible. This approach safeguards against unauthorized access and maintains user trust. As AI capabilities grow, adopting governed access strategies like those offered by 1Password is crucial for maintaining security in a collaborative digital landscape.

Continue reading on 1password.com

#reading-list #best-practice #ai #auth

🔗 Detecting full table scans with SQLite

2026-08-16T17:00:00Z

What if you could detect full table scans in SQLite effortlessly? The article dives into how SQLite collects information about prepared statements, allowing developers to figure out if a query caused a full table scan after it was executed. This could have been beneficial for lobste.rs during a recent performance issue. With practical code examples, the author shows how to create a table, insert records, and utilize the statement statistics to check for full scans. By adding indices, the performance improves instantly, as demonstrated with another query. There’s also a thought-provoking suggestion to integrate this functionality into Rails, potentially enhancing the debugging process in development environments.

Continue reading on tenderlovemaking.com

#reading-list #development #database #best-practice #sqlite

🐥 YellowDuck.be

🔗 Claude Code skills: automate repetitive Linux tasks with custom skills

🔗 Reviewing AI code is not a viable argument

🔗 A PDF parser from the 80s beats Claude (and they use it internally)

🔗 Modernizing my dotfiles

🔗 How to achieve pruning when querying by non-partitioned columns in PostgreSQL

🔗 Sanding UI

🐥 Faster, leaner MySQL backups and restores with mysqldump

Where to configure this in Laravel

Dump-time optimisations

Exclude noisy, non-essential tables

Use a single transaction

Increase --net-buffer-length

Skip unnecessary LOCK/UNLOCK statements

Suppress MySQL 8 column statistics

Compress the dump on the wire

Skip binary log tracking (GTID)

Avoid table-level locks

Use --quick for large tables

Restore-time optimisations

SET sql_log_bin=0

SET foreign_key_checks=0

SET unique_checks=0

SET autocommit=0

Putting it together

More info

🔗 Why Elixir is the best language for LLMs

🔗 The Go architecture behind intelligence API

🔗 First-party image processing in Laravel 13.20

🔗 Work loudly

🔗 The git history command deserves more attention

🐥 Speeding up our PHP test suite with a GitHub Actions matrix strategy

The Problem: Three Jobs, Lots of Duplication

Step 1: Collapsing Three Jobs into a Matrix

Why More Suites Instead of Fewer?

Step 2: Caching apt Packages

The Downstream Effect: Coverage Merging

What This Changes

🔗 Learning Elixir: Error Handling with try/rescue/catch/after

🔗 Film: Final Frontier Patagonia

🔗 Learning a few things about running SQLite

🔗 Git rebase -i is not that scary

🔗 The integration loop

🔗 Supercharge your PHP apps with Go-powered PHP extensions

🔗 Go releases are exciting (especially 1.27)

🔗 Laravel facade pattern explained: build your own custom facade

🐥 Advanced debugging in Elixir with IO.inspect

The Basics of IO.inspect

Caveat: When IO.inspect Is the Last Call in a Function

Strategic Placement With the Pipe Operator

Using Labels for Clarity

Pretty Printing and Formatting Output

Coloring and Styling Output

Conditional Inspection

Capturing Inspect Output Instead of Printing

Debugging Concurrency and Async Code

Advanced Trick: Inspecting and Pattern Matching in One Go

Using dbg/2 for Richer Inspection

When IO.inspect Is Not Enough

Setting Default Options for IO.inspect in IEx

Creating a Reusable Inspect Helper

Handy Visual Studio Code snippets

Best practices

Conclusion

🔗 My notes on three years of coding with AI

🔗 1Password for Claude: give Claude access without giving up your credentials

🔗 Detecting full table scans with SQLite

Increase `--net-buffer-length`

Use `--quick` for large tables

`SET sql_log_bin=0`

`SET foreign_key_checks=0`

`SET unique_checks=0`

`SET autocommit=0`

The Basics of `IO.inspect`

Caveat: When `IO.inspect` Is the Last Call in a Function

Using `dbg/2` for Richer Inspection

When `IO.inspect` Is Not Enough

Setting Default Options for `IO.inspect` in IEx