tigretigre.com

So you've built out your unit tests with mocks and everything is looking peachy. But the next thing you know you have to extend a class here or there, tweak a little functionality. Maybe the cases that you so carefully mocked are suddenly no longer valid. Or maybe a few assumptions crept in that never really are valid in the first place. If your test suite is comprehensive enough you'll certainly catch it eventually, but possibly only after a monstrous cascade of test failures that don't make it clear where the real problem is. How can you guard against this sort of class-mock drift?

Here's a situation I often find myself in: I'm writing two routines that share essentially identical structure and differ only on a few values. The obvious DRY approach is to put the common stuff in a single subroutine and the specific stuff in two wrappers. Simple enough.

Every now and then, you want to be able to do certain things if you're inside a transaction that you wouldn't otherwise do, or conversely do some things only if you're not inside a transaction. MySQL doesn't give you a simple way to do that. You might think just checking the value of @@autocommit would do it, but no such luck, because that doesn't work if the transaction was started with start transaction (or one of its aliases, e.g. begin).

I have a love-hate relationship with Perl's scoping model. It has quite obviously grown over time so it is kind of twisted and knotted like a tree. However, all those twists and knots make it easy to climb if you know what you're doing. So lets review the different types of scope:

I just recently read Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck. Very insightful and replete with wisdom derived of experience. What just struck me though was how many of the principles relate to my ongoing study and practice of the ancient Asian strategy game of Go. Maybe there's some shared Japanese philosophy behind it all that I just happened upon.

If there's a place you wanna go, I'm the one you need to know...

My boss tells me I have "an unhealthy fascination with map". That may be true, but it's only because map is a perfect example of what makes Perl Perl. Let's take a quick stroll through some of the ins and outs of this wondrous little function, shall we?

I used to like Perl. The past few months using it as my main language, I grew to really like it a lot. What had me fall head over heels in love, what inspired me to start this new blog series: hash slices. Anyone who's been around Perl at all knows hashes (i.e. associative arrays, to use the behavioral description rather than the implementation description). They are a core feature that set it apart fairly early on as a force to be reckoned with, and has been emulated numerous times due to it's simplicity and power.

Someone asked me to elaborate a bit on what would motivate participants in my SOA social-network aggregation scheme. So here's my take on it at this stage of the game.

It's about time I started getting down to brass tacks on how I will implement a proof-of-concept of my SOA-based content aggregation scheme. I guess for that, I'm going to have to build some services. I'm taking an object-oriented approach, and hopefully one that can be applied in multiple languages/platforms and can be used to implement services using a wide range of protocols.

Google tells me today that I am for the moment the world's foremost expert on SOA-based social-network aggregation, so I figured I'd better have more to say on that topic. Fortunately, I do.

First, a little further review of the existing literature:

• Wikipedia has a good summary of the standard sort of social-network aggregators you'll find out there, but as I said before, they are all going about it with the master portal approach.