摘要： 望DUDU见谅，暂放首页一天，呵呵:) 就在昨天(2007.12.24), 公司的discuz!nt 2.0 正式版终于开源了，下面就是链接(开源页面): http://www.discuznt.com/opensource.html 阅读全文

摘要： 注:如果您觉得音乐太吵,可以适当调整一下音量,但不建议关闭.因为只有伴随着这种力量,读本文时才是最出火的! 在易中天品三国第二十八回“借刀杀人”一集中，一个让后世文人不断追捧的狂人形象--“弥衡”闪亮登场。虽然易中天先生只用了20多分钟来讲述弥衡的“光辉”事迹，甚至可以说弥衡的登场一直是伴随着骂声进行的，正所谓“将骂人进行到底!” 也许正是这种“口腔体操”才让他有别于那些“老谋深算”的谋士之流。 而另一个让后人们津津乐道的就是“击鼓骂曹”了。甚至在郭德纲《歪批三国》这个相声作品中也给弥衡在当今社会上找了一个相当前卫的职业--“人体模特”（因为弥衡脱光衣服之后击鼓骂曹，这可能是最早的行为艺术吧）。 说到这里有必要引用易中天先生的话来介绍一下，身为一名“鼓吏”（相当于鼓手）弥衡在曹操手下的精彩演出： 阅读全文

摘要： 作为产品中的一大特色，模板机制一经推出，就引来了大家特别是站长们的关注。但它所饱受的风风雨雨也成了那时不少人关注的话题。而今天本人将结合在产品组中的开发经历，介绍一下模板机制在设计使用时的一些体会心得。希望借此陋文，使模板机制揭开“神秘”面纱，为大家在实际设计中提供一些有价值的参考和建议。 好了，开始今天的话题:) 阅读全文

摘要： 如果大家从官方下载2.0正式版的DLL程序集中会从里面找到discuz.config这个DLL文件。通过reflector 反射加载这个程序集后，后从中找到一些从类名称上非常相似且有一定规律（格式）的类。它们是： 全局配置类 阅读全文

摘要：在2007年里，有三件事对我来说是很重要的: 一是我LP给我生了个猪宝宝，小家伙自降生之日就给我们以及周围的人带来了无限的快乐，当然也有了更多的洗洗涮涮。二是我们的产品顺利推出了 2.0, 可以说这个版本的顺序发布，给2007年一年的忙碌工作划出了一个“阶段性成果”，当然其中的风风雨雨也让我变得更加成熟。三是有时间在园子里写了一些BLOG，认为了更多的朋友，同时也扩展了知识面和思考问题的方式。 阅读全文

摘要： 早在“关于三国谋士之IT从业可行性报告”中就曾经说过“郭嘉”是一个很会给自己找老板的谋士。其实在三国中，还有几位很有代表性的谋士，他们给自己找老板的本事也非常强。这里不妨简要介绍一下，希望能给大家在工作提供一些参考:) 首先聊一聊“贾诩”这个在三国早期谋士圈中重量级的人物。 阅读全文

摘要： 前两天在整理电脑资料时，发现这两个已被打入"冷宫"的控件。运行效果如下: 阅读全文

摘要： 关键设计复核 （CDR）指在确保（时序图和相应的类图指定的）详细设计的“如何”同用例指定的“什么”完全一致。 CDR还需要从多种不同的角度复核详细设计的质量，这些角度包括模块性，类的内聚性，对象之间的耦合性以及被子统称为“OO优良”的其他度量标准。在这个阶段，要求所有设计人员和开发人员都必须参加。而在 PDR（初步设计复核：本系列第五篇）之后，客户的主动参与就不再受到欢迎了。除非他老人家是拥有详细设计方面的丰富专业知识，否则就该礼貌的劝退客户直到我们根据行为描述对构建的系统进行测试时再让客户参与进来。而这一阶段在ICONIX方法中的位置如下所示： 阅读全文

