takhus lukhnos

"What we know about eating animals is that we don’t want to know."

Sat, 07 Nov 2009 23:32:58 +0800

“What we know about eating animals is that we don’t want to know.”

- The New Yorker: Should you eat meat? (via marco)

Ergosoft and Monokakido

Wed, 04 Nov 2009 06:26:00 +0800

I was going to post an article on how sad and surprised I was to learn that Ergosoft (エルゴソフト), a Japanese input method maker¹, folded their Mac software business in January 2008. I met one of their engineers at an input method developer’s seminar hosted by Apple in Beijing, China in 2007. They used animated menu and had an excellent UI (that was before Core Animation) and showed people what input method could be.

A number of articles reported or commented on its quitting Mac software business:

ASCII.jp: “エルゴソフト、Mac用パッケージソフト事業を終了” (Ergosoft folded its Mac package software business)
CNET Japan: “エルゴソフトの事業終了に思う” (Opinion on Ergosoft’s closure)
excellog: “さようなら　「エルゴソフト」” (Goodbye Ergosoft)

And that was when Kida-san saw my tweet and told me that Monokakido (物書堂) was a spin-out, founded by two of Ergosoft’s former employees. I was so gladly surprised to learn that, because Monokakido is the company that makes the iPhone version of the very popular Japanese dictionary Daijirin (大辞林) !

The story of Monokakido is definitely inspiring. Their mission, according to their company intro, is

“Mac で文章を書く人々に対して、創造力を最大限に発揮できる道具を提供することを目的としています”

(to provide everyone who writes on Mac with tools that bring out the best of their creativity).

Plus the fact that they are a company of two, it immediately becomes my role model of what a small software company can do and achieve.

I was equally surprised that its majority holder was the game maker Koei. ↩

Kindle 2 and the Disruptive Force

Thu, 08 Oct 2009 00:30:00 +0800

Kindle goes international. The new international model seems to use now 3G instead of EVDO, which is a big step forward.

As much as Apple was possible to roll out the App Store by first building up a global app distribution and payment collection mechanism, Amazon seems to have talked mobile operators well into buying their ideas. If it’s as promised that it’s a subscription-less roaming device (even if the usage fee is actually included in the book price), it’s still a huge improvement over some of the last barriers of mobile communication. This probably also raises the bar for Apple, considering Apple is now a handset manufacturer, which has certain constraints when talking to mobile operators.

The implication could be huge. For example, Amazon can have huge leverage over many local markets (it doesn’t even have to sell physical books there now—just like Apple doesn’t have to have iTunes Music Store everywhere to have a say in a market). Another possibility is when/if Amazon combines its already leading role in providing cloud computing utilities, and comes up with a business platform. An e-ink reader, a mobile device, an internet communicator—companies like Bloomberg or big banks might be highly interested in turning that into a great transaction device, who knows¹.

Then there are books, and for now it’s still about books. There is already much written about it. I’m happy with my Kindle 2 as it is now—although I do envy friends who use their DX to read journals and papers. The publishing industry is transforming in a pace faster than people would have imagined a year ago. Let’s see what goes with it and what will be born, or reborn, out of this great disruptive, if not destructive, force.

From a software developer’s perspective though, Amazon doesn’t seem enthusiastic in turning Kindle into a platform. No word was given when iPhone first launched in 2007, but Apple has always been a company that relies on developers. On the other hand, there are already many Kindle hacks on the potential and limits of Kindle as it is now. Amazon probably also has a different set of software development in mind, such as non-native, out-of-device, server-served applications, much like their own store on Kindle now. ↩

Hiragino Sans GB: A typeface with Japanese soul and Simplified Chinese look

Fri, 25 Sep 2009 01:17:00 +0800

Who else could give a more authoritative non-official introduction¹ than Kida-sensei:

心配なのは、一番最初の例のように、質の低い日本語の文字がグローバルスタンダードになってしまって、高品質なフォントが日本国内だけのお家芸になってしまうことだ。グローバルに羽ばたける高品質な日中共通デザインのフォントが欲しい。

SnowLeopard で新しく加わったフォント Hiragino Sans GB はまさにそういうフォントだ。

これはヒラギノ角ゴシックの中国語版、正確に言うと大陸の簡体字版で、ヒラギノ角ゴシックとデザイン的な互換性がある。ウェイト（太さ）は W3 と W6 の二つ。漢字の字形は完全に中国の規格に沿っていて、日本のメーカーが作ったフォントでは初めて中国政府の認証を取得した。

In rough summary, Hiragino Sans GB is the Simplified Chinese version of the Hiragino typeface. The glyphs use the forms that are Chinese national standard. It’s designed to make Chinese characters look good in Japanese texts, and vice versa.

I have always been a fan of Hiragino. Sometimes I even print documents using the fonts in its family. I usually avoid Traditional Chinese characters that are not covered by them². With zonble’s system-wide font fallback hack, I am now able to use Hiragino Sans GB as my default Traditional Chinese font.

What’s my take, as a Taiwanese, in using a Japanese/Simplified Chinese font for Traditional Chinese? I have mixed feelings. But I know these things hold true for me:

