程序员如何挑选钻戒

Posted on by 18 Comments

好久没有写博客了，哈哈。最近事情太多，最幸福的就是求婚成功。继我的肥仔同事购买钻戒求婚成功之后，没想到我也要踏上寻找钻石之路了。看了他的那篇文章，给了我一些钻石的基本知识，最终我买了 BlueNile 的裸钻，可以分享一下购买历程，给有需要的朋友。

品牌和裸钻

钻戒基本上分成两种， 一种是品牌的成品钻戒，比如 Tiffany, Cartier, 六福珠宝等。也有裸钻，裸钻的意思是你直接从珠宝商那里购买一个钻石，然后再去购买一个戒托，最后找一个提供加工服务的地方，把它们加工成钻戒。

钻石的议价空间比较大。买裸钻的价格最低，像国内的六福珠宝等，钻戒的价格一般是裸钻最后成品的价格的 1.5倍 – 2倍。奢侈品牌一般是裸钻的 2倍 – 4倍。

bluenile 的钻石挑选页面，品质更好，价钱就更高

那么要不要购买裸钻，就成了一个问题。裸钻的优势是：

  1. 价格便宜，一分钱一分货，基本上没有溢价，价格非常透明；
  2. 你可以亲自挑选一颗特定的钻石，每一颗钻石都是不一样的，钻石商也是通过这一点营销出来钻石的意义；
  3. 可以自己挑选戒托；
  4. 钻石库非常大，15万颗钻石；

裸钻的劣势是：

  1. 等待时间较长。裸钻之所以便宜，就是因为钻石并不是在钻石商手中的现货，网站上供你选择的钻石其实是不同钻石商共享的钻石库。你要先预定上，他们回去帮你购买，最后送到你的手上。像我购买的 Bluenile 就花了 4 个周才到我的手上。国内的钻石小鸟，要求立即拿货的话，要比全球调货的钻石，价格贵 1.5-2倍。并且即使你挑选好了钻石，最后也有 30% 的几率买不到；
  2. 加工成本。就是你要自己选择戒托并且加工。但是现在基本上裸钻厂商都会提供戒托 + 加工的服务了。除了收藏钻石，很少有人直接买钻石了，基本上都是加个戒托，最后拿到手成品。另外要注意的是裸钻提供的戒托以及加工，做工上可能没有奢侈品牌好，比如同样款式的 Tiffany 六爪经典款戒托，Bluenile 的可能爪之类的地方会更显粗大一些；
  3. 无法试戴。Bluenile 提供了一些方法可以测量手寸，并且提供免费修改手寸的服务。所以如果不着急拿货的话，可以接受。

服务方面

无论是裸钻还是品牌厂商，都提供一些服务。但是这些服务有些许猫腻，需要注意：

  • Bluenile：1年内免费调整手寸，1个月内免费退货。用户只需要承担退货运费。购买新的钻戒的话，上次购买的钻戒可以抵100%的现金。但是要注意，这也意味着你购买的钻石可能是别的用户退回的。虽然对于钻石这么坚硬的珠宝来说几乎没有影响；
  • Tiffany：不能退货，免费调整手寸；
  • 其他：可以自己咨询店员；

如何挑选钻石？

来到了最重要的环节了。无论是品牌钻戒还是裸钻，挑选哪一颗钻石，都是买方要面临的问题。

首先介绍一下基本的知识。钻石的品质是由四个指标决定的。一颗钻石的四个指标分别得分如何，一般会有一个 GIA 证书来说明。GIA 是权威的钻石鉴定结构，钻石商为了让钻石的品质得到认可，会付给 GIA 钱，然后把钻石送往 GIA 鉴定所，GIA 将厂商标签删去，平等地评价钻石的品质，最后给钻石出示一个证书。

