值得一说的是这周由于时间比较紧迫，难得有2天时间在公司全方位的投入，应该说是久违的效率吧。在慵懒的时候总是希望自己能够更加效率一些，不要把时间浪费在一些无意义的浏览网页上。但是这种事情真的不是下决心就可以做好的，加之之前自己的习惯也并不是很好，所以总希望能在这方面有所进步，不过闲暇下来却每每又不能提醒自己，有时候甚至提醒自己也不是很管用，因为感觉自己没什么明确的任务方向，无论去做什么都不可能集中太长的时间。这是一个很大的问题，就像上周，如果有事情、有任务的话还是很容易达到高效率的，一方面我感觉兴趣是关键，其次计划也很重要。之所以在空下来的时候会感觉效率低下，也是自己之前没有计划好的原因。

这篇总结搁了好久，已经过了一周。上周都在公司忙于程序的调试，多线程下一直crash。很烦恼的一件事情，首先是多线程，然后crash也不是一直发生，而且在本地调试一直是没有问题的，所以感觉十分的无从下手。好吧，最终把引擎初始化的部分用线程互斥量操作了一下，基本就没有发生了。

上周遇到了这样的情况，缘起于InfoQ上的“代码之丑”系列的文章吧，的确是发现了一些软件中的bad code，不过自己不是很有自信，而且有的地方牵涉的比较大，所以只能旁敲侧击，看看其他人的反应。后来得到的结论还是比较中庸的，对于自己的feature，尽量考虑周到些。

因为blogbus超级不稳定，所以这篇就放这边了。
本来计划一周一篇的整理这周晚了一些，因为上周女朋友生病了，所以大多数的时间都在陪她，基本上就是她那里、学校和公司来回跑，隔了这几天，现在可以静下来，总结一下。其实我对这种自我整理还是很喜欢的，但是每次公司的scrum meeting都会有些忐忑不安，呵呵，可能有时候底气还不太足吧，毕竟在公司也没有做到百分之百，好吧，看来还有提升的空间。

公司里面还是老样子，上次反省了一次之后好了一些，感觉做事情的时候会主动的给自己压力，希望自己能做的更好，当然效果还是不错的，但是有些程序什么的还有些硬伤，呵呵，还需要不断总结吧。有时候leader不管了是比较容易走神，因为自己也会觉得没东西可做了，但其实还是有很多的。值得高兴的是并没有像之前那样那么无所事事，闲下来的时候还是可以看一些自己感兴趣的东西。比如今天早晨就看了一些powershell的东西，弄了一下自动化的输入，感觉效果还不错，另外看看大牛的博客，也感觉收获颇丰。怎么说的，希望稳定下来之后还是能有所进步，有些事情还是要主动一些。

上周的波形拟合有了一些进展，不过说是进展，其实很惭愧，拟合的效果还是不好，得到的结果就是单纯用hermite多项式根本行不通，果然还是要和论文上的保持一致。我也找到了那篇原文，准备尝试一下他们的函数，希望这周能看到结果。

嗯，先写到这里，感觉有些累了，想起别的东西在添上吧 :-) 。

文章提供一种容错性较高的方法来动态的加载程序的组件，论文提供了一个初步的构想，并对未来的工作进行了展望。

为何要引入新的组件隔离机制：

随着构件式软件开发的发展，以往的构件开发方式存在了诸多缺点，比如：大多数的组件都是由第三方来开发的，这给组件带来了一定程度的不可控性，软件的主体是否对组件完全的信任是一个很重要的问题，因为组件可能对软件主体造成一定程度的影响，最为直接的就是组件的bug影响到整个程序的运行，造成程序的崩溃，这是我们很不愿意看到的。

此外，传统的组件隔离大多是基于Namespace的，这种方法只能逻辑上进行代码的分离，起不到内存和错误的隔离作用。而且如今的组件开发也面临了各种各样的软件环境，这给组件的测试带来了很大的困难，从而进一步增加了系统的不稳定性。

什么是OSGi：

OSGi技术是面向Java的动态模型系统。它提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语。这些组件能够组装进一个应用和部署中。

简单的说，OSGi提供了一种实时的组件机制，组件可以被动态的添加、运行、停止和更新而不影响主程序的运行。

如今围绕OSGi的COTS市场正在逐步扩大，而COTS质量模型的不实用性也逐渐的体现出来。因为COTS质量模型需要组件的众多属性（成熟度、可恢复度和容错性），这些属性大多很难测量。

本篇文章为当今主流的组件隔离做出了总结，在此基础上提出了一种基于OSGi平台上的隔离机制。

Java标准隔离机制：

1、 Namespace-Based Isolation

基于命名空间的隔离是编写代码的常用的手段，在程序查找类或者函数时把命名空间也当做一个基本的标识属性，从而形成从函数到命名空间的一个向上的遍历来做到区分不同空间下的同名函数的问题。

但是这种隔离方法只起到了代码的隔离作用，对于组件中的错误并不能进行控制，也起不到隔离效果。

2、 OS-Based Isolation

OS-Based隔离机制是一种类似与多进程的隔离，它把程序分解到多个虚拟机上，从而提供了内存的隔离，不同虚拟机上的程序也互不影响。虽然单个进程的崩溃不会引起整个程序的问题，但是会带来程序的停滞，而组件的重新启动也会加重系统的资源消耗。

