Photo: Frank

There's a crisp bite to the air as the leaves march from green to rich yellows, oranges and reds. Weaving their way through the falling leaves is a stealthy army of small soldiers invading my neighborhood. They're fully equipped, armed to the teeth with supplies and are being unleashed all over this country. They're small children and they're selling crap.

I'll admit it. I'm a veteran of this particular army. I served 7 tours of duty armed with cases full of World's Finest Chocolate from the age of 5 to 12. I knocked on doors, faced complete strangers and engaged in a ritual that's deep and ancient: trying to convince a positively ancient adult that the $2 candy bars in my cardboard case truly were the world's finest confectionary treats. When that failed, I fell back on my training and recited a litany of beneficial purposes toward which the proceeds would be applied.

Unfortunately, with school budget cuts, it seems that this kind of activity is now a nearly constant presence. They've branched out from candy and sell magazines, frozen pizza, frozen cookie dough, home interior decorations, and lots of other crap, nearly all of which I either could buy at much lower cost in a store or that I have absolutely no use for.

I do sympathize with the need to fundraise and how appealing the door-to-door sales method appears. Since I'm right in the middle of the target market for this stuff (high disposable income in a family-centric suburban neighborhood filled with school-aged children), I figure I can share my take on what gets me to buy. If you or your child are newly enlisted into this army or you are a commander looking to deploy a local division, here are a few bits of advice to get me to buy this stuff.

1. The kid needs to sell it. Maybe this just comes from having spent my time in the trenches, but when the parent does the selling, I really don't want to buy it from the adult.
2. Sending out your army along with dozens of other small armies leaves me not wanting to answer the door. I've had no less than 7 sets of kids at my door in the first 3 days of this week. I have no intention of answering it for anyone under 5 feet the rest of this week.
3. Tell me what the goal is. "Do you want to buy this stuff?" is not convincing. Tell me that your band is going to Chicago.
4. No catalogs. I already have enough decorations, magazines, etc. I also don't want to have to spend 10 minutes flipping through the catalog, help the child fill in the form (or wait for them to figure it out) and then shell out 10 to 20 times as much as if the product being sold is candy or something of similar price/size.
5. If I can reach in my pocket, pull out a $5 bill and be back in the house in 2 minutes, I'm about 100x more likely to buy.

While I like scriptaculous, sometimes you just want to cycle through messages and fade between them and don't need a full-blown effects library. A script popped up in the feeds today that does just that.

It intrigued me because I'd been looking at something like this to be able to easily and programatically whip up intros for screencasts. Simply write up some slides, turn on the screencam, run this and you've got your intro video ready to go. Same with credits. Basically, I want to streamline those bits of production and lower the barrier to me producing screencasts.

The library itself can be found at Brand Spanking New. It comes with a sample page and sample code to invoke it, but I thought I'd share a really quick way to extend it.

The sample invocation looks like this:

var cf = new Crossfader( new Array('cf1','cf2','cf3'), 500, 2000 );

The "cf1", "cf2", etc. are the divs to cycle between and the numbers are how long the fades take and how long the individual slides take (in milliseconds).

That immediately struck me as a pain because it requires you to manually add new "slides" to the array, in addition to actually putting them into the HTML document.

This snippet below uses the same HTML document in the sample. It grabs the containing div and then grabs all child divs with a class name of "cf_element" and adds them to the cycle.

var container = document.getElementById("cf_wrapper")
var children = container.getElementsByTagName("div");
var cycled_elements = new Array();
for ($i=0;$i<children.length;$i++){
     if(children[$i].className == "cf_element"){
         cycled_elements.push(children[$i].id);
      }
}
var cf = new Crossfader( cycled_elements, 500, 2000 );

This isn't terribly efficient and should really be fixed up, but that's not in the scope of a quick tip. However, if you were to take that task on, I'd suggest making a single function that takes an id as input. All of the immediate child elements (regardless of div or img or whatever) would be added to the cycle, regardless of class name.

Photo: Hughes Leglise-Bataille

There's been quite a bit of recent discussion about how gaming of Digg's system shows that "The Wisdom of Crowds" is failing.

