@ZEAL Blog·厉
WWW Zeal Blog
We stand alone,
TOGETHER.
+ 0 - 0 | §新春伊始,阳光普照

头一次不用从头到尾守着央视的春晚过除夕 -- 还是足总杯比较好看;

看完米兰和桑普多利亚的比赛之后倒头大睡,一觉起来阳光明媚,完全扫去前阵子阴雨绵绵的压抑。新年新气象,好兆头。

+ 1 - 0 | §辞旧迎新,上UTF-8

  一直以来想把这个从GB2312改到编码,但因为pivot采用的文本数据库使用PHP的serialize存档方式,数据结构依赖于字符串长度,一旦从GB2312改到UTF-8,非英文字符串的长度就发生了变化,原有的日志读取将发生错误。日志一天天增多,编码切换可能的潜在危险就让我越来越不敢去做这件事情了。

  昨天终于咬咬牙,决心彻底搞定这个问题,算是给自己新年带来的第一个新气象吧。写GB2UTF8的批量日志文件编码转换脚本、更新语言文件/模板文件、增加新的UTF-8相关字符串处理函数,一切在本地机器上测试相当顺利。没想到覆盖到服务器上的时候居然出现莫名其妙的问题,页面没法正常重新生成。用ftp维护上传文件是件痛苦的事情,经过几个小时的折腾,终于是“暮然回首”,在pivot站点上发现了db repair的工具可以轻松的解决问题,修复升级之后被局部破坏的数据文件。

  总算大功告成,两点教训:

  • 覆盖之前一定要在服务器上备份目录,而不是只在本地备份!不同环境下的备份即便只是简单的copy,也可能存在差异性。没有服务器Shell登录的权限,也可以想办法用PHP的passthru之类的系统命令调用来曲线执行Shell命令。
  • 碰到问题最好先到官方站点找找答案。看似简单的问题可能会越变越复杂,不如在自己给自己设套之前看看是不是有更简单现成的解决方法。
标签 ( WebDev ) :
+ 0 - 0 | §Links 2006-01-25: wiki巴别塔
  • wiki真是巴别塔?
    如果这样的行为蔓延下去,维基百科还能通过准确度测验么?
  • RssFwd : Reading RSS the way you are already reading your emails
    用RoR实现的开源RSS阅读系统,通过邮件订阅来阅读rss feeds。
  • 卖掉你的Blog@专业博客
    专业博客意味着高品质的个人媒体.那种只记录自己今天中午吃了几粒大米和几片白菜的Blog,无疑真是没有普遍性价值的.而专业博客,无疑会将中国的博客市场推进到一个新的高度。
  • Apache for Nokia cell phones
    在手机上搭建自己的Web Server,听上去有点螺蛳壳里做道场的味道。不过从大型机到台式电脑再到笔记本,设备越做越精巧。谁知道明天的个人终端是个什么样?只要解决了虚拟屏幕和键盘的问题,让用户能够方便的Read/Write,那么放在口袋里的个人服务器也不是什么天方夜谭了。
  • 18 ways to be a good developer
标签 ( 网摘分享 ) :
+ 1 - 1 | §高效程序员应该养成的七个习惯

