TextMarks and AppEngine Make Building SMS-Enabled Webapps Simple

TextMarks has been on my radar for a little while. It's a company offering free (ad-supported) access to SMS shortcode 41411, via a secondary keyword of your choice. They also have pro options with no ads, and shorter (or reserved) keywords.

Not having a great idea for a SMS-based app (I think I'm biased from having web-enabled, push-email PDAs for too long), but wanting to kick the tires, I decided to build an iteration of the now-classic "to-do list" app.

Meanwhile, I've been spending a little time with the Google AppEngine. When a hosting account came due for renewal, I decided to see if I could replicate it using AppEngine. AppEngine covers all the basics, and makes it easy to stream BLOBs out of the datastore as well. But if you host files (anything over 1MB), those are not allowed in AppEngine, either as static files or as datastore objects. Too great a magnet for bandwidth or data hogs I suppose. So those files live somewhere else.

But AppEngine makes a fine place to put a small SMS-driven app (assuming you don't need the background processes or scheduled processes that AppEngine doesn't allow).

Registering a TextMark is simple. Set the URL to the one you want called when 41411 receives your keyword, and add dynamic data from the SMS into the URL request GET params using escape sequences (e.g., \0 means "the whole message after my keyword"). So your URL might look something like http://foo.appspot.com/sms?text=\0).

Go into the "Manage" tab, pick "Configuration" and turn off the various options related to "posting messages" -- these aren't necessary for your app. If you aren't planning to asynchronously send messages out to your users (hard to do with AppEngine, as mentioned above), you can also turn off the subscription options.

Now you just need a handler on AppEngine to receive those calls and do something. Whatever the handler renders will be truncated and sent back to the user as a reply SMS, so you get a semi-web-like mechanism for confirming that you're done an operation, or returning results.

Create your AppEngine app, a handler, and yaml that ties 'em together, per the tutorial. Now you can just modify the basic HelloWorld to do your bidding instead.

Here is my little memo handler -- it files memos under the phone number of the person sending the text, and forwards a list of all the memos to an email address if it receives the command "export (email address)." Don't put anything private in there, since there's no PIN/authentication (although it would be easy enough to add) ... so anyone who knows your phone number and can build a URL by hand can just ask for all your notes :)

Of course, it's easy to test out your handler with just the browser address bar, but TextMarks also provides a nice emulator so you can send messages to your handler -- and see what the response will look like with their 120 char (free account) limit and their ad tacked on. And there are a bunch of other neat things you can do, like create short term stateful contexts, where a user can just text back Y/N or a response to numbered "menu" and the messages will get to your app automagically.

zBoost Cell Extender: Refinement Post

This is a refinement, or follow-up, to my first post about cell signal boosting with zBoost:

While the base station allows decent communication over a specific area once a data or voice call is established, it seems to have little or no ability to propagate the signaling part of the GSM protocols when there is no connection established.

This symptom means that the network is unaware of a handset, and a handset thinks there is no service. As a result, it often will not even try to make a call.

Once the handset decides there's a network -- usually by picking up a very faint signal from a real tower -- it will attempt the call and then discovers a near-perfect connection.

zBoost may not be responsible for this behavior -- the product docs specifically say that you have to have some real signal level in order to use the repeater. I had imagined this restriction was solely due to the zBoost device needing a tower to talk to (it cannot bridge to another backhaul) -- but in fact it may also be due to zBoost's inability to simulate the idle signaling between the handset and the tower. That is, you need a tower to make or get a call, but the zBoost can boost the data in the call stream.

So what does this all mean?

Well basically that if your RF visibility to a tower is marginal, as mine is, zBoost may still be able to help. But you don't want to rely on this to reach 911 or make any other kind of need it right now phone call, as it might take you a few minutes of moving around or monkeying with the phone to get it to realize there's any service.

Likewise, if you absolutely positively cannot miss an incoming call, this may not be the solution for you, although, interestingly, incoming signaling (calls and SMS) seems to be stronger/prioritized traffic from the tower than idle updates, and so gets to the handset more frequently, without any kind of booster present.

Credit Crisis: At Least One Great Thing Already Happening for Silicon Valley

The unfolding credit crisis may have severe implications for the region -- or the world -- a bit down the line. But it is already helping chip away at one of the Bay Area's biggest long-term problems: housing (un)affordability.

I'm going to keep with my narrow technology focus here and, fairly or not, make an analysis specifically of the region's viability as a technology and innovation hub, its ability to route investment into businesses that attract top engineers and churn out world-changing products.

Every year when the region's large business leaders meet, housing is at or near the top of their list of concerns. It's hard to hire in a place people cannot afford to live. Especially when potential employees are talented and often mobile, with a lot of options in front of them.

