Garbage In Garbage Out

昨天晚上，想說我的 MacMiniM4 好久沒關機了，關個機讓它好好睡個飽覺，養精蓄銳隔日再戰。 今天早上上班後一開機，嚇得我差點挫賽！！ 我所有工作要用的 app 全部消失無法使用！！ 底下全部變成 ? 圖示，沒有一個可以打開！

最近很喜歡在網路上看別人分享他們 #WFH 的辦公配置，剛好看到一個老外躺著幹的影片，不由得羨慕起來，不用頭部前傾、聳肩、頸部酸痛，可以全身自然放鬆。 我判斷卡點主要是因為遷就桌面上的 #有線實體機械鍵盤 ，所以決定全面換成蘋果的藍牙 #無線巧控鍵盤 和 #無線觸控板 。

        最近某單位一個委託，希望我在寒暑假的國高中營隊，擔任志工講師教授學生怎麼開始使用 AI。         想來想去，教什麼生產力應用這些學生應該完全沒興趣吧？什麼文案、投影片、講稿、翻譯、文章潤飾...         感覺就以 AI 做小遊戲為主題，看能不能帶起這些學生的興趣？

        我擁有的 Apple 產品中，最喜愛、最離不開身的，不是 iPhone，而是 AppleWatch。         我不是一個喜歡滑社群、隨時追影音或打手遊的人，除非預期有拍照的需求，或是知道現場要排隊等很久，需要打發無聊時間，不然大多出門我都不太會帶手機， 太重了 ，但手錶我是幾乎不離身，LTE esim 的5G AppleWatch 版本完全能滿足我所有需求。         而且隨時掌握身體狀況數值，像是有個貼身護士的安心感，天氣、股市、行事曆、待辦清單，不擾人的手腕震動提醒，也不讓我漏接任何電話、訊息，有貼身助理的感覺。         手機放外套、褲襠裡，震動經常沒發現到，但我又是非常討厭鈴響的人，所以手錶的震動真的超適合我。         原本服役中的 S8 沒打算今年換的，因為還很好用，電池健康度續航也還在可用範圍。想說再撐到 S13 再換新款造型再升級…         沒想到上週開始，續航莫名急速下滑，幾乎是每分鐘就掉1%電， 充滿100%也撐不到兩小時 ！         重置兩次急救無法，已經到了不可用的地步！睡前定個鬧鐘，睡一半就耗盡電力，早上根本叫不起我！無奈只好提前購入他的接班人 S11 LTE 版 。

如果是跟我一樣超愛這次新款 Mac mini M4 並入手的朋友，一定會好好研究相關的擴容和接口的擴充方案。 畢竟這次為了縮小體積，把 USB-A 口砍光，並且那跟金價一樣貴的硬碟存儲空間...

          我們有兩棟十年前的磚瓦混泥土老舊技術建造的老公寓，這些年來一直疊床架屋地想辦法滿足租客們的需要。           最近老房客一直流失，所以業主們想要招租一批新世代的房客們。面對這全新的客群，如果能成功開拓這塊過往沒有深入的市場，或許能帶來不錯租金的成長。           但是，目前的老公寓卻無法滿足這批新世代房客的需要，就是我們老舊公寓的插座，都是雙孔的插座，但是新世代客戶他們要用的電器，都是三插頭，他們入住會無法使用他們原本的家電。

         Apple 史上CP值最高的Mac mini M4 推出已經讓我心動了幾個月，但我把目標定在記憶體加滿的 32GB 和硬碟升級到 512GB 的進階款，希望這次可以用個至少5年，不再擔心換機。 但升級後的價格有點貴到猶豫不決，於是決定只要我可以靠股票投機賺到這筆開銷費用，就立刻買到手！

        早上起床看完這段非常有棒的AI 討論的深度對談。尤其對以下幾段印象極為深刻：

            說實在的，2024 年對我來說並不是一個安穩的一年，經歷車禍斷手、肝炎硬化昏厥而開刀做了器官移植，能活到現在也算是不幸中的大幸。           鑑於衰事太多，老婆開始吃齋念佛，希望能保佑我自此平安，並且突然許願我能為她開發一款每日提醒她誦經的手機 app。           由於我們全家用的都是 Apple 全家桶，自然就選擇 iOS 上開發這款老婆需要的 app。           這時候要提到我先前說的「 等等黨的勝利 」，蘋果用 Swift 語言取代了過去的 Objective-C，UI 也用 SwiftUI 逐步取代 Storyboard 機制，這些被迫打掉重練的過程，我通通跳過，更何況現在還有 AI 可以直接幫我寫 code，連我這個不熟悉 Swift 語言的生手，也能快速就開發出老婆需要的 app，而且連 Xcode 這款我完全不會使用的 IDE，也透過 AI 的指導學會一些需要的操作。 果然『等等黨』就是這麼爽啊，完全不走冤望路！