对于软件工程师来说,工作也许意味着许多东西 -- 稳定的收入、做自己感兴趣的项目、找一份更好工作的跳板,或者你只是喜欢与其他程序员共事。但说到“效率”,强调的是在一定时间内按质完成项目的能力。Phil Chu根据自己的经验提出了高效程序员应该养成的七个习惯。建议去看看作者的原文(可能需要代理才能正常访问)。

  • 理解你的需求
    成为一个有效率的程序员首先要知道如何正确的支配自己的时间。对时间最大的浪费莫过于去做那些没有用处或者永远不会上线的项目。而导致这种结果的根源往往是对需求理解的偏差。
    要最大程度避免这种情况的发生,最好的办法是快速建模,尽可能让演示系统早点出来。对于客户来说,只有看得到摸得着的产品摆在面前,他们才会有兴趣去试用观察,才会在实际的操作中发现供需双方在需求理解上的偏差。否则即使你写上几百页的需求分析文档也只能是自己的一面之词,客户可没耐心去检查这些文档写的是否准确。
    另一方面,你应该让每一个阶段的开发成果都能够尽早的提交给客户。让他们以完全不考虑操作合理性和业务逻辑性的傻瓜级操作来发现程序员编程中的固有思维局限。尤其必须让QA尽早的介入到项目开发中来。如果能够每天提交一份测试版本给QA自然是最理想的了,但大多数项目开发做不到这样的粒度,那么就争取每周提交一份可测试版本。重要的是应该让QA和开发能够保持交错并行状态。只有这样,才能让QA尽早发现bug,降低每个bug的修复成本,同时缩减独立测试周期的跨度。
    程序员往往不愿意把半成品代码交付给测试人员,相反他们更喜欢在所有代码都完工,达到自己满意的程度之后再让别人来测试。因为在这之前的代码往往存在很多程序员自己知道需要修改(或者故意留待后续补全)的流程缺失和Bug,测试人员并不知道哪些是真正的Bug,哪些只是临时性的运行错误,每次都会一股脑儿作为Bug反馈给程序员。这往往让程序员们心烦。同时测试人员有时候也不喜欢测试这种很多分支都走不通的中间版本。
    但不管喜不喜欢,测试并发现问题是测试人员的工作;程序员则应该认识到,Bug反馈得越早就越是件好事情。QA和开发之间的关系往往很敌对,可实际上双方的目标是一致的。“忠言逆耳”古训有之,对于程序员来说就应该“有则改之,无则加勉”。总好过项目完成之后才发现一堆的问题,到那时候再要做修改,基本上都会牵一发而动全身,痛苦的还是程序员自己。
  • 保持真实性
    尽可能让你的系统运行在最接近真实环境配置下面,使用有实际意义的数据和真实的编译版本,并经常性进行模块整合。如果你的测试环境使用的数据都是些胡乱添加的东西,那么将来和测试数据大相径庭的真实数据这块大冰山早晚会撞沉你的程序。另一方面如果你只在开发环境来编译运行测试,会发现正式发布之后有各种各样莫名其妙的问题产生,到最后原来都是因为环境配置与开发环境有些不起眼的差异所导致。把所有模块整合进行编译联调,看上去应该是最后作的一项附加工作,但实际上这是一项需要在开发过程中经常性进行的工作。只有这样QA才能有最完整的东西拿来测试,得到更多的Bug反馈,同时降低模块整合的难度。
  • 理解你的代码
    书写规范的代码,并保持代码的整洁。Coding是一门艺术。正如写作一样,同样的文字在文豪的笔下就能够熠熠生辉,读起来赏心悦目;在普通人的笔下大概就只是词能达意的效果了;在某些人的笔下或许就需要研究半天才能猜出个大概来。当然不可能人人都成为艺术家,但至少你可以学会欣赏艺术、学习艺术。书写漂亮的代码是对自己工作的尊重,也是对其他程序员的尊重。如果你的代码中间充斥着大段过时的注释、可读性差的变量/函数,怎么去要求别人或者自己以后能够理解它们?
  • 最优编程
    把你的时间花在代码的功能上, 而不是去把现有的代码改得对自己胃口(尤其对于那些copy/paste过来的代码);要找到系统的瓶颈进行优化,而不是对那些无益于系统整体性能提高的地方做无用功。
  • 管理好你自己
    也许有人会说计划和进度控制是PM的事情,但一个好的程序员应该比PM更了解自己目前工作的进度。不论上头给的进度计划是否合理,你都应该有自己的原则和概念,清楚知道每天该做什么怎么去做。
  • 持续教育
    只有不断的学习、实践、犯错误,你才会真正有所提高。在我看来,对于程序员来说最好的老师不在学校,而在书本、网络、社区。学会自我学习才能保持与时俱进。
  • R-E-S-P-E-C-T
    互相尊重是一切的基础。
