I've been doing some work in AS3 of late and stumbled onto a bit of a gotcha last week that I thought I'd share since it caused me about 15 minutes of frustration.

The gotcha pertains to a significant difference in how Javascript and AS3 handle the match method of the String object when the global flag is passed. Consider the following Javascript snippet:

var r = /[a-z]/g
var s = "abc";
var x = s.match(r);

This will return an Array with values "a,b,c" in both Javascript and in its AS3 equivalent.

Now, consider this code, replacing the value of s with something that will not match:

In Javascript, this will return null, but AS3 will return a zero length Array. Which means that this...

if(s.match(r)) {
// do stuff...
}

..would always be true in AS3, but false in Javascript. I spent about 10 minutes thinking there was something wrong with my regular expression, and another five thinking there was something wrong with AS3's regexp engine before I realized what was happening.

So who has it right? According to the ECMA 262 spec, AS3 does (see page 101-102). Of course, Mozilla's documentation claims that it will return an Array as well with no mention of null on that page, while Microsoft's JScript documentation admits it will return null if no match is found.

Good times.

My son, born this evening weighing in at 9.33 pounds, measuring 20 inches.

(And that's why I wasn't in Austin this year!)

And I'm not gonna be there this year. I know, I know - I should have told you sooner. You're probably already in Austin or in flight, now wishing you had advance notice of this turn of events so you could have just stayed home. I'm sorry, I really am. This really was terribly inconsiderate of me.

Soldier on, brave geeks, and know that with enough Shiner Bock, anything can be fun even if I'm not there. Be strong. And take lots of pictures. And twitter a lot. Let me experience Austin through your internets.

(Any day now I'll have an announcement of why I'm not there this year...)

These three drawings I did leading up to Christmas - I've kept them private on Flickr and not published them here as they were gifts for family and I didn't want to spoil the suprise.

• Clara at 17 Months
• 8 x 10"
• Colored Pencil on Eggshell Mi-Tients Paper
• November 20, 2007

• Big Smile
• 8 x 10"
• Colored Pencil on Cream Mi-Tientes Paper
• December 11, 2007

• Clara at 18 Months
• 10 x 8"
• Colored Pencil on Eggshell Mi-Tientes Paper
• December 21, 2007

And with those, I'll no longer be posting drawings on slayeroffice. 2008 seems a good a time as any to get the site back on the web development talk track. If you're interested in following my portraiture work, you can find it on my new drawing blog. Or, just grab the feed.

My good pal Mr. Lawver has included a reference to my Page Info Favelet on page 222 of his new book.

Congratulations to Kevin, Kimberly, Christopher, Rob, Meryl and Mark on the book. I'm not sure when it comes out, but with that caliber of authorship (and obvious good taste) its a must-own.

• Maya
• Graphite on Cold Press Illustration Board
• 11 x 8.5"

A portrait of a friend's new baby.

• Graphite on Cold Press Illustration Board
• 8.5 x 11"
• Source Photo © Kevin C. Smith
• In-progress scans

My first go at graphite in about 12 years. It didn't take nearly as long as a colored pencil drawing, and it was awfully nice to be able to use an eraser. I may stick with it for a little while.

• Clara the Angry Cow
• Colored Pencil on Cold Press Illustration Board
• 11 x 8.5"
• Source photo © S.G. Chipman
• In Progress Scans

Clara in her Halloween costume impersonating her Daddy's scowl.

As well, Happy 5th Birthday, slayeroffice!

• Colored Pencil on Cream Mi-Teintes Board
• 11 x 8.5 "
• October 29, 2007
• Source Photo © Kevin Lawver

• Colored Pencil on Cream Mi-Teintes Board
• 11 x 8.5"
• October 24th, 2007
• Source Photo © Kevin Lawver

A finished this one a week or so ago but forgot to post:

• Colored Pencil on Cream Mi-Teintes Paper
• 8.5 x 11"
• October 14th, 2007
• Source Photo © S.G. Chipman

