存档

‘网摘’ 分类的存档

我想嫁给一个这样的男人

2013年1月19日 没有评论

题记:今天闲逛微博,发现一篇美文,话说妹子想要嫁给一个什么样的男人。其实这个问题我一致困惑着。不知道各位看官是如何思考的。我想我会努力成为,下面文章中所说的那样的男人。

[我想嫁给一个这样的男人]

我想嫁给一个这样的男人,

嫁给一个性情稳定的男人,我们各自上下班,过朝九晚五的生活。 我们一起在领工资的那一天,小小的大吃一顿犒劳自己。 我们手牵手去银行,存我们每个月的爱情储蓄,给我们将来的小Baby。 开着我们小排量的大笛笛,看着存折上的小数点,满足于我们小小的成绩。
我想嫁给一个这样的男人,
嫁给一个勤快的男人,他会做好吃的饭菜,会用洗衣机洗衣服,会把屋子打扫的亮堂堂的。 会在每个月我想偷懒的那几天,全全料理家务,放我一个美美的大假。 伺候我吃,伺候我穿。 尽管等我好了,我要加倍服侍我的大老爷。 我也还是会赞叹生活如此的美丽!
我想嫁给一个这样的男人,
嫁给一个心思细腻的男人,不会忘记我的生日,我们的结婚纪念日,知道我的喜好。 会偶尔在我表现良好的时候给我一些鼓励。 买我心仪已久的小东西,送我做奖励。 会让我的家人,朋友,欣赏他的超强观察力。 会傻傻的笑,腼腆不语,其实却蛮有心计。 随时冒的出新奇的鬼主意。
我想嫁给一个这样的男人,
嫁给一个懂得上进的男人,即使工资少的可怜,我们也能用剩余的时间去发展副业。 只要我们俩个人在一起,就算下海打渔也会觉得浪漫无比。
我想嫁给一个这样的男人,
嫁给一个喜欢旅游的男人。 等我们有了时间,就跑到想去的地方走走看看,我们在每一个留下我们脚印的地方拍模样搞怪的照片。 等老了以后,我们就坐在阳台上,我翻着照片数落他: 你看你啊,你个臭老头,年轻的时候就没个正经。 照相还瞪眼伸舌头呐!
我想嫁给一个这样的男人,
嫁给一个心灵手巧的男人。 万一家里哪个哪个坏了。 出了小毛病他能够轻松修理。 不会让我急的又跑去买个新的来用。 回来便自己责备自己败家,又乱花钱,挣钱真的不容易!
我想嫁给一个这样的男人,
我要嫁给一个懂事的男人,他有我没有过的经历,有我没有过的故事。 他能帮助我,他能管教我,他能告诉我,应该怎么好好的控制我自己。 遇到不开心的事情,有他,我就不会再没完没了的哭泣他能像爸爸一样抚摸着我的头发,轻轻的说爱我。 然后再也不离开我。
我想嫁给一个这样的男人,
嫁给一个喜欢孩子,喜欢动物的男人。 我要生个超级帅的儿子,再多一个女儿我也不介意,我们养我喜欢的小宠物。 有一天看见宝宝爬在狗狗身上说: 狗狗,狗狗,我爱你。 我要做个温柔漂亮的妈咪,等儿子长大了会骄傲的搂着我的肩膀出去。 自豪地炫耀说:“这个‘姐姐’其实是我妈咪。 ”
我想嫁给一个这样的男人,
嫁给一个说话算数的男人。 我要他能监督我守时,守规矩。 更能控制他自己。 我想要他不用我等啊等啊,等到没了耐心。 我想要他犯了错会诚恳,不逃避。 我想要他不骗我,不跟我玩神秘。 我想要他知道我们要做什么。 什么时候要做什么。 去哪里做什么。 像导航一样,控制我没主见的大脑。
我想嫁给一个这样的男人,
嫁给一个懂得欣赏的男人,我们要有一个不必太大的房子,要很多阳光能照进来的大窗户或者落地玻璃。 我要串一排又一排亮亮的珠子,做成帘子,微笑着说那是我的一帘幽梦,告诉老公,每一颗珠子里都有我的一个愿望,关于,我们。 我不要古老的白色墙壁。 我要卧室是粉蓝色,厨房是水绿色,雪白沙发,透明角椅。 我要在在墙壁上挂满我们的照片。 我要生活里处处充满颜色,温馨又甜蜜。 假如老公出差去,自己留在家里不会寂寞,也不会害怕和恐惧。
我想嫁给一个这样的男人,
嫁给一个长的不帅却很平易近人的男人,他要没有大大的啤酒肚,没有地中海似的大光头。 他要没有鸡毛蒜皮都计较的小心眼,也要没有莫名其妙就爆发的坏脾气,他要喜欢运动,充满男子气。 他要喜欢唱歌,就算走调到吓的我哭泣。 他要捧着我的脸说,娶到你,真是我的福气
分类: 网摘 标签: , , ,

