标签归档：豆瓣

为什么感觉豆瓣在走下坡？

发表于由
回复

知乎上的一个问题：http://zhi.hu/WhTD

—–

豆瓣的问题在于它太过偏执于“长尾”(1) 和“自发秩序”(2) 了。

如果你仔细看，豆瓣的大部分产品都遵循类似的思路：首先满足用户的“长尾需求”，再想办法把同质用户汇聚成组，最后相同兴趣用户的组内行为可以形成正反馈强化整个系统的运转。当然，具体到实现这个流程的方式还可以再细分，比如利用算法的（FM）或者利用社交网络（小组）来分组；“组”的概念比较弱的（书影音用户利用友邻关系和猜你喜欢形成的“隐性组”）或者形式感非常强的（小组、九点、广场、阿尔法城）。

大体上讲，虽然单个产品各有成败，但沿着这个思路去解决用户的“长尾需求”是没有大问题的。

问题在于豆瓣把这个思路贯彻到了偏执的程度。于是就有了不断重复的广场、部落、阿尔法城这些“自发生长”的理念高于用户实际需求的“玩意”，以及在有热点的垂直领域里也偏去玩草根 provider 和 consumer 的小圈子——读书的征文比赛、音乐人、同城的小型演出票务（可惜没有一个的草根电影人圈子，不然就圆满了）。甚至在运营、推广层面也践行“不运营，自生长”的策略 (3)。

但是如果按照长尾（帕累托）分布不严谨的表述“20/80法则”来看，费了这么大力气满足的可只是20%用户（对长尾里80%事物）的兴趣……

当然这其中有一些美好的假设，比如从长尾中涌现80%人会感兴趣的热门内容。的确，豆瓣里也涌现出了“失恋33天”这样的 case，但是最终把握住这些 case 的可不是“不运营”的豆瓣。至于《长尾理论》里暗示的“随着互联网的发展，用户数量/兴趣曲线会变平缓，整体长尾化”也好像并没发生。

回到问题“为什么感觉豆瓣在走下坡”，“感觉”两个字用在这里很好。豆瓣也没走下坡，书影音评论这看家的东西不还好着。只是这些年早前就不关注长尾而是玩热点的别人家已经把制造热点这个事情玩烂了，现在都去忙移动互联网和穿戴计算了。而豆瓣还在这儿纠结“长尾”和“自生长”纠结了六七年了，自然让人有种不进则退的感觉。

一定要说个原因，大概就是世界不是豆瓣想像的那个样子吧。

1. 长尾年代，http://book.douban.com/review/1095674/
2. 豆瓣是一座仁者见仁、智者见智的城市，http://www.douban.com/note/12053438/
3. 杨勃：豆瓣社区不运营 用产品来表达，http://tech.163.com/…

修了一下Mp3tag的豆瓣数据源脚本

发表于由
15

2015-05-02 近期可能会整理一下 github pages，如果 2011-01-24 的链接 不能下载，试一下：http://sakinijino.github.com/tools/douban4mp3tag/Douban.com.src

——————————————————————-

2011-01-24 更新：把脚本挪到github上了，下载链接：http://sakinijino.github.com/douban4mp3tag/Douban.com.src

——————————————————————-

这东西是啥，以及yoyicue开始的版本见这篇blog。

这个版本失效有一段时间。今天终于不能忍了，就修了一下。失效的原因是豆瓣图片cdn的域名变了，改的时候就顺便把对域名的依赖去掉了。

猛击这里下载，用法之类的见前面提到的那篇blog。

ps：mp3tag的脚本也不是一般的难用。。。连个try都没有，orz。。。

当天晚上的更新：基本把解析和抓取重写了（脚本太弱，文档又不清楚，所以代码写得超迂回，囧），稳定性和准确度都比原来强了很多，建议之前没看到这个更新的都重新下载一下。

另外和原作者联系了一下，在原作者的google code上也放了一份——beta 1.5版本那个。

豆瓣API: One Year Later

发表于由
3

正好是豆瓣API发布一年的时间。之前有打算写一点总结性的东西，可最近很不在写字的状态里——有好几篇东西都是开了头就进行不下去了，所以这里也就只能流于简短。

过去

写这种东西，往往都脱不了回顾过去展望未来的路子。回顾来说，过去一年里，还是很happy的看到豆瓣API从一开始比较简陋的书影音只读接口，到现在基本上覆盖豆瓣主要功能的很成型的东西。

