班導那邊說下半年會一口氣開兩個職訓班，內容一樣是教PHP網頁設計，兩個班級的差別在於一個是920小時，另一個是600小時。

PHP資料庫網頁程式應用(泰山) 第01期-600小時

這個班主要在教程式設計的內容，和另一個班的差別在於少了網頁乙級證照的輔考及視覺美術軟體的教學(photoshop & illustartor)，適合想利用短時間學會網頁程式設計並投入職場的人士。

PHP資料庫網頁設計(泰山) 第02期-920小時

這個班是延續之前幾期的課程內容，包含了視覺美術，網頁前端，資料庫及後端程式語言，最重要的是還有網頁設計技術士乙丙級的輔考，乙級會有難度，但丙級是至少可以拿到的，適合完全沒技術基礎，待業時間長的人士加入。

我自己上過了五個職訓班，認真來說，轉技術職絕對不是一件輕鬆的事，也別奢望上完一門課就突然變成程式設計的專業人士，職訓班可以縮短你入行的摸索期，但是想要可以獨當一面，靠寫程式糊口的話，至少得再花個一年自行進修和練習才足夠，目前我那班結訓的同學中已經至少五人是在從事程式設計的工作了，其中四個人是非相關科系及無程式技術經驗的，因此鼓勵有需要的朋友可以好好參考一下。

周日時去參加了乙級學科的考試，由於現在大多數的技術士檢定都不再保留學科成績，因此上次術科沒過後，學科成績也需要重考；我的考場在亞東科大，這地點和我之前考桃園捷運是一樣的地方。

有別於先前在職訓班時的團體專案，這次由於是全國性各職類一起考，所以採用畫卡的方式應考，我是到了前一天才知道，臨時準備了２Ｂ鉛筆應考，除了即評即測的項目，其他的職類並沒有建立線上題庫，所以大多乙級以上的檢定都還是採用畫卡的方式進行；每一間教室依照各職類的編號坐在一起，有些職類應考人數多的可能全教室都是同一職類，有些則是多個職類混在同一間教室考，我那間教室就至少六種職類的應試人員；同學們分別在不同的考場應考，在考前用Line閒聊時，得知其中一個考場有三位應考人的編號後面加上了B，我看了一下名字覺得眼熟，上網查了一下，原來是免試術科的學生，分別是前幾屆全國技能競賽的及格者，所以他們只需要考完學科及格就可以拿到乙級技術士的證照了，特別一提的是，每年三梯次的乙級技術士考試中，只有第二梯次有術科的考試，其他兩個梯次只有免試術科的考試。

答案是第二天會公告在技術士網站的歷屆試題中，我對了一下，單選全對，複選錯三題，沒意外的話應該會有94分；這次的準備，原本是想在考前一個月開始每天100的進度來準備的，但因為練習術科題目的關係，實際上是到了考前一周才開始準備，由於我上一次考了87分，大多是錯在共同科目的題目上，因此我這次先從共同科目的四百題下手，一個小時可以做200題，我花了兩天時間把共同科目練了三次，再利用士商的線上練習系統把不熟的題目寄回信箱，考前一小時就只看信箱裏的題目就好了；另外專業的八百多題我只複習了一次，而且把重點放在複選題上，一樣是利用線上練習系統把沒把握的題目寄回信箱，這樣下來我實際只花了四天在準備學科的一千兩百多題試題，有一天則是保持術科的練習。當天去考場時，我只在考前把手機拿出來看看信箱中的題目而已。

照目前的進度來看，要到八月十號才會公告成績，也就是要到八月十號之後才會確認術科是否舉行及舉辦的考場，然後再寄發通知信，所以保守估計術科考試大概要到八月底才會舉行，因此還有一個半月的時間可以準備術科的提目。

考後我特別去統計了一下這次網頁設計類的應考人數，我自己亞東的考場包含我在內一共有三個人考乙級，另外兩位不是免試術科，我也不認識，所以好奇心驅使下利用考場查詢系統做了統計，這次全國一共有20人報考網頁乙級檢定，滿好奇最後會有多少人考到證照；如果加上職訓班今年兩梯次的報考人數，今年的報考人數有可能上看50人，105年時也有51人報考，不過那年只有六個人拿到證照，考照率只有12%左右，目前已知的是今年己經發出六張證照了，三張是免試術科，三張是我們職訓班拿到的，所以如果這次20人可以有三個人以上拿到證照，就可以算是突破紀錄了。

