The Old Blog Archive, 2005-2009

Continue the journey where he once dropped

I wrote my first database application at 11. I was in the sixth grade, and the homeroom teacher needed a way to calculate the scores of each student fast. He was himself a computer enthusiast, first among a new generation of young teachers in Taiwan in the mid-1980s. The school had an early PC/XT (the Taiwan-made pirate clone, of course) at his disposal, and he knew one of his students had some gift on making computer work. And that seemed to me, as far as I could recall, how the journey began.

Before the teacher used Lotus 1-2-3. If all you needed was quick statistics, simple averages and sorting, that could be the best tool you needed. But Lotus 1-2-3 was not about bulk data entry and processing. The early day version didn’t have good group features (later features like pivot tables solved the problem), and the early version didn’t go with Chinese characters well.

So I wrote a program with dBase III, then the most popular, generic PC database application, and we had run two semesters of scores with it. I heard the teacher continue using it for another few terms, with only minor modifications.

Then for the next two years I wrote another few database applications, all in dBase III and one eventually compiled with Clipper. I can’t recall every one of them, but the list should include a business contact database, a department expense database, and a clinic patient record database. They all come with a visual user interface, form validation and all. The last of them, the clinic’s database, had been put in use for at least 5 years and had kept about 20,000 unique patient’s records, quite a number for a local clinic.

About 20 years later, during a casual talk, mom mentioned this in passing: “I marveled, why were you able to do the programming?”

Honestly I didn’t know and I don’t know.

Should I say it’s in the blood … I still remember the three dBase III books that dad bought for his reference at work, because they started introducing it in their company, and one thing that dBase III was different from similar PC database applications was the programmability, even if it came with crappy language design that was in the middle of no where and performed badly. But it was programmable, malleable and could be bent to the will (slightly) of a 11-year-old. It was magic, among other magical things like MS BASIC, Turbo C and Turbo Pascal.

Only after 20 years am I now finally able to untangle many of the unhappy consequences because of that–being able to do programming at such an early stage in the mid-80′s Taiwan. I mean, come on–it’s not such a phenomenon now, if we hear now in the late 2000′s that your neighbor’s kid knows programming in Python or Process or Mathematica or even in C (I do admit that knowing C deserves more of my amazement though). It’s not even a thing that you tag with the term “whiz kid” anymore.

But I just don’t think that’s what happened to me or to a few kids that I knew personally during that time.

If you knew programming as a kid in Taiwan in the mid-80′s, what was brought out of you could be determined in either of the three family settings. Say you are from a very good family, and your parents and relatives happen to know other people (e.g. university profs) that know what to do with it. Or you are from a rural family where your parents aren’t college-graduated and they have not a clue what you are doing.

I personally prefer the latter–although never is such thing a choice that, in the mid-80′s Taiwan, it was way better if your parents didn’t know the nature of your doings and you were simply left alone. I find–subjectively and biased though–that most people I knew that belonged to that category did the best. Not necessarily in terms of achievement, but in terms of that they later took the path of becoming a programmer or dropped it as some experience (like being able to play guitar or piano, albeit never professionally) and could smile at it.

The former wasn’t that bad either, but not as good as the latter. Chances are you were thought as a kid good at math and sent to the so-called class for the talented students (we have lots of that kind of thing in Taiwan), or if your parents were business-savvy, your software was packaged and sold. And if your parents were really, really business-savvy (that is, unlike many Taiwanese who blow their easy-come fortune), the money earned from your software would be put in trust, invested other things, and you started a software business world from that modest beginning.

Well, if I do the categorization, I’d say my family belonged to the third kind: somewhere in the middle. My parents didn’t really know what to do with it, but being upward mobile middle-middle-class in the mid-80s, they thought–or they took the advice from their peers–they could do something out of it, to the worst combination.

So here’s the ugly thing. My late father used the database software I wrote to try to help his colleagues or superiors. Actually, other than the business contact program which I willingly did for him, the other two apps were results upon his request. Not that he forced me to do it–I did have developed them with pleasure and fun.

The problem was I was paid naught, except for some perfunctory praises. I don’t think he got paid too, in the form of the due value, other than the imaginary “good karma” in the course of career-wise promotion.

20 years later, I have a better idea how much the app probably valued. A PC/XT clone, with 640 KB of RAM and a 20 MB hard disk drive, could cost at today’s equivalent of USD 3,000-4,000, a handsome sum. In the mid-80s the doctors were among the most affluent and most technologically savvy class in Taiwan, and they were indeed among the first to introduce personal computers into their clinics. A well-made database application, I was told only later, could be easily sold at USD 5,000-7,000 alone (again, at today’s value) and there was a demand for such packages–because there weren’t many during that time. This all excluding service (though then a rarely-heard concept), upgrading, maintenance and all.

