我们的隐私正在被侵蚀。无论是住酒店，过机场安检，还是各种移动 App 的身份验证，作为用户，正在做着小白鼠，每验证一次就等于在帮助那台无形的机器。
用户永远不知道他们的数据流向了哪里，不知道哪些人在利用他们的数据做训练，当然也不知道那些机构或者公司有没有能力保护自己的隐私数据。
换句话说，我们正在充当数据电池，为母体贡献着能量。
可悲的是，无力阻止这件事情发生。
--EOF--
Recently in Review 分类
这个入口年久失修，重新梳理了一下。把 Movable Type 调试到可用状态。长久没有访问中端，对配置文件着实生疏，花了不少时间调试。发现 MT 不再开源之后，反而比 WordPress 做得更好了。好在哪里？优雅，简洁。
迄今为止，Movable Type 依然提供比 WordPress 好得多的用户体验。
优雅，真是学不来的。
--EOF--
两年前，我写过从国内 IE 6 的市场份额说开去，抱怨了一下，一切皆有可能，现在中国大陆 IE 6 市场份额终于大幅度降下来了，年底有可能降到 20% 以下。 无论如何，对前端工程师来说，这是一大好消息。
(refer)
这张图体现的其实是中国互联网跟世界的某种差距吧。遗憾的是，业内媒体似乎对这些都不太关心。
这次，360 的确做了一件好事。不管动机是什么，起码这个结果是好的。很久以前我说过一句玩笑话「内容审查、GFW、带宽差费用高、IE 6 已经成为制约中国互联网进一步发展的四大障碍」，现在 IE 6 的制约即将消除，接下来会是什么呢?
我不知道。你说呢?
--EOF--
微信公众平台堪称是本年度国内互联网产品领域国内最大的创新，有朋友问我怎么看微信公众平台，我其实没怎么「看」 ，因为我一直在尝试学习利用微信公众平台，在做运营上的实践。我个人运营了「小道消息」，基本上是每天一篇文章，和朋友们交流一下我的一些观点；丁香园团队前一段时间也利用微信的开放消息接口做了「用药助手」的即时信息查询的功能，目前来看还只是具备一定的功能，改进的地方还有许多。
如果非要我说微信公众平台是怎么回事，那么可能一句话就够了「对话即服务 对话即搜索」
对话即服务
这里说的「对话」，是指用户和微信公众帐户的交互。
对话即服务，或许是微信公众平台的初衷。通过公众平台帐户让第三方服务直接在这里完成，Web 端和移动端有效的结合起来。最常见的是客服服务，微信公众平台本身就是个绝佳的客服反馈系统，用户遇到问题，发个消息过来，服务人员在 Web 后台看到，立刻可以跟进处理，信息是异步的，直达的，经济而有效。随着公众帐户越来越多，可以看到能够完成的第三方服务正在增加。
从信息的到达率上来看，微信公众帐户群发到每个真实的用户. 到达率和用户群细分远比 App Push 精准. 从 Email 到 SMS 到 App Push，再到微信，成本越来越低。
对话即搜索
什么叫「对话即搜索」呢? 举个例子来说，你关注了「用药助手」，然后发送「药品 阿司匹林」过去，用药助手给你返回的消息就是关于阿司匹林的药品说明，这就是一个搜索服务，同样，对于「大众点评」和「微信路况」这样的公众帐户来说，用户发送当前的地理位置过去，返回的消息则是周边的饮食和路况信息，这已经是不折不扣的搜索服务了。我相信腾讯自己的搜索用不了多久即可进入，或许这帮家伙还没意识到，不用离开当前应用即可完成搜索服务，这是以前所有非搜索类 App 无法完成的问题。
从这个角度来说，微信一定会蚕食搜索引擎的市场。如果搜索引擎愿意接入微信，那是另外一回事了。问题是，有几家搜索引擎愿意寄人篱下呢?
搜索本质上也是服务。天气、旅游、购物，股票... 皆可扩展。
微信的一些弱点：信息的「纵深」远远不如微博。相比微博而言，多数都是一些「浅」 信息；信息缺乏可挖掘的能力，比如，天然的无法搜索内容，甚至自己在朋友圈分享的信息都无法搜索，无法回溯。微信公众平台后台数据目前还无法进行量化分析，这个或许是时间问题，相信微信团队能够解决。另外，微信公众平台的数据，可查询性还不够，有必要增加数据查询服务。
有人问，在微信上创业怎么样? 微信是个平台，是个媒介，通过这个去做你做的事情，如果能给用户带来价值，为什么不可以? 前景如何? 但做好事，莫问前程。当你为这些事情纠结的时候有人已经赚的盆满钵满了。
有些人绝对高估了微信，但也有另一些人低估了微信。
「对话即服务 对话即搜索」，请记住这句话。
--EOF--
你一定听过那个小工识别生产线上的空肥皂盒的故事。
让我简明扼要的将这个故事复述一遍：某大型日化公司引入了一条国外肥皂生产线，这条生产线将肥皂从原材料加入直到包装箱自动完成。不过产品线有瑕疵，个别肥皂盒是空的，这家公司联系厂商后被告知这是设计上的缺陷，无法避免。于是老板要求工程师们解决这个问题，以数名博士为核心形成一个技术攻关团队，耗费大笔资金之后，终于宣告解决。解决的办法是在生产线上安装一套 X 光机进行扫描识别。在另一家私人企业，老板让新来的小工解决问题，小工所用的办法是，找来一台电风扇放在生产线旁边...不知道这个故事是编造出来的还是真的发生过。
在现实中，类似的没有技术含量的解决方案，但是又奏效的确实很多。
国内某个厂商曾经发布过一款日常安排的移动 App , 这个产品的独到之处是能够把语言转化为日程，准确率相当高，曾经一度令人惊讶，不过后来有人证实其真正的做法是：远端用人接听这些语音，然后手工输入进去。所以，准确率不成问题。最起码要超过苹果的 Siri 系统。
又比如某个商务社交应用的名片识别应用，也曾经有网友证实产品发布的初期时候技术还达不到要求，所以有的时候后台是用人工识别。这个产品在初期果然赢得了不少用户的信赖。
再比如验证码(CAPTCHA), 每个上网的人都见过这个东西，我们知道世界上有一些计算机科学家在研究验证码的自动破解工作，而且，屡屡传出各种新进展。不过，我们也不要忘了，世界上还有一个第三世界国家的网民热衷从事的工作叫做「打码」，人工识别各种验证字，效率也很好。据说，为了提升协作效率，有些专门打码的网站已经对外提供程序接口了，要说没有技术含量，他们肯定不承认。
这些有点遥远的例子说完之后，我要说一下我的一位朋友亲口对我说的经历。这位朋友的创业项目是做个电商导购网站，本来想找几个人在算法上下功夫，做商品「智能」推荐后来算了一本帐，成本上抗不住，因为这样的技术人才工资都不低，而且，还要投入一定的服务器，一定时间后才能看到效果。他的解决办法简单直接：找 5 个编辑人员，直接用人工推荐，人力成本极低；效果？当然直接超过了「人工智能」。我问他一旦数据量大了怎么办？他的回答很简单，人的效率还能提升。比算法提升的幅度还大。
这是个复杂的世界。技术含量当然重要，但有的时候在低成本下有效解决问题更重要。
敬请注意: 本文已经发布在《创业家》杂志.
--EOF--
新浪微博前段时间做了一个反人类的功能「智能排序」，验证了我以前喜欢说的一句话: 智能和弱智只有一步之遥。当然这个所谓的智能也是表现的绝对弱智，在几乎遭受了绝大多数用户的声讨之后，现在终于消停了，已经不是默认给用户设置智能排序了。
不过最近又有点故态重萌。以前曾公开私下里都夸过好几次新浪微博 WAP 版的团队，我也是少数用智能手机的... WAP 版本的重度用户，WAP 设计的够简朴，必备的功能都有，还没有那么多干扰。好景不长，WAP 版本微博评论现在这是按照什么顺序了? 怎么如此怪异?
还以为这个团队有点发昏了? 问了一下，有人告诉我现在评论顺序是「会员评论优先」(然后又有人告诉我，是所有客户端现在都 「会员评论优先」了)。 我想问，做这个决定的人，你长了一个猪脑袋么? 且不说这给用户带来多大的困扰，会员用户增加曝光率就一定能让更多用户购买会员资格么? 你以为你们是 CCTV 啊?
新浪为了赚钱，着急乱出王八拳情有可原，无独有偶，想起百度空间这个产品，做搜索起家的百度，用户的空间居然没有搜索功能，要查找一个用户写过的内容，必须要想点别的「技巧」。更为搞笑的是，前一段时间百度空间升级，估计是怕别人不知道他们终于升级得更为难用了，居然默认把用户的 RSS 直接插入一个产品升级通知，一打开 Google Reader，发现订阅的百度空间的内容齐刷刷的是这个产品通知......
建议新浪百度阿里腾讯这种大一点的互联网公司定期测试一下管理人员以及产品经理的智商，低于平均线的早点开除掉。对中国互联网有益，对人类也有益。另外，也测试一下管理人员以及产品经理的常识水平，低于平均线的立刻开掉。
有的时候想，为什么豆瓣的产品经常被人称道呢? 或许豆瓣团队也不都是聪明人，但他们能用正常人平常人的思维做事情，用常识做产品，而不是用「榨汁机」、「提款机」或「升职机」的脑袋做产品。
我们常说做产品要有点敬畏心，什么是敬畏心? 也就是说别没事卖弄你的智商，你一卖弄智商就暴露了你的智商；你越想着做点智能的东西就越显得产品弱智。
--EOF--
今天业界热议的事情是Facebook创始人兼CEO马克·扎克伯格在接受采访的时候承认「专注在 HTML 5上面是他有史以来犯过的最大的错误。」然后，透露出来的数据是：用户浏览的 Feed 信息流是之前的 2 倍。
Facebook 最初使用 HTML 5 的主要原因是什么呢？一次开发，跨平台发布肯定是其中考虑的一个因素，当然，开发上可以做到快速迭代，这和 Facebook 的工程文化也是相符的。不过，这样实际上是节约了开发成本，获得了开发上的「速度」，这样做也牺牲了用户的体验上的「速度」，牺牲了「性能」。
为什么 Facebook 过度在移动上压注 HTML 5 是不对的？最大可能的原因或许就是「性能」的问题，没有更好的速度就没有更好的用户体验，而用户体验一直是扎克伯格最看重的东西。
扎克伯格从 Facebook 创建之初就认识到，对 Facebook 这样的的网络服务而言，「性能表现就是关键。假如向用户传送新页面的速度开始减缓，那就是致命的一击。」从技术的角度看，Facebook 一向在网站优化上不遗余力，无论是 BigPipe 还是 HipHop for PHP， 这些不遗余力的优化实践以及技术创新为 Facebook 带来了绝佳的用户体验，而移动端押注 HTML 5 则恰恰是无形中背离了 Facebook 的这一准则。
iOS 原生应用发布之后，浏览信息是原来的两倍意味着什么？用户会在意你用 HTML 5 开发还是用的本地原生应用？绝大多数用户都不在乎这个，甚至都不知道，用户更关心的是「应用的速度」，App 是否足够快? 是否可以更流畅的阅读信息，没有人愿意在手机上等待某个应用慢吞吞的打开，就这么简单。
接下来面对 Facebook 的挑战是能否像在 Web 产品上进行的那些最佳实践那样也在移动产品上建立起更有效的研发机制，毕竟这是另外一个战场，一个互联网巨头在移动领域是否还是绝对的统治者? 没有人能知道。
事后诸葛亮一样来评价这个事情的对错本身并不重要，重要的是，我们是否可以从中学到某些教训?
--EOF--
对 HTML 5 来说，谈不上是什么「打击」，或许是好事情也说不定，让更多人认识 HTML 5 的优点和缺点，而不是一窝蜂的冲上去。
我在去年这个时间曾经说过这样一句话「我的两个固执的观点：1 HTML 5 不是移动开发的救星，至少现在不是；2 因为有 1 , 所以类似 PhoneGap 之类的解决方案还不靠谱，没有银弹。还需要再等 18 个月再看。」
现在看起来，还要再等 18 个月了。
本文首发: 福布斯中文网 (URL)。
某公司开发人员对该公司 DBA 不愿意从 Oracle 转到 MySQL 评价说「读点源代码会死吗?」
我看到该信息后评论到「能读源代码有个屁用?」 这有些偏激，读代码当然有用，不过读懂代码只是锦上添花的事儿，并不代表能管理好数据库。
就我对 DBA 群体的了解，不愿技术转型的原因典型可能在于:
1. 不少 DBA 的「不愿意」其实是对对行政意志的抗拒. 一个大型团队里面，的确要经常面对并且服从各种决策，不过，如果技术决策无视具体环境，违背了客观规律，完全是出于一两个人的好恶的话，那么对于整个团队来说，并不是好事情。理性的人一定会提前发出自己的质疑或是忧虑。
2. 也有是出于对 MySQL 的「不信任」。这几年 MySQL 有了很大进步，开源社区对 MySQL 的改进也相当好，但是，缺陷还是很明显的，比如，对于联机维护的支持能力至今还是不够的，尤其是对于需要支撑密集并发事务的网络应用来说，达不到工业强度。「可靠性」有的时候比「好用」或是「便宜」什么的更为重要。或许有人不信，拿 Facebook 来反驳，人家不是搞定了么？没错，Facebook 搞定了，但是记住，Facebook 的产品业务类型跟贵公司业务是一样的吗? 如果 DB 本身无能为力，你能从架构角度保证不影响业务呢? 另外，去看看 Google 为什么要开发 F1。
3. 对于某种「不确定」性的恐惧。对于一个自己暂时无法掌控的事物有排斥感，这也可能是人的某种自我保护的天性，超出了自己的「技术舒适区」，担心自己被淘汰或是价值被稀释。如果遇到持这种想法的人，倒是可以对他激励一下，「不都是数据库么?」小马过河，试试深浅再说。
4. 或许还有其他原因，不一一列举。
不过，不管什么原因，「读点源代码会死吗?」这种话都类似于体委主任要刘翔顺便去跑个百米比赛一样，不都是田径短跑么(原理都没变，不都是数据库么)？跑快点就行了嘛 ... 读懂 MySQL 代码的人一堆一堆的，能给 MySQL 提交 Patch 的开发者估计在各大公司也不在少数，但是如果几十台上百台服务器崩溃掉，整个技术团队都看着你的时候，你能气定神闲的分析代码然后写个管用的补丁出来么? 这个时候，可没有人会提 「 MySQL 给公司解决了多少成本」，管理者会暂时忘了那事儿，他这个时候关心的是「可用性」了。
作 DBA 和做 Coding 是泾渭分明的两种思维模式，并无所谓高下之分，会写代码的没必要看不起做运维的，掌控数据的也别看不起做功能实现的，都是看人担柴不费力，如果你是真的去经历一番，就会得出另一种结论。
PS. 这个话题还会引出另外值得讨论的话题来，比如「技术决策的是与非」，今天日子特殊，等我有空再写一下。
--EOF--
