Java EE

摘要： 刚开始用Razor的时候经常把RenderSection当作RenderPartial的替代品，其实它是ContentHolder的替代品。Section的意图是在上级页面（原来的master）中建立一个空间，在子级页面中向其中根据需要填充内容。因此不能在被直接调用的子页面（如index）中直接写RenderSetion，而只能写@section。因此直接访问带有RenderSection的页面，相当于直接调用master。点击下载免费的敏捷开发教材：《火星人敏捷开发手册》 阅读全文

摘要： 说起oracle，每个oracle　DBA都是很头疼的，为什么？oracle软件本身就是很大的，动不动就是这里出问题，要么就是那里出问题了，总之，就是各种问题。小弟我在oracle这个领域还是新手了，没有任何经验，在自己的本子上玩玩oracle了。花了重金买了本《Oracle　DBA宝典》这本书，从头开始学习oracle。呵呵，我是下了决心的。 问题是说来就来，今天准备打开Em，管理一下数据库。无法进入，反正就是无法进入。错误提示如下：手工启动：emctl start dbconsoleEnvironment variable ORACLE_SID not defined. Pleas... 阅读全文

摘要： 本文长期更新，请常来看看。• 序言– 从代码行到故事点敏捷估算：故事点与直接估算天数的差异– 下一步？• 敏捷团队绩效管理– 谁来管理团队中的个体？同行压力（兼谈敏捷团队，绩效管理，自组织团队）目标管理（百度百科）– 敏捷团队的目标– 从团队外部认识团队目标 敏捷团队绩效管理与目标管理：关于如何为团队设立外部目标– 敏捷开发中的目标管理意识 – 执行与实施层面的敏捷实践 敏捷生态系统：2009敏捷中国大会上的演讲稿139团队（大型研发团队，大型敏捷开发团队，大型团队结构，敏捷绩效管理）绩效管理：软件开发团队的非物质激励机制• 敏捷产品版本管理– 当我们成为“产品的主人”“迭代期间内变更”与敏捷 阅读全文

摘要： 作者：陈勇出处：blog.csdn.net/cheny_com迭代期间无变更？支持派说：对，如果经常变，我们怎么开发啊。反对派说：不对，敏捷开发不能上来就确认了需求，要的就是在开发中逐步了解需求，怎么可能不变呢。只在开发层面，这个问题无解。让我们站在研发心理学的高度来看这个问题。先看看如果变更了，团队会有哪些不利的心理变化。1. 咱们不要在开始承诺能完成，一旦变化承诺就落空了2. 既然总是在变，每次我们都预留点估算余地吧3. 别着急，你忙也完不成的，到最后一天还给你变4. ……再看看Product Owner，这个变更发起人居然也发生了变化：1. 反正日后可以变，这次计划会我就不出席了，让他们 阅读全文

摘要： 作者：陈勇出处：blog.csdn.net/cheny_com迭代期间无变更？支持派说：对，如果经常变，我们怎么开发啊。反对派说：不对，敏捷开发不能上来就确认了需求，要的就是在开发中逐步了解需求，怎么可能不变呢。只在开发层面，这个问题无解。让我们站在产品版本规划的高度来看这个问题。下个产品版本（或下个迭代）中到底应该有什么功能？最重要的功能？最基础的功能？当前可能实现的功能？已经弄清楚的功能？这些角度都是基于技术活动而非市场目标来制定的，都有其局限性。其实，每个产品的版本都是企业的一步棋：在某个时间，推出某些功能，满足某些需求，获取某些客户，打败某些对手，取代某些产品。若认同了这一点，则早在产 阅读全文

摘要： 作者：陈勇出处：blog.csdn.net/cheny_comIT人士要想被激励起来，除了可以用薪酬之外，其实还有很多办法。比如笔者刚刚毕业的时候，曾经彻夜编制一个软件长达5个月，原因是自己居然有一台专属的486电脑；而数年后我一个同事会在中午一边吃饭一边编程，是因为他独自负责一个至关重要的模块……很多人身边都因为各种不同的原因发现神奇的被激励的人，这些激励机制有哪些可遵循的规律呢？我02年左右曾经读过一本麦克康奈尔（当时人称美国几大GURU之一，《完美编程Code Complete》也是其作品）的《快速软件开发》，里边曾有一章节提及软件团队的激励问题，其大致将人分为两种：团队领导和团队队员， 阅读全文

摘要： 这篇博文主要讲的是冒泡排序（Bubble Sort）。千万别小看了冒泡排序，去很多的公司面试，上机题很多都是冒泡排序，为什么冒泡排序会成为面试的宠儿呢？这个嘛？其实我也不知道，天知道那些纠结的面试官是怎么想的！呵呵，不管他了，只要我们掌握了冒泡排序，还怕他们吗?伙计，来吧！开始我们的冒泡排序吧！ 算法思想：通俗易懂的说，就是大的数往下沉，小的数往上走，就好比在水中，气泡往上冒一样，一次得名为冒泡排序，不管了，我也不知道是怎么命名了。我想现在也一无证可考了吧。 现在就根据下面我的思路走一遍算法吧！A[0] 56 23……A[1] 23 56……A[2] 89 89……A[3] 12 12……A[ 阅读全文

摘要： 作者：陈勇出处：blog.csdn.net/cheny_com很多人都知道甚至感觉到敏捷开发的生产率比传统开发高，但到底敏捷开发是怎样提升生产率的呢？以及当前自己正在实施的敏捷开发还有多大的生产率潜力？当然“受激励的个体”会产生生产率，但只是这样解释恐怕难以服众，更难说服老板。让我们换一个角度吧。下面几个问题揭示了一些隐性的生产率潜力：10万/100万/1000万代码行的项目有20%/48%/65%被取消（Jones, 1998）成功交付的产品中，约2/3延期交付（The Standish Group, 1992~2004）所有软件平均60%左右的功能从未或很少被使用（个人是PPT和Excel 阅读全文

摘要： 作者：陈勇出处：blog.csdn.net/cheny_com在敏捷中直接估算天数最大的好处是直观，坏处是很难衡量是否有故意的高估和低估，也不能比较生产力是否在提升，于是基于故事点的估算应运而生。基本使用方式故事点的基本做法是：把一些常见的“标准任务”给出一个“标准点数”，形成比较基线，估算的时候只要是同一类型的任务，直接写上故事点数而非天数。比如：1. 对单个表进行增删改查2. 为一个已经存在的数据表增加一个复杂报表3. 修改一个中等难度的BUG……在刚开始的时候，“点数”可以就是以往完成任务的平均天数。比如曾经有4次对单个表进行增删改查，查看历史记录发现天数大约是15天，则可以定为15点。 阅读全文

摘要： 在敏捷测试中也有测试活动乃至专职的测试人员，但其活动内容和目标是有显著差异的。一般在传统开发团队中，产品经理（或销售）为范围或称之为需求负责，项目经理和开发组为进度负责，测试组为质量负责，部门经理为成本负责，结果就是当四者发生矛盾时，会有四个部门各自站在自己的立场上，从而导致沟通不畅或或博弈成分超过合作。在敏捷开发中需求与进度的冲突由计划会和自组织团队机制解决，成本由BDC和故事点开发率的提升来解决（解决的不好），而进度与质量间的矛盾，则由新型的测试理念来解决。在传统测试中，测试团队被认为是找BUG的人，比如如果BUG众多，则测试人员和开发人员会一起加班，后者修改BUG，前者验证是否修改好。而 阅读全文