DAY1

出發是下午的班機，因此第一天幾乎沒甚麼行程，恰逢連假機場滿滿的都是旅客，班機延誤兩小時
大夥就在免稅區逛逛，還沒踏出國門就先敗家了~
抵達日本已經是晚上了，趕在飯店晚餐時間結束前用餐，一整天都在奔波中度過
我們這團的導遊是李桑李曜同先生，是非常專業的資深導遊唷!

第一晚過夜的飯店-金澤國際飯店
suzy拍的甜點九宮格自助餐

DAY2

白川鄉合掌村

早上起來發現窗外已經開始有少許積雪，對於很少看到雪的台灣人而言真是新奇呀
馬上跑到外面拍照，結果沒一分鐘就開始感覺到冷啦 XD
越靠近合掌村，霧氣也越重
合掌村全景

遠眺全景現場實際光線就是像照片這樣色調喔!灰灰暗暗的~
由於正逢合掌村展望台積雪過深沒有開放，因此最多只能拍到像這樣子的鳥瞰圖啦~
下車後要過橋才會抵達合掌村，這時正飄著細雨小雪~地上會滑，走路要留意。
有的房子旁邊積雪很深，這邊的雪壁是很緊密扎實的，可以堆成冰宮
整個村子好安靜，加上下雪天，有隱居山林的感覺
這邊房子有的是有住人的，有的則是有開放付費參觀，也有部分是店面，販售當地紀念品跟特產
大家在這裡買了不少零食。這邊的特產是北陸飛驒地區的傳統護身符猴子寶寶sarubobo
紅色沒有臉的那隻娃娃就是~
(by 小魚)

今天算是我們第一次體驗到下大雪的酷寒天氣
因此大家格外期待用餐 XD XD ，在看到今日午餐後好開心呀!
豐盛的朴葉味噌燒，除了肉跟飯、湯以外都是冷的

照片拍的剛好是素食口味，有興趣可以上網GOOGLE，會有很多讓人流口水的好吃照片~
有肉有豆腐有湯有菜，味噌很下飯讓人食慾大動，豆腐則是口感較硬的板豆腐
不過因為天氣關係，導遊說這一區的蔬菜大都是醬菜
肉的話要自己邊吃邊烤，有的是做成有湯的壽喜燒形式，都很好吃

此時窗外下起大雪，我們很興奮的跑到陽台拍照
不過沒一分鐘就全都被冷回屋內....(現場光線就跟照片一樣!)

下午的行程是參訪高山陣屋-上三之町
一下車就感覺寒風刺骨，導遊說這邊地勢比較高，
雖然這邊積雪不若合掌村深，但實際上這邊溫度比較低!

高山陣屋舊跡:高山陣屋原為高山城主的宅邸，幕府時期曾在此處設置了辦公機構，
以便管理飛驒地區的行政事務。而這個辦公機構的場所，便被稱為“高山陣屋”。
(by雄獅旅遊官網資訊)
進去參觀要另外付費，我們便到隔壁的上三之町古街去逛街嘍!食尚玩家也有來這條街採訪過喔!

(by 小魚)
隔壁賣的醬油麻糬糰子，口味偏鹹，有興趣的人可以嘗試看看

復古精美的十二生肖手工娃娃擺飾，好想全部帶回家~


果子店吃草莓大福(因為真的太冷了，想說吃點東西吹暖氣 XD)

(by 小魚)
也有日本酒專賣店，同事買了一個迷你籐編酒桶組

今晚的過夜的是深山裡的溫泉旅館唷!穗高莊溫泉旅館
越往山上走，天色越昏暗積雪也越來越深
大夥看著車窗外的景色嘰嘰喳喳興奮不已
坐落在深山中的溫泉旅館給人相當溫暖靜謐的感覺，
我笑說金田一事件簿就都是發生在這種溫泉旅館裡面
因為前不著村後不著店，出旅館就凍昏了 XD XD


一字排開很壯觀的壽喜燒晚餐
這一餐相當豐盛!有烏龍麵，要自己煮，不過煮的時間要掌控好，不然湯汁就乾掉啦
方形竹盒裡面有新鮮蔬菜跟海鮮，是用有點類似蒸籠般的煮法。
侍者都是70多歲的和服阿嬤，動作靈活完全看不出年紀。
房間內有附浴衣讓房客可以去泡溫泉時穿著
日本溫泉是要全裸的，不像台灣還可以穿泳衣入池，要泡的人要注意這點喔。
有分男湯女湯，也有男女混浴的大眾池。
在冷冷的天氣泡溫泉真是人生一大享受!
(待續)

這些字可不是圖片，真的是CSS嵌入字型完成的作品....而且IE6 ~ 9、Firefox、Safari、Chrome、Opera都可以正常顯示。但要滿足這麼多瀏覽器的情況，A&F是怎麼樣做到的呢？

正確的答案就是，使用@font-face！那@font-face要怎麼用呢？請看範例：

1. 先在css中定義要使用的字型名稱以及字型檔放置的位置

我們在A&F的CSS原始碼中查看到其中一個字型的@font-face設定如下：

我們可以發現，其實在使用@font-face的時候，「好像」需要很多不同類型的字型格式檔....但是，不要懷疑。因為各家瀏覽器在支援的字型格式不同的情況下，所以造成了必須要將希望正常顯示字型的瀏覽器都要設定的情況。
所以，要使用的時候，需要先將@font-face照前面的程式碼先設定好後，再用一般使用CSS設定字型的方式套用，如下方範例：

接下來會看到字型會被套上的樣子...(此字型是套另一個worldwideweb字型)

2. 那些瀏覽器支援什麼樣的字型檔？

基本上，因為常見到的瀏覽器有幾種：IE系列、Firefox、Safari、Chrome。基本上，這幾種瀏覽器都是需要正常顯示出來。初步測試後，支援字型檔的格式如下：

* IE6, IE7, IE8, IE9： 支援EOT字型檔。
* Firefox：支援otf以及ttf、woff
* Safari：支援svg、otf
* Chrome (Google 瀏覽器)：支援svg、otf

3. 這幾個英文是什麼意思？

* EOT(Embedded OpenType)： 由微軟制定並於2008年1月提交至W3C的字型規格。因為本篇不是在介紹字型格式，所以詳情可以看這邊了解格式的內容。

