豆瓣的sns之路

豆瓣基于用户喜好的社区服务最终的目的是什么? 现在来看越来越像facebook

虽然种子不同, 但却最终长到差不多的结果. 这种基因上的不同, 最终会让豆瓣和facebook的区别在哪里?

也许可以用中国人和欧美人的性格差异说起, 一种内向一种外向, facebook的用户更多是一种秀 – 看我的network多广, 看我认识的人有多cool, 看我多重要….而豆瓣上, 每个用户都很务实地看看谁和自己有共同的爱好, 也许就算有也不会加为友邻. 说起来有点奇怪, 为什么豆瓣一直都不开发邮件通讯录找人的功能, 这可是sns的标配啊. 由此看的出豆瓣相对来说低调/不盲目扩张的本质. 也许过早的带来一大批用户反而不是好事, 不如一直来培育自己的”硬核用户”. 都是很务实的方法/团队, 做的事情/目标却不尽相同.

在中国, 做sns是有局限. 不会让你拥有”无限可能”的. 也许豆瓣的路, 还是一点一点走, 慢慢改变人们的生活. 也许不是sns或者不叫sns.

ktv和云计算

笔记本换硬盘, 还在备份. 抽点时间yy. 忽然间想起了这两个东西 ktv和云计算

idea产生的一个很好的方法就是随机找两个东西, 然后把它们放到一起看看会怎样 – 随机混搭. 当然还有另一个就是在日常生活中细心发现,琢磨琢磨. 回到正题.

其实想起俩东西也是今天用ipad在网上找歌时的感受, 如果ipad能像ktv那样点歌, 甚至可以代替部分ktv的功能该多好.比如,选择歌曲并录下你的歌声. 然后bang!发布到网上, 供好友们共享.

如果把ktv这个东西拨开, 这个idea的本质无非是语音共享, 类似podcast, 这是这个podcast更private, 更偏下局部社交. 另一个问题是: 除了真正关注你的人, 谁会耐着性子把你的天籁听完呢?在这个耐心匮乏的互联网上, 有人会花2,3分钟时间听你把一首歌唱完吗?

当然, 可以引入打分机制之类的增加用户黏度的措施. 但???

于是乎, 提供这个服务的人觉得 – 要不我把平台搭建到所有的ktv???(看看现有的ktv糟糕的点歌系统, 这一点应该也不是什么难事), 最终达到用户无论在哪里都能和ktv中同步. 想象一下, 你们一伙人在某ktv高歌, 这时传入一条消息, 某出差在成都的哥们, 传入一首刚刚学会的四川话版<没那么简单>, 甚至留言说刚刚A姐唱的实在是太好了, 已经在微博上转发了一大圈了…..wow

That’s it. EOYY

会议是最糟糕的打断方式

下面这段话引自<rework>, 对会议的评价, 实在太给力了..送给那些在会议中打瞌睡和让人打瞌睡的人们.

会议是最糟糕的打断方式。原因是:

通常会议只是文字和抽象的内容,没有实质。

通常会议每分钟只传达出极为少的信息。

人们在会议中容易跑题堪比暴风雪里的芝加哥出租车。

会议要求做充分的准备,但是大多数人没有时间做这个。

频繁的提出模糊的议程而没有人能真的清楚目标是什么。

常常会出现至少一个傻瓜不可避免的,毫无意义的浪费大家时间。

会议会繁殖。一次会议会导致另外一次,再生出下一次……

微博的能量到底多大

最早对twitter的感觉是: 这个鸟东东到底是干什么的? 有个毛用啊?  以下”twitter”适用于所有microblogging

个人的感觉, twitter是个web2.0的终点 — 无论是用户创造的内容, 还是供用户消费的内容, 最终都会汇入到twitter的洪流. 而twitter提供给用户的是定制的订阅, 这一点很重要, 否则用户会被淹死的. 可以理解为, 站点的水汇入twitter, 而twitter提供个每个人将这条江里的水引到自家门口的可能. 那么之后呢? 用户在消费了自家门口的水后会决定, 去水源点看看或者在多引一些水来.

