<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Arthur Hsu&#039;s Blogz &#187; 軟體工程</title>
	<atom:link href="http://www.cchsu.com/arthur/category/software-engineering/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.cchsu.com/arthur</link>
	<description>隨便寫寫大家隨便看看的不出名小格子</description>
	<lastBuildDate>Tue, 03 Jan 2012 21:13:19 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>虎瀾集: Enterprise Service Bus 的演化之路</title>
		<link>http://www.cchsu.com/arthur/2008/11/15/208/</link>
		<comments>http://www.cchsu.com/arthur/2008/11/15/208/#comments</comments>
		<pubDate>Sat, 15 Nov 2008 08:51:01 +0000</pubDate>
		<dc:creator>arthur</dc:creator>
				<category><![CDATA[技術文章]]></category>
		<category><![CDATA[無責任評論]]></category>
		<category><![CDATA[軟體工程]]></category>

		<guid isPermaLink="false">http://www.cchsu.com/arthur/?p=208</guid>
		<description><![CDATA[在某窩上有鳥友問到 ESB 這個東西，剛好最近比較閒可以來講點訐古，大家就湊和著看看吧。故事是從一家小不拉幾的銀行開始的，我們姑且就稱它為斯摩銀行好了。斯摩銀行小本經營，分行只開了 8 個，台幣系統這種大傢伙當然還是乖乖的去交 IBM 稅吧，沒人會因為用了 IBM 而被炒魷魚的。最近景氣不好，個金的貸款逾期的很多。直接包給外面的催收公司嘛，他們的趴數要的實在有點高，而且據說對企業形象不好。所以呢，摳門的老闆想要自己弄個催收的功能，每個行員每天撥一個小時的時間去打電話，但是 IBM 催收模組好貴，那就試試看 PC-based 的催收系統好了。 催收系統是很簡單的系統，資料從台幣主機撈下來，秀在行員的螢幕上讓他們去打電話，行員記一下通話摘要，系統要自動 follow 客戶有沒有履行承諾，沒有的話要做一些必要的措施。夠簡單了吧? 不過是個簡單的資料庫加上流程處理，還有一點 UI，這很久以前就有人做，用 client-server 就可以解決了，後台跑資料庫，流程處理切開，一半在資料庫跑批次，一半在前台 VB 寫的軟體中內建流程，一塊小蛋糕沒什麼大學問的。 解法好像可行，它的成本夠低嗎? 讓我們來想一想。資料庫軟體是按 seat 來收錢的 (呃，至少我那個美好的年代是如此)，八個分行加總行至少 100 個 user，這個 license 好貴啊。VB 軟體要灌在 100 台電腦上，雖然說可以拗廠商來裝機，但是裝機的時候行員一定去打茫的，隱性人事成本很高。如果軟體有 bug，全部 100 台都得 patch 過，又是個打茫的好藉口，對摳門的斯摩銀行老闆而言，這似乎不是什麼高明的主意。另外要是資料不小心給他有點多，好像現有的網路流量不夠用要再想辦法升級，這又是一筆開銷啊。 所以聰明的廠商想出了一個好辦法: multi-tier 架構，名字聴起來夠威，應該是不錯的。我們架個中介軟體，把所有資料存取集中，所以資料庫 license 可以買便宜一點的。架個網站，把前台的程式做成網頁，所以行員只要知道網址，直接用瀏覽器就可以開始工作了，不必裝機，不讓他們有打茫的藉口。最後想辦法把工作流程通通集中放到 application server 上，再把 app server、web server 和 DB server 通通串好，搞定收工走路有風。 [...]]]></description>
		<wfw:commentRss>http://www.cchsu.com/arthur/2008/11/15/208/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>虎瀾集: 今夜您要選擇什麼?</title>
		<link>http://www.cchsu.com/arthur/2008/08/08/160/</link>
		<comments>http://www.cchsu.com/arthur/2008/08/08/160/#comments</comments>
		<pubDate>Fri, 08 Aug 2008 21:36:09 +0000</pubDate>
		<dc:creator>arthur</dc:creator>
				<category><![CDATA[技術文章]]></category>
		<category><![CDATA[無責任評論]]></category>
		<category><![CDATA[軟體工程]]></category>

		<guid isPermaLink="false">http://www.cchsu.com/arthur/?p=160</guid>
		<description><![CDATA[線上遇到學弟，他現在正為要選哪種方案來做他的專案很苦惱。其實這問題說難也不難，因為答案很清楚，出來賺錢嘛，選擇獲利最高 (通常也等同於成本最低) 的開發方式就對了，真正麻煩的是怎麼去算獲利。 以我學弟的例子而言，他的狀況是客戶開預算案，他們公司承包，這種最好算: &#160;&#160;&#160;&#160;獲利 = 工程款 &#8211; 開發成本 &#8211; 維護成本 &#8211; 固定成本 算這種東西的時候，工時是最多專案經理拿來算成本的工具，不過呢，它只代表小小的一部份成本而已。如果今天做的東西驗收不過的話，工時少只代表虧的少，所以選擇的第一要件就是要確保你可以用它做出你想要的東西。以他的情況來講，大部份的 team member 只會 Java 和 PHP，所以在程式語言上，他沒什麼選擇，若是 Java 加上 PHP 都做不出他要的東西，那最好的選擇就是閃人先。 接下來是平台，平台直接影響固定成本，所以很多老闆看見你用微軟的方案會直接否決，因為帳面上這些是要付錢的。不過呢，若這個平台可以幫助你減少開發成本和維護成本，那最好還是精算一下再決定比較好。以我學弟的情形，他的客戶的 SA 熟 Windows 和 Solaris，不過他的團隊除了他之外沒人碰過 Solaris，這種情形下很容易可以算出來用 Windows 的成本會比較低些，因為可以買比較便宜一點的 x86 伺服器，而且不必付出讓團隊去熟悉 Solaris 的工時成本。兩個最主要的東西決定下來，CM (Configuration Management) 的主軸也就定了，接下來就是用需求訪談得來的情報去擬定整個 project 的 execution plan，那就是他自己的事了哇哈哈 &#8230; 對了，為什麼不用 Linux 呢? Linux 和 Solaris 的差異不至於大到太誇張啊? 這是好問題，去問你客戶的 SA 要不要幫 [...]]]></description>
		<wfw:commentRss>http://www.cchsu.com/arthur/2008/08/08/160/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>虎瀾集: 為什麼同步很重要</title>
		<link>http://www.cchsu.com/arthur/2008/07/27/151/</link>
		<comments>http://www.cchsu.com/arthur/2008/07/27/151/#comments</comments>
		<pubDate>Sun, 27 Jul 2008 19:36:47 +0000</pubDate>
		<dc:creator>arthur</dc:creator>
				<category><![CDATA[無責任評論]]></category>
		<category><![CDATA[軟體工程]]></category>

		<guid isPermaLink="false">http://www.cchsu.com/arthur/?p=151</guid>
		<description><![CDATA[在約爾大神的文章裡，他老兄把微軟的那票 architect (架構設計師? 104 翻的不是我啊 &#8230;) 好好地損了一下，幫他們取了個響亮的綽號：architect astronaut (架構太空人設計師)，順便也好好地損了一下同步 (synchronization) 這個概念。好吧，這裡就有點怪怪的了，微軟並不是唯一押寶在同步上的笨蛋，如果「同步」這個概念不賺錢，為什麼有這麼多攀子要燒錢? 我個人的看法是，「同步檔案」這玩意兒當然不賺錢，它只是一個大布局的基礎棋子罷了，這個布局是為了簡化資訊共享和協力工作的難度。就像下棋吧，直砍直殺未必是好，有時得要繞個彎設個套才能贏。今天的手機了不起只有 VGA 解析度，當然搞不出什麼大風大浪來，但若等到手機都是 XGA 傳輸速度都很猛時才要進場，那就只能揀別人吃剩的了。 其實「同步」這個詞並不精確，它其實就是最近很夯的「雲端運算」的一種附加功能而已。因為資訊都存在網路上，也都在網路上分享操作，當然它會是同步的。好吧，雲端運算是不是又是那票太空人弄出來唬弄普羅大眾的呢? 我個人認為他們還不至於這麼閒。就像約爾問的: 誰會需要同步檔案? 如果這只是一個包套方案中的某一點小小的附加功能，我想也不會有人拒絕使用才對。]]></description>
		<wfw:commentRss>http://www.cchsu.com/arthur/2008/07/27/151/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>效能調校</title>
		<link>http://www.cchsu.com/arthur/2008/01/27/141/</link>
		<comments>http://www.cchsu.com/arthur/2008/01/27/141/#comments</comments>
		<pubDate>Sun, 27 Jan 2008 08:19:26 +0000</pubDate>
		<dc:creator>arthur</dc:creator>
				<category><![CDATA[技術文章]]></category>
		<category><![CDATA[無責任評論]]></category>
		<category><![CDATA[狀況排解]]></category>
		<category><![CDATA[軟體工程]]></category>

		<guid isPermaLink="false">http://www.cchsu.com/arthur/2008/01/27/141/</guid>
		<description><![CDATA[搞軟體的常常遇到的問題就是，程式寫好之後，客戶嫌它跑的慢，所以不爽付錢。爽，是一件很重要的事情，所以師程工多半都會被要求無論如何要調到客戶爽為止。不過說真的，效能調校是件很有趣的事情，小弟來分享一些曾遇過的趣事好了。 關於時間方面的效能調校大致上可以分成兩種：縮短執行的時間，或是縮短等待的時間。前者多半出現在後台用的程式，例如小弟以前做過的某個銀行專案，一個批次跑下來要十九個半小時，基本上這等於叫客戶不要開門做生意 經過一個多月的調教校，批次執行時間變成十九分鐘。這麼歡樂的情形也許不常見，不過我倒是從中學到不少有趣的東西： 資料庫的 table design 非常重要，我所做過大部份的專案都是以客戶現有的資料結構下去設計，但客戶的資料結構往往不符合效能最佳化的需求。在一開始設計時就應找出最常用或最關鍵的 query path，針對這個 path 下去設計才對。 Stored procedure 的設計必須把握「先細篩後粗篩」的原則，cursor 指向的 data set 越小，跑起來越快。像上面的例子中，我只是把兩個 select 的順序換一下，時間就從十九個半小時變成六小時。 注意一下 team member 的實際能力，雖然這有些傷感情或 micro-management 的嫌疑，不過卻太常見了。一個很有效的鑑別方式是和你的隊友聊天，看看他打算用什麼方法解決問題，若是沒有方法，或是方法的執行上實在不怎麼樣，那就該想想 plan B 了。 擴充性迷思：客戶通常會要求高於他們業務量所需的規格以備未來的擴充，或是要求要有種種神奇的擴充能力。如何委婉的讓他們知道有多少錢玩多大的車是很重要的事情，很多時候系統只打算用五年卻做了十年的規劃，這樣做起來累驗收也累，爽的只有 sales。 注意客戶的真實需求：很多時候程式跑的慢並不是技術上有問題，而是管理面或協調面上出紕漏。比方說奧客亂拗碰上軟腳 sales PM，或是客戶自己都搞不清楚自己要什麼，或是客戶自己山頭林立一人一把號各吹各的調。這種情形下除了等五年後摩爾定律打敗客戶需求之外，找個很會喬夠力喬的高層才是明智之舉。 很多學校都灌輸「演算法改進會優於程式本身改進」這個概念，不過呢，請務必確認您的隊友都了解這個原則是基於「程式本身已經寫的很好」的假設。我看過不少同行花好多好多的時間想要去生出一個更好更棒的演算法，卻沒有去檢查原有程式的品質。爛程式可以很有效地搞砸好的演算法！ 如果 team 很大，程式慢就幾乎是必然的，因為程式往往會遷就組織架構而做許多不必要的取捨，例如過度模組化或不必要的流程。這時候通常我們會需要一點來自上層的助力和自己的勇氣才行。 縮短等待時間一般牽扯到的問題反而都不是技術面的，除非一開始設計就很爛，或是很幸運的遇到網路基礎架構很爛的客戶，不然很少會需要什麼技術面的調整。大部份的調整都是屬於心理層面的，所謂 perceptual performance 的東西。比方說，跑一個報表產生的程式，50 頁用了 5 分鐘，客人嫌太慢等很久，放了一個 dialog 上面跑個 progress bar 外加一堆文字閃來閃去顯示報表產生的步驟和進度，50 頁共用了 7 分鐘，客人反而很滿意覺得程式很讚跑的很快 訣竅很簡單：UI 有在動不會卡住，客人的爽度一般而言比較高。 [...]]]></description>
		<wfw:commentRss>http://www.cchsu.com/arthur/2008/01/27/141/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Service Oriented Architecture</title>
		<link>http://www.cchsu.com/arthur/2007/04/03/129/</link>
		<comments>http://www.cchsu.com/arthur/2007/04/03/129/#comments</comments>
		<pubDate>Tue, 03 Apr 2007 06:32:30 +0000</pubDate>
		<dc:creator>arthur</dc:creator>
				<category><![CDATA[軟體工程]]></category>

		<guid isPermaLink="false">http://www.cchsu.com/arthur/2007/04/03/129/</guid>
		<description><![CDATA[乃特大有一篇 SOA 的觀念問題，難得正經地寫一下 comment，就把我寫的 comment co 回家留底了 &#8230; ccc &#8230; SOA 小弟認為不應該當成軟體工程的 concept 來看，而應該當成 business model 的 concept。傳統上開門要賺錢，首先要能找出獲利模式，確定獲利模式之後，就必須根據公司的獲利模式來建構 supporting infrastructure。 傳統傳統有夠傳統的 supporting infrastructure 又可稱為強百樂架構，公司要喝牛奶就得養頭牛，要喝羊奶就得養頭羊。問題是負責養這些東西的費用太可觀了，如果今天可以把這些 infrastructure componentize 之後由專業公司代包，只要成本較自己做低，功能不要太遜，那就是很好的東西。 換到 IT 的角度來講，大部份公司的 IT infrastructure 也只是 supporting infrastructure，若能從這個角度出發，把它整個 componentize 後包出去，成本應該是可以降低，而且也是很好的商業模式。這東西個人認為遠在 requirement 之前，因為它是用來 generate requirement 的。 *** 以下是沒有寫出來的謎之聲 *** &#60;謎之聲&#62; 商業流程 componentize 的先決條件是要有人可以真的搞清楚這些流程的全貌和細項，對於大部份的企業來說，這是天方夜譚，不然 requirement analysis 也不成為一門可以出書的學問了 &#8230; &#60;/謎之聲&#62;]]></description>
		<wfw:commentRss>http://www.cchsu.com/arthur/2007/04/03/129/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>這才叫駭客</title>
		<link>http://www.cchsu.com/arthur/2006/09/21/117/</link>
		<comments>http://www.cchsu.com/arthur/2006/09/21/117/#comments</comments>
		<pubDate>Thu, 21 Sep 2006 06:36:46 +0000</pubDate>
		<dc:creator>arthur</dc:creator>
				<category><![CDATA[軟體工程]]></category>

		<guid isPermaLink="false">http://www.cchsu.com/arthur/2006/09/21/117/</guid>
		<description><![CDATA[剛才在 Wired blog 上看到一篇文章，大意是這樣的：在美國維吉尼亞州發生了一件竊盜案件，嫌犯從網路上獲取商店中 ATM 提款機的操作手冊，他老兄便到某加油站的提款機去，從鍵盤輸入特別操作碼以及預設密碼，進入該 ATM 的管理模式。美國的 ATM 提款機一般都是提供 20 元美鈔供客人提領，接下來，嫌犯將該 ATM 給鈔盒設定其存鈔面額為 5 元，然後利用預付信用卡提領現鈔，機器吐的張數是以 5 元來計數，但實際吐的是 20 元的鈔票，於是嫌犯當場海噱一頓揚長而去。 這件事本來可以做的很漂亮的，但嫌犯忘了將機器設定回去。於是機器就繼續努力地發鈔，直到有一天終於有個誠實的人向加油站舉報，這整件事才被爆破出來。(謎之聲：可見那台提款機還真的是很少人用 &#8230;) 這個事件可以說是個典型的軟體工程負面教材，隨便都可以列出許多缺失： 進入管理模式除密碼之外，應該要有第二道防線，例如 POS 系統常用的鑰匙，或是刷卡機 設定存鈔面額後，應偵測給鈔盒是否有開啟過再讓變更生效 進入管理模式時應連線到控制中心進行記錄 (ATM 不可能沒有網路連線)，要不然也該閃個警示燈讓店員知道吧 機器出廠後，第一次使用時應強制更改密碼 (提款卡不就是這樣的？) 機密的使用手冊未經控管直接在網路上流傳 這些都可以由簡易的 STRIDE 分析找出對應的防制措施才對，可見當初設計時根本沒做 (或是不知道要做)。現在就等等看其他國家的提款機什麼時候會傳出災情吧]]></description>
		<wfw:commentRss>http://www.cchsu.com/arthur/2006/09/21/117/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>人機介面</title>
		<link>http://www.cchsu.com/arthur/2005/06/23/89/</link>
		<comments>http://www.cchsu.com/arthur/2005/06/23/89/#comments</comments>
		<pubDate>Thu, 23 Jun 2005 21:46:00 +0000</pubDate>
		<dc:creator>arthur</dc:creator>
				<category><![CDATA[無責任評論]]></category>
		<category><![CDATA[軟體工程]]></category>

		<guid isPermaLink="false">http://www.cchsu.com/arthur/?p=89</guid>
		<description><![CDATA[根據 MacWorld 的報導，Sony 新任大老闆在股東會上透露他與英國女王伊莉莎白二世會餐時得到的消息，女王覺得 Sony 的東西太過複雜很難用，她老人家現在是 iPod 的愛用者，正享受著 Apple 當世無雙的防呆介面。 這讓我想起當初去敗的那台 iRiver MP3。拿到機器時很興奮，學了一陣子用的很開心，後來老婆大人拿去玩，一個月後我拿回來想錄音時，我已完全忘記要如何操作了。 這件事告訴我們任何人機介面最好都遵守 KISS 原則：Keep It Simple &#38; Stupid。]]></description>
		<wfw:commentRss>http://www.cchsu.com/arthur/2005/06/23/89/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>與客戶接觸</title>
		<link>http://www.cchsu.com/arthur/2005/01/11/61/</link>
		<comments>http://www.cchsu.com/arthur/2005/01/11/61/#comments</comments>
		<pubDate>Tue, 11 Jan 2005 20:23:00 +0000</pubDate>
		<dc:creator>arthur</dc:creator>
				<category><![CDATA[軟體工程]]></category>

		<guid isPermaLink="false">http://www.cchsu.com/arthur/?p=61</guid>
		<description><![CDATA[最近被業務員弄的有些小煩。他們看到條大魚，於是便照慣例地進入了興奮模式，但我卻是那個叫人冷靜點的壞人，於是我又做了個比喻 (在心裡做沒跟他們說 :p) 與客戶接觸就像在舞會上把妹，第一次開會就好比是邀舞。有人會在第一次邀舞時就說：「嗨辣妹，晚上要和帥哥我上床嗎？」嗯，若你是 007 「真是棒」(James Bond) 的話這應該不是問題，辣妹哈你哈好久了肯定會自動倒貼上來。不過一般的流程應該是先邀舞，聊個小天，讓她看上你，多哈啦兩句，自強活動帶開 (看是到她家你家還是賓館)，親親嘴調調情最後才上床，總之都不是一個步驟一句話可以搞定的事情。 有趣的是，許多業務第一次見客戶的時候老是急著問這種「上床」的問題，更有甚者，連見都沒見到就已經在想「床上雄風」的問題了。 所以呢，下次你的業務員要是又很興奮亂吹牛的時候，先檢查看看他們領帶打了沒，鞋子擦了沒、西裝燙了沒。要是什麼都沒做，大概又是摃龜的下場，你不妨省下為他們準備花束的時間，改準備垃圾桶、啤酒和南方四賤客的錄影帶，他們會用的著的。]]></description>
		<wfw:commentRss>http://www.cchsu.com/arthur/2005/01/11/61/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>對軟體專案的形容</title>
		<link>http://www.cchsu.com/arthur/2005/01/05/62/</link>
		<comments>http://www.cchsu.com/arthur/2005/01/05/62/#comments</comments>
		<pubDate>Wed, 05 Jan 2005 17:26:00 +0000</pubDate>
		<dc:creator>arthur</dc:creator>
				<category><![CDATA[軟體工程]]></category>

		<guid isPermaLink="false">http://www.cchsu.com/arthur/?p=62</guid>
		<description><![CDATA[最近和鄰居吃飯，他們夫婦都是藥師，我試著用一個比喻向他們解釋為何寫一個大的軟體是很困難的事情，以下是我說的比喻。 做一套很大的軟體，就好像在一塊像道奇棒球場那麼大的畫布上做畫。你只有三個月的時間，五個畫家，而且不可能有詳細的藍圖。為何不可能？因為你畫的畫要不就是為某人量身訂做的 (如某個有錢大闊佬要你把他肥胖臃腫噁心的尊容畫成玉樹臨風少女殺手級的肖像)，要不就是得畫一張公開展示的作品，在掛出來的那一天才能知道大眾對它的評語是「哇！」還是「去～～」 也許有人會說三個月太誇張了，通常不是都有長一點的時間嗎？別忘了，師程工必須花至少三個月的時間等待英明的上級定出方向，用比較專業的詞來形容的話這就叫「策略規畫」。某些廢柴花了九個月的時間做「規畫」，接下來還很寬容地留下三個月的時間讓師程工們寫程式、測試加包裝。嘿，您瞧，產品週期一年，不賴嘛 &#8230; Ok 冷靜冷靜，趕快拉回比喻裡。為了要讓這幅畫看起來對勁，這五個畫家就必須達成某種程度上的和諧，如此一來當觀眾看到這幅畫時他們才知道這是「一」幅畫而不是五幅。當然，五個畫家也必須對整體畫面的結構心裡有個底，畫出來的作品才能看。 現在有三個大問題來了。 問題一：某些畫家根本不配稱為畫家，他們除了吃喝玩樂吹牛拍馬在行之外，本職學能一塌糊塗，這種人來畫簡直是個災難。 問題二：天才畫家不爽遵守規則，要知道他們的座右銘 &#8212; 規則就是用來打破的。 *問題三：(這問題太黯然太銷魂了所以必須打個星號以示對星爺的尊重) 除了畫家之外，還有一群專職「管理」這五個畫家的經理。為了維持人類社會的安定，每三個畫家至少要配兩個或兩個以上的經理才行。眾所周知的是，「為了這幅畫好」，這些經理對於畫裡頭的光線明暗、線條顏色這些東西是非常挑剔的，畫家們最好乖乖地聽從經理的意見來畫，否則就等著被炒魷魚吧！然後呢，經理們的強烈意見可能是來自專業的眼光，也可能只是胡搞瞎掰政治至上的和稀泥。但是，若有一位英明神武的大老闆發現這幅畫的某一塊地方的光線明暗或線條顏色不對，我敢向您打包票九成九九的機會是畫這個部份的畫家被開除，不管這是不是他的錯。 在聽完這個比喻之後，我的鄰居們深深地體會到原來藥局是個十分良好的工作場所，他們也非常地慶幸他們當初沒有填錯志願選擇軟體產業。]]></description>
		<wfw:commentRss>http://www.cchsu.com/arthur/2005/01/05/62/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>&#8220;User Interface Design for Programmers&#8221; 讀後感</title>
		<link>http://www.cchsu.com/arthur/2004/09/22/33/</link>
		<comments>http://www.cchsu.com/arthur/2004/09/22/33/#comments</comments>
		<pubDate>Wed, 22 Sep 2004 19:27:00 +0000</pubDate>
		<dc:creator>arthur</dc:creator>
				<category><![CDATA[無責任評論]]></category>
		<category><![CDATA[軟體工程]]></category>

		<guid isPermaLink="false">http://www.cchsu.com/arthur/?p=33</guid>
		<description><![CDATA[最近將 Joel Spolsky 的新書 User Interface Design for Programmers 看完了，很有趣的一本書，但價錢實在貴了點。我搞不懂他老兄為何要將書印成全彩的，事實上大部份的內容只需要黑白印刷便可搞定，而且黑白印刷也較為便宜。 這本書的內容重點如下： user 不會去讀使用手冊，也不會讀你寫的 dialog box user 不會用滑鼠，或者說，沒辦法像你一像精準地控制滑鼠 user 並不笨，術業有專攻，你必須把 UI 寫的直覺好用 寫給 user 看的東西，冗長優雅的文章是廢物，他們要的是簡單而且一目瞭然的東西 想像使用者會如何用，不如把你的設計畫成 mock up，到路邊去找五個路人來看看還比較快]]></description>
		<wfw:commentRss>http://www.cchsu.com/arthur/2004/09/22/33/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

