如何转换NUNIT生成的XML测试结果到可读性的HTML

在网上搜了一大圈，还是从中国的一个程序员博客里面搜到了解决方案。
尽管生成的测试报告界面非常寒碜，但是总比没有好。

http://blog.csdn.net/andyhong110/archive/2010/07/28/5770768.aspx

插件下载：
https://launchpad.net/nunit-results/1.1/

"Mother China" Music Video now is on CNN

Sea turtles (haigui) return to China with a music video


Everything is a pun in China and overseas Chinese aren’t exempt from the language exercise. Called haigui (海归 or 海龟, sea turtle which has the same pronunciation), ethnic Chinese's successes, fears and experiences upon returning to China after a time abroad, has been documented over the past few decades.

Now a recent video made by Reno Studios with a song by two haigui living in the U.S. has caught on online. ChinaSMACK explains that, “The song is based on the writers’ real story of returning to China, with a complexity of excitement and frustration, optimism and disappointment, hope and hopeless.”

Here’s the translation of the song, and as ChinaSMACK points out, 妈呀 (Mother) is a pun that can be used for surprise, excitement or frustration -- much like the haigui writers' journey.

妈呀，中国 - 视觉加强修订第三版

本视频为修订三版，对个别图片作了微量调整。

This is the vision enhance version of "Mother, China". Hope you all like it.。

作为一个旅加华人，这首原创歌曲说出了我10年海外生活的心声，我相信，也说出了在北 美和世界各地海外华人的心声。

歌词:
(T) - Timothy
(F) - 我爱微风
(C) - 合唱

(music)

(T)我生在新中国，我长在红旗下
(F)我带过红领巾，我爱国如爱家
(T)十年寒窗苦，我好不容易进清华
(F)我成绩不算差，(C)可我户口落不下

(F)阴差又阳错，我出国象出家
(T)为了养家糊口，我得赶紧办绿卡
(F)出国护照难拿，回国却偏要VISA
(C)入了外国籍，但我做梦都说中国话

(T)我的大中国，(F)我的大华夏
(T)尽管我在外飘泊，(F)总是把你牵挂
(T)我的大中国，(F)我的大华夏
(C)风里雨里同度过，我只认你这个妈

(F)我曾经爱闯荡，现在却很想家
(T)爸爸已经去世，家里就剩妈妈
(F)我很想做海归，怕你嫌我年纪大
(T)可是你看那谁，他八十二能娶二十八

(music)

(T)在国外住得越久，我心里就越放不下
(F)好不容易请了假，我兴冲冲地飞回家 (T)北京欢迎你
(T)看着立交桥发傻，我迷失在高楼大厦
(F)江河流着黑水，天空下着黄沙 (T)妈呀，这也算是晴天啊

(T)老同学一见面，感觉亲如一家 (F)哥们，喝酒！
(F)可陌生人对我，有时冷眼有时骂 (T)嘿！你长不长眼啊
(T)车比纽约还多，路比伦敦要大 (F)那当然
(F)到处奔驰宝马，坐进去那真叫害怕 (F)找死啊你！

(C)不管怎么样，是你把我养大
即使跑遍了全世界，也忘不了这个家
只希望你更好，原谅我有时乱说话
儿女发点牢骚，当妈的根本不用怕


感谢旅美华人：我爱微风&Timothy的音乐原创。
作为一个旅加华人，这首原创歌曲说出了我10年海外生活的心声，我相信，也说出了在北 美和世界各地海外华人的心声。

Beijing Welcome You

