梦想风暴

来源: BlogBus 原始链接: http://dreamhead.blogbus.com:80/index.html 存档链接: https://web.archive.org/web/20060112013436id_/http://dreamhead.blogbus.com:80/index.html

梦想风暴 一个小程序员的信口开河 首页 分页: 2006-01-08 21:20 张驰有道 代码写得快也未见得是什么好事。周五下班前，我完成该写的代码，为即将到来的周末做好了充分的心理准备，这时，领导找到我。 “你那部分写得怎么样了？” “完事了。” “XX的部分没人写，你就把它写了吧！” 就这样，所有美好的周末幻想全部成为了泡影，可怜我的周末在公司编码中度过，。 我不喜欢加班，去年那一段让我心情沮丧的加班之后，尤其如此。何况，只见加班，不见加班费。在从前的部门中，私下里有一种说法，“能者多劳，累死拉倒”。领导会根据你的能力给你安排工作，也就是说，表现得越好，越有机会承担更多的职责，这会直接导致能力的不断提升，不过，薪水的成长却是“老牛拉破车”，一步一个深深的脚印，扎实得很，不匹配的结果就是公司成为了著名的人才摇篮。 熬过去年那段痛苦之后，这次还是我几个月来第一次周末在公司加班。干我们这行而没加过班的大概是稀有动物。其实，加班并不可怕，为了项目能够正常进行偶尔加一次也没什么大不了，可怕的是加班成为一种常态。 大多数时间里，我的工作对我而言并不是压力非常大，因此，我总有些闲心去偷懒。我也经常为自己的这种状态不安。与老妈谈起这个话题，老妈告诉我，当自己的绝大多数工作让自己用尽全力，恐怕自己的能量也就到头了。老妈的话让我释然，偷懒是一种释放压力的方法。虽说有人琢磨出“软件蓝领”的说法，但我们毕竟需要用脑子完成工作。在经常处于高压之下，脑子容易僵硬，比如，我这两天写的代码整体质量要比我之前写的那些差了许多，质量往往与压力成反比。 看过一些报道，虽然程序员每天上班八小时，但不可能真正的工作八小时，Joel的《 Fire And Motion 》（中文版《 行进中开火 》）很好的描绘了这种状态。Google懂得这一点，干脆给了员工20%的偷懒时间，于是，一批为人称道的产品出现在我们面前。 一张一弛，文武之道。 dreamhead @ 21:20 | 阅读全文 | 评论(2) | 引用Trackback(1) | 编辑 2005-12-30 22:29 IoC与DI 一个朋友发了封mail问了几个问题，其中的一个是关于IoC和DI的： Inversion of Control和Dependency Injection 是什么关系，我认为两个词代表的是同一个意思，只是两种不同的表示，对吗？ 下面是我对这个问题的一些理解。 准确的说，IoC和DI并不相同，这一点从字面上就可以看出，否则，它们可以叫一个名字。^_^ 理解IoC，我们需要知道Control是什么，它又是怎样被Inversion的。其实，IoC是用来说明“程序库”和“框架”区别的最好证据。在使用程序库的时候，控制权是掌握在我们手中的，我们编写的代码调用程序库的实现，完成相应的功能，想想我们使用JDK的情况。使用框架的时候，控制权则掌握在框架手中，我们的代码最终是由框架调用，一个常见的例子是Servlet，我们编写的Servlet代码是放在整个Servlet的框架中，由Web容器进行调用。这就是差异所在。我们更习惯于自己掌控一切，因此，对框架掌握控制权的这种情况，我们用“Inversion”来形容，这也是 Martin Fowler 在那篇 给DI正名的文章 中提到，所有框架都是IoC的原因。 Spring的核心容器是一个框架，所以，我们可以说它是IoC，但是就如前面所说，每个框架都有IoC，所以，仅仅用IoC是不足以说明一切的。Spring核心容器完成的是组件组装的过程，这是它和其它普通框架区别最为显著的地方。如果说用IoC描述这个框架，那么，这里所指的Control实际上是组件的组装过程。 站在Spring核心容器的层面上看，它完成组装过程是把组件所依赖的零部件给组件安装上去。站在单个组件层面上看，它所需要的零部件是由外部给它安装的，这个过程就像是把“Dependency”这管药水用注射器“Injection”到组件的身体中去，所以，我们称之为“Dependency Injection”。 完成组件组装的容器也不只是注入一种形式，还有一种常见的方式是“Dependency Lookup”，即每个组件自己去查找自己所需要的内容。至于到哪去找，也有不同的实现方式，有固定到某个地方（比如使用静态方法），有把查找点通过DI的方式注入进来等等。 Martin Fowler的文章已经很清楚的解释了IoC和DI这两个概念，我们只需要去细细品味。 dreamhead @ 22:29 | 阅读全文 | 评论(1) | 引用Trackback(0) | 编辑 2005-12-25 22:56 圣诞随想 又是一年的圣诞节，没有什么能够挡住时间不断前进的步伐。 今年似乎是流年不利，赶上了很多不尽如人意的事，有相当长的一段时间，整个人的情绪极其低落。我是一个乐天派，遇到事情，总愿意向好的方向想，有些人对我说，快乐是可以感染人的，看到我成天笑呵呵的样子，他们也感觉心情不错。不过，就是因为这样，我对于困难的估计总是不足，所以，每当与意外不期而遇，我总会有些手足无措。我不愿意相信以诚相待换来的只是表面的笑脸。好在那段不顺心的日子都过去，这一年让我成熟了很多，最近和一些朋友聊天的时候，他们认为我考虑问题不再像那样简单，不过遇到事，我还是愿意更多的向好的方向想，我相信，这个世界还是好人多一些。 换部门让我遇到了一个很特别的领导，之所以这么说，因为他在我心目中不仅仅是个领导，更像一个老师，事实上，他原本也是一个老师。他是公司的元老，在公司内的级别相当高，也是经得多见得广。在或公或私的场合交流，我经常能从他的言谈中感受到他对许多问题深入的思考，这是我工作这几年从未感受过的。一个好的老师，传授的绝不仅仅是知识。我从他的身上除了学会了一些做事方法，更学会一些思考的方式。这使得他成为了我心目中最为尊敬的领导。 离开了学习了两年多的Java，最初我以为舍弃了很多，经过一个完全不同的项目，我发现原来自己放弃的只是一些形式上的东西，自己对于程序设计的理解还陪伴于自己身边。或许，我不能像从前那样熟练的使用一些API，但却从差异的之中找到了很多的共性，让自己的知识有了更大的适应面。抽象的好处在于简化，但劣势却让人容易脱离实际，为了让自己能够脚踏实地，我开始学习一些基础知识，比如OS，在这个过程中，我也发现了许多与原有知识有共性的东西，不断补充到自己的知识体系中，让自己在未来的路上，可以走得更踏实一些。如果不是学习了这些基础知识，恐怕我今年在技术上的进步都可以忽略不计了。 这一年中，最大的收获莫过于懂得了“Follow My Heart”的道理，而这就是我明年的努力方向。 dreamhead @ 22:56 | 阅读全文 | 评论(3) | 引用Trackback(0) | 编辑 2005-12-22 22:22 招聘广告 岁末年初，正是人心思动的时候，于是，招聘工作如火如荼。 前两天，一个朋友给我看了一份他起草的招聘广告。说实话，我这人最看不得招聘广告，因为我觉得那些广告是对我自信的严重摧残，之所以这么说，是因为那些广告上要得分明都是些高手高手高高手，基本上属于上知天文下晓地理中通人和，上得厅堂，下得厨房。单就满山遍野的“精通”、“熟练”就足以让我心里没底了，按说我学习编程也有些年头了，掰掰手指头，还真不敢说自己精通什么，而且随着自己了解东西的增多，越发不敢说精通了，因为觉得自己太不懂的东西也越来越多。 曾经，我对招聘广告中的年头要求颇有微词，因为在我看来，很多工作了很长时间的人并不一定比年头短的人优秀。后来，我逐渐认识到年头在个人发展过程中还是起到了相当的作用，想想现在的自己，比起刚工作那会，许多方面都得到了提高，有些东西确实需要经过长时间的浸泡才能认识得比较清楚，技术是一种。《 Teach Yourself Programming in Ten Years 》（中文版《 10年编程无师自通 》）说明了一些道理。以个体论，年头长的不确实不一定优于年头短的，但从整体上来说，这却是一定的，这就是统计的威力吧！ 以前，我总是一厢情愿的认为，在应聘过程中，个人往往会夸大自己的能力，比如装个Linux就说自己精通Linux，写过“Hello,World”就说精通某某语言，CSDN上的两篇关于招聘广告的新闻让我知道了这不是单方面的问题。 解读招聘广告的4大最常见误区(上) 解读招聘广告的4大最常见误区(下) 我不好说是因为用人单位习惯了应聘者的夸夸其谈而在广告“提高”要求，以便让双方都志得意满，还是那些“聪明”的应聘者看穿了用人单位的把戏，提升了自己简历的优美程度，抑或是那些词汇早就不是我所理解的含义，只剩下像我这样的愚者庸人自扰。 最近还看到了一篇让人心情愉悦的招聘广告，是曹晓刚在JavaParty邮件列表中发的一篇。在这篇广告的最后，提到了数学建模竞赛和挑战杯，这是我没有在其它广告中见到的，让我颇感新鲜。再有，大三那年，撞上了大运，我先后在这两个竞赛中拿奖，这篇广告勾起了我无限的回忆。 dreamhead @ 22:22 | 阅读全文 | 评论(0) | 引用Trackback(0) | 编辑 2005-12-20 17:43 管窥OS——进程透明化 在软件设计中，一个基本原则就是“高内聚，低耦合”。作为一类历史悠久的经典软件，OS历经多年的发展，在设计上已经达到了相当的高度。随便翻开一本操作系统的教材，那些经典词汇便不断的在我们面前闪烁：进程、内存管理、文件系统、输入输出等等，而它们正对应中设计中的一个个模块。记得初学OS的时候，我怎么也想不明白这些东西究竟有什么联系，这一方面体现出我对这些内容不甚了解，另一方面也充分体现出了设计的精彩，模块之间耦合极低。只可惜，我的老师从来没有站在设计的角度，为我们讲解OS。我们不妨从OS这个大拼盘中取出一块，管窥其中精彩，讨论的目标就锁定于IA32架构。 在现代OS中，在用户的角度来说，计算机同时干好几件事似乎是已经成了一件理所当然的事情，而这一切源于多进程技术的存在，正是多进程技术善意的欺骗，让感观上的“同时执行”成为了可能。其实，上当受骗的不只是用户，每个进程也是受害者，他们认为单纯的认为自己独霸着CPU，殊不知，这一切都是多进程技术为它们营造的虚拟空间。顺便说一下，虚拟这个词可谓应用广泛：网络为用户营造了虚拟世界，虚拟机让跨平台切实走入程序员们日常生活…… CPU很单纯，它所做就是“取指、执行”这样简单的重复性工作。既然各位都是好人，那唱白脸的活只能交给中间人——OS来做了。那我们就来看看OS究竟做了怎样的手脚，营造出这样一份欣欣向荣的景象。 老实的CPU只懂得按照一个预先设定运作模式运行，比如认定CS:EIP所放的就是自己要执行指令，比如认定ESP就是自己的堆栈。这就给了OS可乘之机，只要能够入乡随俗，就可以对欺骗CPU，比如改变CS:EIP就可以改变CPU所要执行的指令。偶尔，CPU自欺欺人，比如中断发生时，它在堆栈中保存了CS:EIP，执行中断处理程序，之后，再从堆栈中恢复过来，继续未尽的事业。正是有了这样的机会，进程调度才可能起作用。 谈到这里，我想就中断再说上一些。在我看来，中断是OS的动力源。前面的讨论中，我们也知道了，CPU太过老实，只知道一条道跑到黑，正是中断的存在才让这个世界变得丰富多彩。其实，如果把中断这个名字换成事件，对程序员来说，或许会更熟悉一些，就是兵来将挡的道理。我们已经面对过太多的事件处理机制，GUI有之，Web页面有之，即便是服务端应用本质上也是一种事件处理。其实，软硬件本身就有许多相同的地方，差别只在谁来做而已，中断这档事交给了硬件。分清责任在设计中非常重要，在OS这个层面上，我们应该弄清楚，哪些东西硬件能做，而哪些需要OS亲历亲为。 在执行过一条指令之后，CPU会去看看是否有中断发生，如果有，就是中断处理程序表演的时间了。很多情况下都会产生中断，而这里我们关注的是定时器，因为通常进程调度就是在这个时候起作用的。因为CPU是在堆栈中保存的CS:EIP，所以，只要改变ESP，傻乎乎的CPU在恢复的时候，取到的就是另外的CS:EIP，而它对此一无所知，殊不知，此时早已物是人非了。人们常说的进程切换做的就是这样的事情。于是，OS得以成功的欺骗了CPU。 骗了CPU，OS还要摆平另外一边——进程。进程是一个运行起来的程序，程序是什么。大多数情况下，我们都在用各种高级语言写程序，经过编译器的处理之后，它们就变成了一条条的指令。最终完成任务就是靠CPU把这些指令一一执行。OS欺骗进程的手法就是保证这些指令的正常执行。说起来很简单，但别忘了，世界上还有进程切换这么一回事。如果进程被拦腰斩断，当它有了翻身做主的哪天，一切还要变回原来的样子才可以。这就涉及到一个问题，如何恢复进程原有的风采。这是一个持久化的问题。应用级程序员对于持久化应该并不陌生，它解决实际上就是恢复的问题，不同的只是存放信息的位置，通常的选择是外存，比如硬盘，而在进程切换时的选择通常是内存，一般是堆栈。 找到了存放地点，接下来还要考虑一下存放的内容。程序=数据结构+算法，对于一个程序而言，对它持久化，关键就在于数据结构的持久化，算法本身持久化是没有意义的，因为只有数据算得上是物理的存在，这个东西想来是很奇妙的。如果把算法比作精神，那数据就是物质。怎样保存精神的东西呢？归根结底，还是要通过物质的东西来体现，就像我们把自己的想法记在纸上一样。在CPU运行的层面上，数据就是各个寄存器的内容。所以，只要把寄存器的内容保存下来，我们便得以将进程持久化了，当然，这还会涉及到一些内存里的东西，但其核心在于数据持久化。 还有一个有趣的地方，持久化的工作是在原子操作执行完毕之后进行的。对于CPU来说，原子操作应该是一条指令，值得注意的是，CPU响应中断是在一条指令执行完毕，而不是过程之中，这样就保证了在中断处理过程中，原有指令执行是完整的，这与数据库中的原子性异曲同工。持久化的工作只有在一个原子操作之后进行，才可以保证数据恢复时的正确性。在OS层面上，正是由于原子性的粒度很小，即指令级，这样才使得进程管理部分有机会在这种级别上进行调度，而在高级语言上看，程序是在任意处中断执行的，因为通常高级语言的一条语句要对应着多条指令，而这恰恰成为了进程透明化的又一关键。 就这样，OS成功的做到了欺上瞒下，实现了进程的透明化，正是因为这样，我们在使用进程时才可以完全的一意孤行。这就是设计的精彩所在，其它模块对其背后的复杂一无所知，而这只是OS经典设计的一点体现。 dreamhead @ 17:43 | 阅读全文 | 评论(1) | 引用Trackback(0) | 编辑 日历 最近更新 最新评论 存档 我的链接