理想与现实之间

之前工作上偶尔用到WCF，都靠之前的一些知识对付过去了。现在终于下决心要来系统地学习一下。
拿出先前买的O'reilly的"Programming WCF"来读。

第一章对SOA做了个简单的介绍，其实这些概念之前也基本了解的，不过还是浏览一过来加深下印象，结果到也看到不少有趣的地方。
比如书里提到Service的自主性，理论上讲Service除了应该有明确地边界之外，应该还是自主的，不和其它的Service共享数据，需要交互都应该以Message的形式来进行。但是书上也提到，现实中的Service其实对这一条是没办法完全做到。因为业务数据通常是统一存放在一个关系型数据库中的，而其上的Service，例如业务或者报表，必然会共用数据。

于是想到，如果要改变这种状况，必然要把数据的供给也独立成一个Service，而其它的Service都使用这个Service。这里必然要面临的一个问题是性能下降，如果Data Object也要跨边界Serialize和Deserialize，效率应该会有很大的损失。这里，不禁异想天开：既然WCF已经做到Protocol透明，那么是不是也可以封装出一个进程内的，不Serialize的Channel呢？多少有点不切实际吧？

另外，联想到DP Group的Astoria项目已经改名叫ADO.NET Data Service，似乎和我想的这个东西有点类似。突然又联想到自己的工作，是不是给Reporting Services做一个Astoria的data processing extension呢？

第一次接触C#的编译，从现在看来确实和过程化语言的编译在Symbol Table的构建上有很大的差异。

MONO的C#编译器中，仿照System.Reflection以及System.Reflection.Emit中的构架，建立了自己的TypeManager，用相同的机制来完成对源代码中的类型和方法的解析以及代码生成。使用RootContext类型来统筹和驱动整个编译的过程。语法分析阶段产生的Parse Tree实际和类型系统被整合在了一起。可以看到ParseTree中的Class类型，实际间接继承自TypeContainer类型。

相对的，在ROTOR的编译器中。Parse Tree的结点在Allnodes.h中定义，而另外有独立的SYM系统，使用的方式似乎更为复杂一些。

在过程化语言的编译过程中，因为类型可能和变量重名，我们通常准备两个Environment(即查找用的Symbol Table)，一个对应类型，另一个对应变量和函数。

而在面向对象的语言里，对于一个Identifier的查找，与过程化语言很不一样。
初步考虑仍然使用两套Environment，其中之一为一个类型系统(TypeManager)，保存所有已经被解析之后的代码中的类型信息，按照以下的树型方式保存：
Namespace
 |-- Class/Struct/Interface
          |-- Method
          |-- Property
          |-- Member
为了提高作Name Resolving和Type Checking的效率，底层的数据结构可能需要结合HashTable和Tree

因为C#支持引用先于定义（C++的前置声明对编译器来说就是福音啊），因此解析时可能要按照以下的顺序：

