A quick comparison between Readability and Pocket

To be honest, I'm not really a hard-core tech. fashion follower. That's why I heard of Pocket and Readability just a few days ago. I downloaded both app to my Motorola Defy (Cyanogen Mod 9 nightly buids) and registered accounts. Then I used them for days.

Feeling? See below:

Adding entries: Pocket > Readability.
Both Readability and Pocket support adding post from Browser. Pocket uses an snippet of  Javascript code, which can be saved to bookmark list. Readability recommends I install a plug-in, which supports Safari, Firefox and Chrome. By the way, it looks like there's no plug-in for IE. Does Readability team decide to remove the support for IE? Kindly correct me if I'm wrong.

I personally like Pocket's way a little bit more. Installing a plug-in is not always working when user need to use a shared computer (like me). Pocket's solution is simpler, and working for almost all browsers.

In my Android phone (Motorola Defy), the story is a little bit different. Both two apps provides "share to ..." for sharing. The difference is the UI response: Pocket is always pops an quick on-screen message fast, while Readability's sharing button has no response until several seconds after. Another problem is Readability sometimes pops up a "adding article fails" message so I have to share it again, while Pocket never fails me.

NOTE: As a man lives in Great Fire Wall, I can't confirm if Readability should be responsible for the last problem.

Sync: Pocket >>> Readability.
I'll say this is the most important reason I like Pocket. In the environment of using my China Unicom ADSL connection, a new post can be seen immediately in Pocket. Meanwhile, I have to wait for a while (probably 2 - 3 minutes) to see it appear in Readability reading list.

Frankly speaking, this issue may not be a deal break: why do I want to see an entry in list when I has already decided to read it later?

I think it's just because of perfection. Who knows?

Page re-formatting: Readability >> Pocket.
Readability wins. With multiple reading theme and clear font settings, the reading experience is more comfortable. Meanwhile, Pocket only allows switching fonts by clicking the same button for several times, which is not intuitive to me.

Add-on for Chinese. One difference between Readability and Pocket for Chinese character is Readability does not use Italic fonts for Chinese characters, while Pocket uses it. Though I personally believe this is a bug, I must say thanks to Readability. This is because Chinese does not use italic at all. As for Pocket, the use of italic fonts makes Chinese articles looks weird.

Night reading mode: Readability >> Pocket.

In one word, I hate the night reading theme from Pocket! There's only one pure black theme for Pocket and it looks ugly. Readability is much better: it offers five themes (wheat, black, light blue, etc.) to allow me choose proper theme for different environments. The most remarkable point is Readability uses a dark grey background for night reading theme, instead of pure black. That makes my eyes much comfortable. My taste, at least.

Subscribing: Readability > Pocket. (You may have different point of view)

Readability offers a subscribing mode, which charges us a small amount to support article writers, $5/month. The 70% of the money will go to the article writers. I didn't see equivalent approaches in Pocket.

Some people may not like it. As for me, I'm fine because I'm always happy to support my favorite writers. So that depends on you. At least, you may choose to decline this without losing any features from Readability.

