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

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

軒爸 | 23rd Jul 2008 | 一般 | (3398 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的你, 豈能無動於衷呢?


Google 廣告
最新留言
網誌統計
文章總數:45
留言總數:300
引用總數:14
閱讀總數:247243
總瀏覽數:383920
MySinaBlog 精選文章