+ 0 - 0 | §住在我楼上的邻居

  不知哪天开始楼上变得好不热闹,要么就是脚步声来来往往,要么就是半夜行将入睡的时候“嗵”来一声巨响。

  实在被骚扰的受不了了,用对讲电话跟他们提意见,对方态度倒是不错,表示以后注意。可是状况依旧,再次投诉,他们干脆来了个死不认账,自称没做过什么大动作,甚至让我自己跑上去参观一下。

  这种时断时续萦绕在脑袋上方的声响你不去注意也便罢了,一旦卯上劲了就声声入耳,比夏天蚊子的营营还要难受。被逼急了,跑上去敲他们家门决心看个究竟。

  一对中年夫妇,一个十来岁的小孩,一位老人。外加一只小狗。看他们的样子倒也和善,脚上穿的也都是挺柔软的拖鞋,不像能发出大动静的装束。只是地上没铺木地板,而是用的地板砖。大概就是这没有夹层的地砖隔音效果太差的缘故吧。

  罢罢罢,总不能让他们撬了地板砖改铺木地板,只好认倒霉。

  今天这声音可又升级了,估计是小孩新买了辆电动汽车,在地上开来开去的折腾个没完。这骨碌骨碌的声音听着实在难受,便又拿起对讲电话拨他家号码。刚拨完号码,就听见骨碌声止,脚步声起 -- NND,还说不是你家发出的?

  电话接通,我没好气:“是602吧!”

  “不是。这里是601。” 一个小孩子的声音。

  ... ... 搞了半天,居然是楼上隔壁家在作恶!若不是拨错号码,还真想不通这斜对面的声音也能传过来。大楼的结构实在奇妙。

  “我是你们楼下的,是你在上面玩什么东西吧?骨碌骨碌的很吵。小朋友要玩到外面去好不好?”

  “哦。”

  这个世界清静了。

  然而清静不了几时,小孩子又开始玩耍了。又是无可奈何的事情。总不能跟小孩一般见识阿,谁小时候不顽皮呢。

  不管怎么样,这次总算找到根源了,不至于再错怪楼上那家子了。

  哪天等咱有钱了,买房一定要买20层以上的高层,还必须是顶层。铺上一地的大理石,爱跳绳就跳绳,爱溜旱冰就溜旱冰。

  高高在上的时候,有几个人会真正在乎下面人的感受?

+ 0 - 0 | §据说我开上了宝马
下午以前的同事来电询问:听说你买了宝马啦?这让我不由得胸中翻起千层万浪:这年头的资讯,甭管真假,全都以超光速在地球上面传播。不服不行啊!但我要澄清的是这个说法并不确切。其实事情的经过是这样嘀:  查看全文
标签 ( 懒人散记 ) :
+ 0 - 0 | §狗年将至,旺一旺
狗据说是人类最忠实的朋友,可在中文里面有关狗的却都不是什么好词。既然用语言来表达对即将到来的狗年的祝福颇有难度,不如用图片来说话。愿大家狗年大旺!  查看全文
标签 ( 数码影像 ) :
+ 0 - 1 | §Links 2006-01-18: 老罗来了
  • 骚得要死的使用说明 - 罗永浩
    老罗的博客,秉承老罗语录一贯风格。可惜不让写评论。
  • When Apache met DTrace
    Apache性能分析module mod_dtrace
  • RMI and Full GC
    为了保证RMI原始对象在不被引用后尽量即时的销毁Stub,因此只要有未被释放的RMI实例存在,系统就会周期性的进行Full GC。知道原理再改变就相对简单了。
  • 分布式应用日志的集中化存储
    通过UDP协议或者方式实现在小局域网内部的日志广播,然后在后面多台服务器上实现各种日志处理的并发计算。而日志的截断等操作,也可以在后台实现
  • PHP Crawler
    一个简单的网络爬虫脚本。你也可以用来完成其他页面抓取的工作。
  • PHP best practices
    This guide will give you solutions to common PHP design problems. It also provides a sketch of an application layout that I developed during the implementation of some projects.
  • Javascript Inheritance
+ 1 - 0 | §频繁的会议是一剂毒药

  不知道有多少的经理主管每天受困于大大小小的会议;反正我曾经有段时间对“开会”两个字过敏 -- 一听到就想吐。

  Marc Abrahams 摘述了 Alexandra Luong 和 Steven G Rogelberg 所做的关于会议对雇员的负面影响力的研究。他们认为:尽管会议有助于工作目标的更好完成,但每天过多的会议以及会议时间过长都会对个体造成消极的影响。

  从某种角度来说,会议的召开是对员工日常工作的干扰。尤其当你正有些棘手的问题刚刚理出点头绪的时候,一开完会就得重头思考。

  在我看来,最令我厌恶的会议譬如:

  • 召开时间一改再改的会议
    如果能够有准确的时间点提前通知,那样的会议至少可以让人有个心理准备。最怕的就是搞突然袭击或者隔两分钟变更一次召开时间的“游击会”。
  • 主题不明确的会议
    主题一旦不明确,必然导致结束时间遥遥无期。讨论的最终结果往往是“以后再说”。
  • 结束时间遥遥无期的会议
    经常发现群体会议变成其中几个人聊家常,其他无辜听众只能是哈欠连连。当然,剩下的那些人往往是无权宣布会议结束的“小角色”。当你作为会议上的老大天马行空纵论古今之时,最好想想自己的老板如果开这样的会议给你是什么感觉。
  • 参与人员必须用“堆”来形容的会议
    工厂车间的年度职工大会当然是必须用大礼堂来装下所有的与会者的;其他大多数情况下,真正需要列席会议的人不会超过个位数。人数一多,主题渐渐就不明确了,结束时间也就在群聊之中遥遥无期了。

  真正的垃圾会议你是忍受不了的,就因为言之无物、屁话连篇,就因为你不知道会议什么时候召开,什么时候结束,不知道你什么时候会再被叫去开下一个垃圾会议!

