分类
生活

一些近况

4月28日晚上，我在家跳 Just Dance，大概跳了 4 首歌，结果第二天早上起床，左脚踝肿了。我猜测是扭伤，因为前几天光脚跳舞，感觉很粘，做动作比较困难，所以28日特地穿了袜子，光滑了很多。我左脚本就有伤，怀疑旧伤复发。

但是我没有特别在意，觉得似乎不太影响行动，有点大学时候崴了一下那种感觉。于是该遛狗遛狗，该出门出门。晚上伤势突然加重，甚至把我疼醒了。次日起床，脚踝肿得更加严重。我开始怀疑是痛风，因为我尿酸一直偏高。

经过冰敷+云南白药，两日后渐渐消肿，不太影响行动。但是没高兴多久，肩膀又痛起来，也是夜里突发，又把我疼醒了。这次觉得惨了，多半是痛风。

然后赶紧去医院诊治，测了尿酸，好像并不太高。但是血糖因为前阵子的疏忽，百达杨停药，我自己麻痹大意，空腹高到12.5，糖化8.7，已经明显进入发病状态。骨科大夫说，糖尿病人多半会有肩周炎，关节莫名其妙的疼痛也很常见，所以怀疑我并不是痛风，也不是扭伤，而是血糖控制不好导致多发关节炎。

所以，没办法，赶紧控糖吧。首先请内分泌大夫调整药物剂量，我也重新定时定起来，保证按时吃药；其次百达杨性价比太低不再用，但是类似的药还是用起来，这次换上诺合力，在我身上效果明显，食量大减，我本身血糖也高，并不会觉得不舒服；再次，小区里的健身房办张卡，尽量每天都锻炼一下子。

经过一个月努力，现在空腹能维持在 6.1 附近，偶尔能正常；餐后如果体育锻炼，能降到 7.8 以下，不锻炼8附近，算基本控制住。接下来就是坚持，顺便把体重减一减。等到放了暑假，有空去住下院，好好检查一番，希望到时候能都正常。

哎，这身体真是一刻都不能大意啊……

诺合力在我身上表现不错，且已入医保，需要减肥又控制不住嘴巴的同学可以去医院咨询一下专业医师。（此段文字不构成用药建议）

分类
vue

webpack 入口是 vue 文件时，无法合并 CSS

在多页网站中合并 CSS 是很常见的优化手法。一般来说，CSS 体积不会太大，使用同一份 CSS，改进用户点击链接后的加载速度，大部分收益都大于多加载几 K CSS 带来的损耗。

对于 UI 库来说也是如此，用统一的样式库，减少 import 时的心智负担，也是性价比很高的做法。

最开始我在 UI 库的入口文件里 export 所有组件，然后在其它仓库里用 import {component} from 'my-components' 使用组件。后来通过分析得知，这样做无法 tree-shaking，而且会导致组件库的重复引用，即 A import B，B import C，那么无论 A 里有没有用到 C（比如用到 B 的一个小功能 b1，它不依赖 C），都会把 C 的代码打包进去。

通过研读 Webpack 的 tree-shaking 文档，我得知也没有什么好办法可以规避这个问题，毕竟 JS 很灵活，你也不知道哪个开发者会搞个 eval('const myRequire = require')，如果要识别解析分辨所有情况太复杂，所以选择最保守的策略：认不出来具体功能的代码都给你带上。（早年我写 NerveNet 的时候，就是想不通这里怎么搞，最后坑掉了。早知道大家都选择绕开，说不定我的 NerveNet 也能如愿写出来了……）

总之，目前 lodash 的做法比较常见且能解决问题，即增加多入口，为每个可能用到的函数都打包独立的函数。这样需要引用那个就引用哪个，不用担心把整个 lodash 都打包进去。

于是我就立项开始重构我厂的几个前端库。然后很快就卡在 UI 库上面：无法生成合并过的 CSS 文件。Google 许久没有结果，吃饭前我灵机一动：vue-loader 必须搭配 VueLoaderPlugin 才能正确打包，会不会这个过程有 bug，导致如果我的入口都是 Vue 单文件组件，就会没法正确合并 CSS 文件。

然后我就测试了一下，代码大约如下：

// a.js
import './a.styl'

// b.js
import './b.styl'

可以生成合并过的 CSS 文件。与之相较，这样的 Vue 单文件组件就不行：

// a.vue
<style lang="stylus">
body
  font-size 16px
</style>

// b.vue
<style lang="stylus">
body
  color red
</style>

但是，同样是 vue 单文件组件，样式使用 import 的方式导入，就没问题：

// a.vue
<script>
import './a.styl';
</script>

// b.vue
<script>
import './b.styl';
</script>

