其实侧边栏的优化思路很简单，首先，静态页面里的侧边栏并不是全静态的，它能够实现一些简单的动态效果，例如登录框的表现，评论，访问数量等等。如果侧边栏每次都去访问服务器这样的速度肯定在，高速的静态页面下表现很慢。 最好的解决办法能够让浏览器知道如何才去获取到新的数据。

我们了解HTTP协议知道，304 是浏览器向服务器咨询内容是否有更新用的。朝这个方向去考虑，我打算让侧边栏实现304效果，只有服务器有更新才获取数据，没有更新让浏览器总是到本地的缓存去获取数据，以达到速度的提升。

看看我们的ASP是如何实现304的

服务端获取到客户端的etag后，和服务器的etag进行对比。如果相等说明客户端有本地缓存，于是返回304给客户端，否则加载侧边栏的数据。当然这个判断的消耗是非常低的，我们甚至不用访问服务器，只要访问服务器里的一个缓存的etag即可

IE历来被web标准的拥护者所诟病，而当FireFox横空出世以后，更多的网页制作者开始关注web标准设计。看着FireFox的市场占有率不停的上升，微软终于推出了IE7。但IE7是否真的能够力挽狂澜，是否真的能够得到用户的信任，是否真的能够得到网页设计者的认可呢？

且看《IE7的web标准之道》系列文章，和你一起见证IE7的改变！

什么叫云计算？根据维基百科当中的定义（基于某种原因，可能无法访问维基百科）：云计算（cloud computing，分布式计算技术的一种，其最基本的概念，是透过网络将庞大的计算处理程序自动分拆成无数个较小的子程序，再交由多部服务器所组成的庞大系统经搜寻、计算分析之后将处理结果回传给用户。透过这项技术，网络服务提供者可以在数秒之内，达成处理数以千万计甚至亿计的信息，达到和“超级计算机”同样强大效能的网络服务。

很深奥的概念，相信很多朋友可能和开心一样，有些云里雾里，真的掉到云里面去了。而且在下面的云计算示例一节当中，又给出了两个简单的云计算案例，即搜索引擎以及网络邮箱。俺就有一些搞不明白了，按照这种示例，所谓的云计算，与B/S以及C/S架构到底有什么不同呢？如果再看看各大媒体举的例子，把一些在线文档编辑器也称之为云计算，那么云计算与SaaS又有什么区别呢？这不就是经典的新瓶装旧酒吗？

其实，云计算的先驱真的不是Google（谷歌）或者微软，而是亚马逊（Amazon）。让我们来看一下所谓的B/S以及C/S架构，如果从分层上来看，其实都是Client to Server的层次（只不过B/S中把C换成了Browser而已）。而无论在Client端还是Server端，都适用于经典的软件销售，在Client端，我们有Office、Windows Vista、Firefxo，而在Server端，则有SQL Server、Oracle、Apache。这些软件都适用于software license的销售模式（软件收费或者支持服务收费）。

而亚马逊的EC2则更改了Server端的software license模式，其最主要的含义是将软件的功能以服务的方式提供出来，然后根据类似于SLA（Service Level Agreement）的方式为其客户提供相应的服务。比如EC2当中的Simple DB，就是一个网络存储服务，类似于SQL Server/Oracle等等，你在开发的时候，不需要安装经典的数据库应用程序在服务器上，根本不用在意我的数据到底存在“哪块云里面”，而且开发的时候还可以使用原来的SQL语句进行CRUD（不知道CRUD是什么意思？赶快做一下功课去吧），任何时间，任何地点，任何设备都可以进行访问。听上去很美吧？

所以云计算其实就是C/S的一个扩展版本，简单可以描述为C to S to S (C/S/S)，实质就是一个更新版本的SaaS，服务器端的Software As A Service。大小S之间进行计算以及数据的传输，最终把结果输给C，让C来展示就可以了。而云计算指的其实就是S to S这一端，所以与最终用户根本无关，甚至最终用户根本感觉不到这种改动，所改动的其实就是开发商如何采购其服务而已（是购买软件还是租用服务）。所以俺开心个人认为，传统的搜索引擎以及网络邮箱，或者在线文档编辑器(Google Docs)还称不上什么云计算（当然，你硬说里面也有S to S之类的云端交流，俺也不没有什么理由来说服你）。

