箱猫日和

最近最终把日本驾照考出来了，花了整整五个月。考出来的时候决定一定要写点什么，一方面是记录，另一方面也可以作为其他人的参考。 先说一下，我在国内有驾照，MT，手动挡。在日本重新考一个驾照是考虑到自己距离上一次开车时间很久，自己在国内学完之后也只开过半年，还只能算初学者。而且日本的交通规则和国内的很不一样，日本是少数三个靠左行驶的国家之一。 一部分人可能会选择外国驾照转日本驾照，那你可能需要到驾照考试中心（運転免許試験センター）去考一次。我自己没有经历过，从考试内容来看类似日本“仮免試験”。只知道靠左行驶是不够的，标牌的意思，十字路口的优先顺序都很重要，所以考试前你至少需要几个课时的实际训练以及相关的交通知识。 有些人可能会有国际驾照，日本的法律规定国际驾照只能用一年，之后你要么不开车，要么想办法弄个本地驾照。 我花了五个月学开车，主要是因为上班没时间。大大小小总共六次考试全部顺利通过也花了那么多时间。我以前在国内学的驾照有四次考试 科目一（笔试） 科目二（车上，考场内） 科目三（车上，考场外） 科目四（笔试） 我在日本这边的驾校一路下来有六次考试 仮免前効果測定（学科） 修了検定（実技、仮免試験） 仮免学科試験 卒検前効果測定（学科） 卒業検定（実技） 学科試験（試験センター）

从去年年初开始重拾英语差不多有一年半多了。最近一两个月开始上在线英语对话，训练自己的口语。现在处于可以开口讲，但是词汇和表达不够的状态。我想分享从几个月前没开口讲到现在能开始讲的期间内自己感受到的东西。 在线英语对话 是一个很好的trigger。在线英语对话比自己对着镜子讲，找非native的朋友讲都要好。原因是你必须讲英语，你在一个受控的环境中。你听得到对方的问题，想要回答对方，用英语回答，这一连串的过程是你以前没有的经验。换句话说，在线英语对话可以帮助你训练思维回路，达到相对自然回答的状态。 回答的范例以及and/so 不是说有了在线英语对话，你就肯定能流利地开始讲英语了。我大概在一个月左右的时候感觉自己可以比以前自由地回答了。一个特点是流畅度比以前有所提升，另外一个特点是不过度使用and/so之类的连词。严格来说，我不认为这是在线英语对话的效果。在这一个月内，我买了一本《SPEAKING FOR IELTS》的书，并且开始上第一课。IELTS Speaking考试的Part 1其实和在线英语对话很像，就是闲聊。重点是书中提供了范例答案。 自己一个人学习时最大的问题是，你没有参照，你不知道对错。我发现范例答案中有and/so之类的连词，但是用法不太一样。不过度使用是一方面，不怎么用可能更贴切一点。口语不是写作，不需要特别明确的连词来指出关系。范例中递进也好，并列也好，其实不需要连词也可以理解。而且你可能会发现范例的主语，包括形式主语会有变化，这可能是英语表达的习惯，也是你必须找实际范例才能看出来和理解的东西。电影，书籍包括新闻都不会很明显地体现这些特点，但是各种口语考试的答案是很好的参考。

最近因为某些原因看了很多买房的资料，但是最终放弃买房决定租房。整个过程中了解了很多买房和租房的知识，现在分享出来希望对各位有用。 首先，我希望站立在一个你和你的另一半能够自由选择的角度看待这个标题。因为丈母娘等原因必须买房的情况不在讨论范围内，这种属于社会属性大于实际居住。另外，一个人居住的话选择面比较广，这里的讨论不一定适合你。 买房和租房哪个更好，如果你尝试搜索的话，会找到很多比较的文章。比较买房和租房各自的好处和坏处。但是同时也有各种外部因素影响你。比如说，不知道是不是国人受丈母娘要求买房买车的影响比较大，到了国外也有优先买房的倾向。还有一些租房的钱不如去买房的说法。整体来说，想要理性分析还是有点困难的。但是如果你把租房当作后备选择，把买房作为主要判断对象的话，决定起来会相对容易一些。 是否需要买房，可以从多个角度来看，比如说 买房有什么好处 因为什么买房 你的计划是什么

2021年已经过去1/4，在这3个月时间内做了好几件事情，其中一件就是买了保险。 保险对于我们这一代人来说可能没有什么好的印象，不要花钱在保险上，甚至保险等于骗钱。不过，对于大部人一般人来说，保险是少数可以保障我们未来的手段。 死亡保险和医疗保险是两个比较重要的保险。 一般来说，到子女独立之前死亡的话，对于家庭的影响比较大，为了避免意外加一个死亡保险比较好。另外，如果你有住房贷款的话，在日本一般会加入“団体信用生命保険”，死亡之后贷款消失，所以住房贷款可以和死亡保险分开考虑。 日本的死亡保险主要有两种，终身和定期。定期的死亡保险到一定时间会自动停止保障。你可能会认为，到时候你没有挂的话，你付的钱全都归保险公司。事实确实如此，不过你要从保险的本质上来看，保险不是赚钱，保险是出意外时的保障。终身一般会比定期贵很多，但是解约时会返钱给你（定期一般不会）。定期里面还分收入保障型和一般意义上的定期。前者是每个月付款，后者是一次性付款。一般每个月付款的类型相对便宜，后者会贵一些。上面只是一般意义上的分类，具体到产品的时候会有不同，比如说有终身和定期混合的产品等等。

