工作点滴

工作后的记录

用沟通模型分析社交网络用户诉求

关于在社交网络 (Social Network Service, SNS) 上, 用户到底想要什么, 这个问题一直在想并且想了很久, 最近对个人认识体系有个相对完整的想法, 感觉还是用沟通模型来解释比较好

在得到这个想法前, 翻看了很多别的地方的讨论, 包括知乎上被转比较多那个 “上人人网就是为了泡妞” 的说法, 如果抛开这些非持续性的稳定需求, SNS 也好, IM 等也好, 最后一定还是回到沟通的本质上来. 虽然人人的早期 (当时还是校内和 5Q 在 PK), 以及其他的很多 SNS (比如早期的 51.com, 还有陌陌) 的第一波增长都是约炮, 但是约炮的人毕竟还是有限, 做成十万或百万规模还行, 而且有道德和法律风险, 要想继续做大, 必须还是走正路, 就还是沟通

在这里把不同的沟通模型拿进来看, 个人感觉主要的差异性在: 1) 实时与否; 2) 反馈与否; 3) 私密与否; 4) 重要与否. 当然这个划分方法不一定能很好区别, 不过大体来看可以如此. 实时性是指是否可以异步进行, 还是必须参与方必须实时参与; 反馈是说沟通是否单向, 收到消息的人是否需要反馈, 在这如果加个强要求就是是否必须反馈; 私密是说这个沟通是否有限制参与方, 非预期内的人是否也能参与; 重要表示对参与方的重视程度, 比如是否需要当面或书面等方式表达. 按我这个定义, 把常用的方式列举如下 (后面符号分别表示是否 实时/反馈/私密/重要, o 表是 x 表否 ? 表可能)

会议 o/o/o/o
聊天 o/o/x/x
电话 o/o/o/o
短信 x/o/o/o
电邮 x/o/o/o
IM ?/o/o/x
SNS x/o/?/x
博客 x/?/x/?
微信 ?/o/o/?

基本上越重要的事情应该是需要当面说, 并且最好是有记录的, 而一些随便的东西就不一定要当面, 而且不一定要是同步通讯, 再随便一点就也可以不要求私密性, 博客谁都可以看, 在轻松环境下的聊天也可以任何人都来参与. 另外一个比较大的差异就是是否需要反馈, 这事是你自说自话就行了, 还是必须有其他人反馈你才能继续下去, 或有动力持续下去.

扯回到 SNS (特别是人人) 上, 这四个特征对应的分别是:
1) 实时性. 信息是否能被实时获取, 甚至实时的推送到收件人那并有明显提示. 更严格对应到人人上, 就是新鲜事的到达速度, 以及导航栏气泡/聊天窗等信息到达速度. 应该说人人对实时性要求没那么高, 最多也就是数分钟这个实时性, 有爆炸性事件能保证可以被传播, 热点内容的传播足够快就行, 类似 IM 那样的实时性要求并无太多必要
2) 反馈性. 用户行为是否需要有反馈, 且反馈是否需要有明确通知. 对应到人人上, 就是新鲜事是否可以被回复, 被分享, 被喜欢 (或其他的快速情感表达, 赞/踩等都算), 反馈的通知就还是气泡或其他推送信息了. 不过很多反馈会要求实时, 比如两个人版聊起来了, 这时候微观交流就会被从 SNS 变成 IM. 其他的反馈可以不那么实时, 但是一定要有
3) 私密性. 用户行为是否需要限制可见人或参与人. 对应到人人上, 就类似个人主页是否任何人可见所有内容, 相片等内容是否只有好友可见或更复杂的隐私模型 (这个近期也想写点东西说下)
4) 重要性. 是否需要区分不同重要性的内容? 比如我女朋友的新鲜事我一定会关注, 而一些公共主页, 类似我们爱讲冷笑话这样的, 可能就是兴趣来了看一下, 没兴趣时就不看了, 来自这些地方的新鲜事丢了就丢了我也不在乎

SNS 的默认模型不需要那么实时, 所以太过频繁的消息推送会让用户觉得反感, 获取信息的主动权应该由用户来拉, 除非是用户非常关注的信息值得去推送 (比如某屌丝暗恋关注的女神有新动态, 他可能需要去抢沙发以获得更多好感)
另外用户的行为需要获得反馈来提升 TA 的黏度, 所以当用户的信息是被朋友或陌生人看到且作出相应回应 (我看过了, 我觉得赞, 我来说几句, 我来骂醒你) 后, 这个消息一定要推送给 TA, 至于实时性与否可以分情况讨论. 另外如果是太频繁且无用的提醒, 那此反馈渠道基本就算废了

