Redesign of CIlib core for 0.8 release

The release of CIlib 0.7.5 will be out soon. We anticipate that this will be the last release of the 0.7.x series of CIlib and work will begin on the new 0.8.x series soon.

With 0.8, a few (large) changes will happen to the core CIlib library. Firstly, we are decoupling the simulator from the library completely. This means that the core library will be exactly that, a core library. Some design desicions made in the past are coming back to haunt us, so we'd rather just fix the problem instead of making it a known issue and living with it.

Additionally, the objects in CIlib currently know far too much about the objects they use etc. The core will migrate to use dependency injection (the hollywood principle) so that:

1. Testability will be a primary concern.
2. Lots of redundant code will disappear.
3. The cleanup will mean better code for the users of the library.

I encourage you to chat to us on the mailing list about these changes, they are long overdue and I'm looking forward to making the changes which will mean a better library.

Why I hate XML with more ferocity than a rabid dog

Right, so.... XML.

Yet another technology that has been misused and abused by the world. It's got it's uses, sure, but they are mainly directed to storing data for transfer between unrelated external entities.

Now, using XML just "because" is a silly idea. Period. I have never understood why people want to use XML when a plain text file can achieve the same effect. Processing and parsing XML with the libraries of today is terribly painful, I don't think anybody can argue with that. Some tools make it simpler, yes, but the verbosity of the representation results in far too many complications. Now add a schema into the mix and you will have a melting pot of things that should not exist in reality.

I hope this XML fad disappears sooner rather than later.

License updates

After receiving numerous requests to have the default license of CIlib altered, we have changed the license to the LGPL from the GPL.

This change should result in our users linking to the library much more simply. Well, that's about that. Head on over to the website and the forums for more info.

Getting functional

Recently, I've been doing some work in other languages such as Python. I must say, after the initial annoyance, the languages have become rather pleasant to use.

The biggest benefit was the ability to quickly get complex movements of data performed with very little effort in terms of the amount of code that I needed to write. The "functional" way as it were is, in one word, fantastic.

The paradigm advocates immutability (which I absolutely agree with) and concise statements whereby boilerplate code is kept to an absolute minimum. As a result of this, together with my enjoyment of Java has spurred me on to start learning Scala, the best of both worlds as it were. By learning a new language, I hope to improve the APIs available in CIlib. Such improvements will ensure that we focus on the intentions of the algorithms etc and not get bogged down with the implementation related difficulties.

I'd love to one day write concise statements like:

topology.foreach(calculateFitness)

Slowness? Nope. Just writing up.

It's been a while since I wrote something about of the stuff I'm up to. Currently, finalizing my MSc dissertation is taking priority, but I'll be back to hacking away on some CIlib code soon enough.

The main topics at the moment are the need to correctly fix some of the measurement APIs within the library and of course the pending refactor for dependency injection. Feel free to add some issues (if you have any) at the CIlib Google Code page.

In the meantime, here are some links to my more favored blogs:

• Google Testing
• Misko Hevery

That should keep you busy :P

Bootstrapping, the new frontier

Bootstrapping CIlib is providing some interesting challenges.

We need to have a selection of predefined bindings and then have them dynamically overridden when needed. This is only on the specification usage of CIlib, so the API usage will remain relatively unchanged (for the moment - some setters might be removed in future versions)

To address these issues, we have written some interesting code to get the overrides working correctly. This is still very much a work in progress, but I feel we are on the right track at least.

Nothing is set in stone at the moment, but the Bootstrapping API is changing a lot. It's exciting to get the new framework up and running :D

Core issues and Dependency Injection

It's something that has been a long time coming, but CIlib is in need of a little core refactoring to ensure that the code is maintainable and most importantly, testable.

I've spent a long time examining the various Dependency Injection (DI) frameworks that are available and I've finally decided on using Guice.

The core of CIlib will rely completely on injection to get the required instances in the required places. This does, however, mean that some serious changes will be needed on the inside, but they will be changes that users will not even notice.

CIlib has some static code (in the form of singleton instances and static accessors - Algorithm.get()) and this will be removed to ensure that the library is what it is supposed to be.

More to come on this refactoring as I get into it.

Also, it's almost time to commit the missing code / algorithms :) Keep an eye out for the new Evolutionary Programming and Evolutionary Strategies algorithms that will make their way into the master branch soon.