[9102 && 2020] New World

回望过去, 瞭望未来

OKR 2020 中期檢查修正

今天 6.30 , Q2 的最后一天 , TimePolice 提示 2020 已经过去 49.45%(181/366), 来更新下 OKR 2020 的 中期进度 以及 部分修正,

中期总结

2020 从年初起, 业余时间基本就全部投入到 MSC (Side Project) 里了,所以别的 OKR 项目基本没有什么动作. 目前有进度的 OKR 是如下这些:

• Linux Desktop 方面, 已经彻底转换到 I3WM 下进行工作, 但还没有去 对 I3WM 进行自定义. 没有开始自定义的原因是 配置的同步目前依旧还没有找到合适的方案, 但个人认为对 Linux Desktop 的用户来说, 配置的同步其实是一个痛点.

  所以 笔者计划写一个 confSyncer 来完成这个工作, 目前正在缓慢开发中, 处于总是分不到 时间片的状态 :joy:. confSyncer 的项目进度方面, 目前基础功能已经跑通, 处于 完善特性 和 修复 Bug 的状态, 不知道什么时候能发 V1.0 . 另外在关于 Linux Desktop 的恢复和备份上面, 笔者有一些自己想法想谈一谈, 未来成文后会更新到 Gist 上.

• 开源 方面, 今年 Q2 有参加 Pingcap 的 TIDB 易用性挑战赛, 但因为各种各样的原因, 只参与了 pingcap/dm等 项目 , 对一些比较边缘的功能进行了修复, 在接下来的 Q3 和 Q4 还是希望可以参加到一些比较知名项目(目前目标还是按照年初提出的 OKR 不变, kubernetes/ golang), 以及对比较核心的部分进行贡献. 但这里也不是说在 TiDB 易用性挑战赛中的收获没有什么用, 这块其实有很多收获, 这块留到后面去讲.

• 博客 方面, 统计了一下 , 大概 2020 上半年只有 Q2 产出了 两篇 Gist , 阅读 Tidb 4.0 和 Go 1.14 Feature 之后的总结, Articles 方面 Q1 + Q2 只有一篇产出, 那就是昨晚刚刚发布的 PromQL query result is abnormal when it process NaN data , 离 30 篇/年 的目标 还有一段距离, 但随着逐步深入, 笔者相信 应该下半年完成 10 篇 Articles 应该还是有可能的.

  另外博客计划已经重命名成 Proj 百万亚瑟王的石中剑, 关于最近莫名其妙且中二的 Project 命名, 之后会写一篇 Gist 来聊一下.

• Side Project 方面, MSC 的 Alpha 阶段开发已经完成, 再逐步 添加特性 和 Bug 修复 到 Beta 特性, 即可上线运营. 但对于 MSC 还有一些别的感想, 所以这块留到后面去讲.

• 阅读书籍方面, 其实很多书都有开坑, 例如 Google SRE 动物书, 书很好, 也有在读, 但是就是莫名其妙就没读完, 然后莫名其妙就吃灰了, 觉得这一方面需要检讨. 目前在尝试养成阅读书籍习惯, 每天定时某个时间点来阅读书籍, 不然感觉阅读书籍这件事很难分到时间片. 而它又是 ROI 非常高的一项活动. 可能还是需要沉下心来, 阅读书籍这件事情虽然没有 写代码 和 读代码那样可以看到立竿见影的好处, 并且 相较 写代码 和 读代码 略显枯燥, 而且读完还要写笔记, 很花时间. 但阅读书籍才是 the true way, 对现阶段的笔者来讲 , 大量的 基础知识 和 沉淀下来的思考 都在其中.

除了上面这些, 2020 OKR 的其他部分完全没有动作,

明确 与 修正

接下来是对 2020 下半年的 OKR 明确和修正, Q3 + Q4 两条重点线是放在 基础知识补充 和 代码阅读 方面,

基础知识补充

主要包含 计算机组成原理 ,GC,编译原理, 算法 , Linux 组成, 网络与网络协议, 基本可以理解成 重学 CS 计划 (@煎鱼 XD),

并且不要以读完一本书做完结尾, 也不要将教材局限于一本书, 需要输出文章对 整块的知识模块来进行总结.

其实关于 基础知识 的补充是个老生常谈的话题了, 程序员论坛里的隔三差五就能看到相关帖子. 但这次把 基础知识补充 拿出来作为一个重要方向的原因是 基础知识匮乏已经着实影响到笔者的工作和成长, 举个例子, Kubernetes 管理容器有 Memory Limit 上限, 内存在 Limit 左右 久居不下将会被 Kubelet OOM 掉, 而 Memory Limit 直接关系的 是程序的 Memory WorkerSet 指标, 而 WorkerSet 又由 Memory Cache + RSS 组成 , 然后这里又可以扯出 虚拟内存 等的一干概念, 对这块 基础概念 笔者着实是 极度匮乏, 定位问题时实在感觉力不从心.