软件工艺宣言

2012年10月15日 没有评论

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

 

作为有理想的软件工匠,我们一直身体力行,提升专业软件开发的标准,并帮助他人学习此工艺。通过这些工作,我们建立了如下价值观:

 

Not only working software, but also well-crafted software

 

不仅要让软件工作,更要精益求精。

 

Not only responding to change, but also steadily adding value

 

不仅可以响应变化,更要稳步增加价值

 

Not only individuals and interactions, but also a community of professionals

 

不仅要有个体与交互,更要形成专业人员的社区

 

Not only customer collaboration, but also productive partnerships

 

不仅要与客户合作,更要建立卓有成效的伙伴关系

 

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

 

也就是说,左项固然值得追求,右项同样不可或缺。

 

© 2009, the undersigned.

this statement may be freely copied in any form, but only in its entirety through this notice.

著作权为下述签名者所有

此宣言可以任何形式自由地复制,但其全文必须包含上述申明在内。

分类: 网摘 标签:

抱歉,那可不是爱

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, 数据库, 网摘 标签:

分享9个单页面网站开发必备jQuery插件

2012年8月7日 没有评论

单页面网站作为简单快捷,易于维护的页面设计方案,越来越受到工作室,作品集,或者个人博客类网站用户的青睐,我们可以使用不同的特效来使得页面更加的丰富和炫动,今天我们将介绍几款可以作为单页面开发的jQuery插件,帮助大家快速简便的实现一个单页面的网站设计,希望大家喜欢!

jQuery one page nav

使用这个插件,可以帮助你快速的搭建一个滚动的页面导航,如果你需要比较简单直接的方式开发一个单页面的网站,这个插件是一个不错的选择。

分享9个单页面网站开发必备jQuery插件

jQuery ScrollPath

jQuery ScrollPath是一个非常棒的插件,允许你画出自己自定义的滚动路径。HTML元素可以被放置到路径上,而且类似的鼠标滚轮,键盘上下移动键,或者空格都可以帮助你移动到你需要到达的元素位置。并且一个可选的自定义滚动条可以帮助你方便的点击和拖拽滚动。而且插件允许你使用CSS变形旋转整个页面。

分享9个单页面网站开发必备jQuery插件

Ascensor.js

使用这个jQuery插件可以帮助我们定位页面任何内容块到画布,并且可以使用键盘来浏览。而且这个部分可以被上下左右的导航和浏览。

分享9个单页面网站开发必备jQuery插件

Curtain.js

curtain.js是一个用来使用自定义的窗帘效果显示多个固定面板的jquery插件,拥有非常棒的滚动特效。

分享9个单页面网站开发必备jQuery插件

Zoonooz.js

一个缩放的插件,但是可以用来定位单页面中的不同区域

分享9个单页面网站开发必备jQuery插件

Pagify.js