* OTF(OpenType)：也是由微軟一開始制定，後來adobe也加入共同發展。字型規格

* TTF(TrueType)：早期為了對抗Adobe的Type1 Postcript字體而由Apple、微軟共同開發的一種字體標準。字型規格

* WOFF(Web Open Font Format)：2010年由Mozzila基金會、Opera、微軟一起送出的Web開放字型格式。

* SVG(Scalable Vector Graphics)：這不是一種字型檔，而是基於XML的一種製造二維向量圖形的格式。由W3C制定，是一種開放標準。頁面請見此處

基本上只要特別注意提供支援的格式，其實你也做的到不使用系統預設字型來設計網頁！

假設有一案例：

有一個html的版面，長的樣子如下：

需求
需要將圖中logo右邊有一個歡迎訊息：「您好, 歡迎來到xxxxxxxx X網站.」的加入二個中文字，變成「您好，歡迎來到xxxxxxxx 這是一網站.」

發現問題
在畫面上看起來，其實感覺將需求一下就可以完成。而其實也只是二個字而已。但開始動的時候就發現問題來了.....在IE6上，可以正常的顯示。如下圖：

但是同樣的畫面在Firefox、Chrom、IE8會變成下圖的樣子：

這個時候總是會發現怎麼會有這種情況？這到底是發生什麼事？又不想把字體縮小，因為如果這個文字再縮下就到8px的話，其實如果是Mac的使用者看到會發現小到很難看的清楚。但是，不縮小又沒辦法整個不換行放進去.....

網頁實際切版狀況

我們來看看實際上header的部分排版的狀況：
如果以目前這個版面是以Table做排版的情況，並且將header的部分(就是有logo的那一塊)排出來的時候，其實事實上是像圖片上紅線的樣式切出空間然後將圖片、連結就上定位。但是就是因為有固定的寬度，也沒有辦法在為了維持目前的字體大小之下，將其他的瀏覽器加字後完整的不換行放在同一個空間中。
所以，千萬別以為只有加「二個字」也是很簡單的事.......設計師們可能要調上好久的時間囉！

網站的粉藍*鵝黃色調充滿溫馨感

http://shopping.chick.com.tw/

寶寶的第一個朋友-奇哥

跟寶寶有關的相關用品均可一次購足
也有提供專屬網路購物優惠商品

在新的一年 2012， 奇哥很貼心的在月初寄給哇寶伙伴們的禮品:

很可愛的寶寶日曆，質感精美的精裝筆記本和紅包袋~
女同事看到都忍不住尖叫好可愛呢~

在此祝福奇哥 2012 能開春大賣~

一、下載安裝python:

請先到 http://python.org/getit/ 下載windows的installer(目前是使用python 2.7版)
 

二、一直下一步安裝:

預設安裝會將python2.7安裝在 c:\Python27 的資料夾之中。在這個時候，windows上直接開始Dos模式後直接下

c:\python

會出現錯誤，因為這個時候系統並沒有將python認成是內部指令。
 

三、設定環境變數:

在系統 / 進階 / 環境變數之中，加入以下變數設定：
 

PATH = C:\Python27

 
接下來重開一次Dos模式重新再下一次python指令後，應該會進入python的指令模式。這時候退出請下：
 

exit()

 
基本的python環境就完成了。
 

四、安裝套件工具easy_install

先到http://pypi.python.org/pypi/setuptools#files下載相對python版本的工具。因為之前筆者安裝的是python 2.7，所以在這邊安裝了2.7版本的setuptools-0.6c11.win32-py2.7.exe檔。 下載好後，直接點開一直按下一步安裝。除非預設的Python27的資料夾有變動，否則直接下一步安裝就可以完成了。當安裝完畢後，會在C:\Python27\Scripts這個資料夾下發現有easy_install的程式可以執行。
 

五、將easy_install加到環境變數之中

因為安裝後還是不能直接在dos環境下直接下指令，所以，就手動把環境變數加進去。
 

PATH = C:\Python27\Scripts

六、安裝MySQLdb for Python:

先到這個網址: http://www.codegood.com/archives/129下載讓python 2.7使用的檔案。下載好後，一樣直接點二下執行安裝。一樣一直按「下一步」安裝，就會安裝在預設的資料夾C:\Python27之中。 (本文為32bit的安裝方式。64bit會需要更改機碼。)

這樣就完成了。

文章轉自：在windows環境中設定python以及MySQLdb

有圖有真相-->

這是日前筆者在雅虎首頁看到的
圈選起來的三個廣告欄位都是我們哇寶的客戶
分別是 lativ、Gracegift、天母嚴選
能夠排到雅虎首頁黃金廣告欄位的網站
都是台灣網路業界的top star
哇寶也備感榮焉呀~~
同時也讓我們哇寶在業界知名度大大提升

耳聞有網友在打探這幾間購物網站是哪家公司做的?
由於購物網站上不會特別提及製作網站等相關資訊
聽說可是費了一番功夫，好不容易才探聽到是哇寶
"網友A:我問了好多人好多家廠商才問到某某購物網站是你們哇寶做的........"

"同事B:啊~您好您好~(心裡OS難道是我們真的這麼難找!?)"

"同事C:阿不就要在黑板上寫XYZ才能夠招喚出哇寶接case嗎......."

於雅虎購物中心發跡，主打18-35的少淑女客群
旗下有兩個品牌GraceGift和KAZANA
涵蓋風格極廣，從甜美少女風乃至帥氣軍裝路線都有
無論是各式靴款、涼鞋平底鞋都一應俱全
現在市面上各大少女雜誌都可以看到她們的廣告和產品
曾邀請過知名女星徐若瑄以及日雜名模藤井LENA為品牌代言
最新一期的代言人是最近大紅的陳妍希及昆凌

圖:混血名模昆凌示範穿搭GraceGift秋冬靴款
圖:新生代女星陳妍希為GraceGift品牌誌拍攝的形象圖

GraceGift網站籌備許久才正式上線
讓我們來看看有甚麼特色吧!

既然是購物網站當然會有獨家優惠啦~~
GraceGift提供多款美鞋官網獨家優惠
換算下來折數蠻大，也有單一特價款
顧客同樣享有7天鑑賞期可無條件退貨
還有貼心的新服務--->電話訂購
對於網路購物不熟悉的網友可以直接電洽訂購
也提供貨到付款以及7-11取貨、信用卡刷卡等方式
再也不用擔心家裡沒人收件嘍
是不是很方便呢!
心動了就趕快去體驗一下吧!

