原來可以這麼寫(11): 每個人的心中都要有DevOps

最近工作比較沒有什麼新鮮事,所以開始在將手上專案有比較完整的文件化之後,開始逐步導入TDD ,寫一些Unit Test 以確保程式碼的品質。

但老實說:我還是不是太懂Laravel Feature 和 Unit 這兩個資料夾的區別?我知道Unit 是要做單元測試,是測試那個類別的行為,但我目前大多都在寫Feature Test… 如果有大大知道Unit 該在何時寫、什麼情境下要寫,歡迎不吝賜教!

研究Socket/API Gateway

因為要導入官網購物車購買,討論一連串的流程與討論,最後希望我Laravel 要開一個socket server,但研究的結果其實發現 因為我們專案的版本比較低,所以沒辦法使用Laravel-Websocket 套件,也就是在Laravel 裡面自己開socket server 那種,變成我們要另外用Node 的套件去建立… 然後… 又衍伸第二種方案,在AWS Api-gateway 架起websocket api ,然後他可以指定動作去call API…

這個方案很好玩… 不過在研究初期卡關在怎麼用Laravel 取出 connectid , 因為AWS example 是用Node 的Lambda 去串的,很簡單就取出connectid… 。我Laravel 怎麼print request 的body 還是 header ,顯然就是找不太到那個connectid …

後來實在有點卡太久了(大概一天),被同事叫我去寫AWS Support XD

人生第一次寫AWS Support 耶,然後AWS 團隊真的很用心很貼心,告訴我很詳細的步驟及方法、解決方案,原來,如果要讓Laravel 的 後端讀得到 connectid ,是要透過CLI 去設定啊… (目前API gateway 控制台還沒有支援這個),不然就是需要把integration type 改成 HTTP ,去寫 request template 這樣。

總之,這次經驗讓我更認識 API gateway 和 socket 啦!預計之後想要開一系列深入研究Laravel 的系列,想要寫broadcast 的部分,希望今年可以完成這個寫作計畫 ^^

網站可靠性工程工作導讀

我們每個禮拜都會有小組的例會,小組的成員都需要報告一下我們各自的狀況與專案進度,然而在今年我們組長要求大家輪流每個禮拜都要分享一下技術議題,不管他是前端還是後端皆可。

我個人覺得這是很好的一個文化,但最近也常常聽到同事在講對他們有一點小小的loading…。有點不知道耶,明明是很棒的事情為什麼反而有點造成不太好的效果?我們的專案真的有點多而且每個人負責很多啊,不太平均……

話說回來,大概這樣輪流每個人平均一個月講一次,所以這個月就帶來我讀網站可靠性工作工程的心得與收穫~

之前,也曾經參加這本書的導讀會,大家可以參考:網站可靠性工程工作手冊導讀會一遊

然後值得一講的是後面補充文章有一則:技術債觀念及實務
因為在查一些SRE 和 DevOps 相關文章時就不小心逛到,在這篇文章讀到:

另一方面,著有《Domain-Driven Design》一書的 Eric Evans ,對於處理舊有程式碼(legacy code),也曾提出過一個叫做「戰略設計(Strategic Design)」的觀念。Eric Evans 認為,在一個系統中,根本不可能所有的程式碼都維持夠高的品質,而且,有些情況下,有些程式碼也沒有必要一定非得是高品質。這是個相當務實的觀念,如果我們很現實的來計較在開發過程中每一份生產力的 C/P 值,那麼,維持一些程式碼的完美,需要付出的代價太高,但這些程式碼即使完美對整個系統的效用卻不大時,是否應該讓它們也被一視同仁地被維持高品質?

By 技術債觀念及實務

這帶給我寫程式上面莫大省思與體悟,原來,寫程式也像DevOps 一樣「不應該」去要求百分百可靠度(完美)

以前我都覺得自己要每一行寫得很棒很好,這是一種工程師對自我的要求… 反而導致每一次我寫功能之後就會每次檢討自己、總是花很多時間在想下一次怎麼可以寫更好,但有時候下一次也不一定像這一次可以要求寫得很好…

