动态简历

引子

大家都喜欢投简历,而且都喜欢投漂亮的简历以使自己脱颖而出,不过另一方面

几乎人人都讨厌坐下来咬文嚼字地认真写简历。这便形成了矛盾,有的人的思路是

去网上寻找漂亮的模板来套,而有些人的思路则是给出自己做过的开源项目地址

当然这种办法只能是给程序员玩。还有些人给出自己的主页或者社交网络地址,希望

面试官能够看到一个真实的自我。老实说,这些都不怎么完美,漂亮的模板许多人用

也会让人审美疲劳,开源项目地址有时候会让面试官发现一些很不爽的编码习惯而影响

决策,何况非程序员没办法利用这个方法。至于说主页或社交网络地址,主题又太散

太多与简历无关的东西存在里面。我倒是曾经有个关于简历的思路,思考过一阵,今天

下午一时兴起,于是决定写下此篇博文。

我的想法

今年来infograph十分盛行,几乎每一次网上流传的惊艳简历都是infograph形式的

之所以这样,我想原因在于面试官那边,传统的文字/表格简历排版一般都很糟糕,毕竟

word/pdf上面还没什么好的css模板, :D, 另一方面,面试官有很多简历需要看,他能给

每份简历的时间是有限的,如果不能快速获取感兴趣的信息,那就只好pass了。流行的

infograph一般都色彩鲜明,排版漂亮,并且关键的是简洁大方,用简单的图表达出了

需要一坨文字才能表达的信息,也便因此收到了预期效果。

简历应该传达的信息

你也许会说,既然infograph形式这么好,那我们照做就是了,问题不是这么简单,

首先,infograph不像文字/表格简历有那么多的模板可套,其次,即使有人提供模板

,鉴于各人的情况不一样,适合他人的模板未必适合你。所以,我们有必要从问题的

根源着手,研究到底简历应该传达什么样的信息,如此才能对症下药。

那么,简历到底应该传达什么样的信息呢?我们不妨换位思考?企业需要什么样

的简历呢?企业说到底是为了招人,而不是收集艺术品,大多数企业无非想从简历上

获得"这个人是个什么样的人,他是否适合我们企业?" 这个问题的答案,那么企业会

怎么做呢?我们从生活中的经验出发,如果我们想知道某个人是个什么样的人,他是

否值得交往?我们会如何做呢?我们会过去攀谈或者向他人打听此人过去的一些经历

,或者直接观察此人看看他的穿着,样貌行为习惯等等, 其实就是此人物理上的属性了。

那么对于企业招人来说,无非是想了解下此人过去的经历,尤其是从业经历,以及此

人目前所掌握的一些技能,资源(推销员?),尤其是那些能被企业职位直接利用的,传

统的简历一般是直接罗列,也许你有那么一两个面试官感兴趣的点,但我很怀疑他能否

从那一推文字里找到。infograph相对好点,比如我给自己绘制的一个个人兴趣图,我

想就比单纯地用文字罗列自己的兴趣比较让人一目了然。

http://geek42.info/attachments/yunfan-interesting.jpg

不过目前的这些infograph形式有个问题,如上面我的个人兴趣图示,有时候需要列出的

信息太多要么你的图不够简洁,一如我的那样,要么,你的图很长或者很宽,导致面试官

错过什么重要信息 另外一方面,有时候你罗列得太多,反而让人怀疑简历的真实性。

我的动态简历设想

呈现方式
关于上面那些问题,我的解决方案是制作动态呈现的简历,将信息按照时间的推移

逐步的呈现出来简单来说,相当于当前这种静态的infograph的升级。那么,为什么我觉

得这种方法好呢?

首先,上面提到有时候你罗列太多,反而让人怀疑简历的真实性,我们想一想,工

作上的技能,资源之类的都不是天生的,而是随着时间推移慢慢积累的,从业经历更是

需要映射到时间轴上的,从传统的文字形式简历来考虑,你的简历上说“我目前掌握 技

能A, 技能B, 技能C, ... 技能Z” 显然不如 “我在公司A从业期间,同事教会了我技能A

和B, 后来我去了公司B,从事XX职位又让我掌握了技能C” 这样的说法更好,后者更容易

让人相信,因为人家看到了你的技能的来源说法,可以凭借自己的经验去判断合理与否

。其实就算看简历的时候不说什么,面试的时候,也许面试官还是会问你: "你说你会

技能A, 你能不能告诉我们一些东西证明一下?"

当然后者的那种说法虽然不错,由于表现形式是文字,所以还是有我们曾经提到的

文字的那些问题,而静态的图其实是很难体现出这个意思的,除非你作成漫画形式,而

把漫画的换页速度加快一点,也就是我说的动态简历啦(假设你了解电影动画的原理,

12帧,24帧:])

其次,这种形式是基于时间轴的,不断的加入你的各种事件,比如:
  1. "你进公司A了,那时候你是个刚刚毕业的愣头青"
  2. "你分到研发组,但是负责与产品经理们打交道,因此掌握了对非技术人员的沟通技巧"
  3. "你离开公司A了,因为你十分看好redis,而那帮人非要死守memcache"

随着时间的延长,这里能列出的事件会越来越多,而你的个人形象也会在面试官那里越

来越丰富,越真实,

同时很关键的一点是,这种模式能适合大多数人,所以能够采用统一的模板形式

衍生的想法
既然可以找到一种模式适合大多数人,那么很显然,作成一个网站服务大众是很不

错的,同时,很有可能也是有利可图的, 不过话又说回来,如果不能普适的话,我也没

必要把想法写成博文,我只需要自己做一个这样的动态简历,然后享受赞誉即可。

说到做网站,有必要说说如何做

首先提供一次性编辑,并且生成动画文件的方式是不太好的,很难想象连认真写文

字简历都懒得做的人会花更多的时间来回忆揣摩过去发生的种种事件与修饰动画,何况

过了一年可能用户又需要投简历,而这一年中又发生了点事件,很显然,用户会想要复

用以前的数据,而不是时隔一年后又重新再走这么一次流程,搞不好用户的记忆会出些

错,而让那些有机会看到用户的两个版本的简历的面试官怀疑其诚信问题。所以我们应

该让用户像更新twitter那样添加增量的在网站添加事件,并且随时可以查看整个动画,

随时可以修改编辑动画的某些部分,像是样式,演示图,tips之类的,这有点像在线记账

理财的网站,你随时添加记录,随时查看总体结果。

其次从长期来看,一个人的简历上事件多多,然而短期来看,即使放到以周来考虑

的话,适合写入简历的事件也并不多,我想你换工作或者换岗位的频率应该没有这么快,

然而一个网站如果用户几个月,甚至一年三年才来访问一次,并且更新数据的话,我想

这就很难说服投资者或者员工相信其前景了,除非你收月费或者要求用户提供各种社交网

站账户绑定,以方便你自动挖掘信息,整理信息,并把信息面向企业招聘者服务,协助

他们找到合适的人才,并且在最后的时刻联系找到这位很长时间都不来的用户,通过社交

账户 :], 这也是一种模式,然而我不太喜欢,自动挖掘的话,社交网站本身也可以做到,

同时自动生成的信息总有不准确的,又或者千人一面,如果没有用户的主动修饰,很难

保证企业面试官不会再一次审美疲劳。我喜欢的模式是,你可以让用户绑定自己的社交

账户,并且做一些社交平台第三方开发,与用户约定一些动作比如在twitter上 ,如果

用户绑定了账户,并且发了一个信息 带有 #career# 标记之类的,就把该条信息视作一

个事件收录并且做相关处理,又比如说与类似trello这样的服务网站合作,让用户每完成

一个卡片可以选择产成一个日常性低优先级的事件,如此则能收集到很多的用户事件,

而这又可以成为督促用户每周或者每3天回到网站来回顾自己的动态简历并且做出修饰的

动力,因为他可能把自己的动态简历地址印在名片或者贴在个人主页上。当然,也许你

会自己做个类似trello的服务,那样不是更方便么?企业在你这里招到人,然后在你这

