Evan's Tech View

如果将字母?A?到?Z?分别编上?1?到?26?的分数，(A=1,B=2...,Z=26)?你的知识(KNOWLEDGE)得到?96?分(11+14+15+23+12+5+4+7+5=96)?你的努力(HARDWORK)也只得到?98?分(8+1+18+4+23+15+18+11=98)?你的态度(ATTITUDE)才是左右你生命的全部(1+20+20+9+20+21+4+5=100)?从

There are no perfect structure . There are only structure that try to balance the current cost and benefit.Pattern is something that comes with both costs and benefits.You should find yourself using t

We Need 去ThoughtWorks的Portal逛了圈,看看他们招聘开发人员,都要求些什么东西..NET Application DevelopersIf you have...4+ years development experience with either 3 years of Java J2EE recently moving to

这个05年，开年就懒了一把，到今天才提起劲来润一把我的blog开年的前两周就接踵几件不顺心的事，不过很快就过去了。事情顺不顺，关键还是看自己怎么看，就象我自己前两天还安慰Eidde，“有什么事情大不了的呢？”呵呵工作上，主要研究并运用了Authorization,.NET Sink,AOP 几样技术。授权上有几点体会（1）授权（Authorization)和验证（authentiact

为什么不能很好的沟通？如果对方性格暴躁到极点，那情有可源，否则都是沟通双方的事情。项目中与人合作，总感觉沟通上不是很顺利，原因其实很简单：每个人都更多的以自我为中心，以自己的经验积累或片面的书本知识为评判事务的标准，更严重的是即使感觉的自己错了也拒绝承认。而软件开发中绝对的对与错又太少了，每个人在平衡的时候方向稍微不一就可能导致长时间的争论。想到以下几点可以改善的方面：其一：敢于否定自己问题没有最

乌江鱼火锅用料：鲜活草鱼1条（约1500克）或花鲢鱼（2000克）、火锅底料300克、郫县豆瓣200克、泡辣椒末250克、泡姜150克、干辣椒节15克、豆豉末35克、姜颗30克、泡酸菜100克、花椒4克、蒜片30克、葱节100克、油酥黄豆40克、鸡精20克、味精15克、白酒25克、盐适量、白糖8克、料酒100克（或啤酒半瓶）、干细豆粉60克、色拉油800克。制作：1、鱼宰杀后治净，剔下两扇净肉，剔

一、 马太效应二、 手表定理三、 不值得定律四、 彼得原理五、 零和游戏原理六、 华盛顿合作规律七、 酒与污水定律八、 水桶定律九、 蘑菇管理十、 奥卡姆剃刀定律十一、 二八法则十二、 钱的问题　　一、马太效应《新约•马太福音》中有这样一个故事，一个国王远行前，交给三个仆人每人一锭银子，吩咐他们：“你们去做生意，等我回来时，再来见我。”国王回来时，第一个仆人说：“主人，你交给我们的一锭银子，我已赚

我抑制不住再次推荐>，尤其是Part IV:Strategic Design,每每读着不经意间碰到段言语，就正好是自己近来的亲身体验。我确信系统做大了必然是无数的问题，感谢作者以自身丰富的经验为我们引路。下午刚进行了场思想斗争，为了工作量、效率等原因，牺牲了架构的完整性，看看Evans都给我们说些什么了---“An up-front imposition of a large-scale stru

要避免这样一种诱惑，即把你的最初假设视作答案把解决问题的过程看作是证明最初假设的练习。要保持一种开放而具有弹性的思维。不要让一种强有力的假设变成头脑僵化的借口.                                                               -----------载自>这好象是我和团队成员经常犯的一个错误 ------ 在OO的某些整体或者局部细节设计时

 http://evanyuan.cnblogs.com/csdn居然没有打包下载备份,社区的氛围也太差, 实在没理由再待在这里,

>一、人之所以痛苦，在于追求错误的东西。> 二、与其说是别人让你痛苦，不如说自己的修养不够。> 三、如果你不给自己烦恼，别人也永远不可能给你烦恼。因为你自己的内心，你放不下。> 四、好好的管教你自己，不要管别人。 > 五、不宽恕众生，不原谅众生，是苦了你自己。> 六、别说别人可怜，自己更可怜，自己修行又如何？自己又懂得人生多少？> 七、学佛是对自己的良心交待，不是做给别人看的。> 八、福报不够的

从"豆豆他爹"那里拷来一段很有意思的对话今天，挤在公交车里，听见一对母子的对话。“妈妈，为什么没有人买票？”“这是无人售票车，妈妈上车的时候，在车头的投币箱子里投上钱，然后我们在这个门口下车就行”“妈妈，为什么要说两遍星海广场？”“因为要提醒人不要坐过了站？”“什么叫坐过了站？”“就是说本来要在这站下车，结果在后面的站才下去”。“那为什么要说两遍呢？”“害怕说一遍有

这两天项目比较忙,也做得比较郁闷,偷闲逛了下BlogDriver,还是蛮有收获这个同志的话,对我很有指导意义http://johnson.blogdriver.com/johnson/index.html"其实，我也慢慢的感觉倒这一点。与其抱怨别人不接收你的想法，不如好好的去考虑如何让别人接受或者与他们一起找出问题的解决方案。从肯定别人入手，可以为双发找到一个共同的出发点，而不是从一开始就势如水火