摘要： 声明: 本文是本人在“头脑发热”下的产场，纯属个人观点，因些有些比喻和语气偏激再所难免，如果认为这是一篇垃圾，那我只能对给您的思想所带来的“精神污染”和侵害深表报歉了:) 这些年一直在Windows平台上做开发，坐在Microsoft这只船上，总体上感觉是自己越来越懒了，什么都想去用现成的，如果有什么问题，基本上都会去MSDN，BAIDU或 GOOGLE上SEARCH一把，看有没有很合口味的，如果没有自己才真正动手写些东西。微软在给我们提供各种开发工具和不断更新并日益强大的.net平台的同时，也让自己变成了一个瘾君子，除了C# 和.NET框架之外，已无兴趣和耐性再去过多涉略其它领域的技术了。遥想当年学习ACE的兴趣和看JAVA编程思想的兴奋，现在只想感叹.net这边新东东层出不穷，而再去研究和学习JAVA开源框架的时间已所剩无已。而更让我强烈感受到的就是微软已变得越来越像是个厨子，特别是一个善于做自助餐的厨子。而我以前还喜欢亲自下厨（写一些核心类和方法）的“瘾”已越来越少，剩下的就只是想吃现成东西的欲望了。 阅读全文

摘要： 最近听了易中天先生的品三国，对其中的“海纳百川（说曹操）和天下归心”这两集，给我留下了非常深刻的印象。 易中天给曹操用人之道的总结是：实事求是、唯才是举、不拘一格、来者不拒。在此前提下，曹操妥善地处理了五种关系。 曹操的用人政策一： 名至实归　更重实际 曹操的用人政策二： 德才兼备　唯才是举 曹操的用人政策三： 重用清官　不避小贪 曹操的用人政策四： 招降纳叛　尽释前嫌 曹操的用人政策五： 抓大放小　不拘小节 其中的第四和第五个用人政策是今天文章的重点，主要内容也是围绕这两个政策展开的： 阅读全文

摘要： 在前几篇文章中，我们分别进行了域模型和用例建模，并使用 Robustness工具进一步分析验证了相应用例的处理流程，并在相应模型（域模型）的基础上，通过Robustness方法引入相关的边界对象，控制对象（控制器），并更新了相应域模型中类的属性（字段）。下面就可以进入到交互建模阶段了。如下图: 作为交互建模本身，就是要通过寻找对象之间的交互关系，进而进行方法（操作或行为）分配。 正所谓“只有在所有的用例为所有事件进程建立了交互建模式之后，才可以确定已经发现系统所需的每个对象所扮演的角色，以及它们的责任。” ----Ivar Jacobson 而上面的那句话换言之就是仅当为每一个用例的所有基本流程和所有分支流程绘制时序图后，才能确保发现了每一个对象的所有职责。 阅读全文

摘要： 这一篇文章的内容有些对不住大家了。因为公司正在准备发布新产品(Discuz!NT2.0)，大家的心思全在产品上，本人构思内容和写作的时间几乎没有了，因此就偷了个懒，把书中认为很有必要让大家了解的内容简单的抄上来。同时因为这一章主要的内容都是进行相应的用例文本和健壮性图的检查，以及更新域模型（使之逐步向详细类图逼进），所以如果大家感兴趣的话，可以找几个人一起研究一下，相信大家一定会有所收获的。最后我也希望在产品正式发布之后能够回过头来有时间进一步完善和补充相应的内容。再次向大家致歉了:( 好了，开始正文吧。 阅读全文

摘要： 在前三章中通过（问题域）建模和用例分析之后，在许多的UML书中可能接下来就要进行时序图和协同图的绘制了。但是问题好像还没那么简单，因为这里有一条鸿沟还没有跨过去，正如下图所示： 在我刚学开始学习 UML时，在拿到用例文本时要去画时序图总感觉有些别扭，不知如何才能将文本中的意思完全用图的形式表达出来，总是感觉分析出来的文本中缺了一些很重要的东西, 而这些被丢掉的对象最终可能会导致无法绘制时序图，但又找不出用例文本中到底还有什么东西被遗漏，最终导致设计瘫痪。后来从网上搜索到的一些文章里发现了这种方法(robustness), 在看了半天之后感觉找到了方向和窍门:) 阅读全文