里开展日常工作,员工在你这里的企业间流转,多美妙的前景?

对呈现方式的修正
缺乏足够多的用户事件可能会让网站头疼,然而如上述方式收集到足够多(或许是

太多了)的事件,也许最终会让企业方面头疼,从而最终让用户以及网站头疼,毕竟,

企业方面的人员时间有限,而你的10年简历可能生成的动态简历全部播完得要一个多小

时,那么要么是企业人员看到15分钟还是看到你愣头青那会儿的狗屁企业政治斗争细节

或者你的碎碎念之类的东西从而厌烦的退出,要么就是他被1个多小时的时长给吓住了,

从而直接跳过你的动态简历,这两种情况都很糟糕,所以这里要引入对呈现方式的修正。

为了更准确表达意思以及更丰富地表现用户,网站方面需要收集更多的事件与细节,

这些都会催生更长的动态简历播放时间,而这刚好与企业预期给每个简历的审阅时间相

反,企业是希望审阅时间越少并且掌握的信息越多越好

有没有例外呢?有的,当企业对该人感兴趣并且想要了解更多细节的时候,很显然,

这时候他不介意多花10分钟了解下你在某公司的详细从业经历,如果结果令他更感兴趣,

则显然他愿意再花又一个10到20分钟来详细审阅你在某个岗位工作的任务细节和你当时

对一些工作任务的感想之类的,从而决定你是否就是他们想要的人。

所以我们的动态简历必须是能够被压缩,隐藏细节的,并且在浏览者感兴趣的时候,

可以随时就某个地方进行细节展开。

举个例子,你的15年从业经历可以压缩成 "在公司A上班" "在公司B上班" "在公司C

上班" ... "在目前的公司Z上班" 以及 "掌握技能A" "掌握技能B" "掌握技能C" 等登。

有时候企业人员对你当前的公司从业经历没啥兴趣,他想看看你在公司B上班的经历,那

么他可以选择你的 "在公司B上班" 事件对应的时间轴范围,同时选择细节展开,然后你

在公司B上班时候那些 岗位变动事件,工作任务完成事件这些会被调阅,并且以时间轴的

形式播放,这时候,这位企业人员发现你曾经开发过某个模块,而这个经验可能非常适合

他们企业目前招聘的职位,于是他再进一步展开你在完成这个模块任务事件相关的更具体

的细节事件展开,看看你开发第一天怎么说,第三天怎么说,最后完成模块你有啥总结的

感想,甚至当他发现你最后总结说这项任务太简单了,会想要看看当时你的同事们是怎么

说的,是否你是个天才或者大话精,又或者根本就是分给你的任务部分就是简单的(个人

觉得,这个feature已经在对企业人员的收费线内了),如果恰好同事们证明你就是个天才

bingo,这位企业人员于是决定联系你啦

所以对任何人来说,他的动态简历在第一眼看上去都只是很短的一个快速浏览,如果

没有感兴趣的话,那么3至5分钟放完然后pass, 如果有感兴趣的方面,则可以付出更多的

时间来展开相关细节查看播放,这是一个皆大欢喜的呈现方式。当然网站可能就得要求用

户在回来修饰的时候给各种事件添加从属关系, 在A公司B职位的工作事件显然都属于在A

公司工作的事件,网站还可能要求用户给各类事件提供一些打分,从而在压缩动态的时候

可以考虑省略掉某些不那么重要的事件,而这些都能增强用户与网站的互动。

这个想法适合谁?
  1. twitter, 他们目前好像在为盈利模式发愁

  2. google plus,从他们的创新性圈子设计与ui来看,他们很喜欢搞点不一样的花样,并且

    显然他们想玩出自己的社交网站style

  3. linkedin, 他们目前不缺员工与企业,缺的只是一种好的方式让员工与企业更快匹配

    (他们上次给了google一个我的推荐,结果那边却不知道我英文烂,害我白激动一场)这 也是他们的正事

  4. skillpages, 他们的界面比linkedin简洁多了,他们可能想更简洁更创新一点。

  5. trello, 他们可能就会从自己的用户着手,推出这项增强服务

  6. HackerNews上的诸位,他们既渴望创业又有能力去实现这些

    你也许会以为我最适合,因为这一切都是我想起来的,是的,随着实现的深入,我还能

想更多,问题在于,虽然我也会css修饰但我完全没有设计能力(这一点请参考我的博客页面

设计,css是我自己写的),也许idea不错,结果硬是就让我拙劣的美工与平面设计能力给搞砸

了。

我写出来,是希望他实现,至于是不是我实现的,无关紧要,谁实现的谁得利,如果你

觉得心里过意不去,那么可以考虑给我前50的内测用户资格 :], 当然经常与我通通气就更好啦。

最后欢迎来信交流,我的邮箱是 jyf1987 at gmail dot com, 费了几个小时写这么篇文

章,本来计划的自己的forth实现又泡汤了。

Author: jyf
Published on: May 3, 2013, 10:30:00 PM - Modified on: May 4, 2013, 2:40:43 AM
Tags: resume, infograph, web, service
Comments - Permalink - Source code

2012总结与2013展望

目录

似乎年末总结总会感慨时间过得快,去年如是,前年如是,今年亦不外如是,去年写的

