Pascal Also a Silverlight Option

I try not to do too much "link/clip blogging." But I have a soft spot in my heart for Pascal, since some of my early PC and Mac programming was in Pascal. I had already racked up plenty of bad BASIC and assembler programming by that point. But both BASIC and assembly language encouraged the worst of my habits (hence "bad"), while Pascal made it easy to leave them behind.

Also I worked for a couple of years for one of Anders Hejlsberg's close friends, so if I didn't already admire him that experience was sure to raise his stature in my eyes.

So I thought it was cool that you can author Silverlight apps (along with any other flavor of app) in Pascal, using RemObjects Chrome.

For the Love of God, Count Something

I've been reading Steve McConnell's Software Estimation: Demystifying the Black Art.

It's a mostly-fabulous book, and I highly recommend it. I have no doubt this book will take its place as a classic alongside his Code Complete and Rapid Development titles.

This post is the first of a few summarizing and commenting on key estimation principles that McConnell covers in the book.

As my title suggests, step zero: count something ... count anything. Count features, functions point, user stories, use cases, web pages, GUI widgets... count what you can. It'll take some work to get from that count to a useful heuristic for estimation, but it's way better than the all-too-common practice of estimating by licking a finger and holding it up in the air. Hmmm ... 7 knots, from the north-west.

Steve spends many chapters exploring what to count, when, and how; who should do the counting; and what to do with the totals. But the premise is that "take a SWAG and double it" is not only unreliable, but it's indefensible. How can you explain an overrun or ask for more resources if there's no process to justify your numbers? There's no way anyone in your organization can plug your "gut" into a spreadsheet in a useful way, so you're perpetually at a disadvantage in negotiating to ensure positive outcomes.

Another vulnerability in the gut-feel approach is that -- even if the manager or programmer who makes the gut estimate is right on the money -- she can only be right on relative to the scope she is imagining to be on the table.

In many organizations, scope is not made sufficiently explicit to guarantee a proper understanding up front. Thus the "counting" part of the estimation process actually brings new specifications to light regarding the project being estimated. A couple of iterations of this process, and a lot more is known by all parties. More knowledge generally leads to less risk and more predictable outcomes.

The Hardest Thing About Having Plan B is Realizing You Might Be Wrong About Plan A

The second law of thermodynamics describes why it's easier to break a glass than put it back together; easier to write the wrong code than the right code; and easier to metabolize nutrients than to create them. Wilfred Bion's group dynamics theories provide a bit of a social parallel -- some of the reasoning why groups and organizations persistently do the "incorrect" (by their own definitions of "correct"!) thing. By default, groups tend to devolve from their own goals in more or less spectacular ways.

Our social interactions don't rigidly follow laws of physics, we can occasionally climb out of the potential well of typical group dynamics. Doing so improves our odds of success on technology projects.

One of my favorite success stories is Intel's "Yamhill Project." Yamhill is why Intel is still in business. But it's also something few management egos could have lived with, and the Intel exec team's willingness to deal is why Intel is still a going concern.

Once upon a time, Intel wanted to clean up all the messiness that had evolved over the history of the x86 architecture. Make a clean break and launch Itanium, a new 64-bit architecture and instruction set. The new chips would not be backwards-compatible, so the gamble was that if Intel said that the future is Itanium, then no matter how painful the transition for customers and partners, they would have to go along.

Given the egos, and the "all-in" nature of chip development, the typical move would be to wave the Itanium flag, charge into battle, and either win the war or die trying. Lots of famous companies have died (or become irrelevant) fighting these battles.

But Intel's team did something much better. A few folks early on said that the market might not tolerate the change and ... if an alternative emerged from a competitor ... the result for Intel would be catastrophic. Officially, Craig Barrett backed Itanium / IA-64 all the way. But in secret he gathered together some of the brightest engineers in the company and sent them off to work in a remote location on Plan B, a non-Itanium 64-bit chip that would be backward compatible.

Barrett and his team possessed an all-too-rare willingness to come to grips with the fact that the big IA-64 play might possibly go wrong. Instead of ostracizing whoever made the suggestion (more typical organizational behavior), they integrated the information and took a decision about how to work with that possibility.