这里必须要感谢大头鱼、davies和subdragon在Server和Client两端工作，没有这些努力，所有东西都只能是纸面上的空中楼阁。

还要感谢所有关注豆瓣API的豆友们。特别是其中那些使用API的开发人员，Meaglith、wu yuntao、Livid、刀马、EmilMatthew、MJiA、Hooopo、tsing、14、狮兄、bc1998，排名不分先后。我相信我一定忘了谁的名字，不过一定原谅我，因为这绝对是我越来越老，记忆力越来越差的缘故，我对所有人的感谢是一致的，因为没有你们的应用，API的工作没有意义。

接着说一点遗憾的事，虽然从06年刚接触豆瓣的热情，到07，再到08一路经过，我自己对于API的预期和动力都已经消磨了很多，但即使在这种情况下API流行程度还是低于了我的预期。这一部分是源于我们工作的不成熟，比如API入门门槛还是有点高，虽然我们也进行了一些工作试图改变，但总得来看降低API的上手难度仍然是有很大空间来做的事。另外不得不说在这块神奇的土地上，大家的生存压力如此之大，比之海外无偿的第三方开发工作需要更多的付出。理解这些，我也就更加感谢现在这些开发人员。

未来

即使在寒冷的冬天，未来仍是让人向往的。豆瓣API的第二年，依照自己的想法，希望豆瓣API会在以下这些方向上继续前进。

首先是开放更多可以通过API使用功能，包括相册、豆列、留言这些功能，而online、artist这些还在演化中的工作，随着他们的完善，也会早日将他们纳入API的范畴。总之为开发人员提供能力更强，更能激发创意，更有施展空间的接口。

其次是API的推广，这个可做的事情很多。而我目前最想做的是提供更好的应用展示平台。如今的豆瓣API还是有一些很“产品级”的应用的，然而因为现在缺少展示平台 ，应用的传播走的还是小组推荐这些很豆瓣很草根的方式。并不是说这样不好，不过既然大家在这么大的生存压力下辛辛苦苦花了很多时间来做应用，那么专门的页面总是应该有的吧~~

最后，我个人的希望是可以把API更好地适用于插件小组。API小组和插件小组基本集中了意愿为豆瓣做第三方开发的全部草根力量。然而插件小组从我建组，到NP同学接手过去，一直在fx gm的路线奋勇前进，大部份工作和API全不相交。这有点脱离我当初希望做API来帮助插件开发的本意，接下来的一年里我希望这两个小组可以有更多的交集。

结语

说是流于简短，写起来真是很多废话。其实文字絮絮叨叨是我的特质，难免让大家厌烦了。

总之最后还是要说很感谢所有人对于豆瓣API的努力和关注，真的很感谢。

题外话是2009年，我要好好读博，天天向上，努力在2011年毕业，囧~~

No Country for Old Cats

发表于由
2

写点感情，也许语无伦次，也许你不知道我在说什么，不过我想很多话语不必那么有伦次。

我早知道会有最后一根稻草，不过我没想到的是这稻草是3.16被解散——据说是因为被冷组举报而解散。其实我从来不混小组，对于3.16也是隔三岔五地去扫一眼，恶趣味地看看有没有新的代目。然而它真的被解散的时候，这根稻草还是让我发现了一些长久以来隐藏的变化。

很久之前，因为要整理自己的读书计划而上这个网站。然后深深地喜欢上这个网站，因为她是那么special。

很久以前，曾经会花上几个小时，翻她给我的推荐。曾经会很高兴发现和我志趣相投的人。曾经因为自己写的评论上首页而happy。

很久之前，曾经真心希望这个网站变得更好。所以才去建插件小组，所以才写那些脚本，所以才会来做api——因为那个时候那样会让它比其他国内网站更酷。

很久以来，都刻意保持和这个团队的若即若离。因为飞特——我注定是个飞特，但也因为始终希望让自己始终是个“用户”。

然而，很久之前，我熟悉她的方方面面，而现在很多功能我从没用过。

很久之前，我不用翻上10页才知道友邻昨天读了什么书、写了什么评论，书影音在导航栏的前部，猜你喜欢在首页，评论在首页，豆列很容易找到，热榜很容易发现，有一个七嘴八舌的站务论坛，没有从来没用过日记、同城以及广场。

很久以来，每一次变化都会有人口诛笔伐，我不解地看着那么激烈的言辞，以至于让我没有注意到每一次被边缘化的都是对我重要的东西。而我也忽略了从自己那里溜走的小情感。

