use Perl

Its been a wild ride while it lasted, and I certainly learned a lot, not just about s/w development, but mostly about business. But after lone wolfing for several years, I've thrown in the towel and taken up with a database startup.

Alas, I'll be doing very little Perl for my new job; lots of C/C++, and my new overlords seem to have fallen pretty hard for Guido's koolaid, so I'll need to write a Python indenter . While I'll inject Perl where I can, I fear it'll be an uphill battle, and avoiding those is why I succumbed to captivity in the first place.

OTOH, I'll be doing stuff I've been doing for the better part of 20+ years, stuff I can do without getting out of bed, much less falling out. And I have a few notions I hope to inject into the product suite; the database field is starting to get crowded again, and anything we can do to differentiate is going to be essential to success.

And they're letting me do it from Reno, which was a big condition for me. The California thing lost its luster for me years ago; I especially revile the SillyConJob Valley nonsense. I live 10 miles from the CA line...and thats plenty close enough for me.

I also made them pick up the tab for my OSCON attendance, so I'll actually get to stay at a decent hotel this year!

What really made me steer back into the database maelstrom was the crew manning this startup. Some of them are almost iconic in the DBMS world, and they've been very succesful in the past; some others I've personally known for a decade or more. Hopefully, the cumulative experience will be enough to climb over the other startups massing around this particular niche. I commented to the VP of Engineering that, if the DBMS s/w didn't pan out, he could just pimp us all out as consultants at $300/hr and probably make more money!

That said, I am suffering some separation anxiety. Working on what *I* wanted to *when* I wanted to was fun, albeit frustratingly difficult/impossible to monetize. I've spent most of the last 5 years banging out Perl and (recently) Javascript, only doing XS/C when conditions demanded; now I'll be slogging thru mind numbingly slow and (esp) error prone C/C++ development. Hopefully I'll endure long enough to collect the gold ring.

In the meantime, I'm desperately trying to get Thread::Sociable into at least compilable shape and uploaded to a Google Code repository I setup some months ago. Unfortunately, life keeps getting in the way, so progress has been very slow. Its a damn shame I can't get paid to finish that up. I really think it would make a nice splash for Perl: faster shared access, real STM for real threads, and even shared nothing for those that prefer it, plus (for those that hate on ithreads) all that for process shared memory (without the Storable or DBM contortions of existing solutions). Hopefully, some others will attempt to grok my XS/C hacking and take up the cause. While I won't be tossing commit bits around like beads at Mardi Gras, I'll certainly open things up for those that express both an interest *and* the skill to comprehend it (the STMness gets pretty gruesome in places).

Oh well. Its my last weekend of independence, and another beautiful Sierra spring day, so I'd better get out and enjoy it before I jump on a plane on Monday.

Let me preface this by clearly stating I'm not blaming Mssr. Schwern, who has been very helpful, and a general Perl Hero. This situation certainly is not his fault, and in some sense he's as much a victim of DH as I am. But ever since I took him up on the DreamHost offer, I've been in hosting hell.

Since moving to DH, I'm confronted with

• sloooooow page loads (that is, when the site is up), even for simple static pages with a couple images;
• email frequently down or very slow;
• repeated screwups with my weblogs.
• for some odd reason, my sites (the static ones, no magic JS or server scripts) frequently cause FF 2.0.0.12 to crash...usually after trying to load the page for 10+ secs (no such problems in Safari, IE or Opera, thank god)
• server status tester frequently reporting "heavily loaded" (can you say "oversubscribed" ?)

I never thought I'd long for a return to my old host (Earthlink), but their overpriced, restrictive plans seem like nirvana now.

So I've got to find a new host and fast. I'm looking at Pair, since they've been Perl friendly for awhile now, and they run Perl 5.8.8. More expensive, certainly, but after the DH debacle, I'd rather pay a bit more and not have to constantly run a canary to verify my sites and email are still functioning. MediaTemple is also on my radar, tho they don't appear to be as Perl friendly as Pair.

If anyone has some recommendations, please pass them along! I'd love to help "Perl bloom", but its obvious that DH is all fertilizer and no substance.

Update

