之前，讀了這本「你要如何衡量你的人生」，到現在整理一些簡易的心得才po上來......

最近人生其實頗為迷惘、或許是到了一個人生路口吧！現在所做的工作也不是到自己頂級喜歡的，然而、哪有工作是完美的、是天天都讓自己喜歡的呢？

在高中畢業時，其實學妹就有推薦我讀這一本書。然而笑。死。

我到現在才開始買這本書、讀這一本書XD

說到底，這本書要回答三個問題：

• 如何知道自己的職涯可以成功、快樂？
• 如何知道我與配偶、兒女及朋友的關係可以成為快樂的泉源？
• 如何知道我的這一生會堅守原則、免除牢獄之災？

那作者舉出了一些企業的例子，來類比到我們人生的許許多多決策、討論中。老實講我覺得並不是那麼好讀...相對應這本書的類型，我更推薦「大人學選擇」這一本書，剛好最近它要再版，我已經將它果斷放進我的書單當中＾＾

關於第一個問題，作者其實也說中我的一個內心想法：「希望一早起來能為了自己喜歡做的事情感到快樂、而不是『又要上班了』...」阿關於那些怎麼選擇工作的因素與關鍵我想也都是那些老生常談，像是薪水大概不是最最關鍵的因素拉、成就感拉、意義感啊諸如此類的，但我覺得被提醒的是：可以有個「B計畫」，像我現在自認自己在執行的正是B計畫...

至於第二個問題，誠如阿德勒說過：「所有的問題都來自於人際關係」。其實作者也大概提醒我們要花時間投資這一塊，尤其是親子這一塊兒

阿第三個問題，作者很清楚且很簡短的回應就是：「不要越界、連第一次都不行」，我向這蠻符合我們教會傳統的教導。畢竟作者是摩門教教徒，和我們基督徒也算是一種親戚麻？

小君曰：不知道該如何衡量我的一生

我覺得 Laravel 的 Authentication 其實變了很多。

從一開始可以使用php artisan make:auth 做一個簡單的auth起手架以後，往後變成要下載package，到現在可以根據不同的情境使用不同的package。

真不知道該說這是變得麻煩還是越來越進步？(我私心覺得，是進步！)

1. Breeze

如果懷念以前的make:auth的時光可以使用這個package，附帶前端UI, 使用 Tailwind CSS 作為樣式配置

教學文件可以參考：https://laravel.com/docs/9.x/starter-kits

2. Sanctum

我最近開了一個新的laravel專案，最近就有附帶這個package，他有點像是firebase那一種，總之如果你要簡單實作token based 的系統可以使用這個package，但他最大的缺點就是沒有支援oauth，如果要使用oauth請左轉去用Passport，否則他其實和passport很像的。

詳細教學可以參考：https://laravel.com/docs/9.x/sanctum#main-content

3. Passport

他比Sanctum早出生很多，或許在implement token based 以前專案都會使用這個套件，我自己目前還沒玩過(聽說未來我新公司會用，蠻期待的)。 和sanctum 最大的差別似乎就是他有額外支持oauth的部分，如果你有oauth的需求請直接使用這個套件拉

詳細教學可以參考：https://laravel.com/docs/9.x/passport

4. Fortify

這個套件有點神秘，他一個與其他auth相關套件最大的差別就是他沒有前端實現 所以我個人認為應該是比較適合已經存在的專案之類的，或者你只是想要 純後端實現的認證系統。

相關教學可以參考：https://laravel.com/docs/9.x/fortify#main-content

小君曰：我個人自己有在玩Breeze&Sanctum，不得不說，Sanctum真的很不錯，我喜歡。

最近突然心血來潮看到這篇 Laravel new 的 post: https://laravel-news.com/building-your-own-laravel-packages

於是起心動念開始寫一個 package來玩一玩。 詳細程式碼在這裡：https://github.com/r567tw/laravel-package-practice

首先，要有composer

既然要寫一個自己的客製package，當然要先有composer.json呀 於是讓我們先composer init起來！或者你要手動建立composer.json也是可以

總之，你composer.json 裡面的內容應該要包含以下

{
    "name": "{你的名稱}/{你的套件名稱}",
    "type": "library",
    "license": "MIT",
    "autoload": {
        "psr-4": {
            "{你的名稱}\\{你的套件名稱}": "src/"
        }
    },
    "require": {
        "php": "^8.1",
        "illuminate/support": "^9.23"
    },
    "extra": {
        "laravel": {
            "providers": [
                "{你的名稱}\\{你的套件名稱}\\Providers\\PackageServiceProvider"
            ]
        }
    }
}