很久以来，有太多各种各样着边际或者不着边际的评论，评论这些改变到底是对是错。也许我也可以评论，或者或多或少评论过。不过真是可笑，又有谁有资格去评论别人呢。所以后来对于变化的一切，我都会说我理解。虽然我其中很多我没有接受。

于是就有了稻草。一个存在了年余之久的小组，最后因为举报被解散掉，理由是安全，这真有点喜剧。然而3.16并不重要，重要的是，或者说可悲的是3.16可能是唯一还让我还觉得这个网站special的东西。而现在如果她还有一些不普通，那也是和那些我经常上的网站一样的不普通。

“1个喜欢这个网站的用户，或者3个经常上这个网站的用户”。在这个世界里，也许很容易选择。我理解，虽然我可能是被放弃掉的遗老遗少。

也许对于双鱼座的人来说，很多很多事都像谈一场恋爱，或者搞一场暧昧。规则是你不能说爱，否则死无葬身之地。可惜对于豆瓣，我说的太早太早。于是我是注定被淡掉的那一位。仅此而已。

从前我来这里是为了读书。现在读读书才是正经事。其他的，对不起，我只是出来打酱油的而已。

豆瓣上的朋友数量呈螺旋上升趋势。。。

发表于由
回复

原来一直全是认识的人，数量也很稳定。前一段各种各样的原因加了好多人，一下从40+到50+，突飞猛进。

然后吧，经过这几天的努力，这十来个人里几个原来不认识的也都变成认识的人了。其他除了已经认识的，还有若干原来我就认识，然而加朋友的时候完全没对上号的人，这两天也都对上号了，我好囧rz~

估计接下来一段，朋友数量又该稳定了。。。螺旋上升，螺旋上升~

一个基于AIR的豆瓣API应用演示

发表于由
2

花了两天研究了一下Ajax based AIR实做，和想象的复杂度差不多，不过没怎么用到高级功能。顺手试了一下mootools和git，全都是复杂的东西。。。还是jquery大爱。。。

个人收藏浏览。纯粹学习加演示，没什么实用价值。

前提需要装Adobe Air Runtime才能用（到这里装：http://get.adobe.com/air/ ）

程序下载在这里：http://douban-collection-explorer.googlecode.com/files/Douban%20Collection%20Explorer.air
https://github.com/sakinijino/douban-collection-explorer/raw/master/bin/Douban%20Collection%20Explorer.air

程序源码在这里：http://github.com/sakinijino/douban-collection-explorer/tree （Git好复杂……）。比较有复用价值的就是OAuth认证的部分，自以为我封装的还可以，两个页面加一组js类，有需要的可以直接拿去用。（经27同学提醒，想起来其实还没搞定sha1加密，所以最后用的Plaintext，囧。。。）

图和真相在这里：

Lost in SNS

发表于由
回复

现在再在blog中大谈SNS、Facebook不免是跟不上潮流的嫌疑。不过在年前把近半年多所有的思路汇总一下，也为明年（农历）做个备份。

去年底（公历）的时候读了FOSE07的论文集，其中一篇关于Web Trends的论文谈到Search、Tag、SNS、Collaboration是现在每个Web2.0网站的infrastructure，而也许可以将这些东西抽象出来形成一个Web Oriented Middleware。当时并没有对这个说法太感冒，因为Middleware这个说法的直观印象还是WAS、Spring、RoR这样的东西。后来讨论的时候联系到Facebook F8，发现了这个说法的味道。实际上Open之后的Facebook已经是可以算是Service形态的SNS Middleware了（当然如果你不习惯的Middleware这个说法，你也可以换成OS什么什么其他的，总之这也不是什么新观点了）。

从这个角度出发，Facebook或者说SNS将会是互联网中的infrastructure。一定会出现SNS巨头（可能是Facebook也可能是其他的），因为对用户来说社会网络建设的成本很高，没有必要用户不会重复建设。如果我们注意这些年涌现出来旨在满足实际需求的实用性网站，例如blog、delicious、flickr这些，存在一个很明显的特点是这些网站都是个人向网站，也就是说这些网站提供的功能都是面向个人的（书签、相片），简单的说就是可以自己玩（i Age, aha~）。虽然这些网站也存在自己网站范围内的SNS（Group功能），但是这些功能只是锦上添花，没有的话用户一样可以用得很好。然而相比之下解决实际问题的群体向网站非常少。这些网站旨不在创建人际关系和交往，而是旨在方便特定领域（小领域）中已经存在的人际交往过程，简单的说就是解决大家如何有效地一起玩（并且一个人玩不了）这种问题。而这类网站面临的很大问题就是SNS如何初始建设，因为面向小领域提供精致的解决方案，所以新用户登录到往往面临一片白地，而这时他们最可能的不是到处发email给朋友邀请他们，而是下线。但是这并不是说群体向的网站没有需求，相反的我觉得这方面的需求可能比个人向网站还强烈，毕竟人是社会性动物，而网络天生为交流存在。