（小知识：有了 GIA 证书，买到的钻石就一定好吗？也不是。有一种骗局是珠宝商将一颗品质极好的钻石送到 GIA 鉴定，拿到一个证书。GIA 会将证书标号用镭射引到钻石腰上，以做到一颗钻石对应一个证书。但是只要花 500 块钱，就可以将这个编号给抹去。然后珠宝商再次将这颗优秀的钻石送到 GIA，拿到一张新的证书。老的证书就可以搭配品质不好的钻石来买，赚黑心钱。奸商）

在我心中这四个标准按照重要性排序如下：

  1. 切工：对钻石是否闪亮起决定性作用，即使天然品质再好，如果切工不好，折射光的效果大大折扣。所以我挑选钻石只看 3 Excellect 等级切工的钻石。另外，某些钻石商会在 3 Excellent 中再加一个更好的等级，将钻石卖的更贵。就像是得到 80 分以上，GIA 就认为是 Excellent 了。然后 Bluenile 从中挑选出切工 95 分以上的钻石，将它们作为 Astor 品质的钻石；
  2. 大小：就是克拉数。可能是我们平时听到的 “几克拉的钻石” 比较多，但是这个参数的重要性不如切工。并且并非越大就越好，要结合媳妇的手来看，看起来好看才最重要；
  3. 颜色：颜色用字母 D – K 表示，D 最透明，K 有些发黄。我选择的是 E 色，仅次于 D，即使在没有强光下，钻石也看起来很漂亮；
  4. 净度：最不重要的一个指标。因为内含物都比较小，肉眼基本上都看不到。我选择的 VS2；

除此之外，还有钻石的荧光，奶钻、咖钻、绿钻等。可以自己了解下，看是否能将接受。我选择的是完全无荧光的。

另外不要迷信参数，D和E，E和F，VS2还是VVS2，普通人基本上是看不出来的。并且加上上文提到的奸商行为，也不应该过分迷信参数。犹豫不决的时候，可以在店里让柜员掩盖标签，你觉得哪个好看就买哪个。：）

如何测量手寸

如果是和女朋友一起去珠宝店挑选钻石的话，就没有这个问题了，可以现场试戴。如果是选择裸钻网购，可以使用：

  1. 测量卡片，比如 BlueNile 提供的，免费申请即可；
  2. 使用绳子测量；
  3. 或者其他可以在淘宝购买的测量工具；
  4. 去店里找类似的款式试戴；
  5. 为了保险起见，还是推荐购买有调整手寸服务的珠宝商；

最后如果男士想要制造惊喜的话，再提供几个方案：

  1. 带她假装不经意间去珠宝店，然后免费记下合适的手寸；
  2. 在她睡觉的时候偷偷测量；
  3. 将她敲晕，然后测量（同事提供的方法，作者不付责任）；

小贴士：

  1. 手再一天当中不是固定的手寸，比如傍晚会膨胀，早上会变细一些。拿到戒指不要一下子觉得不合适，最好试戴几天；
  2. Tiffany 的手寸基本都是 HK13，即美国的 6 号手寸，柜员的解释是，基本上每个女生的食指、无名指、中指，总有一个手指可以戴上 6 号；

说在最后的话…

说了这么多，其实开心最重要。选择一颗钻戒只是两个人即将一起度过下半生的众多选择中的一个，无论是裸钻还是品牌钻石，无论是选择什么品质，两个人默契，观念一致或者最终达成一致，才最重要。

最后我选择的钻戒信息如下，供网友参考：

实际到手的成品如下：

祝读者幸福！

 

玩了一下 Github 个人首页的 Profile （使用 Action 自动更新）

Posted on by 15 Comments

Github 最近推出了一个 Profile 功能，大体上就是用户层面的 Readme。如果你新建一个和你的用户名一样名字的仓库，这个仓库的 Readme 就会展示在你的个人主页上。

虽然仅仅是一 Markdown 形式的 Readme，但是可玩性也很多了。

