标签：#Development

Yao Yue discusses the fundamental limitations of standard line charts for system observability. Drawing from 15 years of operating large-scale systems, she shares how engineering leaders and software architects can transform telemetry data - moving beyond simple time-series defaults - to build visualizations that directly answer critical capacity, latency, and fleet-sizing questions. By Yao Yue

HashiCorp is positioning HCP Terraform as the governance and control plane for a new generation of AI-driven infrastructure, arguing that the rapid adoption of coding agents is shifting the biggest infrastructure challenge from writing configuration to verifying and safely executing it. By Craig Risi

Dirk Lemmerman has released FlexGanttFX as an open-source resource-scheduling framework under the AGPL license. This JavaFX library enables Gantt chart creation for various industries, optimizing performance with a Canvas rendering method. The framework includes features for task dependency modeling and direct editing, accommodating diverse project planning needs. By Erik Costlow

How It Started I am a backend software engineer, primarily working in the Java ecosystem. Most developers in my space know about PlantUML and have probably been using it for years—I certainly have. PlantUML has long been a go-to tool for developers who need a robust way to write UML diagrams as code. But let's face it: PlantUML is showing its age. As powerful as it is, PlantUML can feel slow, its default look-and-feel is dated, and its interactive feature set has lagged behind modern development workflows. That is a major reason why alternatives have gained so much ground. Tools like Draw.io and Mermaid.js have steadily captured a large portion of the mindshare that PlantUML once held. While Draw.io is a visual drag-and-drop tool rather than a pure text DSL, it offers rich component sets and high customizability. However, text-based versioning and quick code playback aren't its primary strengths. On the other hand, Mermaid.js brought text-to-diagramming into the modern web. It is fast, renders across browsers and IDEs, offers an accessible DSL, and integrates directly into platforms like GitHub and Notion. Yet, I felt we could take this concept even further. We need something more modern, more customizable, and more tactile—a text-to-diagram engine that is fast, easy to learn, and visually sharp, while bridging the gap between raw code and visual canvas control. Introducing DrakoFlow For a long time, I’ve dreamed of having a diagram engine that makes sharing architecture effortless. A tool that enhances the documentation experience rather than standing in the way of it. So, I finally decided to build it. I wanted DrakoFlow to be fast, robust, and elegant—not only in its syntax, but in its visual output. Most importantly, I wanted it to be 100% free, open-source, and privacy-first (running entirely in the browser with zero server dependencies). Building it was a challenge. As a backend developer, creating a heavily interactive, client-side web application meant stepp

Amazon recently announced Kiro Crew, an open-source system for running multiple Kiro coding agents across sessions, tools, and tasks. The new workspace lets developers assign asynchronous coding tasks to AI agents, allowing work such as incident investigation, ticket triage, migrations, and PR monitoring to continue without active supervision. By Renato Losio

KH4 Companion is a small extension I built: it counts down to Kingdom Hearts IV, puts the days remaining on the toolbar badge, pulls series news and trailers from public feeds, carries a lore compendium, and hides a three-lane rhythm minigame in the popup. It has been on the Chrome Web Store since 19 August. As of this week it is also on addons.mozilla.org , which makes it my first Mozilla listing. I had been putting the port off, because "port" sounds like work. It was not. Same build, same version number, same feature set — what changed was four keys in manifest.json . This is the writeup I wanted to find before I started. The thing nobody tells you first The blocker is not your code. It is that AMO rejects the package before it ever shows you a listing form. So the order of operations is: fix the manifest, get the linter to zero errors, then worry about icons and screenshots and copy. Assets built against a package that cannot upload are wasted. npx addons-linter@latest <extension-dir> is the gate. Run it before you touch anything else. 1. Firefox needs an explicit add-on ID Chrome derives an extension ID for you. Firefox does not — in MV3 you must state it: "browser_specific_settings" : { "gecko" : { "id" : "kh4-companion@dhseadev.online" } } The email-ish form or a {8-4-4-4-12} GUID both work. Pick carefully: this ID is your update identity forever. Changing it later means a new listing, not an update. 2. There are no extension service workers in Firefox This is the real difference, and it is smaller than it sounds. Firefox runs an event page where Chrome runs a service worker. background.service_worker is simply ignored, with a BACKGROUND_SERVICE_WORKER_IGNORED warning. The cross-browser answer is the dual key: "background" : { "scripts" : [ "core/lib.js" , "background.js" ], "service_worker" : "background.js" } Chrome reads service_worker . Firefox reads scripts . One file, both browsers. Two traps live in here, and both pass a manifest review and fail at run

