這周主要目標的第三和第四題的重新練習，不過因為最近開始在研究一些新的框架和技術，所以除了先前的解法外，也打算試試用新的語法來解題，PDO是最先想到的改變，PDO是目前PHP官方推薦的資料庫連線方式，除了安全性的強化之外，最主要的改進就是對於多種資料庫的相容，以往如果要連接不同的資料庫，就得使用不同的資料庫語法，mysql的話是一連串mysqli_XXX的函式，PostgreSQL的話就是一堆pg_XXX的函式，如果將來有可能更換資料庫的話，那整個程式的語法都得改，PDO的功能就是整合連接資料庫的介面，只需要一套語法，就可以對應各種資料庫了。

之前一直沒有碰PDO是因為對物件導向的操作有點恐懼，不過最近在接觸的東西幾乎都是物件導向了，無法再逃避了，所以利用解題的機會直接就拿來使用了，由於PDO只有資料庫連接的部份算是使用了物件導向，其它的部份並沒有需要也跟著改成物件導向，所以其實我只花了半小時了解一下怎麼連接資料庫和撈資料後就上手了，解題不需要利用到預處理的機制，所以那塊我就先跳過了，這樣使用下來其實也和之前使用mysqli_的方式沒有太大差異。

使用心得上，我覺得對比之前的做法，PDO的一些函式用法的確簡化了一些程式的撰寫，整個結構也不會太亂，甚至因為可以少打一些符號和指令，我反而覺得在解題上使用PDO還比較快一些，比如之前在做分頁時，如果要計算總筆數，我會一行式的指令來寫；

$total=mysqli_num_rows(mysqli_query($link,”SELECT  * FROM post”))[0];

改成PDO之後的語法會變成;

$total=$pdo->query(“SELECT * FROM post”)->rowCount();

sql語法的部份並沒有什麼不同，但是在函式的應用上，從原本的一個包一個的語法變成直接用物件來取用，習慣之後其實縮短了不少打字時間，另外，像是PDO滿鼓勵直接用fetchALL()的方式把撈出來的資料丟到陣列去處理，雖然原本也是有mysqli_fetch_all()這樣的用法，但是一般坊間的書或課程很少有提這種用法，以我今天在解第三題的首頁動畫部份來說，如果是傳統的方式，我在海報主圖和按鈕的地方要分別去撈兩次一樣的資料，這其實滿消耗資料庫資源的，我今天的解法就改成直接fetchAll()到一個陣列後，直接在兩個地方把陣列的內容拿來使用就可以了，不用擔心資料指標的問題。

至於第三題的解題心得部份，因為這陣子在接觸canvas的操作，所以對jQuery的使用有些新的心得，因此在做動畫的部份，我也改了做法，原本是利用函式直接在DOM中找到元素再做字串處理再丟去放動畫，這樣其實要了解不少DOM的尋找，字串的取代技巧等等，我的新做法是直接把DOM的id和對應的動畫做成兩個陣列放在script區域中，這樣就不太需要去管DOM的部份，專心在陣列的操作上就可以了，程式架構就簡化不少，不過今天還是有遇到一個比較卡關的問題，就是jQuery的animate()這個動畫函式只能操作數值型的屬性，非數值型的屬性是起不了作用的，比如顏色；另外也發現一個字型的問題，當字型被縮到系統預設字型大小時，似乎就無法再縮小了，比如我想做一個字型由50px縮小到0px的動畫，然後發現字型到了12px時就停住了，等動畫跑到0px時字就直接消失，雖然這點小問題對解題成果來說不是什麼會扣分的要素，不過我倒是花了快一小時在研究這個問題，最後能用的解法就是使用CSS原生的動畫方式來解決。

接下來的幾周練習，我都會開始把一些新的做法直接帶入乙級的解題中，試試看能不能找到更快速的解法來

今天嘗試著重新解第一題時，發現無法在四小時內全解完，雖然及格應該是沒問題了，但這成了一個警訊，結訓後的這兩個月，我練打程式碼的時間的確少了很多，速度和應變上慢了不少，距離學科試大概還有七周時間，術科考試暫抓十周時間，扣掉工作的日子，一周大概剩四天可以準備，再扣兩天用來淮備上課要用的東西，實際可以用來備考的時間剩下一周兩天左右，想想不提早規劃一下，等到應考前一個月再來操心肯定來不及了。

目前算了一下日期，暫時的規劃如下：

1.每周練兩個題目一至二次，比如這周練一，二題，下周練三，四題，一題要大概四小時，一天練兩題就要八九個小時去了；

2.每天學科一百至兩百題，如果自己的學科系統來不及完成，就先用士商的線上試題系統來練習，一天兩百題大概也要一小時左右的時間；先做循序的題目練習，把一千兩百題都練上一兩次，等考前兩周再開始混合作答，一樣每天一至兩百題的量。

目前每周還會利用時間去解全國競賽的題目，所以時間算是排滿滿的了，充實。

網頁設計乙級術科解題網

這一個月主要在忙著找工作及利用閒餘時間把這個解題網站做完，目前算是完成0.1版，把概略的解題想法及原始碼都放上網站了，接下來會再利用時間研究更精進的解題方式，並完善文字及圖說的內容。

最近也在導師的安排下接觸了一些和推廣乙級證照有關的工作機會，如果其它工作還是沒什麼消息，那麼接下來這一年就打算往教育方面的工作來嘗試看看。

