存档

2012年9月 的存档

抱歉,那可不是爱

2012年9月29日 没有评论

有人认为爱是性、是婚姻、是清晨六点的吻、是一堆孩子,也许真是这样的,莱斯特小姐。但你知道我怎么想吗?我觉得爱是想触碰又收回手。塞林格的这段关于爱的理解一直让我印象十分深刻,是啊,关于“爱”,关于什么是爱的话题从过去到现在已经被讨论了无数遍了,人们一直在争论着,在爱欲中挣扎,时不时感觉自己理解了爱。感觉自己终于读懂了这份上天赐予人类最美的礼物。可又一次次被骗的一无所有,心中的爱一点点被忙碌的,不堪的,琐碎的现实生活吞噬掉,直至消失。

今天就来说说——爱。

爱不是恋爱宝典上教你如何取悦异性的技能

不知什么时候,这样的书开始畅销起来了,什么《男女爱情密码》《如何在情场上百战百胜》《俘获对方的100个妙招》。 一个个如白纸版的小青年,开始幻想从这些书中学到一击制胜的方法, 看完一些这样的书,你就以为你是一个游走情场的老油条了?

有一天,当你那个真正爱的人出现的时候,你会发现这些全部不管用,如果在一段爱情中,人的智商没有下降,那么你经历的根本不算是爱情。你会心甘情愿的沉沦到一种单纯的幼稚中,像一个调皮的孩子一样斤斤计较,打打闹闹。并乐此不疲,甘之如饴。而这些恋爱宝典所定义的东西最多只能称的上是一种模式化的,按部就班的“关系”。这可不是爱。爱是一种山呼海啸般的悸动,轰隆隆的,仿佛直接从地底迸出来的。

爱不是一种被旷日持久追求的感动

大学时,有一个长的很漂亮的女同学。各方面都很有优秀,所以注定高傲。追求她的人很多,每天上演着各种追求。都是电视剧里,电影上,那些俗套的情节。诸如每天送早饭啊 楼下夜半歌声啊 各种帮忙的苦力活啊。

我不知道她是不是被这种突然涌来的深情惯坏了,她开始变得越来越高傲,越来越瞧不起那些男生,她开始享受一种公主般被捧着的生活。最后,她选了一个追求最久,最用心,对她最好的男生恋爱了。后来好像结婚了。去年,听到她的消息,说是婚后那个男生的脾气变得越来越糟,开始对她斥责来 指责去 ,她不再是一个高高在上的公主,快变成一个任劳任怨的嬷嬷了。听到这样的消息,还是对她有一些同情,比较各方面条件来说,她都称的上是下嫁那个男生的。可能最大的错误,就是她误把一种旷日追求的感动理解成爱了吧。

对于有些人来说,他追求的是一种猎宝过程,而不是这样宝贝本身。一旦他要的东西到手了,他就厌倦了,那些以前被他捧在手心的宝贝也就不再珍贵。这样单方面的追求和接受可不是爱。爱不是慈善事业,有时一个人要学会斩钉截铁的拒绝。

爱不是年龄快到期的无奈将就 。

很多人之所以迫不及待的寻找爱,是为了安抚自己年龄快到期的紧迫感。仿佛爱是在这个年龄段他们要完成的任务。而那些压力来自于周遭那些朋友,亲友,父母连绵不绝的“关心”。他们总会在各式各样的谈话中,携带这样一个致命的问题,“你有对象了吗?”

比如,隔壁的老张的女儿在银行上班听说,干的很不错的样子,你有对象了吗? “最近出席了一场好浪漫的婚礼,好羡慕他们哦,对了,你有对象了吗? 谁谁谁的儿子真可爱啊,你有对象了吗?被问烦的我们,再也不想被这些问题噎住,总想能有底气的一声大吼 “有了 有了 老子终于有了。于是很多人开始参加各式各样的相亲,碰上感觉还不错的对象,两个人还没接触了解几个月,就迫不及待的结婚了。这样的婚姻注定漏洞百出,最后惨淡结尾。他们找到的只是一个可以生活的对象,而不是一个点燃世界的爱人。