While the punctuations in Traditional Chinese should always be aligned in the center, not on the baseline, when written vertically (直書), I don’t belong to the traditional school that thinks the same should hold true when written horizontally (橫書). So I’m quite comfortable actually with any CJK font as long as it looks good.
For some period of time I had actually used STHeiti as my default fallback font for any Chinese.
This being said, I don’t like inconsistencies—and this makes Apple’s Hei TC, while a laudable attempt to offer a modernized Traditional Chinese typeface, unusable in professional settings. It also has other major flaws, most objective, some subjective depending on your aesthetic take.
As long as a typeface has consistent radical components³, I don’t actually mind if a character is written according to the Japanese, Taiwanese, Chinese, or Korean standard (the first three in the order of my subjective preference).

I want to say that it’s a good thing that a Japanese font foundry would want to come up with a typeface that attempts to make mixed kanji writings look good. It’s a shame that hardly any Taiwanese or Chinese font I know of tries to do that. Most of the latter two look good in Chinese only (and often only in either Traditional or Simplified, not even both). Many of them, Apple’s Hei SC and Hei TC included, have substandard Japanese kanas. The Roman characters in those fonts also look just so-so (this is, however, also something that Hiragino has space to improve). I hardly know any Korean so I can’t speak for the hangul part—although I assume the Korean language is much less dependent on hanja (kanji).

No oxymoron here. Kida-sensei is the chief developer of Apple’s Kotoeri Japanese input method. ↩
As a native user of the language it’s not that hard. Imagine you must not use the word “oversee” and should substitute it with “supervise”. Naturally you can’t do this too often and too much, but for titles or short texts it works perfectly. That is, again, if you don’t mind the punctuations. I admit that this sometimes exudes an air of exoticism—but that’s exactly what I intend to do. ↩
And as long as they are modern—say of the Song (Mincho in Japanese) or Hei (Gothic in Japanese) family. I’m not fond of the Kai or the Li family, but that’s another story… ↩

Some caveats for using C Blocks

Mon, 21 Sep 2009 02:08:00 +0800

One audacious thing that Apple does when it releases Mac OS X 10.6 is it adds block support into the C language. It’s pretty much like what you expect—first-class objects that can be passed as function parameter and saved for later use. C aficionados now don’t have to envy C++0x—if they’re happy with the fact that it’s an Apple-only extension for now (Apple is advocating the addition of the extension to the C language).

It’s pretty fun. Read Mike Ash’s article for a summary of what blocks do. I just want to point out some gotchas:

Blocks live on your local stack. Fine if you pass them as function/method arguments in a local scope. If you want to toss them around, say save them for later use, you must make a copy.
Copying a block has the side-effect of making a copy of its current local variables. These local variables are henceforth consts by nature when the copied block is later invoked. This is a very important point to bear in mind. See the usage for __block modifier if you need vars to live beyond such local scope¹.
Objective-C objects inside a block are implicitly retained when the block is copied. The compilers supplied by Apple are smart enough to produce codes that send -retain to all local variables that represent Objective-C objects (in short, all ids) in a managed setting (i.e. non-gc) when you copy a block², so you really have something very close to a closure. On the other hand, objects are retained, not copied (it’s the pointer values that get copied, copy that?), so make sure you don’t fiddle with those objects unless you really want to (e.g. sending addObject: to an NSMutableArray object)—it might surprise you.
If you want to pass a block to a property, make sure you have declared the property as copy. No, retain won’t work, for reasons (1.) and (2.). You must use the copy attribute even if you are using gc.
Yes, you need to remember to release the blocks if yours are copies, unless if you’re using gc.
Debugging is gapless. Simply set breakpoints inside any block. The only exception that I’ve run into so far is when you forgot to copy a block, and you use the objects pointed by the local vars—there you get really bizarre crashes and the debugger is stopped in the middle of nowhere. You’re warned.

The block syntax has its own irregularities (different when you’re declaring a method argument, for example), but once you get past and get used to that, it really becomes part of the code’s blood. And at least in my case I couldn’t imagine how I ever lived without it. After all, many other languages already have it for ages—they are nothing new! Finally ye olde C has it. I do hope this extension will get accepted in the industry—standardization takes long time, but it should be a good one to add to the language.

This has consequences for C++ and Objective-C++ code that uses block. Copy constructors are invoked for C++ objects that live on a block’s stack when a block is copied. More about that in Apple’s document. ↩
This isn’t explained explicitly by Apple’s own document. If you go to read Mike Ash’s article, there’s a discussion about this buried deep in the comment thread. I’ve done the experiments and confirmed it behaves as such. ↩

Dido's Name

Sun, 13 Sep 2009 17:08:31 +0800

From the Wikipedia entry on her:

Dido was named after the mythical Queen of Carthage. As a child, she had to deal with the ambiguous and unusual nature of her name, which led to her being bullied and even to her pretending to have an ordinary name. As she explains:

To be called one thing and christened another is actually very confusing and annoying. It’s one of the most irritating things that my parents did to me. …Florian is a German man’s name. That’s just mean. To give your child a whole lot of odd names. They were all so embarrassing. …I thought it was cruel to call me Dido and then expect me to just deal with it. —Dido, Interview published in The Observer in 2001

It’s one of those funny things that can happen to your children after you have given them extraordinary names, and the effects can last long.

In Search of the Real Ideas

Sun, 13 Sep 2009 02:33:00 +0800

From The Economist, “Germany’s oddly vapid election”:

The German people are in a “very unusual” mood, says Werner Weidenfeld of the University of Munich. Past elections involved clashes of ideas and angry finger-pointing between the big parties. In the 1970s, recalls the professor, voters turned out in record numbers to cast their verdicts on Willy Brandt’s entente with the Communist east. In television debates voters used to ask leaders about the “society of tomorrow”. Today, they have “zero” interest in such lofty questions, inquiring instead about optimal levels for health-insurance contributions. In the depths of the biggest economic crisis in 70 years, many Germans feel that their country has weathered the storm well.