I did have mentioned this to my dad when he was still alive, and later to mom when she mentioned all this in passing.

I can actually understand why we arrived where we were. Dad conceded that running a software business out of it wasn’t on his mind at all. He was, after all, trying to secure a job and working upwards–even if that meant he had to please his superior with what he had at hands. For example, I still remembered that I was brought to fix one of his boss’s computer at 11pm, reinstalling Windows 3.0 with early-day Excel and DOS-boxed Lotus 1-2-3 and all. I don’t think I was duly appreciated, and neither was my dad.

And mom said, “Son, really, we didn’t know what to do. And you never knew what you’d become even if you had your business plan running. I meant, it was in the 80s, and many whiz kids who earned their fortune did not end up well. Many of them even became lost because of the early fortune and the talent. Ours was not a culture that knew how to treat the precocious gifts well. We’re still learning, son.”

She’s right.

With hindsight, I wasn’t really troubled by all those under-appreciations that had to do with my database app. It was only after when I got into high school was I then told that writing database app was about big money (at least relatively big to a high school kid–you usually didn’t get a good bargaining because people thought it was written by a kid) and this or that senior of ours had made some money out of it. But database app written in dBase III or Clipper or FoxBase (later FoxPro) was despised by peers, because real high school kid learned C++ (then a novelty) and chewed on OOP jargons and boasted their male prowess in assembly language, among many other things (like sports, at which I am eternally awkward).

And then there were other teenage teethings and the troubled youth that I had. Some of them was still caused by the fact that I knew programming, because many teachers thought I should be good at math but I flunked high school math every semester.

I still did quite lot coding, first in C and later in C++, did come up with a few utilities, some half-baked full apps, even a never-finished interpreter of BASIC language with OO add-on’s.

But I was told, sometimes insinuated, that I was simply and totally unfit for computer science even if that was what I wanted to study at first, then even dad opposed vehemently too the idea of doing CS because he associated the study of computer with the drudgery of PC clone sales and probably (this I gathered only years after) the worthless programming–tinkering–that his son had done for his thankless superiors.

And in-between I had read some algorithm and data structure textbooks, read about system software programming and operating systems, computer graphics and software engineering, even some introduction to compiler implementation in C, some by myself, some with the help from a kind senior or teacher. I must have had glimpses of most parts of sophomore or even junior CS classes, but probably didn’t know when I read them, and throughout wished I had attended a vocational school (which my parents looked down upon, but I really fantasized countless times), because then I could have become more craftsman-like without the need to pass the math, which I flunked, six semesters straight, and being told that as a general high-school student, I was not fit for something I was simply able to do.

I finally gave up programming in 1995 after having finished my first year at college–I then majored in geography–and having passed calculus with passable grades (which healed my trauma about high school math). I did find some new passion in human languages and applied for transfer to do foreign langs. Probably once again without much bitterness just as I didn’t think too much about those database apps. But I did have thought that probably I would never do programming again. I did have closed the books, literally, by throwing or giving away every computer textbook that I had possessed before I was 18.

Thirteen years later, and after having run for the first one year my own software company with client projects and our own products humming, and as we have a modest beginning, and as I didn’t thought much about the efforts in doing the actual coding work and as mom mentioned in passing her surprise at how I came back, continuing the journey from where I dropped, and I thought, that dad would be proud, and that I have found something back, after all those years on the long and winding road.

Can Tourism Buy Us Some Little Sense of Belongingness?

Lately the biggest change in my house (where I live with my mom and bro) was that we canceled the cable and subscribed to a local ISP’s media-on-demand service. We now pay a fraction of the monthly fee. We have less channels, no 24-hour local news, but we get the extra. We now have things like DW-TV (Germany), TV5 (France), BBC World, Bloomberg, Arirang TV (South Korean, in English) and Aljazeera. The media-on-demand service isn’t top-notch, but it’s like what I think Taiwan should always have had 5-7 years ago. Anyway they fit into my taste, and I happen to be able to watch the German and French channels.

The other day I was watching TV5, and I noticed the program, a science and technology one, was made by CBC, the Canadian (quasi?) equivalent of BBC. It talked about transportation technology and the cityscape of Montreal came on screen.

Plan du métro

