Sibling projects

Blogs : Latest entries

I'm not sure at all who's still active in the server-side web development world, but it seemed best to reach out through the old channels in case some people are interested in reviving RIFE.

I've personally been busy with a lot of other projects during the last 7 years, ranging for high-performance clustered data tools to real-time musical instruments.

I'm now working at ZeroTurnaround on the LiveRebel product and am being confronted with the state of web development nowadays. To my surprise, in many ways the approaches in RIFE are still relevant and even the Play framework is lacking quite a lot of RIFE's simplicity and power.

So, a few months ago I started work to analyze what I want to keep from RIFE version 1 to build a fresh version 2: https://github.com/gbevin/rife. I took a little break to work on another quick pet-project in the meantime (http://uwyn.com/geco) but that's now all ready for launch.

The idea is to basically put a lot of things in question about RIFE and trim it down, throw away a lot of the junk that was accumulated and make the features very opinionated and targeted.

My initial plan of action is this:

focus on pure Java and byte-code instrumentation, no scripting languages

leverage the upcoming features of Java 8

rebuild the template engine with largely the same ideas in place, but clearer and more focused

properly finish the isolation of the continuations engine and bring it up to date

rethink the infrastructure with IoC as a starting point, instead of having it as an afterthought

totally rewrite the web engine, with similar principles but much more conventions and less configuration

trim out the database abstraction layer for only certain relevant databases

I've started mocking up the new version of the template engine and took an initial stab at creating an Antlr 4 grammar. That sadly is really not working out so I've started work on a new custom parser.

One of my mistakes with RIFE v1 was that I didn't involve the community much during the development process, so I want to change that.

We've all been there, you start with a class and a simple constructor that makes total sense. As time goes by, you keep adding features and the list of constructor arguments grows … and grows … until … it becomes unusable. This is exactly what happened with the Cache class in Ehcache.

The version 1.0 constructor looked like this:

publicCache(String name,int maxElementsInMemory,

boolean overflowToDisk,boolean eternal,

long timeToLiveSeconds,long timeToIdleSeconds)

However, with version 1.7 this turned into:

publicCache(String name,int maxElementsInMemory,

MemoryStoreEvictionPolicy memoryStoreEvictionPolicy,

boolean overflowToDisk,String diskStorePath,

boolean eternal,long timeToLiveSeconds,

long timeToIdleSeconds,boolean diskPersistent,

long diskExpiryThreadIntervalSeconds,

RegisteredEventListeners registeredEventListeners,

BootstrapCacheLoader bootstrapCacheLoader,

int maxElementsOnDisk,int diskSpoolBufferSizeMB,

boolean clearOnFlush,

boolean isTerracottaClustered,

String terracottaValueMode,

boolean terracottaCoherentReads)

There are a lot of downsides to relying on constructor parameters like this:

the author of the class needs to continue to overload the constructors to add new parameters

users need to decide which overloaded constructor they want to use

users need to figure out what sensible default values are for the values that they're not interested in

it's very easy to accidentally put a value at the wrong place and provide wrong parameters

reading the constructor afterwards is a nightmare and can't be done without looking at the Javadocs at the same time, for instance:

newCache("myCache",10000,MemoryStoreEvictionPolicy.LRU,false,

null,true,60,30,false,0,null,null,0,0,false,

true,"identity",true)

However there some advantages:

you can enforce which parameters are mandatory

at instantiation you can validate the constructor parameters

at instantiation you fully set up the instance without requiring users to call an initialization method

So, we decided to change the Cache constructor approach in Ehcache 2.0 and use a builder pattern with a fluent interface, keeping the advantages of the parameters approach but solving all the problems.

The version 2.0 constructor looks like this:

newCache(CacheConfiguration config)

We then created a constructor in CacheConfigurator with the strict minimal number of parameters that are required for a cache to function:

publicCacheConfiguration(String name,int maxElementsInMemory)

All the other parameters are implemented as fluent interface methods as well as regular setters and getters so that instances of the class can be used as beans:

publicfinalCacheConfiguration clearOnFlush(boolean clearOnFlush){

setClearOnFlush(clearOnFlush);

returnthis;

}

This allows the example above to be rewritten like this:

newCache(newCacheConfiguration("myCache",10000)

.eternal(true)

.timeToLiveSeconds(60)

.timeToIdleSeconds(30)

.terracotta(newTerracottaConfiguration()

.clustered(true)

.valueMode(ValueMode.IDENTITY)));

The end results are that:

we can continue to expand the CacheConfiguration class without ever having to change the constructors of the Cache class

the user doesn't have to figure out the defaults for parameters he doesn't care about

the configuration parameters are self-explanatory by simply looking at the available API methods

anyone can read the usage of any Cache constructor and understand what each configuration value's purpose is

Ever since I upgraded to Snow Leopard 10.6.1, my MacBook Pro startup and shutdown was much slower than before.

I searched for a quite a while on forums to find the solution, but nobody seemed to know a solution. I finally figured out what it was. It seems that somehow the ownership of my startup volume's root directory (/) wasn't assigned to the root account anymore, but to my account instead. This made the kernel prelinking fail since it requires that root is the owner.

I picked music back up after a loooong hiatus of 7 years. I decided to evolve together with the world and to broadcast myself .

Did the first one last night. The song is "All The Kings Horses" from Robert Plant and the Strange Sensation. When I heard it playing last afternoon from my iTunes collection, I couldn't help picking up my guitar to figure out the chords and such. This recording is the result of a couple of hours searching and rehearsing. I'm considering adding it to a concert repertoire I'm preparing, as one of the few cover songs.