Are you doing cool stuff? If so, you need to communicate how cool it is, with demo apps, exciting examples, articles, talks, and seminars. I love to bring the best new technologies into the public eye. I'm especially a fan of innovative programming tools and mobility software (Tablet PC, SmartPhone, and .NET Compact Framework). Contact me:
Code, industry analysis, and miscellaneous cross-links from Larry O'Brien, the former editor of Computer Language and Software Development magazines.
To receive an occasional announcement message regarding my seminars or publications, please subscribe to my mailing list.
....Why don't I just bill the user via email using something like PayPal? Think about it, the user enters their email and phone number on their phone, promises to pay the 99 cents when they get to a real computer and that's it. Done. No middle man, no carriers, no aggregators, no e-wallets, nothing. Just an old fashioned billing system....there will be lots of people who will never pay. Fine....Some will gladly pony up for the convenience, others will try to ditch the cost because they're like that.... If they lie about their email or SMS, then they don't actually receive the answer.... Bill My Email. Quick, easy and simple. via [Russell Beattie Notebook]
Not the first really good idea from Russell.
Apparently some top Xbox execs are quietly confirming that the Xbox 2 isn't going to be backwards compatible with original Xbox games. via [Engadget]
MSDN Magazine: 2, Raymond Chen: 0!!!!
On rereading Joel's article, I think his argument boils down to:

He's not denying the need to rely on "external dependencies," he's advocating that such dependencies be localized. Why? Because when there are several external dependencies, they have a tendency to have internal dependencies, and you tend to need a very specific set of versions and it's a source of complexity and, therefore, application brittleness.
Hiding multiple dependencies behind a single dependency is A Good Thing. This is what I was getting at in my previous post about "touch once, fix everywhere." But I still don't see how this supports his thesis that Microsoft lost the API war, since API dependencies still exist. And it only supports the "Web Apps will rule" conclusion to the extent that the client value really doesn't depend on an external service (API). If you need to make music (which is only a shorthand for "things which, for connectivity, computational, security, or resource issues make sense to execute locally"), you've got to have a local API.
Corporate development choices are driven by the imperative to rapidly deliver customer value. Developers have their own values (language preferences, philosophical agenda, etc.) which sometimes conflict with this imperative but when push comes to shove, a CTO's job is to "get it done."
The great advantage of Web Apps for corporate development, and to a slightly lesser extent for ISVs, is the "touch once, fix everwhere," deployment model. The hyperlink and button Web UI paradigm has a "don't make me think" advantage and is easy to develop, but really, what makes the Web ideal for corporate development is that because corporate apps evolve in a much-less disciplined manner than commercial software, Web-based deployment can get a fix "into the field" in a matter of hours.
Visual Studio Tools for Office gives a hint of how Web-based deployment can be combined with the ultimate fat client: Microsoft's Office suite. The problem is that even VSTO does not yet have an appealing solution for bestowing trust. There needs to be an easy yet completely trustworthy rights-granting process: in a completely trustworthy manner, the publisher identity and a comprehensive list of security requests must be presented to an administrative actor (either a sufficiently trustworthy end-user, a remote operator, or a system process). Basically, .NET's got the publisher-identity stuff down, but the list of security attributes and process by which rights are granted are too obscure.
You need something along the lines of a firewall: I was just configuring a system for my sister and got an alert that something called "Backweb" was trying to access the Internet. I Googled for it and found that it was the result of having just installed a Logitech device: okay. Remove the step of having to manually Google for an explanation and extend the firewall-like "Allow, Allow once, Block once, Block forever" across all security attributes and you've got the type of UI I'm talking about. Modify it so that instead of my sister getting the message I could set up her system to pass the security request to me (her sysadmin) for either manual or automated decision-making.
Short of that type of capability, the fat-client model will always be less appealing than Web Apps on the deployment front.
| June 2004 | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
| May Jul | ||||||
Recent code:
Recent writing:
Review of Borland's C# Builder 1.0
Recommended .NET Programming Books
Programming Sabre with Java, C#, and XML
Best Practices for .NET Architecture
Windows Server 2003 as an Application Server
Toolroll:
Motion Computing M1200 Tablet PC
Visual Studio 2003 Enterprise Architect
Rational Rose Enterprise Edition 7
T Mobile Pocket PC Phone Edition