算法方面也存在缺陷, 目前 Leetcode 刷题, 只能搞定 DP 以下, 对 DP 的理解只是皮毛, 周赛基本做完前面两题就可以收工, 图方面更不用说了, 直接凉凉, Q2 的时候有想过给 Go-callvis 加一个 有向有环图 寻路的特性, 但一直分不到时间片, 而且这块 ROI 实在不高, 所以只能作罢. 随着 Q3 公司开始试水 Service Mesh , 笔者在 协议和网络 这块的缺口可能会继续扩大, 所以 重学 CS 计划 刻不容缓 :joy:

代码阅读

代码阅读另一方面 也可以理解成源码阅读, 觉得就笔者现阶段的程度来讲, 读代码 比 写代码 的 ROI 高得多. 无论是 提高从源码定位问题的能力(例如 Prometheus 等), 还是 增加 结构设计阅历(例如 Kubernetes / Prometheus 等), 亦或者 提升社区认可度和社区声望 (知名 项目的 PR 量以及 有价值的博客产出) 等等 的方向来看, 都是非常有吸引力的.

基于上面的两个主线, 也能对 2020 OKR 中的大多数目标起到 推动作用.

另外在语言学习方面, 也需要尝试分配一定的时间片.

一些感悟

PingCAP 易用性挑战赛 (UCP)

下文简称 UCP

虽然 在 UCP 中, 笔者只参与了 pingcap/dm 等边缘项目的贡献, 但依旧有很多收获 (这么说好像山里的原始人一样 :joy:)

1. 对 Issue 和 PR 以及 Project(gitlab 里称为 Board 看板) 的协同运作有一个初步的认识, 毕竟笔者是第一参与大型的开源项目, 此前对这一套有耳闻, 但未实践过, 这次在 UCP 中体验了一把, 很实用 , 遂之后在 MSC 的任务和缺陷管理中, 也把这一套用了起来
2. 完善的 TestCI 和 DevOps 流程, 来减少工作量和提升代码质量. PingCAP 项目用了很多 bot 来进行代码检查和运作, 例如 对注释和代码规范的检查, 还有 自动和 关键字触发 TestCI, 很多的工作已经被自动化.
3. 测试以及基于测试保证代码质量, 基本上大部分特性的提交都会要求补充测试用例, 并且测试的代码可能和功能代码有 3:7 占比, 开源项目需要测试用例来保证质量. 即便需要付出很多的时间也是值得的.

能总结出来的基本是以上三点.

Proj 赫菲斯托斯的翼鞋集市 (MSC)

下文简称 MSC , 中二的 project 名太长了.

笔者一直希望可以有一些 SideProject 可以带来额外收入, 这个希望在今年总算真正意义上付诸行动, 而 MSC 便是那个希望的种子.

然而在实际的种子生长过程中, 各种问题频出, 让笔者切肤的感受到自己的 稚嫩.

• 对项目的工作量完全无法客观进行预期, 什么东西都感觉一下子应该都能搞定. 然而实际上, 整个项目到 Alpha 测试上线, 用了将近 6 个月.
• 无法进行项目管理
• 自我搏斗内耗严重,
• 任务和缺陷管理全靠大脑, 时常忘记为什么要这么做 或者哪些地方要改, 在 PingCAP UCP 之后开始使用 GitLab Issue + Board 进行管理.
• Feature 添加非常随性, 觉得 Cool 就加,觉得现在的不好就直接改, 完全忽略了 工程 和 Demo 之间的区别
• 项目架构设计完全没有思考权衡, 拍脑门觉得 OK 就直接这么做了. 这个情况在 Q2 有所改善
• 无效且脱离现实的时间管理 搭配 容易走神的大脑, 一道 香甜可口 的 一事无成 做好了, 这位先生请尽情享用 : )
• 莫名的焦虑 和 脱离现实的急于求成,
• 对产品的认识和定位不清, 技术方案也很随性. 在 Alpha 完成之后, 发现市面上已经出现了类似的竞品.

虽然整个 MSC 项目的结果最后可能也是失败吧, 但整个项目过程中和结束后带给 笔者的反思还有成长以及经验, 以及对笔者自身的实际认识, 大概已经超过了这个项目可以得到的盈利. 如何成为一个沉稳的职人, 而不是这种三十流业余选手.同时也要尊重现实,尊重逻辑, 基于自身情况来进行规划.

