下下来的Visual Studio 2008安装.iso文件，用winiso打开之后，3G多的容量，发现只有一个README.TXT，打开之后有如下的一段话：

This disc contains a "UDF" file system and requires an operating system
that supports the ISO-13346 "UDF" file system specification.

额的神那，那不是意味着我还要换一个支持UDF文件系统的操作系统。于是我把上面这段话在网上搜索，还有搜索“Windows XP下 识别UDF”，均无果。。。

后来发现了http://blog.chinaunix.net/u/8681/showart_454782.html，才知道原来是WINISO的问题，引用：

WinISO 不能打开微软VS2008的这种格式, 虽以ISO后辍以, 实质上是DVD UDF格式, Ultra ISO(8.6.5.2140)可以

于是换用UltraISO，果然有用，顺利解压！

ISO格式真是麻烦，以前用WINRAR打开ISO，有时候解压之后中文变成乱码，于是受人推荐换用了WINISO，这次发现WINISO也有这样的问题，以后支持UltraISO了~

接受Sixsix的建议，直接从Silverlight 2开始学起，貌似2是个更加成熟的平台，相信1不久将会被2取代~希望不要在刚把2学得差不多的时候，3又出来了。。。其实更新速度不算快，人家竞争对手Flash不是都更新9了么~

http://www.microsoft.com/taiwan/msdn/columns/huang_jhong_cheng/Silverlight_beta1.htm

Silverlight 2.0 Beta 1 之初體驗  作者：黃忠成

看MSDN总是会有收获的。台湾人写的，主要是介绍了SL2的新特性，并给出了一个应用WCF和SL2结合的简单实例，浏览一遍即可~文中有Silverlight 2.0 Beta 1 SDK的下载地址。

http://blog.joycode.com/scottgu/archive/2008/02/29/114918.aspx

Silverlight 2 入门教程中文版~

貌似英文原版就是Silverlight的开发者写的~一共用8个部分细致地讲解了如何拥Silverlight 2创建一个Digg应用，虽然作者说时间仓促翻译的不好，但是作者明显谦虚了~看了这个教程你会清楚Silverlight是做什么，怎么做的，以及SL2的新特性如何使用~

在这个教程当中涉及到用LinearGradientBrush 来获得 DiggPanel 上的好看的渐变背景效果，http://bbs.blueidea.com/thread-2834417-1-1.html 提供了另外一种方式，可以用Blend制作出来，然后导入XAML。

在第7部分中，作者有一个CloseButton UI上的巧妙实现，作者用"Webdings"字体的"r"文字，显示出来的是一个叉状的符号，比用字母X或者其他什么的效果更加专业一些。

Grid.rowspan属性是控制什么的？跟ASP里面类似，用于控制表格中单元格的合并。

在设置表格长宽时，“50*”的意义：

#11楼 2007-03-28 11:27 ququ [未注册用户]

To zhouyinhui
你好：
问一个题外话，在表格中，行和列的定义，
<ColumnDefinition Width="50*"/>的50后面带*是什么意思，我只知道，如果是窗口的一半用0.5*，剩余部分用*，那么50*是不是和窗口宽度一半有关系呢？还有，行高，为什么也是25*，到底什么意思呢？
新手，请指教！
回复 引用 查看

#12楼 [楼主] 2007-03-28 11:43 周银辉

TO: ququ
指定表格的大小时，可以有三种方式：
1,GridUnitType.Auto:自动，其大小取决于其内容（Content）的大小，在Xaml中你可以这样书写<ColumnDefinition Width="Auto" />
2,GridUnitType.Star:按比例，比如<ColumnDefinition Width="50*"/>表示该列占据整个表格宽度的50%
3GridUnitType.Pixel:表示指定的值为像素数。在Xaml中你可以这样书写<ColumnDefinition Width="50"/> 

Silverlight确实是非常cool的东西，微软做东西一直强调cool & innovation，今天李开复在演讲中却说他获得的最深刻的教训之一就是不要只做cool的东西，而要做实用的东西，能cool当然更好。这也许也是企业文化的不同吧~

见http://im.baidu.com/

想要立即开始体验的请留下你的百度ID或者注册百度帐号的email，我会发邀请给你。