昨天晚上花了點工夫把第一個版本的解題成果都上傳到github去，順便熟悉一下git的指令，然後果然發生一些狀況；

第一個狀況是第三題的影片檔當初轉檔的格式錯誤，所以檔案很大，整個專案快300mb就這樣被我傳上去了，後來改了格式，而且也把原始資料加入忽略清單，重新push後發現專案更大，原來是我忘了版控系統的最重要精神就是保留一切的修改紀錄，所以雖然我在本機上置換檔案，但是在版本紀錄中還是有我原本的檔案在，解決方式在git中很簡單，就是把隱蔵目錄.git砍掉，同時也把github上的專案刪除後重建，這樣再重新push後就是新專案的大小了。

第二個狀況是github在開新專案時，可以選擇要不要先初始化並建立一個readme.md檔，如果我選擇了初始化，就會push不上去，如果不初始化，照它給的引導說明就可以push上去，這原因合理，因為我在github上有了一個readme.md檔，但本地端沒有，所以兩邊版本內容不同的狀況下會無法push，所以我先做了一次pull想把readme.md拉下來做合併，結果拉不下來，上網google了不少資料都沒找到符合我狀況的解答，雖然用 push -f 強推上去也是可以的，但這樣就把會readme.md這個檔給蓋掉，花了兩個小時才找到原因，而且這個解決方式還是git在pull不下來時就有給了，只是我當時懶得去細讀英文的說明；這個狀況是因為git較新的版本不允許沒有同主支的分支做合併，而我在github上開的新專案和我本地端剛建立的新版控目錄都是獨立的新master，所以git認為這應該是兩個不同專案而且沒有關聯的東西，不應該合併；解決方式是在pull時，加上 –allow-unrelated-histories 這個參數，這樣就可以把沒有關聯的兩個分支合併在一起，之後再push上去就可以了成了。

把專案放上github後，之後要做本地端的練習或更新就簡單許多了，不然之前每練習完一次就要備份一次目錄，浪費不少空間，現在改成git來管理後，只要在每次有較大變動時做一次commit，就可以建立起一個版本，而且只會紀錄有變動的部份，也可以利用分支的方式來管理一些多元解法的動作，不再需要用多個版本或註解片段的方式來管理。

我的github網站

第四題相較前幾題來說，就是個比較複雜，但難度中等的題目，最大的挑戰是來不來得及做到及格，而不是會不會做，因此在解題上，可能更需要一些策略，這是我在考前最後一次練習才想到的，可惜沒有足夠的時間去執行自己的策略，以致於在真的考試時變成來不及，在經過前三題的磨練後，第四題真的沒有什麼難度，只剩熟練的問題而已，而第四題我覺得可能在設計上是針對framework的開發方式而有的題目，採用framework的話可以大幅的減少在資料表的存取動作上，進而縮短整體的解題時間，只是我們最終沒有教到任何一套framework的使用方式而已。

在解題流程上，我後來實際考試時的做法是想先把首頁的選單及產品頁先做出來，這樣可以直接把購物一路做完，之後再去處理後台的部份，因為第四題的後台比較麻煩，而且不是那麼好拿分，因此前台的選單我是直接開資料表後，手動增加產品項目進去，這樣可以很快的把選單做出來，而產品的部份也是開好資料表後，直接手動新增八筆資料進資料表，這邊會花點時間在填產品的大分類和中分類上，不過比起花時間做新增產品的頁面來說，我是覺得這點時間還是划算的，因為手動新增完商品後，整個前台購物流程100多分就入袋了，接下來是製作註冊會員和管理員登入的部份，這邊做完就可以先去做管理員管理及功能權限的部份，然後因為購物功能做完了，所以訂單管理也可以做了，再回來做頁尾版權及最新消息這兩個算送分的動作，最最後才是後台最多分的商品分類及商品管理的部份，這邊因為選單和商品的資料都己經先手動新增好了，所以至少列表出來的動作可以很快的完成，刪除及修改的功能也可以很簡單的做完，至於新增就看時間來不來得再做，如果時間來不及，那寧可先把去會員管理的頁面做出來，這樣大概就可以確保在及格的水準了。

利用jQuery來操作DOM配合ajax可以簡化不少動作

購物幾乎都是用session來處理，減少對資料表的操作

在架構上，我目前也沒什麼好的精簡做法，原則上是一個功能一個檔案來做，只有api會整合在一個檔案中，不過我的檔案數大概是25個檔，但老師的解法好象用上了40多個檔案，我覺得那麼多檔案的操作，肯定是來不及做到及格的，就算用dreamweaver在那操作資料庫，但是前端要手動去調整的部份也不少，快不到那去，所以如果來得及準備，下一次的考試，我第四題應該會採用framework來解題，因為framework大多把一些常用的操作都先包好了，所以只需要專注在資料的處理及頁面的建構上就可以了。

整體來說，我是認為第四題如果是要採用原始PHP的語法來解題的話，那真的要花很多時間去練到很熟才有辦法，我在考試時，當時在選單的部份自己因為放錯tag的位置所以花了快十五分鐘在debug，以致於之後的解題自己也慌了，即便如此，我最終也大概是解到正三十分的成績，再多個半小時做完購物或訂單管理，就有機會及格了，所以嚴格來說也不是鐵板一塊。