摘要： 可能最近听易中天的“品三国”听得有些“走火入魔”，再加上本是对三国一直是个“门外汉”，一直以来只知道三国谋士里的诸葛亮，鲁肃，陆逊，庞统。所以才会在听到诸如：郭嘉，陈宫，贾诩（易中天非常欣赏的一位谋士）田丰，荀彧，徐庶，沮授，许攸，张昭等人的“事迹”之后深受感染。才能想应该写点什么以回味一下这些人的“功德”和“品行”。 另外因为这些人都自知非常聪明，而IT人员（特别是程序员）也基本上是一群自认为“聪明”的家伙。所幸就让这些人在IT行业来一次再就业，看看他们到底能够有何作为。 1. 鲁肃 诸葛亮 应聘 软件架构师 阅读全文

摘要： 需求复核旨在确保用例和域模型同时满足客户的功能性需求。同时确保客户知道开发小组将根据这些需求做何种设计。同时它也是系统分析阶段的一个里程碑(milestone)。 这一阶段在ICONIX方法中的位置如下图： 阅读全文

摘要： 在上一篇文章中我们了解并进行了域建模，换言之我们有了一个好的开始，起码开发人员对自己要开发的软件已有了初步的认识，且也得到了进行交流时可以使用的术语表。 本章将会在前一篇的基本上进一步阐述使用ICONIX方法实践用例建模，同样在文章的最后还会有在这个阶段最容易犯的10个错误，以给大家提醒或在分析过程中进行参照。 本文在ICONIX方法中所处的位置如下图（红圈标记的地方） 阅读全文

摘要： ICONIX过程的规模大概在重量级Rational Unified Process (RUP)和轻量纺的极限编程之间(XP)。同时这种方法也是用例驱动，但不需要RUP使用记录延续到表中带来的大量开销。和XP一样，它相对较小，不像XP那样摒弃了分析和设计过程。因此，有助于使用UML，同时对需求进行跟踪。该过程遵循Ivar Jacobson的用例驱动思想，能够获得有形，具体，易于理解的用例，开发小组可以使用这个用例来驱动开发工作。 该方法是迭代，循序渐进同时足够的轻量级。因为它遵循20%原则，即用UML中20%的图表来完成设计中80%的需求。从这个角度讲倒是满符合中国国情的，因为具我观察不少国内软件公司都不是肯花心思和时间在设计架构上。 阅读全文

摘要： 最近园子里的book.save()讨论已让我看的有些厌恶了。同时也希望大家不要再在这个问题上火上浇油了。有关这个问题在别的技术社区早就有过讨论(不要吃人啃过的馍)，最后又怎么样呢？ 还是希望大家务实点好（干好手头的事等）。 从这些计论中发现大家在不厌其烦的寻找所谓的银弹，但具我了解这个问题可能无解。必定软件开发设计要有一定的行业背景（应用场景）。而离开这些条件的话，空谈这个问题犹如盲目人摸象（如果把上面的问题放到不同背景下都会有不同的解答）。 另外我担心的是争论到背后，不仅没找到所谓银弹，可能大家倒学会扯蛋了。当然如果是在春晚赵本山小品中的 "扯蛋" 的话，倒还说的过去，必定那位秘书找到了解决问题（用户需求）的方法，因为王八蛋确实不好用筷子夹。所以这种"扯蛋"可以被看成是解决方案。但不是这样的话，就太浪费大家的精力和时间了。 最后还是希望大家正确对待这个问题，不要给它过多不该有的关注:) 希望DUDU暂实不要将该贴从首页移走!!! 而那些想 阅读全文

摘要： 设计前提：早在RC1之前聚合功能还比较弱化时，系统结构比较简单，只用了一个website页面就聚集了大部分的功能调用。因为快速完成之后陆续又加入了不少新特性，导致类的名称(website) 与所聚合提供的功能已完全不相符 (代码已过度膨胀) ，所以重构的任务已变得非常紧迫了。但用什么方式，因为系统聚合时是按内容类型聚合功能页面并决定显示方式的。而这里的内容类型在大概可分为（论坛主题，相册，图片，空间文章（及最新回复）等）。为了尽量简化系统设计时的复杂度，这里只按内容所属的大类（论坛，空间，相册, 图片）来进行简单的初步规划，这就产生出来上面图片所说的类AggregationData,SpaceAggregationData, AlbumAggregationData.cs,ForumAggregationData.cs ...... 阅读全文