总结( http://blog.renren.com/blog/80288196/795338871 ) 似乎还未淡忘,今年的

年末却又到来,没奈何,只得写一写。

2012年的总结

工作

前期在 果壳 完成了动态的改造,我感觉那个做完以后

动态部分我也可算是有不少经验之人了,果壳是一家很有意思的公司,做的事情有意思,

工作过程也有意思,同事更有意思,问题自然也是存在的,否则我不会跑路,坦率地说

如果果壳能够支持远程办公,让我在家coding,我完全愿意继续做下去。

从果壳一离职,没休息两天就立刻感到新公司 果合

职了,(没办法, 糊口阿,大哥 )名字纯属巧合,业务是不一样的,现在担任的是数

据挖掘以及各种救火队职能,这家的氛围很不错,尤其是老板与员工的互动以及轻松的日

常工作,当然事物都是有其两面性的。总体来说,这是一家能让人满意的公司(废话,要

不然干嘛来),要是能支持远程办公就更妙了。

人文素养

今年于音乐事业是彻底绝缘了,就算把最近发现的一个音乐生成库算进去的话,也只

能勉强扳回一局吧。

历史上倒是看了不少书,包括剑桥中国史系列里的隋唐与辽宋夏金元史,另外分裂时

时期的南北朝的一些论文看了不少,最近kindle里三国两晋南北朝的目录下的所有论文都

已看完,又该考虑弄个代理去万方下新的论文了。

说到这些历史,插一句关于我家世的问题,查了下,我祖先的金姓鲜有汉族来源,几

乎全为少数民族,考虑到我爷爷当年之情况,我很怀疑他为清末躲入深山之满族人,这点

从我及我父亲的一些毛发特征也能看出来,当然,有赖于进一步的血液化验证实,上次果

壳那个血液研究调查我没参加,实在是可惜。

科学素养

今年貌似开悟,许多以前导致我的数学与物理方面陷入滞塞关键点有所突破,比如说

数学上的微积分,物理上的那些守恒,电磁学的一些问题,我有在看一些公开课和可汗学

院的视频,最近这几个月一直玩游戏,又没怎么坚持,惭愧。

技术

由于新公司的技术工作任务变化,我现在更多的使用shell与python混合编程,前不

久甚至参加web开发,写了几段php代码,虽然有点别扭。

由于个人喜好问题,我算是学会了点clojure,现在对于lisp系终于不是叶公好龙了

我对csapp的阅读停顿了,具体什么时候开始忘记了,很挫。

生活

6月份搬家,新地方跟原来没隔几步路,空间更大了点,当然价格也高了,没有专属

卫生间,终究比较麻烦,有一阵很迷恋折叠设计,曾经想把所有家具都替换掉,最后还是

没干成,懒惰是我最大的敌人。新屋子隔音不怎么好,隔壁情侣太烦人,感觉很有必要带

耳罩,现在终于知道为毛武侠小说里那些人要闭关了,声音干扰始终是一项大问题

认识论

似乎过了末日那一天以后,还真是末日了,没盼头了嘛。以前种种紧迫都以末日为理

由,现在没了,只得恢复之前的状态,当然,根据一项德国科学家的报告,我的推论是这

样的状态也许才是最好的,所有都是真正的兴趣驱动。

社会交往

新公司认识了几个新同事,如此而已。同往年一样,我现在几乎是结交不到新人了,

旧人也在不断丧失,波波已经好久没跟我电话了,大概是热衷于传教事业,又或者是我

对宗教的言论触怒了他吧。

2013年展望

自我拓展

我要考虑学点音乐合成的知识,由于之前发现的那个好玩的clojure音乐合成库,我

对音乐合成的兴趣又一次燃起了

把目前在看的可汗学院视频看完,同时物理上看到大学物理为止。另外工作相关的数

学知识可能要看一看

然后就是计算机科学与工程上的四个基础方面的提高,csapp,sicp,数据结构,tcp/ip

最后是一定要找个机会,最少实现一个我的那些idea的网站,用clojure!

生活相关

找一些适合我的运动,应以室内为主,或者买个WII来?毕竟现在挂了对家人不好

尽量争取远程办公或者离开帝都去杭州混

万年话题之泡妞
年龄一大,必定就有人热心,立松的老婆就热心给我找,阿姨也曾考虑给我撮合,上

次回家老妈还跟我说有个姑娘可以考虑,但我始终都没有找,不是我这人性取向独特或者

根本不想找,我是个正常的男人,我当然想要个女人,但问题是这种事于我是很严肃却又

不急迫的,许多朋友曾经劝我可以考虑将就下先在帝都找个姑娘,然后骑驴找马,这种事

别人做我看得惯,自己去做总过不了心理的关,毕竟大家都是有爹妈有人疼的人,关起门

来在家里都是宝贝一样哄着,这么做,将把别人置于何地呢? 我的观点是,男人似乎是

随着年龄增长而越发增值,女人则是慢慢贬值的,倘若耗费别人的青春最后又抛弃了她,

这种事情实在是与我个人的处世原则冲突。

我对待找伴侣的要求倒也不高,只希望能够谈得来,不过这个也许就隐含了许多潜在

的要求,又因为我不太愿意跟不熟悉的女性交往,可选范围就更少了,所以最后导致今天

这么个结局。

只能说,继续考虑吧

尾声

既然末日都过了,也没啥可担心的了,大家都吃好喝好生活好吧,顺祝新年快乐
Author: jyf
Published on: Dec 31, 2012, 8:00:00 PM - Modified on: Jun 22, 2013, 4:37:31 PM
Tags: years
Comments - Permalink - Source code

现代技术条件下的中餐增强

由头

最近有一阵晚饭总是在回家路上的小豆面馆吃,几次

遭遇让我有了些想法。再者,上次搬家时候立松跟我谈起

杭州小笼包的事,备加感慨。

观察与对比

kfc等西式快餐在国内很流行,我觉得应该跟滋味关系不大,

主要是猎奇与换换口味之类的心理,另外也有不少人真的是

冲着他的快去的,因为那些流程保证了你是立等可取的。另外

一个是标准化的问题,你在一家店铺里尝的跟另外n家的都一样,

喜欢的话总能每次吃到这滋味。份量上则标准单位很低,适合

调整,一个人喜欢吃汉堡,可能可以多吃两个,像我喜欢吃炒蛋

什么的,多吃两盘似乎不太合适。也撑不下。

反观中餐则不行,首先是流程不保证你快,即使是小豆面馆

吉野家,虽然也是让你立等,却不是立取的,这是中餐性质决定的

,这还是比较快餐化的,如果是传统的,那就更不可能让你在那立

等,话说吃个酸菜鱼锅会让你自己端回去座位去吃么?

另一个问题是中餐的口味并不标准化,比如蛋炒饭,我从来没

吃到过统一的,即使同一家店铺,换个师傅都不一样,比较典型的

都是那几样流行菜,像川菜里的鱼香系列(肉丝,茄子),杭帮菜

的西湖牛肉羹更是离谱,自离杭州,没吃过味道接近的。这个有点

让消费者无所适从。

我的观点

中餐这个问题既是劣势也是优势,说他劣势主要是基于历史的

数据来看的,没有做得很大型的连锁,这里的大型,我指的是kfc

麦当劳这种大型,不是小豆这种,kfc在我家乡黄山市都有,小豆我

在杭州都没见到过。

但上面说过的一些问题其实也是优势,因为信息时代,信息处理

越来越廉价了,而现代消费市场更是一个精准的市场,所谓精准,也

就是要针对个人作定制,在这一点上,中餐可谓是非常适合,举个简单

的例子,你去中餐店吃多了,与那店员熟悉了,也许某些你爱吃的菜

份量可以稍微多点,某些你偏爱的口味可以重一点,然而你即使去千百

次KFC,店员也不会了解你喜欢吃汉堡而多给你一个汉堡,这正是他的

标准单位小带来的不利影响,同时由于标准化问题,店员也不大可能给

你做个大一点的汉堡

中餐虽然有这个优势,但历史上因为主要靠人来判断,所以很难形

成一种稳定的方法:首先某个店员的好的方法并不能快速的传递给所有

员工; 其次是人事变动会有很大影响,某个核心员工一跑路,他的那些

熟客立刻就会感觉不适(前提是以前享受了该员工提供的定制化服务)。

然而,信息时代的来临带来了一种新的解决方案

我的方案

措施

简单点说就是: 计算机视觉+云计算(computer visior + cloud service)

详细版本的解释是

  • 使用云计算,将顾客的偏好数据存在公共库里供共享使用,

    比如我偏好咸,则这个偏好无论在川菜馆还是杭帮菜馆里

    都是成立的,即使是在KFC,他们如果能把汉堡做得咸一点

    对我而言,也是令人愉悦的。

  • 使用计算机视觉,一般来说是,人物识别,在各个终端上

    识别出顾客,并将其与云中的数据联系在一起。

应用场景

  • 兼容的方案通常会比较好,所以顾客仍和以往一样先就坐后点餐,餐馆

    中应布满摄像头,使其能够覆盖整个就餐区,这个说起来玄乎,其实无非

    几个摄像头而已,然后顾客进入以后触发跟踪系统跟踪,这时候,只要

    顾客一招手,系统就会自动判断是否要点餐,于是召唤相应的空闲服务员

    过来,这种技术虽然理论比较玄乎,但其实早已经在用了,典型的例子是

    kinect。

  • 点餐应该考虑使用可交互移动终端,当然这个无所谓是给服务员还是顾客,

    只是这个点餐的选项应该有可选的口味与份量以及其他偏好,比如我每次去

    吃蛋炒饭都要多加两个蛋,如果每次都是服务员问我还是像以前那样多加

    两个蛋吗?这会让我很开心。这个场景在传统的餐厅只有经常去的熟客才

    会遇见,但信息时代借助云计算,一个陌生的餐厅的服务员也可以做到这点。

  • 接上面的,要将个人的偏好数据提取出来,很重要的一点是需要人脸识别,

    这会识别出当前消费者具体是谁,这样才有助于下一步判断。关于这一点,

    我不清楚是否很容易,因为识别出人脸的区域很容易,识别出是谁就未必,

    还有一些具体的问题如双胞胎如何处理,都是需要专家考虑解决的

扩展

  • 有了消费者的数据以后,下一步就是各种挖掘与推荐了

    • 首先是点菜的推荐。这个无须赘述

    • 其次是健康信息的跟踪与共享

      • 腹泻去了医院,医生也许要查看下你最近吃了什么

      • 感冒生病打针吃药也许有一些忌口,这个需要反应到餐馆去

      • 节食计划也许要考虑你的口味偏好推荐一些既能让你满意,又不会让你

        发胖的菜品

      • 减肥运动计划也许会因为你刚才吃了一碗红烧肉而加大今天的运动指标

  • 使用云计算的方案对一些松散的中餐的品牌建设会很有利,比如立松给我

    说的杭州小笼包,压根不是杭州的,也不是一家连锁的,但是大家都做这个

    共享些数据还是对所有人都有利的,同时也对品牌有利,通过对整个共享

    数据的挖掘,可以了解消费者究竟对品牌的哪些菜品感兴趣。

  • 对于西餐,对,你没看错,我说的就是西餐,云计算与计算机识别以及顾客数据

    可以加强集团对于连锁店的约束,例如对于店员的行为监控,对于顾客反馈的

    获知,以及配料的调剂(这个我可以解释,地区差异可能让KFC的某种汉堡在此地

    比彼处消费比例更高,但这个其实是取决于顾客的,如果只是看整体的统计数据

    是很难找到真实数据来源,从而做出准确预测的)。

讲了这些,无非是希望餐馆的体验更好而已,想起我以前跟同事说的用平板给餐馆

作点菜的想法还被嘲笑,后来国外真有人这么搞了,却被赞誉,现实总是让人无语

Author: jyf
Published on: Jul 29, 2012, 8:00:00 PM - Modified on: Jun 22, 2013, 4:37:31 PM
Tags: idea, computer-vision, cloud, chinese-food
Comments - Permalink - Source code

一种基于虚拟机的ADT服务器

目录

1   摘要

这篇文章介绍了一种基于虚拟机的ADT服务器的设计,该文章尤其针对redis

2   概念

2.1   ADT服务器

该文章主要讨论的是key-value类型的内存数据库

在内存数据库的设计中,有两种思路:

  1. 将任意数据序列化后存储在内存中,数据库不了解保存的内容类型

  2. 将特定类型的数据用既定的接口存储在内存中,数据库了解保存的

    内容的类型,并能对其做精细化的控制

第一种方式的典型代表是memcached, 而第二种方式的典型代表则是redis

这里我们主要讨论第二种方式。

3   redis分析

3.1   redis是什么

以下摘录来自redis官方的描述文档:

Redis is an open source, advanced key-value store.
It is often referred to as a data structure server
since keys can contain strings, hashes, lists,
sets and sorted sets.

注意,它也认可自身是一个数据结构服务器的说法

3.2   redis有什么特性

  1. 服务器提供多种数据类型,string, list, set, hash, sorted set,

    并且根据每种类型提供相应的操作方法,例如对于sorted set类型,

    就有获取某些区间内值的操作方法,这个对于典型的web列表分页是

    非常有帮助的

  2. 服务器的数据类型是抽象的,比如hash类型,自从2.2以后,对于小数据量

    的hash类型,使用的是一种优化过的叫做zipmap的存储,而大于一定数量

    以后,则切换到另外一种存储,(由此引发了切换攻击,:])。这一点

    是很便利的,用户得到了使用上的便利与存储上的便宜。