尴尬的是twitter的位置, 它更多的是一种类似基础设施的东西, 也是为啥到现在twitter仍没找到自己如何从这中间赚到钱的原因. 比如twitter曾惩罚那些他们觉得不合适的水闸厂商, 想要自己帮用户来引水, 这样他就可以知道用户都喝什么水了. 显然这是在破坏它好不容易创造出的生态圈. 迫于生存的压力, 它需要不停的尝试. 我倒觉得, 作为基础设施应该是培养生态让更多的人能参与去挖掘, 而不一定要自己亲自来. 赚钱是迟早的事情.

twitter让人与人之间的交流变的近了许多, 说实在的, 自从开始用twitter, 我和一些多年不联系的外地朋友交流更多了, 而且也更有效更有持续性.

twitter要做的另一个工作是保持水质, 避免让自己变成一条臭水沟.

近期找工作的一些总结

最近的找工作算是有了一个结果. 投了4家公司, 除了一家拒了之外, 其他三家基本都有了offer. 拒我的那一家其实本身我的激励就不足, 因为这家公司没有什么让我心动的, 纯粹是看到老东家的很多同事跳到那里, 所以就报个试试看的态度而且职位也说实话有点不靠自己的谱(SD). OK. 说说另外三家. 这次求职过程和以往不太一样, 可能在别人看来早已司空见惯.

1. 简历能让人看下去

简历可以说是第一步, 也是最重要的一步, 如果简历都无法通过, 那么人再牛也是浮云. 简历的版式和编排其实还是很重要的,Joel Spolsky在他的一篇blog里以他的筛选简历的经历指出了简历细节的重要性 – 首先要让简历能被对方看下去. 不要犯低级错误, 比如把对方公司的名字写错. iweekly的招聘广告中也提及”简历的美观很重要, 从中可以看出作者的是否用心,条理性”.

2. 光有简历还不够

以前都是直接把简历作为附件发出去, 让对方仅仅从一份简历中提取出全面衡量一个人的信息还是不够的, 应该尽量提供一些详细的资料, 比如facebook主页让别人了解你的信息和交友,linkedin主页让别人了解你的人际情况和履历甚至是微博id/豆瓣id/blog这些让别人能看到平时的你. 如果有一张有特色的生活照就更好了. 
有些公司确实只看简历, 通常说明这样的公司并不看重人, 对这样的公司来说 你只是”一种资源”, 而不是”人”, 一般这样的公司都是沦落到找猎头来帮自己找人.

3. 拿出激情来

因为这次的三个公司确实是自己一直都想去的, 所以除了简历以外, 各写了一份关于对方产品的一些想法,甚至是一个设计草稿. 而且在简历的最开始都有一段为什么选择对方的理由. 以bx为例, 同样一份简历, 年前只是发了简历, 一直没有回音, 而年后除了简历还附加了一份survey, 结果第二天就收到了面试通知. 
有了激情和想法, 才能为后续的面试设定一个有利于自己的context, 相对来说, 对方很多时候会围绕你设定的context来考察, 而如果没有, 那么context就是有对方来设定, 就会比较challenging了.

4. 哀兵胜算大一些

丢掉想赢怕输的包袱, 我只是来看看自己是否够格, 不够格找到差距下次再来就是了. 还是激情, 如果真的有激情来, 一次不行就再来一次!

5. 做好准备

如果对方提让你提一些对产品的建议而你却一无所知, 那就只能被减分了, 而如果不仅能知道一些细节, 甚至能有一些改进的建议, 那绝对是加分的.
此外一些常见的面试问题, 就不用多说了, 尽量做一些准备. 这里有一些常见的技术面试的题目, 这次db的面试中还真有一道, 可惜之前还没有完整过一遍, 幸好并不是特别难, 当时也搞定了.
在面试之前, 专门把数据结构的一本书拿出来复习了一遍.

再补充吧, 先写这些. 

x200换硬盘数据备份恢复全过程

这里不记录全过程, 只记录概要的. 留给自己或其他需要参考的朋友.

原配硬盘的两个分区经常变为只读, 而且重启后需要自检. 严重影响到使用, 网上看了一些貌似是磁盘有了坏道. 数据安全起见还是换个新的硬盘吧!