来看看现在人人网上的用户都是啥样:
1) 有人喜欢显摆, 发个照片或日志希望大家都来看看我有多牛逼, 这种人需要更多更实时的反馈, 所以消息应该尽快推给他的朋友或其他人, 并让他的朋友尽快反馈 (哪怕只是很简单的一个赞按钮), 这样能促使他更多的活跃
2) 有人喜欢观察, 就是看自己订阅的信息, 这时候需要让他的信息流的实时性和完整性更好, 同时因为其拉信息足够频繁, 所以可以让其自己决定查看方式 (新鲜事是否按时间序这时候就很重要, 同时是否支持分好友组或分类型查看也很有用)
3) 有人就是 “我跟大家说个事, 我说完了, 再见” 这样的风格, 以工作了发婚纱照和娃的照片居多, 不过其实他们还是希望有反馈的, 比如 “婚纱照真漂亮” “娃好可爱” 等, 但是他对反馈的时效性不敏感, 只要定期有一个汇总就好, 并且他很可能不会主动来看反馈, 需要我们去推送 (一天一次? 一周一次?)
4) 有人就是 “今儿大爷心情好上来看看朋友们有啥好玩的”, 以工作了偶尔上来看的居多, 这些人需要尽可能快的让其获取关键信息 (主要是为了完成反馈操作), 然后再用起感兴趣的内容做扩散阅读希望能让其有更多的黏性

第一种和第二种人会是重度用户, 但第三种第四种才会是更多人的存活状态, 而且大部分人同时兼有 34 两种特性
第一种人需要的是更好的发布器, 让其发布内容更方便更爽, 同时把反馈尽可能快的推送给他并让他获得满足感, 并能跟其他人互动起来
第二种人需要的是更合理的信息获取方式, 优化新鲜事, 相册分享等浏览方式 (比如严格按时间序, 指定用户范围或新鲜事类型), 并给他足够简单高效的反馈让 13 两种用户能持续活动
第三种人更需要一个合适频度的反馈渠道 (邮箱? 合并了的手机通知?), 让他们能从发布信息获得成就感, 并保持活跃度继续发布内容或跟人交互, 过频的通知反倒会逼走他们
第四种人的信息流组织是个很有挑战性的活, TA 的收件箱可能压了一堆没读的东西, 那怎么把重要的东西挑出来让他不要错过, 同时也满足 13 两种人的反馈需求, 这个事情很重要, 那新鲜事就不应该按纯时间序而是按重要性组织, 或单独提供一个要闻模块, 以在可能很短的访问时间里更多完成他的信息获取需求和让他完成其他人需要的反馈行为

具体到一些产品上, 个人感觉应该做的
1) 消息本体, 保证其能被进行回复/分享/喜欢等操作, 并且消息展现的不同地方体验一致 (不管是新鲜事, 还是个人主页或时间轴, 以及终端页)
2) 新鲜事, 保证信息不会因为消息传递阻塞或蹩脚的排序/折叠/聚合方式而丢失或有很大延迟, 同时提供多种查看方式让用户自己选 (时间序/分组/分类/特别关注等)
3) 分享/收藏, 有算法聚合或人工推荐的公开信息聚合页供随便逛的用户打发时间, 也有多维度的查询方式让用户定位自己看过或收藏过的特定信息
4) 搜索, 类 Facebook Graph Search 那样的有点科幻, 而且实用性不高, 能按关键词搜人, 个体的新鲜事中的文本标题或正文, 以及全站公开信息的文本部分就 OK (比如状态, 相片/相册描述或标题, 分享的视频标题和评论等, 特别是用户自己的新鲜事内部搜索)
5) 通知系统, 更精准的消息推送, 现在导航栏上有消息气泡, 加好友气泡, 提醒气泡, 这仨应该被合成两个, 如果需要有实时的聊天需求, 类似私信或站内信这样的可以单拉一个气泡, 且无关紧要的进 ticker (这是个神器, 后面会讨论), 如果导航栏上的通知做的足够优, 网页内的右下角弹窗应该也能被整合
6) Ticker, 不得不说 Facebook 的这个东西是我在其他地方都没见过且我觉得非常赞的神器, 这里面糅合了不重要的新鲜事和通知, 保证信息的完整性, 且因为其占据的位置不大且不那么醒目, 又不会干扰用户正常行为, 同时 ticker 可以作为实验田, 我们猜测不重要的新鲜事可以试着先移到这, 如果用户还持续交互, 说明用户对此消息源或此类型的消息还是感兴趣的, 应该被更重视用更重的产品来展现, 通知反馈也是一样 (比如我的好友 x 跟 y 加为好友, 我要不要也跟 y 加为好友), 另外如果要对信息流做货币化, 这里显然也是个很好的切入点(做广告做久了的职业病, 啥都想到卖钱上去). 总之, 这个东西是少数几个我觉得一定要从别人那腆着脸抄过来并将其好好优化的功能之一
7) 隐私体系, 大部分人当这个地方是公开场合 (谁都能看, 比如微博), 或有限开放的公共场合 (大家对人人的默认定位, 好友可见, 其他人看我的内容被分享的情况了), 如果一旦有不适合按这个规模公开的内容, 用户又找不到方便的手段限制, 那势必会流失或遗憾 (比如我有一些以前的猥琐照片想分享给大学同宿舍那几个哥们, 现在就是放哪都不好, 人人上的隐私体系管不住, QQ 群别人不一定看到, 大家的交流也是时间序的而不是围绕这张照片进行, 不过 QQ 空间似乎有这样的功能了?), 而相反, 如果给用户提供隐私选项让其对部分内容加限制, 反倒应该能促进他更多的发布公开内容, 并让全站良性循环

租房提取公积金流程记录

更新 2014-09-30, 因政策变化, 本文部分内容已不适用 (新闻来源: 人民网: 北京提取公积金无需购房合同 租房可3月提1次)
更新 2013-04-18, 发票和租房合同原件已取回
更新 2013-03-28, 钱已到账, 发票暂未取回

大约半年前发现公积金放在国家那是不划算的 (计算方法见最后), 所以一直想着把钱盘出来, 最近完成了提取的大部分步骤, 把过程写下来供他人参考

步骤和注意事项
a. 开租房发票和完税证明
a.1) 房屋所在区的任一地税或代征点办理, 代征点一般几个小区就有一个
a.2) 带上 1/2/3/4/7/8 去, 交租房合同上总租金的 5% 税费, 一般都只收现金, 得到 11/13
a.3) 注意发票的付款人是租房人, 收款人是房东
a.4) 注意完税证明的纳税人名称是房东
a.5) 注意发票上的租房时间和合同一致
a.6) 注意发票上项目只能是 “房租”
a.7) 注意发票上总额除以租房月数后是整数
a.8) 房产证在最近一年及发票上租房周期内没有其他租房提取记录
b. 在中智办理支取手续
a.1) 中智在汉威大厦 27 层 4 号窗口
a.2) 先在后面电脑上提交电子申请, 桌面第三个快捷方式, 点打印 (实际不用打出来) 后再提交
a.3) 提交 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15 给窗口工作人员, 验证后当场返还 1/3/5/9
a.4) 据说 7/11/13 办妥后由驻公司的中智员工还我
a.5) 每月 20 日前办理当月的申请, 月底到账
a.6) 提取人最近一年需没有提取记录

所需材料
1. 房东身份证原件 (a/b 用, 验证后当场返还)
2. 房东身份证复印件 (a/b 用, 收走)
3. 房东房产证原件 (a/b 用, 验证后当场返还)
4. 房东房产证复印件 (a/b 用, 收走)
—- 如果房产多人所有则需每个人的身份证和房产证原件复印件
5. 租房人身份证原件 (b 用, 验证后当场返还)
6. 租房人身份证复印件 (b 用, 收走)
7. 租房合同原件 (a/b 用, b 处收走, 办妥后归还)
8. 租房合同复印件 (a/b 用, 收走)
—- 非中介用合同建议用北京住建给的模板, 没用的可以删掉, 关键是要有房东和租房人信息, 房屋地址, 租期, 租金这几个
9. 支取用银行卡原件 (b 用, 验证后当场返还)
10. 支取用银行卡复印件 (b 用, 收走)
—- 不强制要求公积金联名卡 (反正是一年一次的操作)
11. 租房发票原件 (步骤 a 获得, b 处收走付款人一联, 办妥后归还?)
12. 租房发票复印件 (b 用, 收走)
13. 完税证明原件 (步骤 a 获得, b 处收走, 办妥后归还)
14. 完税证明复印件 (b 用, 收走)
15. 提取申请书原件 (b 用, 收走)
—- 中智的在这里下载

提前支取的理由和其他的一些感慨
公积金中心的计息方法是: 当年缴存的公积金按活期利率算存款利息 (目前是 0.72%), 去年及之前的按三个月定期利率算存款利息 (目前是 2.75% 左右)
一般的投资收益应该在 4% 以上 (随便哪个银行的理财产品都不会低于 4% 吧? 这还是最稳妥收益最低的)
提取公积金要交的税是 5%
所以, 如果一年半内不买房, 花 5% 的手续费 (税费) 把钱取出来做投资, 一年半内能回本 (如果有其他更好的投资渠道回本时间更短), 而且钱放自己手里比放国家那显然更放心, 谁知道政策以后会变成怎样

感觉我办这坨事还算是没怎么折腾, 关键是有朋友肯借我房本和身份证用, 不然就算是正常租房, 一般的房东也绝对不会把这两样东西给你哪怕半天, 而且对应房本在这个时间段内还不能有其他租房提取, 所以现在中介帮弄都是要 15%~20% 的手续费, 他们租房本什么的也还是挺贵的, 而且都是把一个房本对应到好几个合租租房合同上去帮人取. 另外公积金中心不对个人, 必须是以公司或人才市场的名义去, 这应该也是中介手续费高的原因.

ps. 朝阳的公积金管的比较严, 中智卡的更严 (那个房东房本和身份证原件就是中智的土规定), 所以如果在海淀能取建议在海淀取了, 据某些中介说可以用买房等发票套出来, 最低的时候手续费只要 3%

2012 年度盘点

从 2006 年开始每年写年度记录, 继续保持下吧.

先流水账记些大事:
一月, 公司年会, 蹭百度年会, 刷回家火车票, 暖气漏水
二月, 搬到静安中心五楼, 出去拓展
三月, 去围观了场婚礼
四月, 入手 X200 底座, 买了辆小折, 刷街, 奇怪的去了趟环铁
五月, yewen.us 续费, 换手机, 买 new iPad
六月, 伪球迷看欧洲杯, 正式刷了一次铁博
七月, 搬到静安中心二十五楼, 开搞新鲜事, 爸妈来京, 买 X200 电池, 恶意刷小米之家
八月, 新室友, 去深圳围观架构师大会, 买 M4
九月, 校招, 去泰山, 装了一堆新配件弄成整机带回家
十月, 宅家, 去武汉校招, 围观死猫让人压力山大的个性婚礼, 续租和中介折腾
十一月, 还是校招, 帮小强跑一些结婚材料, 又去围观了个婚礼
十二月, 校招终于结束了, 工作上有明显产出, 组织 PUZZLES 群聚, 滑雪, 入手 650D

关于生活, 最大的事情该算全家对喵的全面认可, 但是某喵那边还没搞定, 还死活不让我说, 但是我又想显摆, 所以全年有不少事情只能这样被隐藏掉, 简单的说就是 “笨狗热恋中, 还没结婚生娃, 很幸福”. 全年又围观了很多婚礼, 看很多人生娃, 果然都已经进入到结婚生子的年龄, 说到这还是不展开了, 参照前一句打引号部分好了. 另外今天回忆时发现, 原来今年是最近几年唯一没有搬家的一年, 暖气漏水折腾过一次, 到期续租时被中介坑过一把.

关于工作, 搞了半年, 基本上从广告抽出来, 留下一个还凑合的摊子. 很遗憾的发现, 在互联网, 只要不是在非常大的公司或垂直划分的很清楚的地方做别的, 还是比较难和钱绕开. 换到新鲜事上, 在年末最后一段时间效果飙上去, 有这样一群非常给力的同事和朋友, 真的很赞. 对数据的认识又更深刻一些, 驱动去弄了很多数据方面的事情. 校招占了今年下半年很大的工作比重, 见识了各种强人和奇葩, 最后抢人还是抢的很辛苦, 但为了保证持续产出, 人的质量一定要保证, 今年各种事情都再次验证了这个定理. 因为一些奇奇怪怪的原因进了人人的技术委员会, 参与职称评审, 出去参会, 看看不一样的事情其实挺好的. 团队今年在公司获得一人次季度之星, 一人次最佳新人, 一次最佳团队, 当奶妈补血当的应该还算不错.

个人习惯上, 今年看了不少杂书和技术方向的书, 也在自己记一些笔记, 过的勉勉强强, 不算上进, 但也没完全颓废. 写 blog 明显懒了很多, 有一些东西是不方便写, 有一些就完全是因为懒. 因为在公司每个月混电影票, 所以今年多去电影院看了几场电影, 算把生活品质提升了下吧. 最近给自己定在公开课学习/复习一些东西的目标, 希望能坚持下去, 不学习, 要完蛋.

身体方面, 年初和年末去滑过两次雪, 中间有段时间每天做操, 骑车没跑远路, 就刷街了, 全年体重在 64~66kg 之间波动, 果然没达到去年 YY 的体重 KPI, 不过体检也没啥毛病, 就这样吧.

全年在个人穿着方面几乎没花钱, 倒是还在折腾电子产品, 给自己/喵/老爸各换了台手机, 买了个 new iPad, 给 X200 买了底座换了电池加了 SSD, 基本上算新配了台电脑带回家, 2012 马上要过完时买了个 650D, 可惜顺丰这次不够给力, 本来想着今年最后一天到手的还没送到. 网络方面也还持续投入, 买 ssh 和 vpn 维持科学上网, 域名续了五年费, 家里网络终于升到 20M 光纤. 一开始对 iPad 和手机各种折腾越狱, 刷机, 到后来也还就是当个普通玩具来用, 平平淡淡也好.

