Nici de Blog

Deep Zoom测试

2008-08-11T15:08:00.001+08:00

美丽的西雅图

2006-05-02T12:41:00.000+08:00

IMG_0612
Originally uploaded by niciyou.

从飞机上看西雅图的海湾

北京火车站的清晨

2006-03-27T14:03:00.000+08:00

丫头学校的拉面馆

2006-03-27T11:31:00.000+08:00

由于经常关顾，丫头已经和拉面馆的老板娘相当的熟悉。

老板娘的孩子已经长这么大了！旁边是他的舅舅。

丫头在学校的期间，看着老板娘的孩子长大。这次回去，小孩又长高了，已经长得这么可爱了:)

虽然年初的生意不是很好，但是好拉面不怕巷子深。

其实，丫头最爱吃的是他们的刀削面。。。-_-b

周末南京-无锡之旅

2006-03-27T11:23:00.000+08:00

周六的上午终于抵达了南京火车站。
此时南京的火车站和地铁都相继完工。当年离开南京的时候，一片狼藉的工地已经被整洁的现代化设施取代！

干净而整洁的地铁站不知道能保持多久呢？南京的变化确实改变了我对南京的看法。以前的火车站，又脏又乱。

又被google折服了一把

2006-03-24T11:26:00.000+08:00

今天收到google的通知，我的Page Creator注册成功了，试用以后又被google的web技术折服了。
实用、方便、直观，更令我惊叹的是它的速度，相比其他的利用AJEX技术开发的网站，他的速度确实很快。
如果有感兴趣的朋友可以去http://pages.google.com/注册一个试用玩一玩，非常有意思。他本身就具有了wiki的很多功能。如果能够结合google的blogger使用又是续Blog后未来网络的潮流。
很多公司在谈web 2.0，但是google本身就是web 2.0，
http://xueming.duan.googlepages.com/

恍惚的十年

2006-03-21T15:39:00.000+08:00

十年前的我到现在已经完全两个样子，就是与十年前的朋友们一起的时候都已经难以找到昔日的感觉。昔日，豪情万丈、意气风发欲与天公试比高。而今却浑浑噩噩，胸无大志。诚然，虽已经没有了当年的稚气，却也缺少了那份豪气。

其实看看昔日的很多同窗好友，很多也都看似如此。但我相信很多人都已经将那份豪气内敛。正所谓厚积勃发。这十年的光阴是对我的磨练，下一个十年已经快来到了。已经是我抉择的时候了！

To be or not to be? That is the quesiton!

老校友 vs 新校门 - 15年凝聚在这一刻

2006-03-07T13:29:00.000+08:00

我们一起长到的朋友都在这里个学校念过初中，转眼十多年就这样过去了。老校门已经被堵上了，老朋友们只能在新的校门前留影纪念。

Microsoft .net

2006-01-25T17:40:00.000+08:00

aaabbb

圣诞节的晚上，我们共聚一堂！

2006-01-10T22:17:00.000+08:00

My Portrait

2006-01-10T22:07:00.000+08:00

Abbreviation

2005-11-30T17:09:00.000+08:00

DPE: Developer & Platform Evangelism
POC: Proof of Concept

Healthcare:
HIPAA
HL7
DICOM

Company:
CSS: China National Software & Service Company Ltd. 中软
ICSS: 中软国际
CSST: 中软培训
EPG: Enterprise & Patner Group
PSG: Public Sector Group

Others:
CTEC: Certified Technical Education Center

Bliki Wikilog

2005-11-14T11:42:00.000+08:00

如果能够将Wiki和Blog集成起来，对于网络用户来说是多么兴奋的事情。于是，Bliki或者说Wikilog就这样诞生了。
Bliki来自Martin Fowler的网站，而且他自己也开始写Bliki。
他也提到了SnipSnap这个Bliki平台。于是下载了来看看。SnipSnap已经很不错了。但是，中文界面还是有布局的问题。但是尝试设置为英文失败后就没有在继续。
还是希望能够有一个商业Bliki的平台提供给用户。
比如Google的这个blog能够融合Wiki的功能给用户那就太棒了。

Hosting .NET Windows Forms Controls in IE

2005-10-31T14:42:00.000+08:00

Resemble Java Applets:-)
但是Hosting .NET WinForm的最大问题是支持，仅仅Microsoft自己的IE6.0+.NET Framework才能够运行这些控件。太多的限制，难怪很少见到这项技术的实际应用。
Java Applet在浏览器上被Microsoft的压制，使得JavaApplet的局势越来越糟。
看样子Flash技术才是Web Rich Client的唯一解决方案。
如果能够出现Flash+.NET的解决方案，将一统Web端Rich方案。

