fiat lux (cahier lukhnos)

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.

lukhnos :: Aug.23.2008 :: tekhnologia :: No Comments »

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 :: 18 Comments »

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.

lukhnos :: Jul.23.2008 :: tekhnologia :: No Comments »

(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.

lukhnos :: Jun.29.2008 :: tekhnologia :: No Comments »

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.

lukhnos :: Apr.18.2008 :: tekhnologia :: No Comments »

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.

lukhnos :: Mar.25.2008 :: tekhnologia :: 2 Comments »

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

lukhnos :: Jan.07.2008 :: tekhnologia :: 1 Comment »

question = self.be?

self.call nobler? ?
    lambda{|s| s.mind.suffer([:slings, :arrows].each {|x| fortune(:outrageous, x) }) }
  : lambda{|s| s.fight_and_kill([:trouble, :trouble, :trouble]) }

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

# no more

lukhnos :: Jan.06.2008 :: tekhnologia :: No Comments »

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.

lukhnos :: Nov.10.2007 :: tekhnologia :: 1 Comment »

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:

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.

lukhnos :: Nov.09.2007 :: tekhnologia :: 3 Comments »