Owning a house in the Bay Area has been expensive for some time. But -- in the space of the last eight years or so -- it has crossed the line from "painful but affordable" to "not realistically affordable" for the technology professionals smart enough not to take one of those wild-'n'-wacky subprime loans with a handful of bogus low payments up front.

I'm going to be concrete here, and use specific numbers... numbers which may leave you gasping or slapping your head if you live elsewhere in the world, but numbers which are real.

In the wake of the dot-com crash, a large portion of the area's "starter house" stock was available for $350,000 to $500,000. These were often 2-bedroom tract homes, not always in the most desirable locations, but not in the worst either. They were no bargain, but they were affordable for the "senior software engineers" with a decent education, a half-dozen years of experience, and the willingness to save for a real down payment all that time instead of going wild with the Visa card. These engineers had seen their earning power top $100,000 (partly due to the dot-com boom), and if they avoided Aqua when the company wasn't paying, they could sock away some serious cash.

A widely held rule of thumb regarding housing affordability suggests that at most one-third -- perhaps a little more -- of gross income can go to housing. More than that, and the probability of the buyer experiencing financial hardship or outright defaulting goes up sharply.

So the senior engineer, with say six or seven years of professional experience, making a little over $100,000 -- exactly the "heart of the batting order" in a growing tech company's talent pool -- could afford a $400,000-$500,000 house, at around 6%, with the traditional 20% down payment. If they had a significant other who was also earning money, they could afford a little more. But not too much more if they didn't want to be dependent on those full dual incomes indefinitely.

Almost all of the folks in my "cohort" (say, within four years or so of my age) whom I know and who bought houses in the Bay Area did so in this way, at this time, and with this sort of cost.

Fast forward three years.

Easy money and bogus mortgages have caused prices to balloon. Those $400k-$500k houses become $700-$800k houses.

Salaries have drifted up a touch as the worst "crash" years pass, but not much beyond the rate of inflation, maybe $5k-$10k per year for these mid-level positions. Certainly not enough to cover the change in housing prices.

And -- just like that -- those engineers, the early-to-mid-career core of any tech company trying to scale, the folks who know enough to use a little process and not re-invent the wheel, while still working hard and willing to take chances to innovate and make something happen, have no access to the stock of starter homes.

Beyond the larger down payment, they discover that making a "real" (i.e., based on traditional mortgage terms) monthly payment on this $750,000 house means making over $150,000. And that's well beyond the typical salary for a senior engineer or even a lead engineer / architect type role.

And there's the story: that bubble cut off the up-and-coming generations of engineers from homeownership. Indefinitely if not permanently. If the Silicon Valley business leaders roundtable thought housing was an issue before, they are in a whole new landscape now.

But this is exactly where the credit crisis is starting to help. It was never practical to build our way out of the housing shortage because not only is buildable land scarce here, but ready credit meant each housing unit gets bid up based on what lenders are in the mood to invest.

Now that the brakes are on, we've already seen the median home price in the Bay Area drop by nearly a third from its high in '06. We need a couple more years of this -- together with lenders that want to see payments under that one-third of income mark, and a solid down payment.

When it all shakes out, perhaps some of my friends who missed that narrow window early in the decade and so, despite working hard, excelling, and making serious incomes, missed a chance to own any kind of house, will get their opportunity.

And, if it's too late for them -- after all, families grow, the kids get bigger, and that worn-down starter house won't look so attractive when we're all middle-aged -- at least the next generation of geeks and whiz kids will have a reason to work in Silicon Valley.

Low-Hanging Fruit: a Server-Side JavaScript API (or Standards, or ...)

There's a big chunk of stuff missing from JavaScript cloud-hosting platforms (like 10gen) and as well as from JavaScript semi-app-servers (like Phobos).

It's called any kind of API or standard.

Hard to believe, but after several years of growing JavaScript influence, and a whole web culture that is tilts towards openness and standards, all of the players -- Bungee Labs, AppJet, 10gen, Phobos, and many others -- are rolling their own little server-side platform APIs.

Standards make a platform easier to learn, understand, debate, debunk, and fix. They allow a larger community to share code and ideas, and provide a small degree of lock-in-proofing and future-proofing. Standards also allow transparent competition on the basis of implementation quality, tooling, SLA, etc., rather than obscuring those things behind incompatible facades (APIs).

New platforms on new technologies with no standards behind them can be a hard sell -- especially when they do not offer any new capabilities.

According to Techcrunch, Bungee is in a "freefall." And the interesting bit is that their CEO ascribed the recent round of layoffs to 'actual vs. anticipated rates of adoption.'

Hello, if you are trying to sell the world on your server-side JavaScript programming and deployment environment, you're not helping your 'rates of adoption' by also asking people to learn and commit to your own home-brew platform API.