I visited Montreal a few months ago and was in love with the city. But my affairs with cities are not confined to that North American gem. Such is the up side if you plan traveling yourself.

One thing I find, this being very subjective, about the cities I love is that they have this or that quality that I want to call it home–if I can overcome the hurdles of not just being a visitor.

That’s probably som sense that plain tourism can’t emit–the type of tourism, of joing a tour, that we are familiar with. The appeal of a place can come ironicaly from some travails you undergo on the road.

I’m not sure how those cities do it. They don’t seem to try very hard on being a places people want to call home–or if they try, collectively, they aren’t trying too hard that we see the trace.

On this I reflect on what we do in Taiwan, especially when the government and the tourism industry are calling for more visitors and more revenues generated from tourism. Now I measure the success (or not) of such endeavor by if someone recalls a good trip when s/he sees streetscape in any Taiwanese city and starts to want to call the place home, among the many choices and city affairs the person has in life.

Against To-Do Lists

I always have problem with the various methodologies that teach you organizing your own to-do lists. I often wonder what the to-do list of an achieved artist, architect or designer looks like. I even wonder if they ever come up with to-do lists at all.

Don’t get me wrong. It’s not that I don’t make to-do lists or I suspect others don’t. As a programmer I can’t value the tools too much. Many professions, software development included, require team work and project management. You need all kind of techniques and measurements to ensure the things get delivered.

But I sometimes really question the philosophy of compartmentalizing your core activity, what to-do lists or what the more sophisticated (and widely marketed) schools teach you.

The problem is many activities, creative ones especially, are not the ones you can desire. There are, if you listen to yourself careful enough, I believe, moments in life when you don’t feel the pressure that you have to do this and this in order to reach the goal. There are moments when you just feel the urge to do something. And there are, sometimes, those very rare moments when you just do something, and only after its accomplishment that you realized you did it. When such moments come, be they the “feeling the urge” mode or the “post hoc realization” mode, any to-do item becomes self-evident and natural, and there is no such “I have to do this” pressure on it.

That’s why I wonder what people’s to-do lists look like. I’ve tried a few personal organizing tools and methodologies, and I was very bad at adopting them. Sometimes I even felt I was adapting myself to them, that is, by definition, modifying my own modus operandi–even though I wasn’t sure what it really was–to fit in their molds.

It turned out that I’m an organized but indisciplined person. That’s such an oxymoron. I’ve tried, twice successfully, to run a period of my life waking up every day at 7 am, jogging for 3000 meters, and starting to working in the morning, and calling it a day by sunset, to my benefits–I did a lot during those two periods. To get things done. There were a lot of to-do lists. But I wasn’t very happy because of that. Later on, I found myself organizing best when I oscillate between paper to-do lists, post-it notes, OmniOutliner, text editors (and I use four: SubEthaEdit, TextMate, TextEdit and vim) and Notes.app on my iPod Touch. Usually I run my “to-do app” on one of those tools for a while, then move on to another in the next period, and the cycle goes on. That’s what I mean by “indisciplined organization”: I’m not bound by an overarching methodology to run my own life. And I am happy with it.

But there are sometimes those periods of life where I was occupied entirely by one project, or sometimes the situation became that I was so busy and I didn’t even have time to do to-do list. I was knocked out of doing them. And many times the post hoc realization has been that I was even happier because I didn’t need to be driven by to-do lists.

That’s how I start to wonder if there are differences between “having to do”, “wanting to do” and just “doing”. In any case I become more skeptical about the promises that organizing methodologies make, because they probably don’t work well for everyone.

Yea, perhaps I’m an oddball.

TapExpense: Our First iPhone Application

TapExpense is available on Apple’s iTunes AppStore today. It is a nifty expense tracker designed for the financially fastidious and global trotters. It lets you keep records of expense in different editable categories, payment methods, and most important of all–different currencies. It also gives you reports grouped by currency.

The idea of a multi-currency expense tracker comes from my personal needs. I’ve been keeping expense records since 1994, and from 1996 on not a day without a record. I only use Excel for its power and flexibility.

But keeping expense records with Excel can be an overkill sometimes. You don’t want to open your laptop for that when you’re on the road. So iPhone/iPod Touch is a nifty solution to this. Hence the software. And also because I travel often, keeping records in different currencies is a problem. A good tool that accommodates and groups such information is a bonus.

Zonble and I have been developing this application for the past few weeks. It’s our first commercial iPhone application, and we’re both glad and proud to be part of the historical launch of the AppStore–the first in the industry–among the first 300-500+ applications on Day 1 from midnight New Zeland time, July 11, 2008. (The number varies according to availibility of different apps in different countries).

