Bob Kerns: Thinking

CBS News Makes False Claim of "Toxic Plutonium Pools"

Letter to CBS news:

Your headline writer has made a serious factual error of major significance.

"Somber prime minister addresses nation, says country on "maximum alert" following discovery of toxic plutonium pools"

Fact: There are no pools of plutonium. There are traces detected in soil samples at a level around that found after atmospheric tests (the last one being in China in 1980). The ratio of radio-nucleotides suggests they came from the reactor.

TEPCO's press release, accompanied with the actual data, can be found here: http://www.tepco.co.jp/en/press/corp-com/release/11032812-e.html

This is almost certainly the original source of the information in the article itself; I doubt if the information has been made available independently of TEPCO.

Nobody, not even the very article on which this headline appears, has said anything about pools of plutonium. Yet reader comments demonstrate that people are believing the headline, rather than the article.

The analysis of the pools of water do NOT show plutonium, so there can be no excuse that this is shorthand for "plutonium-contaminated pools of water".  The article itself indicates it was found in soil samples.

The truth is serious enough. This is something I might expect from Fox News -- not from the network of Walter Cronkite.

This is a seriously inflammatory and false headline, and urgently needs to be retracted with a public apology.

I first reported this via the comments section about 18 hours ago. Let's see how long it takes them to publish a retraction.

[Update: Updated the link to the article, since it seems to have changed.]

Anonymity, and On Teachers Blogging

Recently, I commented on two topics, which intersect. Kent Pitman posted on the topic of anonymity on Open Salon, and I responded with a few of my thoughts on that topic.

And then came the case of Natalie Munroe, a teacher in Pennsylvania, who has been suspended with pay for blogging anonnymously, and talking (without naming herself, her school, or her students) about the frustrations in her work.

While I definitely feel there's a need and role for anonymity, I think there' is great strength and value in the courage to stand up and speak publicly.

I reproduce here a comment I originally made on an Education Week blog yesterday.

---

Back in 1979, Brian Harvey left the MIT AI Lab (or was it the Stanford AI Lab? I forget the chronlogy), to teach computers at the Lincoln-Sudbury High School in Massachusetts.

I was a devoted reader of his semi-regular email list on his experiences there. This was about as close to a blog as you could get back then. We didn't have Google back then, of course, but we did have a more open environment, and his writings were discoverable -- in fact, I suspect that's how I discovered where he'd gone and that he was writing about it, and asked to be on the mailing list.

I learned a lot from this. Had he been gagged, I would not have learned a thing. He also wrote in other contexts about his experience and lessons learned, for example: http://www.cs.berkeley.edu/~bh/freedom.html

Schools are already far too much a secret society, with the public, parents, and even the students themselves being outsiders. Of course there are issues. If my kids were specifically blogged about by a teacher, I would have some concerns about that, even if not by name. Not "Thou shalt not blog about my kids", but issues of fairness, motivating kids, and privacy arise, and must be handled with care.

I don't know that  Ms. Munroe crossed those lines. According to Ms. Munroe (who I heard speak on the radio earlier today), those quotes that are making headlines, like "not as smart as she seems", were from a list of alternate check-off report card items she'd like to see -- satire and humor.

And you know what? Although I can't check her blog now, since it's been taken down -- I believe her, because that one is not original -- I've seen it before, in just such a list.

Did the press manage to get that?  Apparently not. Aparently, satire, irony, and humor are utterly lost on our modern "press" in their rush to the most sensational headlines possible. One can only imagine what their teachers thought about their reading ability when they were young!

I think the reaction is plain backwards. I think teachers should be encouraged to communicate about what happens in the classroom. Carefully, of course. But -- if a student acts up in class and disrupts learning for the entire class, I'd like to hear about it from the teacher, and not just from my kid's viewpoint.

I can be a better parent, and a better citizen of our school district, if I understand better what goes in in the classrooms, and the minds, of our teachers. And our students could be better students.

But -- there has to be some respect and some professionalism. If Ms. Munroe failed anywhere, I'd guess it was most likely here.