…

Alas, this crisis is deeper than German politicians admit. Germany’s social-market model still faces severe tests. It is specious to boast that it should be exported widely, even within Europe: Germany’s combination of wealth, wage discipline and post-war obsession with consensus is pretty unusual. Cosy, smug introspection may be right for a Bavarian country fair. Elsewhere, though, it is time for Germany’s leaders to debate real ideas.

It’s probably not just in Germany, but complacency is the keyword. It’s also probably true that in advanced, developed economies, division of labor has conferred the task of “imagineering” or “the art of the possible” to the politicians. The political systems in those economies have usually worked well in all these post-war years, and usually they are backed by both competent bureaucracies (such is the case in Japan) and strong, healthy economies.

I’m not so sure if our generation (specifically, those of us who were born in the 1970s), the generation that is taking up the baton of social and economic responsibilities, will ever be able to engage in those big actions.

We are probably seeing the ends of the “post-” talks there were so prevalent in the 90s. But that does not mean the “end” of things. No, no eschatology yet¹. But, like that article in The Economist says, people are probably more concerned with their health care and retirement pensions—admittedly also big issues—than problems at a larger scale. The problem now is whether we should ask bigger questions, because issues like health care and pension are really just manifestations of those bigger troubles, or if the system one’s having—here the term “YMMV” can’t be more appropriate—is still trustable and well-geared.

If you ask me to come up with a few big words quickly, the top two big items on my list would be like:

Whether economic development can be done without political freedom (the even bigger question: whether the values that we see as “modern” and in particular “Western” are universal, or are they relative): Would moral relativism prevail?
Will the pension scheme in my country go broke? I wonder if this is going to be a generational issue in many places in the world, where the schemes were designed long ago on premises that are probably no longer true today (e.g. assumptions on demographical growth, economic growth, promises to certain classes, etc.). I say it’s a generation issue because our generation is never consulted on those many designs². It’s a harsh scenario, but what if the pension scheme (again, YMMV and depending on which country you are from) is a Ponzi/Madoff scheme?

There are also a few Taiwan-specific big questions, naturally, although I won’t say we’re complacent about them (like the German people, who at least from the article seem to be confident in their tested system), but rather we’re paralyzed. The questions themselves (the “who are we, from where we have come, and to where will we go” questions) become an impassé and trying to ask those questions, meaningful and important doing so is, can make you an unpleasant dinner guest. So we actually face a meta-problem here: Whether it’s possible to have meaningful discussion on them at all³.

There are admittedly very difficult ones. But I don’t think we can afford staying where we are either.

For example, differences between this title to this title are telling. ↩
In this respect, the bigger question is whether our existing social contract would still hold. ↩
Although this again boils down to the Number One issue on my list. The faith in the meaningfulness of discussion (reads: open, democratic discourses) is itself the faith in certain solid values. ↩

"I know it’s ridiculous, but one of my favorite tweaks in Snow Leopard is that you can now have the..."

Tue, 01 Sep 2009 03:00:29 +0800

“I know it’s ridiculous, but one of my favorite tweaks in Snow Leopard is that you can now have the character palette/keyboard viewer option in your menubar without having to have a flag. It used to be that this option would be (in my case) the US flag, which looked silly as hell. Not any more!”

- Maniacal Rage

This is a bedtime story that goes wrong

Sun, 30 Aug 2009 02:11:00 +0800

At a divorce court.

Prince Charming: “Pay me alimony, and we’ll settle.”

Snow White: “But I’m a princess! A princess! No princess in history has ever paid alimony. You’re a man, be a man!”

Prince Charming: “But I’m not a man anymore! Remember?”

OpenVanilla 0.9.0a1

Wed, 26 Aug 2009 21:58:00 +0800

Zonble and I have released OpenVanilla 0.9.0a1 for Mac OS X today. OpenVanilla is an input method toolset. I’ve started the project with a number of friends in late 2004, and it has become one of Taiwan’s most important open source projects for Mac users. Its Mac distribution provides a replacement for Apple’s own built-in Traditional Chinese input methods, regarded as inferior to their Windows counterparts.

0.9.0a1 is built from the Oranje branch that Zonble and I have forked in late 2008. Our goal is to keep only the core and the most essential modules, and to modernize the code base, whose foundation was largely laid during our early days of dabbling with C++.

Personally I no longer use OpenVanilla. I now use Yahoo! KeyKey for my everyday text input. My company was commissioned by Yahoo! Taiwan in 2007 to create a cross-platform input method solution. Its design and architecture is based on OpenVanilla, but it also supersedes OpenVanilla in many ways. Take the Smart Mandarin input method for example. Also commissioned from scratch-up by Yahoo! Taiwan, it uses a database-driven, bigram-based engine that is capable of utilizing large corpus and search engine-provided terms. This is the input method with which I finally settle down.

Still, I’m glad to have been able to resume working on the core of the Oranje branch. It is also an example of using IMK-Tiger to produce distribution packages that support both 10.4 and 10.5/10.6.

In essence, 0.9.0a1 is a more developer-oriented version, with the focus on the core (framework, loader, essential modules). With our limited resource and time, polishes needed for end-user distribution are mostly left out to future developers who want to continue OpenVanilla’s development. For people who choose to use OpenVanilla because it’s an open source solution, on the other hand, 0.9.0a1 will bring timely update to the software itself, especially compatibility with Mac OS X 10.6.