标签 ( 杂言乱语 ) :
+ 0 - 0 | §Links 2006-01-17: UTF-8 in Rails
  • UTF-8 Plugin for Rails, Fine for Ruby 1.8
    Rails如果不尽快在最新版本中加入对UTF-8的天然支持,将会成为不少开发人员使用它的心理障碍。
  • Web users judge sites in the blink of an eye
    Potential readers can make snap decisions in just 50 milliseconds.
  • 金刚:为何口碑好、票房差
    在我看来,对于美国本地观众来说,让这样一个野性十足的蛮荒巨兽登上帝国大厦似乎自从911之后就成了美国人的忌讳;对于中国的观众来说,没有全球同步上映未免使影片悬念大打折扣。上映档期又正好在圣诞几部国产影片抢钱完毕之后,恐怕大多数人都更愿意留着钱过春节了,呵呵。但相信这绝对是一只潜力股,最终的总票房加上DVD的销量不会差到哪去。
+ 0 - 0 | §项目开发的内部竞标机制

之前开发上碰到的问题:

需求过多,开发人员疲于应付
开发效率低
缺乏项目后期跟踪,很多项目做完之后变得无人问津

尝试过的解决方案:

项目外包 - 验收和后续维护上出现不少问题。进行需求的沟通也花费了大量的精力。
控制需求量 - 由于所有的商务内容提需求的时候都认为这个项目非常重要,往往造成需求控制失效。

一方面,开发人员抱怨需求像雪片一样飘过来,到最后却被证明做的不少项目都是无用功;
另一方面,市场、内容方面的策划人员抱怨提出来的需求没人来做,做出来的东西又质量不高。

现在想来,采用公司内部的项目竞标机制可以比较折衷的解决这些矛盾。

内部竞标机制:

需求方提供项目需求、开发周期与项目报酬等信息提出竞标;
开发人员自愿组合或者由高级分析设计人员点将组成项目小组来接受项目任务;

由于开发人员来自公司内部,对业务需求更加熟悉,同时限以公司统一的开发规范,有利于验收维护。
组队接受项目争取项目报酬的方式更能激发开发人员的创造力和主动性。

对于需求方来说,要考虑项目报酬成本,会更加谨慎的考虑需求的提出是否合理。

对于绩效考察来说,开发人员的能力贡献更加一目了然。

标签 ( 开发/理论 ) :
+ 0 - 0 | §Links 2006-01-16: 春运
+ 0 - 0 | §Links 2006-01-15: engineer
+ 0 - 0 | §《金刚》:讲述大猩猩自己的故事

金刚
  自听说彼得・杰克逊 (Peter Jackson)开拍《金刚》之日起,就对这部经典重拍充满期待;几天前看了高飞对于影片的评价,更加迫不及待的在周末去影院一睹为快。

  结果这位新西兰大胖子再一次让我对他崇拜得六体投地(下巴也掉地上合不拢了)。两亿美金打造出来的奇幻世界只能用叹为观止来形容,更可贵的是杰克逊能够让这些超炫的特效和剧情和谐的融合在一起,让你的注意力完全放在叙事过程中而不是去关心这些CG有多真多假。

  在《》里面杰克逊为了让巨大的猛犸象看上去更真实所花费的心思已经让我吃惊;这次的世外荒岛上竟然比比皆是这样的庞然大物。蛇颈龙群与弱小的人类一起大逃亡的混乱场景到底是如何逼真的呈现出来的,恐怕只有等着去看将来的DVD花絮了。

  说到这个场景就不得不把《》给拎出来当靶子了:张东健这帮奴隶在牛群中间奔跑的镜头与之相比,简直就像是手绘时代的二维动画片一样粗糙。三亿人民币的投资和两亿美元相比当然是差了一个数量级,但出来的效果相差得可比一个数量级要远的多。