這周花了三天在做三四題的第二次解題練習 ，雖然目前的解法己經固定下來，但是明顯的熟練度還不太夠，總是會需要時間再回想一下要怎麼解，這造成了三四題在解題時間上的延長，距離術考應考大概還有一個半月時間，希望能在應考前把解法記熟。

這周在解題時特別在每一個步驟的段落做一下紀錄，原本只是想當做重新寫解題網頁時的參考，同時提醒自己每個步驟會用到的一些關鍵語法，但是到了第四題時，索性把每一個段落的時間也記錄上去，這會比之前直接看倒數計器要來得有價值，可以更徹底的分析自己的速度卡在那些地方；

第三題解題紀錄：

1. 搬移檔案及整理目錄
　　PHP.ini->[Date]->"Asia/Taipei"
2. 開資料表手動塞資料
　　分類資料表增加count欄位
3. 撰寫base.php
　　pdo連接語法 / session_start() / $today
　　建立分級陣列
　　建立常用自訂函式
　　getRow($table,$data)->單一條件單筆資料
　　allData($table,$type,$data)->單一條件全部資料或全資料表資料
　　delData($table,$data)->單一條件資料刪除
　　upData($table,$seq,$data)->單一條件更新資料
　　newData($table,$data)->新增資料
4. 建立前後台版面架構
　　主要內容拆離成單獨立檔案，以include方式載入主內容區
5. 建立後台版型
　　css建構
　　三個頁面版型先建構完成
　　新增及編輯院線片頁面先拉好
6. 建立前台版型
　　院線片清單先完成並做好分頁功能
　　預告片先建好div分層，採固定數字即可
7. 院線片簡介頁面完成
8. 建構訂票功能選擇畫面
9. 建構劃位功能畫面
10.建構訂票完成畫面
11.製作後台登入功能
12.製作預告片海報後台列表
　　製作新增預告片海報功能
　　製作刪除及編輯資料功能
　　製作更換排序功能
13.製作院線片後台列表
　　製作刪除資料功能
　　製作更換排序功能
　　製作新增/編輯院線片的按鈕連結
　　製作顯示/隱藏功能
14.製作訂票管理列表
15.製作訂票選擇畫面功能
　　selMovie()/selDate()/selSession()
　　以ajax方式來和api.php做溝通
　　日期的計算以$today和ondate +2days的日期差來計算
　　各項選擇的結果都存入SESSION備用
　　場次的計算要加算是否為當天，非當天一律是五場，
　　當天的話則要計算時間是否在下午兩點後，若在下午兩點前一律為五場。
　　增加判斷是否已經有在session中存在己選擇的項目(上一步的記憶功能)
16.製作劃位功能
　　先以array_fill()來產生一個冇20個0的陣列
　　利用array_merge()來合併己訂的位置，
　　將己訂的位置改為1
　　產生劃位畫位
　　以prop("checked")來驗證座位是否被點選
　　array.push->在陣列中增加元素
　　array.splice(index,1)->在陣列中移除一個元素
　　array.indexOf()->回傳陣列中某值的索引值
17.訂單編號直接以文字格式來儲存，
　　產生方式為從資料表中取最大的序號值來加1(max(seq)+1)，
　　再以sprintf()來格式化輸出(sprintf("%04d",$s))
18.訂票功能完成後接著做訂單管理功能的快速刪除及單筆刪除功能
19.製作預告海報的下方按鈕顯示及移動功能
20.製作預告片海報上方顯示功能
21.製作按鈕切換海報功能
22.回頭製作後台院線片管理的新增院線片及編輯院線片功能
23.最後製作預告片海報轉場動畫及自動播放功能
　　以json格式產生一個id=>ani對應的陣列，
　　使用Object.keys(array)[x]來取key值
　　淡入淡出->現有的fadeOut，下一張fadeIn
　　滑入滑出->現有的先定位，下一張定位在右側可視區外，兩張同時向左移動同等寬度
　　縮放->現有的先定位，下一張先縮小到零高度及零寬度並定位在中間位置，
　　現有的先往中間縮小到零高度及零寬度後，
　　下一張開始放大到容器的高度及寬度並定位到容器的左上角，
　　現有的記得要先隱藏並恢復大小。
24.時間夠就多加一個滑入按鈕區時暫停自動播放的功能，免得動div的計算會出錯

第四題解題紀錄：

