Manjusaka

唉，最近因为气胸大过年的住院，春节颓废了好久，今天开始回北京，干脆来安利一个输入法— Rime 碎碎念如同大多数人一样，我之前也是使用搜狗输入法作为自己的主力输入法，但是搜狗输入法的一些缺陷让我放弃了使用搜狗输入法 作为传统艺能，搜狗输入法隐私保护成迷，在 MacOS 上某几个版本的搜狗在寻求获取我的通讯录和日历读取权限 作为传统艺能，搜狗输入法的广告推送实在是一言难尽，特别是在 Windows 上，已经禁了一些组件，但是还是防不胜防 因为和港澳台和国外社区朋友的交流需要，我需要输入法能够比较好的支持繁体，而搜狗输入法的繁体支持也是一言难尽 搜狗输入法的定制能力也着实不满足我的需求。。 因此我在18年开始在寻求一种开源，可控，可定制，对简/繁输入都比较友好的输入法。经过寻找之后，Rime 输入法进入了我的视线，经过一年多的使用，我觉得这个真的是一款非常棒的输入法 Rime 是什么？Rime （又名 中州韻）是一款开源的跨平台的输入法引擎，完全开源，完全可定制，你甚至可以基于 Rime 的源码，来封装一套自己的输入法引擎。同时因为 Rime...

好久没写文章了，新年还是得写点技术水文来保证下状态，正好最近遇到一个比较有意思的问题，就来简单聊聊一下关于 MySQL 中 Prepared Statements 吧 开始gorm 是大家在使用 Go 开发时的比较常用的 ORM 了，最近在使用 gORM 的时候遇到一个很有意思的问题。首先我大概描述一下这个问题 在使用 gORM 的 Raw 方法进行 SQL 查询时，构造了如下类似的 SQL 1select * from demo where match(name) AGAINST('+?' IN BOOLEAN MODE) 在随后传入参数的时候，返回 Error : sql: expected 0 arguments, got 1。而其余的诸如如下的查询就正常执行 1select * from demo where name = ? 最开始我以为这是 gORM 中拼接 SQL 模块的问题，但是看了下代码后发现一个很有趣的逻辑。gORM 中并没有拼接 Raw SQL 的相关逻辑，它会直接调用 Golang 中的标准库 database/sql 来进行...

从工作开始，一直就想买个 Mac，但是一直没有买成，虽说有公司配发的 Mac（这也让我从 Macbook Pro 2015 13寸到 Macbook Pro 2017 15寸，到 Macbook Pro 2017 15寸，到 Macbook Pro 2018 13寸，到 Macbook Pro 2018 15寸用了个遍，23333），但是没有自己的 Mac始终是一个比较遗憾的事，所以这次新款 Mac 出来后，就瞬时公司员工优惠（官网95折）+12期免息分期入手了，现在我来从一个开发者的角度来给一个简单的评测吧 正文为什么会考虑 Mac写这个文章之前，我需要介绍下我买 Mac 的背景。目前我的主力机是来自蓝天的准系统，P775TM，配置是 i7 8700+32G+512G SSD+1070。工作系统是 Manjaro（一个 Linux 发型版）。在目前开发的时候觉得非常舒服，但是我也遇到了几个问题 太重了，有些时候临时有事需要出门带着并不方便 Linux...

说实话，突然体会到了老祖宗说的『光阴似箭，日月如梭』的感觉了，感觉告白还在昨天，但是转眼就一年了。所以来写篇文章纪念这短短却有很丰富的一年吧 起初说实话，我现在都没搞清楚是她撩的我，还是我撩的她，估计暂时也不会搞清楚了？ 在去年的11月7号凌晨，当时聊着双十一，然后她突然说，“要是双十一能脱单就好了”，然后我直接没过大脑的来了一句...

其实这篇文章最开始动笔是写于9月份，PyCon China 2019 上海场的工作结束后。后续因为还有北京，成都场的工作，所以拖到了现在。正好我自己的三年计划刚刚落下帷幕。下一个三年计划正在开展。我也来聊聊在这三年里面，让我花费精力最多，也是最为重要的部分组成之一吧。 PyCon China，嗯这三年的时间里，我有两年都在与这个熟悉而陌生的名字关联在了一起 我与 PyCon China 的结识说实话，之前 Laike9M 的一句话让我产生了共鸣 Kenneth Reitz 曾经说，他的一年是按 PyCon 计算的。尽管围绕他有很多争议，这句话依然让我有了奇妙的共鸣。对他来说，”PyCon”自然是指 PyCon US，而对我来说，则是 PyCon China 而我18/19年这两年的时间里，有很大一部分时间都在围绕着 PyCon China 要说最早结识 PyCon，应该能追溯到的 2016 年，当时初学 Python 的我，看到 David Beazley 在 PyCon US 2009 上分享的一个名为 A Curious Course on Coroutines...

