今天是国耻日,恰好昨晚看完了号称日剧第一的《半泽直树》,是个关于复仇和道歉的故事。很应景。

早上听着鸣笛声发了一条关于国耻日、半泽直树和道歉的朋友圈。顺势想起了关于道歉的一些事情。让日本人道歉真难,即使是心知肚明,但不知道是出于骄傲还是出于偏执,就是无法道歉。真是让我无法理解。

我常常会玩玩文字游戏,声称:日本是敌人,而非对手。

这句话其实还是有些意味的,对手,往往是那些和你有着同一级别的道德水平的,但价值取向不同而已,所以是值得尊敬的。而敌人,是比对手低一个层次的概念,仅仅是战斗中的对方,不需要考虑到道德水准和价值观的。对待日本,就是这样。(当然不排除在某些特定的领域,日本是值得尊敬的对手)。

道歉到底有多难?我们对道歉到底有多在意?

不同于很多人要求的抓着要日本人道歉,我对日本道歉这件事其实并不特别看重 – 不道歉并不代表没做错,事实摆在那里,态度而已,而你的态度不会影响到我,最多会让我知道你的心理素质比较差而已。但是我们会时时记得这个敌人,即便是我这个从未经历战争、从小看着日本漫画和动画片长大的昨天晚上还看了日剧的中国人。

你可以说这种“恨意”是溶在血里的,也不排除是宣传教育的结果。但非常客观(自己所谓的客观也许并不客观)地说,对待日本整体的行为,我是非常傲娇地鄙夷之的。

为什么?

引用日本人自己的评价,《半泽直树》中贯穿全剧的一句话(大意):一定要重视人与人的交往,而不要像机器人一样工作。相比日本来说,中国人“像机器人一样”工作的人要少许多。

我们在读书的时候为什么有时看的很累?有时却有轻松而有收获?

除了兴趣和精神状态之外,也许还有别的原因。

反馈效应

反馈原来是物理学中的一个概念,是指把放大器的输出电路中的一部分能量送回输入电路中,以增强或减弱输入讯号的效应。心理学借用这一概念,以说明学习者对自己学习结果的了解,而这种对结果的了解又起到了强化作用,促进了学习者更加努力学习,从而提高学习效率。这一心理现象称做“反馈效应”。

我们在读书时也同样需要类似的反馈机制存在,显而易见的,就是“翻页”这个动作。“翻页”会让我们获得来自书的反馈 – 这页你读完了(也许未必完全明白,但这不重要,重要的是“读完了”)。尤其是那些比较艰深的读物,更是感觉明显。

所以,也许在考虑书籍的排版和封装的时候,需要考虑一下主要读者群对反馈的适应情况,比如,如果读者阅读时比较吃力,可以考虑每页字数不要太多,并且如果书籍内容比较多的时候,考虑分成多册(kindle就不需要考虑分册这个问题了)。

其实即便是生活中很小的点滴,也可能蕴含很多普遍而浅显的原理。

 

 

基于朴素贝叶斯进行文本分类因为实现简单被广泛应用,很多开源的机器学习框架都提供了相应的实现。使用场景如新闻类内容的分类,垃圾信息识别等等。

原理

贝叶斯的定义就不具体说了,概率统计都有讲,如果没学过也没关系,去wikipedia上看看。非常朴素,值得一看。

分类器最重要的是先要有“分类”,而且分类之间应该是相对来说重合度比较低的,或者说是正交的。然后对每个分类进行词的统计,然后就会生成一个关键词序列,或者叫模型。有点像这个分类的DNA序列一样,即可以理解为这个分类在用词维度上的特征(特征向量)。然后就是将目标内容基于这一系列的“DNA”序列进行计算likelihood,值最大的那个就是了。

实践

具体的实现我就不上代码了。主要几步:

0. 抽样

从对应的分类中获取足够多的样本,并且要避免有脏样本,否则生成的分类器会不准确。

1. 分词

这个很容易理解,因为是要用到词,中文就一定会用到分词工具。Java里有paoding, PHP里有Jieba,甚至新浪SAE的分词服务…这方面有很多开源的解决方案。

2. 统计、生成DNA(模型)

针对每个分类的样本集合,统计每个关键词的出现频率。最终得到一个“词-次数”的Map。这里就用到Redis了,其实不一定要用Redis,用Redis主要是考虑到后续的模型自动反馈改进。如果只是不怕麻烦而手动生成的话,这里保存模型到哪里其实无所谓。

3. 权重设置

针对每个词在所在分类里出现的频率来设置一个后续计算的权重。最简单是:这个词在所有词中的出现概率(该词的出现次数 / 所在分类中样本的总词数)。用Redis的SortedSet来保存。

4. 使用

对于一个目标样本,分词,然后针对每个分类计算相应的权重值和。

5. 模型自动化反馈

这个还是比较重要的思路,因为模型也是会变动的,你的分类可能也在不断进化,比如法制新闻的内容可能随着法制热点或者法治进程的变化,产生不同的特征(这个例子有点YY了)。所以模型的产生应该随着新的样本不断地变化,所以生成模型的过程应该是保持一定的频率进行,同时,每次的使用模型进行分类的目标样本如果区分度较高,也可以直接加入到模型里进行计算。

 

优化

避免overfit – 模型并不容易达到足够高的准确率,准确率过高的原因可能是因为分类区分度很高,也许根本就不需要用分类器类做这件事,而准确率过低有可能是你的抽样有问题,或者你的分类有很大的重叠,比如生活和社会这种。所以如果是目标样本非常fit某个分类,建议就不要放到新的抽样样本里,因为不会产生新的“基因”了,如果这种样本过多,最终就容易overfit。

数量取胜 – 也是很朴素的想法,一个分类器不行,那么十个、二十个呢?如果能够把整个抽样提取、模型生成、模型反馈机制都自动化了,那么用多个分类器进行交叉验证,或者是来个投票机制。准确率应该也可以有很好的提升。

考虑到目前在读的书有七八本之多,我得分析分析自己的这种读书习惯了。

我非常赞同开卷有益和不求甚解,也就养成了什么书都读的特点,当然前提是自己至少有点兴趣,或者别人强烈推荐。但是,我很难控制这种“随意的开始”,经常是买回几本书,然后都翻几十页,虽然最终都会读完,但是貌似“进度”并行的结果就是读得有点慢。

比如,现在我就在同时读:

1. 道德情操论(家里书架上,慢读)

2. 零年(办公室)

3. 美国大城市的生与死 (微信读书)

4. 文明之光(书房书架显眼位置,工作间歇休息时阅读)

5. 量子物理史话(第二遍、ipad)

6. 我们能做什么(微信读书)

这都不是我的“巅峰状态”,因为kindle都处于赋闲状态(kindle一般都是旅行模式)。先说说这么读书的好处和坏处:

1. 场景化阅读 – 每本书都是处于一个特定的场景,不会出现无书可读的情况,如果真的有记忆需求的化,场景也不失为一种记忆手段。只是大多数情况下,我读书都不会特别的去记忆。这么来看,读书似乎是一种往潜意识“放东西”的行为,也许在某个时刻会激发创造力,或者干脆是做梦用的。

2. 不强迫自己 – 比较随意,也许是我本身就是一个思维比较随意的人。我的目标是获取insight,而不是单纯的知识(考虑自己也没有过目不忘的本领)。所以也不会强迫给自己设定读书目标,比如本数、页数。

3. 缺点 – 随意的开始“一段感情”,这么类比也许不太恰当。太随意的开始就像是没有想清楚就结婚一样,也许会缺乏持续投入(commitment),最终不欢而散。还好看书没那么大的“负担”和“复杂度”,而且书很多时候也不会和我要求什么。

好吧,每个人都有适合自己的读书方式。

用google和百度最大的区别是:如果你是问一个问题,即便是相对冷僻的主题,google也会帮你找到质量不错的答案。

