Implementing clean architecture is amazing. A clean architecture fundamentally changes the way you create software and perform changes to existing code. The architectural style, also known as Jacobson architecture or Onion architecture, is based on the business rules. Meaning the application model and use cases. These parts become the explicit core of such an application. The core is agnostic against the database, the web, and frameworks, which are then just plugins to the application.

Read more ...

In May 2014, I needed a Redis client. I had to collect log events within Redis (see https://github.com/mp911de/logcapture) during integration tests. The nature of integration tests and log events is, when tests are running, a lot is logged, but after the tests the connection is idle. Several clients caused connections to run into defective states, and I did not want remote log capturing kills my integration tests. So I took the best client amongst them all and started to fix the issues that were show stoppers.

Now, about a year later, lettuce 3.2 is the most recent version, three versions were released since then. Developing lettuce is amazing. It's by far the most advanced low-level client. There are others like Spring Data Redis or Redisson that provide high-level functionality. I'm not talking about those high-level clients. I guess, my biggest mistake was connection pooling. I was supercilious, and I was convinced, that connection pooling is a killer feature and a must. I had only my use case on my mind. @wg did not like connection pooling, too, and most probably it is the reason, why he never merged my pull request.

However, my best decision was to start working on lettuce. I learned a lot, and I was able to support nearly all Redis 3.0 features: Sentinel, Cluster and a ton of commands. The features are well received, and the downloads increase every month.

The question might arise: Where is the journey heading? What are the strategy and the roadmap?

I want lettuce to be the most easy-to-use, advanced, and, flexible Java Redis client. I want to provide a synchronous, an asynchronous and a reactive API. Spinach, the Java Disque client, is built on top of lettuce. A pull request for Spring Data Redis, upgrade lettuce to 3.2, is already in progress.

The roadmap for lettuce 4.0:

  • Advanced Cluster API: Provide means to run commands on a selected set of cluster nodes
  • Pipelining for specific cluster commands
  • Improve RedisFuture
  • Add a reactive API
  • Drop Java 6 and 7 support and maintain the 3.x branch for a certain time.
  • Streamline connection resources, so that users can use different API's for the same resource
  • More community feedback

I learned that plain Java futures are not flexible enough, that's the reason, why RedisFuture is a ListenableFuture. Lettuce 4.0 will use CompleteableFutures under the hood, and this will change the behavior. Currently RedisFuture.get does not throw an exception when the command errored within Redis. The ´RedisFuture.getError´ method provides the error text. CompleteableFuture's require to complete either with a result or with an exception, and that, will be a breaking change for async users.

Although downloads and the user base grow, the community around lettuce is far too small. I am grateful for every feedback and discussion on lettuce and it's API.

I want the community to grow. I created recently the mailing list/Google Group lettuce-redis-client-users and updated the contribution readme. Github Issues and the mailing list are great starting points to contribute.

The Geo-API of the upcoming Redis 3.2 release allows to maintain a set (backed by a Redis sorted set) of Geo points described by WGS84 coordinates. You can add and query set members using the new Geo-API. Use ZREM to remove members from the until https://github.com/antirez/redis/issues/2674 is resolved.

Read more ...

This release features Unix domain sockets on linux-x86_64 systems. Local connections to a Redis instance are now possible without the use of the network. A second feature with a huge impact is client options. Client options allow to control behavior on a fine-grained base. It is now possible to turn off auto-reconnect, validate the connection with a PING before activating the connection for client usage and many more.

Read more ...

I released today two betas of lettuce: 3.3.Beta1 and 4.0.Beta1. What is the difference between those versions? Both use netty and a very similar core to serve as Redis driver. The 4.0 branch introduces a Reactive API, stateful connections, improved API and command execution on multiple cluster nodes. 4.0 also introduces a set of breaking changes. The 3.x branch is supported for at least a year, new Redis commands will be supported in both branches. 4.0 is the next generation of lettuce.

Read more ...

This release features Unix domain sockets on linux-x86_64 systems. Local connections to a Redis instance are now possible without the use of the network. A second feature with a huge impact is client options. Client options allow to control behavior on a fine-grained base. It is now possible to turn off auto-reconnect, validate the connection with a PING before activating the connection for client usage and many more.

Read more ...

CDI is one of the best additions to Java EE of the recent. This opinion is widely shared amongst users and integrators. CDI 1.2, the current version, was released in April, 2014. Now in mid-2015, we face the early draft review of the CDI 2.0 spec. CDI 2.0 will run on Java 8 and higher.

Read more ...

It has been over a year ago the project started that I’m currently working on. This project had the goal to create an archiving service for grocery point of sales receipts. We ended up with creating an outstanding system that might become the new blueprint for software applications within the customers’ software development departments.

I’m now on a Java/JBoss/AngularJS project, that is heading towards it end. A triumphal end, since we created an outstanding software system in many various ways. The most impressive, the application has the potential to be the blueprint for future applications. It will influence how applications will be developed and operated in this particular customers’ software development teams. Here is the story.

TL;DR;

Focus on the important things. Choose your architecture style according to your needs. Functional requirements are by far not everything that make a successful software development venture. Postpone major decisions. Always be aware of the things you do, be lean, do TDD and automated integration/acceptance tests, use Continuous Delivery, make yourself a comfortable life with always delivering a bit more than required.
Read more ...

I released the first version of spinach, a scalable Java Disque client based on netty. spinach is built on top of the lettuce client which provides SSL and Unix domain connections in addition to plaintext connections.

Basic usage

DisqueClient client = new DisqueClient("host");
DisqueConnection<String, String> connection = client.connect().sync();
DisqueCommands<String, String> sync = connection.sync();
String jobId = sync.addjob("queue", "body", 1, TimeUnit.MINUTES);

Job<String, String> job = sync.getjob("queue");
connection.ackjob(job.getId());

Features

For complete information on spinach see the websites:

Links

Maven coordinates:

<dependency>
    <groupId>biz.paluch.redis</groupId>
    <artifactId>spinach</artifactId>
    <version>0.1</version>
</dependency>

Any feedback is appreciated or create issues on GitHub.

You might have noticed it if you are a developer. In rare occasions, there might be the case a particular artifact runs on your machine. But not anywhere else. This issue is known as the "It works on my machine" problem. As soon as this happens, ...

There are several causes, why this might happen. Either a different build process is used, the build environment is different, the way how you deploy is slightly different, the runtime environment differs from the others, the config looks like different, ... or a thousand more reasons might have caused that the artifact runs just on one machine.

Read more ...