这个插件可以用来创建单页面的网站,这个插件的实现方式是将不同菜单中的内容保存到不同HTML文件中,并且通过定义的div来加载不同的菜单项内容。

分享9个单页面网站开发必备jQuery插件

JustaPage

Justapage不仅仅是一个插件,还是一个用来设计单页面网站的模板,这个模板是跨浏览器兼容的,并且支持移动设备!

分享9个单页面网站开发必备jQuery插件

SuperScrollrama

这个超棒的插件可以帮助你生成视差滚动特效,如果你希望你的网站更酷一些,那么就整合这个插件吧!

分享9个单页面网站开发必备jQuery插件

Waypoints

Waypoints可以用作页面内滚动操作的单页面导航设计插件。它可以让你方便的处理页面滚动事件,你可以比较自由的在自己的UI中使用这个插件控制页面滚动事件。

分享9个单页面网站开发必备jQuery插件

来源:分享9个单页面网站开发必备jQuery插件

分类: javasript, Jquery, 网摘 标签:

爸爸和无我编程十条诫律

2012年8月1日 没有评论

在爸爸去世前,我和他谈论了2个星期关于编程的事。

我22岁,一个在大学里攻读美术设计的四年级的学生。爸爸62岁,一个很老的爸爸。早在世纪60年代他就在田纳西理工大学编程,他在打孔纸带上做FORTRAN开发。他知识丰富。

这个学期我才刚刚开始接触编程,而我的整个脑子全被它吸引住了。编程很神奇,很强大,在很多方面比图像设计更富创造性(我会在另外的文章里谈论这个话题)。

在我假期回到家时,爸爸向我分享了无我编程的十条诫律。他把它打印出来,逐条和我讨论。这是在他意外去世前我们仅有的关于编程的讨论。也许这是让我对此念念不忘的原因。

来自写于1971年的《程序开发心理学(The Psychology of Computer Programming)》,下面就是这无我编程十条诫律:

  1. 理解和接受自己会犯错误。关键是要尽早发现,在错误进入到最终产品前发现它们。幸运的是,除了我们少数几个在喷气推进实验所开发火箭导航系统的人外,在软件行业中犯错误通常不会导致灾难性事故。我们可以,也应该从错误中吸取教训,微笑,并继续前进。
  2. 你不是你的代码。记住代码审查的全部目的就是去发现问题,相信问题会被我们发现。当有问题疏漏时不要自责。
  3. 不管你对“空手道”有多了解,一定会有人知道的更多。如果你去问,这样的人可以告诉你一些新的招数。从别人那里寻找和接受新的知识,特别是那些你认为不需要的知识。
  4. 不要在没有讨论的情况下重写代码。在“调整代码”和“重写代码”之间有一条很细致的界限,你应该在代码审查的制度下做风格上的调整,不要独断专行。
  5. 对那些不如你的人要尊敬,礼遇,有耐心。经常跟开发人员打交道的非技术人士通常持有这样的观点:程序员凭借一技之长狂放不羁。不要让你的发怒和缺乏耐性让他们心中的这种形象加深。
  6. 这世界上唯一不变的就是变化。开放思考,面带微笑的接受它。把需求上、平台或工具里的每个改变都视作一种新的挑战,而不是把它们当作大麻烦来抵制。
  7. 真正的权威来自知识,而不是职位。知识造就权威,权威带来尊敬——所以,如果你想在一个无私的环境中获得尊敬,去培养自己的知识吧。
  8. 为信仰奋斗,但我文雅的接受失败。要理解,有时候你的想法会被拒绝。即使你是对的,你也不要报复或说“I told you so.”千万不要让你心爱的被抛弃的想法变成殉道者或抱怨素材。
  9. 不要成为“角落里的程序员。”不要成为隐藏在黑暗办公室里、只因为口渴才出现的人。藏在角落的里程序员短视、与世隔绝、不受控制。这样的人在公开的、合作的工作环境中发不出声音。参与到交流中,成为你的办公室团体中的一员。
  10. 批评代码而不是人——对编码人友善,但不要对代码友善。尽可能的让你的批评具有积极性,以改进代码为目标。批评要联系本地标准,编程规格文档和提高后的性能等。