重装太麻烦, 系统又没坏, 还可以用. 参考网上有个朋友用Acronis True Image Home的经验, 觉得靠谱. 决定用这个. 下载安装, 你懂的. 我用的是2011.

第一步: 将系统盘[分区备份]到移动硬盘, 或者就备份到原有硬盘的某个分区. 也可以把其他分区同样备份.

第二步: 激活acronis的启动工具, 这样每次启动windows时候可以选择用acronis启动

第三步: 把旧硬盘装到usb硬盘盒, 安装新硬盘

第四步: 配置bios使用usb boot

第五步: 插上装有旧硬盘的硬盘盒启动, 选择进入acronis

第六步: 选择recover, 把之前备份的文件recover到新硬盘的主分区 (在这之前要给新硬盘分区)

第七步: 同样道理recover其他的分区到对应的新硬盘, 我的某些分区是不需要这样recover的, 之后还是copy到新硬盘的.

第八步: 拔掉旧硬盘, 重启. 完成.

周一更新[想看]为[看过]的应是深度豆瓣用户

也许豆瓣可以挖掘一下这样的用户. 看我的猜想是否正确.
有这样的行为的人, 可能还有其他一些特质, 比如, 上班族, 平时比较忙, 喜欢分享,可以顺带挖掘此人的sharefeed, 进而发现他的喜好.
然后知道这些以后豆瓣可以做什么呢? 也许可以根据所从事的职业和城市, 分析此人每天上班必经的路线(比如地铁, 或者某条路)
进而将想要给他看的东西 flood 到”指定地点”
wow, 这是作恶吗?

java程序员的集合使用误区

ArrayList用到底, 其他选择 LinkedList, set, treeset,stack 关键是你要解决什么问题
一直以来, 在没有什么特殊情况下, 只要是元素数量不确定, 必然会用ArrayList. 除了增加了变长的特性外, ArrayList本质上就是个数组.
因此在创建ArrayList时应对其中要存储的对象数量有个估计, 否则经常性的扩容操作和remove带来的下标移位操作会影响程序的性能.
如果需要经常性的删除, 可以考虑hashset. 当然hashset不支持随机访问, 只能通过遍历.所以要根据需求来决定.
Linked***和其他集合的区别基本就是底层实现用链表和数组的区别. 链表和数组的区别请自行翻阅课本.

HashMap不指定size
由于HashMap的实现也是基于数组进行散列, 所以同样存在扩容时的性能问题. 所以尽量要指定合理的大小和factor

鄙视(膜拜)数组
最原始意味着最好或最坏, 每个人的看法都不一样. 数组的局限在于它是定长且只能是一种类型(java中).(当然你可以声明Object数组然后放任何东西, 但相信我, 你很少需要这么做)
通过下标访问数组元素是最快的
如果是频繁的数据访问, 计算(比如位图处理). 建议还是用数组, 最简单最纯粹也最高效.

随意使用concurrent
当发现HashMap存在多线程修改的情况时, 会立刻Map m = Collections.synchronizedMap(new HashMap(…));
实际上很多时候应该在集合操作以外保证并发的情况, 当然这里再加上一道也更稳妥,但能不用就不用
小心集合类的垃圾回收陷阱
集合对象如果没有设置为null的时候, 其中所有的对象即便设置为null都是无法被回收的, 因为集合仍然有该对象的引用.
所以当使用集合对象时 要记得集合中对象的生命周期, 以免造成泄漏.

参考:
深入Java集合学习系列:ArrayList的实现原理-http://zhangshixi.javaeye.com/blog/674856
深入Java集合学习系列:LinkedHashMap的实现原理-http://zhangshixi.javaeye.com/blog/673789
深入Java集合学习系列:LinkedHashSet的实现原理-http://zhangshixi.javaeye.com/blog/673319
深入Java集合学习系列:HashSet的实现原理-http://zhangshixi.javaeye.com/blog/673143
深入Java集合学习系列:HashMap的实现原理-http://zhangshixi.javaeye.com/blog/672697