花了兩天的時間研究了一下laravel的實作，如果只是照著書上說的或是線上課程的範例，大多都能執行成功，但這沒什麼，畢竟只是走別人走過的路；所以自己打算找些題材來實作練習，第一個想到的就是拿網頁設計乙級的題目來試刀，從頁面blade語法開始研究到後來的Model及Controller的運作，兩天下來只完成了後台的一半功能，過兩天有空再來完成剩下的，不過這邊先紀錄一下心得，免得到時要接上時又忘了。

單就前端頁面的建構來說，使用blade樣板語法後，前端頁面的建構變得非常簡單而且好維護，原本後台的各個功能頁面我是採用switch case的做法，直接複製各個功能的 html碼，再把一些文字做替換，雖然複製貼上是很簡單的工作，但是在修改各畫面的欄位名稱及文字時，不免還是會有遺漏或打錯的狀況，使用blade後，欄位名稱改成用變數的方式來傳送，只要用語法做好一份模型，接下來就是由Controller來控制要傳什麼功能的欄位名稱過來，樣板會自動生成對應的完整HTML語法，原本要4,5百行的檔案，一下縮到一百行左右而己。

資料模型是我目前覺得比較麻煩的地方，也是今天花最多時間研究的地方，單純就ORM的操作來說，的確可以簡化原本的SQL語法操作，甚至比我先前的先寫function的做法還來得快，但目前發現的缺點是一張資料表只能對應一個Model，所以第一題會用到九張資料表就得九個Ｍodel，然後再對應九個Controller來操作資料的CRUD，當然也得設定至少九個相應的Route來管理各項動作，雖然最後只是複製貼上再改一下資料表名就可以，但是採用框架就是為了做到DRY(Don’t Repeat Yourself)，這讓我不得不考慮是否改成直接用DB類別來操作SQL語法會比較快一些。

laravel在table migration的做法和之前習慣的做法不一樣，所以這部份也是要花時間研究，以往都是直接在資料庫或透過phpmyadmin直接建表完成後再來寫程式的，但是laravel是把整個資料表的操作都拉回到框架裏來操作，這部份是考量到團隊工作時，需要有個資料表修改的紀錄做為開發的參考，另一方面也是為了同步團隊的資料表結構而做的設計。

估計再花個一天時間可以把後端的部份全部做完，前端的部份目前看起來不難，後面會有點挑戰的地方應該是Session的使用及laravel驗證機制的操作。

做到目前的心得是採用框架來做解題，並不一定比較快速，而且開發觀念也得轉個彎，但如果是花點時間練熟悉的話，因為整體的程式碼數量是減少很多的，加上錯誤發生機會降低非常多，所以如果練習的強度夠高，整體速度還是可以加快不少的；後面的計畫是在年底前把網頁乙級四個題目都用laravel做過至少一次，然後找出最有效率的解法來。

上個月花了一筆錢去買了線上課程來看laravel的教學，不過內容只有一開始的觀念部份比較受用，後面在談實作時，感覺講師完全忽略了學員的程度，速度一下衝上高速公路，後來自己又翻找了一些資料，總算了解一些框架使用上的問題。

這個月開始，我結束了手上的選手培訓工作，剩一個職訓班的課程，所以有時間開始來研究新東西，而我預計明後年的網頁設計乙級有很大的機會會改題目或加入新的函式庫，所以打算先來研究laravel，之後再回頭去研究CI(因為目前函式庫提供的是舊版的CI，我覺得研究的價值不如直接寫原生PHP)。