比如有一个服务，将这个服务 URL 的参数改成用户名，就可以用一个图片显示个人的开源贡献信息等，原理和项目上的 badge 差不多。

还有展示自己的睡眠数据的：

还有展示年度进度的：

还有在主页交换链接的，并且把这些链接做成了很漂亮的卡片：

 

我一直很喜欢看维基百科的 Picture of the Day，甚至有一段时间写周报的时候，每周都会贴一张 Picture of the Day 的图片在周报的末尾。一个原因是这些图片都非常精美，是由一个小组挑选出来的，普通用户也可以贡献，你可以发现这个世界上还有这么漂亮的地方。另一个原因是阅读维基百科可以学到知识。

 

2020-01-02 的 POTD

所以我就做了一个每天更新 Picture of the Day 的 Github Profile。基本的原理就是使用 Github 的 Action 功能，每天跑一个脚本，去维基百科查到今天的 Picture 地址，然后更新 Readme 中 Picture  的 URL，这个 Readme 就会展示在我的首页上。

实现非常简单，所有的东西都在这个仓库里面。如果你想制作定时更新的 Profile, 可以参考一下这些脚本：https://github.com/laixintao/laixintao

有几个可以少走的弯路，分享一下：

  1. 让 Action 的机器人 push commit 是一个比较 tricky 的事情，好在可以直接用别人写好的 Action，这就是 Github Action 的设计精妙之处吧。像 checkout, setup-python 这种东西，都有现成的 Action 了，不同的用户之间可以组合 Action 实现自己的 CI。git push 使用的 Action 是这个：https://github.com/ad-m/github-push-action 使用方法可以参考这里，可以说非常简单，甚至 Github 的 Action 运行的时候默认就会设置环境变量 secrets.GITHUB_TOKEN，连你手动给机器人设置 Write 权限的 Token 都省去了。
  2. 使用 Action 更新 commit 是一种方法，应该也是简单的方法。一开始我是想用 clock.sh ，不需要 clone 下来仓库，直接使用 Github 的 API 去创建 block，然后创建 tree 和 commit，但是这样操作太复杂了，就放弃了。有想法的用户可以研究一下 Github 的这套 API。
  3. 放弃了 clock.sh 的代价就是…… Github Action 的 schedule 功能感觉有 bug. 如果 workflow.yml 写的有问题，Github 不会告诉你哪里有问题，直接就不会运行，对于调试来说还是挺不方便的；使用 schedule 会有一些坑。比如一你开始写了一个 crontab 15 * * * * ，调来调去最后发现无论如何改都生效不了了。而且 Github 这边就是不运行，没有调试方法。比较直接的方法就是直接将 workflow 换一个名字，push 过去，这样相当于在 Github 那边新建了一个 workflow，重新 schedule. 所以遇到此类问题不要怀疑是不是你的 crontab 写错了，直接换一个 filename 吧。
  4. schedule 功能最短的运行时间是 5min 1次，所以写 * * * * * 是没有意义的；

最后，我发现维基百科有时候会更新出来很恶心的图片，比如今天的…… （恶心，慎点 https://en.wikipedia.org/wiki/Template:POTD/2020-10-08 ）

 

对中台的一些想法

Posted on by 1 Comment

声明：本文仅代表个人想法，不代表我的雇主的想法，也不代表我的同事的想法。

一开始有人开始提出“中台”这个概念的时候，我对此是嗤之以鼻的，认为又一个的炒作的概念。对于中台，我的认识是，将一个垂直领域的东西做成一个 SaaS 平台，它的价值就是避免一定程度的重复建设。举个例子，比如一家公司的很多个 BU 都有播放客户的广告的业务，那么追踪广告的效果就是每一个 BU 做的事情。这个事情需要做 N 遍，但是如果将广告效果追踪变成一个 SaaS 服务，就不需要大家都去做一遍了，只要接入并使用这个服务就可以。这是我理解的中台，可能和其他人的理解有出入。即使在最初提出“中台”的那帮人里面，估计也有很多不同的理解吧。

