dojo.offline = apollo.db = google.gears

You know those scenes in political thrillers when a character starts spilling the beans about what's really going on? And as the real plot takes shape in your mind you start thinking about the consequences: "That means the old guy is working for them ... and the girl is going to get killed if ... wait, she must've done all that stuff on purpose, which means..." You get the idea.

Well I had one of those experiences tonight at the final Google Developer Day session, where it turns out dojo has elected to scrap their own infrastructure for offline AJAX app operation, which had been in development a long time and had just reached beta. In the runup to Dev Day, Brad was treading lightly. But what he just told us is that the dojo plugin is dead. The dojo offline high-level Javascript library will run on top of the Google Gears offline app plugin. Incidentally, Google helped pay for porting the dojo offline library.

Early in the day, when Gears was introduced at the keynote, we learned that Gears would interoperate with Adobe Apollo. This post has details.

Ok, who's left standing here?

True, "interoperation with Apollo" isn't the same as "being Apollo" (Apollo has access to the filesystem, up to the perms that the current user has). But dojo was clearly the frontrunner in offline AJAX, and has held a hegemony in vector graphics and other wicked scripty stuff.

So to keep the metaphor, I see a surprise coup d'etat. And not necessarily a bad one, either. I want to see how this one ends.

Rejected for Individual Health Insurance Coverage in CA? Meet the MRMIP

I keep this blog to tech commentary (and to areas I have expertise in), or software I've cooked up. But I'm writing today about a California-specific health insurance program that guarantees coverage for, among others, self-employed geeks who seek individual health coverage and get rejected.

This is a common phenomenon for those who stray outside the white-picket-fence world of employer-sponsored group coverage. Last weekend I came across another smart, savvy tech pro who got rejected for individual coverage and didn't immediately find info about this critical program. I'm not a big SEO guy, no doubt to the detriment of my traffic volume, but this information really needs to make its way up the Google rankings: for the heck of it I ran a number of searches myself, and info is just as obscure today as it was four years ago when I went looking for help on this issue.

So here's the executive summary:

• California's "Major Risk Medical Insurance Program" or MRMIP is a state-administered program that guarantees certain groups of individuals can buy a health insurance plan from a specific set of private-sector plans
  
  
• This program is mainly valuable to folks who need to obtain individual coverage (i.e. are not eligible for group coverage through an employer, union, etc.)
  
  
• You are eligible if you have been formally rejected for coverage in the last year or if you have been offered coverage at a more expensive rate than the current MRMIP program rates
  
  
• The program addresses accessibility of coverage, not affordability. I.e., it will help you get insured; it will not help you pay for it. Sadly, that means you more or less need some flavor of middle-class income to get your HMO on.
  

Considering this program lives at the unholy intersection of (a) government bureaucracy and (b) health insurance bureaucracy, it is well documented, easy to apply for, and easy to work with. YMMV, but I am speaking from personal experience, having struggled with the "I have no group coverage" problem and being happy with the solution MRMIP provided.

Ironically, once you know the magic keyword (MRMIP) it's easy to Google the rest of the data. But here are some direct links anyway:

2007 program brochure, which includes details on eligibility, carriers, coverage, prices, and the application form. The original is on the state's web site. Here's the program home page.

The program is administered under the auspices of the "Managed Risk Medical Insurance Board." If you're interested in the politics, policy, and future of this program, these notes are interesting.

Two last things worth noting:

First, there is an annual coverage cap of $75,000 on these plans. That seems like a lot of money, but in the US's insane healthcare economy it is very possible to run through that amount if something bad happens. For that reason it is still worth looking at which program offers the most potential care for $75k. I have a hunch that would be Kaiser, though I don't have all the data to back that claim up.

Second, although insurance companies seem to be getting more diligent about investigating your medical history, there may be the temptation to falsify or conceal various bits in order to get coverage, or to get a better rate. Doing so is hazardous.

If you get away with it in the short term, you may get some cheap doctor visits. But if you have a serious illness or injury, where the insurance company is looking at paying big bills, you can bet they'll put a fraud investigator on the case. If they can turn up evidence that you lied on your application, they'll deny your claims and probably try to terminate your coverage altogether. You could fight, but it would be a long uphill battle and not the kind you want to take on when you're already sick or hurt.

