秀优越感 ​

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

功能 ​

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

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

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

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

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

“小爱同学，扫地”

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

“小爱同学，打开台灯”

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

“小爱同学，开始烧水”

……

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

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

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

1. 公司宣传策略不同 ​

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

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

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

来自知乎问题小程序上线后市场反应如何

尘归尘，土归土。正在回归正常。

小程序一直在强调自己线下场景的定位，奈何开发者、媒体总是不信邪，非要赌小程序会有流量红利，会给自己带来线上流量。甚至在微信明确说微信中没有入口，没有应用商店之后，仍然有一大波人围着不愿散去。

现在打脸了吧。线上流量红利真的一点没给。于是这波围观的人一哄而散，甚至还会留下一堆唱衰的评价，“你看，我就说这玩意没鸟用吧”，殊不知，正是自己的期望过高导致现在的巨大落差。

回归到小程序自己的定位来说，其实非常明确，就是线下场景。具体的微信公开课Pro上已经详细阐述过，这里就不复制了，有兴趣的自己找。

来自知乎问题微信小程序为什么不用HTML5、CSS，自己搞了个WXML、WXSS，很多框架用不了，好处一点不知道？

引子 ​

假设我们把问题稍微改一下哈：

iOS应用为什么不用HTML5、CSS，自己搞了个OC / swift / autolayout / storyboard，很多框架用不了，好处一点不知道，以前项目根本没法移植，而且我们习惯的jquery、auicss、图标等完全用不了，也没见OC / swift / autolayout / storyboard有什么好处，完全理解不了。。。

嗯。我只是改一下题目，不回答。可自行思考。

用web做小程序的可能性和限制 ​

为什么没有人问上面改过的问题，而小程序就有人问呢？只是因为小程序和web长得很像，所以就觉得要用web来做吗？那长得像的话是不是就能直接用web做呢？

答案是，大部分是可以的。比如文本、图片、输入框等等，都可以。

但是，也有一部分小程序的功能是web完全不具备的，例如扫码、获取设备信息、获取罗盘信息、等等。

此外，还有一小部分是web做起来很困难的。比如上面有人提到的地图、fixed的文本输入、视频相关、sticky定位等。

除了能力上的限制以外，还有相当一部分是来自于性能上的限制，也即虽然很多东西用web确实可以做，但是性能是很差的。

去年10月份，在我们被产品节奏逼到墙角无路可走的时候，我们在几乎没有准备的情况下，在团队中引入了Git。目前时间已经过去半年，回顾这半年的时间，基本还是运作得比较顺利。当然过程中也少不了踩坑，因此记录一些心得。

Why Git? ​

如果用一句话来说的话，我们是冲“分支”而来的。背景如下：

团队的固定版本节奏为两周一个版本，一周半的时间开发，半周时间测试发布。如果使用软件工程中的概念来说的话，这是一个比较典型的瀑布式流程，即“需求->设计->开发->测试->发布”，然后周而复始，过程中几乎没有重叠。

伴随着瀑布式的流程，代码也只有一份，“开发->改bug->发布”，周而复始。

直到去年10月，公司做了一场声势浩大的营销活动，灾难开始了：一方面需要以并不确定的研发周期支持各种运营活动（运营时间不等人，必须快速写快速发），一方面是运营活动带来大量客户，与客户相关的流程也陷入频繁修改发布的过程。此外支持各种终端需求也集中爆发，需要web侧快速跟进上线。当然，还有一个东西，就是上面瀑布流程中两周发布一次的“主版本”。当这么多版本交叠在一起时，我们发现必须要引入分支来管理研发过程。于是果断切Git。