软件开发

使用textbox控件以及 progressbar，后来发现挺麻烦，远不及console窗口下的console.write和console.writeline方便。于是尝试直接将信息输出到控制台窗口。

所谓单个写入程序/多个阅读程序的线程同步问题，是指任意数量的线程访问共享资源时，写入程序（线程）需要修改共享资源，而阅读程序（线程）需要读取数据。在这个同步问题中，很容易得到下面二个要求：

前不久，微软又推出其“Flash杀手”的又一个新版本Silverlight 3。值得注意的是，不仅Silverlight 3中新增添了不少功能，而且Expression Blend 3较之于其前的版本也大大加强，一个又一个极酷的支持加入到其中。

一个软件项目从开始到结束，由于资源、人员、管理、方法学等等各方面的因素，往往不可避免的会存在一些问题，如需求不明确、项目管理失败、沟通问题等等。

在本系列的前面两篇文章中，我们分别介绍了Windows 7任务栏的Jumplist和实时应用程序缩略图。通过这两项新特性，任务栏为我们的终端用户提供了丰富的快捷功能和信息，让用户感觉到随时随地，应用程序就在手边(at fingertip)。但是微软似乎并不满足，雷德蒙的程序员们想要榨干任务栏的最后一滴油水：任务栏状态提示。

过去，一家新兴软件公司很难超越IBM、微软、Oracle，SAP这些软件巨头，例如adobe，Landesk等传统IT公司。因为做为领先者微软、Oracle，SAP他们有充足的资金积累，可以不断投资新产品的研发

在计算机世界中，我们已经习惯了使用那些已安装Mac OS或Windows的系统。Google最近宣布将推出基于Linux的Chrome OS，它将给我们带来什么样的体验呢

据国外媒体报道，一位谷歌执行人员称智能手机应用程序应被线上浏览而不是下载，恐怕苹果和其他公司很难同意

迄今为止，云领域的软件开发一直受到很大程度的关注。当许多早期的开发者，如Zimky和Coghead都半途而废，平台即服务（PaaS）市场却取得了突破性的进展

在信息化整个生命周期中，企业都越来越依赖于外部供应商，从需求分析到系统选型，再到项目实施乃至最后的运行维护，IT供应商始终与企业如影随形

　前一篇讨论“静态页”的文章反响不错，不少朋友发表了自己的看法，也给老赵更多的想法。虽然也在前一篇文章后面回复了不少内容，但是就以往经验来看，总结为一篇新的文章会让我想表达的内容更为明确，对于“静态化”这一非常容易被人误解的概念来说也是非常重要的。

　“静态页”，在Web应用程序开发中是很常见的概念。只是我发现目前还是有相当部分的朋友，在这方面的存在一定的误区。因此现在独立写一篇文章，也想把一些问题讲讲清楚，以后在讨论的时候也好有个准。

在消息传递（Message Passing）领域，PingPong是最常见的测试之一。它的功能简单的有些无聊，一个Ping Actor和一个Pong Actor之间互相传递消息，你Ping过来我Pong过去。也正因为如此简单，PingPong的目标仅仅是测试纯粹的消息传递机制的效率。也正因为如此，各Actor模型往往都将其作为展示自己功能的第一个示例。老赵从互联网上收集了一些最为常见的，不同语言/平台下Actor模型实现PingPong的示例，可作“观赏”之用。

“延迟”的本意是“减少计算”，但是如果您使用不当，很可能反而会造成“重复计算”。例如，我们首先构建一个方法，它接受一个参数n，返回一个Func<int, bool>对象：

老赵一直建议大家不要倾向于学习IL的原因有二： 　IL能够说明的内容太少，包括大部分.NET“必知必会”。 　IL能够获得的信息从高级语言中也大都可以知道。 　而这篇文章便是希望通过实例来把第1点解释清楚，而第2点则留给下一篇文章来解释。

C#2.0较C#1.0来说是一个突破，其中引入了泛型，以及匿名方法等新特性。如果前者还可以说是平台的增强，而语言只是个“辅助”的话，而后者则百分之一百是编译器的魔法了。别小看这个特性，它为C#3.0的高生产力踏出了坚实的一步——不过还是差了很多。例如，我们有一个要求：“把一个字符串数组中的元素转化为整数，再将其中的偶数放入一个List<int>容器中”。

上节中有点到，只要在地图移动的同时，时时根据主角等对象物体的X，Y坐标进行相对于地图的X，Y坐标移动即可达到目的。但是由此又引来了新问题：主角为Image控件，障碍物则为矩形控件，它们都没有X，Y这两个属性，我们该如何对它们的坐标进行记录呢？

　线程池是一个重要的概念。不过我发现，关于这个话题的讨论似乎还缺少了点什么。作为资料的补充，以及今后文章所需要的引用，我在这里再完整而又简单地谈一下有关线程池，还有.NET中各种线程池的基础。更详细的内容就不多作展开了，有机会我们再详细讨论这方面的细节。这次，还是一个“概述”性质的，希望可以说明白这方面问题的一些概念。

　终于到了这个系列的最后一篇文章了，这个系列的文章本是许多话题的基础，却拖了那么长时间还没有完结。这篇文章主要讨论五种缓存方式各自的优劣，以及他们的性能关键在什么地方，如果要进行改进又有什么可选方案。在这个问题上，老赵的思考可能会有遗漏，如果您有任何补充，也请不吝指出。

　关于可测试性的重要性，老赵觉得已经不需要再过多强调了。如果您想要获得高生产力，为代码编写单元测试似乎已经是必经之路了。不过可惜的是，ASP.NET应用程序给人的感觉，始终是对可测试性不太友好，其最重要的原因之一在于对HttpContext对象的高度依赖，而我们很难对HttpContext编写Mock或Stub：对于最常见的Mock框架来说，进行Mock的方式在于对抽象类型进行继承和重写，因此需要目标类型必须能够继承，其成员也必须能够重写（override），可惜HttpContext对这两个要求均不满足——虽然我们有TypeMock这个强大的工具，只可惜它是商业产品。而且事实上，如果Moq等框架无法满足您的要求，一般可以确定是设计有问题。从这个角度说，ASP.NET围绕HttpContext开展的一系列功能，在设计上的确有不足之处。