App memory usage: Both are bad :(.

Well, when saying memory usage, I mean Android. Both apps uses 35+MB memory, which eats a huge block of memory. When I keep both open, my poor phone becomes slow because memory is swapping in and out.

Conclusion? Not yet.

I want to try more, as I'm still new to both services. Moreover, I don't know if I should recommend you guys use them in phone. I personally prefer Evernote if I want to keep an article. If I want to read an article later (and in a cleaner format), I like computer. Anyway, let me try it a little bit more before making a conclusion. I'll keep you updated.

A quick script to convert your BASH environment settings to environment.plist

When a new Linux guy who switchs to Mac, the first problem for them to use environment.plist. Here's a simple example to convert environment settings to environment.plist. This is especially true when the project you work with uses a lot of environment settings in your XCode project file.

So I created the script below to help me sort it out. It is not a complete script to handle all special cases like differences between ${} and $ token in BASH, but already good enough in my environment.

Try modify code yourself and enjoy hacking!

#!/usr/bin/env python
import sys
import re

keyval_pat = re.compile(r"[ ]*export ([^=]*)=(.*)")
fd = open(sys.argv[1])

print(r'<?xml version="1.0" encoding="utf-8">')
print(r'''
<!DOCTYPE plist PUBLIC 
    "-//Apple DTD PLIST 1.0//EN"
    "http://www.apple.com/DTDs/PropertyList-1.0.dtd">''')
print('<plist version="1.0">')
print('<dict>')
for each_line in fd:
    m = keyval_pat.search(each_line)
    if m is None:
        continue
    key = m.group(1)
    value = m.group(2)
    print("<key>%s</key><string>%s</string>" % (key, value))
print('</dict>')
print('</plist>')
fd.close()

DummyDigit, Reloaded

It has been a long time since my last blog post was out. Sorry for keeping silent for such a long time.

There were so many things happened from 2010 to 2011. Quite a bit. My girlfriend broke up with me. I dropped my job in US and moved back to Beijing. I broke up with my girlfriend (nah you know the difference, buddy). I lost my job (the whole team was cancelled) and got the second offer to went back to US. I found my new love and decided to stay. I got a second job and declined the offer.

Crazy, huh?

Anyway, just like everyone says, thing always becomes better. Though I'm really missing my friends in Washington, I decided to stay in Beijing with my girl for a while. Meanwhile, it's also the time to make this Blog active again.

I'm back, my friends.

TaggyTODO：该不该添加周期性任务支持？

很长时间没有更新TaggyTODO了。这期间发生了很多事情，有个人的，也有工作上的，导致实在没有时间。但最主要的问题是设计上的，因为我正在考虑一个重要功能，而这个功能最终可能导致整个设计的大幅改变，我不敢不慎重。

这个功能就是周期任务支持。

我一直很犹豫是不是需要让TaggyTODO支持周期性任务，因为这个东西实在非常有诱惑力。很多我们生活中的任务都是周期性质的，比如每个月的水电费，支付信用卡帐单，话费，等等。

但是周期性任务的支持会带来的设计上的巨大变化。首先是我们如才能合理地定义多个任务。有一个很简单的方法是：一个任务需要重复多少次，我们就在数据库里保留多少个任务。这个设计是最简单也最容易实现的，但这一来有一个问题：假如用户要求无限重复怎么办？例如用户试图定义一个任务，记录每个月的水电费缴纳情况。假如他／她已经买了房子，那么这个任务可以一直持续到他／她把房子卖掉的时候。我总不能添加无数个任务对象。退一步讲，即使我们限制了重复的最大次数，比如最多365项，那么用户定义一个每天的任务就需要占用365个项目，任务一多起来就会迅速地占用数据库的大量空间，我个人认为这个很难接受。


另一个方案是只定义一个任务，但通过内部添加一些数据来表示和记录多个重复事件的完成情况，每个任务可以通过当前日期计算出相应的起止时间。这个方案就可以有效地节约空间占用问题，但存在一个缺点：假如用户备份并删除了一个老任务，那么后来应当发生的新任务就给一并删掉了。另一个需要解决的问题是如何处理临时改期。对第一个方案这不是问题，而对这个方案来说则需要添加一个新事件，那么如何关联两个事件？这也是需要解决的。


当然，一个最直白的手段是：我不支持重复事件，简单而直接。事实上很多我见到的任务管理程序就是这么做的。不过我还是希望给自己一点挑战。

先记录到这里吧。

TaggyTODO：工作模型（三） 任务分类

标题更新：Gotask正式更名为TaggyTODO。


我对任务分类的考虑相当简单，就一条：tag。每一个TaggyTODO中的任务都可以被打上一个或多个标记，比如“家庭事务”，“工作”，“重要”，“可以忽略”。每当定义一个新的任务时，用户可以选择打上对应的标记。在后来查询的时候我们就可以利用这些标记过滤出我们要的任务，比如“所有可以忽略的工作事务”，或“重要的家庭事务”。我知道很多管理程序都喜欢在tag之外再实现一个能包含层级关系的category概念用于分类，但我不打算这么干，因为我认为tag本身已经足够用于表示分类，至于层级关系，我认为可以用tag组合代替，不需要多此一举。

必须强调的是，我希望tag是必须先定义后使用的。这一点和通常意义上的tag不同。如今我见过的很多用tag这个概念的软件一般都是允许用户随意增减tag的，比如Blogger，每一篇文章都能随便加个标记，Blogger会记录所有用到过的标记，并只显示目前仍在被使用的。但是我认为随意定义tag的做法不适合管理任务，因为用户可能会定义一堆实际意义相同而叫法不同的标记，然后在最后定义query的时候发现自己顾此失彼，总是漏掉一两个任务。

我更期望一个tag应该是一个有限的集合。用户用之前就定义好，需要的时候从列表中选择。这样用户能更仔细地定义所有的tag，因此任务的标记信息可以更规范。除此之外，预先定义还有一个额外的好处：当用户发现某个tag名字不合理时不用一个个任务修正，只需要修改那个tag定义本身就可以了。——别忘了TaggyTODO的目标是用来管理大数量的长期任务，要求用户一个个修改任务可不是什么聪明主意。

最后，我不打算提供任务名称中关键字搜索的功能，也就是说，查询任务时tag是除时间之外唯一的搜索条件。我知道也许有人会认为这种做法太死板，特别是Outlook的用户，他们往往更习惯于在search框里输入标题中的关键字来查找。但我认为我的考虑更适合TaggyTODO，理由有两个：

• 概念单一不会使用户养成不同的使用习惯。假定我同时提供标题字符串搜索和tag，就可能出现两个用户一个习惯用tag而另一个习惯搜索标题的情况。如果他们两人共享任务列表，则合并后的task就无法满足任何一个人的需要。
• 基于tag查找的方法进行优化的方法简单。单纯字符串搜索就可能得动用索引结构之类的大家伙了。相比之下，我更希望我的软件能尽量小一点。

当然，TaggyTODO相对于邮件程序而言更容易实现分类规范化。因为所有的任务定义都是从用户这边来的。邮件程序必须使用字符串搜索的理由是用户收到的邮件来自四面八方，我们不可能要求所有联系人都用一样的规范写信。相比之下，都是自己定义的任务就不会有这个问题。

First Release: GoTask is renamed as TaggyTODO!

OK. So I finally pushed the first bunch of code for GoTask to Google Code. It's still incomplete, which can only run some basic unit tests, but I'll update in the new year. -- New year, new start, right? :)