We finally added OTA updates to Romi. This is something apps have been doing for years, but it’s new territory for us. Instead of waiting for Apple’s review every time we need to push a small fix, we can now ship certain updates directly to users. And because apparently paying for another service wasn’t exciting enough, we built our own setup using Capgo + CDN. It’s one of those things that feels obvious once it works. Getting there was slightly less obvious. 😅 What’s something your team implemented way later than everyone else?

LINE published an official MCP server for its Messaging API, which means an AI agent can now drive a LINE Official Account directly — sending messages, broadcasting promotions, and pushing Flex Message cards without writing any API code. I set it up with Codex and worked through every capability the server exposes, from creating a fresh account to delivering a message to a real phone. This guide is the result: a complete walkthrough, and an honest account of the three places where the documentation and reality diverge. Key takeaways MCP is agent-agnostic. The same LINE server works with Codex, Claude Desktop, and Cline — only the config file format changes, from TOML to JSON. Codex stores MCP config in TOML , at ~/.codex/config.toml . Most guides assume the JSON format used by Claude Desktop, which is the single most common setup mistake. Verified account and API-capable account are different things. A free account can use the Messaging API, but get_follower_ids returns 403 Forbidden until the account is verified or on a premium plan. Official security advice can conflict with official features. LINE's example config disables npm install scripts, which also prevents the headless browser that the rich menu tool depends on from being installed. Agents have habits. Codex is a coding agent first: asked in natural language to build a rich menu, it wrote a Node script instead of calling the MCP tool. Naming the tool explicitly in the prompt fixes it. Broadcasts cannot be recalled. Set default_tools_approval_mode = "writes" so the agent asks before any send. Every screenshot comes from the actual working setup, including the errors. The article is available in both English and Thai. Devlycan - Technology & Programming Insights Devlycan - Technology, programming, AI, lifestyle, and future trends—simple insights for the new digital generation. devlycan.com

It's conference season! I already had to sit at home jealous while friends had fun at Render ATL, but it's my turn soon with Commit Your Code next week in Plano, TX. It boasts a banger lineup of speakers, which got me thinking: how do you get the absolute most out of an event like this? The number one rule is determining your goal before you step through the doors. Are you going to hang out with friends, meet new people, or hunt for a job? Each objective requires a completely different approach, prep strategy, and attire. 1. Hanging Out with Friends This is the easiest path. Wear whatever keeps you comfortable while looking relatively professional. Meet up with your crew, enjoy the sessions, and have fun. You done did it. 2. Networking and Meeting New People This is my primary goal for CYC this year. I'll fill you in on my plan. To keep from getting overwhelmed, I built a tracking spreadsheet for everyone I want to connect with. It might sound clinical, but it ensures no follow-up slips through the cracks. Here is my process: Pre-Conference Research: First, I reviewed the talk schedule and logged the speakers and session titles that caught my eye. Initial Outreach: I added columns for sending an intro message and a LinkedIn connection request. Then I sat down and message every single one of them. I had a bit of a template, but mostly just told people why their talk sounded interesting or exciting to me. It's hard to have writers block when you have a genuine interest in something. Some of them replied, some didn't, but I already feel like I have a foot in the door heading into the conference. During & After the Event: My spreadsheet includes columns for attending their talk, taking photos (speakers always need good photos of themselves on stage), posting on social media, and sending a post-event follow-up. Sounds like a lot? Because it is! Which is why its in a spreadsheet and not my pasta strainer brain. But it's about intent, respect, and appreciating someone else