北京欢迎你 歌词
词：林夕 曲：小柯 制作：陈少琪 小柯 余秉翰
片头：日出、捏面人、挂风筝、刷年画、太极拳、太庙
迎接另一个晨曦 带来全新空气——陈天佳（正阳门箭楼上，背景为正阳门城楼）
气息改变情味不变 茶香飘满情谊——刘欢（鸟巢）
我家大门常打开 开放怀抱等你——那英（德胜门箭楼，2008年4月13日）
拥抱过就有了默契 你会爱上这里——孙燕姿（北海公园白塔，2008年4月2日）
不管远近都是客人请不用客气——孙悦（普渡寺，2008年4月7日）
相约好了在一起 我们欢迎你——王力宏（中华世纪坛、书法，2008年3月20日）
我家种着万年青 开放每段传奇——韩红（北京大学未名湖畔博雅塔）
为传统的土壤播种 为你留下回忆——周华健（太庙，2008年4月8日）
陌生熟悉都是客人请不用拘礼——梁咏琪（国子监琉璃牌坊）
第几次来没关系 有太多话题——羽泉（皮影戏）
北京欢迎你 为你开天辟地——成龙（八达岭长城，2008年4月3日）
流动中的魅力充满着朝气——任贤齐（琉璃厂北京画店、折扇）
北京欢迎你 在太阳下分享呼吸——蔡依林（奥林匹克水上公园）
在黄土地刷新成绩——孙楠（国家大剧院）
我家大门常打开 开怀容纳天地——周笔畅（水立方）
岁月绽放青春笑容 迎接这个日期——韦唯（糊风筝）
天大地大都是朋友请不用客气——黄晓明（奥林匹克水上公园，2008年4月13日）
画意诗情带笑意 只为等待你——韩庚（画京剧脸谱）
北京欢迎你 像音乐感动你——汪峰（古观象台）
让我们都加油去超越自己——莫文蔚（社稷坛(中山公园)五色土）
北京欢迎你 有梦想谁都了不起——谭晶（四合院模型）
有勇气就会有奇迹——陈奕迅（天坛坛门）
北京欢迎你 为你开天辟地——阎维文（五棵松体育馆）
流动中的魅力充满着朝气——戴玉强（北京孔庙大成门）
北京欢迎你 在太阳下分享呼吸——王霞 李双松（什刹海荷花市场）
在黄土地刷新成绩——廖昌永（首都博物馆）
北京欢迎你 像音乐感动你——林依轮（茶道）
让我们都加油去超越自己——张娜拉（鼓楼上，背景为钟楼）
北京欢迎你 有梦想谁都了不起——林俊杰（湖广会馆大戏楼）
有勇气就会有奇迹——阿杜（湖广会馆大戏楼）
京剧：北京欢迎你，啊啊啊霍霍霍哈哈哈
我家大门常打开 开放怀抱等你——容祖儿（故宫）
拥抱过就有了默契 你会爱上这里——李宇春（火锅）
不管远近都是客人请不用客气——黄大炜（拨浪鼓）
相约好了在一起 我们欢迎你——陈坤（福到）
北京欢迎你 为你开天辟地——谢霆锋（故宫）
流动中的魅力充满着朝气——韩磊
北京欢迎你 在太阳下分享呼吸——徐若瑄（世贸天阶，2008年4月7日）
在黄土地刷新成绩——费翔
片中：长城、天安门、天坛祈年殿、九龙壁、故宫三大殿、抖空竹、长嘴壶茶艺、北京烤鸭、拉面、首都机场、北京城铁、立交桥、体育场馆
我家大门常打开 开怀容纳天地——汤灿（刺绣）
岁月绽放青春笑容 迎接这个日期——林志玲（故宫午门） 张梓琳（包饺子）
天大地大都是朋友请不用客气——张靓颖（剪纸）
画意诗情带笑意 只为等待你——许茹芸（浇花） 伍思凯 （瓷器）
北京欢迎你 像音乐感动你——杨坤（画桌前） 范玮琪（中央电视塔）
让我们都加油去超越自己——游鸿明 腾格尔 黄大炜 满文军 纪敏佳（老北京四合院）周晓欧（书法）
北京欢迎你 有梦想谁都了不起——沙宝亮（瓷器）
有勇气就会有奇迹——金海心 何润东（中央电视塔）
北京欢迎你 为你开天辟地——飞儿（北海公园五龙亭） 庞龙
流动中的魅力充满着朝气——李玉刚（国家体育馆）吴克群（老北京四合院）
北京欢迎你 在太阳下分享呼吸——5566（白塔寺） 胡彦斌 （老北京四合院）
在黄土地刷新成绩——刀郎（老北京四合院）
北京欢迎你 像音乐感动你——纪敏佳 屠洪刚 吴彤（老北京四合院）
让我们都加油去超越自己——郭容 刘耕宏（老北京四合院）
北京欢迎你 有梦想谁都了不起——金莎 苏醒 韦嘉（老北京四合院）
有勇气就会有奇迹——付丽珊 黄征 房祖名（老北京四合院）
北京欢迎你 有梦想谁都了不起——全体群唱
有勇气就会有奇迹——全体群唱
北京欢迎你 有梦想谁都了不起——全体群唱
有勇气就会有奇迹——全体群唱

SQL Server编程必知必会