还是略有点感伤和迷茫, 感觉偏混日子, 之所以把蹭百度年会都写到大事里去, 是因为当时齐秦唱外面的世界时, 突然像是被狠狠戳到心底最深处后就泪流满面, 看的喵直接吓傻了, 好久没这样毫无防备的痛哭, 发泄过后日子还是得继续, 那就还是这样继续吧. 自己有一些想法, 但是喵和妈妈都觉得不靠谱, 现在因为喵要工作的原因, 又带来些新要考虑的问题.

本来预留了今年最后这几天来好好展开写点什么, 但是感觉现在总没有那种少年意气风发, 青年锋芒毕露的锐气, 更多的都是默默, 平平淡淡写这么点也不想再去展开. 其实还是要更锐利一点的好, 有霸气才能有才气.

你好, 2013.

读书笔记: 探索推荐引擎内部的秘密

看到别人推荐的, 在 IBM 发布的几篇推荐引擎的介绍, 不少干货, 先记录下

探索推荐引擎内部的秘密,第 1 部分: 推荐引擎初探
http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy1/index.html?ca=drs-

探索推荐引擎内部的秘密,第 2 部分: 深入推荐引擎相关算法 – 协同过滤
http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy2/index.html?ca=drs-

探索推荐引擎内部的秘密,第 3 部分: 深入推荐引擎相关算法 – 聚类
http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy3/index.html?ca=drs-

// 现在写 blog 越来越不勤快了, 最近重看了一遍 Python 的官方文档, 又查漏补缺了好多点, 但是没做笔记, 怕是又会忘, 除了零散乱看还是要勤写, 自己重述一遍才算把看过的东西好好理解了, 之前写机器学习的东西又挖坑没填

为什么通过前端 .js 记用户日志会丢数据

在这个数据驱动的时代, 做什么事情没有数据光凭感觉是不可能了, 今年夏天开始接手新鲜事的策略, 先推日志的丰富化和标准化, 关于点击日志, 解决方法无外乎这么三种:

1. 在点击 url 串上带上丰富信息, 然后在后续处理的前端 (比如 nginx 或 apache) 上打印请求日志, 把请求日志汇总过滤得到想要的
2. 做点击跳转, 用户点击后先跳到自己服务器上, 然后由自己的服务器做重定向, 并记录这一次请求
3. 前端 JavaScript 监控用户鼠标行为, 并及时上报到服务器

这三种方法也分别有各自的优缺点, 当时分析的是

1. 这个必须要保证点击后还是跳到自己的服务器上, 否则跳出去的点击无法跟踪. 不太可能丢日志, 只是过滤会多道工序. 目测 Facebook 曾经是这样干的
2. 绝对完整的记录. 不过需要新增服务器响应跳转请求, 并且如果跳转服务挂了会让用户压根到不了 url 指向的地方. 目前所有的广告服务都是这样 (而且点击串加密), Google 的网页搜索很早就是这样, 百度跟 360 干上后也换成了这种. 根据度厂员工在新浪微博上跟别人的讨论, 即使是百度网页搜索那么大的量, 算上灾备最多 50 台跳转服务器可以搞定 (根据公开资料, 百度每天网页搜索量在十亿这个量级, 按搜索引擎页面点击率 30% 算, 每天至少三亿次点击跳转请求)
3. 可记录的东西非常多, 不仅仅是点击, 而且还有一些页面上的其他 js 行为 (如悬浮, js 展开元素等), 但是会丢 15%~20% 的数据. 跟 360 干架前百度的网页搜索用的这种方式, 刚看了下 FB 也是这种了

其他的优缺点都比较容易明白, 但是 js 模式会丢 15%~20% 的数据这个非常难理解, 之前我只听到 20% 这个比例, 但是没人告诉我为什么, 昨天跟死猫君说日志的时候他也提到他们那边用 js 记的日志也有 15% 的丢失率, 但是他也只是听说这个比例而不明白原理.

