Welcome to SwedenCpp

Latest blogs, videos, podcasts and releases in one stream

Tuesday, July 21, 2026

Prefactoring: Clear the Way for Your New Feature@media only screen and (max-width: 600px) { .body { overflow-x: auto; } .post-content table, .post-content td { width: auto !important; white-space: nowrap; } } This article was adapted from a Google Tech on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Rahul Singal “First make the change easy, then make the easy change.” - paraphrased from Kent Beck You're working on a new feature, but the existing code wasn't written with future changes in mind. Trying to force the feature in directly gets complicated fast. One change leads to another, and before you know it you're already a few files deep fixing things you never planned to touch. Prefactoring (short for "preparatory refactoring") is the practice of reworking existing code to make it more suitable for an upcoming change before you actually implement the new functionality. Instead of cleaning up code as an afterthought or trying to force a new feature into an incompatible structure, you restructure the codebase first. Prefactoring helps you: Easily implement new features: Restructuring the codebase first ensures your new feature fits naturally into the code. Speed up reviews: It's easier to review the refactoring and the feature in separate changes. Avoid bugs: Isolating cleanups from functional logic can help prevent bugs . Roll back safely: If you need to roll back, it is much easier to revert small, focused changes. Here is a simplified example of a prefactoring change: Change 1 (Prefactoring) Extract display name helper to remove duplication. Change 2 (Feature) Add middle name support. + def get_display_name(user): + return f"{user.first_name}” {user.last_name} # Profile page - display_name = f"{user.first_name} {user.last_name}" + display_name = get_display_name(user) # Email template - greeting = f"Hi {user.first_name} {user.last_name}, " + greeting = f"Hi {get_display_name(user)}," def get_display_name(user): - return f"{user.first_name} {user.last_name}” + return f"{user.first_name} {user.middle_name} {user.last_name}" You can prefactor a change that is already in review too! If your reviewer suggests a related cleanup during review, you can also extract it into a new base change to keep your current change focused on the feature. Note that not every cleanup needs to be prefactoring: you can do the cleanup in a follow up change if the cleanup doesn’t block your feature, or even in the same change if the cleanup is small enough.📝Google Testing Blog

If this page is useful, please consider donating a coffee

Monday, July 20, 2026

Sunday, July 19, 2026

Saturday, July 18, 2026

Friday, July 17, 2026

Faster C++ iterative builds with GitHub CopilotSlow builds are a consistent theme of feedback from C++ developers. We built GitHub Copilot build performance for Windows so you can leverage Copilot to optimize your project’s build times. This workflow will find optimizations that bring your build times down. At first, we only measured the impact of build optimizations on full clean builds. […] The post Faster C++ iterative builds with GitHub Copilot appeared first on C++ Team Blog .📝C++ Team Blog
The Case of the Irregular Hanging: A build forensics story from the front lines of remote executionThe Case of the Irregular Hanging: A build forensics story from the front lines of remote execution There is a particular kind of failure that senior infrastructure engineers recognize immediately. Nothing crashes. Nothing spikes. Nothing logs an error. And yet… work simply stops. This is the story of one of those failures and why Build Forensics matters once build systems become production infrastructure.📝EngFlow Blog

Thursday, July 16, 2026

Egerton MS 1995Previously on this blog: “The Book of St Albans (1486)” (2026-05-22), in which I made a table of terms of venery, a.k.a. company terms, e.g. “an exaltation of larks,” as in the eponymous book by James Lipton. I mentioned that the Book of St Albans actually has “an exaltyng of larkis,” and that it’s only in Egerton MS 1995 (circa 1450), according to Lipton, that we find “an exaltacyon of larkys” proper. But I couldn’t find any digitized copy of Egerton MS 1995 to verify that claim.📝Arthur O’Dwyer

Wednesday, July 15, 2026

Reduce LLVM Build Artifact Storage Costs by 50% with Content-Defined ChunkingReduce LLVM Build Artifact Storage Costs by 50% with Content-Defined Chunking One of the classic strategies to speed up a system is to avoid redundant work. Scalable build systems like Bazel and Buck2 heavily employ this strategy in various ways, with remote caching and content-addressable storage being two prominent examples. While remote caching prevents repeating redundant build actions, content-addressable storage (CAS) exists for the purpose of data deduplication. However, traditionally CAS operates at the granularity of a single file. When you modify a single byte in a file and store it in a CAS, the CAS stores a second, complete file. Deduplication at the file level is quite palatable for smaller files; a single build invocation typically contains many thousands of small files. Who cares if we store a couple more? However, as file sizes increase, the cost of storing yet another slightly modified version of a file becomes more expensive. Instead of tossing a couple extra kilobytes into storage, you might be storing a few more gigabytes . Now, consider where these large files come from. These large files are often outputs of build actions, and those build actions depend on many smaller inputs. As those many inputs churn, the outputs also churn. Suddenly the cost of touching a tiny little source file isn’t just the cost of uploading a new version of the source file to CAS–it’s now also the cost of all the large outputs that are produced by the build. This dictates the growth rate of your CAS storage costs, which scales directly with the number of incoming builds. At AI-scale, these costs have become more important than ever before.📝EngFlow Blog