| Notice Board |
那一天，我不得已上路。..... 在路上，只为温暖我的人。-<在路上〉歌词
|
| -- 2007-11-14 13:27:28 |
(zt)What can we expect from Microsoft in 2006
[ 2005-12-30 23:57:58 | Author: ccBoy ]
Just like last year, I made a list of what releases we can expect from Microsoft in 2006. Last year's list turned out to be pretty accurate, the only things wrong weren't my mistakes but delays or change of plans.
If you think someting is missing or wrong please let me know through a comment or sending an email to news at bink nu.
This list is based on facts, assumptions and wild guesses. It will be updated by your feedback!
Windows Server System
------------------------------------------
Read More...
If you think someting is missing or wrong please let me know through a comment or sending an email to news at bink nu.
This list is based on facts, assumptions and wild guesses. It will be updated by your feedback!
Windows Server System
------------------------------------------
- Windows Server 2003 R2---RTM 6 december 2005, VOL and OEM available Q1 2006
- Windows Storage Server 2003 R2--RTM Q1 2006. Available through OEM Q1 2006
- Windows Server 2003 Compute Cluster Edition---Beta2 Q4 2005, RTM Q2 2006
Read More...
这是上次SQL Server 2005 广州发布会时，我们吃饭的时候讨论起测试的话题。
当时刘老师(刘劲浩)说，你们说说，什么是测试？
有人说，测试是个流程，当软件要发布了就需要测试部门的确认；也有人说测试就是找Bug；也有人测试是为了验证需求，也有说测试是为了保证产品质量。
刘老师说，现在的软件产品的开发中，测试成为衡量你产品质量和进度的一把尺子。具体的说，你的软件产品在不断开发的各个过程，你就需要有一种度量的水平随时可以知道你产品的质量和进度。某天某日，你的老板问你产品，开发得如何了，你要能够随时拿出这把尺子进行丈量和报告。行或不行不是随便说的，而是靠数据，靠你身边实践的这个模型。
之后，他给我们讲了之前他看到的一篇文章，他说有空的时候，他一定要写出了，他说这个故事和现代的软件开发非常有雷同的地方。不知道他之后有没有写，不过我按照当天的记忆和当时感受，把这些描述出来吧。
故事的概括是这样的，说二次大战前，德国秘密研制的一种潜水艇，聚集了当时顶尖的科学家，耗资巨大，而且整整研制了4年，当研制出来后，在第一次试水的时候，因为有4级的小台风，所以船下水后，因为重心不稳，从而翻倒，然后就沉没了。事后人们对这个船的遗骸和整个的开发过程作了分析和反思，发现这个船的生产过程和现在的研发过程，非常的相似。
比如，第一重心不稳的问题。说原来这艘船是按两层炮楼的结构设计的，但是因为开发时间太长，两年之后三层炮楼变得比较流行，所以统帅就询问开发人员和设计人员，能否改成三层炮楼，设计师看了图纸，说设计时多留了位置进行扩展，三层炮楼是支持的。看统帅这么说，大家也一致认为三层没有问题。结果日后一试航，船就翻了。这和现在的软件开发也非常的相似，当我们仓促的加入一个新的需...
Read More...
当时刘老师(刘劲浩)说，你们说说，什么是测试？
有人说，测试是个流程，当软件要发布了就需要测试部门的确认；也有人说测试就是找Bug；也有人测试是为了验证需求，也有说测试是为了保证产品质量。
刘老师说，现在的软件产品的开发中，测试成为衡量你产品质量和进度的一把尺子。具体的说，你的软件产品在不断开发的各个过程，你就需要有一种度量的水平随时可以知道你产品的质量和进度。某天某日，你的老板问你产品，开发得如何了，你要能够随时拿出这把尺子进行丈量和报告。行或不行不是随便说的，而是靠数据，靠你身边实践的这个模型。
之后，他给我们讲了之前他看到的一篇文章，他说有空的时候，他一定要写出了，他说这个故事和现代的软件开发非常有雷同的地方。不知道他之后有没有写，不过我按照当天的记忆和当时感受，把这些描述出来吧。
故事的概括是这样的，说二次大战前，德国秘密研制的一种潜水艇，聚集了当时顶尖的科学家，耗资巨大，而且整整研制了4年，当研制出来后，在第一次试水的时候，因为有4级的小台风，所以船下水后，因为重心不稳，从而翻倒，然后就沉没了。事后人们对这个船的遗骸和整个的开发过程作了分析和反思，发现这个船的生产过程和现在的研发过程，非常的相似。
比如，第一重心不稳的问题。说原来这艘船是按两层炮楼的结构设计的，但是因为开发时间太长，两年之后三层炮楼变得比较流行，所以统帅就询问开发人员和设计人员，能否改成三层炮楼，设计师看了图纸，说设计时多留了位置进行扩展，三层炮楼是支持的。看统帅这么说，大家也一致认为三层没有问题。结果日后一试航，船就翻了。这和现在的软件开发也非常的相似，当我们仓促的加入一个新的需...
Read More...
(ZT)杀人游戏多少种玩法？---附细则
[ 2005-12-28 22:58:04 | Author: ccBoy ]
杀人游戏
设置5种身份，警察、医生、匪民、匪、平民，各种身份的责任和权利如下：
1.警察：
2个警察互相知道身份，但不知道其他人的身份。警察每轮在暗杀前都可以向裁判密语指认一个人，裁判会告诉警察此人是不是匪。警察杀匪还是要靠投票。若警察在裁判规定的期限内没有提出指认，则视为放弃当轮指认的权利。2个警察若都被杀，无论是暗杀还是明杀，不管还剩下多少人，匪都胜利。
2.匪
2个匪互相知道身份，但不知道其他人的身份。匪每轮可以暗杀一个人，也可以选择不暗杀。若暗杀的人被医生所救，则此人不死，暗杀无效。匪若在裁判规定的期限内没有提出暗杀名单，视为放弃当轮暗杀的权利。2匪都被杀，匪失败，警方胜利。
3.医生
医生不知道其他人的身份，目的是协助警方获得胜利。医生每轮在暗杀前可以密语告诉裁判救一个人，若匪暗杀的也是此人，则被暗杀者不死。医生可以救自己。医生被暗杀或明杀后，下轮丧失救人的权利。医生若在裁判规定的期限内没有提交救人的名单，视为放弃当轮救人的权利。
4.匪民
匪民不知道其他人的身份。匪民的目的是帮助匪获得胜利，匪民每轮暗杀前可以密语向裁判指认一人，裁判会密语告诉此人是不是匪。匪民被杀后丧失指认的权利。匪民若在裁判规定的期限内没有提交指认名单，视为放弃当轮指认的权利
5.平民
平民不知道其他人的身份，目的是协助警方获得胜利。
胜利条件：匪人数大于等于其他身份的人数，匪胜利；2个警察被杀，匪胜利；2匪被杀，警方胜利。
裁判绝对公正，不为任何一方提供意见
*********************************
杀人游戏的规则和游戏方法
1、参加游戏人数共13人（注释1） 。准备13张扑克牌，其中1张王，3张j，3张k，6张普通牌。众人坐定后，抽牌，抽到王的为法官，抽到j的为匪徒，抽到k的为警察，抽到普通牌的为平民。不要让别人知道你抽到的是什么牌。
...
Read More...
设置5种身份，警察、医生、匪民、匪、平民，各种身份的责任和权利如下：
1.警察：
2个警察互相知道身份，但不知道其他人的身份。警察每轮在暗杀前都可以向裁判密语指认一个人，裁判会告诉警察此人是不是匪。警察杀匪还是要靠投票。若警察在裁判规定的期限内没有提出指认，则视为放弃当轮指认的权利。2个警察若都被杀，无论是暗杀还是明杀，不管还剩下多少人，匪都胜利。
2.匪
2个匪互相知道身份，但不知道其他人的身份。匪每轮可以暗杀一个人，也可以选择不暗杀。若暗杀的人被医生所救，则此人不死，暗杀无效。匪若在裁判规定的期限内没有提出暗杀名单，视为放弃当轮暗杀的权利。2匪都被杀，匪失败，警方胜利。
3.医生
医生不知道其他人的身份，目的是协助警方获得胜利。医生每轮在暗杀前可以密语告诉裁判救一个人，若匪暗杀的也是此人，则被暗杀者不死。医生可以救自己。医生被暗杀或明杀后，下轮丧失救人的权利。医生若在裁判规定的期限内没有提交救人的名单，视为放弃当轮救人的权利。
4.匪民
匪民不知道其他人的身份。匪民的目的是帮助匪获得胜利，匪民每轮暗杀前可以密语向裁判指认一人，裁判会密语告诉此人是不是匪。匪民被杀后丧失指认的权利。匪民若在裁判规定的期限内没有提交指认名单，视为放弃当轮指认的权利
5.平民
平民不知道其他人的身份，目的是协助警方获得胜利。
胜利条件：匪人数大于等于其他身份的人数，匪胜利；2个警察被杀，匪胜利；2匪被杀，警方胜利。
裁判绝对公正，不为任何一方提供意见
*********************************
杀人游戏的规则和游戏方法
1、参加游戏人数共13人（注释1） 。准备13张扑克牌，其中1张王，3张j，3张k，6张普通牌。众人坐定后，抽牌，抽到王的为法官，抽到j的为匪徒，抽到k的为警察，抽到普通牌的为平民。不要让别人知道你抽到的是什么牌。
...
Read More...
不喜欢所谓的年末盘点-年末就应该休息、思考和大块的吃肉
[ 2005-12-27 17:05:10 | Author: ccBoy ]
临近年底了，可以预见性的是各式各样的"2005年底大盘点","2005年十大要事", "2005年最精彩的十件事”等等等等，总之到了年底可以盘点、总结、思考和交成绩单的时候了。
我可以没这么想，年底更多的是想休息休息，常年的出差、工作、搬家、装修，跑家具城，仿佛2005年就是准备和建造一个新的事情的过程，也许到今天还有许多都没有完成，不过没什么，再痛苦的事情，睡上一觉起来就好了。所以无论今年如果，休息一下，明年就不会是这样了。
看下来，今年自己关注最多的技术是WinFX，无论Avalon、Indigo和WF，在PDC之后的3个月里，发展很快，进度也变得比以前有张力多了。明年还会继续关注这方面的发展。
MBF、WinFS、Base4.NET， Biztalk 2006 继续跳票和移出2005年的视线，照上面说，无论今年如何，明年不会这样了。
至于.NET 2.0 系(ASP.NET 2.0, ADO.NET 2.0 , C# 2.0)，SQL Server 2005 已经是今年之后.NET平台和开发人员的基础中的基础了。相信2006年它就会成为.NET的主流了。从.NET开始，升级变得并不迫切，而且新版本和上一个版本之间的迁移和改动变得平滑了很多。许多情景和因素，取决于技术开发人员、公司的实力水平而不是微软公司的想法了。
工作、生活上今年也还有许多收获，这个就不说了。还是看看最新的新闻吧。
Pre-released WinFX Runtime Components Uninstall Tool 下载
...
Read More...
我可以没这么想，年底更多的是想休息休息，常年的出差、工作、搬家、装修，跑家具城，仿佛2005年就是准备和建造一个新的事情的过程，也许到今天还有许多都没有完成，不过没什么，再痛苦的事情，睡上一觉起来就好了。所以无论今年如果，休息一下，明年就不会是这样了。
看下来，今年自己关注最多的技术是WinFX，无论Avalon、Indigo和WF，在PDC之后的3个月里，发展很快，进度也变得比以前有张力多了。明年还会继续关注这方面的发展。
MBF、WinFS、Base4.NET， Biztalk 2006 继续跳票和移出2005年的视线，照上面说，无论今年如何，明年不会这样了。
至于.NET 2.0 系(ASP.NET 2.0, ADO.NET 2.0 , C# 2.0)，SQL Server 2005 已经是今年之后.NET平台和开发人员的基础中的基础了。相信2006年它就会成为.NET的主流了。从.NET开始，升级变得并不迫切，而且新版本和上一个版本之间的迁移和改动变得平滑了很多。许多情景和因素，取决于技术开发人员、公司的实力水平而不是微软公司的想法了。
工作、生活上今年也还有许多收获，这个就不说了。还是看看最新的新闻吧。
Pre-released WinFX Runtime Components Uninstall Tool 下载
...
Read More...
微软(美国)产品开发组的团队角色
[ 2005-12-26 18:47:43 | Author: ccBoy ]
上次提到微软的PM，今天看到这样的文章，收集一下，的确这是微软(美国)产品开发组的团队角色
UI设计人员是对产品的使用界面进行设计和订正的人员。 Usability Engineer是检验UI设计的合理性的人员
在很多团队，真正的界面设计都是由PM做完了Spec，才找UI设计人员来征求意见。像我们团队，我的设计规范书写完后，我才找UI设计人员来，他们所做的也就不过是对我的设计作小改动，如那些英语词句用得不妥，哪里的按钮该改变大小，等等。我所知道的其它视窗操作系统的团队，也是差不多。这主要是因为我们能自己进行界面设计 - 视窗操作系统部门的PM是微软PM中最厉害的。可是，这是不太正确的方法，因为如果你有很强的PM, 你可用这种方法，要是你的PM的设计能力不强，这样的流程就要出问题。你的项目的成功不应该寄托在几个强有力的PM上，而是要用完善的流程来保证。好的流程应该是，在产品开发的早期，在做设计时，PM就应该和UI设计人员一起来考虑产品设计的合理性。
这个问题在微软内部我们自己也有很大的争论。 UI设计人员就常常抱怨，在产品开发的早期，他们常常不被看重，被抛在一边。UI设计的领导人甚至在全公司的培训大会上讲，我们的这个文化有问题，领导对UI设计人员在产品开发早期能起的作用不够重视。可是这个争论已有几年了，结果仍无改变。我想这主要还是跟我们这个行业的产品开发的特性有关系。因为软件开发是很技术性的，常常在早期的技术讨论中，UI设计人员对技术讨论说不出个所以然来(因为他们大多是学艺术设计的)，渐渐地各开发团队对UI设计人员的作用就看轻了。在使用界面因素占很大比例的产品团队，像Office 和MSN，这种情况要好一些。
Usability Engineer 所做的事和UI设计人员不同。他们是将UI设计的模型版，找客户来进行实用和使用性能的检验调查和测试，并根...
Read More...
UI设计人员是对产品的使用界面进行设计和订正的人员。 Usability Engineer是检验UI设计的合理性的人员
在很多团队，真正的界面设计都是由PM做完了Spec，才找UI设计人员来征求意见。像我们团队，我的设计规范书写完后，我才找UI设计人员来，他们所做的也就不过是对我的设计作小改动，如那些英语词句用得不妥，哪里的按钮该改变大小，等等。我所知道的其它视窗操作系统的团队，也是差不多。这主要是因为我们能自己进行界面设计 - 视窗操作系统部门的PM是微软PM中最厉害的。可是，这是不太正确的方法，因为如果你有很强的PM, 你可用这种方法，要是你的PM的设计能力不强，这样的流程就要出问题。你的项目的成功不应该寄托在几个强有力的PM上，而是要用完善的流程来保证。好的流程应该是，在产品开发的早期，在做设计时，PM就应该和UI设计人员一起来考虑产品设计的合理性。
这个问题在微软内部我们自己也有很大的争论。 UI设计人员就常常抱怨，在产品开发的早期，他们常常不被看重，被抛在一边。UI设计的领导人甚至在全公司的培训大会上讲，我们的这个文化有问题，领导对UI设计人员在产品开发早期能起的作用不够重视。可是这个争论已有几年了，结果仍无改变。我想这主要还是跟我们这个行业的产品开发的特性有关系。因为软件开发是很技术性的，常常在早期的技术讨论中，UI设计人员对技术讨论说不出个所以然来(因为他们大多是学艺术设计的)，渐渐地各开发团队对UI设计人员的作用就看轻了。在使用界面因素占很大比例的产品团队，像Office 和MSN，这种情况要好一些。
Usability Engineer 所做的事和UI设计人员不同。他们是将UI设计的模型版，找客户来进行实用和使用性能的检验调查和测试，并根...
Read More...
Wish you and your family a Merry Christmas and a happy New Year!
[ 2005-12-24 13:52:43 | Author: ccBoy ]
祝大家圣诞快乐，在这两天里请你抽出时间，和你的爱人和家人一起渡过，享受这些时光。
下载这首歌曲听听
Spoken: I remember the first time I made Christmas cookies at Aunt MeMes Me and my cousin Sha stayed up all night to put the icing on And then everybody came over cuz MeMe cooked and baked pies And all my mom and dad brought was two gallons of ice cream That's what I remember about Christmas ---A song "Christmas Time Again" from Ashanti.
下载这首歌曲听听
Click Here to Show/Hide MediaSpoken: I remember the first time I made Christmas cookies at Aunt MeMes Me and my cousin Sha stayed up all night to put the icing on And then everybody came over cuz MeMe cooked and baked pies And all my mom and dad brought was two gallons of ice cream That's what I remember about Christmas ---A song "Christmas Time Again" from Ashanti.
You don't have the permission to view this Article.