• extra 是給laravel 看的，laravel在某個版本之後啟用autoload service provider，「粉方便」
• 主要要require illuminate/support這個套件
• 通常我們會使用src這個資料夾，但如果你想特立獨行也是可以拉
• 要寫一個 serviceprovider 檔，如果之後有機會來記錄筆記一下Laravel這個service provider 這個東西，一定可以學到很多！

寫一個service provider

我這個套件的目標很簡單，就是弄出一個artisan 的指令來helloworld一下就好，所以這邊我在src/Providers裡面建立PackageServiceProvider.php檔

<?php
declare(strict_types=1);
 
namespace Fang\LaravelPackagePractice\Providers;
 
use Illuminate\Support\ServiceProvider;
use Fang\LaravelPackagePractice\Console\Commands\FirstPackageCommand;
 
final class PackageServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        if ($this->app->runningInConsole()) {
            $this->commands(
                commands: [
                    FirstPackageCommand::class,
                ],
            );
        }
    }
}

如果你想弄別的其實也可以參考他自家文件，很清楚：https://laravel.com/docs/9.x/packages

準備FirstPackageCommand

如果你是想弄別的，這一步可以略過弄你的版本即可，我以我自己練習用的為例 firstPackageCommand 裡面其實就這樣

<?php
namespace Fang\LaravelPackagePractice\Console\Commands;
 
use Illuminate\Console\Command;
 
final class FirstPackageCommand extends Command
{
    protected $signature = "practice";
 
    protected $description = "just say helloworld";

    public function handle()
    {
        $this->info("it's practice package");
    }
}

於是你的套件完成了！

單元測試

我個人比較雞婆一點，想要弄一個簡單的單元測試。 所以使用到一個套件orchestra/testbench 於是我的composer.json 就增加以下這段

    "require-dev": {
        "orchestra/testbench": "^7.6",
        "phpunit/phpunit": "^9.5"
    }

至於我的案例呢？我只是簡單寫一下

<?php

namespace Fang\LaravelPackagePractice\Tests\Unit;

use \Orchestra\Testbench\TestCase;
use \Fang\LaravelPackagePractice\Providers\PackageServiceProvider;

class FirstPackageCommandTest extends TestCase
{
    protected function getPackageProviders($app): array
    {
        return [
            PackageServiceProvider::class,
        ];
    }

    /** @test */
    function the_command_will_info_message()
    {
        $command = $this->artisan('practice');
        $command->expectsOutput("it's practice package");
    }
}

• 這裡很重要，請記得要寫getPackageProviders這個function 注入你的service provider! 我這裡卡關卡很久...

於是下vendor/bin/phpunit就可以試看看有沒有過啊！

終端測試一下

如果你想要公開給別人用，可以弄到packagist，但我！不！想。

所以你可以更簡單一點在你新的laravel專案底下composer.json加上這一段

"repositories": [
        {
            "type": "vcs",
        }
    ]

然後呢？ 執行composer require {你的名稱}/{你的套件名稱} 就好

以我這個案例為例：執行php artisan practice 就會看到我的成果：it's practice package

小君曰：寫 pakcage 給別人玩吧！

好的工程師通常對於自己的 code 會有所在意，並思考著如何能讓程式碼更讓人好懂,好閱讀。 以及通常團隊裡也會有統一的coding-style。

在 Laravel 9 之後有個套件我覺得很有趣，它就在某個程度上就解決了這個情境 個人認為蠻值得簡介一下，叫做 Laravel Pint。

安裝

首先, 我們先安裝這個套件。

composer require laravel/pint --dev

安裝完之後，你就可以使用./vendor/bin/pint這個指令了。

取得版本

vendor/bin/pint --version

客製化

在文件裡指出，coding-style 可以被客製設定。在root 目錄建立一個叫做pint.json的檔案即可。 裡面的內容則是

{
    "preset": "laravel"
}

這樣它就會設定 laravel 為這個專案的固定 coding-style。 如文件說明，你也可以客製底下的rule 來處理。

如果想要看的更多可以參考這裡：https://laravel.com/docs/9.x/pint

by the way: 也可以看這個影片：https://www.youtube.com/watch?v=dvxzuH2ds8A

小君曰：如何成為一個好的工程師永遠是我人生上的一大哉問。

我其實是一個不太喜歡苦工的工程師，我很喜歡用程式解決我個人的生活問題。自動化最棒了！

之前有個想法希望可以買黃金，剛好看到github action 有所謂的schedule 的選項，於是我就有個大膽的想法：不如就讓line 來通知到要準備買黃金拉

專案開發

原本他只是個簡單的黃金買賣通知，結果到最後我把他寫成通知天氣預報、股票等買賣的決策系統通知了XD