This is our first modest step. And we’re still learning from the process. A lot. We are already receiving reviews and comments. We’ve already submitted version 1.1 and are working (or even reworking) on many different parts of the app. Simple as the idea looks, only by doing it have we realized that there are so many details and nuances. Plus that touch-based device requires a totally new mentality and modus operandi. We have actually unlearned lots of our Cocoa habits and skills along the way.

We also have a lot of open questions for Apple. Questions on how the business model will cater different needs, particularly those of us small independent software vendors. I believe even Apple is learning from the process. This is an interesting relationship, and might even shake the rules of the game in mobile software development.

It’s an exciting time indeed. For some moment I even felt it’s like Christmas in July.

Once again, my thanks to our customers and our friends. We’ll bring the best of ourselves to give you the best mobile phone apps in the world.

Cheers!

 

TapExpense is available at Apple’s AppStore. It’s US$4.99, 3,99 €, £2.99 or ¥600 according to the region. It runs on both iPhone 2G, 3G and iPod Touch and requires iPhone OS 2.0. Currently it lets you export your data as plain-text .CSV to an e-mail. We’re working on enhancing user experience, security features and possible import/export options.For more info visit tapexpense.com or the link to the AppStore. Developed by Lukhnos D. Liu and Weizhong Yang with the support of Lithoglyph Inc.

Thoughts on Redesigning a Framework

(I haven’t been in the writing lane for a while. In lieu of stuff about life, here I repost an entry from the ObjectiveFlickr blog.)

I haven’t really been taking care of ObjectiveFlickr.framework for a while. For the past few months many things have demanded my attention. In between I’ve attended sfMacIndie Soirée 2008 and been to this year’s WWDC too. How time flies! I want to apologize for my late response on everything regarding the framework.

Lately we’ve seen fresh influx of discussions on the mailing list. Reading them, I always have this feeling that “it’s time we’ve got to update the framework.” There are a few things that ObjectiveFlickr needs to do better. Some of them are the result of operating system and development environment changes. Here they are:

  1. Better and clear run loop support
  2. Proxy support in OFHTTPRequest
  3. Fixing the delegate implementation–delegate should never be retained
  4. Support for both 10.4 and 10.5 targets
  5. Properties
  6. Linkage against CommonCrypto instead of OpenSSL (libcrypto)
  7. In with NSXMLParser, out with NSXMLDocument
  8. Support for the-device-and-the-OS-that-shalt-not-be-named-until-July-11th

Many of the items actually have to do with OFHTTPRequest and OFPOSTRequest, two nifty (I think) wrappers of Cocoa’s NSURLConnection (for receiving data) and CFNetwork‘s CFHTTP stack (for posting data with progress callbacks). I use them all the time in many of my Cocoa projects, but even they feel a bit rusty now.

The removal of OpenSSL and NSXMLDocument dependency has also clear reasons (or, reasons-that-shall-not-be-mentioned).

I’m thinking of a new HTTP request class that solely depends on CFHTTP stack and does not use NSURLConnection. Which means that part needs to be redesigned. The existing OFFlickr* class interfaces look fine, but they’re also a bit wordy compared to their Ruby counterparts, ObjectiveFlickr-Ruby.

Should I create a set of new interfaces that break with the past, or should I maintain the interfaces and swap the internals? This is the question that is troubling me now. I appreciate any feedback on those design decisions.

Helveticul

Bought a pin at a museum shop, it says “Helveticul”. The salesperson, who just like many others are bilingual, confirmed my guess: it combines the word Helvetica with the French insulting word (think of “en-” plus the word in question then verbalize it). In a genius stroke it becomes a subtler message than Helvetica the Film‘s official “I Love Helvetica” and “I Hate Helvetica” pin-pair. In Helvetica.

So I put it on my backpack and enjoy the love-hate relationship with the typeface, à la française.

Some History on the .cin Format, and on Apple’s .cin Support

Eric Rasmussen of Yale Chinese Mac has started a discussion on the .cin support in Apple’s Mac OS X Leopard, an addition to their exisitng input method framework as an alternative to help users create their own input methods. I was invited to share what I know about the format, so I wrote a long reply to Eric’s post. The length of the follow-up seems to warrant a standalone blog entry, so here it is. I’ll put more links in the text later.

History of the .cin Format