回到SNS，现在的Facebook们还没有充分发挥SNS的威力（用户往往为交际而交际）。当然在一定层面上发挥SNS的威力也不是Facebook们的职责。这一职责应该由更专业聚焦在更小领域的实用性群体向网站来解决。在SNS巨头的帮助下，这些群体向网站的用户可以快速构建出自己在这些网站内部的社会网络，从而跨越起步的门槛。进而享受这些网站给自己社会生活带来的便利（就如现在的个人向网站为个人生活带来的便利一样）。（造个词，we Age，大抵如此~）

最后又扯一点豆瓣，和主题关系不大。豆瓣原来是个人向网站，现在有点开始向SNS转型的意思。其实不知这个比喻是不是合适，豆瓣现在的发展有点北京城发展的意思——摊大饼的思路。豆瓣原来关注的是书影音这个特定领域下帮助个人解决问题。现在随着用户的增长，从原来的起点向外，饼越摊越大，功能越来越多，新功能又和旧功能关系不大，发展之下就是新功能必将影响老用户。好比北京拆胡同盖楼（好比个鬼。。。我自己都觉得不能这么比。。。囧rz~），就算楼房生活条件比大杂院好，问题是有一帮人“我就不适应，我就不适应”，何况和一些XX的老四合院比楼房未必好。

说到这里，再我说说理想中的互联网公司形态。这应该是大公司和小网站集群的样子。公司可能大，但是手里的不是一个巨无霸的网站，应该是一系列有一定内在联系的小网站的集群，每个小网站的功能都能用一句话说清楚（我对好网站定义的必要条件），而且各自都是独立品牌，同时公司整体又是一个大品牌（37signals~ 喵~）。其实豆瓣和9点的关系就挺好的，也许将来豆瓣也会是豆瓣SNS和豆瓣书影音吧，谁知道呢。特别说明，上面包括豆瓣、北京城和理想公司形态的部分都是随手写的，没什么太多根据了，全是妄言罢了（自己未来看了也不要喵之）。

总之的是年底的时候把思路理清楚，明年自己会依这个想法走下去就好了。

p.s. 这篇的tag都是大词呀。。。

豆瓣，朋友推荐和猜你喜欢

发表于由
回复

关于豆瓣朋友我最大的发现就是原来许多我认为不上豆瓣的人一直在上豆瓣（他们第一时间加我为朋友），另外就是许多我以为一直上豆瓣的人没上豆瓣（当然我不排除他们没看见那个提醒）。

下面随便说说，其实是把昨天和人聊天的内容整理一下下（整理完发现已经不是一个东西了。。。）。

如果豆瓣想做的是“帮助每个人发现适合自己的未知事物”，那么需要关心的有两方面，如何进行“发现和推荐”，以及发现和推荐哪些“事物”。对于“发现和推荐”，广义来讲无外乎两条路：基于算法的、基于人的。世界之初，豆瓣最赖以的是基于算法发现和推荐书影音，品牌是“豆瓣猜”。然而从07年中广播上线到最近在短期之内连续上线了“统一推荐”和“朋友”，如果豆瓣的主旨没有变的话，那么也许可以理解为在积累了大量人气之后，豆瓣认为自己可以也开始发展并完善基于人的发现和推荐了。毕竟正如很多人所持的观点，在拥有如此数量并且高素质的用户群之后，既期从中挖掘一些SNS的优势实在非常直观的事情。

但是这里依然存在一个症结。正如前面所说的两方面问题，“发现和推荐”只是手段，“事物”才是实体。所以这里存在的问题是，基于人的“统一推荐”和“朋友”到底要发现和推荐什么？

