哇寶部落格 » 工作雜談

關於測試這件事

jaceju — Fri, 14 May 2010 10:37:43 +0000

為什麼要測試？

因為我們沒辦法保證程式碼是萬無一失的，所以通常我們都會需要驗證我們的程式，而測試就是其中一種方法。很多工程師都在寫完程式之後，自己手動去做測試；如果執行結果是按照自己的想法出現後，那麼他們通常就認為程式沒錯了。

可是，其實這樣的程式碼通常就會躲進很多很多的 Bug 。所以我們要讓程式碼自己告訴我們它沒問題，而不是我們自己去想像它沒問題。

當然測試並不是萬靈丹，它只是去驗證我們所考慮到的狀況；但如果抱持著「既然我都有考慮到，而且也寫在程式碼裡，那這樣就不用測試了呀！」的態度，那其實也是災難的根源。因為如果我們沒有寫測試來驗證程式碼的話，那我們的防範措施根本就不值得信賴！

所以不是手動測試過沒問題，下次就不會再發生了；而是要拿出保證來才值得相信，而測試就是我們的保證。

如何確保系統照著規格實作？

符合客戶所要求的規格，就是我們實作系統的最終目標。有些規格是流程的控制，有些規格是資料的處理；但這些如果沒有一套好的檢驗機制來協助我們確認這些規格的話，我們就沒辦法有百分之百的信心告訴客戶說，我們的程式完成了你們的需求。

自動化測試就是一個方便的檢驗機制，而測試案例就是客戶的規格。當我們的程式按通過測試後，我們也就可以放心把這些程式碼用在實際的開發中；如果這時還發現執行的結果有問題的話，通常就就可以判斷是實際開發的程式碼中出現了錯誤。

當然有些工程師會認為：為什麼我要把同樣的程式碼在測試案例和實作運作的系統中各寫一遍？其實這是錯誤的觀念。

測試案例分成兩種：一種是在程式正常運作下的案例，它們能明確告訴我們程式的使用方式，也就是客戶要求的規格；一種是設想到可能會讓程式出現問題的案例，它們考驗著身為工程師應該去設想到的錯誤處理機制。

當客戶新增或修改了規格時，那麼我們的測試案例就要跟著調整。而沒有調整的部份，我們就能透過現有的測試案例來確保舊有程式按照舊的規格執行，確保我們的程式沒有因為新增或修改的功能而出現預料之外的錯誤。

怎麼寫出好測試？

好的測試案例依賴著工程師的經驗，經驗越豐富的工程師，就能預想到各種可能發生的狀況，並寫出因應的測試案例。不過有經驗的工程師畢竟是少數，所以大多數時候我們還是要按步就班，從我們能做得到的部份做起。

一開始我們可以先對正常的流程編寫測試；而在程式通過正常測試之後，我們再針對有可能造成我們程式誤動作的狀況去加入異常的測試。有時候 Bug 可能是因為操作流程錯誤而產生，那麼就要在流程中的每個關卡做好程序的把關。

例如某些關卡要有防呆機制，某些關卡不能重覆執行，我們就必須去防止等等。測試之所以要強調自動化，就是讓我們不用把時間花在手動去模擬使用者操作的過程；而且我們可以透過對調測試案例裡的每個觸發條件的執行順序來產生不同的測試方式，以找出可能潛藏的流程問題。

有時候我們的系統可能會有多個使用者同時在操作，如何讓獨立性的資料不互相干擾，或是避免資料更新的先後順序問題 (例如商品庫存) ，這都是好的測試應該注意的重點。

重要的是，每個測試案例是要有意義的，我們在撰寫測試之前就要先分析它們的前因後果，才能擬定出正確的測試方向。如果覺得自己寫的流程測試可能有盲點時，那麼也可以請伙伴幫我們一起思考可能的狀況。

測試太花時間？

在很多 Web 系統開發的過程中，其實很少有人會去考慮測試這件事情；主要是因為 Web 系統中大部份只是簡單的 CRUD 而已，加上時程的壓力，就會讓很多開發人員放棄撰寫自動化測試。

不過在一個較具規模的系統的規劃與設計過程中，就應該將自動化測試考慮進來；而且即便有時程壓力，也應該對核心功能撰寫測試案例。尤其當核心功能牽扯到有關金流等不容有錯的部份時，更是應該用測試來嚴格把關。

