首先, 是地點問題. 要知道, 用戶用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的戰幔, 現在才剛揭開.
可能有朋友未必知道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
或
例牌, 先說說計算方法. 今次的判斷條件比較簡單, 就是如果某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玩玩啦!
一直以來, 都想用全文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罷.)
查實上回我出了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問題已解決, 但總數和清單估計下星期才完成.
以 「博駁博」抓取Blogosphere, 處境非常相似. 以前文為例, 研究的對象是Mysinablog, 那情形就好像兒童周刊上的剪紙遊戲. 粗粗的虛線圍著那隻小青蛙, 任誰也可以輕易剪出健康完整, 有手有腳的小青蛙. 但今回的研究對象是整個香港Blogosphere, 情形就有如要在一張巨幅海報上, 剪下一隻毛茸茸的鬆獅狗.
(閱讀全文)
可是, 網頁來源從何而來呢? Google(或其他大型Search Engine)的網頁來源主要是靠一個人在電腦面前按連結. 他先由一個網頁開始, 把該網頁存檔, 然後從該網頁中的其他連結, 找出其他網頁. 最後, 一連十, 十連百, 整個互聯網, 就這樣被揪出來了.
當然, 上面提到的那位人兄, 不是真的是一個人, 而是一個機械人(即Robot, 或簡稱bot, 又或網絡蜘蛛Web-Spider, 又或網絡爬虫Web-Crawler). 如果那真的一個人的話, 無論他如何做好呢份工, 網海之大, 夠他做幾生幾世了.
話說回來. Blog本來就是網頁, 而在未有BSP, 只有公海的年代, 不靠Blogroll/留言, 是無法給人找上門的. 那些Blog, 是公海中斷六親的孤島. 換言之, 在那個時候的Blogosphere裡, 肯定是博博相連的. 所以, 若以Robot抓取的話, 一定能把所有Blog都找回來. 此方法, 我暫戲稱為「博駁博」吧. 雖然到了今時今日, BSP大行其道, 有推介有排行榜, 但blogosphere的基本生態還是得靠連結來維持的.
(閱讀全文)