总之，后来我的 title 也不知不觉地变成了中台开发工程师。这篇文章就讲讲我们走过的弯路吧。

我们做的中台叫做故障定位中台。出现这个“中台”也有一定的历史原因，我们公司很多 BU 都有做故障定位的 SRE，也就有很多故障定位系统。我们在中台想做的就是把这些故障定位系统给统一接入进来，复用一些能力。

至于具体的实现就不多说了，没有什么魔法，如果让你来实现，估计跟我们现在的样子也不会差太多。主要说一下我们做的不好的地方吧。

简单

对于一个需要其他系统接入的中台来说，我觉得最重要的东西就是简单。在一个垂直的领域做中台，不可避免的要引入一些新的，抽象的概念。但是引入概念越少越好。印象比较深的，红姐以前试图教我设计 DSL 的时候说过，先实现功能，然后看哪些东西是可以去掉的，最后剩下的就是 DSL. 我觉得非常对。只有简单，才能让出错的概率更小，接入的成本才会低，别人才会愿意用你的系统。中台最大的失败就是没有人使用。

先实现功能，然后看哪些东西是可以去掉的，最后剩下的就是 DSL.

——thautwarm

我觉得一个产品在不知道将什么作为自己的竞争力的时候，“简单”就是最好的竞争力。比如 clock.sh ，一个可以托管 cronjob 的平台，创建一个新的任务只需要填写 4 个值，你的 cronjob 就可以跑起来了。

没有保持简洁，就没有用户。没有用户，也就没有后面的故事了。

而我觉得踩过的最大的坑， 就是这里。有同事之前是做交易系统的，我感觉他们设计的东西都非常复杂。以我们的接入接口来说，入参有 20 个参数，返回值需要用户填 20 个参数，就太复杂了。每次新用户接入，我基本上要给他们培训 4 个小时的时间，后续配合调试的成本也巨大。

作为一个平台，至少要做到用户自己看文档就可以进行接入。不然每次接入都需要进行特殊的培训，显然是不具备通用性的。

度量指的是对于接口方需要让他们看到一个运行的状态，知道自己的东西运行了多少次，效果是什么。

度量与统计（管理）

大部分的中台会作为一个服务提供方让别人来接入吧。所以就有对接入能力管理的要求。对于我们的平台来说，这个管理的需求统计这些接入方运行了多少次，失败了多少次，运行的效果如何。

不同的平台对于统计和度量的需求也不是一样的，分情况具体对待吧。我们的情况更有一些棘手，就是很难通过程序来判断运行结果的正确性。这里有一个悖论，就是如果我们如果事先知道一个结果对不对，那么就相当于我们已经知道了“正确的答案”了，后面做的事情也就没有必要了。所以现阶段我们的度量还是基于人工的。

集成功能

中台一个核心的思想就是 1）减少重复劳动，将一些轮子一次性做好，其他人只要用就可以了 2）结合一些已经有的系统，发挥1+1 > 2 的效果。

所以对于一些常用的操作，可以封装成 SDK。这句话说起来很简单，门槛也很低，谁都可以写。但是实际做的好不简单。可惜的是，很多喜欢写 PPT 的人认为“写代码是最简单的事情，是没有技术含量的事情，是谁都可以做的事情”。我见过的大多数的 SDK 都乱七八糟，一通乱写。

要注意一个点是，尽量地少抽象新的概念，如果没有必要，不要增加实体。尽可能地减少框架对用户的束缚。尽量让自己提供的东西成为一种“选择”，而不是一种“约束”。

说到这里，我又佩服 prompt-toolkit 写成了一个库，而不是一个框架。框架是它来调用你写的 API，就增加了很多的限制。而库是你去调用它的 API. 举个例子，从上手成本上说，一个库你可以看一下函数声明就上手开始用了，对于一个框架，你要知道它是怎么运行的，它是怎么调用你的代码的。

 