Now to be fair, there aren't a lot of alternatives in the absence of a standard. But ... it would make a lot more sense for all these players to get together and create some standard APIs and commit to using them. The APIs would cover all the basics: e.g., persistence (of object, key-value and relational flavors), templates, request/response handling, calls out to other web services and processing of their responses, publishing SOAP services (which still remains critical in the enterprise world), and interop with other server-side environments (Java, Python, etc.)

Overnight, there would be a single community (and acronym!) instead of a dozen fragments. Like any standard, it would generate books, conferences, training materials -- and controversy, which is never a bad thing when you need publicity. We would see real performance tests, and get a real debate over where the JavaScript-to-SomethingElse boundary should be and why.

And these vendors would gain instant legitimacy by being founding contributors to a specific platform "trend," rather than lone voices in the woods. That legitimacy (and, via the sad logic of large companies, the "legitimacy" of being printed on the top of some conference bag) would help them appear credible to customers big enough to pay them real money.

BYOA (Bring Your Own Analogies)

I found this brilliant label on the side of an industrial-strength wood chipper/eater/pulverizer.

There are so many other places -- especially in software development -- where a label like this (including both explicit content and implicit assumptions about the attitude of the reader) would be appropriate.

I won't ruin your fun by babbling on about all the specific cases; instead I'll leave you the pleasure and satisfaction that will come as you begin thinking of them.

Presentations from SF Flash Hackers August '08

A couple of weeks ago I gave two mini-presentations to the SF Flash Hackers group, on topics I've talked about here before ... but I figured I'd post the slides to slideshare.

Here are slides about porting a large Windows app (Mindjet MindManager 7.2 with Connect) to run in the browser via Flash (developerd with Flex):

Porting a large Windows app to Flex

View SlideShare presentation or Upload your own.

 

And here are slides on generating ActionScript 3 code from UML class diagrams using my VASGen tool -- which is really a contribution building on two existing tools, the Violet UML modeler, and the Metaas ActionScript 3 meta-library (in Java):

As3 Code Gen from Uml

View SlideShare presentation or Upload your own.

Citibank Needs to Get Their PKI Act Together

While I'm thinking about security ... there has been plenty of debate over whether Firefox 3's hostility toward self-signed certs is a good idea.

Either way, this should be a non-issue in the banking world, which ought to have proper certs on any public facing machines.

So I was more than a little surprised when I went through a workflow with Citi, where a number of links, widgets, etc., triggered the Firefox self-signed-cert blockade/warning. The problem resources were loading from subdomains like foo.citibank.com or bar.citimortgage.com.

When I did some work with [insert other extremely large bank here], everything was SSL, even internal web service and app communications, and usually (not for external customers) mutual authentication. The bank had an entire PKI department, which controlled numerous separate CAs corresponding to dev, test, production, different business units/functions, etc.

Hooking up to most things meant sorting out the right kind of cert to present, and working the proper cert chain for whatever the server gave you. In some situations -- e.g., programmatically sorting this out in Java -- it was a major hassle. Not to mention that the PKI group was cooperative but busy, so there could be delays. And the certs were set to expire in not-so-long, so a whole mechanism was necessary to make sure you didn't have system failures in your department due to not getting a new cert placed in time.

It would have been much easier to use self-signed certs all over the place, but the bank wanted some extra protection even against rogue calls from inside the network. The policy made sense and, even if it didn't to you, your alternative was to box up your stuff and leave the building.

Of course intentionally deploying a production service to external customers with a bogus cert was so unimaginable it wouldn't have even been funny ... in order to be funny there would've had to have been some molecule of possibility in it, and there wasn't.

Can Citibank really not have controls that prevent this?

Chrome's Unusual Installation Location: Good, Bad, or Ugly?

I -- and many other folks -- have noticed that Google Chrome installs only for a single user, and does so in a way that does not require administrative privileges to run the installer.

Basically, it just drops its files into a subdirectory of the user's home directory, places its shortcuts in the user's specific Start Menu folder, Desktop folder, etc., and arranges for its GoogleUpdate.exe helper app to launch from Windows/CurrentVersion/Run under HKEY_CURRENT_USER, rather than HKEY_LOCAL_MACHINE.

This is an unusual pattern for a Windows installer, almost certainly rigged in order to allow minimal-privilege user accounts on corporate networks to install and run Chrome ... under the radar of IT or management policy, if need be.

The question is whether this is inherently a security problem.

