🐥 YellowDuck.be

🐥 Undoing a pushed merge commit without losing work

2026-09-12T17:00:00Z

Sometimes you push a merge commit you didn't mean to, and notice it only after the fact. Here's how we handled it cleanly when that happened on a feature branch.

My branch history looked like this:

abc1234  Fix for the feature we were working on  ← latest commit, must keep
def5678  Merge branch 'feature/my-branch' of ...  ← mistake
ghi9012  Previous commit
jkl3456  Older commit

The merge commit def5678 was already pushed to GitHub. The latest fix (abc1234) sat on top of it, so a plain git reset --hard HEAD~1 would have taken the fix with it.

I needed to drop exactly one commit from the middle of the history while keeping everything above it. git rebase --onto is the right tool for this:

git rebase --onto ghi9012 def5678 HEAD

This tells Git: take all commits after def5678 up to HEAD, and replay them directly onto ghi9012 — the commit before the bad merge. The merge commit is skipped entirely.

The rebase left us in a detached HEAD state, so we updated the branch pointer and switched back:

git branch -f feature/my-branch HEAD
git checkout feature/my-branch

The history was now clean:

xyz7890  Fix for the feature we were working on
ghi9012  Previous commit
jkl3456  Older commit

Then a force-push to update the remote:

git push --force

Why not git revert?

git revert -m 1 is the safer choice when multiple people have already pulled the branch, because it adds a new commit rather than rewriting history. In our case the branch was a personal feature branch with no other active collaborators, so rewriting was fine and kept the history cleaner.

When in doubt on a shared branch, revert. On a solo feature branch, rebase is cleaner.

#best-practice #terminal #git

🔗 Why We Don’t Use AI @ Rene Herse Cycles

2026-09-12T15:00:00Z

A nice post from Rene Herse Cycles on why AI is not the answer to everything.

Continue reading on www.renehersecycles.com

#reading-list

🔗 Linux nameservers and DNS resolution

2026-09-12T13:00:00Z

DNS resolution on Linux can lead to frustrating errors like “Temporary failure in resolving” when issues arise. This guide, written by Hayden James, explains how DNS resolution works on Linux systems, covering configuration for desktops, servers, and VPS setups. The article details the management of DNS settings via /etc/nsswitch.conf and /etc/resolv.conf, as well as the role of systemd-resolved in modern distributions. Key tools such as dig, resolvectl, and getent are discussed for diagnosing and troubleshooting DNS problems. Readers will learn how to configure DNS servers, flush caches, and resolve common DNS issues. Understanding these concepts is crucial for maintaining reliable network connectivity on Linux systems.

Continue reading on linuxblog.io

#reading-list #tools #devops #terminal #linux #sysadmin

🔗 Laravel Doctor: Diagnose your app with one artisan command

2026-09-12T08:00:00Z

Laravel Doctor was announced at Laracon US 2026 in Boston, introducing an artisan doctor command that performs health checks on Laravel applications. This command ensures essential configurations are correct, such as verifying the presence of the .env file, checking the APP_KEY, confirming PHP version compatibility, and making sure required extensions are installed. If issues are found, Doctor can automatically fix them where possible or clearly state what needs attention.

Each diagnostic is grouped into classes handling specific checks—covering environment, Composer dependencies, configuration, database connectivity, and more. The command can be extended by packages that want to add custom diagnostics, making it a versatile tool for maintaining application health. With the ability to provide machine-readable reports, Laravel Doctor is designed not only for developers but also for CI environments and AI coding agents, ensuring robust application maintenance across various setups.

Continue reading on laravel-news.com

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

🔗 ClickHouse adapter Elixir

2026-09-11T17:00:00Z

Building an Ecto adapter for ClickHouse involved overcoming the limits of Postgres when handling aggregate data. The article describes how integrating ClickHouse's columnar storage improves query performance while preserving Ecto's familiar syntax and functions. The author shares insights on the development process, including utilizing a dependency-aware issue tracker called beads and employing a language model for incremental task breakdowns. An important aspect of the project was establishing a native TCP driver to facilitate efficient communication. Key challenges included debugging a complex handshake protocol and implementing a custom compression method. Ultimately, the project produced a functional clickhouse_adapter_ecto, enabling support for ClickHouse features while adapting them to Ecto's structure, proving the value of careful planning and incremental testing in software development.

Continue reading on mfeckie.dev

#reading-list #database #ai #elixir

🔗 Anti-antipatterns in Elixir library guidelines