恐龙
  资金的差距是一方面,导演的想象力和驾驭能力是另一方面。可笑的是这些国内的名导们还前仆后继地拿着这些不入流的CG特效加上粗制滥造的人物情节组装出来的四不象去向奥斯卡献媚,就像在兜售Made in China的廉价名牌一样。犯得着么?

  扯远了。

  特效是天衣无缝的;猩猩是充满感情的;人类是面目可憎的。

  对于这个《金刚》,无须太多的评价,去看就对了。友情提醒:三个小时的片长不是开玩笑的,看之前最好准备妥当。饮料不喝为好,否则像我那样散场之后赶着排队上厕所的滋味可不太好受。

  以杰克逊的认真劲,把足够多的素材剪辑进DVD版本中应该不成问题,等着收藏他的导演剪辑版。

  P.S. 买票时太心急没注意,影片开映了才发现居然买了国配版的票,略微郁闷了一番。听着这些洋面孔满口的国语还真有些别扭。还好影片的主角是只不说话的猩猩,大部分的对白都是人类的尖叫声和野兽的吼叫声,勉强也凑合了。

  周黎明:《金刚》不容错过的N个理由 :

 金钱可以等于技术,金钱却不等于想像,而即使没有CG动物的画面中,杰克逊天马行空的想象力依然使画面变幻无穷,扩充了戏剧张力,却没有抢戏。这堪称特效片的最高境界。
 你可以放心地说,杰克逊的电脑特技预算都花到了刀口上,物有所值。这同时也回击了"给我N亿钱我也能拍出某某影片"的无知论调。
 拍特效史诗片要花钱,但更需要才华。讲故事的才华不需要大钱,但并不是每个人都能把一个耳熟能详的老故事讲得绘声绘色。
+ 0 - 0 | §Links 2006-01-12: 新百家姓
  • 新“百家姓”出炉
    由中国科学院遗传与发育生物学研究所袁义达研究员主持完成,历时两年。调查涉及全国1110个县和市,得到了2.96亿人口的数据,共获得姓氏4100个。咱老家看来是日渐式微了。
  • 要它干嘛?
    古百家姓同时可以作为一种读物,像《三字经》、《千字文》一样读来朗朗上口,兼有识字之效,超越了姓氏排列本身;今百家姓倒是有科学的意味了,却不过是干瘪瘪的姓氏堆积。
  • 霍元甲 (EP)
    周杰伦为电影《霍元甲》创作的主题曲MP3电台首播完整版本
  • Wicket beats all other Java web frameworks
    作者不知怎么调查来的结果。最后分数 Wicket 249 打败 Struts 240
  • Web 2.01, a rich internet application example
    A fusion of "Web 2.0" style application content with a "Rich Internet Application" client, which is not subject to many of the limitations of a web browser.
标签 ( 网络网摘分享 ) :
+ 0 - 0 | §Links 2006-01-11: 无极vs福娃
标签 ( 网络网摘分享 ) :
+ 1 - 0 | §[转]prototype 源码解读
Prototype is a JavaScript framework that aims to ease development of dynamic web applications. Featuring a unique, easy-to-use toolkit for class-driven development and the nicest Ajax library around, Prototype is quickly becoming the codebase of choice for Web 2.0 developers everywhere.Ruby On Rails 中文社区的醒来贴了自己对于prototype的源码解读心得,颇有借鉴意义。  查看全文
标签 ( WebDev ) :
+ 0 - 0 | §Links 2006-01-10: 变态白领
+ 2 - 0 | §Links 2006-01-09: Zend & PHP
标签 ( PHP网摘分享 ) :
+ 0 - 0 | §Maxthon对IE的劫持
一向挺喜欢Maxthon,平时上网也基本上用的是它。但是对于一些特殊的页面访问(比如网上银行、MSN Spaces等)Maxthon似乎并不完美。所以我之前并没有把Maxthon设置为默认浏览器,只在需要的时候才去打开它。那些通过MSN Messenger/Windows Updater等应用程序产生的DDE调用还是让它用IE来打开。一直以来IE和Maxthon分工合作,也算相安无事。但前几天一个朋友问我说她自从装了Maxthon之后在QQ之类的程序里面点击url链接就没反应了,让我帮忙看看原因。因为那时候我的IE没这个问题,也没在意,就让她使用Maxthon的恢复IE默认设置或者重装Maxthon什么的去试试看,同时自己操作了一下。结果昨天想运行WindowsUpdate的时候发现了同样的问题:点击了之后没有任何反应...  查看全文
标签 ( 网络 ) :
+ 1 - 0 | §Rails Mind Map

MunckfishFreemind画了围绕Rails展开的Mind Map,清晰明了,赞一个。

标签 ( RubyOnRails ) :
Since 2005.04.27  梦想 就像鸡蛋 要么孵化 要么臭掉RSS Feed (Entries) | About me | Back To Home | @ZEAL | zbird.com | 沪ICP备05024379号