这个十条诫律至今伴随这我。它让我成为了一名更好的程序员。有时我在想,如果爸爸还在我身边,他还会给我哪些建议?虽然我不知道,但我相信,他会为我一直记住这些而高兴的。

更多关于爸爸的信息,请阅读Frank Bush对计算机业的贡献,这是有他在田纳西理工大学的同事们收集编辑的。

[本文英文原文链接:Dad and the Ten Commandments of Egoless Programming ]

本文转载自: 外刊IT评论 http://www.aqee.net/

分类: 网摘 标签:

验证自己创业idea是否可行的最简单方法

2012年7月16日 没有评论

对于创业者来说,确定自己的创业idea是否可行、能否赚钱并具有可行的盈利模式,将大大节约成本。著名博客作者Max Klein讲述了一位英国创业者在经历6个失败项目后,终于在第7个项目上实现了上线3个月其每月营收就突破2万美元的故事。该创业者分享了他发现、证实一个创业idea是否可行、是否具有需求以及能否盈利的最简单方法。

在这位创业者看来,要验证一个创业idea是否可行,你只需要使用社交媒体如Twitter。具体操作如下:

  • 在Twitter上建立你品牌的账号,在描述自己的地方,精简写出能表达你idea的1到2句话。当然,整个品牌的名称以及后面的语言描述需要花费很多时间来选择。
  • 然后,在你Twitter的目标群体里寻找一位非常著名的人物,比方说极客、母亲或者笑话爱好者,这取决于你对你目标群体的定位。
  • 关注你选择的那位著名人物所关注的粉丝。
  • 如果你能获得一个超过10%的回关注率(回粉率),那么你的idea就是一个不错的创意;如果回关注率低于这个百分比,那么这个idea就不值得继续。

这个方法可以允许你用在以下事情上:

  • 选择一个能吸引你目标市场的品牌和Logo
  • 将你的idea简化为一句话
  • 挑选你的目标市场
  • 发现你的目标市场是否对你的服务感兴趣

这是一个运用社交网络来验证一个创意是否可行的实例,方法非常简单,最为关键的是完全免费。或许这只是一个个例,但是随着社交网络越来越成熟、社交关系越来越清晰、社交网络里的兴趣图谱越来越细化,这个方法也许会成为未来验证很多事情是否可行的方案。

如今利用Twitter的信息流来研究股票走势、经济发展趋势的方法已经越来越多,如创业公司SocialStock让你用社交影响力来买卖“股票”。通过挖掘与分析网络中的个人“情绪”数据,“股票雷达”为用户判断股票走向提供实时支持等都是利用社交网络的案例。

文章来自 36氪
分类: 网摘 标签:

给IT新人的15个建议:苦逼程序员的辛酸反省与总结

2012年6月21日 没有评论

很多人表面上看着老实巴交的,实际上内心比谁都好强、自负、虚荣、甚至阴险。工作中见的多了,也就习惯了。

有一些人,什么事都写在脸上,表面上经常得罪人,甚至让人讨厌。但是他们所表现的又未必不是真性情。

 

我相信大多数人都看过《豪门夜宴》这部香港老电影。张学友、梁朝伟演的拍马屁 的场景太有意思了,其中有这样一段:当两马屁精帮老板说出主意,老板马上叫停,然后拍一下脑门:“哦。。。我想到了。。。”,把别人的idea当成自己的 说出来。我在工作中还真不止一次遇到这种事,我提出来的想法老被别人拿来当作自己的原创,当然个别小偷洋洋得意的描述自己的‘原创’时还会偷偷的瞄我一 下,看我有没有不高兴,,,我并没有不高兴,大概是因为想到那个电影段子被逗乐了。天下学术都一大抄,更何况什么想法,什么创新,通通都是浮云!君不见创新项目一大堆,都被抄死化成灰!但是不能因此而放弃创新,大地不可以因为有畜牲吃草而不复生机,山泉也不会因为有王八偷水而不冒活水。第一点:保持有一颗生机灵动的心。因为这个东西是别人偷不走的,也是最大的财富。如果你不俱备这个东西,那么请用一颗善心去培养它。人人都是耀眼的珍珠,只是被灰尘蒙蔽了眼。

 

