為老不專

軒爸 | 31st Jul 2008 | 一般 | (319 Reads)

小弟所工作的公司, 是一間7x24運作的IT公司. 無風無浪時, 大部份同事都可安枕. 不過, 每兩三個月總會發生一場或大或小的意外(奇怪, 通常都出現在long weekend的!), 一些24小時on duty的同事就會四出致電各負責的部門, 負責部門的同事就得VPN回公司Fire Fight. 當然, 吃得咸魚抵得渴, on call本就是工作一部份嘛, 沒甚麼問題. 但畢竟那是意外, 有時發現得早, 有時發現得遲, 加上負責的同事亦有可能一時連絡不上, 令通報機制沒有展現出其應有的效率, 白白錯過了最佳的救災時機.

我想, 應該有不少公司也有類似的情況發生吧. 小型一點的公司, 可能連通報機制也沒有. 所以, 我就為此花了點時間, 設計了一個Free SMS Alert Broadcast系統, 做福人群.

這個設計選擇了利用SMS作通報, 是因為SMS乃非實時通訊, 就算看電影關了手機, 電池耗盡, 或手機一時沒帶在身邊, 只要一開著手機就能收回訊息. 如此, 大大減少連絡不上負責同事的機會. 不過, 大家都知道, 收SMS多是免費的, 但發SMS通常卻都要錢. 而這點, 大方非常的Google Calendar所提供的免費SMS Alert就可以幫上一把.

下面, 我將一步教大家如何設置SMS Alert Broadcast.

首先, 我們需要有一個Google Account, 而這個Account, 我建議是一個全新的(稍後再解釋). 我稱它為Master Account. 先以這個Master Account登入Google Calendar後, 再開一本新的Calendar. 這本Calendar要共享給需要收SMS的同事的Google Account(沒有就申請一個吧). 然後, 同事需要把該Calendar的預設提示設定為5分鐘SMS. 當然, 想Google發SMS給你, 也得先設定自己的手機號碼. 值得注意是, Calendar是可以同時共享給多位同事的, 就是說, 大家可以同時收到SMS(要不然, 怎叫SMS Broadcast!)

好了, 設定完之後, 就是Programming時間了. 編程分成兩部份. 第一部份, 是一些為系統健康檢查程序, 用以定時替系統把脈. 程序可能是檢查硬盤夠不夠剩餘空間, 也可能是直接檢查SYSTEM LOG, 又或者某Web server是否還正常運作. 一有問題或出現Error log, 就通知第二部份. 這第一部份可以是五花八門, 任你創作的, 因應不同系統就有不同需要, 不能一概而論. 你一時想不出有甚麼要檢查沒關係, 意外多發生幾次你就會知道了.

而第二部份, 就是利用Google Calendar API, 將第一部份的結果, 轉變成Calendar Event. Event設定的時間, 應該是5分鐘之後(注意:若你電腦的時鐘沒跟Google同步, 這個時間你得調一調了), 那未, 預設SMS提示就會被觸發, 各同事同時收到SMS. 好, 救火隊要出發了!

整個設計, 大致就是這樣.

這個設計除了可免費發SMS Broadcast外, 還有以下優點:

每發一次SMS, 即代表加了一個Calendar Event. 即是說, 所有問題都一一記錄在案. 運作了一段時間之後, 打開Calendar, 意外記錄一目了然, 你就知道自己的系統有多穩定(或不穩定)了!
Google Calendar能以「唯讀」形式共享Calendar的. 所以, 就算很多人共享了Calendar, 也沒有人能竄改意外紀錄.
再者, 因為發SMS時是要把Account的密碼傳給Google Calendar API. 這意味著密碼寫死在檔案上. 我想, 是沒有員工願意把自己的密碼給公司使用罷. 所以, 利用「共享」功能除了是為了做Broadcast, 也是為了保護員工自己的Google Acount. 在程序上, 只管記著那個Master Account的密碼就夠了. 那末, 推行起來就不會有太大阻力.
當公司有不同部門時, 需要收到不同的SMS訊息, 如此可利用Master Account多開幾個Calendar, 共享給不同的人.