我不想再说关于google和百度二者的比较,这个已经没意义了。我想说的是,我们经常会看到这些答案出现在IRC、newsgroup、maillist这些我们很多人听都没听过的“原始”工具里,因为这种“负责任的回答”似乎是非常正常不过并且由来已久,比如这种。而我们直到有了知乎之后,才算是有地方去找一些相对靠谱的答案。

除了得出“歪果仁”比国人更认真(普遍意义上讲,不说个别)的结论,似乎得不出别的结论。

我不是“妄自菲薄”,也并没有“崇洋媚外”的习惯,这只是我观察到的一个结果,不排除有主观上的因素。但无论怎样,人还是应该动态地看待问题,我还是对国人乐观的,即便有些人和事很不堪,但还是有很多让人感动的人和事。

前天在微信里看了一篇文章,是这篇文章的中文翻译,觉得很有启发。但今天却怎么也找不到那篇翻译。这里不得不吐槽一下微信里的内容质量实在是不敢恭维。

文章写于2013年,对于日新月异的互联网来说可能已经是“一个世纪”,但是这种简洁的模型却非常有生命力。

简单的说,作者将任何一个平台(platform)拆解为三个要素:

Connection – how easily others can plug into the platform to share and transact

Gravity: how well the platform attracts participants, both producers and consumers

Flow: how well the platform fosters the exchange and co-creation of value

这是能找到的原作者写的文章。但是译文还是没找到,晕。

译文比较深入但也容易理解。不同于上面的三个“晦涩”的词,而是:

1. network(community)

2. technology

3. data

不同的平台的区别主要是这三个因素的比例不同,比如google在初期就是technology为主,然后有了足够的data后,最终产生了network effect,进而再通过technology促进data的丰富。最终三者均衡,但仍然是technology略大。而facebook则一开始就是爆发性的networking,然后data和technology跟进。还有关于craigslist、Nike+、airbnb、linkedin等平台的例子,都可以很好的解释。

这个模型有点像我们经常说的:产品、技术、运营三要素。其实两种模型有互通的地方。

所有的互联网平台其实是两个东西的组织:信息和用户。

信息的组织,体现在将信息进行创新的展示,比如SNS、LBS、blog、twitter、messaging或者其他种种混合嫁接(hybrid)

用户的组织,最开始的互联网体现在将信息传递到用户(这种模式就是所谓web2.0时代之前的pipeline),而web2.0开始,人的组织一方面是提供价值给信息消费者,同时又把信息生产的职责交给了用户(也就是信息的获取)。

剩下一个技术就不用说了,作为工具和驱动力。

虽然关于用户登录注册几乎是每个系统的标配,也是大多数教程里的经典样例。但实际工作中,我们还是时不时会被“用户”搞的焦头烂额。比如防止机器注册、oauth接入以及带来的用户账号合并问题、用户身份验证或身份标识、用户相关的表应该如何设计以应对未来各种扩展和可能性等等。

这里记录一些之前的设计和开发的经验。

用户是否一定要注册并登录

我个人非常反感打开一个网站或者App以后,还没搞清楚是做什么的时候就强制要求注册的。这种做法绝对是“好奇心杀手”,至少一半的人被这个动作挡在了外面,实在是不值得。我之前参与的项目,只要是可以最终能够获得用户的联系方式的,那么一定不需要用户注册以后才能使用功能。比较常见的情况是标准的电商网站,浏览和查看是不需要用户注册的,但是结算时就需要了,在我看来虽然比一上来就注册好一点,但还是有点“伤” – 用户都已经下决心购买了啊!用户结算时一般都会做两件事:填写联系方式、支付。这些都不需要用户ID这个东西,能联系到用户就已经很成功了,一定要用户填个注册表单吗?当然不排除是万恶的KPI。

不过不注册产生的一个问题是用户“返回”和订单跟踪时会需要额外的流程来,比如需要用户提供订单号来找回订单,甚至可能需要人工介入。

身份标识

