Review 类别下的文章

再见, IE 6

两年前,我写过从国内 IE 6 的市场份额说开去,抱怨了一下,一切皆有可能,现在中国大陆 IE 6 市场份额终于大幅度降下来了,年底有可能降到 20% 以下。 无论如何,对前端工程师来说,这是一大好消息。

IE6.png
(refer)

这张图体现的其实是中国互联网跟世界的某种差距吧。遗憾的是,业内媒体似乎对这些都不太关心。

这次,360 的确做了一件好事。不管动机是什么,起码这个结果是好的。很久以前我说过一句玩笑话「内容审查、GFW、带宽差费用高、IE 6 已经成为制约中国互联网进一步发展的四大障碍」,现在 IE 6 的制约即将消除,接下来会是什么呢?

我不知道。你说呢?

--EOF--

微信公众平台堪称是本年度国内互联网产品领域国内最大的创新,有朋友问我怎么看微信公众平台,我其实没怎么「看」 ,因为我一直在尝试学习利用微信公众平台,在做运营上的实践。我个人运营了「小道消息」,基本上是每天一篇文章,和朋友们交流一下我的一些观点;丁香园团队前一段时间也利用微信的开放消息接口做了「用药助手」的即时信息查询的功能,目前来看还只是具备一定的功能,改进的地方还有许多。

如果非要我说微信公众平台是怎么回事,那么可能一句话就够了「对话即服务 对话即搜索

对话即服务

这里说的「对话」,是指用户和微信公众帐户的交互。

对话即服务,或许是微信公众平台的初衷。通过公众平台帐户让第三方服务直接在这里完成,Web 端和移动端有效的结合起来。最常见的是客服服务,微信公众平台本身就是个绝佳的客服反馈系统,用户遇到问题,发个消息过来,服务人员在 Web 后台看到,立刻可以跟进处理,信息是异步的,直达的,经济而有效。随着公众帐户越来越多,可以看到能够完成的第三方服务正在增加。

从信息的到达率上来看,微信公众帐户群发到每个真实的用户. 到达率和用户群细分远比 App Push 精准. 从 Email 到 SMS 到 App Push,再到微信,成本越来越低。

对话即搜索

什么叫「对话即搜索」呢? 举个例子来说,你关注了「用药助手」,然后发送「药品 阿司匹林」过去,用药助手给你返回的消息就是关于阿司匹林的药品说明,这就是一个搜索服务,同样,对于「大众点评」和「微信路况」这样的公众帐户来说,用户发送当前的地理位置过去,返回的消息则是周边的饮食和路况信息,这已经是不折不扣的搜索服务了。我相信腾讯自己的搜索用不了多久即可进入,或许这帮家伙还没意识到,不用离开当前应用即可完成搜索服务,这是以前所有非搜索类 App 无法完成的问题。

DrugsApp.jpg

从这个角度来说,微信一定会蚕食搜索引擎的市场。如果搜索引擎愿意接入微信,那是另外一回事了。问题是,有几家搜索引擎愿意寄人篱下呢?

搜索本质上也是服务。天气、旅游、购物,股票... 皆可扩展。

微信的一些弱点:信息的「纵深」远远不如微博。相比微博而言,多数都是一些「浅」信息;信息缺乏可挖掘的能力,比如,天然的无法搜索内容,甚至自己在朋友圈分享的信息都无法搜索,无法回溯。微信公众平台后台数据目前还无法进行量化分析,这个或许是时间问题,相信微信团队能够解决。另外,微信公众平台的数据,可查询性还不够,有必要增加数据查询服务。

有人问,在微信上创业怎么样? 微信是个平台,是个媒介,通过这个去做你做的事情,如果能给用户带来价值,为什么不可以? 前景如何? 但做好事,莫问前程。当你为这些事情纠结的时候有人已经赚的盆满钵满了。

有些人绝对高估了微信,但也有另一些人低估了微信。

「对话即服务 对话即搜索」,请记住这句话。

--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--

几乎每天都能看到有人在谈论大数据,让人好生厌烦。什么是大数据(Big Data) ? 简单一点可以理解为超出传统数据管理工具处理能力的大规模、复杂的数据集合(1)。判断是否数据大数据的范畴,要从三个维度来衡量:数据量(Volume)、处理速度( Velocity)以及数据种类(Variety)。

大数据(Big Data) 是 2012 年信息技术领域最时髦的词汇。当然,跟所有曾经的时髦技术热词一样,最后可能是一场骗局。为什么?

大数据是个相对的概念,新瓶装旧酒

有些人所说的大数据处理方式,不过是在既有的方案上包装了一下,新瓶装旧酒,只为赶时髦。今天的大数据可能到了明天算不上大数据。过去我们也曾经对「海量数据」望而生畏。但海量数据时代并没有给多少企业带来革命性的变化,在 MapReduce 以及 Hadoop 出现之前,没有多少企业能够轻松的对数据进行大规模并行计算(奇怪的是,那时候没有多少人提大数据)。而 NoSQL 的出现也为处理数据的方式带来了更多可能性。我们突然发现,处理数据能力已经悄然增强。

大数据是机会,但不是所有人的机会

