Feeddler status update

Long story short: I will submit a Feeddler update soon that should transition well into the post-Google Reader era.

No, it's not Feedly or Digg. Their API is not ready yet. I am aware of Feedly's announcement last week and I did get its API access after the news. But Feedly folks are still working day and night to fix bugs. Their API is also different from Google's, so it will take me some time for integration.

Feeddler will first support BazQux Reader which nicely duplicates Google Reader API. In the past few days, its developer even implemented a few advanced API methods that are only used by Feeddler (e.g. drag-and-drop sorting and feed pagination) after my requests. BazQux Reader is the only one I have seen that supports full set of Google Reader API, which means Feeddler users will not miss any major functionality. It has a very usable web interface too. BazQux Reader offers a 30-day free trial and charges a $2/month subscription fee.

Not ready to commit to a subscription service? Feeddler will support Feedly later, but you might lose some functionality due to API changes.

How about Feeddler's own solution? I have completed the code for RSS aggregation and successfully tested hundred of feeds in several languages. But I still need to work on cross-plateform syncing. No subscription fee, but likely a separate app. Some non-technical issues have prevented me from spending time in this new development. I cannot promise when I will release it. Hopefully soon.

Feeddler 2.0

Google will shut down Reader on July 1st.

It simply means that if I cannot find a service to replace Google Reader, Feeddler will be useless. In fact, all RSS reader apps on any platform will be obsolete if they rely on Google Reader. In the past few days, some have stood up and claimed that they already have or are developing Google Reader replacement and will open API for third party developers. I hope they will be as good as they advertised and I can just change API domain and keep Feeddler working after July 1st. Sounds easy? Probably not. I have tried and investigated a few of them. They were either very slow or API is half-baked. Simply put, there is no good solution so far. I do not want to take risk and believe that someone will offer a good solution soon. I hope for the best but plan for the worst.

Feed aggregation and management is not rocket science. However it is difficult to achieve high performance at Google's scale, which requires intensive computation resources. Google will stop picking up the tab for a great service we all love. Someone has to pay for a high-quality service but most users are not ready to pay. So here is the plan for Feeddler 2.0 without Google Reader. I will first implement a cheap syncing solution that can be offered for free without browser support. A high-performance solution will be developed later with browser support for monthly subscription fees. The subscription fee might start with $1/month for up to 50 feeds.

Feeddler will be fine without Google Reader. If many users like the new Feeddler, a Mac and an Android app might come soon!

Flash integration: Always check stage size before you do anything

I had a project to design a Flash component API that needs to be easy to integrate with all video players. I had investigated more than a dozen video players used by web publishers of any size. These video players included big brand names like YouTube and Brightcove, and generic players such as JW and Flowplayers. The goal is simple: the Flash component API needs to work on any given web pages. Making jobs easy for other developers means we have to do all dirty works.

Some web sites have lots of problems in their HTML markups and JavaScripts. Often times, these publishers have no engineering resource to maintain their code. They probably did not test their site performance across different browsers on different platforms. Some bad codes are not fatal but just make the site slow. But for anyone who needs to add code into it, watch out!

More than once, I found my Flash component failed to load on IE. It's always perfect on Firefox. It also happened only on a few sites.

It turned out that this was a timing issue caused by some JavaScripts that IE had problems with. When I initialized my Flash components, the Flash stage size was ZERO! Yes, you don't always get the stage dimension you set in HTML object tag. Solution? I now always add a timer to poll stage width and height till both are not zero before I even initialize any objects in ActionScript. This is a protection for my ActionScript because I have no idea how it will be used by others.

Remember, if your Flash does not work on IE, and IE only, always check if Flash stage size is zero! Before you can fix your JavaScripts and make IE happy, you can always protect your ActionScripts by waiting till Flash stage is properly initialized.

A seasonal pattern of iPhone app usage

The following is an ad request chart of my iPhone app, Men vs Chimps Lite, for the first three weeks since its first release. Do you find anything interesting? Notice that today, 9/27/2009, is a Sunday.