But within those bounds, the more blogging the better. Given the nature of the world our children are growing up in, I would argue that we really should REQUIRE our teachers to blog weekly.  It would be a tremendous opportunity for education, for kids to see their environment, and their behavior, challenges, and progress blogged about. Done right, it could be a tremendous motivator.

And most importantly, it would be leadership by example, about how to write, and how to write about others with civility and respect.

If Ms. Munroe erred in her conduct on her blog, I strongly suspect that the anonymity under which she operated was a major contributing factor. I would expect that she would have written a better blog had she not been hidden behind the veil of anonymity, and had the expectation that she would have to stand by her words into the distant future.

Because the internet has preserved posting I myself wrote back in the 1970's. I learned long ago to regard everything I write as potentially permanent and public. I've also learned the courage to speak my mind, to allow others to disagree, and to disagree with respect. I've learn some skill in calming online arguments, bridging communication gaps, and refocusing conversations.  And most importantly, I've learned the courage to quickly aplogize when I have erred, or have simply allowed myself to be misunderstood.

And always, under my own name.

I would like our teachers to be able to teach this generation of students some of the same lessons.

Advice to Young Journalists

I wrote up some advice for the students in the newspaper club at our local middle school. It's been well-received, and I'd like to share it, under the Creative Commons license.  

The document itself was originally created for paper distribution, but I have converted it to Google Docs to make it more accessible on the web. My apologies for the loss of formatting that entails.

Advice for Young Journalists by Bob Kerns is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Dear Java: better text formatting, please

I've been involved in one way or another in internationalizing software for over 25 years. Those 25 years have certainly seen some changes -- like the rise of Unicode -- but I think we still fall short.

Recently, on the Android platform, a change was made that peripherally relates to today's topic; this is a revised version of that post, as the issue is much broader than that of Android, or Java, but rather how we go about externalizing strings for translation.

The current usual practice for externalizing strings is to externalize a template, which gets filled in, for example, "%d cats and %d dogs". Typically, this would be used like this:

format("%d cats and %d dogs", catCount, dogCount);

That doesn't look too bad, but when you don't have the format string and the parameters in the same place, it becomes really hard to understand what is happening, and errors are common.

But that's just the start of the problem. When you translate, often word order needs to change. For example "red shoes" becomes "zapatos rojos" in Spanish. This extends to entire sentence structure. The usual solution is to allow the format string to refer to arguments explicitly by position, so for:

format("%s %s", color, item);

we might substitute "%2$s %1$s" for Spanish.

But that's not good enough.

In my experience (perhaps not comprehensive), the workflow goes like this: A developer writes the message, in his language of choice, usually English, but perhaps, say, Japanese, and plops in %s and friends where appropriate, and arranges the arguments to the formatting code in the same order as they occur in his format string.

Then someone comes along and whacks him over the head for not externalizing it for translation, and it is moved to strings.xml or other localization resource.

Finally, maybe one time in 100, the application is successful enough to be localized to other languages. One might wish for this to be more often, but actually I think I'm being generous here. But it's a pain to do if the previous step hasn't been done, as a matter of practice. So we'd like to make that as easy as possible. Really, I don't think we're even close to making it as easy as we should make it! Especially since the programmer, and likely his manager as well, will correctly perceive that the effort stands a high probability of being wasted.

Then finally, if we're lucky, we get to translate the app. If we're really, really lucky, we'll have a QA department that will try to reproduce as many of the messages as possible, in the original language.

Now, off goes string.xml and friends to the localization service, translator, team member, or maybe the developer's wife. Much of the time, maybe 80% or more, the strings with multiple %s's will not be using them in a way that is particularly sensitive to language. They may be constructing an identifier name, or a list, or may occur in different sentences, which would not in most cases require reordering.

Your mileage may vary on the frequency, of course. But I'd say the most common use would be something like "%d cats and %d dogs" -- and ordering is not the problem you face here, but rather, handling of plurals.

And Android gets big kudos for addressing it, with a <plurals/> item listing alternatives based on count. But "%d gatos y %d perros" or "%d猫と%d犬?" are perfectly fine, from an ordering standpoint.

