一個傻逼的部落格

　　 對資訊工程研究所的憧憬： 　　國小時期我意外開始接觸程式語言 BASIC, 當時的興趣是做繪圖與動畫, 國中時接下班級成績單列印系統, 雖然未學過資料結構與演算法課程, 絞盡腦汁寫出名次排序的功能, 現在回想起是使用類似氣泡排序法完成(但效能更差)。這樣讓我與電腦程式結下不解之緣, 卻也因為年少得志讓我犯下判斷錯誤的過錯, 以為資訊工程的領域知識只需要依靠坊間書籍努力自學即可, 大學和研究所的時間我應該投資在更需要國家教育資源的學問上, 導致我大學選擇了另一個科系 - 物理系. 　　如今看到資訊科技蓬勃萬里與一日數變的發展, 才發現往日的認知過於天真與錯誤, 程式語言與電腦指令, 只是工具, 只是整個資訊學問的滄海一粟. 真正實務的應用面, 更需要豐富的學理作為基礎. 我好比學會 26 個英文字母就自認為已學會英文那樣荒謬地離譜幼稚. 　　回來資訊工程所做進修, 除了是對自己無知的反省, 也是重新擁抱自己所愛, 希望能將資訊科技的進步與便利帶入社會與生活的每個角落, 以自己的理想與所能促進人類生活的進步. 　　 二、近程（從錄取到正式入學前） 　　由於本公司的產品性質與業務上經常參與許多金融企業的自動化流程設計與開發, 所以對於 EAI 和平台, 網路通訊等有相當的經歷與研究. 持續吸收各個通訊標準與交易傳遞的知識. 並且為了讓自己日後不管專研任何領域的應用, 都能達到最大的設計彈性與易於維護等優勢, 短期內以學習各種程式開發架構面的知識與開發方式為優先. 例如: GOF 的 Design Pattern, CMMI, Agile, Extreme Programming ( XP 開發流程 ) , Prefactoring & Refactoring等議題. 　　 三、中程（進入研究所後） 　　擁有開發流程與架構知識的前期準備, 對於資訊科學, 個人認為應用極致的表現就是人工智慧一項, 這不但是我最大的興趣與夢想, 也是目前尚未成熟且充滿冒險疆域的一塊. 我對於如何運用電腦強勢的計算能力, 輔佐人類做出正確的決定, 感到非常有挑戰性, 且這才是真正可以為人類社會謀取幸福的唯一道路. 人類的判斷過程過於情緒化與缺乏邏輯, 對於決策系統與專家系統的理論研究, 智慧代理人等背後運行的理論與研究, 是我中程的目標. 　　 四、遠程（畢業前） 　　電腦判斷的準...

　　在 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 應該會爆吧? 管他的, 反正是花錢租來的主機, 不是我家的機器, 記...