<![CDATA[為老不專]]> http://jessemok.mysinablog.com Fri, 05 Jun 2009 10:53:15 +0800 mysinablog-2.0 http://mysinablog.com/gallery/166/97/24998/profile.jpg <![CDATA[為老不專]]> http://jessemok.mysinablog.com <![CDATA[維指升穿150,000點!]]> 自四五月開始, 市場不斷出現利好因素, 當中有取態投機的兩大爬蟲基金:「大諤基金」和「烏龜基金」 亂Q咁入市, 又有特首以「代表論」干預市場運作. 與此同時, 以「良資」見稱已故中共領導人亦以老本大手入市, 向市民大派定心丸, 以致昨日維指一口氣升穿150,000. 但回顧過去二十年, 大市似乎多在低水徘徊, 所以, 在一個如此大的升幅之下, 大市的沽壓依然強勁, 市民不應掉以輕心.

 

(閱讀全文)

]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1759247 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1759247 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1759247 Fri, 05 Jun 2009 10:53:15 +0800 <![CDATA[實作無聊答案]]> 小影發起了一個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... 正期待下一個無聊問題...

 

]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1688386 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1688386 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1688386 Fri, 24 Apr 2009 08:40:17 +0800 <![CDATA[無聊答案]]> 無聊問題」, 答案已到其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, 按實際情況, 還可以有更多更多.]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1675159 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1675159 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1675159 Fri, 17 Apr 2009 09:07:29 +0800 <![CDATA[名妓與玉女]]> 一個魔童, 一個瘟神.

一個講波, 一個啜女.

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

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

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

 

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

]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1488646 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1488646 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1488646 Fri, 19 Dec 2008 09:30:57 +0800 <![CDATA[Hacking Mysinablog : 全文皆Feed(二) 之 雲端抓文]]> 早前想試玩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完, 通知我一聲就是了. ^_^

]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1464796 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1464796 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1464796 Sat, 06 Dec 2008 09:26:02 +0800 <![CDATA[Spam Post也上精選]]> 手痕上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霸埋, 人類就嚟無定企囉.

]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1443319 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1443319 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1443319 Fri, 21 Nov 2008 16:23:28 +0800 <![CDATA[利用Google Calendar作Free SMS Broadcast]]>

我想, 應該有不少公司也有類似的情況發生吧. 小型一點的公司, 可能連通報機制也沒有. 所以, 我就為此花了點時間, 設計了一個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)給我, 交流交流, 指教指教, 多謝!]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1278584 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1278584 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1278584 Thu, 31 Jul 2008 14:15:44 +0800 <![CDATA[Y!BOSS : 有得任Search至係老闆]]>

在以往, 任何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的你, 豈能無動於衷呢?]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1267050 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1267050 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=1267050 Wed, 23 Jul 2008 16:51:30 +0800 <![CDATA[Facebook Application 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的戰幔, 現在才剛揭開.]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=863866 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=863866 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=863866 Fri, 16 Nov 2007 13:00:33 +0800 <![CDATA[Custom Blog 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
或

(閱讀全文)

]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=730146 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=730146 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=730146 Fri, 17 Aug 2007 17:54:14 +0800 <![CDATA[Xanga陣容強大]]> 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玩玩啦!

(閱讀全文)

]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=690061 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=690061 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=690061 Mon, 23 Jul 2007 11:22:55 +0800 <![CDATA[Hacking Mysinablog : 全文皆Feed]]> 一直以來, 都想用全文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>
正確的話, 應如下圖:
Picture

Step 3 : 到「外觀管理」 > 「SideBar設定」 > 「CSS設定」
Picture
Step 4 : 在CSS的最底, 加上下面這段, 按「更新」.
hr {
display: none;
}


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

Step 2: 按加入分頁線
Picture

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

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罷.)

(閱讀全文)

]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=685802 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=685802 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=685802 Fri, 20 Jul 2007 11:37:38 +0800 <![CDATA[RoadShow慶回龜俾面派對]]> 呢篇野, 希望大家下次睇RoadShow時心理會好過啲.

(閱讀全文)

]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=642924 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=642924 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=642924 Thu, 21 Jun 2007 09:23:31 +0800 <![CDATA[香港Blogosphere清單 (Y!Blog)]]> 查實上回我出了Y!Blog條數, 報到咁大, 又唔出List.
拿不出證據來, 有冇人懷疑我其實係Y!Blog派來o既卧底呢?
為避嫌, 我已處理好Y!Blog清單.http://jessemok.googlepages.com/list-yahoo-01.html
http://jessemok.googlepages.com/list-yahoo-02.html
http://jessemok.googlepages.com/list-yahoo-03.html
http://jessemok.googlepages.com/list-yahoo-04.html
http://jessemok.googlepages.com/list-yahoo-05.html
http://jessemok.googlepages.com/list-yahoo-06.html
http://jessemok.googlepages.com/list-yahoo-07.html
http://jessemok.googlepages.com/list-yahoo-08.html
http://jessemok.googlepages.com/list-yahoo-09.html
http://jessemok.googlepages.com/list-yahoo-10.html

又Xanga的encoding問題已解決, 但總數和清單估計下星期才完成.

(閱讀全文)

]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=631910 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=631910 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=631910 Thu, 14 Jun 2007 12:31:27 +0800 <![CDATA[香港Blogosphere清單]]> 一歲生日的愛兒軒軒和勞苦功高的軒媽.

(閱讀全文)

]]> http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=619816 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=619816 http://jessemok.mysinablog.com/index.php?op=ViewArticle&articleId=619816 Thu, 07 Jun 2007 12:40:42 +0800