自 Zend Framework 1.6 之後就提供了 Zend_Test 這個套件，協助我們為 Zend Framework 的 MVC 做單元測試。然而當時也許是因為大家對 Zend Framework 的新架構還不熟悉，加上 Zend_Test 套件有許多小地方還不是很完善，因此就很少有人利用它來做測試。

而到了 Zend Framework 1.8 版之後， Zend_Test 便修正了許多缺點；而且也因為 Zend_Application 套件的引入，讓 Zend_Test 在 Controller 上的測試更加方便，也使得網路上許多高手開始為它編寫教學。

不過官方的文件並沒有特別告訴我們怎麼去建構 Zend Framework Testing 的環境，所以以下我以 Zend Framework 1.10 再加上 PHPUnit 3.4 為例，帶領大家進入 Zend Framework Testing 的世界。

準備 Zend Framework 專案

要進行測試前，我們得先要有個 Zend Framework 專案。假設這個專案名稱叫 unittest ，原始檔位於 D:\WEB\zf\unittest 上，我們用 Zend Framework 提供的 Zend_Tool工具來建立它：

zf create project unittest

然後我們切換到該專案目錄下：

cd unittest

註：雖然我是以 Win32 為主要環境，但 Linux 上的操作步驟也是雷同。

由於我個人偏好搬動整個目錄就可以移植專案的模式，因此我就不採用 Zend Framework 原本將 index.php 放在 public 目錄下的架構；以下動作的目的就是把 index.php 從 public 目錄移出來。

首先先把 D:\WEB\zf\unittest\public\index.php 和 D:\WEB\zf\unittest\public\.htaccess 複製到 D:\WEB\zf\unittest 下，然後修改 D:\WEB\zf\unittest\.zfproject.xml ，把上方紅框處的 index.php 和 .htaccess 的 XML tag 複製一份到下方的紅框處：

接下來要修改 D:\WEB\zf\unittest\index.php 中 application 目錄的相對位置；找到：

|| define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/../application'));

改為：

|| define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/application'));

然後我們要在 D:\WEB\zf\unittest\.htaccess 加入當前環境的常數，也就是在它的最上面一行加入：

SetEnv APPLICATION_ENV development

原來的 D:\WEB\zf\unittest\public\index.php 則用來阻擋使用者瀏覽 public 目錄，所以我們把它改成：

<?php
header('HTTP/1.1 403 Forbidden');

而原來的 D:\WEB\zf\unittest\public\.htaccess 則是將 Rewrite Engine 關閉，讓外界可以直接存取：

RewriteEngine Off

這樣就準備好我們的專案了。

在 NetBeans 中加入專案

NetBeans 近來對 PHP 的支援變得非常強大，讓我一用就愛上它。到 6.8 版為止， NetBeans 還沒有正式支援 Zend Framework ，不過這並不影響我們用它來開發以 Zend Framework 為架構的專案。

而這裡會提到 NetBeans ，主要是因為它支援了 PHPUnit ！而且還有圖形化介面；這使得我們在對 PHP 專案進行單元測試時更加便利！

回到剛剛我們建立的 Zend Framework 專案，我們可以在 NetBeans 裡加入一個現成的 PHP 專案。在工具列中，選擇 File > New Project... 後，會出現以下視窗：

然後要選擇現存專案的位置：

最後設定專案執行時的設置：

這樣一來我們就可以在 NetBeans 裡開發 Zend Framework 的專案了。

Zend_Test 基礎

Zend_Test 主要是基於 PHPUnit 這個 PHP 界公認最完善的自動化測試套件所開發的，所以不論是在設置環境或是在撰寫測試上，其實都是以 PHPUnit 的架構去完成。

為了避免本文內容過於冗長，這裡我已經先行設定好 PHPUnit 的執行環境；因此在繼續以下的步驟前，請大家先確認自己是否可以正確執行 PHPUnit 。

在 Zend Framework 為我們們準備好的專案目錄架構中，已經事先建立了 tests 這個供我們放置測試的目錄，所以現在我們可以先試試看用 PHPUnit 來執行我們的測試。假設我們目前的工作路徑是 D:\WEB\zf\unittest\ ，我們要先切換到 tests 目錄下：

cd tests

然後用 PHPUnit 提供的 Command Line Interface (CLI) 工具 phpunit 來執行測試：

phpunit .

我們會發現執行的結果出現了以下錯誤：

PHPUnit_Framework_Exception: Could not load "D:\WEB\zf\unittest\tests\phpunit.xml".

原來， phpunit 這個工具在我們對一個目錄進行測試時，會自動去剖析該目錄下的 phpunit.xml 內容；而 phpunit.xml 在 Zend_Tool 產生之後，並沒有任何內容，所以就使得 PHPUnit 丟出了一個異常。

所以這裡我們先簡單將它變成一個正確的 XML 檔案，在 D:\WEB\zf\unittest\tests\phpunit.xml 中我們加入：

<phpunit></phpunit>

然後在 Command Line 環境下再跑一次測試，結果如下：

這表示 PHPUnit 認得我們的測試環境啦！

建立測試

其實上面也只是讓 phpunit 能在我們的專案上啟用而已，但我們的測試主角根本還沒出現，所以接下來我們要開始來建立測試了。

Zend_Tool 建立出來的專案架構，其實有個預設的前置名稱，叫做 Application ；這個 Application 之後都做為專案中 Model 的前置名稱。一般來說，我都會將它改為像是 MyApp 或是 Shop 等等諸如此類符合目前專案性質的名稱。 Zend_Tool 也提供我們修改這個前置名稱的機制：

zf change application.class-name-prefix MyApp

執行結果如下：

Note: the name provided "MyApp" was altered to "MyApp_" for correctness.
Note: All existing models will need to be altered to this new namespace by hand
application.ini updated with new appnamespace MyApp_
Updating project profile 'D:\WEB\zf\unittest/.zfproject.xml'

要注意的是，如果在修改前就已經存在的 Model ，它們的前置名稱就要手動改成新的。

建立第一個 Model

接著我們建立第一個 Model Class ：

zf create model MyClass1

執行結果如下：

Creating a model at D:\WEB\zf\unittest/application/models/MyClass1.php
Updating project profile 'D:\WEB\zf\unittest/.zfproject.xml'

