去年国庆期间让赵总内荐投的Google APM(Associate Product Manager)。投了也就把这事扔一边了，因为一直不知道APM是否招非应届的，所以几个月没消息也挺正常。
　　元旦之后接到Google HR电话，问我是不是投了Mobile Wireless Application Engineer，我一愣，然后明白是APM不要我，又看我背景有Mobile开发经验，就给我扔这里了。于是HR和我约了笔试时间。尽管不是想去的APM，但是至少Google本身就足够有吸引力了，Mobile也是我熟悉的方面，既然能去试试，当然是不去白不去，能弄个offer就更好了。
　　Google对我来说，吸引力在于：一，今年上海分舵就要开张了，去了Google之后就完全不用担心将来回杭州/上海之后的失业问题。二，做久了小团队小项目，也想去丰富一下大团队做大项目的经验。三，Google的工作环境可以让我吃喝不愁，同时也有不错的薪水。四，想离开技术，做些其他事情，不过这条没有实现，Google把我的应聘职位换回了技术职位，使得我还得继续和代码打交道。

　　笔试还是很让我伤脑筋的，好歹三年多没有参加过笔头的测试了，会不会写字都是问题，于是问熟悉的Googler笔试都考些啥，他们都告诉我不用紧张不用准备，去了就是，肯定会。笔试的时候拿到卷子一看，就知道他们说的肯定会是什么意思了，基本上大学学的东西只要没有全部还给老师，这个卷子就能答得八九不离十，可惜的是我还是有一门课还给了老师，导致有一道选择题不会做——当然我怀疑更大的可能是当时没有学这方面的内容，否则题目和四个选项我也不至于完全看不懂。只能蒙了个看上去更像答案的选项，然后在边上大书了“猜的”两字。其他题目都没有什么大问题，差不多20分钟就全部搞定了，然后又磨磨蹭蹭检查了20分钟，什么都检查不出来，于是交卷走人。
　　笔试后大约两周多接到的面试通知，1月31日上午10点，on site。我原以为还有一个电面，还担心这么多年没怎么说英文，听力和口语能不能过关，后来知道技术职位笔试和电面两个有其一就可以了，而且就算是电面，多半也是中文的。面试前还是很紧张的，又探听一把面试是啥样的，结果得到的答案和笔试前差不多：翻翻数据结构图论组合数学算法什么的书，忘记的记一下，就可以了，没什么可准备的。

　　前一天晚上睡觉前半小时把数据结构和算法书又复习了一遍。上午8点半起床后——这半年来第一次这么早起床——开机，然后发现赵总居然在线，于是赶紧最后打听一下，希望他帮人帮到底。先问有几道题，他说一般是每人三道，做得快就多问点，我说那我还是控制节奏慢慢做吧。又问他有什么要注意的没有，他居然说：拽一点就行了……也只有赵总这么拽的人才能说出这么拽的话来。我要是面试这么表现，肯定被踢出来了。又问题目不会做怎么办，他说：不会做就承认，赶紧让他换题。这句有点信息量，想想也是，一道题不会，本来就三题，1/3答不出，如果卡住好久，少问一道，就变1/2了，更惨，直接说不会，多问几道，那就是1/4，1/5，好歹好看点。
　　9点40到，填了表填了NDA，被领上8楼关进小屋子，今天面Mobile Wireless Application Engineer的至少我看到的连我在内有5个人，有应届也有非应届，应该是攒一块了，其中有的和我同一天笔试的。