更好的方式是將撰寫測試的時間在一開始就放到時程規劃裡，其他的就讓專案經理去傷腦筋，即便是在維護階段時也是如此。因為如果多花半個小時寫自動化測試的話，那麼未來找 Bug 的時間就至少可以減掉半天。

既有的程式該如何測試？

如果大部份已經在運作的程式沒有對應的自動化測試，而在它們發生問題就要花很多時間來除錯時，就應該考慮安排時間進行重構與撰寫測試。

首先在第一次重構時，可以先考慮把核心邏輯獨立出來；如果這個動作在執行上相當困難的話，那麼就先將資料或網路存取的部份獨立出來。這些外在因素我們可以透過 Dependency Injection 的方式來重構，然後在自動化測試時用 Stub 物件來代替它們。

當程式重構至無關外在變因，且手動測試通過後，就可以開始考慮撰寫自動化測試；這時還是要按照先測正常流程，再測異常流程的步驟來進行。而其中測試用的假資料可以從現有的資料中產生，這些資料因為已經透過客戶的驗證，更能確保測試的可靠性。

另外有些既有的錯誤是必須在長時間才能發現，這時候我們可能就要用推測的方式來撰寫測試案例。這樣一來有兩個好處，其一是我們就可以讓測試自動化去代替手動測試的部份，其二是如果未來還是發生同樣問題時，我們也能透過這些測試來排除掉先前推測出來的因素。

結論

其實我們也很難百分之百地保證通過測試的程式碼一定完全沒問題，但很重要的一點就是我們至少能保證通過測試的部份是會按照我們的想法來執行。

一個好的系統在交到客戶手上時，就應該要有一定的品質；而品質的保證來自我們的信心。至於我們的信心並不是建構在想像之上，而是應該用實際的測試數據來做為它的基礎。

2010 亞太資安論壇心得筆記

jaceju — Fri, 23 Apr 2010 01:55:47 +0000

轉自：2010 亞太資安論壇心得筆記

這次臨時去亞太資安論壇，主要是因為 Darkhero 的介紹，且主題剛好是我有興趣的網頁安全；所以就拜託了 Neo 老大讓我去聽課囉。

聽了一整天下來，很多都是廠商在介紹產品，觀念部份反而都是老調重彈 (但實作技術上都比以前進步很多) 。

不過阿碼科技的場次倒是讓我非常驚豔！主要是他們本身在這個業界就非常有名，而且這次分享的內容偏向技術面，讓我非常有認同感。

這次阿碼科技的分享主要內容是「網頁掛馬」，以下我就簡單分享這次的筆記與心得。

Malware 是什麼？

其實就是用來控制被攻擊電腦的惡意軟體，像是不必經過使用者允許就能遠端連線的桌面控制工具。

而常看到的透過 Script 或 Iframe 標籤所連結的 JavaScript ，其實只是用來下載 Malware 的工具程式。

網頁掛馬的途徑

網頁掛馬的方式分成三種途徑：

Web

一般常見的就是透過後端技術 (例如 ASP 、 PHP 、 JSP 等等) ，然後使用 SQL Injection 等常見的 Web 攻擊手法，把木馬掛到 Web 應用程式當中。

LAN

利用使用者操作上的疏忽，感染他們的電腦，再透過區域網路的 ARP 封包來對主機做掛馬的動作。常見的工具有 zxarps.exe ，它可以對區網內的使用者所訪問的所有網站插入惡意的 HTML 碼，例如 iframe 。

WAN

部份非知名品牌的網路設備 (例如 Layer 4 / Layer 7 switch) 存在著漏洞，駭客就利用它來讓連線的用戶被導向惡意的網站。

Malzilla 解掛碼工具

阿碼科技提供了以下測試用的掛碼網址：

http://zcrack.org/a
http://zcrack.org/cookie

然後透過 Malzilla 來就可以攔截到 http://zcrack.org/a 的原始 HTML 碼：

<html>
<head>
  <META NAME = "ROBOTS" CONTENT = "NOARCHIVE" >
  <META NAME = "ROBOTS" CONTENT = "NOINDEX" >
  <META NAME = "ROBOTS" CONTENT = "NONE" >
</head>
<body>
<div id="imgs"> <script src='go.jpg'></script><script src='2.jpg'></script><script src='3.jpg'></script><script src='4.jpg'></script><script src='5.jpg'></script><script src='5.1.jpg'></script><script src='6.jpg'></script><script src='7.jpg'></script><script src='8.jpg'></script>
</body>
</html>

