还不够，array 这玩意还是得靠 docblock 注释出元素类型才行，不然用途有限。nikita 柏林大学的 phd，想法多，估计下一步他就要提泛型的 rfc 了

可以用 buffered channel，也可以用 select{ default: } 做 Non-Blocking Channel 操作

https://tour.golang.org/concurrency/6

@mritd 不好意思，刚才提问的时候走神了，名称打错了，上一条里面的 `hotfix` 应该是 `fix`

我的疑问主要是因为在你这套流程里面，会用 git-chglog 自动根据 commit message 生成变更说明，所以就比较纠结处理新 feature 的 bug 的 commit message 的 subject 的命名：

如果用 feat 的话，会导致变更说明里的 features 重复；
如果用 fix 的话，其实它们也并不是生产上的问题，没有必要把开发过程中的问题也写到 change log 里吧？

@mritd 关于 Angular git commit message，我有一个疑问想请教一下，

开发新功能用 feature 做 commit tag，处理生产问题用 hotfix tag，是吧？
那开发时，处理新 feature 的 bug，提交时应该用什么 tag 呢？

@cstome

怕数据库慢就用 redis，用文章表字段存这个真不太好，我现在能想到的问题就不少了：

1. 会影响文章表的查询效率，尤其是在阅读人数变多之后，每条文章记录都平白无故增加几 K 的内容
2. 无法检索用户已读的文章，因为是 json_encode 到 text 里面的，没法做查询，以后产品有这个需求的时候又要改又要做数据迁移
3. 更新阅读记录效率低下，要先检索出文章，再 decode，再往里面添加内容，再 encode，再更新，还要加锁放并发；比直接插入一条阅读记录效率低多了
4. text 的长度是 65536，你的 uid 长度是多少，假设是 32，最多可以存 2048 个 uid，实际肯定存不了这么多，因为你还做了 json_encode，也就是一篇文章上限只能存一千多个阅读记录

赞赞赞

私家藏书 https://itunes.apple.com/cn/app/%E7%A7%81%E5%AE%B6%E4%B9%A6%E8%97%8F-%E7%BA%AF%E7%B2%B9%E7%9A%84%E5%9B%BE%E4%B9%A6%E7%AE%A1%E5%AE%B6/id1130218642?mt=8

不过我觉得其实应该把已读人员单独弄张表，表里面做个 文章 ID + 用户 ID 的唯一键，插入冲突就表示已经存在这个关系了，直接返回已存在的已读关系，这样接口也幂等了

跟 PHP 没关系，数据库层面可以看看悲观锁、乐观锁，小流量网站用悲观锁一般就解决了

if (cache == null) {
// ...
}

这里的做法是 lazy initialization， handlerSharableCache 属性在类实例化时不会初始化，直到第一次使用时才初始化。好处是提高程序初始化时的性能，坏处时降低了每次访问属性时的性能，并且这段代码不是线程安全的

@shootsoft 没必要加 calculation，有点多余了
@yidinghe 尽量少用自创的缩写，用完整的单词

用代码量做为开发的考核标准，就跟用 BUG 数做测试的考核标准一样，都是懒得动脑子的管理拍脑袋想出的方法

实际上，如果项目里有任务管理工具，在给成员分派任务的时候就可以由 leader 和成员一起，给每个任务评估一个开发工作量和测试工作量
在项目完成之后，在项目回顾时再根据实际的开发情况调整一下每个任务的工作量数值，

考核时直接把每个人所有的开发 /测试的任务的工作量汇总，如果还要考核开发质量，还可以计算一下 bug 数 /工作量 比值

静态方法就是函数

你这个例子实际上就是序列化与反序列化，照着 Serializable 接口按自己的序列化规则实现就行

从微软派了一个人过来当 CEO

https://natfriedman.github.io/hello/

试试把 系统偏好设置 -> 安全性与隐私 -> 文件保险箱 关闭了，看看有没有效果