2026-09-11T13:00:00Z

The Elixir Library Guidelines preach strict rules, but what if they're overlooking practical software engineering needs? This article dives into the nine declared "anti-patterns" from these guidelines, arguing why they aren't just permissible but essential in many scenarios. From the erroneous avoidance of application configuration to the drawbacks of strictly using tuples for control flow, the discussion reveals real-world use cases where breaking these prescribed rules can lead to better software design. The guidelines may be a helpful starting point, but understanding when and why to deviate from them empowers developers to make informed decisions tailored to their project's unique challenges. This piece invites readers to reconsider the rigidity of these guidelines, emphasizing the importance of context-driven development.

Continue reading on rocket-science.ru

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

🔗 Phoenix version adoption & security

2026-09-11T08:00:00Z

The Phoenix ecosystem sees rapid patch adoption but slow migration between minor versions. Data shows that patch releases within the same minor version gain traction within two weeks, while the transition to a new minor version often takes seven to eight months to surpass a 50% adoption rate. This pattern highlights a connection between the minor series in use and the responsiveness to security releases.

Currently, four minor versions of Phoenix receive official support. Adoption data indicates that teams using older versions experience delays in applying patches due to inertia. This not only elevates the risk of unpatched vulnerabilities but complicates upgrades as dependencies grow. When crucial security patches roll out, older versions lag in responsiveness, posing a significant security risk, especially when vulnerabilities require no authentication, rendering unpatched systems vulnerable to attacks. Staying current with Phoenix and LiveView releases is essential to maintaining application security and operational efficiency.

Continue reading on www.praialabs.com

#reading-list #phoenix #devops

🔗 GenStage demand visualized

2026-09-10T17:00:00Z

Can visualizing demand in GenStage optimize your Elixir applications? Andrea Leopardi demonstrates how to craft informative visualizations that clarify backpressure in stream processing. By employing tools like :observer and custom metrics, the article emphasizes the importance of understanding how demand fluctuates in real-time. Leopardi shares practical examples that help developers grasp how to balance producer and consumer relationships in GenStage for more resilient applications. He advocates for clear metrics and visual aids that can significantly enhance how systems operate, especially as complexity increases with more extensive data streams. Overall, it's a focused look at leveraging Elixir's capabilities to improve application performance through visual insights.

Continue reading on out.reddit.com

#reading-list #development #tools #elixir

🔗 GitHub Actions is having one of the worst days in its history

2026-09-10T13:00:00Z

GitHub Actions experienced a major outage on August 6, 2026, that lasted over seven hours, making it the second-longest outage in the service's history. The incident significantly impacted the ability to execute workflows, with GitHub processing only about 15% of webhook triggers at its peak. Many jobs failed to execute, and although there was an improvement later on, the overall performance remained poor. The outage contrasted sharply with GitHub's rapid growth in service demand, as reflected in past metrics that showed an increase from 500 million minutes a week in 2023 to over 2.1 billion minutes this spring. While GitHub has not yet disclosed the exact cause of this latest outage, it highlights the challenges that come with scaling services to meet increasing user demand.

The final tally for this incident marked 7 hours and 26 minutes of total downtime, just shy of the record for the longest major outage set in May 2021. While there may be no immediate lessons learned, the community was left collectively waiting for updates as the situation unfolded.

Continue reading on kernel.pryanic.com

#reading-list #devops #github #announcement

🔗 The DISTINCT in your COUNT

2026-09-10T08:00:00Z

The query SELECT count(DISTINCT user_id) FROM events; might seem efficient, but it can lead to performance pitfalls. The keyword DISTINCT disables parallel query execution in PostgreSQL, forcing the database to process all data serially. This occurs because the aggregate COUNT(DISTINCT ...) requires a unique count, which cannot use parallel processing effectively due to the need for a specific order. Without parallel execution, queries on large tables become inefficient, often resulting in costly disk usage and longer processing times. The article offers a solution: rewriting the query to use a GROUP BY clause instead. This approach allows for parallel processing, significantly improving query execution time with larger datasets while still achieving the desired unique count result. This insight is crucial for developers optimizing analytics queries for better performance.

Continue reading on boringsql.com

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

🔗 What are code reviews even for?

2026-09-09T17:00:00Z

