Patent registering bodies would have to get back into using prior art to reject patent applications. That used to happen in the 80's and before, but at some point they just gave up and said it could be settled in course cases. When that happens there's room for AIs again to find prior art, etc.
I was at a meetup two weeks ago, and networking with someone two decades younger quite well (commonalities, interests, employer(s), etc), and his face was like I'd pronounced his newborn a being ugly, after I explained what TBD was and why teams do it.
Today, pushing TBD could be considered to be career limiting. I've been thinking about that a lot ...
... Nobody wants to hear that **GitHUB Flow** is just one of three major forms of TBD: trunkbaseddevelopment.com/styles/.
The CollabNet people in the room included a lot of sales veterans of other SCM tools, and there was solid opposition.
This crew and others in the enterprise gave me a clue we were in for an uphill struggle
By contrast, promoting TBD in ThoughtWorks didn't seem so hard, many being converts already
ThoughtWorks's owner had me leave the middle of OSCON in 2005 to present to the sales team at CollabNet in California on how their product (using Svn) could be positioned against ClearCase in the enterprise. I talked about trunk-based development, feature toggles, and keeping it all go-live-able
Those cohorts never heard about TBD before, and branch-crazy feels alluring.
In the early 2000's sales folks for ClearCase, StarTeam and even Perforce would tell enterprises you could do **any** branching model you liked. Even long-running ones.
Some idle thoughts: Comp Sci didn't historically teach branching. Heck, until 15 or so years back, Comp Sci didn't teach source control at all. Quorum in dev teams by sheer numbers is reached quickly for more-recent grads. Such cohorts mostly pick up post-university ways of working from each other.
Stepping away from the "car doppler" React app, and back toward the credit card form and address of the original blog entry: the same test harness ideas for a MacOS app using #SwiftUI and #Appium (via node & JavaScript) to test automate it. paulhammant.com/2025/06/30/s...
And a Selenium branch discussed for the same React app and same component-centric tests paulhammant.com/2025/06/22/s...
Continuing the series - a Cypress branch of the same thing (Cypress instead of Playwright for component testing) -> paulhammant.com/2025/06/20/c...
Revisiting an previous "UI component testing" blog entry for a 2025 update with a React/TypeScript example -> paulhammant.com/2025/06/17/u...
Also features a wildly inaccurate app that calculates car speeds based on mic-recorded doppler shift.
Oh, I think it's there already: github.com/AtRayzor/Dot...
Hey @damianedwards.com is there a way with .NET 10 preview 4 (and onwards) to do relative package deps compatible with "dotnet run sourcefile.cs"?
I'm making a multi-language edu piece to teach how Google maintains a multi-lang monorepo. Fingers crossed you've patience for unconventional things
I changed one of the components for the google-monorepo-sim from Java to Kotlin. So there's three languages used in this monorepo now - Java, Rust and Kotlin. Two stdout-using main() style applications within using all three: github.com/paul-hammant...
Of course, for enterprise dev life, one would do .NET work in the regular way (solutions, projects and 'dotnet.exe' as your dispatcher for everything applicable). My work here is just an experiment.
The answer could be in Bazel's .NET bindings. I'm familar with Nx's community-made github.com/nx-dotnet/nx... and I think it still uses .sln/.csproj pieces for a canonical test invocation.
I could be in XyProblem territory though - vstest completes but says it could not find compiled-and-in-dll tests. But the diagnostics says "error" around Microsoft.Bcl.AsyncInterfaces.dll that can't be found.
The wall currently is vstest needs Microsoft.Bcl.AsyncInterfaces.dll and that being handed in as a reference, but vstest claiming it can't find it on instantiation.
The very nature of this tree-like way of laying out modules means I've to avoid the .csproj and .sln files. Compile needs to use csc (Roslyn these days) and tests need to go via vstest which /can /take /args for all setup instead of looking for csproj XML or JSON
The silly google-monorepo-sim thing I was working on (Java and Rust modules, directed acyclic graph build system that isn't Bazel), I've added a .NET application and components that also uses the Rust .so within. Well, or should cos I've hit a wall github.com/paul-hammant...
Likely retiring a pair-programming challenge I have done for many years paulhammant.com/2025/05/23/r...
Techies should've made something for themselves by now .. gist.github.com/paul-hammant.... Linked In's edge over other social media is verified "8/10 grade" identity, but the chains of who verified who are not that accessible. Verified achievements/activities or just CLAIMS would be so cool
Re Linked in feature wish x.com/soren_iverso.... <img src="pbs.twimg.com/media/GraC98bbAAYXV96" alt="Image"/>
I'm also still doing some pieces with Aider chat and another Gemini LLM .. cos that's two orders faster right now given not under the extreme load that Jules is.
I'm getting it to make multiple new test timelines - things that'd stretch the layout. I'll get to something that's better for mobile soon enough, but my first peeve is it won't commit direct-to-main even if I ask it. This is a one person side project; I don't need pull requests
For github.com/paul-hammant... I'm playing with Google's Jules immersive AI playground. It's pretty good but slow at the moment. Or maybe not as force-page-reload sometimes sees progress when that wasn't apparent before.
Caveats: 1) Less than 100 companies would do this Google thing, I guess.
2) Your company is **JUST FINE** with a multi-repo setup.
3) There are multiple sub types of trunk-based development: trunkbaseddevelopment.com/styles/
You'd watch this if you don't understand how Bazel works "under the hood". Or if you don't understand how a ginormous VCS-relying company would actually use a single repo for all applications, apps, services, libraries they make themselves.
This talk compares both, with source in a cloneable repo that shows the structure. I also discuss how Google shrink their 9+ million source files in their trunk to something that is more manageable for a dev or QE who's wanting to achieve a specific coding task/story.