3.3   redis有什么问题

3.3.1   数据类型仍然不够丰富
redis相对memecache开启了内存存储与操纵结构数据的先河,大量的用户开始

把数据存储迁移到redis上,而把后面的sql只当作一种备份策略,但是问题在于

传统sql能够提供的一些策略并非全部都能映射到redis当前所能提供的一些方案

上的,例如 sorted set数据类型 只能根据一个score来排序,而传统sql方案可能

会支持两个到三个field的排序,ORDER BY field1 DESC, field2 ASC 这样的效果

目前官方是不支持的。又比如要限制某些类型的取值之类的问题,存储人的年龄的

至少不应该有负数吧

3.3.2   策略不够灵活
前面说到,redis的数据类型是抽象的,举的例子是hash类型,提到小于一定数量的

hash类型其存储类型是使用zipmap,而超过以后则切换到另外一个存储类型,虽然

这个边界值是可以调整的,默认是512,你可以根据需要来调整,但是过了512以后又

到了65536呢?也许你可能要考虑使用SSD硬盘来替代部分内存的工作,毕竟内存虽然

便宜又大,但如果真超过了机器限制转而走集群的话,那速度未必有走SSD快呢。当然

这个问题官方不是不能解决,而是解决无力,因为官方不能保证用户服务器上有SSD,

或者是虽然你把数据都存在redis里了,但是有许多数据只是衍生的数据,比如sorted

set这个类型大多数情况下就是冗余的,相当于sql里的一个索引,一般来说他的member存

key引用,而score则存对应的排序依据字段。这种情况可能不同的数据类型重要性不一样

我们可能希望string和hash类型的数据都能够在硬盘上有一个备份,而list set sorted

set这些类型 可能由于存储的是key引用,所以不那么重要,丢了还可以重建,无所谓,

但很可惜官方目前无法提供如此灵活的策略

3.3.3   命令设计没有策略
redis的协议是人类友好的,命令式的,基本上来说是 数据类型+操作 对应一个命令,

但问题在于有许多操作从抽象角度来说是一样的,既然redis在数据类型上可以提供

抽象的数据类型,为何在操作上不能也做到这一点呢?

我举个最简单的例子就是 INCRBY 和 HINCRBY 这两个命令,这两个其实抽象的操作

效果是一致,都无非是将该命令相关参数确定的某个值给加上一些数值而已。但是由于

INCRBY是找到一个string类型的key 并增加他的值,而HINCRBY 是找到一个hash 中的

一个key ,并增加他的值,参数个数都不一样,可能大家会有疑问,这个怎么抽象?

其实换个角度来想问题,你就会发现参数个数是可以一样的。

我们参考下web前端的开发,以前要修改一个element,使用传统的w3c那套DOM操作,

你需要一层套一层的get_element_by_name, children 之类的调用来定位到最终需要操

作的元素上,然后调用相关的操作函数,这个一层又一层的调用层数是不固定的,有可

能1层就到,也可能5层,6层,所以这个问题与INCRBY和HINCRBY的参数个数不一样是类

似,最终的解决办法是,把定位当作一个过程,提供一些参数来一次定位,比如jQuery

的选择器,只要你提供一些魔法参数,立刻就能定位到相关的元素上,然后调用相关的

操作了,redis其实也可以这么做,无非是先定位,使用一套标记方法来限制数据类型,

分割符什么的 ,我现在就可以设计个简单的标记法解决INCRBY与HINCRBY的问题:

1, 设计一个命令叫 PLUS, 他只有固定两个参数,一个是定位器,一个是值

2, 定位标记可以规定,#开头的为hash类型, $开头的为字符类型,.(点)作为分隔符

    因此必须相应的禁止redis的key中使用特殊符号如# $ . 之类,这不是问题

3,根据1和2的规定 原来的 INCRBY str_key 1 命令可以改为 PLUS $str_key 1

   而 HINCRBY hkey field 1 则可以改为 PLUS #hkey.field 1

4,该方法还可以进一步套到 sorted set上去。

3.4   redis官方的补救

官方也意识到了一些问题,可能没我想得那么多,所以2.6以后带了lua script,原来只

是个分支,但是antire已经弄到主版本了,但问题在于lua虽然跟python ruby比是个小巧

的语言,但是在redis这种应用场景里,就算是个大语言了,lua核心也谈不上最小,

iolanguage就号称vm比lua的小多了。关键还不在于此,lua为着通用目的考虑,给语言加

了一些特性,这些是定制化无法删除的,你总不能把那套meta table的机制删掉吧?该类

脚本一出手,可能自身的语言机制消耗的性能要比完成的逻辑消耗的性能大多了,lua本

来就是面向table的,如果真的性能比redis的hash高,那就完全可以自己做个redis

server的角色了,我以前写的饭否爬虫就是用lua的table在内存里缓存了200k的用户信息

用起来就跟redis的hash一样的。

当然官方还无意识的提供了另外的有一些补救,比如由于是c写的,代码组织上又比较友

好,所以实际上你当然可以根据自己的特殊需求来定制一些数据类型,例如前面提到的