大家覺得這設計怎麼樣, 有興趣嘗試一下嗎? 如果大家想試試, 不妨留言或Email(jesse@ymail.com)給我, 交流交流, 指教指教, 多謝!

留言(0) | 引用(0)

Y!BOSS : 有得任Search至係老闆

軒爸 | 23rd Jul 2008 | 一般 | (93 Reads)

Yahoo!早前「開放」了其搜尋引擎的API, 該Project名為Yahoo!BOSS (Build your Own Search Service). Y!BOSS其實並無帶來新奇事, 所謂開放的技術其實很少, 論創意亦絶及不上Y!SearchMonkey. 不過, 其帶來的意義卻重大. 因他真正開放的, 是其Search API使用的自由度.

在以往, 任何Search API的限制都多. 限制包括搜尋的次數, 對搜尋結果重排和過濾, 或混合其他搜尋引擎的搜尋結果等等. 這方面, Yahoo原有的Search API和Google AJAX Search亦不例外. 這些限制, 其目的主要是為保障自家搜尋引擎而設. 敝去這些限制, 任誰也可以建基於現有成熟的搜尋引擎, 零成本另做一個搜尋網站, 甚至青出於藍. 要知道, 搜尋引擎和Web2.0網站不同, Web2.0開放API會帶來更多用戶, 但全面開放Search API, 只會帶來的競爭.

其實做一個搜尋引擎的技術門檻是很高的, 所以, 你就算有甚麼具創意的搜尋點子, 你也無法像Web2.0網站般容易做出來. 當然, 人家不全面開放API, 是其商業決定, 但這決定的確扼殺了不少創意. 試想想, 現在大家慣用的搜尋形式其實都千篇一律, 十年如一日, 你不覺得悶嗎? 我確信那存在不少發展空間.

不過, 全面開放這一著, Yahoo!還是做了. 現在使用其API的唯一考慮, 只是將來可能要讓Yahoo!在你的網站上放廣告(但那不是API層面的事了). 而你想到甚麼搜尋點子, 就可以立時在上面造出來.

看上去, 這似乎是拿石頭擲自己雙腳的決定, 不過, 也同時拿了另一塊石頭擲Google雙腳. 然而同樣的一塊石頭, Google似乎會痛一點. 因為其業務有更多是倚重搜尋引擎的. 又或者, 可能Yahoo!看到了搜尋引擎的競爭在"What to Search"部份己成定局, 倒不如帶頭開闢"How to Search"新天地. 說不定可重掌搜尋市場的一哥地位.

讓來自世界各地的developer做自家搜尋引擎, Yahoo!不費甚麼勁就以另一個形式擴展其搜尋引擎, developer又能建立自家引擎並從中分享其廣告利潤, 絕對是雙贏的. 作為developer的你, 豈能無動於衷呢?

留言(0) | 引用(0)

Facebook Application Hosting新戰場

軒爸 | 16th Nov 2007 | Blog 事 | (1274 Reads)

寫Facebook Application和自架網站一樣, 也需要hosting. 不過, 選擇hosting時, 考慮卻很不一樣.

首先, 是地點問題. 要知道, 用戶用Application時, 是直接連上Facebook, 然後Facebook才連上server. 換言之, 你只需要考慮到Facebook和Hosting之間的速度問題. 無論那Application面向本地用戶還是全球, 你所考慮的, 是完全一樣的, 就是放在美國, 並且越近Facebook的Datacenter越好. 一個原先在本地做hosting的.com, 要寫個像樣的Facebook Application, 最好另建server.