在 D:\WEB\zf\unittest/application/models/MyClass1.php 中就是 MyClass1 的內容：

<?php
 
class MyApp_Model_MyClass1
{
 
 
}

當然這個檔案目前只有簡單的類別定義而已，其他就是要靠我們自己手動完成。不過由於我們的重點是測試，所以這裡我們就不管 MyClass1 的內容。

用 NetBeans 產生 Test Case

前面提到 NetBeans 支援 PHPUnit ，因此這裡我們就直接試著用它來幫我們產生測試檔案。切換到專案目錄的「 Source Files/application/models 」下，在 MyClass1.php 上按下右鍵選擇「工具 / Create PHPUnit tests 」，我們就可以建立針對 MyClass1 類別的 Test Case ：

但因為 NetBeans 還不知道測試目錄的所在位置，因此它會提示我們輸入測試目錄；在這裡，我們當然就是選擇 D:\WEB\zf\unittest\tests ：

在按下確定之後， NetBeans 就會自動打開產生好的 Test Case 檔案。在本例中，它的位置就是在 D:\WEB\zf\unittest\tests\application\models\MyApp_Model_MyClass1Test.php 。

另外 NetBeans 也會把 tests 從原來的 Source Files 中獨立成 Test Files 目錄結構，但別忘了它實際的位置還是在 D:\WEB\zf\unittest\ 下。

目錄結構對應

繼續下個步驟之前，我們先來整個專案的目錄結構：

unittest
 |--application
 |   |--models
 |       |--MyClass1.php
 |--library
 |--docs
 |--public
 |--tests
 |   |--application
 |       |--models
 |           |--MyApp_Model_MyClass1Test.php
 |   |--library
 |   |--phpunit.xml
 |--.zfproject.xml
 |--.htaccess
 |--index.php

從上面的架構圖可以看到，在這個 tests 目錄下的 application 及 library ，就是對應著我們的專案目錄下的 application 及 library 。換句話說，我們在專案目錄下的 application/models 所建立的 Model Class ，它們的測試程式就可以放在 tests/application/models 下，其他以此類推。

執行測試類別

在我們建立好 MyApp_Model_MyClass1Test 這個測試類別後，就可以在上面撰寫測試案例了。這裡我們先簡單加入一個空的測試案例，即 testMethod1 方法：

// ... 略 ...
class MyApp_Model_MyClass1Test extends PHPUnit_Framework_TestCase
{
    // ... 略 ...
 
    public function testMethod1()
    {
 
    }
}

接著就可以執行測試了。

這裡雖然我們可以用 phpunit 來執行測試，不過 NetBeans 也可以幫我們代勞。我們可以在 NetBeans 的 Project 視窗中，對 unittest 專案名稱按下滑鼠右鍵，執行 Test 指令 (或直接按下 Alt + F6 ) ，這樣就會開始執行測試了。

完成測試後，就會出現下圖中的 Test Results 視窗。

這看起來是不是比先前的 Command Line 輸出結果好多了呢？

測試環境的自動載入

在測試時，其實我希望要測試用的類別能被自動載入，而不需要加入一堆的 require_once 。以往我在舊專案的做法是在每個測試案例之前，引用一個 bootstrap.php 檔，內容如下：

<?php
define('APP_PATH', realpath(dirname(__FILE__) . '/../app/'));
 
set_include_path(implode(PATH_SEPARATOR, array(
    realpath(APP_PATH . '/lib'),
    realpath(APP_PATH . '/base'),
    realpath(APP_PATH . '/mod/common/models'),
    get_include_path(),
)));
 
function autoload($className)
{
    $className = str_replace('_', '/', $className);
    require_once "$className.php";
}
 
spl_autoload_register('autoload');

而在新架構中， Zend_Tool 很貼心地為我們產生好了這個檔案，也就是 D:\WEB\zf\unittest\tests\application\bootstrap.php 。

註：不過 D:\WEB\zf\unittest\tests\application\bootstrap.php 裡面的內容是空的，我們得自己把它加入。

但是每次都要在測試類別檔載入這個 bootstraop.php 也是相當麻煩，還好 PHPUnit 讓我們可以在 phpunit.xml 中去加入對 bootstraop.php 的自動引用。接下來請將 D:\WEB\zf\unittest\tests\phpunit.xml 的內容改為：

<phpunit bootstrap="./application/bootstrap.php" />

這麼一來，當我們執行 phpunit 時，就會自動引入 bootstraop.php 了。而這裡要注意的是， ./application/bootstrap.php 這個路徑是相對於 phpunit.xml 的，其他非絕對路徑的設定也是。

不過上面的 bootstraop.php 寫法在新的 Zend Framework 架構中就不適用了，因為它的自動載入只能應付類別名稱為 Xxx_Yyy_Zzz 並對應到檔名為 Xxx/Yyy/Zzz.php 的模式；而新架構中的 Model 則是位於 application/models 之下，也就是說我們的 MyApp_Model_MyClass1 這個類別的實際位置是 D:\WEB\zf\unittest\application\models\MyApp_Model_MyClass1.php ，因此我們得想辦法讓 bootstrap.php 能自動載入新架構的 Model Class 。

還好 Zend_Loader 提供了 Zend_Loader_Autoloader_Resource 這個套件，來幫我們載入 Zend Framework MVC 架構下的 Model Class 。所以我們的 bootstrap.php 就可以改成：

<?php
error_reporting(E_ALL | E_STRICT);
 
date_default_timezone_set('Asia/Taipei');
 
define('APPLICATION_ENV', 'testing');
define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/../../application'));
define('APPLICATION_CONFIG', APPLICATION_PATH . '/configs/application.ini');
 
set_include_path(implode(PATH_SEPARATOR, array(
    realpath(APPLICATION_PATH . '/../library'),
    realpath(APPLICATION_PATH . '/../tests'),
    get_include_path(),
)));
 
require_once 'Zend/Loader/Autoloader.php';
$autoloader = Zend_Loader_Autoloader::getInstance();
$resourceLoader = new Zend_Loader_Autoloader_Resource(array(
    'basePath'      => APPLICATION_PATH,
    'namespace'     => 'MyApp',
    'resourceTypes' => array(
        'model' => array(
            'path' => 'models/',
            'namespace' => 'Model',
        ),
    ),
));
$autoloader->pushAutoloader($resourceLoader);