你的系統只會發展成適應組織的模樣     這陣子和主管聊天，討論到公司產品為何會走到現在的模樣。     我們有兩套功能相似的產品線，只是目標客群有所差異。其中一套是從原本的產品複製出來後獨立發展的，為此，公司必須開始養兩倍的人力、兩個團隊各自維護與開發。常常發生同一個 bug 或是功能，兩邊要各做一次，而且做法還彼此不同。同一個需求，兩個團隊挑選的解決方案不一樣，導致公司內部出現許多相似卻不相同的程式庫。     回想自己剛來的時候，公司跟我聊到這個議題，說希望能合併回一個產品線，我當真了。     現在我明白，那只是聊天和單純抱怨 murmur 而已，並不是認真的。

      前陣子，一位從工程師升任主管的朋友，看起來每天像是無頭蒼蠅那樣忙碌，進出各種會議。他問我： 「你當主管時是怎麼追技術的？我覺得時間根本不夠用。你覺得管理好還是專心技術好」       我當時的回答是：你應該是要問自己真正想要的是什麼。       面對財富不均的世界，只有時間是對每個人都公平的資源，富人窮人都是一天 24 小時，『取捨』才是關鍵。       知道自己真正想要的是什麼，才會知道怎麼去做『取捨』，什麼「 身為成熟的大人我兩個都要 」的世界是不存在的。       當時這樣回答完，事後仔細想了想，其實我從來沒有花時間『追』新技術過...。

        今天看到網路上一篇討論 SQL Timeout 原因的探討文章。         由於那篇文章的結論和我過去經驗完全不同，所以我懷疑是不是我過去仰賴的長期判斷經驗有誤，特別寫了個 TestCase 作為比較。         首先我先引用該文章作為調查起點的 Exception 內容：         

          即將發生的網路電商的大事件，莫過於越來越接近的大陸雙十一。屢創高峰的雙十一購物節，究竟阿里巴巴是怎麼在技術上克服這種巨量湧入的交易量呢？         前陣子到中國東北剛好因為業務合作需要而結識了一位在杭州擔任阿里巴巴架構師的高手。晚餐大家在酒醉耳酣之際，我們聊起這件事，做經驗交流。 

        很多人總是拿 Java vs .NET，但這太容易引戰了，所以這邊我不要用兩相比較的方式，單純 從『非技術』的『商業觀點』 談論我對 Java 的看法。         我本身以微軟相關技術為主，但偶而也會寫寫 Java，因為程式語言就是工具，合適的時候就拿來用一用，更何況從 C# 轉 Java 遠比 Java 轉 C# 簡單得多，因為 C# 的語言特性較複雜。         我自己會寫 Java 的幾個機會是：寫 Android App、寫 GAE app、寫公司產品 Java 版本的 SDK，不算是用在很核心的地方。 聲明：以下看法單純從本人過去工作經驗的觀點做分享，難免偏頗絕非全貌，請自行斟酌真實性。

        身為多年 log4net 忠實用戶，最近接獲客戶報案，說 Rolling File Appender 會在跨日一過午夜就將 log 檔案內容清除，只留下 0 byte 的空殼。對方採用 我曾在 blog 推薦的多年調製而成的家傳祕方的組態設定 （ log4net.config ），竟然會遇到如此前所未聞的離奇事件！？         上網 google 搜尋是否有他人遇到類似狀況，卻毫無線索。太陽底下無鮮事，全天下沒有別人遇到的事情，通常也不該發生在我周遭，畢竟我樂透從沒中過（ 不過我也都不買，這樣要中獎對老天爺來說應該是有難度 ），但是客戶現場截圖又不得不讓我閉嘴，不敢過度質疑：

        『 十二小時百人 PITCH X STARTUP馬拉松 』，是個鼓勵創業人腳踏實地驗證自己想法的創新活動。因緣際會，某日晚上受帶衰胖胖之邀，跟其中一個參賽團隊『 鋼鐵人實作聯盟 』的成員聚會交流，順便交換彼此對這個 Business Model 的想法與回饋。         而透過該團隊主要的 Coordinator - Sandy 的介紹，我才知道有這麼一個活動，而該週六就恰巧是馬拉松活動最後的決賽場！         決賽場的地點是在台灣微軟，那地點我很熟，依照慣例，知道現場一定會有免費的糕點和無限暢飲的冷飲機，應該可以省去一頓午餐費用（ 創業維艱、什麼都要省啊 ），於是打定主意前往！

        今年三月底，為了挽救公司的新產品，我臨危受命飛往馬來西雅。也是第一次我才一下飛機，透過越洋國際電話，就決定放生一位團隊同事。         下令放生之前，我寫了封信，跟團隊談談我心中認為『成功的系統』的關鍵要素：

        這一年多來，帶著團隊參與一間新創公司的產品開發，近一年的努力成果終於推向市場營運後，才幾個月不到，結束了。         如今還在收拾一些殘局的過程，看著這潮起潮落，我有些領悟。         當然結束營運背後有諸多複雜的原因混雜，有些也不是我這種技術層級的黑手工頭可以知道的。但是針對 IT 開發這塊，我有個代價挺高的領悟：         產品的系統特性，應交給市場幫你決定，而不是交給 系統架構師 來決定。

        繼 上次才寫到開頭的歷險記 ，第一週我先跟團隊達成『工作完成』定義的共識，避免錯誤的資訊混淆對實際狀況的掌握與判斷。         但是，即使掌握正確的專案進度，避免浮報無知的樂觀，卻 沒辦法讓實際的開發速度加快 。採用了每週一輪的 spring，前兩週都無法達成目標，以當時的 deadline 來看，團隊的開發效率若沒有改善， 肯定無法對上有所交代。