邀请发出之后登录百度passport，可以在站内消息中看到受邀信息，并附带最新版下载地址。

详情见http://im.baidu.com/

我刚申请了，看什么时候给我一个内测资格，到时候我来发邀请。

一直以为，Java在位运算、内存操作等底层方面的处理比C++、ASM这样的语言要弱势很多，今天看到了Java的位运算~不过由于Java是运行在虚拟机里，内存操作估计是不大现实了。。。

今天在看代码的时候，看到一个用DFS思想的迷宫生成算法，对比我以前“自主研发”的DFS迷宫生成算法，要快很多。。。由于Java ME里面的虚拟机是KVM，框架和库精简到了最小化，所以在其他桌面程序中很常见的一些算法，在Java ME中可能很多需要用位运算来代替，这使得编写和理解都更加困难~

选取其中的2句：

maze[x] &= ~(0x1 << y);

上面这句真是精简，而且前后10行内没有注释。。。看了半天。。。

maze[]是一个long型数组，每个long型占64个bit，那么可以存放64个状态，A &= B就是A = A & B，~是逻辑非~，<<是左移位，maze[]数组的每个元素初始值为-1，在计算机中以补码表示就是64个1，所以此语句的操作是将maze[x]的从低往高第y位赋值为0，从而修改了一个状态值。

补充知识：>> 右移（左边以1补齐），<< 左移，>>> 无符号右移（左边以0补齐），&与，|或，~非，^异或

if((((maze[i] & shift) == 0) || (j == (maze.length - 1))) && (startX >= 0))

注意这句有4层括号。。。而且注意区分&和&&。。。这句判断在整个程序中起到了非常重要的作用。

最有帮助的资料：http://www.blogjava.net/rosen/archive/2005/08/12/9955.html

从数以bit位的表示，到各种基本操作，都讲得很清楚。

据说卖的很贵~

据说针对苹果~

本文由XA原创。做人要厚道，转载请注明出处。

这篇读书笔记的发表，代表XA正式启用了Live Space。由于网速原因，如果需要2M~5M附件上传的时候，我还是会发表在原来的MZH BLOG上，其他的日志，我会尽量发表在Live Space上。使用Space的原因很简单：很多朋友都在用，交互起来更加方便。废话少说了，开始正题。

为什么要读这本书？
让我给你2个理由：
1.这本书的作者是图灵奖和美国国家科学技术大奖的获得者，创立了美国北卡罗莱纳大学计算机科学系。这么NB的人一般都很忙，这么忙的人还能抽空写出一本书，那么这本书肯定是精华。
2.就在我们身边，印度的软件产业已经崛起，数家企业通过了CMM5级认证，成为世界第二大软件出口国。目前中国经济发展水平可能领先印度10年，但中国软件产业却落后将近10年，原因何在？很多人认为，软件开发是吃青春饭的，金山公司总裁雷军说：“在印度，包括在美国，我见到的项目经理都是三四十岁的人，他们'越老越值钱'，有些人甚至拥有超过20年度行业经验。”为什么中国的程序员总在不断学习新的开发工具、钻研程序代码，而不能逐步提升自己的视野、思维和经验？

总体上来说，本书指出了很多在软件工程中一直沿用的错误概念和做法，以及某些理解上的谬误。Brooks从软件的架构设计一直到测试发布，针对20多年来的各种实例结合自己的成功经验，发表了很多对软件工程领域贡献或大或小的观点。

