2007年2月28日 星期三

狄葳小姐

  意外看到這樣的一個擬人化的搜尋引擎 Ms. Dewey ( 狄葳小姐 ), 看起來背後用的是 Microsoft Live Search 的搜尋引擎, 外觀包上這有趣的殼. 不但提供搜尋功能, 且有個小妞對你的搜尋主題發出批評與反應, 類似當初 AI 人工智慧電影上映時的宣傳網站, 提供了一個代理人聊天程式.


  不過, 這個炫得多! 帶來的樂趣遠勝於實用性.


  這個讓我想起國中時用 ETBASIC 寫過類似的程式, 命名為 [ 超級麥斯 ] , 點子來自於當年算很紅的台視影集(有口皆碑). 我那時利用當紅的青少年漫畫 - 城市獵人(CITY HUNTER)中的孟波的大頭照當代言人, 然後透過繪圖軟體 [ 變影 72 ] + 掌上形的掃描器, 製作出各種喜怒哀樂的表情. 最後花了好幾個晚上的時間建立話題集, 經由簡單字串比對的查詢效果來完成這虛偽的人工智慧反應...


  現在回想起, 還蠻懷念那段瘋狂又愚蠢的日子....


  拜頻寬普及之時, 網路上互動性更高的應用紛紛出籠, 但是真正能成為 Killer 應用的點子卻越來越少. 這個炫玩意看來製作成本決不低廉, 新鮮歸新鮮, 但錢燒完後, What's NEXT?

2007年2月25日 星期日

我的讀書計畫 ( 研究所書面審查 )

  對資訊工程研究所的憧憬:


  國小時期我意外開始接觸程式語言 BASIC, 當時的興趣是做繪圖與動畫, 國中時接下班級成績單列印系統, 雖然未學過資料結構與演算法課程, 絞盡腦汁寫出名次排序的功能, 現在回想起是使用類似氣泡排序法完成(但效能更差)。這樣讓我與電腦程式結下不解之緣, 卻也因為年少得志讓我犯下判斷錯誤的過錯, 以為資訊工程的領域知識只需要依靠坊間書籍努力自學即可, 大學和研究所的時間我應該投資在更需要國家教育資源的學問上, 導致我大學選擇了另一個科系 - 物理系.


  如今看到資訊科技蓬勃萬里與一日數變的發展, 才發現往日的認知過於天真與錯誤, 程式語言與電腦指令, 只是工具, 只是整個資訊學問的滄海一粟. 真正實務的應用面, 更需要豐富的學理作為基礎. 我好比學會 26 個英文字母就自認為已學會英文那樣荒謬地離譜幼稚.


  回來資訊工程所做進修, 除了是對自己無知的反省, 也是重新擁抱自己所愛, 希望能將資訊科技的進步與便利帶入社會與生活的每個角落, 以自己的理想與所能促進人類生活的進步.


  二、近程(從錄取到正式入學前)


  由於本公司的產品性質與業務上經常參與許多金融企業的自動化流程設計與開發, 所以對於 EAI 和平台, 網路通訊等有相當的經歷與研究. 持續吸收各個通訊標準與交易傳遞的知識. 並且為了讓自己日後不管專研任何領域的應用, 都能達到最大的設計彈性與易於維護等優勢, 短期內以學習各種程式開發架構面的知識與開發方式為優先. 例如: GOF 的 Design Pattern, CMMI, Agile, Extreme Programming ( XP 開發流程 ) , Prefactoring & Refactoring等議題.


  三、中程(進入研究所後)


  擁有開發流程與架構知識的前期準備, 對於資訊科學, 個人認為應用極致的表現就是人工智慧一項, 這不但是我最大的興趣與夢想, 也是目前尚未成熟且充滿冒險疆域的一塊. 我對於如何運用電腦強勢的計算能力, 輔佐人類做出正確的決定, 感到非常有挑戰性, 且這才是真正可以為人類社會謀取幸福的唯一道路. 人類的判斷過程過於情緒化與缺乏邏輯, 對於決策系統與專家系統的理論研究, 智慧代理人等背後運行的理論與研究, 是我中程的目標.


  四、遠程(畢業前)


  電腦判斷的準則一切以數字為依歸, 發展人工智慧來解決人類實際遇到的各種問題, 最難的就是將抽象的問題與不同的選擇之間, 轉化為數據表達, 以便電腦能根據數學原理與演算法做出決定. 要幫電腦做出 Ranking 與考量各種因素的加權值是件困難的事情, 且人為的設計會牽涉到設計者本身的主觀因素(開發人員也是凡人), 在這個階段, 我將研究電腦在自我學習上可以從累次的判斷與結果回饋來自我成長到什麼境界. 人工智慧的自我學習, 是畢業前目標.


  五、未來展望


  為了讓人類能在具有智慧的電腦系統輔助下做出更好的表現與提升工作效率, 做出正確的決定, 未來我將利用所學, 先從經濟面發展出與金融相關的決策系統或專家代理人系統. 為何先從金融面出發, 是因為自己目前的工作性質就是負責金融營運的系統, 再者, 金融界的相關知識都已經數據化, 例如金錢數量, 股票漲跌, 經濟趨勢與景氣訊號, 都是現成已經數據化的資料來源, 對於電腦來做決策與判斷依據是一個絕佳的入門點.


  若在金融領域略有斬獲後, 我會在朝其他領域繼續研究相關系統的潛力與發展方向, 此為我長期, 且終生的目標與職志.


