| Profil de 希章陈希章@中国PhotosBlogListes |  Outils  Aide |
|
|
11/05/2008 开源项目：windows Security Suite这是一套基于.NET Framework 2.0中，windows程序的安全套件，包括了用户和角色管理、身份验证、授权，和用户自定义设置的管理等等。 该套件默认使用的数据库是ASP.NET 2.0所提供的aspnetdb，但我们将试图支持其他数据源。 该套件将以组件的方式提供。诸如
该项目准备使用VS2008开发，也准备支持VS2005开发。因为这两个版本格式不一样，原本想自己写一个小的转换器的，不过，搜索得到下面的链接，很不错的咚咚 http://home.hot.rr.com/graye/Articles/ProjectConverter.htm 该项目托管在google的open source站点，链接地址是 http://code.google.com/p/windowssecuritysuite/ 所以，你可能需要一个gmail的帐号才能参与该项目。但作为浏览者，你不需要任何额外的工作。
该项目使用源代码管理是SVN，请通过下面地址下载客户端 http://tortoisesvn.net/about （免费的，有中文语言包，相当不错） 10/05/2008 开源项目:Business Process Template Suite这是由我组织和发起的第一个开源项目，主要是针对商业流程模板套件。其概念类似于以前我们在有的系统中的动态表单模块。 该项目包含三个部分及必要的文档，测试工程等 1. 核心组件（BPT.Core, BPT.Framework,BPT.Utility等）:这里主要是针对XML的处理的一些框架和工具 2.模板编辑器(BPT Editor)：允许客户的流程定制人员定制、修改并发布模板 3. 客户端程序集成组件（例如查看器等，分别针对windows Forms程序和web Forms程序）
为了有效地开展项目的进程，我想邀请加入开发团队的朋友最好能具备上面所提到的一些技术基础，尤其是对XML技术及其处理要有足够深入的经验。同时，我也邀请有测试经验的朋友加入。要加入开发和测试团队的朋友，您需要具备必要的开发环境，以及需要有一定的空闲时间给这个项目，而且目前我们不会在这个项目上面不会有任何直接的收益。 我们需要的开发环境是Visual Studio 2008专业版或者其他版本（最好是VSTS)。并且需要安装Team Explorer 该项目运行在New BSD License这种授权类型下。所以，即便你不是开发和测试团队的成员，你也可以查看和下载所有的源代码。 我特别要说一下，如果有对开源软件及其相关运作，法律方面有研究的朋友，欢迎大家推荐或者自荐，我很乐意向您请教 该项目由CodePlex进行托管。以下是链接
所有的团队成员都可以通过Visual Studio共享源代码。 27/04/2008 T-SQL中的多条件查询及其组合方式今天被问到一个有意思的查询，大家请看下面这个查询 USE Northwind 作者的本意是根据三个条件去返回不同结果集，他用OR区分三个条件。但事与愿违，他总是得到同样的结果集。请花几秒钟思考一下，这个查询存在什么问题呢？ 这是一个典型的逻辑性错误，而非语法问题。当然，也非人品问题。大家看这三个条件，他们是用OR分开，所以查询引擎的执行方式是， 1. 只要找到一个符合条件的，就返回，而不会再往下找 2. 如果第一个条件不符合，那么将找第二个。以此类推。 所以，本例而言，如果第一个条件City<>'Bern'为真，那么就直接返回，而不会比较后面的条件（因为没有必要）。而如果为假，这时候当然会比较后面的条件，当事实上是徒劳，为什么呢？后面两个条件中都包含了City<>'Bern'本身，而且内部又是用AND连接的。所以，如果City<>'Bern'为假，后面两个条件毫无疑问也为假，所以比较了也是白搭。 所以，根据这样的分析，我们可以如何改进这个查询呢？ 我们的做法是可以把三个条件的顺序颠倒过来，如下面所示。效果就很明显看到了。 USE Northwind 认真想一下，如果是这样的话，那么该查询就直接等同于 SELECT * FROM Customers WHERE City<>'Bern' 难道不是吗？所以，以后搞这么复杂的条件其实还是没有起作用，根源在于这些条件本身是嵌套的。 呵呵，整个世界清净了 ...... 04/02/2008 使用宏(Macro)扩展Visual Studio IDE虽然有很多工具可以开发.NET程序，但我相信大多数的开发人员都是用Visual Studio（简称VS）。VS是微软所提供的一款集成开发工具，其最新版本为VS 2008。 VS使用起来还不错，不是吗？而且它还可以被我们进行扩展，按照我们自己的需求。这的确是挺诱人的，对吧？ 认真说起来，扩展VS的IDE有很多方法，例如你可以通过创建一个所谓的"Visual Studio外接程序"，这个外接程序其实就是一个实现了IDTExtensibility2接口的程序集。
关于外接程序的具体细节，不是我们这次讨论的内容。你可以通过下面地址了解 http://msdn2.microsoft.com/zh-cn/library/ms165620(VS.80).aspx
外接程序的好处是可以比较集中地封装大量复杂的扩展，同时也易于分发。但相对来说，所需要的能力也较高。相对比而言，另外一个扩展方法——宏扩展——则比较适合轻量级的扩展。它的实现方式相对较为容易。我们下面就以一个例子来说明如何创建宏，如何运行宏，实现某些有意思的事情。 我们今天要解决的问题是这样的： 大家知道，每个解决方案或项目都有一个相对应的文件目录。我们经常需要定位到这些目录。以前的做法是（以项目为例）： 1）先选中该项目 2）在它属性中，复制它的"项目文件夹"这个属性值 3）打开"开始"=>"运行"命令，粘贴那个路径，然后回车 这些操作没有什么技术含量，地球人都知道怎么做。但经常这么做，显然不符合和谐社会的要求。试想，如果能在解决方案或者项目的快捷菜单中，就有一个命令，可以一次性做这样的事情，那该多好啊 很多事情并不难，尤其是当我们以认真的态度正视它的时候。为了实现上述要求，我们只需要写一个简单的宏。的确如此简单！ 1）通过ALT+F8 打开宏资源管理器 2）在宏资源管理器中，定位到MyMacros，右键中选择"新建模块"，给新的模块命名为ProjectContextMenu或者其他你喜欢的名字。 3）双击刚才新建的模块，把以下的代码复制到接下来打开的一个设计器中，并保存。 Imports System '这个模块主要是用来为项目添加一些特殊的上下文菜单操作 Dim process As New System.Diagnostics.Process '这个方法是定位到解决方案的目录 这样我们的宏就做好了，你可以直接执行那两个方法。看，是不是很神奇呢。它打开了当前项目的文件夹。
当然，我们还差最后一步没有完成。那就是把这两个方法关联到内置菜单里面去。 1）你需要通过以下路径打开自定义工具栏的对话框。"视图"=〉"工具栏"==〉"自定义" 2）在"自定义"对话框中，选中"上下文菜单"，你会发现所有内置的快捷菜单都显示在顶部了
3）把两个宏方法拖拽到相应的快捷菜单里面去
下面是配置好之后的效果：多出了两个菜单，分别都指向了上面写好的两个方法。单击这个菜单，就可以很方便地定位到项目或者解决方案的根目录，免去了复制，然后粘贴到运行窗口的劳动。
附加资源： Visual Studio自动化对象模型。如果确实有兴趣的朋友可以认真看一下（要想写出高质量的VS IDE扩展程序或插件，必须对该模型有较深入的认识）
如果你的机器上装好了MSDN，那么也可以通过下面的导航，了解到更加详细的信息
最后，你还可以下载VS Sdk进行更加深入的了解 04/01/2008 Oracle Providers for .NET序言： 世界是平的。难道不是吗？曾几何时，要在.NET程序里面访问Oracle数据库，并不是一件很容易的事情。尤其是ASP.NET 2.0推出以后，SQL Server自带了一些服务的支持(Membership,Profile,Role,Personalization等），而如果要把这些信息放在Oracle里面的话，就得自己扩展Provider（挺累人的一个事啊），让人觉得不平和不爽。 现在情况不一样了，这是值得大家高兴的事情。以下服务，Oracle所提供的Provider悉数支持，呵呵，我已经迫不及待地想尝试一下了，谁的机器有装Oracle，赶紧报上名来，嘿嘿
以下邮件内容摘自Oracle发送过来的Newsletter，供大家参考
Download ODAC 11g (11.1.0.6.20) Production
24/11/2007 基于Web的SQL Server管理工具（SSWA）的可行性分析事情经过是这样的： 某一天，我认真地了解了Oracle这个数据库产品，发现它没有类似SQL Server这样的企业管理器（Enterprise Manager，或者Management Studio）,而是通过一个专门的Web站点进行了所有维护和管理操作。 当时，我的感觉就是：这样都可以啊？ 主要的几个截图如下 于是，我就想，那么SQL Server如果也有这样的一个工具，会不会更好呢？
有了这个想法之后，偶尔也曾和一些朋友简单地聊起，但一直没有时间认真来分析和思考。 近日重新拾起来，对如上几点做了进一步的考量，并发了一批邮件给这方面相关的朋友、客户，提请大家帮助讨论和分析。 朋友们很看得起我，就昨天一天我就收到了很多回复，也有的朋友直接在MSN上和我交流了各自的想法。我把目前收集到的一些反馈整理如下。出于隐私考虑，我隐去了人名。 朋友们的反馈是各方面的，总结起来主要包括
我在这里对朋友们的反馈一并表示感谢！还有的朋友对SQL Server这个产品不是很熟悉，但从精神上给了我很大的鼓励和支持。这都是我的荣幸。 多位朋友提到的微软的这个Web Data Administrator工具，所以我特意下载来研究一下。 主要感想就是：这个工具是比较简陋的（这也是当年它不受欢迎的原因之一吧）。目前能做的无外乎：数据库创建和管理，表格的创建和管理，查询。这些其实都不是最重点的。 当然它做了一些基础工作，如果这次咱决定要做，可以在这个基础上改。 如果大家或者周围的朋友们有好的建议，请通过cxizhang@gmail.com 不吝赐教
下面是目前收到的朋友们的回复，供参考
23/09/2007 为微软出版社所写的书评前两天收到微软出版社送来的一本书，是由Stacia Misner编写的《SQL Server 2005 Reporting Service Step by Step》（英文原版,该书尚未有中文版本），希望我能写一段书评。今天周末，整理了一些自己对于Reporting Service的认识，给出版社回复了以下的文字。贴在博客中供大家参考，写得不好的地方，请大家以鞭策之
我们会用各种手段去实现客户想要的报表，例如一直与Visual Studio家族产品密切配合的水晶报表（Crystal Report）,或者其它第三方厂商、独立软件开发商(ISV)提供的报表解决方案，与此同时，在某些场合，我们甚至会试图自己去构建某些特殊的报表（例如用表格，或者GDI技术）。 不管怎么样，我们做到了，报表格式可能是纯粹的HTML页面，也可能是PDF或者其他一些专用的格式。我不得不说，在多种技术和标准之间切换不是一件令人愉快的事情，这些报表格式往往不能互换通用，也很难重用。而某些报表设计工作量是非常大的。如果再算上另外一个因素：客户的报表需求永远是多变的，那么你就不难想象我们当时了解到微软推出Reporting Service后的兴奋之情。 我们知道，SQL Server 2000成功发布之后，受到广大客户的认可，越来越多的客户把企业关键应用程序的数据库平台架设在SQL Server之上。与此同时，客户也给微软提出了一些新的期待，其中很大一部分声音就是希望微软能够推出更好的报表平台和工具。Reporting Service 2000由此应运而生，时间是2004年的1月份。我们马上就组织了人员和时间进行了学习，而且很好地把它运用到我们的项目中。 后来，在我为企业客户做有关咨询和演讲的时候，我总是会花几分钟时间介绍一下Reporting Service及其框架。有很多客户听了我的介绍之后，惊讶地瞪大眼睛，感到不可思议的神情我至今记忆犹新。以下几点将有助于您进行概览性了解
本书（SQL Server 2005 Reporting Service Step by Step）是由Hitachi Consulting的Stacia Misner为广大Reporting Service的爱好者和用户编写的，全书分五大部分，涵盖了使用SQL Server 2005的Reporting Service构建企业级报表解决方案的所有知识，Stacia Misner是SQL Server商业智能方面的专家，实战经验非常丰富，同时具有细腻的写作风格。该书将循序渐进，条理清楚并且理论联系实际地带领您进入Reporting Service的奇妙世界。 我有理由相信，通过这本书的学习和参考，面对解决方案中的报表需求，你也完全可以大声地说: 我有,我可以! :) 22/09/2007 面向未来，数据库开发随想应用程序离不开数据，所以我们的开发工作也就有相当部分时间是与数据库打交道。今天把几个接触过的数据库的一些管理界面整理了一下，有兴趣的朋友可以参考 SQL Server 2005所提供的管理和配置工具（小部分），SQL Server 2005真正是功能强大，使用方便
Oracle 10g所提供的管理和配置工具。Oracle的配置工具相对比较简单一些
Oracle 10g所提供的一个基于Web的Enterprise Manager（企业管理器）--这是我比较赞许的地方。 因此我甚至有初步计划创建一个项目，为SQL Server开发一套类似的Web管理工具（有兴趣和能力参与这个项目的朋友可以将你对该项目的想法发送到我的邮箱，或者在此留言），这个项目如果成功推出，也许可以出现在下一个SQL Server版本中呢，呵呵
MySQL 5.0的命令行和一个第三方的前端管理工具。MySQL是一款开源的数据库，当然，它也有收费的版本。就好像SQL Server也有免费版本一样的道理。个人认为使用MySQL的机会不多，使用不方便是主要的，而且语法方面也不一致，徒增烦恼。当然，MySQL和Oracle有一个共同的优势就是：跨平台。
最后，不管我们使用哪一种数据库系统，如果我们使用．ＮＥＴ开发的话，其访问代码是很类似的，例如下面这样
这就是。NET的优越性，不管访问什么数据源，其实语法都很类似的 其实还有很多数据源，包括我们常见的Access数据库，Excel文件，文本文件，XML文件都可以数据源 20/05/2007 正则表达式？那么难，我不会耶~ 咋办乜正则表达式，总是被我觉得很神奇，今天又拿出来研究了一阵，很是佩服当初想出这套咚咚的那些牛人 大凡学过正则表达式的朋友，对RegExLib.com这个网站一定不会陌生，那里有很多各式各样的正则表达式例子，而且他们也提供了Web Service可以供使用。无聊之下，自己写了一个很简单的客户端来进行查询，截图如下
这里不能贴附件，如果需要源代码或者可执行程序的朋友可以发邮件给我 事先声明一下：写这样一个程序基本上是没有什么技术含量的哈，你当然可以自己写一个 19/05/2007 这个图片的锯齿是怎么做出来的？经常需要自己做些PPT，看到过别人的PPT中有时候会有类似下面这样的图片，不知道他们那个锯齿效果是怎么做出来的？
装了Photoshop，一大堆工具，看得都晕了。其实我就是想做到这个锯齿而已，不知道有没有朋友可以指点一下是否有简单的方法  11/09/2006 9月10日上一周的课程安排得比较集中，连续讲了四天的课之后，加上睡眠时间也不是很够，早出晚归，昨天讲到最后喉咙有些沙哑和疼痛。不幸的是，昨天回来的车上，本想稍微再睡一会儿，谁想到旁边的两个人一直在耳朵边讲话不停，实在佩服他们有那么多话说
虽然确实辛苦，但是看到参加培训的朋友们脸上洋溢的笑容，看到他们在带领之下完成一个一个实验，还是感到高兴的
只是仍然需要注意睡眠，同时好在现在是不抽烟了。
后面已经排好的课程，有考虑到适当休息这个因素，应该会好一些
 28/05/2006 2006微软移动与嵌入式开发者大会如果没有特殊情况，我将做为MVP志愿者参加于下月的22日和23日举行的2006微软移动与嵌入式开发者大会
