这是冯大辉的博客中的一篇文章，看看之余我也在剖析自己的内心。我是该继续做开发，还是转行做产品？
虽然我对产品的理解和设计暂时还不如那些专业的产品经理，但是从事互联网这么多年，没见过猪跑总还吃过猪肉的吧？
OK，先上原文，再继续乱弹，原文来自： 对 Pinterest 类应用的一点思考
最近一段时间 Pinterest 类应用相当火爆，引发了不少讨论。我自己最近也一直在使用花瓣 ，也在捉摸为什么这一类应用这么有魔力。知乎上有个问题是: Pinterest 好在哪里？，尝试做了一下回答，也稍作整理，发在这里做个记录，会随着理解再做进一步修改。
本质上，Pinterest 类应用属于社会化书签站点的延续，只是要处理的数据对象变成了「图片」，而不是传统社会化书签的URL。这是社会化信息处理的一次改良。
提到社会化书签，不得不提 Del.icio.us ，不过或许 Del.icio.us 模式已经到头了，即使现在从Yahoo! 手里卖给了陈士骏，也不太可能玩出新花样，因为核心的数据对象没变。
相比 Flickr 来说，Pinterest 主要的生成内容动作是 Pin (花瓣叫采集)，而 Flickr 则是 Upload，这个动作上的不同导致 Flickr 向左，Pinterest向右。Flickr 重心是「照片」(Picture)，尤其是原创照片，而非图片(Image)。 Flickr的一个弊端是大量的图片没有标题，这意味着元数据的先天不足，不太可能和其他网络内容进一步结合起来。但是也要说一下，Flickr 现在的价值是被低估了。
Pinterest 相对 Flickr 来说，恰恰是一种互补，每张图片基本可以关联到一条URL，进一步可以抽取其他信息。
从用户行为的角度上看，满足了用户天生的「收集癖」，很多人都有看到一张照片想顺手存起来的冲动，没有Pinterest这类产品之前，这个交互操作太费事了... Pinterest 无疑弥补了人的这个原始的需求。
Pinterest 类应用的创新之处我认为是「降低了收集信息的门槛」，或者，至少做到了这一点。其价值是不言而喻的，每一次信息处理的门槛降低都会得到商业价值的变现，你可以不信。
要有足够好的技术团队支撑、足够好的数据处理能力才能走到最后，这也是在国内众多产品中我看好花瓣(huaban.com)的主要理由。
--EOF--
目前现在很多网站都在做Pinterest正在做的事情，而且由于国内广大网民（非设计师、程序员、产品）接触国外网站的机会比较少，因此，这些有创意的复刻版在国内就变得很流行了。
说到美味书签，真要算的话，国内其实也有很多做类似的，只是很多人都不习惯它的使用方法。但要说他死了？也不见得，毕竟书签有很多展示方式，比如：read it later，难道就不能算是一个书签？它也能够通过API的方式来对外分享，而且正因为提供了API，使得在任意平台上都可以支持了read it later，越往后，书签就越来越趋向于移动设备的支持，但移动设备的屏幕小，不适合看书签收藏的网页中提供的内容。所以read it later提供的纯文本阅读，就使得这个缺陷被无限缩小了。
象Pinterest这类网站，还真的不好说能够在移动设备上占优势，流量啊，那可是要钱的东西，you know.
在直接引用外部图片的时候，经常会出现，该图片来自于XXX网站，请勿盗链
找了一下资料，发现只有几种方法可以解决
1、JS，HTML里嵌入iframe，然后类似地打开一个网页的形式，使得页面认为已经访问过主体网站，所以可以解决防盗链
2、如果页面中的图片是：/xxljaslkdjf/xxx.jpg，而这个图片事实上来自于：xxx.xxx.com网站，这时候在页面的<base >TAG里设置一下，就不需要全文正则替换图片了。灰常方便。。。
3、设置HTTP_REFERER，这个有点麻烦，不是每个站都支持。。。
4、在页面中放置一iframe，地址就是主体网站。然后等访问完成后302跳转到真正的页面，图片就能正常了
5、用URL转发的形式，如：image.php?url=image.path.jpg，通过这种方式，几乎解决了很多问题（但，不能走CDN了。真可惜啊。怎么办呢？？生成本地图片后，再由CDN转发？不太现实）
基本上就上述的方法了，如果你还有新方法，请告知
MD，在页面里，只要有5个连在一起的数字，就会被自动加上了链接。这个数字会被浏览器自动认为是电话号码。
这个问题真的很纠结，好好的文章突然变得全是链接，放在谁身上谁也不舒服啊。
但是否能解决呢？原来在4.3的时候是可以的，但新版的IOS却反而没办法了。
原来的版本只要这样：
<meta name="format-detection" content="telphone=no" />
可是现在都不可以了。
而且，现在网上找到的资料，都是上面那句话。也没有更好的办法来解决它。
除非象支付宝那样用恶心的方法：
<button class="t-balance" style="background:none;padding:0;border:0;">95009.00</button>元
转成类似于button的办法，让safari不能给他加链接。。。
但没有什么更佳的方法。郁闷
看到这篇文章的时候还是挺感兴趣的。
几年前，微软出过一个实验性的搜索叫做：人立方，但没有更多的接口和参数。虽然很早之前SNS的建立依据就是每六个人就会通过各种关系认识。人立方却不太一样，他是基于很多的内容搜索来判断他们之前是否有关系，虽然不是特别准，但多少你会发现其实原来你可以认识这么多人，表面上好象你们真没有关系，但仔细看看，好象却真的有点关系。
OK，这篇文章我看到的时候，感觉有点象这种概念，事实上，我在之前就在想，怎么样将一部武侠小说中的人物关系理理清，比如那些经典的小说，很多人在看完一遍两遍三遍后都理不清那之前的关系。比如，射雕里面的人物超多，很多人的关系也很乱，如果再算上，神雕和倚天屠龙记，这三部曲，能够在看到一个人名后把相关的人物连接起来的人还真的不多。好象现在也确实有人在做这种事情，但纯人工的太累了吧？
下面的这篇文章其实和那种开枝散叶的人物关系真的不太一样，但多少接触接触吧。。。
－－－－－－－－－－开始上原文
什么是可视化学术家族树？
可视化学术家族树是继承于微软学术搜索的，以树形可视化图形，展现学者间师生关系的学术关系查询与展示平台。
家族树的用途？
为用户提供与展示学者间的师生关系，方便用户更好的了解一个学者极其相关学者。
如何才能使用学术家族树？
1、 你需要一台电脑
2、 你需要一个浏览器，不论IE, Firefox, Chrome, Safari,还是Opera（国产的那几款如傲游，360等也可以）
3、 微软的Silverlight（银光）插件，下载地址：http://www.microsoft.com/silverlight/（什么？不知道？好吧，这是百度百科：http://baike.baidu.com/view/942429.htm）
4、 然后，然后，输入网址就可以用了。
那么网址是什么？微软学术搜索：http://academic.research.microsoft.com，不过，家族树暂未上线，请大家稍等片刻，可以先用用其它的功能，看看作为一款学术搜索平台，是不是符合你的口味呢？
下面进入正题。
Spec：
作为一个网站，或者说是一个搜索页面，一个用来搜索和展现师生关系的网页。整体架构按照网站的标准来分，可以分成两部分——前端与后端。
前端为界面的设计及数据的展示，后端为数据的获取与存储。
每一款软件必然会有自己的主打招牌，也会有许许多多的特点。成功的软件不一定什么都要做到最好，但至少要有特点。我们的特点是什么？
前端：
1、 最直观的界面布局
做数据的可视化一直是学术界的一个研究热点。当你手上有大量的数据时，以怎样的形式将其展现出来，能够让用户看得清晰明了？这个问题一直困扰了我们 许久，因为我们的屏幕大小是有限的，人眼一次性可以接受的信息量也是有限的，既然是做可视化，也不能简简单单的列一个列表出来就了事。那么该怎么做呢？在 我们统计的数据中，拥有最多学生的学者一共拥有102个学生（直接学生），这102个学生目前分布在近40个不同的研究机构（含公司与高校），要将这 102个学生与40个机构展现出来，可不是一件容易的事，尤其是对于有密集恐惧症的朋友们，你们肯定不情愿看见屏幕上密密麻麻层层叠叠的点吧？
这是去年的一张测试图，你能满意吗？这人的学生还不算很多。
下面是我们前段时间的一个版本，有没有觉得很恐惧？
不过，经过数周的共同努力，我们终于是克服了这个难题，想出了一种根据人数及其影响力与相关程度的聚类分布方式，随时为用户呈现出简约清晰地界面，不会给你的心理带来任何的密集恐惧感。相信当你真正使用时，心里应该会比较舒坦。
2、 华丽的展现动画
或许是因为基于silverlight平台的缘故，动画制作变得非常简单。而在我们的师生关系展现中，由动画带来的视觉效果毫无疑问的会提升用户的使用体验。
后端：
1、 最全的真实数据
“最全”这两字，在任何地方可能都有夸张的嫌疑，在这里也不例外，毕竟谁也不敢保证我们的数据就一定是最全的。也许许多人来使用我们家族树时，并没 有找到自己想要的信息，于是他会放弃使用我们这款平台，这并不是我们想要的结果。我们不是万能的，我们并不能猜到谁跟谁有师生关系，我们的一切数据都是有 根据的，即在大家都可以访问到的网页上说明了谁与谁是师生，只有这样的数据才有可能被我们收录。并不是说你读了谁谁的研究生，但你不告诉我们，我们自己就 可以猜到的。例如以下的作者主页里，就写明了他们的学生信息。
http://www.une.edu.au/staff/nrei3.php
http://www.math.ttu.edu/~barnard/vita.html
虽然不太好找，但还是存在的。
为什么说是最全？在互联网上，也出过不少的学术家族树网站，不过都不怎么给力，而且仅仅是针对某一领域，相比于他们，我们的数据更加的丰富。在微软 学术搜索里面有超过1000万的学者信息，其中有60多万目前我们发现了其个人主页。我们的工作之一，正是在这些个人主页上去挖掘师生关系。当然，这样能 够获取到的信息并不多，因为大多人的主页上未必会写上师生的信息。当然我们还有许多其他的数据源，如Wikipedia，Mathematical Genealogy Project等等，虽然最终获取的总量并不大，但也比市面上其他所有网站的信息要全面地多的多了。我们的所有数据都是有根据的，绝不是自己猜测的，在这 点上我们与清华大学的arnetminer走了完全不同的方向。它们是经过论文的合作网络分析出师生关系，但这种分析往往准确度不高，并且没有足够的信服 力，用户们经常会发现错误的关系，这会极大的影响我们的心情。
数据不全这是必然存在的问题，因此我们为用户提供了编辑的窗口，希望用户们能够帮助我们去填充与校正更多地数据，当然前提是用户要提供证据（比如某个页面url）来支撑填充的数据。这样既可以让他人更加了解你，也能让我们的数据更加丰富，更准确。
我们目前一共搜集了15万对师生关系对，且每一对都有其出处，如果你没有发现你，希望您能主动加入进来。或许将来某一天，当学术搜索与社交网络融合在一起时，家族树会更加显示出其用处。
2、 最快的反应速度
所有的数据都是存放在数据库中的，当数据很小时，查询是很快的，但是当数据超过千万时，速度可就没那么快了。正常的用户是没有心情去花几十秒几分钟 等待一个页面的更新的，这太浪费人的生命了。在我看来，任何搜索引擎，用户所能忍耐的极限时间，是不会超过5秒的，通常都在2秒以内。是的，既然要搜索， 那必然是要建立索引的，而我们正好就为我们的学术家族树建立的索引服务器（Index Server），所有的查询都能在毫秒级别的时间内获得输出结果。是的，你想搜谁，你就搜谁，秒搜秒看，其乐无穷。
挑战无处不在，哪怕傍着微软的大腿也不例外。学术家族树的编码阶段已经结束，现在正处在测试阶段，大约在12月底，就会与大家正式见面的。心动了吗？心动不如行动，收藏我们的博客，等待我们的Release，哇哈哈哈哈~~~
－－－－－－－－－－－－－－－－－－－
关注一下人立方：http://renlifang.msra.cn/
上面的文章来自于：http://www.cnblogs.com/rosting/archive/2011/11/27/2264758.html
Yii for sae终于提交到了google code了。
yii framework for sina sae platform. 初步实现将yii framework 移植到 sina SAE云平台。 assets目录生成到storage中，runtime则是用memcached来实现， 也因此需要激活storage和memcached。 几乎不需要改原来的代码，如果需要设置主从数据库，请另外加一个components节点：sdb，配置信息与db一样，但需增加一个 'isSlave'=>true,即OK。不过在这种情况下，所有的model都请继承SaeActiveRecord?。
配置信息中，在params里增加 'params'=>array(
'sae'=>array( 'storage' => array( 'assets' => 'assets', 'runtime'=>'runtime',
), 'db'=>array( 'slave'=>'sdb', 'master'=>'db',
)
),
);
－－－－
配置起来是不是很简单？
当前目前还是有一点问题的
- 比如对于文件的LOG暂时无法实现，准备使用memcache存储部分，等到了一定大小后，扔到storage中存储。
- GII暂时还不能在线上使用，这个有点纠结，因为GII是需要生成文件 ，而sae平台不支持生成文件。如果扔到storage中，效率又不能保存。如果扔到memcache中。include之类的又不知道是否能够完美实现？纠结中。。（生成到storage?然后下载？扔到models目录中？这多没意思，与其这样，还不如本地建好model，然后SVN上传呢）
- 好象cdbcache是用了sqlite，原本看代码里是能够自动生成的，但在线上，怎么搞呢？存到storage中又没有效率？哎。。。
不过，暂时基本功能都实现了，嗯项目地址是：http://code.google.com/p/yiiforsae/
