Upon seeing the Fluxiom intro video, I was compelled to figure out how they pulled off iPhoto-like image scaling in a browser. Leveraging the work of others, it’s actually very simple.

If you use the script.aculo.us slider control to capture input values, it’s really just a matter of converting those values into something useful and modifying styles.

Note: OS X folks using Firefox will likely get some stutter, due to a crippling, 3 year old bug.

A simple demo.

Here’s how.

1. Install and reference the Prototype and script.aculo.us libraries.

2. Create the track and slider HTML nodes. (CSS inline for simplification)

3. Create a function to be called when the slider value changes. This collects all nodes for resizing, remaps the 0-1 scale to a definable range, and then scales.

4. Create the slider and map the two events to our function (either inline, or as part of the body onload event). See the Slider docs for usage details.

5. Finally, create the HTML for our images.

There are definitely some areas to clean up (redundant div width specifications, for example), but for a quick demo it will suffice. Tested with Firefox, Safari and Win IE 6.

Update: There appears to be a small issue in IE; the slider disappears when you start dragging.
Update: Fixed. Moved the handle image to an actual img.
Update: Corrected a typo. (Fluxium != Fluxiom)

Dave Winer’s Morning Coffee Notes podcast is a recent addition to my listen-list. Dave’s podcast is wacky, entertaining and informative; I’ll even forgive him for that horrible Turkey in the Straw MIDI song he played over and over a couple of episodes back. As I have blogged previously, I spend more time listening to podcasts than reading blogs; there’s just more depth and richness to a podcast and time-shifting is huge for me. This holds true for Dave’s work; I read Scripting News only occasionally, but listen to all Morning Coffee Notes episodes.

Anyway, in Dave’s 19 November 2005 episode, he mentioned the new Simple Sharing Extensions (SSE) for RSS and OPML, a proposal from Microsoft heavily influenced by their new CTO, Ray Ozzie. In a nutshell, where RSS and OPML are about one-way information publishing (read-only from publisher to subscriber), SSE enables synchronized read-write connections—replication—among distributed applications via extended RSS and OPML syntax. And as its name would suggest, SSE manages to pull this off in a reasonably simple way.

If anybody understands replication, it’s Ray Ozzie. Back in 1989, with funding from Lotus’ Mitch Kapor, Ozzie founded Iris Associates and created Notes. Notes was a ground-breaking product in many areas—it was the first major commercial product to embed RSA security technology—but replication was probably its biggest innovation. The Notes replication engine allowed occasionally-connected users to collaboratively edit rich, semi-structured data. When Notes was released back in the early 1990s, there was no commercial Internet (not even a dial-up flavor), and corporations often had many offices that weren’t on the corporate WAN. So Notes had to enable distributed replication over a mixture of dial-up networking and corporate WAN infrastructure. No small feat, especially given the hardware and operating systems available at the time.

To support replication, each chunk of semi-structured data (called a “note”) in a Notes database contained a globally-unique identifier known as a UUID. This, combined with intelligent timestamping, versioning, and conflict resolution mechanisms, made Notes’ asynchronous replication possible.

Eventually Lotus bought Iris, and IBM bought Lotus, and finally Ray Ozzie moved on to found Groove Networks. With Groove, replication was again a cornerstone feature. But where Notes required dedicated server infrastructure, Groove took a page from the peer-to-peer book and enabled replication directly between peers with no servers. Under the hood, though, Groove still has the same basic elements that make replication possible: UUID equivalents, timestamping, versioning, and conflict resolution.

So when I looked at the SSE spec, I saw many familiar elements:

• Within each replicated RSS item or OPML outline there’s a <synch> element with a globally unique id attribute, which serves as the foundation for replication.
• <synch> has <history> and <update> children elements that log and timestamp updates. <synch> also includes a version attribute. This combination enables an SSE application to determine the winner and loser in any replicated update.
• Finally, <synch> has a conflict attribute to flag conflicts when they occur.

There’s a bit more to SSE than this, but not much; it really is pretty simple.

SSE’s potential is staggering. As Ray Ozzie describes it, SSE could become the “RSS of synchronization,” and he identifies synchronization of shared calendars and contact lists as possible early SSE targets. But it’s even bigger than this: once SSE is widely adopted, we’ll be able to “remix with updates.” Imagine something like this craigs-list-on-google-maps application, but with updates synchronizing in both directions. And a hundred other scenarios we haven’t yet thought of. Very powerful.