之前在看了許多的laravel介紹都特別強調要先安裝composer，之後再安裝laravel，我對這點一直很有疑惑，今天試了一下總算有所了解，composer的作用主要是在解決套件相依的問題，因為laravel使用了不少套件來輔助，所以如果不安裝composer，那麼就要自己去把一堆相依套件找出來，並做好相關的設定，laravel才會正常工作；我一開始直接下載laravel放到目錄中的確無法工作，後來沒辦法；裝了composer後，觀察變化，發現主要是多了vendor這個目錄，這個目錄的全部檔案大概29mb多，而laravel的目錄結構及原本的檔案加起來不到1mb；下載完vendor裏的所有套件後，測試了一下，還是無法work，原因是laravel的運作需要在.env檔中放一組key，所以利用artisan 來產生一組key就可以運作了，除了自己開apache來測試外，也可以用arrtisan自帶的serve指令來建一個臨時的網頁伺服器；最後我做了一個測試，把裝好相依套件的專案目錄複製一份起來，改個目錄名，接著把composer移除，然後再試試看laravel能不能正常執行，結論是可以執行；所以說沒有composer也是可以執行laravel的，但是如果使用的專案會利用到其他的套件或是專案本身就是用來開發套件的，那可能還是需要安裝composer來協助做套件的管理；否則，composer在laravel的定位主要就是一開始做版本相依套件安裝時有用而己；當然，composer的作用並不只是做套件安裝檢查這麼簡單而已，其強大的功能在當代的PHP開發上有著相當的地位，所以Laravel才會把composer納進來成為開發環境的建議項目之一，不過composer的研究我是打算之後自己在做side project時再來慢慢研究。

我想測試不用composer的原因不是吃飽沒事幹，而是因為之前的技能競賽有提供laravel，但我很好奇現場沒有網路的狀況下，是要怎麼運作？現在自己試一次就比較清楚怎麼回事了，考場應該也是把整包己經裝好各式套件的Laravel提供給考生，所以就算沒有網路，沒有composer，也是可以在離線的狀況下直接在本機端進行開發的工作。