现在可以确定是 vue-loader 或者 VueLoaderPlugin 有问题。不过最近身体欠佳，每天要花很多时间锻炼，另外还欠下不少坑要填，所以暂时没空去翻 issue 或者提 issue。哪位同学看见了，愿意帮忙的，可以搞一下，也算参与 开源社区建设了，功德无量。

分类
前端

Font Awesome 发布 Duotone 字体，支持双颜色

无意中看到 Font Awesome 发布了 Duotone 双色字体，感觉很神奇，我还不知道 WebFont 竟然支持多种颜色，于是赶紧看了看。

首先，这是旧闻，实际上，去年，也就是2019年7月30日，Font Awesome 就发布了 Duotone。

关于 Duotone 的介绍，大家可以看这篇官方博客：Introducing Duotone。借张图直观地展现 Duotone 的效果：

然后我就很好奇它们是怎么实现的，据我所知 WebFont 不支持多颜色。研究了半天，发现原来是这样：

2019年5月30日，Font Awesome 发布了 Font Awesome Kits（工具包）。Kits 是一个 JS，用来取代之前直接使用 CSS 引用字体的方式。这样做有几个好处：

  1. 根据字体使用情况按需加载
  2. 可以在客户端管理缓存，避免重复下载图标
  3. 可以自动更新图标，跟 Font Awesome 发布同步
  4. 可以帮助开发者处理可用性问题（关于这一点，GitHub 曾经发布过一篇博客，解释他们为什么要从 Icon Font 切换回 图标：https://github.blog/2016-02-22-delivering-octicons-with-svg/）
  5. 可以更快应用新技术，比如 HTTP2，SRI 等

上面几个好处都是 Font Awesome 官博《Introducing Font Awesome Kits》中列出来的，还有一个好处它们没说：可以修改 DOM。Duofont 正是藉此实现双色的。打开开发者工具，我们可以看到，所有图标 <i class="fad fa-*"></i> 都被替换成了 inline <svg>，包含两个图层，自然可以通过 CSS 控制颜色等样式。

这个思路很有意思，布局也一步一步规划的很好，虽然不知道最终效果如何，但还是学到不少东西。

Font Awesome 提供免费版，我一直在用。付费版一年 $99，我觉得还是贵了点，所以一直没用，有需求的同学应该试一下。

分类
分享

程序员当读《男人装》

继续阅读 “程序员当读《男人装》”
分类
管理

浅谈小型技术团队管理：问题篇

开篇先画一下范围：

  1. 针对小公司和小技术团队
  2. 技术团队地位中等偏上，作用比较重要，又不是那么重要
  3. 通常来说没有很核心的产品

比如外包公司，客户当然期望你做出佳作，但实际上也做好了不行就换人的心理准备；或者老板本身不是做互联网的，拉起一支队伍想“赋能”一下自己的行业。总之就是资源不会太多，能做好当然皆大欢喜，做不好背锅走人也不要意外。

这里我主要想和以技术研发为核心的纯互联网产品公司区分开。此时资源都会向研发倾斜，节奏也会跟着研发走，对于技术管理者来说，施展的空间要大得多。

好，相信很多技术同学都有类似的经历：

工作几年之后，自我感觉良好，大部分技术问题难不倒你。突然有一天，某位曾经合作愉快的前同事突然找到你，说有个改变世界的产品，需要一位足够出色的 CTO 来统领团队，想来想去你最合适。

你觉得项目听起来靠谱，也觉得自己有能力接手，然而更重要的是：工作几年，想多接触些管理，但是现在的领导并不打算让贤，公司也没有那么多坑等着你填，这似乎的确是个好机会。

于是你接受了对方的条件，成为这个小型技术团队的领导，公司非常需要你的团队做出好产品，但是你要面临很多不利因素：

  1. HC紧张，岗位设置很难做到面面俱到
  2. 业界知名度低，难以招幕到高级人才
  3. 资金压力大，要求快速迭代、变现，给研发部门自由发挥的空间不大
  4. 名义上“技术一小步，公司一大步”，但实际上技术并不是绝对核心，至少在几位合伙人的眼里不是。

无论如何，先搭建团队，然后动手开发，活儿总是要干的嘛。大多数同学面临这种情况，会直觉性地选择俩眼一闭，先写代码。毕竟，写了代码才有产品，有了产品才有后面的其它工作。