Bite the bullet, tell the truth, and if they tell you to get lost, programs like MRMIP can help.

Notebarn Update: Dial Phone Numbers from Notes

Once I gut a bunch of phone numbers in my Notebarn notepad, I started getting frustrated that I couldn't dial a phone number in a note just by viewing the note and clicking on the number. So I've updated the app to include this capability.

If you want this feature, and don't want to read any more geek ramblings, you can go right to the project page and download the app.

I missed this feature acutely because I used to use a Blackberry. On the Blackberry, whenever you come across an email address, URL, or phone number, the device recognizes the format of the text and creates a sort of smart tag. The trackwheel menu gets new tasks related to the data. If you move the cursor over a phone number, the wheel menu will include Call, Send SMS, and, if the number is recognized as matching someone in your address book, clever things like "Send an email to [name]", "Invite to meeting", etc.

It's not accidental that most Blackberry apps support this functionality: the folks at RIM supply classes in their platform API (net.rim.device.api.ui.component.ActiveRichTextField and net.rim.device.api.ui.component.ActiveAutoTextEditField to be specific) that do pretty much all the work for you. Use these classes, and you get this functionality for free.

Despite many strengths relative to the Blackberry platform, the .Net Compact Framework on Windows does not include such a class (at least as of 2.0).

Making this kind of an implementation harder, the Smartphone version of a multiline textbox has a "clever feature": In order to allow multiline textboxes to fit nicely onto a small screen, play nice with directional tabbing, and still accept a lot of text, they have two states. The base state shows one line of text and a little "expand" triangle. You can edit the text, the control responds to events, etc. If you click "Enter", triggering the expansion, the textbox switches into a fullscreen state where you can put in all the text you like.

