1_DevOps'ish

1_DevOps'ish

Jack Dorsey Is Ready to Explain the Block Layoffs
Jack Dorsey Is Ready to Explain the Block Layoffs
In an exclusive interview with WIRED, Block’s cofounder and CEO says he axed 40 percent of his workforce so that he can rebuild the company “as an intelligence.”
·wired.com·
Jack Dorsey Is Ready to Explain the Block Layoffs
DNS-PERSIST-01: A New Model for DNS-based Challenge Validation
DNS-PERSIST-01: A New Model for DNS-based Challenge Validation
When you request a certificate from Let’s Encrypt, our servers validate that you control the hostnames in that certificate using ACME challenges. For subscribers who need wildcard certificates or who prefer not to expose infrastructure to the public Internet, the DNS-01 challenge type has long been the only choice. DNS-01 works well. It is widely supported and battle-tested, but it comes with operational costs: DNS propagation delays, recurring DNS updates at renewal time, and automation that often requires distributing DNS credentials throughout your infrastructure.
·letsencrypt.org·
DNS-PERSIST-01: A New Model for DNS-based Challenge Validation
googleworkspace/cli: Google Workspace CLI — one command-line tool for Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, and more. Dynamically built from Google Discovery Service. Includes AI agent skills.
googleworkspace/cli: Google Workspace CLI — one command-line tool for Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, and more. Dynamically built from Google Discovery Service. Includes AI agent skills.
Google Workspace CLI — one command-line tool for Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, and more. Dynamically built from Google Discovery Service. Includes AI agent skills. - googlework...
·github.com·
googleworkspace/cli: Google Workspace CLI — one command-line tool for Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, and more. Dynamically built from Google Discovery Service. Includes AI agent skills.
Something is afoot in the land of Qwen
Something is afoot in the land of Qwen
I’m behind on writing about Qwen 3.5, a truly remarkable family of open weight models released by Alibaba’s Qwen team over the past few weeks. I’m hoping that the 3.5 …
·simonwillison.net·
Something is afoot in the land of Qwen
The Generative AI Policy Landscape in Open Source
The Generative AI Policy Landscape in Open Source
After publishing AI Slopageddon and the OSS Maintainers I wanted to move beyond anecdotes and get a clearer picture of how the open source community is actually responding to AI-generated contributions. The stories of maintainer burnout and “AI slop” flooding pull requests were compelling, but I still had lots of questions. How many projects have
·redmonk.com·
The Generative AI Policy Landscape in Open Source
Why I Built Vykar Backup: A Faster, Simpler Rust Backup Tool
Why I Built Vykar Backup: A Faster, Simpler Rust Backup Tool
Vykar Backup is a fast, Rust powered backup tool with one YAML config, built in scheduling, and easy restores via a desktop GUI and WebDAV. It supports local, S3, SFTP, and REST backends with secure deduplicated snapshots.
·noted.lol·
Why I Built Vykar Backup: A Faster, Simpler Rust Backup Tool
Seven Years to TypeScript: Migrating 11,000 Files at Patreon
Seven Years to TypeScript: Migrating 11,000 Files at Patreon
Between 2019 and 2026, we migrated Patreon’s entire frontend codebase from JavaScript to TypeScript, spanning 11,000 files and over 1 million lines of code. Our initial approach was organic. We enabled TypeScript support and let teams adopt it voluntarily. But by 2022, we realized voluntary adoption alone wouldn't get us there. We needed infrastructure, tooling, and eventually AI-powered automation to complete the journey. What began as a grassroots experiment evolved into one of our most ambitious infrastructure projects. Here's how we approached the migration and what we learned from seven years of incremental progress. Breaking down the journey Our seven-year migration evolved across three distinct eras, each with its own strategy and tooling. The chart below shows our migration trajectory. Notice the slow organic growth through 2022, steady infrastructure-driven progress through 2024, and dramatic acceleration in 2025 as AI tools matured. Era 1: Grassroots (2019-2022) In early 2019, a few adventurous frontend engineers started writing new features in TypeScript. There was no official mandate and no migration plan. We added TypeScript support to our build tooling with a permissive configuration: What went right Low friction adoption. Engineers could experiment with TypeScript without fear of breaking things. If they liked it, they could keep using it. But if they didn't, they could stick with JavaScript. Viral spread. When one engineer on a team adopted TypeScript and others saw the benefits (better autocomplete, catching bugs at compile time, self-documenting interfaces) they wanted it too. TypeScript spread organically across teams. What went wrong TypeScript builds weren't passing. We didn't run type checking in CI. If you ran tsc on the master branch, you'd get hundreds of errors. Truthfully, TypeScript was more like an opinionated autocomplete than a real type system. No shared patterns or foundations. We had no shared types for core concepts like creators, posts and memberships. Every file that touched these concepts either defined its own ad-hoc types (often incorrectly) or didn't add types at all. Growing type debt. As more code was written in TypeScript, the lack of foundational types became more painful. You couldn't properly type a component that used the API since the API responses were typed with any . And you couldn't properly type a page component since our routing library had no type information about which routes existed By late 2021, less than 10% of our codebase was in TypeScript files and even less was meaningfully typed. We had syntax but lacked safety. Era 2: First-Class TypeScript Support (2022-2024) In early 2022, we formed the frontend platform team at Patreon. Improving developer experience was a core part of the team’s charter. Motivation for better TypeScript support TypeScript foundations became a priority for developer experience because: Null JavaScript reference errors were a consistent source of production incidents. Engineers hesitated to refactor shared code, fearing unknown breakage without typed contracts. New team members spent weeks building mental models of data structures that should have been self-documenting. Since we lost several engineering hours per week due to type-related issues, the business use case was straightforward too. Building the foundation We decided that we would treat TypeScript as first-class. This meant: Type checking must pass on master. So we made tsc a required CI check. Foundational types must exist. So we created shared types for core domain concepts. However, we couldn't freeze feature development for a big-bang migration. We needed an approach that let us migrate incrementally while maintaining continuous feature velocity. We ship major creator features monthly so any migration strategy that blocked product work was a non-starter. We took a pragmatic approach and methodically added types for: API objects. Core domain models (e.g. user, creator, membership, post) were passed to client consumers in a type-safe way. Routing system. Route definitions and navigation helpers were typed so the compiler knew which routes existed and what parameters they accepted Analytics. Typed wrappers around our analytics systems were implemented so event names and properties were checked at compile time Each of these was a multi-week project. But once done, they provided type information that propagated throughout the codebase. As a result of well-typed foundational infrastructure, we shipped fewer incidents in areas where types were comprehensive, and code reviews felt safer when reviewers could rely on type information to understand data flow and contracts. The remaining problem By the end of 2024, we had excellent TypeScript infrastructure and adoption on new code. But 2000+ old files were still JavaScript because of how tedious it was to convert them. The typical process was: Rename .js to .ts Add types to function parameters Add types to function return values Add types to local variables Fix all the type errors (often dozens per file) Test that nothing broke This effort was exacerbated by: Legacy patterns from 2013. Our codebase predated modern React conventions, with untyped global state from before our Next.js migration, stage-0 decorator syntax TypeScript didn't support, and deeply nested Higher-Order Components (HOCs) passing props through layers. Lost institutional knowledge. Much of our oldest code was written by engineers who had left years ago. Entire subsystems lacked anyone who fully understood their intended behavior. For a complex file, migrating from JavaScript to TypeScript could take 2-4 hours. At that rate, migrating 2000 files would take multiple engineer-years! It was never going to happen through voluntary effort by product teams since migrating legacy JavaScript files provided collective benefit but individual cost. No engineer could spend weeks migrating old code when they had competing priorities and new features to build. The incentives didn't align so we needed to move away from manual migration. Era 3: The Concerted Migration (2025) In 2025, the frontend platform team committed to clearing the remaining JavaScript files and finally achieving end-to-end type safety. To finish the swing, we assembled a task force and adopted a multi-pronged strategy that evolved with AI capabilities. Phase 1: The ts-migrate foundation We started with proven tooling. Airbnb had open-sourced ts-migrate , a codemod tool specifically designed for TypeScript migrations. It wasn't perfect, but it was battle-tested on codebases similar to ours. ts-migrate works by: Renaming .js → .ts files Adding type annotations where it can infer them and $TSFixMe (alias for any ) where it can't. Converting React PropTypes to TypeScript interfaces Adding // @ts-expect-error comments on lines with errors The output isn't beautiful, but it compiles. Here's what a migration looked like: This wasn’t fancy but it allowed us to migrate hundreds of simple function components to TypeScript. However, static analysis struggled with: Redux patterns Higher-order components Files with heavy use of this context Dynamically generated code Legacy decorator syntax These files either failed to migrate or ended up so littered with any that they were barely better than JavaScript. Phase 2: AI-powered codemods As GPT-4 and Claude matured, we realized we could use AI to write codemods that handled patterns ts-migrate couldn't. This was more sophisticated than simple AST transformations as we could leverage semantic understanding. Our process for AI-generated codemods involved 8 steps: Identify a common pattern that needs migration (e.g. all files using decorator X) Provide AI with 5-10 example files showing the pattern Ask AI to write a codemod using jscodeshift Test the codemod on 50 files manually Review the output, tweak the prompt, regenerate Once confident, run on all matching files Create a PR, let CI and tests validate Ship if tests pass This let us tackle categories of files that would have been impossible with pure static analysis. Example 1: React Classes to TypeScript Many of our legacy React components used custom context for i18n. We wrote a codemod to automatically convert hundreds of these to TypeScript: Example 2: Legacy decorator migration Our codebase used an old decorator syntax that TypeScript poorly supported and had to be converted to HOC wrapper calls. To address this, we wrote a codemod with AI that successfully migrated all 500+ decorator usages in our codebase: Phase 3: Localized AI fixes By this point, we'd migrated most of the "easy" files. What remained were complex files with gnarly type errors. These needed human-level understanding to fix properly. But we noticed something interesting: many of these files had errors that were highly localized. A test file might have 15 type errors, but they were all in isolated test cases that didn't interact with each other. So, we developed a localized fix strategy: For files with localized errors, we'd add @ts-expect-error comments with the specific error messages: We'd then use AI to fix each error individually by: Uploading the file with the error comment Asking AI to fix just the error in the file Running type check If it passed, keeping the change If it failed, trying again or moving on We'd batch these fixes, processing 50-100 files per day. This approach worked well for low-risk areas such as tests and internal tools where the blast radius was limited. In early 2025, AI tooling didn’t feel production-ready, so we kept it away from user-facing code. Phase 4: Advanced AI workflows As the second half of 2025 rolled around, AI workflows became sophisticated enough that we felt confident using them on user facing code. This is where things really accelerated. The breakthrough was realizing we could use AI as an orchestrator that delegates to specialized subagents: Orchestrator
·patreon.com·
Seven Years to TypeScript: Migrating 11,000 Files at Patreon
GRAM
GRAM
Gram is an open source code editor with built-in support for many popular languages. Gram is an opinionated fork of the Zed code editor.
·gram.liten.app·
GRAM
Operation Epic Fury and Iranian Cyber Counterattacks | Tenable®
Operation Epic Fury and Iranian Cyber Counterattacks | Tenable®
Following the joint military operation known as Operation Epic Fury, the Tenable Research Special Operations (RSO) team is providing an update regarding potential cyber counteroffensive operations conducted by Iran-linked threat actors.
·tenable.com·
Operation Epic Fury and Iranian Cyber Counterattacks | Tenable®
[Video Podcast] Frictionless DevEx with Nicole Forsgren
[Video Podcast] Frictionless DevEx with Nicole Forsgren
In this episode, Thomas Betts talks with Dr. Nicole Forsgren, the author of Accelerate and one of the most prominent and important minds in DevOps and developer productivity. The conversation is about identifying and removing developer friction, the subject of her new book, Frictionless.
·infoq.com·
[Video Podcast] Frictionless DevEx with Nicole Forsgren
Talos on the developing situation in the Middle East
Talos on the developing situation in the Middle East
Cisco Talos continues to monitor the ongoing conflict in the Middle East. As always, we will be watching closely for any cyber-related incidents that are tied to the conflict.
·blog.talosintelligence.com·
Talos on the developing situation in the Middle East