http://www.imallen.com/blog Angel of Mercy, How did you find me? Tue, 04 Nov 2008 06:12:34 +0000 http://backend.userland.com/rss092 en 8G MARK2 的短棒现在忒便宜，于是入了一个，顺带的买了个超薄铝盒装饰一下我的小 P，原本想买艾儿宝的，可是我买短棒的那家没有，就买了个便宜的山寨版，虽然质量一般，但还能入眼，勉强接受。深红的，比较艳。 下面是王道。 以前的白色小 P，怎么看怎么好看，还是很喜欢滴 4G 红棒和 8G MARK2 合影，交接班嘛，纪念一下，同是组棒 MARK2 没红棒做工细致。 半兽人状态 完工，正面一般，十字键开孔还比较准确，△○×□ 的开孔稍有偏差，不过不影响操作。另外艾尔宝的超薄铝盒开孔处和斜坡处都有打磨，但这山寨的没有。前盖有很薄的软垫，所以装的比较安心，后盖没有，装的时候听见了细微的摩擦声，心里怨念无数，装完残念继续。DJ Max Clazziquai 还算流畅，自制软件也没啥问题。 再来张背面，绝对的背影杀手 8G MARK2 实测 by BlackSpeed v2，读速比意料中的要快许多，不知道寿命如何，拼 RP 了。说是一年店保，如果能用一年那就足够了，一年 140 而已，一年后也该是 16G 主流了。 http://www.imallen.com/blog/diary/2008/11/change-skin-for-ps/ iTunes 和 iPhoto 里的专辑封面在鼠标移过时的变化感觉挺好玩的，就用 JS 实现了一下~ 试一下鼠标移过封面时的效果~ 用 [tag]Javascript[/tag] 其实很方便，只要在 mouseover 的时候判断一下鼠标位置然后根据所在位置显示相应专辑封面就可以了。我用的 JS Framework 是 Prototype，挺好用的，用习惯了。 var myalbum = new Aflow; myalbum.add("http://www.imallen.com/works/aflow/img/1.jpg", "#", "Text"); myalbum.add("http://www.imallen.com/works/aflow/img/2.jpg", "#", "Text"); myalbum.add("http://www.imallen.com/works/aflow/img/3.jpg", "#", "Text"); myalbum.add("http://www.imallen.com/works/aflow/img/4.jpg", "#", "Text"); ... http://www.imallen.com/blog/design/2008/09/js-effect-code-prototype-itnes-iphoto-cover/ 使用软件：FontRouter LT 使用字体：方正兰亭细黑 使用主题：S60 Prototype 使用输入法：搜狗 for S60 内测版 电子书软件：掌上书院 恩，有了抗锯齿 N73 好看了很多。换了字体似乎会多占一些系统资源，不管了，脸蛋漂亮更重要~另外实际使用效果要比截图好看很多，截图凑活看吧。具体下载地址和使用方法自己 Google 之，有必要的话我再整理贴上来吧。 下面是截图： http://www.imallen.com/blog/diary/2008/09/n73-font-switch-fangzheng-lanting/ 优酷要火！ [youku XNDQwNTg3ODA=] http://www.imallen.com/blog/reference/2008/09/jay-mojiezuo-daoxiang-mv/ 每年都会等待 [tag]Jay[/tag] 出新专辑，习惯了这样的等待也就无所谓焦急，只知道每一年都在等待，等待那一点感动。 毫无疑问，[tag]Jay[/tag] 的歌总是让人欣慰，即使那周式小调不曾改变，那一份触动也未曾消失。 喜欢那字里行间透露的那一丝童年时的悸动，喜欢抛开情情爱爱的明快的歌词，喜欢童谣一般朗朗上口的旋律。Jay 的歌更像是一篇流露着真情实感的日记，记录着他的生活。 当一个一人红到发紫的时候却还能保持着那一份童真和惬意，那才是真正值得去喜欢一辈子的。总觉得作为一个男性，说会喜欢另一个男性一辈子是一件颇有歧义且会为自己的性取向带来问题的事，但是我还是要说只要 Jay 还是 Jay，词间流露的还是那份纯真的感动，我就会喜欢他一辈子~（麻了） 恩，等新专辑《[tag]摩羯座[/tag]》出了一定买正版支持。 PS：我也是摩羯座的，咋就没这才呢。 附电台版[tag]稻香[/tag][tag]下载[/tag]地址： 点此下载稻香（电台版） 歌词请点开看全文 LRC 歌词 [00:02.05]周杰伦 - 稻香 [00:15.38]词/曲:周杰伦 [00:30.50]专辑:魔杰座 [00:31.42] [00:31.52]对这个世界如果你有太多的抱怨 [00:34.86]跌倒了 就不敢继续往前走 [00:37.78]为什麼 人要这麼的脆弱 堕落 [00:42.21]请你打开电视看看 多少人 [00:44.69]为生命在努力勇敢的走下去 [00:47.68]我们是不是该知足 [00:50.14]珍惜一切 就算没有拥有 [00:53.05] [00:54.57]还记得你说家是唯一的城堡 [00:58.22]随著稻香河流继续奔跑 [01:01.16]微微笑 小时候的梦我知道 [01:06.25]不要哭让萤火虫带著你逃跑 [01:09.96]乡间的歌谣永远的依靠 [01:12.88]回家吧 回到最初的美好 [01:18.23] [01:41.73]不要这麼容易就想放弃 就像我说的 [01:45.12]追不到的梦想 换个梦不就得了 [01:48.36]为自己的人生鲜艳上色 [01:50.65]先把爱涂上喜欢的颜色 [01:52.96] [01:53.56]笑一个吧 功成名就不是目的 [01:56.38]让自己快乐快乐这才叫做意义 [01:59.21]童年的纸飞机 现在终於飞回我手里 [02:04.15] [02:04.94]所谓的那快乐 赤脚在田里追蜻蜓追到累了 [02:09.21]偷摘水果被蜜蜂给叮到怕了 [02:12.34]谁在偷笑呢 [02:13.84]我靠著稻草人吹著风唱著歌睡著了 [02:17.24]哦 哦 午后吉它在虫鸣中更清脆 [02:20.18]哦 哦 阳光洒在路上就不怕心碎 [02:23.79]珍惜一切 就算没有拥有 [02:27.48] [02:28.48]还记得你说家是唯一的城堡 [02:31.90]随著稻香河流继续奔跑 [02:34.85]微微笑 小时候的梦我知道 [02:39.94]不要哭让萤火虫带著你逃跑 [02:43.65]乡间的歌谣永远的依靠 [02:46.54]回家吧 回到最初的美好 [02:51.17] [02:52.08]还记得你说家是唯一的城堡 [02:55.32]随著稻香河流继续奔跑 [02:58.28]微微笑 小时候的梦我知道 [03:03.38]不要哭让萤火虫带著你逃跑 [03:07.04]乡间的歌谣永远的依靠 [03:09.97]回家吧 回到最初的美好 [03:15.72] [03:18.80]THE END http://www.imallen.com/blog/diary/2008/09/something-about-jays-new-song/ 不知道是不是还会有变数，但愿是杞人忧天~ Christ bless me~ 恩，如果保研了就用一年的时间做自己喜欢的事吧~ http://www.imallen.com/blog/diary/2008/09/postgraduate-recommendation/ 深夜，把 WP 更新到了 2.6.2，把我的水源 Toolbar 也改得更强大了，关于更新，请往下拉到更新记录。 点此下载水源工具栏 v0.2beta 因为还没有通过审核，所以如果不能直接安装，只能通过下载后，把 XPI 文件拖到 Firefox 的方法来安装。在 Mozzila 有注册的同学帮忙在官网 Review 一下，早日通过审核方便安装。 下面是官网地址： https://addons.mozilla.org/en-US/firefox/addon/8824 很早就想开发这个[tag]水源[/tag] [tag]Toolbar[/tag] 了，不过不懂 [tag]Firefox[/tag] [tag]Extension[/tag] 的开发方法，拖延了很久。前几天装了个 Facebook 的 Toolbar，心血来潮看了几篇教程，研究了一下 Facebook Toolbar 和 Google Toolbar 的代码，发现做个简单的 Firefox 扩展不是很麻烦，于是边看边学边写，两天后有了个雏形。先放个 beta 版找人一起测试，也算集思广益，后文会写到大概的发展方向。 本 Toolbar 适合且会越来越适合喜欢 Web 浏览的同学，喜欢 Telnet 的同学不要拍砖哦。 开发环境是 XP(en) + FF 3.0.1(en)，不知道其他操作系统或者其他版本的 FF 兼容性如何，待测试。 已测试通过：XP(SP3en) + FF 3.0.1(en)，MAC OS X(10.5.4) ... http://www.imallen.com/blog/diary/2008/09/shuiyuan-toolbar-for-firefox/ N+, 一款从 Flash 游戏移植到 PSP/DS/XBOX 的游戏, 很好玩~ 介绍就不贴了, 到处都是, 可以归为逃脱类的游戏, 吃黄钻可以加时间, 在时间耗尽前吃到绿钻石再从大门逃脱就可以了. 玩下来感觉一般时间不会太紧张. 最早玩 Flash 版的时候只觉得挺有趣, 玩了一段时间就放下了. 最近玩了 PSP 版的那叫一个畅快, 几天时间就通关了. 感觉很爽就是了. 游戏中其他的隐藏关和隐藏颜色都在游戏进行到一定程度的时候会自动打开, 只有 ATARI BONUS 这个隐藏关需要通过作弊码打开. 先进入 UNLOCKABLES 界面, 按住 L 和 R, 再依次按下 X, O, X, O, X, X, O, 哇咔咔, 隐藏关打开了, 进入单人游戏, 在选关的地方往上多出来一些心的关卡, 不过似乎没什么挑战性. 不知道是不是还有什么隐藏元素, 有新发现的记得留言告诉我. Cheat Codes to Unlock Atari ... http://www.imallen.com/blog/diary/2008/09/n-plus-cleared-cheat-codes/ 软件开发的残酷的现实告诉我们：没有规则的软件开发过程带来的只可能是无法预料的结果。我们中的大多数项目管理人员在其个人简历中纷纷写到：“拥有多年的丰富的项目管理经验”，但在实际开发中，“丰富的”管理经验变成了软件开发人员可怕的梦魇。一次次的失败、一次次的返工，她所谓的项目管理经验只不过是再一次的游戏于“无间”（十八层地狱）。一次，在与不少项目管理者的交流中，大家纷纷提到的软件变更带来的可怕影响。但是正如完整的法律体制不能制止犯罪，但没有完整的法律体制犯罪会更加猖獗一样，频繁的软件变更固然可怕，但是没有一个完整的项目管理对应机制，我们无法相像项目最终会是一个什么样子。此外还有一次，笔者在求职时，招聘公司的技术主管（40-50岁左右），向我吹嘘公司按CMM4的过程规则来进行软件的开发和管理。殊不知，我一问下面开发人员，她们在经历无数的加班后正在给已经完成的软件项目添加软件概要设计书，这让我大吃一惊。如此这样形式主义的公司，不呆也罢。 记得一个格言曾经说过“人类最愚蠢的行为在于忘记常识”。另外一句较为相仿的格言则是“不知道历史的人必然会重蹈覆辙”。作为项目管理来说亦为同样的道理。很可惜，我们中的大多数管理者口口声声“软件工程”，工作时“用程序代替用户需求”，极具政客的嘴脸。其结果必然如目前媒体“程序员生存状况”所言，以开发人员在时间的牺牲为代价来换取项目的结束，这是再为普遍不过的现象，在此不再妄加评论。 如何改善我们的软件开发管理，一条便捷之道便是“尊重常识，尊重历史经验教训”。在软件项目管理中，有许多的原则和经验可以供我们借鉴。 一、 计划原则 没有计划，你无从知道什么时候控制和变更。制定一个详尽的计划，以详细到开发人员可以理解的程度为宜。计划能够告诉你什么时候应该做什么。没有计划，你无从知道自己需要做什么。不少项目经理告诉组员需要做什么东西后扬长而去，丝毫没有一个相关任务（活动）之间的说明。由于没有计划或是计划太粗糙、不切实际，很多项目1/3甚至1/2的时间花在返工上面。因为计划中遗漏了某一项关键任务，项目就有可能宣告失败。试想一下，制定一个周密合理的计划需要耗费这么多的时间吗？需要付出项目失败的代价吗？还有很多项目管理人员常常错误认为“变化比计划快”，但实际的情况是，由于没有计划，你无法预测和估量变化给你的项目所带来影响，你所面临的将会是比面条还难以理清的“混沌”状态。此外，对于开发人员来说，“目标导向（Objective Oriented）”是充分调动其工作积极性的最佳方法，每一个任务阶段的成果能够将员工的工作效率维持在一个较高的水平。因为近期目标总是比远期目标来说更容易看到和达到。为此，制定一个计划吧，让它符合目标导向（通过各个具体任务计划促使项目总计划的达成）。 二、 Brooks原则 向一个已经滞后的项目添加人员，可能会使项目更加滞后。因为作为新加入的员工来说，相关培训、环境熟悉和人员之间的沟通通路的增加，迫使项目的工作效率急剧下跌。工作效率下降需要加班来进行弥补，但加班造成的疲劳会再次使工作效率降低。同时工作成本却不断的向上攀升。不过就目前来说，项目管理人员丝毫不会理会这一点，“人多力量大”也许更能引人入胜。不少项目管理人员抱怨到时间的急迫性，须知很多项目内时间的急迫性来自于项目管理人员不假思索和不基于常理的邀功表现，没有充分考虑的开发人员能力的多样性 所致。为此，正规的企业不得不耗费大量的加班费用于加班人员的津贴，同时亦要承担违反《劳动法》的潜在法律危险。现在一种万不得已的做法是，假设项目开发人员之间的任务的关联性不是太大的情况下，采取两班倒或是三班倒的方法来保证时间的延续性和相关开发人员的工作高效性。 三、 验收标准原则 我们在进行某项任务，往往会为以何种结果为宜而感到困惑。不求质量的开发人员往往凭据经验草草了事，追求完美的开发人员则在该项任务上耗费太多的精力，但此番耗费未必针对该项任务，因而常常吃力不讨好。这是由于没有验收标准而导致的情景。因为没有验收标准，你无法知道你要进行的任务需要一个什么样的结果，需要达到什么样的质量标准。在很多情况下，你的活动会与期望结果背道而驰，而此时的你还在沉醉于自己的辛勤耕耘之中。作为项目经理来说，只有制定好每个任务的验收标准，才能够严格把好每一个质量关、同时了解项目的进度情况。 四、 默认无效原则 你的项目成员理解和赞成项目的范围、目标和你所制定的项目策略吗？不少项目管理人员认为“沉默意味着同意”。实际上我们或多或少都会陷入这样的一个思维误区。试想一下，你作为职员或项目开发人员时的沉默完全代表你赞成你的领导的意见吗？不见得，这就是答案。这一点在项目沟通中极为重要，项目管理者切不可为沉默认为是同意，沉默在很大的程度上说明项目开发人员还尚未弄清楚项目的范围、任务和目标。为此项目管理者还需要同开发人员进行充分沟通，了解开发人员的想法。在对项目没有一个共同的一致的理解的前提下，一个团队是不可能成功的。 五、 80-20原则 80-20原则在软件开发和项目管理方面有许多“实例”。其一便是我们在20％的项目要求上耗费了80％的时间。仔细分析一下，这些项目要求分为必须的非必须的，因此我们建议是压缩非必须的部分或是暂时将其放在一边不必太重视。软件项目开发事实告诉我们，开发人员在非必须的项目要求上耗费了太多的精力，用户的需求变更的大部分出现在“最好有”这一部分，实际上用户并不看重这些需求（即使去除这些需求），而我们所做的，往往是舍本求末。 80-20原则的另外一个实例是我们项目中的20％的人员担当了80％的项目任务（这样讲在实际实施中一点都不过分）。考虑到开发人员能力的多样性，聪明的项目管理人员决不会采取任务均分的愚蠢做法，因为就系统论的观点来看，互补结构比对等结构要更稳定一些。此外作为项目管理人员来说，了解属下员工的能力特点，将其放在合适的位置上，会更有利于项目的顺利进行。很多管理人员常常抱怨属下能力问题，究其实质，往往是这些项目管理人员未能发现开发人员潜能所在之处。她们看待问题往往以“经验”这样的思维定势来做决定。导致的结果如系统论所言：由于“抱怨”的作用和反作用循环，结果是大家都不欢而散。 六、 帕金森原则 帕金森原则原是用于反映政府部门机构臃肿，效率低下的代名词。不过它在软件开发中一样适用。没有时限限制的话，工作可能无限延期。在软件开发中，如果没有严格的时间限制，开发人员往往比较懈怠。这是人的天性所决定的。千万不要指望奇迹的发生――“所有员工的思想觉悟异常崇高”。作为项目管理者而言，此时应充分考虑到员工的工作效率和项目变更带来的负面影响，制定合理的项目工期并鼓动开发人员尽快完成。 七、时间分配原则 在项目计划编制过程中，我们常常将资源可用率（人、设备）等设置为100％，殊不知你曾想过，由于开发人员需要休息、吃饭、开会等，根本不可能把所有的时间放在项目开发工作上，而且这还不考虑到开发人员的工作效率是否保持在一恒定水平上。所谓一天8小时工时制实际上是徒有虚名。由于项目管理人员的“ 无知”，不少开发人员被迫拼命加班。结果依旧出现Brooks原则所出现问题。在实际开发中，开发员工的时间利用率能够达到80％就已经时很不错的了，我个人比较倾向于60％左右（黄金分割点）。一个常用的经验是如果项目人员不懂技术的话，项目时间可能是原计划（该计划没有考虑到资源可用率）的4/3－5 /3。如果项目人员不懂技术、管理人员不懂管理的话，这个数字可能是2倍到3倍。现实就是这么严酷。这很大范围内“归功于项目管理人员。是的，我们的确没有必要责备开发人员，因为我们对资源可用率的判断完全违反常识。 八、变化原则 也许有人问过你，在项目管理中唯一不变的东西是什么？我可以告诉你，项目中唯一不变的就是“变化”。在项目中不考虑可能发生的变化是不可思议的。不过在面对项目可能发生变化而带来的项目风险时，我们的项目管理人员往往会怀有逃避的态度。经济学里大名鼎鼎的风险规避原则便是项目管理人员心理的有效描述。作为项目管理人员来说，应该及早预测可能出现的风险，做好风险储备。虽然风险储备不能解决所有的问题，但是“预防胜于治疗”。可惜的是我们绝大多数人没有这方面的意识，否则医院的生意未必如此红火，项目开发之途未必如此坎坷。 九、作业标准原则 一个团队要完成项目的开发需要有一定的章法。很可惜，在国内目前仍然以“作坊式”为主，高举“我们符合国际CMM X规范（ISO某某规范）”的环境下，未必有多少项目团队注意到这一点。我们曾经惊叹印度的高中生都能编程序，而国内却非本科、硕士不收眼帘。究其原因，在于没有开发章法或是章法粗糙，犹如牛皮圣旨一般。一个好的代码模板和代码规范能够解决大多数人编写程序随心所欲的问题，很可惜，没有多少项目管理人员有此意识，也没有多少人愿意去做这项基础任务。业务软件开发需要高超的开发技巧吗？不需要，那是故弄玄虚的开发人员的伎俩。软件开发的美在于其简洁性和规范性，不在于奇技淫巧。因为缺乏作业标准，我们付出的代价是客户的抱怨和无休止的返工。此外，对于那些以形式主意蒙人的项目团队来说，如果你实质如同你口头所说那样，也许你就不会是今天的这副狼狈相。 十、 复用和组织变革原则－解决项目问题的未来之路 如何解决日益突出的项目工期、成本、质量等问题，这是大多数项目管理者最为关心的问题。从实践来看加强复用的力度，建立项目复用体系和实施组织变革是效果较好的途径之一。复用能够提高项目的生产率，降低项目风险。通过复用，项目管理者能够快速的进入项目问题定义之中，减少项目开发人员的工作量，从而尽可能的解决项目在时间、资源方面的过载问题。另外一条途径是实施项目团队的组织变革（Moc），精简项目管理机构、重新定义工作职责，制定柔性的项目工作流程，改善项目开发人员的沟通状况，提高项目人员的开发效率，努力营造一个良好的项目开发环境。这样才能从根本上解决项目开发的种种棘手问题。 结论：作为一个项目管理者来说，了解和运用上述原则是不够的，若要深入的掌握项目管理知识和技巧，还必须深入学习项目管理（建议参看PMI 《PMBOK》）、管理心理学、质量管理学、组织变革、系统论等方面的知识，并在工作中不断的总结和实践。唯有如此，我们的项目管理人员看自己个人简历时方不会觉得脸红，才能在公司中树立自己的管理权威性，同样也才会有一个良好的职业经理生涯的开端。 作者介绍 张华，国家系统分析员，CSAI高级顾问。先后从事过企业信息管理，项目管理和应用系统分析与设计等工作，能熟练运用多门外语，并在自动化软件生成颇有建树。　　个人熟谙PMI项目管理体系、富士通SDEM方法、IT审计和软件企业信息事业推进，熟悉多种建模方法、设计工具，具有丰富的多种业务领域建模经验。个人目前热切关注的对象有：软件哲学、软件思维工程和知识管理。 http://www.imallen.com/blog/reference/2008/08/software-project-managemen/ 最近做多了 UI 和 UE 方面的活, 觉得 UE 是一项很有意思又极富挑战的工作, 找资料的过程中搜到这么一份质量很高的 Presentation, 作者是 [tag]Alan Cooper[/tag], 用户体验大师, 似乎也是 VB 之父吧. Presentation 的地址: http://www.cooper.com/journal/agile2008/ 留个档, 方便以后查阅, 也算拿出来分享. http://www.imallen.com/blog/design/2008/08/presentation-about-ue-by-alen-cooper/