Feeds:
Posts
Comments

Archive for January, 2011

今天利用Google Translate去確認俄文翻譯時,發現了很古怪的結果。

當翻譯俄文:「опеределенный」時,不論輸出是英文或漢語,結果都是php.ini。參看以下的連結:
http://translate.google.com/#ru|en|%D0%BE%D0%BF%D0%B5%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9

這很明顯有以下的可能性:
1. 翻譯的指令不成功。
2. 翻譯資料出現問題,可能人為出錯,也可能曾被入侵。

在正常情況下,Google Translate會保留不能被翻譯的字眼。這是我第一次看到有檔案名字,這情況不尋常。
如果有駭客看中某些Open Source Project,他可以主動參與,然後加入一些漏洞及加入Google Translate API的代碼。這些漏洞可以利用諸如SQL Injection的技巧,然後取得網站的設定檔案、甚至是密碼檔案。

我將這個問題匯報給Google Translate: http://groups.google.com/group/google-translate-general/browse_thread/thread/3df92ee489bc810c#

等他們的回覆好了。

Read Full Post »

今日,我想談談在互聯網上常被人談論的”nofollow“,其實已經「名存實亡」(nofollow has died).

GoogleMatt Cutts曾經建議在網頁上的連結加上nofollow以表該連結是廣告、或表示連結是第三者提供,網頁的擁有者未經審慎查看。而Google在收錄網頁時,會將沒有nofollow的連結的網頁會調整影響力。

這個建議,受到其他的網頁搜尋器的認同和跟從。

數年後,網頁文化轉向了以短小文字所描述的微搏文化。微博(Microblogging)產生了極大量的內容以及大量加有nofollow的連結,而這些內容對很多搜尋器而言是豐富的資源。有些新興的搜尋器如:Topsy, Tweetmeme…等等,以提供搜尋微博(Microblogging)的內容為主。

網頁搜尋器為此而爭奪微搏的搜尋業務,nofollow這一個規則也變得模稜兩可。可以看到Googlee對nofollow這個它自己創立的規則搖擺不定。

在搜尋twitter這類微博(Microblogging)網站,已經沒有甚麼nofollow可言了。況且,現在有很多轉載微博(Microblogging) 資料庫內容的網站,它們無視nofollow的規則,這些網站又輾轉被搜尋器刊登其內容。

所以,嚴格地說,nofollow已死了(nofollow has died)。

Read Full Post »

Google稱霸搜尋器業務,是一個無可致疑的事實。從一個搜尋器專家的角度看。Google的運算能力大大超越了其它同類型公司,甚至是將全球所有除了Google以外其他搜尋器的運算力總和,也不足以對抗Google。

這些運算力的差異在那些地方呢?計算機的數量、管理系統、硬件、軟件,所有的因素,Google也在其考量之中。

Google 最初的成立公司時以家裡的車房作為中心,以平價電腦加open source的管理系統組成。這訂下了發展的方針,以大量低價的電腦,匯集成今天聞名的Google電腦海。

相對於yahoo剛成立時,記憶中它是用雙核版本的太陽電腦,是那個時代的頂尖電腦。

由於引入公開源碼的Linux使得Google得心應手地改良,看它公開的那個Google Chrome OS可想而知已經很早就將Linux打做成高速的雲端管理系統。

Google 連資料庫軟件也不放過,早就放棄了32bit的舊式設計,突破單一物件4GB記憶上限,更將運行模式大幅修改為雲端模式,成為名叫Big Table的傳說級資料庫。

Google的技術暫時沒有能平起平座的對手,因為天生是雲端的本質,會比其他對手更優勝。

下一步要走的路,就是硬件的優化。將軟體的運算樽頸,轉為以硬件運算,例如,硬件加密,硬件搜尋。

如果未來的電腦能有硬件搜尋的Big Table,能利用硬件Regular Expression的電腦語言,能使用GPU的矩陣運算,有Physic Engine等等的硬件優化。甚至利用GPU的平行矩陣來優Big Table,用Regular Expression來改良現有搜尋機制。利用硬件加密來強化Google的保安設施。

如果這些都是由Google研發,一定會一統資訊科技界。

Read Full Post »

差不多三歲的寶貝女兒從家中的雜物中,找來一部有米奇老鼠圖案、銀色閃粉外殼、粉紅色的任天堂NDS手提遊戲機過來,問我,那是甚麼?

