一看这标题就是不准备好好写的。对的，最近特别忙，只能简单记录一下折腾的东西。

Nginx开启server push

1. 升级nginx到1.13.9或以上版本（注意1.13.6修改http/2的实现，与一些旧版本客户端不兼容，比如旧版Android okhttp）
2. nginx配置中加上http2_push_preload on，表示使用preload header来作为server push标识

Node开启server push

Node处理文件内容时加上preload header即可，例如：

1

link: </main.37d69167.css>; as=style; rel=preload, </main.f06ad8b3.css>; as=style; rel=preload

此处比较科学的做法应该是使用一个中间件，在返回内容之前，根据要返回的HTML内容来处理preload header。

因为我主要处理静态html文件，又用的koa，所以将主要逻辑放在了koa-static的setHeaders函数中。setHeaders主要用于在返回静态文件前设置自定义的header，刚好和server push的场景相符。

2017年开始我做了一款资讯App，叫土葱日报，主要用来抓取科技新闻。目前只有Android版本，在Google Play和应用宝市场有下载。

经过一年的运行，积累了上十万条新闻数据，并从中分析出了近百万关键词数据。在此对结论做一个展示。

2017于个人来说，是非常重要的一年，这一年经历了很多此前从来没有接触过的事情。甚至某一些事情可能会成为未来一些事情开始的基础。

工作

这一年工作状态总体不算太好。一年的安全域工作着实无趣，中间也就少不了自己打打酱油。

离开了产品团队，也觉得并不是很踏实。花了半年时间介入新股认购重构的需求，最后结果也并不是太好。

年底回到产品团队，却发现物是人非。产品换了一大波人来和开发对接，一切都不太对劲。[***]

前端方面，可以说是覆灭。业务小组分开后，前端组的概念更加虚无缥缈，虽然要有预期，但是事情比想象更坏。[***]各组间隔阂进一步加深，导致前端间交流也较少，价值进一步削弱。

客观说，我也没有竭尽全力去推动前端方面的事情。但是话说回来，在一个氛围诡异的环境里，把自己做成一个歇斯底里的形象，这个团队也未必能忍得下。

年底接到了IT方面的工作。在产品和前端都不如意的情况下，反而希望更早介入这一块的工作。前端方面仍然有一些计划继续去推进，但是早晚需要放手。

秀优越感

小米AI音箱299元，但是现在还买不到。要不选择等半年，要不选择淘宝加价一两百。然而令人惊喜的是，参加前端体验大会后，主办方直接送了一个作为礼品。于是我能抢先体验到这一款产品。秀优越感完毕。

功能

外形和基本功能就不详细介绍了，网上的评测文章挺多了。

我用得比较多的功能主要还是点歌，叫一声小爱同学，然后就可以点歌。而且还可以沿同一歌手的歌单一直放下去。至于音效嘛，作为一款身型小巧的音箱，还是有点超出预期的。

此外，家里有一个智能插座是连接饮水机的，还有小米盒子、小米扫地机器人、小米台灯等设备，都可以比较好地联动：

“小爱同学，我要看琅玡榜”

“小爱同学，电视声音大一点”

“小爱同学，扫地”

“小爱同学，扫地机器人还有多少电”

“小爱同学，打开台灯”

“小爱同学，台灯亮度高一点”

“小爱同学，开始烧水”

……

总体来说，小爱同学对声音的响应灵敏度还不错，在房间里也能很自然地交互，对智能家居的打通也做得非常好，用起来真的非常方便。

前端体验大会于我来说并非一个新鲜事物了。即便是担任讲师嘉宾这件事情，也不是第一次，因此也并没有什么太激动的地方。参会完之后本来想着，我本不是一个张扬的人，就让它归于尘土吧。但细细回想起来，本次大会带给我的，还是有挺多前所未有的感觉，因此从一个不起眼的角度来记录一下，也挺好。

评审很煎熬

本次大会公司有给予赞助，考虑到品牌露出更自然，我也就联系了一下主办方，申请了一个演讲主题。虽然明知道近段时间忙得跟狗一样，但还是对自己恶吼了一句“你他妈不是就喜欢被事情压着跑么？”

主题还没准备完，就要进入评审阶段，于是两次翘班出去咖啡馆跟主办方过PPT。不得不说，翘班去咖啡馆的感觉还是挺爽的。但是评审PPT就没那么爽了。

熟悉的人都知道，彪叔是一个三句话就要上升到人生哲学高度的人，因此听他把PPT的评审意见讲完并不是一件很轻松的事情。虽然自认为在多年的会议中已经练就了非常好的理解和归纳能力，但是要完全理会彪叔的意见还是很有挑战性。因此两次评审其实多少都有点煎熬，总是为自己的PPT感觉到有点焦虑，担心是否和主办方的主题契合。

