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.

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.

I’ve posted more details on Cocoa-dev.

Now you know that I work for (and actually own) Lithoglyph, and we’ve just released a new version of Mondrianum, a color picker plug-in that leverages Adobe kuler color theme resources. And this being a few things that we are working on.

At the same time we’re still thinking hard and moving at a slow pace on giving TapExpense an upgrade. We’ve learned a lot three months after the App Store went live, and we are working on putting them in practice. Redesigning, reforming or simply refactoring an existing app is hard, as it turns out. But we are not yielding to the difficulties any time soon.

I really want to apologize for my slowness at doing anything related to mobilesync-inspect. I believe there are (or should be, but I didn’t do research) other tools that perform somewhat same tasks, hopefully with better UI. I really don’t have time to do all the testing and try out the replace-and-restoration scenario myself.

Apparently mobilesync-inspect belongs to some of the worst kinds of the open source software, that it can’t attract enough developer interest to carry on its development, plus that the original developer (that’s me) simply doesn’t have the resource (time, energy, committment) to improve it further…

ObjectiveFlickr, on the other hand, seems to fare better. There are lively discussions on how to port OF to iPhone–cutting off the NSXMLDocument dependency that is. And I’m glad that there are people interested and enthusiastic enough to do it. My own take would be scrapping XML parsing using NS stack entirely and use libxml2 to render Flickr’s XML response block a simple dictionary. But again that takes some time to re-do a few things.

OpenVanilla is under some major overhaul. Zonble and I are working on a nearly rewritten version of the OS X loader, this time entirely based on InputMethodKit. One interesting challenge is to backport IMK-based loader to Tiger, as it turns out that the market we want to support (Taiwan mainly) still has 50%-55% users hanging on with their Tiger installations. And we actually have found a solution for that, first applied in some in-house projects that we have at our company. The solution will be released as an open source library shortly.

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.

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.

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.

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.

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: http://lukhnos.org/blog/en/archives/98 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 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.