早期的开发一般会比较顺利，毕竟没有限制，只管做功能就好。但是，随着开发进行，踏踏实实写代码很快变成了奢求，一茬接一茬的问题出现，大家疲于奔命，到处救火，真正的产品优先级反而抛在后面。以我的经验，常见的问题有：

  1. 出了问题，前后端互相甩锅，前端说是后端的问题，后端说是前端的问题
  2. 测试人员高高兴兴的测出来一大堆问题，其中一多半可能不是问题，但是测试也需要职业成就感，所以他们宁可错杀一千不愿放掉一个
  3. 因为缺少回归，做新功能或者改 bug 的时候一不小心就把之前的代码改坏了
  4. 后端没做出接口，前端开始的时候要等后端，比较闲；后来接口出来了（多半延期），为了项目整体进度，又要赶时间，忙得要死
  5. 没有测试集，不敢重构，不敢升级依赖，不敢更换系统
  6. 没有压力测试，市场费用花出去，一波流量涌入，服务器挂了……
  7. 长期零和博弈导致团队内部关系紧张，内耗严重

早年我也认为这个问题无解。大家只能夹缝中求生存，想方设法把产品搞出来弄上线，寄望产品成功，争取到足够多的时间旧代码，还技术债。用发展解决问题，或者至少延缓问题。

但是我厂工作几年之后，我开始有新的想法。想要保证产品质量和代码质量，同时一点代价都不付出，当然不可能；但是，以优秀的技术产品、良好的流程，在保证产品质量和代码质量的同时，减少付出的成本，使得我们最终能够在项目进度、团队建设、产品质量之间找到平衡点，是绝对可能的。

可惜的是，我暂时找不到能够立刻满足这套需求的产品，所以我决定在未来的一段时间把它整理开发出来，至少能够满足我自己的日常使用。希望这个坑能填上，能够真的派上用场。

分类
分享

思否创始人的 Python 课

我跟思否的关系一直不错，所以理所当然要帮他们宣传一下，顺便水一篇博客。

一般来说，我很少转发别人的课，毕竟我自己的课都不想占用太多公共资源。不过这次是 Joyqi 老道士下山，非常少见，相信课程质量会很有保证，建议不要错过。这里帮他们扩散一下，微信扫描/识别下面图片的链接即可。

训练营形式，面向初学者，非常值得。

分类
vue

Vue 3.0-beta.1 发布！

经历一年多的推倒重来反复打磨，在众多开发者的千呼万唤之下，Vue 开发团队终于在今天发布了 3.0-beta.1 版本，也就是测试版。通常来说，从测试版到正式版，只会修复 bug，不会引入新功能，或者删改老功能。所以，如果你对新版本非常感兴趣，或者有新项目即将上马，不妨尝试一下新版本。

按照官方路线图，原计划 Q1 末发布测试版，Q2 发布正式版。目前看来稍微有些延期，不过不多。相信正式版会很快到来，非常期待呀。

在我看来，Vue 已经是一份杰作，而 3.0 的变化则让它更加优秀。

起初，Vue 开创性的使用 Object.defineProperty 改写对象属性赋值运算，隐性收集依赖，把前端开发的难度降低了一个维度。从此，我们不需要考虑怎么绑定数据，怎么更新视图，只需要简简单单修改变量的值，界面就会自动变化，如魔法一般。

如今，Vue 3.0 更进一步，使用 Proxy 拦截赋值操作，不仅实现了同样的功能，还大幅降低系统消耗、减少计算时间。——更加值得期待的是，因为新 API 更强大，之前困扰众多开发者的“修改数据，界面不更新”问题，应该会变得极为罕见。

这会令 Vue 的入门门槛变得更低。在我看来，这件事善莫大焉。写代码并不仅仅是写代码，它是这个世界上成本最低的“创造型”工作。其它创造型工作，比如雕塑、美术，除了复杂的基础教育，还需要昂贵的生产成本。编程不需要，只要你有一台电脑，坐下来就可以写，想怎么写就怎么写，想写什么就写什么。而前端，又是其中成本最低的，你甚至不需要搭建开发环境，拿个记事本就能写，写完放到浏览器里就能跑。

从这个角度出发，每次在知乎看到“我出身不好，能不能学编程”，或者“我学历不好，能不能学编程”，我都会建议他们学。因为学会编程，不仅仅是掌握一门手艺，可能养家糊口，更是给自己的未来增加了一种可行性。学会编程，你就可以把手伸到我这种专业程序员伸不到的地方，帮助自己、帮助他人、甚至帮助世界，同时也能给自己换来各种各样的回报。

另外，新增的 Composition API——不管是一些人口中的“学 React hooks”，还是 Vue 作者尤雨溪说的“这不是 hooks，这比 hooks 强太多了”——大大增强了代码的可复用性，能很好的改进代码架构，为更大的项目、更强的架构，带来了更多的可能。

如果说 jQuery 让更多的人可以学会开发，那么 Vue 就让更多的人可以开发中大型软件。它会给整个行业带来的巨大帮助，让更多的产品可以有更好的用户体验，让更多的产品可以迁移、升级到新平台、新架构。