http://book.51cto.com/art/200901/106712.htm

Agile Analysis

http://www.agilemodeling.com/essays/agileAnalysis.htm

Agile Analysis

1. What is Analysis?
The purpose of analysis is to understand what will be built, why it should be built, how much it will likely cost to build (estimation), and in what order it should be built (prioritization). This is similar to requirements elicitation, the purpose of which is to determine what your users want to have built. The main difference is that the focus of requirements gathering is on understanding your users and their potential usage of the system, whereas the focus of analysis shifts to understanding the system itself and exploring the details of the problem domain. Another way to look at analysis is that it represents the middle ground between requirements and design, the process by which your mindset shifts from what needs to be built to how it will be built.

2. What is Agile Analysis?
Let’s begin by describing what agile analysis isn’t:
It isn’t a phase in the lifecycle of your project
It isn’t a task on your project schedule
It isn’t a means unto itself
What is agile analysis? From the previous discussion of what an agile business system analyst does, your agile analysis efforts should exhibit the following traits:
Agile analysis should be communication rich. Agile developers prefer warm communication techniques such as face-to-face discussion and video conferencing over cold techniques such as documentation and email, as described in the Communication article. Agile developers prefer to work as closely as possible to their project stakeholders, following AM’s Active Stakeholder Participation practice wherever possible.
Agile analysis is highly iterative. As Martin (2002) points out analysis and design activities both rely on each other: estimating is part of analysis yet that relies on some design being performed to identify how something could be implemented and your design efforts rely on sufficient analysis being performed to define what needs to be built. Hence analysis is iterative.
Agile analysis is incremental. Martin (2002) also correctly points out that agile analysis is incremental, that you don’t need to build systems all in one go. This philosophy supports the incremental approach favored by common agile software processes where the work is broken done into small, achievable “chunks” of functionality. These chunks should be implementable within a short period of time, often as little as hours or days.
Agile analysis explores and illuminates the problem space. Your primary goal is to identify and understand what your project stakeholders need of your system. Furthermore, this information needs to be communicated to everyone involved with the project, including both developers and stakeholders. This promotes understanding of, and agreement with, the overall vision of your project.
Agile analysis includes estimation and prioritization of requirements. It is during estimation and prioritization of requirements where software development becomes “real” for project stakeholders. It is very easy to say that you want something but much hard to agree to a price for it, let alone to trade it off for something that is immediately more important to you.
Agile analysis results in artifacts that are just good enough. If any artifacts are created at all as the result of your agile analysis (you’ll be following the AM practice Discard Temporary Models after all) they should be either agile models or agile documents. Such artifacts are typically far from perfect, they just barely fulfill their purpose and no more.
Here is my definition for agile analysis:
Agile analysis is highly evolutionary and collaborative process where developers and project stakeholders actively work together on a just-in-time (JIT) basis to understand the domain, to identify what needs to be built, to estimate that functionality, to prioritize the functionality, and in the process optionally producing artifacts that are just barely good enough.

3. Analysis Through the Lifecycle
Figure 1 depicts the lifecycle of Agile Model Driven Development (AMDD). During "iteration 0", the first iteration of an agile project, you need to get your project organized and going in the right direction. Part of that effort is the initial envisioning of the requirements and the architecture so that you are able to answer critical questions about the scope, cost, schedule, and technical strategy of your project. Details about the business domain are identified on a just-in-time (JIT) basis during iterations via initial iteration modeling at the beginning of each iteration or by modeling storming throughout the iteration. Analysis is so important to agilists that we do it every day.