註： Zend_Loader_Autoloader_Resource 的詳細用法請參考官方手冊 Resource Autoloaders 一節的說明。

現在我們可以試著把 MyApp_Model_MyClass1Test.php 中的 require_once 敘述移除，試試看 phpunit 會不會自動載入。

不過特別要注意的是， bootstrap.php 只會在 phpunit.xml 被載入時自動被引用，因此我們就一定要透過 phpunit . 這樣的方式來執行測試，不然就會發生找不到 Model Class 檔案的狀況。如果我們只想單獨執行某個測試類別時 (例如 MyApp_Model_MyClass1Test ) ，就必須改用以下的方式執行： (假設當前工作目錄是在 D:\WEB\zf\unittest\tests )

phpunit application\models\MyApp_Model_MyClass1Test.php --configuration ./phpunit.xml

而在 NetBeans 中，我們可以在 Project 視窗的 Test Files 上按下滑鼠右鍵選擇 Properties ，就會出現以下視窗：

然後我們再指定 phpunit.xml 的位置，這樣就算只對單一的 Model 進行測試， NetBeans 也會自動幫我們載入 phpunit.xml 了。

加入更多測試

一個專案裡要測試的 Model 當然不可能只有一個，接著我們再加入新的 Model 。在 D:\WEB\zf\unittest 之下，我們執行：

zf create model MyClass2

然後再透過 NetBeans 的 Create PHPUnit tests ，幫它建立一個測試類別 MyApp_Model_MyClass2Test 。當然也別忘了幫這個測試類別加入測試案例，以免執行測試時會出現沒有測試案例的警告。

不是只有 Model 可以被測試，在 Zend_Test 裡也提供了測試 Controller 的方法；方法很簡單，以預設的 IndexController 為例，我們一樣也是在 NetBeans 的 Project 視窗中，對 unittest/application/controllers/IndexController.php 執行 Create PHPUnit tests 就可以了。

但是這樣卻有可能出現以下的錯誤訊息，而無法成功建立 IndexController 的測試類別。

而查看輸出視窗 (Ctrl + 4) ，實際的錯誤訊息是：

Fatal error: Class 'Zend_Controller_Action' not found in D:\WEB\zf\unittest\application\controllers\IndexController.php on line 3

這是因為 NetBeans 其實是透過 phpunit --skeleton-test 這個指令來幫助我們建立測試類別，而 --skeleton-test 會利用 PHP 5 的 Reflection 機制幫我們找出類別裡的方法；但 Reflection 也會需要相關引用到的類別的定義 (這裡就是 Zend_Controller_Action ) ，因此在沒有事先定義好的狀況下， phpunit 就會回報錯誤了。

解決的方法很簡單，我們只要在 IndexController 類別的上方加入：

require_once 'Zend/Controller/Action.php';

就可以再執行 Create PHPUnit tests 指令了。

完成後， NetBeans 就會產生 D:\WEB\zf\unittest\tests\application\controllers\IndexControllerTest.php 這個檔案了。

測試 Controller

雖然前面我們產生了 IndexControllerTest 這個測試類別，但是它卻不能用來測試 IndexController 的流程。這是因為我們沒有去啟動 Zend_Application 及相關的 Resource ，所以這裡我們要借重 Zend_Test 提供的 Zend_Test_PHPUnit_ControllerTestCase 類別來幫我們進行測試。請將 D:\WEB\zf\unittest\tests\application\controllers\IndexControllerTest.php 的內容改為：

<?php
class IndexControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    protected function setUp()
    {
        $this->bootstrap = array($this, 'appBootstrap');
        parent::setUp();
    }
 
	public function appBootstrap()
	{
	  	$this->application = new Zend_Application(APPLICATION_ENV, APPLICATION_CONFIG);
	  	$this->application->bootstrap();
	}
 
    public function testHome()
    {
        $this->dispatch('/');
        $this->assertAction("index");
        $this->assertController("index");
        $this->assertResponseCode(200);
    }
}

在這裡我們要借重 Zend_Test_PHPUnit_ControllerTestCase 提供的 bootstrap 機制，幫我們處理有關應用程式設定與 Front Controller 等相關資源的啟動；然後我們就可以簡單地透過 Zend_Test_PHPUnit_ControllerTestCase 提供的方法 (例如 dispatch ) ，來幫我們測試 Controller 的流程。

上面的例子裡我們只很簡單地測試首頁，至於更進階的 Controller 測試，有機會我會再分享給大家。

進階的 phpunit.xml 設定

在 phpunit.xml 中可以設定的項目很多，可以參考官方手冊的說明，這邊我們簡單地探討幾個常用的項目。

testsuite

testsuite 標籤主要是幫我們透過 PHPUnit_Framework_TestSuite 去組織多個測試類別，例如以下範例：

<phpunit bootstrap="./application/bootstrap.php">
    <testsuite name="My App">
        <directory>./</directory>
    </testsuite>
</phpunit>

首先 testsuite 的 name 屬性是讓我們設定 Suite 的名稱，而 directory 標籤則是告訴 phpunit ，這個 Suite 包含了 D:\WEB\zf\unittest\tests 下所有檔名結尾為 Test.php 的測試檔案。

另外還要注意一點，在還沒加入 testsuite 之前，我們要在 D:\WEB\zf\unittest\tests 用 "phpunit ." 來指定目錄執行測試；而加入 testsuite 標籤後，我們就可以直接在 D:\WEB\zf\unittest\tests 執行 phpunit ，而不用再指定測試的路徑了。

filter

filter 標籤主要是幫我們過濾程式碼涵蓋範圍報告的項目，避免出現過多不相干類別的報告內容。 filter 分為白名單與黑名單兩種，以下我們以白名單為主：

<phpunit bootstrap="./application/bootstrap.php">
    <!-- 略 -->
    <filter>
        <whitelist>
            <directory suffix=".php">../application/</directory>
            <exclude>
            	<file>../application/Bootstrap.php</file>
            	<file>../application/controllers/ErrorController.php</file>
               <directory suffix=".phtml">../application/</directory>
            </exclude>
        </whitelist>
    </filter>
</phpunit>

