Skip to content


JazzMeme,一个新的新浪微薄客户端,开篇

因为公司工作的原因,需要研究一下新浪微薄的开放平台。与其做一个孤没芳还自赏的闷葫芦,不如把整个的过程记录下来分享给大家。
小弟自以为还会写点程序,故恬不知耻的把整个的思考过程、代码、遇到的一些问题及解决过程一一记录下来,希望能够对广大在IT这个道上混的朋友有些许的作用,我也就算没祸害人类。

在项目什么都还没有的时候,我先感谢一下我亲爱的女朋友萌萌,是她一直支持我,才让我在程序这条倒了霉的不归路上继续傻了吧唧的走下去。

从现在开始,我会记录下这个的整个过程,当然今天当我有这个想法的时候,我并没有一行代码,也没有明确的产品想法。所以这个过程不但各位读者不知道会怎么样,就连我也不知道。而产品的形态,则很可能是根据各位用户(也许悲催的一个用户也咩有)的需求、要求不断的变化和进化。就让我们在程序开发上也体验一次美剧编导的感觉吧。

me@yinwm.com:~$ 如何开始?

一切的一切都需要从一个新注册的新浪微薄应用开始,你可以去 http://open.t.sina.com.cn 转一圈,不管是文档什么的,还是怎么注册,那有比较清楚的介绍,我就不费口舌了。

me@yinwm.com:~$ 选择一门开发语言

我们在开发一个东西的时候,很现实的问题就是选择(一门)开发语言。

相信有一类程序员是不会为此犯难的,那就是锤子党(我编的这个词)。锤子党的一个特点就是会了一种语言,然后看到任何需要开发的应用都是钉子,然后这个语言就可以大而全的搞定它。比如认为Java无所不能(虽然我身为一个Javaer,但是这样的Java程序员我见过不少);或者觉得什么都要用先进的RoR来开发。

在这里我不想勾起无畏的超过我智商的语言论战,我只是想说一下我的看法。语言,只是一个工具,目的应该是满足我们的需求,而不是为了某种莫名的原因去选择什么。那么我选择语言的准则是两个字:合适。尺有所短寸有所长,不同的需求和场景需要不同的语言。

我从这几个方面考虑为什么选用一门语言:

  • 开发者对语言掌握的熟练程度
    • 现有的开发者
    • 如果是团队作战则也需要考虑可招聘的人才市场的供给,比如相对PHP程序员,Python程序员的可选择范围会小很多。
  • 产品需求的侧重点
    • 是要求大规模计算的还是尽快的产品迭代的,等
  • 需要运行的平台
    • 是Web应用还是桌面应用
    • 操作系统,Windows/Linux/Mac 一个还是多个
    • 设备,比如 Android 或者 iPhone 就别想了,直接用 Java 跟 Object-C 就好了
  • 已有的资源
    • 是否有现成的(开源)库,如做搜索类的东西,那么 Lucene 就是天然的选择
    • 是否有活跃的社区

当然在这里我可能无法全部的罗列出我思考的元素,但是总而言之,我认为语言应该是工具。技术应该为需求服务。当然,如果你只会一种语言,那么可能就没有办法了,但是我对你的建议就是再去学习一门语言吧,不同语言的不同思考方式,会让你对编程有更多的理解。

好了,该说我选择的语言了。我选择的是 Python 。原因是Python便于快速迭代;社区提供的资源足够多;国内Python社区发展良好;暂时定位在桌面应用,但是如果迁移到Web应用Python也可以应付的来。暂时妥协的是,Python很难迁移到 Android/iPhone 平台(也许我并不知道),但是暂时就不管了(会有一些其他的考虑,后续的篇章会提到)。

me@yinwm.com:~$ 给自己的应用起一个名字

一个好的名字是非常重要的,不过有时候信手捏来的也是不错的。在晚上回家坐公交车的时候,我想到其实这个项目就是某种意义上的 Twitter 客户端。