第三題相較一、二題，難度直接提升了兩倍以上的難度，這難度的來源是因為在整個職訓期間，並沒有對前端的動態效果做太多的學習導致的，後台的部份大多數都是簡單的存取控制，不難但會花時間，前端的兩個難點一個是轉場效果的製作及訂位功能中的關聯選單功能需要透過較複雜的JS來完成，而整個課程設計中，對JS的著墨是比較少的，我和幾位同學也是在自己解第三題的過程中去加強對於JS及jQuery的認識與操作，大概需要練習個三次左右才會熟練，而第三題打下的解題基礎，對於第四題則會有相當的幫助。

在解題流程上，我後來的做法是先處理前台的三個主要功能，因為這三個功能做完基本上就不會負分了，而後台可以放棄任一個不做也可以及格，因此解題策略上會先前端再後台，而資料來源則是直接以手動新增的方式一次把所有的資料手動新增到資料表中，然後再把圖檔及影片直接複製到對應的目錄下就可以了，第三題只需要三張資料表就可以搞定了，而新增及修改電影這兩個功能則是花時間但分數少的項目，不需要花時間去處理；

首頁的動畫以jQuery來製作可以少寫很多程式碼，但是因為原本的區塊設計的不是很好，所以這邊要自己背一下相關的版面結構語法及CSS，而動畫的部份我是把三個動畫做成一個函數，要取用時就代入目標id及動畫代碼就可以了，這樣的設計可以讓自動播放和按鈕切換都用同一個函式來處理轉場效果，省事不少。

動畫使用的函式以jQuery的方式來製作

訂位功能比較煩一些，其中有三個動作中包了九個小動作，但合計卻只有15分，一開始的選單部份因為是互有關聯的，所以這邊需要透過jQuery的ajax功能來製作會比較方便，如果要用純php來製作的話需要多做很多判斷，時間上來不及，因此會在api的部份開兩支分別來取出電影日期及場次座位，另外為了方便API的作業，在選單的操作上也會把所有的選定項目分別寫入session暫存，這樣在api那邊就不用再去資料庫撈一次資料出來；

訂票選單的部份會因為前一個項目的不同而有不同的變化，因此採用ajax的方式來處理

解決選單後進入劃位畫面時，版面的結構也是要背一下的，因為版型檔案並沒有提供相關的語法，這邊就各憑本事了，有人用表格，有人用巢狀迴圈，我自己是用CSS的語法去限制座位的寬度，然後用一層迴圈及算法來解決排列及顯示座位的文字；這邊還需要先去撈出已被訂走的座位，我的做法是先宣告一個長度20填滿0的陣列，然後再從訂單資料表中撈出該場次的訂票紀錄，用迴圈的方式把每個被訂走的索引位置改成1，最後在畫座位表時，每個位子都檢查一下對應的陣列位置是不是1，如果是1的話，我會把class換成另外一個有不同背景的class，並把checkbox隱藏；最後這頁還需要處理劃位選擇的問題，劃位的判斷我是用jQuery來處理的，這一頁要處理的事不少，要解得順手，就是多練幾次，把程式碼背熟來應對。

劃位紀錄的部份我是採用陣列的方式來處理

劃位檢查使用jQuery來處理

後台的部份比較簡單，使用表格來處理版面會簡單許多，但現在市場上己經不太建議使用表格來做版面配置了，只是應付解題，表格是比較快的做法，其中資料排序的問題我是採用ajax的方式來處理，把排序資料送到 API去交換兩筆資料的排序編號，處理完後再刷新頁面，就可以看到排序完的結果，預告片及院線片的兩個後台我都用同樣的一支API來處理，而排序的資料我是採用在新增資料時去取排序欄位的最大值＋1的方式，這樣可以確認每筆資料的排序關係是相連的，這比起老師用的先放一個定值再去加加減減要來得有保障一些，不過如果是實務上的話，會再另外判斷如果排序中有間隔時要如何補上(比如有資料被刪除，造成該位置為空)，在解題時不需要考慮這些額外的狀況，只要在展示時小心點就好。

資料排序有往上和往下兩個功能，分別以不同的type來識別。

在檔案結構上，第三題並不建議整合在單檔，怕程式碼太亂，不好管理，所以每個功能都單一個檔來處理就好，首頁的部份可以都寫在一個檔案中，也可以拆成兩個檔再include進來，api會是比較吃重的部份，需要練熟的地方也是api比較重要；第三題的另一個麻煩的地方是所附的版型檔案中的CSS，它設定的字型大小及按鈕間距，絕對不適合在1024×768的版面中呈現，具體來說二，三，四題附的css檔都不在1024×768的規範內，到底要不要去改這部份的設定讓人很糾結，在實際考過後，考場的實際狀況是監評委員並沒有去看前三項動作的內容，也就是包含版面大小及版面結構，而是直接從第四項的細部動作開始看，但我們也不確定是不是所有的監評都會這樣評分，這部份只能等命題委員自己發現後做修正了，在我自己的解題上，我是會花個十來分鐘，把附上的 CSS做些修改，讓字型和間距可以在原本的版型檔案中比較好看一些。

整體來說，第三題要做的麻煩事都是前端的部份，所以jQuery和css的部份一定要很熟，時間上才會來得及，克服熟練度，第三題就還好了，畢竟我們班這次就有一位同學是第三題及格的，已經驗證了第三題不是鐵板一塊。

