發現這裡似乎沒什麼討論，在今天（7/1），第一屆的 Laravel Conf Taiwan 2017 剛剛結束。
因為買的是學生票，所以答應主辦單位會後要來寫篇心得。既然寫了心得，又不是國小、國中學生，要做就做得完整一些，從各方面剖析關於這次的 Conference。
關於 Laravel Conf Taiwan 2017，預計將會花到兩、三篇的篇幅來講述這事。（當然這取決於後續的迴響，說不定只寫這麼一篇就斷尾了）這一篇，我們單純從一個與會者的角度來看。
結論：災難、災難還有……災難
在此我要先感謝這次 Laravel Conf Taiwan 的主辦單位及志工，為了在臺灣推廣 Laravel PHP Framework 不遺餘力所做的努力。
然而，誠如大家所認知的，不是努力就應該被讚揚、被鼓勵的，值得讚揚與鼓勵的一向只有努力過後所得來的成就。我這人講話不虛華，說得難聽一點就是「不會看氣氛與場合講話」，在臺灣我們通常稱這種人為「白目」。
低品質的講題，造就低品質的 Conference
如果要說一個研討會的靈魂，我相信應該就是在會場上那些經過百家爭鳴、千挑萬選的講題了。低品質的講題無疑地會降低整個研討會的水準。
這邊先附上整個大會的時程表：
我有參加的講題如下：
- Laravel Storage X GCS 跨平臺應用
- Laravel 單頁面應用與前後端分離開發
- Laravel 事件及序列功能應用
- 水平擴充套件 PHP 應用程式 - 使用 Maghead 資料庫框架
- 運用 Docker 整合 Laravel 提升團隊開發效率
Laravel Storage X GCS 跨平臺應用
老實說會報名這次的 Laravel Conf Taiwan 2017，其中一個講題就是衝著這個來的。
我一直相當苦惱，到底如何在不更動任何程式碼的前提下，如何將儲存於本地端的 Laravel Storage 資料同步到 GCS 上。
其中我自行嘗試過許多方法，像是 Laravel Forge 那樣的佈署服務，將多個 release 版本的 storage 都建立一個 soft link 到佈署根目錄，再將根目錄的 storage 資料夾用 gsutil 同步到 GCS 上。
# Laravel Forge 佈署範例
/var/www # 佈署根目錄
| --- storage # 這個資料夾會用 gsutil 將內容同步到 GCS 上
| --- app --> (link to release-2017-01-03)
| --- release-2017-01-01 # 第一個釋出版本，這是個 Laravel Application
| --- app/
| --- bootstrap/
| --- …
| --- storage --> (link to /var/www/storage)
| --- release-2017-01-02 # 第二個釋出版本，這是個 Laravel Application
| --- app/
| --- bootstrap/
| --- …
| --- storage --> (link to /var/www/storage)
| --- release-2017-01-03 # 第三個釋出版本，也是最新的版本
| --- app/
| --- bootstrap/
| --- …
| --- storage --> (link to /var/www/storage)這是到目前為止我認為 Laravel Storage X GCS 最優雅的解決方案 －－ 但我仍然覺得不夠優雅：
第一：我覺得這樣在處理 storage 資料夾時的許可權設定問題（尤其是 SELinux 的設定）相當麻煩。
第二，我覺得單純用 gsutil 去同步檔案時，無法針對特定的檔案許可權做控管。
然而在這個講題中，我很訝異內容跟我所想像的大相逕庭，因為從頭到尾幾乎都只有幫聽眾複習官方檔案中對於 Storage 功能的使用，以及介紹 superbalist/laravel-google-cloud-storage 這個既有的 Package 套用方法。
當然也有可能是我對於這個講題抱有太多不切實際的幻想，才導致這美麗的錯誤，然而在堂堂 Laravel Conf Taiwan 2017 上面，請講師幫我們複習官方檔案與查詢 Google 的技巧，我不確定我是不是走錯地方了，我參加的到底是 Laravel Conf 還是 Laravel 初學者訓練營……？
Laravel 單頁面應用與前後端分離開發
單頁面應用，又稱為 SPA，Single Page Application。
前陣子嘗試寫過 Vue + Laravel SPA 之後，我一直認為 Laravel 5.4 將 Vue.js 加入並列為預設前端框架是個迎合市場口味的餿主意。（其實我也認為 Laravel 5.2 加入 Bootstrap 跟 jQuery 不是個好主意，雖然這些功能確實為我省了不少時間）
這讓 Laravel 這個框架變得太過臃腫且肥大，我甚至認為像 Queue 、Event、User Auth Model 等等……這類的功能可以另外以服務提供者（Service Provider）的方式提供，畢竟不是每個應用程式都需要這樣的功能。
印象中，這個講題的講者也認為 Vue 整合於 Laravel 中是個奇怪的想法，畢竟前端就是前端，後端就是後端，兩者可以合作但不能逾越界線。
該講者也舉例，有許多公司可能因為各種原因，決定放棄由 Laravel 作為應用後端，但前端仍然使用 Vue 寫成的 SPA。在這樣的情況下，如果 Laravel 與 Vue 是在同一個地方開發（共用同一個 Git Repository），在分離時就會是一場災難。
所以在講者所任職的公司中，Laravel 僅作為 API Server，驗證 Request 、處理商業邏輯與回傳 JSON Response，而另外的前端工程師則利用 Vue + Vuex + Vue-router 製作 SPA，並傳送 Request 與處理後端傳回的 Response。
然而，我認為這麼「乾淨的」使用 Laravel 的方法，似乎有點浪費 Laravel 如此全能的框架能力。我甚至認為這樣不如直接使用個 NodeJS 搭配 Koa 還省事得多，追求效能的話還可以用 Golang 搭配 fasthttp 或是 PHP 搭配 Swoole。不過畢竟是 Laravel Conf，我也不就這麼吹毛求疵了。
講題中也提到了一些有關於推薦套件的使用，像是 Dingo 套件的搭配等等，可以當作開發時的參考。
嚴格來說這是個水準中等的講題，雖然內容平庸但不致於浮濫，技術上雖然已經有點常見但也不失為一個增廣見聞的機會。
Laravel 事件及序列功能應用
關於這個講題我必須鄭重地向各位致歉，也必須向講者致歉。－－ 因為我並沒有認真在聽。
因為一些緣故，我在會場中處理公司的急事，以及因為早上服用藥物的作用讓我昏昏欲睡。
不過就我模糊的印象來說的話，這講題似乎也是個 Laravel 初學訓練營的內容（當然可能有加上一些技巧，但我著實沒有印象），我真的覺得身為一個研討會就不要在幫會眾複習官方檔案了……
水平擴充套件 PHP 應用程式 - 使用 Maghead 資料庫框架
我必須承認，我是為了這個講題而下定決定購票入場的。
畢竟講者是 Maghead 的作者 c9s。
c9s 有許多令人驚豔的專案，例如快速切換 PHP 版本與 extensions 的 phpbrew、接近原生 PDO 效能的 ORM Maghead 以及（目前為止應該仍然是）最高效率的 PHP Router Pux。
講題內容為 Maghead 的介紹與 Maghead 結合 Laravel。
然而因為時間過於倉促，只能將 Maghead 作簡要的介紹，且針對 Maghead 與 Laravel 的結合也僅僅介紹 maghead/laravel-bridge 的簡單使用方法，甚為可惜。
對於 Maghead 取代官方 Eloquent 成為 Laravel 預設 Database ORM，我認為是可以被期待的（前提是有人去發 pull request）。畢竟在用法上與習慣上並沒有太大差異，而且效能上更是令人驚嘆。
運用 Docker 整合 Laravel 提升團隊開發效率
這是個有趣的講師，可惜講著有些過時的議題。
這邊就不特別講述講題內容，畢竟就只是講師分享該工作團隊前端、後端、QA 與 PM 都是利用 Docker 建置而成的環境進行開發、測試與客戶展示的經驗分享，還有利用 Docker 結合 Drone 的 CI/CD 經驗（沒有詳述，只是小小帶過）。
「容器化」（Containerize）大概可以榮登去年三大熱門關鍵字之一，無論在公司、社群還是技術論壇上，無不討論著 Container 的美好未來。
仔細想想，把應用程式包在容器裡執行，開發時輕鬆、測試時愜意、佈署時簡單，除了找到老婆之外，還有什麼事比這個更讓程式設計師們興奮的呢？－－ 想想那個不用加班的未來。
當時許多人都跑去玩 docker，更有不少人認為 docker 就是容器的唯一技術。有許多人寫了無數個 Dockerfile、docker-compose，許下那個不用加班的未來願景。
然而好景不長，就那麼突然地，Docker 的開發公司將 Docker 專案改名為 Moby，然後 Docker 這個名字成為該公司的產品名稱，還分為 Community 與 Enterprise 兩個版本。說個笑話，全世界都幫 Docker 開發公司做了義工，看著產品趨於成熟，Docker 便關起門來開始營利。（嘛，也不能責怪人家，畢竟人家本來就是開公司的，又不是慈善事業）
仍然有許多人認為，「哎呀不過就是改個名字，何必這麼大驚小怪呢？反正它還是個開源專案，繼續用也不傷身的。」
可是這些人沒有想到的是，如果有一天，某個版本的 Docker Community 開始收費……那就算核心是 Moby 那又如何呢？ Docker 公司為了移植容器技術到 macOS 與 Windows 上，對 Moby 做了修改才成為了現在的 Docker Community，從來就不是 Moby = Docker Community。
如果 Docker Community 開始收費，那各種加班的災難將會襲捲而來 －－ 一時半刻要找到能完全取代 Docker 的容器技術還真不容易呢。
當初 Docker 風潮來襲時，我便認為容器技術不應以 Docker 為唯一解決方案，所以我一直在關注 rkt 的發展，我期許 rkt 或是其它的開源容器技術能夠位於天平的另一端以制衡 Docker。
場地抉擇、時間分配與團體衝突
場地
對於一場研討會，場地的抉擇是相當重要的。
本次研討會雖然位於交通相當方便的大樓，但我不確定是經費限制或是其它因素，場地本身通道狹窄，動線規劃並不完善。
租用 10 樓與 11 樓作為活動場地，但中午用餐卻在地下 1 樓，同時有上百人使用六部電梯造成的運量負擔相當可觀。
時間分配
大多講題對於時間的掌握還算可以接受，雖然有一個講題沒能把內容詳述（水平擴充套件 PHP 應用程式 - 使用 Maghead 資料庫框架），但整體而言還算在可接受範圍內
團體衝突
我不確定是溝通上的失誤或是什麼情況，在講者進行活動時竟然隔壁會有巨大的歌唱聲不時打斷，這是相當不給講者尊重的研討會環境，同時也枉顧會眾權益。
本作品採用《CC 協議》，轉載必須註明作者和本文連結