这个影响是潜移默化的，就像当年 Flash Player 集成 H.264 视频解码器一样，虽然很多人没注意，但是视频网站的春天就是那个时候到来的。如今，有了更好的基础设施，哪个新产品会崛起，我无法判断，但我觉得，对技术来说，更好的一天已经开始了。

继续阅读 “Vue 3.0-beta.1 发布！”
分类
技术 招聘

代友招聘：珠海/远程 APISIX 前端

另外我们 OpenResty Inc. 也在持续招聘后端工程师/系统工程师，可选北京、深圳，也支持远程，详情请点击：OpenResty Inc. 招聘后端工程师。

支流科技（APISIX）是一家开源基础软件创业公司，围绕着 Apache APISIX 构建下一代微服务，用户包括：中航信、海尔优家、腾讯云、空中云汇、NASA、欧盟数字工厂等 100 多家国内外知名公司和科研机构。

招聘中高级前端工程师，主要负责：

  1. 企业官网开发
  2. Dashboard 型产品开发

主要待遇：

  1. 全职工作，有五险一金
  2. 珠海上班最好，远程亦可
  3. 有（丰厚）期权

需要：

  1. 独立工作能力
  2. 掌握 Web 前端技术
  3. 掌握前端工具链
  4. 熟悉软件工程体系
  5. 至少熟练使用一个前端框架

加分项：

  1. 有开源项目参与经验
  2. 有长期博客
  3. 有远程工作经验
继续阅读 “代友招聘：珠海/远程 APISIX 前端”
分类
技术 招聘

代友招聘：广州垂直领域知识付费

公司从 2018 年开始做相关的产品研发，到现在已经经历了两轮迭代，目前正在招聘新鲜血液，准备在 2020 年再搏一搏。

招聘链接在这里，长期招聘：https://www.zhipin.com/job_detail/?query=硅碳鼠&city=101280100&industry=&position=，目前主要招聘中级以上的前端和 PHP。

感兴趣的同学可以直接联系，或者找我推荐。

分类
js 技术

使用 JS 模拟元素被 click

需求来自于我厂的 QA 产品。在这个产品中，我需要在浏览器插件里模拟用的各种行为，比如：点击。

click 事件前后发生了什么

最初我觉得点击嘛，能有啥问题，就直接广播 click 事件呗。结果发现并非如此。实际上，一次 click 背后，其实有一大套的逻辑：

  1. 移动到按钮上时，会依次触发 mouseover，mouseenter 事件，前者冒泡，后者不冒泡
  2. 鼠标按下时，广播 mousedown 事件
  3. 如果此时其它元素有焦点，那么该元素会先失去焦点，并广播 blur 事件
  4. （下一节补充）
  5. 按钮获得焦点，广播 focus 事件
  6. 如果因此影响到 DOM，那么会等待 DOM 变更
  7. 如果鼠标没有离开按钮，按钮广播 mouseup 事件
  8. 最后广播 click 事件
  9. 在移动设备上，可能会有 300ms 延迟

其实（5）并不准确，每一次事件广播都是独立的 event loop ，所以上面每一步都可能产生 DOM 变化和其它次生变化，也可能导致一些操作或功能不符合预期。比如：

  1. 一个搜索框。输入后自动搜索，结果以 dropdown 形式展示在下面
  2. 点击 dropdown 里的条目可以跳转
  3. 搜索框 blur 时 dropdown 移除

此时，dropdown 里的条目可能无法点击。因为点击时，输入框先 blur，之后 dropdown 隐藏，接下来 mouseup 事件触发在别的元素上，于是不会有 click 事件。

最简单的解决方案，给 blur 事件加延迟，10ms 就够。

（关于上面的事件触发顺序，可以用这个的 codepen 尝试）

click 事件对 change 事件的影响

接下来，回到 QA 产品。

我真正踩的坑，是 change 事件没有按照预期触发。大家知道，Vue 组件通过 $emit('input') 可以更新绑定在 v-model 里的值。触发的时机一般通过侦听 DOM input 或者 change 来决定。如果 change 无法正确触发，那么 QA 产品自然而然就无法正常工作。

实际上，在上一节的 click 逻辑中，第（4）步可以展开为：

如果失去焦点的元素是 <input> 或者 <textarea>，则该元素会广播 change 事件。

模拟 click 动作的代码

最后，演示一下最终代码：

const options = {
  bubbles: true,
  cancelable: true,
  view: window,
};
let event = new MouseEvent('mousedown', options);
elem.dispatchEvent(event);
elem.focus();
event = new MouseEvent('mouseup', options);
elem.dispatchEvent(event);
elem.click();

相关链接