主要可以看到木馬透過多個

HOLA 的網站改版會議

Neo — Sat, 09 Jan 2010 09:15:36 +0000

回顧去年的時候，特力集團的電子商務團隊負責人跑來我們公司。

會議開始後，從投影機之中映出了一網站，問我們能不能做到這樣的效果?

(這個網站是 Pixazza 。發音 Pix-a-zza 音似: "皮克斯阿殺")

Pixazza 在去年成立時就引發國外媒體關注，這個連 Google 也名列股東之一的公司，做的事看起來明白易懂:「即使是新聞圖片也可以購物」。

雖然很多人笑稱這只是 Flickr + EDM 的變形，國外早年已有類似的應用在型錄上，但實際應用於購物網站在台灣還沒見到。

特力的團隊同時也帶來了 IKEA 的網站做為參考:

看完之後，我請另一位同事先放下手邊的工作，從電腦拿出個東西給他們看，我們其實很早就開發出雛形來了。

(這個雛形不只有"點"，甚至可以延伸到"面"。上圖是 Email 給特力團隊時改為廚房情境照)

接著跟特力的團隊討論完技術層面，並且參考 HOLA 的實體型錄內容之後，特力團隊的負責人認為還有一件事要解決，以圖片為購物主軸來結合購物網站並不容易，在國內外都沒有這樣的案例可以參考，也希望我們能提供一些意見。

這次就輪到我來做展示了，其實在討論的過程中就已經想到我們的客戶 BlingCandy 的網站首頁非常適合呈現這樣的購物模式:

首頁上方遠大於一般購物網站的圖片尺寸，可以左右切換不同的圖片來進行購物。
這樣情境圖片便能成為網站購物的主體，網頁下方再規畫為展示及促銷訊息區塊。

就這樣，客戶帶著滿意的微笑離去， HOLA 的新版計畫也就從這裡開始了。

美麗華 IMAX 3D 體驗阿凡達的真實世界

admin — Fri, 01 Jan 2010 06:22:43 +0000

阿凡達 AVATAR 這部劃時代的電影上映，許多企業紛紛包場體恤辛苦的工作同仁們。

哇寶當然不能錯過這個新時代 3D 電影的響宴，阿凡達在台正式上映前便已預訂在台灣螢幕最大的美麗華 IMAX 影廳，讓全體同仁體驗身歷其境的 IMAX 3D 的潘朵拉星球之旅。

(哇寶夥伴們在阿凡達立牌前合影)

阿凡達這部電影成功的寫下影史的新頁，相信台灣未來也能做出更多舉世刮目相看的革命性產品。

TAIWAN UP!

[小插曲] 辦公室出現了一個可愛的東西... :-)

suzy — Tue, 30 Jun 2009 06:12:01 +0000

這...有耳朵也有屁屁的東西是什麼呢? (Abu 替牠洗完澡正在打蠟的時候引起一陣騷動)

原來是狗狗便當盒, Abu 的午餐盒!! (我照反了, 其實圓點是牠的屁屁)
Abu: "除了裝餐點還可以看牠表演原地旋轉 (微波的時候)."

可以裝不少呢:

阿丹覺得牠像存錢筒:

我覺得像一顆大乳牙....

非常可愛的雙層便當盒推薦給愛狗人士使用喔還有大家要吃早餐喔 Yeah

來自 Christian Heilmann 推特的鼓勵

admin — Sat, 25 Apr 2009 18:56:11 +0000

話說上周公司有四位伙伴去參加了Yahoo! 奇摩校園技術分享講座，回來後 Jace 在公司部落格發表了一篇文章。

文章發表後沒多久，主講人 Christian Heilmann 的 Twitter 上就出現了一則:

(From http://explore.twitter.com/codepo8/status/1543869786)

這真是莫大的鼓勵呀!! 感謝 Christian Heilmann 不辭辛勞的在各地推廣 Web 技術，這真的是網路世界的福氣。

原文: Yahoo! 奇摩校園技術分享講座
英文: Yahoo! campus technology sharing talks
(標題也是 Google 翻的，Christian Heilmann 看到的版本)

開箱－BENQ E2200HD Series LCD Monitor

ingrid — Thu, 16 Apr 2009 06:46:31 +0000

不囉唆~收到東西趕快來開箱…

購於PChome

脫掉PChome的外殼後，終於看見BENQ E2200HD的真面目~
外箱模樣
(P.S買螢幕還送SANYO名片型電動刮鬍刀)

開箱囉~

全部配件出箱圖~

噹噹噹~主角現身囉!
(正面)
16:9面板尺寸，完美呈現Full HD細膩視野，滿足您挑剔的雙眼

(背面)

看出來了嗎?
這個螢幕的一大特點就是背面有一部份是皮革的，
但要是你放的位置背面面對牆，我想應該也沒人會發現這個特色…

既然皮的那麼低調，那就再來幾張特寫~
(塑膠模還捨不得撕)

側邊控制鈕特寫~

螢幕上方後面的散熱孔~

四葉妹妹可以穩穩的站在電腦上面…

但……四葉妹妹站在上面做什麼咧?
沒什麼，純粹是個人喜好~

<結論>

外型清爽，按鈕也不會很突兀，
與過去的19吋相比，
換了寬螢幕，可以呈現的內容也變得更多了。
幾乎可以裝下兩個B&Q網站，
當需要比較兩個網頁或是討論兩種不同頁面的功能的時候，
寬的優點就可以展現(如下圖)~

當然最重要的是這樣的價位跟這樣的尺寸與它所付予的畫質享受，
我認為這個產品是很超值的。
雖然在工作上比較少機會看影片，
但是對於預算少又想擁有最近大家口中經常討論的Full HD 16:9的寬螢幕，
BENQ Senseye 是個不錯的選擇。

(P.S 以上結論, 感謝本monitor主人Suzy同事友情贊助)

開箱－APC Back-UPS ES 500VA

ingrid — Thu, 16 Apr 2009 03:08:47 +0000

今天來跟大家分享開箱APC Back-UPS ES 500VA不斷電系統

相信大家用電腦時最害怕碰到的狀況之一就是—跳電!!!
一旦跳電所有的努力都將付之一炬…同時也很傷電腦。
因此，在需要大量使用電源的地方，或電壓不穩定的地方，
擁有不斷電系統是必須的。

為什麼會選擇這台呢?
原因很單純~
APC是大廠，值得信賴，產品品質有保障；
再來當然就是價格很和藹可親啦！

外盒左下方清楚標明ES系列的四大產品特色 :
1.電源插座(共6個)
2.電話線路保護
3.搭配軟體
4.保護設備及您的文件

開箱囉~~!

拿出所有東西~

拆開包裝後全部的零件 :
本體、控制線、驅動光碟、說明書
本體的大小約是辦公室椅子的一半大，但重量可不輕啊…

另附上兩張系統監測軟體的畫面~
‧當前狀態

‧運行時間

整體而言，初步使用的心得是~

優點：
(1) 簡單易用；只需要接妥電源以後，就可以正常工作，不需額外的設定。
(2) 搭配顯示的軟體介面清楚；簡單明瞭的數據顯示，讓使用者對目前 UPS 的狀態一目了然。

缺點：
(1) 體積稍嫌龐大，重量也不輕；如果需要移動的時候會比較不方便。
(2) 內附光碟提供顯示的軟體，多國語言並未內建繁體中文；對於不習慣英文，安裝簡體中文
介面的使用者來說，需經過特殊處理才能正確顯示，不夠友善。

(P.S 以上心得, 感謝本UPS照顧者Daniel同事友情贊助)

[心得感想] 學習技術的步驟

jaceju — Wed, 15 Apr 2009 12:53:25 +0000

本文轉載自：[心得感想] 學習技術的步驟

在資訊產業上，持續不斷的進步一直以來都是不被淘汰的不二法則。不過要如何有效學習新的技術呢？其實方法非常多，而且每個人學習的方式也不一定都相同。

前些天在噗浪提到我學習技術的幾個步驟，有網友詢問我能不能進一步解說？所以就藉著這篇文章，來分享一下我的方法吧。

六大步驟

接觸

很多技術都是工作有用到才會想去碰它，這是大多數人學習技術的動機，我其實也不例外。不過我個人也習慣在網路上東翻西找，去嗅探一些我有興趣的東西，這也是一種接觸技術的方式。

在接觸的這個步驟中，很重要的一點就是：要對這個技術產生興趣。如果沒有興趣，那麼在後面的步驟中，多數人都會很快地覺得這個技術很困難，然後就放棄學習它了。

實作

在接觸技術後，我個人習慣會用它來實作一些簡單的小程式。這樣做的目的有很多，但主要有兩個：一來可以瞭解這個技術實際運作的方式，二來可以明白這個技術的優缺點在哪裡。

而且實作技術還能增加你對這個技術的熟稔度，如果哪一天專案真的需要用到它時，你就能很快知道它該怎麼用。

瞭解

大部份時候，我們只要會「用」技術就可以了。不過身為一個 IT 人，身上帶著...不對...去弄清楚這個技術的原理是非常重要的。

就像我們在使用 jQuery 的 Plugin 一樣，多數的 Plugins 都會提供文件或範例，然後我們只要針對它的選項做修改即可。然而這些 Plugins 其實都是把一些技術原理包裝起來，方便我們使用。去瞭解這些 Plugins 背後的運作原理，可以幫助我們未來在不方便使用 Plugins 或是想要進一步改良它們時，能夠更清楚地知道自己該怎麼處理。

應用

上面提到實作是指自己先寫一些小程式來熟悉這個技術，當然如果覺得這個技術能派上用場時，就別放棄這個機會啦。在應用技術之前，要記得仔細評估它對專案的適用程度，所以這就得依賴自己對這個技術的掌握有多少。

如果這個技術偏向於視覺化應用時，還要特別注意客戶是否很要求頁面上的呈現。如果這個客戶想要的畫面跟你所用的技術的呈現效果不合時，也千萬別氣餒；這時如果你瞭解這個技術的原理，那麼就可以舉一反三，將它套用在客戶所認可的頁面上。

簡化

因為我個人記憶力不是很好，所以當我對某項技術瞭解至一定程度時，我會習慣把它簡化。這樣不但可以讓我在回顧這個技術時，能很快掌握它的精髓；而且如果要分享給其他人時，更能讓別人瞭解這個技術的本質是什麼。

當然也不是什麼技術我都能簡化，因為這得看我對這個技術的瞭解程度有多深，以及我對這個技術能不能找到一個能類比的例子。所以這個步驟我也不一定會去做，我在乎的是我是不是真的能運用這個技術而已。

很多人學到技術以後，就習慣抱著不放，我個人則是喜歡把它們分享出來。分享技術有很大的好處，一則可以讓其他人也學到東西，二則我可以從別人在應用這個技術過程中，得到他們對於這個技術的反饋。然後在他們的回饋裡，我就可以明白我自己對這個技術是不是真的瞭解了，是不是真的能應用自如。

而分享的方法很多，像是撰寫部落格文章、在公司舉辦內部教育訓練等等。最重要的是不要吝於去分享，也不要害怕去分享。只有透過交流分享，你才能獲得更多東西。

感想

上述的這些步驟都只是輔助我們學習技術而已，走在 IT 這條路上真正需要的是恆心與毅力；雖然聽起來很八股，但卻是不爭的事實。

我的學習步驟不一定適用於其他人，但我希望這樣的解說，可以讓各位在學習的道路上有參考的方向。只有不斷向前，你才能在這個環境中生存下去！

做好、做完、驚喜

Neo — Fri, 03 Apr 2009 13:01:25 +0000

親愛的伙伴們:

做事情，有三種境界:
做好、 做完、驚喜

舉個最近的例子，B&Q 跟真光電店的合作活動預備要正式開跑，網站畫面也出來了。

程式運作正常 <= 把事情「做好」

活動如期上線 <= 把事情「做完」

那...什麼是「驚喜」?

我在真光活動正式開始前就把頁面印出來，並且拿去真光門市去試換，門市人員也很熱心的拿出照會單給我看，確認整個兌換流程。<= 這是產生「驚喜」的前奏

請大家看一下有什麼不正常的地方?
(被畫掉的個人資料除外)

解答:

印出來有二頁，而且第二頁前面只有3行。

B&Q 是國內知名通路品牌，在全球致力於環保節能減碳救地球的氛圍下，B&Q 還跟北市環保局聯合辦理了「綠色商店」，並且不斷的營造綠色環保的形象。

但一個兌換活動卻要用到二張紙，如果被媒體拿去作文章，這是何等的諷刺與難堪?

由於在活動開始之前就事先發現，客戶也立即表達了感謝之意。

這就是「驚喜」。

客戶先前表達感謝的訊息也轉寄給大家看過，我們收到 B&Q 的感謝已經不是第一次了，客戶很明白的指出我們提供的服務已經遠超出了預期。

各位的工作的速度、品質都已經備受客戶肯定，接下來學習把事情做到「驚喜」是我們要努力精進的境界，這同時也是讓人生多采多姿的敲門磚。

與大家共勉之

Neo

jQuery Plugins 星光大道

admin — Fri, 03 Apr 2009 02:48:52 +0000

本周 Jace 舉辦了 jQuery Plugins 星光大道 活動，每個人分享三個 jQuery Plugin ，經過展示及說明後由彼此互相評分。大家都玩的不亦樂乎，不但出現了六分的破表分數，也有被噓到沒分數的 Plugin 。

整個活動進行的過程讓大家更了解 jQuery 許多好玩有趣的 Plugins，同時也激發出更多的想像、創意及應用。即使活動結束後仍然討論的不亦樂乎，相信透過分享能讓大家在技術領域能有更深層、更不受限制的揮灑空間。

[心得] 怎麼寫技術文件

jaceju — Mon, 09 Mar 2009 10:05:32 +0000

文章轉載自：網站製作學習誌 - [心得] 怎麼寫技術文件

先說明，這篇文章只是為了給伙伴看的，它不是一篇正規的文件寫作技巧；因為我也沒學過類似的東西，只是把自己的經驗與心得整理出來分享給大家。

擬定大綱

在寫文件或投影片之前，先把大綱擬定出來是很重要的。寫一篇文章就好像開車上路，有起點也有終點；而且你一定要先確認哪裡是可以走的，把大方向先找出來。大綱的主要目的就是讓我們自己確認文件大致要描述的東西，不致讓我們整個走偏掉。

大綱要怎麼寫呢？首先先把大標題寫下來，確定整篇文件的方向。然後你可以繼續在每個大標題下再補上小標題，將整篇文章的輪廓描繪清楚。

條列說明

擬定好大綱後，我們可以開始寫文章了。不過大多數人都不容易一下子寫出洋洋灑灑、圖文並茂的內容。這時我會建議大家採用條列式說明法，先將重點條列成骨架，再慢慢為它們添血加肉。

條列式說明主要可以簡短扼要先將重點記下來，寫文章的人也不會因為要想落落長的詞句而忘了其他部份的重點。列好重點後，你再用你精美的修辭與曼妙的詞句去補充它們，但切記不要讓文句流於枯燥與繁瑣。

正確地引用與摘要

技術文件很重要的一點就是正確性，所以有時候你可能會需要在你的文章裡補充某些技術性的觀念；這時你可以直接引用別人寫過的文章，把重點摘要在段落之間。最重要的是讓看的人不用點選連結就能簡單掌握住這個觀念，需要詳細瞭解時再點選連結即可。

適時加上圖片或範例

有時候寫了一堆不知所云的說明還講不清楚時，你倒不如用張圖來解釋你的想法。不過有時圖片也不容易解釋清楚，這時你還可以直接用範例說明。

畫圖或範例主要的目的是讓看的人自己在腦海裡產生說明，但簡單的文字敘述還是必要的，免得畫者無心，看者有意。

將它讀出來

很多人寫文章都是寫完就算了，自己根本沒有回頭再多看幾次；所以糟糕的排版，錯誤的標點符號，完全不通順的句子，常常會出現在這些人的文件裡面。

要解決這個問題，我建議你自己讀一次你自己的文章；最好能大聲唸出來，然後把它錄下來播給自己聽，沒睡著就算成功一半了。

說服自己

沒有什麼項目是比說服自己更重要的了，如果你自己寫的東西都無法說服你自己，那又怎麼能期待別人看得懂呢？

不過說服自己並不是催眠自己對自己的文件有莫明奇妙的信心，最好能用完全忘掉內容的心情去重看一次；如果越讀越覺得自己對這份文件的內容掌握度很夠，那這樣一來你的寫作能力就能更往前邁向一大步。

用部落格來練習

很神奇的是，我在寫部落格會有一種我是寫給別人看的感覺 (其實不一定會有) ；所以我自己在寫部落格文章時，就會對自己寫的東西有一種莫明奇妙的責任感。當然不一定每個人都是這樣，但這的確不失為一種好的自我訓練方式。如果有人指正你寫錯了也沒關係，因為這就是我們練習的目的。

總之，寫技術文件其實並沒有想像中那麼困難 (但會覺得麻煩是很正常的) ，重要的是你有沒有重視它，多寫多練習吧~

哇寶十大神秘事件

andrew — Thu, 06 Nov 2008 04:14:05 +0000

1.會自己鎖上的廁所
2.神秘的魚
3.永遠吃不完的零食桌
4.會流血的馬桶
待補完...