24 October 2008

Mobile Internet World was tiny!

I swung by the Yankee Group's Mobile Internet World show in Boston yesterday to check out what was going on. Google's Rich Miner, the head of the Android effort, was doing a Q&A at 2 pm, so I figured I'd see what folks were asking him and check out the vendors on the show floor.

The show was tiny! Boston has two convention centers and when I arrived at the BCEC, things were so quiet that I was worried I was at the wrong one. I eventually wended my way to the back corner where the show was being held and found the show floor. There were only a couple of dozen vendors present and only three of those had anything other than the tiny pipe and drape style displays. I bumped into Derek Speed who I knew from Digital Semiconductor showing off the Moblin SDK for Intel, which was fun, but other than that it was pretty disappointing.

There were perhaps 80-100 people at the Google Q&A (or about 25-30% of the turnout that they had for their developer day in Cambridge last year). In addition to Rich Miner, they also had Justin Mattson from their developer program there to answer questions.

Nothing earthshaking was revealed in the Q&A. Rich said that the early reviews from the media were at the high end of the range of what he thought was possible. He was also pleased with the T-Mobile pre-sales. As for futures, he thought they could do a better job with integrated search (phone + web) and multi-modal search (voice), but didn't say anything about when/if that would be improved.

One thing that I missed before was that the App Market popularity would be computed on both downloads and usage, so they must be uploading usage stats. Rich said there was no plan to expand the app market to content types other than apps because it wasn't a profit center for them.

If they have the show again, I'll definitely look more carefully at the exhibitors list before deciding whether it's worth even an hour or two.

Building Google's Android on 64-bit Linux

This week Google released the sources for all the open-source components of Android including the kernel, the frameworks, the SDK, and most, but not all, of the bundled apps.

My laptop is a dual boot system that mostly runs Windows, but Linux and OS X are the only supported Android build environments, so I fired up Linux (64-bit Ubuntu 8.04 Hardy Heron). Things don't quite build out of the box for 64-bit Linux, so here are some tips to get you going.

In addition to the dependencies listed at http://source.android.com/download#TOC-Linux you'll also need the following:
$ sudo apt-get install ia32-libs g++-multilib gcc-multilib lib32z1-dev lib32ncurses5-dev
There's an additional problem with a missing softlink to the 32-bit version of the X11 client library that you can resolve as follows:
$ cd /usr/lib32
$ sudo ln -s libX11.so.6 libX11.so
It really ought to be included in one of the standard packages, but doesn't seem to be on Ubunto (the shared library itself is included in ia32-libs however).