记得刚进公司那会踏踏实实工作,满怀激情。不过第一周就把自己的顶头上司给得罪了,我并没有做错什么,记得当时还有同事帮我说话,后来慢慢发现他是 一个相当自负的人。不过话说回来搞技术的在技术方面有几个不自负。这次事之后我并没有学乖。对于别人设计不合理的地方,我会指出来,并提出该如何做。对于 语言基础薄弱,设计模式薄弱的同事,我会好心推荐一些书籍,,,,,,本是好心帮助别人,却并没有得到别人的感激。相反,大部分会觉得你看不起他们,更有 甚者不但不会反思改进自己的弱点,反而打击报复看不起他的人。所以千万请记住第二点:不可以随便提意见。我并没有说不提,只说不要太随便,想清楚了再提。向别人提好的建议是一件很重要的事,但是要学会委婉的表达。这一点在日常生活中同样实用。

与第二点相对,第三点:经常肯定、称赞同事的成果和进步。注意这里并不是要你去巴结讨好。常常看到别人的优点并加以肯定也是比较正面和必要的行为。这样不但可以增进关系,更重要的是可以鼓励别人。

 

我一直认为一个人没有自知之明就等同于垃圾。要随时随地知道自己小名叫什么。话说我有一位同事,基础相当薄弱,但又太爱去表现自己,经常到处指指点点,生怕别人不知道自己是“高手”。由于老开“黄腔”常被人背后偷笑而不自知。第四点:低调一些,谦虚一些不断提高自己的实力。


进公司时所在部门是刚成立的,工作一段时间后,我发现由于部门团队开发的特殊性很有必要在公司通用编码规范基础上再制定内部的编码和设计规范,于是 向上司提了我的想法,他同意了。于是我起草了一个内部规范手册。但是执行过程中,有人按手册来,有人不按手册来。产生这种局面的根本原因是上司并没有支 持。在这里没有必要分析原因,直接给出要记住的第五点:不在其位,不言其事。做好本职工作就好。无论在什么地方,开明而大度的好上司并不多,所以这一点相当重要。

 

经常在开会讨论设计方案的时候,会发现一个非常有意思的事情。会议本来进行的正常而和谐,当轮到某个优秀的人上去讲的时候,气氛一下子不和谐了。大 家都迫不及待的想挑出他的毛病,就算没理解别人的意思也会乱说一气。秀才遇到兵了,,,,,,以前实习的公司中也时常见到这种情况。每当此时我都会在下面 感叹:好一幅百鸟凤图。请记住第六点:木秀于林风必摧之,要懂得韬光养晦,不要时时锋芒毕露

 

公司里有个老员工,实力比较强,算是一个独挡一面的人。不过在一次部门改组中并没有得到提升,被提升为经理的反而是一个能力不算太强,还比他晚来的人。在此之前我听到过那个老员工在和其它公司接触并准备跳槽的传闻。第七点:不到最后一刻,自己离职的想法不可以和公司内部任何人分享。因为站在公司的角度来看你已经不忠诚了,不愿意重用你了。但是在员工自己的立场来看,公司给的待遇与能力不成正比、不认同公司的文化、想换个环境、想要一个更好的发展机会,这些都是合情合理的。我个人发现一个规律:在一般的公司里,凡是坚持到最后经受住了“考验”的“忠诚”者,往往都是没什么能力的庸才(一般来说公司管理越先进,这种情况越不会发生,这是大BOSS应该操心的事)。如果你是一个公司高层管理者,那么你会如何对待类似的“叛徒”呢?

 