爱不是像侦探一样窥视对方每一秒的踪迹

生活里太多这样的斗智斗勇了,今天你在我西装里发现一个陌生的口红,明天我在你手机上发现一条暧昧的短信,今天我在你包里发现一条陌生的项链,以为是给我的礼物。明天发现你下班后晚归,跟异性同事谈笑风生。

天天这样累不累,一段真正的爱,是无比信任的,根本没有第三者可趁的机会。那些婚外情或是劈腿往往是两个人本身的关系已经发生不可逆转的裂变,妄图通过这样的跟踪和窥视困住对方,以此来填补横在你们面前巨大的裂痕。最后都是徒劳无功,惹得对方恼怒,反而给了对方借此了结的借口。

我曾在微薄里发一条关于恋爱定律的微博,有人这样回复到,“除非是极弱的女人,就是那种极没大脑的女人,大部分的女人都是遇强则弱遇弱则强的。男人足够强,则女人小鸟依人,男人略弱,那女人就撑半边天。”这段话说的不错,只是第一,这样聪明的像变形金刚的女人可不多。第2,这种斗智斗勇区分双方强弱从属关系的百般附和每天上演累不累。到最后自己疲于应付,也不想继续下去了。爱的关系,是一种自然发生并立即定性的,一把钥匙配一把锁,你一会是钥匙一会又要当锁了,最后只能是一个被人遗弃的四不像旧玩具。

那么爱到底是什么呢?

爱是一旦来过,就永远抹不去的心底驻留。
有时候,我们会自负的以为已经忘掉那个人了,我们用生活琐事,努力工作,泛滥的去爱很多人覆盖在这个记忆上,自欺欺人的以为它已经消失了。可是,只要碰上一点点和那些旧事有关联的物和人,那些好不容易抹杀掉的记忆又全部回来了,致命的,急促的,就像一束照进洞穴赶走所有盘踞很久蝙蝠的光。

爱来之前才不会和你打招呼,爱是一种突然袭来的感觉,是你见到一个人的瞬间,感觉自己就像一个已经习惯黑暗却突然大赦出狱,见到久违太阳的死刑犯。

爱是笨拙的,两个跌跌撞撞的傻瓜反而能在无预警的匆忙中撞见对方,撞见爱。

爱最大的价值在于两个人相爱的过程,一段爱结束的时候,你可能会不幸。可能幸福。只有在追逐爱的过程中,你才会体验到“最快乐” “最痛苦”,只有在你爱的最火热的时候,才能体会到这个情绪最值。

爱是好奇心与警惕心的交织,你们就像两只同类的动物,在森林中相遇,看到彼此,面面相觑,不知所措,呆呆的站在那里。

爱是最强烈的柔情。即便你是一个再冷酷无情的人,你一旦遇上了爱,也会变成一个浪漫诗人。

爱需要沉静的了解,相互信任,共同享受和彼此原谅。爱是不受时间、空间、条件、环境影响的忠实。爱是人们之间取长补短和承认对方的弱点。

说来说去,其实爱很简单,就是两个人有共同的生活目标,朝着同一个方向展望,在同一片未来的彩云下神游。

原文来自豆瓣



分类: 网摘 标签:

从经理的角度看技术债务

2012年9月12日 没有评论

现在已经到第十次迭代开发周期了,你的项目开发速度开始变慢。在之前的几个迭代周期中,团队没有像以前那样完成很多的“故事场景”(stories)。此外,最近在新的故事场景和回溯中却发现更多缺陷(bug)。项目经理知道,团队成员没有变,他们也花同样的时间工作。但是,客户会发问:“发生什么事情了?这个团队还在努力工作吗?”

很多敏捷团队的产品改进率为150-500%,可是你们的项目看起来却貌似只有20-40%左右的改进率。这到底是怎么回事呢?在此我们找不到什么大问题;相反,只是有无数的小问题。有时,这些只是一些为了方便而使用的捷径(开发人员没有时间去清理这些修改),有时开发人员仅仅是不熟悉这中语言。还有一些问题就是,代码跟灌木丛一样凌乱,需要大幅度的修整。所有这些都属于“技术债务”。