Twitter表示的就是小鸟的 JiZha (叽叽喳喳)-> JiZa 会不会更好 -> Jiz 呢 -> Jiz 什么意思?会不会读起来在英语里面并不好? -> Jazz 爵士随心的演绎很能表示这种随波的讯息 -> Jazz太短,就 JazzNews 吧,随意的讯息和信息 -> Google 一下 JazzNews 有 1.4m 个结果,很容易重复 -> JazzMeme,嗯这个不错,随意的小信息块,Google 只有 8k 个结果,就他了。

就这样项目定名  JazzMeme

me@yinwm.com:~$ 找一个地方托管自己的代码、License

这是一个开源的项目,那么肯定是找一个地方托管自己的代码,这样大家也可以第一时间看到各种进展。我考虑的地方有 github/bitbucket/google-code。因为我一直在使用hg,并且想熟练的使用下去,那么首先排除github(虽然我很不舍)。然后考虑到 google-code 的 Wiki/Download/Issues 等周边服务比 bitbucket 好,所以选择 google-code,代码使用 hg 管理。

License,我并没有选择GPL,感觉太粗暴,花两秒钟在 MIT 和 BSD 中间犹豫了一下,鉴于更熟悉BSD,那么选择BSD。

其实在考虑从托管的时候,我还想到了 SourceForge ,但是无奈,这个老牌的东西已经没有以前那么有影响力了,所以在我都搞定之后才想起来。

项目的地址是 http://code.google.com/p/jazzmeme/ 。还没有半毛钱的东西,希望我不会让这个坑一直荒废着。

Posted in JazzMeme, 程序设计.

Tagged with , .


充实快乐的一天

今天,确切的说是从昨天晚上10:50左右开始的。

我这几天在尝试调整作息时间,也就是每天早起一点点。昨天和猫叔说好聊一下用户验证的事情,结果这家伙放我鸽子。那好,去早早睡觉。结果就不该抱怨,就在我准备关电脑前5分钟,猫叔赴约了。娘咧。
跟他一起讨论了很多关于用户验证的东西,主要基于我在139设计的一套无状态的用户验证和OAuth,分别讨论了优点缺点和可能的问题。就这样一边被他折腾,一边看《生化危机4》,结果快两点才睡觉。女主角长的还不错哦。

睡觉到9点,一直惦记着去联通搞网络的事情,我决定不再蹭别人的网络了。其实主要是太不稳定了,还太慢。本来已经搞定了,但是营业员把局号搞错了,所以必须重新选号。还在床上默念起床时候,营业厅来电话搞定了这个事情,嗯,真不错。

中午十一期间定的电视柜送到了,大小刚好,而且还很窄不占地方。这期间断断续续的看了不少页书。中午还上浩方大了三局星际,不到半小时输了三局。不爽。

中午按照计划,背着电脑出来觅食。主要是要找一个好点的地方,能够让我安心的写一下午程序。果然功夫不负有心人,在经历了长达10分钟之巨的时间后,来到五道营,转了一圈,找到了一家叫做葡萄院儿的店家。环境很帅,当中的小院配上桌椅很性感。到了才google到这原来是一个非常有名的场所。
第一次来,要了一份推荐的英式早餐(中午吃早餐哇),还没吃过呢。上的很快,三个煎蛋,半碟子炸土豆块,两条培根,还有两片烤面包。正在我狼吞虎咽的时候,又上来一盘子满满的食物,有蘑菇,炸土豆,两根烤肠,半个烤番茄,还有点豆子。我的乖乖,这一份这么多阿,真点对了。来个烤肠先。
咦,怎么又过来一个服务员。咩?上错了?还端走了被我吃了一根烤肠的盘子。我还没回过神呢,又端回来了,还说是服务员的错误,所以都给我了。爽,爽上加爽的是又给我补了一根烤肠,这是为咩呢?难道是他们以为自己少放了一根?
结果我就这样吃下了三个煎蛋、两片面包、一根烤肠、两条培根、半碟子炸土豆、一杯咖啡之后,还有满满的一碟子食物。

