摘要: 最近在读《The Productive Programmer》学会了很多东西,我选择了一些对我可用的记录如下:1、Launching Pad:尽量将个人电脑中的常用工具编排好,放在Launching Pad中,由快捷键启动,保证桌面的整洁。2、Clipboard:使用多重剪切板,保留多个剪切历史。3、Development Accelerators:开发加速,尽可能多使用IDE快捷键。4、Search:尽量用查询查找需要的文件,而不是点击项目树结构查找。5、Marco:如果需要执行一个命令多次,把它保存成宏。6、Find Hard Targets:在os中寻找文件尽量更多参数的查找工具,你可能 阅读全文

posted @ 2011-08-20 23:43 绿里奇迹 阅读(303) 评论(0) 推荐(0) 编辑


摘要: 前不久的pair着实被鄙视了一把,之前homework所有精力全用在了设计和代码上面(虽然仍然存在很多问题)而从没有建立在pair的假设下完成项目,所以写的比较慢,等到了pair现场,发现pair的同伴不可能像你一样低效的等着所以被告知不注意细节,对工具不熟(确实没关注过Eclipse的快捷方式),在此记录一下:搜索工作空间中的声明Ctrl+G在窗口中 搜索工作空间中的引用Ctrl+Shift+G在窗口中 搜索打开“搜索”对话框Ctrl+H在窗口中 搜索显示“文件中的出现位置”快速菜单Ctrl+Shift+U在窗口中 文件“新建”菜单Alt+Shift+N在窗口中 文件保存Ctrl+ 阅读全文

posted @ 2011-01-26 15:20 绿里奇迹 阅读(1446) 评论(0) 推荐(0) 编辑


摘要: 罗列了珍藏的书籍和文章(随时更新) 阅读全文

posted @ 2010-03-31 13:14 绿里奇迹 阅读(207) 评论(0) 推荐(0) 编辑


摘要: 常用工具安装配置 阅读全文

posted @ 2010-03-20 12:05 绿里奇迹 阅读(1575) 评论(0) 推荐(0) 编辑


2013年1月10日

摘要: 任何新技术,新方法的文档和书记都大致分为两类。第一类是官方手册,是白皮书,对该技术有最权威的解释权,由技术提出者维护。此类文档一般只是枯燥的记录功能条目,其作用等价于字典(没人会拿着字典从第一页看到最后一页看完)。优点是给该技术提供了一致的解释权,该技术对于使用者有根基可循,缺点是相对枯燥不适合用来技术传播。第二类是技术使用者根据自己经验写的类似于“最佳实践”的材料,里面融合和作者个人看法,相对比较生动,组织也很吸引人。优点是有想法,适合用于技术传播,缺点是比较主观,个别观点未见得准确或者说有偏见。当两部分材料结合在一起就能发挥最大的作用。下面分享几点技术文档写作建议(中英文),通用于上述两种 阅读全文

posted @ 2013-01-10 17:28 绿里奇迹 阅读(404) 评论(0) 推荐(0) 编辑


2012年12月8日

摘要: 世界上几乎绝大多数事情的发生都是有偿的,有条件的,只不过大多数情况下讲述者可能出于对他们来说过于显而易见,或者干脆就是下意识而为,而不会把这些背后的条件和假设说出来,比如《时代周刊》最近公布了他们评选出来的2012年10部最佳电影和10部最差电影:十部最佳电影:《爱》《南方的野兽》《少年派的奇幻漂流》《安娜·卡列尼娜》《蝙蝠侠:黑暗骑士崛起》《猎杀本·拉登》《黑马》《武侠》《科学怪狗》《隐秘的战争》十部最差电影:《云图》《异星战场》《总统别恋》《吸血鬼猎人林肯》《特工争风》《老雷斯的故事》《亚历克斯·克洛斯》《孕期完全指导》《蒂莫西的奇异生活》《金钱第一》这十部最 阅读全文

posted @ 2012-12-08 19:30 绿里奇迹 阅读(674) 评论(0) 推荐(0) 编辑


2011年9月1日