任天堂因為成功地生產了這款暢銷的NDS手提遊戲機,而引發了很多針對女性用戶的「高科技」器材。

用家願意花高昂的價錢幫手提遊戲機「裝身」的同時,並不介意遊戲機內按安裝了的遊戲是不是盜版。

在女性消費者的世界,她們重視外表所帶來的價值多於功能上的價值。電玩市場原本是以男性消費主導的高消費市場,女性消費者就有如「長尾理論」(long tail theory)所提到的尾巴的一小部份。

企業家常常走進市場,尋找有潛質的非主流產品「長尾巴」(long tail),用另一個角度,重新開發和包裝。在過往的歷史上,亞馬遜(Amazon)的管理層是「長尾理論」(long tail theory)的高手。在網上大賣非主流的書籍(「長尾巴」)。亞馬遜(Amazon)的高層,利用科網概念籌集大量資金,利用售賣大量非主流的書本,成為公司的藍海。

再利用Data Minning 將用家及產品作出配對。產生持續的銷售。利用自己的網路,建設自己的付費系統。變成出名的Paypal 。

然後,它又利用了龐大的網路設備作為新的「生源」開拓它第二個藍海–雲端服務。

它的雲端服務、付款系統、網路設備、銷售喜好系統…又可以開發其他的藍海。

亞馬遜(Amazon)已經參與了電子書、網上電視台、數碼音樂…等的市場。下一步又是甚麽樣的一個市埸呢?是紅海(Red Sea)還是藍海(Blue Sea)呢?

Read Full Post »

今天談談ASP.NET的誕生的理念問題。

經過十多年的歷史,ASP.NET已經是一個很知名的網頁電腦語言。知名度高、在書店上出現很多教學書本、在不同的學有多課程講授ASP.NET,也不代表ASP.NET是很完美的電腦語言。嚴格一點來說,ASP.NET絕對不完美。為了讓大家了解多一些,讓我從設計理念著手。

在十多年前,有很多編寫在視窗運行(「桌面程式」)的軟件專家,被要求設計一套在伺服器上運行的電腦語言。

如果能夠有一個視覺化的設計畫面就好了。於是他們就花了很多心思去設計那個視覺化畫面。

當他們利用視覺的設計畫面來產生網頁的時候,他們發現他們並不能令到網作出跟「桌面程式」一樣的反應,於是,他們就將每個反應,交回伺服器來處理。這樣就創作了所謂「Post-back」這個不尋常的詞語。

「Post-back」的意思是:網頁在按鍵後會返回同一個網頁。

這看似不太尋常但表面正常的設計,在實際運作上又產生另一個問題。就是網頁無法確保跟伺服器有相同的狀態,例如:如果網頁中途斷了線,使用者往往會按「從新載入」(Reload),有時,使用者又會按「返回上一頁」(Back)之類的網頁瀏覽器的按鈕。使用者看到的往往並不是伺服器上的版本。為了令到司服器上的版本跟使用者在瀏覽器上的版本可以保持同步,ASP.NET的設計專家又引入另一個新的理念「ViewState」,將伺服器上的狀態,儲存到傳給使用者的網頁上。舉一個簡單例子,假設伺服器中的A=5,網頁上有一個將A加上的1的按鈕。為避免使用者不斷按「從新載入」(Reload)而不斷執行將A加1的,變成加了很多1,網頁頁上儲存了A=5的數值,按加1的按鈕就只會執行5+1這個動作。

如果一個網頁有很大量的「ViewState」,例如一個網路遊戲上同一時間有很多遊戲的玩家,「ViewState」就可能需要儲存大量其他用家的資料而變得很巨大,傳送網頁,以至到伺服器的運算,就會變得很慢很慢。我曾經有三年前玩過一個用ASP.NET寫的Facebook的戰爭遊戲,由於參加的人數不斷增加,開發遊戲人不斷買貴價的伺服器,但遊戲仍然反應很慢,下載一個畫面,往往要花3分鐘以上。

現今大流量的應用程式,大多數都採用PHP,速度快及效果好。

究竟ASP.NET的問題出在那裡呢?ASP.NET的設計理念,最初無視瀏覽器的Reload、Back等運作,亦不考慮網頁在未發明XMLHTTP之前,只用作傳送整個網頁。ASP.NET在處理一個按鈕或一個輸入是,要將一整個網頁從新計算、傳送,而且為了確保能跟伺服器保持一定的狀態,但將網頁的內容加到很大,結果將問題惡化。