AMP 全称 Accelerated Mobile Pages ，是由 Google 提出的一种移动端页面的规范。相比普通 HTML 而言，最大的特点是对页面中可用元素进行了严格的限制，以确保高性能。此外，Google 还对 AMP 页面提供了高速缓存，如果从 Google 搜索中打开 AMP 页面，速度非常快，几乎是秒开。

前几天将我的博客完全迁移到了 AMP，在此也做一个记录。

作为单独页面存在的 AMP

在很长一段时间内，我都以为 AMP 只适用于移动端某些特殊场景，至少文章页应该是适用的，于是自然而然就想到了博客应该是非常适合 AMP 的场景。因为我的博客使用的是著名的静态博客程序 Hexo，所以也就很自然地想到了，会不会有人已经写好了 Hexo 的 AMP 插件？搜了一下，果然没有失望，找到了一个名为 hexo-generator-amp的插件。

这个插件不会修改已有的文章页面，而是会为文章页面再生成一个合法的 AMP 页面。这两个页面可以互相引用，表示一个是普通页面，一个是 AMP 页面。这种方式也是 Google 搜索等平台认可的 AMP 生成方式。

按照插件的文档，使用起来还是比较简单的，具体的方式就不写了，直接参考文档即可。有几个值得注意的点：

1. 一定要修改文章页的模板，添加link[rel=amphtml]链接，要不然搜索无法找到 AMP 页面
2. AMP 页面会自动在head中添加canonical链接回原有的文章页

这个插件支持自己修改模板。鉴于我对它的样式并不是很满意，没有修改的欲望，于是也就没有去改它。如果你需要修改 AMP 模板的话，可以在网址中添加#development=1，然后在控制台中查看 AMP 验证结果。

上上周五（18号）支付宝小程序在经历了大半年的传闻之后，终于揭开了神秘面纱，开始公测。和之前传闻的一样，支付宝小程序的核心能力的 API 与微信小程序几乎完全一样。

至此，支付宝勉强算挤进“小程序俱乐部”，而小程序也不再是微信小程序的代名词。

小程序俱乐部

在之前的推文【闲聊】大前端揭秘中，有表述过 native 终端和 web 端融合的趋势。大体上来看，主要的方向包括 native 动态化（React-Native 为代表）、web native 化（以 AMP、PWA 为代表）以及“小程序”。

长期以来，在移动端被诟病的有两件事情：

• web 不管是能力、性能还是体验都太差
• native 体积大，发版更新困难

在大前端融合的大背景下，实现一种既可以充分利用 web 快速轻量的特性，又能够达成 native 的性能和体验的技术方案可谓是众望所归。正是在这种愿景下，诞生了小程序。

从这个角度来看的话，小程序的诞生可能还不能简单归于微信的高瞻远瞩，而更可能是行业发展到了一个路口，大家都发现要走一些新的路了，只是微信提前选定了小程序这样一条路，然后花了一年半的时间把它一脚一脚踩出来。

那么支付宝要做小程序也算是水到渠成了。既有行业大背景，又有前言的领路人。总之小程序俱乐部现在不止是微信一个人玩了。

本文来自知乎问题为啥没人关心腾讯的前端技术栈？

业界对阿里前端的关注度的确是比腾讯的要高好多。个人以为主要原因如下：

1. 公司宣传策略不同

几年前参加过阿里的校招的宣讲会，令我十分意外的是，一场校招宣讲会，居然让章文嵩博士去做了大篇幅的演讲。（不了解其人的可自行搜索。）整场听下来，会传达一个非常重要的基调，就是“我们的技术非常好，这里非常多的牛人”。后来也有幸去参加过阿里的一些培训活动（类似百淘/百支之类的），活动的主线也是让我们去采访阿里各行各业的牛人（当时叫“牛P”）。

同年，也参加了腾讯的校招宣讲会，腾讯的宣讲会有非常大的篇幅在讲企业文化和公司福利待遇。公司的愿景是什么，文化氛围是什么，薪酬组成如何，奖金如何，班车夜宵如何等等。

两家公司都非常有吸引力，但是策略是完全不同的。校招当然只是一个窗口，但是反映出两家公司对外宣传的一些策略确实是非常不一样的。包括现在，很多人对阿里的印象都是技术氛围好，对腾讯的印象则是文化和福利待遇好。这个印象的不同并不是天然形成的，而是公司有意营造的结果。

你是否觉得每天碌碌无为？你是否每时每刻都在切换桌面上的程序，但是时常忘记自己要干嘛？你是否在每天下班的时候根本回想不起来这过去的一天到底做了什么？

如果是的话，请马上拿起电话订购吧，只要 998，只要 998……

对不起，跑错片场了。如果你也有以上的困惑，那么请继续往下读。

简介

今天要推荐的这款软件是一个 Mac App，名叫 Timing。但是因为 Timing 这个词实在是太通用了，所以我们用 Timing App 来指代。

我在几年前用过这个软件，当时给我留下了非常深的印象，最近它又更新了一个大版本，非常好用，所以介绍给大家。