.cin was first introduced by Xcin, an input method framework for X11 developed in the mid 1990s, as a data format for table-based input methods. By table-based I mean input methods that can be implemented, or seen, as a table look-up mechanism. Around 90% of input methods (Chinese and beyond) can be implemented that way. Apple’s .inputplugin also belongs to that category. Almost every mainstream input method framework supports at least one form of user-customizable IME creation. .cin seems to have become one of the standard data formats because it’s simple and many user-generated tables are already in wide
circulation.

I have very limited knowledge of Xcin and other frameworks, but in the early days, .cin was intended as a source format, not to be consumed directly by input method framework (or more precisely, the table-based input method “generator”). Also back then a .cin could use any encoding recognized by the framework. So phone.cin (renamed to bpmf.cin in OV) was encoded in Big5, pinyin.cin in GB, and so on. When we were developing the “generic” module (first named OVIMXcin, later renamed to OVIMGeneric) to support .cin in OpenVanilla, we made two decisions: first, we no longer require user to run a compiler/ converter to make .cin into a binary format, as it was so, which means the .cin is consumed by the input method module directly. Second, all .cin files must use UTF-8 encoding. This opened the door to bigger character set and the famous “♨” input method.

What’s in a .cin?

So what constitutes a valid .cin file? For OpenVanilla, a .cin file consists of three sections:

  1. A header consisting of directives beginning with “%”, like %ename, %selkey, %endkey. Some of them are like meta-data, some of them are controlling directives;
  2. a keyname block between the directives “%keyname begin” and “%keyname end”. This tells the generic input method to map the key typed to a character displayed in the composing stage (mostly to represent radicals in radcial-based input methods), and
  3. a chardef block between the directives “%chardef begin” and “%chardef end”. This is the body of the data table. “chardef” is somewhat an anachronistic misnomer. It used to define the relationship between key sequences to characters (hence the name), but modern implementations like OV and gcin allow phrases in this block