4. Some Potential Analysis Models
Are the artifacts created taking an agile approach to analysis any different than the ones created as the result of traditional analysis? In a way they are. They are in fact the same types of artifacts, a use case diagram is a use case diagram after all, but the way in which they are created are different. The artifacts are created following the principles and practices of AM, they are just barely good enough and are often discarded so as to travel light.
Table 1 lists common artifacts used during analysis modeling and suggests a simple tool with which you could create such an artifact. It is interesting to note that this list is meant to be representative, a more thorough list is presented in the article Artifacts for Agile Modeling and in the book Agile Modeling.
Table 1. Candidate artifacts for analysis modeling.
Artifact
Simple Tool
Description
Activity Diagram
Whiteboard
UML activity diagrams are used during analysis modeling to explore the logic of a usage scenario (see below), system use case, or the flow of logic of a business process. In many ways activity diagrams are the object-oriented equivalent of flow charts and data-flow diagrams (DFDs).
Class Diagram
Whiteboard
Class diagrams show the classes of the system, their inter-relationships (including inheritance, aggregation, and association), and the operations and attributes of the classes. During analysis you can use class diagrams to represent your conceptual model which depict your detailed understanding of the problem space for your system.
Constraint definition
Index card
A constraint is a restriction on the degree of freedom you have in providing a solution. Constraints are effectively global requirements for your project.
CRC model
Index cards
A Class Responsibility Collaborator (CRC) model is a collection of standard index cards, each of which have been divided into three sections, indicating the name of the class, the responsibilities of the class, and the collaborators of the class. Like class diagrams, CRC models are used during analysis modeling for conceptual modeling.
Data flow diagram (DFD)
Whiteboard
A data-flow diagram (DFD) shows the movement of data within a system between processes, entities, and data stores. When analysis modeling a DFD can be used to model the existing and/or proposed business processes that your system will support.
Entity/Relationship (E/R) diagram (data diagram)
Whiteboard
E/R diagrams show the main entities, their data attributes, and the relationships between those entities. Like class diagrams E/R diagrams can be used for conceptual modeling, in many ways E/R diagrams can be thought of as a subset of class diagrams.
Flow chart
Whiteboard
Flow charts are used in a similar manner to activity diagrams.
Robustness diagrams
Whiteboard
Robustness diagrams can be used to analyze usage scenarios to identify candidate classes and major user interface elements (screens, reports, ...).
Sequence diagram
Whiteboard
Sequence diagrams are used to model the logic of usage scenarios. Sequence diagrams model the flow of logic within your system in a visual manner, enabling you to both explore and validate your logic.
State chart diagram
Whiteboard
State chart diagrams depict the various states, and the transitions between those states, that an entity exhibits. During analysis modeling state chart diagrams are used to explore the lifecycle of an entity that exhibits complex behavior.
System use case
Paper
A use case is a sequence of actions that provide a measurable value to an actor. A system use case includes high-level implementation decisions in it. For example, a system use case will refer to specific user interface components – such as screens, HTML pages, or reports. System use cases will also reflect fundamental architectural decisions, such as the use of ATMs versus cell phones to access your bank account.
UI prototype
Whiteboard
A user interface (UI) prototype models the user interface of your system. As a part of analysis modeling it enables you to explore the problem space that your system addresses in a manner that your project stakeholders understand. Remember, the user interface is the system to most people.
Usage scenario
Index card
A usage scenario is exactly what its name indicates – the description of a potential way that your system is used.
Use case diagram
Whiteboard
The use-case diagram depicts a collection of use cases, actors, their associations, and optionally a system boundary box. When analysis modeling a use case diagram can be used to depict the business functionality, at a high-level, that your system will support. It can also be used to depict the scope of the various releases of your system via the use of color or system boundary boxes.

5. Rethinking the Role of Analysts
Analysis is a very important activity on any software development project, regardless of paradigm. It is an organizational design decision to define what roles you will have and what those roles will do. In traditional development there is often someone(s) in the role of analyst, and some organizations even choose to distinguish between analyst types and will have system analysts (SAs), business analysts (BAs), business system analysts (BSAs), data analysts, process analysts, and so on. In agile development we make different organizational design decisions. So, although we still perform analysis we haven't made the decision to have someone in that specific role.
If you are an existing BA, here are a few strategies which you may want to consider when moving to agile software development:
Recognize that agile teams are made up of generalizing specialists instead of specialists (such as analysts). Your analysis skills are valuable, and are clearly a good start, but you need to be able to do more. Be prepared to work closely with other team members to help transfer your skills to them and to pick up new skills from them.
A business analyst, particularly one from the business side, may take on the role of stakeholder/customer/product owner on an agile project, representing the stakeholder community throughout the project (see Figure 2). They may also lead an initial requirements envisioning effort during Iteration 0.
For more details, see the article Rethinking the Role of Business Analysts.


6. Conclusion
The nature of analysis has changed. Several decades ago analysis was seen as a transformational process within a serial project lifecycle. With the rising popularity of object-orientation in the 1980s and 1990s analysis was soon seen as part of an iterative and incremental process, and in the new millennia the nature of analysis is transforming once again. Today analysis is better envisioned as a highly collaborative, iterative, and incremental endeavor involving both developers and stakeholders. The evolution of the analysis process necessitates an evolution in the way that business system analysts (BSAs) work, and in many situations this role arguably disappears in favor of developers who are generalizing specialists.