摘要: FluentInterface是DSL里的重要概念其为业务人员和开发人员搭建了桥梁假设BA要向开发人员表述构建一个“汽车”对象,传统的方式是这样Car car = new Car();car.setFrontWheel(...);car.setRearWheel(...);car.setWindow(...);car.setCeiling(....);这在JAVA领域很常见,但是这些可恶的set函数对于业务人员太过技术化,而且此类表现很罗嗦使用fluentinterface后的方式是这样:Car car = new Car().frontWheel(...).rearWheel(...) .w 阅读全文

posted @ 2011-09-01 13:15 绿里奇迹 阅读(577) 评论(0) 推荐(0) 编辑


2011年8月17日

摘要: 我总结使用DVCS的场景主要包括1、中央仓库可能在远程,比如一个项目是多国完成,团队分布在不同大洲,每次向中央仓库提交更新都需要等到漫长的连接过程,所以使用Git或者Mercurial提交到本地,待网络状态良好情况下集中提交更适合。2、开发人员经常需要离线提交,比如经常需要在飞机上,旅店里提交代码。3、项目对特征分支(Feature Branch)要求很高,需要频繁创建分支,即便频繁分支非常不推荐使用,但是在某些场景下还是必不可少。虽然CentralizedVersionControl工具(比如SVN)能够创建分支,但是这些分支对所有人都是可见的,并非安全的sandbox,DVCS对于VCS的 阅读全文

posted @ 2011-08-17 13:17 绿里奇迹 阅读(406) 评论(0) 推荐(0) 编辑


2011年8月2日

摘要: Martin Fowler给了一篇很好的文章http://martinfowler.com/bliki/RollerSkateImplementation.html从中能学到很多东西。以往的系统建设仅仅是获取用户的需求,并将需求实现成系统,这一点有错么?表面看起来没错!从传统意义上讲也没错!但是请看下面一段小故事:某天,外面下着大雨,你坐在办公室里,突然你的同事焦急的过来说“有伞么?借我用用!”,你会说“我没带伞”然后继续做自己的事情。第二天你得知你的同事因为没有伞而错过了一个很重要的聚会,而当同事得知你昨天开车来,并且车就在楼下的时候,他非常懊恼的说“早知道叫你开车送我去好了”。类似这样的小 阅读全文

posted @ 2011-08-02 13:22 绿里奇迹 阅读(217) 评论(0) 推荐(0) 编辑


2011年1月30日

摘要: 针对某功能进行TDD的步骤如下:1、编写测试用例,此时因为被测试的类还没有实现,所以肯定编译不通过2、写最少的代码保证测试用例通过编译3、运行测试用例,此时可能测试失败4、写最少的代码保证测试成功5、填充测试用例,使测试用例变得丰富,针对边界值等进行充分测试6、重构测试类,写最少的代码保证针对该功能的各种测试都通过,并且消除代码冗余 阅读全文

posted @ 2011-01-30 15:29 绿里奇迹 阅读(270) 评论(0) 推荐(0) 编辑

摘要: Martin Fowler在文章中详细讲解了Mock的应用理念http://martinfowler.com/articles/mocksArentStubs.htmlMockTest是区别于传统测试方法之处在于传统测试风格是状态验证测试,而Mock是行为验证测试Martin Fowler比较了Mock与其他Test Double的不同之处哑对象(Dummy Object):从来不会被使用,一般是用来填充参数列表。伪造对象(Fake Object):拥有方法的实现,通常为了避免直接操作生产环境而使用一些捷径,比如内存数据库测试DAO。桩对象(Stub Object): 提供和真实对象一样的接口 阅读全文

posted @ 2011-01-30 15:20 绿里奇迹 阅读(798) 评论(1) 推荐(1) 编辑


2011年1月27日

摘要: http://martinfowler.com/articles/designDead.html#DoYouWannaBeAnArchitectWhenYouGrowUp在马大叔的文章中讨论了计划式设计和进化式设计的不同在Planned Design中,人们通常会做一个Front-Big-Design,其优势就是可以讲设计职责和开发职责区分开,设计的人负责设计,开发的人负责开发。但是在现代软件工程领域Planned Design有诸多的缺点:第一,过度依赖于设计者的技能,如果设计者能力不足或者设计不周全而使得实现者产生疑问时,沟通较复杂,过程较长。第二,这种模式使得设计者完全脱离编码,而技术在 阅读全文