BUT! Your Spanish translator is barfing right now, and it has nothing to do with positionals. The programmer didn't think about plurals. (Yeah, yeah, he should have. See above for the unfortunate reality). Your translator has to get the programmer to change the code. Bletch. That likely requires a whole new release. more expensive QA, etc. Yikes! Maybe we live with it for now, instead.

Now (next release) it goes to the Japanese translator. Who goes, WTF is this? Well, OK, maybe more like 「なにこれ？」 

What used to be easily translated as "%d猫と%d犬" is now just "%d %s and %d %s", or maybe by now "%1$d %2$s and %3$d %4$s". What's the context? Should this be "%1$d%2$sと%3$d%4$s", "%1$d%2$sで、%3$d%4$s", or a dozen other possibilities? Yes, the first guess is still really the only likely answer given the presence of %d, but still, you've made the translation job harder.

Given that the original was in English, which has plurals, the programmer might have supplied that -- but consider if the original were in Japanese, which almost entirely lacks the concept. Just like English lacks the concept of a different set of number words for long skinny things like pencils, vs flat sheets like paper. In that case, the first time that plurals will enter the picture will be when the app gets to the English translator, who will get to barf. Note that even if the Japanese programmer writes it in English originally, you're still probably going to have the same situation. In fact, you're likely to have it even if English is your programmer's native tongue.

In addition to translation, often the text and wording are manipulated separately from the code, for marketing and/or usability and/or branding purposes. So the original text may have been "Pigs: %d, Cattle: %d", and now it's being rebranded for a pet store by someone who doesn't even have access to the source, and they want to make the text style more friendly -- and THIS is the first context in which plurals need to be handled.

Finally, notice that Spanish has plural forms for the adjectives! Your English-speaking programmer may not have even been aware of this fact. Again, putting this burden on the programmer leads to failure.

Bottom line on that point is that plurals are a linguistic concern, and should not be institutionalized in Java code. Plural handling should be fully externalized -- as part of the format syntax. Say, perhaps, %(3:MyPlural)$s, which rather than directly referencing an argument, references a <plural/>, and selects the case based on the numeric value in parameter 3.

The bottom bottom line is, there really isn't much value in asking programmers to write in the positional arguments. It's more economical to do so at the point of reordering, which is only a small subset of the cases - if you get to that point at all. If you want to force programmers to do something useful -- force them to define and document what each parameter MEANS. For example, if you forced the programmer to give each parameter a NAME, instead of a position in a getString(...) call, the extra effort would not be duplicative, and you get some improved robustness for your efforts.

For a really radical suggestion: in strings.xml:

<string id='cats_and_dogs'
>%(CATS)d % (CATS:cat_plural)s and %(DOGS)d %DOGS:dog_plural)s</string>

in Java:

getFormatted(R.string.cats_and_dogs)
  .p("DOGS", dogCount)
  .p("CATS", catCount)
  .asText();

This fully removes order from the picture, provides some self-documenting characteristics, separates the concerns properly -- and of course, is completely incompatible with Java's formatting. Though it is detectable which is which.

It'd be rather simple to create such a formatting library. It can be built on the existing language formatting facilities, so it could be done as a third-party library. However, as a matter of encouraging good practice throughout the industry, I'd like to see language developers/vendors providing such a facility natively. It adds more value if it's done as a standard practice. Finally, we need tool support to make it easier for programmers to work with externalized string at the point-of-use in the code, and to go in the reverse direction -- from string resource to usage in the code.

Yet more about UTF-8 -- the Evils of Platform Defaults.

In my long experience, one of the most common causes of character-set failure is blindly accepting the platform default encoding. Often, people don't even realize they are doing this.

It's an old story. I've seen it time and again, at company after company. And despite the thought that "Java uses Unicode", I've seen it at least as much in Java as in C++. (Though there's a fair amount of observational bias there!)

The developer tests, and it all seems to work. He may throw in a few odd characters he knows how to type, maybe a few words with accents.

