香港新浪網 MySinaBlog
軒爸 | 5th Jun 2009 | 一般 | (2836 Reads)
自四五月開始, 市場不斷出現利好因素, 當中有取態投機的兩大爬蟲基金:「大諤基金」和「烏龜基金」 亂Q咁入市, 又有特首以「代表論」干預市場運作. 與此同時, 以「良資」見稱已故中共領導人亦以老本大手入市, 向市民大派定心丸, 以致昨日維指一口氣升穿150,000. 但回顧過去二十年, 大市似乎多在低水徘徊, 所以, 在一個如此大的升幅之下, 大市的沽壓依然強勁, 市民不應掉以輕心.

 

 (閱讀全文)

軒爸 | 24th Apr 2009 | 一般 | (2996 Reads)

小影發起了一個quiz, 公開邀請大家以編程解決「無聊問題」. 小影自己和Jacky都分別寫了程序決這問題. 於留言, 我已為「無聊問題」討論過了, 但以編程討飯吃的, 又豈能齋up. 不過, 概然Jacky已實作了我和Clement T第一個想出來的算法, 我就以另一算法再實作一個.

我的程序, 主要以Tree Search解決問題. 有趣的地方是, 那算法聽起來有少許複雜, 但寫出來卻很簡潔. 不會編程的人只知世上只有兩種程序, 會跑和不會跑的, 就是不明白甚麼叫「elegant」的code. 我想, 這就是個一例子了.

算法上次說了, 今次說說編程技巧吧.
(1) Recursive Function
我的實作, 主要運用了Recursive Function(遞迴函數). 一個function會不斷自己call自己, 或兩個function不斷互call. 凡是能以樹狀形式說明的算法, 多能以Recursive Function解決.



(2) Base Case和Termination Condition
用Recursive Function, 主要要決定Base Case和Termination Condition. 我這程序的Base Case就是「全散叫」清單, 然後不停組合不同套餐, 直至不能再組成其他餐, 就是Termination Condition了. 處理Termination Condition一般要很小心, 因為Recursive Function不像iteration, Termination Condition會寫在特定地方[如:while(!term_condition)]. 而且End Condition一般也不會像iteration那樣直觀.

(3) nCr vs nPr
另一個運用技巧, 就是如何控制Recursive Function跑nCr次而不是nPr次. (效能差很遠的!)
這點嘛, 舉例說明會簡單點. 如果不加控制(即nPr), 若你的最後結果是有3個餐, 這個最佳結果你會計到6次.
[1,2,3] [1,3,2] [2,1,3] [2,3,1] [3,1,2] [3,2,1]
然而, 我們其實只想要一次就夠了. 要選一個的話, 最易處理的就是[1,2,3]. 所以, 只會我們控制著X1<=X2<=X3<=...<=Xi, 最佳結果就只會出現一次. 以文字來說, 就是若組合到了一個3號餐, 之後程序只會試組4,5,6... 號餐. (註:也是因為這個原因, 我一開始在Constructor替餐編了號.)

(4) 「省得最多」
第4個值得一提的地方, 是全個算法並沒有計算餐的總價, 而是計每次組合後, 可省下多少錢.
所以, 這算法是在找一個「省得最多」的組合, 而不是「最平的組合」. 只計算「省多少」, 在運用Recursive Function時比較方便.

(5) Trace by Stack
最後, 就是如何追蹤Best Case了. Recursive Function是比較難追蹤的, 我就用了一個平時很少會用到的java.util.Stack. 一進入一個Recursive, 就push()一個餐, 離開就pop()一個, 就能簡單追蹤正在試組甚麼餐, 之前又組過了甚麼餐了.

大概就是這樣. 大家若有興趣的話, 歡迎從github.com下載來研究研究.
Hmm... 正期待下一個無聊問題...

 


軒爸 | 17th Apr 2009 | 一般 | (2937 Reads)
電鋸問了一個「無聊問題」, 答案已到其blog回覆. Generic的解, 就寫到這裡來.

問題:
首先, 假設某餐廳有m種食品, 亦有n種餐可供選擇. 每個餐可包含2種或以上的食品. 而買餐的價錢, 就會比散買要平.
問題是, 如果要買一堆食品, 要叫那幾個餐(可重覆)加散買那幾個食品, 才是最便宜呢?
(不過, 先剔除一個情況, 就是就算「部份叫餐」比「全散買」有機會買多了食物, 卻仍然平些.)

解:
第1步, 就是由Worst Case開始, 即是「全散買」.
第2步, 就嘗試合成一個餐, 這裡可以出現n個可能.(因為有n種餐)
第3步, 跟據上面的每個可能, 嘗試把餘下的再合成另一個餐. 這裡可以出現nC2個可能.(因為先組合1號餐再組合2號餐, 和先組合2號餐再組合1號餐, 是一樣的.)
然後, 第4, 5, 6 .... 一直做, 直至不能再組合任何餐.
假設做到第6步就完, 就最多可以出現nC5個可能.
最後, 將這nC5(實際情況會少得多)個可能, 都計個總和, 就知那個組合最平.

然而, 按實際的情況, 是可以做不同的optimization,
就如麥當勞情況, 所有餐也是有薯條, 就算中薯條升級做大薯條, 所加的價錢是一樣的.
就是說, 你可以完全當薯條無到, 因為薯條完全唔影響結果. 你只要記住, 如果你要買4包薯條, 你頂多只做到4個餐就夠了.

可做的optimization, 按實際情況, 還可以有更多更多.

軒爸 | 19th Dec 2008 | 一般 | (3675 Reads)

一個魔童, 一個瘟神.

一個講波, 一個啜女.

一個招招積, 一個扮死狗.