ASP(Application Service Provider)其实也是云计算的一个先驱，但它是把应用构建在云端，而不是把服务构建在云端，所以造成了其上的二次开发商非常稀少，而没有建立起完整的生态链系统，最终进入到失败。而云计算由于只是把服务器端的Software更改为Service方式应用（云上的API），所以可以召募很多的二次开发商，从而快速得构建起完整的生态链。相当于IT界的一次洗牌过程，抓住了云也就抓住了未来，对于传统软件厂商来说，其危害要比Open source有过之而无不及。整个生态链可以基本上划分为云间服务提供商（相当于原来的服务器端的软件厂商：微软、甲骨文、IBM等）、应用开发商（基于服务构建应用的厂商，SI或者ISV等）以及最终用户等。

但云计算也不会一帆风顺，肯定会有乌云时期，有兴趣的话，可以去了解一下Amazon的EC2的业绩。我们可以先抛开欧美日印市场，从国内的IT环境来看，无论是从政策、技术或者信用等来说，目前还极度不成熟。非死不可（Facebook）本周在国内的突然病亡会在很长一段时期让大家对于云计算充满怀疑（谁又能够预料哪一天App Engine突然发动不起来了？），现有的云计算的开发模式对于重视技术迁移成本的开发商也处于观望状态。

所以云计算虽然看上去很美，但实际上要走得路还是很长。

在接下来的话题当中，开心还想聊聊云端的梦（从最终用户角度会感觉到的优势）、吞云吐雾的幻术（从开发者角度选择最好的云计算平台）等话题，欢迎大家交流。

Silverlight在嵌入式领域发挥的作用绝对不仅仅只有增加Web的用户体验而已。很多嵌入式设备需要丰富多彩的用户交互界面，比如ATM、自动售货机、自助查询终端、老虎机（喔）……Windows Embedded Standard的主要应用领域恰好在这几个方面，所以Silverlight对于来说Windows Embedded Standard来说是如虎添翼。可能有朋友也会说，我们使用其他技术也可以实现与Silverlight类似的界面，这个肯定是没错。但是考虑到与后台数据库或Web Service的交互、部署成本、维护成本等问题，我相信Silverlight肯定会成为开发者今后开发中的首选。

好了，先不说那么多，我们下一步要做的是将Silverlight变成WES的主界面，WES启动之后直接进入到Silverlight的应用之中。我们知道Silverlight是Host到IE等浏览器中运行的，在WES中也是这样，而Silverlight的部署有两种方式：第一种是将Silverlight文件部署到WES的Image中，随Image一起发布；另一种是让浏览器启动后访问Internet上的某个Silverlight站点。这两种方法有各自的应用场景，我们在这里不做过多分析。在这里，我们挑选比较难得一种：将Silverlight文件与WES的Image一起发布。

第一步，我们要创建一个组件：这个组件应该是一个Shell组件，在系统启动后不进入我们传统意义上的“桌面”，而是直接启动这个组件中指定的应用程序。而且组件中还应该包括一些Silverlight相关的文件、一些注册表项，还有一些高级设置。稍后我们会看得到。

我们还是先打开我们创建组件的工具：Component Designer。Windows Embedded Standard没有一个完整的IDE环境，所以做什么事情的时候要分别打开不同的工具。

Component Designer的界面如下，我们要先选择File-New创建一个新的组件，然后保存这个组件，并为sld文件设置一个文件名称。

接下来，我们要创建一个Repositories，这个相当于给组件住的房子。组件是保存在数据库中的，而Repositories在数据库中可以起到隔离组件的作用，而且也比较方便我们维护和升级组件。

我们右键点击上图中Repositories节点，选择“Add Repository”来创建一个新的Repositories。首先为Repositories起个名字，写在右侧属性窗口的Name中，然后还要点击Source Path后边的Browse按钮。Source Path顾名思义，我们要为该Repositories的源文件找一个保存的位置，而我们一般也会把组件所需的文件都放到这个文件夹下。这个文件夹一般没有规定，但是最好放到C盘下，自己创建个文件夹就可以了。

接下来，我们就该添加组件了，在上图的Components节点上右键单击，在右键菜单上选择“Add Component”。

创建组件之后，第一件事是在右侧的属性窗口中修改名字。

因为我们创建的这个组件是一个Shell组件，所以我们还要规定它在组件库中的原型组件，点击Prototype后边的Browse按钮。

我们会看到下图的对话框，初始化可能会花费一些时间。选择Software | System | User Interface | Shells下的Shell Prototype Component组件，作为我们组件的原型组件。

接下来还需要点击Advanced按钮，定义启动时的自定义动作：

