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 ESBs are becoming increasingly
familiar in corporate IT, getting concrete answers is of interest to more and
This article details the testing strategies I employ for Mule ESB-driven
projects, which I think contain elements that could be generalized to other
platforms. I am cer... (more)
In "Working Effectively with Legacy Code", Michael Feathers gives this
To me, legacy code is simply code without tests.He also adds:
I've gotten some grief for this definition.Indeed, defining legacy code is
After purging one of our project from code that we consider legacy
(deprecated, EJB2...), we noticed this interesting trend in our Sonar
Notice how code coverage is way less affected than complexity and rules
compliance. Our legacy code had test coverage, not the greatest ever, but it
Therefore, I am wondering if we could then postulate th... (more)
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
Call Me Never (Ignite Talk)
I've been super honored to give an ignite talk during DevOps Days Vancouver
2014. Ignite talks are intense, as the slides mercilessly fly-by every 15
seconds, and this for 5 minutes sharp (yes, that's just 20 slides!).
In this talk, I tried to present some of the lessons we've learned
at Unbounce while rebuilding our page serving infrastructure. Our
availability target is five-nines (that's an allowance of 6 seconds of
downtime per week) so we've put lots of effort into building a stable,
self-healing, gracefully-degrading piece of software. We had a f... (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)