I write these posts purposely on Fridays (when nobody will read it) just to reflect on where things are at and gather my own thoughts. I will admit that I think there is vastly more feature work in the rear view mirror than there is ahead, but there’s still some things still on the list. But you also never know when some major new software development trends will upend everything you think you think!
CritterWatch 1.1
I’m hoping that CritterWatch 1.1 will be ready for release by the first of October. At this point we’re “officially” feature complete and mostly trying to add more user interface polish and do a lot more manual testing.
The biggest single item is that we’re doing testing in a JasperFx’s client next week who wants to use CritterWatch on an immensely big and complex system (that also uses AWS SQS which is by far and away the whiniest messaging transport). I’m hopeful that getting access to their environment and being able to see CritterWatch admittedly struggle to monitor that massive system will do a great deal for us to get CW 1.1 ready to release.
If everything goes magically well next week, we might be sneaking in a new “Document Explorer” feature set to give you a very comprehensive database viewer for Marten, Polecat, and Fisher built into CritterWatch. That might of course float to 1.2. As it is, CritterWatch 1.1 made our Event Store Explorer feature much more feature rich and flexible to allow you to easily query and view event store data for Marten, Polecat, and Fisher.
You can read more about the improvements to CritterWatch for the 1.1 release here.
You might notice that the project codename “Bobcat” deviates from our Mustelidae naming convention. “Bobcat” has been my working codename for a spiritual and modernized successor to my old Storyteller tool that I’ve been envisioning for longer than the “Critter Stack” naming scheme has existed. I’ve frequently said that my coding superpower is having a much longer attention span than average and Bobcat will maybe be the result of about 17-18 years of work and thinking in this space.
Bobcat is a new MIT-licensed “critter” for improved integration testing and will be the Critter Stack solution to “Spec Driven Development” and a key player in our forthcoming Event Modeling strategy I’ll discuss next.
The big theme is making automated integration testing more successful through:
- A “Supervisor” library that uses the Microsoft Testing Platform to “supervise” integration heavy test suites and provide selective and adaptive test retries, flakiness detection, test parallelization, and even manage resources (Docker container resets or even starting an all new process) during tests. I realize that this effort is quite possibly something that’s just useful for Critter Stack development, but it’s already paid off for us!
- Using some old ideas (that actually did work even if the project as a whole was a bust!) from Storyteller and FitNesse before that for making data intensive testing easier and provide useful, correlated telemetry for diagnosing test failures
- An option for using Gherkin for expressing tests when the Given/When/Then format works or with people who are just comfortable with that approach
- Being able to “project” specifications from existing xUnit or TUnit tests through (hopefully) judicious usage of attributes, comments, and source generators
- Having your test harness be able to also expose a lot of application instrumentation and telemetry in the outputs for easier AI agent consumption and troubleshooting (again, really an old idea from Storyteller being rebuilt with AI agents in mind).
- Some specific add on packages or recipes for HTTP testing with Alba and Spec Driven Development against Event Sourcing with the entire Critter Stack
I’ve thought and discussed a possible markdown authoring approach like ThoughtWork’s Gauge tool, but right now I’m personally leading toward just the combination of Gherkin or the C#/F# tests with projection.
As for the name, I was fascinated as a teen when bobcats started reappearing in our area again (there are actually some very real advantages for wildlife when far fewer people live on farms). But also, as someone with a rural background, people use the name “Bobcat” to refer to any skid steer tool and that carries the connotation of getting stuff done to me:
Event Modeling with the Critter Stack
I’ll share more details soon, but just know that Babu & I are working very hard on a new comprehensive Event Modeling support throughout the Critter Stack. This work and functionality is landing admittedly all over the place with the core JasperFx library defining our official “Event Model” API and that being supported by Wolverine and our event stores including Marten, Polecat, and Fisher. The Bobcat tool up above plays in this too by providing human readable specification rendering and execution. Mostly though, the AI agent coordination, scaffolding, and event model visualization will be from a new tool named “Stoat” that will be included with JasperFx’s AI Skills pack. And of course, our AI Skills tie everything together.
For right now, let me sum that up as:
- Generate system code targeting the Critter Stack from a YAML file exported from the Event Modeling AI platform. Shame on me, but I’m not quite sure that’s a standard yet (this?) or just something from their own toolkit
- Define an “Event Model” through a Gherkin specification or more likely through .NET code and see a visualization of the event model in a web browser as you work and refine that — and then, of course, generate system code from that model
- Generate system code off of the “Event Model” as well as specifications using Bobcat (which could in turn just be riding on xUnit.Net or TUnit)
- CritterWatch can visualize an Event Model for your system as it actually is based on the real application based on a combination of the system describing itself and using logging for cause and effect relationships between command messages or HTTP endpoints and the cascading messages or events appended
- Our AI Skills and some hard coded scaffolding support in Bobcat make the generated code use the Wolverine and Marten/Polecat/Fisher idioms for low code ceremony and maximize testability
And of course, I’m a big believer in the “Semantic Model” strategy for frameworks, so every possible way you can define the “Event Model” like the import from the EventModelers.AI platform, our Gherkin DSL, a forthcoming C#/F# Fluent Interface we’re going to add to JasperFx.Events, or whatever other 3rd party DSL like ESDB we might support later will be translated first to our very own semantic model. All of our visualization and code generation will target our own semantic model.
That being said, I honestly think that it’s going to be faster in many cases to just write low fidelity C# or F# code in an IDE to generate the event model than it will be to use one of those intermediate modeling DSLs like ESDB or some of the other JSON, XML, or YAML dialects that are popping up. I also think that in the end many folks will probably drive the event model through chatting with an LLM, so we’re investing in our AI Skills to make that as seamless as possible too.
Just to level set, I’m struggling to be too enthusiastic about Event Modeling as a formal method used to specify in detail, then generate systems. I definitely think it can be helpful in a “Uml as Sketch” kind of analytic tool of course and I am a fan of doing interactive Event Storming sessions with domain experts. I’m old enough to remember when Model Driven Development was a complete bust and it’s hard for me to get past the obvious comparison. There are some real downsides to being older and more experienced. It’s natural to compare new ideas to older ideas you’ve already encountered, and sometimes that makes you miss the real differences or value in the new thing. Just something mildly depressing to think about for us older guys still doing software.
Stoat is the codename for a new tool from JasperFx Software that is targeted for AI assisted development, durable agentic memory, visualizing agent activity, coordinating agent activity across code repositories (it’s possible that I’m the only person who cares about that, but I care a lot), and as the glue behind our Event Modeling and Spec Driven Development strategy over all including a user interface for Bobcat specification previews and execution.
There’s a documentation site up, but just know that the website is 100% AI generated with lots of Opus inflected Yoda-speak and many things will change before we inflict Stoat upon the world. I’m hoping that Stoat will have its first release at the same time as CritterWatch 1.1.
We will also be doing a full review of the website to improve the verbiage too of course, but sometimes it’s just easiest now to let an AI tool draft something then mostly rewrite it.
Just know though, that Stoat will be a commercially licensed tool that will be bundled (retroactively too!) with the JasperFx AI Skills pack or CritterWatch.