The QA lab runs a few tests, perhaps a bit more thorough. Maybe they even throw in some Japanese or Chinese -- and maybe it even works.

Off it goes to customers. Say, maybe a customer in Canada, who speaks French, and runs an older version of Windows, and sets his locale to something different.

And boom. It fails. If you're lucky, it crashes. If you're unlucky, it loses critical data?

What happened?

Simple: new String(myByteArray).

People assume either that it will use UTF-8, or that it will use some platform default that will be the right thing.

Wrongo, charface!

It will use SOME platform default. It won't be under your control. You don't know when it will change. You have given your application's behavior over to the evil gnomes that lurk in the platform.

Because you simply do not know, there is basically no way to use this API in any way that is remotely useful.

If you have any control the charset being used, always choose Unicode, and in most cases, you should encode it as UTF-8.

 And NEVER perform any conversion in Java that does not specify the character set and encoding. Don't open a text file with new FileReader(...)  you can't specify that second argument. Use new FileInputStream(...) and pass the result to a new InputStreamReader(...) -- and tell that the encoding.

Supplementary Characters in Java

Just a quick followup to my post the other day regarding data corruption and UTF-8 in ABCL.

I just happened upon this Sun (Oracle) article explaining Java's support for the supplemental characters. A nice thing about the article is that it gives a reasonably concise overview of the basic Unicode terminology and concepts, for those who may be unfamiliar with those.

UTF-8, Replacement, and Data Corruption

I happened upon a nice-looking Lisp implementation, ABCL (Armed Bear Common Lisp), which runs in and compiles to the Java JVM, integrating with the JSR-223 Java Scripting API.

Unfortunately, I found on their blog, this article.

[Note: Corrected URL]

Basically, they're trying to handle "bad UTF-8 input" by substituting a character ('?' in this case) for what they don't understand.

I tried to post a response, but my first attempt wouldn't OpenID authenticate against my typepad account (this blog), and resulted in my finely-crafted prose, better than this in many ways, being discarded.

So I rewrote it with what you see below, and tried again with my Google account. First it complained that my HTML was > 4096 characters -- and submitting a smaller partial input also made the same complaint, despite being well below that limit. Presumably some rewriting to HTML was pushing it over the limit.

Finally, I go it to accept it -- only to get a Google error message that the URI was too long to process. Integration failure!

So I post this on my own blog, and direct it to any and all who would consider trying to be nice by "handling" the "bad input".

---

Please, please do not do this!

Your intentions are good, and this seems like an obvious good thing -- but it's not. It's a trap.

This is such a serious mistake as to completely disqualify your system from usage for many purposes (unless one bypasses your text input stream handling entirely!). What Java does here is correct and vital. Do not bypass it.

I quite understand the instinct to just "make things work" in the face of invalid input. For example, Interlisp's DWIM -- Do What I Mean. More aptly titled, "Do what Warren Teitelman taught Interlisp to guess that I might mean."

This had the unfortunate effect of allowing bugs to slip into systems undetected.

You're thinking along the lines of Jon Postel's "be conservative in what you do, be liberal in what you accept from others", but that's a different situation, seeking robustness in establishing communication, not integrity of the data -- and even there, it had a lot of unfortunate consequences and has largely been abandoned in favor of more strict compliance.

Or consider the history of HTML, and the myriad messes which have resulted from browsers being liberal in what they accept coupled with page authors being sloppy.

I consider what you are doing here to be EXTREMELY seriously bad. You are, of your own initiative, silently corrupting data. There are few worse things a computer can do!

I cannot begin to tell you how often I have had to track down bad data caused by EXACTLY this behavior. Such data is usually detected FAR from the bad input. Often, extensive and expensive manual fixup has been required. Often, repair has simply been impossible.

You state "not everybody produces strict ascii or strict utf8 sources." Well, kind of true. People often produce strict ISO-8859-1, for example. That's the situation here, apparently. Rather than fix your real bug (reading an ISO-8859-1 file as UTF-8, thus potentially corrupting the data, if you're unlucky, or getting an error if you are lucky, as in this case) -- you are simply eliminating the error -- guaranteeing you'll be unlucky and the mistake will go undetected, until someone has to investigate why there's this funny '?' in some output somewhere, when some quite different appeared in the source code!