如前文提到的情況很類同,「桌面程式」跟「網頁程式」相去甚遠,勉強將它們變成同一個理念甚為不智。

Read Full Post »

昨天跟一位中學的師兄在電話上談論IT的技術。師兄以前是從事會計,對IT也很有興趣。由於對工作的環境不滿意,放棄了高薪的會計工作,轉了入一間知名的會計軟件公司。由於他對上市公司的合拼帳的運作很熟悉,負責設計新的會計系統。

在電話裡跟他談了很多不同的電腦技術。其中一樣比較新鮮的就是設計「流程管理」軟件,我的師兄說他的公司已經開發了一套「流程管理」Workflow的軟件,由於規模比較大,難於應用在小規模的計劃內。那套「流程管理」的軟件是從收購其他公司而得回來,未能融合在其他產品之上。他的公司曾經花了很多時間和資源去從新開發另一套「流程管理」的系統,但結果不理想,內部人士的評語是設計了另一套解讀c#的c#。這個奇怪的評語,指的就是,用一套類似c#的語言來表達整個流程,包括表達圖片及表真正的流程及其相關的邏輯。

令我想起了我公司那套專為「中介付款系統」背後的「流程管理系統」。設計者是其中的一位同事,是兩年多年的產物。主要的原理是利用邏輯而產生出SQL語言,然後將SQL執行的結果,轉換成流程。

我師兄的老闆是C#高手,而我的同事是SQL高手。他們在設計時難免會以自己最熟悉的技術出發。本來,這種思維模式是理所當然的。可是,c#或SQL太不像圖象,用他們來做圖象介面,不太合適。C#不能直接翻譯,所以用來表達「流程」的邏輯,吃力不討好,SQL處理邏輯不太靈活。這兩種電腦語言,用在「流程管理」上是「相去甚遠」。就算設計者是「神」級也要花巨大的氣力才可以勉強成事。

所以,每當我們要去解決自己熟悉的領域之外的問題時,要細心想想,自己所習慣的模式是否「相去甚遠」呢?

回到原先的問題,本人覺得,古老的「流程圖」還是最合適表達「流程」。則DOM是種很好的描述畫面的中介語言。最後,JSON是一種很好的溝通及直譯的電腦語言。所以,我們可以採用「流程圖」->「DOM」->「JSON」的方式來將「流程」轉化為「JSON」。「JSON」可以被儲存、提取及轉化為真的「流程」及其邏輯。

當然,我們亦可以考慮用XML取代JSON的角式,也可以用UML代替「流程圖」。設計理念是差不多的。

Read Full Post »

協作管理,意思是管理多位作者同時創作的管理方法。「協作」這詞語最早被用在「谷歌」的「協作系統」中,可是「協作系統」的英文名「Google Site」卻沒有協作的意思。「谷歌」的「協作系統」是一個網頁系統。這個系統的優點是容許多位作者同一段時間去更改網頁內容。當兩位作者同一時間開啟同一份文件而又在差不多的時候進行更新,第一位更新者可以順利更新,新二位更新者會收到訊息,該頁已被其他人更新。這種型式,就是最常見的協作手法之一。

協作管理的最大的功用就是提供版本管理的服務。我們利用栛作系統,就可以追蹤每個版本之間的分別,以及由誰去負責某個版本等等。Open source型式開發的計劃,多數採用協作管理,這樣,不同的地域、時間的人,可以根據自己的生活的規律來參與Open source的開發,大家討可以利用「協作系統」來招募參與者、分配不同的角式、引發討論、分析問題、制訂目標、更新內容、版本管理、擬訂合約細節、編寫說明、進行翻譯、追蹤及跟進問題、甚至用作測試等等。

自從協作管理在互聯網上誕生後,大大小小不同的跨國性的計劃就不斷地展開。而不同型式的「協作管理系統」也不斷地誕生。最早期的有Concurrent Version Control, Subversion, Microsoft Visual Source Safe,..等等。以至到近期的github, Google Code, Google Wave, SourceForge, CodePlex, Google Site, OfficeLive, Google Documents, wordpress,…等等,不再局限在程式編寫,亦包括文件、網頁、繪圖、Blog等等的協作計劃。

協作管理將會是未來的「團隊管理」的大趨勢。

Read Full Post »

Older Posts »