A Very Short Note on Why C++ Is Not Suitable for Plug-In Architecture

Wed, 19 Aug 2009 14:30:00 +0800

Plug-in architecture is where reality meets textbook and language purity. It’s a practical problem because:

You probably own the architecture, but you don’t have control over others who develop the plug-in’s
Your project is evolving, their projects are also evolving.

Following 1. and 2., the logical next step would be coming up with a design that keeps both parties in sync with an agreed “contract” (protocol, interface, whathaveyou). Unfortunately:

Even the “contract” itself can evolve
C++ is notoriously bad at keeping up with evolving contracts. It has the notorious fragile base class and fragile binary interface problems. In some extreme cases, you can’t even use different versions of the same C++ compiler and toolchain to build the different parts of a system under the same contract!

C++ is not alone in this, although C++’s problems are the most glaring given its popularity as a system software language and its promise to be such a language. Unfortunately, plug-in architecture, or anything dynamically loaded, involves system components beyond language features (its problem domain lies somewhere in the middle between operating system and software architecture design). This in turn explains the unfortunate reality why C is still the real language for system software, especially system software libraries, because C is the only language that has such a thin and straightforward application binary interface (ABI) for all seasons and all purposes.

webOS and Game Development

Tue, 18 Aug 2009 02:00:46 +0800

webOS and Game Development:

stevenf:

Maybe I’m being cynical but that strikes me as not at all auspicious for Pre users who enjoy games.

It’s self-defeating indeed.

Typhoon Disaster Exposes Ma Ying-jeou's Incompetence

Thu, 13 Aug 2009 12:30:00 +0800

Chiang Chun-nan (江春男), on Apple Daily News (蘋果日報), excerpt and translation:

如果「救災如作戰」這句話是真的，那麼馬英九這個三軍統帥實在太令人擔心了。他似乎不知道自己有指揮權，他一個人到災區，什麼都沒帶，只帶著一顆愛心而已。在台灣遭遇重大災難時，馬英九的領導能力被人看透透。

…

處理重大危機，在總統府由國安會負責，在行政院有國土安全辦公室，多年來，他們努力建立災害應變機制，地方與中央接軌，資源的整合調度，指揮系統的建立，各種應變劇本，定期動員演練。可惜，這套機制在馬政府上台之後，不是放棄就是投閒置散，現在終於吃到苦頭。

真正的關鍵還在指揮統御，如馬英九有足夠的領導能力，就會找對的人，做對的事。在這方面，他與李登輝或宋楚瑜均不可道果計，跟陳水扁，也沒得比。

設想有一天，兩岸發生危機，馬英九有能力處理嗎？天佑台灣！

If the military tradition “disaster relief is war fighting” still holds true, Ma Ying-jeou makes a terribly worrisome commander-in-chief. He doesn’t seem to realize that he’s in command. He went to the typhoon-struck area on his own behalf, bringing with him no one of significance but only his own kindness. Taiwan was hit by such a large-scale disaster, and Ma’s leadership is nakedly exposed.

…

Crisis is handled by different levels of government institutions. The president has National Security Council at the his office, and the Executive Yuan has Homeland Security Office. For many years in the past they had spent efforts on building up a disaster response mechanism, bridging local and central governments, integrating logistics, and establishing the command system. They had prepared scenarios and mobilized regularly to drill the system. Unfortunately, these workings were either abandoned or left to idle after Ma took office. Now the government is paying the price for such negligence.

The key problem always points to Ma’s own leadership. Were Ma a competent chief, he would have put right people into doing right things. In that respect, he is not even distantly comparable to former persident Lee Teng-hui or former governor James Soong. Neither is Ma on par with Chen Shui-bian, his immediate predecessor.

All these leads to the question: Suppose one day crisis breaks out between Taiwan and China, will Ma Ying-jeou be capable of handling it? Only if God blessed Taiwan!

Dangerous Advice

Thu, 13 Aug 2009 02:48:00 +0800

Aaron Hillegass recommends making your UIKit IBOulets weak references. Don’t.

Hillegass’s main argument is that Apple messed it up when they changed the way IBOutlets were associated when an nib is deserialized. On desktop, only the topmost view is retained, all other IBOutlets are weak. On iPhone, every IBOutlet is retained in the beginning. You have to remember to release them when (1) your top-level view is released, (2) when your controller receives -dealloc, of course.

While it is true that Apple did a terrible documentation work in 2.2.1, resulting in that us developers have to go through this clean up hack, and the -viewDidUnload: method that is added to SDK 3.0 is still not well documented (for example, Apple doesn’t tell you when your controller receives -dealloc, no -viewDidUnload: was called before that), but telling people to make IBOutlets weak simply because it’s “idiotic” is dangerous.

In terms of memory management, an iPhone view controller differs from its Mac counterpart in two most important aspects:

The view object is loaded on demand, and unloaded without prior notice (on 3.0, you only get that notice, -viewDidUnload:, after it’s a fait accompli.
Your controller will receive -didReceiveMemoryWarning, but the order in which it’s received is indeterministic¹. It can happen any time, in any order, at any frequency, depending on system load and demand.

So wait until your app goes multithreaded, or until when your apps needs to update UI states when their parent view is gone, or simply when you have controllers in a tab bar.

Yes, it’s always a good practice to zap all your IBOutlets to nil in all of the memory management methods. The problem is you will more easily forget doing that if you’re using a weak reference. Until when your app starts to crash in the middle of nowhere.

If you observe Apple’s iPhone coding style, you’ll find Apple advises developers to make all their IBOutlets properties. There’s a reason for that. For, if you do, and you just forget zapping them² in -viewDidUnload:³, the worst that can happen to you is you have unreleased IBOutlets until the view is loaded again. Even Hillegass acknowledges this:

(OK, I just reread this and realized that the reader might get the idea that the retained views are leaking every time the view is unloaded. It is not quite that bad. A retained view will linger until the view is reloaded. At that point, it will be released as a side-effect of the setValue:forKey: that gets called when the outlet is set again.)

So in fact the biggest source of iPhone app memory leak is not caused by the reasons that Hillegass disparaged. It’s often because developers forget *they’re responsible for the objects created in -viewDidLoad: and forget doing that in both -viewDidUnload: and -dealloc (-didReceiveMemoryWarning is more suitable for releasing and nullifying data model objects or cache objects). Instead, Hillegass suggested a “workaround” that does not help—it actually hurts. The memory leaks caused by your oversight will actually remind you to clean up. With weak references, there’s no such problem—until it resurfaces as other bugs that are even harder to tackle.

And Craig Hockenberry actually already explained why you can’t leave weak references back in 2.x days⁴.

I don’t take side on the recent dot syntax “debate” (summary of which can be found here). I can understand the case against it on pedagogical reasons—but that’s pretty much where my sympathy stays. Hillegass’s new advice, on the other hand, is both counterproductive (it doesn’t identify the rationale and iPhone’s design needs) and outright dangerous.

SDK on iPhone does not work like they do on Mac for a reason. Hillegass’s advice totally missed on that.

Your view controller stops receiving -didReceiveMemoryWarning only after you call [super dealloc]. It’s entirely possible for your view controller to receive that message between your dealloc code and [super dealloc]! ↩
One fine detail though: Using properties to nullify them is discouraged, although there’s usually no harm, in -dealloc. Even Apple sample code does that—though not that it means it’s the absolutely right way to do. We use a macro internally. ↩
Here I’ll skip the details if you want everything works on both iPhone OS 2.2.x and 3.x—which some of your clients may still require you to do. Just remember -viewDidUnload: is not called before your controller receives -dealloc on OS 3.x. ↩
I have also written something on this: “iPhone View Controller Memory Management in a Nutshell”. ↩

Cultured Code's Non-Roadmap for Things

Wed, 12 Aug 2009 22:58:38 +0800

Cultured Code's Non-Roadmap for Things:

I see “performance” there. Good to know!

Good Backend Performance Is This Long-Term Thing

Wed, 12 Aug 2009 12:41:00 +0800

I never looked back at the diverse ways I managed my to-do lists after I bought Cultured Code’s Things. I first bought their iPhone version (USD 10) then the Mac version (USD 50)¹. It’s very well designed, straightforward to use. You don’t need to be an expert of David Allen’s GTD methodology to use it². Things for Mac earned an Apple Design Award this year, and I think Cultured Code deserves the honor.

Still, for all my love and appreciation for the app, it exhibits two long-term problems:

Its data sync between the Mac and iPhone apps is terribly slow and unreliable. Sometimes it adds peekaboo items that were long dead, done or cancelled. Sometimes it adds blank items that actually bear titles. Sometimes it even misses some items. This part is improving, but some occasional glitch can still happen.
Both versions are already painfully slow after 6 months of use. I always have around two dozens of projects at any given time, and complete on average about a dozen of items every day. Juggling items around projects quickly become a slow drag: UI becomes unresponsive, the waiting time, especially the perceived time, is horrible (to the extend I already have developed anxious reflexes when I undo or move items).

I suspect part of the problem is Things is not backed by a super fast data mode, and its current backstore has a scalability bottleneck at around 1k items. The situation is certainly improving, and I believe the developers at Cultured Code are working hard on that. Still, I estimate they need to perform big overhaul on the backend in order to boost the performance.

That’s the flip side of an application with such a great user interface, though. And Things is not alone. Many Mac apps seem to share this backend problem, and while their interfaces make you fall in love with them at the first sight, using them in the long run is another matter. This is when catching up in that part becomes crucial. iPhoto, for example, has been a laggard. Its performance is not stellar. Picasa for Mac, on the other hand, is a super fast roadrunner even with a huge data set, but its interface on Mac is terrible³.

Good user interface only gets you this far (admittedly the business goal is already achieved). The halo effect of good UI wears out after using it for a while, and then you take it for granted. Bad backend performance, on the other hand, can only aggravate the pain as the time goes by, and the problem grows. A good application has to excel at both⁴—hence all the more challenges for software developers.

It turns out I use its Mac version way far more often than its iPhone version. The iPhone version, a premium app given its “exorbitant” price in the one-dollar ecosystem that is the App Store. The iPhone version now mostly serves as today’s to-do list and a quick inbox when I’m on the road. I seldom use it for tasks more complicated than those two. Two observations: First, Mac app can sell at a unit price far more than “premium” iPhone app. And, for all the talks on how (first web apps, then) mobile apps will kill the desktop, in many cases the role of the desktop as the flight carrier is only reinforced. ↩
The book Getting Things Done is a perfect example of the problem of book writing described in this essay by Philip Greenspun. In short, it’s just an idea that’s worth 20 pages, but you have a book with later chapters that are, to say with an understatement, less than insightful. The best part of Allen’s book is its first chapter, in which the author gives you a historical perspective on the origin and evolution of to-do management. Similar things can be said of Merlin Mann’s inbox zero and many other self management techniques. ↩
Picasa’s user interface is terrible, Windows and Mac. It’s a total mess down to the level of its information architecture and data set design, and its interface only faithfully reflects the confusion of an app that tries to be your photo album manager, photo files (actual files residing on your file system) manager, and a syncing tool to its eponymous web service at the same time and can’t decide what to highlight. ↩
Developers who are good at UI can be bad backend technicians. Backend wizards can be terrible UI designers. I don’t know which is harder though—for the UI wizard to come up with reasonable, long-term backend design, or for the backend wizard to come up with visually acceptable and actually usable interface. ↩

Push Notification and MS-DOS TSRs

Tue, 11 Aug 2009 04:33:00 +0800

You’ve probably never heard of TSR until now. Good for you. Back in those MS-DOS days, TSR was the only way you could have another program running (or faking running) in tandem with the foreground application (there’s only the foreground, sorry). That’s how, back in those days, people could have calendar, calculator, memo, and address book¹ when working on their Lotus 1-2-3 spreadsheets.

In retrospect, TSR is a pure hack. You must intercept some of operating system inner workings, hook onto them, and do the dirty job. I wouldn’t be so confident in saying this if I had never written some. I did—and to be honest hacks like those made even the most trivial and straightforward application bloatedly ugly and complex. If an alarm clock is some 300 lines of assembly, a TSR version would grow to double or even triple of that², and they often sucked, loved crashing your system, and never worked well with others, competing with others (other TSRs!) when it came to screen estate and RAM.

The whole point is, because MS-DOS was not a real operating system, people had to go through those hacks.

Let’s fast forward to 2009, one year after iPhone SDK was first announced, and Apple finally got its push notification up and running, despite a year late.

All’s well… except one thing.

Apple could have come up with other designs so that we don’t have to rely on an over-the-Internet push notification system to achieve some damn basic stuff.

For example, there are reminder apps that use push notification to pop up reminder messages when it’s time. While there’s always a need for such kind of app, and iPhone didn’t really have a good one (its own calendar doesn’t cut).

But we have to build a whole backend, server infrastructure to store user to-do’s and send push messages over the Internet to pop up a simple reminder? That’s insane.

I didn’t mean to say those app developers have lost their mind. No. Their efforts are noble and great, serving users’ need, answering to market demands, filling a gap. Just like those MS-DOS TSRs, people actually love using them.

The fact is, even if Apple keeps its no-background-process policy, there can be other ways for doing exactly the same thing for less. Way less. Building up the whole server infrastructure thing just to work around an OS gap is no fun, is downtime-prone, and is expensive³. Let’s say if Apple now has an alarm framework, sending local notifications (there are such thing—NSNotification is on iPhone, NSDistributedNotification on Mac) to subscribing apps. And why not? iPhone already has a settings framework (not many love using that, for sure). So it’s not hard imagining why this can’t be done. The same could be said of many network apps (instant messengers, for example). A subscriber model can even give the OS some power to enforce some power policy over the consumers.

And hey, if it’s not that they hadn’t done similar things before. Remember desktop accessories? And at any rate it’s far less hack than MS-DOS TSR. Or a mechanism that depends on so many things (Internet, your server infrastructure, Apple’s server infrastructure, telco’s infrastructure) that the whole functional equivalent could just live on the user’s damn phone. But such is what Apple excels at: Selling you an inferior technology (push notification), but touting it as the right and enlightened way to solve a big problem (multitasking) that everyone else has pretty much solved⁴.

At least back in those days Microsoft didn’t say it was a good practice to fake illusion of multitasking by hooking up to its system services…

Borland made its fortune from such an application. ↩
I’m never an assembly language buff, and I know there’d be people who said they could do such and such in number of lines far less than that. Let’s just use the number to put things in perspective. Arguing how much you can do with how few lines is, pleeease?, so 1980s. (Disclosure: I wasn’t even 15 by the end of that decade, so you would sound even older than I do now). ↩
Plus, push notification sucks. It makes bad—extremely bad—user experience. Try letting your friends AIM you a few lines while you’re busy reading your email, and you’ll realize how bad is it. Run a few more push notification apps in the background, er, I mean, having more push services around, and they start to compete your screen estate. Sounds familiar? ↩
Actually, when it’s done right, inferior technology doesn’t matter. People just don’t care what iPod’s competitors say it’s nothing special. And Apple can do many things right, even with “inferior” technology. But let’s face it: Push notification just doesn’t sound convincing at all. ↩

TapExpense 2.3

Mon, 10 Aug 2009 20:53:05 +0800

Note: This is a cross-post of the same announcement on my company’s blog

TapExpense 2.3 is now available on the App Store. For the past few weeks we have been tidying up the code, and we’re happy to say 2.3 works perfectly on both iPhone and iPod Touch (all models) on OS 3.0. (Not that the previous version didn’t, but there were a few UI wrinkles that we wanted to iron out, and we did).

Here’s what’s new in 2.3:

Calculator keypad. This has been one of the most frequently requested features, and we now have a calculator built into TapExpense. The simple keypad is still the default—go to the Tools tab, and use the “Numeric Keypad Type” setting to switch between the two keypads. We believe this is very helpful when you’re sharing bill with friends, or when you’re traveling in countries where people pay tips¹.
Landscape mode can be now disabled. This is another frequently requested option. Some people even suggest that Apple should have a global setting on this—because not everyone loves the landscape mode when they’re reading on bed!
There is a new report grouping type called “(Payment) Instrument, then Category”. With this grouping type, it’s easy to see how much you have spent on each payment instruments (credit cards from different banks, for example), and on what.

And we have fixed these bugs in 2.3:

XLS Export’s date problem. Some of us have noticed that the exported spreadsheets can sometimes have wrong dates—all of them exactly one day later than the saved date. That was caused by a miscommunication between the client-side and server-side code of our exporting mechanism, and is now fixed.
Currency converter bug when in European locales. Our currency converter didn’t behave well when TapExpense was run in an European locale that uses comma (“,”) as the decimal point. European locales worked otherwise well in other parts of our app—it now works anywhere in TapExpense.

Finally, we have made a few adjustments in the user-interface. Before, for example, when we wanted to edit an entry’s cateogry, the category list didn’t “jump” to the chosen category right away, therefore requiring some scrolling on our part. Now TapExpense always shows you the currently chosen item in the list (category, currency, group, and so on). There are a few other minute fine-tunings like this. The “Settings” button in the Report tab was too misleading (many of our users didn’t realize they could use customized date range—not just by month—with that), therefore we now have renamed to “More”.

That’s TapExpense 2.3. We’ll keep working to make it work better for you. As always, let us know if you run into any problem, or if you have suggestions—write to us at: service at lithoglyph dot com. Thanks for the waiting!

Service is almost always included in the bill here in Taiwan. Some restaurants do specify they charge you a 10% to 15% extra. ↩

Why Upgradability Is Hard: An Overview

Sat, 08 Aug 2009 14:20:00 +0800

In an ideal world, the system only makes forward progress. Each version (or revision, year model, or other equivalent terms and concepts) is carefully planned, and all consumers (or users, receivers, or other equivalent terms and concepts) upgrade the system accordingly:

Unfortunately in reality things are complicated. If the system is a distributed one (i.e. each consumer has their own copy), this is what might happen. This is especially so when a provider (manufacturer, developer, seller, or any other similar concept or term) runs a policy of planned obsolescene—somethings out of practical reasons like inventory control, and users who are still using V₁ will then have no choice but to upgrade directly to V₃. Any system that does not have such “jump-start” plan at Day 1 is awaiting disasters.

Although this is often an argument against desktop application (contrary to “web apps”), remember the complexity is either shouldered by the end user or the provider. Plus, if end user has, for example, downloaded data, then data format also has the same problem. Not even web app can escape this systematic challenge.

Things are even more complicated then the end user is given the freedom to downgrade. The upgrade path now needs to take both downgrading and jump-start upgrading into consideration.

A “patch”, or “service pack” in some software vendor speak, is something that amends, fixes or enhances certain parts of a system (usually software, but this does not only apply to it). Although we may imagine enough patches accumulate to, culminate in, or simply “morph into” another full version, it is often not the case.

Suppose we only allow forward upgrade here, and jump-start upgrade is only allowed on versions but not patches, the number of possible upgrade path in the example here is 12. The number only grows exponentially as the number of versions and patches goes up.

Excerpts from "A Taiwan that Awaits Defining" by Professor Wan-yao Chou

Thu, 06 Aug 2009 23:03:00 +0800

Professor Wan-yao Chou (周婉窈), of Department of History, National Taiwan University, expresses her reaffirmations of Taiwan’s pursuit of democracy and freedom and the efforts to understand its past, and her refusal of a superimposed historical narrative, in a commemorative article written for the 28th anniversary of Dr. Chen Wen-cheng’s death. Dr. Chen is believed to be a political victim of Taiwan’s Martial Law government, but his case has never been seriously investigated even as of today.

The full text of Professor Chou’s article, in Mandarin Chinese, can be found here. Here is a tentative English translation of the ending paragraphs:

民主、自由和人權，有可能成為臺灣社會如磐石般的核心價值嗎？過去一年多以來，一方面臺灣民主自由體制似乎出現逆轉的危機，另一方面，從去年三月十四日以來，中國對西藏的鎮壓持續不斷，因此臺灣的遊行、靜坐、絕食等活動似乎非常頻繁。我認為，在每次支持西藏、中國、緬甸，以及世界其他地區的自由人權活動中，我們再度肯定我們的價值所在，強化我們捍衛它的決心。

Democracy, freedom and human rights. Do these have a chance to become Taiwan’s core values, values that become a house built on a rock? For over a year now, the democratic institutions and the freedoms in Taiwan are eroded. At the same time, since March 14, 2008, the Chinese government has been continuing its oppressions in Tibet. A lot of demonstrations, sit-in’s and hunger strikes against such oppressions have taken place in Taiwan. I do think that, every time we stand by these human rights campaigns in Tibet, China, Burma and many other places in the world, we reaffirm what we value, and we strengthen our determination to defend these values.

臺灣是一個奇怪的地方，運氣特壞。我自己研究歷史，可能所知有限，但好像還沒看過一個類似的例子。一八九五年，這個遠在中國東南海上的「蕞爾小島」，未遭中日戰火波及，卻突然被清廷「永遠讓與日本」。臺灣人不接受這樣的命運，為了保鄉衛土，浴血抵抗，但欠缺奧援，最後只有認命。在日本統治半世紀之後，經歷近代化和殖民地化的複雜歷史過程，在絕大多數人毫無心理準備之下，又突然被盟軍交給中國。如果這個中國是個統一的中國，或許還好，臺灣人誰又知道「國共鬥爭」呢？戰後初期臺灣的漢人知識分子和青年怎麼懂得這些呢？原住民更是無從了解了。沒想到國民黨被中共打敗，「播遷來臺」，以統治一國的軍政情治裝備支配這個島嶼，臺灣捲入「國土分裂」下的國共鬥爭中，成為反共抗俄的復興基地。我們這一代人在黨國教育下成長，終於了解到何謂「國共鬥爭」，沒想到六十年後，不共載天的國共兩黨竟然熱絡攜手合作！好像歷史特意嘲弄臺灣人。

Taiwan is an odd place, as if star-crossed. I’m a researcher of history, my knowledge has its limits, but so far I don’t see another place that has similar history. The island, situated in sea south-east of China and seen as a “minuscule, negligible island”, was never involved in the Sino-Japanese War, but was “perpetually ceded to Japan” by the Qing government. Many Taiwanese didn’t accept such fate. They sacrificed to defend their land, but to no avail because they didn’t have any outside support. They couldn’t but accept the fate. Then, after half a century of the Japanese rule, after the complex historical process of modernization and colonization, just as hardly anyone was prepared for that, Taiwan was handed again to China by the Allies. It might have turned out better if the China to which Taiwan was handed had been a unified China—for which Taiwanese would know what the Kuomintang (KMT)-Chinese Communist Party (CCP) Struggle was really about? How would Han intellectuals and youths in Taiwan during the early post-war days know that? Let alone the indigenous people. They didn’t anticipate that Kuomintang was defeated by the Communists, and “temporarily moved the government to Taiwan”. They didn’t anticipate that Kuomintang would dominate Taiwan with a military, political and intelligence apparatus designed for ruling one big country. They didn’t anticipate that Taiwan became involved in the KMT-CCP Struggle whose central theme was a “split country”. And they didn’t anticipate Taiwan became the “Resurgence Base” in the anti-Communist and anti-USSR front. Just as when our generation, growing up under such a party-state education system, finally learns the truth about the KMT-CCP Struggle, how shocked we are now to learn that the two parties, archrivals of the past, are now hand-in-hand flirting with each other! It seems History likes mocking us Taiwanese.

此刻的臺灣，尚待定義。不，更確切來說，正面臨重新被定義的危機。或許，我們好不容易獲致的多元文化的思考，將再度一統化；或許，我們的子孫將在課堂上大聲誦讀：「臺灣自古就是中國神聖不可分割的領土，西藏也是、新疆也是。」或許，那個外於臺灣歷史過程的偉大史觀終將再度決定我們怎樣思考、看待這塊土地的過去。陳文成三十一歲的死亡，無庸說，再無究明真相的可能；他被迫縮短的人生也將不具任何意義。解嚴以來的歲月也將成為暗黑長路中偶現的光景，如夢幻泡影，如露亦如電。

Taiwan at this moment awaits defining. No, more precisely, Taiwan is facing a crisis of coerced redefinition. It could be probable that the diversity and the freedom of thought, things which we finally manage to enjoy, would once again become homogenized. It could be also probable that our posterity would read loudly in class: “Taiwan is an inseparable part of China’s territory since antiquity. And so is Tibet. And so is Xinjiang.” It could be probable that the Grand Historical View that was outside of Taiwan’s historical process would come back and once again determine how we think and see our land’s past. The truth about Dr. Chen’s death at 31, needless to say, would then become an impossibility. His involuntarily shortened life would also become meaningless. The light that was shed on the long, dark road of the Martial Law years would turn out to be an illusion, a dream, a morning dew, a short lightening in the sky.

如果我們不要這些「或許」成真，那麼，我們必須堅持自己定義臺灣，我們內部可以衝突矛盾，可以歪纏爛打，但是，我們拒絕由外在的力量（或外力加內部少數人）重新定義臺灣。作為研究臺灣史的我，雅不願看到外於臺灣的史觀指導我們如何研究自己的歷史，我們的先民不是沒反抗過日本（武裝的、非武裝的），但是日本的殖民統治得由這塊土地上的人透過嚴謹的知識方法予以了解、予以評價。或甘苦參半、或愛恨交加、或曖昧矛盾，我們可以論證、論辯，但不要告訴我，我得怎麼看。戰後六十多年的歷史，影響今日臺灣非常深遠，我們才剛開始理解，不要告訴我，我們的苦難，我們的被剝奪，是為了成就一個「偉大民族」的必要犧牲。

If we don’t want to see those “probables” become real, we must then insist that we define what Taiwan is. Internally, we can disagree, we can challenge each other, we can fight the dirty fights. But we must resist the redefinition of Taiwan by any external force (or any external force plus internally fomented factions). Myself being a researcher of Taiwanese History, I refuse to see that a historical narrative outside of Taiwan dictates how we research our own history. It’s not that our forebears had not resisted the Japanese (armed or not). But Japan’s colonized rule in Taiwan can only be evaluated by the people living here, with rigorous methodologies and studies. The past could be bittersweet, love-hate, full of ambivalences and contradictions. We could argue and debate. But we will not allow anyone that dictates to us how we should see our history. More than sixty years of the post-war history has profound influences over today’s Taiwan, and we are just at the beginning of understanding it. We must not let anyone dictate to us that all our sufferings, all our dispossessions, are merely necessary sacrifices to form a part of a “Great Chinese Nation.”

臺灣尚待定義，但不要告訴我，她只能等待再度被外力重新定義。

Taiwan awaits defining. But I will not let anyone dictate to me that, Taiwan deserves no choice and should accept redefinition by a superimposed force.