Input files can be in strict ISO-8859-2, -3, etc. or strict shift-JIS, or various strict combinations of {EUC, ISO-2022} and national coding systems.

The reality is, interpreted in the correct format, malformed input is extremely rare. When it does occur, it is nearly always the result of concatenation of raw byte-data that encodes different formats. For example, a source file that has been edited as UTF-8 by one author, and ISO-8859-1 by another, and then merged in a revision control system.

That's something to fix (the guy with the ISO-8859-1 editor needs to fix his setup), not paper over and ignore.

The solution here is simple: If you find you are reading the file in the wrong format, provide a restart to select the correct format, and reread it -- from the beginning, restarting all processing.

In most cases, the correct action will be to convert the input to UTF-8. In this day and age, nobody should be using any lesser character set, nor any other format for data interchange. (UTF-16 or full 32-bit unicode are suitable for internal processing, but will cause problems for interchange as support is limited in most environments).

And yes, I am aware that a lot of tools still default the charset to the platform's encoding, which for legacy reasons often defaults to some national encoding. Eclipse, for example. This is unfortunate, but data corruption is not the solution.

The only exceptions I see to not doing substitution: (1) Providing visual context to the user about where the problem lies, to aid in investigating and correcting the input -- e.g. selecting the right encoding, or re-encoding the input to the expected encoding, or (2) situations where proceeding without failure is vital, and data integrity is secondary to that goal. (Reading source files does not begin to qualify!)

So please, please, do not do this.

--- Argument by Authority section :=) ---

Developer on:

• MacLisp
• Macsyma
• Symbolics (including Japanese support)
• ANSI X3J13
• CLIM
• Various character-set/encoding libraries.
• Emacs's Edict library

My distaste for this strategy has been honed and reinforced over decades of experience with it.

And you have a lot of company in this, so I've had a lot of opportunity to get experience with it, unfortunately.

So please do not do this!

Meet the Users

(Reconstructing this post, because TypePad ate the previous version).

Our application has been on the market now for a couple days. And so now, we have something new:  users.

One thing I learned long ago about users: They don't always behave the way you expect or want!

One of the little not-so-endearing features of Google's Market application store, is that the descriptions you get are pathetic. You get to use 325 characters and two screenshots. That's it. Somehow, in 325 characters, you have to tell users what your application does, and why they'd like to try it.

This, and the ONE comment you get to submit as a purchaser of your own app, are your only means of communicating with your customers.

So ours reads:

SmartVolume by SF Smart Systems makes it easy to get the most out of your phone.

One screen to manage all your volume settings and even lock volume for each type of sound. No more fumbling around for a setting while trying to hear a caller.

Never miss an important call because you accidentally turned down the ringer.

As a major purchaser of phone apps, I've read a lot of user comments on apps, both on the iPhone (all four of us in my family have one), and on the Google Market application.

As a purchaser, I've found these comments to be all over the map. A few are helpful. Many are just insults, obscene comments, and other juvenile conduct. Others are obviously confused about either their phones or the app's intended purpose.

And many clearly show that the user has not read the app description before downloading, trying, and commenting. Clearly-labeled prank apps being taken for the real thing. People expecting the obviously impossible.

So I was prepared for the worst.

So I took the precaution of posting the first message.

Please send any support requests or problem reports to us at [email protected]. We aim to give fast, quality support.

How much good do you think that did?

Here's a summary of the first comments:

• A report that likes a feature, but complains it won't let her change something on her phone. I'm not sure exactly what she means, but I'd like to know! She also reports the FAQ link doesn't work -- but nobody has asked any questions yet.
• A guy who really loves it. (Thanks!)
• A "Nice try", but reports that while it acts like it'll work, it doesn't -- whatever that means. He reports he's on a Motorola Droid
• A guy who reports it works great on his Motorola Droid

OK, at this point, I'm scratching my head. Do I have a bug? No sign of any problems examining the reports from Flurry. There are a few exceptions that I handle and report, because it came up exactly once during my stress testing.  Thanks to Flurry, I can see that it happens once every several thousand passes through that code -- about once per 1000 sessions.

But then I get one more comment.

• A guy who reports it works, but then forgets, but works again if you fiddle with the volume control

OK...this may be a clue. I go back and retest.

After some testing, uninstall, reinstall, test, retest, reboot, I come to understand that the problem only exists between install and first boot. Once you reboot your phone once, it works reliably and properly.

But if you get a low memory situation, and the system kills your app, THEN it does not restart.

When I tested this behavior -- first I tested that it starts up on booting OK. Then I tested that if you kill it, it restarts properly. That worked. But I needed to have tested them in the other order.

With this information, it didn't take long to track down and fix, and I had a new version up on the Market an hour or so later.

(The problem was that the user interface only bound to the service, which causes it to run, but didn't actually "start" the service, which is required to keep it running even after a low memory situation).

But what to do about those comments on the old version? I'd love to have the people retry, and update their comments, but I have no way to communicate with them.

So I just added the phrase to my comment, "NEWLY UPDATED!". And I found this nicely moved the comment up to be more recent than the other comments. Thus, this now marks where the comments are obsolete!

I tried really hard to test low memory. I really did.

I blew it. In my rush to get a fix up there, I neglected a necessary check. Fortunately, a few hours later I happend to be trying UStream Viewer, and it caused a low memory situation. My app blew a fuse (FC - Force Close). A quick look revealed the problem, and up went a second revision.

A quick check of the bad version (1.0.293) showed:

 
Uh, oh. Well, nothing I can do but hope they upgrade. So this time, I added the version number to my comment as well. "NEWLY UPDATED! 1.0.296"

This is a small percentage of the user base, but I don't want any unhappy customers, even for a free app. The good news is, very few people are encountering low memory situations. As part of my update, I made Flurry report low memory situations. Out of 1206 sessions over the past couple days, only 6 have encountered a low memory situation at all.

I'm going to keep doing this trick with updating my market comment, both in a futile attempt to communicate to users who've already posted comments, and to let potential users know which comments are still relevant.

But the other thing I've learned, is I Really Need A Tool to really test low memory. If I can't find one, I'll have to write it.

So that's all the market comments we've received. Our rating is at 4 out of 5 stars, which isn't too bad for a first attempt, and a few glitches.

But what about email? Did we get any email? The Market app makes it easy to send email -- just tap the Email Developer link.

Yep. We got email. After the above Market comments, two emails came in.

The first was from a fellow Android developer, commiserating about a post about getting useful user feedback.  She liked the app.

The second was from an old friend, whom I'd worked with at MIT and Symbolics back in the 1970's/1980's. Howard I. Cannon is cofounder and CTO of ModelSheet Software which is in public beta now. It generates nice, easily customizable Excel spreadsheet templates for various business modelling needs. A very clever idea. Since business is addicted to Excel, but it becomes unweidy -- do the customization separately, rather than by editing the spreadsheets directly.

Howard had some great feedback for me. I was supposed to call him back today for more, but life intervened, but we'll talk more this weekend.  And I was able to return the favor by looking over his beta site as well.

But that's it. The only email has been from other developers!

That's really not that surpising. We developers understand how valuable feedback is. Even if it annoys, it's our lifeblood.  Customers, especially for free or inexpensive apps, often don't have so much investment in the product. To them, a problem is just an annoyance.

But it's really a partnership. If you take a moment to contact a developer with a problem, you'll help make a better product!

I've done everything I could think of, to make it easier for users. I've used Flurry to automate reporting of errors and other things that will help me make the application better. I've put a menu item in the app to take them to our support page, where they can report problems. I've put in an extensive tutorial (TOO extensive, reports Howard, and I agree) that covers every aspect of the program, and the ins and outs of volume controls on the Android platform.

But it'll never be enough.

Remember all this, the next time you're reading user comments in a phone app store.

I really hope Google folk read this. The Market really needs some work, and #1 on my list is to improve the communications between developers and users. By contrast, the iPhone app store allows over twice the communications and a lot more tools.

Clever use of search and Twitter

Today I blogged about the release of my new Android app. I shared it to my Twitter stream. It seems this immediately caused my Twitter stream to be picked up and republished by WowAndroid. Which was then indexed by Google, and I was notified.

http://wowandroid.com/index.php?user=BobKerns

SmartVolume FREE for Android

In the wee hours of the morning, around 2:00 I think, I released our first Android application.

http://market.android.com/details?id=com.sfsmart.volume.free

(Google's Marketplace doesn't really work except with their application, and their application is not available in all countries, nor via all carriers, nor on your PC -- a topic for another post. You'll get an error, otherwise. You will soon be able read some about it at http://sfsmart.com, but our site is still under construction. My marketing partner is unexpectedly travelling this week, so we don't have as coordinated a launch as we would like.)

It's been an interesting experience getting here. I began learning the Android platform at the start of the year, using this application as a learning platform before we undertake more serious efforts. It's been a better choice for learning than I could have imagined.

Over the next few days, I'll post some of the things I've learned, and try to give some insight into what it's like to pick up new skills and enter a new market.  I hope to cover both some of the more technical aspects that help in creating a solid product, and share some of my thoughts on marketing, from a developer's perspective.

One of the decisions we made was to go with the Free/PAID model, where we have two applications, a Free version, supported by advertising, and a Pro version, which dispenses with the advertising and offers some additional features. Today's release was the Free version.

The launch appears to have been a success. When I woke up this morning, and checked the stats, we had something like 122 downloads in 6 hours, from all over the Northern Hemisphere. Later in the day, we got our first comment in the Market -- quite positive, with a 5-star rating (out of 5). Our little trial application appears to have nicely solved a real problem for a real user -- that feels good!

One of the decisions I made was to include Flurry monitoring into the application. Without being intrusive in any way, nor disclosing any personal information, it gives me insight into how people use our applications, an any potential problems.

Indeed, among the mornings statistics were several occurrences of one error, which was initially concerning. Further investigation showed, however, that these were errors that I'm handling and reporting, and should not be impacting users. This is a problem I found during some of my extensive stress-testing of the application. I left this temporary workaround in place to find out how often it would happen in practice. Rarely -- only a handful of sessions out of thousands, but still worth fixing.

One of the frustrations of the Google Marketplace is that people leave complaints there that you have no way of helping them with. One of the first things I did after downloading our app was to leave a message requesting people send support requests and problems to our email address, but of course, I haven't gotten any email at all (except for test messages I sent to verify it works!)

But already one user has left a semi-complaint that one feature didn't work for her. I'd like to better understand, but I can't reply and ask for more information without wiping out my other message. I'm hoping I can identify the problem through the Flurry data, but not so far.

It may be a documentation problem, or a limitation of her device, or even a bug. It's going to take some more proactive digging to find out, when a simple email would have been so helpful, and not much more trouble than a comment.

Still, we don't have a right to expect users to go out of their way to help us. But we really DO appreciate it when they do. Even in this form, if I can identify this woman's issue and resolve it, she'll have been helpful.  But please -- we'd really like to see just positive comments on the market, and get all questions and problems sent via email. It would make us look so good!  :)

In the meantime, I've been monitoring our ad revenue. We're up to $0.70 which doesn't sound like much, but I'm pretty happy with that so far. How good that is depends on how much people continue to use our app. If we just serve ads to people who try it out and then discard, it won't be so good. $1/day will pay some of our expenses while we work on our next product, but won't be enough to build a company on.

On the other hand, if we end up with a growing set of old users, we may see that number climb.

I don't believe it's possible to make a living on ads for a single utility like this. I think you need to get a number of applications out there, and a mix of free and paid.

Of course, there are the big hit applications which download tens, of not hundreds of copies.  These are in a different class. That's a great kind of success to have, but it's also a very unsure kind of success.

More tomorrow.