1.整理版型及搬移相關目錄及檔案(10分鐘)
2.建構base.php(20分鐘)
3.建構前後台需要include的switch語法(10分鐘)
4.製作最新消息頁面及後台頁尾版權管理(20分鐘)
5.手動塞入分類及商品資料(20分鐘)
6.製作分類選單(15分鐘)
7.製作主頁商品清單(20分鐘)
8.製作會員登入及管理員登入頁面(5分鐘)
9.製作會員註冊頁面(5分鐘)
10.製作購物車/結帳/訂單詳情頁面(15分鐘)
11.製作商品詳情頁面(5分鐘)
12.製作管理員頁面(3分鐘)
13.製作會員管理/編輯會員/訂單管理頁面(10分鐘)
14.製作新增管理員/修改管理員權限頁面(7分鐘)
15.製作新增商品/修改商品頁面(6分鐘)
16.製作商品分類與管理頁面(5分鐘)
17.製作商品分類與管理功能(35分鐘)
18.製作新增商品與修改商品功能(30分鐘)
19.製作會員註冊功能包括api檢測帳號功能(20分鐘)
20.製作會員及管理登入功能(15分鐘)
21.製作新增管理員功能(4分鐘)
22.製作管理員清單及修改/刪除管理員功能(15分鐘)
23.製作後台管理員權限功能(10分鐘)
24.製作會員管理清單功能(3分鐘)
25.製作編輯會員功能(5分鐘)
26.製作訂單管理清單功能(5分鐘)
27.製作訂單詳情功能(10分鐘)
28.製作購物車功能(25分鐘)
29.製作結帳功能(15分鐘)
30.修正後台訂單管理功能(5分鐘)
31.補做商品詳細資料功能(3分鐘)
32.補做首頁會員登入及管理登後的連結變化(5分鐘)
合計381分鐘

即使已經有了優化過的解法，我也沒把握三，四題可以在四小時內完整做完，但是追求及格應該還是可以的。

重新解第四題花了大概八九個小時，這次比較不趕時間，所以重新檢視一下題目的要求及改善解題方式，雖然PDO及自訂函式己經幫忙省了不少功夫，但是第四題有很多畫面需要刻，雖然第一題也很多畫面要刻，但大多可以用複製貼上來完成，第四題的畫面差異比較大，所以刻畫面的部份浪費了不少時間，這部份的工作也沒有什麼好的解決方式，所以最終要靠PHP的部份來省時間。

這次比較大的突破是在選單的部份，由於選單除了要呈現大分類和中分類之外，還要統計各類別的商品數，之前的做法是在秀出選單時再各別去撈商品數出來，這個做法除了sql語法麻煩之外，有幾個選單就要去資料表query幾次的做法，其實效能很差，現在改善的做法是在選單的table加一個count欄位，然後寫一個函式去更新各類別的商品數，接下來就是在有任何影響到商品增減的動作上執行一次這個函式來同步計數的變化就可以了，這樣在做選單時只要一次存取就可以完成選單功能了；不過目前題目的設計上還是存在著問題，由於後台是可以刪除分類的，這會造成己經有分類紀錄的商品找不到對應的分類，也會造成統計上的錯誤，目前無解，除非題目做出修正。

另外在購物車的部份，之前大概花了三十多行在做登入狀態及購物車是否有商品的判斷，現在也換了一個做法，把購物車的陣列改成key-value的型態來分別儲存商品序號(key)及數量(value)，同時也把購物車的判斷流程單獨包成一個函式，這樣一來整個程式碼少了一半，而且也簡潔許多，至於存儲的部份，之前使用兩個陣列來儲存商品及數量，現在改成只要一個陣列就夠了，資料表也少了一欄。

修改後的做法

修改前的做法

後台的部份，原本最麻煩的分類及商品部份是做成兩個檔案來呈現，但看示意圖怎麼看都覺得應該是同一畫面的東西，所以索性改成在一個檔案中分為上下兩個功能的方式來呈現，這樣也少了一個跳頁的處理，同時也可以共用相同的js函式，比如刪除資料的功能，只要傳入資料表名及序號，就可以透過ajax功能去刪除對應的資料，類似的處理方式也可以減少不少js程式碼的工作。

最後是刻畫面的問題，目前能稍微加快作業的方式就是儘可能先把需要刻畫面的部份都先刻好，同時也把檔案都準備好，第四題我用上了二十多個檔案，這樣象購物車和後台訂票詳情的地方畫面都類似，就可以先用複製的方式先做好，然後再統一來處理程式碼的部份，這樣在解題上會比較順手一些。

雖然只是照進度把題目練習完了，不過今天完成的解題模式大概就是之後的定案了，在不使用framework的狀況下，利用pdo及自訂函式來協助解題，的確可以減少打字上的錯誤，同時也增加了效率和安全性；在每一個項目的解法上，目前也大致都定形了，沒有什麼新的做法可以研究了，之後應該就是照著這套模式把題目練熟就可以了。