On one hand, I've read posts pointing out that this setup leaves the executable vulnerable to other executables that run with the user's permissions. This means another app could replace Chrome with a compromised Chrome, and the user would never know. At the same time, if Chrome can install, then any other malware could install itself the same way -- set itself up to launch under HKCU/.../CurrentVersion/Run, and sit in the background doing anything it wanted (like listen to keystrokes for another HWND). Then again, being in the user's browser might make snarfing credentials and scripting their use (or taking advantage of an auth cookie being present) a lot easier. The point is that a traditional executable under Program Files should be less vulnerable -- a nonprivileged user account can't rewrite those files.

On the other hand ... this is not terribly unlike the install/run routine on *nix servers. If I'm a "regular" user, I'm not installing to /usr/bin, I'm just untarring in a local directory, possibly building, and then running the binary. Of course a user doing this is likely more sophisticated than general Windows users, and fewer *nix end users means less malware at the moment.

Always-On JavaScript Mildly Disturbing

Google Chrome doesn't have a switch to turn off or restrict scripts. While this might be an upcoming feature, my guess is that Chrome is about "running" web 2.0 apps, and so JavaScript is considered essential.

Well, maybe that's ok if the security model around JavaScript execution is as fantastic as the comic book suggests.

On the other hand, the launch of this browser featuring a well-known security flaw (admittedly not a JavaScript flaw) makes me a less comfortable about always-100% script execution.

Amazon EC2 to Support Windows Server AMIs

Jeff Barr, Amazon Web Services Senior Evangelist, just finished giving a talk at "The AWS Start-up Event – San Francisco" in which he showed slides listing upcoming plans at AWS, including support for Windows Server.

This is an exciting development, as Windows Server / ASP.Net make for a fantastic if potentially expensive platform. Now Microsoft has to step up to the plate and come up with a pay-as-you-go, per-cycle or per-cpu-hour licensing scheme.

One of the things that makes ASP.Net interesting is that it lives in a nice middle ground between Java, which is extremely fast (in EC2, this means less expensive per transaction) and has great "enterprise" capabilities but is cumbersome to develop with, and, say, Rails, which is quite slow and has poor enterprise app cred but is very pleasant and lightweight to develop with. ASP.Net, especially with the MVC framework and forthcoming support for Python and Ruby in addition to C# and the other .Net languages, seems to combine extreme performance, easy development, and access to as much "enterprise" as you need while offering lightweight alternatives like LINQ and SSDS.

My point isn't to make a commercial for ASP.Net, but to point out that if Microsoft can get their licensing in order, they might catch up in the cloud world through fast, cheap development cycles plus faster (and hence cheaper) runtime operation on a given machine instance than some competing platforms.

Just to be fair, cloud vendor enomalism has run Windows Server on EC2 before, by virtue of the Qemu emulation software (on top of Linux). But if we're talking about maximizing efficiency, wasting cycles on another layer of emulation (EC2 instances are of course virtual to begin with) doesn't sound like the way to go.

Om:Yes, Gillmor:No ... Comcast's Data Transfer Cap

Om Malik nailed it at the end of one his posts on the 250GB cap. He lists Comcast's stilted usage examples for email, music, etc., and asks "How many HD movies will fit under the cap?"

That's the right question, but not because he is worried he'll bump the cap watching video.

The reason it's the right question is that the cap has more to do with Comcast's long-term business plans -- and the cable/telco industry's plans -- than about slapping down a handful of network hogs.

One fact before we continue. As I've written before, while everyone squabbled over BlueRay or HDDVD, the filesharing world settled on the x264 implementation and a container format for it. In that compressed format, a high-def film averages 10-15 GB.

But here's the real deal:

Comcast's cable TV and on-demand video business competes directly with Internet video (both legal and gray-market). By making the cap high enough that it won't immediately impact YouTube watchers but -- over time -- will put a serious dent in customers' ability to get HD video over the Internet, Comcast is simply crippling one product so that customers will have to buy another product from them. Don't even think about mentioning broadband competition -- if you define competition as more than one entity offering substitutable goods (i.e. similar bandwidth, QoS, etc), then most of the U.S. has zero competition.

The 250GB cap is a way to push customers to buy the same content twice. To be specific, you'll pay to see a movie broadcast on cable TV in HD, and then pay again for some special plan that lets you watch the same content later on Hulu. Or you'll pay for Comcast "on-demand" to watch a show on your TV. But if you want to place-shift that show to your laptop or the gym (on your phone), you'll have to pay to get enough headroom to download the same video.

This move is not just about trying to squeeze out more money. It's yet another attempt by network operators to neglect their core business and instead try to get into a content business, so they can do two things badly instead of just one.

Meanwhile, Steve Gillmor writes that bandwidth caps will mean the end of BitTorrent downloading and a shift to streaming. Steve's a smart guy, but streaming is one of those perennial non-trends like speech recognition and thin-client computing. It's only conceivable to someone who has a computer connected to their TV or who lives on their laptop.