Previously I have a macOS App I use myself, gemini-live-translate-macos . It uses ScreenCaptureKit to directly capture audio from a specified App, eliminating the need for virtual sound cards like BlackHole. It then sends the audio to the Gemini Live API for real-time translation, outputting Traditional Chinese subtitles while playing Chinese audio. I've written two posts about the development process: the first one was about building it from scratch using AGY CLI, and the second one was about using Claude Code to take it from "functional" to "user-friendly." The starting point for this new addition was simple: I saw a document for "Real-time Transcription" added to the Live API. Since I was already connected to the Live API, I thought adding a pure transcription mode would just be a matter of changing a few parameters. However, after checking the documentation, I realized that Google released two models with very similar names but very different capabilities at once. The specific feature I actually wanted (speaker diarization) wasn't available at all on the model I originally thought it was. Two Models with Names Differing by Only Two Words Let's lay out the differences first; this is the part I spent the most time figuring out: gemini-3.5-transcribe-live gemini-3.5-transcribe API Used Live API (WebSocket streaming) Interactions API (Standard HTTP request) Usage Scenario Transcribe while speaking Upload the whole file after recording Speaker Diarization Not supported Up to 8 speakers Word-level Timestamps Not supported Supported Audio Length 10 minutes per session 1 hour (30 mins with diarization) Smart Mode SMART available smart is mutually exclusive with diarization Interim Subtitles Has interimInputTranscription Not applicable The official documentation on the Live page's limitations section is very blunt: Speaker diarization is not supported in live streaming sessions. For speaker diarization, use the non-streaming Audio transcription endpoint. So, "seeing who

A recent discovery revealed that AliExpress employs silent audio streams for device fingerprinting, leveraging the Web Audio API. This technique involves analyzing hardware-specific audio processing to distinguish user devices. Privacy-focused browsers have developed countermeasures, highlighting a security gap in current web standards regarding audio context initialization and user privacy. By Olimpiu Pop

When testing opinionated Linux distributions, the ultimate benchmark isn't how smoothly they run on a workstation with 16 cores and a high-end GPU—it's how gracefully they perform on budget, resource-constrained hardware. Enter Omarchy , the "omakase" Arch-based distribution created by David Heinemeier Hansson (DHH) . Built around the Hyprland tiling window manager and explicitly tailored for modern developer productivity, Omarchy proves that a curated desktop environment doesn't require a heavy computing footprint. Running Omarchy 4.0.0 on an entry-level laptop built around an Intel Celeron N4020 CPU demonstrates how deliberate software curation turns modest hardware into a fast, highly capable development machine. 💻 Hardware & System Overview Below is the environment breakdown from our test run: Category Specification / Details Hardware / PC Model ASUS C204M Processor Intel® Celeron® N4020 (2 cores / 2 threads) @ 2.80 GHz Graphics Integrated Intel UHD Graphics 600 Display 11" Built-in Display (1366x768 @ 60 Hz) RAM Utilization 2.69 GiB / 3.68 GiB (~73% load) Storage / Root 15.66 GiB / 27.10 GiB (~58% used) on Btrfs OS & Kernel Omarchy 4.0.0-1 (Linux Kernel 7.1.8-arch1-3) Compositor Hyprland 0.56.2 (Wayland) 🚀 The Developer Experience: What Makes Omarchy Special Omarchy isn't just an Arch installer with custom dots; it's an opinionated operating system designed to eliminate setup friction and let you write code immediately. 1. Zero-Friction Language Setup via Menus Setting up language runtimes on a fresh Linux install often involves hunting down version managers (like asdf , nvm , or pyenv ), configuring shell initialization scripts, and managing system paths. Omarchy streamlines this entirely. Through its integrated menu system, installing a programming language or developer stack is as simple as launching the system menu, picking a language (Node.js, Ruby, Python, Go, Rust), and hitting Enter. The system automatically installs the necessary version managers, conf