這裡主要是告訴 phpunit 只處理 D:\WEB\zf\unittest\application 下的類別 (注意！不是 tests\application ！) ，但排除掉 D:\WEB\zf\unittest\application\Bootstrap.php 、 D:\WEB\zf\unittest\application\controllers\ErrorController.php 以及 D:\WEB\zf\unittest\application\ 下所有的 .phtml 樣板檔。

不過 filter 通常會搭配稍後要說明的 logging 標籤一起使用。

logging

logging 標籤主要用來產生測試報告，它支援相當多的格式，以下我們以 HTML 格式為主：

<phpunit bootstrap="./application/bootstrap.php">
    <!-- 略 -->
    <logging>
        <log type="coverage-html" target="./log/report" charset="UTF-8"
            yui="true" highlight="true" lowUpperBound="50" highLowerBound="80"/>
        <log type="testdox-html" target="./log/testdox.html" />
    </logging>
</phpunit>

在執行測試前，別忘了在 D:\WEB\zf\unittest\tests 下建立一個 log 目錄，避免 phpunit 回報錯誤。執行完測試後，就會在 D:\WEB\zf\unittest\tests\log 產生一個 testdox.html 檔案及一個 report 資料夾。

textdox.html 會以我們在測試類別裡寫的測試案例為名稱來做為驗證項目名稱，例如 testDoSomething 就會變成 Do something 。而用瀏覽器開啟 report/index.html 後，我們就能看到完整的程式碼覆蓋率報告。

小結

最後我們再整理一下重點：

• 我們可以在專案中建立一個 tests 目錄，供我們放置測試類別。

• PHPUnit 可以透過 phpunit.xml 及 bootstrap.php 來做自動化的測試環境。

• phpunit.xml 主要是用來設定 phpunit 執行時的選項。

• bootstrap.php 主要的工作是設定測試時會用到的環境常數、引入路徑以及類別自動載入機制等。

• NetBeans 對 PHPUnit 有強大的支援，不論在建立測試及執行測試上，都非常直覺。

• 即便不使用 NetBeans ，我們還是可以透過 phpunit 這個 CLI 工具來完成自動化測試。

雖然這裡我是以 Zend Framework 專案為主，但大家還是可以仿照這樣的機制，在自己的專案裡去建構自動化測試。

還猶豫什麼？快去試試吧！

為什麼要測試？

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

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

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

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

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

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

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

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

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

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

怎麼寫出好測試？

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

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

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

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

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

測試太花時間？

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

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

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

既有的程式該如何測試？

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

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

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

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

結論

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

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

這次臨時去亞太資安論壇，主要是因為 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>

主要可以看到木馬透過多個 <script> 標籤去組合，這會讓 Sever 端的防毒很難偵測出它的存在。

而這些 JavaScript 就會動態組合出所謂的 Exploits (或稱為 Dropper 及 Downloader )，讓特定的瀏覽器執行後去下載真正的惡意程式 (Malware) 。

因為這些 Exploits 是動態組合，所以不容易被偵測出來，因此要借重一些工具來找出真正的 JavaScript 。

Burp Suite 可以幫我們攔截網頁 HTML ，然後進行適當的修改 (例如把 JavaScript 的 eval 改為 alert ) ，讓我們能看到真正會被執行的 JavaScript 長什麼樣子。

圖解掛馬流程

一般掛碼分為三個步驟：

1. Cracker 想辦法攻擊某些網站的漏洞 (就是上面提到的三種途徑) ，並把 Url Generator 放到它們上面；通常流量較大的知名網站越容易成為被攻擊目標。

2. 使用者去瀏覽這些被攻擊的網站的頁面時，就會被導向置有惡意 JavaScript Exploits 的網站。

3. 當下載回來的 JavaScript Exploits 被特定瀏覽器執行時 (例如 IE6 ) ，就會再次連到另一個真正存放惡意軟體的網站將該惡意軟體下載回來執行。

偵測的難度如下圖所示：

因為 JavaScript 可以透過 JavaScript 來產生新的 JavaScript ，使得 Url Generator 及 Exploits 很容易變形，增加了偵測的難度。

Exploits 難以偵測的原因

• 目前的 Exploites 都做了模組化，不同的瀏覽器有不同的掛馬方式。

• 如果 Exploites 透過 Browser Agent 的方式識別瀏覽器的話，很容易被資安廠商透過更改 Agent 的方式偵測到。所以目前的 Exploits 大多都是透過瀏覽器支援的特性來識別瀏覽器，這樣就更能精準確認使用者的瀏覽器，避免被資安廠商的自動檢測掛馬程式給偵測出來。

• Exploites 也會先行利用偵測到的瀏覽器特性為 Key 來對自己的程式碼進行編碼，這樣就更能增加自動檢測掛馬程式的偵測難度。

Cracker 掛馬的難度

• 要讓被攻擊網站的安全檢測工具都檢查不出來。

• 在網路上的任何節點也不能被偵測到。

• 要隨時注意瀏覽器的漏洞。

• 必須知道資安廠商的 IP ，避免自己的網站被列入黑名單。

資安廠商因應的對策

• Web Application Firewall

• 使用白名單網址，判斷 Script 的來源是否合法。

心得

其實以前也研究過有關 IIS 與 ASP 的資安議題，也在實際上線的網站上被 Cracker 攻擊過，那時就覺得網站安全是一門很深的學問。

今天又在阿碼科技的 CTO 口中，瞭解了這些相當紮實且淺顯易懂的觀念，真是此行最大的收穫！

資安的世界真是複雜又有趣呀~

MADE IN LUKA 手創館自去年度就陸續協助本土設計師發展自己的創意品牌商品，這次超人氣職場部落客 i'm mark 也進駐賣起衣服跟馬克杯了。

現在買衣服還有送 i'm mark 紙喇叭喔。

雖然現在商品還不多，有興趣的話快到 MADE IN LUKA 的 i'm mark 專區看看吧:
http://www.madeinluka.com.tw/category/313

想跟豆花妹穿的一樣甜美可愛嗎? 到天母嚴選 Gotobuy 來看看吧: ^^
http://www.gotobuy.com.tw/templates/gotobuy/edm/100301-EDM/100301-EDM.html

雖然這樣的規劃聽起來不錯，但單元測試這件事說到底我的實務經驗還是太少，在這次的專案項目裡，才讓我真正有了較為深入的體會。

先對要測試的事情有一個概觀

其實測試一開始真的很難下手，主要是因為我們不知道我們要測些什麼東西。因此，我們需要對需要測試的東西有個概觀。

