lettuce 3.0.1 was released. This is a bugfix release fixing some major bugs.

This release contains:

Fixes

• Test improvements for more stability
• URI for sentinel connections
• Provide static syncHandler
• Handle premature channelInactive while ongoing close (avoid NPE)
• Fix signature of clusterSlaves #18
• Fix SCAN command with scan args

Enhancements

• Optimized CRC16 calculation (thanks to Jedis for co-working)
• Use fine grained exceptions for Timeout, CommandExecution and Connection

Links

• Release on Github
• Artifact overview on Maven Central
• Download lettuce 3.0.1.Final
• Wiki
• Maven Site (Javadoc)

Maven coordinates:

<dependency>
    <groupId>biz.paluch.redis</groupId>
    <artifactId>lettuce</artifactId>
    <version>3.0.1.Final</version>
</dependency>

<dependency>
    <groupId>biz.paluch.redis</groupId>
    <artifactId>lettuce</artifactId>
    <version>3.0.1.Final</version>
    <classifier>shaded</classifier>
</dependency>

Any feedback is appreciated or create issues on GitHub.

When CDI and Inifispan meet you've got the chance to improve your code a lot. Let's combine both to make all of your CDI beans @Cacheable.

Caching of values usually goes this way:

public String getSomething(String input) {
    String result = cache.contains(input);
    
	if(result == null) {
        result = getValueFromDatabase(input);
        cache.put(input, result);
    }
	
    return result;    
}

This pattern repeats for every value which is cached/retrieved. Methods like the one above contain repetitive conditionals and value retrievals. Using the caching interceptor pattern eliminates the need for repetition. Business methods will be reduced back to their essence and caching becomes an aspect.

@Cacheable
public String getSomething(@CacheKey String input) {
    return getValueFromDatabase(input);
}

lettuce 3.0 was released. Lettuce is a scalable thread-safe Redis client providing both synchronous and asynchronous connections. Multiple threads may share one connection provided they avoid blocking and transactional operations such as BLPOP, and MULTI/EXEC. Multiple connections are efficiently managed by the excellent netty NIO framework. Support for advanced Redis features such as Sentinel, Cluster and Redis data models are included.

Some of the major changes are:

• Support for the latest Redis commands
• Redis Cluster support
• Redis Sentinel support
• Upgrade to netty 4.0.19 (from netty 3.x)
• CDI and Spring support
• Streaming API
• Listenable Futures (using Guava) for true async operations
• Tons of bugfixes, tests and documentation

Lettuce 3.0 is a fork of original [email protected] with preserved packages and mostly the same API. The original lettuce is no longer in active development.

What's next?

My plan is to keep up with tight Redis development and to integrate the new fork into Spring Data Redis. Redis Cluster has to get mature, and the current implementation has to prove in production.

Links

• Release on Github
• Artifact overview on Maven Central
• Download lettuce 3.0.Final
• Wiki
• Maven Site (Javadoc)

Maven coordinates:

<dependency>
    <groupId>biz.paluch.redis</groupId>
    <artifactId>lettuce</artifactId>
    <version>3.0.Final</version>
</dependency>

<dependency>
    <groupId>biz.paluch.redis</groupId>
    <artifactId>lettuce</artifactId>
    <version>3.0.Final</version>
    <classifier>shaded</classifier>
</dependency>

Any feedback is appreciated or create issues on GitHub.

When releasing lettuce 3.0-Beta3 I was sure this will be the last beta of lettuce 3.0. In the mean time lots of stuff came up: New redis features around clustering, new commands and data structures. On the dev side there was low test coverage and instabilities during the build. This were the reasons to release an third beta. The original plan was to head for final as soon as redis 3.0 is going to be releases.

I've released today logstash-gelf 1.5.3. This is a bugfix release for Hadoop Hive users. I did not announce release 1.5.2 the last time. Apologies for that.

lettuce 3.0.Beta 3 is out now. The new redis commands provide in addition to the basic support also data structures and parsers. This is to support common implementation tasks and to ease adoption.

The Beta 3t is a surprise, because I wanted to release the final after Beta 2. Meanwhile, redis added lots of features and in fact, lettuce was not ready for a final yet. I'll state more about the details in a further, final announcement post. For now enjoy the Beta 3.

A while ago I was inspired by the story of Gameboy to SuperPiBoy, a Raspberry Pi within a Gameboy case. This was reason enough to start my own project. I was owner and a fan of a Gameboy at the age of 10.

My RaspiBoy features:

• 3.5" TFT display
• 32GB solid state drive
• RasperryPi inside
• three more buttons
• WiFi
• Logitech Unify receiver
• Original Gameboy controls
• External Volume control with Speaker and stereo audio connector

Test-driven development is a life-assurance for several software projects.

I’ve started about 10 years ago with test-driven development. Since then I fell into the mantra writing test code then production code run the test and start over. Sometimes even model and interface first then test code then production code and so on. This way less bugs had a chance to remain within production code. But unit testing is not everything. The next level is integration testing, which help to discover even more bugs. As soon as components play together, they start to behave slightly different than assumed in unit tests. Sometimes integration-tests are the only way to test a software (in a sensible way).

I'm progressing on my RaspiBoy project. So I'm getting in touch with a couple of yellowish Gameboy cases and game cartridges.

Older game console cases, such as Gameboy, Nintendo NES, Commodore 64 and so on, start yellowing. The more sun they get the more yellow they become. There is finally a solution (beside sand paper and overpaint) to de-yellowize them. It's called Retr0bright.

Logstash, Elastic Search and Kibana gave us power back over our logs. Now it’s time to expand our potential and use well known components to get even more out of the ELK stack.