The lakehouse projects spent this week arguing about boundaries. Iceberg decided where conformance testing lives and started sketching the REST API shape that V4 tables will need. Polaris argued about what a committer owes a project when LLMs make pull requests cheap. Parquet pulled a feature apart because two proposals were reaching for the same mechanism. DataFusion and Iceberg Rust opened a joint thread about which repository should own their integration. Every one of those debates is a question about ownership, and the answers this week tell you a lot about how these communities plan to scale. Apache Iceberg The single biggest outcome of the week was the creation of a new repository. Neelesh Salian, working with Sung Yun and Andrei Tserakhau, called a vote to create apache/iceberg-verification , a standalone home for language-neutral conformance fixtures that every Iceberg implementation can run against. The vote passed with five binding +1s from Russell Spitzer, Sung Yun, Matt Topol, Daniel Weeks, and Amogh Jahagirdar, plus twenty-two non-binding votes. That is a wide turnout. The names on the non-binding list read like a roll call of the Rust, Python, Go, and Java maintainers, which is the point. Salian will now work with a PMC member to stand the repository up. The reason this matters goes beyond tidiness. Iceberg has at least five serious implementations today across Java, Python, Rust, Go, and C++. Each one carries its own test fixtures and its own understanding of edge cases in the spec. When two implementations disagree about how to interpret a manifest list, users find out the hard way. A shared set of fixtures that every implementation reads from one place turns spec ambiguity into a failing test rather than a production surprise. The 29 messages in the vote thread also included a fair amount of discussion about what belongs in the first batch of fixtures, and the conversation is worth reading if you maintain a client. The second major thread was about

Sätteri is a high-performance Markdown and MDX processor developed by the Astro team. Built in Rust, it enhances build speeds by up to 61% for Astro 7.0. Sätteri supports flexible JavaScript plugins and integrates various Markdown features natively. It maintains compatibility with the unified ecosystem while offering faster parsing and reduced dependencies. By Daniel Curtis

Chad Schuster discusses bridging Python's developer velocity with C-like performance using Numba JIT and GPUs. Drawing from large-scale actuarial modeling, he explains LLVM pipeline architecture, performance gains up to 750x, and essential trade-offs like OOP limits, type inference errors, and compile-time overhead for engineering leaders scaling compute-heavy enterprise systems. By Chad Schuster

A program can produce the right answer and still contain work that does not help it reach that answer. Tests pass, the output looks correct, and unnecessary computations survive because they appear harmless. This becomes easier to miss in AI-generated code. A model can produce a plausible implementation in seconds, but plausible code often includes variables, conversions, or branches that the requirement never asked for. An intent alignment review adds one question to the usual correctness check: Does every instruction help achieve or explain the stated goal? This does not require a formal proof or an exhaustive line-by-line exercise. The useful result can be concise. Correctness and intent Correctness asks whether the observable behavior matches the specification. Intent alignment looks for code that contributes neither behavior nor useful clarity. The goal is not to produce the fewest possible lines. A named constant or helper function can be worthwhile even when the program could run without it. The concern is accidental complexity: code that suggests requirements or design decisions that do not actually exist. AI can help by reading the requirement and implementation together. It can confirm the working behavior, identify unnecessary instructions, and explain whether those instructions are harmful or simply unhelpful. A small Fibonacci example Consider this specification: The function should print to stdout the first hundred elements of the Fibonacci sequence. The phrase "first hundred" does not specify whether the sequence begins with 0, 1 or 1, 1 . For this review, we assume the intended convention begins with 0, 1 and prints one value per line. def print_fibonacci_100 (): a , b = 0 , 1 sequence_limit = 100 display_width = len ( str ( sequence_limit )) for index in range ( sequence_limit ): current_value = int ( a ) print ( current_value ) a , b = b , a + b checkpoint = ( index + 1 ) % 10 == 0 final_pair = ( a , b ) print_fibonacci_100 () Review The implementa

