A very tiny handful of you may know that I was trying to push YAPC::Cuba. Later I expanded the idea to be a more general open source conference in Cuba as that would likely be a better fit. Sadly, it appears that it's not to be (or at least, not to be through me). There was a fair amount of excitement at the idea from those I spoke with. Quite a few said they wanted to be involved and would contribute time and effort to it, but as is often the case with volunteers, time is at a premium and dedicating volunteer time to a long-shot opportunity is understandably low on their priority list.

And of those who I spoke with who said they wouldn't attend? They were invariably not US citizens. They expressed concern about repercussions from the US government for attending a conference they were legally allowed to attend.

Isn't that sad? People are afraid of the US and it kills the chance to have an interesting conference at a time when it seems perfect for Cuba and the world to be talking.

While I'm writing my beginning Perl book, I've developed several tools to make my life easier. However, I've encountered a problem. I've often found that I am using iTerm2 in full-screen and this obscures my battery indicator. If I'm not plugged in, my battery can get dangerously low. I've fixed that.

I'm doing some work with ElasticSearch and while I find Clinton Gormley's Perl interface to ElasticSearch to be excellent, the ElasticSearch docs have left me a bit confused at times. It's based on Lucene, so while trying to find examples of analyzers for non-English langauges, I found a quick introduction to Lucene.

That introduction said I could find a list of analyzers for other languages in the Lucene sandbox.

Except that's a 404.

So in hunting around some more, I find this email which explains that the sandbox has been merged with the rest of the codebase and is now at this subversion repository.

That repository has a single file named trunk_development_moved.txt and clicking on that gives me:

    As of 2010-03-23, development of Lucene Java moved to a
    new SVN folder and was merged with Solr development:

    The combined checkout of Lucene+Solr can be found here:
    https://svn.apache.org/repos/asf/lucene/dev/trunk

    If you are only interested in Lucene Java, use:
    https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene

Sigh.

Digging through further eventually led me to https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/contrib/sandbox/ which is, apparently, the elusive "sandbox".

Except that the analyzers for other languages have apparently been removed. Time for more snipe hunting ...

I'd like to find an alternative to the term "technical debt", but I doubt I could convince people to adopt it. Technical debt is so ingrained in the programmer's consciousness that we seem to confuse metaphors with synonyms. Metaphors are to synonyms as transvestites are to my wife (and that's an analogy I'm sure she's going to bring up over the dinner table).

Technical debt bears a resemblance to actual debt, but it's not the same thing. Like actual debt, it's accrued in the same currency (skilled labor over time) that must be used to pay it off. Like actual debt, it's often desirable if you need something now and can't wait for it.

We were discussing in email at work when Abigail put the nail in the coffin of the "technical debt is actual debt" debate. Specifically:

• Sometimes it's OK to default on technical debt (code rewrite, proof of concept, business requirements change, and so on)
• Monetary debt has a schedule on which you must pay it. Technical debt does not.

Got that? When you encounter technical debt in your code, you can decide to repay it or not. Try telling that to your bank. Or if it's in an old, stable part of your code which rarely needs updating or changing, is spending money refactoring that code more valuable than adding a new feature which might earn money?

When you see "technical debt", ask yourself, "do I need to repay this now?" If your answer to that is always "yes", you're a zealot and I'd rather not be programming with you in a professional environment even if I welcome your work in an open source environment. Technical debt is not debt, but we've heard it called "debt" for so long that we act as if it really is debt (I'm guilty of this too). Don't make that mistake.

Update: On reddit, one user points out that an unhedged call option is a better metaphor, though I confess it's not one which is likely to catch on.