7. Acknowledgements
I’d like to acknowledge the input on the Agile Modeling mailing list of the following people: James Bielak, Adam Geras, Ron Jeffries, Kent J. McDonald, Les Munday, Paul Oldfield, Stephen Palmer, Tom Pardee, Dave Rooney, Gabriel Tanase, and Paul Tiseo.

8. Recommended Resources
Active Stakeholder Participation
Agile Business Analysis (Interview with ModernAnalyst)
Agile Requirements
Agile Requirements Best Practices
Agile Requirements Change Management
Agile Software Development and Business Analysis (Requirements Network, membership required)
Best Practices for Agile/Lean Documentation
Comparing the Various Approaches to Modeling in Software Development
Development Phases Examined: Why Requirements, Analysis and Design No Longer Make Sense
Document Late: An Agile Best Practice
Examining the "Big Requirements Up Front (BRUF)" Approach
The "Flexible Features Split" Pattern
Inclusive Models
Initial High-Level Architectural Envisioning
Initial High-Level Requirements Envisioning
Iteration Modeling
Is the BA an Endangered Species With The Growth of Agile? (Craig Brown)
Model a Bit Ahead
The "One Truth Above All Else" Anti-Pattern
Overcoming Common Requirements Modeling Challenges
Prioritized Requirements: An Agile Best Practice
Rethinking How You View Requirements Management
Rethinking the Role of Business Analysts

North American Hockey Classifications

We felt that it was necessary to shed some light on this sometimes confusing subject. The truth is that levelling systems for North American Hockey tend to vary somewhat from state to state, province to province, and from town to town. With that said, PlayYourGame.com is excited to bring to you a general outline of minor hockey classifications throughout North America.

Firstly, dependent on age, there are various age groupings (Peewee, Bantam, Midget, etc.) at work within the minor hockey system. At any given age level (we'll use Midget), there are different calibres of play based upon skill and commitment. Generally speaking, travel teams are tiered by skill and age using the AAA/AA/A classification as well as the Minor/Major classification. In a given city or town, there may be AAA, AA, and A teams. If so, AAA would be the highest calibre, AA the second highest, etc. In many cases, a town's travel team will fall under only one of these classifications (AAA, AA, or A). Quite often, a team's classification will be based upon the town's size and the respective pool of players that they have to draw from. For instance, in a city like Detroit, there are teams at the AAA level, while some of the smaller areas surrounding the city might have teams classified at the AA level. In some cases, a hockey association might have a large enough pool to field a team at all travel levels (AAA, AA, and A). In the end, your own team's classification is probably based upon the pool size that your community has to draw from.

On top of the AAA/AA classifications, many communities also use the Major/Minor classification. In most cases, the Major/Minor classification is used to denote a team made mostly of first or second year players in a given age level. So, at the Midget level, first year Midgets would most likely make up the core of the Minor AAA/AA team, while second year Midget players would make up the core of the Major AAA/AA team. Although this isn't always the case, most players will follow this sort of a path. In some cases, players will play "up" to the major level in hopes of stronger competition. With that said, there aren't always enough teams in a given region to make a league at both the minor and major level, so some associations will field minor and major teams that compete in the same league.

The system that is listed above pertains only to a player's minor hockey career. After a player has played out his years as a midget (or quite possibly a year or two before), a player will make the jump to a higher level of play - junior hockey. Junior hockey is comprised of two major routes, Major Junior (teams of the OHL, WHL, and the QMJHL) and Junior A/B/C. Major Junior is the route most often taken by those hoping to make a quick transition to the NHL and stand a better chance of being a top draft prospect as an 18 year old. On the other hand, Junior A is the route taken by those players that hope to gain a scholarship and play college hockey before going on to the professional ranks. Although many players at the Major Junior level also pursue school, they are not eligible to play in the NCAA, and so the two playing routes have evolved. In the case of Junior A, B, and C, Junior A is the highest calibre with lots of attention from college scouts.

In addition to junior hockey, many players consider prep hockey. Prep hockey in the U.S is second only to the Junior A leagues in producing NCAA players. In fact, many great professional players like Brian Leetch have taken this route. The calibre falls in line closely with that of Junior A and Junior B.

The above is a summary of the level classifications within the game of North American Hockey, if you happen to have a question on hockey level classifications that wasn't answered in this article, be sure to "Ask the Vet".