One of the very first CTO-grade decision I had to take in the making of
Snoget was to pick what would become our main transactional persistence
engine. Since we're using Erlang exclusively for our production servers, the
solution seemed easy: use Mnesia. But I settled for PostgreSQL.
At this point, anyone who's been dealing with O/R mapping (like Ted Neward
who said: "Object/relational mapping is the Vietnam of Computer Science"),
should cry fool: Mnesia would offer me persistence without any impedence
mismatch with the application runtime environment and I preferred a SQL
database to it? Actually, to someone who has used an O/R mapper before and
who switched to Erlang, discovering Mnesia for the first time is a sheer
heavenly moment similar to that:
Though Mnesia is very clearly not presented as a replacement for general
purpose RDBMSes, one can not avoid to seriousl... (more)
In "Final Parameters and Local Variables", Dr. Heinz M. Kabutz rants against
the generalized used of the final keyword in Java code. For him, this is a
"trend' and an "idiotic coding standard".
I'm a firm believer of the complete opposite.
As a software developer, I spend most of my time reasoning about code.
Anything that can make this reasoning easier is welcome. Good practices like
short methods and descriptive names fall in this category. I believe
immutable variables do too.
Immutable variables simplify reasoning because they ensure a stable state
within a scope, whether it'... (more)
This blog is the formal introduction to the CRaSH console for Mule on which
I've been working for the past month or so. I've decided to interview myself
about it because, hey, if I don't do it, who will?
What is CRaSH for Mule?
It is a shell that is running embedded in Mule and that gives command-line
access to a variety of Mule internal moving parts. It's built thanks to the
excellent CRaSH project, a toolkit built by Julien Viet and sponsored by eXo
Platform, which allows the easy creation of embedded shells.
What can we do with it?
Well, it's easy to find it out. Let's connect ... (more)
In a recent blog post titled "The Limitations of TDD", Jolt Awards colleague
Andrew Binstock shared some reservations Cédric Beust has about TDD.
When a person of extensive experience like Cédric speaks about testing, you
pay attention. And I did.
Among the very interesting quotes from Cédric that Andrew has reproduced,
the following really struck me:
Another important point is that unit tests are a convenience for *you*, the
developer, while functional tests are important for your *users*. When I have
limited time, I always give priority to writing functional tests. Your duty
To be able to do anything useful, an ESB must be configured with all sorts of
parameters, from endpoint connection URIs to message transformation scripts
to content-based routing definitions. Moreover, ESBs like Mule can host
custom components, which will process messages and perform user-specific
actions on them.
Deploying a new version of an ESB configuration raises the question of
whether it will break anything. How can we build confidence that everything
will be just fine? If unit testing did it for standard software development,
what can it do in the realm of the ESB? Since... (more)