從中文輸入法開始的網路之旅1

放假了,我也開始閒了,在巴哈姆特上CHAT常常會覺得打字用注音特別慢,而且總覺得指形有些彆扭。於是我開始了尋找好用的輸入法之旅。

首先想到的就是倉頡,這款處處都有的輸入法。朱邦復先生早年剪字典研究輸入法的辛苦時有可聞,而他在「宇宙浪子」講述他研究的「漢字基因」對於未來世界的發展也讓我十分嚮往。倉頡是漢字基因研究的第一個成品,這麼神奇的輸入法我怎能放過呢?於是我翻開了GOOGLE討論區的大門,一踏就踏進了某個叫做我的倉頡的網站。

這個網站似乎也很久都沒更新了,想說倉頡雖然神奇,也是十幾年前的東西了,沒人更新也是當然的吧。裡面說了「我的倉頡」這款改良式的輸入法,有看沒有懂,裡面「環保書」下的「版權」項目下還加了有的沒的一堆類似「新生活運動」的東東,最後連作者對於「雙重國籍」的呼籲都寫出來了。嗯,真的是一個很PERSONAL的網站呀。結果到頭還是不大懂「我的倉頡」相對於「倉頡」的好處。倒是新的名詞看了不少,啥?倉頡還有分三代五代,到底有什麼不同,沒說。這真是錯綜複雜。

這網站倒是讓我學習了一個蠻糟糕的歷史,是關於民國六十八年的時候,由一群漢字學家以及資訊人員組成的「漢字整理小組」研發出世界上第一款,也是很完善的一款中文字碼「中文資訊交換碼」(Chinese Character Code for Information Interchange, CCCII)。結果因為某些腦殘的因素,演變成政府採用另一個研究組織所研發的字碼。結果發現這套字碼到處是漏洞,而且還不顧國際標準。在接下來的五年內,不同名字的編碼一個個出爐,但是就是漏洞補不完,直到現在的Big5大五碼,還是一樣有漏字的缺陷。Unicode好像好些,不過似乎還是有一些問題。總而言之,這樣子換來換去的國家標準增加了中文資訊發展的阻力是不可否認的。像是我在法院工作的時候,也是必須常常幫人更新增加BIG5沒有的字。而微軟又不支援國家標準(姑且比BIG5好的多。)腦殘真是可惡呀。

這裡是最近有關於中文編碼的討論

[天才] 6GB –> 5 KB

以下為轉載

Super News!!
☆ 6G (影音檔) → 壓縮  → 5K   (60分)
☆ MAIL → TO → MAIL (2秒)
☆ 5K → 解壓縮 →  6G     (3分)

這是5年前的一個家教學生 ( 男 / 16歲 )
發明的一個壓縮程式
我想把它引進台灣
與台大的同學們分享
他一直要我的建議
可是很可惜我不精通電腦程式
—–

不像是開玩笑的 因為

—–
我希望這幾天能夠幫他組織一個TEAM
有興趣這一方面的朋友
我們一起來討論這個軟體開發的前途及方針

在5月1日到7日他有一個假期
如果我們這邊的方針明確了
在29日我會跟他發邀請函
1日到7日
我們可以現場確認壓縮各式檔案 ( 文字. 圖檔. 影片 )
合作最後的CHECK及開發.以及跟他本人共同討論.

他本人精通中文日文英文. 現在住在日本.

當然,這真是創舉呀,足夠叫天底下所有研究過壓縮法的教授研究生們自己去死一死。
也許下載只要幾秒,但是解壓縮要一星期 (by noraneko (野良貓))
或者是幾年前的「虛無演算法」的借屍還魂。
總而言之,這不列在「好軟體」真是過意不去呀。
「好………………………KUSO的軟體」

7-Zip:免費的壓縮程式

7 Zip 是一個自由軟體,支援 Rar, zip 以及其他重要的壓縮格式。好處是它壓的 Zip 檔會比一般 Zip 檔小個 2% ~ 10%。而它自己的壓縮格式 7z 則是跟 RAR 差不多(都比 Zip 小很多)。它跟 WinRAR 一樣支援結實壓縮,所以壓縮一套 BMP 的遊戲 CG 會特別有效果。

可自訂字典大小、多處理序、支援 Unicode、有中文介面。

正體中文網站

軟體工程與瀑布模型

軟體工業似乎是高科技產業的一環,但其實目前絕大多份的公司並不是使用專業的方法來解決問題,導致生產效能低落,臭蟲四竄品質不足,專案時間每每向後延遲,以及開發經費大大增加。這些現象都是因為絕大多數的公司以及開發者都是使用「瀑布模型」進行開發所導致的。

瀑布模型,就像是有五座高低不等的湖泊,每個湖泊都有個瀑布連到下一個湖。

需求  (Requirements)
|——>高階設計 (High Level Design)
|———->細部設計 (Design)
|———–>編碼 (Code)
|———–>測試(Testing)
|———>出貨(Delivery)
|————->維護(Maintenace)

這個模型原先是份大學的論文,結果被美國軍方看上,結果就被採用了。奇怪的是,這篇論文的結尾指出,這個設計流程模型並不是很好的模型。至於為何它還是被採用了,只有天知道。根據調查,因為採用這個模型而導致的累計損失是工程歷史上的數一數二的。

這個模型認為寫程式的人能先作前導的設計,然後才開始真正的寫程式。但是在現實生活上,幾乎沒有一個程式是從頭到尾不需更改一直線進行的。畢竟客戶不知道電腦能做些啥,工程師也不知道客戶想要些啥,所以花幾個月寫好的需求報告書通常都必須一改再改。資料顯示這些需求有一半都不會真正被寫進程式裡。而在上層更改需求會產生雪球效應,如此一來在最底層(測試以及維護階段)就會不可避免的產生許多錯誤。換另一面來看,客戶在一開始交與需求報告書的時候,通常都必須簽訂合約。如此一來每當需求增加的時候,就必須多付些錢。許多軟體公司其實就是靠這些增加的需求來賺錢,一開始的報價反而不重要。

通常80%的資源都被用在測試之後的環節上,這是因為這種設計模型很容易寫出充滿錯誤的程式。

結論是:瀑布模型很爛。
該怎麼辦?使用XP程式設計