Refactoring towards a generic way of representing DaemonConfiguration
's bean properties, to convert them to and from system properties.
2014-12-27
Let's Code Jumi #344: Generic Properties (Part 1)
2014-12-14
Let's Code Jumi #343: Phase Change Pattern
I invented a design pattern which makes it easy to update immutable objects without language support, by providing a way to make an object immutable and back again mutable.
2014-12-11
2014-12-02
Let's Code Jumi #341: Unit Tests (Part 1)
I have a bunch of ideas how to still refactor the daemon and suite configuration classes, but a prerequisite for quick refactoring is good unit test coverage.
2014-10-28
2014-10-23
2014-10-19
Let's Code Jumi #338: Daemon Configuration (Part 1)
The SuiteConfiguration
class is a bit non-cohesive, because it holds also daemon-related parameters which are used differently from suite-related parameters.
2014-10-01
2014-09-17
2014-09-03
Let's Code Jumi #335: Suite Configuration (Part 1)
To avoid changing JumiLauncher always when new suite parameters are added, the current approach needs to be refactored.
2014-08-30
2014-08-28
2014-08-25
Let's Code Jumi #332: Lifecycle Messages (Part 1)
The daemon process should print its version number on startup and another message on shutdown. That would make reading the logs much easier.
2014-08-18
2014-08-15
2014-08-12
2014-08-09
2014-08-06
Let's Code Jumi #327: Shutdown Timeouts (Part 1)
Connecting the dots to shutdown the daemon after a timeout, after the launcher disconnects or doesn't connect in the first place.
2014-07-29
2014-07-20
Let's Code Jumi #323: Flakiness (Part 1)
I think I finally found the cause of the flaky network and end-to-end tests; a concurrency issue in what events Netty fires. Also the tests for the timeout class and resource cleanup had issues. Concurrency is hard.
2014-07-17
2014-07-13
2014-07-09
Let's Code Jumi #320: Timeouts (Part 1)
Testing anything which deals with the current time is hard, because you need to fake the current time or else suffer from flaky and/or slow tests. Encapsulating time and hiding it behind easily testable abstractions is the way to go.
2014-07-06
2014-07-03
Let's Code Jumi #318: Multiple Clients (Part 1)
Improving the network layer to support multiple clients connecting to the server.
2014-06-28
2014-06-22
2014-06-18
2014-06-14
2014-05-31
Let's Code Jumi #313: Releasing Resources Test (Part 4)
I was able to figure out a way to get a list of all Socket
and ServerSocket
instances, so it will be possible to write a test that the launcher closes all network connections.
2014-05-29
2014-05-26
2014-05-21
Let's Code Jumi #310: Stopping Threads (Part 1)
The easiest resource to release is JumiLauncher
's actor threads, which also drives us to promote some bootstrap test code into production code.
2014-05-09
2014-05-05
2014-05-01
Let's Code Jumi #307: Releasing Resources Test (Part 1)
We could test individually that the launcher releases each resource (i.e. threads and sockets) when it is closed, but it would be easy to forget some resource. So let's write a generic test that all resources are released.
2014-04-04
Let's Code Jumi #306: Disconnecting
In order to make the daemon exit after the launcher disconnects, we must implement disconnecting network connections and a notification about the disconnection.
2014-04-01
2014-03-21
Let's Code Jumi #304: Daemon Shutdown (Part 1)
With the launcher code made clean, it's possible to start implementing the shutting down of the daemon process.
2014-03-19
2014-03-12
2014-03-10
2014-03-06
Let's Code Jumi #300: Unit Tests (Part 5)
The formerly monolithic JumiLauncher
has now been split into multiple actors, each of which can be more or less unit tested in isolation.
2014-03-03
2014-03-02
2014-02-22
2014-02-18
2014-02-15
2014-02-13
Let's Code Jumi #294: Network Layer (Part 1)
The current network layer is too tightly coupled to the idea that the launcher connects to the daemon. Let's create an anti-corruption layer over Netty.
2014-02-12
2014-02-02
2014-01-29
2014-01-22
Let's Code Jumi #290: Unit Tests (Part 1)
The formerly monolithic JumiLauncher
has now been split into multiple actors, each of which can be more or less unit tested in isolation.