支持多个排序依据的sorted set,但是阿,这解决不了所有问题哥哥,如果你想在hash里

的一个field里再存一个hash,并且要跟系统的实现一致,你怎么办呢? 如果你是自己实

现了一个 naked hash 选定调用了官方的一个实现,那么如果有另外一个人也实现了一套

hash,你是否又要改代码以便在某些条件下去调用他的实现函数呢? 所以说这是个泥淖

任谁走进来,过一阵都会陷下去无法自拔了。

3.5   我的总结

redis 相比 memcache是开启了一种使用内存的新方式,这个开创性的举动当然是值

得赞扬的,但是一旦现在大家都加入进来,大规模使用以后,是可以发现其中存在的许多

问题的,例如 redis比memcache多的就是数据类型,但自己数据类型不够怎么办? 还有

策略不灵活,以前只是把memcache当缓存用,这个问题无足轻重,现在有的已经当作主要

数据库用了,那么这个问题就很重要了,再有就是命令设计的不够规范,或者再具体点,

不够正交,基本上是需要一个功能就多个命令,而不是从全盘考虑是否需要增加新命令

还是修改已有命令的实现。这个有点类似处理器分类中的 CISC 类型。像那个INCRBY与

HINCRBY两个命令的存在就好像x86里有这种寻址那种寻址N多种寻址一样。

4   我的方案

针对redis的那些问题,我给了一个另外的解决问题的方案。 这个方案在文章标题里就有

体现,既基于虚拟机实现的 ADT服务器,这个解决方案有两个重点:虚拟机与ADT

4.1   虚拟机

就像前面提到的那样,redis目前就像是CISC cpu, 有一个功能就加一个指令,这个

颇有点头疼医头,脚疼医脚,既然谈到CISC,那么不得不提到RISC,RISC对于CISC的改进

可以看得到的就是简化指令,这个大家可以参考下intel的x86指令集砖头书与mips的

mips32指令集的示意图,两者的差别应该是很明显的,如我先前所提到的那样,INCRBY

与HINCRBY 完全可以设计成一个指令,只是得配合另外一个定位功能,所以就像RISC虽然

精简了指令集数目,但往往实现同样一个功能会增加几个指令一样,我之前自己设计的

PLUS指令可能就会相对INCRBY和HINCRBY要多出一些判断数据类型以及多重定位的处理步

骤,这一点就我个人来说,是可以接受的。

另外的问题是策略不够灵活,我之前说过你完全可以自己定制类型实现,但如果是

嵌套的类型就比较难办,你得能够调用其他人写的实现,如果你不了解内在的实现,就c

语言来说就无法动态的调用相应的实现,也许函数指针是可以的,但你得定个调用规范,

类似FFI那样麻烦,这种情况下,不如使用分离式的设计,既将redis server分离为虚拟

机与存储器实现两个部分,虚拟机指令集应该由官方控制,但是预留客户定制的指令空间

至于存储器实现那就可以官方只实现经典的那些,而客户可以自行根据自己的策略实现某

种符合官方定义的数据类型,例如带SSD备份的hash类型,而list仍然只用在内存里的方

式,掉电不管。

这里的好处在于,通过分离式的设计,达到了策略上的完全灵活,一个命令,你既可

以带检查,也可以直接映射某个存储类型提供的操作,这一切取决于你的程序,相比较

redis2.6提供的lua方案,这个虚拟机的开销要远比起个lua其语言的开销小多了。另外

这个方案的好处还在于提供升级与降级的简易方案,写过虚拟机的朋友都晓得,移植cpu

远比移植一个完整应用容易,因为cpu就那几个指令,像我的tweezervm那更是精简得吓人

因为是堆栈式的,只有30来个指令,c/py的版本都能轻松实现,当然,其实你也可以用

fpga烧录一个专用的cpu,这个相比你的汇编实现的redis还给力哦。何况,必要时候你可

以轻松切换到jvm上去 :] 考虑到最近facebook正在往jvm上迁,企业用户应该更喜欢这

个方案吧。

4.2   ADT

ADT就是抽象数据类型的意思,学过c的应该有所了解,我虽然半路出家,恰好也在

云风那学到了这口黑话。ADT的好处在于你可以依据策略来调整实现,但行为的效果却是

对外一致的。这种方式,当然是很适合虚拟机这种设计的,因为你如果用c的宏 那只是在

编译时候就确定的了,在你运行时就糟糕了。另外核心的逻辑代码能够大大的精简,我看

c代码有大量的宏判断,为相关的调用做数据准备之类的冗余,核心逻辑往往就隐藏在这

一堆里,十分影响后来的人理解系统

4.3   具体的工程方案

我是个开发工程师而不是CS理论科学家,所以我能够给出一些工程上的实践方案,由

于ADT的部分实在是很简单,而且具体的工程方法与策略有关,我当然无法给出什么具体

的建议,因此我着重针对虚拟机的设计给出一些建议

4.3.1   虚拟机的建议
  1. 要设计cpu首先的一个问题是,设计成寄存器机还是堆栈机?关于这个的争论真是一坨

    又一坨,我个人比较喜欢堆栈机的概念,但是从性能上来讲,如果是软实现,寄存器

    机多半由于其可以映射到真实cpu上而变得性能很高,反观堆栈机,从forth的实践

    来说,一般操作深度大概是20左右,这个在mips机器上可以映射到32个通用寄存器中

    的20个,但是在x86上就悲剧了,当然如果你使用特殊硬件的例如chunk moore的

    green array,那情况又颠倒过来了。只是现实中毕竟是寄存器机比较多。至于寄存

    器机中存在的流水线,超标量,乱序等工程方法那倒是不必要的,我们应该向GPU看

    齐,他的内部是有好多的流处理器,每个只处理一个任务而已。

  2. 本来我是希望更灵活一点,把数据类型也变成一种附加的指令数据,但是由于不同的

    抽象数据类型有着完全不同的操作,而且由于存储实现那已经够灵活了,所以倒是可

    以把一些抽象数据类型独有的操作给独立出来,比如只有sorted set类型才有取排序

    后范围的指令,也就是 zrange家族指令,这个用在其他抽象数据类型上是无用的。

    至于说 给一个字符串类型设置字符串值与给一个哈希类型的一个field设置字符串值

    这种的是可以合并成一个指令的,既给某一个存储引用设置字符串值,当然前提是之

    前有个指令定位到了那个存储引用。

  3. 此外需要一些专有加速,比如查找hash key, 不光是在全局找,也可以在一个hash类

    型下找,甚至可以在一个hash类型下的嵌套hash里找,这需要设计者的通盘考虑,并

    设计出一套规范hash实现的机制。又比如一些 整数/浮点数检测之类的常用辅助函数

  4. 虚拟机的指令编译可以考虑做在服务器端,我指的是应用服务器,不是虚拟机本身,

    而客户端仍然像以往一样根据既定的协议发送指令过来,并且,客户端可以像soc

    开发一样,在线运行时给某个指令烧录其他的实现。考虑到一个指令往往逻辑并不

    复杂,这完全是可行的

4.4   我的方案的一些问题

  1. 代码品质问题,有可能某些恶劣的实现拖累了整体的运行速度,或者是某些实现

    会泄漏内存,额。

  2. 多种实现的冲突问题,比如两个插件都强调写硬盘,由于互相争抢,反而有可能

    导致双方的效率都低下从而无法达到预期的效果

  3. 开发者的预期可能和具体的实现不一致,不过我觉得出现这种问题,多半是那种

    开发与运维有隔阂的大公司,小团队应该问题不大。

Author: jyf
Published on: May 28, 2012, 8:00:00 PM - Modified on: Jun 22, 2013, 4:37:31 PM
Tags: idea, vm, adt, redis
Comments - Permalink - Source code

关于豆瓣网的富媒体化的想法

目录

1   引子

很长时间以来,我都保持着一个习惯,就是先去 豆瓣电影 寻找我喜欢的某部电影,

查看其相关的推荐电影清单,又或者去某个豆列寻找一些类似电影的清单,得到这些相关

