Saturday, July 21, 2018

How to Make Aggregates Directly Handle Commands In Axon

In 2015, I created the exploringCQRSwithAxon example project while learning about CQRS and the Axon Framework.

When I did, I set up the example project in such a way that it uses command handler classes. The setup was as follows:
  1. A controller receives a request via an endpoint
  2. Controller turns the request into a command and put it on the command gateway
  3. The command handler classes listens to specific commands. When a particular command it listens to is published via the command gateway, it loads the aggregate from the repository.
  4. The command handler class calls method on the loaded aggregate with the command that was published.
The 3rd step, most of the time, is unnecessary and can be eliminated. This is because the command handler class usually just serves as a dummy proxy that proxies commands to the aggregates.



Saturday, July 14, 2018

ip-num 1.1.1 is Released

ip-num, version 1.1.1 is now available.


I will quickly highlight some of the new features, improvement and some bug fixes contained in this release.

Support for IPv4-Mapped IPv6 Address

It is possible to embed an IPv4 address within an IPv6 address. Doing this involves using the least significant 32 bits to encode the IPv4 address, the next least 16 significant bits is turned On, and the remaining 80 bits turned Off. The format of the "IPv4-mapped IPv6 address" Looks like this:

   |                80 bits               | 16 |      32 bits        |
   +--------------------------------------+--------------------------+
   |0000..............................0000|FFFF|    IPv4 address     |
   +--------------------------------------+----+---------------------+

ip-num now supports creating these kinds of IPv6 addresses. This can be achieved in various ways:

Converting from an existing IPv4
import { IPv4 } from "ip-num/IPv4";

let ipv4 = new IPv4("74.125.43.99")
ipv4.toIPv4MappedIPv6().toString() // produces ::ffff:4a7d:2b63

From an existing IPv4 using convenience method on IPv6
import { IPv6 } from "ip-num/IPv6";

let ipv6 = IPv6.fromIPv4(new IPv4("74.125.43.99"))
ipv6.toString() // produces ::ffff:4a7d:2b63

From dot-decimal notation using convenience method on IPv6
import { IPv6 } from "ip-num/IPv6";

let ipv6 = IPv6.fromIPv4DotDecimalString("74.125.43.99")
ipv6.toString() // produces ::ffff:4a7d:2b63

Convenience methods for creating IPv4, IPv6 and ASN from Binary string

ip-num now has method that allows the creation of IPv4, IPv6, and ASN instances from binary string.

import { Asn } from "ip-num/Asn";
import { IPv4 } from "ip-num/IPv4";
import { IPv6 } from "ip-num/IPv6";

let anAsn = Asn.fromBinaryString('1111');
let anIPv4 = IPv4.fromBinaryString("01001010011111010010101101100011");
let anIPv6 = IPv6.fromBinaryString("01001010011111010010101101100011");

Improvement to various Validators

Big fixes, increased test coverage and improvements were made to Validators. This mainly touches the Validator.isValidIPv4String() and Validator.isValidIPv6String() validators.

For a complete view of the changes included in the v1.1.1 release, please check the change log.

As usual, you can download the source here. Or just run:

npm install ip-num //or npm install ip-num@1.1.1

to add ip-num as a dependency to your next project.

Feel free to open an issue to discuss a feature or to report a bug.

ps: v1.1.0 was unpublished due to inadvertently publishing some dev dependencies as normal dependencies

Saturday, July 07, 2018

Rolling Your Own Monad To Deal With Nested Monads In Scala

In Thoughts On Working With Nested Monad Within The Future Monad In Scala, I wrote about how nested contexts (or technically accurate: nested monads) usually end up creeping into any Scala codebase. And how these nested contexts end up leading to unwieldy code base, that is hard to read and hard to work with.

In that same post, I then mentioned two techniques that can be used to regain readability when dealing with such nested monads. Since the post used the Future Monad as its focus, the first suggested technique was to encode the failure in the Future. The second technique was to use monad transformers.

The blogpost inspired a talk that I gave at the Amsterdam Scala Meet-up group. (You can find the slides from that talk here by the way). In the discussions that ensued after the talk, Devlaam suggested an alternative technique for dealing with the situation: which is to basically create a monadic structure that wraps around the value in the nested context.  Doing this would allow us to regain readability by being able to use for comprehensions with the created monadic structure.

In this post I explore how the idea of rolling your own monad can be applied as a third approach to dealing with the clunkiness of working with nested monad in Scala. Just as with the previous post, Future[Either[E, A] would be the nested monads that would be used for illustrations.