最近还是无心写啥文章，说好的写几篇关于 Raft 的论文也因为一些事 delay 了。但是想了想还是准备写点什么，于是写个小的水文来记录下关于今天碰到的一个 Linux 内核参数的问题， 顺便做个笔记 开始我是一个不太喜欢 Mac 的人，所以我自己在家使用的开发环境是 Manjaro（这里打个广告，非常棒的发行版，堪称开箱即用，广告五毛一条）。然后代码工具就是 Jetbrains 的全家桶和 VSCode 搭配使用。 今天打开 Goland 的时候，发现 IDE 给了这样一个 Warning ，External file changes sync may be slow: The current inotify(7) watch limit is too low. 于是大家知道，我是个看着这些 warning 有强迫症的人，于是我就去查了查 简单聊聊我们平常经常会有需求，去监控一个文件或者一个目录下的变化，比如创建文件，删除文件等。我们常规的做法可能是一个直接暴力轮询的方式来做 但是这样的性能会极差。那么我们有没有什么手段来处理一下这个事么？ 有的！ Linux 提供了对应的...

最近沉迷与 MIT 6.824 这门分布式系统的课，无心写文章。不过看到 PEP570 被接受了，决定还是写篇水文随便聊聊 PEP 570 Python 的 argument在聊 PEP570 之前，我们先要来看看 Python 的 argument 变迁 早在 Python 1.0 或更早，Python 的 argument 系统就已经支持我们现在主要使用的两种参数形式了，一种是 positional 一种是 keyword，举几个例子 1234567891011def abc(a, b, c): passabc(1, 2, 3)abc(1, 2, c=3)abc(1, b=2, c=3)abc(*(1, 2, 3))abc(**{"a": 1, "b": 2, "c": 3}) 这是不是我们常见的集中使用方式？ 在发展了很长一段时间后，虽然期间有一些提案对 Python 的 argument 系统做优化和增强，但是一直都被 Reject，直到 PEP3102 的出现 3102...

关于惊群问题，其实我是在去年开始去关注的。然后向 CPython 提了一个关于解决 selector 的惊群问题的补丁 BPO-35517。现在大概来聊聊关于惊群问题那点事吧 惊群问题的过去惊群问题是什么？惊群问题又名惊群效应。简单来说就是多个进程或者线程在等待同一个事件，当事件发生时，所有线程和进程都会被内核唤醒。唤醒后通常只有一个进程获得了该事件并进行处理，其他进程发现获取事件失败后又继续进入了等待状态，在一定程度上降低了系统性能。 可能很多人想问，惊群效应为什么会占用系统资源？降低系统性能？ 多进程/线程的唤醒，涉及到的一个问题是上下文切换问题。频繁的上下文切换带来的一个问题是数据将频繁的在寄存器与运行队列中流转。极端情况下，时间更多的消耗在进程/线程的调度上，而不是执行 接下来我们来聊聊我们网络编程中常见的惊群问题。 常见的惊群问题在 Linux 下，我们常见的惊群效应发生于我们使用 accept 以及我们 select 、poll 或 epoll 等系统提供的 API 来处理我们的网络链接。 accept 惊群首先我们用一个流程图来复习下我们传统的 accept...

关于 pyrightPEP 484，出来也快四年了。正好今天看到一个新库，写个短文，安利下&吐槽下。 关于 PEP 484PEP 484，14年正式提出，15年正式接纳，成为 Python 3.5 以后的标准的一部分。简而言之是通过额外的语法，来为 Python 引入静态类型检查的例子 举个简单例子 1234def return_callback(flag: bool, callback: typing.Callable[[int, int], int])-> int: if not flag: return None return callback(1, 2) 我们通过这样的类型静态标注，来增加可读性以及静态检查的能力。具体内容，可以参看我去年在 BPUG 上的分享的 slide。我最近也会抽出时间，详细聊聊 Type Hint 的前世今生（flag+1） 静态检查静态检查的意义在于，能及时发现低级错误，及时检查，可以很方便的集成进 CI 或者 Git Hook 中 举个简单例子 目前而言，主流的静态检查工具有两种 Python...

2018，我，2019，未来本来以为年前没有机会发这篇年终总结以及新年展望。不过目前去向已经确定，所以准备还是写一篇文章纪念下2018这一年，赶在农历戊戌年的末尾发一篇文章出来吧。 2018，我2018...