今天跟前端同学讨论, 终于搞懂了为什么是这样. 后端的思维是每发生一次事件就打一条日志, 所以极难发生日志丢失的问题. 而前端不能每发生一次事件就向服务器发请求打一次日志, 这样会带来很大的网络开销并拖慢用户的浏览器, 所以前端都是把要纪录的行为在用户端先缓存, 等积累够若干条或过了若干秒后才向服务器汇总上报, 如果在这个上报条件触发前浏览器崩溃掉, 那日志就没了, 或者用户关掉浏览器也会丢掉这部分数据 (据说有一些方式可以响应关闭事件并上报日志, 但具体方式不了解, 另外前端同学反馈 IE6 下丢数据现象更严重). 所以丢数据这事其实是用户流畅度体验和数据完备性的一个平衡, 如果让用户卡一点那丢失比例就低一点. 另外接 js 汇报日志的服务器压力也是一个要考虑的点, 因为如果真用 js 汇报, 那一定就不止点击这点数据了, 鼠标滚轮, 悬停等事件显然是能有都有, 服务器不一定扛的过来.

一季招聘快结束时的找工杂谈

本文说给要找工作的毕业生听, 其他人可以围观看乐子

核心三句话: 该有的有, 该没的别有, 该出彩的最好出彩

简历要有, 基本联系方式要有, 如果不是漂亮妹子就不要放照片吓人了, 个人隐私身份证号家庭信息什么的反正我是不看的, 要有人闲的蛋疼觉得自己信息泄漏的还不够多写上凑个字数那也没人拦的了, 有竞赛/项目/实习经历那最好, 详细说明具体是个什么事, 你在中间扮演什么角色以及你有多重要. 核心目标是节省互相了解的时间, 不浪费口水, 而且写的时候应该没有当场说那么紧张吧

没有太牛逼的简历也没人给你担保那还是去下笔试吧, 比直接霸面还是靠谱点. 卷面整洁点好, 要涂涂改改可以在草稿纸上进行, 没带草稿纸可以在考场问监考的要, 有思路把思路写清楚, 要写代码什么的当然也是越清楚越好, 带注释那就完美透了, 免得遇上比你菜很多的改卷人因为看不懂而把你咔嚓了, 面试时也可以让面试官有个提前了解, 就不用拿菜题来让你感觉被羞辱了

面试时别迟到, 如果路上有状况提前打电话给 HR 告知, 否则很可能是你去了后因为打乱安排而被各种等, 流程好的公司会有很好的预案, 但是不是每个公司每个 HR 每个面试官都那么靠谱. 面试有啥说啥, 会的东西就不用藏者掖着了, 不会的也想办法说明自己为啥不会, 是有别的途径可以弥补这方面的不足, 还是怎样可以短时间内赶上给面试官一个正向的未来预期. 面试时别装逼, 一般面试官不会比你傻太多, 装失败了会有很大的负向影响, 装成功了也会让别人觉得你不好沟通, 礼貌待人在哪里都是适用的. 面试快完时可以就面试的公司做一些了解, 或者让面试官给一些建议, 不要问 “你觉得我这次面试怎么样” 这样的问题, 这种问题让人怎么说? 好的话你明显能看出来面试官也很 high, 不好的话人家也不好当面打击你对吧

后续跟进有必要, 对你是唯一的一次机会, 在公司看来你可能不过是万千人中普通的一个, 很可能会漏了或忘了, 但是如果人家告诉你还在跟进, 特别是还告知了大致进度后, 就不宜缠着死问了

最后吐槽一句话: 一天面试十几个人真不是人干的活, 这种面试强度下面试官的标准还有可靠性吗?

机器学习手记系列 3: 线性回归和最小二乘法

好几个月没再继续, 挖坑不填是不对的, 还是继续写手记.

线性回归

线性回归一般用来学习一维自变量和一维因变量之间的线性关系. 如果存在一维自变量 x, 同时还有一维因变量 y = f(x), 如果有一堆对不同 x 下 y 的观测值, 即 的观测对, 且如果 x, y 之间存在较明显的线性关系, 可以用 f(x) = a*x + b 这样的方程表示, 则可以用线性回归的方法学习出 a 和 b 的值, 同时估计这个拟合方法的误差 r.

扩展一下, 线性回归也可以指 y = a1*x1 + a2*x2 + ... + ak*xk + b 这样多维自变量和一维因变量之间的线性关系 (多项式里自变量的最高幂次都是 1), 同样也可以用回归的方式学出来里面不同的系数和常数项的值. 只有一维自变量的称之为一元线性回归, 否则是多元线性回归.

判断线性回归好坏, 一般就用平方误差和来描述, 其表达为 (f(x1)-y1)2 + (f(x2)-y2)2 + ... + (f(xk)-yk)2), 此值如果为 0 则说明自变量和因变量存在完全的线性关系, 否则是近似线性, 越小近似的越好. 这个东西看着有没有一点面熟? 其实就是机器学习手记系列 2: 离线效果评估里最后提到的 MSE 的非平均版本.

解方程法