簡單說一下目前的解題策略及順序：

1. 先建立PDO的連線物件，
2. 接著撰寫四到五個自訂函式，包括了新增/修改/刪除/取用資料等常用的動作，
3. 建立前後台的所有功能頁面基本HTML語法
4. 逐項功能製作及建資料表
5. 微調及測試

之後的安排就是每天100題學科的練習及每周兩題術科的複習，看來是妥妥的了。

這周的進度是第一，二題的練習，上周原本應該是三四題，結果只練了第三題，這周如果時間夠，要把第四題的進度補上。

這次解第一題，延續上周使用PDO的方式，實際用下來，除了仍然要手動打sql語法這點之外，整體對解題來說是有不小的幫助，至少不會像以前那樣常發生括號裏要放的變數打錯字或忘了放之類的，不過這次解題上幫助最大的應該是函式的代入，這是很早就想嘗試的做法，但是之前一直沒有時間好好的來研究，今天試了一下，果然很棒；原理就是把一些常用的資料庫操作包成函式來處理，其實PDO本身有提供前置語法的做法可以達到和函式相同的功能，不過那塊我還不是很清楚，再加上，我的需求會用到陣列的代入，目前找不到PDO有類似的用法，所以還是採用函式的方式來處理。

我目前做的函式有四個分別是刪除資料(delData($table,$seq)) / 新增資料(newData($table,$data)) / 修改資料(upData($table,$seq,$data)) / 整表取出(allData($table))，參數中的$data是陣列的資料，因此我在函式中會用迴圈的方式去取出陣列資料，再組合成需要的sql語句來送出，比如delData的內容；

function delData($table,$seq){
  global $pdo;
  $pdo->query("DELETE FROM ".$table." WHERE seq='".$seq."';");
}

這樣的做法，讓我省掉不少檢查sql語句的時間，只需要把參數代入就好了，目前還是有些地方是使用完整的語句，比如分頁的部份不是很麻煩，特別去寫一個函式好象也沒有省多少時間，所以類似這樣的情境我還在考慮要不要換成函式，比如計算資料表的總筆數這件事，做一個函式的確可以省不少時間，但是因為在題目中只有分頁會使用到這個功能，而分頁做到後來基本上都是直接複製貼上到所有需要分頁的功能去的，這樣算起來似乎弄個函式也不一定會省時間，不過就長期來看，這樣的做法還是很有幫助的。

這周主要目標的第三和第四題的重新練習，不過因為最近開始在研究一些新的框架和技術，所以除了先前的解法外，也打算試試用新的語法來解題，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.每天學科一百至兩百題，如果自己的學科系統來不及完成，就先用士商的線上試題系統來練習，一天兩百題大概也要一小時左右的時間；先做循序的題目練習，把一千兩百題都練上一兩次，等考前兩周再開始混合作答，一樣每天一至兩百題的量。

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

這幾天在試解2014年第13屆全國身障技能競賽的網頁設計題目，這題目是我收集的三屆題目中算比較有難度的，全國競賽通常會有現場30% 的題目變化，我並不知道當年的30%變化是什麼，只能就目前從競賽網站下載的資料來做解題；

這題要做的是一個旅遊資訊網站，主要的難度第一個是檔案匯入及整理的工作，這部份一般的網頁設計程式教學並不一定會教到，由於題目是賽前一個月公佈的，所以如果賽前知道會有這個內容，預做準備的話也還算可以從容應對；首頁動畫的部份，當年的題目大多是要求做一個flash動畫出來，但這時代flash已經確認退流行了，所以這部份我改用jQuery來做動畫；最麻煩的是篩選資料的功能部份，這一頁中除了資料的撈取條件外，還有一堆的CSS要處理，版面的安排需要從無到有自建構出來，而左方的排名部份會使用到比較麻煩的sql語法，我在解題上也幾乎能用的技巧都用上了。

首頁動畫

資料匯入存在著一些陷阱，由於題目提供的檔案格式及編碼並不是當今通用的規範，所以花了點時間研究資料檔案的問題，再加上，資料的欄位格式其實也很怪，像是類別這個欄位有用逗號分開的，也有用斜線分開的，到底那一種才是正確的格式令人疑惑，而這問題到了篩選資料時也變成麻煩的問題，比如同樣一個type，有的資料前面有加了一個空白，這在做比較時會變成兩個不同的類別，所以得在撈取資料時再去處理一下空白的問題，另外，資料中有些欄位資料是有單引號或雙引號的，這在程式或sql語法的判讀上會造成問題，也得處理。