Diagrid Catalyst 2.0 applies Dapr-based recovery, signed workflow history and execution attestation across several agent frameworks. Architects should compare it with framework-native durability and established workflow engines, while evaluating benchmark evidence and operational trade-offs. By Mark Silvester

Se você já perdeu tempo com essa sequência: git stash git checkout outra-branch # resolve o problema urgente git checkout branch-original git stash pop ...só pra descobrir depois que esqueceu o que tinha no stash, ou que o venv / node_modules da outra branch estava desatualizado — este artigo é pra você. O problema Um repositório Git tradicional tem uma única pasta de trabalho ligada a uma branch por vez. Trocar de branch significa trocar todo o conteúdo dessa pasta. Isso funciona bem quando você faz uma coisa de cada vez, mas quebra assim que você precisa: Revisar um PR urgente enquanto está no meio de uma feature grande Rodar testes de uma branch enquanto edita outra Manter ambientes de dependências diferentes (versões de libs, .env ) para features distintas sem reinstalar tudo a cada troca A saída mais comum é o stash , mas ele é frágil: some da vista, acumula, e é fácil esquecer o que tinha ali dentro. A solução: git worktree O git worktree permite ter várias pastas de trabalho simultâneas , cada uma vinculada a uma branch diferente, todas compartilhando o mesmo histórico de commits (o .git ). Pense em uma biblioteca central (o histórico do repositório) com várias mesas de leitura (as worktrees), cada uma com um livro diferente aberto. Você não precisa fechar um livro pra abrir outro. O que é compartilhado, o que é separado Compartilhado entre worktrees Separado por worktree Histórico de commits Arquivos da working directory Objetos do Git (blobs, trees) Arquivos não versionados ( .env , venv , node_modules ) Configuração do repositório Saída do git status Um commit feito em uma worktree aparece imediatamente no git log das outras — mas os arquivos físicos de cada pasta continuam independentes. Colocando em prática Criando uma worktree com branch nova git worktree add ../meu-projeto-feature-x -b feature/nome-da-feature Isso cria a pasta ../meu-projeto-feature-x , já com uma branch nova feature/nome-da-feature criada a partir do commit atual. Criando uma worktree

Nuxt has released version 4.5, featuring updates such as a switch to Vite 8, a new Rspack 2 builder, and experimental SSR streaming. This streaming enhances Time to First Byte by flushing the HTML shell instantly. The release also includes a stable error code system and new composables, alongside important upgrade instructions for developers moving from earlier versions. By Daniel Curtis

Building a working tender documentation system for yourself is one project. Turning that same system into a template the rest of the team can pick up and use correctly, without needing to ask you what a particular instruction actually means, is a completely different project wearing the same clothes. The Gap Between Personal Use And Handoff A prompt template that only you use can carry a lot of implicit knowledge safely, because the missing context lives in your head and gets filled in automatically every time you run it. An instruction that says something like ensure the response addresses compliance requirements directly means something very specific to the person who wrote it, shaped by dozens of past examples of what counting as directly actually looks like in practice. That same instruction, handed to someone on the team who was not present for any of those past examples, is just as likely to be interpreted in a way that is defensible on its own terms and still wrong relative to what was actually meant. The template worked perfectly for months before it needed to be handed off, which made the gap invisible until the moment it actually mattered. The first time someone else on the team ran it independently and produced a response that technically followed the instructions but missed the actual intent behind them, the problem was not that the instructions were poorly written in any obvious sense. It was that they had been written for an audience of one, and that audience had context nobody else on the team had access to. What Actually Needs To Be In A Handoff Ready Template Fixing this meant rewriting a significant portion of the template with a different question in mind at every step, not does this instruction produce the right output when I run it, but does this instruction contain enough of the reasoning behind it that someone without my accumulated context could apply it correctly to a new tender they have never seen before. That meant replacing instructions