假如输入样本存在绝对的线性关系, 即最后的误差为 0, 则问题变为解二元一次方程 (一元线性回归里的系数加常数) 或 N+1 元一次方程 (多元线性回归里 N 个自变量的系数加常数). 这没什么好说的, 直接对原输入直接求解就行了, 类似计算方法这样的课本上有的是解法, 做梯度下降或牛顿法乃至矩阵分解都可以解.

梯度下降法

考虑到绝大部分情况下不存在绝对的线性关系, 则问题可以变成怎么求平方误差和的最小值点. 如果是一元线性回归, 目标函数变为 g(a, b) = (f(x1)-y1)2 + (f(x2)-y2)2 + ... + (f(xk)-yk)2

我们的目标就是让这个目标函数值最小, 选定一组 的初始值, 然后求其梯度方向, 每次前进一个小步长, 再求梯度前进, 直到目标函数值不再下降, 说明我们已经走到了一个极值点附近, 终止迭代. 对一元线性回归, 梯度方向是对函数求偏导得到的向量方向.

另外需要注意的是, 梯度下降不一定能找到最优解, 可能会在某个局部最优解那陷进去就出不来了.

这部分更详细的推导请见参考资料里 “机器学习中的数学(1)” 一篇, 里面的公式和图做的很赞, 思路也比我清晰.

牛顿法

梯度下降一般遇到的问题迭代步长不好选, 选太小到极值点太慢, 搞太大又会在极值点附近时因为步长太大跳过去了.

牛顿法最大的贡献就是同时给出了梯度方向和迭代步长, 几乎是一步到位的求解. 方法同解方程一样, 对新的损失目标函数求解, 只是一次解可能还不够好, 需要多做几次迭代. 一般梯度下降可能需要上千轮的迭代, 而牛顿法几次迭代就能到极值点了.

最小二乘法

伟大的高斯同学提出并证明了最小二乘法是最好解答, 证明过程略… 直接看维基或百度百科上的原文吧 (数学不好伤不起).

应用

虽然这个方法看起来很简单粗暴, 但是很多时候变化确实就是线性的. 比如在很多论文和工业实践中, 大家认为同等质量的广告或搜索结果, 放在从上到下不同的位置上, 其点击率和位置的关系符合线性关系, 即 ctr(rank) = a*rank + b.

在六月的一次随笔杂记里, 提到了这样的问题:

如下式子里不同的阿拉伯数字只是一个符号, 实际表示的可能是其他数字
967621 = 3
797321 = 1
378581 = 4
422151 = 0
535951 = 1
335771 = 0

根据上述式子, 判断下式等于?
565441 = ?

假设每个式子最后做的都是加法, 并把字符 0~9 映射到 x0~x9, 则统计不同字母出现的次数就可以列线性返程, 可以将第一个式子表示为

x0*0 + x1*1 + x2*1 + x3*0 + x4*0 + x5*0 + x6*2 + x7*1 + x8*0 + x9*1 = 3

其他类推. 对这堆式子求解就可以得到不同数字对应的真实数值, 可以得到 565441 = 1. // 具体代码和方法下次给出

参考资料

* Wiki Least squares: http://en.wikipedia.org/wiki/Least_squares
* Wiki Mean Squared Error: http://en.wikipedia.org/wiki/Mean_squared_error
* 中文维基 最小二乘法: http://zh.wikipedia.org/wiki/%E6%9C%80%E5%B0%8F%E4%BA%8C%E4%B9%98%E6%B3%95
* 百度百科 线性回归: http://baike.baidu.com/view/449540.htm
* 百度百科 最小二乘法: http://baike.baidu.com/view/139822.htm
* 人人上的日志 幼儿园的题目和机器学习的关系: http://blog.renren.com/share/30314/13432269197
* 机器学习中的数学(1): http://www.cnblogs.com/LeftNotEasy/archive/2010/12/05/mathmatic_in_machine_learning_1_regression_and_gradient_descent.html

// 本文开写于 9.24, 拖到 10.26 才马马虎虎完成, 最后那个题的解也没写, 各种错乱后续再修改或补充吧

校招趣事

最近筛简历过校招候选人, 被北邮和中科院的人潮汹涌吓到了, 有些有意思或很苦逼的事, 说说

1. 收到的简历里北邮的数量似乎是最多的, 按北邮出来的人的说法, 北邮在找工季信息共享的很好 (byr 果然不是盖的), 然后很多人不管职位需求, 只要看有一点相关的就会去投. 这种筛的人很痛苦啊… 特别是有很多不了解的项目和实习, 一开始觉得好像很牛逼的样子, 后来看多了就发现怎么看都是个野鸡事

