Finisky Garden

为了精简hexo安装的npm modules，用rm -rf node_modules/删除了已安装的包，再npm install把package.json中定义的包安装一遍。结果hexo自动从4.0.0升级到了4.2.1，hexo g时失败。node.js除了hexo外基本不用，npm自然不熟，有些配置是直接抄来的并不知其所以然。而hexo的插件都是由npm管理的，稍微研究了下如何查看这些插件的最新版本和升级它们。

自从有了 996.icu 和马云的“996福报”理论之后，关于996工作制的讨论就从未停止。我有不少同学同事加入或离开了996公司，我想说的是，福报不福报都是自己的选择，自己选的路，跪着也要走完。都希望挣更多的钱，抵制996并不是抵制高收入，本质上是希望用955的工作制挣到996开的工资。但理性思考后会发现它并不合理，单位时间的工资高低是由市场决定的，在一个充分竞争的市场上，同样性质不同公司的时薪差别不会太大。一家公司的package远高于另一家，工作强度和时长增加情理之中。

看下这个回答：# 如何看待996工作制度?

交叉熵(Cross Entropy)和KL散度(Kullback–Leibler Divergence)是机器学习中极其常用的两个指标，用来衡量两个概率分布的相似度，常被作为Loss Function。本文给出熵、相对熵、交叉熵的定义，用python实现算法并与pytorch中对应的函数结果对比验证。

TextCNN 是一种经典的DNN文本分类方法，自己实现一遍可以更好理解其原理，深入模型细节。本文并非关于TextCNN的完整介绍，假设读者比较熟悉CNN模型本身，仅对实现中比较费解的问题进行剖析。

项目地址：https://github.com/finisky/TextCNN

这里的实现基于： https://github.com/Shawn1993/cnn-text-classification-pytorch

主要改动：

• 简化了参数配置，希望呈现一个最简版本
• Fix一些由于pytorch版本升级接口变动所致语法错误
• Fix模型padding导致的runtime error
• 解耦模型model.py与training/test/prediction逻辑
• 定制tokenizer，默认中文jieba分词
• 使用torchtext的TabularDataset读取数据集：text abel

Transformer自2017年推出之后，已经横扫NLP领域，成为当之无愧的state-of-the-art。原始paper “Attention is All you Need”中对attention提出了通用的query/key/value抽象，开始时觉得很难理解，后来随着读的文献更多，慢慢体会到了其中的意思。关于Transformer和attention的各种解释类文章有很多，不再赘述，本文仅就其中的核心，MultiHeadAttention的实现进行源码剖析。

Find Peak Element 给定一个数组，其中任意两个相邻元素的值不等，寻找数组中某峰值的index i，使得n[i - 1] < n[i] > n[i + 1]。保证峰值一定存在，如果有多个峰值，可返回任意一个。

乍看此题不难，O(n)的算法很容易想到，直接遍历数组即可。但题目要求给出O(log(n))的算法。显然，直观上应该用二分查找，否则复杂度要求不能满足。可数组是无序的，无法直接应用二分查找。

Today I found that some pods in kubernetes cluster are failed, the status is Waiting: ContainerCreating. The pod events:

MountVolume.SetUp failed for volume "xxxxx" : secret "xxxxx" not found
kubelet aks-agentpool-xxx-vmss000001

Unable to attach or mount volumes: unmounted volumes=[xxxxx], unattached volumes=[xxxxx]: timed out waiting for the condition

维护过中型以上系统的工程师，一定都有看到某处代码或设计后脱口而出"What the fuck","这TMD是谁设计的系统","写这代码的人脑子有坑吧?"的经历。

想到上学时一个工作几年的师兄聊天时说，实际系统里讲究“够用就好”，不要搞一些奇技淫巧，当年听起来觉得很有道理，但却没有切身体会。随着经验的积累，慢慢明白什么叫“够用就好”，什么叫过度设计，以及简单比复杂需要更高技巧和更多思考的道理。

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

在以前的面试指南中，写代码不限定编程语言，主要考察算法。近几年机器学习火了之后，作为面试官，面试科班出身的面试者我会要求对方使用C或C++而非Python。原因很简单，现在许多科班出身的同学基本功不扎实，恨不能大一上来就搞深度学习，对计算机科学没有大局观和底层的认识，往往不能很好地胜任日常的工作。而C/C++作为科班的必修课，可以作为一个简单的分类器判断对方的功底。

吐槽完毕，LeetCode是大家常用来刷题的网站，但对于工作中不把C/C++作为开发语言的工程师来说有些语法太久不用就忘了，更不提STL中的一些特殊数据结构的方法，这里简单总结一下，便于快速捡起来。

GPT2是一个很好的长文本生成模型，但官方版本并没有开源中文预训练好的模型。因此，最近用开源的中文新闻，wiki，评论等从头训练了一个中文GPT2用于文本生成任务。

预训练使用的是HuggingFace的transformers库，这库是个好东西，把当前主流的transfomer-based模型都封装了一遍，使用起来方便很多。但由于不同模型的结构、参数等等细节不同，封装成统一的interface还是有难度，因此此库上也有一些折衷，也并不像想像中那么好使。就pretrain和fine-tune来说，都是训练一个language model，理论上调用它examples/run_language_modeling.py即可。不过真训练起来发现还是有些坑：

• 中文Tokenizer用什么？
• 大规模语料爆内存
• fp16混合精度训练？

最后一个问题坑有点深，nvidia的apex库用起来并不是那么顺滑，尝试了多次并未成功。此外听朋友说即使fp16也仅能提升约20%的训练速度，看起来并不太promising。另外inference时也要使用apex，增加了额外依赖，麻烦。

这里就说说前两个问题。