之前看到一個文章，印象中說是英國有種高級的計程車司機考試非常的難考，幾乎是把國家所有的地圖記在腦中。後來 Uber 崛起，本來還在說線上地圖的導航跟本無法比上這些考試出來的人，時至今日將被打敗的卻是老司機。
那個文章用這個故事類比程式開發人員，說明我們遲早被 AI 取代。
我也只能說，我早就說過了。雖然我當時的理由是，老闆根本不在意程式碼品質，但事實上那個品質差不到哪去，尤其是你先寫好文件載明用什麼架構、用什麼框架的時候。
我現在接手的專案，有各種不同團隊接手過的痕跡，圖片載入一種 library 就可以完成的事，專案用三種不同的 library 來解決，比 AI 寫的差多了。
現在連 Linus Torvalds 都在用 AI 寫程式了，我實在不覺得我害怕被取代到底哪邊不對，但總有人想說服其他人 AI 就是垃圾。
不知不覺就更新了。
當初它還在 dev 的時候我就有試過一些東西，今天也把我直播畫面上的聊天室給更新上去了。
在我的聊天室專案中最主要被影響到的應該是 StateNotifierProvider 被移到 legacy 了，基本上這一升級就會跑紅線出來，很容易找到。
偷懶的做法，就是引用 legacy 的檔案，這樣程式碼本身就不用改。
勤勞一點的話，就改用 NotifierProvider，如果是像我一樣沒有使用程式碼生成情況，要把 (ref) => Notifier() 中的 ref 給拿掉，Notifier 則要實作它的 build()。
另外就是 StateProvider 也被丟到 legacy 了，這個比較煩，因為我覺得這個沒要做什麼的話，一行就能寫完還是比較輕鬆的。
有用程式碼生成的是我在公司寫的範例專案，但現在公司有去限制套件庫得用公司內部的， riverpod 的升級還得申請，那邊的話就先放著吧……。
記錄一下。
所有提交至 Google Play 且目標為 Android 15 或更高版本的應用程式在2025年11月1日後必須支援 16KB 記憶體分頁大小，大部份的情況應該是不用做什麼調整才對，但有可能發生使用到的 library so 檔沒有做這個調整。
這件事 Google Play Console 就有得看，進到 Test and release 分類中的 Latest release and bundles，下方 Latest app bundles 選到最新的版本，進入查看詳請，在最下方就有 Memory page size。
點開 Show detail 就會提示有哪些檔案不符合要求。
在公司強制使用 AI 寫程式，甚至希望我們 100% 使用 Cursor 的今天，我跟其他工程師的看法不太一樣，認為我們終會被 AI 取代的。
為什麼？因為太方便了。
直接跟 AI 溝通，跟我得面試一個能用的人，這邊就有時間成本上的差異了。特別是，老闆找人通常都不是只找能用，而是找高手來解決其實不需要高手就能解決的問題。
從我進到這間公司，一直接收到跟敏捷一併宣傳的概念都是，產品要推出去才能賺錢，這個找人的時間明顯是個問題。
其次，我在工作上也老是看其他人說要做什麼什麼彈性，以免下次要做類似的東西得花三天來重構，結果就是多花了三天把帶有彈性的功能完成，下次需求進來，這邊全部砍掉重練，花三天的彈性等於沒有彈性。你要怎麼知道你找進來的人不是這種高手？
說到底，程式的價值不是由工程師決定，而是由賣了多少錢決定，越早開始賣，越有可能先出頭。
NPM 与 left-pad 事件：我们是不是早已忘记该如何好好地编程？
這篇文章我久久想到就又會拿出來看一次，有時候我會覺得有個套件是省事，比方說你要在 Android 上顯示圖片，你希望它有快取、能播放 GIF ，你自己來得花多少時間？有個 Glide 省事多了。
另外有些人注重測試，你看他下載數這麼多，這表示有很多人驗證過了。
但有時遇到的就不是這樣。
就一個 left-pad，寫一個能花你多少時間？有多容易寫錯？
又比方說會遇到這個我們前團隊有用，我們寫 Flutter 應該有個狀態管理框架以方便開發，結果用下去跟官方的使用範例長的差很多，本來邏輯分離的目的全沒辦到，用 UI 元件當狀態傳出去，收到 UI 的 UI 又要寫一些邏輯來判斷該不該顯示收到的這個狀態 UI。
這說明什麼？程式能跑就好，套件能讓你省下更多時間去思考話術，邏輯分離或設計模式講的好聽都只是為了你的官階，建議是講好一點，不要跟錢過不去。
記錄一下，因為很煩。
這東西經常會忘記跑，尤其是產生出來的東西明明不會動到 hashcode 會變這點更煩。
到 File -> Settings -> Tools -> Startup Tasks 新增一個 Execute 選 Script text，指令是 dart run build_runner watch，有用 fvm 的話記得加在開頭。
有時候就是你也沒有很想要相信，甚至這個社會會教你一些傳統美德，努力會出頭天啊、先累積實力啊之類的。
沒有，你運氣好就能做14年工作才被開除。
搞不好運氣再好一點，法官還能判一個做不到新人做三個月能做完的工作的大佬復職。
再厲害一點的話，大概就是工作18年，不會民國轉西元，但當到資訊室副主任吧。
希望我昨天教了我的上級工程師怎麼在建構式用 super 能累積我的功德、讓我中樂透頭獎。
最近在升級專案使用的 flutter 到 3.27，也升級了AGP，遇到各種問題。
先是有套件是沒有在 gradle 放 namespace，丟了 PR 也不理，只好自己 fork。
然後不知道為什麼，沒放 jvmTarget 的套件也會有相容性問題，就隨便給他指定一個低的。
allprojects {
tasks.withType(KotlinCompile).configureEach {
kotlinOptions {
if (jvmTarget == null) {
jvmTarget = JavaVersion.VERSION_1_8.toString()
}
}
}
}然後其他的事讓 toolchain 處理。
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}然後怪事就來了，flutter_statusbarcolor_ns 這個套件不知道為什麼，toolchain 指定 21 的時候會跟你說沒辦法跟 17 相容，指定 17 的時候又會跳 class file has wrong version 65.0, should be 61.0，後來實在搞不定，最後只好在 gradle.properties 加個設定忽略這個檢查。
kotlin.jvm.target.validation.mode = IGNORE有空再研究為什麼。
說是遊記是因為，它著實對我目前的工作沒太大用處。倒也不是說內容差，而是我真的無能為力。
這次AI主題大概占了七成吧。
首先是這個，至少我在串 Gemini 的時候是有自覺的，當時也只當作是一種用 Flutter 寫小工具的練習，以及看一下這個 API 怎麼用。
以我有聽的議程來看，AI 的用法大概是辨識、生成內容、作為介面這三種方式。
辨識這東西，主要是第一個只有一個議程的那個時間段吧，很硬，各種公式，線性代數、矩陣、微分都來，大概是給研發AI的人看的，不是給上面那張圖指的對象聽的。
生成內容跟作為介面算是同一件事，目的的差別而已，比方說，你要生出內容，讓跟他說你要生出什麼內容，雖然聽起來很像廢話，但以作為介面的角度來看就會變成你能把 AI 丟到別人的面前了。
比如 multiON 控制電腦買東西，或有個議程就丟到使用者的面前，讓使用者對 AI 下命令，AI 就會生成指令去打 API，完成使用者的命令，這部份體感上是「AI 幫你做事」，背後的運作是「AI 生成指令」，還是生成內容。
但你要怎麼信任 AI 會做對的事……。
現在 AI 有幻覺的問題，但不談這個他也可能搞錯，或下命令的人本身也搞不懂他自己想下什麼命令。好像我們平常對其他人下命令都有可能有這個問題了，那不如回到我們平常會有的設計，動作前確認或動作後復原吧。
比較有趣的是，Akane 的主題《沒靈感的設計師找 AI 幫忙有用嗎》，開場就說了沒靈感的成因通常出自心理問題以及環境或工作經驗造成我們必須不要有靈感，AI 不是一個心理醫生，也不能改變工作常態，看待它還是要以工具來看，至少它還是能生出東西的。
另外還有九歲小朋友跟 AI 來回溝通，最後寫出記帳 APP 這件事。我現在看起來，它就算沒有 AI，小朋友能開發這件事還是遲早會發生。有些東西在我沒有清楚概念的時候就能寫出程式了，到了現在也看過不少連基礎概念都沒有也能寫出程式的人，我想現在市場還是缺開發的碼農吧。
講講 AI 之外的。
《讓數據說話：用 Python、Prometheus 和 Grafana 講故事》這個議程有個概念，如果不幸，機器有某些原因造成監控沒辦法主動去拉資料，那不如果讓它主動把資料打出來到另一台機器上，再讓監控去拉，這樣實際上出去的資料範圍就能被控制，實際運作的機器也不需要公開在外面。
unconf 講到敏捷開發，國泰的人有提到會議種類。讓我想起主管講過：「我記得我們以前沒有 Refinement，你們哪邊生出來的？」它不在 scrum guide，應該是後續需要所以生出來的。另外也提到，敏捷主要是要解決不肯定的東西，肯定的東西不太需要那個來回小步的去確認做的東西對不對的過程。所以以我們現在的團隊來看，有很大一部份我們需要的是敏捷裡會用到的管理做法，而不是需要敏捷。即使如此，站會或回顧會議都還是很好的概念，只是會變形成「做敏捷事的非敏捷」，因為東西太明確了，動態調整不來。
framework 筆電看起來滿有趣，可以抽換模組，連鍵盤也是模組，但我現在三台筆電了，還三個不同系統，目前應該是沒什麼購入的需要。
可開機的容器，看起來是用不可變的核心掛載可變的設定來跑，如果有特殊的驅動就要先編好然後去改設定檔讓它安裝。Linux 我用的不太深入所以改啥東西我也沒搞太懂。我在想這設定的移轉方便的話，那驗證系統升級也很方便，但我現在的工作不碰這個所以(ry
議程外的事，我下午茶排隊排到桌子的地方就沒東西了，不知道這份量怎麼估的，還好還有另外放餅乾。
大致上就這樣吧，MOPCON 網站有放共筆，可能比這篇遊記有價值點。
更新 IDE 後發生了一個慘劇。
從錯誤訊息上看的出來，因為我在前一版開了 ZGC，但新的 IDE 不認得這個選項了。
如果照著他說的，重新安裝 IDE，什麼都不會改變，因為它的設定檔還是在那邊。
這時候到 %AppData%\Roaming\Google\ 找到這個版本的資料夾，用文字編輯器打開 studio64.exe.vmoptions 這個檔案，把有問題的設定砍掉就解決了。