或許之後還可以有更多細緻化的設定，反正他就是個超簡單的side project, 技術基於 line notify, github action 及 python。黃金、天氣與股票各由負責的python script 處理，算是有點為服務的feel 吧？

如果以後line notify 壞掉了怎麼辦？

其實就把helpers/notify.py裡面的程式調整修改就好了，這個side project 最最最核心的程式應該就是他了，其他服務都是有各自的實作之後呼叫這裡的function 去 line notify 通知我。

import os
import requests

def send(message):
    token = os.getenv("TOKEN")

    requests.post(
        headers={'Authorization': "Bearer {}".format(token)},
        data={"message": message}
    )

line notify 這個服務有夠簡單，其實就是簡單發出個POST request 就好，然後你可以去 line notify 的頁面申請token就好。

github action 就是簡單寫一下 yaml ，我以我最自豪的黃金為例

name: gold-notify
on:
  schedule:
    - cron: '30 3 * * 0-4'
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: checkout repo content
        uses: actions/checkout@v2 # checkout the repository content to github runner.
      - name: setup python
        uses: actions/setup-python@v2
        with:
          python-version: 3.8 #install the python needed
      - name: install py package
        run: pip install -r requirements.txt
      - name: execute py script # run the run.py to get the latest data
        run: python gold.py
        env:
          TOKEN: ${{ secrets.TOKEN }}
          GOLD_BUY: ${{ secrets.GOLD_BUY }}
          GOLD_SELL: ${{ secrets.GOLD_SELL }}

其實上網查就有發現到有人寫好執行python的github action, 你只要照抄其實就可以給他執行起來。而在on 裡面規劃一下schedule，其實就有點像是個人助理的感覺，line notify 在一定的時間可以通知訊息給你。

結果與影響

我順利在低點購買到黃金，然後最近俄烏戰爭開打黃金上漲。我賺到一波真棒

PS. 原本這個專案只是叫什麼gold-notify 之類的，但為了中二，我把他取名成jarvis 哈哈哈

小君曰：來喔，歡迎大家拿這個idea & project 去做成你們自己的 jarvis 吧

Pragmatic Programmer 他談很多題目，裏面也談到很多如何寫程式的廣泛技巧，例如第一篇我們談到的正交性, 以及知識資產的部分。未來可能我也會陸陸續續分享他各種不同的篇幅與個人領悟。

這次我想要分享他其中一個篇章：需求坑。

做軟體工程師越久，就越覺得這個小篇章所講的有感。我們常常把客戶的“第一次需求”當真，並且就一頭埋入實作它的解決方案。

這種最初的需求並不是真正的需求。客戶可能本身沒有意識到這一點，但其實這種需求是一種邀我們去進一步探索的邀請

如同這本書定義需求是一種過程，是藉由一次又一次的回饋當中循環暸解的。

另外有感而發的是：之前網路上看到某粉專寫道的一句話

有時候我們在實作處理需求時，或許不要總是陷入一定要寫很多程式碼。有的時候不用寫程式的解決方案可能比寫一堆程式碼會是更佳優秀、適合的解喔

小君曰：less code, more better

在這個小篇章，我最有印象的是這句話：

管理知識資產與管理金融資產非常相似

像是你管理金融資產會注意以下幾點：

1. 定期投資(固定時間有週期的學習、調整)
2. 多元化(不要把雞蛋放在同一個籃子裡)
3. 管理風險
4. 低買高賣
5. 審查與調整

相對的，你如何管理知識資產，如何進化你自己的程式功力就也是這樣！於是Pragmatic Programmer 這本書就提出幾個務實的建議，我整理如下：

• 每年至少學一門新語言
• 每個閱讀一本技術書
• 也要閱讀非技術的書
• 上課
• 參與本地使用者群組或會議
• 批判性思考：「為什麼」、「這對誰有好處」、「時空背景是什麼」、「何時何地用」、「為什麼會有這個問題」

小君曰：我覺得每一年排一次出去外面面試其實也是個不錯的 idea.

最近有點水貨，都在讀一些書，不過最近在看得這本書個人私底下認為應該作為工程師必看的一本書之一。原因是你可以從這本書或多或少得到一些啟示、有用的技巧可以帶回到你個人的專案當中，而且他應該算是可以每一年都拿出來複習一遍的好書之一。

這本書如同標題所示：The Pragmatic Programmer。天瓏書局也有在賣，歡迎去購買～(連結)，

這本書談了很多東西、像是重構、測試、需求與開發等，與之前我看的軟實力不同，前者偏向做人與軟體工程師的人生，但後者更比較偏向軟體工程師的實際操作、練習等等，相比之下，我比較喜歡後者，也就是Pragmatic Programmer