目前能用语言表达的部分大概这些, 可能之后会再补充一些.

最后贴上以前的 Leader 在他的文章 <创业 21 年> 中的片段作为这次中期检查的结尾吧. 共勉.

From「創業 21 年」By Thorb J

急于求成使我不论在何种处境下，不论得失都在焦虑，不顺的时候自然是郁郁不得志，小有所成带来的短暂快乐也过不了夜，第二天就会想要更多，永远都处在求而不得的状态，又怎会快乐，更糟糕的是这种在状态会使人无法专注于当前的工作，最终的结果是什么都做不足够好，进而阻碍了进一步的发展。

过去我迫切的想要「成功」，但是直到现在，我对「成功」的定义依然是模糊的，但「迫切」是真实的。每一天我都在想怎么做成更大的事情，怎么赚更多的钱，没有任何其它兴趣爱好，工作谈不上有多快乐，但是不工作的确会很不舒服，工作以外没有任何想做的事。但本质上，我想要的不是经历无数艰难困苦后的而取得的伟大胜利，而仅仅是想要「立刻成功」，这并不现实，天资平平，普通到不能再普通，又怎能期待幸运女神突然降临，这无异于和买彩票一样不现实。

9102

看了下 timePolice , 2019 年已经过去 362/365 (99.18%) 了, 也基本到了尾声, 先对今年做一个总结吧.

Q1 和 Q2 基本都在低效和焦虑中度过, 那个时候从上一间公司离职, 想转向 Go 开发和熟悉 Kubernetes ,但由于心态的原因, 一直处于低效学习和摸鱼的状态. 而效率是一方面, 另一方面在对自己的项目管理和时间管理上, 也做的比较差, 以致于这段时间的 SideProject 全部是放弃或者失败的状态. 曾经在公司觉得每天写的业务很无聊, 如果让我投入精力去做自己的东西, 一定可以大放异彩, 然而结果却非常讽刺. 过于的急于求成和忽略事实情况的乱开空头支票以及毫无道理的时间管理, 基本可以预言项目将会以失败告终.

Q3 Q4 开始做 微服务和云原生相关的工作, 也算是往自己想做的事情上靠了一些, 心态问题和焦虑逐步缓解, 从 Q3 初期开始培养 写作写博客 的习惯, 一方面是总结, 另一方面是用输出倒逼输入, 这块感谢 @Bestony 的写作课程. Q3 也开始 follow 左耳朵耗子 提出的 ARTS 练习, 不过从工作后时间管理上就做的不是太好, 中间断了大概有三个月的 ARTS.在 2020 部分会再讲 时间管理的问题.

不过也由于去年没有立今年的目标, 然后看了看 Google keep 上(Google keep 已经很久没有用了)去年的目标, 完成的有一些, 没完成的也很多, 希望 2020 年末比较的时候能够将结果 量化.

2020

学习

持续进步需要大量的输入.

专业支持的补充/tips

专业知识的补充上面分为两块,

• 基础知识, 例如 网络协议模型/数据结构与算法补全/Linux 系统特性/操作系统原理
• 上层建筑知识, 例如 Kubernetes 和 Server Mesh 设计与细节/微服务设计/DevOps 体系知识/ 项目管理的知识与方法

书籍阅读/targets

读书的必要性不需要多说, 9102 年读书很多都是开了开头就之后再也没翻开过, 所以希望 2020 年能有所改善

1. 读一本书就先攻到底, 同时的阅读任务不要超过 三本

2. 读完要有相应的书评和笔记, 书评更新到 Articles-书籍阅读进度 ,笔记更新到 Gist 上

3. 每一本书有相应的排期评估, 以周为单位 ,逐步调整, 但也不要求快,求快很可能什么也没得到, 有收获才是最重要的, 延期无所谓, 重点是 计划在实际推进

   目标:

   年书籍阅读量 >=12

课程/Targets

这一块目前主要集中在 极客时间上, 9102 买了很多课, 大部分都是翻了翻就放置 Play, 也希望 2020 有所改善

1. 也是和读书一样是排期制, 这类课程和读书比较不同, 读书比较需要大块的时间, 而课程则对时间连续性上的要求没那么强, 所以可以用碎片时间来进行学习, 但是在 课程消化和笔记落地上则需要不少的时间, 这个能否和 书籍阅读的排期并行还不清楚, 先尝试并行试试

2. 一期课程需要有相应的课评, 之后会在 blog 有专门的帖子, 笔记发在 gist , 版权这块应该是没问题,.