2. 去年参加校招面试的某狐狸, 说出去面试老能遇到北邮的人, 后来很 ws 的做了个实验, 出去面试碰到不认识的人就问 “你北邮的吧?”, 大部分情况下都命中, 屡试不爽 // 我能吐槽下恶趣味么…

3. 收到一份 00 级本科的简历, 本科武大物理, 然后在中科院念了五年的物理, 不过这个经历貌似没下文, 因为简历上最后的学习经历是计算机方向的硕士, 跟大家说了下, 都觉得应该是学物理太苦逼而且很难毕业没办法只能转方向了, 唉, 真心苦逼

4. 简历做的好不好在校招海投季节显得尤其重要. 有人的简历做的就让人看不下去, 两个人一天筛一千份简历的情况下, 八成会被直接无视; 有人简历一开始是大片大片的不知所云, 有亮点都放后面, 不知道怎么想的, 你们试试看在 Win7 的资源管理器里打开预览窗格, 然后看自己简历, 能不翻页情况下能看到多少内容? 我在筛实习生筛过后的简历时就这么筛的

5. 除了智商是硬伤, 感觉沟通更是硬伤. 有几个北大的妹子面的各种心情愉悦, 说什么都能很快跟上思路, 理解题目意思和跟上提醒都非常上道, 相比而言可能因为北邮人实在太多, 总能遇上那么一两个极品, 面试时各种沟通找虐, 你不明白他说什么, 他也不明白你说什么, 或者压根就不屑跟你说或想去理解你, 你都不屑了你还来个球啊 (摔), 刷小怪也认真点好么

2012全球架构师峰会参会简记

8.10 ~ 8.12 在深圳参加全球架构师峰会 (http://www.archsummit.com/), 回来也十来天了, 先把回来后记在 evernote 里的简记发下, 详细的后面跟着幻灯片展开下


公司定的机票时间都太晚了, 走的时候上飞机没晚点, 起飞晚了一个多小时, 到深圳都晚上十一点, 到酒店也半夜一点
住的略偏, 在小梅沙, 这酒店算一般水平吧, 可以理解成规模大点的农家乐
吃的凑合, 会务的自助餐还是挺不错的, 就是人太多, 要么早点要么晚点, 不然排队排死人. 茶点我就第一天提前去偷吃了点, 剩下的都懒得排队了
会场是万科的总部, 很多地方设计的很精妙, 但是大梅沙离市区还是太远太远了


组织的还是挺不错的, 就是有时候几个分会场都想去, 无法分身
同声传译很赞, 也没有很外行翻出莫名其妙的句子来, 前面坚持听了几场英文的, 最后一场借了个传译器果然还是听中文要顺畅很多
腾讯是主赞助商, 发的东西很多, 公仔和衣服没抽到和领到, 其他的资料倒是都拿点, 腾讯在这方面的宣传做的挺好, 给的东西也比较下血本
其他有很多硬件 (比如 SanDisk 的企业用 SSD) 或平台型 (比如云存储) 的赞助商, 我不懂, 就随便看了看展台. 倒是有很多开发平台的赞助商, 比如天翼, 还有海豚浏览器也是赞助商, 我还没怎么弄明白开发平台这个生态圈怎么玩, 果然落伍了


大会场的几个 topic, Pinterest 那个没赶上, 老外吐槽中国网络状况倒是吐的挺狠也挺实在的, 包括多网不通, 还有 GFW, 只是八线机房是个什么情况, 电信/联通/移动/教育网/还有四个有啥?
搜索那个 session 讲的都比较虚, 扯了些概念, 搜狗的提出抓别人的搜索结果 (参考资料: 孟学一有关暗网数据挖掘的书), 一淘讲了些干货, 不过总感觉也没啥特别的, 是因为别的人都没做过或看过这么大的搜索引擎, 所以觉得有很爽的干货么?
大数据那个 session 干货比较多, EMC 上来介绍了一些基于 Hadoop 或 Map/Reduce 的框架, 都很赞, Yahoo 的 Nova 自动化调度数据和任务也做的很好, LinkedIn 对数据的处理方式也非常值得参考, Pinterest 最后讲那个数据库分片, 真的是把简单做到极致, 能不复杂绝不复杂, 能用钱搞定的事情没必要省那几台服务器钱结果把系统搞的巨麻烦


Day1
All: http://vdisk.weibo.com/s/ajLUe

Day2
上午: http://vdisk.weibo.com/s/au-u-
下午主会场 (海量数据): http://vdisk.weibo.com/s/av8ue
下午分会场 1 (移动互联网): http://vdisk.weibo.com/s/aveIJ
下午分会场 2 (安全): http://vdisk.weibo.com/s/av5bn

Day3
All: http://vdisk.weibo.com/s/aAaQ3/1345032030