As it happened, AMD came to market with a backwards-compatible 64-bit implementation. The market loved it, and, outside of a few server niches, it might have been game over for Intel right then. If they hadn't had Yamhill.

Ads "Clear" -- Security Line Benefits Not So Clear

Full disclosure: I used to work for a now-defunct startup which, in addition to doing cell phone check-in for airlines, did a bunch of airport parking, check-in, and security stuff.

So maybe it's just sour grapes as Clear moves into the SF Bay area. But this experience is also the reason I think Verified Identity Pass is misleading people with the barrage of advertising it has unleashed about it's Clear program.

In exchange for an in-depth background check, your biometric data, and a chunk of cash, you are promised a better, faster security lane experience at the airport. But here's what they're not telling you: the actual security protocol isn't any different for the Clear member than for anyone else. Don't believe me? Take a look at the TSA's Registered Traveler (RT) program page. Clear is a vendor implementation of RT.

TSA describes the "benefits" of RT as

• "modified airport configuration to minimize ... wait times"
• "enhanced customer service"
• "discounts for services or concessions"

Nowhere in this list is being able to leave your shoes or coat on, keep your fluid container, or leave your laptop in its bag. At the time Skip evaluated RT participation, there was discussion at TSA surrounding waiving the "Additional Screening" described on this page for all RT members. Apparently, TSA decided against that change for now, and instead elected no changes to the security protocol at all for RT.

So Clear is just selling you a customer service promise. A promise that they will keep leasing and staffing more and more security lanes. Because as more people sign up for the program, the initially empty "Lexus lanes" will fill up. And the friendly banter may become as indifferent or hostile as that of the cellphone customer service rep who knows your only other choice is to unsubscribe, and who isn't paid to care whether you do.

Now, if someone wants to pay $99 just for a plausible chance of being able to move quicker through security (heck, SFO's average wait is under 7 minutes anyway), what's the harm?

The problem is fourfold:

1. This scheme, which utterly lacks any innovation, makes it less likely that airports, airlines, and TSA will implement truly innovative solutions.
   
2. Personal data privacy breaches by companies and government entities tell me I should worry about my background check and/or biometric data being lost or stolen. These promises are meant to make me feel good; they don't protect my data.
   
3. If there is a for-pay security alternative, and airlines feel that their top flyers can/do pay it, they are likely to spend less on regular security lanes (yes, the airlines, not the government, sponsor the security lanes). Don't want to pay your kickback to the Clear folks? Stand in line an hour. Miss your flight? You're a cheapskate, stop whining.
   
4. Yet another step enlarging the security-industrial complex, where we all pay, not to be secure, but to secure the financial success of a handful of well-connected companies.
   

Not surprisingly, local TV, newspaper, and radio all picked up Clear's story, and played it like a commercial for the future of air travel. Let's hope it's not.

When Building a Smartphone App, Resist the Siren Song of J2ME

I'm tempted to comment a bunch on the Yahoo! Go smartphone app with its secret J2ME porting layer. But I just don't have enough of the business context around the project to draw solid conclusions. So I'll spare you the half-bakery and instead share something that you can use.

If you're building a mobile productivity app, think realistically about who your principal user personas are. If your user is on a Windows Mobile phone, a Blackberry, or a Symbian-based smartphone, don't even think about writing a J2ME app. Just don't. If you haven't been down this road, you're probably thinking, "Of course I wouldn't do that.. why do think I would?"

Here's why, sooner or later, you're going to be tempted to do it. And if you're not, another project stakeholder will, and you're going to have to talk him or her out of it. The argument is going to go like this:

1. The J2ME / MIDP platform offers a lot of functionality (graphics, networking, threading, PIM integration)
2. The vast majority of phones support J2ME, even ones that also offer an OS-level API, like Symbian or Windows Mobile
3. Therefore, if an app is built on J2ME/MIDP, it will have an enormously larger potential market size in terms of device compatibility. Like an order of magnitude (or more) larger. And, heck, it's easier to write one app than a whole pile of them, right?

The problem is not that you're going to be have to do a lot of adaptation, since no two J2ME implementations do the same thing. Although it's something to keep in mind.

The real problem is that if your customer is a smartphone user, the J2ME app is going to stink. It will be clunky, trouble-prone, and will not match the level of user experience that the user is accustomed to on their device. Compared to the native apps on the device, yours will be the "weird" one that somehow just doesn't work quite right. (Incidentally, this is exactly how Yahoo! Go looks next to the couple dozen native Windows apps on my Blackjack.) So just when you think you've got a killer app figured out for mobile, you're guaranteeing it won't be.

And you're not really going to attract those hundreds of millions of J2ME-capable feature-phone-users because they weren't your target in the first place. Not to mention, those users generally don't understand how to install apps on their devices, don't have unlimited data plans, and don't understand how incremental data charges work on their plan, so they are terrified of the cost of using networked apps.

Bottom line: it sounds cliche, but know your market and build what they want to use.  Build a Blackberry app for your Blackberry users and a Windows app for your Windows users. It's easier than building hacked-up J2ME apps. It's enormously easier to test and support, because those operating system APIs you're using are actually tested and supported (unlike J2ME). And if you're secretly nervous that there aren't enough customers on these platforms to support your business plan, admit it now and make some adjustments before you write a line of code.

Now You Can Start Porting All Your Killer J2ME Apps to .Net CF

Yes, that's a joke.

After discovering the J2ME implementation shipped with Yahoo! Go's Windows Smartphone implementation, I felt compelled to take one more little step and make sure that you could actually build and deploy your own (or someone else's) MIDlets on the framework.

