今天很怪异，我的PowerPoint出现了下面的提示对话框后，不论我选择是或者否，我的PowerPoint都再也打不开了。

网上搜索了相关资料，通过下面步骤删除这个插件后，就可以正常使用了。

• 单击开始→运行→输入Powerpnt.exe /safe回车，尝试以安全模式运行POWERPOINT。
• 如果可以运行，点击POWERPOINT选项→加载项→里面的活动应用程序加载项→去除对应插件。

 

参考资料：

启用或禁用 Office 程序中的加载项
http://office.microsoft.com/zh-cn/help/HA100341272052.aspx

http://bbs.kafan.cn/thread-459528-2-9.html

     硅脂对CPU的热量向散热风扇的传递很重要，上周对我家电脑的处理对此深有感受。特写此篇Blog。

     之前我家的台式机由于频繁出现无法启动。症状是：主板灯亮，风扇都在转，但是就是无法启动，而且主板没有任何嘟嘟提醒。每次碰到这种情况，我需要把CPU拆下来，重新装上去才可以启动。我怀疑就是CPU热量散不出去的原因，在能启动的时候，通过进入主板的管理界面，看到一开机，CPU的温度就是74度。风扇乌鸦乌鸦的响。

     后来就是买了硅脂，涂在风扇跟CPU接触面上后，开机进入BIOS 后，发现CPU温度只有三十多度，玩一个3D的游戏时，也只有60度。之前不能启动的问题也就解决了。由于我家电脑的风扇是可以根据温度变转速的，之前开机后风扇很响的问题也解决了。  

参考：

实践出真知－4种硅脂涂法详尽测试
http://mb.beareyes.com.cn/2/lib/200801/24/20080124504.htm

     上周五参加Google开发者日，给我冲击最大的是Html5。对我的冲击主要有2点：

     1、Html 5 可以带来丰富的用户体验。

     开发者日中Google演示的用Html5开发的Wave（一个Mail的应用）就被Google玩的很炫。邮件、IM、博客、照片等功能融合在一起。特别是可以在一个邮件中，几个相关人能够协同讨论，不再像从前一样一个问题可以讨论N个邮件。从现场多次的掌声中可以看到这个东西很强大。它可以实现现在Flash\Silverlight才能提供的功能。

下面是 Wave 的一个截图

图片来源自：http://google.org.cn/2009/05/29/google-wave-a-new-communication-platform-for-a-new-web-2/

     2、各种浏览器支持Html5的步伐很快。

Html5的规范不象之前，九几年就出来的规范，不久前普及，这次Html5的支持，进展很快。HTML 5还没有标准化，但Firefox、Chrome、Safari和Opera已经引入了它的元素。很难想象的是一个处于草案解决的规范，已经有众多浏览器支持了。一些支持信息如下：

图片来源自： http://radar.oreilly.com/2009/05/google-bets-big-on-html-5.html 

 

小结

进展很快，功能强大，由于Google等大公司的推进，很快我们将能看到Html5的更多应用，这是一个值得关注的领域。

 

参看：

Google Wave会影响RIA/Silverlight吗？
http://www.infoq.com/cn/news/2009/06/Wave-Silverlight

谷歌开发者日：Google Wave将基于BSD协议开源
http://www.infoq.com/cn/news/2009/06/google-wave-opensource-bsd

Google I/O 2009现场视频之HTML 5之歌
http://google.org.cn/2009/06/02/song-of-html-50/

Google力挺HTML 5 或成未来应用核心
http://developer.51cto.com/art/200906/126709.htm

HTML 5 正式标准恐将2022年才能正式发布
http://developer.51cto.com/art/200809/89605.htm    

Firefox 3.1开始支持HTML 5 视频和音频
http://www.javaeye.com/news/3959-firefox-3-1-to-support-html-5-video-and-audio

我做的一个Windows Form 程序碰到一个很怪异的多线程情况，最后检查进去竟然是部分代码的数据库链接没有关闭导致的。

我的这个程序是多线程程序，每个线程不间断的从数据库中取得数据，然后对取出的数据进行处理，一直循环到没有需要处理的数据为至。每个线程的循环是上万次的，即，每个线程上万次的数据库链接打开操作。

这个程序碰到怪异的现象是：

