The New NASA Calendar

AppSumo are Unrepentant Spammers

AppSumo are unrepentant spammers.

I signed up for a givewaway they advertised on Twitter, using a throwaway address. There was NO INDICATION that they would sign me up for their spam list. They even sent a confirmation link which I did NOT click on.

Today I got spam from them again on the throwaway address.

Avoid AppSumo until they learn how to be good email citizens.

Cassandra May (repeat, MAY) be Usable for Production After All

Cassandra 1.0 actually has a feature that, if the documentation is to be believed, relieves it of its worst misfeature: casually dropped replication events.  The story of the fix is entertainingly told in https://issues.apache.org/jira/browse/CASSANDRA-2034 (if you're into a certain kind of entertainment).

Thanks to Jake Luciani for the clue.  I don't understand why none of the Cassandra apologists who tried to tell me I was all wet about its replication flaws didn't actually, you know, mention this before now.  But it's not the biggest mystery I've ever seen.

Anyway, without having tried it 1.0, I can't give it a thumbs up.  Still, kudos for adding a feature that looks like the right thing.  I hope it really is.

PS: Cassandra needs to stop requiring half your disk to stay empty, but at least they're up front about that requirement.  If you can afford lots of unused disk, knock yourself out.

Salzenberg's Law of Pretense

Salzenberg's Law of Pretense: Trying to simplify technology by pretending a thing is something else always fails, because the pretense is itself a complication.  Putting a mask on a thing does not remove the thing, it adds the mask.  It thus requires new technologies to create the mask, identify it, remove it, and see behind it.

Examples: Unix symlinks, Unix device files, Unix pipes -- basically everything in Unix that uses an fd but isn't a local file; DNS CNAME records; and, most recently, making the Perl regex /ss/ match "ß".

Utility Corollary: If simplicity is not your primary goal, then adding a mask may work great.

Examples: same list.  Except for that /ss/ thing.

Why GlusterFS is Glusterfsck'd Too

Looking into GlusterFS, I find that its designers (like those of Cassandra) have failed to take replication seriously.  They depend on read repair to trigger checks for file consistency... and, unbelievably, they don't even trigger complete repair automatically after a node has been disconnected and reconnects:

    http://gluster.org/pipermail/gluster-users/2011-March/006958.html

The official docs imply this failure mode but don't quite spell it out, which is a bad sign.  The FAQ starts out with "When the brick comes back, glusterfs fixes all the changes on it by its self-heal feature," which falsely implies that self-healing is automatic.  Rather, the user has to know when it's necessary and has to make it happen quickly enough that another failure doesn't bite him.
   http://www.gluster.com/community/documentation/index.php/GlusterFS_Technical_FAQ#What_happens_if_a_GlusterFS_brick_crashes.3F
http://www.gluster.com/community/documentation/index.php/GlusterFS_Technical_FAQ#What_about_deletion_self.2Fauto_healing.3F
http://www.gluster.com/community/documentation/index.php/Gluster_3.2:_Triggering_Self-Heal_on_Replicate

What is wrong with these people?  What is the freaking point of making a distributed and replicated FS if you're not going to be a hardass about consistency and repair?  It boggles the mind.

 

Why Cassandra is Unfit for Production

Cassandra is a tragedy.

Database replication should be a queue, or otherwise kept strict track of. If a datum should be replicated from X to Y and Z, then if it hasn't gotten to Z yet, then it should eventually.  The database is allowed to fail to replicate at first, but it is not allowed to just give up.

Cassandra views 1000 replication events from X to Z as a flock of birds who set off toward their destination. Most should arrive. If some don't ... well, no problem, you still have at least 950, right?

Also, there is absolutely no backpressure to throttle a writing process that would really like to write as fast is it can but no faster. This makes replication failure much harder to avoid.

To deal with the consequences, Cassandra depends on read repair (which is ludicrous) and a manual process that amounts to read repair of everything all at once.

It's pathetic that the Cassandra guys won't fix these problems, or even acknowledge that they are problems.

The Toolsmith's Dilemma

When I am using tools is when I most want to fix them. But that is when I least can.  Right now, for instance, I am trying to write some fricking PERL APPLICATIONS, but what do I have on my mind? The ways the tools should be better.  I've even patched some of them:

• namespace::autoclean needs -except (patched on github)
• namespace::autoclean should support Mouse (patched on github)
• namespace::autoclean wipes out overload functions (patched on github)
• B::Hooks::EndOfScope calls the same callback more than once. sometimes (worked around on github, but I have no idea why that happens, and really we need real core feature for stuff like this, which are fairly obvious in implementation)
• Mouse introspection - method detection is lame (should work like autoclean)
• Moose inner/augment doesn't work if more than one function in a class uses it (lame)
• Method::Signatures::Simple has no invocant-less variant (obvious fix)
• Method::Signatures invocant-less variant causes assertion failures on Perl 5.12.1 when there is any syntax error elsewhere (wtf)
• NYTProf with Coro (crash and/or nonsense results)
• perl -d with Coro (crashola, so back to printf debugging)
• how cool a modern Perl debugger could be

Oh, and let's not even talk about the incredible panoply of core features and redesigns just asking to be written! First, for example, a real working is_num and is_str that I know how to do, just haven't been able to get to.

But I have actual programs to write, don't I?

Lesson learned: it's too late for Perl, but if I want to keep writing C++ productively, I conclude that I must never peek inside another C++ compiler for the rest of my life.  And probably not the Boost libraries, either.

Child's Play

