My blog has been moved to

Sunday, March 30, 2008

accident waiting to happen

cranberry rolls

Well, given a wonderful kitchen, a new city to explore and a quite amount of free time, never been before I am involved in making assorted pizza variants (mini-pizza, lamb, tuna, tofu), tika scampi, plenty of sushi rolls, fried rice, naan bread, fried noodles, brownies, baked banana, cranberry rolls (the picture above), and some others (that I can't possibly remember) in just a few days!

Thursday, March 13, 2008

Guitar Hero for C64

Well, ray tracing into a sparse voxel octree might be inspiring, but for the time being, Toni's Shredz64, which is essentially the Commodore 64 version of Guitar Hero, is tantalizing!

Wednesday, March 12, 2008

Common characteristics of failed open-sourced projects

Who am I to write this one? But, really, it is what I observe in the last couple of years watching some open-sourced projects die slowly.

Start with something big. Imagine you want to create a next-gen music player, sort of Amarok-killer. Don't worry about skinning, lastfm integration, support for Oracle DB, automation with infrared remote control etc. One step at a time. Just make your player plays MP3 files (or Ogg, pick anything you like) and continue from there. Keep the horizon in your vicinity so that the journey does not look like an impossible intergalactic travel.

Blind design. Don't get me wrong, design phase is a very important one. However, if you are new to the field, don't bother too much with the design because your project will need a rewrite anyway. If you never study physics/electrical engineering before and your boss asks you to build a transatlantic fiber optic transmission system, I bet you would need to redesign your system several times so at first no need to talk about transmission impairments, price, modularity, and other issues. If your first serious project is supposed to be a new revolutionary spreadsheet program, never mind about its scalability, multicore CPU support, and Excel interoperability, until you get the core spreadsheet functionalities right first. Design is important, and so is experience.

Smoke without fire. Unless your project is about a web application, then there is little point of discussing which CMS to use, where to host the website, how can we get the artists, etc etc. Sure, good looking web site, developers blog, and maintained forum can give more exposures to the project. But if you are only at the early stage, then just focus on the important part: the application. If you place your project on the host service like Google Code (avoid SourceForge), then the basic tools like subversion/wiki/issue tracker are already at your disposal. No need to show up your PHP skills there or to argue which artwork should be chosen for the logo, that can be done when finally your project has enough users. Spend your precious time doing something more helpful to the project's important lifecycle.

Lack of passion. This is not work, this is supposed to be fun. Nobody holds a gun and tells you to do something. If you want to create a web browser but you hardly browse the web, forget it right away. Think twice: even if you are flamed and criticized, are you still going to love your new baby or not?

Too many mock-ups (will kill you). Yes, mock-ups are wonderful, they help people to visualize the end result of the project. But mock-up only without any code will not drive the project to success. You can't post hundreds of mock-ups and hope that one or two real coders would step in and implement everything for you. In the open-source world, it is close to impossible to ask people to do what you want (unless you have billions to spare).

Follow the fashion. If you want the fame, do not waste your time doing software and do something more sensible (e.g. practice a lot for the next year's Idol program). The problem with cool stuff is, when it is not the trend anymore, you are deserted. So stick with common sense and do what you think you can do best, not always what others think must be urgently done. Imagine if we have a dozen of PointCast clones...

Reinvent the wheels. Yes, this is so obvious. But let us talk about the components here. For example, even if you hate STL, just use it while you are kickstarting your project. If your design is correct, you can replace it later on (often not trivial, but still better than wasting time creating another library). When you need scripting support, just pick Lua/JavaScript/Python/etc at first. If finally it is absolutely necessary, you can hook your own script interpreter. Focus on building the application, not all the nitpicky details which can be improved with time.

Underestimate the maintenance. Just check SF, how many projects did become orphaned in the last years? You can create two dozens open-source projects if you want, but if you think you won't be able to maintain them, then think about it again. Most of the time, we always hope that someone will take over the maintenance, but only a handful projects manage this. I assume, partly because maintaining something is not the fun part of the game. You may get slashdotted when magically you create something out of nothing, while when you fix a bug it is often (sometimes not at all) noticed only by the bug reporter.

Wanna add some other points?

(Don't be trapped in the fallacy: if you see these signs on the project you are working on, it does not mean that your project is bound to fail).

Say all I need is the air I breathe

If AIR is supposed to mean Adobe Integrated Runtime, calling it Adobe AIR sounds a bit awkward, right?

Tuesday, March 11, 2008

who understands this boring blog

blog readability test

At the time I check Planet KDE, it is for high school while Planet GNOME requires junior high school level. Strangely, my website is only for genius (no wonder I myself could not understand it).

Someone knows the algorithm behind that detector?

Friday, March 07, 2008

The Forbidden Kingdom

Finally the long wait is over! In The Forbidden Kingdom, for the first time we are going to see the fantastic Jet Li and Jacky Chan together. Not so much about the story has been revealed. The plot might not be that unusual and even it is likely quite predictable (but who knows until we all watch it). From the trailer, it is mostly about a young bloke that travelled back in time. With a girl and two warriors, he was doing some sort of "prophecy fulfilling" adventure.

Few weeks to go.

Tuesday, March 04, 2008

PhotoFlow as a plasmoid

Plasmoids on KDE 4

PhotoFlow, which I introduced less than 48 hours ago, can also be realized as a plasmoid. It is the top left applet in the screenshot above. I have never written a plasma applet in my life before, so it took me quite a while to figure out how the mechanism works. And frankly, I am still not sure whether such a kind of widget can be really useful at all.

I guess I will wait until KDE 4.1 before I place this stuff in KDE's playground. By that time, Plasma itself should already stabilize. Probably it is even better to integrate it with the Picture of the Day data engine. Or even with the slideshow plasmoid. Or perhaps do you have any other idea?

Monday, March 03, 2008

chasing of the day

We don't believe improving your OS should be like chasing Tigers or Leopards.

-- gOS, on its free updates for life feature

introducing PhotoFlow

As I wrote before, the obvious complaints people are having after trying out Chad's precompiled PictureFlow for Windows Mobile are (1) slow start-up and (2) memory footprint. These stem from the fact that the example demo program that I included was written for clarity so that you can get your feet wet quickly. To overcome the initial loading and memory consumption problem, of course you have to attack the problem from a different point of view.

So here it comes: PhotoFlow. It is a small application for view images and photos, designed to run on mobile devices --like those HTC smartphones, other Windows Mobile phones, Qtopia-based handsets etc-- although you can test it of course on the desktop (but I will focus on the intended target platform only). The usual trick employed here is the so-called "delayed loading". PhotoFlow never attempts to load, resize, and prepare an image to be rendered if that image is not in the vicinity of the user's view. Thus, it starts rather instantly and won't suck hundred of MBs of the precious memory space. This is even done without changing anything in the original PictureFlow widget, we just need to subclass it and handle several things smartly.

Because I am (still) insane, PhotoFlow supports both Qt/Qtopia 4 and the old Qt/Embedded 2.3 (actually also Qt 3, for which there isn't any embedded version) with a single code base. Also the delayed loading part has two versions: with and without QThread. Of course the former is better but some platforms with Qt/E (or even Qtopia, if you want) might not support threading at all, hence the latter.

Get it while it's hot and flood my inbox with your flames.

Saturday, March 01, 2008

sushi factory bremen

If you happen to be in Bremen, give Sushi Factory a try. It is located right in downtown (see on Google Maps) and easily reachable. The soy sauce is a bit salty for me, but otherwise everything else if fine. The place is cozy. The atmosphere is relaxing. The rolls are of course tasty although they are rather not so cheap. Still, there is a nice bargain for a lunch pack.