吃饱喝足就开始变身成为一个死Coder,研究一下gae和4sq。写了几个小东西,但是到了验证的时候死活过不去了,总是报104,connection reset by peer. 搞了半天才想起来4sq是一个不存在的网站(你懂的)。也不能每次都传到gae上面测试吧。费了半天的功夫,终于让我找到了一个方法。
在我的ubuntu上(对,就是那个用来简易装13的道具),把代码托管到bitbucket.org的私有项目。ssh到dreamhost,从dreamhost上跑测试gae环境。就是编码太慢,动一下光标半天,而且dreamhost上面用emacs不爽(我不会vim)。活人还能让尿憋死不成,折腾emacs的tramp,ubuntu是内置的,直接ssh到dreamhost进行编辑。终于可以看上去好像在本机就能调试了。我容易么我。

今天第一次用番茄时间法,效率好高啊,高到快把自己折腾死了。晚上吃饱了,就是那剩下的一盘,你懂的。结帐,之前还手欠的升级ubuntu到10.10。结果下雨了,还是暴雨。我后面的座位漏雨,娇滴滴的小mm被淋了。(这手误)大大小小的接水的盆就离我不到十公分。

今天真是充实阿,这也太搞了吧。真哈皮。除了没翻到小月月的更新。

雨还没停,冲回家,走着,XDJM们,掩护我阿。

更新:现在已经在家洗完澡晾头发呢。回来时候,根据葡萄院儿服务员的介绍,用一个大的垃圾袋自制了一个雨衣,然后要了一个小袋子垫自行车座。一路飙回来,只湿了头发和小腿以下。而且出门选的破牛仔和匡威,太英明了。

Posted in Life.

Tagged with .


139,再见

今天很肆意的睡了下去,因为我已经正式的成为失业下岗大军的一员。

昨天办理了全部的手续,轻轻的离开了139。心里的确是很不好受。

新的旅程开始了,我也该开始总结我在139近两年的点滴了。

给点力吧老湿,都加了个油~~

Posted in Life.


域名丢了很多

今天很偶然的发现有域名要过期了,才发现丢了很多域名。

看来我的智商不足以支撑瞎搞,还是老老实实的吧。

Posted in Life.


这也许是我最后一次在139通宵上线了

今天整个移动集团要推动 http://10086.cn 的改造,http://139.com 正式尘封,改为 http://shequ.10086.cnhttp://t.10086.cn

在139刚刚成立的时候我加入了进来,已经快两年了,在这有很多的美好的回忆,我看着139一路的成长,经历各种成功和失败。我也一路从一个死Coder成长到现在的技术和项目经理。真是怀念啊。

现在我很可能离开139,去寻找我自己的一片天空。现在,晚上1:20分,大家还在为了上线而奋战。随着我们上线流程和系统的逐步完善,我们产品形态的逐步确定,通宵上线貌似已经是很久远的事情了。所以,这个时刻,也许还真是我的幸运啊。

一小时之后,荷兰就要和乌拉圭进行第一场半决赛了。比赛在继续,我的工作和生活也要继续,是时候开始我自己的冒险了。这一年半多的时间,我很开心,我很怀念。等我正式离开的时候,我会把这快两年的点滴回忆写下来作为纪念,以及思考。

PS:10086.cn 这个域名真山寨,本着我朝山寨既创新的风骚,让我们山寨到底。

Update:2010/07/07 附上通宵上线的人们

通宵上线的人们

Posted in Life.

Tagged with , .


入手iPad

我让朋友从米国带来的iPad到了。准备按照计划开始移动开发之旅了。

感受先。

Posted in Life, 互联网.

Tagged with .


我现在开始倾向于使用Hg了

用过一段时间的git,感觉非常之爽歪歪,但是也发现了一些问题,比如团队的成员并不是很容易的接受git,觉得麻烦。而且对于在含有*nix和windows上面同时开发的团队,经常要在不同的环境中处理回车换行的问题。这时候git不是不能解决,而是一遍一遍的给团队的成员灌输这些东西,成本是非常高的。

这两天抽空研究了一下Hg,发现国内外的“实用主义者”更倾向于使用这个。她和svn的一些使用习惯差不多,比如diff时候的版本号都是使用冒号(:)分割等等。这些小细节往往则是团队开发中选择一个工具的比较重要的因素。

我决定继续研究一段hg,然后考虑一下是否更加合适在团队中使用。

Posted in 技术快餐, 随想.

Tagged with .


今天情人节