再者, 是關於收費計劃的問題. 傳統hosting本來也會有類似問題, 但因為social network的傳播速度快, Facebook Application的「成功/失敗週期」比.com短得多. 一個Application若成功, 一星期已看出端倪, bandwidth/CPU/Ram的需求激增, 急需升級. 但若無起色, 兩星期也嫌多. 給你重整軍型, 頂多三個星期你好認輸了. 所以, 在First launch之前, 你就要有到天堂的準備. 因為你不過一星期時間, 就可以到天堂, 也可以去地獄. 地獄你固然不想去, 但就算去天堂, 你也得早些準備一下去天堂的路線圖罷. 另外, 傳統的hosting公司應配合, 提供更具彈性的收費計劃給Facebook Application Hosting.

然後, 還要考慮的, 就是當你真的「爆」熱之後(誰不考慮這點, 你總應為自己的點子是最強的, 對不?), 你的hosting如何對待你. 因為要隔山買牛, 很容易誤墮流氓hosting的圈套. 萬一真的「爆」了, 卻給流氓諸多理由坐地起價, 網站被停一陣子. 到你忍痛付費, 說不定已出現了copycat. 極速推進的穿梭機遇上了飛毛腿導彈, 你會死得很慘.

不過, 無可否認, 現時的Facebook的Application尚算幼嫩, 多是Toys, 生命週期故然較短. 將來若出現一些實用性較強的, 可能逃過這宿命也說不定.

Facebook, Joyent和DELL以乎早就看到這點, 昨天就合作推出一Facebook Application Hosting計劃. 用戶頭一年免費, 第二年$45/month. 不過按前面的說法, 一個Facebook Application免費一年, 根本是多餘的. 所謂一年免費, 除了是宣傳, 是綽頭, 也是一年後趕失敗者離開的理由. 因為成功的話, 你早就找Joyent即時Upgrade了.

計劃還有兩大賣點, 一是他們的server根本就和Facebook server放同一Data Center, bandwidth有了最大的保障. 二是他們支援SSH, 而且有root access (不代表有root account)! 那根本就是一台VPS嘛. 你要用PHP, Ruby on Rails, Python或Java, 悉隨尊便, 彈性極大.

Joyent一下子網羅大批潛在客戶, Facebook可保証Application(在bandwidth上)的穩定, 用戶又有一個理想的startup平台. 這絕對是個三贏方案.

不過, 要有足夠穩定, 也不一定要和Facebook當鄰居才成, 真正吸引的, 還是價錢, 技術支援, 收費彈性和透明度. 所以, Joyent並不會是唯一方案.

我想, Facebook Application Hosting的戰幔, 現在才剛揭開.

留言(1) | 引用(0)

Custom Blog Search Engine

軒爸 | 17th Aug 2007 | Blog 事 | (1717 Reads)

Google有個Application叫Custom Search Engine, 而小弟手頭上又有一份頗完整的HK Blogosphere清單. 兩者結合, 不就成為了一個香港Blogosphere的Search Engine嗎? 真蠢, 竟現在才想到.

可能有朋友未必知道Custom Search Engine是甚麼, 我就在此說明一下. 使用Custom Search Engine, 你可用自己提供的網站清單去製造一個Search Engine, 而該Search Engine所Search出來的結果, 只會是清單內所列出的網站. 這效果, 有如使用Query Modifier "site:"去指定一兩個網站為搜索範圍, 不過, Custom Search Engine最多可定義的網站(或URL Pattern), 是5000個. 作點取捨, 這勉強夠容納香港的Blogosphere, 但作了甚麼取捨, 就不便公開了.

又, Google雖然說這是Custom Search Engine, 版面其實沒其麼可以Customize的, 但那Logo倒是可以換的. 要是有朋友可以免費幫幫我這個美工白痴設計一個Logo, 實在萬分感激.

老實說, 這東西並非我心目中最理想的Blog Search Engine. 但不費灰之力, 就可以完成一個Search Engine, 真的非常過癮, 又可以益街坊, 何其好玩!

由此路進>> HK Blogosphere Search
或

留言(5) | 引用(0)

Xanga陣容強大

軒爸 | 23rd Jul 2007 | Blog 事 | (3103 Reads)