第二題開始的題目描述就有些不清楚了這部份感覺是要自由發揮的感覺，根據考過的同學表示，監評委員在看的時候並不見得會照著題目一字一句的去檢查，所以真的在評測時，自己要掌握好展示的流程，不要把題目沒有的或交代不清的內容也展示，自找麻煩而已，當然也有可能會遇到很嚴格的委員字字計較，要你一直重覆做功能展示，這時就只能靠真功夫來展現了。

第二題的題目設計上，後台比較簡單，前台要做的事略多，沒有完整的後台功能，所以像文章或會員帳號都是可以先手動增加到資料庫的，所以在解題流程上會先處理登入註冊及後台的部份，再去處理問卷調查的部份，接著是首頁頁籤的功能用DreamWeaver拉一拉就好，但如果不是為了考試或時間足夠的狀況下，我比較建議頁籤功能自己寫會比較乾淨一些，DreamWeaver會另外增加一些CSS和JS的檔案進來，在操作時要確認檔案的連結是正確的，免得展示出錯，最後再去處理分類網誌，人氣文章和最新文章的顯示，其中分頁功能後台一個，前台兩個，所以分頁功能一定要做出來，然後複製貼上兩次，改一下路徑就有15分了，cp值不錯，最最後有時間再來做按讚和點擊後顯示詳細內容的功能，這樣的流程可以確保穩定拿到分數，而不會因為麻煩的地方卡住了而影響整體的解題步調；另外，第二題強烈建議使用大量的jQuery ajax功能來做資料庫的存取及前端的顯示功能，會非常省事及有效率。

jQuery的使用，可以簡化文件的程式碼邏輯，讓api集中在一個檔案來處理

在解題架構上，除api.php及login.php之外，其他功能我還是以單檔的方式來處理，這是為了解題順手的考量，如果真的很熟練了，把檔案都整合在一個檔案也是可以的，因為參照原本版型提供的線索，大概可以推測出來，原本的題目設計要不就是整合在一個檔案中來呈現，要不就是使用framework來處理所有的頁面構成，所以才會頁面連結幾乎都是用參數來處理的狀況。

資料表的部份，如果沒有要做按讚的功能，就不用開log資料表，而文章相關功能因為題目沒有說明，所以有看把分類網誌的文章和最新文章分兩張表的解題法，這種解題法明顯只是為了把結果弄得和題目的示意圖一樣而已，不過因為題目沒講清楚，評委也扣不了分數就是了，我是只開一張post的表，然後手動新增八筆文章資料進去，多一個分類的欄位，所以分類網誌，最新文章和人氣文章我都用一張表來處理；而問卷調查的資料表我也只開了一張表，一樣用parent欄位來表達題目和選項的關係，這樣的結構用來應用解題是足了，大型問卷系統才需要考慮是不是要拆成兩張表來管理。

只以一張資料表來處理問卷的題目和選項

整體來說第二題是比起第一題簡單的題目，因為比較麻煩的按讚這項功能只佔了十分，不做也影響不大，而問卷功能並沒有要求做會員資格的限制，比如一位會員只能投一票之類的要求，這讓問卷調查的功能只剩下要花時間做頁面而已。

第一題是四個題目中，題目設計比較完整，而且附的版型檔案及CSS也是最不需要去改動的，甚至一些前端的動態效果的Javascript都先寫好了，所以在解題上，就只要專注在後端的管理功能及前端的資料顯示即可。

第一題也幾乎是唯一可以單純使用傳統PHP+MySQL就可以一路順順的解完的題目，因此老師當時還有建議直接安裝舊版的PHP，然後用DreamWeaver拉一拉就可以了，聽說之前的幾次檢定，大多也都是抽中第一題的考生可以做完題目，並且也是透過DreaｍWeaver來完成的；不過我個人是覺得，為了考證照去使用市場上已經不太使用的解題方式，那麼這張證照考到了又能代表什麼？所以很慶幸的是，這次參加考試的十五位同學，最終大家都還是使用Notepad++或PsPad之類的純文字軟體來進行解題。

第一題主要測試的重點是資料庫的新增／修改／刪除的功能，以及圖片上傳和分頁的功能，雖然要求的動作項目很多，但都是基於CRUD(Create,Read,Update,Delete)而來，因此，九個後台的功能項目中，有五個功能項目是可以用同一套語法來處理的，而真正會花到時間去單獨處理的，只有選單管理的功能而已，因為選單管理還有次選單的部份，而題目中的次選單功能設計的不是很好，只是為了符合題目要求，要另外花時間去處理。

在檔案結構上，除了素材附的四個檔案外，我只另外新增了三個檔案來處理所有的功能；

api.php-所有實際對資料庫進行請求的程式碼都在這個檔案中處理，以switch case的方式來整合多個功能項目。

內容幾乎都是PHP和SQL語法 ,只負責接收和回傳資料，很少處理顯示的部份

view.php-所有利用原本附的彈出視窗進行的新增功能的畫面元件都放在這個檔案中，包括圖片更換的功能也是集中在這個檔案，一樣是以switch case的方式來整合。

main.php-和view.php很類似，只是這個檔案是用來顯示後台管理頁面中的各個功能項目的畫面，只有包含讀取資料的Sql語法，大多數內容還是以HTML為主。

所有的顯示語法都集中在一個檔案中，利用switch case來做切換顯示