2007年2月19日 星期一

ViewState 滾開!



  在 ASP.NET 的架構下, 最令人驚奇的就是 ViewState 的存在. ViewState 是 ASP.NET 的靈魂, 巧妙地避開 Http stateless 的先天限制, 讓 Web ap 也能享有狀態存留, 事件觸發等原本屬於 Winform AP 的開發特性.


  ASP.NET 的 ViewState 的自動化讓開發人員可以很輕易就發展出高互動的網站, 但是他也讓 ASP.NET 背上效能不佳的罪名, 濫用伺服端控制項的人最終會發現, ViewState 的包袱是很沉重的, 就像是惡魔的交易, 必須用靈魂般沉重的代價換取.



  儘管微軟一直強調 ASP.NET 的開發效能與執行效能評比, 遠超過老爸 ASP 甚多, 但這些效能評比都是在 Server 上作評比, 沒太多人想過在 Client 上的效能評比又如何. 當然這是因為比較 client 端的變數太多, 受限於 End user 端的硬體等級, 頻寬等級..., Server 端評比是單純容易多了.


  但是在現今電腦硬體越來越快, 價格越來越低廉, 這些 CPU 上的數據其實已經不如以往重要, 相比之下, 頻寬效能才是重點. 單比頻寬就會發現 ASP.NET 是龐大且反應緩慢的怪物, 真兇就是 ViewState + PostBack 兩者. 一般拿來做企業 / 公司內的 AP 還不會有人發現其嚴重性, 反正都是 Intranet 區域網路, 動輒上百 M 的頻寬在流竄, 拿來做 Internet AP 就會發現客戶抱怨聲此起彼落. 我也是拿 ASP.NET 做了個電子商務訂單系統, 才被這看似好用的糖衣陷阱搞得七葷八素. 為了滿足客戶對效能的期望, 盡量關閉不必要的 ViewState, 開始手工打造 Jscript 來減少 PostBack 的次數.


  ASP.NET 要做到頻寬的最佳化可是條艱辛的路, 所幸, 在網路上發現高人指點, 可以將 ViewState 儲存於 Server 的 Session 之中的偷吃步做法, 減少傳輸的頻寬量, 花了點時間研究, 今天總算改良完畢, 做出來的效能我相當滿意.



  不過這個偷吃步是用 Server 的記憶體空間換取時間效能的做法, 同時上線人數一多, Server 應該會爆吧? 管他的, 反正是花錢租來的主機, 不是我家的機器, 記憶體就給他吃吧. 客戶滿意度最重要! ^_^ Y


  參考文獻:
  CodeProject : Keep ASP.NET ViewState out of ASPX Page for Performance Improvement
  - 作者: Regis Daniel de Oliveira