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 few close
calls though, hence the lessons learned shared in this talk.
I was initially planning to cover this subject in a 30 minutes talk and had
gathered tons of material to go in-depth, so delivering this material in 5
minutes was an interesting challenge! It was good actually, as it forced... (more)
During the past months, ToughtWorkers have been regularly pounding on ESBs in
a manner that Martin Fowler has neatly summarized like this:
"Hang around my colleagues at ThoughtWorks and you soon get the impression
that the only good Enterprise Service Bus (ESB) is a dead ESB. Jim Webber
refers to them as Egregious Spaghetti Boxes. So it's not uncommon to hear
tales of attempts to get them out of systems that don't need them."
The reasons for such a reaction to ESBs are multiple and, more often than
not, very valid. I think they stem from two main issues: the proprietary
nature ... (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)
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)
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