就以這次的例子來說吧，我要測試的東西就是「折價券攤提的演算法邏輯」，那它裡面重要的東西是什麼？

在跟客戶討論，我們得知折價券面額要分攤到的商品上時有一定的規則；這時我們就要先在紙上作業，用簡單的例子跟客戶確認清楚規則。

確認了方向之後，因為我之前已經測試架構準備好了，所以接下來就只要針對要測試的部份撰寫程式碼即可。但如果一開始還沒有準備好測試架構的話，這裡給大家幾個建置環境的簡易流程：

1. 在專案裡開個 tests 資料夾，這裡就是放置測試案例的地方。

2. 準備一個 init.php ，目的是用來設置 include_path 及 autoload 機制。

3. 按照 PHPUnit 官方的建議，建立一個 AllTests.php 的 Test Suite 。

註：這裡我就不列出程式碼了，讓大家自己試試看。

然後每次測試就用以下指令即可：

> phpunit AllTests.php

之後我會以「跑測試」來表示執行這個指令。

描繪程式的輪廓

接下來我們就要把整個系統的測試架構定義出來，不過這時候其實我們還沒開始寫程式，只是把流程和相關的方法先定義出來。

這裡的方法很簡單，就是先透過註解和方法介面來描述整個流程，而不是先寫細部的程式碼。

class Shop_Cart_Plugin_Coupon extends Shop_Cart_Plugin
{
    // ... 略 ...
 
    // 演算法計算後的結果
    protected $_sharedCouponData = array();
 
    // 取得演算法計算後的結果，也可供測試來驗證
    public functino getSharedCouponData() 
    {
        return $this->_sharedCouponData;
    }
 
    // 主要的執行方法
    public function doCheckout()
    {
        $this->_getCouponData(); // 取得
        $this->_getProductData(); // 取得商品資料
        $this->_initData(); // 初始化要攤提的資料
        $this->_shareCouponToProduct(); // 開始攤提
    }
 
    // ... 略 ...
}

當然這些都是大概的輪廓，因為可能在我們寫好測試執行時，會再額外加入新的方法及介面。

還有一個要先定義好的是測試用的比對數據格式，它對我們稍後要測試的程式寫法會有影響。

寫第一個測試

到這裡，我們就可以開始寫第一個測試，而接下來的程式碼，都是先以這個測試可以成功為目的。而這個測試要怎麼寫呢？就是把一開始我們在紙上作業的數字拿進來套用。

當然這裡我的 setUp 和 tearDown 也已經在之前準備測試架構時寫好了，它們會讓我們每次的測試數據都能夠獨立。我們關心的就是第一個測試案例：

<?php
class Shop_Cart_Plugin_CouponTest extends PHPUnit_Framework_TestCase
{
    // ... 略 ...
 
    public function setUp()
    {
        // ... 略 ...
    }
 
    public function tearDown()
    {
        // ... 略 ...
    }
 
    public function testDoCheckout()
    {
        $this->_plugin->setValue(array(
           1 => 1, // C1, ProductCoupon for P1, $100
           2 => 2, // C2, ProductCoupon for P1, P2, $100
        ));
        $this->_cart->addItems(array(
            'P1' => 1, // $200
            'P2' => 1, // $300
        ))->refresh();
        $this->assertEquals(300, $this->_cart->getTotal());
        $this->_plugin->doCheckout();
        $resultDataList = $this->_plugin->getSelectedOrderCouponDataList();
 
        $this->assertEquals(-100, $resultDataList['P1-C1']['discountPrice']);
        $this->assertEquals(-25,  $resultDataList['P1-C2']['discountPrice']);
        $this->assertEquals(-75,  $resultDataList['P2-C2']['discountPrice']);
    }
}

這裡因為我們在上一步就定義好比對用的數據，所以測試時就是用這個輸出的數據來與我們預期的數字相比較。

接下來就先跑跑測試，看看這個 TestCase 有沒有執行錯誤的地方 (例如物件沒有正確初始化或是變數名稱誤寫等等) ；當然如果沒有出現預期值是正常的，因為我們根本還沒有寫計算公式。

繼續完成演算法

現在回到 Shop_Cart_Plugin_Coupon ，我們就要把剛剛那些只有骨頭的方法開始添血添肉，這裡就請大家自行發擇。

接著只要你覺得程式差不多了，就先跑一下測試，看看是不是符合測試的預期結果。

當你完成第一個測試時，程式的就差不多完成百分之五十啦，到這裡別忘了先把程式 commit 到版本控制系統裡。

加入新測試並修改程式

完成第一個測試時，當然不是沒事了，我們要針對不同的狀況再加入其他的測試數據。

這裡我們就可以開始考慮把第一個測試以 PHPUnit 提供的 Data Provider 改寫，讓我們不必重複過多的程式碼。

<?php
class Shop_Cart_Plugin_CouponTest extends PHPUnit_Framework_TestCase
{
    // ... 略 ...
 
    public function setUp()
    {
        // ... 略 ...
    }
 
    public function tearDown()
    {
        // ... 略 ...
    }
 
    /**
     * @dataProvider provider
     */
    public function testDoCheckout($selectedCouponIdList, $productSkuNumberList, $total, $discountDataList)
    {
        $this->_plugin->setValue($selectedCouponIdList);
        $this->_cart->addItems($productSkuNumberList)->refresh();
        $this->assertEquals($total, $this->_cart->getTotal());
        $this->_plugin->doCheckout();
        $resultDataList = $this->_plugin->getSharedCouponData();
 
        foreach ($discountDataList as $key => $value) {
        	$this->assertEquals($value, $resultDataList[$key]['discountPrice']);
        }
    }
 
 
    public function provider()
    {
        return array( // 第一個測試
            array(array(
                1 => 1, // C1, ProductCoupon for P1, $100
                2 => 2, // C2, ProductCoupon for P1, P2, $100
            ), array(
                'P1' => 1, // $200
                'P2' => 1, // $300
            ), 300, array(
                'P1-C1' => -100,
                'P1-C2' => -25,
                'P2-C2' => -75,
            )),
            array( // 第二個測試
                // ... 略 ...
            ),
            // ... 略 ...
        );
    }
}