About .NET

2005-10-26T21:46:00.000+08:00

= 无聊的多语言支持 =
其实.NET对多种编程语言(C++,C#,VB, etc)的支持是一个无聊的把戏，没有太多的意义而带来的很多的麻烦。Microsoft对这些语言.NET版本的支持造成了成本上升，初学者常常为学习那种语言而苦恼，.NET开发人员也会因为使用的语言不同而造成communication overhead.
然后，计算机编程语言本身的差异性相对于编程平台的差异来说不大。一个熟练的开发人员要熟悉C#的语法一周就已经足够了。但是，要熟悉整个.NET Framework和相应的开发平台可能需要好几个月的时间。
然后为了避免这一周的学习，MS制造了如此多版本的.NET Computing Language可谓得不偿失。而且，VB6的开发人员要使用VB.NET也需要很长时间的学习。因为，就我遇到的几个VB6的开发人员学习情况来看是这个样的。

= 我想看到Source Code =
更加糟糕的是，你根本开不到.NET Framework是如何使用.NET Computing Language的。对于开发者来说，最好的学习工具和范本就是Source Code。如果，他能看到Framework的Source Code，那样就更加知道如何使用这些编程语言开发程序。

Reading: Web Services Enablement for Healthcare HL7 Applications - Web Services Basic Profile Reference Implementation

2005-10-25T13:38:00.000+08:00

Author: Mauro Regio
Resource: Web Services Enablement for Healthcare HL7 Applications - Web Services Basic Profile Reference Implementation

敏捷实践12条原则 -- Martin Fowler

2005-10-21T14:53:00.000+08:00

敏捷实践12条原则 -- Martin Fowler
Martin

敏捷实践12 条原则，它们是敏捷实践区别于重型过程的特征所在。
1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
MIT Sloan 管理评论杂志刊登过一篇论文，分析了对于公司构建高质量产品方面有帮助的软件开发实践。该论文发现了很多对于最终系统质量有重要影响的实践。其中一个实践表明，尽早地交付具有部分功能的系统和系统质量之间具有很强的相关性。该论文指出，初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高。
该论文的另一项发现是，以逐渐增加功能的方式经常性地交付系统和最终质量之间有非常强的相关性。交付得越频繁，最终产品的质量就越高。
敏捷实践会尽早地、经常地进行交付。我们努力在项目刚开始的几周内就交付一个具有基本功能的系统。然后，我们努力坚持每两周就交付一个功能渐增的系统。
如果客户认为目前的功能已经足够了，客户可以选择把这些系统加入到产品中。或者，他们可以简单地选择再检查一遍已有的功能，并指出他们想要做的改变。
2．即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
这是一个关于态度的声明。敏捷过程的参与者不惧怕变化。他们认为改变需求是好的事情，因为那些改变意味着团队已经学到了很多如何满足市场需要的知识。
敏捷团队会非常努力地保持软件结构的灵活性，这样当需求变化时，对于系统造成的影响是最小的。
3．经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
我们交付可以工作的软件（working software ），并且尽早地（项目刚开始很少的几周后）、经常性地（此后每隔很少的几周）交付它。我们不赞成交付大量的文档或者计划。我们认为那些不是真正要交付的东西。我们关注的目标是交付满足客户需要的软件。
4．在整个项目开发期间，商务人员和开发人员必须天天都工作在一起。
为了能够以敏捷的方式进行项目的开发，客户、开发人员以及涉众之间就必须要进行有意义的、频繁的交互。软件项目不像发射出去就能够自动导航的武器，必须要对软件项目进行持续不断地引导。
5．围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
在敏捷项目中，人被认为是项目取得成功的最重要的因素。所有其他的因素——过程、环境、管理等等——都被认为是次要的，并且当它们对于人有负面的影响时，就要对它们进行改变。例如，如果办公环境对团队的工作造成阻碍，就必须对办公环境进行改变。如果某些过程步骤
对团队的工作造成阻碍，就必须对那些过程步骤进行改变。
6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
在敏捷项目中，人们之间相互进行交谈。首要的沟通方式就是交谈。也许会编写文档，但是不会企图在文档中包含所有的项目信息。敏捷团队不需要书面的规范、书面的计划或者书面的设计。
团队成员可以去编写文档，如果对于这些文档的需求是迫切并且意义重大的，但是文档不是默认的沟通方式。默认的沟通方式是交谈。
7．工作的软件是首要的进度度量标准。
敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度。它们不是根据所处的开发阶段、已经编写的文档的多少或者已经创建的基础设施（ infrastructure）代码的数量来度量开发进度的。
只有当30%的必须功能可以工作时，才可以确定进度完成了30%。
8．敏捷过程提倡可持续的开发速度。责任人（sponsors）、开发者和用户应该能够保持一个长期的、恒定的开发速度。
敏捷项目不是50 米短跑；而是马拉松长跑。团队不是以全速启动并试图在项目开发期间维持那个速度；相反，他们以快速但是可持续的速度行进。跑得过快会导致团队精力耗尽、出现短期行为以致崩溃。敏捷团队会测量他们自己的速度。他们不允许自己过于疲惫。他们不会借用明天的精力来在今天多完成一点工作。他们工作在一个可以使在整个项目开发期间保持最高质量标准的速度上。
9．不断地关注优秀的技能和好的设计会增强敏捷能力。
高的产品质量是获取高的开发速度的关键。保持软件尽可能的清洁、健壮是快速开发软件的途径。因而，所有的敏捷团队成员都致力于只编写他们能够编写的最高质量的代码。他们不会制造混乱然后告诉自己等有更多的时间时再来清理它们。如果他们在今天制造了混乱，他们会在今天把混乱清理干净。
10．简单——使未完成的工作最大化的艺术——是根本的。
敏捷团队不会试图去构建那些华而不实的系统，他们总是更愿意采用和目标一致的最简单的方法。他们并不看重对于明天会出现的问题的预测，也不会在今天就对那些问题进行防卫。相反，他们在今天以最高的质量完成最简单的工作，深信如果在明天发生了问题，也会很容易进行处理。
11．最好的构架、需求和设计出自于自组织的团队。
敏捷团队是自组织的团队。任务不是从外部分配给单个团队成员，而是分配给整个团队，然后再由团队来确定完成任务的最好方法。
敏捷团队的成员共同来解决项目中所有方面的问题。每一个成员都具有项目中所有方面的参与权力。不存在单一的团队成员对系统构架、需求或者测试负责的情况。整个团队共同承担那些职责，每一个团队成员都能够影响它们。
12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整。敏捷团队知道团队所处的环境在不断的变化，并且知道为了保持团队的敏捷性，就必须要随环境一起变化。

结论
每一个软件开发人员、每一个开发团队的职业目标，都是给他们的雇主和客户交付最大可能的价值。可是，我们的项目以令人沮丧的速度失败，或者未能交付任何价值。虽然在项目中采用过程方法是出于好意的，但是膨胀的过程方法对于我们的失败至少是应该负一些责任的。敏捷软件开发的原则和价值观构成了一个可以帮助团队打破过程膨胀循环的方法，这个方法关注的是可以达到团队目标的一些简单的技术。

开发团队的质量保证

2005-10-10T15:50:00.000+08:00

开发团队的产品质量的依赖于2类主要的因素，一个是人员的素质，另一个是质量体系（包括软件流程）的规范和实施。

质量体系有一个主要的作用就是来弥补人的缺陷。但是，不能取代人因素。产品质量需要人的能力、责任感、热情的支持，否则再好的流程也难获得好的产品质量。好的质量体系可以提高人员的工作效率，弥补人的缺陷，并且能够避免容易重复犯的错误。能够协助团队的成长。

Task-Oriented Project Management Relationship

2005-10-08T16:26:00.000+08:00

Task-Oriented Project Management Relationship
Task input includes Artifact and Processor Task.
Task output includes the Artifact and Successor Task.
Task has Processor and Successor Task.
The lifecycle of Task includes Submit, Assign, Open, Resolve, Verify, Close, Duplicate and Monitor.
Types of Task include Defect, Enhancement, Requirement, Design, and Implementation.
Participations

The relationship between Tasks is Depends (Waiting), Include, Extend, Processor, and Successor.

Ivy学习笔记-1

2005-09-20T16:39:00.000+08:00

今天把Ivy下载下来用了一把，确实针对传递依赖关系做了很多的工作。但是，似乎做的有些太过于复杂。但是，我又一时无法提出一个更加简洁的解决方案。

Tips：
1．在ivy.xml文件中描述依赖关系时，版本信息rev是”latest.integration”时，则会获取最新的版本。

问题：
一个HTTP的Resolver能否支持publish任务？