解析所有类型的名称 （此时类型的其它信息一概未知，但光有名字的信息已经足以在下步做类型检查了）
   |---> 解析所有的数据成员和方法的声明 (使用上一步中的信息对成员的类型、方法返回类型、方法参数类型做类型检查）
               |---> 解析方法的定义

在解析方法的定义中，将使用到另一套Environment(VariableEnv)，这个Environment中，包含了所有的本地变量的Binding，Binding中的信息非常简单，只需要表明该Variable的类型即可。VariableEnv和过程化语言编译中使用的Symbol Table类似，有成熟的算法可以参考，Block之中作用域的扩展和相互屏敝也类似。

对于以下的代码：


在解析t.Foo();的时候，首先在VariableEnv查找t的Binding，从而得知类型为MyClass，然后在TypeManager中查找MyClass的方法中，是否有Foo()的定义。

初步设想，当中间代码生成结束之后，把得到的Intermediate Representation（IR）挂接到TypeManager中的Method部分中去，TypeManager中的信息已经足够可以用来做后阶段真正的IL生成了。此时，从Parse Tree到IR的转换也就完成了。

题外话：方法重载的检查其实相对简单，当在解析方法定义的时候，根据参数的类型，在TypeManager中查找相应的方法即可。即使在面向过程的语言之中，对以下的代码：


加入到Environment中的时候，我们只要保证foo->foo(int i)的Binding不会屏敝掉之前加入的foo->foo()的Binding即可。这个既可以通过存放的数据结构来实现也可以通过查找的算法来加以保证。

这本书比较全面地介绍了SharpDevelop的开发原理，写得非常不错，然而中文的翻译版本实在太糟糕了...好在现在它的出版社Apress，提供了免费的电子书下载：

http://www.apress.com/free/content/Dissecting_A_CSharp_Application.pdf

还记得去年圣诞节的那一期Special Holiday Episode 吗？

今年的圣诞节又快到了，所以又出了一个Speical Holiday Episode II，主要介绍了一下在Avalon里怎样自己实现一个类似FlowPanel的东东。

去年节目结束的部分，两人(Don Box and Chris Anderson)自弹自唱了改编后的圣诞歌曲。今年他们再接再励，给大家献上了诗朗诵。这首诗是改编自Clement Clarke Moore的" 'Twas the Night Before Christmas "

大家不妨去看看

最近在根据PSP(个体软件开发过程)的相关内容，统计我每天花在主要活动上的时间。在坚持了大概1个月之后，总算也积累了一定的数据。我发现每天浪费掉的时间还真是非常多。在统计数据里，很少有单次活动超过1个小时的记录，大部分时候总是会被各种各样的事情打断。而且很多时候，你觉得你整整工作了一个下午，但实际的有效时间可能都只有3小时，真是非常惊讶呢。

我发现做这些统计也带来了一些时间安排上的好处。如果你能够比较正确地选择工作单元的单位，就可以根据以前的数据来比较有效地预测将要在花费在某个活动上的时间，从而更合理地安排的日程。

一个时间记录日志，包括以下几列：

日期 开始时间 结束时间 中断时间 净时间 活动 备注 C U

每一行都是一项活动，记录时间的单位为分钟。

其中，C列表示这个活动是否完成了，比如这个活动是读某本书的某一个章节，在C列上打勾表示已经读完了这个章节。

U列表示这项活动完成的工作单元的数目，合理地选取工作单元的单位，才能比较准确地根据过去的数据来预测将来的情况。还是以读书来作例子，你可以选择在活动中读完的页数来作工作单元，也可以选择读完的章节数来做工作单元，然而很显然是页数比较好。通常工作单元选比较小的单位比较好，这样能减少数据的误差。如果所记录的活动是写代码，那么可以使用所写程序的行数来做工作单元。

追踪时间的使用状况还是一个蛮有帮助的过程，大家不妨尝试一下。

看到这个消息的时候，并不觉得十分意外，因为一直觉得《csdn开发高手》的文章质量比较欠佳，买过最初几期之后，就失去了再买下去的兴趣。

然而抛开个案不谈，在《程序春秋》和《csdn开发高手》相继倒下之后，在开发类的技术杂志领域又只下了《程序员》孤军奋战。这多少是一个不怎么健康且值得思考的现象。或许国内确实比较缺乏做技术杂志的土壤，因为似乎并没有很多人是在关注技术，浏览csdn的论坛，你常常会有这样一个感觉：发帖的人通常都只是功利地想解决工作中遇到的问题，甚至把作业放到网上找人代做的都有，但真正讨论技术的却实在太少。如果程序员的整个群体都处于这样一个状况，要找到一本技术杂志的市场，确实非常困难。

好在blog出现之后，多少让人看到了一些改变的希望。像博客园就聚集了一批关注技术的人。或许我们不需要太悲观，要相信事情总会往好的方向上发展。　

最近一直在用VS 2005 express，很多功能都让人爱不释手，然而总还是需要写一些必须运行在.net v1.1上的程序，被迫要去用VS 2003，觉得非常不爽。人果然是容易被宠坏的，越来越懒了　

所以现在就尝试用VS 2005写代码，然后用nant来编译项目。nant有三种改变编译目标平台的方法：

(1)直接在命令行中指定，例如：

        NAnt.exe -t:net-1.1

(2)通过在build文件，对系统属性nant.settings.currentframework赋值来进行指定：

<property name="nant.settings.currentframework" value="net-1.1" />

(3)直接修改nant的配置文件来改变nant的默认目标平台

<frameworks>
<platform name="win32" default="net-1.1">
...
</platform>
</frameworks>

所有支持的平台，你可以nant.exe.config里找到，比如我手头的nant就支持　net-1.0 net-1.1 net-2.0 netcf-1.0 mono-1.0。

直觉上觉得，既然VS2005里的C#已经开始用msbuild来进行后台编译，那么应该也可以支持目标平台的设置，但似乎并没有在vs2005的项目设置里找到相应的选项，对msbuild也不很了解，如果哪位知道，还请不吝赐教。

有时候，你不得不佩服微软的想法！

http://webmessenger.msn.com/

在学习.net编程时，你一定有听到过这样的说法，System.String类是不可变字符串，也就是说你不能修改一个字符串的值。

比如以下这段代码


你并不是把s的值修改为world，而是生成了一个新的包含"world"的字符串，然后令s这个字符串的引用指向新的字符串，而原来的那个字符串就被抛弃掉了。

也正是基于String类的不可修改性，CLR采用了String Interning的技术来共享相同的字符串，以达到减少内存使用的目的。比如以下这段代码


s1和s2其实指向相同的字符串。

那么是不是我们真的没有办法改变一个string的值呢？当然不是，在C++/CLI中，我们可以使用一些特殊的手段来达到我们的目的！

PtrToStringChars(String^)是一个定义在vcclr.h头文件中的一个helper function，它返回一个类型为interior_ptr<const Char>的内部指针，指向String实例内部所包含的字符串，之所以返回类型是interior_ptr<const Char>而不是interior_ptr<Char>是因为不希望我们改变String实例内的字符串，不过既然我们执意要这么做，那么就让我们用一个const_cast<T>来把这个const搞掉！

运行以上代码你会发现，s2现在的内容已经是aaaaa，而不是hello了。

当然，以上例子只是说明存在修改string实例的内容的可能，并不是鼓励大家这么做。虽然直接访问string实例内部的字符串，可能会带来一些性能上的好处。但是由于String Interning的存在，修改String实例内部的字符串是相当危险的行为，比如上面的那个例子中，你会发现，s1的输出也变成aaaaa了！

高中和初进大学的时候，周围总有这么一种论调：好的计算机公司都喜欢招聘数学系或者物理系的毕业生，说是数学功底比较扎实。我的一位学物理出身的长辈曾问我计算机系都学些什么，听了我的描述之后，露出一种不屑的神色，说这些有什么可学的。言下之意似乎只有物理、数学系学的那些东西才算是真正的学问。

然而，既然计算机从数学和物理之中分离出来，成了一个独立的学科，总有它独到之处。那么这个独到之处是什么呢？我觉得不是数据结构，以数学系学生的离散数学知识，我们在数据结构上占不到什么便宜，也正是因为这个，才会有本文开头的那种论调。何况数据结构的复用是做得相当好的，很多人用着STL里的Map、.Net里的HashTable，很好的完成了自己的工作，却不用太注意那背后的红黑树、碰撞处理。

那么除了数据结构的知识之外，要成为一名合格的软件开发者，还需要具备什么样的知识呢？我觉得是面向对象技术和软件工程知识。这两项技术理应成为计算机系学生的优势。然而现实情况实在是令人沮丧。

大学里的课程开设，主干依然是围绕数据结构展开的，软件工程现在总算也是一门主干课程了，但重要性远不如数据结构的一系列课程。而面向对象技术往往只是软件工程课程中的一个章节，有所讲述也往往停留在面向对象技术初始阶段的理论，而完全无视近年的发展。当大家已经承认接口复用的意义，课堂上还在大讲代码复用。当大家已经都在用C++、C#编程的时候，课堂上还在大讲Goto语句的危害性。

面对这样的现实，有的只能是无奈...

     摘要: 如果你不清楚VS 2005的定制Code Expansion的功能，可以看一下我的这篇文章。第一个是用来生成string，其实就是自动生成一对双引号，在中间输入好string之后，按回车可以跳到双引号之后。这个是受了eclipse的启发，不过觉得我的这个更好用，因为输入完字符串之后，不用去按方向键，嘿嘿 <?xml version="1.0" enco... 阅读全文

我在私有新闻组里询问VC2005里是不是会有Refactoring或者Code Expansion的功能，结果得到如下的回复，真是十分遗憾：


Unfortunately, we won't be able to support refactoring or code expansion in
the Whidbey timeframe.  However, we will definitely be revisiting and
considering the feature set for our next release.  It's an important
customer request, and we'd like to implement it if possible.

--
cheers,
Ami Vora
Program Manager, Visual C++

     摘要: 在上篇文章里，我向大家介绍了在VS2005的IDE中，利用code expansion功能，自动生成Property的方法，事实上，在VS2005里已经预制了相当多的用来代码扩展(Code Expansion)的代码片断(Code Snippet)，"prop"就是一个例子。在Tools菜单下，有一个叫作Code Snippets Manager的工具，在里面可以看到预定义的所有的Code Sni... 阅读全文