石锅拌饭

[update: I have updated downloadable xmlrpc.php example for wordpress 2.1. It also fixes the wordpress 2.1 bug when getting category via xmlrpc. Check the end of the post. 2007-02-20]

I once wrote about “How to make ecto work with Ultimate Tag Warrior”. In that article, I discussed how to make the wordpress with UTW plugin recognize tag information sent by ecto. It works well except that some friends reported after the post is published, the tag information can not be stored in ecto. It means you lose track of all the tag information in ecto. When you edit a post, you have to set the tags again, which is very inconvenient.

From a post in the ecto forum, I knew that ecto recognizes mt_keywords. After some more hacking of xmlrpc.php, I fixed the problem. Now, you can not only use ecto to publish your post with tag information but also get tag information from your post. Here’s how (UPDATE: be sure to follow the steps in Part I before applying following steps. Thank Bruce for your reminding and all the helps):

First, you need to add one function in xmlrpc.php before the class wp_xmlrpc_server is defined:

/* ROBIN LU HACK get keywords */
function ecto_get_keywords($postid) {
$utw = new UltimateTagWarriorCore();
$tags = $utw->GetTagsForPost($postid);
$postkeywords = '';
if (is_array($tags)) {
foreach($tags as $data) {
if(!empty($data) &&
!empty($postkeywords))
$postkeywords .= ", ";
$postkeywords .= $data->tag;
}
}
return ($postkeywords);
}

Then, add this line

'mt_keywords' => ecto_get_keywords($postdata['ID']),

in function mw_getPost at where $resp is set:

$resp = array(
'dateCreated' => new IXR_Date($post_date),
'userid' => $postdata['post_author'],
'postid' => $postdata['ID'],
'description' => $post['main'],
'title' => $postdata['post_title'],
'link' => $link,
'permaLink' => $link,
// commented out because no other tool seems to use this
//	      'content' => $entry['post_content'],
'categories' => $categories,
'mt_excerpt' => $postdata['post_excerpt'],
'mt_text_more' => $post['extended'],
'mt_allow_comments' => $allow_comments,
//ROBIN LU HACK
'mt_keywords' => ecto_get_keywords($postdata['ID']),
'mt_allow_pings' => $allow_pings
);

Then add this line:

'mt_keywords' => ecto_get_keywords($entry['ID']),

in function mw_getRecentPosts() at where $struct[] is assigned like this:

$struct[] = array(
'dateCreated' => new IXR_Date($post_date),
'userid' => $entry['post_author'],
'postid' => $entry['ID'],
'description' => $post['main'],
'title' => $entry['post_title'],
'link' => $link,
'permaLink' => $link,
// commented out because no other tool seems to use this
//	      'content' => $entry['post_content'],
'categories' => $categories,
'mt_excerpt' => $entry['post_excerpt'],
'mt_text_more' => $post['extended'],
'mt_allow_comments' => $allow_comments,
//ROBIN LU HACK
'mt_keywords' => ecto_get_keywords($entry['ID']),
'mt_allow_pings' => $allow_pings
);

Save your xmlrpc.php and refresh in ecto. You will get all the tag information back to you.
There are xmlrpc.php files for different wordpress version:

• xmlrpc.php for wordpress 2.0.1
• xmlrpc.php for wordpress 2.0.3
• xmlrpc.php for wordpress 2.1

在中期review的时候发了一篇牢骚，引来了一些朋友的共鸣和反馈，一位guest朋友留言谈了他的经验：

量化工作也是职业化的一种吧。尽管我个人对此并无赞同或者反对。不过如果特别是说程序员做Object Setting，我有一点经验，不知道有用没有：最重要的当然是需要完成的项目。每个项目都会有roadmap吧？roadmap上的milestone就可以作为一个时间上比较靠谱的参考。然后开发时候，陆续把所有的任务都敲碎放到bugzilla里去。到项目结束/年度结束，考察工作其实就是review bugzilla。再不懂技术的老板，看到通过解决的所有的可预见的问题和中途修改好的bug报表（所以要用bugzilla，因为它能自动生成报表），也都会对一年的工作有数了。至于说performance，这个东西应该是相对的，而且最好是这一年度的bug报表对于上一年度的比较。说真的，这东西确实没有什么实际用处，谁会因为多写了一年程序就真的提高了多少performance，这种循序渐进的东西确实无法量化。

对目标的制定也许会很让人迷惑，我的不一定有用的经验就是写的越具体越好。百分比应该用在对项目完成度的衡量上。但是如果有百分比，就一定指出来那些没有包括进来的百分比是留在下一年了，还是有团队的其它人来完成。这对于项目管理者来说也会有帮助的。

定期review工作的好处是，可以及时发现blocking bug，并且对此做出相应的调整。但是管理者不见得能够实践后一条，这可能也不说明review工作真的没有用，只是管理者本身执行得不够好。

其实我并不反对设定目标和定期的review，我反对的是这种纯粹management oriented的长期目标设定和review。
实施敏捷开发有一段时间了，一个scrum的周期最长也就是一个月，每天都会花很短的时间做前一天的review和目标的调整。我体会到的这个过程的要点就是:review要及时，目标设定要随时调整。我对以年为跨度的object setting和performance review的最大困惑就在于两者的严重脱节。
实际上，这样长跨度的目标设定，更倾向于一个career plan而不是project或者product plan。而拿一个career plan作为年终performance review的依据，纯粹就是牛头不对马嘴。

在三个不同的外企呆了一共快六年的时间，有一个共同点就是每年年初都要做Object Setting，年终要做Performance Review。不知道是这个做法本身有问题还是在中国没执行好，每年到这个时候面对一堆的表格我不知道要添什么，也不知道别人想要我添什么。其实说来简单，Object Setting无非是定一个目标，为这个目标制定一个计划，最后给一个衡量标准，怎么才算目标达到。Performance Review的时候就拿出你当年添的东西一一对照，哪达到了哪没达到。就象自己先下个套，然后钻。怎么看怎么别扭的一个过程。至今我仍然搞不清楚作为一个程序员该如何设定目标，我曾经这样制定过：我的代码（包括bug fix和新feature）产生的P1的bug不超过xxx个，P2不超过xxx个。第二年，为了表示进步，我需要这样制定：P1 bug减少5%，P2 bug减少10%。听上去和扯淡差不多。或者写今年我要做三个features，修100个bugs。更离谱。目标定高了是和自己过不去，定低了是和老板过不去，定实了到年终全变样，定虚了又没法衡量。大多外企的现状也使得Performance Review的作用落不到实处，高了不会升你低了不会抄你。每年两次轰轰烈烈运动的主要作用就是浪费时间。如果还有什么比着更无聊的，可能就是再加一个中期review了。