After way too much research, I've jumped to BlueHost, they seem to keep their customers pretty satisfied, and have pretty much everything DH does...except the downtime. BlueHost also has a nifty little Perl package installer to pull stuff directly from cpan; I haven't tried it yet, but it should be fun to play with. But I've still got lots of site xfer chores to finish before then.

BTW, anyone whoc opened a DH account since the 1st of the year is now pretty much dead in the water. And DH's response as to when it will be back up ? "Um, don't know, maybe by the end of the week ?"

I sure hope I get my refund before they go bellyup 8^(

I got a couple CPAN tester failures in my email today:

FAIL Win32-Font-NameToFile-0.10 x86_64-linux-thread-multi-ld 2.6.22.10
FAIL Win32-WebBrowser-1.02 x86_64-linux-thread-multi-ld 2.6.22.10

Yes, I'm shocked, shocked! to learn my Win32 modules failed on 64 bit Linux!

Seriously: I think we can do a better filtering job than this...if for no other reason than running tests for Win32 packages on Linux is a waste of CPANTester resources. How about

if (($filename=~/^Win32/) && ($^O ne 'MSWin32'))
{
    next;  # NO SOUP FOR YOU!!!
}

HTTP::Daemon::Threaded started as an apartment threading exersize. I was never comfortable with the plugin interface (all LWP based), but didn't have time to figure out a better solution in a threaded environment.

So when a user prodded me about it last week, it became a serious burr under my saddle.

After applying some IO::Scalar shenanigans, and a helpful %ENV hint from perlmonks, I'm happy to announce HDT is now CGI capable.

And just in time for IE8's 6 concurrent connection Web buster (I expect FF, Safari, and Opera will follow suit shortly).

Anyone interested in building the pure Perl replacement for Google Gears ?

Oh boy, new toys!

pQuery

See also pQuery

I'm not a big fan of jQuery, but pQuery should keep me busy this weekend 8^))

For "Tired of Perl Is Dead FUD", I generated a simple chart of Perl, PHP, Python, and Ruby job listings. It generated a lot more interest than I expected.

One of the common comments went something like, "Yeah, but there's no Perl jobs in my backyard".

Which aggravated a chronic itch I've had since first releasing DBD::Chart/ DBIx::Chart several years ago: how to support some kind of GIS visualizations. I've occasionally had users ask about GIS support, but it seemed like such a huge challenge that I've always begged off.

All the online mapping services are about "geo-location"; I'm interested in "geo-intelligence".

So when people asked "yeah, but where are those jobs ?", I decided to scratch that itch.

I found GD::Map, but its interface and rendering weren't quite what I wanted. So I've created GD::Map::Mercator. (Alas, I still haven't figured out how to integrate it into DBIx::Chart, but the experience helped me better understand the issues)

With that, and a Javascript widget I've been working on for another project, and a bit more detailed screenscraping, I've whipped up a Dynamic Language Jobs Map that provides some relative indicators of where those jobs are, along with a drill-down breakout of the Javascript, Perl, PHP, Python, and Ruby job counts. (Sorry, USA only; free/open, current detail GIS data for other locations is hard to find)

Note that I've added Javascript to the list, because its become increasingly important to me personally, and I suspect it either already is, or soon will be, important to other dynamic language users.

The cosmetics are still a bit rough in spots (despite minor intervention with Microsoft Paint), but hopefully its a bit more insightful. I'd hoped to get a deeper drill down using area code GIS data, but I've been unable to locate a free/open source for the data (if anyone knows of a source of such data, I'd be grateful if you passed along the info).

I'll try to update the data every couple of weeks; I've imposed on DICE's hospitality a bit more than I should; hopefully they'll continue to be gracious about my occasional scraping.

An interesting day for those of us that splash about in the DBMS end of the pool:

• Sun to acquire MySQL (tho for the life of me I can't figure out why...)
• Oracle to acquire BEA
• DBD::Pg 2.0 almost ready, with some nifty new features
• Proof that I'm not alone in my SQL madness affliction.

Javascript's prototype object system may be academically interesting, but its a royal PITA for coding decent class hierachies. (Just do a quick google on "javascript inheritance" and you'll see the madness that makes Perl's OO look like the purest of Smalltalk).

Most of the solutions I've seen tend to be bloated, slow, and only marginally less ugly than the original prototype wrangling they attempt to avoid.

As I'm in the process of bringing DBIx::Chart into the 21st century, I'm wrangling a lot of Javascript. And the long overdue refactoring of the rendering engine means a lot of object hierachies. But typing all the "ThisLongClassname.prototype.someFunction = function..." nonsense is really annoying, and jumping thru all the hoops to properly propagate methods up the class chain is a mind numbing exersize, not to mention an unreadable mess.

So I think, "Someone must have written a preprocessor for this stuff.". While Google turns up a few hits, they all appear to be full-blown Java to Javascript translators. All I need is something to bury the OO yak shaving; while the Java class declaration syntax is a reasonable choice, I don't want to carry all the other bloated baggage. And CPAN has loads of Javascripty modules, but none that address my little task.

Ergo...I've whipped up some Perl to do the translation, and the result is actually pretty reasonable. Just declare classes like

class Parent {
    Parent(first, last) {
        this.first = first;
        this.last = last;
    }

    toString() { return this.first + " " + this.last; }
}

class Child extends Parent {
    Child(first, last, id) {
        super(first, last);
        this.id = id;
    }

    toString() { return super.toString() + " " + this.id; }
}

et voila, (and with the aid of a very tiny Javascript helper function), the Perl script emits the Javascript with all the prototype crud.

Which will save me many hours of typing and eyestrain. I spose I should CPANify it at some point...

Hmmm. A Perl script to convert Java syntax to Javascript prototyped class hierachies so I can display charts rendered using an extended SQL syntax inside HTML pages.

Anyone looking to hire a polyglot programmer ?

So Amazon's big announcement RE: SimpleDB service gets us DBD'ers all fired up...and then we've got no place to go. Seems they announced things a bit prematurely, and all the beta slots are filled. <sigh/>

If any Amazonian's out there read this, we'd sure appreciate a little fast track access. Morphing DBD::Amazon into DBD::SimpleDB looks pretty straightforward, and would add a bit more relational usefulness to SDB to boot. While SDB seems targeted at the SQL challenged, I'm betting someone's going to want to do a JOIN eventually - even if they don't know what a JOIN is. And there's a pretty good chance they'll want a SUM(), MIN(), and MAX() before long, too.

And DBD::SimpleDB can do that (courtesy SQL::Statement). ...if we can get at the service.

For the past week I've been building a package to provide bitmapped fonts for HTML <canvas> elements (which don't provide native text drawing - someone at Apple needs to be flogged for that omission...). All the existing solutions I can google up require manual intervention at some point. Not very 21st Century, and certainly unacceptable for lazy Perl programmers.

On Monday, after some deep cogitation during a restless slumber, I devise a plan. "Should be simple", thinks I, "just use GD::Text to progressively render a text string in a specified font, accumulating character positions and widths as I go. Write a bit of Javascript to load and slice up the character set image and apply to the canvas via drawImage(). Steal a bit of Javascript from some other similar solutions, and I'm done."

Then a sudden shudder down my spine: "ooooh...GD::Text... ." A minor headache begins to throb in my temples as I recall painful memories of trying to get the damn thing to work. Vague recollections that the POD is actually a work of fiction. And bugs, strange little bugs, but I can't recall what they were. Perhaps its been updated ?

Alas, No. Untouched since 2003.

"But this is too simple, shouldn't take me more than an afternoon to find and workaround the bugs."

Yes, I'm a cockeyed optimist.

So I dig in. The code nearly writes itself. "Simple things should be easy!". Even the Javascript is a breeze.

And then I begin testing. And the painful memories of GD::Text become tangible welts across my back once again. Strange and silent errors. getBounds() behavior and interface only vaguely resembles the POD. Printing a zero character by itself on a line results in nothing printed...unless I add another character. And when, 36 hours later, I finally manage to get the character set rendered, it looks like shit...and strings reassembled from sliced out characters look even worse.

(My neighbors are now quite certain they've moved next to a drunken, angry Russion sailor. Fortunately, they have no children, so no one learned any new vocabulary words)

So I'm done with GD::Text (and probably GD, too). They were an adequate solution in the long ago, far away time, and they are still a nice lightweight solution for "Simple should be easy" projects. But the accumulation of frustrations with the pair of them has done me in.

So I jump to Imager. I'd looked at it some years ago when it was still fairly nascent, and it looked promising, but the docs were confusing, and I didn't have time to spend on it. But the latest versions look pretty robust, and the docs seem better, so I PPM's me a copy and begin code conversion in earnest.

OK, first, I need to make a transparent fill color. So how do I do that ? Looks in Imager docs. Nothing. Looks in Imager::Color docs. Nothing. Imager::Draw ? Nope. WTF ???

Fortunately, as I've been on this merry-go-round a few times now, I figure it must be the alpha channel. Then I find a code sample buried deep in the Imager source tree. OK, 3 hours to find a very basic thing that should be one of the 1st 3 items described in Imager::Color. But I'm a n00b, so I take it like a man and move on.

Well, thinks I, since I'm screwing with alpha channels anyway, why not add opacity to the text colors. So I does. 'Cept the docs never state what kind of value the alpha channel actually uses. After trying a few fractional values, I discover it ain't like CSS. <sigh/>. So i start throwing numbers at it and seeing what comes out. Big numbers, huge numbers, little numbers. By trial and error I discover its a value betweem 0 and 255. Thanks for the helpful docs, Imager. And another 3 hours pissed away.

So now I'm ready to start trying fonts. And Imager has a very nice font metrics function. "Ah, at last I'm on the downhill side!", thinks I, and beginning typing furiously. "Now, which of these 9 values do I use to figure out how big a box I need to render my string ? Er...". Another painful trial and error session until I finally get satisfactory results.

But at least it looks good. And assembling strings from extracted bits looks great. Tweak the API to render the Javascript better, fixup the test suite, and things are humming. At 8PM Thursday night - after starting bright and early Monday AM - I've finally got the Perl working. Yep, "Simple things should be easy."

I awake Friday after yet another fretful slumber, hack in a few niceties I'd conjured during the night, and start testing the Javascript. Firefox + Firebug, the Web Developer's best friends. Whats this, do I want to update to 2.0.0.10 ? Oh sure, what the heck, can't hurt...

After fixing a few Javascript syntax errors, things look ready to roll...except for this nasty "Uncaught exception:.... NS_ERROR_NOT_AVAILABLE...". Hmm, the docs say canvas.drawImage() waits for the image to load. Lemme try this...no ? Ok, what about this ? Huh ? Wait one goddamn minute...

So, reverting to first principles, I grab example code direct from the MDC canvas tutorial site and give it a go. "Uncaught exception:....NS_ERROR_NOT_AVAILABLE..." WTF???

Fiddle some more. Still getting the error. Time for drastic measures. Clicks the Opera icon and loads the MDC tutorial page. Runs like a charm.

Ok, now this is bullshit. "Google, please assure me I'm not insane!", I think, as I feverishly type in "canvas firefox NS_ERROR_NOT_AVAILABLE". First hit: 2.0.0.10 Gaffe Prompts Quickfix. Follow the links to Bugzilla. Seems our friends at Firefox are doing a less than thorough job of testing standard API functions.

AARRRRRRGGHH!

And from the comments in the Bugzilla entry, there are *many* others in far worse shape than I. Hopefully, this episode will light a fire under the Firefox.

Its now Friday evening. I've poured a a tall spiced ale, and will top it off with a tall Jack and soda soon. This little exersize - that should never have taken more than a day, maybe 2 tops - is now stretching into day 6. I'm frustrated, tired, pissed off, and seriously wondering if its time to throw away OSS and embrace the C#.

My takeways:

1. Start using Opera for development, and stop recommending Firefox.
2. Stop using GD anything.
3. Submit some doc patches for Imager::Cookbook. Imager is a great package, but the docs seem to assume the reader either has an advanced degree in CG, or was a contributor.
4. If anyone from WHATWG reads this, PLEASE FOR THE LOVE OF GOD ADD drawString() TO HTML5!!!!

Because Simple things should be easy, dammit.