一個離奇辭職, 一個和平分手.

一個相愛唔結婚, 一個轉頭玩結婚.

 

呢個故事教訓我地:名妓玩唔過, 玉女好玩啲.


軒爸 | 6th Dec 2008 | 一般 | (3259 Reads)
早前想試玩Yahoo!Pipes. 不過, 漫無目的的玩, 不會玩得深入透徹, 也玩得不過癮. 想了想, 就找了一個之前處理過, 卻沒有優雅地解決的問題, 今次試用Y!Pipes再做一遍. 那個問題就是Mysinablog的全文Feed.

或者你從來都未想過花俏的Y!Pipes可以有甚麼實際用途. 對, 全文Feed就是一例了. 原理嘛, 就是先讀取RSS, 追蹤入面所有的URL, 再一篇一篇抓下來, 並轉換成Feed. 有趣吧? 原來Y!Pipes就是可以這麼玩.

原理雖然簡單, 不過以一個功能如此精簡的工具來做, 其實挺難的. 你就別以為他真的會像Shell Script的pipe功能那麼完整. 成不成功? 夠膽出Post, 當然就是成功了.

下面就是以Y!Pipes看全文Feed的方法, 歡迎使用:

方法一:

進入這個網址, 填入Blog ID.
http://pipes.yahoo.com/jessemok/msb_feed

例如, 如果你要訂閱的是http://diumanpark.mysinablog.com/的話, 就填diumanpark

按"Run Pipe", 然後在"More Option"選擇你所用的Feed Reade更成了!


方法二: (若方法一沒有你所用的Feed Reader選擇, 就用這個)

首先, 把Blog的ID, 填到這條URL的後面:
http://pipes.yahoo.com/jessemok/msb_feed?_render=rss&blog=[blog id]

例如, 如果你要訂閱的是http://diumanpark.mysinablog.com/的話, 那URL就是:
http://pipes.yahoo.com/jessemok/msb_feed?_render=rss&blog=diumanpark

跟著, 用這條URL去Subscribe便成了!


就是這麼簡單.

有一點要注意是, 在Feed Reader中, Feed名會顯示為"msb-full-feed", 而不是Blog名(e.g. 刁民公園). 若出現這情況, 你可在reader內, 替這個Feed改名. Google Reader和Bloglines同樣有提供類似功能的. 不過, 就算你用的Reader沒有這個功能(Google Reader的Mobile Version就是了), 放心, 我已將Blog名附加在每個Post的標題旁邊, 怪是怪了點, 但應該不會引起閱讀困難.


另外, 我已在所有Feed之內, 藏了伏線, 加上了"msb-full-feed"標記. 我並非買廣告, 只是希望假以時日, 大家用這個用多了, 在Google Reader內, 打下"msb-full-feed", 就可以搜尋到一大堆Mysinablog的全文Feed了. 對不?

這個的方案, 比之前的解決方案漂亮得多. 最重要的, 是一次過支援了所有Mysinablog. 上次, 每個Blog得自行處理, 推廣起來自然有難度. 而且, 利用Y!Pipes, 你可以把抓文的工作完全交給雲端. 就是說, 不管你用甚麼Browser閱讀, even你用是手機上最陽春WAP Browser(我就是了), 一樣可以零障礙看全文Feed.

當然, 理論上要如法炮製的話, 絕對可以應用在其他Blog或Feed之上. 不過, 畢竟這只是我試玩Y!Pipes時的一個習作而已, 暫時沒打算花時間發展下去, 受歡迎的話再考慮吧. 若誰有興趣自己做一個類似的, 大家也不妨"Clone"一個出來玩 (Y!Pipes內所有Pipe都可以任Clone的). Clone完, 通知我一聲就是了. ^_^


軒爸 | 21st Nov 2008 | 一般 | (3495 Reads)

手痕上Mysinablog精選, 網絡精選一欄見到一篇叫"Google Talk - 來自 Google 的即時通訊助手".
Picture
嘩, 而家個個都講緊Gmail Video Chat, 你反潮流講Google Talk?! 一定有甚麼堅料, 快入去睇睇. 一看, 就發現內容不對勁, 明顯是一篇舊文, 係講GTalk. 上Google Search一下, 發現應文原來是PC Home 2005年的一篇舊文.

Picture


唔, 似乎係個Spam Blog喎.

 


不過, Spam Blog都唔係新奇事, 最奇係佢上到精選喎. 咁至堅.

真係佢有佢「豬o翕」, 編輯部就以為有金執. (註:「豬o翕」乃GTalk一花名)


第二奇事就係, 個精選到而家都成3日啦, 點解無人發現呢. 還是發現咗, 又唔出聲. 還是出咗聲, 又無人理呢? 咁查實呢個精選版, 仲有無人在乎o架呢?

第三奇事就係, 呢個Spam Blog又有其他Spam會留Comment不特止, 而「Blog主」Melvin又Spamly Reply喎.
Picture
Spam來Spam去, 嘩睇嚟呢啲充滿人工智能o既Spam Program, 發展到識得互相打下招呼咁啦喎. 利害呀, 真人都無咁好禮貌啦.

連精選都俾Spam霸埋, 人類就嚟無定企囉.


軒爸 | 31st Jul 2008 | 一般 | (9423 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 | 一般 | (3396 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的你, 豈能無動於衷呢?

軒爸 | 16th Nov 2007 | Blog 事 | (6254 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的戰幔, 現在才剛揭開.

軒爸 | 17th Aug 2007 | Blog 事 | (5264 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



Next

Google 廣告
最新留言
網誌統計
文章總數:47
留言總數:301
引用總數:14
閱讀總數:242801
總瀏覽數:379302
MySinaBlog 精選文章