How to Get Your CorDapps Wrong, Right

A good user experience helps people to enjoy the product they’re using. If you think of some of your favourite products and apps, you’ll be able to spot things which make it enjoyable. It’s probably been designed with empathy, by people who not only craft the experience but deliberately participate in it. It will have affordances which, once you have the product, prompt you in how to use it. It will give you useful information on the effects of your actions, and it will warn you if you’re about to do something irrevocable, or that won’t work.

When thinking about Developer Experience, we consider the same kind of aspects. We want our code to be easy and enjoyable to use. We want a clear interface that guides you in its use. We want to give useful information about the effects in play. We try it out ourselves, and because even we get things wrong, above all, we want feedback.

Feedback is crucial in software development.

There’s usually an inverse relationship between how new something is, and how predictable its behaviour will be. Innovation and change are inextricably linked; nowhere more so than software development. The name, “soft”, gives it away. Changes, at least early on in the development cycle, are generally safe-to-fail. It isn’t like developing a nuclear power plant. If we have an explosion in our codebase, we can roll it back to the previous version.

That is, of course, if we know that there are problems.

The best time to find out that there’s a problem is right after the problem has been created; while it’s still fresh in the developer’s head, and before they’ve left it behind to focus on something else; or, you know, just left. A bug that’s just been created can take minutes to fix.

Even half an hour of delay means other code has been written on top, and it’s no longer simple to find the problem. It can take hours of debugging, loading new contexts and trying out different inputs to isolate it.

If your organization has a typical overabundance of work in progress you might not find the problem until you’ve moved on to another task. Now it’s stretched out to several days of work on five different things at once, each one of which results in a time-expensive context switch back to the one with the bug.

If we don’t find out about the bug for a week or two, it probably won’t get fixed for a week or two, and now it’s not even the same developer working on it any more, and the bugs are being triaged and it’s anyone’s guess whether it will be fixed at all.

It’s much, much nicer to find bugs early on.

Developers who are really keen to find out what’s wrong with their code will often practice some variant of TDD; writing examples of how a piece of code will work before they write the code itself. The act of modelling the code’s behaviour can help developers think about capabilities and responsibilities, driving cleaner design; and well-written tests can act as living documentation, helping newcomers understand the behaviour of the code without having to look at the internals. Even when tests are written after the code, this kind of “testing” has value beyond just regression checking. It makes the code easier to change, rather than pinning it down – and innovation means the code is always changing.

Having tools at hand to help drive out this living documentation, as well as giving feedback on what’s wrong with code, quickly, is invaluable.

Setting up a full, working installation of Corda 5, though, takes time. In operation it’s fast, but it’s an Enterprise product designed to be highly available. Even on a local Docker instance it involves installing prerequisites, spinning up over a dozen Kubernetes pods, packaging CorDapps with all the permissions, certificates and meta-info necessary for them to work, uploading them, and sending messages through to the end points. It can all be automated, but there’s still a lot of waiting for things to be ready. It moves feedback from seconds to minutes or tens of minutes. That’s enough time to be distracted and lose that precious focus.

So we’re creating some tools to give you faster feedback on your flows. We intend to release prototypes of these as part of DP2 – check out CordaCon for more announcements.

As well as a “lite” version of Corda 5 that runs without Kubernetes (but still requires packaging and upload and posting messages to end points), we’re exploring a simulator for Corda 5 that’s even lighter still.

Introducing the Corda 5 Simulator

It uses the same APIs, and constructs your flows in the same way that Corda does, but it works in-process and in-memory, and it works quickly. It’s designed to have an intuitive interface that matches, conceptually, the way that Corda works.

Note that this is still a work in progress, and the API is likely to change (as well as move to the corda-api repository), but you can see our current state of play in our Corda 5 open-source repo. You can build it yourself by cloning the repo and running:

./gradlew :cordapp-test-utils:test-utils:jar

Or publish it to your local Maven with:

./gradlew :cordapp-test-utils:test-utils:publishToMavenLocal

Here’s what it looks like to use it today:

    val corda = CordaSim()
    val alice = HoldingIdentity.createFor("Alice")
    val node = corda.createVirtualNode(alice, HelloFlow::class.java)

    val response = node.callFlow(
        RPCRequestDataWrapper("r1", HelloFlow::class.java.name, "{ \"name\" : \"CordaDev\" }")
    )

Simulator will check your flows and subflows for missing annotations and constructors, instantiate them, create the FlowMessaging, FlowEngine and FlowSessions needed for them to communicate, and persist entities for you (with one database per member, just like Corda).

It even comes with a ResponderMock that can be used to fake responses and check the initiating flow in isolation (InitiatorMock coming soon).

It isn’t intended to replace testing with real Corda, where permissions and certificates and networking all come into play. If you want to know whether your flows work with real Corda, then use real Corda.

If you want to know that they don’t work, though, the simulator can give you feedback on that, quickly; because your time and your focus are valuable to us, too.