When I was a mere sprout I learned to play 3D chess. It wasn't the Star Trek kind; it was three full boards vertically aligned. The details of the rules variant I learned don't matter... the point is, if you think the solution space of normal chess is big, just imagine that when you think you have the enemy king cornered, bloop it goes one level UP.

During this period, my stepfather uncharacteristically invited me to play chess with him. And when the game began, I was astounded at how simple it was. Only ONE plane! Child's play, literally.

That's what it feels like to switch gears from C++ to Perl.

Retrofitting Modern Perl, Part Dieux

As a first step to introducing modern Perl to the Topsy code base, I've created a Local::Std module that provides all of the basic features I think no Perl program should be without.  It's all the same idea of what ToolSet does, but with a bit more control.

Of course Moose support is necessary when writing OO code.  There is much of Moose that annoys me, but using it is definitely better than not using it.  Then again, for many cases, Mouse is adequate.  So we use Any::Moose to allow loading either.

Also standard for classes are my own MooseX::Locked (when using real Moose) plus MooseX::StrictConstructor (which ought to be the Moose default, really).

I also provide easy access to MooseX::ParameterizedRole.  When you need a PR, you really need it.

The interface to all this is very simple, an absolutely vital design point:

• use Local::Std - only language features (described in a future post)
• use Local::Class - Std + Any::Moose + namespace clean
• use Local::Role - Std + Any::Moose('Role') + namespace clean
• use Local::RoleParam - Std + Moose + MooseX::ParameterizedRole + namespace clean

Next post: The language features in Local::Std.  Lots of goodies.

PS: I have ported autoclean to Mouse.  I hope the patches are accepted upstream.  Meanwhile, when using Mouse, we fall back to namespace::clean.  This seems ... less than ideal.

Retrofitting Enlightened Perl: Part 1 of N

At Topsy we started developing our code base before the Perl Enlightenment reached us.  So there is quite a bit of modernization to do.  Fortunately, this is (1) relatively easy to automate and (2) fun.  I'll be writing about this process as it proceeds.

First steps in reforming an old code base involve janitorial duties: (1) Fixing any actually bad things that have crept in; and (2) Trimming out unused code (no use in renovating a room you never use).

In our case, the old bad code includes some classics:

• Lack of "use strict".  Yeah, I know, I don't get it either.
• Lack of "use warnings".  Not as big a deal, but still not acceptable.
• Use of "perl -s".

Now "perl -s" isn't as evil as you might imagine, in context.  Sure, it turns any command line option into an assignment to a global variable.  And if the code were being packaged for someone else, that would be awful.  For internal use, this hack's functionality is not an issue.  However, usability is still an issue.  If I misspell a command line option it's just impolite not to tell me about it.  Getopt::Long is my argument parser of choice; so far I haven't seen any compelling improvements on it.

But back to strict/warnings.  You might think that the first step is adding "use strict" and "use warnings" to all our Perl code.  But under the assumption that there will be more standard modules to load (sneak preview: "mro" and "Method::Signatures"), the first step is actually to create an "Std.pm" module that does all the, well, standard things.  One can use ToolSet to to do this, but as always, TMTOWTDI.  And of course if it weren't automated we wouldn't be properly Lazy.  More on this tomorrow.

Why I Only Use ThinkPads: Keyboards

By request, here's some more detail about why ThinkPads are uniquely qualified as tools for typing, which is what coders mostly do. I started ThinkPads with a 765, went through a couple of A30s and T2x and T4x models, today I use a T61p, and I am drooling over the T510, so I am walking this walk.

First, there is nothing better than the TrackPoint (a.k.a. nipplemouse among other things). I can't abide trackpads; I always disable them on UltraNav keyboards. Trackpads are too easy to touch by accident, especially when using your palms to stabilize the computer that is both topheavy and highly valuable. Trackpads also take your fingers away from the home row. I do see why some people dislike nipplemice - the right index finger can get overworked, and making big, fast, precision movement such as for artwork is harder. But I'm no artist.

As nice as TrackPoints are, the real killer feature of ThinkPad keyboards is their key travel and resistance profile. ThinkPad keyboards have long key travel compared to other laptops (this is Apple's major sin), nice key shapes, nice arrangement, and a nice resistance profile - keys start a little hard to push down, but finish easy. Tastes vary, I grant you, but if you've only ever used short-travel keys you don't know what you're missing.

Even within the ThinkPad brand, quality varies by keyboard OEM. NMB, Chicony, and Alps all make keyboards for the T6x series, for example. Google those names and discover a subcommunity of keyboard fanatics. Note that you have to buy by FRU, not part number. I will follow up with the FRU I use; I don't want to mislead readers by trusting my somewhat confused notes, so I have to take my laptop apart to be sure.

If your coding task absolutely requires a Mac, the plastic Macbook is less bad than the others. Something about the shape of the case in front of the keyboard makes the keys' short travel less annoying, and the plastic is much better at grabbing the heel of the hand than brushed aluminum (shudder). It is still definitely out of ThinkPad's class, though.

I should also mention that Toshiba makes/made a black shiny keyboard for some of its models (e.g. Satellite A300) that has very nice travel and resistance qualities as well. But then you're stuck with a trackbad. (That's a typo, but it was so appropriate I left it in.)

PS: Beware early T4xx and T5xx models. Lenovo experimented with replacing the strong aluminum keyboard baseplate with a glued aluminum and plastic base that was shot full of holes to save weight. It didn't work well. The corner keys suffered really annoying flexing.