Posts RSS Comments RSS 104 Posts and 72 Comments till now

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.

Extracting iPhone Backup Data with mobilesync-inspect

I wrote a command line tool called mobilesync-inspect that can list, extract, replace and backup your iPhone/iPod Touch (hereafter I use iPhone to represent both devices) backup data.

To download the prebuilt binaries for Mac OS X and Windows, use this link.

It is well understood now that iTunes backs up the application data on your iPhone in one of your user directories. It is not yet well understood exactly how iTunes makes use of such data, and why the backup/restore process is so slow.

What mobilesync-inspect differs from other similar tools, say, from iphone-backup-decoder, is that it’s duo-platform. I have prebuilt both Mac OS X and Windows versions, in the hope that it helps Windows iPhone users out there. Although iphone-backup-decoder is written in Python, installing Python on Windows and run the script is not trivial matter for the less technically savvy (or people who are busy).

Of course there’s still a hoop to jump: mobilesync-inspect on Windows requires some DLLs from Safari for Windows. But once you have Safari installed, it’s really just four files to copy, and you’re all set. Plus mobilesync-inspect provides more than backing up backup data.

We have heard a lot about app data loss after App Store upgrades. It’s disheartening for me to learn that iTunes did not make versioned backups. If your app is zapped during the upgrade process (this mostly happens if your Internet connection is not stable between the different upgrade stages) and you inadvertently sync your iPhone with iTunes, iTunes will faithfully zap your app along with your app data. It’s quite scary if the app in question is about personal finance data (like what my app is about), to-do lists or password reminders.

One last note: mobilesync-inspect is open source. I probably won’t have too much time taking care of this side project apart from my daily work. I hope that other developers will be interested enough in making use of it to, for example, build a GUI tool for inspecting and manipulating the backup data. For those interested how and why its Windows version requires Safari, the answer is short: to be able to do cross-platform, mobilesync-inspect is written in C++ and makes use of Apple’s own CoreFoundation library to do the mdbackup data I/O (itself in Apple’s own property list format). Frankly I think Apple should put CF for Windows in circulation (currently it’s quite restrictive, tied to WebKit), because it’s a well-designed general-purpose library (think of glib with Apple flavor) and makes cross-platform dev experience far better on Windows.

Also: lukhnos :: Aug.06.2008 :: tekhnologia :: 19 Comments »

The Risk Factor

I mentioned among a series of tweets that the risk for developing an iPhone app is becoming pretty high lately. The biggest problem is that there’s no guarantee that the user’s data is safe in these respects:

  1. There’s no guarantee that iTunes performs faithful, controllable, restorable backups for any data stored in an application’s virtualized ./Documents/ folder
  2. Even if it’s possible for a more technically savvy users to extract the backed-up data (and we’re discounting the factor that there is iTunes for Windows and I don’t have much clue how we existing Mac developers are going to deal with that, other than offering service utilities for Windows), there is, AFAIK, currently no way to put the backed-up data back into an app bundle as the user wishes
  3. Many developers (among them Craig Hockenberry and Brent Simmons) have expressed the frustration over the fact that we developers have absolutely no means to help the user out of any trouble. Releasing an app in wild becomes playing with Russian roulettes.

My biggest fear is that if the situation doesn’t improve, these risk factors will swell up to the point that supporting becomes endless nightmare for developers, and many data-intensive apps will become simply not do-able–because users won’t trust them with their local data. Some forms of liability issues will also surface.

And if the situation doesn’t really improve, I fret that those factors will start driving out applications that rely on local data (many productivity apps fall in this cateogry), leaving only three do-able apps: games, web service clients, and photo apps (because they have access to the camera roll).

Games and photo apps are by their nature platform- and device-dependent and they will always have a place as native apps. But the driving-out of native productivity apps, local-only or more “rich” (i.e. they sync or work with remote ends), will make the point of going native a huge disappointment. If that is what’s going to happen in the long run, it will be a big setback for the whole point of a native iPhone SDK.

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.

Matsumoto Shinosuke, the Blogger Killer

It rained, serendipitously, when he was deciding which part of his past to throw away, whom to avenge, and how to forget.

Matsumoto Shinosuke, also known as Dr. T in his pro circle, was an ASP .NET programmer who wrote bespoke, or customized, blog systems in Akihabara, Tokyo. But his real job was a professional assassin. Ironically, the blog systems he made had such a good reputation of having very little spam. Probably it’s because Mr. Matsumoto applied his pro assassin knowledge to spam killing, at the expense of his victims.

There was once when Mr. Matsumoto’s cover and real jobs overlapped. A certain telecom conglomerate was suffering huge bandwidth loss because of botnet attacks. The conglomerate, run by one of Japan’s oldest families, had finally had enough and sought the help from the underworld. While picking up the hit man was not hard, finding out the mastermind behind the botnet was trickier. An anti-spam strike team finally identified the man, a script language black-belt who scoffed anyone whose expertise ends in the word dot en ee tee. What the man, let’s call him the V, didn’t realize was that, he made some of such scoffs on a free, anonymous blog system, which, to his haughty ignorance, was a bespoke work implemented by no one but our Dr. T, in, to the V’s horror, ASP .NET. And Mr. Matsumoto hated it most when people scoffed at his being master of ASP .NET, even if he was equally fluent in any script language the source code of which requires to start with a shebang.

So a detective service paid Mr. Matsumoto’s cover job employer (actually, one of his cover job employers) to locate the V, and the conglomerate paid Mr. Matsumoto, indirectly through layers of underworld connections, for the ultimate strike. It couldn’t be a happier assignment: a fat double-pay. But of course it would not be a happy ending for the V.

On a rainy, quiet night Mr. Matsumoto arrived at the door of the V’s posh apartment in the equally posh community of Daikanyama. The doorbell rang, and exactly 180 seconds later, a spammer was totally unwound just like a most insignificant exception in a try-catch clause, and to Dr. T’s delight, one less ASP .NET scoffer. A bloodstained laptop was left in the scene, the signature of Mr. Matsumoto’s yet another tour de force.

dataWithContentsOfURL: inconsistencies

Was tracing a mysterious bug. Some software component that uses NSData’s dataWithContentsOfURL: suddenly fails to work with a specific URL endpoint only when it is run on Tiger. Switching the URL endpoint to the dev server, and the problem is gone.

Turns out that the specific URL endpoint is served by an Apache server with gzipped data option turned on. Many a modern day web servers do that to lighten the traffic load (especially if you serving tons of JavaScripts, for example). Unfortunately, the naïve dataWithContentsOfURL: does not unzip the data for you automatically, so your NSData object contains actually a zipped data.

Interestingly, on Leopard dataWithContentsOfURL: works just as transparently as it should always be. Digging through the mailing list some Apple people confirmed that it behaved inconsistently since the days of 10.3.3. It’s just unfortunate.

The solution? Ask the server side people to turn off that option.

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.

Hamlet in Ruby (Version 2)

question = self.be?

o_f = fortune(:outrageous)
suffer = s.mind.suffer(slings(o_f) && arrows(o_f))

sea_of_trouble = [:trouble, :trouble, :trouble]
fight = sea_of_trouble.map { |t| kill self.arm.take.against(t) }

nobler = suffer > fight ? suffer: fight

if fork == 0
  while 1
    sleep
  end
else
  die
end

nil  # no more

« Previous PageNext Page »