即如何标识一个用户,常见的标识有:昵称、邮箱、手机号、OAuth授权ID。更多的标识建议没有特殊必要就不要收集了,一来涉及到个人隐私,二来这种数据需要更高安全要求的存储(前提是你没打算用来干坏事)。在bot还不是那么泛滥的年代,常常是一个昵称就可以了,但现在连邮箱都不行了,几乎都是手机号码起步。很多时候,一个手机号就对应一个用户,虽然现实并不是这样,但至少是比较靠谱。会产生多账号问题 – 因为有些人换号了或者有多个手机号,如果用户有合并账号asset(也就是账号的“资产”,比如余额、积分、优惠券等等)的需求,目前看貌似真不好搞,判断两个账号同一个人并不容易也会存在风险。

比较常见的还是基于手机号标识用户后,在进行手机号的更换绑定的流程,这样就成了“一个用户一个手机号”,也算是解决了问题。至于账号相关asset合并问题,就要视具体情况来定了。

多账号问题

举个极端的例子,当系统支持手机号、邮箱注册,同时支持Oauth登录时,如果没有任何限制,一个用户可能会用手机号、邮箱、各个Oauth各注册一个用户。这种情况带来的问题是用户会搞不清楚自己的订单在哪个用户里,相信我,有这种“糊涂”的用户。之前的一个经验是“关联”,比如,除了上述的标识以外,我们通常还会生成一个唯一的标识记到cookie里,同时useragent信息也可以部分的标识,geo信息,ip归属地,甚至再“玄”一点的用户行为模式。通过这些标识也可以进行账号是否属于同一用户的判断,此时再提供给用户合并账号的流程。

OAuth

OAuth现在也是标配了,大多数的OAuth的接入都不困难,所以接入的技术细节就略过了。之前的经验是用户和用户OAuth是一对多的。用户正常注册后,然后绑定各OAuth,这样之后通过OAuth登录就可以确定用户,这是最简单的情况。如果用户是先通过微博的OAuth登录,之后又正常注册的,也就是上面说的多账号问题了,除了上面的“关联”方法,另一种解决办法是针对这种用户鼓励再进行手机号或邮箱的注册。

经常见到,用OAuth登录跳转回来以后,马上要求用户进行手机号或邮箱注册的流程,虽然可以最快的完成绑定。但却失去了Oauth登录的便捷性,有点被“坑”的感觉 – 本来觉得注册麻烦,以后授权一下就可以搞定,结果授权完还是一样要注册。

用户表结构

也没什么花头,User表记录用户的基本信息,UserProfile记录用户的个人资料,UserAddress记录用户的地址,UserOauth记录用户的登录授权信息,UserCredit用户积分信息,UserXXX,总之就是尽量让User表纯粹,通过增加实体表来扩展。比较简单,就不细说了。

验证码(captcha)

验证码用来防止机器人进行表单提交,比较经典是12306的验证码。对这件事我是有点“悲观”的,因为永远都是道高一尺,魔高一丈。现在很多时候都是用了手机或者邮箱的动态验证码,或者类似微信换设备登录时选择好友头像,还有非常原始但有效的“注册预留问题”。相对来说类似微信这种根据账号的asset(微信的好友就是微信账号的asset)来进行验证,但这个又是和你的业务相关的,比如如果是滴滴打车,可能会让你选择你曾经在哪些城市使用过滴滴。

单纯的captcha真的没有卵用,看看满大街的注册机就行了,当可以cover成本的时候,甚至都可以人肉来做,搞captcha有啥用呢?