在A服务器上，没有任何问题，在B服务器上程序开一个线程没有任何问题，开多个线程则只有一个线程没问题，其他线程都有问题。

对每一个线程都作 try catch 拦截，就会看到出错线程报如下错误：

超时时间已到。超时时间已到，但是尚未从池中获取连接。出现这种情况可能是因为所有池连接均在使用，并且达到了最大池大小。

System.Data

   在 System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)

   在 System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)

   在 System.Data.SqlClient.SqlConnection.Open()

从这个异常就可以看到，是数据库链接对象池中没有可用的链接了。

再分析下去，就是其中一部分从数据库中读数据的代码，没有调用 SqlConnection.Close。

 

分析我这个程序出现的规律：

单线程，不主动调用 SqlConnection.Close

这时候竟然数据库链接池不会报没有可用资源：

数据库链接对象池的默认最大容量为100，单线程对数据库链接打开的请求超过10000的。

显然这种情况下，虽然没有手工SqlConnection.Close，但是这些数据库链接SqlConnection还是回到了数据库链接对象池中了。

多线程时，不主动调用 SqlConnection.Close。

只有一个线程在跑，其他线程都报上述错误。

显然，多线程时，数据库链接对象池都被一个线程占住了，其他线程获得不了可用分数据库链接。

 

这个多线程怪异的特征，之前一直没想到会是SqlConnection.Close导致的，一直在其他方面想可能的问题。这次经验教训后，心得就是：

• try catch 只能拦截当前线程的异常，它拦截不到其他线程的。
• 多人协作开发，并且程序经过多次修改bug后，完全有可能出现某些情况下，没有关闭数据库链接的情况，这种情况如何避免，是必须深思的一个问题。
• 单线程，不主动关闭SqlConnection，有可能仍然不报错误，但是多线程下，就可能报错误了。

 

参考资料：

FIX: Error message when a "System.Data" thread tries to open a pooled connection in the .NET Framework 2.0: "Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool
http://support.microsoft.com/kb/948868

http://support.microsoft.com/kb/948868/en-us

 

使用连接池
http://msdn.microsoft.com/zh-cn/library/8xx3tyca(VS.80).aspx

Connection Pooling for the .NET Framework Data Provider for SQL Server
http://msdn.microsoft.com/en-us/library/8xx3tyca(vs.71).aspx

这7种结构型设计模式是下面7种：

• Adapter 适配器模式
• Bridge 桥接模式
• Composite 组合模式
• Decorator 装饰模式
• Facade 外观模式
• Flyweight 享元模式
• Proxy 代理模式

对比：

• Adapter模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况” ，在遗留代码复用、类库迁移等方面非常有用。
• Bridge模式的应用一般在“两个非常强的变化维度”。Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维护来变化。
• Composite模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化为“一对一”的关系，使得客户代码可以一致地处理对象和对象容器，无需关心处理的是单个的对象，还是组合的对象容器。 将“客户代码与复杂的对象容器结构”解耦是Composite模式的核心思想，解耦之后，客户代码将与纯粹的抽象接口（而非对象容器的复杂内部实现）发生依赖关系，从而更能“应对变化”。
• 通过采用组合、而非继承的手法， Decorator（装饰）模式实现了在运行时动态地扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。
• 从客户程序的角度来看， Facade（外观）模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上也达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Façade接口的变化。Façade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Façade很多时候更是一种架构设计模式。
• 面向对象很好地解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight（享元）设计模式主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。 运用共享技术有效地支持大量细粒度的对象。
• Proxy并不一定要求保持接口的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。

从接口的角度来看：

• Adapter模式注重转换接口； 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
• Bridge模式注重分离接口（抽象）与其实现； 将抽象部分与它的实现部分分离，使它们都可以独立地变化。
• Decorator（装饰）模式注重稳定接口的前提下为对象扩展功能； 动态地给一个对象添加一些额外的职责。就扩展功能而言，Decorator模式比生成子类方式更为灵活。
• Façade 外观模式注重简化接口； 为子系统中的一组接口提供一个一致的界面，Façade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
• Composite 组合模式，更是简化接口， 将“一对多”的关系转化为“一对一”的关系。将对象组合成树形结构以表示“部分－整体”的层次结构。Composite使得客户对单个对象和复合对象的使用具有一致性。
• Proxy 代理模式，为其他对象提供一个代理以控制对这个对象的访问。