從 iThome 看到的消息〈羅技也加入DIY維修行列，將提供官方零件予iFixit〉。我在公司成立後，因為主業一直沒有什麼起色，就一時興起想說乾脆幫網友（主要是在 Twitter 上的）修理鍵盤、滑鼠、軌跡球，幫家裡的貓加減補貼一點主食與零食的費用，順便為減少 e-waste 盡點心力。沒想到修啊修的，竟也修了不少這類設備。
其中羅技的產品我也修了好幾款。有人可能看到這裡又想酸羅技品質，但是我蠻懷疑這是一種市占率高，連帶使得故障品的「數目」也較多，但是或許算一下比例，搞不好良率並不低的現象，跟華碩筆電被譏常要出「子龍任務」類似的道理？
在維修羅技的 MX 系列產品時，我最苦惱的便是其中那些很脆弱的扁平軟排線與聯接器，即使我在維修時非常小心了，還是曾弄斷過，補救起來非常麻煩，且這些元件並不像微動開關這麼好買。
如今羅技願意提供零件，實是好事一樁。
希望其他廠商願意響應跟進，讓 e-waste 問題減緩，也讓我們這些做維修的阿伯阿姨更方便，不然我還曾經想過要來自己搞個 aftermarket 零件事業咧！
故事源於我昨天想做房間裡的相片牆，結果那種四支小釘子的掛勾，根本咬不住我家的水泥牆，剝落的牆面留下了難看的凹洞。
我用補土補平後要上漆，而家裡這罐之前在一間油漆行買的漆，是當初店家用色卡和我帶去的一塊樣本對照著選色，結果根本就過白，與牆上的米白不一致，漆上去形成的色差讓我強迫症發作，一大早起來就忙著補救。
其實我買油漆那時就很好奇，這間店不是宣稱有「電腦調色」嗎？為何還是用這種人工方式選色？
於是我就打算再去買一罐油漆，又先從家裡牆壁很克難地刮取樣本，然後拿去另一間油漆行，希望能夠用到「真正」、「精準」的電腦調色：
我：「請問我這個顏色，電腦有辦法幫我調出來嗎？」
店家：「？？」
我：「這邊不是有電腦調色嗎？有辦法讓電腦掃描顏色後，幫我調出一樣顏色的漆嗎？」
店家：「喔！你誤會了，電腦調色還是要拿著色卡先選你要的顏色，然後輸入進去電腦叫它配出這款顏色。」
我：「喔，我做電腦平面設計時，有校色器幫我先把設備校準，讓我可以有準據取出我要的顏色，我以為電腦調色是這樣。」
店家：「你走遍全台灣的電腦調色油漆行，都是我講的這樣，沒有你想的這麼厲害。」
我：「喔喔喔這樣啊！」（好失望）
我後來找了一下網上的介紹，「電腦調色」還真的就像店家講的那樣：
所以電腦調色的意思是：我廠的漆有這些上千種顏色，但是一般店裡不可能常備這麼多種，所以我大威能電腦會用基礎色加上比例配方，配出符合某色卡的顏色來。
我完全誤解了。
且我又多花了四百元買了同樣色偏很大的油漆回來。
很巧合的是，這罐漆的色彩編號，與我上次買的那罐，是一樣的，也就是說，兩個不同的人，一致認為我家牆壁的顏色，最接近的，就是這種白。
後來還是沒辦法忍受色差的刺眼攻擊，好在水泥漆、乳膠漆是可以透過添加色素來調色的，於是我又跑了一趟這間油漆行，再買了黃、紅色素回來。至於 CMYK 我為何會知道要買 Y 與 M 來調出與我家牆壁相符的米白，這該歸功於從小受到的美術教育，讓我直覺就知道應該要再加一點黃與一點點紅。
調出與牆壁並無二致的米白後，我終於能把這面牆漆成順眼的樣子，還順道把上次為了冷氣管路改道，而把原來開孔填起來時漆的那片過白的區域，一併「修正」回來。
「順眼」的感覺實在舒服。或許別人覺得我太小題大作、吹毛求疵，不過我個性或感官特質就是這樣啊！
也是前幾天做的小東西：https://github.com/hiroshiyui/homebrew_oci_base_images
不消多說，就是因應最近 Docker 公司調整 Hub registry 服務政策。我目前確實是窮到付不起這些開發工具的訂閱費用，只好自立自強，學著自己做 base images。
千萬別誤會，我認為服務有價，Docker 提供的服務對於開發流程的生產力增益，絕對值得有能力、負擔得起的人付費去支撐這個服務；但如果像我這樣無力負擔的人，多走一點曲折蜿蜒的路、多耗一些自己的時間成本，也算合理。
前幾天做的東西：https://github.com/hiroshiyui/ithome_updates_mastodon_bot
目前是跑在 GCP free-tier GCE instance 上，以 @unofficial_ithome@g0v.social 身分運作。為了減輕 g0v.social 站台負擔，以及避免洗版面，所以設定成盡量不要太密集張貼，在臺灣的一般工作時間內每 10 分鐘才會發一篇，因此不會與 iThome 官方近乎同步刊登。
開發上的感想嘛…主要是 Kotlin 雖然寫起來很開心，但是湊齊各種能夠讓這隻程式能動的第三方元件，還是不免有些心智負擔。認識我的人都知道，我寫這類 utility 程式，主要常用的語言是 Ruby，這次嘗試用 Kotlin/JVM，Java 生態系我不太熟，就多花了幾天時間在找資源，但是總體來說，開發體驗是開心的。
今天啟用 WordPress ActivityPub plugin 試試看效果如何。
正在開發的自家產品對於 ActivityPub 協定支援也很重視（另一個重點則是 RSS feeds/Atom），多一個參考實作可以借鏡學習，是件好事。
長期以來，我都在忍耐 MediaWiki 架在 DreamHost shared hosting 上的低效能，因為領教過更誇張的 Drupal，所以耐受度也拉高了，覺得多等個幾秒也還好。
但是最近開始認真將 MediaWiki 當成網路筆記本後，就愈來愈覺得，每次再這樣多等個幾秒，除了浪費時間，剛剛得到的靈感恐怕也就忘了，所以就稍稍研究了一下把效能稍加提升的方法。
在沒有登入 MediaWiki 的情形下，$wgUseFileCache = true;的效益很大，會生出靜態頁面，省掉了「到資料庫撈資料出來，再生成頁面」的昂貴開銷。這個在未登入、單純查看筆記的場景下確實是加速很多。
但是如果在登入的狀態下，由於各人的變數不同（即使這個 Wiki 只有我一個使用者），所以如果要生成靜態頁面，要處理的毛多很多，就有點不實際。不過 MediaWiki 另外有個設定 $wgCacheDirectory 會將比如 L10N 的資源編成快取檔，也省下了不少的 DB 操作。把這個路徑設定弄好，也能在登入的狀態下，換到不少的效能。
除了這兩項設定，$wgMainCacheType = CACHE_ACCEL;也很明顯，如果 CACHE_ACCEL 不適用，CACHE_DB 可以碰碰運氣，看看業者的 MySQL server 效能撐不撐的起來（但是別抱太大希望）。