　　10点到了，别人的小屋子里都进了面试官，我的面试官却还没来，又等了10来分钟，终于来了一个，一看就是做技术的。他说，原来安排第一个面我的人拒绝前来，临时找他来代替，所以晚了。看了他手上的名单，原来安排的第一个是Xuhui……估计是为了避嫌，就主动换人了。这个面试官感觉也是被赶鸭子上架，我紧张，他也紧张。上来就先来了个写程序的题，当时估计双方都处于混乱状态，他题目只说了一遍，我也就听了个大概，没细想就开始做了，程序迅速写完，他一看，说，咦，我要你做的是这个吗？我说是啊，难道不是吗，他说难道不是啥啥吗？我还是没缓过来，说，我这不是吗？他说，你这不是那啥啥吗，于是我恍然大悟，忙说是我太紧张，脑子没转过来。然后拿笔划掉了四五行程序说ok了，看上去他对我的改动还比较满意，这时候我开始有点进入状态了，他加了个小改动，我想都没想就在程序里插入一句话解决了。由于第一题出师不利，我就想后面干脆答快点，让他多问几题，弥补下损失，加上当时忽然状态不错，后来他连出了四题都被我哗啦哗啦解决了。我的策略是他报完题之后直接抛一个可行算法给他，然后给他复杂度，然后立刻说这个算法肯定不好，让我想个更好的，然后想一下，给个我认为的最优解。我觉得这样的好处一是不会陷入死局，好歹我有个可行解了，二是这样做的话面试官不太会主动给出提醒，可以显得我是在无提醒下做出来的。第二，三，四题都很顺利，最后一题遇到些麻烦，我给的是时间O(nlogn)空间O(n)的算法，自己觉得已经不错了，没继续想下去，然后面试官说这不错，但是有没有更好的。我故意随口说一句难道有数学方法，他也随口说了一句不需要数学方法。在这句话的提醒下我直接杀向时间复杂度，那个n是逃不掉的，再一看，logn完全没必要，常数时间就解决了，于是变成了O(n)搞定。我的这道题最终算法，以及前面某智力题最终算法可能都和面试官的标准算法不一样，因为我都讲了两遍他才承认我的算法是对的。
　　第一个结束之后等了40分钟，才等来了第二个面试官(安排如此，不是迟到)。期间我研究了一下椅子，调整到了一个比较舒服的状态，同时又把空调从30度调到了20度，免得上火。
　　第二个面试官从年龄，身材和进门的气势一看就是个老手了，坐下之后先对我的信息学竞赛经历和研究生阶段的研究项目表示了兴趣，问了一下之后进入正题。他给的是一个有趣的应用题，抛开故事情节来看，和搜索较为相关，而且是个比较开放性的问题，和前一个人的小算法题完全是两种风格。既然是开放性问题，我也给个开放性的解答，直接给他设计了两三种解决方法，然后边想边说这种哪里好那种哪里不好，这种喜欢什么样的数据，那种在最坏情况可能很坏，等等，因为其实我也不知道整体上说哪种好哪种不好，哪种是他想要的方法，所以只能全抛出来想到哪里说哪里。这时候他对我的某一个方法产生了兴趣，让我写程序，我问他能不能直接用某函数还是要实现一个，他说这东西看着你应该会写，就不浪费时间了，直接用吧。于是我又得寸进尺说能不能做个假定。他问我假如假定不成立，标准做法是什么，我就给他说了两种常见的处理方法，他说ok那就假定成立吧。这时候这个东西已经没什么可写了，总共就六七行代码。然后他继续讲他的故事，把题目变难了，提出了新要求，我说了想法之后他又提出了个新要求，这样麻烦就大了，新的这个问题一看就不容易，赶紧继续第一场的策略，先胡乱说一个可行算法再说。面试官看了我的算法说这东西复杂度不是一般的高啊，我说是啊，这个确实麻烦，于是他提醒我换个角度看看，这句话起了作用，我立刻又想了个算法出来，结果说完之后自己愣了，看上去没啥差别。他说你这俩是不是差不多啊，我想我可不能说差不多，就说新的这个好，肯定比刚才那个复杂度低，他说为什么啊，我说靠直觉，他又问，你的直觉哪里来的啊，我说，新的这个求出来的就是解了，无非是不是最好，老的这个求个东西出来还得先验证是不是正确解。后来想想这个回答很汗，因为这根本不是算法好不好的理由。不过他没追问，让我用新的这个思路继续做下去。我又想了下，给了他一个比较详细而且复杂度不是很高的实现，事实上我也不知道这个实现对不对，不过运气很好，他没有让我证明，没有让我优化，也没有给我找反例，而是让我算复杂度，有了刚才详细实现的分析，这个复杂度就很显然了。答完之后这一面就结束了，从头到尾就是一个问题不断地扩散和变难。后来想想也许我给的算法和标准答案差不多，因为假如我的复杂度高了，他肯定会引导我优化，如果复杂度低了就是错了，肯定会被找反例，如果复杂度一样实现不一样，也许会让我证明。既然什么都没要我做，那么要么是对了，要么是错到无可救药了。
　　第三个面试官上来就抛题，没有让我自我介绍也没让我讲简历，我只能立刻调整状态接镖。第一个题理论上说是个经典问题，但是我没看过也没做过，于是只能瞎说，结果不小心把面试官搅进去了，很显然，又是因为我的算法和这个问题的经典解不一样，没办法，要是这样就能想到经典解，那也太不容易了。期间他让我程序实现这个算法，在实现期间他继续想我的算法，最后我写完了讲了一遍，他终于说觉得我这个也是可行的，然后我问他经典解是什么，他说了一下，于是我和他讨论了下我的做法和经典做法的区别，并试图让他确信我的是对的。随后又就代码中某个极其细小功能的实现方式进行了讨论，因为他觉得我的实现多了三次运算，而我说我这样可以省一个变量空间(就算你可以立刻想到是什么功能，那也别说……)，当然，这些都是细节，无关大局，不过后来我发现这个程序我写了个小bug，当时我和他都没注意到。接着他又让我写程序，一个非常非常简单但是各种细节非常多很容易写错的题目，面试官也说了，这个题目不难，就是繁到家了。于是我就开工，期间瞟了他几眼发觉他在仔仔细细看我的简历，估计是最后要对简历提问。因为代码繁琐，所以我写完之后反复看了两遍，才敢告诉他我写完了。然后对着代码仔细讲了一次，相信他也没找出什么错来。果然之后关于简历内容提了一些。最后他让我提问，可惜的是，前三个面试官都不是做Mobile的(本来第一个是，可是换人了)，于是我关心的问题也答不出多少来。
　　又等了一会等到了最后一个面试官，正如我所猜的，前三个是男的，最后一个想必是女的。这时候快一点了，我已经饿得不行了，估计她都能听到我肚子的叫声。这个面试官上来先就我简历里的Mobile方面的背景进行了询问，让我说说我做过的项目，接着问了几个非常开放的问题，都是实际问题，和无线产品，无线搜索相关度很大，有的甚至是产品方面的问题而不是技术方面的，于是我猜她来头不小(事后知道是这块的tech leader)。问完这些，照常规还是做题。她问我是想写程序还是想算法，我说还是想算法吧，今天写了不少程序了。而且当时饿了懒得动笔——当然这个不能和她说。于是她就给了我一个小算法题。题本身不是老题，但是这类题基本变不出什么新花样了。在她说完题的时候我已经有了想法，而且坚信是最优的。当然我没直接说，而是仔仔细细又推敲了一下，大约一分钟左右，把算法告诉了她。结果她说：这么快就想出来了，看来只能让你把程序实现一下了……我倒，早知道多拖一会。这个算法很简单，但是实现起来并不容易，还是有很多繁琐的细节的(比如一个多路归并败者法，说出来就几个字，但是让你手写完整的就很容易错，这个题也是这样)。我先把笔放在一边，大约想了两分钟确定了实现思路，然后开始写函数，程序基本是一气呵成的，写完之后又自己做了个数据走了一遍，确定没有错误。幸好的是讲程序的时候她也没找到什么问题。这之后是提问时间，好不容易遇到一个做Mobile的，自然我要问问Google China的Mobile到底做什么。也许是最初我讲做的东西的时候她发觉我对这块技术包括市场和政策什么的都挺熟的，于是最后讲得也相对深入，我也能偶尔插上几句表达一下自己的看法。
　　出来之后，hr说可能要两三周有消息，不过让我先准备成绩单给她送去。这个节骨眼上说两三周，那应该就是年后了出结果了。