实时上传数据备份文件到S3

Posted on by Leave a comment

最近写了一个小工具，用处是可以将数据库的备份文件上传到 S3 上面去。学到了一些很有意思的东西，觉得值得记录一下。

工具的源代码：https://github.com/laixintao/mydumper2s3

备份数据库的方法

最简单的方法，只要将数据库 dump 出来，然后上传到 S3 即可。

但是全量 dump 出来数据库占用磁盘的空间较大，并且上传完之后一般都删掉了。有一种可以不浪费本地磁盘的空间的方法，之前在博客《用 ssh 传输文件》中介绍过。我们可以用管道将 dump 的进程和上传的进程连接起来，这样就不需要本地的磁盘了。

类似这样的方法：

MySQL 自带的 mysqldump 命令是支持将数据库 dump 到 stdout 的，然后我们使用 aws s3 的 cp 命令，将源文件设置为 stdin，中间加了一个 gzip 做压缩上传。因为 SQL 文本压缩空间很大。

使用 mydumper 的问题…

mydumper 是一个第三方的开源 dump 工具（只有 3k 行 C 语言代码）。做的事情其实和原生的 mysqldump 差不多，但是有几点好处（引用 Readme）：Parallelism, Easier to manage output, Consistency, Manageability. 在我看来，最重要的是 Parallelism，它比原生的 mysqldump 要快很多，（猜想）这个速度快是用了很多黑魔法来实现的，比如采用了多线程同时写入多个文件的方式，因为多线程 dump，并不支持输出到 stdout，因为每一个线程都需要一个 fd 来写入（还是我的猜想）。在不修改 Mydumper 的代码的情况下，直接使用 Unix pipe 是不可行的。

所以，要是使用 mydumper 的话，我想到了以下几种方法。

1. 将 S3 挂载到系统上，作为一个文件系统

考虑使用 https://github.com/s3fs-fuse/s3fs-fuse 将 S3 直接挂载到操作系统上，这样 mydumper 并不知道自己在往网络上上传，fuse 封装出来一套 POSIX API，不是完全兼容的，还不知道够不够 mydumper 用，但是感觉问题不大。

这里的问题是，每次文件创建，每一次写入，都是通过网络做的，网络不稳定可能会有问题。也不知道问题会多大，我还没时间测试。

2. 黑魔法，使用 LD_PRELOAD 直接覆盖 write_data

链接的时候可以提前 load 我们定义好的函数，来覆盖 mydumper 的函数。（相当于 Python 的 mock.patch 功能）

比如写一个这样的函数：

然后定义环境变量：

这样在运行程序的时候，随机数得到的就永远是 42 了。

看了下 mydumper 的源代码，只有3k+行 clang，考虑可以使用 ld_preload 直接将他的 write_data （以及打开文件相关的操作）直接覆盖（考虑使用golang，比较好些），将实现直接替换成写 s3。

这样相当于不需要本地磁盘就可以上传了。

参考：https://jvns.ca/blog/2014/11/27/ld-preload-is-super-fun-and-easy/

3. 两个进程，一边 dump 一边上传

这个思路比较朴素，就是 mydumper 只管普通的上传，而另一个进程（我们就叫它 mydumper2s3 吧），只管上传，然后上传文件完成之后，就将上传完成的删掉。

这样，只要上传的速度比 dump 的速度快，就依然还是可以继续的。就怕磁盘空间不够，上传的速度又比 dump 的速度慢，就悲剧了。

这个问题我一开始纠结了很多，最后发现应该也不是什么大问题。以为：

  1. 看了一下 S3 的技术规格，如果在同一个局域网内，速度是 GB 级别的，而 mydumper 是几十M1秒；
  2. Mydumper 支持 --compress ，自带压缩功能，那实际的写入速度又要慢上一些；
  3. 实在不行，可以用 systemd/ionice 这种工具对 mydumper 的进程限速；