引用JJX的一段话“作为一个不时要给别人建议的咨询提供者，我想说的是：你唯一可以相信的，是你自己的实践证据。没有任何一种技术会是万灵药，也没有任何一种技术是非有不可的——也许出于自己的恐惧，我会说面向对象技术是非有不可的，然而面向对象在企业级应用这个领域里简直是放之四海而皆准的。至于EJB、Spring、Hibernate、WebWork之类的具体技术，如果有谁说其中某一个是不可或缺的，只有掌握了

以前在blogcn上有自己的blog,虽然没发几篇文章但是最近特想写几份东西上去的时候,发现那个网站居然在升级维修,而且一连就是4,5天不叫好转出于对csdn的信任,换到这里来,不知道是否会有一天csdn 突然不干了,或者说blog数据全部丢失或损坏. 真出现这种情况,谁来对这么多丢失的思想负责?? 是否该提供功能,可以让发表的文章打包下载呢?或者提供数据不会丢失的保证,并且对丢失进行负责的保证呢

 "程序要写的放松，首先就要尽量使用单一技术，程序和代码是有呼吸的。单一的技术能让程序的呼吸更加顺畅与人的感觉保持一致自然而协调，同时一旦你强迫自己采用单一技术，那么你的程序将会写的让人兴奋异常，光芒四射" 这是从Wintegel那里引来的话,一个对音乐研究颇深的人对程序的理解。我很喜欢里面"程序是有呼吸的"这样的认知。我对程序的认知源于毕业后正式开发的地一个项目，两月之内匆匆弄出来就给了客户，后

??????? 今天单位里面新来两周的一个暑假实习生走了,或许对他们这种名牌大学的人来说,在这样的公司工作,做着这样那样的小事,可能是有点屈才了。??????? 也或许根本不是那么回事，可能别人有自己的特殊情况。只是看着他推着包回家的样子，想起以前自己也为了干些瞧不起的“小事而觉得委屈，但如今才发现受益菲浅，不由得想在键盘上敲上这么几句。?????? 曾经经手过一个小的产品，因为缺少人手和好的管理

试了下google或baidu查找自己写的内容,不行. 为什么其它的blog可以呢? 是静态网业动态网业的区别吗?不懂

早上觉得自己最近要学的和要做的事比较多,想用 紧急&重要 的四个区间来给它们做下划分,最后 不紧急&不重要 的区间为空,送给自己两句话.The more you want to achieve ,the less you can achieveIf anything is important ,then nothing is important  

2002>>注: 看这两本书的时候，我经常问自己大学的时间都在干吗2003>>注: 两本书都是在家休息的一个半月时看的,这一个半月绝对超值2004>注: 一周就看完的书,促使我在以后的项目里面更苛求质量和结构> >注: 两三年之内的方向基本上有了>注：换一种心态面对工作，面对同事to be contiune.....

没有太多的编程经验，对交互的系统进行半年以上的系统维护，学习他人的代码，接受用户“变态”的需求，更改系统满足用户需求，体会老的系统不合理带来的痛楚实在是很有必要（不过维护的系统最好是对公司不是太重要的，经得起折腾的系统）否则一开始写的代码往往毫无可维护性，你无法体会经验丰富的程序员为什么要精心设计搭建系统

我真的很佩服有的开发人员，可以在对自己所开发的东西的业务不甚了解，就进行开发，而且为了项目进度，甚至懒得去理解。我很怀疑这样是否能创建出用户所需要的系统。 或者说软件开发分工中，如果设计人员设计的够好，开发人员可以不需要理解那么多业务。但是我想在一般的中国的软件公司，设计应该不可能达到这种水平啊。

深受项目维护苦难的人，是不是都容易产生这么一种幻想-----要是这是一个经过精心设计的比较纯的OO的项目，而且对象模型很优雅，项目的维护将轻松很多？或许是这样，我也这样幻想过，现在渐渐清醒点：时间总是紧迫的，设计开发人员的能力总是和“大师们”的水平相距甚远的，精心设计的OO也容易成为铁板面对需求变动无能为力。系统不一定真的要好到哪里去，为用户创造价值是最重要的。立谦那么一个在我的眼中如同垃

"唯一不变的就是变化"一两年前这句话我说给别人听，现在别人说给我听需求当然是容易变化的,但是在有时候还是要区别对待,当心这么种理念对项目造成大的伤害首先,需求分析不到位即开始设计实现,名曰"以后反正要变的" --- 看到需求的表面而不是本质,面对变化估计不会那么从容.这种情况下返工的原因往往不是需求的变化而是最初根本没有把需求搞清楚.另外,系统的设计要够灵活,才能很好的应对变化. 如果系统的设计和

johnsonqu把gigix的话引过来,自我提醒一把,我也把他的文字再引一遍,自我提醒一把"http://forum.javaeye.com/viewtopic.php?t=6664&postdays=0&postorder=asc&start=0，JavaEye的讨论总是如火如荼，这一次对于AOP的讨论竟然又开到了第二个系列，乖乖！不过，这里我想说的不是对于AOP的意见，而是对于透明的这段回复