　　最后提几个前面没说到我觉得相对又有用的：
　　1. 面试官的节奏掌握得都很好，即使不断出题，也让人没有什么压迫感，所以除了第一个人第一题我紧张犯晕了之外，别的感觉都正常发挥了，没有什么出门就觉得遗憾的地方。
　　2. 在我想题的时候，面试官都在不断敲键盘记录着，应该是记录我前一题的答题情况，边问边记，都是这样。每轮最后我写的所有程序和草稿都被拿走，程序应该是会被原样敲进去，而草稿可能是看出你思考过程的一个方法。所以，写程序的时候字好看点比较好，像我这样草书连笔的字写程序，面试官回头看不清楚，我损失就大了。
　　3. 程序最好用一种不容易出错的语言来写。我今天都用的python，并不是因为我对python熟悉，而是python简单，不容易写错，当然java也成。我绝对不敢用C++，弄堆指针弄个数组就算在电脑里写，就能把我弄晕，更别说纸上了，与其让面试官在这里挑毛病，不如挑个简单的语言，数组，字符串都直接拿来就用，多好。
　　4. 总的来说题目比我想象的简单很多，不少算法或者数据结构的小题，科班出身的人靠直觉都应该能答得比较靠谱。我觉得唯一一道有挑战性的题目是第二个面试官那个系列问题的最后一问，另外第一个面试官有一个智力题也有点意思。据说Google有一些面试官会问一些变态题，没有遇到这样的题，觉得有点遗憾。
　　5. 早上去面试的，一定要吃饱早饭，否则面到下午2点，没被问死，先把自己饿死了。后来想想中间有一次休息的时候hr问我饿不饿，当时应该说饿，弄点东西吃的。不过吃一半面试官进来就很狼狈，所以还是早上多吃点好。