posted @ 2011-01-27 17:23 绿里奇迹 阅读(271) 评论(0) 推荐(0) 编辑

摘要: Alistair Cockburn 十分强调Information Radiator的作用 http://alistair.cockburn.us/Information+radiatorInformation Radiator(信息发射器)区别于传统的沟通方式是其是“推式沟通”不是“拉式沟通”你不需要打断别人的思路而获取信息,一切都在白板上写着呢Information Radiator在敏捷实践中还有一个很重要的作用就是可以让其他团队的成员看到你们团队的信息,以用来改善他们团队的建设,这在传统沟通途径上很难,试想想你在焦头烂额解决一个问题时候,一个你们项目不相干的人突然跑来问你你们项目的情况 阅读全文

posted @ 2011-01-27 15:41 绿里奇迹 阅读(428) 评论(0) 推荐(0) 编辑

摘要: MartinFowler用最通俗的语言阐述了软件架构的本质“软件架构就是那些一旦确定了,就很难更改的东西,所以确定之前一定要谨慎再谨慎”。如何才能合理的设计软件架构呢?林巴斯,克莱门斯等在书中定义了架构设计的方法学,我总结如下:第一步:收集需求,万事起于需求,没有需求什么也定不了。第二步:从需求中识别架构驱动因素。比如“我需要一个注册登录页面”这样的需求不会驱动架构的设计,而“我们有500万用户”会驱动架构设计。第三步:根据架构驱动因素制定出“架构风格”,也是最困难的一步。架构风格优先于架构,是架构的指导方针。按照罗伊博士的话说架构风格就是作用于架构之前的一组约束。这时候肯定会出现很多相冲突的 阅读全文

posted @ 2011-01-27 14:54 绿里奇迹 阅读(542) 评论(0) 推荐(1) 编辑


2011年1月14日

摘要: 在Robert Martin的SOLID原则中,LSP是实现OCP的重要原则之一。LSP规定:任何使用到子类的地方替换成父类都能正常运行,也就是说子类里面不能有,公有的且父类里面没有定义的方法。但是考虑到现实情况,很多时候LSP无法得到保证举个例子,在Java里,可以将接口分为两类,一类是行为接口。一类是标识型接口行为接口比如people接口定义了人类不同行为,所有的人种都要实现这样的行为,行为接口属于对客观事物的一种抽象,这种情况下LSP是实现OCP的关键步骤但是标识型接口不需要LSP的限制,比如Comparable,总不能要求实现Comparable的类只有compareTo一个公有方法吧 阅读全文

posted @ 2011-01-14 17:17 绿里奇迹 阅读(359) 评论(2) 推荐(0) 编辑


2010年12月13日

摘要: 在JDK5.0中新增加了特性Annotation,可谓为后来JavaEE架构带来了不少技术性变革各种annotated风格的架构如雨后春笋一般涌现出来,EJB3.0, Junit4, SpringMVC 3.X 以及后来的Servlet3.0规范都迫不及待地支持annotation到底annotation有多大魔力呢?一、annotationVSxml有人说annotation用作配置比xml更好,其有一定道理又并非完全如此,annotation和xml在配置领域相辅相成,各自扮演自己的角色我认为一般的配置可以分为两类:第一类为开发级别配置,这些配置是方便开发有条不稳的进行,不错乱,这些配置在 阅读全文

posted @ 2010-12-13 23:17 绿里奇迹 阅读(252) 评论(0) 推荐(0) 编辑


2010年12月2日

摘要: 最近想写一个BS模式开发的小型工具,要能在物理硬盘上存储数据,又要轻便,不要动不动就装个ORACLE这么大的软件,希望足够的便携,考下就用,考虑了几个可用方案。1、Access的MDB文件优点:非常非常的轻便,并且能把ORACLE等主流数据库中数据自动转成MDB缺点:(1)MDB文件不是标准的数据库文件,使用Access软件查看数据的时候无法用SQL检索记录。(2)MDB文件一般用ODBC访问,O... 阅读全文

posted @ 2010-12-02 14:51 绿里奇迹 阅读(633) 评论(0) 推荐(0) 编辑


Copyright © 2024 绿里奇迹
Powered by .NET 8.0 on Kubernetes