现在使用 Homebrew ，但是受不了下载一大堆依赖，准备把开发环境相关的都使用 [Dev Containers]( https://containers.dev) 来替换了

感谢
发现 Google Play 上 WKTV for TV 会提示 This app is not available for your device ，无法安装到 Google Chromecast

使用过其他记账软件都是半途而废，但是这种周期性记录资产的方式确实更适合我，更容易坚持，很早起就购买了完整版了。

一个想法，可以丰富信用卡账户的管理，比如记录总额度，展示使用比例，或者是还款日期等。

1. Rebase -i 去 Drop commits ，再 Force Push 。但是其他人拉过更新，有可能再 Push 上去。
2. 在 .gitignore 里面添加文件或目录之类的

差评之前讲过一个类似的 https://mp.weixin.qq.com/s/421JM7swsF2y8hAh7cwK6w

可以导入一套新的键盘 Layout ，效果就像是新加了一个输入法
https://stackoverflow.com/questions/11876485/how-to-disable-generating-special-characters-when-pressing-the-alta-optiona

@Biluesgakki #12 API 上的测试并不都是「单元测试」，也有「集成测试」之类的。一般 API 的单元测试意义并不大，因为 Controller 上都不一样有逻辑，更多的是框架的调用，注解之类的，更好的是使用「集成测试」来保证 API 的请求验证，序列化或反序列化等。
而下层的 Service / Domain / Utils 的「公开」方法，更应该用单元测试，这些方法的输入和输出就都会被轻量的自动化的测试给保护好，以后做内部实现的重构才会更安全。

有单元测试吗？覆盖全吗？如果没有，那很难保证不改挂。
或许得换个思路了，绞杀模式一步步去重写，替换模块……

个人觉得 PostController 更合适一点，因为从属上是「某个文章里面的评论」

一种划分思路，从 Post / Comment 这两个资源的生命周期，依赖关系，聚合关系出发。
比如一个 Comment 一定仅是出现并关联在一个具体的 Post 上，不能完全创建的话，那就是 /posts/:postId/comments

请病假，刚好没用完

为了赶工而冠以敏捷之名的压迫。
连问几个简单问题就知道了，有没有迭代计划，按团队效率安排，有没有单元测试，集成测试等自动化测试，有没有 CI/CD 。

之前刚开始的时候注册过 https://alive.bar/ 的，但是没什么人就没玩了
老马最近也在折腾 Mastodon 玩 https://martinfowler.com/articles/exploring-mastodon.html

@feelinglucky #35 赞同，作业面试过的开发，要是能熟悉写好 Java 8 （ LocalDate / Instant / Lambda 之类的）都算是亮点了

我司社招面试也是提前一天给候选人一个模拟项目的代码，然后面试官会和他一起去完成新需求，主要考察点也是代码能力 /风格之类的。

可能有些区别是更关注过程中的观察，不一定要求能在规定时间内完成（虽然能完成的确实比例也不高

试一下删除 Keychain 里面 Apple watch 的 key 。我之前也遇见过，是这样解决的。

类似这样： https://georgegarside.com/blog/macos/fix-apple-watch-auto-unlock-mac/

对具体技术实现的快速尝试或者调研。比如前两天看见 V 友提到实现对 PDF 打码的需求，那如果团队里面人都没有经验，无法给出工作量复杂度的估计。这时候就需要提前去调研解决方式，各种不同类型的 Libraray ，针对需要实现的需求来对比优劣。

就是手动点 UI 也是需要知道测试策略，和一些测试概念，黑盒白盒测试，测试边界。
其次不可能所有都是 UI 相关的测试，需要会熟练使用 Postman 等等测试工具。
再进一步，上次测试过了的功能不可能每次都手动去回归吧，需要掌握写自动化脚步的能力，API 测试，UI 测试，Snapshot 测试等等。
还有一些非功能性的测试，性能测试等。