AI didn’t break code review; it highlighted existing issues. Brian Houck discusses how the surge of AI in code production has outpaced human review. At Meta, lines of code per diff increased by 106%, with diffs up 51% due to AI, while the timeliness of reviews has declined. Developers idealize spending only 7% of their time reviewing code, indicating we must rethink the purpose of code review itself. It's traditionally about more than just defect detection; it's a space for knowledge transfer and architectural understanding. Rethinking habits around code reviews before AI can be effective is crucial. Using AI wisely can enhance the process, but organizations risk eroded collective understanding by automating too much. Effective code review is about preserving knowledge and fostering collaboration, not just speeding up the process.

Continue reading on newsletter.getdx.com

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

🔗 Your COUNT(DISTINCT) is too slow: Approximations and sampling in PostgreSQL

2026-09-09T13:00:00Z

Can you afford to wait for precise distinct counts in Postgres? Elizabeth Garrett Christensen reveals that exact counts can be prohibitively slow, especially with large datasets. She outlines various strategies for approximating unique counts using features like the built-in TABLESAMPLE for random sampling, the HyperLogLog (HLL) for efficient distinct counting, and introduces Apache DataSketches for more complex scenarios. The article offers practical examples, including how to set up a sample page_views table with 10 million rows, and examines the benchmarks of different methods to highlight performance differences. You'll learn how accurate data analysis can still be quick and accessible without sacrificing too much precision.

Continue reading on www.snowflake.com

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

🔗 Hybrid search patterns with PostgreSQL and pgvector

2026-09-09T08:00:00Z

Most production vector queries aren't just about finding similar documents; they often involve specific criteria. The article explains hybrid search patterns, combining similarity ranking with scalar filters in PostgreSQL by utilizing pgvector and hybrid Nearest Neighbor searches. The author showcases how to effectively integrate WHERE clauses into vector queries, which can often lead to trade-offs between recall and performance. Techniques such as iterative index scans are discussed to refine these searches. The article thoroughly analyzes various querying strategies, including oversampling and caching responses to improve query efficiency. It offers practical insights on building indexes and optimizing performance for complex applications that require both speed and accuracy, making it an essential read for database administrators and developers working with vector data in PostgreSQL.

Continue reading on www.crunchydata.com

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

🔗 Image dominant color and HEIC support in Laravel 13.24

2026-09-08T17:00:00Z

Laravel 13.24 brings major improvements to its image API, including dominant color detection and support for HEIC files. With the new dominantColor() method, developers can now easily retrieve the average color of an image, making it ideal for UI enhancements while loading images. This version also introduces the modelKeys() method to Eloquent queries, streamlining primary key retrieval, along with a new array_keys validation rule that reports unexpected keys directly. Importantly, it adds support for AVIF and HEIC image formats as both input and output, enhancing compatibility for images straight from devices like iPhones. Other fixes include performance improvements for wildcard validations on large arrays, among various other enhancements to the Laravel framework. This update reflects Laravel's ongoing commitment to improving developer experience and application performance.

Continue reading on laravel-news.com

#reading-list #development #laravel #eloquent

🔗 Limited output is a feature.

2026-09-08T13:00:00Z

As startups increasingly leverage LLM agents for software tasks, a critical question arises: are they losing sight of meaningful product development? Johanna Larsson argues that many are racing to optimize for "AI-enablement" rather than focusing on user value. She highlights successful companies like Linear, which thrived by prioritizing core user experiences over excessive features. Instead of getting caught up in continuous output and feature requests, Larsson encourages a return to thoughtful product creation. Businesses should spend more time contemplating what truly matters—cutting out unnecessary complexity to reveal the essence of their products. This slower, more intentional approach not only enhances user satisfaction but also fosters innovation, advocating for fewer features that deliver greater value.

Continue reading on jola.dev

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

🔗 What's new in PHP 8.6

2026-09-08T08:00:00Z

PHP 8.6, set to release on November 19, 2026, introduces several important features including partial function application (PFA) and a new polling API. PFA lets developers create references to closures with some parameters pre-defined, streamlining code when combined with the pipe operator. The new polling API improves the handling of asynchronous processes, although it doesn't bring built-in async capabilities.

Another significant change is the allowance of default values for readonly properties, following the introduction of property hooks in PHP 8.4, and the addition of new functions and classes for enhanced functionality such as Duration and clamp(). Moreover, the security for session defaults is tightened with stricter ini settings, improving overall security for applications. These updates reflect an aim for better usability and performance in PHP development.

Continue reading on stitcher.io

#reading-list #development #php #best-practice

🐥 Laravel boost best practices: A major tone shift (August 2026)

2026-09-07T17:00:00Z

