手機差點不見…懺悔中

我的手機是 HTC Desire 已經用了一年多,平常都會小心收好,但就在今天傍晚大概六點左右,我突然發現我的手機不見了,四處都找不到,口袋也沒有…

雖然我一直都對我的 Desire 不是很滿意,可是我目前還沒有和它分開的打算阿阿阿!

抱著死馬當活馬醫的心情,我打了我自己的電話,希望電話那頭可以有人接起。

第一次打電話,沒人接聽…

第二次打電話,依然沒人接聽…

就在我要死心的時候 ,突然我的電話響了(我的市內電話) 。看了看來電顯示,原來是樓上的收發室打來的。我心想,該不會是有人撿到我的電話,然後送到收發室吧?

我忐忑不安地接起了電話,電話那端傳來收發室的小姐的聲音:「你說是不是掉了手機?」

呼,我心中終於放下一顆大石頭,不用花錢買新手機了 Q_Q

還好是在公司裡面掉的,謝謝幫我把手機送到收發室的無名英雄,雖然我不曉得你是誰,但我打從心底謝謝你的好心,讓我不致於因為我自己的粗心大意而付出代價。

以後我會認真保管好手機的!

Plurk 訊息取得時間分布

這是一隻我寫的 Plurk 機器人(註一) 在不同時間差的情況下個別抓的「待回應訊息」 (註二) 分布狀況。

目前共有七隻 fetcher ,第一隻 fetcher 使用 Plurk Real Time Channel API ,其餘六隻 fetcher 使用 Plurk Polling API 並且以延遲 10s, 30s, 60s, 90s, 180s, 240s 的時間差 (offset) 來抓取訊息,圖表的縱軸代表「待回應的訊息」數目,橫軸則是時間差。整個圖表趨勢如果越往左靠,則表示 Plurk 系統對訊息同步的即時性越好,如果越往右靠,表示 Plurk 系統在訊息同步上花的時間越多。

之前在抓取訊息時,我都只抓取一分鐘之內訊息,過期的都不抓,但這樣也造成不少人說機器人沒有回應 (沒回應表示一分鐘內機器人沒抓到使用者發的訊息),以上圖來看,就是以前至少有 30% 的「待回應訊息」我漏抓了。

這種情況下,唯一的解決方法大概就是把時間差 (offset) 再加大。但其實這麼做的幫助很有限,因為使用者通常會因為等太久而自行砍掉沒有回應的訊息,然後機器人這邊則是會因此發生 (plurk not found) 的錯誤。

目前透過 Real Time Channel API 拿到的只佔 34% 左右,有 30% 是 offset 在 10s – 60s 之間拿到,而剩下 35% 則是超過 90s 才拿到。

備註:

  • 這隻機器人的架構設計分為 fetcher 和 replier ,可各別決定要跑幾個 process 起來,目前機器人有 26.8 萬個好友,現在實際狀況是跑七隻 fetcher 和一隻 replier 。
  • 「待回應的訊息」就是拿到的訊息中含有觸發機器人的關鍵字,其餘則為「不回應的訊息」 ,我會記錄每則回應的訊息,並以 fetch_offset 欄位代表是在哪個時間區間的 fetcher 抓到的,統計回應時間差的 SQL 如下

最近機器人的回應狀況不甚理想,我會再觀察一至兩週之後再 update 一下。