David's Computer Stuff Journal

One of the interesting things about Google's Android project is the mix of cultures.

There are a number of people like me, firmly grounded in the open source world, who are happy to get something that 1) works, 2) looks to have legs in terms of popularity, and 3) will be open source. Think of a lot of your favorite open source projects when they first launched. "Polished" isn't a word you would probably use to describe them, although it usually happens in later releases (Ubuntu looks better and better, for example).

There are also a lot of people who come from a 'commercial' background, who expect to see everything ready and waiting on a plate for them, which isn't a mistaken expectation if you're used to using products from big companies who are staking their reputations on them. They want nice, thorough docs for everything, almost all bugs worked out, and lots of easy to use tools.

Android lies in a middle ground somewhere between these two camps, which I think at times makes people uneasy.

It's not open source yet. You can't hack it as much as you may want. You can't rebuild it from the ground up. You don't get access to the communication between the developers working on it, and cannot participate in that development. However, there is a promise to open source it that would reflect very, very poorly on Google were it not met and is therefore pretty credible. The developers and many people involved with it certainly seem to "get" open source, and are taking good steps to create a community around Android (a few even hang out in the #android IRC channel on Freenode) that will most likely not take too long to start assimilating interested outsiders once the code is open. In terms of quality, it wasn't bad when it came out, but it was very definitely an "early look", put out there to solicit feedback and change according to it, something that's part and parcel of a release early, release often open source model.

On the other side, Android looks to be a big effort from a big company to get into a big market in a big way - it's not a "under the radar" type of strategy that the open source world is often constrained to follow for lack of monetary and marketing resources to do it any other way. This has attracted a number of developers who either don't see or don't really get some of the "open source" aspects of what we have so far: it's still changing! The docs aren't complete! The emulator is still ugly in places! And from their point of view, it must seem odd to getting something that's obviously not a finished product, without crystal clear direction and goals and a roadmap, and without actual hardware only available in the distant (well, in internet terms! - 8 months or so) future. That kind of thing probably isn't done very often in their world, or where it's done, is certainly kept quieter and perhaps restricted to registered developers. They came over to have a look at something that was ready to go, and it isn't, yet. This has caused some disappointment for people who expected to see something ready to go out of the box.

Perhaps Google needed to manage their initial communications slightly better in order to manage the second group's expectations more carefully. In terms of us open source folks, I think that what we want is more access, as soon as Google is willing to hand it out. More source code access, but also access to the development process and people. "Real" open source isn't just about the code, it's about being more or less equal participants in a community. Luckily, I think the people at Google get this, which is one of the reasons I'm enthusiastic about Android, even if I wish we didn't have to wait so long for the source code.

Here's one way of having a look under the android hood:

mkdir /tmp/android/
cp .../android.jar /tmp/android
cd /tmp/android
unzip android.jar
... lots of files unzipped ...
for c in `find  android/ -name "*.class" | sed -e 's/.class//'`; do nice javap "$c" ; done > androidclasses.txt

That gives you a nice dump of all the classes available. It's a useful way to get an idea of some of the under the hood capabilities of Android. Perhaps someone wiser in the ways of Java hacking can suggest even better ways of accomplishing the same thing.

Of course, anything that's not officially documented is liable to change!

I whipped this up as a quick Sunday project. The code is based on dims' code here.

Its translations aren't great, but would probably do in a pinch. They'll likely improve as Google improves its translation bots.

I also used it to to test out Google's code hosting, which is quite nice. The code is located here:

http://code.google.com/p/seathreepo/

Here's a question that has bugged me for a while, and to which I've never found a satisfactory answer.

How do people handle mailing list moderation when they have spam filters active? For instance, I get a lot of spam in the moderation queues for the Apache mailing lists I moderate. Sometimes gmail flags it as spam, and I can't quite say it's wrong... I mean the body of the email that's help up for moderation is often full of spam words. But the moderation message itself isn't really spam. I'm afraid of confusing the filter if I let it through. I guess this is where an open source system might be better, as you could simply put a rule in saying "if it's a moderation email, don't even bother looking at the keywords". Gmail's awfully convenient though... anyone else out there with the same problem?

The latest component of Android Hecl that I have been working on is a simple shell server that lets you interact with Hecl remotely, in order to be able to telnet in, run commands and see what they do. In order to give it a whirl, fetch Hecl from svn:

svn co http://hecl.svn.sourceforge.net/svnroot/hecl/trunk/hecl hecl

Then install the Hecl.apk:

adb install android/bin/Hecl.apk

Select the Hecl Server demo, at the bottom of the list:

You also need to make sure that port forwarding is set up:

adb forward tcp:7405 tcp:7405

At this point, you can telnet to port 7405 on localhost, and run Hecl commands:

> puts hi
hi
> androidlog "hello world"

> java android.telephony.TelephonyManager telman
telman
> set phoneinfo [[activity] getSystemService phone]
android.telephony.TelephonyManager@435c8f80
> $phoneinfo getLine1Number
15555218135

Since this simple server runs in its own thread/interpreter, you can't control the GUI from it. To do that, there is a 'maineval' function that sends code back to the main interpreter:

> maineval {set layout  [linearlayout -new [activity]]}
1
> maineval {$layout setorientation VERTICAL}
1
> maineval {set layoutparams [linearlayoutparams -new {FILL_PARENT WRAP_CONTENT}]}
1
> maineval {$layout addview [textview -new [activity] -text "Hi!" -layoutparams $layoutparams]}
1
> maineval {[activity] setcontentview $layout}
1

Gets us this very, very simple screen:

Hecl's Java reflection support is still fairly alphaish, but you can use it to query classes about their methods and constructors, and call them most of the time; errors should be sent to me or the mailing list.

I found this little server particularly useful when fiddling around with some of the undocumented android classes, as a way to experiment in a running system.

http://www.postgresql.org/about/news.918

I've always preferred PostgreSQL to Mysql. I think the "worse is better" compromise is ok in some cases, but it's scary to see money being handled in transactionless MyISAM tables that are so widely used; I've done work for a number of places that had that kind of setup, and extrapolating from that, it's got to be very, very common indeed. I guess they heard it was "faster"... but I've always likened that kind of faster to the kind of faster you get by riding a bicycle with no brakes down a hill. Mysql's made lots of improvements over the past few years and is beginning to approach the robustness that Postgres has always had, but I'm going to stick with Postgres, and I'm glad to see they keep churning out cool new things, using the same sort of community open source approach that works so well at the Apache Software Foundation.

Yoav Shapira wonders about the "rails backlash": http://yoavs.blogspot.com/2008/02/railsshudder.html

I'm a big fan of Rails, and of course I realize that it has some flaws and is certainly not the optimal choice for all situations, but I don't buy into the bashing.

Sure, Rails was hyped, but there is no way that it could have possible reached the level of popularity it has on hype alone. We're not talking about multi-million dollar marketing budgets commanded by the likes of Sun or Microsoft, but about a video and some nice dressings by DHH and 37signals. A small group like that just doesn't have the resources to push something like Rails as far as it's gone without some substance to back it up.

Look at all the imitation. People realize that the basic idea is good, and even though the basic idea is nothing phenomenal, it hadn't really been done before. What is this idea? Take a bunch of components, and good (if not always the absolute best) practices, and integrate them nicely. Database, templating, testing, a clean application structure, ajax/javascript integration, with some code generation, all done with a language that's flexible enough to do all of the above pretty well. All those things existed, but Rails did a great job of tying them all together. And that's been imitated far and wide. That seems to indicate that, even though the imitators may change and improve bits and pieces, they're quite smitten with the idea itself. So much that they've dedicated a lot of time and effort to reproduce it. That's quite a tribute.

Look at the adoption. Moving to a new language/platform is a big step, not one to be taken lightly, and for people with lots of existing code in some other language, perhaps simply not possible. Hype will take things only so far, but Rails has been taken up by a large number of people who certainly didn't do so because it was the safe, easy path to take. Perhaps some of those people have found that Rails really wasn't for them, but that's pretty normal. No one said it was perfect. However, when you look at what it takes to make people jump ship from what they know, and are comfortable with, you realize that it really must have been that much better to make people go out on a limb.

Furthermore, it's easy to point out the failings and drawbacks of something after the fact, but much more difficult to do creative, innovative work of your own. Compounding that is the fact that criticizing others' work is often an easy and effective way of looking smart; there's an interesting study referenced here http://bobsutton.typepad.com/my_weblog/2006/08/brilliant_but_c.html that talks about this effect.

It's something I've come to dislike over the years. Our field is so new, so dynamic, and so immature, that it's usually pretty easy to take a look at something and say that it "sucks". It is much harder to write something of your own and put it out there, knowing full well that lots of people who have never done much of anything will jump on it and bemoan its "copious failings". That's not to say that it's impolite to criticize, but - do it constructively please. Imagine that you were there in the same room, talking to the person who wrote the code in question. You would still say you don't like it, but you'd probably be much more polite and helpful in your commentary. I hope so, at least.