• 报上经常会出现这样的新闻，讲述2个程序员如何在经过改造的简陋车库中，编出了超过大型团队工作量的重要程序。接着，每个编程人员准备相信这样的神话，因为他知道自己能以超过产业化团队的1000代码行/年的生产率来开发任何程序。其实真正最后成型的的软件产品，是复杂的编程系统产品（请百度这个名词），2人组合并不适用于所有的情况。
• 书中解答了编程为什么有趣？这和我的观点是一致的，因为编程跟其他艺术一样，是一种以人的智慧和灵感创造事物的纯粹快乐！这并不是说编程没有苦恼的时候。
• 以传统的“人月”为单位作为度量软件工程的规模和进度安排是过于乐观的，这是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。而人数和时间的互换仅仅适用于以下情况：某个人物可以分解给参与人员，并且他们之间不需要交流。沟通增加的负担由2部分组成：培训和相互的交流。书中以一个例子说明，假如一个项目进度滞后了，单纯地增加人手，不仅不会按时完成，很可能比原来更加严重地滞后。
• 一个软件开发团队在分工明确之后，才可能以很高的效率开发，具体的分工是首席程序员、副手、管理员、编辑、2个文秘、程序职员、工具维护人员、测试人员。其中首席程序员和副手了解所有的设计和全部的代码（这一点在如今可能有几百万行代码的大型系统中不再适用，这里针对的是小型团队开发小型项目）。
• 在一个系统的设计阶段，概念完整性应该是最重要的考虑因素。概念的完整性要求设计必须由一个人完成，或者非常少数互有默契的人来实现。系统的体系结构是指完整和详细的用户接口说明。体系结构描述的是发生了什么，而实现描述的是如何实现。书中讨论了几个经常出现严重谬误的问题（甚至我先前也是这么认为的），难道结构师才是最NB的，题目专门来告诉可怜的实现人员如何工作？是否所有的创造活动都被这样的人独占了额，实现人员仅仅是机器中的齿轮？难道不能民主地从所有员工中搜集好的创意，以得到更好的产品，而不是将技术说明的开发工作仅限于少数人？
• 对于最后一个问题，当然并不是只有结构师才有最好的创意，新的概念常常来自实现人员和用户，然而，系统的概念完整性决定了其使用的容易程度。不能与系统基本概念进行整合的良好想法和特色，最好放到一边，不予考虑。就算出现了一些很重要但是不兼容的构想，那么最好抛弃原有的设计，在新概念的合并上重新开始。关于第二个问题，实际上实现人员同样需要创造性的工作、新的思路和卓越的才华，结构师的工作并不一定比实现工作更富有创造性。因为产品的成本性能很大程度上依靠实现人员，就像易用性很大程度上依赖结构师。
• 整个创造性活动包括了三个独立阶段：体系结构（Architecture）、设计实现（Implementation）和物理实现（Realization）。在实际情况中，它们往往可以同时开始和并发地进行。在作者管理OS/360的经验中，体系结构团队需要工作10个月完成书写规格说明，并且出色地完成任务，这比预定的进度多了3个月，而150名程序实现人员在这10个月就只能坐在那儿干等10个月？作者决定让程序实现人员参与体系结构团队的工作，实际上，工作非但没有按时完成，而且仍将推迟3个月，而且质量更加低劣。那么看来正确的做法就是只能让实现人员坐等着了？不对，只要由一些系统功能雏形设计出来了，实现人员可以设定时间和空间目标，了解产品运行的平台配置，设计模块的边界、数据结构、算法以及所有的工具。还有个办法，其实也是在其他工程领域的办法，就是，在实现的时候才雇佣实现人员。
• 结构师必须牢记开发人员承担创造性和发明星的实现责任，所以结构师只能建议，而不能支配，但是时刻准备着为所指定的说明建议一种实现的方法。
• 第二个系统是一个很危险的系统，一个结构师可能在自己设计的第一个系统时非常谨慎，不会把新鲜但是可能出错的功能模块加入，而力求第一个系统的正常和稳定；而在第二个系统中，结构师可能会想把自己在第一个系统中由于小心谨慎而没有试过的功能模块统统加入进来，这就导致了第二个系统的危险性，结构师在设计第二个以及以后的系统时应该约束自己，避免这样的危险。
• 在软件的手册说明以及帮助文件中，形式化定义的语言是精确的，倾向完整，但是形式化定义的缺点是不易理解。在面对用户数量很大的系统中，精确往往比生动更加重要。
• 在对设计进行变更时，如果在会议上大家达成了共识，那很好，如果没有，则由首席结构师决定。
• 什么样的项目能够完成？有哪些先决条件？他们是否有清晰的目标、人力、材料、足够的技术、足够的时间、交流和组织？
• Brooks说每个编程人员应该了解所有的材料，即在办公室内应保留一份工作手册的拷贝。这是Brooks在本书中为数不多的错误观点。通过OO模型，我们应该充分运用封装继承来隐藏自己不需要知道的东西，这样会更加高效而且更加正确。
• Brooks说思考者很少，实干家更少，即是思考者又是实干者的太少了。所以产品负责人和技术主管是同一个人的可能性不大。应该让产品负责人作为总指挥，技术主管充当其左右手。产品负责人必须对技术主管的技术才能表现出尊重。
• 除了前面提到的“人月”，编程工作量可以以什么来衡量？编程工作量是程序规模的函数：