另外，由於素材提供的版型檔案都各自有一個目錄，第一題雖然沒影響，但後面幾題會去動到CSS時就很麻煩，所以我會在考試一開始時，花個幾分鐘把CSS和JS另外拉出來放在對應的目錄，然後再去修改版型檔案及CSS檔中的相關路徑，這樣如果有需要改css時就不需要每個目錄都開起來改了。

我的解法讓我在檔案管理上會比較輕鬆，就算是同質性的功能要複製貼上也是在同一個檔案內複製貼上，所以我幾乎可以在兩小時內處理完第一題的所有畫面元素並準備好資料表。

利用相同結構的資料表設計，來簡化程式撰寫時在SQL語法上的調整

然後說一下選單的部份，第一題和第四題都有針對選單的動作要求，老師的解法是分成兩張表，一張負責主選單，一張負責子選單，但這個做法在第四題需要額外去撈取每個分類的產品數時會遇到多表查詢的困難，最後老師還用上了子查詢，但我覺得這對同學來說是真的有難到，針對解題的部份，我是只用了一張表，然後多了一個’parent’的欄位，parent=0時就是主選單，parent=x時就是次選單，而x就是其上層的主選單，這樣我只需要操作一張表就可以了，簡單許多。

最後是版型檔案的部份，第一題的版型檔案是最完整的，連Javascript的部份都有附上，只要資料叫出來放在對應的地方就可以了，不過要求完美的人一定會發現這幾支js都有點小bug，如果時間夠，稍微調整一下就可以了，比如選單的js在一開始時不會先自動隱藏子選單，校園映象區的圖片換頁張數計算有問題，新聞的彈出詳細內容的javascript冒泡機制沒有處理好，動畫輪播的JS程式碼區段放錯位置等，如果解題時間有多個十分鐘的話，可以把這些小BUG修整一下。

結訓後一周了，目前丟出去的履歷約十五份，只有一份有通知面試，還要再努力。

這一周除了寄履歷表外，比較重要的工作就是把四題乙級術科的題目重新整理一下解法，把自己認為可以簡化或好記的解法定版下來，這花了我不少時間，和練習解題比起來，練習時求速度，有些解法並不會去考慮效率或邏輯，只是先用自己想得到的做法先撐過去，所以事後發現其實沒有省到時間，只是當時的腦子能想到的也就只有這解法了；重新整理後，有些比較囉嗦的流程做了簡化，比如我會用大量的一行式指令來取代之前老師教的三行指令，這在實際應考時，可以省下不少時間。

各題的解法心得過陣子我會一題一題的再寫出來，原則上，一二題是比較簡單的，而且我也把要編寫的檔案數做了相當程度的縮減，在準備上已經沒有難度了，第三題前端的部份比較麻煩，但其實jQuery的部份說穿了就是背熟就好，倒是素材提供的版型CSS實在很醜，到底應考時要不要去改CSS這我還要思考一下，第四題其實每個動作要求的都不難，但第四題的麻煩在於要串的頁面很多，也很難用一二題的做法拚在一個檔案去處理，所以第四題的簡化我還是很傷腦筋，不過第四題是可以選擇性放棄幾個麻煩的動作，先以及格為目標；總的來說，一，二題我覺得用傳統的PHP解法老老實實做就可以在時間內做完了，但三四題可能要用framework的方式來解題才會快一些，這也是我接下來要自己進修的方向，因為很多職缺也都要求要會使用framework，而乙檢的素材中是有附上cakephp,codeiginter兩個framework，我前幾天也有試了一下，感覺在資料庫的取用上，可以省下不少工夫，這對第四題的解題來說是有幫助的。

乙檢成果展示網站

最後我也把這周重新整理的四題解題重新上傳到網站去，目前這個分站只有放上四個題目的解題成果，未來希望能把完整的解題邏輯，方法也都放上去。

這是幫班上的同學代發的心得文，這次抽中第三題還能堅持到最後並取得證照，實在優秀，更優秀的是100天的課程沒有請過假，全勤到底，從純文組的背景在一百天的課程中成為可以熟悉並靈活運用程式語言的工程師，下的工夫絕對是超出想象且值得學習的。

——————————————————————–以下正文—————————————————————————–