　　整体来说，我对自己的这次面试发挥还是比较满意的，觉得答得都还可以——当然，可能面试官会有相反意见。尽管很久没有碰算法了，但是竞赛时候留下的底子还在，没有忘光，这点比较值得欣慰。另外感到不足的一点就是没有一门非常精通的开发语言，基本什么都能写，但是没有能写得特别熟练的，这就使得手写程序的时候感到有些不适，如果还继续做技术的话，就要想办法弥补。还有就是Google会向社招的人要成绩单，所以学校里的成绩也得掂量掂量，我研究生期间成绩还凑合，本科的就有点难看了，所以看来得只开研究生成绩单给他了。最后，鉴于Google发Offer除了面试之外其他随机因素占的比例很大(当然，对我来说是随机因素，对Google来说不是，只不过是我不知道的判断条件罢了)，所以面试只是个开始，还很难说会有什么结果。

　　这篇文章同时在水木社区的求职Google版面发表，文字内容略有区别，不过相同的是，由于签了NDA，我不能透露任何题目相关的内容也不会回答任何相关问题，只能讲讲流程，体会，以及自己的思路而已。另外，本文未经许可请勿转载。

　　从去年11月起就盯着yangfan.net的域名了，看着它的状态从RedemptionPeriod变成PendingDelete，掐指算准删除日期，然后上去注册，结果很显然，手动注册的不如专业网站自动抢注，域名被snapnames抢走。跑去一看，这是个卖域名的网站，再仔细一搜，还是个挺知名的卖域名的网站。于是想看看究竟是谁通过它买了这个域名，结果一查，竟然处于拍卖中，敢情它是不管三七二十一先注册下来再开始卖啊，如果没人买，大不了浪费一年注册费，对它们来说，也是没几个钱的事情，无非浪费了域名资源而已。于是就随手出了个底价$60，碰碰运气。

　　三天后，就是今天，运气碰成了，$60买下了这个域名(包括第一年注册费用)。它给我选的注册商不提供免费域名解析服务(要$14单独买)，于是把nameserver转了，就一切ok。等待60天后把域名转到国内注册商上，整个过程就结束了。

　　可见一个人的名字重复率太高是很不好的事情，连个网站域名都难弄，算来我还是幸运的了，把最看重的域名买了下来，千千万万和我重名或者谐音的人或者公司，就弄不到域名了。

　　顺手看了一下其他yangfan的域名，除了我拥有的yangfan.net和yangfan.name之外：

　　　　yangfan.com 　　　上海扬帆毛衫有限公司
　　　　yangfan.cn　　　　河北辛集市洋帆制衣有限公司
　　　　yangfan.com.cn　　金华市扬帆电脑有限公司
　　　　yangfan.net.cn　　海南扬帆国际旅行社有限公司

　　而通过各大搜索引擎一起使用挖掘出来的蛛丝马迹，yangfan.net原来很可能是属于温州市平阳县扬帆机械厂——是不是倒闭了？
　　另外，不知道这些网站的用户会不会互相弄混……

　　首先打开http://blog.sohu.com/robots.txt，看到以下内容：

　　　User-agent: Googlebot
　　　Disallow:
　　　User-agent: baiduspider
　　　Disallow: /
　　　User-agent: Nutch
　　　Disallow:
　　　User-agent: *
　　　Disallow: /
　　可以看到，搜狐博客禁止了除了Google和Nutch之外一切搜索引擎的抓取，而且还单独把百度拿出来深恶痛绝地鞭尸。这显然是小鸡肚肠的行为，对用户很不负责——因为别人无法通过搜索引擎搜到自己的博客内容。但是且慢，真的如此吗？

　　在各个搜索引擎用site:blog.sohu.com进行搜索。