所以就不去考虑这个问题了。

有趣的是，我去翻 mydumper 的 issue，发现竟然有人抱怨在磁盘慢的时候 iohang 住，而不是报错（issue）。不过作者回复说这样挺好的啊，这样不就给你时间释放磁盘空间了吗：）

我也想要这样的 T T

实现细节

在 mydumper 还在写入文件的时候上传，需要注意，正在被打开并写入的文件先不要上传，等文件被关闭之后在开始上传。所以需要维护 4 个文件列表：

  1. 当前 dir 下的所有文件；
  2. 正在被打开的文件；
  3. 正在被上传的文件；
  4. 已上传的逻辑；

然后每隔 1s 扫描一次文件夹，将 “当前 dir 下的所有文件” 中，没有被打开、没有被上传、没有已上传的文件，加入到上传队列中。其中要注意好多线程之间的逻辑，至少需要一个定时扫描的 watcher 线程，然后需要一个上传的线程池（注意连接池的大小不要小于线程池的大小）。比如我写的一个 bug 是这样的，将这些文件加入到上传队列，但是没有立即更新到 “正在被上传的文件”中，而是线程池真正开始上传的时候才更新。这样就导致下一秒扫到的时候认为这些正在队列中的文件还没有上传，又入了一次队列，导致文件被重复上传了非常多次。

一开始我是想用 inotify 这种接口去监听文件变化的，最后变成了定时扫描（扫描间隔是可以用命令行参数 --interval 控制的），是考虑到下几点：

  1. inotify 只能在 Linux 系统工作，不同的操作系统，文件变化的事件不同；
  2. 实现太复杂，需要3个线程，监听创建 + 监听关闭 + 上传线程，这些线程之间需要通讯；
  3. 需要处理一些临时文件的变化，比如 metadata.partial最后 dump 完会被重命名成 metadata ；

最后实现的效果如下：

验证备份文件

还写了一个工具可以校验上传文件的 md5.

有个有意思的地方，如果文件太大（超过5M？），S3 的 SDK 在上传的时候会使用 multipart 上传，如果是multipart上传的，s3上面的 e-tag 不是整个文件的md5，是每段的md5合起来再md5. 这样校验就非常复杂。

我发现了这个神奇的bash，按照s3的逻辑在本地文件切段，然后计算hash：https://gist.github.com/emersonf/7413337  （from: https://www.savjee.be/2015/10/Verifying-Amazon-S3-multi-part-uploads-with-ETag-hash/）。

 

最后，这个工具的源代码在这里：https://github.com/laixintao/mydumper2s3

2021年10月29日更新：

今天发现 mydumper 已经实现 --stream 的feature了，作者到我的 Repo 留言说下个版本会支持。

目前还没release。所以我去看了它的代码，看这个实现比较简单。原来的逻辑都没有改，只是会在 mydumper 进程内新开一个线程将 dump 好的文件输出到 stdout 然后删除。这样还是用的多线程 dump。这样，我们就可以使用其他工具直接从 stdout 读出来然后上传了。不过读的时候要注意去解析 mydumper 的输出，比如它是每次先写 stdout 一个 \n -- 4个字符，然后写文件名字，然后文件内容。

 

近况更新

Posted on by 10 Comments

好久没写博客了，决定唠叨一下最近的生活和工作，避免这个博客长草。

大约从5月份开始，我们项目进入了“闭关室”，几乎是封闭开发的状态，但是我没想到的是，到现在我都没有从闭关室里面出来。这几个月的工作中经历了很多事情，大多都不顺，但是总之还是坚持到现在。最有意思的是我在很短的时间内换了 4 个老板：一开始的老板突然就转岗了，我直接汇报给老板的老板；2天后，老板的老板“拥抱变化”了，我就汇报给老板的老板的老板；最近老板的老板的老板招来一位转岗过来的博士，博士就成了我现在的老板。