第八点:不得罪办公室里的女人。 此处女人定义如下:(1)国宝级的女程序员;(2)女测试,这个不稀罕 ;(3)女助理,到处都是;(4)女上司,这个最要命!   男的处在一起,有什么冲突矛盾吵吵过了就忘了。但女的不一样,一不小心就得罪了,后边一逮到机会就会摆你一道,还没完没了!最要命的是:背地里狠狠的阴 你,而当着面表现得像你温馨的亲人。好吧,本着男女平等的原则,这一点可以没有、、、、、、

 

我们研发中心有个领导很可爱,不太清楚上面给他灌了什么迷魂汤,以至于自己职位被降了,职权被销了很大一部分,还整天手舞足蹈高兴得很。事后一两个 月才反应过来不对劲,然后整天愁眉苦脸、、、、、、以这种交际反应的速度,被撤是必然的事情,确实不适合搞管理。技术男大多脑袋是‘方’的,不太善与处理 人际关系。第九点:加强交际能力。程序员大多还算是聪明的,平常稍稍注意一下就没什么大问题。不过不要自我感觉良好,我们公司有个工作了十多年的IT男,几年前就开始被派除去和客户沟通,丫的,至今那一口吞吞吐吐的蹩脚的普通话让人听了就伤心。

 

第十点:若无特殊情况,一定不要跨级汇报。这一点细节很重要。某种意义上你的顶头上司就是你的老板,直接决定了你的发展,你就是他手下的兵。并不是谁官大就听谁的,要不然历史上那么多兵变都不可能成功,因为大家都只听皇帝的,呵呵。从另一个方面讲,你‘忠于’你上司的上司,他也不敢用你,因为谁知道提拔你之后,你会不会再越一次级?!!

 

第十一点:要善于向上司汇报工作。 国家干部是不是人民的公仆本人不太清楚。但公司里那些大大小小的管理者一定是(如果不是这样那他就不是一个好上司)!那些“夹板男”(形象称呼,绝无贬 义)大小确实是个官,不过过得很纠结。既要应付好上面的领导,又要充分调动下面群众做出业绩,整天搞得焦头烂额。上面的唱白脸,那么夹板男就唱黑脸。总之 挺不容易。他们的猜疑心大多都很重(换谁都这样)!时常会怀疑下面的人没尽心工作。虽然一般公司都有什么任务分配管理系统,但是那东西远远不够。你需要找准时机让他清楚你工作进展,你所做出的努力。

 

第十二点:不要轻易造成情绪污染。不要因为你一个人不高兴,而让别人都看你的脸色。要学会雪藏自己的情绪。你若是一个领导,那这一点就太要紧了。

 

第十三点:一举一动找准自己的位置、别人的位置。比如:吃饭时的座次,照相时的排列位置,群发邮件时收件人的排名顺序,文档作者的位置顺序、、、、、、这些都很重要。《易经》中有讲:明相位,立德业。要是你连自己在哪儿都不知道,你又如何到得了目的地。

 

第十四点:没有必要做一个愤青。刚毕业那会,我很愤青,看不惯这看不惯那。但是又能怎么样呢?弱肉强食的本质从来没有改变过,你要学会尝试去理解这个社会,理解种种关系。到某个时候你会发现:一切理所当然。你若真的不满意某个现状,那么就去尽自己的能力去改变它。势者,不均也!均则无势。

 

第十五点:记住别人的善,忘记别人的恶。一个人心里不应该有太多仇恨,仇恨是别人扔给你的垃圾, 你又不是垃圾桶,老装着它做什么?在公司当算法工程师近三年了,别人怎么对我,我的心里跟明镜似的一清二楚。对我不好的人我并没太在意,更别说去报复。相 反,他们有事要我帮忙的时候,我总能真心实意的去帮,甚至主动帮忙解决问题。这是这几年来,我对自己唯一满意的一点。我相信一句话:活着就是修行。但是你 得清楚你修的是善行还是恶行。

 

