Shao Fan

          關于JAVA與軟件工程
          posts - 31, comments - 71, trackbacks - 0, articles - 4
            BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

               摘要: 最近Business 2.0雜志發表了一篇文章,名為"Next net 25",介紹了五類25家新銳網站。它們大多為web2.0網站,它們的發展正體現了當今互聯網的動向。有人敏銳地認識到了這篇文章的特別之處,并把它和 94年的狀況進行了對比。認為web2.0開始從少數人面前跳上了大眾舞臺,而目前主流媒體也開始注意并認可這類站點和服務了。  閱讀全文

          posted @ 2006-03-13 08:13 shaofan 閱讀(1710) | 評論 (3)編輯 收藏

          本文譯自Joel on Software,同時發表在其wiki上。關于作者本人,請看這里。由于Joel對于他人對其作品的轉載有較嚴限制,轉載及引用者請參閱其聲明:Linking, Quotation, and Reprinting。這是我翻譯的第一篇文章,有些地方我也不是很肯定,請多多指正!

          (第一稿)


          在飛機控制的設計中,糟糕的可用性會致使飛機發生CFIT:可控飛行撞地

          可能可用性在你的產品中不是那么關鍵。如果幸運的話,你在可用性設計中的錯誤可能只會使人失去四肢,或甚至只是拇指。沒什么更糟的了。

          事實上,如果極端幸運,那么糟糕的可用性設計除了會使人難受,沒有其他后果。用戶試著去做一些事情,或者失敗,或者掙扎著去用,很直接的后果就是他們會為此感到不悅。在將來的文章里,我會講講此事在心理上的原因,但現在,這樣說就足夠了:使用戶不悅的原因,很可能并非完全如你所想。

          可用性,確實是一個“好”設計的核心。在將來,我會花很多時間來講述這個問題。

          好消息是:我可以很輕松地教你關于可用性設計的話題。讓我們開始吧:

          當一件東西能夠以被期待的方式運行,那它就是易用的。

          就是這樣!這就是關于可用性的一切!像Hillel所說,其它的一切都是解說詞。

          讓我們來看一個簡單的例子。


          哪個更好用:Windows還是Mac?


          在為人們設計產品時,有一個假想用戶是很有幫助的。所設想的用戶越是實際,提供的幫助越大。

          我的假想用戶就是彼特。

          有一天,彼特的朋友,吉娜叫他來幫忙。吉娜有一臺Macintosh的iBook,因為她喜歡白色的電腦。當彼特坐下開始試著用吉娜的Macintosh時,他很快就感到有點沮喪了。“我討厭這些東西,”他說。雖然最后成功地幫吉娜解決了問題,他卻覺得高興不起來。“Macintosh的用戶界面真是笨拙至極。”

          笨拙?為什么會這樣說呢?每個人都知道,Macintosh有著優雅易用的用戶界面,對不對?難道它不是那種易用性的范例嗎?

          好吧。讓我們來看看。

          在Macintosh上,如果你想改變窗口的大小,你必須拖它的右下角。而在Windows上,在任何一個邊上拖動鼠標,都可以改變窗口大小。當彼特幫吉娜時,他試著拖右側的邊來讓窗口變寬。結果,整個窗口都跟著動了,而不是他想要的“改變大小”。

          在Windows上,當出現一個消息框時,你只要按tab鍵移動焦點到所需的按鈕上,然后按一下空格鍵就可以按到那個按鈕。但在Mac上,空格鍵不起那樣的作用。當彼特得到一個警告,他就試著像他過去六年里下意識的做的那樣,按空格鍵來關掉消息框。第一次,機器沒有任何反應,他以為是鍵盤有問題,于是更大力地又按了一次。結果還是一樣。最后他只能用鼠標了。這是另一個小小的挫折。

          彼特還習慣用Alt+F4來關閉窗口。在Mac上,這恰恰是用來調整聲音音量的。這次,彼特想點擊桌面上的IE圖標,而這個圖標剛好被另一個窗口遮住了一部份。于是他按Alt+F4關閉窗口的同時立即雙擊圖標所在的位置。結果是聲音音量變大了,而窗口并未被關掉。而他的雙擊點在了他想關掉的那個窗口的幫助按鈕上,把幫助窗口打開了。好了,他現在需要關閉兩個窗口了。

          這也是一個小小的挫折吧,但是,這確實讓彼特更加郁悶了。這天結束的時候,彼特的脾氣很不好。他試著控制那些東西,卻都沒有反應。空格鍵和Alt+F4都“不起作用”----就像它們壞了一樣。窗口也不聽話,連調整大小都不行。真差勁。就算這些想法都是下意識的,這些“失去控制”的細微感受也最終使他感到不快。“我還是喜歡我自己的電腦”,彼特想,“它被我設置的完美無缺,總能按照我想的方式去運行。而這些Mac真是難用。真是讓人不爽。如果Apple這些年多花些心思在MacOS上,而不是搞iPod那些那些玩意,他們的操作系統也不會這么糟糕了。”

          好了。我們比彼特清楚。他雖然有這些種種感受,但事實上對Mac用戶來說,Mac確實很好用。完全可以用任意鍵來關閉窗口。微軟的程序員很可能覺得,讓用戶拖動任意邊都可以調整窗口大小的功能真的很不錯。而Apple程序員很可能認為,拖動任意邊來移動窗口位置的功能很有創意。

          那些盲目信仰某種OS的網站上的關于用戶界面的爭論,都沒有說到點子上。Windows更好,是因為給你更多手段來調整窗口大小。那又怎樣?這并不是問題所在。真正的問題是,UI是否以用戶預期的方式來響應他們的操作。如果不是,那么用戶就會覺得他們無法控制它,并覺得自己會難以達成目的。就是這樣了。當一件東西能夠以被期待的方式運行,那它就是易用的。你可以把這句話反著紋在你的額頭上,這樣你在鏡子里就可以看到它。

          如果你繼續關注將來的文章,那么你會發現,我所告訴你的關于可用性設計的一切,都可以追溯到這個簡單的法則。如果哪天外星人在你的花園里著陸,把你扔到了名叫Kij8zxwrk的星球,在那里你無法連接到地球的互聯網,因為數據包傳送到地球所花時間太長導致TCP/IP無法正常工作,那么你所知道的東西也足以讓你找到一份相當體面的可用性設計師的工作了。

          posted @ 2006-03-10 06:39 shaofan 閱讀(1861) | 評論 (5)編輯 收藏

          我有一個習慣,每次學門語言,總要自己寫個List或Stack并加上Unit Test來試試。這次對Python也不例外。總體感覺有以下幾點

          1.這是我用過的唯一一個把代碼行的縮進也做為語法的語言,就因為不正確的縮進,我的第一個Python程序讓我吃盡了苦頭。事情是這樣的,我運行測試時,報告每次都說"Ran 0 test in 0.000s",找了半天,也找不出為什么只運行了0個測試,一直以為是unittest包的用法有問題,或我的語法有問題,直到花了大半個小時翻書,又對比其他的測試程序以后,才發現,天啊,原來是因為最后一行的縮進多縮了一層,被認為與上一個方法同一個block。

          2.雖然在縮進上吃了苦頭,但是代碼看起來確實相當整潔清楚,感覺比java的動不動一堆大括號相比,實在多了。

          3.Python的每個module(可以看作與java的包類似)都可以包含方法和類,而java的所有方法都要寫在類里,包里只有類,這點相當不同。

          4.因為Python是用c實現的,它的命名比較簡單,使用很多縮寫,與java的長長一串的命名是很強烈的對比

          5.Python是動態類型的語言,變量不需聲明類型可以直接使用,雖然方便,但缺點也很明顯,那就是變量的類型信息不見了,經常搞不清楚方法的參數要傳入什么,返回什么,挺不習慣的。

          6.就因為缺少類型信息,Python的文檔也沒有Java的可讀性強。比如java的 String foo(int a)一看就知道傳入整形返回字符串,換成Python就變成了 foo(a),只能讀文檔才能搞清楚了。可能我還沒習慣的原因吧,感覺有時文檔對它們的類型也說的不太清楚。

          總體感覺Python一些風格像C。寫起代碼來,感覺很快,很清楚,還是很不錯的 I love the feeling :)


          看看我寫的Stack

          posted @ 2006-03-09 20:31 shaofan 閱讀(1050) | 評論 (0)編輯 收藏

               摘要: 過去的一年,Mustang 沒能出來,EJB3剛剛才提交最終草案,Ajax興起但是五花八門不知道應該用誰,Aspectj 5出來了,但是缺乏驚喜。
          或許我們會說,過去的2005,Java界缺乏成績,但是卻毫無疑問,Java遙遙領先于其他語言。從11月的語言排行榜Java遙遙領先,到今年的Java圖書銷售統計上,Java圖書銷售總數是C#的2倍,PHP的2.5倍,Perl的4倍,Ruby/Python的9倍.
          這足以讓我們對2006充滿想象。
          不過,還是讓我們先回顧下2005吧....  閱讀全文

          posted @ 2006-03-07 09:56 shaofan 閱讀(504) | 評論 (0)編輯 收藏

               摘要: 總感覺只會JAVA似乎不夠,不記得是哪位先人說的了,一個程序員起碼要精通兩門語言,所以這些天花了不少時間琢磨python,看了不少網站,查了不少資料,正想著把一些東西寫下來,以免日后忘了,也可以和大家分享.先寫一些下載安裝和學習資源的東東.  閱讀全文

          posted @ 2006-03-05 09:30 shaofan 閱讀(5375) | 評論 (7)編輯 收藏

               摘要: Design by Contract (DbC)的概念已經出現很長時間了,最先是在Eiffel的一個特色,通過DbC來提高軟件質量,目前很多語言也都有相應的實現,但是在GOOGLE上搜索中文網頁,得到的資源并不是很多.直覺上來說,DbC確實是一個很好的想法,本著拓寬眼界的原則,就簡單了解一下吧.  閱讀全文

          posted @ 2006-03-02 00:55 shaofan 閱讀(2075) | 評論 (4)編輯 收藏

                  今天試著把大蝦寫的系統登錄模塊加到我們現有的模塊里來,他寫的時候因為有些試驗的成分,所以沒有按照我們項目的配置來寫,也沒有按照我們的模塊來劃分配置,加過來以后重新配置了模塊信息,結果居然無法正常運行。顯示錯誤:“cannot retrieve action mapping  。廢了九牛二虎之力,都無法解決。web.xml、struts-config、模塊配置,一切看起來都無比的正常,但就是運行不了。真搞不清楚是哪里出了問題。還以為搞不定,晚上要加班了,誰知道,踏破鐵鞋無覓處,柳暗花明又一村,在google上搜索關鍵字"action mapping 找不到",第一個鏈接居然就是問題的答案!(還從來沒有只點一次就可以找到問題答案的經驗,所以興奮無比^O^)

                  總的來說,問題的原因就在于,struts是在第一次收到對action的請求(注意:不包括jsp的請求)時,提取這個請求的url的路徑信息,把相應模塊的mapping信息設置到請求中去。如果在進入一個模塊時,第一次訪問的是一個jsp頁面,而在這個jsp頁面中提交到該模塊的一個action,就會出現找不到action mapping的情況。這就是因為,在進到這個模塊時,訪問的是jsp,這個模塊的任何一個action都沒有被訪問到,所以struts的ActionServlet還沒有來得及把這個模塊的mapping設置到請求中,自然找不到該模塊的action。

                  因此,這就引出一個約定,就是系統中盡量避免對Jsp的直接訪問,如果要訪問也要通過action來forward。雖然看起來麻煩一點,但是安全性、健壯性都會有所提高。

                  關于以上提到的模塊mapping的設置原理,具體的文章在這里(不長),值得收藏:

                  原文鏈接:http://202.100.72.44/news/itschool/pro/pro44134.htm

          posted @ 2006-03-01 10:44 shaofan 閱讀(2061) | 評論 (5)編輯 收藏

               摘要: 介紹了在JSP頁面動態生成Javascript樹結構的一種實現.原理是利用JSP標簽讀取數據(從數據庫或其他地方),在頁面生成Javascript的樹的數據結構,然后由Javascript腳本根據這個結構顯示出來.  閱讀全文

          posted @ 2006-02-26 18:47 shaofan 閱讀(5801) | 評論 (4)編輯 收藏

               摘要: 1.管理J2EE工程:發布WEB程序,啟動/關閉服務器等
          2.編輯JSP/HTML/XML:有代碼提示,語法著色,錯誤提示等功能
          3.跟蹤調試JSP/SERVLET:可設置斷點,單步執行,變量/棧/線程跟蹤等  閱讀全文

          posted @ 2006-02-26 18:39 shaofan 閱讀(7947) | 評論 (1)編輯 收藏

          If the problem was exploring requirements to lead them toward stability, the solution was seen to be prototyping. ... Prototyping and JAD continue to be used to this day, especially when requirements are poorly understood.

          Meanwhile, management had to figure out how to deal with reuiqrements instability and the "moving target" problem. ... But eventually management came to realize that, although they could not freeze the requirements, they could insist that changing requirements lead to changing project terms and conditions. "You want new or revised features? Then let's talk about how much time and money that will cost over and above our original estimate." Unfortunately, that led us into the swampland of changing estimates while the project was in progress...

          There is an interesting new twist evolving on the requirements instability problem. The extream Programming lightweight methodology calls for a representative of the user community to reside with the software project team during development. ... The questions remain, however, how many user organizations (a) will be willing to give up a first-rate person to such a full-time task, and (b) have one person who can represent all the potentially varying viewpoints of the customers and users?

          為了更好得捕獲需求,使它們有更好的穩定性,人們開始使用"原型"."原型"和JAD(聯合應用開發)在如今仍在被使用著,尤其當需求無法被準確理解的時候.

          同時,管理者必需面對和解決需求不穩定,及"移動靶"的問題.最終他們認識到,雖然他們無法凍結需求,但是他們可以堅持"需求變化導致合同條款變更"的想法."如果你想修改項目的功能,那就需要考慮這些修改所需要的時間和資金成本."不幸的是,這致使項目陷入需要重新進行估計的泥沼之中(在項目進行之中進行重新估計會造成哪些問題?).

          此時極限編程浮出水面.它要求一個客戶代表與開發人員一起,參與軟件開發的過程.這可以解決一些問題,然而問題仍然存在,有多少組織(a)愿意放棄一個一線員工,讓他全職參與軟件開發,(b)能找到一個可以代表所有潛在的,持不同觀點的客戶和用戶的人?(關于這點,個人認為光有客戶代表可能還不夠,還是要在需求捕獲的過程中采用多種有效的手段,起碼客戶代表要與其他參與需求的客戶和用戶有一定的一致意見,否則,怎么起到"代表"的作用?)

          [GLASS] Facts and Fallacies of Software Engineering, Rober L. Glass, Addison-Wesley,2002

          posted @ 2006-02-26 07:22 shaofan 閱讀(343) | 評論 (0)編輯 收藏

          僅列出標題
          共4頁: 上一頁 1 2 3 4 下一頁 
          主站蜘蛛池模板: 清水河县| 北川| 镇原县| 南郑县| 西安市| 巴塘县| 钟祥市| 师宗县| 云林县| 肃南| 库尔勒市| 遵化市| 新巴尔虎左旗| 西乡县| 潼关县| 沙田区| 大兴区| 磴口县| 龙江县| 湘乡市| 饶河县| 德钦县| 隆安县| 崇仁县| 辉南县| 抚顺县| 改则县| 蒙城县| 前郭尔| 湖北省| 遂川县| 根河市| 淮滨县| 兴海县| 利辛县| 井冈山市| 都江堰市| 土默特右旗| 吴川市| 什邡市| 琼海市|