I’ve been along for the whole Ray Ozzie ride, first as a Lotus Notes business partner in the mid-90s, and more recently as a Groove user and implementer. I was worried when Microsoft invested in Groove, and disappointed when Microsoft bought the company. Ozzie was selling out, I thought; another good guy assimilated by the borg. Ozzie being named Microsoft CTO was surprising; but I just couldn’t picture Ozzie, who I remember as soft-spoken and somewhat shy, having much influence around the likes of Steve Ballmer, the poster child of brash.

But SSE has me reconsidering my Ozzie-sold-out stance, and wondering if we might see a (slightly!) kinder, gentler Microsoft thanks to Ozzie’s influence. Here are a couple of good signs:

• Rather than trying to jam a fully-baked standard down the world’s throat, Microsoft first did some reaching out. Ray Ozzie called to Dave Winer to discuss Microsoft’s initial SSE concept, which applied to RSS only. As a result of their conversation, SSE was extended to OPML, which I feel more than doubles its usefulness: OPML can represent almost any hierarchically structured data.
• Microsoft released the SSE spec under the Creative Commons Attribution ShareAlike license.

I hope to see the SSE spec finalized and adopted soon, and am looking forward to building some remix-with-updates webapps.

Two recent podcasts from the Accelerating Change 2005 conference really gave me a chill. Check out Verner Vinge’s keynote presentation, and Moira Gunn’s interview with Ray Kurweil.

So what’s so scary here? Here’s wikipedia’s definition of Technological Singularity:

In future studies, a technological singularity (also referred to as just the Singularity) is a predicted future event when technological progress and societal change accelerate due to the advent of superhuman intelligence, changing our environment beyond the ability of pre-Singularity humans to comprehend or reliably predict.

Vinge and Kurzweil are credible futurists, and based on the incredible pace at which computer technology is emerging, both state that a Technological Singularity is a real possibility during our lifetime. Vinge talks about both “soft takeoff” and “hard takeoff” singularities; in the latter, computer intelligence could transcend human intelligence in a matter of days or hours.

So, you wake up one morning and the world has changed in ways we can no longer understand; we wouldn’t even be able to understand if the freshly-emerged intelligence attempted to explain it to us. Think of trying to explain your car to a snail: that is how far beyond our comprehension the new intelligence could be.

To me, this is scary stuff … coming from credible sources. Kurzweil has a new book on the subject.

Based on a request we got from Upayavira, Vadim ran benchmarks on the XT XSLT processor using the same test suite we used for GT2005, and was favorably impressed. XT performed as well as XSLTC, while using a bit more memory, but still less than all the other contenders benchmarked to date. We will include XT results in our final writeup of the benchmarks (not yet completed, still working on Gregor testing.)

Vadim made a comment that XT might become his new favorite XSLT processor, which surprised me because (a) Vadim is a big proponent of All Things Apache and (b) XT does consume more memory than XSLTC. I asked him about this, and here’s how he responded (direct from an e-mail):

Major one is overall system complexity. The less count of moving parts, the better. XSLTC:

XSLTC is not bad, actually, but if its performance improvements are only marginal (as shown), then I prefer XT.

I’m not completely sold yet; XT is currently a one-person project, not much is happening on new development, and we haven’t yet given it a heavy workout on a large set of XSLTs to see what breaks. Regardless, quite interesting …

Yes, I am podcasting-obsessed. Not content to simply listen, I decided I had to experience the joy of creating a podcast hands-on. The Cocoon GetTogether 2005 event held in Amsterdam Oct. 5th through the 7th presented a great opportunity, a genuine need. Last year’s GetTogether sessions were videotaped with the intent of publishing the videos on-line, but because of the comparatively high effort involved in producing and publishing video, they never made it onto the web.

With a burning desire to get hands-on podcasting experience, I volunteered on the cocoon-dev list to capture and publish audio for this year’s GetTogether. A few people expressed a desire for video instead of audio, but most shared my keep-it-simple-and-make-it-happen perspective. Another factor is time-shifting: a key benefit of podcasting is its ability to time-shift into any timeslot where our ears and mind are available. Video is more limited for time-shifting, incompatible with a number of timeshifting opportunities such as drive time, workout time, etc.

Choosing the Hardware

The first decision was what hardware to use for audio capture. I had two separate audio capture needs: first, to capture audio from the GT2005 sessions, which meant connecting into whatver A/V equipment they had at the NEMO Science Museum where GT2005 was being held; and second, to capture audio from interviews, ideally with two microphones on separate recording channels. Plugging a microphone into the jack on the laptop was definitely not going to cut it.

My first thought was to use my home music studio setup, which features Pro Tools and Reason software, Mbox hardware, various studio microphones, etc., which would be more than adequate quality-wise for recording and producing podcast audio. The problem is, this setup isn’t very portable, and furthermore my kids use the studio a lot and would not be pleased to have it disappear for a week while I was in Amsterdam. Finally, my current laptop is pretty lame, and I wasn’t sure it could even run Pro Tools, which is notoriously finicky about hardware and OS configuration.