工作量 = 常数 X 指令的数量^1.5 

• 当你的程序在空间预算过多的时候，如果实现程序规模的减小？有2个常用的办法，在保持速度不变的情况下，可以削减功能来换取空间，第二个技能是考虑空间-时间的折衷（特别在使用新语言或新机器时，培训很重要）。曾经一名IBM 650的开发人员，编写了一个解释器的解释器，将最后程序所占的空间减少到了不可思议的程度。
• 软件项目需要哪些文档？
  内容：目标
  内容：产品技术说明
  时间：进度
  资金：预算
  地点：工作空间分配
  人员：组织图
• 对于大型项目，管理上的问题不再是“是否构建一个试验性的系统，然后抛弃它？”你必须这样做！
• 为变更组建团队比为变更进行设计更加困难。应该采取一定的措施使管理人员和技术人才具有互换性。贝尔实验室废除了所有的职位头衔，每个专业人士都是“技术人员中的一员”。IBM保持了2条职位晋升线，如图所示，相应的级别在概念上是相同的。当然了，微软也有类似的做法。
   

• 在开发中，个性化的工具妨碍、而不是促进沟通。开发和维护公共的通用编程工具的效率更高。
• 实验室研制和试制的模型产品或早期硬件不会像定义的那样运行，不会稳定工作，甚至不会保持不变。
• 在确定进度表时，每一件事都被成为“里程碑”。里程碑的选择只有1个原则，那就是里程碑必须是具体的、特定的、可度量的事件，能够清晰定义。在做估计日期的时候，要做到没有偏见的估计，而不是那些合乎心意的乐观估计或者自我保护的保守估计。
• 老板必须规范自己，不对项目经历可以解决的问题做出反应，并且决不在检查状态报告的时候做安排。Brooks曾经认识一个老板，他总是在状态报告的第一个段落结束之前，拿起电话发号施令。这样的做法肯定会压制信息的完全公开。
• 软件的复杂性是根本属性，不是次要因素。因此，抽掉复杂度的软件实体描述常常也去掉了一些本质属性。数学和物理学在过去三个世纪取得了巨大的进步，数学家与物理学家们为复杂的现象建立了简化的模型，从模型中抽取出各种特性，并通过试验来验证这些特性。这些方法之所以可行，是因为模型中忽略的复杂度不是被研究现象的根本属性。当复杂度是本质特性时，这些方法就行不通了。
• 软件的客观存在不具有空间的形体特征，因此，没有已有的几何表达方式。流程图等只是在软件完成后可能补充的一种无用的、被过度重视的图。对VLSI芯片设计方法的类推是一种误导——芯片设计是对两维对象的层次设计，几何特性反应了它的本质特性，而软件系统则不是这样。
• Parnas澄清了“人工智能”的2种定义。AI 1：使用计算机来解决以前只能通过人类智慧解决的问题。AI 2：使用启发式或基于规则的特定编程技术。而“专家系统”是包含归纳推论引擎和规则基础的程序，比如医生专家诊断系统。
• 技术工作的生产率公式：

任务时间 = 求和（频率_i X 时间_i）

• Brooks曾经预言MS-DOS不会是个激动人心的产品，这也是他说错的话。
• 瀑布模型是错误的，它的基本谬误是它假设项目只经历一次过程。
• Parnas产品家族树：
• 在项目的早期添加人力比在后期添加人力更加安全一些。指出“人件”概念的DeMacro和Lister的观点是：“我们行业的主要问题实质上更侧重于社会学（sociological）而不是科学技术（technological）。”还有“管理人员的职责不是要人们去工作，而是创造工作的可能。”
• 任务可以成功地转移给其他人完成，但是项目不可以，只有重新开始。

最后，发现书中有个有趣的团队名称叫Coding War Games，好像Sixsix的Peace War Found团队，哈哈。