Two commits landed in the Laravel Boost repository on August 26, 2026 that significantly update the AI guidance rules baked into the package. The changes touch all 19 best-practice rule files and add a new section on controller resource design. Here is what changed and why it matters.

The big picture: from prescriptive to contextual

The first commit (d165b9ea) touches 1,427 lines across every rule file. The headline change is not a new feature — it is a deliberate softening of absolute language.

Rules that previously said "Incorrect" / "Correct" now use labels like:

"Manual lookup:" / "Use route model binding:"
"Hidden dependency:" / "Injected dependency:"
"Unsafe:" / "Preferred:"
"Queued and durable:" / "Deferred in the current process:"

The intent is clear: the guidance now presents trade-offs and context instead of moral verdicts. This matters because AI coding agents (and developers) following these rules were previously being trained to treat "Incorrect" examples as always wrong, even in situations where the pattern was actually fine.

Key Changes by Area

Queries — `advanced-queries.md`

The old guidance said whereHas() was flat-out wrong because it "re-executes per row." The new version is more honest:

whereHas() typically produces an EXISTS subquery, while whereIn() can express the same filter with an IN subquery. Either form may be faster depending on the database engine, indexes, cardinality, and query plan. Measure both forms with representative data.

The section title changed from "Prefer whereIn + Subquery Over whereHas" to "Compare whereHas() with an IN Subquery". Similarly, the compound index rule now says "verify the query plan" rather than asserting a single correct approach.

A technical fix also snuck in: the dynamic relationship example now correctly passes the foreign key to belongsTo():


// Before (broken — missing the FK argument):
return $this->belongsTo(Login::class);

// After (correct):
return $this->belongsTo(Login::class, 'last_login_id');

Architecture — `architecture.md`

Two notable shifts:

Dependency injection: The old rule said constructor injection was always correct and method injection was a code smell. The new rule aligns with how Laravel actually works:

Prefer constructor injection for dependencies required throughout an object's lifetime. Method injection is appropriate for dependencies needed by one controller action, listener, job handler, or other container-invoked method.

Default sort order: Instead of "always use latest()", the guidance now recommends a stable two-column sort with a tie-breaker for reliable pagination:


Post::query()
    ->orderByDesc('created_at')
    ->orderByDesc('id')
    ->paginate();

Caching — `caching.md`

The Cache::remember() section now explicitly warns about the false-cache-miss bug:

The manual version below incorrectly treats valid falsy values, such as false or 0, as cache misses.

It also adds an honest caveat: Cache::remember() does not prevent concurrent requests from computing the same missing value — you still need Cache::lock() for that.

Routing — `routing.md`

The "Keep Controllers Thin" rule (with its arbitrary "under 10 lines" target) is gone. In its place:

Controllers should coordinate HTTP input, authorization, validation, an application operation, and the response. Extract substantial or reusable business logic, but do not introduce an action or service merely to satisfy an arbitrary line limit.

Migrations — `migrations.md`

The file shrank significantly (78 → 24 deletions vs. 24 additions). Several overly prescriptive examples were removed. The foreign-key section now includes a practical note:

Do not add a duplicate single-column index without checking the database driver's treatment of foreign-key indexes and the indexes already created by the migration.

Security — `security.md`

Two nuanced additions stand out:

$guarded = [] is no longer labeled universally "Incorrect." The new text acknowledges that mass-assignment protection controls which attributes can be set, not values or authorization — and that deliberate conventions using $guarded are valid.
The SQL injection example now uses the fluent string helper properly:


User::whereRaw('LOWER(name) = ?', [$request->string('name')->lower()->toString()])->get();

A new explicit note: "Public actions intentionally available to everyone do not need a redundant authorization check."

Queues — `queue-jobs.md`

The Amazon SQS footnote is new and important:

Amazon Simple Queue Service uses its visibility timeout instead of Laravel's retry_after; configure that timeout at the queue level.

The ShouldBeUnique section now notes that all dispatching processes must share a cache store that supports locks — a silent gotcha that has burned teams before.

New section: organize controllers around resources

The second commit (b19e98a8) adds a standalone section to routing.md covering a pattern that often gets debated on Laravel teams.

The guidance establishes a clear default: organize controllers around one resource using standard resource actions (index, show, create, store, edit, update, destroy). When a custom verb like publish, approve, or archive appears, treat it as a design signal — it might represent a separate resource.

The canonical example models podcast publishing as a dedicated controller:


// Route
Route::post('/published-podcasts/{podcast}', [PublishedPodcastController::class, 'store'])
    ->name('published-podcasts.store');

Route::delete('/published-podcasts/{podcast}', [PublishedPodcastController::class, 'destroy'])
    ->name('published-podcasts.destroy');

// Controller
class PublishedPodcastController extends Controller
{
    public function store(Podcast $podcast): RedirectResponse
    {
        $podcast->publish();
        return back();
    }

    public function destroy(Podcast $podcast): RedirectResponse
    {
        $podcast->unpublish();
        return back();
    }
}

The guidance ends with an important escape hatch:

Treat a custom verb as a design signal, not proof that another controller is required. Use query parameters for simple filtering, and keep an explicit action route when modeling the operation as a resource would obscure the domain or conflict with established project conventions.

Why this matters for AI-assisted development

Laravel Boost feeds these rules directly to AI coding agents as context when generating code. Overly prescriptive "always/never" rules cause agents to reject valid patterns and to add unnecessary abstractions (action classes for trivial logic, for example). The new tone should lead to more pragmatic, context-aware suggestions — and fewer unnecessary "Incorrect" rewrites of perfectly reasonable code.

The shift also signals a broader direction: good AI guidance reads like a senior developer explaining trade-offs, not a linter listing violations.

#laravel #best-practice #ai

🔗 Native apps should be avoided whenever possible

2026-09-07T13:00:00Z

What if your smartphone is tracking you more than you think? A detailed article warns against using native apps, revealing their penchant for collecting vast amounts of data, often without users' knowledge. It highlights the case of the recently launched White House app, which claimed zero data collection but was found to be tracking location continuously. The author emphasizes that native apps often inherit permissions from embedded third-party software, posing significant privacy risks. In contrast, websites restrict this level of access, making them a safer choice for most services. With governments and companies frequently buying users' location data, the article advocates for minimizing app usage, reminding readers that many everyday tasks can be handled through web browsers instead. This shift could help protect personal data from prying eyes in an age when surveillance and data commodification are rampant.

Continue reading on nooneshappy.com

#reading-list #best-practice #android

🔗 IBM i (OS/400) the database operating system

2026-09-07T08:00:00Z

What if there’s an operating system that challenges traditional views on how systems should be designed? Kamil Pytliński’s article dives into IBM i, an often-overlooked platform that marries its integrated relational database, Db2 for i, directly with its OS. This unique configuration treats all data as objects, leading to enhanced security and unprecedented performance in online transaction processing since its inception in 1988. With features such as Single Level Storage and the TIMI layer ensuring backward compatibility, IBM i stands as a testament to innovative design, offering capabilities still unmatched today, though access remains limited to high-end IBM hardware. The article showcases how this elite system continues to perform where others struggle, challenging the perception of legacy systems.

Continue reading on osadmins.com

#reading-list #database #best-practice #sysadmin

🔗 The schema doctor is in

2026-09-06T17:00:00Z

A migration adding a user_id column can pass all reviews, but later lead to slow queries. This is a problem the new truss:doctor feature of Truss 1.5 addresses. Designed to identify schema issues before deployment, it flags problems like tables missing primary keys, foreign keys without supporting indexes, and redundant indexes.

Running php artisan truss:doctor in your terminal checks for these issues deterministically, which is safe for CI pipelines. The results can also be viewed graphically in the dashboard, offering real-time feedback on database structure without querying actual data. This phase one release includes 13 distinct rules and plans for future enhancements are already in the pipeline, focusing on suppressions and additional checks. Truss has quickly gained traction in the Laravel community, making it a valuable tool for maintaining database integrity.

Continue reading on albertoarena.it

#reading-list #laravel #database #tools #best-practice #devops

🔗 15 Linux interview questions every sysadmin should know

2026-09-06T13:00:00Z

Most Linux interview lists recycle the same ten questions from a decade ago, and many of the ‘official’ answers are outdated or no longer apply to modern Linux distributions. This updated guide highlights essential knowledge for positions such as Linux System Administrator, DevOps, and Site Reliability Engineer (SRE).

It covers 15 practical questions designed to help candidates showcase their hands-on experience rather than just theoretical knowledge. Interviewers seek to understand real-world problem-solving skills, so the guide emphasizes the importance of explaining concepts clearly and demonstrating with the right Linux commands.

Candidates can expect topics like managing processes, checking boot messages, and automating log rotation. With the Linux landscape continuously evolving, being prepared with the latest tools and techniques is crucial for any sysadmin preparing for interviews.

