WCF Config (ZT)

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<!-- <system.ServiceModel> section -->
<system.ServiceModel>
<!-- services 元素包含应用中驻留的所有service的配置要求 -->
<services>
<!-- 每个服务的配置
属性说明:
name - 指定这个service配置是针对的那个服务,为一个实现了某些Contract的服务类的完全限定名
(名称空间.类型名),ServiceHost载入一个服务后，会到配置文件中的<services>下找有没有
name属性跟服务匹配的<service>的配置
behaviorConfiguration - 指定在<serviceBehaviors>下的一个<behavior>的name,这个特定<behavior>
给这个service制定了一些行为,比如服务是否允许身份模拟-->
<service name="名称空间.类型名" behaviorConfiguration="behavior名">
<!-- 每个服务可以有多个Endpoint，下面<endpoint>元素对每个Endpoint分别进行配置
属性说明:
address - 指定这个Endpoint对外的URI,这个URI可以是个绝对地址，也可以是个相对于baseAddress的
相对地址。如果此属性为空，则这个Endpoint的地址就是baseAddress
binding - 指定这个Endpoint使用的binding，这个banding可以是系统预定义的9个binding之一，
比如是basicHttpBinding，也可以是自定义的customBinding。binding决定了通讯的类型、
安全、如何编码、是否基于session、是否基于事务等等
contract - 指定这个Endpoint对应的Contract的全限定名(名称空间.类型名)，这个Contract应该被
service元素的name指定的那个service实现
bindingConfiguration - 指定一个binding的配置名称，跟<bindings>下面同类<binding>的name匹配
name - Endpoint的名称，可选属性，每个Contract都可以有多个Endpoint，但是每个Contract对应的
多个Endpoint名必须是唯一的-->
<endpoint address="URI" binding="basicHttpBinding" contract="Contract全限定名" bindingConfiguration="binding名" name="">
<!-- 用户定义的xml元素集合，一般用作SOAP的header内容-->
<headers>
<!-- 任何xml内容 -->
</headers>
<identity>
<!-- <identity>下的元素都是可选的-->
<userPrincipalName></userPrincipalName>
<servicePrincipalName></servicePrincipalName>
<dns></dns>
<rsa></rsa>
<certificate encodedValue=""></certificate>
<!-- <certificateReference>的属性都是可选的
属性说明：
storeName - 证书的存储区，可能值为：AddressBook，AuthRoot，CertificateAuthority
Disallowed，My，Root，TrustedPeople，TrustedPublisher
storeLocation - 证书存储位置，可能值为：CurrentUser，LocalMachine-->
<certificateReference storeName="" storeLocation="">
</certificateReference>
</identity>
</endpoint>
<host>
<baseAddresses>
<!-- 在此可以定义每种传输协议的baseAddress，用于跟使用同样传输协议Endpoint定义的相对地
址组成完整的地址，但是每种传输协议只能定义一个baseAddress。HTTP的baseAddress同时是service
对外发布元数据的URL-->
<add baseAddress="http://address" />
</baseAddresses>
<timeouts></timeouts>
</host>
</service>
</services>

<bindings>
<!-- 指定一个或多个系统预定义的binding，比如<basicHttpBinding>，当然也可以指定自定义的customBinding，
然后在某个指定的binding下建立一个或多个配置，以便被Endpoint来使用这些配置 -->
<basicHttpBinding>
<!-- 某一类的binding的下面可能有多个配置，binding元素的name属性标识某个binding-->
<binding name="binding名">
</binding>
</basicHttpBinding>
</bindings>
<!-- 定义service和Endpiont行为-->
<behaviors>
<!-- 定义service的行为-->
<serviceBehaviors>
<!-- 一个或多个系统提供的或定制的behavior元素
属性说明：
name - 一个behavior唯一标识,<service>元素的behaviorConfiguration属性指向这个name-->
<behavior name="">
<!-- 指定service元数据发布和相关信息
属性说明：
httpGetEnabled - bool类型的值，表示是否允许通过HTTP的get方法获取sevice的WSDL元数据
httpGetUrl - 如果httpGetEnabled为true，这个属性指示使用哪个URL地址发布服务的WSDL，
如果这个属性没有设置，则使用服务的HTTP类型的baseAddress后面加上?WSDL-->
<serviceMetadata httpGetEnabled="true" httpGetUrl="http://URI:port/address" />
</behavior>
</serviceBehaviors>
<!-- 定义Endpiont的行为-->
<endpointBehaviors>
</endpointBehaviors>
</behaviors>
<!-- 包含客户端跟服务端连接使用到的Endpoint的配置 -->
<client>
<!-- 每个客户端Endpoint设置
属性说明：
address - 对应到服务端这个Endpoint的address
binding - 指定这个Endpoint使用的binding，这个banding可以是系统预定义的9个binding之一，
比如是basicHttpBinding
contract - 指定这个Endpoint对应的Contract的全限定名(名称空间.类型名)
name - Endpoint的配置名，客户端代理类的构造方法中的endpointConfigurationName对应到这个name
bindingConfiguration - 指定客户端binding的具体设置，指向<bindings>元素下同类型binding的name -->
<endpoint address="URI"
binding="basicHttpBinding" bindingConfiguration="binding名"
contract="Contract全限定名" name="endpoint配置名" />
</client>
</system.ServiceModel>
</configuration>