Different frameworks have implemented the details somewhat differently. OV’s implementation disallows the use of Windows-style CR LF (so only the UNIX-style \n is used, and that’s also what OS X uses), and comment lines (beginning with #) is not allowed in the chardef block.

Although .cin contains enough information for key-character/phrase mapping, but many input methods (like 倉頡 Cangjei/”Changjei” or 簡易 Simplex/Jianyi) require finer control. For OpenVanilla, the control is provided in the form of input method preferences (with some mind- bogging names like “force composition when reaching maximum length of radical” or “use space to select the 1st candidate). Different input methods require different controls (and those are a must — failure to provide those controls yields barely usable input methods). gcin
differs from OV’s implementation in that it allows those control directives to be expressed as a .cin header, with its own directive extensions.

OpenVanilla’s Own Take of .cin

OpenVanilla’s repository of .cin is available at: http://openvanilla.googlecode.com/svn/trunk/Modules/SharedData/

Zonble has written an excellent tutorial (in Chinese) on how to create
your own input method by writing up a .cin, which is kind of standard
text now: http://docs.google.com/View?docid=ah6d8th954vw_201fd5dkx

Technically .cin is really just a set of key-value pairs with its own convention. OV makes heavy use of .cin as a format. Things like reverse radical/pinyin lookup or associated phrases are also done with .cin-based data tables. I see it a good sign that Apple adopts a popular (and mostly consistent and cross-framework compatible) data format for Leopard.

Leopard’s Support of .cin

So what about Leopard? As far as I know, dropping in a UTF-8-encoded .cin into ~/Library/Input Methods or /Library/Input Methods then re-login just works. A new input method, using the name defined in the .cin, shows up in the Input Menu tab of the International preferences panel. I’m not aware of any per-method level control so far (I might be very ignorant on this).

In terms of limitation, I’m not aware of that either. OV’s own implementation (and many others) is only limited by memory and your patience (loading a .cin with 200,000 entries on a G3 is no small thing; a database-backed design will solve the problem). Leopard’s own take should not differ much. So it should be very flexible and easily customizable.

Cover-Flowize Your Application

People on the cocoa-dev mailing list talked about the cover flow API, which does exist, albeit not in public. If you know how to use IKImageBrwoserView, you already know how to cover-flowize your application.

In your Interface Builder project, drop in a custom view and make its class IKImageFlowView. In the data source class (which has the same form as IKImageBrowserDataSource), implement these two required methods:

  • - (NSUInteger)numberOfItemsInImageFlow:(id)aFlowLayer
  • - (id)imageFlow:(id)aFlowLayer itemAtIndex:(int)index

And there you have it:

Cover Flow Study

I showed that in yesterday’s CocoaHeads Taipei meet-up. The sample code is available here.

As this is an undocumented class, so caveat programmor. It may change in the next version’s OS X or simply be snapped away under your nose.

OpenVanilla 0.8.0: Now for Leopard

Today we announce the release of OpenVanilla 0.8. It is the third major version of OpenVanilla (0.6, 0.7, 0.8) since 2004. Version 0.8 is available for Mac OS X and Windows. For the unpatient, the new release is available at openvanilla.org.

One thing that I’d like to mention is that the OS X version comes in two flavors–one for OS X 10.4 and above, and one solely for OS X 10.5–the big cat that is finally unleashed today, and that’s why we choose today to announce its release.

LeopardVanilla

OpenVanilla 0.8 for Mac OS X Leopard has a redesigned engine under the hood. From the appearance it feels just the same as the non-Leopard version, but because Leopard offers us a more clear, easy architecture of developing input methods, we’ll start migrating the entire OpenVanilla framework accordingly. Other than maintain releases of 0.8.x, the next major version of OpenVanilla on OS X will be for Leopard (and above) only.

The major changes of version 0.8, in short words, includes:

  • better visual design elements, including a redesigned candidate window and a set of new icons;
  • redesigned web-site and user manual;
  • the latest version of libchewing for Chewing input method, with an expanded phrase database coverage;
  • wildcard support in Array and Generic input methods, and
  • Support for 3rd party on-screen keyboardlets.

Once again, for download and other information, just visit openvanilla.org.

Back from Tokyo

Just took a half-vacation, half-work break in Tokyo last week (well, you can’t really call a half-work break a break, but so it went…).

My fifth time there, and I felt even more at home than last summer when I was on a business trip. I could feel my Japanese improving and that I was able to do more in Japanese this time. The only two occasions I had to resort to English had both to do with technical stuff, like input method development and programming langauge issues. That was when I felt most awkward and powerless. And I forgot to (and didn’t have time to) buy Takahashi’s book this time.

... 浪費在...

So other than the work part (the typhoon in Taiwan made some trouble), it was a very enjoyable trip.

When you visit a foreign city and it’s no longer the first or second time, it’s the little things that count. Like this time I was finally able to have brunch at the Tsukiji Fish Market–fresh toro-uni don was totally refreshing, and would certainly make me unable to visit ordinary kaiten sushi bars for a while!

The new Tokyo Midtown in Roppongi was equally amazing in its architecture and interior. Inside it was hustle and bustle, just like any other shopping venue. But at the exterior, especially in the garden, it was very quite. I couldn’t imagine this kind of places in Taiwan (or in any other Chinese-speaking regions) offer the same silence–or other, I couldn’t imagine if they ever stop making sound during weekend. Tokyo was really a crowded city, and Midtown was really popular during the weekend. But such soundlessness negated the crowd effect.

Surprisingly, this was the first time I realized, and felt tired of, the fact that Tokyo was such a crowded city. Taking the Yamanote Line during the peak hours (which means most of the day) could be physically exhausting. And I stopped wondering why the pedestrian crossings in Akihabara and Shibuya are so wide and long–because they have to be so. I shunned visits to Shinjuku as much as I could this time.

Fortunately, we were staying at a great weekly mansion (ウィークリー.マンション; a type of accommodation in Japan that has no room service, is on a relatively longer lease, and is a great bargain) in a very quiet area in Tokyo. I couldn’t believe it’s still within the reach of Yamanote Line, yet is on such a slow pace. One reason I suspect though is that the area has many cemeteries. But Japanese cemeteries are like Western ones in that they are peaceful and are never visually intimidating.

With the Sony empire in decline, game consoles going global, and best MP3 players coming from Apple, Japan has lost its appeal to me as a beacon of leading consumer electronics. I still remembered the first time a family friend brought me to the Yodobashi Camera store, and boy it was heaven. Shopping is also more or less a Starbucks thing–you run into same stuff in any big city.

Interestingly, exactly because those can be bought is now available everywhere (and if you don’t think so, you must be too inexperienced with the international shipping options), that those couldn’t be bought and brought back with you become more valuable. I like travelling in Japan because its culture is not loud–loud in aesthetic, sensual, architectural and audio-visual terms. Simply taking a walk in the city–pick a quiter neighborhood with old bookstores, izakayas and wagasi shops sitting around–is a pleasure. And knowing more about the language enriches every new trip.

I’ll definitely refrain from working next time.

« Previous PageNext Page »