春节快乐~~

Posted in Life.

Tagged with .


封闭笔记——第十八天,收官

2010-03-18 晴

今天应该是封闭的最后一天,我们要在最后一天把这次封闭的成果上线展示出来。这次封闭其实更多的是一个练兵,是让兄弟姐妹们能够学习和提高。

今天是我们的收官之战,同志们还在前沿阵地奋战。一拨人公司配合上线的,另外一拨人测试这次开发的功能,还有继续改代码的,还有我这样记录的。

今天大家都很辛苦,几拨人都是到了中午下午才把代码全部搞定提测。需要上线的有两部分,一部分人是这次封闭做的新的小的任务,我们姑且叫做团队A。一部分是和公司一起搞的一个大版本升级,我们不妨叫做团队B。两个任务同时上线,刚刚好可以做一个不是那么精准的比较。

  1. 人员组成
    • A组是一个中级程序员和三个初级程序员组成的团队,每人认领几个指令任务进行开发。
    • B组是一个半高级程序员,而那一个全人的水平是很不错的。
  2. 任务类型
    • A组是一个组合指令的任务,可以明确的拆分任务,而且B组的负责人前期已经制作好了一个框架。
    • B组是一个现有系统的升级,牵扯到新老平台的切换,而且要修改的代码很难界定范围。
  3. 开发模式
    • A组采用的是这次封闭尝到的单元测试先行的开发模式。
    • B组由于是修改现有系统,而且以前没有任何的测试类代码,所以还是传统的开发模式。
  4. 任务难度
    • A组的每一个细分的任务都不是很难,但是比较庞杂,想要做好了必须完全吃透需求和无数的场景。
    • B组的难度比较大,是公司的一个重点项目,牵扯的系统都很多。
  5. 任务强度
    • A组是这次封闭的主要项目。
    • B组时间非常紧张,本周才开始。
  6. 测试人员数量
    • A组一个半人,最后这半个测试人员也并入到B组的测试中。
    • B组的专职测试人员4+人,还有很多不明真相的志愿者。
  7. 测试时间
    • A组采用单元测试,从第一天可以说就在测试,从全部提测到测试结束大约3天。
    • B组由于任务重,所以测试时间并不多,但是从开发开始没多长时间就开始测试了。
  8. Bug
    • A组的Bug不能算少,但是严重的bug并不多,只是几个。大多数的bug集中在类似文案调整的类型。
    • B组的Bug并不是很多,但是每一个bug都很纠结。
  9. Bug的修复
    • A组的Bug由于存在测试用例,所以很容易定位,基本上每一个Bug修复的时间都不长。
    • B组由于没有测试用例,加之系统复杂,所以每一个bug都无法快速定位,必须依靠经验和对代码的熟悉程度。而且中间还出现了相关人员集中在白板前思索可能的坑在哪的问题。

上面是一个比较不靠谱的比较,也许并不公平。但是我们从中还是能看到一些问题的。比如有了测试用例可以快速的定位bug,比如如果没有我们会很纠结。比如我们每次修改的系统如果牵扯的非常多我们就很抓狂(应该把系统隔离的更好)。

现在已经早上6点了,我们还在准备上线。两个组都还纠结,但是看到曙光了。凡是我们用例定义的好的,测试覆盖的好的,很快就过了,否则都很缓慢。我们还有很长的路要走。

记得第一天我说,行百里者半九十,我们现在还远没有走到九十里。前面的路还很长。
前方的路不知是洒满阳光还是布满荆棘,我都会掸掸身上的土,继续走下去。

Posted in TDD, 程序设计, 项目管理.

Tagged with , , .


封闭笔记——第十七天

2010-03-17 晴

今天全天都处在疯狂的状态。几个小组齐头并进,我也亲自下水了。

还是发现兄弟们的基础还有待提高,而且往往是不对需求仔细了解就开始动手。这也是我发现的很多工程师的一个问题,就是总觉得动手早就是快。

工欲善其事,必先利其器。还是我昨天说的,必须吃透了需求,我们才能更好的进行下去。

这两天比较忙,昨天的东西现在才写,就到这吧。

Posted in 程序设计, 项目管理.