Having played a key role in several home-entertainment / media-tech startups, two of which have been successfully acquired, I feel confident saying streaming is only a little piece of a solution. For the foreseeable future, streaming will never be more than that. It neglects too many consumer needs and desires, is too inflexible, and is too warped by DRM and platform-lock-in issues.

Moreover, the latest round of DRM around HDMI and high-def media playback in general means that even in-home "streaming" -- i.e., from a PC to a TV or from one PC to another -- is facing setbacks just as Joe tech-savvy consumer finally starts to realize how to use a home server or network attached hard drive to get and watch shows.

And the set-top boxes, increasingly tied in tightly with content delivery (Comcast DVR, DirecTV TiVo expiring your pay-per-view movies, etc.) are more closed than ever. Instead of encouraging an ecosystem of streaming, they force customers into an ecosystem of downloading.

I think we'll see more people gaming the 250GB cap ... using scheduling software so they can maximize the utility of the 250GB and hoard downloads. Not to mention leaving the torrent client running so that every time I visit someone else's network -- an office, a coffeeshop, etc. -- I'll keep the downloads slowly but surely coming in.

One final note: the marginal cost of moving a kb of data around a big network -- that is, the cost of the power and cooling for the switches and the amortized cost of the cables and gear and ops guys divided over their lifetime data transfer -- is more or less zero when the network isn't already near peak bandwidth somewhere. So even if there is a problem, the volume-based cap is the answer to a different problem.

Extending a Cell Signal With zBoost

Although I'm curious about the AIRAVE, I'm not on Sprint and not convinced it's worth switching just for the AIRAVE capability.

But I do have a signal problem at my house, and I'm currently testing out the zBoost Wi-Ex signal booster to see how much of a dent it can make.

Unlike AIRAVE, which creates a local CDMA network and bridges it to another backhaul, the Wi-Ex is an RF repeater/amplifier. So you need to feed it a signal -- from somewhere nearby that has a signal -- and it extends the signal via a new base station and antenna.

So far I'm inconclusive on the quantitative results. Certainly, in my house, the coverage area it creates is closer to 600 square feet than the 2500 square feet advertised. But as with any RF setup, there are so many variables that this doesn't prove a heck of a lot.

I can report positive results on a qualitative measure.

Normally, the signal is so weak inside my house that, without this unit, I can receive a call signal (e.g., ring or text message) but as soon as I press "talk" it drops. 100% of the time. Also, my Blackjack had never successfully retrieved a web page from inside the house. With the zBoost unit, there is  qualitative difference: The data connection can retrieve web pages -- sometimes slower, sometimes faster, but pretty much successfully. And if I receive a call, I can answer without the call dropping instantly. Again, depending on various things the call quality may be better or worse -- but there is always a call there, struggling to get through. Which despite being reminiscent of 1995 is a major improvement.

What I'm wondering is ... if, as zBoost claims, the device is FCC legit and is designed not to create trouble for the existing cell network, why don't the cell carriers themselves sell this device? It seems like it could help them extend their reach geographically and satisfy a few more customers.

And before you suggest that they don't offer it because doing so would be tantamount to admitting their existing network footprint isn't solid, note that both T-Mobile and Sprint are already selling personal femtocells and rumors are that AT&T isn't far behind. And anyway, spotty coverage inside buildings has never been any kind of secret.

Airave and Network Sniffing for Fun and Profit

Sprint's AIRAVE BYOB (bring-your-own-backhaul) femtocell went on sale nationwide this week. Reviews seem mildly positive; it kind of costs a bunch considering you're subsidizing Sprint's infrastructure, but it's marketed toward people who have little other choice.

I don't have one (I'm not on Sprint at the moment). But if I did, the second thing I'd do with it is to start sniffing the traffic it sends back up the wire.

But all that data would be encrypted, right? Well, maybe ... and maybe not. Since Excel files seem to be an enterprise data store of choice these days for companies handling sensitive personal information, and since telcos are not the science-fair winners of the class but more like that kid in the back that just giggles all day keeps getting his lollipop stuck in his own hair, it wouldn't surprise me if they think ADPCM is encryption.

Even if some or all of the call content is encrypted, though, one could probably learn a lot about the signaling layer of the system -- i.e., how the network identifies and talks to the phones to indicate presence or session initiation.

Why would this be useful?

Well, for one thing, it would be interesting to use the AIRAVE as a presence detection mechanism. Once I can determine that the base station has recognized a known cell phone ID, I can automate all sorts of things that are supposed to happen when I'm nearby.

