ybark

DELL 客服答复是不会在 MacOS 上做驱动的，之前回了一篇显示器音频输出无法控制音量的，希望能提供 mac 的驱动来解决，客服答复很牛: The online sales page and User's Guide were very clear about what Dell will support. There are no plans to support Apple product with the U2718Q. Any Apple drivers for the Apple OS must be written by Apple.

https://www.dell.com/community/Monitors/U2718Q-MacBook-Pro-no-volume-control-on-audio-output/m-p/6132431#M116728

目前我在老款 mbp 上是通过 DP 输出 4k 60HZ 没问题，HDMI 只能 30HZ 鼠标很迟钝的，这个应该是苹果的问题。

其实很希望官方能给 macos 做驱动能够调节音量，开启 HDR。

关于 8bit 伪 HDR 在 mac 下开启这里的矛盾是：mac 只能通过 DP 口上到 4k 60HZ，HDMI 不行；但是如果用 DP 口，显示器本身又只能是 DP1.2，传输不了 HDR 数据。所以 mac 目前开 HDR 是无解的。

半价升级，钱都准备好了他不给 wxpay 和支付宝，那就算了呗，继续用 3

觉得时间太特么多的也可以看看“ RESTful APIs, the big lie ”原文的撕 b： https://mmikowski.github.io/the_lie/

上面一大堆撕 b 回复，看了以后很客观的觉得是浪费时间。我想，作为一个正常的靠谱开发者，对 restful 不可能不产生一种排斥和别扭的感受。个人觉得以资源为中心组织 url 很受用，但是非要让业务逻辑去依赖 http 协议中的语义我 tmd 就是不爽（包括 http method 以及 status code ）。
这里有一篇文章为我这种不爽提供了很靠谱的解释和出口： https://eggggger.xyz/2017/01/04/restful-api/ 。

无意争辩和钻牛角尖，我认为开发者的心态大概应该这样：
透彻的理解你的问题，然后用你熟悉的技术和方法解决问题赚钱；
如果在解决问题时发现你正在用的技术和方法不熟，那就继续搞明白，如果觉得不爽，就用你认为正确的技术和方法继续解决问题并赚钱。
在解决问题并赚钱的这个大目标上，用还是不用 restful 基本上没什么太大的决定性影响。

手机本地找到小程序代码包 wxapkg，通过 github 上有人写的反编译还原脚本（项目距发这条评论前 11 天还在更新）。理论上看，若真要有团队有时间去搞你的小程序，如果你没做特别的处理，小程序就是开源的。那么此时后端 api 带不带 token，就没区别了，整套代码跑起来，token 也能拿到，后面需要 token 的 api 也不用伪造请求。

发个尾巴，纯好奇试试先： http://ipm.ipfstalk.net/?code=NzUwOTQ=

appstore 上买的 markdown plus，主要就遭遇了 2 个问题，github 提了 issue，作者修改很快

确实很恶心，即使是 spring boot，尽力减少 xml 配置（转而写 property 或 yaml 配置），并倡导约定优先于配置。可是还有一大堆注解，靠最头疼的就是这种东西，脱离程序思路的语法糖，吃多了也不怕糖尿病。
相比之下，python 清爽很多，最多就是有个修饰器，至少是可以在 1 天内搞懂原理的。

买了个 tg pro，好些了。最好还是空调房。