TRAILBLAZER-STORY will follow as it turned out to be inevitable for setting up application state for tests. Instead of fumbling around with factories and traits in your tests, you “tell a story” about what to create in which order, easily customizable, and all written using activities.

Using operations as test factories is a fundamental concept of Trailblazer to remove buggy redundancy in tests and manual factories.

It is absolutely advisable to use factory in combination with let. let(:song) { factory( Song::Create, { title: "Timebomb", band: "Rancid" } ) }

You should always use operations as factories in tests.

There are several helpers to deal with operation tests and operations used as factories.

Run the complete unit with a certain input set, and test the side-effects. This differs to the Rails Way™ testing style, where smaller units of code, such as a specific validation or a callback, are tested in complete isolation. While that might look tempting and clean, it will create a test environment that is not identical to what happens in production.

endpoint Diagram::Operation::Create do |ctx, **| redirect_to diagram_path(ctx[:diagram].id) end.Or do |ctx, **| render :form end

When nesting an activity with multiple outcomes, you can wire each terminus to a different route.

For example, an output using Track(:create) will snap to the next possible task that is “magnetic to” :create. That’s how tracks or paths are created.

Semantics are mostly relevant for nesting

Remember, in a railway activity each task has two standard outputs with the “semantics” success and failure.

By using Output(:semantic), you can select an existing output of the task and rewire it.

Why don’t we put the “create user” task onto the failure track, and in case of successfully persisting the new user, we deviate back to the happy path?

Instead of one big code pile, activities will gently enforce a clean, standardized way for organizing code.

the Activity component is the heart of TRB

To implement such an activity, we only need to rewire the second step’s failure output to a new terminus.

Since you can reference outputs by their semantic, you as a modeller only connect conceptual termini to ongoing connections!

it’s a bit as if the following wiring is applied to every task added via #step

Additionally, you may add debugging steps, error handler or rewire the conditions dynamically without touching the original snippet.

Suppose that the validate task was getting quite complex and bloated. When writing “normal” Ruby, you’d break up one method into several. In Trailblazer, that’s when you introduce a new, smaller activity.

Knowing about the wiring mechanics in Trailblazer is one thing. However, the real fun starts with nesting activities. That’s when the ideas of encapsulation, interfaces and reducing dependencies really come into play.

Nesting an activity into another is a bit like calling a library method from another method

the explicit modelling has one massive advantage: all possible outcomes of the nested activity are visible and have to be connected in the outer diagram

or even configure its taskWrap

Please note that the I/O DSL is only providing the most-used requirements. Feel free to use the low-level taskWrap API to build your own variable mapping with different scoping techniques.

The absence of a method name here is per design: this object does only one thing, and hence what it does is reflected in the class name.

step :direct_debit

WE ARE CURRENTLY WORKING ON A UNIFIED API FOR ERRORS (FOR DRY AND REFORM).

An operation has two invocation styles. This is the only difference to an Activity.

Operations are often confused as god objects that do “everything”. However, operations are nothing but orchestrators.

In other words: the controllers usually contain only routing and rendering code and dispatch instantly to a particular operation/activity class.

Activities are a necessary abstraction on top of Ruby.

Instead of dealing with a mix of before_filters, Rack-middlewares, controller code and callbacks, an endpoint is just another activity and allows to be customized with the well-established Trailblazer mechanics.

An endpoint links your routing with your business code. The idea is that your controllers are pure HTTP routers, calling the respective endpoint for each action. From there, the endpoint takes over, handles authentication, policies, executing the domain code, interpreting the result, and providing hooks to render a response.

The endpoint gem is the missing link between your routing framework and your business code. It acts like a mix of before_filters and “responder” that handles authentication and authorization, invoking your actual logic, and rendering a response.

Endpoint is the missing link between your routing (Rails, Hanami, …) and the “operation” to be called. It provides standard behavior for all cases 404, 401, 403, etc and lets you hook in your own logic like Devise or Tyrant authentication, again, using TRB activity mechanics.

TRAILBLAZER-TEST The official stable release is only weeks away bringing you a bunch of new assertions that drastically reduce coding effort for tests! Of course, Minitest and RSpec will both be supported. TRAILBLAZER-STORY will follow as it turned out to be inevitable for setting up application state for tests. Instead of fumbling around with factories and traits in your tests, you “tell a story” about what to create in which order, easily customizable, and all written using activities. Currently, I’m working on designing the interfaces and it’s real fun!

In the past 1 ½ years something weird happened: a real core team formed around the Trailblazer gems. I say “real” because in the past 15 years of OSS, I’ve had people come and go, being of great help but never staying and taking over long-term responsibilities - which I found to be the pivotal element of a core team. Eventually, those kids convinced me to start the Trailblazer organization on Github and move over all “apotonick gems”. Over the course of time, I saw myself giving away that aforementioned responsibility with a smile on my face, adding owners and collaborators to gems, yes, even giving away entire gems, letting people work on documentation and just trusting someone and their skills. I have no words to describe how good that feels!

The legendary cfp-app will become a Rails-to-TRB refactoring tutorial.

A major improvement here is the ability to maintain more than two explicit termini. In 2.0, you had the success and the failure termini (or “ends” as we used to call them). Now, additional ends such as not_found can be leveraged to communicate a non-binary outcome of your activity or operation.

Yes, Trailblazer is adding new abstractions and concepts and they are different to the 90s-Ruby, but now, at the latest, it becomes obvious how this improves the developing process. We’re no longer talking in two-dimensional method stack traces or byebug hoops, the language and conception is changing to the actual higher level code flow, to activities sitting in activities structured into smaller step units.

To tell you the truth, the new tracing feature was the original reason why I decided to write 2.1 and make you sit and wait in agony for years. Nevertheless, tracing is simply blowing my mind. I can’t count how many hours and angering rushs of adrenaline I’ve saved since the introduction of the wtf? method and its helpful higher-level stack trace.

The trailblazer-workflow gem is currently a paid feature.

We use a subset of BPMN for the visual language in the editor, but added our own set of restrictions and semantics to it.

Their high degree of encapsulation makes them a replacement for test factories, too.

Operations completely replace the need for leaky factories.

In Trailblazer, models are completely empty. They solely contain associations and finders. No business logic is allowed in models.

Operations encapsulate business logic and are the heart of a Trailblazer architecture.

The bare bones operation without any Trailblazery is implemented in the trailblazer-operation gem and can be used without our stack.

An operation is not just a monolithic replacement for your business code. It's a simple orchestrator between the form objects, models, your business code and all other layers needed to get the job done.

While Trailblazer offers you abstraction layers for all aspects of Ruby On Rails, it does not missionize you. Wherever you want, you may fall back to the "Rails Way" with fat models, monolithic controllers, global helpers, etc. This is not a bad thing, but allows you to step-wise introduce Trailblazer's encapsulation in your app without having to rewrite it.