磕磕碰碰,在九零后纷纷崛起的时代,我这个八零后老人也开始创业了。
想起写这个题目已经有一段时间了,在开始创业以后,很多思考方式和做事方法和以前不同,所以也就越发留心那些“做事”的人是怎么做事的,那些“说”的人是怎么说的。
现在形形色色的创业者(包括想要创业的人)是何其多,但90%(或者更高)还没有实质的成效。作为一个技术工作者,我有幸接触了很多想要创业和处于创业初期(包括我)的人。那些想要创业还没有创业的人,无非两种执行力强的和执行力弱的;而那些已经创业的创业者其实也无外乎那两种。而且所占比例可以说没什么区别,一方面是现今创业门槛过低,而另一方面也是很多人并不具备识别doer的能力。于是乎,很多时候创业就成了赌博和包办婚姻的结合体。
而我想要说的,恰恰就是创业团队里的talker问题,我称这种人为“创业之贼”。

最初的核心的创业团队,通常是“知根知底”并且是互相认可对方在各自专业领域的能力的。但是我们知道,通常两个人是很难“起事”的,这时候就需要通过各种人脉圈去找一些可以弥补某些短板的合伙人加入。而这种时候就很可能引入所谓的talker,并且创业者遇到这种情况非常普遍。一种心理原因是“饥不择食”,有总比没有强;还有一种可能是某个创始人比较看重,直接做了决定。

如果这个人能胜任,并且能够被其他人认可还好。但如果这个人只会说不会做就头疼了,事情到他那里就停了,做事情来有头无尾,时不时需要别人擦屁股,各种idea满天飞但永远都是别人来实施,不分析原因不持续学习(这个最可怕)。恭喜你!你遇到了所谓的“创业之贼”。

怎么解决“创业之贼”这个问题呢?很多doer并不是很有经验去处理这种问题,毕竟大家更多的精力是往目标去冲,但“贼”的问题在于,你越是忽略他,他可能越让你烦心,最后可能让整个团队都会受到影响。创业团队天天都是各种要解决的问题,难不成是去搞“宫斗”?

隐藏在学霸中的学渣,也就是俗称“凤尾”的人。他们见识过什么是学霸、并了解成为学霸需要如何努力。同时,他能够体会学渣的心理活动是怎样的。

有机会深度接触产品经理和开发工程师这两类人,有时候也会在二者之间不停地的角色切换。这种不上不下的感觉有时候让人颇感难受。为什么?因为一边需要考虑定义产品边界以尽快上线迭代、不得不进行妥协,而另一边作为开发人员却时时事事想要做到最大的扩展和可能性,而不得不拖延进度。

但二者有一点是需要有共识的,那就是细节的重视。

好吧,有点跑题了。

之所以突发奇想想到这个题目,也许是内心的另一半有积郁已久的怒气吧。常见的比如改需求、催进度、不去了解技术这些就不说了。说三个我比较有体会的。

1. 不正确的命名

这个放到第一个可能让很多人意外了。在中国,程序员可能算是整体英文能力最高的群体。当我作为一个产品经理设计完一个产品,并准备“亲手”去实现它的时候,我发现我经常需要用到英汉/英英词典去给产品、模块、子系统、甚至状态正确的命名。比如“积分”,到底应该是point、credit,当程序员在思考”积分“的本质的时候,如果产品过来来一句,“别纠结了!就叫‘jifen’吧!”,你知道程序员心里是怎么想的吗?你知道程序员每次在IDE中看到jifen这个词的时候是怎么想的吗?你知道程序员会不得不创建诸如“JifenAccount”,“JifenLog”这些奇葩的名词吗?你能想到code review时候,其他程序员对你英文能力的“冷嘲热讽”吗?

2. “引经据典”

“Facebook就是这么做的,微信就是这么做的”,这种话多半出自一只菜鸟产品经理 – 因为你只知道需求,却不知道边界、约束。你有没有制定合理的版本计划并和程序员商量过?你有没有正确地评估你可用的开发资源和时间?

3. 缺乏学习能力

这一点其实任何人都应该避免,别抱着一知半解去和别人讨论。多去了解“目标”周边的情况 – 这就是学习能力。缺乏学习能力其实不可怕,可怕的是没有意愿或没有动力去学。这种就建议转行了,应该去做自己喜欢的事情。

4. 重复

DRY(Don’t repeat yourself),重复的问题就像是“重复”代码一样可恶。