fiat lux

Also posted in Flickr API Group.

The Ruby version of the ObjectiveFlickr library has been updated. Version 0.9.2 includes support for Flickr’s new “farm id”, now required for newly uploaded photos since the format’s announcement.

Your old code will work without any change. If you also use this library’s helper functions that help you handle the photo information (a hash that stores photo id, server id, “secret”, and the newly-added farm id), there should be no problem working with new photos too.

Other minor changes include some refactoring and deprecations that should lead to cleaner code and style. Documentation is also updated. Please refer to its release notes for details.

To install ObjectiveFlickr, simply use “gem install objectiveflickr” for the latest version. The Ruby version is hosted at http://rubyforge.org/projects/objectiveflickr.

The Objective-C version (hosted separately at http://code.google.com/p/objectiveflickr/) will be updated shortly. I’m refactoring part of its code so it may take another few days.

lukhnos :: Dec.29.2006 :: tekhnologia :: Comments Off

ObjectiveFlickr 0.9.1 is released. This is a minor update. For details, please refer to the ObjectiveFlickr blog article.

lukhnos :: Dec.13.2006 :: tekhnologia :: Comments Off

I’m happy to announce that ObjectiveFlickr Library 0.9.0 is released, available in two languages: Objective-C and Ruby.

The Objective-C version is the continuation of my work on the Flickr API framework, first released in September. Version 0.9.0 includes documentation, sample code, and the pre-built ObjectiveFlickr.framework which can be placed into your own Cocoa app. I’m planning to add unit tests and synchronous calls in the near future.

The reason I’ve created a Ruby version is that I need an ultra-lightweight Flickr library for my web applications. Since Flickr now provides return data in JSON, there is really no reason we need a myriad of Ruby classes (one for photos, one for groups, one for users, … and so on) that encapsulate different types of Flickr data. I’ve packaged the library into a gem so with just a one-liner ("gem install objectiveflickr") you’re all set.

The Objective-C version is hosted at Google Code, whereas the Ruby version is hosted at RubyForge. I also keep a blog that tracks its growth and progress (I hope).

I’m eager to learn if ObjectiveFlickr can help you better, so feel free to comment or drop me a line. Thank you!

lukhnos :: Dec.11.2006 :: tekhnologia :: Comments Off

Some people I know are working on things like group calendars, group to-do’s, or group task tracking system. One common theme (use case actually) in those applications, and one that you also find in big boy apps like Google Calendar, is that you can “dump” things quickly. In Google Calednar you can click on any day and type “15:00 Meet-up with Taipei.js people” and Google knows you want to set up a calendar item beginning from 15:00 that day. Keyboard is still the fastest input device, and by allowing people to “dump” their thoughts, to-do or calendar items, you’re giving your users a big favor.

Now I wonder if we should really have something like that in bookkeeping. Done wite the days when we row-and-column Excel spreadsheets. In a messy situation such as when travelling aboard with an unfamiliar currency, something we just want to “dump” the expense record we have, and let the system do the rest of the calculation (and slip keeping). For example, “200 Yen a can of tea at Narita Airport” and “USD 20 subway prepaid card at the exit of JFK Airport”, then the service should be able to tell you that you spent 60 NTD at Narita and 660 NTD at JFK, using that day’s rates.

Of course by its nature a bookkeeping service needs to work both online and offline. Sync, security and multiple report-generation options are needed. If the service can keep track with daily currency rates or even your portfolio, so much the better.

lukhnos :: Dec.10.2006 :: tekhnologia :: Comments Off

Web 2.0 Visual Design, 1928 Style

Originally uploaded by lukhnos.

A poster in 1928. “Büro” means office in German. By Theo H. Ballmer (1902-1965).

Musem of Modern Art, New York City.

lukhnos :: Nov.20.2006 :: tekhnologia :: Comments Off

OpenVanilla just had its 2nd birthday. It was born in the form of a little .h file on the Twenty-Third of October in the Year of Common Era Two-Thousand-and-Four. We’re well into the third year. I’m really glad that it helps many people and is both useful, innovative, and fun.

As the operating system and desktop environment grow over time, OpenVanilla must catch up too. Many edges are becoming rough again, and some of its code base begins to show its age. We’ll continue polishing the rough edges and hopefully we’ll come up with features that are again both useful, innovative, and fun (WebKit-based candidate/feedback windows are high on the list).

Without you support, OV wouldn’t be what it is today. Thanks everyone!

When it was three weeks old: the first functional POJ module

lukhnos :: Oct.24.2006 :: tekhnologia :: Comments Off

I’ve started putting in HeaderDoc tags into ObjectiveFlickr header files. Which marks the beginning of documentation work. The framework has been stablized, and I feel good about it. Now what is needed is a really good documentation. A dedicated blog and nightly/weekly builds will be in the sweetspot, too.

It’s almost done. Another two or three days and the documentation should be there.

lukhnos :: Oct.20.2006 :: tekhnologia :: Comments Off

The refactor work is now done. I’ve broken lots of things for lots of reasons. But all in all I hope this eventually becomes a production-grade framework, with details such as naming convention being taken minute care of.

Now there is documentation work to do. I’m thinking about using Apple’s own HeaderDoc tools to write the in-the-code documentation, and use the tools to generate HTML document for me.

And I’ve added another example. This is done after Ruby on Rails’ screencast (on how to use RoR to create Flickr public photo search). I have even copied their CSS. Working with WebKit is always fun, and ObjectiveFlickr gives you the power of accessing Flickr method and return data blocks in native Objective-C. Because of limited time, I only wrote a Chinese blog entry on that, but you can always download the latest build or use the source to see for yourself.

I know. The current state is very, very far away from anything “production grade.” Even my blog theme is lacking in that they are totally inadequate for project hosting purposes. I have to work harder on this.

lukhnos :: Oct.08.2006 :: tekhnologia :: 1 Comment »

Lately I found you can actually call valueForKeyPath: to retrieve a key from deep dictionary-array combos, such as [aDict valueForKeyPath:@"a.b.c"] instead of [[[aDict objectForKey:@"a"] objectForKey:@”b”] objectForKey:@”c”].

Apple calls it “Key Path” (à la XPath?) and it plays an important role in Key-Value Coding/Observation. The biggest problem, however, is that it uses the symbol “@” to perform some functions on array data (e.g. you can do average or count or total, those db/spreadsheet thing, using @ modifier in a key path).

That is in direct conflict with ObjectiveFlickr’s current XML-to-NSDictionary convention, which follows BadgerFish’s XML-to-JSON convention, ie. using @ symbol to mark that it’s an attribute of an XML tag.

Either I’ll have to move attributes to another key, e.g. aTag._attr, or have to use another symbol that is not “@”.

In any case, I’m going to break that part of ObjectiveFlickr. I don’t want to write three left brackets just to retrieve a key, it’s too ugly. KeyPath is a better way, but unfortunately the symbol “@” doesn’t fit into the picture. Only had I knew it before I designed!

lukhnos :: Oct.02.2006 :: tekhnologia :: Comments Off

I just came back to Taipei and will spend the next two days in Chutung, attending HappyDesigner’s second gathering and catching up with friends.

For the last two days I have been refactoring the framework. One thing that I have to say is that, since ObjectiveFlickr is still in a very rough and early state, each new version mak break somewhat what was available before…

I’m thinking about removing OFFlickrRESTRequest altogether, creating an OFFlickrHTTPRequest instead. In fact it’d be nice to have a HTTP transport class, because we may also want to fetch the image–you don’t want to do that with NSImage’s initWithContentsOfURL, it’s blocking your code!

We will actually need two HTTP transport classes, one for regular GET/POST requests with a potential large return data, and another for doing large POST request (i.e. “uploading”). This is because NSURLConnection is not good at doing large POSTs… well, at this point I was actually thinking, if we should scrap NSURLConnection altogether and simply use CFReadStream for everything?

There are other design considerations, such as simplifying the error codes, and making classes Key-Value-Coding compliant. In addition, there is actually a very nifty way of getting Flickr XML data that is converted into NSDictionary (using flickrDictionaryFromDocument method), which is called “value path” and is a part of the KVC convention. I haven’t tried out that yet.

In the end, all those async things smell like reinventing the wheel of XMLHttpRequest… why didn’t we simply create a WebKit object and make Javascript work for us? Or maybe some AOCX (OC for Objective-C) may eventually surface. Who knows…

Lots of work ahead, will keep you posted on the progress. Before then, if you’re already using ObjectiveFlickr, I’m eager to learn to which extent are you using. Some things will really break in the next few revisions…

lukhnos :: Oct.01.2006 :: tekhnologia :: Comments Off