我很久沒有用了，以前的用途除了可以讓解壓縮的人免去安裝 WinRAR 的需求，主要是 WinRAR SFX 裡有很多 hook 可以用，透過 Resource Hacker 之類的工具還可以換掉圖片和 layout，把 SFX 變成特定目的的執行檔，例如一個安裝程式。
Android 開發者替另外一邊的人寫問題也很多:
- 為什麼我這邊工作比較多？
- Android 開發者寫 kotlin 給 iOS，那最終他還是要會 iOS 的東西。會雙修的人就是兩邊都會寫了，不會找這種工具來用。不想雙修的人會去找 flutter ，而不是 KMP
Mono repo
iOS/Android 兩個專案肥的跟什麼一樣，tool chain 也很混亂，放在一起會很痛苦
原本的 code base 要把業務邏輯切得夠乾淨
這基本上要三修的人 (backend/android/ios...etc) 的人來規劃才有機會做的好，然後沒有這種人。就算有，他也不太可能指揮所有部門聽他的
去年稍微摸了一下 Kotlint Multiplatform，總讓我一直想到 LLVM。
當時的需求是有一段業務邏輯，需要在 SpringBoot Server/Android/iOS 三個平台上面做同樣的處理，但不希望寫三份。如果當時採用 KMP 就能用一份源碼生出三個平台都能用的 library。就當下來說滿符合我們的需求，最後沒採用是因為它的版號仍然是 beta，公司覺得有風險。
就我對其他跨平台方案的粗淺理解(實在不太想花時間去理解這類方案了)，多是希望開發者在一個抽象層上實作，藉以避開各個平台的差異。KMP 則是僅提供 Primitive Class，再去生出各個平台的函式庫。
原文認為會有 ego 問題，要求 iOS/JS developer 去寫 Kotlin 會有難度。我覺得可以有另外一個切入點：「如果公司有 Android/iOS dev，那就讓 Android 的人多寫點 code 給 iOS 的用」，在我的角度來看應該難度沒增加。(至少當時我的 iOS dev 同事還滿期待前述的那塊邏輯他不用管 XD)
我反倒覺得 KMP 的難關在於，許諾的事情太少，但是引入的成本頗高。
譬如說，它要 Android 跟 iOS 放在同一個 Parent directory 底下，這在沒有 Mono repo 的公司就很難做到。若是獨立一個 Repo 專門處理業務邏輯，又要考慮如何把生出的 binary 放進 Android/iOS repo，這是對於開發流程的影響。另外，多一個external dependency，偶爾又要擔心版本問題。
最難的是，原本的 code base 要把業務邏輯切得夠乾淨，才能享受到 KMP 的好處，但是大公司的 code base，尤其是 client side，通常都不容易做到這點。
網路看到的新產品訪問：
1、本次产品的面向对象？
这次的产品主要是面向内容创作者，在保留传统hhkb配列的前提下，针对内容创作者的需求，加入了手势感应条、指点杆和鼠标左右键。
2、为什么不用静电容？
静电容在立项之初是在考虑范围内的。但是因为现在的键盘市场对于换轴有着较高的需求，而目前東プレ的静电容轴并没有提供热插拔功能，因此最终选择了机械轴。
hhkb在采访中表示，支持热插拔的静电容轴其实已经存在，这次考虑到风险没有选择，但是在未来有可能会换静电容轴。
3、机械轴的参数？
本次的机械轴是hhkb向凯华定制的，压力克数为45克，测试按压次数为1亿次。
根据采访者的使用体验，这个轴体的按压手感和声音非常接近静电容轴。
4、hhkb hybrid professional type-s系列之后会取消吗？
不会，hhkb的传统系列今后会始终作为一款拳头产品来推出。对于这一系列的更新计划已经提上日程。
同时，这一系列将会一直采用静电容轴，hhkb会坚持自己的传统。
5、hhkb studio的开发是理光主导的吗？
不是，hhkb studio的开发立项已经4年以上，是从富士通就开始了。
整体立项由美国hhkb主导，机体设计由美国Huge Design公司负责。
同时在hhkb studio的开发设计中，hhkb和和田英一教授一直保持着沟通，
确保hhkb的本质不变。