類似Google構架的開源項目Hadoop 已經存在一年多了,現在正受到來自開發社區的廣泛關注。下面是來自Hadoop官網 的消息:
Hadoop是一個軟件平臺,可以讓你很容易地開發和運行處理海量數據的應用……Hadoop是MapReduce 的實現,它使用了Hadoop分布式文件系統(HDFS)。MapReduce將應用切分為許多小任務塊去執行。出于保證可靠性的考慮,HDFS會為數據塊創建多個副本,并放置在群的計算節點中,MapReduce就在數據副本存放的地方進行處理……
Hadoop是由Java編寫的,該項目已到得Yahoo的全面支持,項目的領袖Doug Cutting從2006年一月開始已經被Yahoo全職雇用于此項目中。華盛頓大學也從那時開始了一個以Hadoop為基礎的分布式計算的課程,課程相關的材料也已發布 在Google Code了,以滿足那些對這項技術感興趣的開發者們。
最近,Yahoo的Jeremy Zawodny提供了 一個Hadoop的狀態更新:
在過去的幾年里,每家參與建立大規模Web系統的公司都面臨著一些相同的基礎性挑戰……底層架構從來都是一個挑戰。你不得不去購 買、并大量安裝和管理眾多的服務器,即使你使用的是其他人提供的商業硬件平臺,你也不得不開發軟件對這些任務進行分治處理,并讓其保持運行……要建立一個 必要的軟件基礎結構,我們可以放棄開發自己的技術,這可以認為是一項競爭優勢,先賺到錢再說。但我們已經選擇了一條稍有不同的路,當認識到有越來越多的公 司和組織的需求都很相似的時候,我們發現了Doug Cutting(開源項目Nutch和Lucene的開創者)的工作,于是我們邀請他加入Yahoo,在新的開源項目Hadoop上繼續工作。
Zawodny去年一直工作于提供數據排序的基準評測,在測試中,每一個節點都對相同總和的輸入數量進行排序。 假如有20個節點,每個節點有100條記錄,那么就有2000個記錄需要排序;當有100個節點時,每個節點有100條記錄,那就總共有10000條記 錄。下面是最近的評測結果:
日期 | 節點數 |
耗時(小時) |
|
四月 | 2006 | 188 | 47.9 |
五月 | 2006 | 500 | 42.0 |
十一月 | 2006 | 20 | 1.8 |
十一月 | 2006 | 100 | 3.3 |
十一月 | 2006 | 500 | 5.2 |
十一月 | 2006 | 900 | 7.8 |
七月 |
2007 | 20 | 1.2 |
七月 | 2007 | 100 | 1.3 |
七月 | 2007 | 500 | 2.0 |
七月 | 2007 | 900 | 2.5 |
Tim O'Reilly找出了 Zawodny所發的帖子,并從中發現了來自于Yahoo的高層支持:
……Yahoo! 已經在一月聘用了Hadoop的創始人Doug Cutting,但Doug在開源大會上的談論 ,更像是Hadoop的發布會,Yahoo! 也想以此表明Hadoop項目對他們來講有多么重要。實際上,我還接到David Filo打來的電話,他想確認我是否知道這種支持來自于高層……
…… 為什么Yahoo! 的參與這么重要?首先,這預示一個搜索界第二大的公司認識到開源是在Web 2.0上與一個占統治地位的對手進行競爭的強大武器……支持Hadoop和其它Apache項目不僅僅只是讓Yahoo深入到他們可以使用的開源軟件項目 中,更會幫助他們恢復在極客(geek)心中的形象……其次,或是同樣重要的是,Yahoo! 給了Hadoop一個機會進行規模方面的測試……
John Munsh用一句話總結了
Yahoo的參與:“Hadoop和‘非我發明癥(Not-Invented-Here Syndrome)’之反例”。(譯者注:John
Munsh在這里用“非我發明癥”來指Microsoft那種不愿意接受任何協議,標準,或是其他公司開發的軟件的態度。它認為不是自己創造的東西就是不
值得信任的。而Yahoo! 卻基于競爭對手Google的MapReduce來構造自己的應用,所以這里說是“非我發明癥”之反例。)
微軟的Sriram Krishnan則從那些 轉到類似Hadoop和Amazon EC2這種針對大規模應用并在不斷發展的解決方案的創業者和開發人員所面對的問題的角度,對Hadoop提出了反對意見:
Web 2.0的主要價值來自于由眾多用戶生成的數據,如del.ico.us、Digg、Facebook……它已經超越了任何個人運行大規模的服務器軟件的商 業意義,如Gmail、Google Search、Live、Y! Search……放蕩不羈的極客們根本就不會去碰那些大規模blob存儲(S3,Google文件系統),大規模結構化存儲(Google的 Bigtable),還有在這種微架構之上運行代碼的工具(MapReduct,Dryad)等等……我也不知道Doug Cutting的這種類似的開源產物在這條路上已經走了多遠——也許這就是答案吧……查看英文原文:Open Source Google-Like Infrastructure Project Hadoop Gains Momentum
“可伸縮性(Scalability)”是軟件廠商常常在新聞稿中用到的一個詞(也是人們站在飲水機旁談論的一個詞),但這個詞在很多情況下都被誤解了。例如,很多人說起可伸縮性的時候其實指的是性能和高可用性。Royans K Tharakan試圖回答“什么是可伸縮性”這個問題,他說:
可伸縮性,簡單來說,是以更大的規模來做你現在所做的事。伸展一個Web應用的規模在于讓更多的人使用你的程序。如果你沒法找出 方法在伸展規模的同時提高性能,沒關系。而且只要你可以伸展規模來處理更大數量的用戶,那么有幾個單點故障(single point of failure)也沒關系。
Royans解釋說如今我們在面對規模伸展的時候有兩個選擇:
- 縱向的可伸縮性——在同一個邏輯單元內增加資源來提高處理能力。這樣的例子包括在現有服務器上增加CPU,或者在現有的RAID/SAN存儲中增加硬盤來提高存儲量。
- 橫向的可伸縮性——增加更多邏輯單元的資源,并令它們像是一個單元一樣工作。大多數集群方案、分布式文件系統、負載平衡都是在幫助你提高橫向的可伸縮性。
架構師們都在為達到線性的可伸縮性而掙扎,目的是讓系統產出的增長與系統中投入資源的增長保持穩定的比率。然而,增加資源會導致一般耗費 (overhead)的額外增長,因此難以達到線性的可伸縮性。Royans將之稱為“伸縮性因子”,并用它來區分各種類型的伸縮能力:
- 如果在你擴大規模的時候伸縮性因子保持為常數,這種叫做線性伸縮性。
- 但很可能有些組件并不像其他組件那么適應規模的增長。小于1.0的伸縮性因子叫做次線性伸縮性。
- 話說回來,也可能因為增加更多組件而獲得更佳的性能(在RAID系統中跨多個磁盤的I/O,當磁盤越多,性能越好)。這種叫做超線性伸縮性 。
- 如果應用程序沒有專門為可伸縮性而設計,有可能當規模擴大的時候情況會變糟。這種稱為負伸縮性。
跟軟件開發中的許多事物一樣,這里也沒有適合一切情形的銀彈可以解決你的伸縮性問題。Royans建議說,“如果你急切需要可伸縮性,向縱向發展可能是最容易的”,但注意“不幸的是縱向伸展會隨著你的規模增長而越來越昂貴”,而且“無窮的橫向線性伸縮性只是難以達到,而無窮的縱向伸縮性絕不可能”。他繼續說:
從另一方面來說,橫向可伸縮性并不要求你購買越來越昂貴的服務器。它的本意是用普通的存儲和服務器方案來實現規模伸展。不過橫向可伸縮性也不便宜。應用必須從建造的最底層就加以考慮才能在多臺服務器上運行得像一臺服務器一樣。
Royans最后建議應該考慮所有的層次才能解決可伸縮性問題:
對于一個成功的Web應用,所有的層次都要同樣能夠應付規模的增長。包括存儲層(集群文件系統、S3等)、數據庫層(分區、聯 合)、應用層(memcached、scaleout、terracota、tomcat clustering等等)、Web層、負載平衡、防火墻等等。比如,如果你沒辦法實現多個負載平衡控制器來處理未來的網絡流量,不管你在Web層的橫向 伸縮性上扔下多少錢,都不會有什么效果。你的流量始終被限制在一個負載平衡控制器能夠承受的程度。
查看英文原文:Think you know what scalability is?
12月 22nd, 2006 by 奇遇
書名原文: About Face 2.0: The Essentials of Interaction Design
作者: [ 美 ]Alan Cooper , Robert M. Reimann 譯者:詹劍鋒、張知非
推薦語
本書是一本由一位在交互設計前沿有著10年設計咨詢經驗及25年計算機工業界經驗的卓越權威撰寫的設計數字化產品行為的啟蒙書。它探索了一個獨特的設計領
域,即復雜系統行為的設計——特別是軟件激活技術。本書論述一種具有革命意義的設計觀念——人類驅動設計過程。
本書是一本難得的大師經典之作,應該是一本產品規劃師、界面設計師以及可用性工程職業人員或者程序員都想得到的書。
封面
序
本書旨在為您提供一些有效而實用的工具來設計用戶界面( user interface )。這些工具很明顯分為截然不同的兩類:戰術性工具
(tactical) 和策略性 (strategic) 工具。戰術性工具是使用和創建用戶界面的習慣用法 (user interface
idioms) ——如對話框 (dialog box) 和下壓按鈕 (push button) ——的提示( hint )和技巧 (tip)
。而策略性工具是思考用戶界面習慣用法的方式,換言之,即用戶與用戶界面習慣用法的交互方式。
雖然已經有了一些介紹策略性或者戰術性準則的書,我們的目標在于寫一本能將兩者融為一體的書。在幫助您設計更有吸引力、更有效的對話框的同時,本書還將幫助您理解用戶如何了解您的軟件,以及與之交互的方式。
設計有效的用戶交互和界面之關鍵在于將策略性和戰術性的方法合二為一。例如,客觀上不存在好的對話框——對話框的品質取決于具體的應用情形:用戶是
誰,他們的背景和目標是什么。僅僅應用一系列的戰術性說明( tactical dictum
),會使創建用戶界面變得更容易,但這并不能使最終結果更好。同樣,對于用戶應該如何與您的系統交互的深層次思考也不能改善軟件本身。真正奏效的是:在策
略上對用戶與特定軟件的交互方式保持敏感的同時,擁有一個可以在任意情況下應用的在你掌握之中的戰術工具盒 ( tactical toolbox )
。本書既會加深您對用戶的理解,又將教您如何把這些理解轉變為設計理念。
誰應該讀這本書
在 1995 年 8 月,軟件觀念革命( About Face )這本書第一次出版時, 界面設計 (interface design)
還是個未開墾的新領域。少數人在軟件工程的影子下,勇敢地以用戶界面設計師的頭銜工作,正如機敏的小哺乳動物在粗暴的巨龍陰影下爬行。正如在軟件觀念革命
第一版中所指出的,軟件設計被人們錯誤地理解和評價。過去是怎么做的,程序員就就是怎么做的。很多處境不佳的文檔工程師 (documenters)
、培訓者、技術支持人員,以及處于增長趨勢的 可用性工程職業人員( usability practitioners )
都意識到:某些事情應該改變。
Web 令人吃驚的、似乎是一夜之間的發展和流行,驅動了這種改變。突然間,易用性( ease Of use) 成了掛在每個人嘴邊的術語。在
20 世紀 90 年代初期,即多媒體短暫流行的期間,涉足數字產品設計的傳統設計師紛紛轉向 Web
。表面上,新的設計師頭銜像雜草一樣涌現:信息設計師 (information designer) 、信息架構師 (information
architect) 、用戶體驗策略師 (user experience strategist) ,以及交互設計師 (interaction
designer) 。 C 級公司的首席職務(首席用戶體驗官, user experience officer
)一開始就存在,他的工作核心是創建以用戶為中心的產品。很多重點大學都爭先恐后地開展這些理論的培訓。與此同時,可用性工程和人性因素( human
factor )職業人員的地位也在提升,現在被承認是推動更好產品設計的領導者。
雖然 Web 使得界面技術倒退了不止十年,但它無可爭議地將用戶需求永久地置于公司的雷達之上。作者堅信: .COM
的衰敗只能使得用戶及其需求的可見性,以及對它們的關注在將來變得更加明顯。人們一般對新技術感到厭倦。消費者傳達了明確的信息,他們所需要的好技術是容
易使用的,并且能滿足他們需求的技術。
因此,作者很高興地說,新版本的讀者群會大大地增大:任何對用戶與數字產品的交互感興趣的人都會在讀這本書的過程中獲得獨特的能力洞察力。程序員、與
數字產品相關的設計者、可用性工程職業人員、項目經理都會從此書中受益匪淺。讀過《軟件觀念革命》( About Face )
第一版或《軟件創新之路》( The Inmates are running the Asylum )
第一版的讀者會在此發現更新穎且更詳細的有關設計方法和原理的詳細信息。
為什么要做交互設計
《軟件觀念革命》的第一版描述了一門被稱為軟件設計的學科,同時也可稱為用戶界面設計。在這兩個術語中,用戶界面設計有更強的生命力。在本書里,我們仍會使用它,而且大多數是合適的。
然而,筆者很清楚,本書所討論的內容要遠比用戶界面設計的范圍廣。界面這個詞意指表面,本書所闡述的大多數設計問題要遠遠比 CRT 屏幕的表面問題深奧,它直接觸及了“數字產品是什么”,以及“數字產品要做什么”等核心問題。
近些年來,對于這類設計,人們已經提出了許許多多的術語。在 2000 年左右,公司對 Web 的興趣達到頂點時,被稱為信息架構(
information architecture , IA )的學科似乎最終包含了此處這里討論的這類設計。但是正如 Web
在經濟方面的前景已經暗淡一樣, IA 基本上也保留了它以 Web 為中心的狹隘視圖:如何組織和瀏覽頁面上的內容。隨著新經濟的明顯下滑, IA
產業的好運也逐漸消失。
另一個近年來流行的術語是 體驗設計( experience design ) 。美國圖形藝術研究所 (American Institute
of Graphic Artists , AIGA)
特別提倡使用這個術語來概括用于開發數字產品和系統的不同設計與可用性工程學科。這個想法很有吸引力,但它仍然回避了一個問題——什么樣的設計才是交互式
系統設計的真正核心,交互式系統設計是一種明顯不同于已有設計的嶄新設計。
體驗設計這種想法也有一定的問題。在筆者看來,體驗是人與人工制品(或者其他生物)交互的結果。體驗出現在一定的上下文場景 (context) 中,進一步由內部、心理的個人環境所調節,這種個人環境由動機、過去經驗、氣質和多種認知因素形成。
作為設計者,我們不能聲稱能夠設計一種人工制品或者系統的用戶體驗,但我們能夠設計與人工制品交互的機制,以改善用戶體驗。因為,我們相信體驗發生在
人和人工制品交互的過程中,我們已經選擇了“交互設計”這個術語來表示本書描述的這類設計,該術語由 Bill Moggridge 和 Bill
Verplank 在 20 世紀 80 年代首創。你不能設計體驗本身,但你能設計調節和引導體驗的交互行為。
交互設計的定義
簡單地說,交互設計是 人工制品 (artifact) 、環境和系統的行為,以及傳達這種行為的 外形元素 (formal element)
的設計與定義。不像傳統的設計學科主要關注 形式 (form) ,最近則是關注 內容和內涵 (content and meaning)
,而交互設計首先旨在規劃和描述事物的行為方式,然后描述傳達這種行為的最有效形式(參見圖 1 )。
交互設計借鑒了傳統設計、可用性工程及工程學科的理論和技術,它是一個具有獨特方法和實踐的綜合體,而不只是部分的疊加。它也是一門工程學科,具有不同于其他科學和工程學科的方法。
交互設計是一門特別關注以下內容的學科:
? 定義與產品的行為和使用密切相關的產品形式
? 預測產品的使用如何影響產品與用戶的關系,以及用戶對產品的理解。
? 探索產品、人和 上下文 (context) (物質、文化和歷史)之間的對話 (Riemann 和 Forlizzi,2001)
? 交互設計從目標導向 (goal-directed) 的角度解決產品設計:
? 要形成對人們希望的產品使用方式,以及人們為什么想用這種產品等問題的見解。
? 尊重用戶及其期望目標。
? 對于產品特征與使用屬性,要有一個完全的形態,而不能太簡單。
? 要看到產品最終成品的樣子,它們目前的樣子并不重要。
設計的三維
交互設計著重于傳統設計較少探索的領域:行為設計。
所有的設計影響人類行為:結構關于人們使用空間的方式,與形式和光線有關。如果沒人對張貼畫所表達的信息有所反應,那張貼畫又有什么意義呢?
引入交互技術——計算機的禮節——來設計人工制品的行為,以及這種行為如何影響和支持人的目標和期望?已經成為一門值得關注的學科。
理解交互設計和傳統設計關注點的不同方法之一是借助歷史透鏡。在 20
世紀的上半葉,設計者主要關注形式。后來設計者逐漸關注內涵,例如,產品設計師和結構師在 20 世紀 70
年代引入了本土和懷舊形式。直到今天,這種趨勢仍在繼續,諸如 PT Cruiser
的懷舊風格的汽車。今天,信息設計師繼續關注內涵,包括可用內容的設計。
在最近 15 年以來,越來越多的設計師開始談論行為:軟件激活技術 (software-enabled) 的產品(或復雜的機械)直接與用戶交互的動態方式。
這些關注(形式、內涵及行為)并不是相互排斥的。交互產品必須多少包含各部分;軟件應用關注更多的是行為和形式,而對內容的需求較少; Web 站點和公用信息亭關注更多的是內容和形式,而較少關注復雜的行為。
因為,復雜系統的行為通常不是一個審美學 (aesthetics) 的問題,而是認知因素 (cognitive factor) 和邏輯過程 (logical processes) 的結合,交互設計應該采用系統化方法,且能從這種方法中受益匪淺。
交互設計師應該,也是首先要做的,理解使用他們設計的人們的目標、動機和期望(心智模型 , mental model )。這些最好能被理解為“敘述” (narrative) ——時間軸上的邏輯(或者情感)進展。
與這些“敘述”相適應,所設計的人工制品必須具有它們自己的行為敘述,且這些行為必須成功地與用戶的期望吻合。不像大多數機械制品,只有簡單的行為,
觀察之下一切都一目了然,軟件和其他數字產品因為其行為潛在的復雜性,所以它們需要交互設計。軟件對于觀察者是不透明的,然而它所表現出來的可能行為幾乎
是無限的。
一些設計者,以設計的傳統形式,如視覺 (visual) 、聲音( audible )、觸覺 (tactile themes) ,模式
(patterns) 、風格 (style) ,以及習慣用法 (idioms) 為論據,認為交互元素應被視為隨著時間變化的感覺數據(
sense data )流,類似于動畫 (motion picture)
,因此完全可以通過傳統設計方法來描述。然而,這種論點有嚴重的缺陷:盡管交互設計面向形式的方面非常重要,但是,除非它們是通過有效和合適的行為組織
的,否則幾乎沒用。如果沒有一個邏輯結構或流來幫助解決用戶的實際問題,那么面向形式的交互設計( form-oriented
interactive design )本身只是隔靴搔癢,價值值得懷疑。
換句話說,如果沒有條理化的“敘述”,感覺數據本身毫無意義。電影不能光有特效,敘述也很必不可少。這一點,對與數字產品的交互而言,更有效,因為對
話不在第三方可觀察到的虛幻境界中發生。相反,它是在人和設計的人工制品之間的交流, Bill Buxton ( 1990
)稱之為“非文字的自然語言”。這種對話(也就是行為)的期望和設計是交互設計的實質。
本書的內涵和外延
本書是一本有關交互設計(交互系統復雜且以用戶為中心的行為設計)的原理和方法的參考書。本書的第一篇強調 設計過程 (design process) ,以及對用戶的系統理解;第 2 篇提供了策略原理和工具;第 3 篇更深地鉆研戰術性的問題。
本書不打算以 指南 ( guide )的姿態出現,或者提供一些界面標準。實際上,你會在第 19
章了解到為什么那些工具的使用是有限制的,而僅僅與特定環境相關。也就是說,在本書中描述的過程和原理是與你選擇的風格指南相兼容的,它也是解決任意這類
問題的一本極好的配套書。 指南 擅長于回答做什么,但無法回答為什么這樣做。本書打算解決交互系統設計中未解決的問題。
設計交互系統有 4 個步驟:研究問題域( researching the domain ),理解用戶 (understanding
with user) 及其需求;定義解決問題的框架 (defining the framework of a solution)
;完善設計細節 (filling in the design details) 。
很多業內人士會加上第 5 個步驟:確認( validation )——讓用戶測試方案的有效性。他們這么做,不會錯。最后一步是眾所周知稱為可用性學科的一部分。
可用性工程方面的重要文獻在持續增長,但有關交互設計的資料卻相對很少。本書專門關注交互設計的過程和原理,設計方案的測試方法則留給出版的相關學術著作。本書可以與可用性工程方法和實踐的文獻配套使用。通過和諧地結合這兩個學科,你會獲得最好的設計成果。
譯者注 作者定義的術語,見第 2 章。
譯者注 作者定義的術語,見第 6 章。
名家推薦
ALAN COOPER 作者推薦
當我們被聯系為 該 寫中文版的序言時,我們非常興奮,因為我們有機會接觸一批新的而為數眾多的讀者,包括學生,設計人員,開發人員,以及人性因素專家等。
在最近幾年,中國不僅成為基于軟件的數字產品 —— 從計算機、蜂窩電話到家庭和個人娛樂系統 ——
的主要制造者,也成為這些產品的日益重要的消費者。這就意味著在中國數以百萬的新用戶正在使用軟件和數字產品,其中不乏初學者。由此可見,對于用戶界面口
和交互設計師來說,這是一個獨一無二的機會,他們的工作可以極大地改進這些數字產品的質量和合意性,并最終影響數以百萬計的人們的生活。
和西方一樣,中國的開發者和制造商經過了一段時間才理解,用戶界面和用戶交互對于使得數字產品更有用和更成方面所具有的極端重要性。除了改善用戶的生
活質量以外,容易使用和理解,并且能夠更好地滿足用戶需求的產品有額外的潛力,為生產商增加利潤和市場份額。我們希望本書將會為市場引領一條通向更好的數
字產品的道路,也可以為本書的讀者,不論學生,設計人員,開發人員還是制造商,帶來更多的機遇。
交互設計是設計中的一個新領域,在這里是行為,而非形式成為最為關鍵的因素。形式必須支持行為,但是當用戶和一個復雜的數字產品交互時,用戶所能感受
到的產品質量和從中獲得的親身體驗均來自于產品的行為。不是基于軟件的產品不會有復雜的行為:錘子只有單一而簡單的行為,除了樣式以外不需要別的設計。然
而,蜂窩電話、掌上電腦或者數碼相機有很多復雜的行為,而這些行為需要仔細而專門的設計方法。
本書試圖描述行為和交互式設計這一嶄新而又令人興奮的領域的基本原則,我們預測這一領域將會成為 21 世紀設計學中的一個主要領域。
本書的大部分例子來源于桌面計算機應用和 WWW 。盡管如此,書中幾乎所有的內容也適用于別的數字設備。
本書并不致力于闡述所有可能的設計方法,它也不包括用戶界面標準的風格指南。事實上,本書提供了一個獨特的過程和框架,借助它可以設計產品和產品的行為,而這些行為真正地解決了用戶最核心的需求和意愿。
書的第一篇描述了這一系統的過程 —— 我們稱之為目標導向設計 —— 這一部分有一個前提,就是:如果你對產品的用戶有深入了解,也了解他們使用該產品的動機(他們的目的),那么你可以為最重要的用戶需求開發界面。
本書第二篇和第三篇提供了高層次和細節的設計原則,主要涉及如何選擇產品行為,既可以滿足用戶需求,又可以為用戶消障礙,這無疑會提高用戶的滿意度和
生產率。在過去的 13 年里,我們在全世界使用了上面所說的方法為小到剛起步,大到有上百億美金的公司的數百種數字設備,軟件產品以及基于 Web
的服務做了設計。
自從該書 2003 年在美國出版以來, 在美國和歐洲本書已被許多大學的計算機科學和設計專業選為教材 。尤其是人物角色的使用(在第一篇所描述的刻畫用戶的一個強有力的工具),幾乎已經成為普遍采納的設計和人性因素的最優方法。
無論在中國還是西方,交互式設計的未來都是光明的。我們希望本書能激發出中國新一代數字產品和服務中的杰出設計!
Robert Reimann
Brookline , Massachusetts , USA
Alan Cooper
Menlo Park, California, USA
2005 。 1
葉展 人機交互分析師
讀經典著作如同飲醇酒,回味雋永。而給經典著作寫序,則如推銷醇酒與人,在別人的沉醉中分享快樂。
擺在我面前的就是一本經典著作,一本計算機領域的經典著作。眾所周知,計算機領域多的是應景之作,比如某某軟件版本 X.0
的使用指南之類,而少能經得起時間考驗的經典著作。其原因一方面是計算機領域發展迅猛,知識更新代謝極快;另一方面,則是計算機領域應用重于理論,所以有
思想深度的著作比較少。
一本書要成為經典,起碼要兩個條件。其一是著者是擁有深邃的思想,且文筆流暢。大師級人物,往往單從文字上的修養就看得出。比如經濟界的
George Stigler (諾貝爾獎獲得者,被譽為經濟學界一支筆)和軟件工程方面的 Frederick Brooks
(《神秘的人月》著者),他們的著作拿起來閱讀幾段,你馬上就可以在行文中感到那種大家的雍容風度。而更重要的是,大師們在書中所講述的往往不是細枝末節
的技巧和技術,而是一種深邃的思想方法,可以給人以深層次的啟發。那種風度和深度,是難于模仿的。
要成為經典的第二個條件是作者的思想要經得起時間的考驗。對計算機書籍來說,起碼要能經過 10 年的考驗。這個標準比之其他領域已經是很寬松的了,但在這個標準下大部分計算機書籍會落馬。
以筆者來看,本書基本上符合前面的兩個條件,是一本計算機領域的經典之作。
本書的作者 Alan Cooper ,是計算機業界一位成名高手。除了早期在 Visual Basic 方面的工作外(他被譽為 Visual
Basic 之父),更重要的是他曾站到了一個新領域的前沿,參與并影響了軟件開發領域一次深刻的變革。而這個新領域,就是人機交互(
Human-Computer Interaction )。這個變革,是軟件開發領域的第三次革命。
在軟件開發領域出現過三次革命—— 50
年代高級語言的出現,使得軟件開發從機器硬件(機器語言)的束縛中解脫出來,程序員能夠從(抽象+結構)層次來進行思考。此為第一次革命。 70
年代軟件工程興起,使得軟件開發的注意力由語言和編譯器技術拓展到軟件開發的過程( software process
)。人們意識到:要提高一個軟件產品最終的靜態質量,必須提高這個產品產生過程的動態質量。此為第二次革命。而 90
年代以來,隨著計算機軟件和商業行為的聯系越來越緊密,特別是互聯網的興起,人們進一步認識到:軟件不是孤立的,軟件的質量并不是僅由其本身就能決定的,
而是由(軟件+用戶)這個大系統來決定的。軟件的成功,在于是否它能夠成功嵌入到用戶的商業活動中。對人的因素的重視,使得一門新的領域崛起。這就是人機
交互。經過十幾年發展,人機交互理論已經全面改觀了一般商用軟件設計開發的流程和方式,成為業界的標準。是為第三次革命。
每次革命或變革,都會有豪杰之士涌現,為改變舊的思想和宣傳一種新的思想而搖旗吶喊,成為領導變革的預言家和代言人。在 90
年代,一批人物涌現,一批著作發表,為人機交互理論在業界的應用打開了局面。 Donald Norman 在 1990 年出版了《 The
Design of Everyday Things 》, Jakob Nielsen 在 1994 年出版了《 Usability
Engineering 》,本書作者在 1995 年出版了本書的第一版。這些人的著作,都是經受了 10
年考驗的,現在都成了經典。他們當時的思想,現在已經成為業界的主流。他們也自然而然地成為了人機交互領域舉足輕重的領導者。
閱讀本書,最重要的是了解作者所闡述的關于軟件設計開發的高層次理念和指導思想。因為作者是最新一次軟件開發思想變革的積極參與者,他親自現身說法寫
的書當是記錄這個思想變革的寶貴的第一手資料。正因為如此,筆者竊以為本書的第一部分最是重要,乃為全書的靈魂。這部分從了解用戶,了解用戶需求講起,到
構建用戶模型,到設計 scenario
來描述軟件系統現在和未來的行為模式,到如何把對用戶的理解和行為模式轉換為設計方案。作者不僅把軟件設計的整個過程流暢清晰地描述出來,而且真知灼見不
斷涌現于其中。下面隨便列舉一二:
? 軟件的設計和開發,不要囫圇吞在一塊,最好要分成兩個單獨的過程——設計過程和開發過程:
傳統的軟件工程理論,是對整個軟件設計開發的過程化研究,而更側重編程測試和項目規劃部分,并且把設計和開發混在一起。而現在人機交互理論,實際上是把軟
件設計這部分提出來,是對軟件設計的過程化分析,還借用了認知心理學和其他領域的成果。目前業界普遍認為:對商用軟件來說,這兩個階段分開,有助于軟件質
量的提高。
? 應當以用戶為中心去設計軟件,而不是以某項新技術或者技術人員為中心去開發軟件:
這一點是軟件走出象牙塔,滲入人類生活和商業領域的必然后果。作者雖然是程序員出身,但對以程序員(技術的代表)為核心的軟件開發的局限性有清醒的認識,
并指出這種方法再也不能適應開發軟件產品的需要。基于用戶的設計( User-Centered Design )是 90
年代以后被“炒”的最火的一個詞。它實際上是說在軟件設計過程中要圍繞用戶和商業活動來進行,是不是圍繞技術和程序員來運行。
? 決定軟件成功與否的,不是一個軟件有多少個功能,而是這些功能是否有用和好用。
? 設計軟件,重要的是設計用戶行為: 作者所極力鼓吹的一個新的名詞——交互設計( Interaction Design )的含義就是軟件設計師設計的不是死的軟件,不是靜止的界面,而是活的行為,是用戶和軟件硬件環境之間的動態交互,并尋求動態的最優。
需要指出的是:以上思想,在 1995
年本書初版時乃為革命,與今則為業界常識——起碼是美國商用軟件開發領域人所共奉的常識。現今但凡大一點的和軟件開發有關的公司,其軟件設計開發過程都按
作者所提出的思路改進過。從另一個角度講,這更體現了 90 年代這場變革的影響之深遠。
在本書的第二部分, Alan Cooper 介紹了一大把新概念和新名詞(眾所周知, Alan Cooper
在業界有賣弄新名詞的“不良”嗜好。業內人最愛開的玩笑之一就是傳說在什么什么會議上 Alan Cooper
又發明了一個新的英文詞。當然能夠在計算機業內成為這種玩笑的對象本身就說明這個人很有影響力。)這些新名詞,由于是獨此一家,別無分號,讀者讀來需要一
定的辨別力。需要記住的是:雖然這些名詞比較新奇,但其含義和基本思路應該是容易接受的。
與前兩部分比,本書的第三部分就完全是實用性的了,有諸多實際的設計案例和討論,而且主要是基于現有圖形用戶界面的格局。
由于本書的這種結構——由抽象理念入手,到具體的設計方法和案例,使得它適合各類讀者閱讀。軟件公司的領導者可以通過前兩部分了解軟件行業的最新思
潮,并以此為指導思想來改進自己公司內部的軟件開發流程。軟件開發人員,可以學習書中介紹的具體的方法,更可以從更實際的案例討論中獲得啟發。對學生來
說,除了學習編程等“硬”技術外,通過讀書了解一下軟件行業“軟”的思想,拓展眼界,受益將會不淺。
國內軟件行業經過多年發展已經初具規模,當然在發展的過程中也遇到諸多問題。目前的一個共識是中國軟件業和外國比,最大的劣勢并不是在具體某項技術或
者編程方面。中國的勤奮而又有天分的程序員,可以獲得美國業界的編程大獎。由此可見單打獨斗中國人是可以的。但項目一大起來,中國軟件業的固有劣勢就顯現
出來了。中國的傳統弱項主要是在軟件工程和軟件過程等方面。而現在西方軟件行業又進了一步,在軟件工程的基礎上搞出了人機交互理論,又引發了一次革命。我
們目前對這場革命的了解還是很膚淺,人機交互領域在國內的科研、教學和應用都還在起步階段。這就很有些舊的差距沒有彌補上,新的差距又產生了的危險。這本
書現在被介紹到國內來,將有助于我們填補這方面的差距。此其時也!
葉展
人機交互分析師
2005 年 7 月于美國芝加哥
葉展,清華大學自動化系本科畢業,后赴美留學,先后取得伊州理工學院( Illinois Institute of Technology)的計算機碩士學位和卡內基美隆大學(Carnegie Mellon University)的人機交互(Human-Computer Interaction)碩士學位,現在美國BCS管理和IT咨詢顧問公司任職。葉展目前主要的研究和工作領域是人機交互理論在游戲設計中的應用、人機界 面設計與評測、以及軟件開發流程設計和管理。是這些領域有一定影響的專家,并應邀在包括CHI等一系列重要國際會議上發表了論文和演講。
譯 者 序
今天,人類不僅在認識世界,也在創造著新世界。軟件作為人類所創造的最復雜的人工制品( artifact )之一 ,
已不僅僅是人類智慧和工具的延伸,而在某種程度上作為虛擬世界新法則的執行者和實施者統治著我們。諾貝爾物理學獎獲得者費曼曾經以這種方式描述過人類創造
新事物的過程:我們創造新事物,而被創造的新事物按照某種規則又創造新的事物,突然某一瞬間,不同于人類靈魂的事物出現了:它與人類靈魂迥然不同,或許還
有著惡意,威脅著人類。一個智者以這種玄想的方式展現了對人類創造物的恐懼。
今天的軟件人工制品會以這種方式工作嗎?是否會威脅到我們的人類?作為軟件業的一名從業人員,譯者深知以 0 或者 1
為工作基礎的計算機所有智慧來自于設計師和程序員的智慧,本身不具有惡意。然而,現實的情況是 “
受不正確的設計觀念影響開發的軟件已經開始威脅到大眾用戶 ” ,技術派論者甚至以 “ 計算機盲 ” 通常稱這些和計算機工作者一樣富有智慧的人們。
請尊重你的用戶! Alan Cooper
,這位在圖形用戶界面領域馳騁數十年的大師給出了如此的忠告。大師的忠告是中肯而辛辣的,技術不能高高在上,而應該植根于土壤,軟件工人們不能脫離為人民
服務的宗旨,否則就要被革命了。新技術經濟的沉淪也許指示著新的機遇:為大眾用戶服務,采取全新的目標導向設計方法。
這種方法關注用戶的目標;認真地研究實際用戶和潛在用戶,定義具體的原型用戶 ( 人物角色 , persona) ;使用人物角色作為腳本提綱 (scenarios) 的主要人物;人物角色作為定義交互產品功能、行為和形式的主要工具;遵循行為設計的原理。
在系統模型方面,作者精彩地辨析了程序員的實現模型和用戶的心智模型之間的差異,指出程序員通常為了容易實現的私利犧牲用戶利益,用實現模型取代用戶
的心智模型,從而產生了認知方面的鴻溝,因此在交互設計領域有必要區分設計和編程的責任。在用戶分析方面,將用戶分為新手用戶、中間用戶和專家用戶三類
, 提出了沒有用戶愿意永遠做新手用戶,只有少數用戶才會成為專家用戶,因此大多數用戶都是永久的中間用戶,設計應該為中間用戶優化的精辟論解。
在行為和形式設計方面,作者深刻地揭示了一些現象背后隱藏的本質。首先從行為立場出發,定義了軟件姿態的概念,將軟件分為獨占、暫時、精靈和輔助四種
姿態。不同姿態的軟件對應不同的用戶類型,如獨占式應用的用戶是永久的中間用戶,應該在使用整個屏幕的情況下優化獨占姿態的應用;而暫時姿態應用應該簡
單、清晰而切中要點,保持在一個窗口和視圖內。在用戶心理層次,作者深刻地揭示了流狀態 :“ 深深的完全沉思狀態 ” ,經常產生 “ 輕微的歡娛
”
,能夠讓你忘記時間的流逝。因此,軟件交互應該促進和加強流狀態,而不是打斷或者干擾流狀態。為了創建高效的軟件,作者提出了附加工作的概念,分析了附加
工作產生的原因,指出只有消除附加工作,用戶才會效率更高。在這種背景下,作者也詳細地分析了圖形用戶界面的導航問題,以及如何消除導航中出現的附加工
作。另外,作者指出要想開發效能高和用戶使用起來會愉悅的軟件,軟件必須能夠體貼和足夠聰明。也正是從這個角度出發,作者詳細地討論了如何改善數據檢索和
數據輸入,使其體貼和足夠聰明。
在討論如何為不同用戶設計時,作者指出有兩個概念在根據不同的經驗水平將用戶的需求進行分類方面特別有用:命令向量和工作集。命令向量是允許用戶向程
序發起指令的特殊技術:下拉菜單、彈出菜單和工具條控件都是命令向量的例子。好的用戶界面提供多種命令向量,這種冗余性讓不同技能水平的用戶和不同偏好的
用戶根據自己的意愿和能力向程序發起命令。因為每個用戶都在無意識地記憶經常使用的命令,持久的中間用戶記住了命令和功能的適度子集:工作集。雖然嚴格的
說沒有一個標準的工作集可以覆蓋所有用戶的需求,但是用戶和使用模式的研究和建模可以產生一個較小的功能子集。這個最小工作集可以通過目標導向的設計方法
確定:利用腳本提綱來發現你的人物角色所需求的功能。這些需求直接轉化成最小工作集的內容。
作者也詳細地闡述了視覺界面設計的一些基本原理,并在具體的背景下討論了這些視覺界面設計原理的應用。如視覺界面必須:
? 避免視覺噪音 (visual noise) 和雜亂 (clutter) ;
? 使用對比 (contrast) ,相似性( similarity )與分層 (layering) 來區分和組織元素;
? 在每一個組織層次提供視覺結構和流;
? 使用緊湊、一致而場景合適的圖像;
? 全面而有目的地結合風格和功能。
在對主流的三類界面范例:實現為中心( implementation-centric )、隱喻 (metaphoric) 和習慣用法
(idiomatic) 分析的基礎上,作者獨特而精辟地指出隱喻的限制,強調了習慣用法的力量,深刻地指出 “
所有的習慣用法都需要學習,而好的習慣用法只需要學一次 ” 。
另外,作者憑借淵博的知識和豐富的產業界經驗,深刻全面地揭示和闡述了各種交互細節的本質、演化和蘊含的發展機遇,如直接操作 (direct
manipulation) 、選擇、拖放 (drag and drop)
。在圖形用戶界面發展的歷史背景下,作者高屋建瓴地詳細討論了各種控件和它們的行為。
在譯者學習和翻譯這本書的過程中,深深地感受和體會到作者的大師風范,以及卓爾不群的見解和深刻的思想,并且在具體的科研實踐中受益。相信任何一個讀者只要用心讀這本書,都會有同樣的感受,并有豐富的收獲。
譯者要感謝參與本書出版過程中的朱沭紅編輯、孫學瑛編輯、 蔣芳 女士,感謝她們的耐心、信任和協作。
詹劍鋒 ( jfzhan@ncic.ac.cn ) 、張知非
2005 年 3 月 1 日
第一篇 了解你的用戶
第一部分 彌合差距
1 目標導向設計
2 實現模型和心智模型
3 新手、專家和中間用戶
4 理解用戶:定性研究
5 用戶建模:人物角色和目標
6 腳本提綱:將目標轉換為設計
7 綜合好的設計:原理和模式
第二篇 設計行為和形式
第二部分
8 軟件姿態
9 和諧與流
10 消除附加工作
11 導航和調整
12 理解撤銷
13 重新思考“ Files ”和“ Save ”
第三部分 提供高效能和愉悅
14 設計體貼的軟件
15 設計智能的軟件
16 改進數據檢索
17 改進數據輸入
18 為不同的需要進行設計
第四部分 應用視覺設計原理
19 外觀設計
20 隱喻、習慣用法和啟示
第三篇 交互細節
第五部分 鼠標和操作
21 直接操作和定點設備
22 選 擇 327
23 拖 放 336
24 操作控件、對象和連接
第六部分 控件及其行為
25 窗口行為
26 使用控件
27 菜單:教學向量
28 使用菜單
29 使用工具條和工具提示
30 使用對話框
31 對話框禮節
32 創建更好的控件
第七部分 與用戶的交流
33 消除錯誤
34 通知和確認
35 與用戶的其他交流方式
36 安裝過程
第八部分 超越桌面的設計
37 Web 設計
38 嵌入式系統的設計
1. 基本組成:
a) 運行入口CodeEngineRunner的main();里面注冊所有的Generator;主要有:IbatisGenerator,ControllerGenerator,JSPGenerator三個;任意一個可以單獨運行多次;
b) 代碼結構:*Generator,用于生成domain,manager和sqlmap,controller等文件,在生成之后為了保持系統的完整性,通常會調用一些Modifier去修改配置文件;由于每個Generator會單獨再次訪問配置文件,所以可以單獨和重復生成;
c) 主要的配置文件有2個,位于code_engine目錄下,分別為:code-engine-config.xml,code-engine-gears.xml,但在實際使用中,我們經常要配置的是code-engine-gears.xml,前者一般在項目開始的時候設定,后者用來生成和修改domain,manager和sqlmap, controller,jsp和相關的一些配置文件;
d) 模板文件位于template文件夾下面;可以任意添加和調用;語法為freemarker,但是,通常只需參照其他模板文件,一般都可以寫出新模板;
e) 每次運行codeengine都會在backup目錄下面生成備份文件,以備再次生成和修改;
f) 生成日志在logs目錄下;
g) Framework目錄是框架目錄,可重用部分,在生成新項目時候拷貝用;
h) Reference目錄是一些開發組件,主要是寫js組件;
2. code-engine-config.xml 配置簡介:
<?xml version="1.0" encoding="UTF-8"?>
<codeEngineConfiguration>
<context>
<distDir path="D:"wiczone"trunk"wiczone" java="src" web="war"/>
<!--<distDir path="D:"test"trunk"project" java="src" web="war"/>-->
<!--<distDir path="build" java="src" web="war"/>-->
<templateDir path="template"/>
<i18nSupport>true</i18nSupport>
<database classPath="lib"mysql-connector-java-3.1.7-bin.jar">
<driverClass>org.gjt.mm.mysql.Driver</driverClass>
<url>jdbc:mysql://localhost:3306/wiczone</url>
<username>root</username>
<password>root</password>
</database>
<package base="biz.wic" app="application">
<!--<package base="biz.web" app="framework">-->
<domain>domain</domain>
<controller>web</controller>
<manager>manager</manager>
<service>service</service>
</package>
<web layoutComponent="tiles">
<manager>WEB-INF"applicationContext-manager.xml</manager>
<lucene>WEB-INF"applicationContext-lucene.xml</lucene>
<servlet>WEB-INF"action-servlet.xml</servlet>
<security>WEB-INF"applicationContext-acegi.xml</security>
<sqlMapConfig>WEB-INF"sql-map-config.xml</sqlMapConfig>
<messages>WEB-INF"classes"messages.properties</messages>
<tiles>WEB-INF"defs</tiles>
<jdbc>WEB-INF"jdbc.properties</jdbc>
</web>
</context>
<!--
IMPORTANT NOTES:
1.in most cases, we no necessary to modify the <context/> part, since we have already set done;
2.each of controller/jsp can be re-created alternatively.
3.please becareful that metadata's character case.
4.the basis rule is:
if not existed we will created;
if already existed we may overwrited;
-->
</codeEngineConfiguration>
1) 如上所示,< database > 用于配置數據庫的連接,注意要保證driver能訪問到;
2) <Package>負責生成各種代碼使用,
3) <web>用于指定一些配置文件;
4) 以上文件通常在項目開始的時候設定;
<context>詳解
a)<distDir path="build" java="src" web="war"/>
<!--<distDir path="D:"dist_project" java="src" web="war"/>-->
<templateDir path="template"/>
<i18nSupport>true</i18nSupport>
distDir@path指目標項目的路徑,‘build’是相對路徑; @java指java source code的根目錄;
@web指web application的根目錄;
templateDir@path指freemarker template所在的目錄,這里設定的是$Code_Engin$"template; 此目錄下放置用于生成controller和jsp的模板文件(以ftl為文件后綴);
template /lib/下面放置的一個common.ftl為通用的functions,已經用auto imports引入,要調用common.ftl的function,通常類似:<@ce.dosth param=paramObj />, ce是namespace,用于限定引用;具體代碼見(BaseGenerator.java)
5) i18nSupport是指定jsp是否支持多語言;一般設定為支持的;
<package base="biz.wic" app="application">
<domain>domain</domain>
<controller>web</controller>
<manager>manager</manager>
<service>service</service>
</package>
用于設定java code的package;
<web layoutComponent="tiles">
<manager>WEB-INF"applicationContext-manager.xml</manager>
<servlet>WEB-INF"jbcc-servlet.xml</servlet>
<security>WEB-INF"applicationContext-acegi.xml</security>
<sqlMapConfig>WEB-INF"sql-map-config.xml</sqlMapConfig>
<messages>WEB-INF"classes"messages.properties</messages>
<tiles>WEB-INF"defs</tiles>
6) </web>
3.code-engine-gears.xml配置詳解:
<?xml version="1.0" encoding="UTF-8"?>
<gears>
<!--
Generate model, related sqlmap manager file via abator, in most case we don't need modify the abator-config.xml;
just add the following model node will work;
and this model node can create more than one; model name should be unique;
default extends is : biz.web.framework.domain.BaseEntity
-->
<model name="city_model" table="city" domain="City" usingLucene="false"
extends="biz.web.framework.domain.BaseEntity" keyProperty="id"/>
<!--
Create *Controller and *MgrController, modify layout component like Tiles of Sitemesh;
modify action-servlet.xml, applicationContext-*.xml
defaultMethods@keyProperty default to "id"
-->
<controller name="City" springBeanDef="true" template="controller.ftl">
<managers>CityMgr</managers>
<!--<services support="MailService"></services>-->
<defaultMethods refModel="city_model">
<method name="index" style="form" view="list_city"/>
<method name="listAll" style="ajax" />
<method name="list" style="ajax" />
<method name="get" style="ajax"/>
</defaultMethods>
</controller>
<!-- using the option [extends] to generated Mgr controller,
overwrite default to true;
method view default to
-->
<controller name="CityMgr" springBeanDef="true" template="controller_mgr.ftl"
extends="City" overwrite="true">
<!--<services support="CompassService"></services>-->
<defaultMethods refModel="city_model">
<method name="manager" style="form" view="list_mgr_city"/>
<method name="update" style="form" view="edit_city"/>
<method name="create" style="form" view="edit_city"/>
<method name="save" style="form" view="edit_city"/>
<method name="edit" style="form" view="edit_city"/>
<method name="delete" style="ajax"/>
</defaultMethods>
</controller>
<!-- overwrite default to true;
jsp name attribute used for jsp file name, and also used for tiles definition
-->
<jsp name="list_mgr_city" refController="CityMgr" template="list_mgr_jsp.ftl" overwrite="false">
<tiles>main_layout_4</tiles>
</jsp>
<jsp name="edit_city" refController="CityMgr" template="edit_jsp.ftl" overwrite="false">
<!--<tinyMCE>content</tinyMCE>-->
<!--<tiles>main_layout_4</tiles>-->
</jsp>
<!--<jsp name="detail_recommend" refController="City" template="detail_jsp.ftl" overwrite="false">-->
<!--<tinyMCE>content</tinyMCE>-->
<!--<tiles>main_layout_1</tiles>-->
<!--</jsp>-->
<!--overwrite default to true;-->
<!--<jsp name="list_city" refController="City" template="list_jsp.ftl" overwrite="false">-->
<!--<tiles>main_layout_2</tiles>-->
<!--</jsp>-->
</gears>
1)<model> <controller><jsp> 等節點用于生成domain,manager,controller和jsp,可配置0-n個;次序隨意; 且每個節點都有可選屬性 overwrite (true、false);
overwrite指定當目標controller文件存在時,是否要覆寫該文件,否則就生成.generated為后綴的文件;overwrite屬性是可選的,默認為true;
2)<controller name="CityMgr" springBeanDef="true" template="controller_mgr.ftl"
extends="City" overwrite="true">
<managers>CityMgr</managers>
<!--<services support="CompassService"></services>-->
<defaultMethods refModel="city_model">
<method name="manager" style="form" view="list_mgr_city"/>
<method name="update" style="form" view="edit_city"/>
<method name="create" style="form" view="edit_city"/>
<method name="save" style="form" view="edit_city"/>
<method name="edit" style="form" view="edit_city"/>
<method name="delete" style="ajax"/>
</defaultMethods>
</controller>
這個配置看上去有些復雜,是為了提供更好的靈活性;name用于在code engine中標識controller,同時用于生成的controller.java的命名;在配置文件中應該是唯一的;
springBeanDef用于指出是否在相關的配置文件中添加spring bean的定義,比如xxx-servlet.xml等;否則只是生成controller的java;
template指定freemarker模板;
managers指定要注入manager定義;如果有多個用逗號分割;可選;
services指定要注入service定義;如果有多個用逗號分割;@support用于指定framework下的common service,比如mail,compass等;可選;
defaultMethods里面用于指定生成的controller里面的方法;refModel 指參照的model定義, method@name用于指定方法名,比如list,而且list方法是預定義寫在模板里面的; method@style指定代碼風格,可選有form,ajax兩種;這個風格會同時影響cotroller部分和jsp部分;
method@view指方法返回的tiles定義視圖,當然這個屬性在style是form的時候有效;可選;
e) <jsp name="edit_user" refController="UserMgr" template="edit_jsp.ftl" >
<tinyMCE>Description</tinyMCE>
<tiles>main_layout_1</tiles>
</jsp>
Jsp的name用于生成的jsp頁面的文件名,同時還是tiles的定義,在生成controller時候也是有用的;
refController就是指明jsp所參照的controller定義;通過這個refController,jsp可以找到default_methods的style,refModel等信息;
Template指明所使用的freemarker模板;
這里省略了overwrite屬性,overwrite屬性是可選的,默認為true;
tinyMCE指定要加入tinyMCE支持,同時,所管理的屬性為‘Description’; 可選屬性;
tiles屬性定義了,此jsp所extend的layout,可選屬性;
f)
<model name="city_model" table="city" domain="City" usingLucene="false"
extends="biz.web.framework.domain.BaseEntity" keyProperty="id"/>
用于生成domain,manager,和sqlmap,可以配置多個;
luceneSupport可選,如為true代表將在domain和manager以及配置文件中加入lucene的支持;
4.創建新項目
A.從codeEngineRunner開始執行createNewProject(“distProject”);(將copy必需的框架文件到目標目錄,同時修改jdbc.properties等文件,同時將初始化abator-config.xml;)
B.分別用到了JDBCPropertiesModifier和CodeEngineInitModifier;
C.執行目標工程project目錄下的initdb.bat;初始化數據庫,加載初始系統表和數據;當然執行此步驟之前要先創建數據庫;
D.利用codeEngineRunner的從數據庫表,生成相應的文件后,使用project目錄下build.bat編譯文件;
1. 方案:
a) Load balancer +reverse proxy server + server cluster;
圖一是整體的結構圖;思路很清楚;這種的結構的網站系統可以提高系統的響應能力;
圖一
b)細節問題:
i)web server 是否可以是非同質的server,比如有的負責mail,有的負責web頁面,
有的負責文件上傳;
ii)用戶的session信息如何在不同的server之間同步;
iii)如果使用數據庫集群的話,則有的dbserver只負責讀數據,有的則讀寫都做;
如何實現;Replaication 在mysql中的支持正在研究;
c)加入reverse proxy server; 圖二顯示了如何在架構中加入reverse proxy server;
這里選擇的proxy server是squid (http://www.squid-cache.org),(至于為什么選它,
因為很多人都用它;本人奉行拿來主義);squid用來cache靜態的文件,js,image,
css等;squid可以和tomcat,apache等集成;
圖二
d)誰來做load balancer呢,如果你使用linux操作系統的話,那么一定要試試Linux Virtual Server(www.linuxvirtualserver.org/ http://zh.linuxvirtualserver.org/ ), 我國的章文嵩博士主持的開源項目,TelTel的首席科學家;
IBM 的介紹資料:
http://www-128.ibm.com/developerworks/cn/linux/cluster/lvs/part1/index.html
http://www-128.ibm.com/developerworks/cn/linux/cluster/lvs/part2/index.html
http://www-128.ibm.com/developerworks/cn/linux/cluster/lvs/part3/index.html
http://www-128.ibm.com/developerworks/cn/linux/cluster/lvs/part4/index.html
圖三
不光要考慮開發的簡單,還要考慮日后的升級;
甚至足夠充分的文檔資料支持;還有現有團隊的技術能力;以及項目時間等;
MVC:第一要素我個人覺得是要簡單,因為在這個部分的中的代碼量,通常相對后端是很多的;一個容易上手,并且大家都熟悉并且不討厭;
SpringMVC,我個人覺得是很完備的mvc,有著很強的靈活性,但正是這種靈活性,讓很多人無所適從;
Struts 1 標簽很糟糕;form對象很別扭,繁瑣的配置;
Struts2 沒有用過,如果他還有form我就不打算用;
學習springside(以前)使用Spring 的MultiActionController,減少了很多沒有必要的配置;在一個controller里面可以寫多個Action;MultiActionController還可以很靈活的從request中綁定Domain對象,非常的方便;
MultiActionController 加 Controller可以滿足全部的需要;
JSP部分使用spring form tag;
Tiles 和 sitemesh; 考慮到使用Ajax,而sitemesh是利用filter來修飾;選擇Tiles;
ORM用ibatis,當前最實用,簡單的ORM;而且可以自動生成,又容易理解;何樂而不為;
FullTextSearch: compass + lucene;
Others:ActiveMQ + ApacheCXF
Form/Ajax Request > Controller > Manager/Service > GenericDao
其他輔助工具:
EMS for mysql;
SVN as version control;
DB/web server:mysql/resin
關于速度問題;
我想在大多數情況下,我們不是在get
all,如果只是java, jsp,
xml等的話,還是可以忍受的;同時更新幾個文件大約1分鐘左右(我在公司測的);
如果get
all的話,可以選擇一個空閑的時間去得,或者由某個人得一下,想辦法減少重復工作;
或者大家有沒有什么好建議? :)
最新進展: http://www.coollittlethings.com/svn/wiczone/
私有的,免費的,快的;
步驟:1.注冊和激活;
2.訪問http://svn.coollittlethings.com/project_detail.php?name=wiczone
申請加入此項目;
3.通知我把申請者加入,即可;
做網站最難的是定位。
當定好位,剩下的事情再苦再難對站長來說也是快樂。
當一個人有做事的信心和能力,卻不知道要做什么時是最痛苦的。
當一個劍客找不到人PK的時候是最孤獨的。
當一個站長無法確定一個網站定位的時候是最彷徨的。
站長失敗的兩大原因: 1 定位錯誤 2 缺乏堅持
有一個經常被引用的故事:
一個人挖井,10年先后挖了10眼井,沒有一眼挖出水來。有好多眼井,在快要挖出水的時候,他動搖了,放棄了,他認為里永遠不會挖出水,于是又去開挖一眼新井,就這樣10年過去了...
另一個人,一眼井堅持挖了10年,終于挖出了如泉水般的、清冽甘甜的井水,
他成功了!
上面的故事被很多成功者引用,以證明堅持的重要性。
但問題是,如果這個地方真的挖不出水呢?或者你根本不可能堅持到挖出水的那天,你為什么不去尋找一個地下蘊涵著豐富水資源的地方呢?
還有,當你終于選擇了一個水位非常高、水質非常好的地方,但別人,那些更具實力的挖井大戶也看中了這個地方,在你的旁邊以比你更快的速度打了一眼深井,你怎么辦?
所以剛剛起步的網絡創業者,你第一要定好位。第二要確定這是大網站顧及不到的地方。你要確定你不僅能率先在這里打出水,而且能牢牢占據這個地方!
你看好在線點播、看好B2B、C2B、B2C,但你看到排成長隊、腰纏萬貫、虎視耽耽的那些人了嗎?你冷靜的想一下你能擠進去嗎?以為有千八百萬很了不起嗎,但有人可以上億燒錢,你和他玩,玩的起嗎?強者和強者最后的競爭是實力的競爭、是資本的較量。
我們要玩的是弱者和強者的游戲,是用弱者之強對強者之弱。強中有弱,弱中有強,這是顛仆不破的真理!強能轉為弱,弱能化為強,這是永恒的運動規律!這些暫且不提,再回到網站的定位上。
網絡創業者的定位是否正確,基本上就決定了他的事業能否得到長遠發展。
網絡創業的機會還非常非常多,關鍵是有沒有抓住這些機會的眼光!
還是用打井做比喻,你可以聘請專業的勘探隊伍幫你尋找最佳位置。你還可以接著別人半途而廢的井繼續挖,但關鍵還是眼光要好,眼光好則定位準確,定位準確,網站發展會形成良性循環,所有的努力都將促進網站的快速發展。定位不準確,則事倍功半,最后徒勞無功。
一開始的定位很小,小可以變成大,
一開始的定位很大,大可能變成小。
所以我覺得特色很重要,而且不易模仿的特色其實才能算是真正的特色,因為在中國很多好東西,從一開始就是在模仿;模仿就是在學習別人的定位,而非自己的,只有自己設立的目標或特色,在長時間的努力堅持后,才形成自己真正的特色;才是網站長久發展的根本;
Selenium
是一個由ThoughtWorks做的專門為web應用所做的非常有效的功能測試工具。Selenium
的 tests
直接在瀏覽器里跑,就像用戶真的在操作一樣。Selenium
可運行 Windows, Linux, 和 Macintosh
的各種瀏覽器, 如
Internet Explorer, Mozilla 和 Firefox。
.......
訪問鏈接:
http://forum.springside.org.cn/viewthread.php?tid=195&extra=page%3D1
之前一直以為我們搞定了中文,所以一直沒有懷疑我們的配置,今天和立國發現一個問題:
就是用ajax的方式去創建一個記錄,然后用jsp的方式去取數據,出現亂碼;
但是用ajax的方式取此記錄,正常;
后來發現,我們提交數據的方式,不管是ajax的,還是form表單提交,所使用的編碼通通沒有指定!!,雖然我們在頁面上加上了<%@
page contentType="text/html;charset=UTF-8" language="java"
%>,但這一句主要是負責response的數據顯示;
查了資料后才發現需要加上:<%@
page pageEncoding="utf-8"
%>;
而之前我們都沒有指定request的charset,所以按照servlet標準,大多數web
server(Resin,Tomcat)默認按照iso-8859-1來處理,而我們的數據庫是utf-8的,所以放到數據庫中的數據并不是utf-8的;所以用jsp顯示時候出錯;但用ajax的方式為什么沒出錯,還沒有搞明白;
解決方案:
1.ajax方式
#1:prototype.js
[line707]contentType:
'application/x-www-form-urlencoded;charset=UTF-8',
#2:BaseController
[line135] response.setCharacterEncoding("UTF-8");
以上兩行保證了ajax請求和相應的方式一致,并都是utf8;
2.form表單方式;
#3:在jsp加上:<%@ page
pageEncoding="utf-8" %>;
#4:和<%@ page
contentType="text/html;charset=utf-8" language="java"
%>
3.我在web。xml中加了一個encodefilter,保證了當請求中沒有指定charset的時候,使用utf-8方式,所以以上#1和#3處的指定charset是可選的!!
請大家注意更新以上3個文件;prototype.js,BaseController
.java, web.xml
同意以上所述,更新3個文件:prototype.js,
BaseController.java, web.xml ,頂。
我發現直接按照以上的配置resin還有問題,就是無法加載applicationContext_manager.xml;
我費了很大勁才搞明白,是resin用自己的xmlparser所以不識別spring2.0的xml
schema 配置;已經找到解決辦法:
1.將<web-app id="/wiczone"
document-directory="你自己的wiczone war
目錄G:/IdeaProjects/wiczone/trunk/wiczone/war"/> 改為:
<web-app id="/wiczone"
document-directory="D:/wiczone/trunk/wiczone/war">
<!-- xml -->
<system-property
javax.xml.parsers.DocumentBuilderFactory=
"org.apache.xerces.jaxp.DocumentBuilderFactoryImpl"/>
<system-property javax.xml.parsers.SAXParserFactory=
"org.apache.xerces.jaxp.SAXParserFactoryImpl"/>
<!-- xslt -->
<system-property
javax.xml.transform.TransformerFactory=
"org.apache.xalan.processor.TransformerFactoryImpl"/>
</web-app>;
2.得最新web-inf\lib下的jar包;多加了一個xml解析器;
另外,\trunk\web
server\resin下面有resin服務器,和resin配置文件;