3. 每一门课程也和书籍阅读一样有排期, 一周为单位, 相同的要求

   目标:

   年课程阅读量 >= 12

源码阅读/Targets

这是第一次尝试较硬核的源码阅读, 此前虽然也有阅读过一些源码, 不过主要是工作中用到类似的函数, 然后跳转过去看下实现.

源码阅读这里分为两条线

1. 从外到内, 先用起来, 知道它是怎么运行的, 再对感兴趣的功能点进行细节阅读
2. 从点到线, 顺着 Issue 或者亟待解决的问题 对 框架中的 点 (Point) 进行细节阅读, 直到逐步熟悉. 再考虑从线到面, 至于在线的阶段要怎么阅读, 那就是在线的阶段考虑的事情了 .

此前, 我下意识的觉得源码阅读是通篇阅读, 这里我想引用现在 Leader 对于源码阅读的评论,

源码阅读更像一种压缩算法, 大部分的压缩算法都是有损压缩, 而阅读源码阅读也是一样的, 你不可能无损的将全部的细节都放进来, 损失的部分可以之后再去补充, 你需要 Handle 住你感兴趣的那些点.

今年的目标主要是这三个

• micro/go-micro + micro/go-plugins 微服务框架

• kubernetes/kubernetes

• Go 标准库和 Go 本身

  目标:

  已阅读代码百分比> 50%的项目数量 >= 1

  每个阅读代码百分比大于 50%的项目的文章产出 >= 5

博客/Targets

• 这个是入职时候立的 Flag, 但是入职时候的那个目标应该是没法实现了…… 重新定目标

  目标:

  Articles 的数量 >= 30

  掘金作者等级 >= lv3

英文/Targets

• 还债系列…… 三天一篇 阅读理解/完形填空, 这个能否和前面的并行比较存疑, 不过可以肯定的是没时间打 PS4 了……

  目标:

  六级试卷及格次数 >= 3

Target 2

12 月前去一次英语为母语的国家.

工作

工作目标与个人目标尽量靠近/tips

尽可能的在自己感兴趣的方向上持续找到点去对公司的项目进行优化, 这需要对该方向有一定的认知与理解以及视野, 才能达成这样的良性循环 . 尽量减少个人目标与工作目标背离的情况.

提高工作效率/target

这里有几条可以优化的点:

1. 降低上下文切换的代价
   1. 被打断和任务切换之间的存在大量的低效时间
2. 正确评估任务完成所需的时间,
   1. 任务完成并不是写完代码主体即可, 还有测试用例/设计文档/使用文档/注释 以及其他的东西(记录优化点/), 所以任务排期的时候, 不要害怕自己要的时间太多, 优质的产出才是最重要的. 效率并不是写的快, 而是写的快又好, 而快和好之间在软件开发中是制衡关系, 所以 合理的排期才是最重要的.
3. 提高沟通效率,
   1. 例如和同事交流问题的时候, 使用关键词系统, 快速进入同一个频道,
   2. 不要恐惧沟通
4. 充足的睡眠
   1. 一个清醒的脑子比什么都重要, 任何娱乐行为占据睡眠时间都是愚蠢的.

打造自己的竞争力/tips

• 如果可以的话, 可以考虑两个月去面试一次. 并不是要到处跳, 仅仅是对自己的程度和不足做检查.

  目标

  中大厂面试次数 >= 2

SideProject/Targets

• 2020 上半年的主要目标是 Supergroup Cluster 的 SaaS, 尽量年后可以出 MVP, 不过时间点还要再评估.

  目标:

  成功上线并创造营收的 SideProject >= 1

开源/Targets

• 至少参与到一个大型的开源项目中, 目前的预选项有 micro / kubernetes / go , 和上面源码阅读的目标是一致的

  目标:

  加入 Kubernetes Sig

效率/Targets

为了改善经常 ARTS 莫名其妙就没时间做, Gist 莫名其妙没时间写的问题, 需要开始对自己的时间开始追踪, 使用 Google 日历和其他时间追踪软件对事件进行规划, 这条参考自 @Bestony 的 2020 年度目标, 这块的目标尚未提出.

运动/Targets

滑板

• 目标:

  能街滑和代步, 做出基本的花式动作 Ollie

其他

Linux Desktop

彻底切换到 I3wm 进行工作, 在通常情况下最好能够完全切换到键盘流工作

ML 方面

学习基础的数学理论, 尝试做出一些东西?

结

先立这么多 Flag, 2020 年末再来看完成了多少 XD

ref:

2020 年目标