Today we are proud to announce the release of Pond version 2.3.0 on npm.

This release contains the following improvements:

• Addition of observeAll and observeOne functions to the Pond – see our dedicated blog post
• Pond.dispose() will now properly shut down all async operations, so that applications may terminate orderly
• Fixed a bug where command serialization between subsequent calls to Pond.run() was broken if the argument Fish was originally woken by Pond.observe()
• Turn Pond.test() and Pond.mock() into synchronous functions
• Direct validation of arguments passed to FishId.of() – the strings must not be empty
• If the enqueue function passed to pond.run() callbacks is invoked after the callback has returned, it will now throw an error rather than silently fail to emit
• Support for nodejs 12 (LTS Erbium)

Happy hacking!

With the release of Pond 2.3.0 we are shipping two new major functions: Pond.observeAll() and Pond.observeOne() – they will make development a lot easier in some cases.

Sneak peak:
pond.observeAll(taskCreatedTag, makeTaskFish, {}, x => console.log('all tasks:', x))

In this blog post we give an overview of the new functions and explain the motivation behind adding them.

One of the many projects we’re currently pushing forward at Actyx is a port of the Actyx Pond V2 from TypeScript to C#.

C# and TypeScript build on very different foundations. Both are modern multi-paradigm languages; both have somewhat dynamic function dispatch mechanisms; but the typical C# program is still very much concerned with the runtime type of objects, as modelled by the CLR. TypeScript meanwhile is all about type shapes (or duck typing): The type system itself is quite strong, but its reality does not carry over into the (JavaScript) runtime.

One way this difference in typing plays out is union types. Union types are a cornerstone of TypeScript programming, and prominently feature in our TypeScript Pond interfaces. But C# does not have an exact equivalent. In this blog post we are looking at ways to preserve all the TypeScript Pond’s features, without giving up idiomatic C#.

In practical applications of differential dataflow to analyze factory event streams one frequently encounters a lot of strings. Those strings usually represent various names - of inventory articles, workstations, or activities. However, the straightforward approach in data flows rich in string objects may lead to a lot of unnecessary duplication which can result in high memory usage, unacceptable in small devices. Let's take a look at how we have handled this problem in Actyx internal BI pipelines using the Actyx Rust SDK.

It is with great pleasure that we announce the release of ActyxOS 1.0.0 today! After extensive testing we find this foundational product to be fit for general production use. Together with Actyx Pond 2.1.0, Actyx CLI 1.0.0, and Actyx NodeManager 1.0.2, this marks the general availability of the Actyx Platform.

The IT and OT landscape inside factories is extremely heterogeneous; many systems are necessary to efficiently and effectively produce goods. This enables purpose-built software with fast iterations, but obviously requires integrations between systems if data should be made available to other systems along the life cycle. In this article, we will develop a one-way integration: exporting data originating from the warehouse to the ERP system.

Today we have released Pond version 2.1.0 on npm.

This version does not bring new functionality; rather, it reduces the amount of exported types by a lot, hiding everything that is not part of the public API. This will make developing on the Pond in the IDE of your choice – like in our recommended editor, VSCode – much nicer, due to more relevant auto-complete and auto-import suggestions.

Read on for a brief explanation of how we cleaned up our type exports with the help of a tool called API Extractor.

Coming from centralized application models, designing an application running on top of a decentralized and distributed architecture requires a little mind shift. With help of a real world example, this blog post introduces one of basic building blocks of architecting a decentralized application: designing event schemata.

We are currently migrating our core event dissemination system to the Rust programming language, using the libp2p decentralised networking stack as a basis. In the process of doing so, we have discovered an interop issue between go-libp2p and rust-libp2p.

This post describes the process of finding and fixing the issue.

We are happy to announce the release of the Actyx Pond v2 (download from npm).

Read on for a brief overview of the changes, which we have developed with the goal of reducing boilerplate and allowing more flexibility and elegance in your application architecture.