Follow the rest of the directions on the Android site to install their repo tool (and git if you don't have it), fetch sources, and then do
$ cd ~/mydroid (or wherever you put things)
$ make sdk
to build your own shiny version of Android from scratch. This took over an hour on my laptop, so be patient. When it's finished, you should be able to change to the results directory and running the freshly built emulator
$ cd out/host/linux-x86/sdk/android-sdk_eng._linux-x86
$ tools/emulator
You should see an Android emulator window pop up on your screen running your freshly built code.

17 October 2008

What's wrong with UML?

The catalyst for finally starting a blog was Kenn Hussey's post about What's Wrong with UML... I wanted to contribute to the discussion, but my comments would have been way too long for that little tiny comment box.

Apparently the Object Management Group (OMG) has asked its members to come to the next meeting with a list of their top three things which are wrong with UML. Wow! Where to begin?

Without meaning to criticize Kenn, because I think he's done more than almost anyone to help open up UML and the OMG process, I think his list is made from much too much of an insider's perspective. Here's his list:
  1. Un-intended inheritance
  2. Undefined namespaces for standard stereotypes and primitive types
  3. Inability to create a usable XML schema for UML
Let's take a few giant steps back here to get a little bit better view of the problem from the point of view of a UML user. As someone who's spent years working on an open source UML editor where I actually have to deal with users who are affected by this problems as they try to do their work, let me give you my list:
  1. Lack of Interoperability
  2. Incompatibility
  3. The OMG
Let's take a closer look at each one.

Interoperability - The dirty little secret of all the UML tool vendors is that there simply is none -- and no one cares. I could go on about XMI this and MOF that, but let's start with the basics. UML is a visual/graphical modeling language. There is absolutely no way to interchange the graphical representation. WTF? With a little bit of luck, a consultant who's got a bag full of XSLT scripts, and two tools that don't stray too far from the spec, you might be able to get the semantic contents of your model across from one tool to another, but what about all those diagrams that you spent days and weeks slaving over? All completely gone. You'll need to redraw them from scratch. Sure, a spec for UML Diagram Interchange was promulgated (six or seven years after the initial UML specs were released), but no one's implemented it and the Eclipse folks have said that they consider it unimplementable so they're going to work to get their own standard adopted instead.

Even if we just look at the semantic contents of the model, as serialized in an XMI file, interoperability is very dodgy. Different tools have different bugs in their XMI reading/writing code which don't get fixed, vendors use proprietary extensions, and different tools implement different versions of the spec, but the biggest problem is that there's no systematic focus on improving interoperability. It's been broken so long that people don't expect it to get fixed. Each customer is own their own to fight with their own specific vendor and the vendors believe they have no incentive to fix the problems since it helps guarantee vendor lock-in. (They're wrong in their belief that this is to their economic benefit, but that's another story).

Compatibility - I mentioned different tools implementing different versions of the spec. Why is this important? Because the OMG has paid absolutely zero attention to compatibility between versions. UML 1.5 is the only version which was a pure superset of the previous version. In every other release, they've made incompatible changes at multiple levels of the specification. Not only have they changed the language itself in incompatible ways, but they've incompatibly changed the metamodel that's used to define it and the file format that's used to serialize it. Two tools which both implemented UML 1.3 wouldn't be compatible if one serialized using XMI 1.0 and the other serialized using XMI 1.1, let alone if one implemented UML 1.3 and the other implemented UML 1.4

This has an obvious negative effect on interchange/interoperability, but it has impacts throughout the modeling ecosystem. Vendors waste engineering effort reimplementing things just to conform to the new specification. Customers have to upgrade tool chains in lock-step and may not be able to upgrade at all if even a single vendor lags. Downstream standards groups working on modeling standards for bioinformatics, finance, or health care have to either freeze on an old standard as their basis or let the incompatibilities ripple downstream to their consumers.

UML 2.x deserves a special mention here because it is such a massive dislocation in the time/space continuum. In addition to the normal changes in the layer above (MOF) and the layer below (XMI), fundamental concepts of the UML itself were completely thrown out and reinvented for UML 2.x. These changes were so extensive that the OMG didn't even attempt to produce a change-barred spec or keep a comprehensive list of them. Instead entire sections will have a tiny little note at the end that says something like "This concept from UML 1.x has no equivalent."

Object Management Group (OMG) - This is probably going to seem harsh, and since they're local, I may even have friends working there, but I believe both of the problems above, and many of UML's other problems, can be traced back to the OMG and how it works. I'll reserve detailing the problems for a separate post, but they can be summarized as:
  • Industry trade group, not a standards body
  • Don't eat their own dog food
  • Closed to participation by individuals, (most) users, and open source groups
  • Too slow
  • Too fast (ie not careful enough)
More on the OMG in another post.

As far as UML goes, there are any number of problems which could be enumerated, but if the interoperability nut could be cracked, they could build the momentum to address the other problems.

UML has been around since 1999 and its whole raison d'ĂȘtre is to be the lingua franca of the modeling world. Why not make it a goal to actually achieve this aim before the 10 year anniversary rolls around?

Obligatory first post

I put up my first web page back in the 90s, but I've resisted blogging for years, partly because I'm anti anything that smacks of being hip and trendy, and partly because I was put off by much of the style of the so called "A-list" bloggers -- you know, the ones who post six times a day, consider their words to be equivalent to those engraved on the tablets handed down from the Mount, and write articles which consist solely of things like:
"This is cool."
Cool in what way? Rad windsurfer cool or nerdy cool or script kiddy kewl or ...? You really couldn't write five words to describe why I should follow that link? Having been a software architect for much of my career, I'm pretty familiar with the whole "Terse == Knowledgeable" theme, but I don't buy into it. To be fair most of the tech blogs, at least the ones which aren't about blogging itself, do better than the standard A-list genre.

Dan Bricklin's blog is one that I've followed for years and is pretty close to what I aspire to. He only writes when he's got something to say and the posts are spaced out enough that I can keep up without having to check three times a day. If I've got real work to do for a day or three, I won't have to catch up on eighteen new posts. It helps that he's interested in a similar range of topics -- software engineering, the business of software, intellectual property, open source, photography, etc. Brough Turner has a similar blog in different technology space, principally focusing on mobile, but more generally all types of communications. One thing that they both do well is tie technology to its business and social context so it's not a pure geek fest.

If you catch me backsliding by posting drivel or using oh-so-trendy terms like blogosphere, feel free to send a cyber-slap my way. My one nod to blogging culture is to choose a faux-edgy blog name which is a play on my initials and the popular engineer's retort RTFM (Read The Fine Manual) from back in the days when users had manuals printed on dead trees. Not a very original idea, of course. That URL on Blogger was taken ages ago and hosts, like so many others, a place holder blog.