　　首先是Google的结果，共有搜索结果417000项，全部是三级域名xxxx.blog.sohu.com这样的首页，任意找一个xxxx.blog.sohu.com去site:一下，可以看到还是都抓到内容的。417000，是一个三级域名的数量，差不多也就是他抓到的搜狐博客的用户数量。

　　然后是搜狗的结果，2984875个页面，看到的也都是三级域名，随便找个继续site:，可以看到只有首页没有内容，说明sogou就算是在自己家也还是很道德的。至于为什么sohu博客吃里扒外让Google抓却不让自家的sogou抓，那就要去问张朝阳了。

　　接着给出有道的结果：抱歉，没有找到与 “site:blog.sohu.com” 相关的网页。很好，遵纪守法。

　　最后隆重推出百度的结果，找到了131000篇，数量不是关键，关键是它的结果从第二篇开始就是内容页面，也许是百度不敢太过分，从外部过来的页面抓了之后看了眼robots.txt，于是不再往下继续，但是好歹，有外链的全给抓了(应该不是全部，否则数量也太少了)。这只有三种可能，一是百度不懂robots.txt的规范，二是百度装作不懂，做了流氓——还好它没全抓，否则就不是流氓而是黑社会了，第三就是只抓外链页面是允许的，我个人感觉这种可能性不大。地震震得w3c网站连不上，所以也确定不了。

　　看完sohu的，再来看看流氓百度家的http://hi.baidu.com/robots.txt，内容如下：

　　　User-agent: Baiduspider
　　　Disallow:
　　　User-agent: Googlebot
　　　Disallow:
　　　User-agent:
　　　Disallow: /

　　流氓就是流氓，比他强的他不得罪，比他弱的，全部封杀。至于最后那个User-agent为什么不加个*，我就不知道了。这样写是不是符合规范呢？如果不符合，那就是白写，就算页面被人抓了也是白抓。那么来看看site:hi.baidu.com的搜索结果。

　　首先还是Google的结果，只有96400个结果，都是每个人的首页！而且搜几个朋友的百度空间，发现只有首页没有内容，也就是说，Google也许只抓了每个人的首页，即使它被允许全抓。

　　然后是有道的结果，和Google一样，只有每个人的首页而没有内容，一共171000条。有道还是挺听话的。至于为什么数量几乎是Google的两倍，很简单，因为Google没有抓中文目录，而有道抓了。正好这里顺路鄙视一下百度这么大个家伙居然还允许用户用中文目录名。

　　百度自己的结果在这里就没有什么意义了，4980000条，挺多。

　　最后是搜狗的结果，667756项。结果很眼熟是吧，没错，就是和百度搜搜狐博客的结果非常像，应该是只抓了外部有链接的，没有继续扒拉。

　　好了，结果出来了，搜狐博客和百度空间，毫无疑问，都不是合适的BSP，因为它们连用户内容被检索的自由都不给。相比之下同样是门户的博客，新浪和网易至少没有从robots.txt上去做手脚。

　　谁是流氓呢？在能找全robots.txt规范前不下定义，但是比较显然的是，百度流氓的可能性很大，而搜狗的以彼之道还致彼身很可能因为百度自己的写法错误而只能让百度有苦说不出。

　　apple总是能给人带来惊喜，今年轮到了传说中的iPhone。

　　这场地震至少让我的Space空间更新受到了很大影响。无论是公司的铁通还是住处的海淀宽带，都几乎连不上Live Space，套层代理走香港，勉强还算可以打开半个页面——不错，是半个，永远没有打开一个的时候。幸好的是Live Space提供了mobile的访问方式，页面非常简洁没有什么废代码，使得我可以顺利阅读与发布，虽说只能看点纯文本，但是聊胜于无了。
　　看来2007年的年头也要在这样的状况下度过了，说是全球一张网，但是这网的鲁棒性也太差了点，看上去像是一根扁担挑着的两个连通图，扁担一断，两头就如参商相隔，彻底歇菜。
　　2007年的当务之急，是要在国内架一个自己的空间。Google要被盾，微软怕断网，网易搜狐之流滥用Ajax弄得搜索引擎都抓不到内容，只有自己架一个才最是安全实惠。

　　ps：Live Space的Mobile方式继承着微软的一贯大爷作风，在Firefox和Opera里访问是会报错而不能浏览的，也就是说，语法检查比Opera更严格的手机也都不能访问这个页面。估计微软关心的，只有IE和Windows Mobile而已。

需求：

　　用JavaScript代码取消页面上的文字选取

实现方法：