Continue reading on www.tecmint.com

#reading-list #devops #linux #sysadmin

🔗 With purpose: How to win the transcontinental race

2026-09-06T08:00:00Z

Robin Gemperle set an impressive standard by winning The Transcontinental Race No. 12 in just 10 days, 8 hours, and 55 minutes. Covering 4,694 kilometers from Trondheim, Norway, to Kalamata, Greece, he demonstrated an unparalleled strategy in race preparation. Every decision, from gear selection to routing, was made with the primary goal of victory in mind, showing that even the best need to balance racing hard and resting hard. With precise planning, including ingenious hydration solutions and clever route adjustments, Robin exemplified what it means to race with intent. His methodical approach to rest and efficient setup proved key to maintaining speed throughout the grueling challenge. The article showcases Robin's dedication and clever tactics, which might just inspire the next wave of ultra-racers aiming for success.

Continue reading on www.apidura.com

#reading-list #sports

🐥 One line to measure PHP memory

2026-09-05T17:00:00Z

You've just run a long-running Artisan command and production is complaining about memory. Before reaching for Xdebug or a full profiler, there's a tool already on your machine that answers the question in one line:

/usr/bin/time -l php artisan your:command 2>&1 | grep "maximum resident"

That's it. No code changes, no instrumentation, no deployment.

Breaking it down

/usr/bin/time — the system binary, not the shell built-in. The full path is important: your shell likely has a time built-in that doesn't support the -l flag.
-l — tells it to emit detailed resource usage. On Linux, use -v instead.
2>&1 — time writes its output to stderr, so you need to redirect it into stdout before you can pipe it.
| grep "maximum resident" — filters down to the one line you care about.

The output looks like this:

 147922944  maximum resident set size

That number is in bytes. Divide by 1024 × 1024 and you have the peak RSS in megabytes — in this case, 141 MB. That's the high-water mark of physical RAM the process held at any one moment, and the right number to compare against memory_limit in php.ini.

Why not `memory_get_peak_usage()`?

PHP's own memory_get_peak_usage(true) is great when you control the code — add it at the end of handle() and you see PHP's internal allocator peak. But it only sees what PHP's memory manager tracked. The OS-level approach catches everything: the runtime itself, loaded extensions, forked child processes. For commands that spawn subprocesses or load large extensions, the two numbers can diverge meaningfully.

The OS measurement also requires no deployment — run it against production code on a staging server without touching a line.

macOS vs. Linux

Swap -l for -v on Linux. The field name also changes slightly — look for "Maximum resident set size (kbytes)" — and note the unit shift from bytes to kilobytes.

Drop the grep for more

Skip the pipe entirely and /usr/bin/time -l dumps the full resource table after your command finishes: page faults, context switches, I/O operations, wall time. Worth reading once to understand what your command is actually doing at the OS level.

#laravel #php #best-practice #terminal #sysadmin

🔗 Curl says it's fast. Your users disagree.

2026-09-05T13:00:00Z

Does your application feel slow even when Curl shows it's fast? This article dives into the real user experience versus baseline performance metrics. It highlights how relying solely on tools like Curl can mislead developers about actual performance. The article draws attention to user feedback, which often uncovers issues that run deeper than simple response times. It emphasizes the importance of understanding user interactions and suggests that performance metrics should include real-world scenarios instead of just testing tools. Developers are encouraged to look beyond the numbers to measure how users truly experience their applications.

Continue reading on madewithlove.com

#reading-list #best-practice #http

🔗 SQLite vs DuckDB on the same $16 box: every cliff moved 100X

2026-09-05T08:00:00Z

DuckDB outperforms SQLite significantly on a low-cost server, achieving write speeds 4x to 15x faster. In a benchmark that lasted six days, DuckDB managed to serve dashboards at up to 100 times the row count, accommodating a billion metric points within 10.8 GB. Notably, DuckDB's architecture allowed for efficient data handling and query performance, smoothly surpassing SQLite's limits in real-world scenarios. For instance, metrics read cliffs increased from 1 million rows in SQLite to 100 million in DuckDB, all while maintaining or improving latency. Such results imply that for self-hosted applications managing large volumes of data, DuckDB may provide a compelling alternative to SQLite, especially in contexts that demand high throughput and scalability. The article also elaborates on the methodology of the tests conducted.

Continue reading on tracewayapp.com

#reading-list #database #devops #testing #sqlite