Applications include home automation (open locks, turn off the alarm); media (access and/or license to all of the media I own "appears" on any connected device when I'm nearby with my cell phone, and goes away when I leave); or for commerce: my hotel reservation, preferences at a restaurant, or online search history for a retailer can cue up automagically as I enter range.

Tripeedo Brings Travel Search Full-Circle

I couldn't help but crack up when I read a post about Tripeedo, an AJAX-enabled "command line for travel," since of course all this reservation searching stuff was on a command line to begin with, on a terminal a generation older than this hideous beast. And in fact while the hardware has mercifully been emulated away, the protocols are still in wide use under the hood in the travel industry.

I had to use a command line like this as recently as 2006 for a project. Unlike tripeedo's version, I recall the search started with a strange lozenge character that doesn't seem to have a proper Unicode name, but was part of the 6-bit EBCDIC charset these terminals used when they were deployed in 1969. Then came a letter or a delimiter of some sort, and then a line like 15AUGSFODFW to look at flights on August 15th from SFO to DFW.

I thought I'd try it in Tripeedo. The site prefers the month first, and it likes spaces. And, unlike the old system, it has lowercase letters too!

So I type "15 aug sfo dfw" and get some flights to look at. In 1969, this was the future.

iPhone Brings New Attention to AT&T's Existing 3G Problem

The wave has been building for a few days now, with consumers, Apple, and AT&T sparring over the problems with the iPhone 3G staying connected (and on 3G).

Today seems to be a local maximum and the mainstream media are starting to look.

If you read this blog regularly, you're probably expecting me to blame Apple for the problem, then blame Apple again for denying there's a problem, then blame Apple fanboys for putting up with it all for so long then suddenly acting betrayed.

Surprise!

As much as that might be a valid argument -- especially the part about Apple denying there's a problem -- this one is really not their fault.

It's kind of AT&T's fault -- and kind of GSM's fault -- and kind of just mediocre engineering.

A while back, I wrote about similar experiences with my Samsung Blackjack on AT&T. I've also seen the same thing with the AT&T 8525 (Cingular 8525 / HTC TyTn), as this was one of the first multi-protocol, multi-band 3G devices on that network.

Most people don't have any idea what this is all about, since their devices cannot experience this specific sort of problem because they don't support 3G, and so never have to resolve between 3G, EDGE, GPRS, etc.

In this case, AT&T argues that one suspect, the Infineon chipset, is not to blame because it's the same one in Samsung devices, with which they have had little problem. I don't think that's their strongest argument: others appear to be having as much trouble as I do with the Blackjack/3G. We just never made as much noise as the iPhone folks.

Perhaps a better argument would be that it affects all the EDGE/UMTS/HSDPA devices on the network and then maybe blame GSM for having such a funky data transport technology roadmap over the last 10 years.

I'm not saying AT&T could easily do better -- maybe they need more capacity and a tune-up of switching algorithms. A CNET article points to GSM carrier T-Mobile Netherlands having the same problem. And even though CDMA is worlds better as a technology, it's nice to have a little competition out there: two CDMA carriers for the U.S. out of four majors is enough.

So what does all this mean?

First, I'll tip my hat for once to the iPhonosphere and the obsessive media that love them: this is a real issue and we all know it takes a lot of volume to be heard talking to a telco.

Second, even Steve Jobs' strong-arming of the carriers worldwide (and good for him on that one!) doesn't mean everything is really under his control. According to this Sydney Morning Herald story, Apple didn't provide any test units to some carriers until the day before the product release, hoping it would all "just work."

To paraphrase someone I used to work with, in technology "hope is not a strategy."

Non-compete Ruling May Indirectly Help Broken Organizations

Last week's California court ruling against non-competes is interesting, not least because I've had one client who was more interested in a getting me to sign a specially crafted non-compete that he hoped to use in a lawsuit than in having me actually deliver work.

Actually I'm not sure this ruling would even affect independent contractors like me; the view of employment law towards contractors (where it applies at all) is very different from that toward employees.

This ruling may play a small role spurring innovation by making it easier for employees to quit and then compete with their former employer.

I'm also hopeful that the newly prominent threat of such competition may encourage dysfunctional tech organizations to renew their efforts at achieving better group dynamics. (Is there such a thing as therapy for whole organizations? No, I don't mean those motivational or consulting clown-schools that involve offsites and create a distraction ... at least until the check is cashed.)

In addition to the ominpresent threat that one's best employees might leave, there is now renewed emphasis on the fact that a group of them might well leave together and "do it right" if they can.

While the ruling does not of course give anyone license to loot protected IP from the former company, history shows that's rarely the issue in Silicon Valley anyway.

Every development manager should view this as a wake-up call to think about keeping the team on board.

Format Shifting

The dead-tree-publishing world is slowly starting to worry about online, possibly illegal, distribution of books. Not nearly enough to get smart about it though.