乙級術科解題心得
一、 總論
        大致上，我自己做每一題都至少會做三遍以上，而且每次練習我都會盡力去做並且”計時”，因為這樣才能知道自己有沒有進步，自己嘗試的方法有沒有效果，我覺得這是很重要的，而且盡量同一個時間專注在一題就好，雖然同一題做很多遍
    可能會有點煩躁，但是我會專注在可以提升速度的改變上，專注去思考可以更快的方法上，如果能夠想出來，那就是有很成就感的一件事。
    每一題做三遍的過程中，第一遍通常是熟悉題目的要求和功能，也熟悉網站的架構和流程，所以第一遍通常會花比較多的時間(像是第一題我花了8小時、第三題花了3天…)，但這是一切的基礎，所以不要怕麻煩，要去了解每一個細節；再寫第二遍之前，我會在第一遍的基礎上，按照自己的想法來精簡流程和架構，想出自己覺得更快的作法，然後一樣進行第二次的計時練習。第二次練習的目的，就在於驗證自己的想法，確認自己想出來的解決方案是符合要求和時間。
        同樣的，再第三遍開始以前，我會把第二遍做的過程和最後的結果，進行一個檢視和調整的作業，把過程當中不夠順暢、不夠簡潔的地方都再一次修改，最後同樣是抱著通過4小時的心情來驗證自己的程式碼…。不用害怕做很多遍，第一題我不熟悉的時候做了5遍，但是有時候想不到好方法的時候，也不用一直鑽牛角尖，可以嘗試看看別人的東西，多接觸不同的想法，或許就會有更好的靈感產生，所以交流真的是很重要的!!
        最後要提醒的是，練習的過程其實不是無腦的練習，對我來說，除了熟悉流程架構、驗證自己想法以外，我還會不斷思考有沒有重複出現的形式(pattern)，如果有，那就是可以簡化的部分，像是第一題，第一次做的時候覺得東西很多、很繁雜，所以直覺就是需要一個SOP來簡化流程、確保過程不要遺漏；後來不斷練習之後，覺得第一題後台的東西，也不過就是簡單的增刪改查，(這就是一種pattern，要掌握相同、反覆出現的部分來加以簡化)，會變化的也只是樣式或類型而已，再更進一步說，其實後台就兩種類型，一種是檔案上傳的類型，另一種是一般文字的類型，所以我的流程規劃就會是相同類型的檔案一起做(先做檔案上傳類型，再做文字類型的)，這樣可以避免腦袋打結和混淆；再來又發現，其實他們的欄位都很相似，所以我就從欄位的設計下手，把他們的欄位做相同的命名，有變化的只是他們的前綴，所以像是圖片就會是：pic_name、pic_text；文字就會是：word_name等等，這樣命名的好處就是，後台各功能的增刪改查的語法其實都差不多，有差別的也只是table名稱和欄位名稱不同而已，所以我就想如果要更快的話，就可以利用「搜尋和取代」的功能，來迅速地替換程式碼不同的地方，只是這有個前提，那就是命名一定要有個規則來處理他，這樣在取代的過程中，才不會自亂陣腳，不會不清楚自己到底有沒有取代成功，或是不清楚自己取代到了什麼…。
        以上分享就是在說明我發現pattern、簡化程式碼、簡化流程的一個過程，這當中其實需要很多的思考和設計的，這都是息息相關的，所以我很能體會林老師上課提到的，跟客戶要先確認架構和功能，還有修改的範圍和次數，否則我架構、db都設計好了，客戶來個大修，那我豈不是要全部從頭思考一遍?
        總之，我想說明的就是，大家在練習的時候，不要只是無腦的練習，其實要注意有哪些地方是反覆出現的，那就是可以簡化的部分，如果自己對於程式語法、相關技術有一定了解，那能夠運用的技巧或技術又更多了，所以不管是劉大哥或解題影片的方法，都是把增刪改查的方法包裝成一個api或function，然後透過傳值、傳參數的方法來實現功能，這也是很棒的方式，同樣都是把相同的過程提煉出來，但是每個人可以有不同的解決方式，我覺得這是很棒的地方，大家相互交流就能學到新東西!!
        其實我鼓勵大家跳脫考試的框框，對我來說，我自己也很討厭重複做一樣的題目，但是大部分的時候我沒有把他當成考試題目，我把它當成一個挑戰，因為考試是一時的，但是我學到的技術就是跟著我的，所以當我能夠把學到的技術整合應用在考試上，然後真的把流程更簡化，那開心的感覺是不可言喻的，心裡會更踏實，因為知道自己又成長了。老實說，我覺得考試要能提升速度，關鍵不在打字速度，關鍵在自己的思維能力、邏輯能力，程式碼的架構和流程更簡單了、更直覺了，那自然寫程式的速度也就快了，大家不要覺得自己不行，其實這是可以透過訓練來達成的，還記得我說過我第三題花了三天嗎?!那時的我也覺得第三題很難啊，我也覺得自己才能不夠用啊，但是當我慢慢消化、一點一點理出頭緒，雖然很緩慢，但是我慢慢就看到希望了。其實碰到這種問題才是好的，難的題目才能學到東西，因此當我第三題多做幾遍之後，再回過頭來看第一第二題，怎麼看都覺得變得很簡單，因為第一二題跟第三題的速度是不一樣的，雖然都是增刪改查，但是在經歷第三題操過幾遍之後，就會深深覺得第一二題東西真的少很多，這時候就會知道自己的能力提升了。
        當然，有時候我也深深自覺自己的能力不足，所以除了上課以外，我自己也會在網路上找更多的影片或資源來學習，因為我想學到更多的技術，想解決更多的問題。勉勵大家一起努力，真的想走這條路，就要下一定的決心，付出一定的真功夫。

二、 第一題
        其實第一題上面已經講了差不多了…。這邊大概補充一下就好，基本上，第一題後台的部分我大概會花2.5小時，前台的部分大概1小時。後台的部分如上所述，我會分成兩個部分，一個是檔案上傳的類型(包括標題圖片、動畫圖片、校園映像圖片等)，另一個是文字類型(就是其他的功能了)。基本上，不管哪個類型，其實只要把各類型第一個樣板做好，之後就只是複製取代而已。我覺得需要注意的就是命名要清楚，這樣取代的時候才不會有問題。(這邊是以複製取代的作法而言，如果有其他方法請自行掌握)
        至於前台的部分，其實素材檔把前台控制的js或樣式都寫得滿完整的了，需要做的功課就是要先了解js的功能和設計，這樣才能進行套用，如果了解它運作的架構之後，套用起來就非常容易了，所以我說前台1個小時完成不是說說而已，是絕對可以的。但是!!一定要徹底了解他的js原理和樣式喔!!不要只學怎麼套用，這樣一點幫助也沒有!!