在確定了Laravel可以運作後，我做的第一個實驗就是把網頁乙級的第一題版型先納進來試試看，相較於以前使用檔案的方式來開發網站，目前市面上的框架都是用”路由(Route)”的方式來開發，也就是MVC的開發方式，不過我只是為了先確定可以把靜態頁面先納入，所以我把css及js搬到public目錄下後，依照Laravel的規範，把版型檔案改成*.blade.php的樣版檔案，放在resource\view中，接著在routes\wep.php中寫四個Route去對應四個樣版檔案，這麼一來，以前都是用/*.php的方式來link檔案，使用框架後，會改成用/*的方式來訪問需要的服務，開發觀念上會大大的不同。

使用Laravel來套版型

從9/14考完術科後的第十四天開始，我就幾乎天天上網看成績公告出來了沒，十月中時還打了電話去問到底成績何時會出來，結果技檢中心的回答是說承辦考試的單位還沒有把成績寄回技檢中心，所以要我再等等，問了一下原因是因為在全國檢定的各梯次中，有些考場會在一個梯次中同時承辦多個職類的考試，而這麼多的考試也不會集中在一天考完，比如拆成一個月的期間來考的話就要等那個考場舉辦完所有的考試後才會一次性的把所有的職類考試成績寄回技檢中心去做確認，等技檢中心確認完後才會把成績登錄到系統中，並寄出成績單；如果是專案檢定的考試，則是考場當天就可以確認完成績並上傳到系統中，隔天就可以發證了。

然後我終於在考完後的第四十一天，也就是10/25看到自己的術科成績了，系統也註明了會在10/25寄出成績單，不過我想我要到下周才會收到成績單了；系統上註明我的證照編號是29號，表示我是第29位拿到網頁設計乙級的技術士。

乙級成績查詢結果，今年一共考了兩次，一次是在職訓期間的專案檢定，那次術科沒過。

接下來等成績通知寄到後，匯入證照費，然後再等證照寄來了。

今天一早六點起床，然後七點吃完早餐，七點半出門去考場，因為泰山離我家很近，所以我時間抓很準，這次班上報考的五位同學最後包括我只有兩個人來考，今天原定的十三名應檢人，實到也只有六個人而已，這難怪考照率低，考的人也少，六人中有三位是不認識的，閒聊了一下，一位大哥是學java的，被鼓勵來考看看，但是他說完全沒準備；另一位妹妹是資訊類的專科生，有考過丙級，所以想來試試看，有用DreamWeaver自己做過一次，最後一位大姐考生離我太遠，我就沒問了。

按表操課，所以八點四十分抽完崗位號碼就進場做軟體安裝的工作，除了安裝軟體，也可以用來做一些測試及準備工作；不過我大概是連續兩周每天十幾個小時練習過頭了，疲累感一直揮之不去，頭也有點暈暈的，在設定網站根目錄時設錯項目，造成apache無法啟動，後來移除xampp重裝才發現自己搞錯了，九十分鐘的時間被我浪費了三十分鐘在搞定軟體上；我一直是假設自己會手氣很差的抽到三四題的心態來做準備的，所以剩下的六十分鐘裏，我先把各試題版型檔案的相關路徑先做整理，第三題試題中附的avi影片檔我也都先用考場電腦內附的轉檔軟體先轉成chrome可以使用的mp4檔案，最後再檢查一下鍵盤的按鍵，考場附的薄型鍵盤實在不好打字，建議在準備時間內先熟悉一下鍵位。

中場休息時間下山去小七買了紅豆和巧克力麵包來補充血糖，然後回考場休息到十一點二十分，開始抽題目，題目是由崗位數最小的人來抽，剛好我是２號最小號的，所以我去抽，其實就只是點一下按鈕，然後它會自動分配所有應檢人的考題，我抽到第二題，然後從我的號碼開始再三四一二的順序輪下去；抽到第二題，心中是很爽啦，雖然我是比較想挑戰三四題，但可以順順的過也是不錯的。

第二題我最後定案的解法是先建資料表手動塞完資料後，先把後台的三個功能做完，這時也會把後台的新增會員的功能一併做完，然後後台的新增會員功能其實就是前台的會員註冊功能，程式碼原封不動複製過來，改一下抬頭文字就完成了，然後就接著做完登入和找回密碼的功能；再來是利用後台做完的問卷管理功能把問卷新增上去，接著把前台的問卷功能也做完，做到這邊時間才過一個半小時，我就鬆一口氣了，然後把後台的文章管理中的分頁功能搬到前台的最新文章和人氣文章中，按讚的功能我先跳過，先把主頁的頁籤文章功能利用Dreamweaver快速完成，這邊我懶得自己寫，所以直接用DW來做，再去改一下CSS，讓頁籤看起來和題目要求的畫面一樣就可以了，接著是做分類網誌的功能，這邊我改了新做法之後變得很簡單，利用Ajax技術去後台撈資料再塞到div去，不到二十分鐘就搞定了，雖然它只值五分；最後再回頭去把最新文章和人氣文章的按讚功能做掉，按讚功能我每次做都會出點小問題，這次也在同步按讚數上出了點狀況，共用函式一直起不了作用，最後直接下sql指令來解決，做到這，我看了一下時間還有一小時，等於三個小時做完了。

最後我還是花了四十分鐘重頭到尾再檢查一遍所有的功能是否都有完成，的確也被我找到一個session的錯誤，即時修正回來，然後大概剩下十五分時我就舉手要求檢查了，評委其實也沒有真的照題本一項一項的看，但是每個連結和功能都有測試一次看看是否正確，最後還要求看資料表的結構，確認我是真的有用到資料庫，最終我是一分未扣的通過測試。

我沒有馬上離開考場，在休息室和後面陸續出來的應檢人閒聊，看來這次是只有我一個人通過檢測，班上另一位同學是抽到第三題，而他只準備了一二題，一位抽到第一題的也是練習不足，所以出了錯時來不及修正，差了十分及格，其他三位不認識的新朋友則是來體驗乙級檢測的殘酷的；後來我也和考場人員閒聊了一下，提到我練習的狀況，我說不誇張，到考前一天為止，四個題目每一題我都練習了至少十次，每次以平均四小時來算四十次就至少一百六十小時，這還不包含研究簡化解題所做的一些測試時間，而且因為我知道考場的鍵盤不好打，所以我很努力的在壓縮自己的解題時間來因應考場可能會有的影響，我今天就因為鍵盤問題，好多次都按錯按鍵。

最後我下去和班導打個招呼，今天也是職訓班的結訓日，昨天他們專案檢測，一共七個人通過術科，五個人今天領證，三個班次下來，算是打開了網頁乙級檢測的一條活路了；也希望能把這張證照推出去讓業界知道，成為一項能力的證明；接下來，我要休息幾天不碰程式了，然後下下周會開始整理解題內容，及準備新工作的前置作業。

因為乙級檢定今年有把VS CODE加入軟體清單中，雖然不知道是不是每個考場都有準備這一套，但我還是想玩看看，由於內建了emmet的支援，所以在刻HTML和CSS時會省時不少，同時也降低打錯字的機率；另外是因為VS CODE內建檔案管理員及終端機的功能，所以在檔案的操作上也省時不少，至於git 的支援也是很厲害的工具，可以隨時去比對自己做的東西在版本上的差異。

這兩天實際拿題目來練習，以第四題來說，雖然在刻畫面這件事情上的確省了不少工夫，但對整體時間的縮減似乎還好，檢討原因主要還是題目本身的問題，第四題的量太多，功能又雜，控管的檔案一多，很容易出錯，這部份，內建的PHP語法檢查器幫了不少忙，可以即時的幫有問題的語法加上紅底線，不需要一直去檢查畫面看錯誤訊息；另外我也拿了第一題來實驗，由於第一題的問題在於量，所以不管是emmet或是語法檢查，能幫得上忙的地方都很有限。

這兩天使用的心得是雖然對於解題時間上的幫助有限，但是在降低錯誤上還是滿值得信賴的，目前的狀況就是三，四題要在四小時內完成是很困難的，只能追求到及格，而一，二題只要熟練，都是可以在四小時內完成全部的功能。

不知不覺時間剩下十天，接下來的十天我有兩天的工作，等於剩下八天可以準備，一題有兩天的時間可以分配，一天八小時來算，一題還有四次練習機會，就目前的狀況來說，應該是很夠了。

這三天都在研究第四題的解法，從一開始的八小時，到今天為止，已經可以縮到五個小時了，只要再多加熟練，不要有奇怪的bug發生，壓在四小時左右應該是可以的，目前的解法應該是非框架的解法中算是很精簡的了，只是三四題都有太多的HTML要刻，真正php程式的時間其實不算多。

因為這陣子都在培訓選手，綜合選手的題目和乙級題目來比，我幾乎很確定當初在設計乙級術科時，是以技能競賽選手的規模來思考的，由於網頁技術職類的競賽大多會在賽前一兩個月先公告試題出來，然後選手準備充分後，現場可能會有30%的變動讓選手去應對，但是整體而言，由於選手已經先練過考題了，所以現場競賽己經不是在比會不會解題了，而是在比打字速度，以及時間內可以做多少，藉此來分出高下，也的確是非常的”技術”導向；而技術士證照的考題似乎也有這麼一個成分在，但是技術士證照是採及格制，而非評分比排名的方式，因此把競賽的題目類型拿來做為證照的題目類型，就產生了一些問題，而這也是為什麼過去五年來，幾乎現場考術科的應檢者全軍覆没的原因之一了；由於乙級是採用扣分制，這使得每個題目不分難易度，只要有九個小項目沒有完成，就會不及格，而且每個項目又不等值，容易的和困難的都是五分，但有時你不完成困難的項目，容易的你也做不了，這是項目功能間的相依性的問題，我目前的策略是平均一分鐘的時間要可以拿到相對一分的分數，所以如果要花三分鐘才能拿到一分的項目我就會先跳過。

在過去兩個梯次的職訓班專案應檢案例中，考照率都在20%左右，主要是抽中一，二題的應試者有比較高的及格率，三，四題過去比較沒有被討論，不過我目前自己設計的解法應該是可以穩穩的拿到及格以上的分數，只是要在四個小時內完美做完題目還是很困難；新的一個職訓梯次聽說有機會創新紀錄拿到高及格率，如果這一兩年可以有較多的人拿到乙級證照的話，應該會刺激命題委員好好思考一下題目的方向是否要改了，畢竟已經五年沒改題目了，連函式庫都還是舊版的，素材中還有flash這種已經不被瀏灠器支援的的格式以及影片素材是avi的格式，除了IE支援，其它的瀏灠器根本無法播放；儲如此類的一些問題，真的會讓人覺得國家技術士證照是完全和業界及時代脫鈎的。

希望這次的考照能順順利利的，從六月開始到現在，也花了三個月的時間在準備，原本想學新的技術都先擱著了，付出不算少，要有收獲才值得。

今天收到一包掛號，內容是今年的網頁乙級術科應試通知，還附上了一大本的參考資料及一片光碟，參考資料基本上就是PDF檔整本印出來的東西，而光碟內容則是函式庫及題目素材，所以，為什麼不只寄光碟就好？時代在進步，但公家機關的作業方式始終原地踏步。

原本預計是八月底會考術科，但是今天寄來的通知時間是9/14日，而且還是周五的非假日；比原定的時間多了兩周準備，對我來說目前還是卡關在三四題，所以一個月的時間希望可以把三四題的速度練上來。

另外，通知中也有附了考場的設備，考場是預定在泰山職訓場，但是所附的設備清單比我所知道的考場實際規格要精簡許多，不知道是否是為了降低爭議，所以只列出沒有版權爭議的軟體，像技能競賽就很大方的列出試用軟體，目的是儘可能提供選手最新最普遍的設備及環境，但技術士檢定卻似乎不這麼想；另外一點是，去年修定的新的設備清單中，其實有新增了VS CODE這套自由軟體，但是因為上面只提五套選四套，而另外四套大部份的考場都有附，而VS CODE太新，所以考場沒有附上，我在考慮要不要申請自己帶去，因為我接下來打算都用VS CODE來練習及上課。

最後，到目前為止，一二題我都練習了至少八次，這兩題最好的狀況可以在三小時半內完成，而三四題平均還是要六個小時左右，接下來的一個月希望三四題的練習次數可以到達十次，並把時間壓在五小時內，這樣才可以確保有到及格的門檻。

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

有別於先前在職訓班時的團體專案，這次由於是全國性各職類一起考，所以採用畫卡的方式應考，我是到了前一天才知道，臨時準備了２Ｂ鉛筆應考，除了即評即測的項目，其他的職類並沒有建立線上題庫，所以大多乙級以上的檢定都還是採用畫卡的方式進行；每一間教室依照各職類的編號坐在一起，有些職類應考人數多的可能全教室都是同一職類，有些則是多個職類混在同一間教室考，我那間教室就至少六種職類的應試人員；同學們分別在不同的考場應考，在考前用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語句的時間，只需要把參數代入就好了，目前還是有些地方是使用完整的語句，比如分頁的部份不是很麻煩，特別去寫一個函式好象也沒有省多少時間，所以類似這樣的情境我還在考慮要不要換成函式，比如計算資料表的總筆數這件事，做一個函式的確可以省不少時間，但是因為在題目中只有分頁會使用到這個功能，而分頁做到後來基本上都是直接複製貼上到所有需要分頁的功能去的，這樣算起來似乎弄個函式也不一定會省時間，不過就長期來看，這樣的做法還是很有幫助的。