毕业三年了,看看走过的路,总觉的有点荒凉。确实真正明白了许多道理。感谢帮助过我的人,也感谢打击过我的人。也许一个人只有亲身经历了困难才可能真正成长起来,由此我不得不感叹造化的残酷。

原文来自http://blog.csdn.net/pozen/article/details/7583820

程序员需要谨记的九大安全编码规则

2012年4月1日 没有评论

历史已经证明,软件设计的缺陷一直是导致其漏洞被利用的最主要的罪魁祸首。安全专家发现,多数漏洞源自常见软件中相对有限的一些漏洞。软件开发者和设计者应当严格检查程序中的各种错误,尽量在软件部署之前就减少或清除其中的漏洞。

下面列举的这些方法会有助于开发人员提高编码的安全性:

一、注意编译器警告

程序员应当使用编译器的最高警告等级。在编译过程中,应当修改程序中的错误,直到警告解除。应当使用静态和动态的分析工具来检测和清除安全缺陷。

二、根据安全策略设置软件架构

设计者应创建一个软件架构,并在设计软件的过程中实施和强化安全策略。例如,如果你的系统在不同的时间要求不同的特权,就不妨考虑将系统分解成能够互联通信的不同的子系统,每一个系统都有自己适当的特权。这种“分而治之”的方法可以有效地提高应用程序的安全性。

三、验证输入

程序设计者在设计程序时必须验证来自所有不可信数据源的输入。适当的输入验证可以清除多数软件漏洞。在设计程序时,必须对多数外部的数据源抱着怀疑的态度,其中包括命令行参数、网络接口、环境变量、用户控制的文件等。

四、保持程序简单

设计者要尽量使程序短小精悍。复杂的设计会增加实施、配置、使用过程中出现错误的可能性。程序越复杂,就需要越多的复杂的安全控制,企业需要付出的努力也就会越多。

五、拒绝默认访问

访问决策的制定应当根据许可权限而不是根据其它的任何方面。这意味着,默认情况下,应当拒绝访问,程序的保护机制应当根据“允许谁访问”来确认访问条件。

六、遵循最小特权原则

程序的每个处理过程在执行时,都应当仅使用为完成其工作而需要的最小特权。任何提升的许可权限都要尽量持续最短的时间。这种方法可以减少攻击者用提升的特权执行任意代码的可能性。

七、“净化”传送给其它系统的数据

所谓“净化”是指从用户输入的数据中清除恶意数据,如清除用户提交表单时的恶意的或错误的字符。

程序设计者必须对传送到复杂的子系统(如命令外壳、关系型数据库、购买的商业软件组 件)的所有数据进行“净化”。攻击者有可能通过使用 SQL 注入命令或其它注入攻击来调用这些组件中没有被使用的功能。这未必是输入验证问题,因为被调用的复杂的子系统并不理解调用过程中的前后关系。由于调用程序 理解前后关系,所以我们要在调用子系统之前对数据进行“净化”。

八、实施深度防御

程序设计必须能够利用多种防御策略来管理风险。只有这样,才能在一层防御不够用或失效时,另外一层防御可以防止将安全设计上的缺陷变成可被利用的漏洞,从而可以限制攻击者利用漏洞的后果。例如,将安全编程技术与安全运行环境结合起来,可以减少在部署阶段残存在代码中的漏洞被攻击者在操作环境中利用的可能性。

九、使用有效的质量保证技术

良好的质量保证技术可以有效地确认和清除漏洞。模糊测试、渗透测试、源代码审计等都可以结合起来使用,以此作为一个有效的质量保证项目的一部 分。独立的安全检查可以使系统更安全。有资质的外部审查人员可以提供独立的观点,例如,外部人员有助于确认和纠正一些错误的设想。

当然,为保证代码的安全,企业应当为开发语言和平台制定并实施一套健全的编码标准。

原文来自

互联网安全