資料匯入

篩選資料的功能主要是在版面安排上會花費比較多的時間，由於題目並沒有要求得在1024×768的範圍內來做，所以這邊我採用的是全版面及RWD的方式來處理，不過我也只是做到能看的程度而已，畫面尺寸變化太大時還是會有版面跑掉的狀況。

景點篩選

第三題相較一、二題，難度直接提升了兩倍以上的難度，這難度的來源是因為在整個職訓期間，並沒有對前端的動態效果做太多的學習導致的，後台的部份大多數都是簡單的存取控制，不難但會花時間，前端的兩個難點一個是轉場效果的製作及訂位功能中的關聯選單功能需要透過較複雜的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欄位來表達題目和選項的關係，這樣的結構用來應用解題是足了，大型問卷系統才需要考慮是不是要拆成兩張表來管理。

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

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

這次的課程期間長達五個半月，中間還分別跨了國曆新年和農曆新年，一共149天，上課日100天。

這次的課程內容涵蓋範圍也很廣，因為班導一開始的課程設計是針對網頁乙級國家技術士，所以在PHP的部份有上了不少和題目有關的實例，透過實例來帶出一些程式流程和編碼的學習也算是不錯的一個教法，這比起之前在委外的補習班的教法更可以啟發學員的能力。

這次甄選進來的學員也是態度比較正面的一群，雖然程度的落差是目前職訓班一直都有的問題，但我的觀察是，如果學習態度好，那至少整個上課的氣氛不會太差，之前遇過那種只是想來混時間領津貼的，上課睡覺打呼就算了，偶爾還會干擾到其他學員，或是態度不佳，和老師對嗆之類的。

整體來說，我這次學到的東西比起之前東一塊西一塊的學，這次是紮實多了，之前的補習班教學的確都是從基礎開始教，什麼九九乘法表，印出星星排成三角形之類的，雖然好象什麼都有教到，但最終無法整合成一個完整的作品；而這次的教學採用的做法都是一次一個完整的實務案例，這周可能先講解其中一個部份來教迴圈或陣列，下次換另一個部份來講解資料表如何連線，如何取值等等，至少每個主題都可以看到完整的成果，而不只是看到一個單一指令執行的結果而己，即便是Phtoshop和Illustrtor的課程，班導的教法也是只花一天把基本操作講完後，然後就丟了大量的練習題和實例題給我們去做大量操作的練習，在民間補習班則是光操作就教了一周，然後也沒有太多實例可以練習應用，學完我也忘光了。

講師素質的部份，我覺得僅是恰如其份的程度，畢竟職訓班因為政府政策的關係，不像很久以前的職訓聽說可以嚴格挑選學員的背景條件，因此當很多學員是非本科系的時候，講師在速度和教材的取捨上自然無法滿足所有人的需求，這點倒是我上過的五個職訓班都有一樣的問題，講得再簡單也還是有人就是不懂，所以我到後來都是上課聽重點，然後自己去補強自己想額外學的；另外這次的PHP和MySQL都是用純文字編輯器在上課，我覺得比之前用Dreamweaver來教要實際的多了，這對於了解程式的運作及資料庫的語法會比較有幫助，真的都把基礎打穩了，再去考慮使用工具來簡化操作。

在訓練目標上，因為這次的目標是訂在國家技術士網頁設計乙級上，所以課堂氣氛是比較活絡一些，畢竟大家有一個共同的短期目標在努力，話題的重心就會比較集中，也比較有可以交流的內容，先前的職訓班大多有一兩周的專題製作來做為課程的目標，但是因為專題製作容易發散，最後往往都不了了之。

環境的部份，公家單位提供的上課環境真的沒話說，山上空氣清新，往山下挑望的景觀也不差，上課用的電腦設備也是一等一的，可以參考我網誌前幾篇的介紹。

整體來說，這次的受訓體驗是正面的，舒服的，而且也有確實學到東西，因為時間長，學員間也有不錯的革命情感在，受訓後期還特別辦了一場徵才會也是很讓人感動的，據說也是場區第一次這樣辦；

結訓後兩天，己經開始在丟履歷等面試了，這過四十歲的年紀才要來轉程式設計，我也知道困難度不是一般般，這兩天有打電話來主動給工作的都是房仲和保全，實在很令人不甘心，希望再拚拚看，不過學程式的另一個保障也是我昨天在面試時和某公司提到的：”就算最後真的沒找到程式設計的工作，我也可以自己轉接案或純創作，這是程式設計可以不依賴特定公司或行業的優勢＂，我大不了就當個會寫程式的社區保全，干！