豆瓣的看家领域书影音里基于算法“猜你喜欢”的发现和推荐机制工作良好并且非常成功。不过这种成功的原因之一，正是因为“朋友”往往不是“和你口味最像”的人，所以很大程度上最适合进行书影音发现和推荐的方式就是“猜你喜欢”，“朋友推荐”不过是蛇足而已（特别的，豆瓣现在的推荐还不是点对点推荐的。如果我向我所有的朋友推荐Touch、Kino和Mushishi，那么其实这更像是告诉他们我喜欢这些而不是推荐）。对于书影音衍生出来的评论，同样的，如果我对那本书都不感兴趣，你给我推荐评论干什么。。。

豆瓣9点也一周年了，9点的内容在一定程度上是适合进行“朋友推荐”，然而9点的问题是他不符合很多人的阅读习惯。相对于9点Rss Reader和Search Engine是普遍的阅读入口，从这个角度说twitter现在比豆瓣广播更适合完成推荐网文的任务。所以9点推荐更依赖于一些重度豆瓣用户。（另外一点点，相对于其他实体，网文推荐的容错级别很高，所以9点推荐的语义其实不是你可能喜欢，而是你可能需要读一下，不论你认同、反对还是不感兴趣）

豆瓣同城。如果豆瓣能支持一些更复杂的活动形态，那么它可能是可以依赖于“朋友推荐”的。但至少现在用户对于豆瓣同城的理解可能更偏向于SNS中的基础设施，他们更多地是使用豆瓣组织而不是发现活动。另外就是豆瓣已经把活动抽象到可以进行算法推荐的级别了，这说明即使在发现这一方面豆瓣还有一半想的是“猜你喜欢”这条路。

直白一点来总结，豆瓣也许已经创造了一条发现和推荐的新途径，但是现在看来这还不过是一项“屠龙之技”。那么“龙”在哪里呢？这里只有一些简单的想法。“龙”会是一种与书影音完全相反的东西，书影音有一个很大的特质，你喜不喜欢一本书和你的朋友完全没有关系。所以“龙”的最根本属性是你喜欢与否很大程度上是由你的朋友喜欢与否决定的。这会是个什么东西呢？某种你去我才去的活动？某种你感兴趣我才感兴趣的东西？好吧，这么复杂的问题，猫不思考。

豆瓣活动 & 长尾宅猫

发表于由
1

本来想写一点长的合逻辑的文字，不过还是算了。把想法罗列一下而已，有点对不起这个标题——当然其实标题是“豆瓣活动 & 长尾”，宅猫是我。

首先，无疑问的，活动是个长尾。但是这个长尾和豆瓣原来所做的书影音很不一样。其中最大的不同，长尾中的书还是书，然而长尾中的活动，每个和每个之间的形态相差太远了。公司同事的聚餐、画展、旅行，虽然这些都可以按小学作文所教的用时间、地点、人物、事件来描述。但是在稍微细致一点的层面他们差距太远了。例如聚餐最简单，但是也完全可以靠吼辅以短信来处理（也更有效，即时性强）；画展要明确区分组织者和参与者；而旅行最复杂，好的旅行活动需要包含大量形态各异的数据。

而另一个问题，参与一次活动的成本比看一部电影大太多了。所以对于我这种宅猫来说，我不会像我收藏电影那样疯狂收藏活动。所以本质上我可能不关心豆瓣猜我可能喜欢参与什么活动，我需要的是将我现在的活动管理好。

从这个角度来说，好的活动网站最需要的不是现在豆瓣最擅长的那些收藏、推荐、过滤的功能；好的活动网站应该提供的是针对一种长尾里的活动，提供最全面细致好用的管理功能（这更很难做）。现在豆瓣活动泛化了活动的概念，这让活动贴近豆瓣中书的概念，不涉及流程而用通用元数据表达，这方便它做它最擅长的那些，但是想象一下如果要用豆瓣活动组织一次旅行或者球赛多么困难……

相信豆瓣还是很想把活动作为一个长尾来处理，从挖掘出我感兴趣的活动。然而泯灭了活动的差异之后，以及从而导致的实用性问题，使这个长尾被压缩过的“伪长尾”了。挖掘之外管理功能的薄弱（本质上就是邀请、讨论和消息黑板），这样下来直观的感觉，豆瓣的活动里可以处理的两种活动：参与人员松散、计划性不强、流产几率大的活动（线下聚会）；单方面组织的活动（展览）。而对于任何元数据复杂、涉及流程的活动，用豆瓣活动来处理都是不方便的。

当然这里还有更根本的问题：选择做针对特定种类活动的网站，面临推广和用户来源的问题；选择做活动平台，面临活动泛化而难以实用的问题。

至于解决方案呢？其实facebook已经教给我们，但是国内谁来开放平台呢？