而加入新測試之後，就可以跑跑測試，看看我們剛寫好的演算法是否正確動作？通常這時候才真正是考驗的開始。因為這時候前面寫好的程式碼可能只對第一個測試正常，接下來的測試也許就會出錯了。

所以我們就會需要修改或重構程式碼，讓後面的測試也能正常執行。當然改過的程式也要讓第一個測試正常運作，才是正確的修改。

當然演算法寫好後，就要真正上到 Web 畫面去測試。至此，你會發現你花在寫測試上的心力都有了回報，因為通常如果你已經定義好介面，而這次的修改只是改寫一個小類別的話，那麼就會發現程式會非常順利地運作了。

心得

每次寫購物車時，最麻煩的就是測試時要開啟購物車網頁，把一個一個的商品加進來，再加入不同的折價券條件...

而有單元測試之後，我就可以省去一大堆開啟網頁，點選連結的功夫，專心地撰寫計算邏輯...只能說...單元測試真的個超級便利的工具呀。

在和Neo討論之後，想試試看"內嵌前台"方式來製作這次的管理介面，一開始思索了一下，首先是"如何進入管理模式"，一般正常的方式，不外乎就是進到一個有帳號&密碼欄位的畫面，輸入帳密之後，導向進管理後台，而這次想挑戰的內嵌式，當然要嚐試看看新鮮的寫法，相信有玩過魂斗羅的骨灰級玩家都知道，只要在一開始遊戲畫面中輸入上、上、下、下、左、右、左、右、B、A、B、A，，就可以得到30隻，對於想破關的朋友，莫不是一大福音，根據這樣的"取得隻數"的方式，"取得權限"亦可如法炮制，於是就出現了，魂斗羅內嵌Trihome的想法，在網站的任意位置，只要管理者突然有想進入管理介面的衝動，只要輸入密碼按下Enter，就可以神不知鬼不覺的偷偷進入管理介面，以下即為進入管理介面之後的畫面：

眼尖的朋友應該注意到了，在畫面上有隱約透露出神秘綠光的區塊，這部份是提示管理者，目前頁面上"即將被編輯的區域"，而點擊右上的綠勾，就可以進入真正的編輯區塊了，如下圖：

在編輯區塊內全部採取ajax即時更新資訊方式，讓管理者更能直覺的輸入修改資料。

在一開始構思的時候，本來預定是要真的在網頁上，即時編輯所有內容，不過第一頁就遇到問題了，在首頁的Banner，一次需要上多張Banner，系統判斷上下檔期後，要自動替換，那要可以即時編輯的話，難道要把全部已經上傳的圖都秀出來，版面應該會破的亂七八糟吧，所以才借助了blockUI，把需要編輯的部份通通丟在裡面，以不破壞原始版面為主；在這次撰寫過程，遇到很多問題需要解決，也連帶吸收了不少EXP，整個管理的方式進步空間還很大，不過算是處女作就....勉強算ok，未來有機會的話，可以再嚐試看看不同的方式，朝更人性、更直覺的設計介面前進吧~

三燔本家在網路上許多吃過的人都極力推薦，甚至可以說是一生當中一定要吃一次的店。經過哇寶挑嘴團這次尾牙的實地品嚐，雖然價格較高，但的確非常值得親身前往一探究竟。

有多值得呢? 從第一道菜開始沒多久，身邊陸續傳來同事們此起彼落的聲音「好好吃喔~」「嗯~這個真好吃」「喔~太好吃了」...(每道新的菜上來，重覆的戲碼也不斷的上演 XD)

(不只沙拉做的美味，連裝沙拉的碗都又脆又香，吃的不亦樂乎)

(極度受好評的開胃菜)

(生魚片好吃到大家都在用搶的)

(這道牛肉的料理鮮嫩多汁，對牛肉最挑嘴的 Jace 都大力推薦)

(龍蝦海鮮的美妙滋味實在讓人難以忘懷)

(這隻魚一出現沒多久就只剩下骨頭了 XD)

(燒烤的味道也不是蓋的)

這次的主角"和牛"更是不可少，甚至加點了一份頂級和牛來吃。

(用鍋底的蒸氣來吃，這真的是人間美味呀~)

最後的甜點水果一搬進來，真的就是異口同聲的「哇噢~~~」

(照片看起沒什麼，但現場看這個真的非常大一鍋)

雖然有遇到牛小排吃到飽的優惠，但同事有的不吃牛、不吃肉...點吃到飽的並不划算 (註)，所以這次以尾牙以三燔本家的套餐為主。以上的照片也只列出部份餐點，由於現場吃的種類很多，加上平常難得有機會吃到高級料理，只顧著吃都來不及了，能保持理性的人記得每樣菜的人已經不多了。XD

註:使用吃到飽的優惠，包廂全場的每個人都要加一份牛小排吃到飽的價格。

(最後每個人幾乎飽到走不太動了，飽到不行的合照)

今年大家也要一起好好努力，明年繼續吃大餐。^^

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

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

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

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

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

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

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

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

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

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

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

(第1名"天母嚴選"及第10名"御家族"正好都是我們的客戶)

我們非常了解網路市場的經營不易，因此對能入榜 Yahoo! TOP10 的商家都深感佩服。

在這邊也同時祝福台灣所有的電子商務網站在 2010 年能有更好的成績。TAIWAN UP!

相關網頁:
Yahoo! 奇摩2009之最

上線日期: 2009/11/30

沒吃過御海苔，等於這輩子沒吃過海苔。

御海苔有多好吃? Google 搜尋 "御海苔" 所出現的一大串團購、勸敗文:

小華兒愛瞎拼_【團購】御家族的御海苔~忍不住想吃咧

喵喵の簡單生活 ::【團購】御家族的味付海苔&手工達人之黃金蛋捲

[團購]板橋市。寬泓御海苔@ 佳莉。心情:: 痞客邦PIXNET ::

yumi的隨意札記: 【零食】味付御海苔- yam天空部落

御家族除了海苔很有名之外，陸續推出了許多不同種類的零食。

這次很高興能有機會跟御家族的團隊合作，他們真的很在乎每一位網友的反應，對於自家購物網站也要求一定要做到最好、最方便訂購。

御家族網站在2009 年尾很順利的上線了，但偷偷告訴大家，這個網站的重頭戲還沒來，2010 年初將提供一般購物網站難得一見的新功能，敬請期待。

御家族官方購物網站:
http://www.ace-88.com/