分類: 隨口說說

  • 用英國的計程車司機類比程式開發

    之前看到一個文章,印象中說是英國有種高級的計程車司機考試非常的難考,幾乎是把國家所有的地圖記在腦中。後來 Uber 崛起,本來還在說線上地圖的導航跟本無法比上這些考試出來的人,時至今日將被打敗的卻是老司機。

    那個文章用這個故事類比程式開發人員,說明我們遲早被 AI 取代。

    我也只能說,我早就說過了。雖然我當時的理由是,老闆根本不在意程式碼品質,但事實上那個品質差不到哪去,尤其是你先寫好文件載明用什麼架構、用什麼框架的時候。

    我現在接手的專案,有各種不同團隊接手過的痕跡,圖片載入一種 library 就可以完成的事,專案用三種不同的 library 來解決,比 AI 寫的差多了。

    現在連 Linus Torvalds 都在用 AI 寫程式了,我實在不覺得我害怕被取代到底哪邊不對,但總有人想說服其他人 AI 就是垃圾。

  • AI 寫程式的年代

    在公司強制使用 AI 寫程式,甚至希望我們 100% 使用 Cursor 的今天,我跟其他工程師的看法不太一樣,認為我們終會被 AI 取代的。

    為什麼?因為太方便了。

    直接跟 AI 溝通,跟我得面試一個能用的人,這邊就有時間成本上的差異了。特別是,老闆找人通常都不是只找能用,而是找高手來解決其實不需要高手就能解決的問題。

    從我進到這間公司,一直接收到跟敏捷一併宣傳的概念都是,產品要推出去才能賺錢,這個找人的時間明顯是個問題。

    其次,我在工作上也老是看其他人說要做什麼什麼彈性,以免下次要做類似的東西得花三天來重構,結果就是多花了三天把帶有彈性的功能完成,下次需求進來,這邊全部砍掉重練,花三天的彈性等於沒有彈性。你要怎麼知道你找進來的人不是這種高手?

    說到底,程式的價值不是由工程師決定,而是由賣了多少錢決定,越早開始賣,越有可能先出頭。

  • 寫程式有多少東西需要自己來?

    NPM 与 left-pad 事件:我们是不是早已忘记该如何好好地编程?

    這篇文章我久久想到就又會拿出來看一次,有時候我會覺得有個套件是省事,比方說你要在 Android 上顯示圖片,你希望它有快取、能播放 GIF ,你自己來得花多少時間?有個 Glide 省事多了。

    另外有些人注重測試,你看他下載數這麼多,這表示有很多人驗證過了。

    但有時遇到的就不是這樣。

    就一個 left-pad,寫一個能花你多少時間?有多容易寫錯?

    又比方說會遇到這個我們前團隊有用,我們寫 Flutter 應該有個狀態管理框架以方便開發,結果用下去跟官方的使用範例長的差很多,本來邏輯分離的目的全沒辦到,用 UI 元件當狀態傳出去,收到 UI 的 UI 又要寫一些邏輯來判斷該不該顯示收到的這個狀態 UI。

    這說明什麼?程式能跑就好,套件能讓你省下更多時間去思考話術,邏輯分離或設計模式講的好聽都只是為了你的官階,建議是講好一點,不要跟錢過不去。

  • 14年

    有時候就是你也沒有很想要相信,甚至這個社會會教你一些傳統美德,努力會出頭天啊、先累積實力啊之類的。

    沒有,你運氣好就能做14年工作才被開除。

    搞不好運氣再好一點,法官還能判一個做不到新人做三個月能做完的工作的大佬復職。

    再厲害一點的話,大概就是工作18年,不會民國轉西元,但當到資訊室副主任吧。

    希望我昨天教了我的上級工程師怎麼在建構式用 super 能累積我的功德、讓我中樂透頭獎。

  • MOPCON 2024 遊記

    說是遊記是因為,它著實對我目前的工作沒太大用處。倒也不是說內容差,而是我真的無能為力。

    這次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 網站有放共筆,可能比這篇遊記有價值點。

  • Firefox 支援 zoom 了

    之前的文章說到我又改回用 Firefox 了,因此為了玩 GBF,我除了改 user-agent 以外還做了一點手腳,但平時還是以手機玩居多。

    想不到上個月開起來之後又大跑版,研究了一下,才發現五月的時候 Firefox 支援 zoom 了,大概是這東西從非標準的 css 被列為標準,至少我在2月的時候看 caniuse 它還是寫 Non-standard method of scaling content。

    以前絕大多數的問題都是 zoom 的原因造成,本來我是用 transform:scale 來解決,但問題還是很多就是了,畢竟實際的行為也不同。

    目前某些地方的寬度還是過寬沒有改變,並且多出了 border-image-slice 不一致的問題。

  • Firefox 在 Youtube 不同語言的字體問題

    最近又把 Edge 蛋雕,裝回 Firefox,在選單把預設字體改為 Noto 系列之後,Youtube 對不同語系的文字就出現不太一致的現象。

    看了一下,Youtube 把字體指定成 Roboto,在不能顯示中文的情況下就去找我設定的 Noto Sans CJK TC,但日文顯然並沒有去找我設定在日文的 Noto Sans CJK JP。

    為什麼?看了這篇文章我有個猜測,它似乎是去讀了 Youtube 中 html 標籤裡 lang 設定的 zh-Hant-TW,去找對應的 Noto Sans CJK TC,然後就去找 about:config 中 font.name.{generic}.{language} 所設定的那些了。

    在選單中每個語系設定的那些就不管你了。

    像是 font.name-list.sans-serif.ja 預設是 Meiryo, Yu Gothic, MS PGothic, MS Gothic, Yu Mincho, MS PMincho, MS Mincho,明顯不是我要的。

    當然這只是猜測,我不是很肯定猜的對不對,但要解決這個問題只要把我的 Noto Sans CJK JP 放到這個設定值的開頭就完成了。

  • 死了但也沒死

    記得有一年參加了線上的 Agile Summit,有一軌在看著指南講 Agile 確實有點毛病。

    過了幾年突然想起這件事,去用「agile 已死」當關鍵字找東西,但出現的只有敏捷已死。

    看了一下內容,跟當初在 Agile Summit 的內容相差很多,講的主要是「敏捷」兩個字只有行銷招牌的用途,沒有實際功能,所以該換個名字再來一次。

    這論述明顯是有點問題的。

    如果換個名字能夠推廣其中的價值,那不是表示內容其實沒有問題嗎?

    然而,確實,就我目前跑敏捷的感想,內容依然能帶給你他理想中的方向,理念還是那個改進的理念。但實際上的運作,價值似乎存在於創造一個新名詞,宣稱它是新方法,然後去做早在哪一次回顧會議就決定並早已實行的事,說這個新東西肯定能帶來團隊的新氣象,又或者把去參加了哪個年會哪個教學這件事本身當成一個價值,而不是內容改進來自己的什麼思想,這個思想又怎麼改善運作。

    敏捷不管跑到哪個層面,難道都是名字的戰爭嗎?

    讓我想起好幾年前,RxJS 把十行程式變五十行程式、像邪教一樣流行的時光。

    那東西沒有不好,什麼都要硬套上去並說套上去本身就是救贖,那就是走火入魔了。