大数据的商业前景被过分夸大了。到目前来看,只有为数不多的企业真正拥有大数据,而且这些数据的管理、处理、分析并没有带来所谓空前大的挑战。因为新的工具、新的计算方式已经已经具备处理这些数据的能力。

大数据是机会,但只是少数人的机会,更多是巨头们的商业障眼法,比如 IBM 、Oracle、微软,他们提倡甚至夸大大数据的目的还是为了向你兜售他们的工具,兜售他们的解决方案,确切的说,从你身上赚钱。更有甚者,居然是向你兜售硬件,这不完全是扯淡么? 大硬件还差不多。

中小型公司应该绕道走,别唯大佬们马首是瞻,别总去凑热闹。你所需要的东西,通过开源社区就可以获取到,参加各种大佬们口沫横飞的会议还不如和工程师聊聊可以运用什么工具来具体操练一下。「适用」好比什么都重要。创业公司也应该绕着「大数据」走,这未必是个好方向。

大数据的确会有价值,但没有那么大

必须要承认从某些大数据中会挖掘出新的价值,但这个价值只是附加价值,没有理由去夸大他,更没有理由去无端的想象。你可以说这篇沙漠可能有金子,但并不是说沙漠中一定就能挖掘出金子。

从现在业界一些公司拿出来的所谓的大数据应用实例来看,依然只是在利用传统意义上的数据价值,只是巧妙地把这笔帐记在了大数据上而已。一个电子商务网站说「什么地方的人买东西最疯狂」或是「什么型号手机最好卖」,这会是大数据分析的结果,完全是扯淡嘛。难道数据仓库系统分析出来的结果和这个大数据出来的结果会有不同么?

不算结束的结束语

大数据不会是什么「商业模式的变革」,重视大数据,但没必要抱着大数据的大腿,尤其是在业界对于「数据」还不够重视的时候,就更别说大数据了。相信随着时间的推移,大数据这个词会和信息爆炸、网格计算、云计算等逐渐被淡忘,当然,到时候可能出现新的时髦词汇了。

没有大数据,只有数据;没有蓝海,只有大海;没有先知,只有忽悠。

--EOF--

读杂志看到篇文章谈到新浪微博的商业化问题,目前大约有三万付费会员用户,每个月费用10元。恰好我本人就是付费会员,在用了一段时间之后,作为新浪微博的重度用户,真的感觉这个会员服务有点鸡肋。除了可以关注更多人之外,没有什么显而易见的卖点。

看完那篇文章之后我最大的疑问是:新浪这群愚蠢的家伙,为什么还不对企业微博帐户收费? 当然就别问为什么不学 Facebook 做广告了。

我之所以问为什么不对企业微博收费,是因为就 @丁香园 这样的公司帐户来说,作为用户方,我们更愿意付费得到更好的服务,因为我们通过新浪微博得到「收益」,当然还想把这个「收益」放大。那么,哪些是更好的服务? 企业需要获得更多目标用户的关注、更多的品牌曝光、更多的流量转化、更精准的数据统计。微博是个很好的载体,为了这几点,企业会愿意付费,而且投入产出是明摆着的事情。这不是一厢情愿。

按照微博披露的数据,现在有 13 万企业帐号,预计年底发展到 100 万个,如果能将其中的 10% 转化为付费用户,每个用户付费 100-1000 每个月的话,一年差不多可以带来 1.2 ~ 12 个亿的收入。当然,付费用户或许达不到 10% ,但是也可提供更多的定制化服务,进而提高服务费用。而且,这个几乎是没有什么销售成本的,技术上的成本也不高。重要的是,企业用户付费意愿更为强烈,只要有投出产出成正比,支付更高的费用当然顺理成章。其实哪怕有 10000 个企业付费用户,运营得力的话,也会带来惊人的收益。

或许有人说,一对企业帐号收费,那么他们宁愿用个人帐户怎么办? 是会有企业帐户宁愿用个人帐户,但是不也有很多企业现在就在购买各种价格不菲的「微博营销」的服务么?在自己的平台上眼看着各种「营销」在赚钱而自己无所作为,这是新浪最愚蠢的地方。新浪微博自认为是媒体,而且绞尽脑汁想赚广告的钱,但是又眼睁睁看着广告的利润、流量的利润被各家「微博营销商」拿走。难道还不够讽刺么?

新浪应该也想过通过企业帐户收费,也有可能已经处于分析到瘫痪(Analysis Paralysis)的境地了,也或许,依旧是卖 Banner 广告的基因。到底怎么办? 很简单,走两步,走两步试试看。

--待续--

更新:经过微博网友提示,发现新浪3、4月份的时候上线了「微博4S店」这个服务,针对国内 5000 家 4S 店提供增值服务,年服务费 5 万左右,不知道目前销售如何,但这不是我说的向企业收费。这依然是传统销售的路数:销售人员打电话去 4S 店兜售服务,而不是用户自己主动购买,可想而知,销售结果会相当垃圾。

关注我的微博: @Fenng

关于归档

本页包含 Review 类别下的所有文章.

上一类别为 OpenSource.

Security 为下一类别.

回到 首页 查看最近发表的文章或者查看所有 归档文章.