(ZT)Dependency Property Notes

 

I've run into dependency properties in both Windows Presentation Foundation and Windows Workflow Foundation. In trying to understand what they do, I ran across Drew Marsh's excellent introduction - "Avalon: Understanding DependencyObject and DependencyProperty". Drew's article has a WPF slant and I've mostly been seeing dependency properties from the workflow side.

In WF, dependency properties enable three features:

• Attached properties
• Activity binding
• Meta properties

The attached property story in WF is similar to the attached property story in WPF - a parent object can add additional state to the children it manages. A WPF grid will attach Row and Column properties to its children. The dynamically attached properties allow the grid to store layout state in each child. In WF, the Conditioned Activity Group can attach a When property to each child. The When property holds a condition for the CAG to evaluate before running a child activity.

Activity binding gives a dependency property an ActivityBind object to evaluate when asked for its value. The ActivityBind can point to other fields, properties, or methods of activities inside a workflow. One activity could bind its input properties to a previous activity's outputs. Binding makes the data flow a part of the workflow model.

The behavior of meta properties caught me off guard. There are two types of dependency properties in WF activities: meta properties and instance properties. We set meta properties at design time and cannot change their value at runtime (they can't use binding, either). I think meta properties exist to guarantee the integrity of an activity. At runtime, I can't change the InterfaceType of a CallExternalMethod activity and screw up the rest of the parameter bindings because InterfaceType is a meta-property.  

Dependency properties are easier to understand once you see the use cases. You have to wonder if we'd be talking about dependency properties a all if the mainstream CLR languages were more dynamic.

(ZT)Ajax vs. Silverlight and .NET

http://www.nikhilk.net/Ajax-vs-Silverlight-and-NET.aspx

(ZT)Fast Workouts That Really Work! Posted Wed, Nov 26, 2008, 1:47 pm PST

Post a Comment View All 46 Comments

I love my long training runs, but most days carving out more than an hour to work out just isn't in the cards. And when my schedule is really crammed, shoehorning a sweat session seems next to impossible.

Luckily, the fantastic fitness team at SELF let me in on a little secret: You can get an hour's worth of fitness and calorie burning in 20 short minutes. Yes, I was skeptical at first, but this fat-blasting routine is as ultraeffective as it is speedy, and the secret lies in high-intensity spurts of energy. Here's how to do it:

• Pick any cardio you like (running, swimming, the elliptical trainer). Warm up for 2 minutes at a moderate pace, then sprint for 30 seconds at the highest intensity you can muster. Slow down and do 90 seconds at a catch-your-breath recovery pace. Repeat eight times. You'll torch more calories in less time, while you burn fat faster. Follow this cardio session with a few of the following fast firmers for a total-body workout in less than 30 minutes.

• Tighten your tummy: Do two sets of 10 to 12 crunches on a stability ball. Research from the University of Auckland, Tamaki Campus, in New Zealand, revealed that using the ball makes crunches 20 percent more effective compared to hitting the floor.

• Firm up legs: Stand on left foot, hands on hips, and bring right knee to hip level in front. Trace a horizontal figure eight in front of you with knee. Then bend left knee and hop to right, landing on right foot. Repeat figure eight with left knee, then hop back to left to complete one rep. Do 10 reps, then hop back and forth 10 times to complete one set.

• Boost your bottom: Stand with feet hip-width apart, hands on waist. Shift weight to left foot and lift heel of right foot so you're resting on toes. Bend left knee and sink hips back, keeping weight off right foot (toes stay on ground). Rise up. Do 12 reps on left leg, then switch legs and repeat.

• Bare amazing arms: Holding a dumbbell in each hand, stand with feet hip-width apart. Raise arms, palms down, out and slightly forward to shoulder height. Slowly lower them behind you so weights almost touch. Do 12 reps.

• Slim all over: Stand with feet hip-width apart. Keeping legs as straight as possible, bend forward and walk hands out until they're under shoulders. Do two push-ups, then walk hands back and stand. Repeat twice, doing four push-ups, then six.

Ready for more tested toners? Check out Self.com for tips, tools and trimming tricks.

Scrum (ZT) Intro

公司流程的改变，这周主要对敏捷的Scrum培训和Daptiv工具 的培训，因为是英语培训，许多东西自己要整理一下。

首先是和开发传统模型（Waterfall）的对比，传统模型随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就迅速降低。而scrum模型非常灵活，是一个增量迭代的开发过程。在这个框架整个开发周期由若干个小的迭代周期（Iteration Cycle），每个小的迭代周期称为一个Sprint，每个sprint的周期是14到30天。每个sprint 由inspection process 组成，各个team的成员每天碰一次头review项目进行的活动并做适当的修改。推进迭代过程的需求来自Product Backlog，scrum的开发团队拿到一个排列好优先级的需求列表，因此开发的是对客户就有较高价值的需求。每个迭代结束后，都会完成可交付的产品。

这里先解释两个术语：

Product Backlog：在项目开始的时候，product owner要准备一个根据商业价值排好序的客户需求列表，这个列表就是product backlog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级别。Scrum team会根据这个来做工作量的估计。

Product Backlog应该涵盖所有用来构建满足客户需求的产品特性，包括技术上的需求。高优先级的一些产品特性需要足够的细化以便我们做工作量估计和做测试。对于那些可以在下个Sprint中完成的Product Backlog功能点，大约10人天的工作量的粒度就不错了。对于那些以后将要实现的特性可以不够详细。

Sprint Backlog：Sprint Backlog是Sprint规划会上产出的一个法宝。当Scrum team选择并承诺了Product Backlog 中要递交的一些高优先级的产品功能后，这些功能点就会被细化成为Sprint Backlog：一个完成Product Backlog功能点的必需的任务列表。这些点会被细化为更小的任务，工作量小于两天。Sprint Backlog完成后，scrum team会根据它重新估计工作量，如果这些工作量和原始设计的工作量有较大差异，scrum team会根据它重新估计工作量，如果这些工作量和原始估计的工作量有较大差异，scrum team和product owner协商，调整合理的工作量到sprint中，以确保sprint的成功实施。

Burndown Chart现实了sprint中累积剩余的工作量，它是一个反应工作量完成状况的趋势图。在sprint开始的时候，develop team会表示和估计在这个sprint需要完成的详细的任务。所有这个sprint需要完成，但没有完成的任务的工作量是累积工作量，scrum master会根据进展情况每天更新和积累工作量，如果在sprint结束时，累计工作量降低到0，sprint就成功结束。

Sprint的会议形式：

Daily Scrum 会议：Scrum组织成员每天要开Daily Scrum会议，用15分钟的时间让大家review项目的进度情况。在会上，每个团队成员需要问3个问题：（What have you done on the project since the last daily Scrum meeting?

What do you plan on doing on this project between now and the next daily Scrum meeting?

What impediments stand in the way of you meeting your commitments to this Sprint and to this project?）就是我昨天做了什么，今天做了什么，遇到哪些障碍。这个会议的目标是监测项目的全局，定位项目成员的要求，实时的调整当天开发计划。Note：不允许非项目内的人发言。

Sprint Planning Meeting（sprint规划会）：参加者有product owner，develop team，scrummaster。需要要鸡的角色的人参与，第三方提供数据后就可以解散。第一个四个小时的会议来对product backlog进行选择，肯能否在sprint内完成。Product owner在会议之前准备好product backlog，product owner决定哪些要在sprint，develop team可以提出建议。然后team再从product owner选好的product backlog中决定哪些在在sprint。第二个四个小时，develop team列出所有的任务，进行时间的评估和分配。

Sprint Review meeting（sprint 评审会）：一个小时准备时间，四个小时的review时间。参加会议的developteam表明已经完成功能，没有完成的team不能参见。会议的开始是develop team演示完成的product backlog或sprint backlog，develop team的成员会讨论在这个sprint中哪些做得好需要保持，哪些需要改进。会议的大部分时间是产品的演示，以及回答stake-holder的问题。功能演示完之后，stakeholders会对此评价，并提出想要改变的东西以及优先级。接下来product owner会和develop team和stakeholders对product的backlog的反馈进行重现安排和规划。Stakeholders也许会发表自己对演示的想法，或是提出新要增加的product backlog。在会议的最后，会宣布下一次评审会议的时间和地点。

Sprint Retrospective Meeting：设定三个小时，参加者有，develop team，scrummaster， product owner可选。所有的develop team需要回答两个问题：上一个sprint哪里做得好，哪里需要改进。Scrummaster会记录所有的回答，并和team一起排列优先顺序。需要改进的项目添加到下一个sprint中作为高优先级非功能性product backlog。

Scrum定义了许多角色，根据Pig和chicken的笑话分为两组，pig和chicken。

猪是全身投入项目和scrum过程的人：Product owner，scrummaster，和Develop Team。

Product Owner的职责：

确定产品的功能；

决定发布日期和发布内容；

为产品的ROI负责；

根据市场价值确定功能优先级；

接受或拒绝接受开发团队的工作成果。

Develop Team

具有不同特长的团队成员，人数控制在7个左右；

确定sprint目标和具体说明工作成果；

在项目向导范围内有权利做任何事情已确保到sprint的目标。

高度的自我管理能力；

向product owner演示产品功能。

ScrumMaster

保证团队资源完全可被利用并且全部是高产出的。

保证各个角色及职责的良好协作。

解决团队开发中的障碍。

做为团队和外部的接口，屏蔽外界对团队成员的干扰。

保证开发过程按照计划进行，组织daily scrum，sprint review和sprint planning meetings。

Note：ScrumMaster is not a project manager， the team is self-managing.