三、 第二題
        第二題感覺沒什麼特別的耶…，我覺得可以用來練習jQuery，把本來可以用js寫的部分用jQuery來操作。然後這題有些地方我會用URL參數來處理，這樣我覺得比較直覺又簡單，像是分類網誌、投票，然後再搭配table欄位的安排，其實就能有效的簡化一些流程了。
        其實有時候方法沒有很難，簡單的技術一樣有功效，只是懂不懂的運用而已，方法沒有高下，只是有沒有效而已。
(我稍微修改了一下register驗證，還有logout的地方)

四、 第三題
        第三題相對其他題目是比較複雜的，這裡我只會以考試方法來說，至於更細節的程式部分，請再自行看我的雲端(點我看連結)。
後台的部分，比較花時間的就是電影的新增和修改，所以在考試的時候我會直接放棄(總共才10分而已)，直接建立db和檔案資料夾(movie)，把影片(記得要先轉檔，用adobe的media encoder轉成mp4，考試的時候，環境設定的90分鐘就已經有素材檔了，可以在那段時間裡面先轉檔!)和圖片先複製到movie的資料夾，然後我會更名成簡單的數字(像是：1.mp4、2.png，可以利用F2和tab來快速改名)，最後再db先鍵入一筆資料，再用phpmyadmin的複製功能讓資料快速增加，最後再修改資料，像是：預告片和圖片、電影名稱等等，目的是讓他們呈現在前台的時候有差異性，至於一些不太重要的導演、簡介等等，我個人覺得沒差，大家自己斟酌。

        後台大部分沒有太多的困難，只是有點雜亂而已，想清楚自己的架構、流程和程式碼，要掌握應該不難。(後台全部差不多要1.5個小時左右)
        前台的部分，動畫其實很好掌握，只要熟悉jQuery的動畫，還有一些相關語法，基本上就不會被扣到分數了，大家仔細看題目就會發現很好拿分。這部分我覺得比較重要的是練習樣式的調整，首先一定要能調整出大小圖的比例和位置，這部分只能靠大家自己練習了。基本上，我考試不會去背這些調整的參數，我都是靠平常練習和臨場反應的，這部分記得要多用F12來檢視和調整(雖然樣式有時候不好理解，但是基本上他都是有邏輯的，只要理解他的邏輯和用法，掌握上就不難了；如果不了解的話，那就自己多嘗試、多實驗!!)。(這部分做的熟悉，應該可以在20分鐘內搞定!!)
        前台訂票的部分，這部分也是前台比較花時間的部分，不過這部分主要還是考驗邏輯，至於前台顯示的部分到還其次。我會說考驗邏輯，主要是在api的部分，這部份是硬功夫，但是只要邏輯能夠通，就會變得很容易。大家可以照著流程來思考，像是：一進畫面電影就會有預設值，這時候就要接續跑出相對應的日期，那日期的部分要怎麼做?日期部分搞定之後，那場次怎麼出來?有了場次之後，如何跳頁、叫出座位表?座位表先不要管有沒有定位的問題，先處理樣式，能夠正確顯示之後再做checkbox的驗證(不超過4筆)，最後在處理有無定位的顯示問題；做完之後，要怎麼在table新增資料、跳頁顯示訂單。這部分大家不要著急，一步一步完成就可以了，愈踏實就愈快完成。(詳細的說明可以看我的程式碼)(這部分差不多要花1.5~2小時)

五、 第四題
        這題因為我練習的還不夠熟，所以只能提供一點方向和建議。這題主要會分成三大部分，一是前台購物車，二是後台的商品分類、商品管理和訂單管理，第三就是剩下的其他功能和顯示。因為畢竟這題還是以購物車為主，所以考試的時候，我會很快的解決第三部分，那時候練習的速度大約是需要1.5小時(我的目標是設定在1小時)。
        再來第二部分，因為會放棄商品管理的新增和修改部分，所以後台預計是1.5小時左右；第一部分，前台顯示商品和購物車這部分預計是1.5小時。
        這題其實也挺雜亂的，大家最好花一點時間整理好架構和流程，而且他很多不同型態的表格，所以要訓練自己快速地把表格生出來；還有就是增刪改查的功能也在很多地方出現，像這種資料重複出現、形式重複出現的地方，都是可以思考簡化的地方，大家可以善用api和session。
        後要提醒的就是，他的購物車其實沒有什麼功能，只是顯示用而已，這說明只要好好掌握這部分，其實這裡是可省時間的地方。具體來說就是，只要表格用好、session放對位置、用jQ切換顯示、最後api寫入db，這一連串其實跟第三題的訂票根本大同小異，但是應該更簡單一點，這裡只要熟悉session和陣列就ok了，如果多練一段時間，這部分應該可以節省不少時間。

六、 最後提醒
        以考試來說，我還是覺得最好的程式碼就是自己看得懂的、又最直覺的，因為不用背是最簡單的方式，所以很多函式、樣式設定、參數我都不會刻意去背，因此每次我的樣式都會不太一樣。對我來說，只要掌握關鍵邏輯就好，剩下的就靠平常多練習而已，尤其是樣式的部分，其實平常多調整就會有經驗了，不用還要刻意去背，這樣會太累。