虽然工作内容没有太大变化，但是工作的思路变化了很多。一开始的老板在，很多决策上都坚持的比较彻底（现在想想好像有些错了），他走之后，我们的思路几乎就变了，然后我就在原来的基础上做很大的调整。我觉得之前的设计太复杂了，我们作为中台，设计的接口里面入参有二十几个，出参有二十几个，每次接入方来找我的时候，我都要费半天的功夫给他们讲这些参数是干嘛的（大部分时间你们都用不到，这是为了“将来的扩展性”）。接下来我想找时间实现一个新的接口（但是兼容之前的接口，让两种接口同时存在）。关于设计上的复杂性，我跟前老板争论了很多次，我坚持应该保持简洁，代码写的越少越好，给别人的参数应该越少越好，我们现在几乎还在 POC 阶段，应该保持足够的简单来适应将来的变化，快速试错。但是被“要考虑扩展性，要考虑将来的需求，要考虑3年的长远目标”给驳回了。导致现在的系统中充斥着各种复杂的概念，实现一个简单的需求需要大规模的重构。

老板走后，我们在去年成立小组的时候的4个人，就只剩下我一个了。另外两个一个是转岗，一个因为工作地的问题划到另外一个组了。好消息是，8月初入职了一个新同学（我也理所当然地成了新人的师兄），所以应该是剩下我们两个人。然后几乎所有的事情都到我这里了，每天不停的有人找我提新的需求，由于平台（设计上）的复杂性，几乎每个需求我都要和同事分析半天。这些复杂的东西也要讲给新人。说实话我好怕新人一看我们这些过度设计提桶跑路。不过好的地方是，我不再像1年那样抵触这些过度设计了。要是那样的话，估计我现在都有很多代码看不懂。现在我已经把系统的代码看了好几遍，很多过度设计的地方也理解了是想到了将来的什么地方。不必要的地方可以自信的删除掉。

我发现起名字真是写好代码的一个硬实力。我们的代码中有很多 invoker, execute, doExecute, item, call 之类的名字，不同的概念起的名字几乎一样，比如 Action, ActionItem, ActionInfo 这种。导致非常难以理解。该加注释的地方不加，不需要加注释的地方乱加，看起来注释率很高，但是大多数都是废话。非常头疼。

说回工作，这个事情感觉我已经做了两年，但是依然没有满意的成果，有点力不从心了。自己的想法没有机会去做，总是感觉是在一堆摇摇欲坠的系统上做一个火箭。不知道这样做下去会是什么结果。有时候会想，要是我自己完成所有的事情，不需要PD，不需要UI，也不需要前端开发，都是我自己去做，实现的效果可能会更好一些。现在是大家的想法（主要是老板的），然后开五六个会确定怎么做，然后我来做主系统分析设计，告诉其他的几个系统怎么配合，这样做下来几乎每个人只会理解70%（还有人不停地问讲过好几遍的问题，心好累），做出来的东西就差一大截。

唉，不说工作了，越想越烦。

搬了新家，开始扔掉一些“觉得有用但是一直没有用过的东西”，感觉很幸福。处理掉了200来本书，都送出去了，留下十几本还没看完的。感觉换一个环境住是一件很快乐的事情。

最近在玩《荒野乱斗》，也有1万杯了，有玩这个游戏的朋友欢迎加个好友，我的玩家标签是：#PYLL90LR 。最近茶杯头登陆 PS4 了，想玩。糖豆人 PS4 港服的会员赠送了，我也有了，也想玩，可惜没时间。想玩微软的模拟飞行，可惜没电脑。

DDIA 快要看完了，真是一本不可多得的好书！

iredis 最近攒了很多 Feature 没有做，最近下了班会找时间搞一搞。

睡觉去了，不知道自己都写了些啥，好乱。