电影的名字以及一些评论以后,确定要看哪一部,然后去某些著名视频网站 [1] 寻找相关

播放页。 但我感觉这样的步骤实在是多余,而且随着打击盗版的力度加大,视频站的搜索

是越来越弱, 以至于根本无法搜到你想看的,而其实那个视频确实在的。但是我想,那位

在豆瓣上发评论的人应该是一定有个地址可以播放的 :]

2   问题

豆瓣网 是一个社区,虽然我不是其重度用户,(我是 GR 重度用户), 但是有些

需求严重依赖他,比如前面所提的找电影看的需求, 还有找书看等等,在这些核心的应用

方面,豆瓣的体验都做得还不错,饶是如此,我仍对前述的流程不满意,因为有太多的电影

我找不到,简言之是命中率太高,失望也就大了。你想想,看到那评论,动心了,结果找

不到任何可播放地址,要走非法路径下载的话,目前这个网速也是不给力,等到终于把电影

拖到本地以后,激情恐怕早就不在了。

3   我的想法

3.1   豆瓣应该做的事

3.1.1   电影页

有几种思路可供借鉴

  1. 在电影介绍页提供添加嵌入式视频播放的功能,这个直接开放给用户,借助用户的力量

去补充相关的播放页,从而把用户都黏在网站内。

  1. 由官方根据页面上的 想看 的统计数据, 人工对热门的电影添加播放页,这个似乎

以中国的国情来看,比较符合实际的控制需求,能够满足审查部门的无理要求。

3.1.2   图书页

图书方面豆瓣本身就有商店购买推荐的,不过我们应该考虑一些问题

  1. 许多书买不到纸张版本了。
  2. 有许多书是需要勘误表的。
  3. 还有些书,是需要周边的配套的,比如需要配套的磁带,或者配套的习题集, 典型的同时包含

这两种配套物品的就是 英语教材, LOL

要解决此类问题就需要

  1. 提供文档嵌入,比如国内最大的版权内容集散地: 新浪爱问 以及老二的 百度文库 现在

就利用flash支持文档嵌入,他们的本意是提供预览,但我觉得豆瓣这里使用可以就是提供全文电子

化阅读。

  1. 还可以提供冲印服务,许多书都是小众的,出版社不敢多印,但考虑到豆瓣有这个想读这种功能,

用户习惯培养很好,可以增加一个团购印刷本,就我所知 china-pub 现在提供此类服务,也有一些

专门的网站提供书籍印刷服务,如果能与豆瓣结合一下,相信对大家都有好处。

  1. 勘误表的问题,其实靠文档嵌入就可以解决了,因为只要增加在文档相关位置插入勘误的功能就

可以了,这个对于读者快速获得勘误位置很有帮助。

  1. 周边产品需要的也是富媒体的插入,这里的富媒体不单指视频与音乐,还可以考虑教材类书籍的

习题集等,我曾经给大学一个教师做过一个调查问卷,也无非是单选,多选等选择题,此类题型都可以

用flash/js实现,作为教材的配套测试提供在豆瓣的书籍信息页面上,对于各种教材类书籍的反馈是

很有帮助的。

3.1.3   活动页

豆瓣有许多同城活动,但是要举办线下活动显然就限制了参与的人人数了, 这是很容易理解的,原因无非是

同城就限制了外地的朋友参加的可能性,线下活动则一来有场地限制,二来人太多了,容易引起相关部门注意

但有些活动必然是会引起大量人群关注的,比如某个科幻讲座,某个技术论坛,以及某个线下选美腿什么的,

虽则有照片,但我其实希望豆瓣能提供两类视频嵌入

  1. 活动的直播视频(这个或许可以找 pps/pplive/tencent 之类的有经验服务提供商)
  2. 活动过后剪辑过的

3.2   如何获取效益

无利不起早,利当然是要重点考虑的, 以我个人对豆瓣的一些小组的参与来看,大家似乎是有能力以及意愿

享受付费的优质服务的,所以这就很简单了

  1. 提供付费的服务,比如前述的冲印图书
  2. 与第三方服务提供商分成,这个似乎是豆瓣的传统模式,只是实施起来需要考虑统一付费方式,总不能用户在

每家都注册个付费会员帐号吧。

4   存在的问题

  1. 有关部门, 有些书籍,影音在国内是 不应该 出现在公众视野的,以往豆瓣只提供一些文字介绍,最多是

图片,如果全面富媒体化以后,要小心在这里中招,因为目前看来,最不理性的就是有关部门,一个不小心封站是

有可能的。慎之慎之!

  1. 某些公司,只要在地球上做服务,就要谨防来自中国的 c2c [2] 攻势,所以这点也是需要考虑的,不要为他人

做嫁衣忙活一场。

  1. 计费策略与形象公关问题。收费这东西腾讯做得最好,不过也因此形象很不好,腾讯的庞大而默默的用户群稀释

了对他的一些负面指责声音,但我想豆瓣的那些个用户可都不是好惹的,呵呵。

5   最后的话

  1. 文章只是拿豆瓣来做典型,重点在于表达新时代的网站应该着重内容的混搭以及提供一站式服务的问题,可以将豆瓣

替换成任意相关类型的网站,比如 果壳网

  1. 对于优酷等视频网站,光靠目前这个电影院模式还是太乏味了,所以我考虑要发篇文章讨论这个,暂且加入todo

6   文中引用链接