　　 IE ： document.selection.empty(); 　　 FireFox ： window.getSelection().removeAllRanges();

　　 Opera ：Opera对这两个都不支持，确切的说，document.selection只有IE支持，window.getSelection()也只有FireFox和Safari支持，都不是标准语法。搜索了一下发现Opera支持用document.getSelection()获得选中的文字(FireFox也支持)，但是typeof一下返回的是个string而不是一个像window.getSelection()那样的DOM:Selection对象(DOM:Selection对象貌似是FireFox自己的标准)，这样就没法进行写操作了。在网上无论怎么搜都找不到解答，但我觉得应该一定有办法的。

Gacrux是什么？

Gacrux是一种社会化服务，使用主动聚合手段，整合好友间的个人rss，使得朋友圈内的交流更为通畅，极大增强好友间的紧密性。

Gacrux的描述

功能：

Gacrux提供群体的rss聚合与阅读。

Gacrux提供群体论坛、群体相册等传统功能。

Gacrux不负责任何个人文档、相片、BLOG的存储和发布，只提供个人rss源的聚合。

使用流程：

用户申请帐号，加入系统。

用户配置自己的rss发布源，可能包括自己的Blog，相册等。

用户申请加入群组(朋友圈)，并设置自己在该群组中的名称显示，各个rss发布与否等属性。

加入群组的用户可以浏览已聚合的群组内所有成员的rss内容，同时他提交的rss也被聚合。

加入群组的用户可以使用群组论坛，群组相册等功能。

相似服务的比较

** 传统的群组交流网站(以各种同学录为典型)： **以群组为元素，用户只有加入群组才能得到服务

群组提供论坛，相册等功能

用户在论坛，相册中创造内容，并阅读同一群组中其他用户创造的内容。

缺点：

*　　当用户加入多个群组时，他的文章、相片等内容必须多次发布* *　　个人Blog的兴起使得网民更愿意在Blog上发表内容，尤其是有价值的内容* *　　当用户创造的内容减少后，其阅读频率也明显下降，从而形成恶性循环*

Web 2.0下的SNS网站(如orkut，myspace等)： 以个人为元素，用户具享个人Blog，相册等服务项目

提供群组功能，群组以共同话题形式组织，用户可创建，加入群组，群组提供论坛，相册等功能

关注用户间的好友关系，用户维护并经营自己的朋友网络

缺点(更多的是国内类似网站的缺点)：

　　 *廉价的好友关系泛滥，SNS服务沦为交友服务

　　* *用户创造的个人内容与群组内容割裂严重

　　* *较为封闭的写作平台，同样受到Blog的冲击

　　* 整个服务很容易最终收敛至一个具有各种版面的大规模论坛，或者一个纯粹的交友网站

无中心的交流方式： 网民寻找合适的Blog服务、相册服务或个人Space服务提供商，更新并维护自己的空间

网民将自己的空间地址在好友间宣传，使得好友可以访问自己的空间

网民关注并收集好友的空间地址，时常进行访问

好友间通过相互在对方空间的留言等方式进行交流

缺点：

　　 *不存在一个中心结点，使得每个人的订阅与阅读无所适从(各种rss reader即为解决该问题而设计)。

　　* *人与人之间交互没有依托点

　　* 宣传自己的空间与收集别人的空间地址过程复杂，且会有大量遗漏

Gacrux：

以群组为主要元素，用户必须加入群组才能得到服务

群组依托于现实中的人际圈，群组中的好友网络为完全图

用户提交自己的rss feed，由Gacrux进行整合

优点：

　　 *Gacrux不改变用户的写作方式和写作习惯，且只要加入Gacrux的用户即为其群组贡献内容

　　* *用户任何时候都只需更新自己的Blog空间，Gacrux自动将更新的内容获取并提供给其加入的所有群组阅读

　　* *Gacrux改变用户的阅读方式，大大方便了朋友圈内信息和内容的共享

　　* *用户无需关注群组内其他人的Blog等，只需访问Gacrux群组，即可获得所有人的更新

　　* *对于任何一个朋友圈，Gacrux可以维护加入同一群组的人的完全图关系，找回久不联系的好友下落

　　* Gacrux群组中的好友关系是极其稳固而有价值的社会关系

Gacrux与SNS的区别

观点：

　　SNS关注人际间的网状关系，基于六度理论，以个人为中心，维护与经营自己的朋友网络。

　　Gacrux关注已经存在的朋友圈与社交圈，并以此为中心，维护并强化圈内朋友的联系。