The problem is that in fullscreen mode the component does not respond to all of its events (it doesn't even fire an event when switching modes), making it very hard to do context-sensitive stuff, such as "look at where the cursor is, extract the nearby phone number, and allow the user to dial it." Which is what I really wanted to do.

I implemented two workarounds instead. When notebarn finds one phone number in the note (using a RegEx that looks like a U.S. number), it adds a "Dial 415-555-1212" command to the main app menu. If there are multiple numbers, it opens a new window with a list showing each number and some of the context around it (so you can tell which number is which). Pick the one you want, and click to dial.

Happy calling!

TechCrunch vs. The Maker Faire

Mike Arrington wrote one of those shot-heard-round-the-world posts today. It wasn't news, but Mike Arrington writing it on TechCrunch was the news. The Valley in a troubling state? Indeed.

It would bum me out a lot more if I hadn't spent this weekend at the Maker Faire. The fair was a beautiful thing. The people and projects looked great; the companies mostly silly. The bigger they tried to look (Yahoo!) the sillier they looked. The more they focused on doing cool stuff (Microsoft... sorta kinda) the better they looked. But really it was DIY anything and everything. The essence of the geek thought process was there, the thought process that makes Silicon Valley work decade after decade: one part science, one part "I bet if I monkeyed with this a little more, it would be really damn cool," and one part "that is really damn cool -- you need a hand with that?"

Robert Scoble already made this connection. But I want to hammer on it a little more. Spend 15 minutes browsing this flickr stream and you'll feel right as rain. It's meatspace stuff, mostly, some fire and robots and yarn along with the software. But the idea is the same, and the membrane between online and offline has never been thinner.

On Saturday, we spent 20 minutes looking for parking and ended up in the far reaches of a dirt lot where some cargo trailers were parked. The event was well attended.

The peninsula has its own cash-driven strain of lycanthropy, never more than a full moon away, but a lot of people here always want to sit down with a soldering iron or scissors or a blank text editor window and put something new and cool into the world.

No Signature Required: It's the New Cash

Banks, credit card companies, startups, mobile phone companies, and whole bunch of other folks have jumped onto "future payment systems" in recent years -- focusing mostly on how to make small day-to-day payments more frictionless. So we've seen a dozen wireless phone wallets that, in the U.S. anyway, aren't very useful. RFID payment experiments at Mobile or McDonalds, and credit cards with chips of dubious value embedded in them.

When I recently found myself hoarding cash because it made certain purchases easier than using a credit card, I thought a little bit about the ease-of-payment problem. I came up with the following equation:

Ease(CreditCardPaymentNoSignatureOrPIN)
>= Ease(LoyaltyCard)
>= Ease(CashWithNoChange)
>= Ease(CreditCardWithSignatureOrPIN)
>= Ease(CashWithChange)

In English? The easiest game in town is swiping your card (or handing it over) and walking away (well hopefully you get it back). No signature, no PIN, no touchpad. Where does this happen? Starbucks and 7-Eleven are among the merchants supporting the Visa No Signature Required program for amounts under $25. It's a beautiful thing -- I can't imagine any easier way to pay, and I used to work on some of those RFID systems. At best they match this experience, but they can be much worse. The credit card gives me near perfect fraud protection, an itemized bill, and a short-term zero-interest loan.

A lot of businesses (Peets, Subway, etc.) haven't hopped on the bandwagon though, I suspect because the fine print is higher pricing on the back end. They'd love to avoid and card fees if they can, and they're happiest when they carry your cash for you. So they sell you a stored-value card and in exchange for letting them keep your interest and unspent funds, you get a swipe-and-run experience. This approach also has the drawback of requiring an extra card for each vendor, more of a hassle than pulling out a single Visa card.

After this, a cash transaction where no change is involved is fast and painless. You can pay and run, and cashiers love not having to count or give out change. Pricing in round numbers (think parking garages or ballparks) eliminates most change. Much is made of the supposed "anonymity" of cash. But that argument applies only to illicit transactions. Any transaction you do in person with an established business is bound to be on camera and timestamped these days, so you can be tracked even if you pay in cash.

Then you have credit card purchases with a signature or PIN -- my principal method of payment. This sounds easy until you're handed a card and a receipt to sign and return at a parking garage on a windy day. Aaaargh.

Lastly there's old fashioned cash with change: pain for all involved.

The big opportunity here is for banks and other credit-card issuers to cement their lead in the payment industry by pushing hard to expand the No Signature program. As it is, there is vastly improved data transmission infrastructure compared with what existed when credit card protocols were designed. The Obopays and Speedpasses, not to mention alternative credit card entrepreneurs are all over it. But the same data infrastructure could let Visa vastly extend No Signature without the fraud risk this would once have entailed.

Flight Data Button 0.5 for Outlook

I've spent a little time working on an Outlook add-in for putting flights in my calendar. A few weeks back, I took a trip and wanted to be able to pull up flight status on my phone, without keying in an address and surfing, or installing an app like Skip. (Skip is great, but was never fully implemented for Smartphone.)

So I put my flight into Outlook as a calendar item, and put a link in it to FlightStats Mobile, for my specific flight. FlightStats is the premier flight data provider in the U.S. -- many airport flight boards actually get their data feeds from FlightStats. Now, when my phone syncs with Exchange, the flight item comes onto my phone along with a quick-click link for status.

I decided this is a useful thing to automate, since any system that syncs Exchange to a device (DirectPush, Blackberry Enterprise Server, Moto/Good) would carry the link. But I was frustrated that I needed to key in the flight times, and I realized that should be automated too. To top it off, I foolishly ended up booking an appointment during time I needed to be driving (but which showed "free" in my calendar) -- so I figured my "automation" widget ought to add the travel time to and from the airport, and the time waiting at the airport before departure.

Using OpenKapow, I built a web service that scrapes flight schedule data. Assembling a FlightStats link is almost straightforward (getting to the individual segment within a flight number turned out to be tricky). And integrating to Office is delightfully simple thanks to great templates that take all the work out of it so a lazy sod like me can just write business logic.

I've called the addin "Flightify" since, to use it, you select an appointment in your Outlook calendar (where you've previously stuck some basic flight info), click the button, and the plug-in "flightifies" the appointment.

Here's an example: you start with basic info like this:



Click the button, and select the additional calendar items you'd like:



And a few seconds later your calendar shows the sad reality of your travel day:



You can't see them, but the mobile links to realtime flight status are embedded in the body of the flight item, so it's ready-to-click on your phone.