在写完自己的Raft算法实现xraft之后，对自己欠缺并发和网络程序方面的知识非常有痛感。之后自己找了很多并发程序方面的资料，比如《多核编程艺术》，相对系统性地学习了并发数据结构的知识。其中比较中意STM（Software Transaction Memory）技术，因为实际的程序中对于共享数据的访问模式不会像典型并发数据结构那么简单，这时候，拆分数据，并且用STM来访问的话可以间接解决并发访问的问题。 到此为止，我一直认为自己是并发程序方面有所欠缺。转变发生在今年年初，自己看到别人写的一篇实现Bittorrent Client的文章，自己也想实现一下。个人在很早以前，就对实现Bittorrent Client很感兴趣，但是当时自己能力只够解析Torrent文件。 在实现Bittorrent Client时，自己有意识地把能够并行执行的代码并行化，并且尝试使用Kotlin的coroutine来写。使用Kotlin的coroutine而不是现在貌似很火的Golang的goroutine来写主要还是因为自己不喜欢Golang的运行模式。Golang的runtime决定了goroutine怎么执行，用户无法直接介入。个人认为应用程序需要一种flexible的机制，能够根据工作负载决定使用基于线程的还是基于work-stealing的coroutine的运行模型。Golang帮你做了决定，在错误处理上也帮你做了决定，有强烈的设计者（C语言）的风格。 回到主题，相比之下，Kotlin的coroutine提供了自定义运行模式的方法，我可以强制要求某些coroutine只在某个线程中之行，利用thread confinement避开锁或者其他同步机制。而且Kotlin的coroutine提供了结构化的coroutine，能够简化复杂的异步编程场景。比如说，我先异步访问服务A，结束之后在并行访问多个服务B，全部完成后再访问服务C，Kotlin里面不需要额外的同步类，只需要使用coroutineScope，launch，async/await就可以实现。整体来说，Kotlin的coroutine非常适合复杂的业务场景，用一个类似DSL的方式类型安全地编写异步/并行编程的代码。 不过我在用Kotlin的coroutine编码的时候，发现一个问题，准确来说这和coroutine没有关系，是你的网络程序该用什么架构？习惯了Web后端的线程模型，NodeJS的单线程模型，UI程序的单事件模型之后，对于网络程序，感觉没有一个确定或者通用的模型。coroutine是一个模型么？个人认为coroutine不是一个模型，coroutine准确来说是一种实现，运行模式的一种实现。你可以用基于线程的运行模式，也可以使用coroutine+work stealing的运行模式，这只是两种不同的实现。对于网络程序来说，你的工作负载决定了你适合哪种运行模式。 一般人可能会按照IO多，还是CPU多来分。很明显CPU工作多的程序不希望频繁切换CPU，而IO非常多的则可以在IO等待时运行其他任务避免浪费CPU。现实中的程序，往往是两者兼具的。在定性你的程序之前，另外一个注意的是，运行模式会影响到你的并行程序的写法。程序调度、共享数据访问、线程管理其实是互相关联的，不只是网络程序，非单线程程序都需要考虑这个问题。 之前也提到通过thread confinement可以避免使用锁，这其实就是一个通过程序调度解决共享数据访问的例子。假如一个语言把程序调度和线程管理都帮你做掉了，那么你必须自己解决剩下的共享数据访问问题。Golang提供了锁和间接解决问题的工具channel，Erlang禁止共享数据访问并且提供了Actor方案。 语言提供的解决方案，往往存在可以优化的空间。比如说我有一个只有单个线程会更新的数据，由于其他线程只会读，所以不需要锁，也不需要发送消息。从另一个角度来说，基于通信的方案可以解决更复杂的问题，但是简单的场景可以使用更简单和高效的方案。另外，基于通信的方案对于一次要求多个数据更新的场景支持并不好，有些人会退回到粗粒度锁，但更好的方案是STM等。 总体来说，网络程序也好，一般的多线程程序也好，需要一个灵活的、能够最大化性能，以及解决共享数据访问的整体方案。个人在尝试了多种方案之后，觉得类似Actor，或者说从SEDA（staged event driven architecture）出发的方案比较合适。SEDA把工作负载按照步骤切分，提供了并行执行的方向，间接地解决了共享数据的问题。你可以把SEDA中的Stage等同于Actor，只不过Erlang用coroutine来运行Actor。这里面的重点不是coroutine，而是Actor在收到消息之后，顺序执行的这点。所以Actor是类似Process的东西，而在Process中执行的指令满足process confinement，理论上不会出现多线程访问下的数据竞争问题。其次Actor额外还有父子结构，自我替换，异常时的处理策略等等。其中父子结构模仿了进程的父子进程，可以用于动态子任务生成，与父Actor在不同逻辑线程上执行，提高并行度。 从解决方案的完整度上来看，Actor确实可以作为一个参考架构。为了进一步提高性能，你可以放宽Actor要求，允许Actor收到消息后乱序执行（或者说没有Queue）。还有就是Erlang是一门函数式语言，只有不可变的变量，假如你用其他语言，可以使用语言本身的内存模型来小心地共享部分变量，减少Actor之间的消息。 个人其实也是这么做的，在几次重写之后，用Kotlin写了一个简单的Actor运行时，使用Actor架构的变体来同时解决并发数据访问和运行模式的选择。整体上来说，不用考虑背后是用线程还是coroutine，并发数据访问也很容易，应用层面不需要锁。到现在为止，应该算是我个人认为比较理想的网络程序架构了。