Thursday, March 29, 2007

NetBeans 6 m8 and Ruby: Get Yours Now

As of yesterday, NetBeans 6.0 milestone release m8 is out.

Having known NetBeans since its very early days, I'm surprised and excited that it seems to be a serious come-from-behind competitor in the contest of world-class IDEs.

Besides the core Java IDE elements, the platform is being pushed in a bunch of ways. My favorite at the moment is the Ruby support (which works with JRuby or the regular Ruby interpreter). The team has feverishly added a bunch of debugging features over the last few weeks, and the latest Ruby-support builds snap in nicely with the m8 release. (Some of the recent IDE builds didn't snap together quite so well.)

Here's a quick screenshot showing debugging stopped at a breakpoint, with all the goodies you'd expect -- stack trace, local variables, etc.

Fun stuff! At least for IDE junkies like me.

I had been watching to see where Ruby IDEs would come out... the "free Ruby IDEs" are, well, no offense, but they're awful compared to stuff like Eclipse and Visual Studio. Arachno Ruby is better, but I didn't love it when I tried it.

I've been using a trial of the SapphireSteel's Ruby In Steel, which is built on Visual Studio. Ruby In Steel is amazing, and I consider it the first really world class Ruby IDE. But it requires VS2005 Standard edition or above, which means money and a Windows box, both of which I believe will be impediments to longterm success. The money thing is sad, because the SapphireSteel guys seem wicked smart, and it's a bummer that we're living in an age where they probably can't/won't get away charging $200 or $300 per seat for this package. But with Eclipse, NetBeans, and Sun Java Studio Creator being free, and Microsoft's Empower prorgam giving away the farm (a.k.a. MSDN) for under $400 to legitimate startups, it's rough.

This NetBeans add-on is at the head of the pack. It's a really nice piece of work and clearly (read the changelogs) there's a ton of energy going into it. Nice work!

Another ASP.NET Adaptive Rendering Tip

For the background to this adaptive rendering thread, you may want refer to this previous post.

It turns out that in .net 2.0, the base "Mozilla" rendering profile sets the cookies capability to false. Why would it do this? Well, specific mozilla-derived browser profiles turn the setting back on, so it's not like thinks Firefox won't support cookies. Here's a clue, in the comments at the top of the mozilla.browser config file, showing some sample user agent strings that would match:

<!-- sample UA "Go.Web/1.1 (UP.Browser/3.1-UPG1 UP.Link/3.2; Mozilla/1.0; RIM957; Elaine/1.0 )" -->
<!-- sample UA "Mozilla/1.0[en]; Go.Web/1.1 (compatible; MSIE 2.0; HandHttp 1.1; Palm)" -->

Some old school mobile browsers were the targets here. Unfortunately, if users come to your site on, say, a Samsung Blackjack or another new device running WM5 and PIE, they end up in the same bucket. You can sniff this out by logging Request.UserAgent, Request.Browser.Browser, and Request.Browser.Type. I highly recommend doing this at least on one "entry" page for any mobile site. You may also want to log the computed capability for an attribute your app needs, like cookies (Request.Browser.Cookies).

Even though will automagically try to do cookieless sessions, I want to force cookie-based authentication on my mobile site so that users don't have to sign in every time they visit (those extra key presses are brutal on a phone). I know that more or less every mobile browser out there can support cookies now, so I'm not too worried about this decision.

The fix? Similar to the others, we'll just override this one attribute in our supplement.browser file:

<browser refID="Mozilla">
<capability name="cookies" value="true" />

Another free bonus is that with cookies, doesn't have to do the URL mangling that is involved in cookieless techniques. So your users get URLs that make more sense in their history and work properly as bookmarks!

Yahoo Mail API Misses the Point

Within the last day, Yahoo has officially released the web service API for mail they demo'd at Hack Day last year. Earlier in the week, mailbox storage limits were removed. Everyone seems to be cheering, and talking about the obligatory Flickr mashup.

Before we get too drunk on champagne, let's take a look at the details. The API only allows retrieval of the mail message body for Yahoo Mail premium subscribers. This correlates to their policy of allowing POP/IMAP access only for premium subscribers too. They are missing the whole point of an open API here. There's only so much I can build if I know that Yahoo mail basic users (i.e., most people) will have degraded functionality.

The Yahoo motivation is, of course, to drive people to the web site to get their mail, where they can be exposed to ads, which keep Yahoo in business providing free mail. Ok, cool. But why not use this opportunity to explore some alternatives that keep the revenue coming, but allow Yahoo to really open the data service up, instead of having this silly $20 tax (i.e. "premium") on people too lazy to switch to a more open free service? (User inertia is a dangerous business model because it exhibits "tipping point behavior" -- one day, everyone's too lazy to switch and the next day all your best users are gone.)

So what are the more imaginative approaches Yahoo could have taken? Well, for one thing they could continue to insert text ads, or even image ads into mail sent or retrieved. They could specify terms of service that require another app (say a mail client or another web site) to display certain ad items when using Y! Mail content, or else risk losing developer key access.

They could innovate further by creating a loyalty program across Yahoo properties that informs whether a user gets certain service levels: for example, if I have lots of My Yahoo page views, or I click a lot of ads there, or I buy a ton of stuff from Yahoo Stores businesses, shouldn't that count for something? Certainly this sort of user is different from a freeloader who hypothetically never views a Yahoo web page, and just sucks his mail down into Outlook. How about if I have a full demographic profile in Yahoo, and I leave myself logged in with a persistent cookie, and I use Yahoo search a bunch ... thereby providing Yahoo a wealth of data that should raise the value of ads shown to me?

C'mon guys ... if you don't do it, someone else will.

Wednesday, March 28, 2007

Opera Mini as Abstraction Layer

Opera Mini is a free J2ME-based browser from the folks at Opera. This FAQ tells you how it works and this demo lets you try it. I've spent some time using it on my old Blackberry 7250 and it's a pretty impressive browser &em; far more capable than the built-in browser on the Blackberry (although that's not saying a whole lot). How does it work its magic? The J2ME client handles user I/O and screen rendering (including a fabulous small antialiased font that is built into Opera); the page rendering, on the other hand, is offloaded to Opera's servers.

Since latency is the bane of even the fastest 3G networks, having extra proxying in the path makes the actual go-to-page browsing way slower than usual for a mobile. On the other hand, you have that warm feeling that practically any page, even moderately AJAX-y ones, will actually render attractively and usably when they do show up. Contrast this to the Blackberry browser experience, where the data starts coming down very quickly, but the device spend 30 seconds thinking about how to render it, and then ultimately produces something barely usable. Since subsequent navigations seem to perform better than initial ones, I suspect the Opera server is chasing forward links and preparing them while you read the first page. Not a bad plan.

I started wondering: Would Opera Mini serve well as a "base platform" abstraction layer for mobile web apps? If I code to O.M., and I can expect to be able to run unmodified on handsets all over the world, there's significant value in that.

What are the costs of such an approach? Hmm... let's see...

  • Like all abstraction layers (Win32/POSIX/.net/...), the end user has to get it up and running. Sounds easy, but ask anyone who's ever wanted to deploy a "lightweight" .net or Java app and assumed users would already have the runtime ready to go...

  • Opera has a done a lot of heavy lifting, but what if they change their browser capabilities, and now there's another fragmented set of clients, just a layer up the stack?

  • Like all abstraction layers, there's a performance hit. In this case it's twofold: the memory and CPU usage of the Java runtime hits some devices pretty hard, and the proxy-through-Opera network access is painful even on EV-DO

In the end I think I'll take the weaselly way out for now. I wouldn't go all in, build an app, and say to the user "Opera Mini is a pre-requisite for this app. If you get it, you're golden; if not, no support for you!" I'd target a base of browser set with some kind of adaptive rendering. But I might well make Opera Mini the first-tier tech support response for any native browser problems.

Saturday, March 17, 2007

The Eagle has Landed at 601 Townsend St.

I spent last night at Adobe's Apollo Camp. The Apollo Camp was about exposing a group of developers to the (almost) latest build of Apollo; introducing some partner apps and the insights and clever tricks these apps have already spawned; and letting us meet, chat, question, and occasionally argue with the guys who build Flash, Flex, and Apollo.

Since this is a commentary blog, I'll let the tech news blogs cover all the great content that was presented last night. Much of it is probably in the blogosphere by now; a lot more is due to be released by Adobe via Labs very soon.

Apollo is going to be an important and prominent platform. It's not perfect (Adobe certainly doesn't claim it is right now either), and the truth is it doesn't actually do all that much. But it is a kind of fabulous connective glue for the front end. Metaphorically it reminds me of OLE/COM/ActiveX in its desktop ambitions. It's not defined to be a desktop object bus per se, but it's way easier to use, and it's cross platform. It is also reminiscent of web services and RSS in the middleware realm, in that it provides a connective mechanism simple enough but expressive enough to throw the door open for all sorts of creative mixing and mashing and integrating fun.

It's interesting that we're at this juncture with Adobe/Macromedia poised to leap into the RIA lead with this tech. Credit is due to some long-range strategic thinking. For example, we were told that Flash player has for years now been designed as an express install vector for Apollo. And moving to from AS2 to AS3 reminds me of the bold but necessary move from VB6 to that Microsoft took in '01.

More than a little is owed to luck, or lucky timing, as well: without the evolution of Agile and TDD, leading to effective development practices with dynamic languages (and popular day-to-day AJAX, Ruby, and Flash apps as a result), it would be hard to imagine a bright future for desktop apps built on ActionScript. But these things have come to pass, and AS3/Flash9/Flex/Apollo/Tamarin has shown up at just the right place, and just the right time.

Tuesday, March 13, 2007

Making Mobile Browsers Work Better with ASP.NET

ASP.NET is architected with a robust scheme for adaptive page rendering. This scheme allows "server controls" or metamarkup to be rendered appropriately to various browsers, and becomes particularly important when using the mobile web controls.

For an overview of how this works, take a look at ASP.NET Web Server Controls and Browser Capabilities (from MSDN/Visual Studio '05 docs)

There are also numreous ways of overriding this framework, from code (Page.ClientTarget) to XML config files, to defining new browsers, or altering attributes of the browser configurations that ship with the framework.

Modification is critical for mobile web development, because the device data that ships with ASP.NET 2.0 doesn't include any of the wireless devices shipped in the past two years or so. (For a list of what is included, check out this list and walk down memory lane)

Since most users of mobile applications will be carrying a device built in the last 2 years the built-in browser profiles will not cover current customer devices. The good news is that the browsers in these newer devices are more advanced than the earlier browsers, and make a credible attempt to process xhtml and javascript. So less divergence from a "basic desktop browser" profile is needed to address these clients.

Here is what I did to handle some problems with newer Motorola and Nokia devices:

If the framework cannot come up with a positive match for the User Agent string to either an individual browser definition or a family of browsers, it is bound to the "default" profile and identified by the name "Unknown"

All major desktop browsers are correctly identified, whereas many (maybe most) late-model mobile browsers are not identified. So if the browser is identified as "Unknown", we'll assume it's a new mobile device.

The framework will render for a base desktop browser, which works pretty well. But certain postbacks cause a processing error which can be circumvented by altering the "default" profile and adding the attribute "requiresPostRedirectionHandling" right into the default definition. Rather than editing the files that ship with ASP.NET (which may be impossible in a shared hosting environment anyway), the preferred approach is:

1. Add the special "App_Browsers" folder to your ASP.NET 2.0 app
2. Add .browser file to that folder -- mine is called Supplement.browser
3. Add the attribute into an XML element that specifies this should modify the existing default definition. Here's how the whole file looks:

<browser refID="Default">
<capability name="requiresPostRedirectionHandling" value="true" />

The refID attribute refers to the Default definition that you can find in [WINDIR]\Microsoft.NET\Framework\[VERSION]\CONFIG\Browsers

For my application, this fix got my app running great on the MOTO RAZR devices, where I had experienced a number of problems before.

4. I also wanted to target newer Nokia phones. They have a family of browsers which are identified even when the individual phone model is not. So I added this element inside the 'browsers' tag to fix the Nokias:

<browser refID="Nokia">
<capability name="cookies" value="true" />
<capability name="preferredRenderingMime" value="application/xhtml+xml" />
<capability name="preferredRenderingType" value="xhtml-basic" />
<capability name="isColor" value="true" />
<capability name="requiresPostRedirectionHandling" value="true" />

As you can see, I noticed that these devices are xhtml capable, but the Nokia default profile was sending them WAP content. I also pointed out to ASP.NET that these devices take cookies, are all color, and handle redirects differently from desktops.

I'm sure I'll find more issues and more fixes, but these have made a big difference once I figured them out.

Incidentally, save yourself a lot of pain and do not rely on either Motorola's ADK emulator or Cingular's online (ActiveX) emulators to test web content on these devices. Many difficult bugs appeared with these emulators, but on the actual devices, everything worked great. Nokia's emulator/SDK on the other hand was pretty solid and very helpful.

Thursday, March 08, 2007

I Have a New 6-lb. Cellphone

I was traveling last week with a pretty decked-out Thinkpad T60p, and decided it would make a great smartphone. It's got a huge screen, a 512MB 400MHz ATI graphics card, 2 GB of RAM, happily runs a few VMs, development tools, databases, and DVD-quality movies all at the same time. It runs 5 hours on a charge while doing that, can idle in sleep mode for days, and stays on the network with integrated WiFi and EV-DO.

Last time I checked, smartphones don't do any of that stuff, and if you continually use them to access data, their batteries will not even last 5 hours.

So crank up Skype or Gizmo Project and it's a heck of a phone.

And yet ... at 6.5 lbs, and a foot across, I'll get some odd looks when I clip it to my belt.

Where am I going with all this? there are two things we need here:

First, a new BIOS-level powersave mode that lets me receive calls -- routed to a Bluetooth headset -- when the laptop is sleeping, maybe even with a satellite UI ... wait, someone had this idea, it's called Vista Sideshow. So I'm asking for a Vista Sideshow VoIP phone gadget.

Second, a more flexible way to link multiple telephony devices to a single phone line. I want my Sideshow PC phone and I want a $49 cellphone that I can carry around when I don't want to carry the PC -- and I want them on the same number. And I'd like to link my Blackberry onto that number too, so I have my choice of high productivity, high voice quality, or a compromise. I'll bring the hardware and the subscriptions. Wait! My second wish is already coming true. It's called GrandCentral.

Now let me get this all rigged up and I'll report back.