JasperFx offers online training workshops, and we've done enough of these now to know what works. Here's what you're actually buying.

JasperFx works every day with our clients using the "Critter Stack" to help them best utilize our tools or to help support them with software architecture or test automation. We've picked up quite a bit of knowledge along the way -- and some hard lessons -- about building systems with event sourcing, asynchronous messaging, HTTP services, and event driven architecture in general. We've naturally started conducting online workshops to help out clients wring the most value out of our tools and understand the approaches and thinking that can lead to more successful software projects.

The first question anyone asks about a training workshop is some version of "what's the agenda?" — which is fair, and I'll get to it. But it's the wrong question to lead with, because the honest answer is that the agenda has been different for every single customer so far, and the ones that went best were the ones where we just adapted by switching to whatever topic the attendees were interested in.

Let me explain what I mean by that, because it's the whole point.

No two of these have been the same

Same instructors, same tools, same underlying material — and genuinely different workshops:

• One customer wanted asynchronous messaging, and not much else. We spent the bulk of our time on Wolverine's messaging story: routing, error handling policies, retries and circuit breakers, dead letter queues, and how the transactional outbox actually works when Marten and Wolverine share a transaction. Event sourcing was a supporting character.

• Another was mostly interested in Wolverine's HTTP story — specifically the hybrid types, where the same handler method can be an HTTP endpoint and a message handler, and what that does to how you structure an application. That's a fairly narrow slice of the tooling, and it deserved most of a day.

• A third team came in with a reporting problem. They wanted to know how to use Marten projections to build denormalized views for dashboards and reporting screens — multi-stream projections, flat table projections that write real relational columns their BI tool could read, and the operational question underneath all of it: what happens when you need to change one of those projections after it has two years of history behind it.

• And in some cases the tools have barely been the point. More than one team has needed the concepts first — what CQRS actually commits you to, when event sourcing is worth it and when it very much isn't, how to think about consistency boundaries. Marten and Wolverine showed up as the thing we happened to be typing into, not the subject.

• Some folks wanted to know all about the multi-tenancy support in the Critter Stack (it's a lot), and other folks just wanted to know a little bit about what's possible

• Everybody sooner or later wants to talk about test automation, and we're definitely ready for that one!

That's not us being disorganized. It's the deliberate design. A workshop that ignores what your team is actually struggling with is a conference talk you paid extra for.

The interactivity is the product

These are small, online, and highly interactive. We want the questions. We would much rather spend twenty minutes on the thing that's been blocking your team for a month than stay on schedule.

In practice that means:

• Questions interrupt. Not "hold them for the end." If something on screen doesn't match how your system works, that's the most valuable moment in the session and we should chase it.
• We'll go off the agenda entirely if that's where the value is. More than once the most useful hour has been a topic that wasn't on the plan when we started.
• We'll look at your problem, specifically. Not always your actual codebase — though we've done that — but your architecture, your constraints, the decision you're stuck on.

I've had the experience of explaining a consistency trade-off in a workshop and realizing halfway through that the room's real question was something else entirely. Following that instead is why they hired us.

What we bring to the table

Being flexible only works if the underlying material is solid, so it is. We maintain a full workshop curriculum with working sample code, and the code on the slides is pulled directly out of projects that compile and run — not snippets typed into a slide editor that drifted out of date two releases ago.

The full curriculum covers:

• CQRS and Event Sourcing fundamentals — including the parts where event sourcing is the wrong answer
• Marten (or Polecat and now Fisher!) as both a document database and an event store, and why it doesn't have to be all or nothing
• Projections in depth — single stream, multi-stream, event projections, flat table projections, composite projections, event enrichment, side effects, and what it takes to change a projection in production without downtime
• Asynchronous messaging with Wolverine — routing, transports, cascading messages, and the several different ways to get events onto a bus
• Resiliency and concurrency — retry policies, circuit breakers, dead letter queues, optimistic concurrency, and message ordering
• Data consistency — the dual write problem, the transactional outbox, idempotency, and reading your own writes
• Modular monoliths and multi-tenancy
• Observability — OpenTelemetry, metadata, metrics, and CritterWatch
• Testing and DevOps — the testing story is genuinely one of the best reasons to use this stack, and it's usually the section people don't expect to enjoy
• Vertical Slice Architecture — Wolverine does it better than anything else in the .NET ecosystem and there's a lot of tools to shrink down your application code compared to other technical stacks
• Multi-tenancy — what's possible, what works best in different scenarios, how that integrates all the way through Wolverine and Marten/Polecat/Fisher

You will not get all of that in a day, and you shouldn't want to. We'll pick.

Who's teaching

The people who build and maintain these tools. When someone asks "why does it work that way?" the answer isn't a guess from documentation — it's usually the actual design rationale, including the parts we'd do differently now.

That cuts both ways, and it should. We'll tell you when something is a rough edge, when a feature isn't ready, and when the right answer for your situation is not to use our tool.

The material is ready when you are

We have the curriculum built and current. If your team wants training, the lead time is a planning call and a date — not months of preparation.

That planning call matters more than it sounds. It's where we find out whether you need the messaging deep dive or the projections deep dive or a day of stepping back from the tools entirely. Everything above is raw material; the call is where it turns into your workshop.

If that sounds useful, the workshops page has the format, the topics, and a scheduling link — or just email us and tell us what your team is wrestling with.