上周总感觉在赶时间，前后花了一周时间完成了最难的一个feature，并且深刻的体会到了日本人的严谨，甚至有些吹毛求疵，不管怎么说，改完成的都完成了，没完成的还有很多地方需要花功夫，自己还需要加油。

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

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

在实习的过程中经常会的情况是接手新的工作。即便是在正式的工作中，也有可能从中间作为成员插入到当中。如果是在软件的待开发过程中，多数是设计阶段的话还比较好，因为毕竟还没到真正的编码，什么东西都可以推翻重来。然而现实中的很多事情并不是这样，比如我现在参与的项目，基本上的功能都已经完成了，或者是软件的版本的升级需要添加新的features。在这样的情况下，通常会发现原来代码中的一些bad code，并且有时候会因此而头疼。当然，这种情况并不是很多，但是有些很典型，而且会让我很纠结，到底是在原来的bad code上改少量的代码，完成了新的feature，但是依然给代码的风格结构留下缺陷，还是花一些力气，从根部着手，添加大量异或是改动很多之前的代码。我想着的确是很纠结的事情，代码大多都是迭代开发的，有些不好的地方会一步步的叠加，越叠越大。

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

因为女朋友的课程关系，经常有一些统计数据要处理，之前她都用SPSS和Excel来做，碰到有些数据，处理起来还是比较麻烦的。比如上周的一个问题，她要从excel的两个sheet中比较两个列的内容，然后把相同的内容提出来，用sheet2的字段赋值sheet1的其它字段。可能问题比较抽象，其实就是两个dictionary，然后找到相同的key，并用第一个dictionary的value赋值第二个dictionary相同key的value。因为数据量比较大，她就问我有没有什么蛮力的方法。嗯，方法当然有很多，当时就想到了vbs，但是因为不熟悉，所以回来的时候熟悉了一下。其实，如果知道一些vbs的知识，然后在excel里使用它，的确可以达到事半功倍的效果。
这里就简单的帖一下上面问题的vbs的代码，好吧，我也懒得解释了，网上也有很多的教程嗯。
这里的数据是这样的：

自从装了Win7之后就发现了这个东西，感觉脚本很好用，一些linux的习惯可以带过来，虽然机制是不同的，但是效果不错。后来到了公司有了一些空余的时间就会看一些这方面的知识。最近一直想用脚本来自动化测试，虽然是Dev，但是有时候自己的程序一遍遍的跑也挺烦的，所以有想用python或者powershell的脚本来处理，因为python不是很熟悉，而powershell的进展还不错。
问题很简单，有时候会遇到一些比较固定的输入来看程序是否正常，但是每改动一个小的feature可能就要跑个几遍，在输入比较多的情况下还是比较麻烦的，还好接口的程序是cmd下的，所以powershell比较管用，使用管道和重定向能够达到一些自动化的效果。
其实原理很简单，比如我们有一个计算 x+y 的程序，运行的时候需要用户输入x和y，那么我们每次需要做的就是输入x和y的值来看结果。这个输入比较少，可能没有必要写脚本来测试，但是有的时候输入还是很多的。这时候，可以把要输入的值依次放在文件中，然后使用管道来进行输入重定向，比如我们的程序文件为add.exe，那么我们就可以这样：
来达到脚本输入的目的，这样就不用一个个自己输入了。

论文的题目是：Towards Dynamic Component Isolation in a Service Oriented Platform。

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

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

随着构件式软件开发的发展，以往的构件开发方式存在了诸多缺点，比如：大多数的组件都是由第三方来开发的，这给组件带来了一定程度的不可控性，软件的主体是否对组件完全的信任是一个很重要的问题，因为组件可能对软件主体造成一定程度的影响，最为直接的就是组件的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组件的通信都是需要进一步研究的问题。

之前也用过Vista的侧边栏，主要钟情于Rss和Notes这两个工具。Notes主要记录一些网上浏览的东西，比如图书的索书号，感觉Notes如果和手机的短信结合起来应该会很酷，当然Vista下的侧边栏还是很耗内存的:P。

主导思想就是通过手机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。

C#中好像有关于压缩的库，但是有很多限制，并不能很好的进行自定义压缩。

网上也有一些方法，有使用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版本压缩空文件的时候也会出错。哎，纠结了……