什么是“技术债务”?

它就是“那些内在的事物,现在你不去解决,遗留下来(不干完),它就会阻碍未来开发”[Ward Cunningham]。 表面上,应用程序看起来质量很高且状况良好,但是这些问题却隐藏在下面。 QA(质量保证部门)甚至可能告诉你说,这个应用程序真是不错,几乎找不到缺陷,但是其中仍然存在“技术债务”,如果我们没有很好地管理并设法降低这些“技术债务”,那么,程序编写和维护的代价最终将会超过它对客户的价值。

技术债务就像信用卡一样,会有很高的利息率,就如同给团队留下了大量的帐务开销。这种情况下,开销将会体现在时间花费和解决问题所需的努力上面。开发团队拖延债务的时间越长,所积累的利息就越多(会额外增加很多工作),付出的成本也就越高。

另外,这还增加了实际的财务支出:开发团队处理技术债务所花费的时间,可以用在对团队有价值的其它工作上。同时,这些难读的代码引起的技术债务也让我们难以找到软件的缺陷。再且,理解代码所损失的时间还可以用来做其它更有价值的事情呢。

我们为何要累积技术债务呢?

项目编码初期,不整理代码,不写单元测试,也不做测试驱动开发,整个团队粗制滥造出更多的“故事场景”。 这些问题通常都不会马上暴露出来,而循规蹈矩地编写代码往往需要更多的时间,特别是在早期阶段。

技术债务来自哪里?

  • 没有经验的开发人员 —— 有些项目里面,编写Java/C#/Ruby的开发人员没有接受过培训,或者没有面向对象的观念。结果呢,他们会一直编写适用于他们曾经习惯的编程语言——像Visual Basic等——的代码。
  • 项目工期的压力 —— 那些来自于经理或客户的显性压力和其它一些潜在的压力。“我们承诺在以后迭代(发布)的故事场景中做到这些”。开发团队会发现他们不会交付这些承诺的发行版本(迭代版本),而是采取便捷的手段。“我们不得不把事情做完;我们无法承担修整代码所耗费的时间。如果这不是新特性/缺陷,那么就不用去做”。 不幸的是,这些观点还会得到管理人员的支持,特别是在管理层没有意识到这些成本的时候。
  • 凌乱而难读的代码。当一个方法或类中存在一些难读的代码,下一个开发人员继续这些工作的时候,就觉得他也没有必要迫使自己编写清晰的代码。所以,每次有人接手这些代码的时候,一小段脏乱的代码将会变成一大堆乱七八糟的代码。
  • 专业领域的代码 —— 往往有这样的观念:这些代码看起来就是很差劲,但是这不属于我的领域,所以我不能或不会改变它们。另外,对于修改专业领域的代码,开发人员也会觉得力不从心。
  • 过度复杂 —— 开发人员经常趋向于在需求之前设计解决方案。而且,很多情况下他们的代码没有找到正确的方向,还会写一些没有用处的代码。或者,这些代码没有真正地符合需求,因为代码在问题还没有完全明白的时候就已经写完了。还有另外一种情况,过度设计花费了额外的时间,产生的代码不是不能使用就是不符合项目的需求。
  • 糟糕的设计 —— 有些解决方案只是设计不佳。但在设计不好的代码上面继续扩展,而不去解决这个问题,会使问题更加恶化。

解决问题

这个问题的并不是一下子可以解决的,解决方案需要通过几个迭代周期。并且,你需要耐心,并要从多个角度寻找解决途径。