关于这次的任务，还没有得到具体的指令，估计是负责现场一些活动的讲解和支援工作等等 组织上比较照顾，据说两天日程中，我们有半天是做志愿者工作，其他时间也就自由活动了，可以好好学习学习一下了
24/05/2006 Sun Microsystems首席信息官访谈录
关键字：网格计算，软件即是服务，IPTV
作为改革的发源地，Sun Microsystems和它的首席信息官Bill Vass始终走在科技的最前沿。Vass曾经担任过国防部和陆军的CIO，因此，他对大型机构的IT运作过程并不陌生。而且，同时他也非常关注新技术以及新技术对未来运作可能产生的影响。 CIO Update专栏记者对Vass进行了采访，探讨了关于Sun公司IT运作过程中所面临的挑战以及CIO们应该关注的新技术这两个方面的问题。 CIO Update专栏记者：“作为一家具备高技术水准的公司的CIO，我想了解您大部分时间专注于哪方面的技术？” Vass：“在我的工作中，占用我时间最多的是对企业的管理。其中，保持目前所拥有的技术以及管理技术对我来说是比较容易做到的。困难之处在于我必须协调企业、管理企业、证明预算的合理性、参加董事会议、参加高层会晤（说明目前开展的工作，尽力让高层领导接受变革的事物），等等诸如此类的事物。 这就是我的工作内容。我可能需要花费70%的时间在协调企业以及处理企业事物的工作上。而且我认为这是一名CIO所应该做的。” CIO Update专栏记者：“但是现在不是有很多CIO实际上扮演了首席技术官CTO的角色吗?他们必须要花时间对技术进行管理，而不是集中精力在企业管理上。” Vass：“这个视公司情况不同而有很大差异。但是我认为越来越多的CIO们正在转到企业管理上来。因此，他们必须对技术拥有很好的理解，但是也必须在制定公司政策、促进企业蜕变以及跨机构工作方面花更多的时间和精力。 需要他们处理的问题中只有很少一部分是技术方面的。我可以解决任何技术问题，它通常比较容易解决。 我认为大多数CIO们需要花费大部分工作时间来开展与企业用户的良好合作，尽力证明成本的合理性，列出优化企业管理的计划，尽力使企业认同进行方法改革的必要性并接受改革，设法解决如何节约那些本该节约的企业成本以及解决无法避免的企业成本，用权衡的方法简化企业并对各种投诉作出反应——在我们公司就存在很多投诉要处理。 CIO的工作是一项并不讨好的工作。当你成为一名CIO时，之前已经有人做过你要开展的工作，而且很可能比你正在做的完成得更好。” CIO Update专栏记者：“为什么会这样？是你的上司不重视IT吗？这看起来似乎很奇怪，毕竟Sun公司是一家技术公司。” Vass：“不是的，实际上我们公司的首席执行官CEO和首席运营官COO非常重视IT。我认为，一般情况下整个执行管理团队都会非常积极的支持IT，但是位居他们之下的那一层次的管理人员往往不够重视IT。我想这是因为在那一层次的管理人员看来，我们消耗了太多的成本，而且进展不快。 当我们谈到象戴尔、微软、IBM、惠普这样的IT公司对于IT的投入时，就会看到他们在IT部门的投入大约占了公司总收入的4%、5%或6%。而在Sun公司，目前在我们部门的投入仅占到公司收入的2%，这对于一家技术公司来讲是非常少的。 我们在用仅占公司收入2%到2.5%的投入，迎接来自各方的挑战，而且从某种程度上讲，我们做得非常成功。我想同微软或者其它公司比较来看，Sun公司的许多技术都是非常高效的。另外，我认为我们公司对于IT部门的投资有些低。惠普、IBM、戴尔、微软这几家公司对IT部门的投资平均在4.5%左右，我们甚至连这个平均数都没有达到。” CIO Update专栏记者：“您认为什么技术是CIO们需要了解的？” Vass：“网格技术是非常重要的。现在，许多人认为网格技术只能局限于高性能计算的应用，事实上这是错误的。网格技术完全可以扩展应用到运行你的ERP系统，扩展应用到运行你的桌面系统，扩展应用到用相同的结构运行你的高性能计算负荷。 就这方面来讲，软件作为服务（Software-as-a-Service，简称SaaS）成为了一种新型的软件存在形态，是对原有软件存在形式的一种变革。在将来，我希望Sun公司可以不用购买Oracle许可证并运行Oracle软件，我们可以从Oracle购买SaaS，而Oracle将运行在网格上。 因此，我的想法就是我不会再去运行我的ERP系统或者CRM系统以及其它任何系统，它们将作为一种服务体现出来，而不是需要我们创建、安装、运行的某个软件。” CIO Update专栏记者：“但这并不是一个新的思路。” Vass：“现在与过去不同的是网络带宽在加大，结构在改善，网络上信息的传输速度在变得越来越快。你可以看到Salesforce.com就是一个很好的例子，它发展得很快。因此，你将会看到像NetSuite、Salesforce.com公司的崛起，而且在不久的将来，像Oracle/Siebel这样的公司也很可能会提供SaaS来适应大量的需求。” CIO Update专栏记者：“对于那些运行网格技术及SaaS服务的公司来讲，虚拟化是非常关键的吗？” Vass：“虚拟化非常重要。伴随着新的多线程芯片技术的出现，虚拟化应运而生。当虚拟化出现在网络上时，不仅仅是Sun公司重视它，其它公司也一样，不同的是，我们只是关注得比较早而已。 虚拟化实现了动态将基于线程模型的负荷发送到三个不同芯片组的可能：一个芯片组为线程提供安全保护，一个芯片组为多线程提供大容量，一个芯片组用来快速处理多线程。” CIO Update专栏记者：“其他什么技术将列入您的规划呢？您又如何看待纳米技术？” Vass：“我认为最多在五年之后纳米技术就将进入公司的供应链及物流。在收集数据和探测方面，纳米技术将同射频(Radio Frequency，简称RF)连接起来。” 因此，现在非常流行的RFID将从仅仅作为RFID改变成为RF-MEM(微型电子机械)或者成为可以用作RF传感器的纳米设备。那些RF传感器将共同建立所谓的超级网络，这些网络可以动态的连接在一起。同时，这些超级网络将返回大量的计算信息，这些信息是我们之前在ERP系统和数据仓库中从来没有看到过的。 我们将能够更加严密的控制我们为客户所提供产品的交付时间以及我们的计算支持，比过去完成得更加完善，而且这将再一次的、更大程度的优化企业，同时也将成为CIO们必须应对的又一改变。 这些事物的出现对我们来说并不遥远。因此，存储将成为纳米技术和像IP-TV那样的事物之间必须要处理的一项非常重大的任务。此外，IP-TV将被列入CIO们的计划，但实际上他们对它并不了解。 据我了解IP-TV将进入视频电视会议领域，现在的Real Player和Microsoft Media Player将被IP-TV替代。这将会成为CIO计划中的另一个非常大的变化。 在将来，你会看到规模庞大的网格，其前端提供面向结构的服务(Service Orientated Architecture，简称SOA)，这将简化应用程序，同时其内部各个组件之间可以彼此进行交互。当这样的网络得以普及，你就会看到集中管理将越来越盛行，而局部处理也将变得越来越少。” 05/05/2006 软件开发管理的75条体会[转载]1. 你们的项目组使用源代码管理工具了么？
MVM：应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。 2. 你们的项目组使用缺陷管理系统了么？ MVM：应该用。ClearQuest太复杂，我的推荐是BugZilla。 3. 你们的测试组还在用Word写测试用例么？ MVM：不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。 4. 你们的项目组有没有建立一个门户网站？ MVM：要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。 5. 你们的项目组用了你能买到最好的工具么？ MVM：应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。 6. 你们的程序员工作在安静的环境里么？ MVM：需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。 7. 你们的员工每个人都有一部电话么？ MVM：需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。 8. 你们每个人都知道出了问题应该找谁么？ MVM：应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。 9. 你遇到过有人说“我以为…”么？ MVM：要消灭“我以为”。Never assume anything。 10. 你们的项目组中所有的人都坐在一起么？ MVM：需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。 11. 你们的进度表是否反映最新开发进展情况？ MVM：应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。 12. 你们的工作量是先由每个人自己估算的么？ MVM：应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。 13. 你们的开发人员从项目一开始就加班么？ MVM：不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。 14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？ MVM：不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。 15. 值得再多花一些时间，从95%做到100%好 MVM：值得，非常值得。尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。
16. 登记新缺陷时，是否写清了重现步骤？ MVM：要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。 17. 写新代码前会把已知缺陷解决么？ MVM：要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。 18. 你们对缺陷的轻重缓急有事先的约定么？ MVM：必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。 19. 你们对意见不一的缺陷有三国会议么？ MVM：必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。 20. 所有的缺陷都是由登记的人最后关闭的么？ MVM：Bug应该由Opener关闭。Dev不能私自关闭Bug。 21. 你们的程序员厌恶修改老的代码么？ MVM：厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。 22. 你们项目组有Team Morale Activity么？ MVM：每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。 23. 你们项目组有自己的Logo么？ MVM：要有自己的Logo。至少应该有自己的Codename。 24. 你们的员工有印有公司Logo的T-Shirt么？ MVM：要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。 25. 总经理至少每月参加次项目组会议 MVM：要的。要让team member觉得高层关注这个项目。 26. 你们是给每个Dev开一个分支么？ MVM：反对。Branch的管理以及Merge的工作量太大，而且容易出错。 27. 有人长期不Check-In代码么？ MVM：不可以。对大部分项目来说，最多两三天就应该Check-In。 28. 在Check-In代码时都填写注释了么？ MVM：要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。 29. 有没有设定每天Check-In的最后期限？ MVM：要的，要明确Check-In Deadline。否则会Build Break。 30. 你们能把所有源码一下子编译成安装文件吗？ MVM：要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。
31. 你们的项目组做每日编译么？ MVM：当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。 32. 你们公司有没有积累一个项目风险列表？ MVM：要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。 33. 设计越简单越好 MVM：越简单越好。设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。 34. 尽量利用现有的产品、技术、代码 MVM：千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。 35. 你们会隔一段时间就停下来夯实代码么？ MVM：要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。 36. 你们的项目组每个人都写Daily Report么？ MVM：要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。 37. 你们的项目经理会发出Weekly Report么？ MVM：要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。 38. 你们项目组是否至少每周全体开会一次？ MVM：要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。 39. 你们项目组的会议、讨论都有记录么？ MVM：会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。 40. 其他部门知道你们项目组在干什么么？ MVM：要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。 41. 通过Email进行所有正式沟通 MVM：Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。 42. 为项目组建立多个Mailing Group MVM：如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。 43. 每个人都知道哪里可以找到全部的文档么？ MVM：应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。 44. 你做决定、做变化时，告诉大家原因了么？ MVM：要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。 45. Stay agile and expect change MVM：要这样。需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。
46. 你们有没有专职的软件测试人员？ MVM：要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。 47. 你们的测试有一份总的计划来规定做什么和怎么做么？ MVM：这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。 48. 你是先写Test Case然后再测试的么？ MVM：应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。 49. 你是否会为各种输入组合创建测试用例？ MVM：不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚，你是否有时间去运行那么多test case。 50. 你们的程序员能看到测试用例么？ MVM：要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。 51. 你们是否随便抓一些人来做易用性测试？ MVM：要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了，不方便的永久了也就习惯了。 52. 你对自动测试的期望正确么？ MVM：别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。 53. 你们的性能测试是等所有功能都开发完才做的么？ MVM：不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。 54. 你注意到测试中的杀虫剂效应了么？ MVM：虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。 55. 你们项目组中有人能说出产品的当前整体质量情况么？ MVM：要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。 56. 你们有单元测试么？ MVM：单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了——可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。 57. 你们的程序员是写完代码就扔过墙的么？ MVM：大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。 58. 你们的程序中所有的函数都有输入检查么？ MVM：不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。 59. 产品有统一的错误处理机制和报错界面么？ MVM：要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。 60. 你们有统一的代码书写规范么？ MVM：要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。
61. 你们的每个人都了解项目的商业意义么？ MVM：要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。 62. 产品各部分的界面和操作习惯一致么？ MVM：要这样。要让用户觉得整个程序好像是一个人写出来的那样。 63. 有可以作为宣传亮点的Cool Feature么？ MVM：要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。 64. 尽可能缩短产品的启动时间 MVM：要这样。软件启动时间（Start-Up time）是客户对性能好坏的第一印象。 65. 不要过于注重内在品质而忽视了第一眼的外在印象 MVM：程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。 66. 你们根据详细产品功能说明书做开发么？ MVM：要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。 67. 开始开发和测试之前每个人都仔细审阅功能设计么？ MVM：要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧” 68. 所有人都始终想着The Whole Image么？ MVM：要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。 69. Dev工作的划分是单纯纵向或横向的么？ MVM：不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。 70. 你们的程序员写程序设计说明文档么？ MVM：要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。 71. 你在招人面试时让他写一段程序么？ MVM：要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。 72. 你们有没有技术交流讲座？ MVM：要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。 73. 你们的程序员都能专注于一件事情么？ MVM：要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。 74. 你们的程序员会夸大完成某项工作所需要的时间么？ MVM：会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。 75. 尽量不要用Virtual Heads MVM：最好不要用Virtual Heads。Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对Resource Manager的。
03/05/2006 可爱的 卡巴斯基前几天在调试一个很长时间前写过的一个VBA程序，发现总是莫名其妙的错误，具体症状是，那个程序里有操作本地文件系统的功能，例如检查某个文件夹，如果不存在的话，就自动创建一个等等。不知道怎么回事，总是在这段程序执行时中断或者出错
而在之前，肯定是可以执行的。左想又想，都没有找到原因，当时无奈之下是想了其他的方法避开这个问题
今天，偶尔想起来一个情况，我的电脑上装的杀毒软件是卡巴斯基，里面有一个宏病毒监控的选项，默认情况下是不允许对本地文件系统执行上述的那些操作的
把这个选项关上后，程序又正常运行了
这个保护还是有意义的，只是以后在排除错误的时候，要考虑到杀毒软件的防控选项才行
一不留神，被卡巴斯基忽悠了一把，呵呵
19/07/2005 技术日志转移到博客园通知日前应邀参加OFFICE开发团队，为避免重复（同时自己精力也有限，不可能同时维护两个地方的技术日志），特决定自即日起技术类日志将全部归类到我在博客园的地址。
OFFICE开发应用方兴未艾，虽然现在也有不少的公司和人士在做这方面的事情。但我依然选择了这一个事业，希望通过自己以及更多的人的努力能把OFFICE开发应用推向新的高度。
很喜欢MSN的Space，这里将保存的是我的一些心情，随想。
也希望大家喜欢
04/07/2005 保证你现在和未来不失业的十项IT关键技术一、XML 二、Web Services 三、面向对象编程 四、Java, C++, C#, VB.NET 五、JavaScript 六、Regular Expressions 七、Design Patterns 八、Flash MX 九、Linux/Windows 十、SQL 尾声：培养对技术的好奇心 02/07/2005 我研究的方向结合我自己的情况，个人决定后期几个主要的方向进行努力和加强
1。Excel+Access，Excel+Sql Server整合应用
2。SharePoint Server & Office 整合应用
3。InfoPath & XML应用，深入了解Office 12的特性
4。Visual Basic 2005开发，尤其是研究它所包含的Office开发的部分
5。SPSS专业数据分析
备注：SPSS（Statistics Package For Social Science）是著名的统计分析软件，适用于在自然科学，社会科学等多个领域进行统计分析。
我用的是SPSS 11 FOR Windows
|
|
|