不同的进程间的通信使用Sockets或者RMI来实现。

3、 Domain Isolation

域隔离是一种细粒度的隔离方式，类似于多线程。它使用一个隔离容器和API来控制整个程序的生命周期。其中每个隔离的部分都是JVM的一个单独的实例。同样，被隔离的组件崩溃之后也不影响系统的运行，优势是域隔离的通信消耗低，可以有一套自己的资源访问机制、容错机制和一套clean application termination的机制。

Java组件隔离的应用：

Java组件隔离的应用有很多，不同类型的程序都会有使用，具体如下图：

论文中列出了7个例子，可以看出OS based和Domain based都提供了一定的容错性，并且他们大多使用Socket或者RMI方式来通信组合。

OSGi下的新隔离机制：

结合OSGi下无需重启加载组件的特性，使用一个组件管理中心对组件进行管理，各个组件以低耦合的方式结合，在代码上使用加强型的Namespace-Isolation，使类和方法可以交叉引用。Bundle（OSGi下的基本组件）的注销机制不会造成任何反作用。

新隔离机制的另外一个特点就是动态隔离，这里引入了一个sandbox来实现其功能。

程序被分为两个部分，主区域和隔离区，在主区域中只运行信任的组件，不信任的组件并不运行，不信任的组件和其依赖的组件运行在sandbox中，在sandbox中依赖组件并不运行，但却作为一份拷贝复制在sandbox里。不信任组件的崩溃只会造成sandbox的重新启动，对程序主体并没有影响。并且系统提供了一套组件由sandbox向主程序过度的机制。

组件间通信通过一个特殊的ServiceReference对象来完成，它的本质是通过代理来完成通讯，这无疑加重了系统的负担。

总结：

论文结合当今主流的组件隔离方式提出了一种基于sandbox的组件隔离方法，从而增强了系统的稳定性和健壮性，第三方组件对系统的影响只波及到sandbox。但是sandbox的引入也带来了一定的负面影响，加重了系统的通信负担。

对于使用sandbox的隔离方法，论文只是提出了构想，还有一些细节问题没有涉及，比如sandbox中的组件如何平稳过渡到主程序，而且在JVM中对于多个组件引入的sandbox的数量也是问题，还有sandbox组件的通信都是需要进一步研究的问题。

主导思想就是通过手机139邮箱来实现邮件的短信通知，程序只需要向139的邮箱发邮件就可以了。一般的Gadgets，比如Rss和Notes所涉及的只是提取以及显示信息的功能，配合html和javascript就可以实现，MSDN上也有不少Gadgets的参考。编写中遇到的一个难点就是不好使用javascript来操作邮件的收发。这里参考了一篇文章，是介绍一个Gmail Gadgets工具的，其中引入了一层交互层.net Interop，这样就可以在Gadgets中运行.net的代码，程序中建立了一个特殊的COM对象来载入.net 的assembly，这样便为使用.net的代码提供了一种可能性。（附：Gmail Gadgets Example）

有了这个例子作为基础，后面的也就不难了，我使用C#编译了发邮件的dll，然后从javacript中进行调用。至于事件的触发也很简单，都是html里的，因为懒得重新改写Notes的布局，所以添加了键盘的按键来触发邮件的发送。这里就不贴代码了，核心在于Gmail Gadgets那篇文章，看懂了也就很简单了。

今天下午一鼓作气把awesome的问题都解决了。之前零零散散的安装了一下遗留了很多问题。先是偷懒在gnome的session中更改了桌面管理程序，这样虽然其它的软件可以正常配置，但是经过整合的桌面效果并不好，上下的工具栏都会比较扎眼。

然后还是把桌面管理改回了metacity，在登录的时候重新使用awesome自带的session。又回到了之前的问题，无线的配置，之前也搜到了不少命令行的配置，但感觉太麻烦，后来发现在awesome自带的手册中就有配置的方法。真是太杯具了……

直接在awesome中调用NetworkManager，具体的方法就不说了，见http://awesome.naquadah.org/wiki/Nm-applet。

然后是声音的配置，直接在rc.lua中调用gnome-volumn-control-applet就可以了。

最后推荐一篇awesome的配置文章:在Ubuntu下编译安装Awesome。

网上也有一些方法，有使用SharpZipLib的。也有C#使用J#类库中的Zip类压缩文件和数据。各有优缺点吧。

这里使用SevenZipSharp来进行压缩，用起来也比较方便。SevenZipSharp是codeplex的开源项目，其中使用了7-zip的library。

使用的时候需要7z.dll和SevenZipSharp.dll，其中前一个不能直接添加引用，可以把它复制到项目里或者在程序里添加它的路径，像下面这样：

    public class Util
    {
        static Util()
        {
            SevenZipCompressor.SetLibraryPath(@"d:\My Documents\7z.dll");
        }

        public static void CompressFiles() 
        {
            SevenZipCompressor tmp = new SevenZipCompressor();
            tmp.ArchiveFormat = OutArchiveFormat.Zip;
            tmp.CompressFiles(@"D:\test.zip", @"D:\test.txt");
        }
    }

也可以使用CompressDirectory来压缩目录和CompressFileDictionary自由形式压缩，在codeplex里有文档的下载。现在最新的版本0.58中CompressFileDictionary会有Exception，这在0.36版本里就没有问题。但是0.36版本压缩空文件的时候也会出错。哎，纠结了……