　　SNS的群组以某一个话题为中心发起并建立，参与者围绕话题进行讨论，群组关系依靠此话题维系。

　　Gacrux的朋友圈以现实存在的社会关系为依托，不存在中心话题，其维系为现实中的人际关系。

　　SNS中大量用户以交友为目的加入，并不断尝试扩充好友圈，使得大量廉价一度关系存在，而系统又无法判断关系强弱，影响人际网络价值。

　　Gacrux并不依靠点对点的人人关系维持，也不维持点对点的人人关系，因此好友圈内的好友是极其稳固和有价值的一度关系。

　　SNS依靠用户创造内容而又难以吸引用户创造内容，网站间竞争激烈，具有排他性。

　　Gacrux不依靠用户创造内容，主要依靠聚合的内容，不具有强烈排他性。

结论：

　　虽然同样是人际网络相关，Gacrux与SNS所关注的内容以及所提供的服务的并不相同。

　　Gacrux可以有效与SNS服务成为互补。

Gacrux用户的扩张

　　Gacrux及类似服务对用户的访问具有相当粘性，即使用该服务的用户会以很高频率持续访问其所在的朋友圈页面。

　　Gacrux的用户会主动邀请朋友注册参与，以获得更完整的朋友圈。

　　用户在注册之后即使从此不再使用该服务，也在持续不断提供内容并为他的朋友创造更好的阅读体验。这是Gacrux的一大魅力。

市场竞争

观点：

　　目前市场上没有类似产品服务。

　　Gacrux的服务提供从技术角度而言并没有难度，不存在技术壁垒，容易仿造。

　　大型网站可以使用其现成的产品通过很少的修改，很低的成本，整合出类似的服务来。

　　当竞争存在时，由于整个朋友圈的迁移成本非常小，因此容易产生马太效应，小型网站很难在竞争中胜出。

结论：

　　Gacrux服务并不适合成为创业型网站的选择。

　　Gacrux服务适合成为综合型社区的有机组成部分。

Gacrux实例模拟

* 本段文字以Google为例，简单模拟一个综合性网站如何迅速利用现有服务整合出Gacrux服务

之所以以Google为例，源于本人对Google相对齐全的功能的了解，并不意味着该构想与Google有任何相关 *以 ** Google Account **为登录入口

　　每个用户在第一次使用Gacrux时，填写自己的rss feed地址列表。用户对其中的相册地址单独说明。

　　如果用户没有Blog，Photo Album，可引导其使用 ** Blogspot **作为自己的Blog空间，使用 ** Picasa web **作为自己的Photo Album。

创建群组：

　　群组的创建者可选择此群组是否可被公共阅读

加入群组：

　　用户选择加入群组后，群组的管理员通过 ** Gmail **信箱获得用户消息，并进行验证

　　验证通过的用户设置自己的该群组中显示的姓名，同时可以设置自己的部分rss feed是否对该群组隐藏。

使用群组：

　　群组自动抓取所有成员的rss feed，进行整合。rss feed的抓取和处理直接使用 ** Google Reader **的技术；

　　群组自动生成日历，标注成员的更新，所有成员都可以观看并订阅该日历。日历的生成和保存直接使用 Google Calendar ；

　　群组提供自定义页面，模版的选择和编辑。 ** Google Pages **和 ** Blogspot **均有类似功能；

　　群组包含一个独立的讨论组。可直接调用 ** Google Group **实现；

　　群组包含一个独立的相册。可使用 Picasa Web Album 。不过目前Picasa不支持群组相册，需要增加功能；

　　Gacrux中的同一群组用户可以自动在 ** Orkut **中成为好友；

　　当 ** Google Talk **提供群聊功能时，Gacrux群组将自动成为 ** Google Talk **群，使即时交流更加方便。

服务商得到了什么：

　　通过Gacrux群组，服务商可以获得大量真实，有效，稳固的社会关系。这些关系远比通过SNS服务所得到的有价值得多。

　　可以通过用户的rss feed，以及加入的群组内容，交流对象，挖掘出用户的喜好、需求，有助于提供个性化服务。

　　刷刷地看到好多好友Blog上都有这个测试，还互相点名。好吧，我就在被点到前，主动点……顺便帮这个网站带去一点流量好了，好歹页面做得还算舒服，不容易。

梦影月痕

100.0%男性倾向,0.0%女性倾向

yodao | 博客男女