在上面的对话框中，点击Add按钮添加一个叫做“cmiShellPath”的扩展属性，类型为String，具体指为：

%16426%\Internet Explorer\iexplore.exe -k "C:\SilverlightApplication2\Default.html"

怎么样看着眼熟吧，没错就是启动一个IE浏览器的实例，-k表示全屏显示，而后边的文件路径不是一成不变的，要根据你将这个HTML文件放到哪里而决定。如果是在线的网站其实更简单一些，直接写网址就好了。

然后为组件指定Repositories，点击“Repositories…”按钮，会弹出下面的对话框。好了，直接选择咱们前边创建的，就可以了。

然后到了非常重要的一步，添加文件。这个问题也曾经困扰了我很久，我们明天再说。

    更多关于Windows Embedded开发文件，请参考：http://we.cnblogs.com/

本文从HTML, CSS 原理等多个方面详细比较分析了 block 和 inline 的概念区别和表现区别。对前台开发感兴趣的可以看看哟。

好了，完成安装之后，我们就可以来做Windows Embedded Standard的第一个操作系统镜像了。在开始菜单中找到“Microsoft Windows Embedded Studio”，启动其中的Target Designer。然后再Target Designer的File菜单中选择New，创建一个新的Configuration。

输入名称后，点击OK，进入Target Designer的主界面。为了简单起见，我们选择Virtual PC作为我们的目标设备，这样就可以省去获取硬件设备信息的步骤。

首先，我们要在左侧的组件列表中找到我们要添加的组件。第一个自然是Silverlight组件了。Windows Embedded Standard中包括的是Silverlight 1.0，目前Silverlight 2.0还是beta阶段，也许等WES正式推出时就是Silverlight 2.0了，即使不是，也肯定会有QFE的。

由于不确定Silverlight被放到哪里了，所以只好Search了一把。结果是，在Software-System-System Services-Application Support中包括了Silverlight组件。除了Silverlight之外，我们还需要添加几个组件：

首先，是Design Templates下的Information Application；然后是，Software节点下的Test & Development下的Runtime Quick Start Helper Macro和Virtual PC 2007 Helper Macro两个组件。

添加了这些组件之后，我们就可以进行依赖检查了，按F5，或者在Configuration菜单下的Check Dependencies项，就可以执行了。如下图：

依赖检查之后，如果没有错误，我们可以直接进行编译，选择Configuration下的Build Target Image或者按F7，构建过程如下图：

在编译完成之后，我们就可以在C：\Windows Embedded Images下找到已经编译好的文件。我们将其拷贝到准备好的虚拟硬盘中就可以了。如何构建VPC的开发环境，请参考我的Webcast 《XP Embedded开发初体验》中的介绍。

在第一次启动时，系统会启动FBA(First boot agent)来完成一些设置，我们需要耐心等待一些时间：

接下来，我们关闭WES开发环境的VPC，记得一定要选择Shut down。

然后运行XPETraget的VPC，我们编译出来的Windows Embedded Standard Image其实和XP Professional非常类似，只是少了比较多的组件。不过我们仍然能够通过开始菜单来打开IE浏览器，然后再里边输入URL: http://www.silverlight.net/ 。对Silverlight比较熟悉的朋友一定会知道这个网站。而访问这个网站时，并没有提示我们需要安装Silverlight，这表明Silverlight已经被加到了Windows Embedded Standard的Image之中了。

MLC NAND Flash allows each memory cell to store two bits of information, compared to the one bit-per-cell SLC NAND Flash allows.  As a result, 90 nanometer (nm) MLC NAND offers a larger capacity (typically twice the density of SLC) and at a cost point appropriate for consumer products multi-function cell phones, digital cameras, USB drives and memory cards.  Toshiba 90nm MLC NAND Flash is rated to last approximately 10,000 cycles, which is considered more than sufficient for the average consumer application.  For example, a USB drive application that used the 10,000 write/erase cycles would enable the user to completely write and erase the entire contents once per day for 27 years, well beyond the life of the hardware.

Though SLC NAND offers a lower density, it also provides an enhanced level of performance in the form of faster write speeds.  Because SLC stores only one bit per cell, the likelihood for error is reduced. At 90 nanometer process, it is recommended to implement a 1 to 2-bit ECC for SLC, whereas 4-bit ECC is recommended on the MLC architecture. SLC also allows for longer write/erase cycle endurance and has a life expectancy rated at approximately 100,000 cycles, making it a better fit for use in applications requiring higher reliability, increased endurance and viability in multi-year product life cycles.