Your guilt at work. If ten people sign up for a tenner-a-month ORG membership and send their confirmation code to Danny O’Brien, he’ll put out a special one-off issue of NTK!

Silverback has launched!. Clearleft’s “guerilla usability” software for OS X Tiger and Leopard—specialist screencasting software optimised for conducting usability tests.

The Open Web Foundation. Launched today at OSCON, an independent, non-profit organisation dedicated to incubating and protecting new specifications like OAuth and oEmbed. The focus is incubation, licensing, copyright and community.

Twing.com, a property of Accoona Corp., is a free service that aims to help users search for opinions, information, and conversations that match their particular interest—however obscure that particular interest may be. The site encourages users to get in on the conversation by enabling them to find communities relevant to their interests.

While blogs and social media have become increasingly common - discussions occurring on message boards and within forums aren't usually surfaced by traditional search engines. This kind of web content is multiplying rapidly and you are going to need something dedicated to getting to the content underneath.

So I interviewed Scott Germaise the director of product management for Twing to find out how we should be using this great new tool for your reputation monitoring efforts.

Link to Original Audio Source

Signup for this Podcast Series

About Scott

Scott is currently the Director of Product Management at Twing.com, a vertical search engine for searching and discovering communities. I've been in the online biz since the early days at Prodigy, was a co-founder and VP, Information Architecture at About.com, worked for or on other community sites such as ClubMom.com.

Recently I had to do some mass-conversion of HTML files to DITA XML — material I’d written for the upcoming JavaScript Ultimate Reference (the third, and arguably most complicated, part of the SitePoint Reference).

But a problem I came across several times was the sheer complexity of recursive element conversion — <code> becomes <jsvalue> (or one of a dozen similar elements), <a> becomes <xref> … and that’s all simple enough; but each of these elements might contain the other, or further child elements like <em>, and as we walk through the DOM so the incidence of potential recursion increases, until it gets to the point where my brain explodes.

There’s a limit to how much recursion I can get my head around — or rather — a limit to how much I’m prepared to get my head around before I just go the heck with this, why can’t I mangle it as text with regular expressions!?

Unfortunately there doesn’t seem to be a way with PHP DOM to get the text equivalent of any arbitrary node, but we can do that at the Document or DocumentFragment level; so with a little toying-around I came up with a way to leverage that capability and make it work at the Node level.

So for example, let’s begin with this XML:

We have a reference to its DOM saved to a PHP variable called $xmldom. And we want to parse it so that the <code> element becomes a <jstype>, and the <div class="section"> becomes simply <section>, all without affecting the rest of the document.

Here’s the complete code to do it, which I’ll then talk through stage by stage:

In the first step we get a reference to the element we want to work with, and save it to $node.

In the second step we create a new document, and use loadXML() to create a placeholder root node (the loadXML method converts text input to XML, and is one of the cornerstones of our process). Next we import the original node into that document, then use saveXML() to convert the whole document to text (the saveXML method converts an XML document to text, and is as critical as loadXML() for what we’re doing here). The text output is parsed using ereg_replace to remove the outer contents of the document (its prolog and root node) so that we’re left with a text equivalent of the original input node.

In the third step we do whatever text-based mangling we need; in this case it’s simple element name conversions, but it could be anything.

In the fourth step we want to convert our parsed text back into XML, and we do this by creating a document fragment, then using appendXML() to load the text and have it converted to XML (the appendXML method does the same thing as loadXML(), but it doesn’t require an entire document to be created).

Finally, in the fifth step we merge the processed XML back into our original document. The document fragment has the original document as its owner, so we can simply use the replaceChild method to replace the original node and its children with the processed version. (Whenever a document fragment is added to a document, only its children are actually added, the document fragment itself is discarded; DocumentFragment is a virtual construct and never actually appears in a document.)

Both the first and the final step are arbitrary — we could work with an entire document, or just a single node, and edit our referencing and merging statements accordingly. Or we could build a method from the inner steps, which accepts $node as an argument (and maybe an array of replacement expressions), and returns the processed node at the end: