Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

renodino (6856)

renodino
  (email not shown publicly)
http://www.presicient.com/

Perl Contrarian & SQL fanboy.

Here's my CPAN goods. [cpan.org]

Journal of renodino (6856)

Monday March 24, 2008
12:46 PM

"Dream"Host ? More like Nightmare

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^(

Tuesday March 18, 2008
10:35 AM

CPAN Testers, I love you, but, seriously, we need to talk.

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!!!
}

Tuesday March 11, 2008
08:09 PM

HTTP::Daemon::Threaded finally gets some CGI love

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 ?

Thursday February 28, 2008
02:03 PM

pQuery: jQuery for Perl

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^))

Monday February 11, 2008
02:37 PM

"Tired of FUD" Followup: Where the Jobs Are

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.

Wednesday January 16, 2008
02:19 PM

ALL UR QWERIES ARE BELONG TO US

An interesting day for those of us that splash about in the DBMS end of the pool:
Saturday December 29, 2007
07:49 PM

Perl for munging Java-esque Javascript

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 ?

Monday December 17, 2007
02:15 PM

Lil help, Amazon ? (DBD::SimpleDB)

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.

Friday November 30, 2007
08:51 PM

I must have enemies...

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.

Tuesday November 20, 2007
08:20 PM

DDJ's 1st major insight in a decade...

I've been computing long enough to recall when Dr. Dobb's was a worthwhile rag. In the far away, long ago time, I was a regular subscriber, and learned many interesting lessons from it. But the Internet era, and an unhealthy codependence on the MSFT and Java crowd, sucked the life out of the good doctor.

So I was happily surprised when by chance I headed over to see what VB/C# pimping the Doctor was doing these days, only to discover this article on dashboards: a very commonsense, yet important, set of datapoints and conclusions.

Gives me much food for thought...DBIx::Chart is in dire need of an update, and I must admit to serious penis envy when viewing some recent developments for charting tools.

Guess I gotta find a fresh cache of tuits...