Also, I finally found a name for the project: TaggyTODO. I have to change the name because I found the name GoTask has been used in another project, a library for Game development. Hope the name is not used again.

If you are interested in it, check it out from http://code.google.com/p/taggytodo.

ConsoleKit, access denied and a see-it-once bug

    I just noticed an interesting bug when I upgraded my ArchLinux last Sunday.  Every time when I log on my Openbox desktop, I found my NetworkManager applet icon cannot be shown on the system tray. When I invoke nm-applet from comman line, I got an error like below:

** (nm-applet:14122): WARNING **:   applet_dbus_manager_start_service(): 
Could not acquire the NetworkManagerUserSettings service.
  Message: 'Connection ":1.21" is not allowed to own the service 
"org.freedesktop.NetworkManagerUserSettings" due to security policies in the 
configuration file'

The most interesting thing is: the issue only happens *once*. When I log out and log in again, everything looks fine.

Obviously it's not a hardware issue. Since it only happens after upgrading, I decided to have a check on udev configuration files and finally got something new:

<policy at_console="true">
   <allow own="org.freedesktop.NetworkManagerUserSettings"/>
   <allow send_destination="org.freedesktop.NetworkManagerUserSettings"
     send_interface="org.freedesktop.NetworkManagerSettings"/>
   <allow send_destination="org.freedesktop.NetworkManagerUserSettings" send_interface="org.freedesktop.NetworkManagerSettings.Connection"/>
</policy>

This is new to me. I know that the traditional way is to use network group to define who can access network configuration. I also got some suggestions from *here* that I should add to make it back to old behavior.


But wait -- is it really the root cause? If that is the case, why it works when I log on twice?

After some studies I noticed that the settings above are used by ConsoleKit. Meanwhile, I also found that there should be a daemon, /usr/sbin/console-kit-daemon, which will assign an XDG_SESSION_COOKIE environment variable to every active logon session so it can determine who is using the current console. This is important for nm-applet to determine who should be assigned the access to read network settings.

Look -- the key is here. I didn't see XDG_SESSION_COOKIE environment variable when I log on system for the first time! However, I'm able to see the setting from the second logon. It seems the server was not there but was then invoked after first session, but NO DOCUMENT says that console-kit-daemon can be automatically started!

So the final fix is rather simple: I opened my /etc/rc.local file and added two lines:

#!/bin/bash
/usr/sbin/console-kit-daemon

That will force starting a console-kit-daemon service when system starts up. I rebooted the machine and everything works then.

Also, it just solve another see-it-once issue: my PCManFM file manager always give me an error when I'm trying to mount any USB flash disk, with a message like "send message rejected". This is also a see-it-once issue on my first logon session. After applying the fix (or workaround? Who knows) above, it also disappeared.

So my friend, if you are also experiencing the same issue, try that. Good luck.

Gotask：设计部分暂停

简单地说，四个原因：

a) 最近工作实在太忙，脱不开身。
b) 最近是人生一个重大转折，不可不上心。
c) Gotask可能要改名。
d) 光说不练，假把式。

这一个多月我也没闲着，目前的状态是Gotask的查询部分代码已经完成，正在开始写XML解析和数据库的部分。如今暂定的计划是年内能够发布查询和数据库部分的函数库代码，而后续的设计我希望留到至少开始UI部分再开始。

另外，Gotask使用的开发语言是Python（>= 2.5)，暂时没有做C扩展的方案。目前的计划是在数据库和查询的部分实现Python2和Python3双兼容，UI部分第一个实现应当会基于GTK+。