[1]比如 优酷网(http://www.youku.com/) , 土豆网(http://www.tudou.com/) etc
[2]copy to china
Author: jyf
Published on: Dec 17, 2011, 8:00:00 PM - Modified on: Jun 22, 2013, 4:37:31 PM
Tags: idea, douban, rich-media
Comments - Permalink - Source code

android 市场的一些想法

目录

1   引子

前一阵关注了很长时间的 jz4770 终于在市场上开卖了, 艾诺出了个平板,使用此处理器,

我去看了论坛的测试 [1] ,感觉不错,续航又行,又是我想玩的 jz4770 , 所以就买了一个,

价格也便宜,买来以后发现确实续航不错,比我的 g7手机好多拉, 只是屏幕分辨率有点低, 所以

如果要我给别人推荐,我不推荐这款产品,只是对我个人来说, 我只是拿来测试而已,倒也无所谓。

2   问题

分辨率是一方面的原因,但另外一方面的原因则是直接制约了这款机器的推广,他的兼容性问题,

大家可能以为android是java平台,应该没什么兼容问题,其实恰好相反,问题很大,android虽然看

起来在市场上支持了那么多手机,其实日常的也不过是arm和x86, mips是后来才开始加入支持的, x86

基本不是日常用的,所以市面上清一色的 arm, 也因此,很多人动起了加速的主意,大多数程序都或多

或少用了arm加速, 在市面上一片 arm的情况下, 没有出现兼容性问题,反而对程序加速有所裨益,

可是一拿我这个 mips的平板出来后,马脚全露出来了,到现在我也没找到一款可用的终端软件,大家

都是拿来主义,直接拿java做个壳包装了下现成的c的terminal库。

3   我的想法

我的想法是, app market 不单只是做个 app 下载,计费的托管地,还应该成为一个开发团队项目

管理,自动打包测试的平台,用给开发团队带来更增值的服务提升自身的地位,只是个下载地的话,就太

低级了,这也是山寨市场满天飞的一个原因。

具体来说, 应该具备以下的功能

包括代码托管地, 可以与 google code 整合, 也可以另开炉灶, 可以选择开源,也可以选择闭源,

还应该包括开发管理的一些工具,像 nightly build 之类的, 提供早期开发版本之类的, 还有 bug追踪,

如 trac 之类提供的功能, 如此才能拖住开发者, 而代码放在市场上的好处在于:

  1. 有利于程序调查,用户对程序表示异议时,可由 google 出面开具无害证明。
  2. 有利于性能调优,google可以在后台对代码进行优化调查,给出一些优化建议,这个对于广大初中级程序员

的开发十分有利。使得开发经验不足的程序员也能依靠优秀的点子胜出。

  1. 能够快速发布多平台版本app, 在google推出新的平台以后,能够迅速检查代码,判断能否直接编译打包?或者

依赖前面所说的那个特性, 给出需要移植的地方,对于迅速推出新版本很有帮助。

  1. 为客户定制软件, 如果代码能够遵循一定规范, 相同的软件,可以针对不同的用户提供不能的定制版本,

比如针对 我的 htc g7 可以去掉代码中的许多 硬件探测部分。对于我的 mips平台, 以及后面会加入的各种

平台,也能在一夜之间提供相应的平台版本程序,厂商的精力能够放到底层优化而非市场培育上,这对于拉拢盟友

很有帮助, 事实上甚至可以直接把dalvik-vm 上的字节码转换成客户手机上的机器码,这样速度应该会快好多。

  1. 这是最后一点, 可以方便的切换到其他语言去, android其实提供的是 jvm而已, 在jvm上已经有一些寄生的

语言了, 像scala, jpython, jruby什么的, 如果能够籍由gogole提供的代码打包服务, 大家就可以放心的使用

自己喜欢的语言来做开发了,一旦google碰到这次 oracle 状告的情况, 就能很方便的换个底层解决了。

4   存在的问题

  1. 收费还是不收费的问题
  2. 有些公司不愿意提供代码给google
[1]http://bbs.imp3.net/thread-10493859-1-1.html
Author: jyf
Published on: Dec 12, 2011, 8:00:00 PM - Modified on: Jun 22, 2013, 4:37:31 PM
Tags: idea, android, app-market
Comments - Permalink - Source code

关于门徒这部电影

目录

1   惯例的话

刚看了部电影,叫《门徒》, 一开始就当是普通的磕瓜子时间电影来看,

没想到第一句就把人给吸引进去了,吴彦祖那句:

“吸毒,是因为空虚,那到底是空虚可怕,还是吸毒可怕?”

直接就把我抓住了。于是收紧注意力接着看。

剧情倒是不复杂,卧底电影,最后成功起出,把他们一网打尽。倒是其中一些

小细节相互呼应,连缀成串,给人勾勒出了一副现实的场景。

片中昆哥一直说着说着不要相信别人,尤其是教育阿力不要相信吸毒者的

鬼话,然后又大谈市场供需,这个倒是显得出他的心虚,所以要不断的强调吸毒者

的问题来安慰自己,hmm. 阿力在片后也曾经犹豫了下想要走进吸毒者的路,幸而

被小女孩把工具给扔了,不过我想根源解决不了,以后会不会重演呢?

其实片里最后那一段真的很有意思,最后阿力去问啊芬的老公为何不戒毒,

此人给出了和啊芬一样的答案,大家肯定觉得他这个该死的吸毒者在撒谎编造

理由,但我以为这里倒是跟前面昆哥谈的相互辉映了,这两个人都是吸毒者,

你不能光看演员的外表而决定相信那女的而不是男的,有时候女人说谎可比男人

精多了,两个人一样的理由,理性的观众一定会由此产生对啊芬当初吸毒原因

的质疑,进而对啊芬这个人产生质疑,一下子就推翻了先前那种认定的角色设定

所以说这里做得非常不错。

2   引申的

首先要说的是,我能够理解这些人吸毒的原因,破败的家庭,暗淡的前途,

注定无光的人生,这样的生活能带来什么呢?不用说家里也没有电脑,也没有

互联网接入,打开电视也多半是那些无聊的节目。我这样爱好互联网,热爱搞

技术的人玩着互联网偶尔还会觉得无聊,何况是他们呢。

一般人感觉不到是因为有这样那样的物欲吊住,为了这样那样的物欲而去

维持一份工作,而为了这份工作又要投入自己全身心去,这样自然不会无聊了,

假如偶尔停下来喘口气,思考思考,其实也会觉得无聊的,但是现代工业体系好

就好在 不用鞭子抽打你,你也会自动拼命干,系统没有给你停下来喘气的机会

自然思考的机会也就剥夺了,在很小的时候,思考的机会业已由经教育甄别出来

的少数人给夺了去了,剩下来的都是一个个的水袋了。

这里产生一个社会问题就是,自觉生活充实的精英应该如何看待那些淘汰赛

中的大多数失败者,在民主国家,虽然这些人话语权加大,不过其实那都是假象

世界越来越由精英去控制了,这是趋势。扯远了,精英与那些身体构成,体液

成分几乎一样的别样的同类们,究竟该如何相处呢?或者说如何去帮助那些人,

避免使其自身陷入一种并不乐意的状态。我想有个古老的妙方是宗教信仰,虽则

科技发达的今天,沙漠诸一神教的体系在崩溃,但换来的无非是新的内容,披着新

外衣的另类宗教崛起而已,比如我们这些爱好科幻的群体,爱好瑜伽,追求xx文化

什么的,甚而是飞天面条怪教,种种形式,无非是换了点坚持的内容和形式,本质

上还在于给每个人找一根无形的鞭子,好帮助你进入工作状态,:D

3   扯得更远的

想到了黑客帝国里,机器人完全靠刺激人来发电这种模式,这里生存的人跟

吸毒者不就是差不多的么,但人体内本身也会合成多巴胺这种自产自销的毒品,

平时为了获得那份喜悦,感动种种多巴胺奖励,也会鞭策人去跟吸毒者一样地

“不择手段”。 感觉人的多巴胺奖励是有限的,一生中所获大概也和那些吸毒者

短短的一生中所获的差不多,那究竟是这种细水长流好呢还是樱花似的绚烂好呢?

各人有各人的答案,那些舍己救人的英雄,不知道挂之前有没有吸毒者体验。可惜

现实永远是现实,这类问题就跟小头大头一样,永远是无法解答的。

另外想到了今天看的 bill joy写的 why the future dont need us, 感觉他

基本是老调重弹,我因为经常看科幻,对这类一点也不觉得陌生,只是我想,后

机器人时代,假如侥幸机器人对人类就实行那种养小孩的态度,会不会产生整个

社会的人类都空虚无聊,进而陷入吸毒者境界呢?

科技的未来很黑暗
Author: jyf
Published on: Aug 8, 2011, 8:00:00 PM - Modified on: Jun 22, 2013, 4:37:31 PM
Tags: movie-comment
Comments - Permalink - Source code

about-gtld.rst

目录

1   缘起

关于gTLD的话题其实去年就有所耳闻了,当时初一听也觉得不错,也有一些想法,

但是发现其实还在讨论阶段,并没有实现的意思,所以也就作罢了,前一阵突然

看到cb新闻 [1] 说正式通过了,价格也敲定了,所以一下子有了兴趣了。

2   谁会受益

2.1   装逼企业

比如爱国者 [2] 和佳能 [3] , 但以我浅薄的战略意识来看,意义不大,纯属

装逼

2.2   SNS网络

这个才是重点, 比如 人人网,腾讯, 新浪微博, 这三家是典型,人人网和腾讯

都有个问题,赚钱要靠哄用户,特别是腾讯,但是腾讯的那些会员qzone什么的实在

不咋的,名字长又长,邮箱本来也是,现在好多了。让我们想想看,假如腾讯申请了个

.qq 的gTLD, 那么首先所有用户都有 qq号码.qq 的qzone空间了, 进一步整合的话,

就是个人在腾讯这的门户, 下面再分级搞各个服务的菜单,会员有权选择字母域名,

呵呵 ,典型腾讯运作。

人人网和微博也差不多,尤其是人人网。

2.3   多入口的服务

这里说的是比如gmail这样的服务, 我的邮箱是 jyf1987@gmail.com, 事实上gmail

是支持把所有 发往 jyf1987+xxx@gmail.com 这样的邮件发到我这里的,但是,这个是

不通用的,经常有email validator会不通过。 所以如果换成 xxx@jyf1987.gmail

这个问题的解决就完美了。

3   总体收益

首先这些举例都是大型网络社区,他们是需要集群的,现在许多系统的思路是把相关

的数据存放在一块,拿人人网来举例, 我可以拥有一个 jyf1987.renren的域名,这个域名

根据他们的存储策略被解析到具体存我的所有相关数据的那台节点上去,这样他们所有的

数据存取都在本节点上进行,对于性能优化可能有帮助

其次就是有助于突出用户的地位,使用了该类gTLD以后,网站运营方自己的一些系统

功能模块也用的是和用户平级的域名,这个更符合今后扁平化的发展趋势,打个不恰当的

比方就是好比google今后将自己的新服务都放到GAE上部署了,和用户平级了。

4   存在的一些问题

4.1   技术问题

#. 跨域问题, :] , 这个好理解, jyf1987.renren 和 xxx.renren 这两者的ajax post就有 点麻烦了,不过我感觉新式浏览器能解决,或许采用flash xmlsocket 那种许可模式。

#. 大段内容的CDN, youtube这种服务就很难享受到好处,而且潜在访客无法预测的,大视频 数据传输量又大,所以这是个问题,解决思路恐怕是换架构

4.2   对行业的影响

#. phishing更容易or更难? 说他容易是,后缀名增多了,企业防不胜防。说他难是因为,大企业 可以就注册个gTLD, 教育用户以此为识别,这个反而phishing不了了。

#. 提供整站解决方案的企业会强者愈强,而且抬高了做社区网站的门槛,185k USD的setup fee加 每年70k USD的年费可就不好玩了,何况为了使用流畅,还要考虑各地有dns节点

5   一点小建议

要不大家组团去团购.qq吧, 185k USD也不多,到手后一个域名10块一个月卖给腾讯用户,

一下子就能赚回头了。

[1]http://cn.reuters.com/article/CNTechNews/idCNCHINA-4478720110620
[2]http://tech.ifeng.com/internet/detail_2011_06/22/7187997_0.shtml
[3]http://tech.163.com/digi/10/0318/09/6223GE2K001624J2.html
Author: jyf
Published on: Jun 30, 2011, 8:00:00 PM - Modified on: Jun 22, 2013, 4:37:31 PM
Tags: idea, gtld
Comments - Permalink - Source code

enhancement-of-beijing-traffic.rst

目录

1   缘起

本文缘起于笔者日日在北京挤地铁,积数年之怨气而作。总所周知,北京交通十分拥堵,

城区设计不合理导致交通运输一方面需求量很大,但是另一方面现有方案可供提升的空间

却不多了,故此,笔者有必要绞尽脑汁,来为北京交通提项改进

2   问题分析

2.1   为何交通很拥堵

我们知道,北京的交通不可谓不发达了,公交线路多如牛毛,地铁线也是四通八达,何况

赖政府财政补贴,该地交通费用及其低廉,人们出行也多选择公共交通(这里自然是指普通

人类),从这个意义上讲,公共交通设立的目的是达到了,既然如此,为何交通仍然如此拥堵

呢?这就需要我们仔细观察下了。原来问题出在不合理的城区设计上。

北京城城区分片十分鲜明,西北,东南等刚好分别是it,媒体公司扎堆处,由于公司扎堆,自然

抬高了中心区域的租房价格。迫使大量的 民工 跑到近郊租房,比如天通苑,回龙观,通州等等,

这批人数量很大,是造成早间高峰拥堵的那一群,当然也是身受其害的那一群。另外我们大家要看到,

北京中间有个紫禁城,这么大个地方,却不能住人,而且除了地铁能穿过去,其他私车也好,公交也好

均不能穿行而过,给交通线路规划造成了很大的麻烦。

另外有一个问题是,乘坐北京交通的很大一部分人往往是穿越很大一块区域到达上班地点的,

一路上往往只有上的人,而没有下的人,这也是造成拥堵的一个重要原因。

2.2   解决的要点在哪里

其实我们稍作观察可知,交通十分拥堵情况主要发生在早高峰以及晚高峰这两个上班族出行时间,

要解决此一问题,应该要解决上班族上下班瞬间高峰的问题。这个目的决定了,我们无法靠增加车次来

解决问题, 因为人人几乎都是要在那个点数上下班的,而且虽则设计交通的人该骂,运营交通,至少

是地铁的人,却还是很尽责的,据观察,早晚高峰,地铁发车时间间隔都会大大缩短,但目前几乎已

到极致,每趟列车发车间隔都缩短到了1分钟左右(掐表算过),因此增加车次已无提升空间。

回到问题上来,现在我们解决问题的关键在于:

在一定时间段内尽可能多地运输人群,使其到达目的地

3   问题解决

3.1   枪毙掉的方案

增加地铁车次? 枪毙原因前面已述。

增加地铁线路? 目前已经在实施,但地铁线路投资浩大,目前在建的几条线路只是考虑到了几个

新建或扩建的居民区的出行问题,属于填补已有需求,再者,地铁方面绝不会让地铁载运冗余的,原因

仍是如前所述,耗资过大,因此,随着新地铁线路的落成,部分地区势必成为购房热土,居民纷纷涌入,

最终地铁仍然拥堵。

拆掉故宫开路建房? 这个如果能够实施,倒是能解决交通问题,只是笔者自己也想不到它的可能性。

3.2   本文的方案

3.2.1   节流

既然无法增加车次来扩容,那就靠调整列车内部设置来扩大载运量,笔者认为有两个方面可以考虑:

首先,如前所述,公交地铁高峰期多为长途运输,一路上多上少下,因此可考虑增设车内扶手以及车顶

拉环,原因车顶不设拉环是为了方便下车的人不致为中间的人堵住,但现在既然极少有人下车,那么就可以

考虑多设拉环,以便于多站人。

其次,将公交与地铁的座椅改为可收起。据观察,一个坐着的人大概占据2.5个站着的人的空间,倘若

高峰期可以将座椅收起,则运载量势必有所提升。而且,我们知道,由于老人有其出行的优势,早高峰期间

也能看到不少老人乘坐公交出行买菜办事,如果座椅收起,则应能迫使部分老人选择其他时段乘坐,如此

又能腾出部分空间来给真正急需的人。

3.2.2   开源

只想到一个理想的方案: 飞艇运输

飞艇运输有几大好处:造价便宜,可伸缩性强,部署灵活,能够并行运行。飞艇本身就不贵,而且无须

像地铁那样修建轨道,我们要知道,造地铁最贵的就是挖那个地铁隧道了。地铁一旦造了轨道,你开与不开

钱都砸了好多好多了,而飞艇则没有关系,可以随时根据客流调整线路,公交也有这个优势,但是公交需要

根据在地面修建好的道路上行驶,碰上堵车会很纠结,我想这也是大多数人选择地铁的原因,飞艇既如公交

一般灵活又如地铁一般迅捷不堵,实在是结合两者优点的一个东西。飞艇还可以随客流增加而增加投入的飞艇

数量,地铁线路则不能说开就开,就算你想开,也不是马上就可以开成的,公交本是可以说开就开的,可惜

北京城堵车也是非常厉害的,所以多开也不是很现实。何况飞艇还可以一条线路同时发多个来运输,相比之下

地铁线也好,公交也好,都无法做到,(公交那个是伪并行),

大家可能想到安全问题,其实无须担心,现代汽艇都是具有十分安全的防护的,不像30年代那种居然可以

点爆的,而飞艇速度能达到0-100km/h ,所以这个也是十分快了,笔者每天大概坐地铁是20km,如乘飞艇高速飞行

也不过是10几分钟,当然加上从飞艇站至公司的时间,大概20分钟出头就能到吧。

另外我有朋友提到空中飞行,遇到大风怎么办?其实这个也不必怕,飞艇能抗7-8级大风,而我在北京两年

多,至今未遇到8级以上大风。

4   结束

非常欢迎各位将自己对本人提出的方案的批评,意见,以及担忧方面提出。
Author: jyf
Published on: May 18, 2011, 8:00:00 PM - Modified on: Jun 22, 2013, 4:37:31 PM
Tags: idea, traffic, beijing
Comments - Permalink - Source code