http://www.msdnwebcast.net/
其中智能客户端系列：http://www.msdnwebcast.net/webcast/1987.aspx
|
||||||
|
利用互动百科的代码一口气搭建了两个百科：射频识别百科:http://baike.ziytek.cn，电缆百科：http://baike.ecable.cn。没事儿就添加个字条玩玩。也算是知识管理吧。 作为传统的Win Form拥护者，我始终认为智能客户端是一个值得替代的方向。相对于Web客户端而言，智能客户端具备更丰富的界面，同时又具备Web分发方便的特征。 http://code.msdn.microsoft.com/SmartClient 此链接还是2007版本的，看来微软搞得有点乱 Smart Client – Composite UI Application Block：http://msdn.microsoft.com/en-us/library/Aa480450 Enterprise Library 4.1-October 2008 http://www.microsoft.com/downloads/details.aspx?familyid=1643758B-2986-47F7-B529-3E41584B6CE5&displaylang=en Version 4.1: http://www.microsoft.com/downloads/details.aspx?FamilyID=1643758b-2986-47f7-b529-3e41584b6ce5&DisplayLang=en Version 4.0 Version 3.1 Caching Application Block. 好不容易从Google blogger上迁移过来，第一件事情就是修改缺省的友好链接（Permalinks）,个人觉得采用Category/Post-Id.aspx这种方式比较好。 今天(2010.04.11)得闲，在Google与baidu上查了一下，居然都还没有收录我的新域名，顺手提交了下，看看几天后能在两个搜索引擎上找到我的文章呢？ 2010.04.12: 同时向Bing(必应)提交了网址:http://cn.bing.com/docs/submit.aspx,只不过搞笑的是,在bing.com中搜索向该站提交网址的信息都是从其他网站来的.有点在肯德基里叫麦当劳外卖的感觉. 查了以前的文章,发现2008年9月9日就有一片文章,<开始博客推广>,只是随着Blogger的关闭,这些都得重新做过了,一声叹息! 4，进度表的结构 按照XPlanner的结构而言，主要有Story和Task，一个进度表包含若干Story，一个Story包含若干Task。对于Story的理解可以是Feature也可以是Case，其粒度比Task大，而Task就是我们所说的在该Case下的若干任务。就我们的经验而言，我比较喜欢按照任务的流程进行划分，比如从需求的确定到写设计文档到编码（当然实际Task的粒度要比这几个词汇的粒度小得多，Task粒度应该小，小到以“小时”为单位，而不是以“天”，这稍后为谈到）。然后一个Task至少应该包含以下几项内容：任务名称、任务内容、其所在的Story、任务的实施者、任务的跟踪者、优先级、计划时间、已使用时间、剩余时间、完成任务的实际使用时间等。但我仍然坚持Task也应该保持简单明了，一是一目了然，二是节约时间，三是防止团队成员的抵触情绪，所以Task中需要填写的字段不亦过多。 5，任务粒度要小 任务的粒度绝对不能大，大的是Story而不是Task。推荐的粒度是按“小时”为单位，而不是按“天”为单位，我的一位同事的不错的经验是将任务细化到4小时或8小时以内，并且尽量保持任务的完整性（意思是说，不应该出现事情刚做一半就下班了的情况），这有利于“每日检入”（Daily Check in）和“每日构建”（Daily Build）。粒度太大很明显的缺点是时间估计的误差很大，如果是一个全新的任务（而不是被你重复过无数次的任务）而给出一个“我大概需要三天”的时间估算的参考意义是不大的。另外，我也有一个失败经验，当我用Outlook的“任务”工具为自己指定一个任务时，如果我仅仅指定某个任务应该在未来3天内完成，那么该任务往往被推迟到第三天才真正开始做，甚至被拖延更长的时间，正确的做法是，即便该任务需要3天，那么应该将该任务拆分成3部分（或更多）然后分配到每一天中去，做到今日事今日毕。 如何撰写一个良好的用户例事（How to write a good user story）按道理讲，用户例事是连接团队日复一日工作与玩家收益的最佳渠道。通常很容易能想象出玩家想在游戏里看到什么（比如，“不管我怎样操作我的角色，我要看到超酷的粒子特效。”）。 另一方面，有些工作的内容不是完全符合用户例事的格式。这些东西是玩家不能直接表达出来的，而是迂回的联系到玩家收益上。 对于项目的后期，团队正在处理大量的备受关注的工作，这时Scrum板子的清晰度会被减少，意味着关系到用户的各种收益的例事不能直观的显现出来。Large Animal的团队发现当一个项目进入到开发阶段后期时，很多用户例事最后看起来越来越像围绕着一系列子任务的“超级任务”。例事，任务，或bug（Stories, tasks, or bugs）在采用敏捷开发模式之前，Large Animal习惯用FogBugz作为任务和bug的共同跟踪工具。尽管这个工具缺乏Scrum的可见性，但是它对于帮助管理大量详细bug报告、减少bug造成的崩溃是非常有效的，特别是在版本处于繁重测试和修订的过程中。 不幸的是，这通常与验证阶段Scrum板上的工作内容重叠。所以，有时会让人觉得很混乱，不知道用哪个工具来跟踪问题。时间估计（Time estimation）有些事实是不能逃避的，那就是精确估计问题解决方案所花费的时间是很困难的，不论是代码、游戏性还是UI设计。虽然敏捷开发模式使Large Animal的开发过程更舒适、更为可预测，但是估计任务的准确时间仍然是一个进行中的挑战。 原帖：http://www.cnblogs.com/HanN1984/archive/2007/08/09/840575.html一、Ticket系统简介Ticket系统是Trac中关于项目管理的一个重要单元，它是一个简单有效的版本差异和Bug跟踪系统。在项目开发过程中出现的任何问题，都可以用一个Ticket来标识，例如Bug，项目计划，功能改进，项目建议，Todo等等，都可以写成一个Ticket，开发人员通过访问查看Ticket系统，可以及时的了解到项目进度，有待解决的地方等等每个Ticket都可以被修改和说明（Description属性），并说明这个Ticket是Bug还是项目建议还是其他什么（Type属性），指派由哪个人对这个Ticket负责（Assigned to/Owner属性），设定Ticket的优先级（Priority属性），设定Ticket的最终完成时间（Milestone属性），设定这个Ticket属于哪个模块（Component属性）。二、Ticket创建，及其各个属性详解点击“New Ticket”，进入“New Ticket”页面，在这里我们可以生成一个新的Ticket，生成新的Ticket时，我们需要填写Ticket必须的一些属性：1.short summary:这个属性是Ticket的标识，可以理解为Ticket的名称，可以根据情况随意填写；2.Type：这个属性表明你所要创建的Ticket是什么类型，Trac系统中默认包含三种Type，分别是defect，enhancement和task，我们也可以通过WebAdmin或者TracAdmin来增减，或修改Type，以符合我们的需求；3.Full Description:这是对所要创建的Ticket的描述，用户以后可以根据一个Ticket的Type和Description属性，来判断这个Ticket的目的；4.Priority：设定所要创建的Ticket的优先级，Trac系统中默认五种优先级类别，分别为blocker，critical，major，minor和trivial，我们也可以通过WebAdmin或者TracAdmin来增减，或修改优先级类别，以符合我们的需求；5.Milestone：直译过来的意思是里程碑，我们可以理解为一个项目的不同阶段，一个Milestone包含一个名称和时间，其中时间即为项目中这个阶段的预计完结时间，我们通过设定这个属性，来表明所要创建的Ticket属于哪个Milestone，属于项目的哪个阶段，该在哪个时间之前完成，Trac系统中默认有四个Milestone，我们可以通过WebAdmin或者TracAdmin来增减修改它，以符合我们的要求；6.Component：这个属性可以理解为一个项目的层或者模块，通过这个属性，可以设定我们所要创建的Ticket属于项目的哪个模块，或者说属于哪个层级，这样便于分类，便于划分任务，Trac系统默认有两个Component，我们可以通过WebAdmin或者TracAdmin来增减修改它，以符合我们的要求；7.Version：用来说明当前所要创建的Ticket该归结于项目的哪个版本，这个主要在项目的多个版本同时开发时，例如项目1.0版本正在维护，同时也在进行项目2.0版本的研发。Trac系统默认两个Version，我们可以通过WebAdmin或者TracAdmin来增减修改它，以符合我们的要求；8.Keywords：用来标记所要创建的Ticket，在Ticket搜索，或者生成Ticket报告时会有用；9.Assign to：说明这个Ticket归谁负责；10.Cc：这是一个使用逗号隔开的字符串列表，表明当这个Ticket被修改时所要Email通知的地址，格式如shengf@star-net.cn,yaoq@star-net.cn,cjl@star-net.cn,hann@star-net.cn三、查看Ticket1.点击“View Tickets”，进入Ticket查看页面，在这个页面中，会罗列出8个Report，如下所示：以下!!!!中的内容为注释（1） Active Tickets !!列出所有Active的Ticket!!（2） Active Tickets by Version !!根据Version列出所有Active的Ticket!!（3） Active Tickets by Milestone !!根据Milestone列出所有Active的Ticket!!（4） Assigned, Active Tickets by Owner !!根据Owner列出所有已被assign的Ticket!!（5） Assigned, Active Tickets by Owner (Full Description) !!同上，只是多出Description!!（6） All Tickets By Milestone (Including closed) !!根据Milestone列出所有的Ticket，包括已经Close的Ticket!!（7） My Tickets !!我的Ticket!!（8） Active Tickets, Mine first !!列出所有Active的Ticket，我的放在最前面!!2.可以点击页面下部的“Create new Report”按钮，利用Sql语句，生成一个新的ReportTrac底层使用PostgreSQL数据库来实现的数据保存，所以Report的生成应该是利用SQL语句去查询数据库来实现的，由于本次调研主要针对Ticket系统的流程和功能，所以暂时没有去了解Report的生成方式，以后有待完善。3.点击“Active Tickets”，可以看到一个Ticket列表，点击任意一个，可以查看详细信息（1）在点开后的页面，我们可以看到这个Ticket的详细信息，例如这个Ticket由谁提出，由谁负责，优先级，最后期限，所属模块，所属版本，关键字，Email通知列表等等；（2）在页面下面，我们可以对这个Ticket进行修改，可以修改Summary，Tpye，Description，Reporter，Priority，Milestone，Component，Version，Keywords，Cc字段，修改时，需要添加一个Comment，用于描述本次修改的内容；（3）我们也可以在页面的最底部，选择我们所要进行操作的类型，具体可以进行那些操作，则跟Ticket当前状态有关，如果一个Ticket为New状态时，可以进行如下四种操作：（i） leave as [...] 让VS 2008支持Subversion 10个免费SVN:http://www.straw-dogs.co.uk/09/20/6-free-svn-project-hosting-services/ Hosted-projects.com 看起来更实惠，但问题是，好像只是两个人在干活，服务器也只有两台： Plan Developer 万象科技:http://www.88soft.cn/ 关于SQL Server 2005你应该知道的13件事情。 SQL Server 2005 Express——其作用是代替微软SQL Server桌面引擎（Microsoft SQL Server Desktop Engine，MSDE）。SQL Server 2005 Express可以用于自由发布，并与SQL Server使用同样的关系数据库核心引擎。不同的是它并不像MSDE一样使用查询管理器。仅有的限制是一个CPU，1G的内存和每个数据库4G的存储空间。 SQL Server 2005——工作组版不是自由发布的。它的设计着眼点在于服务器消息块协议（SMB）和分部门解决方案。在量化性能上，它更优于SQL Server 2005 Express，并能提供关系数据库的支持，只是缺少分析服务。工作组版限用于两个CPU，3G内存，数据库大小不限。 2. 新的子系统 整合服务——与之前负责此功能的DTS相比，速度快600%。SQL Server整合服务是拥有强大的工作流控制能力的企业级ETL平台。 提醒服务——可以提供搭建自定义提醒程序的应用框架。 3.整合全新的.NET Framework 3. 新的数据类型 SQL Server 2005中添加了两种新的数据类型：xml和varbinary(max)。 4. 新的点对点事务型映射 SQL Server [...] |
||||||
|
Copyright © 2012 Dragonfly的博客 - All Rights Reserved |
||||||