而DevOps 和剛剛讀到的技術債觀念及實務帶給我在寫程式上面的一個心態轉變,應該要對於不同的程式碼有不同的權重分配,有些可以選擇粗略地寫,只要功能有夠、排版讓人覺得算ok,這樣就好;而有些需要好好每次的重構每次的改善,讓程式碼可以越來越易讀!

總之,這是我當天報告用的ppt ,希望能幫助到大家~

小君曰:每個工程師的心中都應該要有DevOps !

原來可以這麼寫(6): 換了一個佈景主題

我換了一個佈景主題,你知道的,後端工程師美感幾乎都不怎麼樣。我覺得我開發的佈景主題好像還是不是很好用、很美… 所以找了一個新的佈景主題,好看多了……

參加 AWS 工作坊

最近有機會上課,課程名稱是:PHP 開發者工作坊 -深入淺出 AWS 無伺服器 LAMP 架構(https://awsphpday.splashthat.com/),引用了外國人寫的一系列文章:https://aws.amazon.com/tw/blogs/compute/introducing-the-new-serverless-lamp-stack/

從這一系列文章,這個人定義出新的LAMP定義: L- Lambda , A- API gateway , M-Mysql , P-PHP。並且介紹如何實作以及實現。

之後滿心期待報名,甚至還報名了三次,兩次用私人信箱、一次用公司信箱。AWS真的有夠現實的,只有公司信箱報名的那個有成功XD 另外也發現原來我們公司的公假這麼好請XD 只要主管有同意就好 哈哈

有機會認識到Pahud 大大,他真的是一個很熱情的人,在會後請教他問題都很熱情地回答哈哈,同時也深入到Bref 這個套件、以及 Pahud 大大開發的套件可以如何方便的部署serverless laravel 在 AWS 上,我真的很期待這門課程也很開心得到很多不錯的收穫,同時也認識到AWS CDK,目前也正以緩慢的速度慢慢理解學習他(畢竟我又不是DevOps 哈哈)……

啊主要這門課程他就是在介紹他開發的這個套件:https://github.com/aws-samples/cdk-serverless-lamp

這個套件主要是依據AWS CDK為基底,做出符合serverless laravel 的contruct lib ,可以很方便的讓開發者使用開箱

AWS SAM CLI & Lambda

同時我的第一個 Lambda 專案終於開發到一個階段了,甚至也經過前輩的Code Review 完!真的很期待他上架的時候,除了是我第一個Nodejs 架上專案也是第一個 Lambda 專案,而且很認真的畫流程圖、一步一步開發規劃。就是可惜目前開發順序&上架就是有點混亂、這也是讓我有點不爽的地方,一直被「中間插件」… 然後等到上架可能又有更多東西要調…那開發者到底為什麼當初要規劃那麼多?幫使用者想那麼多?(不過軟體工程不就是需求常常會改來改去嗎? 真的很好奇更標準更專業的IT他們怎麼處理這一塊?)

同時,這個專案也要慢慢學習與習慣用SAM CLI ,之前我們公司的Lambda 管理與開發比較亂、現在有了SAM之後會比較好整理及有次序,能夠成為公司內導入這部分的其中一份子真的蠻令人興奮的!也希望我的 第一個 Lambda 專案可以趕快上去! 這樣我就又有一個成績可以炫耀(誤

小君曰:最近都在搞AWS呢

原來可以這麼寫(5): 原來MySQL 博大精深

最近工作接下交易與金流的部分,開始將自己最近火燙燙學習的 Nodejs 來拿去試試水溫。不過,被callback 弄的昏頭轉向的…. 所幸,最後藉著文件與冷靜,慢慢的下斷點、看結果,參考之前前人寫的code , 才慢慢走出來,甚至處理到進度似乎發展還不錯。

MySQL 的 insert 新寫法

因為專案需求,我雖然接下這個舊專案,但是要開發新功能,於是,我覺得可以趁此改善專案架構與程式碼品質,原本程式碼的SQL 是用那種字串方式連結的,但我知道這樣會有SQL injection 的問題,所以在新功能&參考舊程式碼的過程當中,也慢慢的將字串方式改成可以防止SQL injection 的方式。同時也意外發現Mysql insert 有新的寫法:


INSERT INTO table SET a=1, b=2, c=3

比起原本冗長INSERT INTO table (a, b, c) VALUES (1,2,3), 我覺得這種set 的方法真的很不錯,這樣在對照上及程式碼易讀性也更勝一籌,所以覺得可以評估是否要引入的可能性…..

參考資料:https://stackoverflow.com/questions/861722/mysql-insert-into-table-values-vs-insert-into-table-set

參加LaravelConf 2020

其實本週還真的沒啥事情,除了就是討論、開發、維護、就是這些不斷的循環…. 工程師的人生就是這麼平凡無奇,但週末參加了 LaravelConf 2020 , 這次我買的是線上回放票,整體下來感覺很不錯,聽Ant 大大的對PHP&Laravel 之未來的一席話,真的有所感受與領悟啊!然後我覺得比起之前參與過的2017、2019,我發現我又更加聽懂了很多內容,覺得感受到自己的成長真的蠻棒的,不過整體的心得文與筆記我想之後會再好好整理起來。現在還有安可場,可以再去買票去聽啊

小君曰:工程師的生活就是這麼平凡無奇,且有趣

原來可以這麼寫(2):好久沒寫文章了

哈哈,  原本想說可以一個禮拜寫一篇技術文章的

但就是「懶」,所以到現在才出所謂的第二篇….

距離通過工作試用期也已經超過一個月了,我覺得工作上還算是得心應手,進度都在掌握中,也很喜歡目前的工作狀態,只是….我好想接新專案啊…..

在家工作心得

之前,因為疫情關係,我們公司試行了在家工作。老實說,這是我人生第一次在家工作。第一次的時候,還沒有待滿一個月…第一次,好慌、好亂….完全不知道在做什麼

但是,等我慢慢熟悉專案與產品、進度也漸漸掌握起來了,第二次試行、第三次試行,搞清楚自己目前的戰鬥位置、狀況,突然覺得,在家工作好棒啊,甚至有點享受、開心!只要我進度在掌握中就好拉,也確實,我也漸漸掌握好專案的進度XD

可惜,台灣疫情控制實在太好了,之前公司試行在家工作的制度就這樣無疾而終。

我好想要繼續在家上班啊…

結論:在家上班的前置工作與預備真的要做好

Mysql function/trigger

在做搜尋API這個功能時,因為原有資料庫欄位的設計限制與需要,欄位存了HTML標籤,但這反而造成我們在搜尋類似‘p’這種關鍵字時,會變成所有的資料都被回傳,形同沒有搜尋….  那時還算菜… 同事後來找到一個解法,就是新增新的欄位,利用Mysql function 的功能,再加上trigger , 可以在每次資料庫有異動時,新的欄位可以放入沒有html標籤的原資料,從而在API開發上,搜尋這個新的欄位,就可以克服這個問題

我以為只有oracle 資料庫有這種trigger 功能,因為我以前有在學校上課有修過這個oracle資料庫的課,所以對這個略知一二,但沒想到Mysql 也有這樣的功能,於是花了一點時間重新複習,把以前上課的回憶都找回來了啊… 而網路上,也有幫忙去除html 標籤的現成function,  配合trigger 的onupdate & oninsert , 再配合sql 語法將現在線上資料的html標籤去除,  真的是一個不錯的方案….不過如果你知道有更好的方式解決,歡迎告訴我&交流~

windows docker  問題

因為公司產品有使用到docker, 另外我在公司配備的是 windows電腦 (好想要被配備mac啊~~),於是在某次午休回來時,發現為什麼我的API 會出現問題?明明token , 程式都沒什麼問題啊… 後來我發現好像原來是docker 在windows休眠之後醒來後, docker內部container的時間會和外部window 不是一樣的,因為我的專案有調用到aws的api , 在時間不sync的情況下當然api就出錯了…. 我記得有搜尋到某篇文章說怎麼解決那個問題,好像到window設定什麼東西的….  總之,那是之前遇到的,我也不知道我那時的紀錄丟到哪了,現在我寫文章的時候一直找不到XD  但我說一下我的解法:因為文章裡面交代得實在太麻煩了,於是我決定:重開docker 大法 哈哈哈

Laravel env 問題

我在開發時候,有時候調用一些env的資料, 後來發現, 為什麼都調用不到… 經查詢後發現,原來是因為執行了php artisan config:cache的指令關係…. 詳細可以看看這篇文章:https://learnku.com/laravel/t/3362/laravel-use-env-to-read-the-environment-variable-null

結論:媽的,坑….好拉, 對不起,我沒好好認真看文件所以犯蠢….

Laravel 的queue 和玩玩 graphQL

剛好專案有用到, laravel 的queue 功能, 我預計之後為這個寫一篇專屬文章筆記一下這個, 以後面試可以大膽說用到queue了哈哈

然後因為進度超前及在掌握中,有一些空閒的時間,研究一下之前開發者還沒研究出來的GraphQL, 我裝了rebing/graphql-laravel, 原來,graphQL 是這個樣子…..  在這段時間,比起之前對graphQL有更多更深入的認識了, YA ~

小君曰:真的很久沒寫文章了

賽後小感想以及後續學習

終於來到這最後一天,然而人家最後一天都在寫些感言充廢文,我在這一天還是要稍微帶點技術含量的東西ㄎㄎ

以下東西很多又很雜,畢竟 php 就是義大利麵嘛(大誤),請耐心閱讀~

Laravel Best Practice

介紹一個 Github 專案:https://github.com/alexeymezenin/laravel-best-practices

裡面介紹很多建議的 Laravel 寫法,例如驗證不要寫在 controller 裡面,而是用 Request 類別作為包裝,在寫 Laravel 的時候可以根據這些原則檢核一下自己

Laravel 遇上大架構

當 Laravel 遇到大架構的時候,基本上我們不會把這些東西都只是塞在 Model\Controller\view 當中,而是會使用到 Repository、Service、Presenter 或 Transformer 做包裝,分別控制資料庫邏輯與商業邏輯、顯示的邏輯和格式的回傳,讓程式更加容易維護、易讀

大架構的部分說明你可以參考以下網址:

可以讓 PHP 偉大的其他東西

其實只學會 Laravel 不足以讓 PHP 偉大啦,不過我期許自己是能夠成為越來越強的 phper 的喔!希望你們也是^^

1.學習 swoole:據說這是可以讓 php 效能 up up 的工具框架,是現代 phper 值得學習的一項東西,也是可以讓 php 邁向異步時代的重要推手

2.學習 composer:我還能說什麼呢?沒有 Composer 別跟我說他是現代 php 框架 XD

2.學習 lumen、slim: 剛剛學過 Laravel 一遍了,他就是這麼的肥這麼的胖,所以如果能學會幾個微框架是不錯的,對應 Laravel 來說,Lumen 就是他的簡易版,相信學會了 Laravel 以後,Lumen 上手應該不是什麼太大的難事。

如何學好 php

其實我覺得網路上的資源太多了,容易眼花撩亂而且有時候還會學到舊的。我個人是建議以下這些資料

我個人只推薦這幾個資源,其他就不必了。因為這些資源是可以讓你比較能夠學習現代php的方法與資源。

Laravel 相關資源

  • larvel news: 每週都會寄給你 Laravel 界相關資訊,你也可以加入他的 Procast,順便練習英文聽力
  • Diving Laravel:一個深入 Laravel 核心的部落格,會講到 Queue、job 等等較為進階的功能與核心解釋等。

賽後感言

其實一開始還卡在題目到底要選什麼…然後就咚咚咚的到開賽前一刻才決定好,於是成為了時間驅動寫作,也因為自己的惰性使然,其實有點虎頭蛇尾,自己都覺得自己好像沒有寫的太好……。只能說又學到這次的經驗了~

然後有別於去年我寫的 python,這次的 Laravel 似乎不怎麼討好…所以後面也越寫越沒勁兒,於是成為這樣小蛇尾,我自己應該好好檢討吧 XD

本人的技術部落格:https://tech.r567tw.tw/
歡迎使用 feedly 訂閱我的網站喔 XD

未來我會慢慢的將我鐵人賽的文章慢慢的搬過去我個人網站的,並且加以擴充、更新吧?!應該吧?!

Laravel 套件

今天將帶大家快速帶過幾個官方套件以及個人工作經驗上覺得好用的套件。並且後續也給大家相關的軍火庫可以在日後開發專案上用到。基本上有相對應的需求才用,可以搭配該套件的官方文件撰寫程式,這些基本上文件都很易讀,相信無痛上手是很有可能的喔!

官方套件 篇

首先我一定要先推薦一下 Laravel 官方提供的套件啦,就是這些套件形成 Laravel 一個龐大且厲害的生態系。

  1. Laravel Cashier(官方文件):一個關於金流的套件,他可以與國外金流公司 API 做無痛的結合,例如 Stripe 或者 Braintree,當然,如果台灣的話可以使用其他的套件,例如laravel-newebpay或者laravel-payum
  2. Laravel Dusk(官方文件):還記得我們之前的測試篇嗎?其實 Dusk 這個服務有點像是Browsers的測試,如果你看到文件你就大概明瞭,他是有點 for 終端測試的角色
  3. Laravel Passport(官方文件):一個快速建立 API 授權請求的相關套件,基於 Oauth2 標準
  4. Laravel Scout(官方文件): 一個基於 Eloquent Model 所建立的全文搜索相關開發套件,並且預設以 Algolia 作為驅動
  5. Laravel Socialite(官方文件):我們在網頁註冊的時候,常常看到 FB/Google 一鍵登入對吧?其實實作 Facebook,Twitter,LinkedIn,Google,GitHub,GitLab 和 Bitbucket 等等相關身份驗證機制並不難,這個套件可以提供你這樣的功能~
  6. Laravel Telescope(官方文件):本人認為史上最牛的開發調試工具,可以觀察資料庫、也可以觀察任務工作、Request/Respose 等等

另外還有很多其他的官方套件,不過我覺得很少用所以就不特別介紹了……

個人經驗 篇

  1. laravel-excel(官方文件): 一個可以方便操作 Excel 的套件
  1. laravel log viewer(官方文件):有時候我們會需要 Trace log 好幫助我們能夠 trace Request 或者 Response 喔喔~
  2. laravel-cors(官方文件):前後端分離,你會遇到的 Cors 問題~
  3. laravel-permission(官方文件): Laravel 界最有名的權限/角色管理套件
  4. laratrust(官方文件): 另一套個人覺得也沒好用的權限/角色管理套件,而且他比前面的 Laravel-permission 多支援 Group 的特色,好用!然後文件也寫得和 Laravel 易讀好用。
  5. Forms & HTML(官方文件): Laravel 在 4.x 的版本有所謂的 Form 的語法糖,但在 5.x 版本之後便移除了,很多人還想要繼續有這種功能,所以這個套件便出現了啦!

軍火庫

接下來,我要介紹一下 Laravel 的軍火庫

  • packagist :Laravel 使用 Composer,而 composer 使用的軍火庫也就是這個!
  • packalyst:類似上面的 packagist,不過這是專屬 Laravel 的喔!

Laravel: 遺珠之憾

剩下最後的三天鐵人賽,其實原本我有點想繼續寫下去的…但說真的有點有氣無力,如果你發現我最近這幾天的文章風格與教學,就可以發現我其實有點虎頭蛇尾了哈哈。

所以最後這三天將進入第三階段新的章節,也就是主要會再討論關於 Laravel 的套件、以及大架構、還有 Best Practice 等等的內容,雖然技術含量不高,但也就是我基於我所有的 Laravel 經驗全力輸出了!

不過我個人是還蠻喜歡看書的,在資訊界的領域當中,歐萊禮是很多人常常入門的資訊書出版社。所以這裡,我要學習歐萊禮的寫作風格,寫寫一些遺珠之憾,好讓大家不至於感覺有點一半跑掉,而是後續還能有些內容學習和追蹤。

  • Notifications
    Laravel 有一個類別是 Notifications,有別於我們之前寫到的 mailable 可以寄信,Notifications 可以寄送通知到其他服務,例如 Slack、簡訊、或者其他類似可以收取資訊的內容
  • Queues
    這個東西允許你將一個比較耗時的任務延後處理,好讓你的網頁服務不至於為了處理某些很複雜的請求讓後面在等待的其他請求全部 pedding,無法更快的反應。而他的背後又可以與 Redis 或者 Amazon SQS 等服務一起工作
  • Cache
    Laravel 是個全能型的框架,所以其實他的速度會很,所以 Laravel 允許你快取一些設定檔或者路由,好讓整個網頁的效能可以做個簡易的提升,像是php artisan config:cache或者php artisan route:cache之類的指令都可以做這樣的快取。
  • Frontend
    Laravel 的前端框架預設是Vue,然而,現在他也允許使用React了,在我們目錄底下有一個檔案是webpack.mix.js,還記得我們之前使用Auth的時候就有用到類似npm run build之類的指令嗎,其實就是動用這個檔案裡面的設定與調整。以及 resourse 裡面的 js 檔如何做出編譯也是這部分的課題。
  • Broadcasting(廣播)
    此類課題有點困難,我自己也私自下班玩過一次而已,這個東西其實需要配合前端以及相對應的套件,其中一個用途就是可以寫聊天室、或者與 Websocket 的結合,讓網頁也可以主動通知使用者
  • Event
    它提供了一個簡單的監聽器實作,允許你在應用程式可以訂閱和監聽事件
  • Laravel 及 Redis 相互搭配使用

明天我將分享一些生態系的官方套件以及自己之前工作經驗常用到的套件。明天見囉!

Laravel Collections

接下來,我想要分享關於Laravel 的一個比較特別的類別:Collections
他有點像是陣列的概念,但更像是一個集合的概念。

相信如果你還記得前面教學談到幾行的程式碼,裡面不是有Article::all$article->tags這幾段嗎?如果你去dd()它,你會發現他們都是同一種類別:Illuminate\Database\Eloquent\Collection

當然,如果你有在之前helper的章節發現到collect()這個方法,他其實回傳的也是Collection,但是他是Illuminate\Support\Collection

兩者在使用上會有一些差異,基本上他們也是大部分使用上也蠻像的,所以我就在這裡把他們放在一起講。

兩者使用差異可以參考這篇文章:https://medium.com/@lynnlin827/two-types-of-collections-in-laravel-888d43858c4e

Laravel為Collection這個類別提供許多的方法,例如map()或者avg()等等,其實和helper()那裏一樣,其實文件也大部分都寫的清清楚楚了。
https://laravel.com/docs/6.x/collections#available-methods

是不是有點像是在寫JavaScript在處理呢!沒錯,我也有這樣的感覺。但這樣似乎程式變得更好讀了呢!

另外Laravel在6.0也推出Lazy Collections的類別,是為了處理我們有時候會有大量的資料時候,避免一次全部讀進記憶體,使用到比較現代化的PHP技巧:yield 和 generator,而開發的一個新類別。其實使用方法很簡單,就是將我們原本使用的all()改成cursor()就完成囉!

Laravel 多語系網站

接著前一天的Helper主題,我們那時談到了trans()這個helper,底下應該會常常在使用它,我們有時候會需要有國際化的需求,需要征服宇宙,所以做一個多語系的網站是有必要的。接下來,讓我們來示範一下Laravel這個全能型框架關於多語系能力的展現吧!

網頁要實現所謂的多語系有兩種方法

  1. 建立多個網站(土法煉鋼型):例如我需要有英文和中文的網站,就會英文有一個網站,中文又會有另外一個網站。這兩個網站的樣子可能會有很大的不一樣或者很大的一模一樣,好處是:可以就語系別做出更高的客製化,然後壞處就是:費工,重複造的輪子肯定很多
  2. 使用語系檔將檔案內容作出轉換:以上面的例子來說,可能我會有一個中文的語系檔和另外一個英文的語系檔,根據網站的語系選擇呈現以某個語系檔所轉換過來的文字。好處是:重複造的輪子不多,只要學會翻譯文字就好,壞處就是無法提供給各語系特別的客製化

我大概能想到的優點和缺點就是這樣,如果有大大可以補充歡迎告訴我。
接下來我們將示範說明的會是第二類。使用所謂的語系檔轉換內容。

Laravel 語系檔存放在resources/lang資料夾的檔案裡。在此資料夾內,一個蘿蔔一個坑,一個網站支援的語系對應到一個語系子目錄。像是這樣的結構:

/resources
    /lang
        /en
            messages.php
        /zh-Hans-TW
            messages.php

語系檔裡面放的到底是什麼,其實就是大概這樣而已拉

<?php

return [
    'welcome' => 'Welcome to our application'
];

一般來說,網站的預設語系是在config/app.php這個檔案裡面有一個locale的屬性

   'locale' => 'en',

然而如果我們想要切換語系的話該怎麼辦?其實很簡單,使用App::setLocale($locale);這個方法就可以了,以下讓我們做個簡單的火力展示。

首先是增加個Route規則

Route::get('welcome/{locale}', function ($locale) {
    app()->setLocale($locale);
    return view('welcome');
});

然後分別建立兩個檔案,一個是resources/lang/zh-TW/message.php以及resources/lang/en/message.php,分別在裡面寫這些:

//zh-TW/message.php
<?php

return [
    'welcome' => '歡迎來到我們的應用程式'
];

//en/message.php
<?php

return [
    'welcome' => 'Welcome to our application'
];

之後到welcome.blade.php修改一下,把原本的Laravel那一行替換成

{{ trans('message.welcome') }}

之後到welcome/zh-twwelcome/en就會看到我們這些被轉換的文字呢!

當然拉,這個超級陽春的多語系,其實我們可以利用cookiesession存放語系值,藉由前面我們說到的middleware,加上app()->setLocale($locale)來做我們語系上的設定喔。

以下是參考的文件:

今天得程式碼不多,要看完整程式碼的可以參考這裡:
https://github.com/r567tw/Make-PHP-Great-Again/commit/9957deac8788ee8bd20ccb3a0cd8ce867e352f0e

Laravel Helpers

寫到這裡,終於剩下最後的5天就可以完成這整個鐵人賽!(撒花

接下來希望自己再接再厲。繼續完成後續幾天的Laravel 教學系列。
今天也是個簡單風(好幾天都是簡單風了QQ)

介紹一下Laravel作為一個全能型的框架,還提供了一些稱為「Helper」的東西幫助我們可以整理程式碼、封裝了一些我們常常會弄到的部分,也可以稱之為「語法糖」,總之幫助我們可以避免「重複造輪子」。而順道一提的是:我們之前也早已用過這些東西了:例如route()view()或者factory()

如果你看到文件:https://laravel.com/docs/master/helpers

其實大概這些語法可以分類為以下幾種:

  1. 陣列及物件類:可以處理陣列與物件的資料等,例如:Arr::add()Arr::where()
  2. 路徑類:就是Laravel一些資料夾的路徑,像是public_pathstorage_path()
  3. 字串類:可以處理我們的字串,Str::cameltrans(),預告一下明天將會討論關於多語系的網站設計,trans()便是我們到時會可能會用到的方法~
  4. 網址類:像是我們之前會用到的route()方法、以及asset()方法都是回傳一串的網址。
  5. 其他:像是無法歸類以上四類的,之前我們用到的view()或者factory()都在這個裡面,而這裡我也順道介紹一個我們在debug常常會用到的dd()

在你任何想要的地方,如果你想知道這個值到底傳出來是怎麼樣的值、怎麼樣的型態,你可以使用dd(),例如我們昨天的分頁:

dd(Article::paginate(5))

當執行到dd()的時候會立刻終止那一段程式,並且var_dump回傳被dd的值與型態,像是這樣
https://i0.wp.com/ithelp.ithome.com.tw/upload/images/20191010/20106999CVvC4sVxvE.png?w=840&ssl=1

我覺得Laravel的文件是世界上最好讀的文件,我想剩下的你們應該可以自行探索吧XD