Here's the project page with the download/install if you want to try it. Full source code is there too.

I wanted to make this more of a learning experience and use the Outlook Addin templates that ship as part of Visual Studio Orcas Beta 1. I could try out more of Orcas and easily produce both an Office 2003 and Office 2007 version of my button.

Unfortunately, the Orcas Beta includes project templates, but not all of the Interop Assemblies you need to build the project (Office COM libs are required as well). So to get it building I would have needed to install Office on the Orcas test machine (in my case a VM with limited resources, meant for testing VS CTPs). My recommendation to Visual Studio team? Ship stub DLLs that implement the relevant COM classes (perhaps they just log calls to a file) and all of the Interop Assemblies. That way, the machine where Orcas is running doesn't need to have Office installed and can still successfully build these Office project types.

A few final thoughts on the plug-in:

• Since the web service calls run in the main thread, Outlook will freeze for a second or two while they're being made. Considering that Outlook freezes the UI thread all the time while doing its own built-in tasks, I didn't put a lot of time into a proper workaround.
  
  
• I don't write a lot of Windows Forms apps, so I was pleasantly surprised that the snap-band positioning logic in the form designer allowed my dialog box to appear the same on both a standard and high-DPI display without my having to do anything special.
  
  
• The automagical "Setup Project" builder was also great. I didn't really have to do anything, and it produced a nice exe/msi install, that includes registering my addin with COM via RegAsm.
  

OpenKapow Fun: Scraping an AJAX Site

I'm interested in web services which represent operations that make a persistent change in the non-web world. Like buying a ordering food or checking in for a flight. These capabilities exist as human-powered web workflows today, but rarely as remixable web services. Sooner or later, that's going to change.

Many of these services resist initial attempts at scraping and remixing because they contain AJAX elements such as scripts that rewrite the DOM. Scraping such a site is more than a little challenging, since you either need to analyze exactly what the scripts do and try to grab and run just the scripts you want, or else you need to emulate a Javascript enabled browser and then scrape the screen when the script is finished and the DOM is in the "right" state.

One tool that seems promising in the quest to tame these sites is the openkapow service host and its Robomaker IDE, which both work by hosting a Javascript-enabled browsing engine. The IDE combines this engine with a set of tag-finding and flow-control tools so that you can point-and-click your way to a script that automates the target site.

I've been looking for an excuse to build something transactional with Robomaker, and I hacked up REST services that execute a checkin or an offload ("un-checkin") for a passenger on a United Airlines flight. It worked for me on a couple of flights. But without having a large sample of itineraries that I could abuse in the testing process, I was a little uncomfortable with how the robot might handle some multisegment flights. The source (".robot" XML files) are available here though if you want to try it out or tinker. Seat selection would be an interesting and nontrivial feature to add...

So I reined in my ambitions a little and created a service to get flight schedules, in order to add automation to a small Office 2007 tool I'm working on.

The Airwise flight schedule page seems simple enough at first glance, but turns out to be one of those pages that uses script to write the DOM data that the user ultimately sees. That makes it a perfect candidate for ... RoboMaker!

It was straightforward to configure my robot to enter travel dates and airports into the form, click "go," and find the table with the results. What I wanted to do was look through the table rows, create XML snippets for the data, and package them up into a response.

But here's where my inexperience with RoboMaker and impatience got the best of me: once I got beyond the point-and-click part of automating the web page, I wanted to just write some imperative code to pack up my XML. Since RoboMaker is a Java app, I wished I could just write a micro-plugin for this stage of my robot in Java. I found the deep spelunking in dialog boxes, squirrelly regular expressions, and mediocre help docs to be frustrating.

Maybe the idea is to give me a taste of Kapow so I'll license their enterprise technology, which isn't free. Not sure about that. But I did know that I could dump the entire flight schedule table as the service response and deal with it on the client. So I selected to return the whole table content as "advanced structured text" (which basically translates into plaintext with newlines in between every table cell).

