fiat lux (cahier lukhnos)

A couple of veteran Mac developers have come up with the idea of OpenRadar. Anyone who has ever filed a bug to Apple through their bug reporting system (”Radar”) knows its close nature. It’s understandable that you don’t want to disclose your reported bugs on unreleased software from Apple, neither do you want to reveal a bug that has to do with your own unreleased software. So Apple chooses to make it close on fair grounds.

On the other hand, there are situations where you want to make your filing public. I often encounter these two: (1) you have a feature enhance request, but it’s rejected on the ground that it’s a “dup”, but you don’t know if it’s really so, or you want to seek some support from your fellow developers; (2) you want to discuss openly about a bug or a fix which may benefit all.

At any rate this is community spirit at work. It’s amazing to see how Google’s App Engine is used. Will we be seeing a desktop client for that soon, too?

Update: Tim Burks, the person behind the idea, blogs about it in his own words.

lukhnos :: Nov.17.2008 :: tekhnologia :: No Comments »

In-between the problem of structuring your GUI application at higher order has caught my attention. The glaring problem of multi-core multithreading is trapping us developers. We are bound to the limitations of modern graphics system design–to our amazement window systems are themselves very complicated beasts. But while our computation and heavy-lifting parts are migrating to the multithreaded world (hey even network connections are in that area already too), GUI code is still confined to either main thread or the thread that created the component/widget in question. You don’t, can’t, dare not, ought not, may not pass them back and forth between different threads. How quaint.

In other news C++0x shows its promise with all its new syntactic constructs (many of them condensed form of popular idioms, esp. template metaprogramming) and its inherent support of modern threading control objects. And talk about lambda and better type inference. Hey but a working compiler is still years ahead. And will we be still using gcc?

(But I guess I’ll still have problem doing GUI stuff with such a strongly-typed language.)

The real challenge is how to formulate, in my opinion, GUI event and graphics model as trasnactionable operations. Animation frameworks like CoreAnimation show the way, but it doesn’t seem to have become that much generalized yet. GUI programming is in a desperate need of new models that can catch up with the already more advanced, more sophiticated way of (esp. networked) data modeling and manipulation. It’s such a scandal that database operations can be thought as series of rollbackable transactions but GUI ops cannot.

I’ll be happy to see the death of the decade-old event-loop model and its rebirth as a higher order construct. Although that seems a call for declarative UI design but perhaps we’re still far away from that.

lukhnos :: Nov.14.2008 :: tekhnologia :: No Comments »

InputMethodKit Backporting Component, or IMK-Tiger for short, helps
input method developers backport their IMK-based input method apps to
OS X 10.4 Tiger. It is what we use to backport the latest OpenVanilla,
a popular input method toolset in Taiwan, to 10.4.

I’ve posted more details on Cocoa-dev.

lukhnos :: Oct.20.2008 :: tekhnologia :: No Comments »

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 :: 19 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 »