他有點將內容分成很多一小段一小段的，我覺得非常適用於我們目前這種速食閱讀的時代，偶爾就能翻一翻幾個小篇章提醒自己一下，而且它也不一定適用要從頭讀到尾的那種閱讀方式。

像最近他就講到需求是一種過程就很有感覺，他說到菜鳥開發人員最常犯的一種錯誤就是聽到客戶的需求就馬上做，但根據經驗來看，很多時候客戶的初次需求往往不一定就真的是需求，是需要一步一步藉由回饋加以確認的！

另外原本我有點不喜歡我家老闆一直care 我API的規格，甚至有時候明明就這幾個欄位前端不會用到，卻硬是被要求去傳...，但讀到這裡有個篇章：正交性，主張一個好的系統可以讓其中一個的變化不會影響其他任何一個，舉個例子來說，就像資料庫程式碼與使用者介面應該要是正交的

這不免就讓我發現原來我老闆的顧慮或許是正確的

但是正交性真的也能應用於我與前端溝通用的API嗎？這裡我給個問號

最後，我覺得這本書帶給我新的立志：成為Pragmatic Programmer（務實的工程師） 比起之前我想的，成為專家？成為厲害的工程師？我倒覺得這個flag務實多了

那麼什麼是務實的工程師呢？

1. 重視你手中的工作與手藝(程式碼)
2. 找出合適的解決方案
3. 虛懷若谷、持續學習

小君曰：我是一位務實的Programmer......

最近讀了一本書叫做「原子習慣」，是一本很常在暢銷榜上的一本書...作為工程師，非技術相關的書還是要有些涉獵啊～

之前買過這本書，後來賣掉。但後來又覺得想把它買回來，於是在五倍券發放的時候又把他買下來了XD

現在想來真的覺得自己蠻蠢的呵呵，有興趣的可以自行去買書，我這裡就記錄一下我從這本書獲得的心得。對了！ 我覺得這本書很棒的一點是他每一章後面都有重點整理、然後重點的句子都會做粗體標示，這帶給我很不錯的閱讀體驗，但相對也讓我有點難想一個字一個字讀下去...

• 如果你覺得改變習觀很難，問題不在於你，而在你的系統
• 改變有三種層次：結果、過程與身份認同
• 習慣就是重複次數多到足以自動化的行為
• 習慣形成的四個步驟：提示、渴望、回應(我這裡比較想翻譯成執行...)、獎賞

法則一：提示

• 讓提示顯而易見
• 對自己實際的作為保持意識、保持覺察，是改變習慣最大的挑戰之一(講到日本列車員指差確認部分...)
• 當X情境時發生時，我就會執行Y反應
• 盡量避免把一個習慣的情境跟另一個習慣的情境混在一起
  • 例如：手機

法則二：渴望

• 讓習慣有吸引力
• 所處文化決定了哪些行為對我們有吸引力
• 我們最早的習慣並非來自選擇，而是模仿
  • 這部分在談談夥伴與社群的部分...
• 創造一個動機儀式：在執行困難的習慣之前，做一件你很享受的事
  • 重新思考你的習慣，把重點放在益處而非壞處(要懂得轉換思考模式好讓自己維持習慣)

法則三：回應

謎之音：這裡有DevOps的味道...

• 讓行動輕而易舉
• 關鍵是由重複開始，而非完美...開始重複實行就對了
• 最小努力原則：讓習慣簡單到就算沒有意願也會執行
  • 兩分鐘法則：新習慣的開始應該要花不到兩分鐘

法則四：獎賞

• 讓獎賞令人滿足
• 前三個法則是增加我們執行某個行為的機率，但獎賞法則是增加我們下一次重複該行為的可能性
• 習慣追蹤
  • 「當測量成了目標，就不在是個好的測量方式」測量只有在引導你、幫助你看清全局、而不是消耗你心神的時候，才對你有用(古德哈特定律)
• 習慣中斷：基本上不要錯過兩次，盡快恢復正軌

寫在法則之後

• 當習慣符合你天生的傾向與能力，執行起來就比較容易，堅持下去也比較令人滿足
• 基因決定的不是你的命運，而是你在哪個領域會有機會(性格如何影響習慣)
• 反省與複查是一個讓你對自身表現長久保持覺察的過程

個人回應與結論

其實對我來說重點與癥結點在於「回應」，也就是執行。還有如何創造一個系統，讓自己維持習慣的執行與養成。

例如每天早上就是讀聖經、背英文單字和學習程式這樣，有一個早晨的「習慣set」，或者下班就是去運動、睡前小閱讀幾頁的書...這樣的一個晚上「習慣set」...總之，我們都希望自己成為更好的人吧?!

小君曰：不想要成為一直耍廢、退步的人...