To me, it seems brain-dead obvious that if I buy a paper copy of a book for anywhere from $20 to $50, I ought to be able to use an electronic copy. I don't know the law on this, but I don't have pangs of conscience downloading a gray-market PDF of a book I've already bought, because the publisher wants to charge me again for an "e-book bundle" or because they make the content available in an annoying format.

But that's just the tip of the blade. In a short while, things like Kindle will take off, and the next generation -- motivated to leap in because of expensive textbooks -- will start assuming all books will be free.

Publishers should be experimenting with their models right now in attempt to adapt.

Here's one idea: the whole hardcover-softcover release cycle makes about as much sense as releasing a movie in the U.S. on Wednesday and not expecting it to be an xvid in homes in Thailand by Friday.

I like paper books, but I don't like hardcover books for anything non-classic. They're overly large, awkward to carry, just plain silly. So what happens when a publisher releases a new book I want to read in hardcover? I'm not inclined to buy it -- heck if I wanted to carry the hardcover around I could just get it out of the library.

I could download it as soon as someone puts it online, but I would want to print and bind it ... so I'd have to submit it as a print-on-demand job somewhere, hope they don't complain about the copyrighted material, and get it sent to me. I guess Kinko's is an option.

Anyone else see the problem/opportunity here?

For now, anyway, the hassle and cost of print-on-demand makes it a cost-neutral issue; I simply don't have the option getting a bound paper copy of the book for free. So given that I'm willing to -- and indeed must -- spend money to get the book, why won't the publisher sell it to me in the format I want?

Publishers ought to be taking the risks and making the friends now, before e-book readers make a big dent in the marker. Otherwise, it will be game over soon enough.

And before anyone suggests that the publishers play some critical role in blessing publications, I would point out that is just an artifact of the traditional physical distribution mechanism (paper, shelf space, etc.) ... the Internet already allows vastly more content than could be run through a press and tossed up at Borders. It's not all "good" ... but the net does a fine at creating search, moderation, and recommendation networks that allow one to find the good stuff, in a way that 3x5 "recommendation" cards tacked under a bookshelf at the local store cannot.

Rails and .Net Had One Thing in Common Before ASP.Net-MVC: Magic

It's possible now to build a very Rails-like website via ASP.Net MVC. And at RailsConf, John Lam showed IronRuby starting to run Rails.

But long before all this, these two very different platforms had one thing in common: "magic."

By magic, I mean the sort of implicit, we-solve-problems-you-didn't-even-know-you-had kind of magic that makes it easy for people who don't know the details, don't want to know the details, or know but don't want to be bothered by the details to build an app.

From ASP.Net's first iteration, where you could drop an item on a "web form," wire a server-side event handler, and talk to items on the page through a .Net server-side object interface, ASP.Net has been heavy on the magic. Rails has been the same way, from scaffolding up through ActiveRecord, you point Rails in the direction you want to go and it drives.

Of course we all know about the leaky abstractions... in .Net, you used to get some funky HTML and Javascript, plus a server-based page lifecycle that didn't always match the model of what you wanted to do with the DOM. In Rails, we've seen perf issues, and discussions of the "worst practices" [pdf] that can result from letting the autopilot do too much and your brain too little when writing for Rails.

But in any case -- as opposed to a framework like Django (which included a big feature push called 'removing the magic' to make functionality more explicit) -- Rails and .Net give you as much magic as they can.

[How] Will Microsoft Weather a Perfect Storm?

Last week's article What Is Microsoft So Afraid Of? is meant to be provocative ... but it is also real reporting.

Thinking about the situation Microsoft is in, I believe the firm has, at a high level, quite a lot to be worried about ... a sort of perfect storm of high-level business trends, many of which transcend any individual product or feature. Big trends are harder to debug and then patch on Tuesdays.

Here are the issues:

1. Declining importance of the desktop OS. As people spend more and more time in their browsers, the OS underneath it matters less. The trend is definitely toward more browser-based apps, even if they employ Flash or Silverlight or other acceleration technologies. Offline support is moving slowly but together with cloud (Mesh?) storage, will make the local filesystem less important.
2. Rise of OS X as a real competitor -- between publicity, 'time to sink in,' and the decreasing premium that Apple charges for a Mac over a similarly equipped Dell/Acer/Toshiba laptop, OS X is a real and growing threat to Windows.
3. Bill's off to save the world. For a while now, Bill has been the good cop (hey, stop laughing, I'm serious) to Steve Ballmer's bad cop. Now that Gates has retired to work on philanthropy, and Ballmer's the CEO, we're seeing more dumb-ass bad-cop stuff like the Mojave experiment, and less brilliant product strategy. Microsoft needs a good cop to pair off with Steve.
4. Vista failure. The .Net platform was one of the smartest, most successful things Microsoft has ever done, an enormous accomplishment that brought enterprise IT shops and other developers along. Following that up with Vista isn't just bad at the retail (license selling) level, it shakes enterprise confidence in MSFT, and ticks off developers. From a developer POV, most of the cool stuff in Vista was gutted, or moved somewhere else ... or never really worked very well (WPF), after years of build-up. Now MSFT desperately needs devs to buy into "the next thing," and they're hesitant.
5. Silverlight stuck in transition: Silverlight 2 is an awesome technology... but it has two problems: First, small penetration, unknown/unpublished penetration numbers, and no specific numeric commitment by MSFT to create penetration on PCs. Second, folks are sceptical that Silverlight on Mac really has a future. If that's in doubt, it seriously impacts the choice to use Silverlight because of #2 above. I can say that I've already had more than one client interested in doing serious work on Silverlight 2, but they insist on installed base projections (not download numbers) to make the business decision, and I don't blame them.
6. Rise of console gaming: PC gaming was always a key part of the "latest and greatest" PC/OS/component ecosystem, plus it helped press down Mac adoption. As consoles (including Microsoft's own Xbox 360) gain, this relative benefit of the Wintel client platform goes down... and yet MSFT still has to spend a ton on R&D if they intend to keep the PC gaming client (DirectX and hardware integration) decent. So less bang for the buck there.
7. Rise of USB. Now that practically everything runs over USB, it's easier for device makers to offer Linux, MacOS, etc. drivers (the upper layers can often be just user-space apps). So on the peripheral front there is less Windows differentiation in terms of hardware choices, and less lock-in.
8. Reluctance to innovate with server licensing model. Most startups dream of going big, and they assume they'll do so on an open-source stack -- not because Windows Server isn't a killer product ... but because the current licensing for Server makes it a non-starter for cloud services or for architectures designed around cheap, flexible horizontal scaling. An easy fix is to add auditing to the core WMI counters and create a Windows Server SKU that costs $0 per CPU and $0 per client ... but to stay in compliance you average your ASP.net transaction count, or SQL size/complexity + operation count and then cut a license renewal check. Make it free (as in beer, with online-only support) for the first few thousand page views per month for a typical app, and it'll rapidly start taking over a big piece of the startup and cloud/on-demand computing world.

All this said, big companies tend to have nine lives (even if Yahoo! seems intent on burning through all nine of them). So I'm not about to count Microsoft out, or suggest an "over-the-hill" tipping point is at hand. Just some big decisions, both strategic and tactical, that ought to be made well and soon.

So What's the Deal With ... ?

• ... those tech videos where the topic sounds interesting but I have to watch 3 guys chat about it in real time for 45 minutes? Like I have nothing better to do than watch people talk? Give me the slide deck, the bullets, a transcript, something I can scan through and read, since I know it's going to take me 4 minutes max to sort through the content.
• ... 10gen and the folks that want to write yet another server computing platform ... in JavaScript, and then compete with Google using their $1.5 million in VC? Ever since Douglas Crockford schooled me in the true nature of JavaScript, I've had little bad to say about the language. But why yet another platform for server-side computing? 10gen's argument that Google's AppEngine is too closed and locks apps in seems like a stretch: you can run Python/Django apps on AppEngine ... or somewhere else. Yes, the Google data API is their own, but it's simpler than a relational database API -- if you really need to use Google's data API over your own data store, it won't be hard to set up. There's also Rails, which is open and has the advantage (over 10gen) of being well known already ... If you don't think Rails can work as a cloud platform, talk to Heroku.
• ... Symbian's S60 emulator triggering DEP faults, so that Windows has to kill it? I can imagine how one might, when writing an emulator, run afoul of DEP ... But this is my first run-in with an app fatally triggering it, and I've already used Microsoft's device emulators, Palm's emulators, VMWare, and Sun's xVM VirtualBox (a VM is not the same as an emulator ... but some parts of the VM function via emulation) ... and had no problems.
• ... all the enmity toward Windows from the Rails guys? First, Ruby and Rails run fine on Windows, there's no need for all the "we specifically won't say anything about working on Windows, I mean, if you're crazy enough to want to do that" stuff that keeps popping up in otherwise respectable books. Second, many (most?) of the top Rails hackers are so young, they probably don't even remember Microsoft's real "bad old days." Yes, Microsoft has done some shady things worth complaining about. The fact that IE 7 doesn't render your CSS the way you wanted is not one of them.
• ... those posts where an unknown wantrepreneur with no valley connections or financing seeks a successful, experienced, genius hacker to build his mediocre but top secret idea for equity only? The posts crop up constantly on craigslist and all the SF tech meetup mailing lists. If this kind of post represents your thought process, why not just skip step 1 and 2, and post for people to send you a burlap sack full of cash?