The problem is that Digg doesn't implement the wisdom of crowds. And, it seems, most of the participants in the discussion don't know the difference.

The criteria for when the effect that the book talks about kicks in are fairly simple. They require that every member of a wise crowd is acting without knowing anyone else's actions before they choose. That means that, if Digg were actually based on the WOC principle, you'd never see how many people had dugg an article before you choose to digg it yourself. Additionally, you'd only ever vote on a random selection of articles.

Basically, if you're voting on a list of already popular articles, you're seeing the aggregated existing inputs to the system. And, by seeing numbers, you're seeing even more. Any system that shows those bits before you choose to give an article the thumbs up or thumbs down is both easier to game and not based on the WOC principle.

To truly invoke the wisdom of crowds in a cream-of-the-crop link aggregator like Digg, all voting should be done seperate from displaying links. Links should be held back from display until voting thresholds are met on it. So, if you want to vote on articles, you hit a page that presents a random selection of articles for voting. You vote on articles. Once an article gets the right combination of votes, it leaves the queue and shows up on the front page.

Unfortunately, that's not as neat and fun as what Digg does, meaning it's not likely to get implemented anywhere soon. However, these systems shouldn't be mistaken for being the wisdom of crowds and their failure surely shouldn't be pinned on the wisdom of crowds idea.

Photo: Roland Tanglao

I've been looking on with interest at the developments in the Atom world. You may have noticed that things in that arena are changing. The feed format has left version 0.3 behind for a 1.0 edition. In addition, there's been quite a bit of work on the Atom Publishing Protocol. Given that Atom provides (with these develpments) an end-to-end scheme for managing content, I took some time on Friday night to dig a little deeper.

I'm still not done exploring, but am liking what I'm finding. First, I wanted to upgrade this site's Atom feed to the 1.0 standard. A quick application of the Wordpress publishing plugin and I was up and running with a shiny new Atom 1.0 feed. You can verify the validated feed as well as see other sites that have made the switch.

That accomplished, I turned to the publishing end of things. Given how the Metaweblog API pisses me off (including how there's no way to work with draft posts and how this is NOT an API document, while this is), I'd been contemplating using Atom as my drafting and writing format for new posts and in my prototype C# client.

So, when I found the plugin for Wordpress to enable Atom Publishing, I figured that it was an ideal way to handle the publishing end of things in building my client. I'm working with the author to figure out why it doesn't work out of the box on my server, but it's definitely promising.

With Atom from end-to-end, posts can be drafted anywhere, stored in something like Amazon's S3 and eventually published anywhere that supports it. Given that eventually, I'd like to be able to work on a pool of posts, independent of where they'll end up and independent of which machine I'm working on (I'm sick of tools like Performancing for Firefox that do drafting locally because I rarely spend an entire day on the same machine.

Since it looks like this is a realistic path, I think I'm going to keep working on this approach and eventually the Wordpress Atom Publishing Protocol bit will work itself out.

Photo: Doug

So, this week I've been working heavily with PHP, consuming full-blown SOAP web services, which I had only dealt with casually in the past. The last time I used SOAP and PHP, I used NuSOAP, but, apparently, there's a namespace collision between NuSOAP and the new PHP SOAP library.

Given that this is for a client, and namespace collisions aren't likely to be won by 3rd party libraries, I'm using the included library from PHP5. However, that's all just background to my general surprise at just how primitive most of the tools in PHP are at dealing with SOAP. SOAP 1.1 was submitted as a standard back in 2000, 6 years ago.

For the basic stuff, it works well enough, but, when it came time to code a test server to work with until the real one was finished, I had to generate a WSDL file and discovered that I was pretty much stuck doing it manually. The library provides a way to construct a service *given* a WSDL file, but how you get it is up to you.

This isn't entirely unreasonable, since a WSDL needs strongly typed variables, which PHP doesn't do, but there's not even a mechanism to more explicitly cast variables and turn that into a WSDL.

Anyway, it turns out that someone put together a nice little tool for generating them, so you can keep up with Dotnet Jones next door and your SOAP services can have their very own WSDL's as well.

For a bonus game, read this post out loud to someone who doesn't do web development and take a picture of the look they give you.