DecoratorInjector in Python by Yannick
My friend Yannick is a huge fan of the Python programming language. As a die-hard geek, he's been coding various hacks over the years, but for some very strange reason, he never published a single of his (sometimes really nice) hacks
We pushed him again and again, and I'm glad to announce that after more than a year of intense pressure, Yannick has just published the first of his hacks! Congrats Yannick, and thanks for not choosing the GPL
This first hack is called "DecoratorInjection" (notice the nice Sphinx documentation):
This is an internal DSL providing fluent interface to inject decoration, i.e. decorate methods at runtime.
Method names can be specified directly or using a method grabber, which introspect the class.
The DSL is quite pleasant to read. For example you can easily perform AOP on your Python classes using a decorator and the following declaration:
decorate(PUBLIC_METHODS).of(classes_named("DAO.*").within(somemodule)).using(tracer)
which sould be read as:
decorate the public methods of the classes whose name start with "
DAO" in the module called "somemodule" using the "tracer" decorator
Nice work Yannick, and please publish more of your Python hacks!
Initialization blocks in Java
I discovered yesterday a feature of the Java language that I didn't know of: initialization blocks. This is something that we rarely see in code, hence you may not be aware of their existence too...
You probably already know of static initialization blocks such as:
public class Foo { public static final int MY_INT; static { MY_INT = 1; } }
In this example, the static block is called when the Foo class is loaded by a classloader. It can perform anything you want of course, but its main purpose is to eventually initialize / configure static class fields.
What I didn't know is that you can have such blocks at the class instance level as well:
public class Bar { private int myInt; { myInt = 1; } }
Here this block is called before the Bar class constructors. It can do anything including touching instance fields.
I must confess that I can hardly see a use-case for this lesser-known feature of the Java language since one is more likely to use a constructor for such tasks.
It may be sometimes nicer to read with anonymous classes though:
MyListener listener = new MyListener() { { bind("this").with("that"); // etc } };
What do you think? Have you ever seen a great application of those blocks? I'm really curious!
Continuous integration: it’s not just about tests
Most people value continuous integration as the ability to run unit and integration test suites whenever a developer makes a change. For sure it has a lot of merits, but a continuous integration setup provides some benefits way beyond that.
We recently set-up a Bamboo CI server instance for IzPack, thanks to Codehaus, Atlassian and the anonymous company that gave a server to Codehaus for the purpose.
Quite often, continuous integration allowed us to be instantly notified of issues we would have spoted much later otherwise:
- files that were not put under version control (one developer can easily forget that!)
- use of Java 6 features while we target Java 5 compliance.
I'm sure you can get other examples as well, but the point is clearly that a properly configured CI server helps you spot issues way beyond just failing test cases, as it should be rather viewed as a constrained, automatic, developer agnostic build environment.
By the way, I’m looking for job
In case you didn't know, I am currently looking at every good job opportunity that may arise
You can get the PDF version of my CV.
I am primarily looking for a position based in France (I just want to avoid Paris) where I can build on my previous experience and push forward challenging projects.
Do not hesitate to contact me!