Krusk之前在留言中提過Xanga Metros. Xanga Metros是一個以地區劃分Xanga用戶的功能, 網頁面入聲稱, Xanga的香港用戶數目有383756(as at 2007-07-18). 當然, Xanga自己公報數字畢竟會有利益衝突, 所以我們還是應先抱懷疑的態度. 好, 繼「香港的Blogosphere有多大」之後, 我再下一城, 計計Xanga的香港用戶到底有多少.

例牌, 先說說計算方法. 今次的判斷條件比較簡單, 就是如果某Blog是繁體中文的, 就被當作是香港blog. 因為根據Xanga Metros提供的香港用戶數目(383756)和台灣用戶數目(7399)的比例, 是51比1, 所以, 就算納入台灣blog, 估計對結果不會有太大的影響. 如此, 就不大費周章判別台灣Blog, 只在過後檢查一下, 並按檢查結果在比例上扣減就行了.

另外, 因為有部份的Blog是有閱讀限制的, 可能是會員限制或者年齡限制, 總之不是全面公開的. 這類Blog, 我將不會計算在內(但Xanga Metros所公報的數字中, 這類Blog是有計算在內的).

編碼方面, 這次支援三種編碼, UTF-8, BIG5和HTML Encoding. 出乎意料之外, BIG-5並非佔多數, 有很多都是HTML Encoding的. 關於HTML Encoding我常稱它為無敵編碼, 因為採用HTML Encoding的網頁, 在任何情況之下, 中文顯示都會正確無誤.

程式斷斷續續的跑了幾星期, 終於跑完, 而我得到的結果是370016, 非常接近Xanga公報的數字. 若加上那些把Blog上鎖的用戶, 我認為Xanga Metros所公報的數字應該是可信的. 關於台灣的問題, 我從結果中隨機抽樣了一百個, 發現沒有一個是台灣Blog. 我猜測台灣的用戶實在太少, 跟本沒有形成一個用戶群並互相連結, 以致沒有找到他們的蹤跡. 所以, 370016個Xanga用戶加上上次的48167, 香港的Blogosphere大約有418183人. Xanga果然陣容強大, 後生可畏呀!

P.S. 今次清單超過5MB, 太大了, 我就不打算提供連結. 若大家有興趣的話, 就自己上Xanga Metros玩玩啦!

留言(7) | 引用(0)

Hacking Mysinablog : 全文皆Feed

軒爸 | 20th Jul 2007 | Blog 事 | (966 Reads)

一直以來, 都想用全文Feed, 但若在Mysinablog採用全文Feed, 將嚴重影響首頁的外觀. 順得哥情失嫂意, 為靚靚, 只有放棄全文Feed(當然, 若你不使用全文Feed原因只是為衝View Count, 你不用讀下去了). 近來, 亦有不少聲音有大呼全文Feed, Jacky甚至寫了個Greasemonkey script來「對付」Mysinablog(等BSP). 身為Mysinablog的blogger, 要人家扭盡六壬, 只為求看自己的文章看得輕鬆一點, 實在有點不好意思. 我想, 我們倒不如從自己做起, 就發明了一個可在Mysinablog使用全文Feed而不影響首頁的方法. 大家有興趣, 不妨試試. 此發明分開兩部份, A)修改設定; B)改變發文方法(別怕, 大致上和以前是一樣的, 只有很少改動).

A) 修改設定
Step 1 : 先到「外觀管理」 > 「SideBar設定」 > 「新增項目」
Step 2 : 增加一個新的「自訂項目」, 「自定名稱」為一個空格(space), 而內文如下:
<script type="text/javascript" language="javascript">
if (document.location.href.indexOf("op=ViewArticle") == -1 && document.location.href.indexOf("admin.php") == -1) {
var els = document.getElementsByTagName("div");
var elsLen = els.length;
for (j = 0; j < elsLen; j++) {
   if (els[j].className == "post_content") {
    var node = els[j];
    len = node.childNodes.length;
    hrAt = len;
    for (var i = 0; i < len; i++) {
     if (node.childNodes[i].nodeName == "HR") {
      hrAt = i;
     }
    }
    if (hrAt != len) {
     for (var i = len - 1; i >= hrAt; i--) {
      node.removeChild(node.childNodes[i]);
     }
     var anchor = document.createElement("a");
     anchor.href = els[j - 3].childNodes[0].href;
     anchor.innerHTML = "(閱讀全文)";
     node.appendChild(anchor);
    }
   }
}
}
</script>
正確的話, 應如下圖:

Step 3 : 到「外觀管理」 > 「SideBar設定」 > 「CSS設定」

Step 4 : 在CSS的最底, 加上下面這段, 按「更新」.
hr {
display: none;
}

B) 發文方法
Step 1: 一篇文章, 在Mysinablog可以分為兩部份, 內文和伸延內文. 首先, 你要做的是和往常一樣, 把內文放在上面的文字框.

Step 2: 按

加入分頁線

Step 3: 把剩餘的伸延內文, 放到分頁線以下.

Step 4: 按「發表」, 完成!

示範單位 : 活在Web1.0 @ 軒爸湊仔公

好了, 那邊廂有Reader為讀全文Feed動手寫Script, 這邊廂又有Blogger為出全文Feed動手改Blog. Mysinablog, 你做啲嘢啦, 好嗎?

注意事項 :
1. 你不能在文章內用"分頁線"作間隔. (其實只有少數人會使用分頁線的)
2. 伸延內文有機會出現在首頁大約一秒時間. (若Browser慢, 時間可能再長一點)
3. "分頁線"雖不會出現在內文或首頁, 但還是會出現在Feed Reader裡面, 可幸是, 這不太會影響閱讀.
4. 因為此方法建基於Mysinablog的頁面結構之上, 若Mysinablog更改結構, 此Hack有可能失效. 不過, 此可能性微乎其微, 因為若Mysinablog更改結構的話, 很多Blog的CSS/Javascript亦將失效. 不過, 要是真有此一日, 我亦很樂意因應變化作出修改.

(P.S. 本文已經應用此法...... 不過, 暫時應該沒有多少人會用Feed Reader看我這個Blog罷.)

留言(3) | 引用(0)

RoadShow慶回龜俾面派對

軒爸 | 21st Jun 2007 | Blog 事 | (718 Reads)

睇完呢篇野, 希望大家下次睇RoadShow時心理會好過啲.

留言(0) | 引用(0)

香港Blogosphere清單 (Y!Blog)

軒爸 | 14th Jun 2007 | Blog 事 | (1954 Reads)

留言(0) | 引用(0)

香港Blogosphere清單

軒爸 | 7th Jun 2007 | Blog 事 | (2069 Reads)

特將此Blogosphere清單獻給今天一歲生日的愛兒軒軒和勞苦功高的軒媽.

(閱讀全文)

留言(18) | 引用(1)

香港的Blogosphere有多大? (剪紙篇) [完]

軒爸 | 7th Jun 2007 | Blog 事 | (2431 Reads)

小時候, 曾經從八卦雜誌上, 剪下喜愛的明星照片, 然後貼在自己的相片旁, 扮作跟他有張合照. 那個年代, 並沒有Photoshop, 所以都是用人手剪下來的. 自問手藝不錯, 沿衫邊剪, 沿手指剪, 沿耳朵剪, 都難不到我, 但難就難在頭髮的部份. 剪頭髮的時候, 我總會剪走了許多髮絲, 又留下了部份背景沒有剪去. 最後, 剪出來的那個明星, 服飾依舊, 樣貌依舊, 而髮型, 卻是全新的.

以「博駁博」抓取Blogosphere, 處境非常相似. 以前文為例, 研究的對象是Mysinablog, 那情形就好像兒童周刊上的剪紙遊戲. 粗粗的虛線圍著那隻小青蛙, 任誰也可以輕易剪出健康完整, 有手有腳的小青蛙. 但今回的研究對象是整個香港Blogosphere, 情形就有如要在一張巨幅海報上, 剪下一隻毛茸茸的鬆獅狗.

(閱讀全文)

留言(42) | 引用(3)

Google 廣告