其實考前，我大部分都只是把流程、架構、邏輯順過一遍，像一二題比較簡單，我平常都練了五遍以上，那考前我就只會自己在腦中想一下流程、看一下題目，還有看一下平常容易出現bug的地方或是有不太熟的地方；我會把更多的時間放在第三第四題，如果還有時間的話，我會把網站打開，配合題目和程式碼一起把流程和邏輯順過一遍，也會把關鍵的程式碼印下來，如果有空還可以複習。雖然我到最後還是沒什麼看…。(其實放鬆心情比較重要，保持腦袋清醒和靈活就可以了!!)

　　前陣子花了點時間去技術士網站找了開辦網頁乙級證照以來的發證數，乙丙級的報名人數和通過率實在落差很大，107年目前是本班的15位報名佔了大多數，一整年大概在50人上下，這樣的執行成績，不知道主辦單位會不會檢討一下。

　　剛好今天看到這則新聞-高職最大的騙局?-剛來上課時也是有同學一直在質疑考這證照有沒有用，我是覺得對我這種非本科系要換跑道，又有點年紀的人來說，這證照是我最快能證明自己能力的方式了，如果時間和環境允許，我希望今年可以再去考個java的證照，那是比起台灣的技術士證照，更被業界認可的國際證照；當然，證照對每個人都會有不同的意義，所以一直以來，我都認為問題不是”證照有沒有用”，而是”我需要證照嗎”，主體不是證照，而是個人。

　　回到發證數的話題來，從開辦到去年為止不到200人報名，實際發證數只有15張，而這15張還不知道有沒有包含全國技能競賽的免術科換證名額，根據我查到的資料，105年舉辦的全國技能競賽中，有11人具有免術科換證的權利，可以在三年內通過學科考試後直接取得網頁設計乙級技術士的證照，只是目前為止，不確定這11人是否都有去換證就是了，如果有，那這網頁乙級的實際考證率就真的是低到離譜了，也許再過一兩年沒有什麼成績出來，會被廢止也說不定，

　　今天完成了第四題的二解，算一算也大概花了八個多小時，雖然每一題第二次解都花上了八小時，但我二解的做法和第一次解題不同，相當於是把這四五個月學到的東西都儘力用上了，己經超出老師教的部份許多了，學科應該是不太需要擔心了，因為做了幾次模擬測試都有80分的水準，明天早上再惡補一下就夠了，下周的目標是把各題的做法精簡化，確保每一題都能壓在四小時內做完，雖然我原先的計畫是把自己的做法放出來給同學一起研究，但因為一些私事擔誤了幾天的時間，所以看來是來不及了，不過等結訓後，我會再製作詳的解題內容和影片放出來給日後有需要的人參考，不然我真的擔心網頁乙級會被廢掉的。

在放假前花了點時間把各題的主要動作數依前後台分析出來後，也得到了每個動作大約可以使用的時間，實做上，如果真的一個動作一個動作老實的做，一定是來不及的，光是建好資料表，再寫個新增資料的前端頁面，再加上sql語法，最後串起來，四五分鐘能不能做得完對很多同學來說一大挑戰，因此實際解題時一定會針對各題的特性再去研究精簡快速的做法，才有可能縮短解題時間；

第一題的重點在後台的功能上，前台的部份功能都有現成的JS可以直接套用，所以相較之下，只要後台做完了，前台就大多只是把資料撈出來後套上對應的JS程式就可以，而後台的製作如果一個一個功能做，一定會來不及，所以可以想見的是一定會大量複製相似的程式碼來協助，而其中又因後台有五個項目的功能需求其實很類似，因此只要寫好一段程式，直接複製就好了，秘訣在於欄位及變數名稱儘可能一樣，這樣在複製時，幾乎什麼都不用改就可以套用了．

第二題麻煩的地方在於題目描述有很多不清楚的地方，加上實際考過的人沒有放出相關消息來，所以到底評審標準如何，不得而知，而第二題的重點大多在前台的部份，如果考量時間性的話，有很多動作可以直接開DW來拉一拉就可以完成了，後台的部份沒有什麼新增修改的需求，資料直接往資料表塞就可以了，唯一稍微要花時間的就只有會員註冊及會員後台管理而已，而這部份只要背熟程式碼，也是很好應對．

第三題算是魔王關題目，主要是前台後台都有大量的JS程式要做，而且版型給得很糟，CSS的設計和題目給的示意圖也差了十萬八千里，這題的解題策略就是事先熟悉所有的JS動畫語法，而且儘量是以JQuery為主，因為可以少背很多內容，而後台的部份，剛是建議以div來取得表格的排版，這可以在做排序功能時，取得較好的JS程式彈性，如果要用老師提供的排序寫法，那麼在評審展示時要小心操作，免得露饀，最後的訂票部份很麻煩，如果時間來不及，只能策略性放棄某些項目不做，如果想拚這部份，那就要熟悉ajax的相關語法及應用，才能在時間上取得良好的優勢．

第四題算是四題裏難度在中間的題目，穩穩做要及格應該不難，唯一的難度只有在購物車的部份，因為購物車並不會只進去看一次，而且在結帳前如果後悔還可以重新選商品，所以這部份要使用SESSION或COOKIE來紀錄商品才能確保資料不會在頁面轉換中流失，然後因為題目在一些購物的細節上沒有明說，所以象是要不要去扣庫存，或是判斷選購商品是否超過庫存等細節，可以看解時間來決定要不要做；後台的部份建議使用JQuery的ajax相關函式來製作，可以省掉不少工夫．