The best portable platform for pro-quality podcasting is probably a PowerBook paired with a FireWire-based recording interface like a PreSonus Firepod; and in fact I’ve been looking for an excuse to buy a PowerBook … Unfortunately, the timing was really bad, with Apple overdue to release a new PowerBook line. (They’re still overdue!)

I decided to make a trip to Guitar Center, a major US music chain with a strong professional audio department. When I walked in the door, I was leaning towards buying the latest Mbox or maybe a Firepod; but then the pro-audio guy showed me the just-released M-AUDIO MicroTrack 24/96.

Just a tad larger than a full-size iPod, the MicroTrack captures professional-quality audio in WAV or MP3 format. It has two 1/4″ TRS jacks for stereo recording using pro-grade microphones; with the right cable you can connect XLR-cabled mics, even condenser mics that require “phantom power.” These same inputs can connect to the line output of a mixer. Recordings are saved directly on Compact Flash storage; I bought a 2GB card, which has a 30+ hour capacity when recording to MP3, or 3+ hours to WAV. The MicroTrack has a USB 2 port, and when you it plug it in, it looks like a USB hard drive. It looked pretty much perfect.

I already had one Audix OM-2 mic, so I bought a second one, a couple of table-top mic stands, the right cables, and a whole raft of adapters so that I could connect to pretty much any A/V hardware that they might have at the NEMO. The whole setup fit into one compartment in my laptop bag—most of the space was taken up by cables and microphones.

On-site in Amsterdam

The MicroTrack worked like a charm. I did interviews during the Hackathon on October 5th and 6th; it is ironic that a single microphone is larger and heavier than the MicroTrack!

Also on the 6th, Arjé Cahn (hippo.nl) and I travelled by bicycle over to the NEMO to check out their A/V setup in their theater where the next day’s presentations would take place. The theater was nicely equipped with a full pro sound system including a Mackie mixer, so interfacing was a snap.

On the day of the GetTogether itself, October 7th, it was just a matter of plugging in, pushing the record button, and keeping an eye on the input level displayed on the MicroTrack’s LCD display.

On-the-fly Production

My original plan was to capture audio files in large but lossless WAV format, bring them back to Chicago with me, and do post-production using Pro Tools. But in Amsterdam, I decided to switch to MP3 recording, because the WAV files were pretty unwieldy—a single 20 minute interview could generate a 150MB file, which was then slow to copy or FTP around. I also downloaded and installed Audacity, an open source audio recording and editing tool, to see if I could do the audio post-production right there in Amsterdam.

Photo by Steven Noels

Audacity worked well overall (see one possible caveat below) and enabled me to edit the audio immediately as sessions were recorded. We nearly achieved same-day publishing, but the NEMO’s network crapped out at the last minute on Friday and I didn’t get things uploaded to the GT2005 site until Sunday.

John Berry pulled together the podcast’s RSS feed, and I was able to test subscribing under iTunes and synch with my iPod. The result looked and sounded good; and as they say on TWIT, the podcast was “in the can.”

Lessons Learned

• Interviews require careful preparation. I tried to “wing it” but soon realized that both I and the person being interviewed needed to understand what the questions were going to be, in advance, otherwise it would be very easy to stumble around, run into unhappy subjects, etc.
• Audacity downsampling troubles. Somehow I managed to introduce some voice distortion when I took the original MP3 files (captured at 128K) and downsampled them to 64K. This might be a limitation of using MP3 (rather than WAV) as my source format; or of Audacity; or just a problem with how I went about it. I haven’t had time to diagnose yet, but plan to.
• Gain is key, and MP3Gain is nice. I learned that getting nice fat gain on your MP3s is important, and that the MP3s coming out of the Microtrack tended to be low-gain. I found another piece of open source software called MP3Gain that does a nice job fattening up the gain.
• Don’t forget to set the ID3 tags on the MP3s. When I compared our podcast with those produced by IT Conversations inside iTunes, I noticed that theirs had Artist listed while ours didn’t. At first I thought this information was being pulled from the RSS feed, but later determined it actually comes from the ID3 tags in the MP3 files themselves. Next time I’ll remember to set those …
• Consider capturing WAV versus MP3. I have great respect for Doug Kaye at IT Conversations, and apparently they capture audio as WAV rather than MP3. I’m still not sure if this is a must; it might even be an artifact of the devices and software normally used to capture audio. But next time around I’ll definitely rethink WAV versus MP3 recording
• iPod earbuds are NOT for audio editing. Actually, they’re not really that good for anything…. Get some good quality headphones!