解决方案中的要点

  1. 让开发人员接受语言方面的基本培训并教授他们面向对象的原理,从而把他们的理解力提升至入门阶段。要想既成功又有效的话,这需要花几个礼拜的时间培训,还需要有精通这方面的人员来跟进和支持这一系列培训。
  2. 告诉开发人员和管理人员,当前的这些问题都是需要花费企业资金的。这点尤其重要,因为它会使解决这些问题的意义更加明确。你要清楚地告诉他们,管理人员会重视这些问题,并且已经开始着手偿还这些技术债务了。不断支持这些工作使之成为常规的原则之一,这样整个团队就会信任这个准则。
  3. 提供一些培训,包括代码的坏味道,重构,单元测试和测试驱动开发等。还可以结合课堂会议,基于网络的材料和书籍来进行培训。
  4. 在工作的时候,给他们一些空余时间去研究和练习他们的技能(一个礼拜两个小时应该是达成这个目标的最小的时间量)。练习的代码应该被丢弃,这样,他们就能无拘无束地尝试和试验一些事情,不管怎么样,他们不用在基础代码库上面进行练习。花点时间练习和研究应该是最有用的建议了。假如没有为他们提供空闲的时间,就压根不会发现真正合理的敏捷开发方式。这种组织方式也被称为“道场”-Dojo(更加详细的资料可以参考 TDD Randori Session 和 TDD Randori Workshop)。
  5. 使用工具(静态分析,单元测试,持续集成,自动化可接受性测试)来帮助团队发现、减少和衡量他们的技术债务量。应该在团队层面利用这些度量数据,而不能分享给管理人员。团队成员需要知道,他们并不会因为对这些技术债务的度量而接受奖励或者遭受惩罚。如果我们把这些度量数据报告给管理层,并由管理层来追踪的话,开发人员很快会找到一些窍门来规避它们,这样就失去了本来应有的价值了。
  6. 当人们完成了他们的培训或者在技术上取得了少许提升时,应该得到奖励。奖励可以是给予一次认可的表彰或者是一些小小的礼物,但不要直接给予现金奖励。
  7. 每两个礼拜进行一次午餐聚会和一些关于技术方面的学习型会议。利用这些会议来促进开发成员之间的讨论。提供午餐可以提高参会人数。另外比较重要的是需要管理人员每次都来出席,这样就很清楚的表明他们也一直支持大家提高技术。
  8. 维护关于技术债务的备忘录 – 任何时候,如果开发人员发现一些无法立即应付的技术债务时,就需要填写一份技术债务登记卡。开发人员应该优先考虑这些技术债务,并花费10-15%的精力来偿还这些技术债务。大多数项目中,任何的一些小事都会使问题变得更加严重。

基于这样的立场,你会发现问题,也会拥有机会。你的问题是:项目的基础代码一直在积累技术债务,但是这些债务已经开始下降了。然而,现在跟客户申请用于处理这些问题的资金会跟处理这些问题一样困难。你的机遇是:提高了开发人员的技能;清楚地表达了管理层对这项工作的支持,还有,软件的代码质量会不断改善,软件缺陷的数目也会不断减少。同时这也会很好的提高团队的整体开发能力。

英文原文:Technical Debt a Perspective for Managers

译文原文:infoq

作者:Mark Levison 译者:赖勤毅 发布于 2010年11月5日



分类: 网摘 标签:

Sql语句优化注意

2012年9月4日 没有评论

1.尽量不要对列名进行函数处理.而是针对后面的值进行处理
例如where col1 = -5的效率比where -col1=5的效率要高
因为后面的条件对列值进行了计算.这样的条件下优化器无法使用索引
而是要针对所有值进行计算之后才能再比较

2.尽量使用和数剧列一样的值进行操作
如果col1是数值型
那么例如where col1 = 2和where col1= ‘2’
则前者效率更高
因为比较字符和数值型的时候
引擎需要把两者都转化成双精度然后进行比较
这样col1上的索引就失去作用了

3.减少函数的使用
例如where col1 >= ‘2009-10-26’ and col1 <= ‘2009-10-27’
和where datediff(day,col1,getdate())=0
后者因为用到函数处理.所以col1上的索引又无法使用了

4.尽量不要用OR
一般对于OR的条件
优化器一般会使用全表扫描

原文地址:http://blog.rebill.info/archives/Note-that-SQL-Optimization.html



分类: mysql, 数据库, 网摘 标签:

无觅相关文章插件,快速提升流量

互联网安全