分类
电子产品

Ubuntu 20.04 配置 TP-WDN5200H 无线网卡

前情提要：朋友赞助了 AMD 2950x + 技嘉 x399 MEG Creation，我配上其它组件，装了台新电脑。接下来把老电脑收拾一下，装上 Ubuntu 20.04，打算补齐 x86 64 Linux 平台。

结果卡在无线网卡配置上，Ubuntu 无法识别和使用。我的无线网卡是 TP-Link 的 WDN5200H 免驱 USB 网卡，我直接用型号搜索，很容易就找到介绍安装教程。

原来这个网卡同时集成了一块小 U 盘，里面是驱动程序，方便没有网络的人安装。但是在 Ubuntu 下，会优先把它识别成 U 盘（但是我也没找到盘符），所以无线网络不工作。解决方案就是先安装驱动，然后用 usb_modeswitch 切换工作模式，然后系统就会把它识别成无线网卡，然后就可以了。

但在我这里，这套操作行不通，切换设备的时候，上面都一样，但最后会报错：

Use interface number 0
 with class 255
Error: can't use storage command in MessageContent with interface 0; interface class is 255, expected 8. Abort.

我用上面的错误信息作为关键词搜索，只能找到各种关于 huawei modem 的讨论，解决不了问题。折腾很久，我突然注意到，我的网卡 ID 似乎和教程里不太一样，我的是 obda:c811，而教程里是 obda:1a2b（分号前是设备id，分号后是产品id），是不是这个原因呢？我以 0bda:c811 作为关键词，很快找到这个答案。

原来核心原因在于原先的驱动是基于 4.x 内核的，从 19.04 开始，Ubuntu 内核已经升级到 5.x，所以要用新驱动。所以我按照帖子里的指示，安装了新驱动。一番折腾之后，还是不行……

眼看周末过去，没时间继续折腾了，我只有到京东下单了一款 m2 接口的 Intel AX200 无线网卡（含蓝牙）——据说 Intel 网卡都是免驱的，而且 m2 接口肯定没有集成 U 盘这种幺蛾子。

周一，拿到新网卡，插上。果然，Intel 网卡就是免驱，工作正常；但是，我没买天线，而这个鬼网卡没有天线是绝对不能工作的（客服告诉我可以试试，不行再买天线，我……），于是我只好再下单了一套天线。然后我无意打开 Wi-Fi 一看，WTF，这是啥，Rtl8821CU？不就是我的 TP-WDN5200H 么？原来我昨天其实就弄好了，只是没有重启，没有生效……

至此，问题解决。

继续阅读 “Ubuntu 20.04 配置 TP-WDN5200H 无线网卡”
分类
wp

Jetpack 的流量统计好像被墙了

从5月23日开始，从 WP 后台的 Jetpack 统计看起来，我的博客访问量大跌。

一开始我以为是 CDN 的问题，拉着同事研究了半天，没有找到证据。然后检查了 DNS 解析统计，似乎也正常。最后想起来看 GA。从 GA 的数据来看，似乎访问量并没有什么变化。那么只好猜测是 Jetpack 的统计出问题，很多访问没有统计到。

不过我觉得多半是误伤，毕竟 Jetpack 作为 WordPress 的产品，很容易被“误伤”，而且在国内也没多少人用，不必像 GA 这样还要留点余地。可惜以后我没法很容易的看到统计数据了。

分类
npm

使用 GitHub Registry 托管私有 NPM 源

我厂有不少私有仓库，都是日常开发中提炼出来的，在几个项目中共享，比如 UI、Vuex、网络请求（axios 封装）等。以前的主要形式是使用 npm 安装 GitHub 仓库，即

npm i openresty/some-repo

这样 npm 会自动去 GitHub 查找对应的仓库，然后 clone 下来完成安装。项目中的 .npmignore 文件也会正常生效，安装后的目录会忽略不需要的文件。这样做的好处就是简单，只要仓库存在，安装依赖的系统有足够的权限（比如 ssh key），就能顺利安装。在过去的三年时间里，我们一直都这样做。

但是这样会有一些问题：

  1. package-lock.json 里记录的是 commit hash，只看这个值无法判断版本，npm 也没法使用版本号解决依赖冲突的问题。换言之，比如 A 仓库需要 C 仓库的 1 版本，B 仓库需要 C 仓库的 2 版本，那么就只能同时安装两个版本，因为 npm 无法判断两个版本是否兼容。
  2. 安装的时候要走 git clone，下载量很大，速度很慢，经常被同事吐槽。也会影响 CI 的效率。
  3. git 仓库里要提交编译后的代码，一方面浪费时间和空间，另一方面大量编译后的代码也影响 code review

所以，考虑之后决定改用 GitHub Registry。GitHub Registry 是 GitHub 提供的私有源，感兴趣的同学可以访问这个页面了解详情。这个服务需要收费，不过我厂本来就是 Team 用户，额度比较富裕，所以并没有阻力。

经过一段时间的摸索，终于搞成了，下面简单说一下做法。

对依赖项目

修改 package.json，把项目名称改成 @openresty/some-repo，即“@公司名/仓库名”。然后增加 publishConfig 字段，设置源为 GitHub registry：

{
  "publishConfig": {
    "registry": "https://npm.pkg.github.com/"
  },
}

接下来，正常使用 npm publish 发布依赖即可。不过在发布之前，最好使用 .npmignore 忽略掉开发时的源文件和配置文件，一方面这些文件对于其它项目的开发没有价值，另一方面无论是存储还是下载消耗流量，都要收费，能省则省嘛。

对业务项目

因为这些依赖仓库都是私有项目，所以我们先得解决身份认证的问题。GitHub 提供了 Personal access tokens 方式，生成 token 后，添加到 ~/.npmrc 文件即可：

//npm.pkg.github.com/:_authToken=<TOKEN>

接下来，在业务项目中，添加 .npmrc 文件，指名依赖源：

registry=https://registry.npmjs.org/
@openresty:registry=https://npm.pkg.github.com

这段配置分两部分：其它域的依赖，直接从 npm 的源下载；@openresty 域下的依赖，从 GitHub Registry 下载。

最后，正常使用 npm i @openresty/some-repo 安装依赖即可。

最后的最后附上修改前后的效果对比，可以看出，改造后效果明显：

国内修改前real 0m39.543s
user 0m17.768s
sys 0m3.944s		阿里云
修改后real 0m16.450s
user 0m15.204s
sys 0m3.380s		阿里云
国外修改前real 0m49.350s
user 0m22.352s
sys 0m4.144s		阿里云
修改后real 0m30.807s
user 0m15.780s
sys 0m3.936s		阿里云
分类
生活

一些近况

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 发布！”