A Great Night for Podcasts

 

One small consolation of my contract in Rockville is spending quality time with my iPod Touch, podcasts, and the Civic–who is now officially named “Blue Monday”.  Tonight’s drive was especially pleasant from both the driving and podcast listening perspectives.  Here are some highlights from the things I heard:

Beer-Drinking Tree Shrews

Oh, beer.  You are such a Good Thing that even evolution loves you.  A palm evolved natural fermentation chambers to capture yeast and brew you from its own nectar.  A species of beer-swilling shrew doesn’t seem to get drunk despite a hefty habit; I can’t decide if we should praise or pity the little fellow.  A species of loris has also developed a drinking habit, nothing nearly as nasty as their anorexic cousin’s habits who grace the cover of one of my favorite O’Reilly books.  Evolution, beer, UNIX, and primates behaving badly–fabulous!

Nail Your Files

Stever Robbins, the Get-It-Done guy over at quickanddirtytips.com has some helpful hints about a subject near and dear to my heart, file naming conventions.  He gets points for suggesting the ISO 8601 date to tell apart your 5,000 report.doc files and to sort them chronologically in your file manager of choice.  It’s sad that most people still live in a world where meaningful search or–dare I say it–real metadata doesn’t exist.  On a related note, I definitely have a few things to say about how much I’m using Spotlight in a subsequent post.

Outsmarting Bombers

This edition of the Scientific American’s weekly podcast podcast takes a fascinating look at counter-IED technology in Iraq and a related story about the continuing problems with turning the lights back on in Baghdad.  More robots controlled by the video-game generation combat an adaptable enemy turning our commodity tech against us.  Scary and fascinating.  Finally, our friend the beer-swilling Loris makes an appearance at the end of the podcast in the “Totally Bogus” segment.  Who knew I was embracing my Inner Chimp every time I popped the top off a bottle of Midas Touch? Mmm, beer.

Tell Me a Story

Finally, RadioLab has produced some of the best podcasts I’ve ever listened to.  It’s This American Life meets Nova, two things I already love.  In this between-seasons short, Robert Krulwich addresses Cal Tech graduates.  I won’t butcher it with a summary.  Just go listen to it right now.  Being a science reporter like Krulwich or Mursky (of SciAm) is my new dream job.  Subscribe to the podcast, go back through all the episodes–especially the ones or morality and emergence–and thank me later.

My iPhone Ultimatum

I’ve given up on iPhone 3G after 48 frustrating hours.  Instead of today’s post praising the platform, I must chastise Apple for one of the worst product launches in memory.  Given Veronica Belmont’s experience, maybe I should be grateful for the delay.  To avoid my inevitable agonizing over buying it or not buying it, I’ve come up with my five-point ultimatum that Apple must meet before I’ll consider buying an iPhone again:

1. I don’t have to stand in line to buy it.  My current Blackberry/Touch configuration is good enough for now.  One of three things needs to happen:  Demand abates, supply increases, or Apple bitch-slaps AT&T until they agree to online purchases and at-home activations.  Otherwise, it’s just not worth the bother.

2. Apple releases two software updates.  Apple’s notoriously bad at Dot Zero releases, and they don’t seem as on top of things with the iPhone as they are with OS X.  In this particular case, I’ll stick to the two update rule assuming the first update will fix most things but break a few more in the process.

3. I can synchronize with a released version of OmniFocus. Having my not-at-computer actions with me is a must have, and I’m unwilling to trust my daily operations to a sneak peak version of OmniFocus.  I may buy the iPhone version for my Touch when OmniFocus 1.1 comes out, but only if I can use or transfer it to an iPhone later.  Anybody know how the App Store works with multiple devices on the same iTunes account?

4. Reliable sources report battery life exceeds 24 hours.  If the device can’t last an average day without turning everything off, I don’t want it.  Ideally my everything device needs to last 48 hours–one weekend away from home and/or laptop–to be practical.  This might be a deal-breaker with iPhone 3G.  Anybody know how to tether an iPod Touch to a Blackberry Pearl or Bold?  That might hold me over until a third generation iPhone with a reasonable battery life hits the shelves.

5. It comes with a reasonable plan.  A reasonable plan includes text messages.  The fact that I’m paying for an all-you-can-eat data plan but still have to pay extra for snippets of text drives me crazy now.  I don’t love T-Mobile, and I don’t really hate AT&T from personal experience, but I have lots of AT&T-hating friends and feel that the iPhone and Apple itself have both been tainted by a deal with this particular devil.

The real shame here is I’m totally hyped about iPhone 2.0 as a computing platform.  The total interface package (multi-touch, accelerometer, proximity) really delivers in what has been a decades-long innovation dead zone, and the App Store is a first look at the amazing possibility of putting such power in the hands of thousands of developers.  The missing piece with the Touch is Internet Everywhere, but I’ve learned to live with good-enough works in progress elsewhere in life.

I can wait.  I think.  Ask me again tomorrow.

DFC has Junk (DNA) in the Trunk

In a webex with EMC engineering about DFS and UCF, I asked if D6.5 would bring full coverage of DFC functionality to DFS. The answer was yes and no.

The first cut of DFS was a little minimal even for my tastes. Anything beyond basic object-related operations was either barely implemented or completely ignored, like workflow and lifecycles respectively. D6.5 promises more than a dozen new services that will fill out much of the missing functionality and add some application-specific services for things like formal records management and content transformation. EMC is clearly committed to DFS as the primary API for application development and system integration.

The only big chunk of functionality missing in D6.5 will be administration-related. There’s still no way to write your own Documentum Administrator (DA) in DFS. I can’t think of an application more in need of a make-over than DA, but we’ll have to wait until D7 or beyond to write our own in DFS.

If I were the DFC, I’d be feeling a little uncomfortable about now. Documentum is like the Zsa Zsa Gabor of APIs and client interfaces; just as an interface matures, they dump it and move onto the next pretty face or fat checkbook. EMC’s already been seen around town with party boy Magellan even though Webtop still wears a ring. The same goes for DFS and DFC. With DFS 6.5 meeting all of EMC’s needs, I hope DFC’s hiring a good divorce attorney. DMCL didn’t, and look what happened to him!

No more wire hangers!The “yes and no” answer I got stems from my previous observation about Documentum’s junk DNA. That idea resonates with people, including Pie who provoked me into posting this with his own latest post. EMC sees the DFC as littered with failed ideas, obsolete patterns, and deprecated methods. When I pressed, EMC said that the DFS will contain everything an application developer would require. Parts of the DFC that qualify as junk in its trunk will not find their way into the DFS closet. No more wire hangers DFC classes!

Fear not, DFC fanboys! The DFC will still be the primary interface for writing things that go into docapps or service providers–methods, (S|T)BOs, custom DFS services and my bad boyfriend of the day, aspects.

While I understand EMC’s constraints and the issues of compatibility versus new development, I have to say my feelings here are mixed. Are we going SOA as a choice to solve particular kinds of problems or because it’s too hard for people to treat Documentum objects as java objects? My relationship with the DFC hasn’t been a smooth one, but I do feel that it has come to express the underlying model fairly well. By saying “DFS for applications, DFC for the back end”, my read between the lines is that the average application developer just can’t handle Documentum as OOP. I wish I could disagree.