So I grabbed ye olde Hello World MIDlet which -- at one point anyway -- was part of a Sun tutorial on MIDP 1.0 programming, and wanted to see if I could get it to run on the javaxnet10 layer. Purely for research purposes, of course, because deploying other apps against the Y!Go runtime is likely against the EULA/license.

This exercise turned out to be pretty trivial, and it goes like this:

1. Create a new C# Smartphone project in Visual Studio (VS). Using J# would obviate a lot of small C#/Java syntax changes, but by default J# isn't supported for "smart device" projects. In theory it should be fairly easy to flip compiler switches and get it working (it's all IL, after all), but the fastest route for me to try this out was with C#.
   
2. Make a lib folder and bring in the javaxnet10.dll, platfom.dll, and interop.dll libs from a Windows Mobile distro of Y!Go. As of today, all of the available Windows Mobile devices are ARM-based (as is the MS Smartphone emulator), so you'll have an ARM interop.dll, which is fine.
   
3. In VS, add references to javaxnet10.dll and platform.dll. Add interop.dll as an "existing item" and mark it to be copied through into the output directory for your app.
   
4. Delete the Program class that VS generates (which has the Smartphone app entry point) and the Form1 class (MIDP handles the display; you won't be using System.Windows.Forms directly).
   
5. Add in the Hello World (or other) MIDlet class, and perform C#-ification. (C# is explicit about virtual/override, string and bool vs. String and boolean, etc.)
   
6. Add a .Net-suitable entry point. I used the following code, which is taken from the decompiled Main entry point in Yahoo! Go:
   
   private static void Main()
   {
              MIDlet midlet = new HelloWorld();
              MIDlet.Start(midlet);
   }
   
   
7. Click "debug" to do a build-deploy-run. If this is the first .Net CF app you're debugging on this emulator image, be patient -- it takes a little while for VS to deploy the compact framework to the device. My HelloWorld C# MIDlet source produces this output:
   
   

   

 

Ok... so we have the ability to import MIDlet code and run it in on the .Net compact framework runtime. Pretty cool.

If we wanted to try this with a real J2ME codebase, we'd almost certainly want to build it with the jsc, the Visual J# compiler, or else run it through a Java-C# syntax conversion tool, so as to avoid creating a entire C# variant of the code.

I'm still curious where this J2ME implementation came from (I'm about to shoot an email off to Jeremy Zawodny with Yahoo's developer group / dev relations to ask) ... If it's not an in-house creation, my best guess would be the mobile game industry, since that's the one area where MIDP apps have been successful enough that it would be worth the investment to be able to sell them on Windows phones.

And I still plan to comment on what this all means in terms of an architecture choice for Yahoo! Go ... (and no, the last post about NIH and crackpots was not the promised commentary about it).

In a Small Company, NIH is Just Paranoia and Crackpot-ism

If you meet a math or science professor at a party and you don't feel like you have any intelligent questions to ask or small talk to make, just ask about his or her "crackpot file."  You're guaranteed amusing stories about sometimes smart, sometimes crazy, and always ill-trained "amateurs" who write in with easy proofs of hard things (like Fermat's Last Theorem) and hard proofs of impossible things (like squaring the circle).

In the software world, full-on crackpot code ideas tend to be self-correcting -- the code doesn't run, or doesn't produce the desired result. But crackpot-ism has a cousin in software. In large entities, this is referred to as NIH, or "Not Invented Here." An organization becomes so impressed with itself that it starts re-inventing more and more of the world, believing that its own in-house solutions are always better and more clever that what is in general use in the industry. NIH does not apply to "core" intellectual property, like a new algorithm for a search engine, where the whole point is to build something new or better; instead it applies to well-known components, like building one's own "better" database, when there is no evidence that an off-the-shelf database wouldn't work.

There are rare cases of NIH being beneficial, and beliefs that some organizations (the NSA and military) do indeed have more advanced solutions than what is generally available. But in most cases, and, in small software companies, in all cases, NIH is just crackpot-ism.

It is not uncommon for a startup to have a "genius hacker" doing a lot of the heavy lifting. Which is great. The problem comes when the genius hacker loses touch with the industry and the overall goal of the startup (make a product, make money) and begins creating his or her own "clever" and unusual architecture components. Common examples are inventing a new data storage engine (because none of the existing ones fit your application or are fast enough, and you don't understand the way these problems are normally solved and/or you haven't actually done a proper performance test anyway) and inventing your own TCP layer (because UDP is "more efficient" ... but -- wait! -- actually you need the features of TCP and surely you can figure this out better than the folks that developed it, they're so old and stupid anyway).

This flavor of crackpot-ism tends to corrupt the organization: as the system gets more and more peculiar, the company is increasingly dependent on the developer. New outside job candidates who figure out what's going on become increasingly reluctant to join the firm. The company lives in fear of the crackpot developer, because he insists that any substantial remediation would be foolish or have terrible schedule consequences.

Management may get an inkling of what's happening, but are more interested in the business benefit of achieving the next milestone than in the expensive, painful transition that will result from trying to bring some sanity to the product architecture.

And so it goes, with the strange architecture gaining more and more control over the company until the feasibility of products and features are determined by how well they fit into the crackpot's technology stack. Ultimately, the wacky implementation is driving the entire product roadmap, and the whole company is pwned.

Reverse Engineering: Finding the (Not So) Secrets of javaxnet10.dll

When I was restoring my Blackjack from backup last week, I noticed a file with an interesting name in the Yahoo! Go application folder: javaxnet10.dll

Eh? ... some kind of Java library? or a JVM? or maybe just a Microsoft runtime DLL for using J# with the .Net Compact Framework? Running J2ME apps on .Net CF would be a kind of cool... Ok, off to Google. A Google search for "javaxnet10" (over the web and newsgroup archive) produces several links to this single discussion thread where someone speculates on this exact question.

So I did some research. I'll save my conclusions and speculation for my next post; here, I'll tell you how I did my 10-minute analysis of this app. Old news to Win32 developers, but I think there may be a few .net/mobile/Web2.0 devs out there that might find this useful.

First, I used ActiveSync to pull all the DLLs and EXE for Y!Go off of my phone and onto my desktop. Then I right-clicked on the files to see if there was any metadata I could view that way. There was nothing -- either because it wasn't published, or it was removed at some point.

So I opened up a Visual Studio command prompt and cranked up dumpbin.exe. Dumpbin is a command-line PE format file processor. Since Windows Mobile is built on Windows CE and uses PE format for binaries, dumpbin doesn't care that these files are for a phone with an ARM processor rather than a desktop with an x86. Dumpbin will tell you which libraries a file loads, what it exports for other files to use, and all kinds of other fun stuff, including disassembly and -- get this -- it will disassemble an ARM binary into ARM assembly (the register names are the giveaway). I wonder how many instruction sets it understands?

But that's not relevant here because javaxnet10.dll is not a native code library at all.

It's a .Net assembly. How do I know? It reports a single import of mscoree.dll. mscoree.dll, short for "Microsoft component object runtime execution engine" is the .Net virtual machine. Or, as Don Box more poetically put it, "mscoree is the last COM DLL." He meant that metaphorically, not literally, of course. "mscorlib," he continued, "is the first .Net DLL," since that's the base library that mscoree loads to do anything useful.

Ok, let's look at all the files from Y!Go and see how they break down: javaxnet10.dll is .net, platform.dll is .net, ygonet.exe is .net, interop.dll is native (it imports a handful of OS binaries, and not the .net runtime -- try dumpbin /dependents to see).

So this is looking like a .Net CF app, with a native interop helper library for things that are hard or impossible to do with .Net CF. But we still haven't answered the question of what javaxnet10.dll is about.

Since it's a .Net assembly, we can bring in the magical MRI machine of dot-net, Lutz Roeder's .NET Reflector. This tool is an amazing free application that allows you to fully explore the insides of a .Net assembly, from the class-and-namespace level down to full decompilation. And, since .Net IL is much richer in metadata than native assembly, the decompilation produces intelligible code in the .Net language of your choice!

Point the .NET Reflector at javaxnet10.dll, and the mystery is revealed: it's an implementation of most (maybe all) of the J2ME and MIDP APIs. It does not run Java bytecode (it's not a JVM, interpreter, or cross compiler). Instead, it implements Java platform interfaces the way WINE implements Windows APIs. Here's a screenshot... the namespaces read like a tour of the MIDP API.

Just to confirm our understanding, we can basically browse the source of the whole application, and see the use of Java types and patterns everywhere. For example, StringBuffer is the classic Java equivalent of .Net's System.Text.StringBuilder. Although the waters have been muddied with the recent introduction of a Java class called StringBuilder, J2ME/MIDP predates that API by years. Which is to say, if the app were being written in a .Net CF style, we would see StringBuilder in high-level functions even if Java libraries were leveraged down below. In a Java mobile style, we'd see StringBuffer. The fact the we see StringBuffer (and many similar cases) argues that, in fact, this is basically a Java app. Heck, com.yahoo.go.app.YGo extends javax.microedition.midlet.MIDlet.

'Nuff said. Next time, we'll talk about the significance or usefulness of our discoveries, and where javaxnet10.dll might have come from.

Show Up for Class, Learn the Questions on the Final (or Interview)

Even though I went to the University of Chicago, unofficially known as the place "where fun comes to die," some profs had a sense of humor. Physics professors would sometimes "joke" about the sort of problems that would likely appear on the final, and the joke was that those problems (or nearly identical ones) would appear on the final. If, even with the hint, you still didn't prepare how to solve the problem, then the joke was on you.

In that spirit, I'll share my two favorite (at the moment) interview questions for senior- and lead-level tech job candidates. First:

What's interesting about RSS?

I'm not looking for what RSS stands for, how it works, what library you'd use to parse it, or who invented it, although those might make excellent lead-in questions. Or fallback ones if you have no idea how to answer the real question.

The real question is about the significance of RSS ... to the industry, to building applications, etc. You don't have to like it. Tell me why it's no good. Tell me how you'd do it differently, and what the tradeoffs are. Tell me about the alternate formats and why they exist. Or tell me why it's saved the Internet. Either way, show some real thought process. I know it sounds obnoxious to read -- heck, it sounds obnoxious to write. But hundreds of absolutely stumped interviewees with overblown resumes have taught me it's necessary.

Second:

"I always thought that Smalltalk would beat Java, I just didn’t know that it would be called ‘Ruby’ when it did." — Kent Beck.
What is Kent saying here?

Notwithstanding this page, which claims to have verified the quote, it could be apocryphal. Doesn't matter (though it's not bad if you know who Kent Beck is or at least recognize the name).

I want to know what you think the quote means. At the industry level, what's the significance of Smalltalk? Ruby? Why are they being compared? Why are they distinguished from Java? At the nuts-and-bolts level, what might it hint at in terms of improving Ruby performance?

Anyway, it's not the answer, it's the thought process that matters.

No. It's Just About the Metadata.

If an ad-supported blog exists to stir the pot then I supposed the GigaOM network's future of software blog is succeeding. I thought the first post was tennis without a net. Actually I also thought the second post was tennis without a net. And now I think the latest, "Web Services war is over: Time to Rest" is just bogus hype. Not that REST isn’t gaining ascendancy, but it’s a case of the straw man fallacy.

The war was never between REST and WS-* specs: the WS-* specs have been despised, ignored, and abused since their introduction.

Nor is it between REST and SOAP (and the xml schema documents that go with SOAP, which are also despised) which WS-* was meant to supplement.

It’s a war of describing operation semantics versus hoping that they will be “implicitly self-describing” and that everyone can agree on what GET, PUT, DELETE, POST etc. mean.

 The latter, which is the purist REST position, works well for documents (e.g., HTML pages on the web), and alright for basic business objects (calendar appointment, car maintenance record) but gets a lot trickier for transactional services like “change John's seat on the second jetBlue segment today to 13A, or else the window seat closest to the front of the cabin, or else fail fast and give me a set of alternate available seats.” Can this be done with REST? Yes … kinda sorta … but the call will not be one of those trivial “implicitly self-describing operations on an entity” that REST works very well for.

The good news is that, in reality, both camps are converging on a compromise: REST with (optional) metadata: WADL, OpenSearch, WRDL, even the much-maligned (and for good reason) WSDL 2.0. The metadata supports tooling, automated strong bindings, better testing, automatic integration to enterprise object buses etc.

This is a philosophical step away from REST, but this is actually what we’re seeing coming down the pike for enterprise work, and the SOAP and WS-* people will be just fine with it.

Minimo and Blackjack: Destruction, Repair

On my Blackjack phone, I use Pocket IE, Opera, and the pseudo browsers in Yahoo! Go and Windows Live Search for Mobile. But none of them deliver the Firefox-level experience I really want. So today I grabbed the latest build of Minimo, a Windows Mobile build of Mozilla that has been in development for a few years now. I installed it, it started, it stopped, it completely trashed my Blackjack smartphone. Ouch.

I'm not complaining about Minimo, since it's a 0.2 product, it's open source, and I'm thankful folks write software and give it away as early as possible. Stuff happens, especially when it's v. 0.2 and mobile (since true smartphones give the user full power over the device and there is rarely a root vs. user privilege distinction).

Instead, I figured I'd share the symptom and the solution.

Symptom: After rebooting, the home screen was missing graphics, the Start Menu was empty, and the whole device was relatively non functional.

After freaking out for a moment or two, I plugged in my ActiveSync cable and opened the device file explorer from my desktop. The filesystem seemed mostly ok. The biggest problem I immediately saw was that, in the Windows directory, all of the folders were gone. Bad for Windows. But not so bad for me, since the rest of my data looked to be still there.

Fix:

Step 1. Make a folder on my desktop, and copy off My Documents, My Pictures, etc. from the Blackjack.

Step 2. Copy off interesting folders in the Application Data folder from my device to the backup folder. In my case, this was a Google Maps for Mobile data folder.

Step 3. Copy off application folders from under the Program Files folder. Actually, I could have skipped this step and installed the software anew. Moreover, there's no guarantee that copying an application folder ("xcopy deployment") will work. But many mobile apps play nice and keep all the necessary binaries in their folder. Some of these same ones also play not-so-nice and put configuration data in their app folder too. Ideally this should go in a data folder (like under Application Data) or user settings folder. But it doesn't always work that way, and I wanted to preserve this data if possible. So... grab the app folder for things like Yahoo! Go, Live Search, etc.

Step 4. Factory reset! Unhook from PC. Power off the Blackjack. Holder the "up direction" on the directional pad while powering back on. Answer the prompts indicating you do want to format (the flash memory).

Step 5. Wait a few moments, and you're looking at the baby fresh Blackjack that greeted you when you first took it out of the box.

Step 6. Plug it back into your PC. If you use Exchange ActiveSync and/or DirectPush, enter your account and password data. The phone will sync and all of your contacts, calendar, mail, etc. will automagically re-appear on your phone.

Step 7. Copy the stuff from steps 1, 2, and 3 back onto the device in the appropriate locations.

Step 8. Reinstall any OS extensions that you need, such as the .Net Framework. In particular, the Blackjack doesn't ship with .Net Compact Framework v. 2. So if you use any software that depends on .Net CF2 it, you'll need to reinstall it. Easily enough done.

Step 9. Adjust device settings the way you like -- things like sound profiles, choice of home screen, and which app lives under the right-side-soft-key.

All in all, only a minor hassle.

Here's a vaguely clever idea in parting: Microsoft should provide an API (as part of the Pocket Outlook / Exchange Sync services) that lets apps store their data (and backup images of themselves) with a mechanism that syncs to storage on the Exchange Server. Maybe with some kind of unified store API like Core Data. Preferably with versioning.

This would be good for Microsoft, because it would be a great phone feature and a great way to sell Server and Exchange licenses, and maybe even work SQL Server and SQL Server CE. It would be great for the end user (me) because if things go badly, I can wipe my phone, re-create my pairing to the Exchange server and -- just like my contacts and mail -- all of my apps and config data would show up.

Free Stuff Heralds Changing Conference Scene ... Not Just More Money Either

LinuxWorld is offering free exhibit hall passes for the San Francisco show next week. They have always made exhibit passes available for free. But in the past, as with many conferences, free guests were

• only free when pre-registered by a certain date
• restricted from conference sessions
• not invited to catered events

After the dot-com crash, free passes got cheaper. This year, things are even easier, with LinuxWorld providing

• free day-of-conference passes
• coupons for passes sent to all pre-registered attendees, with instructions to photocopy
• open invitation to the "kick-off" shindig
• a voucher to attend one conference session for exhibit-hall-only guests

The tech show world has been evolving: JavaOne, after some years of a no-exhibit-pass policy started selling them. The Web 2.0 conference not only invited people in for free, but invited them to a free-beer-and-food fest. It's not just that the shows are hurting for attendee numbers to prop up sponsorship and booth prices. They may be, but I haven't got data to prove it.

Rather, it's that the value proposition of the show has changed. Conference sessions used to be a critical way to keep up with the tech landscape. I remember my frustration at not being able to get into the $2000 JavaOne show in 1999: I was working on a critical app using the brand-new Java2D API and the only people who really knew what I needed to find out about this API were not available to chat except at that show.

Now, the developers themselves blog about the newest APIs, post examples, and answer comments, providing a richer kind of support than was ever possible before. So you don't need to wait in line to snag them for 30 seconds at the end of a session.

Companies large and small are freely distributing pre-release bits too. Years ahead of RTM, in some cases. The audience has gotten sophisticated, and understands the difference between a brilliant but unofficial "side project" of a developer, a CTP, a "Go Live License" ... and that their favorite features may not make it to the RC, but that's a small price to pay for having running code -- for free! -- many quarters ahead of retail launch.

Valuable beta bits from the show goodie bag are usually posted by their creators within hours of any significant announcement at a show. And the blogosphere is de facto host to a worldwide birds-of-a-feather session that dwarfs any single show.

Meanwhile, unconferences are proliferating, where developers go to jack their brains straight into the coding matrix of other geeks, bypassing silly conference stuff, going right to what's relevant, and showing something off or banging something out on their own.

So where does that leave traditional format tech conferences? Honestly, I'm not sure. I hope somewhere good, since I'm presenting at one in September.

The current vibrancy of the tech economy should guarantee that these traditional-format shows will not whither due to lack of sponsorship/exhibitor money, or employers' belt-tightening. Money isn't the currency at issue at the moment. But attention is, and the quest to craft something that combines the meaningful intimacy of the unconferences with the massive scale of the every-day-is-Christmas tech-blog world. It's a big, expensive, and maybe even lucrative opportunity.