Although the data is limited, I found that Wednesday, Thursday and Friday usually have peak usages. I have thought people may use iPhone apps more often on weekends. Obviously, I was dead wrong! From the chart, Saturday has the lightest app usages.

Perhaps, people are having fun on the weekend and they don't need iPhone apps. Everyone works hard on Monday and Tuesday. By Wednesday, iPhone users are already looking for weekends and use (entertainment) apps to kill time.

Mutable objects as default arguments in Python

I spent quite some time Friday morning trying to figure out a weird problem. The problem was not there when executing code in command line in a production machine or in a local environment.

It turned out that I made a mistake that I had never known. I had a function looks like

def a(m=[]):
  m.append(1)
  return m

If you call a() three times, you get

[1]
[1 1]
[1 1 1]

which was not what I expected. I used m as a flag to select algorithms, and the function a() was called exactly once in every process. In a single thread process, everything seems ok. But in a multi-threading environment, once a flag is set, the flag will be there for all subsequent calls.

I checked Python documents and found that "the default value is evaluated only once." That's a potential problem if you use list or dict as a default argument in Python. It essentially says that a list or a dict as default is taken as a static object. If the argument is read-only, you are fine. If you want to overwrite the argument, make sure you intend to use the list or dict as a static object. For me, I rewrote my function like

def a(m=[]):
  m = m + [1]
  return m

so m is pointed to a new list object. Problem solved. Lesson learned.

iPhone app review process - a level playing field?

Facebook submitted its iPhone app 3.0 on August 16, 2009 (according to TechCrunch). Joe Hewitt, the Facebook iPhone app lead, wrote a blog a week later and proposed "the review process needs to be eliminated completely." TechCrunch then wrote "Tear Down This App Store Wall." Users were inpatient too, pointing fingers to Apple. I could feel Apple was under great pressure.

Facebook 3.0 for iPhone was available in Apple App Store late night August 27th. People were so excited as you could see the wave at Twitter. I found a bug that crashed the app every time I scrolled my friend list to the bottom (friends' names in Chinese) and reported it to Facebook. Then Facebook 3.0.1 came out three days later. Bugs fixed. That was really QUICK! Yesterday afternoon, September 3rd, Facebook 3.0.2 was out. That was unbelievably efficient from Apple.

Set aside any discussion to remove iPhone app review process for now. As a small developer, I have another concern about a level playing field in the app review process. I was very surprised it took Apple only 11 days to review Facebook 3.0. It took Apple two weeks or more to review my app for its first release and also a subsequent update. My app, Real-Time Stocks, has only five views (aka screens), obviously cannot compare with Facebook for its breadth of functionality. How could Apple approve a huge Facebook app a few days faster than my tiny app? What's more shocking to me, Facebook 3.0.1 and 3.0.2 were both approved in about three days. That really disturbed me.

I submitted a new app, Men vs Chimps, on August 25th, and just received ready-for-sale notice from Apple yesterday evening. Now I know during the review process for my app, Apple approved three Facebook app submissions. My little iPhone app has only three views: a menu, a game view, and a result view. You don't even have to count to know Facebook app has more than ten times as many views as mine. But the most important point here is that Facebook submitted two updates a few days after my submission, and both of them came out ahead of mine.

Now, I want to know if Apple is willing to update my app on a super fast track if I have a bug fix for my app. Didn't I pay as much as Facebook did for the standard iPhone Developer Program? As long as there is a review process for iPhone apps, I suppose all apps should play by the same rules. Unless there is a rule that I don't know.

A blog reborn

It has been a long time since last update. I have removed posts that were meant to be experiments for old work. They are in the past. From now on, I will write more of my thoughts and many useful programming tricks, libraries, and tools that I have used in various projects.

I still write C/C++ and actually used it alone to develop all the computer vision and image/video processing algorithms for an internet video object tracking project for my current company. However, I will say that the most fun in programming is probably in Python, ActionScript 2/3, JavaScript, and Objective-C/iPhone. Lots of fun comes from programming with APIs like YouTube, Facebook, and many others. Expect I write more on these stuff.