Although on the client it's trivial to parse the resulting data set and find what I want, I feel a little guilty about the ugliness of the XML response. You can view/use/download/edit the REST robot on the openkapow portal, and if you run it with the defaults you can see the mildly embarrassing chunk of XML produced (in the browser, the newlines in XML are ignored, so it looks even worse). A REST call looks like this.

I got over my issues with the service, though, and moved on to using the data for my Office plugin, which I'll post about soon.

Interaction Sequence Diagram for Google Web Toolkit

I've been doing some work with Google Web Toolkit. GWT is based on a cool model where the client-side and server-side code are both written in Java. The client-side code follows certain API guidelines which allow it to be compiled to optimized Javascript by GWT. Among the APIs that can be used is a pattern for asynchronous remoting, so that AJAX calls can be made and received in Java, with Java objects as arguments and return values (a bit like RMI). The marshaling and unmarshling, JSONizing and the like is done automagically. Nikhil Kothari has a similar technology on the .net side that lets you code client-side Javascript via C#. It is called Script#.

This model has a number of major strengths. But one weakness is that is not common, so it is not immediately familiar to developers. The interaction pattern can seem a little mysterious even with Google's doc set, debugging tools, etc. It gets more interesting when you consider that you might also be generating the original pages (the ones with AJAX interactions on them) via Java. (GWT does not require a dynamic page generation scheme at all, and can use static HTML.) In order to make this clearer, I wrote a sequence diagram which I'm posting because it may be valuable to other developers getting their heads around GWT.

The diagram shows three interactions. First, I'm generating my initial pages using the FreeMarker templating system. There are lots of other ways (like JSP for example). But here I'm using FreeMarker. This all takes place before GWT gets involved in the pages.

Next, I show how the GWT scripting gets running and loads the page specific code which will rewrite the DOM. At the end of this, the page is rendered the way the user will see it in the browser.

Last, I show how an AJAX interaction flows, including a call to an external web service on the back end -- e.g., if there is a "Load My Favorites" button on the page that results in a call to an external service and asynchronously returns with data to bind into the DOM.

I hope it's helpful. If I've left anything key out, let me know.

Click to enlarge / view:

Lunchrtime on Mobilecrunch

I was psyched to fire up the newsreader tonight, pull the latest mobilecrunch stories and see my own "mobile 2.0" food ordering site, lunchrtime, as the top story.

Photoshop notwithstanding, I can't resist including a screenshot while this is still the latest mobilecrunch post.



What? Why? ... check out the about page. Is this going to be the next twitter? Probably not, but if the AdWords revenue covers the cost of the web services, I'll be pretty happy. If you like it, have fun, and maybe add in some restaurants near you.

Meantime, if you're up for some geekery, one of the things I loved about building the site was leveraging so many pieces of the asp.net platform to make it a little less code, a little more action with a very small amount of effort.

The entire app includes only around 300 lines of code and some markup. The total time to build, including the user-facing functionality, some quick admin bits, and the micro cms that I use to upload and serve pages with scanned menus like this? something like 70 hours. Total. It doesn't look as slick as it might, but if you've read this far you know I'm a developer and not a designer.

Here are the (mostly) asp.net pieces I used so I could be lazy, do my day job, and get this running:

• Built in Users and Roles infrastructure
• Built in Login widgets and automagic password reset by email for above
• Built in User profiles
• Asp.net Master pages
• Asp.net AJAX
• Mobile Web Forms adaptive rendering technology (needed a tiny bit of massaging, but there's an easy pattern for that too)
• Practically-writes-itself code to mash in SOAP services
• and REST services
• HTTP handlers for serving arbitrary data or acting as AJAX service endpoints
• SubSonic Data Access Layer, aka ActiveRecord on .net, so no database code
  
• FreeTextBox WYSIWYG HTML editing (I can't wait for 4.0 with the legendary Safari support)
• Flash
• Yahoo Maps Javascript API
• Asp.net hosting with SQL Server 2005 for under $10/month

It's a blast -- I really don't feel like I need to do much besides wave the baton, and all this stuff just comes together and starts playing in Visual Studio.

There are a bunch of solid web platforms out there today aside from asp.net. But anyone who thinks .net is somehow cumbersome, un-agile, un-fun, or not suitable for rapidly building and modifying a modern web app should really log out of the groupthink.