　　继续点名，学习kick和deer的点法，点前四个看到这个贴子的。什么，你不知道自己是不是前四个？你不知道我怎么知道……

　　2006年12月1日，我们的手机休闲娱乐平台**玩派**终于开始测试了。

　　玩派是一个集合了各种棋类，牌类，休闲类游戏的手机娱乐平台，满足了用户随时随地随身娱乐的愿望。我们觉得，手机游戏，是一种简单的快乐，不需要多么复杂的游戏内容，不需要多么精美的画面，它更讲究的，是一种 随时可以开始，随处可以进行，人人可以参与 的游戏方式。因此玩派平台上提供的，无论是麻将还是斗地主，无论是连连看还是俄罗斯方块，都是精心挑选的，广为流传的休闲游戏，不用教，不用学，上手就能参与其中。
　　和其他棋牌休闲类网游相比，玩派采用了先进而独特的脚本化编译执行技术，使得用户只需在手机中安装玩派平台，就可以享受到玩派现在的，以及将来的所有游戏。无论是当我们推出新游戏，还是升级现有游戏时，用户都无需重新下载安装玩派，即可直接使用。也就是说，一次安装，终身使用。这是玩派与其他棋牌网游相比，最为独特的优势。
　　玩派平台内测时首批上线的共有17个游戏，其中单人游戏4个(均为休闲类游戏)，双人游戏12个(棋类4个，牌类2个，麻将1个，休闲类游戏5个)，三人游戏1个(牌类)，同时在平台上上线测试的还有手机聊天室和国内300个城市72小时天气预报即时查询。在测试期间以及将来正式运营期间，我们将随时发布更多的新游戏以及其他娱乐产品，力争让玩派成为用户手机休闲娱乐的第一选择。

　　如果你的手机在玩派的支持机型列表中，那么欢迎下载玩派平台，加入我们的用户行列。

　　想在HTML里实现一个很简单的功能，就是在<a>标签被点击的时候，执行一个javascript函数。然后发现，居然在IE6，Opera9和FireFox2三种浏览器里，实现方法还不一样。

　　当然，通用实现是存在的，即<a href=“javascript:dosth(p,q);“>xxx</a>，这样所有浏览器都能认识。可是我不想这么写，因为这样的话鼠标移上去状态栏就会出现我的函数名，很难看。于是换一种写法<a onclick=“dosth(p,q);“>xxx</a>。更简洁了是吧？可是问题就接踵而至了。

　　首先，不带href的<a>在IE6里是不能触发:hover的css的，也就是说原来鼠标移上去的效果没了，这应该和IE6不支持div:hover这样的写法是一个毛病，这个不难解决，加一个href=”#“就可以了，反正在FireFox和Opera里都不会因此出错。

　　真正的麻烦从这里开始了：我的<a>标签不是直接写在html里面的，而是用javascript生成的。这部分代码很简单：

　　　act=“dosth(p,q);”;

　　　i=document.createElement(“a”);

　　　with(i) {

　　　 setAttribute(“href”,”#”);

　　　 onclick=act;

　　　}

　　结果呢，在Opera里运行正常，而在IE和FireFox里，居然都不执行dosth(p,q)的函数！跟踪分析发现，这俩浏览器不支持onclick这么写——但是也不报错。既然不支持，那就写成onclick=new Function(act);，这时候IE和Opera正常，FireFox依旧不认。改用setAttribute(“onclick”,act);好了，这下Opera和FireFox倒是都认识了，正确执行了，而且用FireFox好用的查看部分源代码功能可以看到输出是完全正确的(貌似只有FireFox提供了这个强大而实用的功能，其他浏览器都不能看执行结果的代码)。但是IE，却不执行dosth(p,q)函数，仿佛根本不存在一样——而直接在html里按这样的href+onclick属性书写是没有问题的。

　　最后反复调试，还是解决不了问题，没办法，只能用最无奈的方法，判断浏览器，然后对人说人话，对鬼说鬼话了。如果是IE和Opera就执行onclick=new Function(act);，如果是FireFox，就执行setAttribute(“onclick”,act);。

　　这好端端的一个简单功能，非要整得这么麻烦，唉。

　　更新@11.23：原因找到了，非常简单，不要在with(i)里面写onclick=new Function(act);，直接在外面写i.onclick=new Function(act);，就搞定了。这也许是FireFox的一个Bug，但是触发条件未知，因为我做一个简单的页面代码单独测这个是可以pass的……