博客园_1-2-3.cnblogs.com

[javascript]图解+注释版 Ext.extend()

2012-05-21T01:40:00Z

Ext.extend() 体现了程序员非凡的制造轮子的能力。它基于 javascript 古老的对象模型，最大程度地模拟出现代面向对象语言的类型继承的语意。但是在程序界有太多的“与XXX很像”，但是实际上又有很多差别。要想最彻底、最精确地理解 Ext.extend()，最直接（往往也是最有效）的方法就是去读它的源代码。为了达到更好的可读性，我更改了部分变量名称，加上了详细的注释。

  1 /**  2          * <p>Extends one class to create a subclass and optionally overrides members with the passed literal. This method  3          * also adds the function "override()" to the subclass that can be used to override members of the class.</p>  4          * For example, to create a subclass of Ext GridPanel:  5          * <pre><code>  6 MyGridPanel = Ext.extend(Ext.grid.GridPanel, {  7     constructor: function(config) {  8   9 //      Create configuration for this Grid. 10         var store = new Ext.data.Store({...}); 11         var colModel = new Ext.grid.ColumnModel({...}); 12  13 //      Create a new config object containing our computed properties 14 //      *plus* whatever was in the config parameter. 15         config = Ext.apply({ 16             store: store, 17             colModel: colModel 18         }, config); 19  20         MyGridPanel.superclass.constructor.call(this, config); 21  22 //      Your postprocessing here 23     }, 24  25     yourMethod: function() { 26         // etc. 27     } 28 }); 29 </code></pre> 30  * 31  * <p>This function also supports a 3-argument call in which the subclass's constructor is 32  * passed as an argument. In this form, the parameters are as follows:</p> 33  * <div class="mdetail-params"><ul> 34  * <li><code>subclass</code> : Function <div class="sub-desc">The subclass constructor.</div></li> 35  * <li><code>superclass</code> : Function <div class="sub-desc">The constructor of class being extended</div></li> 36  * <li><code>overrides</code> : Object <div class="sub-desc">A literal with members which are copied into the subclass's 37  * prototype, and are therefore shared among all instances of the new class.</div></li> 38  * </ul></div> 39  * 40  * @param {Function} superclass The constructor of class being extended. 41  * @param {Object} overrides <p>A literal with members which are copied into the subclass's 42  * prototype, and are therefore shared between all instances of the new class.</p> 43  * <p>This may contain a special member named <tt><b>constructor</b></tt>. This is used 44  * to define the constructor of the new class, and is returned. If this property is 45  * <i>not</i> specified, a constructor is generated and returned which just calls the 46  * superclass's constructor passing on its parameters.</p> 47  * <p><b>It is essential that you call the superclass constructor in any provided constructor. See example code.</b></p> 48  * @return {Function} The subclass constructor from the <code>overrides</code> parameter, or a generated one if not provided. 49  */ 50 Ext.extend = function(){ 51     // inline overrides 52     var io = function(o){ 53         for(var m in o){ 54             this[m] = o[m]; 55         } 56     }; 57     var oc = Object.prototype.constructor; // 如果一个对象的 constructor == oc，说明它是使用类似 { age:22 } 这种语法创建的字面量对象， 58                                            // 而且没有对constructor属性赋值 59  60     return function(subClass, superClass, overrides){ 61         if(typeof superClass == 'object'){ 62             // 如果 superClass 是对象而不是构造函数，就说明是使用的是 63             // var Cat = Ext.extend(Animal, { 64             //     say : function() { 65             //         document.writeln("I'm a cat name " + this.name); 66             //     } 67             // }); 68             // 这种方式调用的。也就是说返回值是subClass, subClass 参数其实是 superClass，superClass参数其实是overrides，overrides参数应该被忽略 69             overrides = superClass; // 忽略 overrides 参数 70             superClass = subClass; // subClass 参数其实是 superClass 71             // subClass 参数将作为将来的返回值。 72             // 如果 overrides 对象没有自定义构造函数，为其定义一个，并且里面调用父类构造函数； 73             // 如果 overrides 对象含有自定义构造函数，把overrides的构造函数赋给子类 74             subClass = overrides.constructor != oc ? overrides.constructor : function(){  75                     superClass.apply(this, arguments); // 调用父类构造函数（前提是子类构造函数的参数可以比父类少，但是顺序要一致） 76                 }; 77         } 78          79         // 原型式继承。之所以创建一个临时构造函数F，而不是令 subClass.prototype = new SuperClass， 80         // 是为了更改子类的prototype的时候不会影响到父类的prototype 81         var F = function(){}, 82             subPrototype, // 子类构造函数的 Prototype 83             superPrototype = superClass.prototype; // 父类构造函数的 Prototype  84  85         F.prototype = superPrototype; 86         subPrototype = subClass.prototype = new F(); 87         subPrototype.constructor=subClass; 88         // 只所以没写成 subClass.superclass=superClass，是为了在overrides对象的constructor方法里 89         // 可以使用诸如 “MyGridPanel.superclass.constructor.call(this, config)”这种（读起来比较 90         // 自然的）写法调用父类构造函数。 91         subClass.superclass=superPrototype; 92         // 如果 superclass.prototype 是字面量对象，确保 superclass.prototype。constructor 指向 superClass 93         if(superPrototype.constructor == oc){ 94             superPrototype.constructor=superClass; 95         } 96         // 为子类增加一个override()方法。调用　subClass.override(o) 等价于调用 Ext.override(subClass, o) 97         subClass.override = function(o){ 98             Ext.override(subClass, o); 99         };100         // 增加一个名为 superclass() 的实例方法，这样在overrides对象的constructor方法里101         // 就可以使用诸如 “this.superclass().constructor.call(this, config)”来调用父类102         // 构造函数，而且没有依赖子类构造函数的名称。103         subPrototype.superclass = subPrototype.supr = (function(){104             return superPrototype;105         });106         // 为子类增加一个实例方法: override()107         subPrototype.override = io;108         // 将 overrides 对象里的方法复写到 subClass.prototype 中109         Ext.override(subClass, overrides);110         // 为子类增加一个extend()方法。调用　subClass.extend(o); 等价于调用 Ext.extend(subClass, o);111         subClass.extend = function(o){return Ext.extend(subClass, o);};112         return subClass;113     };114 }();

下面这张对象图则是执行了 var SubClass = Ext.extend(SuperClass, { someprop : 'some' }) 之后的效果。

本文链接

Oracle 数据库隔离级别，特性，问题和解决方法

2012-04-05T01:56:00Z

“……老手根本就不会照着指示去做，他边做边取舍，因此必须全神贯注于手上的工作，即使他没有刻意这样做，他的动作和机器之间也自然有一种和谐的感觉。他不需要遵照任何书面的指示，因为手中的机器给他的感觉决定他的思路和动作，同时也影响他手中的工作。所以机器和他的思想同时不断地改变，一直到把事情做好了，他的内心才真正地安宁下来。”
“听起来好像艺术一样。”
——罗伯特·M.波西格《禅与摩托车维修艺术》

如果没有任何数据库隔离策略，在多用户（多事务）并发时，会产生下列问题：
- 丢失更新（lost update）：两个事务同时更新同一条数据时，会发生更新丢失。
例如：用户A读取学号为107的学生（学号=107，姓名=“小明”，年龄=28）
=> 用户B读取学号为107的学生（学号=107，姓名=“小明”，年龄=28）
=> 用户A把姓名更改为“王小明”（学号=107，姓名=“王小明”，年龄=28）
=> 用户B把年龄更改为33（学号=107，姓名=“小明”，年龄=33）
=> 用户A提交（学号=107，姓名=“王小明”，年龄=28）
=> 用户B提交（学号=107，姓名=“小明”，年龄=33）
用户A对学生姓名的更新丢失了。
- 脏读（dirty read）：当一个事务读取另一个事务尚未提交的修改时，产生脏读。
例如：用户A读取学号为107的学生（学号=107，姓名=“小明”，年龄=28）
=> 用户A把姓名更改为“王小明”（学号=107，姓名=“王小明”，年龄=28）
=> 用户B读取学号为107的学生（学号=107，姓名=“王小明”，年龄=28）
=> 用户A撤销更改，事务回滚（学号=107，姓名=“小明”，年龄=28）
这样用户B相当于读取了一个从未存在过的数据“王小明”。如果涉及到金额的话问题更为严重，因为用户B读取了一个金额之后，很可能把这个金额与其它金额累加，再把结果保存到汇总数据之中，这样在月底对不上账的时候，由于用户A回滚了事务，数据库内不会有任何操作记录，这样用户B是何时、从哪里读取了错误数据根本无从查起。
- 不可重现的读取（nonrepeatable read）：同一查询在同一事务中多次进行，在此期间，由于其他事务提交了对数据的修改或删除，每次返回不同的结果。
例如：假设学生表里只有“小明”和“小丽”2条记录（小明.年龄=20，小丽.年龄=30）。如果用户A把“小明.年龄”更改为40、把“小丽.年龄”更改为50并提交事务。在用户A修改数据并提交前，学生的平均年龄为(20+30)/2=25；在用户A修改数据并提交后，学生的平均年龄为(40+50)/2=45。
现在考虑在用户A更新 2 名学生的年龄时，用户B执行了一个计算平均年龄的事务：

如前所述，在用户A修改数据并提交前，学生的平均年龄为(20+30)/2=25；在用户A修改数据并提交后，学生的平均年龄为(40+50)/2=45。用户B计算得出的平均年龄是 25 或 45 都是可以接受的，但是在上例中用户B计算得出的平均年龄 35 是从未出现在系统中的错误数值。
- 幻读（phantom read）：同一查询在同一事务中多次进行，由于其他提交事务所做的插入操作，虽然查询条件相同，每次返回的结果集却不同。

事务B使用相同的条件进行了2次查询/筛选，一次是为了向费用结算表插入汇总数据，一次为了确定对费用明细表的更新范围。在这两次筛选之间，事务A提交了一条新的费用明细数据，导致两次筛选的结果不一致。

隔离级别

为避免上述并发问题，ANSI/ISO SQL92标准定义了一些隔离级别：

- 读取未提交数据（read uncommitted）

- 读取已提交数据（read committed）

- 可重现的读取（repeatable read）

- 序列化（serializable）

通过指定不同的隔离级别，可避免上述一种或多种并发问题，见下图。

细心的读者可能已经注意到上图不包括“丢失更新（lost update）”，这是因为“丢失更新”问题需要使用乐观锁或悲观锁来解决，超出本文范围，先不详述。

Oracle 的隔离级别

SQL92定义的隔离级别在理论上很完善，但是 Oracle 显然认为在实际实现的时候并不应该完全照搬SQL92的模型。
- Oracle不支持 SQL92 标准中的“读取未提交数据（read uncommitted）”隔离级别，想要脏读都没可能。
- Oracle 支持 SQL92 标准中的“读取已提交数据（read committed）”隔离级别，（这也是Oracle默认的隔离级别）。
- Oracle不支持 SQL92 标准中的“可重现的读取（repeatable read）”隔离级别，要想避免“不可重现的读取（nonrepeatable read）”可以直接使用“序列化（serializable）”隔离级别。
- Oracle 支持 SQL92 标准中的“序列化（serializable）”隔离级别，但是并不真正阻塞事务的执行（这一点在后文还有详述）。
- Oracle 还另外增加了一个非SQL92标准的“只读(read-only)”隔离级别。

Oracle的序列化（serializable）隔离级别

序列化，顾名思义，是让并发的事务感觉上是一个挨一个地串行执行的。之所以说是“感觉上”，是因为当2个事务并发时，Oracle并不会阻塞其中一个事务去等待另一个事务执行完毕再执行，而是仍然让2个事务同时并行，那么如何能“感觉”是串行的呢？请看下图的实验。

用户B的事务因为指定了serializable隔离级别，所以虽然在查询费用明细表之前，用户A提交了对费用明细表的更改，但是因为用户A提交的更改是在用户B的事务开始之后才提交的，所以这个更改对用户B的事务不可见。也就是说，用户B的事务开始之后，其它事务提交的更改都不会再影响事务内的查询结果，这样感觉上用户A的事务好像是在用户B的事务结束之后才执行的似的。这本来是非常好的一个特性，极大地提高了并行性，但是也会造成问题。

问题1：Oracle的这种“假串行”会让严格依赖于时间的程序产生混乱。

请看下图这个例子，对费用结算的例子稍稍做了一点改动。

程序员的本意是统计2012-3-4这天从零点至运行程序之时的费用总额。如果他以为 Oracle 的 serializable 会像 C# 的 lock 一样阻塞其它事务的话，就会对结果非常吃惊：在2012-3-4 0:00 ~ 2012-3-4 10:02 实际有3条费用明细，总额为20+30+100=150，而不是用户B的事务统计得出的50。

问题2：ORA-08177 Can't serialize access for this transaction (无法序列化访问)错误。

如果你使用了 serialize 隔离级别，没准你的客户会经常抱怨这个随机出现的错误。兄弟，你并不孤独！
导致这个错误的原因有2个：
(1) 两个事务同时更新了同一条数据。你可以这样重现这个错误：事务B开始（使用serialize 隔离级别) => 事务A开始，更新表1.RowA 但不提交 => 事务B更新表1.RowA，因为行锁定而被阻塞 => 事务A提交 => 事务B报 ORA-08177 错误。
(2) 事务所更新的表的 initrans 参数太小。Oracle 官方文档的说法是，如果使用了 serialize 隔离级别，表的 initrans 参数最小要设置成3（默认是1）。

alter table 费用明细表 initrans 3;

原文：“Oracle Database stores control information in each data block to manage access by concurrent transactions. Therefore, if you set the transaction isolation level to SERIALIZABLE, then you must use the ALTER TABLE command to set INITRANS to at least 3. This parameter causes Oracle Database to allocate sufficient storage in each block to record the history of recent transactions that accessed the block. Higher values should be used for tables that will undergo many transactions updating the same blocks.”
注意，人家说的是“最小是3”。我用自己笔记本里的 32 位 Oracle10g 测试的结果是设置成 3 也会频繁地报 ORA-08177 错误。后来改成5 和 10，都不行。改成50，终于不报错了。但是都说了这个错误是随机的，有时候3也没问题的——反过来说，设置成50也未必保险。坑爹啊！真坑爹！！这就像菜谱里面写的“放入适量的油……”，他喵的到底多少算是“适量”啊？！！！
有兴趣的读者可以使用下图的语句实际测试一下。

我的建议是，还是尽量不要用 serialize 隔离级别吧，用户是不会理解什么叫“无法序列化访问”的，他只会觉得你的“XX功能会随机地不好用”倒是真的。稍后我们再简单讨论一下不用 serialize 隔离级别如何避免幻读。现在先来看一下 Oracle 官方文档建议的适合使用 serialize 隔离级别的3种情况。

(1) With large databases and short transactions that update only a fewrows（大数据库、只更新几条数据的短事务）

(2) Where the chance that two concurrent transactions will modify thesame rows is relatively low（2个并发事务更新同一条数据的几率不大）

(3) Where relatively long-running transactions are primarily read only（相对运行时间较长的事务主要用来读取数据）

使用默认的 read committed 隔离级别，如何避免幻读产生的问题

使用默认的 read committed 隔离级别，如何编写程序才能避免幻读产生的问题呢？首先，无论是“不可重现的读取（nonrepeatable read）”还是“幻读（phantom read）”，都是因为程序反复读取数据产生的。所以首先需要做的是，在一个事务里确保只读取数据一次。最好用C#而不是存储过程实现业务逻辑，这样很容易做到只读取一次，然后把结果存放到IList或IDictionary里。比较难办的是需要更新数据的情况。回顾一下前面所举的幻读的例子。

事务B使用相同的条件进行了2次查询/筛选，一次是为了向费用结算表插入汇总数据，一次为了确定对费用明细表的更新范围。在这两次筛选之间，事务A提交了一条新的费用明细数据，导致两次筛选的结果不一致。要避免这个问题，还是要贯彻“只读取一次”的原则，或者更广义地说，是“只确定一次筛选范围”。大致有2种方法。
<法一> 可以先把符合条件的费用明细读取出来保存到一个列表里，然后无论统计还是更新，都局限于这个列表里的数据。下面的C#代码与上图的功能相同，但是没有幻读的问题。

// 用户B的事务开始

IList<费用明细> chargeList = 费用明细Repository.获取未结算列表();
费用结算 balance = new 费用结算 
{
    总金额 = chargeList.Sum(t => t.金额),
    结算编号 = "J122"
};
费用结算Repository.Save(balance);

// 这时候用户A提交了一条新的费用明细，不过没关系

foreach(费用明细 charge in chargeList)
{
    charge.是否已结算 = 1;
    charge.结算编号 = "J122";
    费用明细Repository.Update(charge);
}

这个方法的缺点是要对 chargeList 里的每个实体 Update 一次，如果数据量较大可能会有性能问题。这时候可以用<法二>。
注本文为了表述的方便使用了中文和英文混杂的代码，实际编程的时候不要这样做。
<法二> 使用事务B独有的方法标识出操作数据的范围。

注虽然上图是用SQL语句来演示的，使用C#（实体+ORM）同样可以用这种方法。

严格依赖时间的程序

严格来说这并不是幻读造成的问题——事务A还没提交呢。这种设计十分危险，无论使用 read committed 还是 serializable 隔离级别都不足以避免并发造成的不一致，应该尽量避免这样的设计。依赖时间很危险，因为系统时间是随时可能被系统管理员更改的，更别提有些国家和地区会实行夏时制，想想看，事务B提交了之后，系统时间被回拨了1小时！
然而世事往往不尽如人意，你可能不幸遇到了这样一个遗留系统，或者用户有很多其它的业务或与你交互的系统严格依赖于时间而逼得你不得不这么做的时候，该怎么办呢？
<法一> 在业务逻辑层面，可以把用户B和用户A的两个方法使用C#提供的线程同步技术串行化——理论上行的通，但是操作费用明细实体的方法那么多，很容易有所遗漏。
<法二> 在Repository层面，为费用明细实体设置一个令牌，并且可以设置是否进入令牌模式。在令牌模式下，费用明细Repository里面的所有持久化操作都必须拿到令牌才能操作，拿不到令牌直接抛异常。平时的业务操作都在非令牌模式下工作。在用户B想要进行结算操作时，事务开始之后，马上设置成令牌模式，然后获取令牌，这样就能确保此时只有用户B才能操作费用明细表了。此法虽然并发性很差，但是既简单又保险。而且很多时候像结算这样的操作一个月（或一天）只进行一次，并发性差一些也可以忍受。值得注意的是下面这种情况。

虽然发生的概率不高，但是让令牌法彻底失效了。综合考虑系统时间被管理员改变的可能性，仅仅在结算事务里独占令牌也是不够的，还必须在费用明细Repository.Save()方法里验证费用明细.创建时间必须大于最近一次的结算时间。

本文链接

[双板滑雪]教学视频和技术贴精选

2012-03-08T01:43:00Z

教学视频

1. 央视教学片http://www.youku.com/playlist_show/id_1526075_ascending_1_mode_pic_page_1.html
共21集，讲解非常详尽，但是从另一方面讲，它太长了，掺杂了各种花里胡哨的东西，其实捞干的4集足够，需要些耐心才能看完。从犁式到半犁式再到平行式，打好基础，循序渐进。缺点是没讲刻滑，对大回转和小回转也是一带而过。另外想要吐槽的一点是里面的练习花样繁多，但多是摆出姿态让你模仿，很少讲背后的原理和发力的方法。这就像只把打狗棍法的招式摆给你看，却不教你心法。这是双板教学片的通病，也是学习滑雪的难点之一。因为滑雪的发力动作短暂（有的不到半秒钟）而且发力动作幅度很小，往往隐藏在教练厚厚的雪服里面，不特意指给你看你根本注意不到。所以当我们想要模仿教练的动作的时候，就会发现不是怎么也做不出来，就是做到了8、9分像却总是差那么一点点，怎么也搞不明白差在哪。曾经看过一个日本的单板教学片，里面的教练会特地在室内把雪鞋脱掉，把雪裤挽到膝盖以上，然后一边在一个小窗格里慢放雪上的动作，一边在室内讲解脚部和全身是如何发力和协调的，这样的双板教学片至今还没遇到。所以童鞋们要想学好滑雪的话，要么找到循循善诱的好教练，要么只能把本文里面所有的视频全看一遍，再结合技术帖，自己好好琢磨啦。
练习方法：先在初级雪道上把犁式和半犁式练熟。从半犁式到平行式的过渡最好去稍缓一些的中级雪道上练习，因为滑平行式最好要有小跑以上的速度，雪太薄也不利于练习。

12 Steps to ski like a pro http://www.youku.com/playlist_show/id_5558115.html

2. 丸山贵雄教练的纵滑的几种练习方法 http://www.tudou.com/programs/view/9kyuQGC0Kn8/?resourceId=0_06_02_99
一些不错的搓雪练习。

3. 佐藤久哉教练的刻滑入门http://www.tudou.com/programs/view/lzyvc802ku0/?resourceId=0_06_02_99
强烈推荐！练习滑雪，找到简单有效、能让你循序渐进的一套练习方法是至关重要的。很多教学视频看上去特别NB，但是里面练习方法很多，有些难度也较大，入门选手很容易抓不住重点。反观这个视频只有12分钟，涵盖carving入门、几种单脚carving练习和bending。每种滑法都有2、3种简单而有效的练习方法。看了这个视频的第一感觉就是，原来carving和bending一点也不神秘！
正如这个教学片的名字所表达的，它的重点是carving入门滑法。我觉得它最有价值也最让我喜欢的地方是，他是先教你做核心技术（换刃）的练习，然后再一次一个地加上辅助动作，这样初学者就不会因为动作太多太复杂而顾此失彼。先把核心技术练好、定型，然后再加辅助动作，这才是最有效的练习顺序。特别是一开始的双手扶膝练习一定不要跳过，它可以很好地控制你的上身姿态和转换重心时身体的协调性。我实际练习的时候感觉第二个板子与肩同宽的练习相对容易些，反而第一个板子分开较宽的练习比较难，很容易摔倒。可以先做第二个练习，不过如果板子比较宽的练习总摔倒的话，说明你的动作还是有做得不对的地方，可以作为对你的技术动作的一个很好的检验。
刻滑内涵丰富，需要练习、注意的细节很多。这个视频只是用来入门，很多重要的细节，包括转弯的不同阶段的连接技术，双板的重心分配，手部动作都没有详细介绍。有兴趣练刻滑的童鞋还要多看后面的视频和技术贴。
很多童鞋可能跟我一样，练搓雪平行式总练不利索，看到有高手练刻滑很羡慕，就急着也开始试着刻滑。特别是男生，有运动基础的，一走刃感觉也挺像那么回事，就一路练下来了。但是刻滑的很多发力方法和重心的转换与搓雪是一样的，如果搓雪练不好，刻滑很快就会遇到难以突破的瓶颈。这时候建议再开始练搓雪。因为搓雪的动作频率比刻滑慢，也容易把动作分解开来练，把搓雪的发力方法搞明白了，对刻滑会有很大帮助。
小贴士 所谓carving，直译为卡宾转弯，意译为刻雪转弯或刻滑(有时也会直接管它叫“走刃”)，是利用carving雪板的特性作出快速转弯的技术。所谓carving雪板，是指板头宽、板腰窄、板尾宽的那种雪板——怪坡滑雪场的就是，东北亚的那种鸟板估计够呛。这种雪板，在立刃的时候受到下压力时，雪板将弯曲成弧线，不需要做其它的多余动作就可以自然、迅捷地完成漂亮的弧形转弯。

佐藤久哉的另一个很细致的教程，可惜没字幕 http://www.tudou.com/programs/view/KKWWuGoLjnc/?fr=rec1

4. 丸山贵雄教练的纵滑的前后动 http://www.tudou.com/programs/view/Vs684off4EE/?fr=rec1
这个视频专门讲解转弯的第1阶段（从斜滑降轻身之后到雪板指向滚落线），非常细致。

5. 柏林义之教练的大弯滑法 http://www.tudou.com/programs/view/1DaMtuIWMl4/?resourceId=0_06_02_99
非常细致地讲解刻滑大弯的各个阶段的重心和动作，适合已经初步掌握刻滑，想要滑出更漂亮、规范的动作的童鞋。（可惜没字幕）

6. 一个马脸帅哥的教学视频 http://v.youku.com/v_show/id_XODQ3MDE3ODA=.html
包括大回转、小回转和点杖。一开始感觉讲得不太细，后来才发现里面有很多不错的要点，包括站姿、重心、上身动作，练习也很不错。

7. Greg Gurshman 教练的刻滑大、小回转教学 http://www.tudou.com/playlist/id/14026280/
慢动作拍摄得非常好。没字幕和讲解，理论部分可参考本文最后的技术贴。

8. Lito Tejada-Flores教练的 a private lesson with Lito Tejada-Flores http://v.youku.com/v_show/id_XNjQ1NjUyNzY=.html
1个小时全是单脚carving的多角度慢动作。教练的动作很优美，没字幕，甚至也没多少讲解。

9. 佐藤久哉教练的小弯入门 http://www.tudou.com/programs/view/V7n1PZ4tIN8/?fr=rec1
与刻滑入门一样，佐藤久哉一如既往地简明、独特。特别是里面的点杖练习非常独到，想练点杖小回转的童鞋一定得看看。

朴教练的小回转教学 http://v.youku.com/v_show/id_XMjQwNjM0NDgw.html

10. 六种小回转技术 http://v.youku.com/v_show/id_XMzE0NzU5Njgw.html
里面的练习都很有效，后面几个难度稍大，但是游戏要是只有3关岂不是会很没追求？

11. 渡边一树教练的猫跳入门 第一部分，第二部分
很细致的蘑菇教程。里面有很好的搓雪练习，即使你暂时还不打算挑战蘑菇也值得一看（特别是6:30开始的180及360度搓雪练习）。

12. 丸山贵雄教练的深弧小弯 http://www.tudou.com/programs/view/tCF6D37tlEA/?resourceId=0_06_02_99
所谓深弧小弯是指在陡坡上使用搓雪和刻滑相结合的技术作出快节奏、大弧度的转弯。里面有很多非常独特的练习点杖的方法，连我这个严重的点杖恐惧症患者看了之后都忍不住想要练习一下了。

13. 滑雪表演串烧 http://www.tudou.com/programs/view/qbN1bTAN74c/?resourceId=0_06_02_99
4:00开始的那段雪上舞蹈真是酷毙了。视频的最后还非常体贴地录了一段摔跤集锦，意思是你看那么多高手也摔得啪啪地。
超酷的雪上芭蕾，神乎其技：http://www.tudou.com/programs/view/vW9RwLPCutA/

14. 非常清晰的大、小回转慢动作视频
大回转：http://www.tudou.com/programs/view/yEMSmc2D0M0/?resourceId=0_06_02_99
小回转：http://www.tudou.com/programs/view/9zjU6BciRWY/?resourceId=0_06_02_99

15. 大小回转欣赏
http://www.tudou.com/programs/view/x7a17mPc2d4/?fr=rec1
http://www.tudou.com/programs/view/T42Iij0xRZI/?fr=rec1

16. 野雪教程
野雪教程-第一部分基本练习 http://www.tudou.com/programs/view/KUxaCFXGZyE/?resourceId=0_06_02_99
野雪教程-第二部分实用技巧 http://www.tudou.com/programs/view/IiDr_SKlQQQ/?resourceId=0_06_02_99

技术贴

1. 滑雪中的连接技术：出弯、入弯和转换

2. Greg Gurshman 教练的几篇非常精辟的文章
    内侧板在现代竞技转弯中的应用
    现代高山滑雪竞技技术
    一个利用S弯和香蕉弯提高大回转转弯技术的方法
    现代技术的趋势——神话和现实

3. NPS自然能量滑雪学习体系（进阶衔接部分：图解雪板转弯的奥秘）
    布鲁狼的理论讲解非常给力，特别是里面配的手绘的图特别好，非常有才。
    Carving 基础

4. 《点杖小回转》之 “揭开新的篇章--扭转”
    《点杖小回转》之二 “如何用好三板斧”
    滑雪葵花宝典之《点仗心经》
    布鲁狼的讲解比较独到的地方是，他不是一开始就告诉你最标准的全套动作是怎么样的，而是给你一些练习让你自己去实验不同的动作出来的效果，然后再讲解发力的方法和原理，非常难得。

5. 一篇很不错的野雪教程 http://blog.sina.com.cn/s/blog_489d12ef0100kq1m.html

6.  登山滑雪装备概述 http://bbs.lvye.cn/thread-354353-1-1.html
     登山滑雪装备最新发展趋势 http://bbs.lvye.cn/thread-356322-1-1.html

(持续更新...）

本文链接

[日记]夜滑

2012-03-04T15:17:00Z

拉开车门准备下车的时候，我对小驰和夜场大哥说“明年见！”。我们开怀一笑，心里隐隐觉得这回也许又要食言。
追着雪季的尾巴接连滑了好几次夜场，今天是最后一次。

从雪具大厅出来，往魔毯上走的时候挺费劲，因为要越过一个结了冰的小陡坡，雪板不容易刻住雪，用雪杖小心地支着往上蹭的样子挺笨拙。这时候，一个玩单板的家伙指着我跟他的同伴说，“你看你看，就这种连走都走不明白的就别上中级道了，还往上上……”当时真把我气得够呛，心想滑雪要是像篮球那样也能单挑就好了，咱俩比比到底谁技术好。不过后来转念一想，他刚刚被一个新手狠狠地撞了一下胳膊，也算是受害者。其实任何运动都一样，你老是得忍受那些一瓶不满、半瓶晃荡的伪高手们脆弱的自尊心。
所以，脸皮厚很重要。
为什么这么说呢？初学者都希望能尽快进入中级水平，这是人之常情。进入中级水平之后，往往就会因基本功不好而遇到瓶颈。这时如果害怕被伪高手笑话而不好意思从头练基本功的话，就很难突破瓶颈。不拍摔跤固然可贵，不怕笑话才是难得。
胆大，心细，脸皮厚，业余滑雪爱好者三大天赋是也。

本文链接

[推荐]番茄工作法——专治拖延症、精神涣散、再要五分钟综合症

2012-01-18T01:51:00Z

首先向仍然在工作岗位上奋战以及回到家还不忘刷博客园的兄弟们致敬。
最近读了一点《The Clean Coder》，一个意外的收获是，知道了原来还有个“番茄工作法”。尝试了几天，觉得很有效，推荐给你。
XX工作法，一听这名字你就能猜到，是时间管理，而时间管理又往往等同于成功学，所以你看了标题之后习惯性地无视本文的话，我也不怪你。成功学没有效果，是因为每个人的特质、境遇都不相同，成功往往无法复制。相反的，想办法改掉自己的一些坏习惯会更有效果。
我同时患有严重的拖延症、精神涣散和再要五分钟综合症，用了番茄工作法之后，好转了很多。
先说说我的病情。
拖延症——一直在心里想着“那件事必须得做了”，可就是迟迟不能开始。越是困难的、重要的事情，越容易这样。
再要五分钟综合症——无论娱乐还是工作，都容易烂尾。想好了娱乐到9点就工作，结果拖拖拉拉到10点还没开始干正经事；下定决心要在11点之前睡觉，但是天天都会磨蹭到11点半，12点还没上床。
精神涣散——我们都知道打断的危害。但是仔细想想，被别人打断的次数远没有被自己打断自己的次数多。譬如编译程序的时候，感觉好慢呐，赶快趁机刷下微博或者豆瓣吧，然后看到网友上传了美女图片，呦，韩寒写了新博客啦，完了又想起周报还没写呢……
这三种毛病综合发作的结果就是，整天愁眉苦脸、心急火燎，好像忙忙叨叨累的不行，到了该睡觉的时候却发现其实没干多少正经事，越发舍不得睡觉。脸色苍白，目光空洞，神疲气短，恶性循环。

番茄工作法

番茄工作法用一句话来概括就是——工作25分钟休息5分钟。详细条款如下：
0. 准备工作：买一个厨房计时器，或者使用软件计时器也行（pc，mac，iphone，Android）。
1. 把计时器设定为25分钟，开始工作，直到响铃，算工作了一个番茄时间。然后在你的本子的工作项后面画一个叉叉表示此项工作已经耗费了一个番茄时间（如果使用软件会自动记录，更为方便）。
在一个番茄时间内，不可以被打断。这意味着等待编译的时候也不可以刷微博，也不要去泡咖啡或者吃东西。如果想到周报还没写，在本子上记上“需要写周报”然后马上回到工作中。如果有同事打扰你或者接到客户的电话，礼貌地请求他等待20分钟，在本子上记上“需要给王科长回电话”然后马上回到工作中。当然有时人家也会大喊一声“我等不了了！”，需要你立即紧急处理，那么这个番茄时间就相当于白费了，回到工作中时要重新开始这个番茄时间，就当这个番茄时间从来没有开始过。响铃之后，你就可以看一下你的本子，处理刚刚记下的事情。如果这些零碎的小事很多，可以开启一个番茄时间集中处理它们。
在一个番茄时间内，只做一件工作。如果工作了20分钟就完成了，也不要开始下一项工作或者去娱乐，可以回顾一下，检查/测试，总结经验，做一些优化或美化。如果工作了5分钟就完成了，而且你觉得它本可以在上一个番茄时间里就完成的，并且再去复查一遍也没什么必要，可以将这个番茄时间作废。
2. 休息5分钟。
响铃之后必须立即停止手中的工作，想象你在考试，时间到，马上停笔。即使你觉得在休息的几分钟里就能完成它，也不能继续工作。而且，脑子里也不要再去想任何有关你工作的事情。这其实挺难做到的，我的建议是——离开你的座位——去做运动，或者跟同事聊聊天。
3. 每4个番茄之后休息15分钟。
如果感到疲劳，也可3个番茄就长休一次。或者把休息时间延长，但是不应超过25分钟。

更为详细的内容可以参考网站，电子书英文版，中文版（仅32页，值得一读）。番茄工作法由意大利人Francesco Cirillo(弗朗切斯科•齐立罗)发明于1992年。因发明人最开始使用的是番茄形状的计时器而得名。

番茄工作法的好处

健康。这个世界上有太多好玩的事情让人目不暇接。今晚有NFL季后赛野马vs爱国者耶，另外巴萨的比赛也不能错过，还有NBA快船vs湖人也想看一看。《The Clean Coder》看了一半不能扔下，还想再研究下ios编程……一件接着一件，一直不休息，直到累得实在难受才去床上趴一会儿，要么睡不着要么一睡不起。这种被动的休息方式对健康极为不利。最好的休息方式是在感到累之前就做短暂的休息。
保持大脑的活力。由于特定的生化原理，大脑内每个神经元都只能连续工作几分钟，之后就必须休息。连续的娱乐和工作会让大脑处于一种麻木、呆滞的状态。番茄团队经过大量研究发现，为保持大脑的活力和效率最大化，最佳番茄时间为25～35分钟。我们大多数人连续工作的时间都是1小时或2小时，所以直觉上会怀疑25分钟的工作时间是不是短了点？会不会刚刚进入状态就被休息打断了？其实，5分钟的休息并不会中断你的思路，反而可以让大脑里的清洁工有时间打扫战场，给脑细胞做做马杀鸡，之后你会文思泉涌也说不定。
成就感。每个番茄代表一个纯的25分钟的工作时间。每天数一下番茄数就知道自己做了多少有用功，对每项工作耗费了多少时间也会有更具体的感觉。你可以知道自己娱乐了几个番茄，看了几个番茄的书，做了几个番茄的练习，对时间更有掌控感。
安全感。你可以安全地先娱乐一个番茄，然后再看一个番茄的书，不必担心一娱乐起来就停不下。
专心。娱乐的时候想着工作，工作的时候不忘娱乐，这是我们大多数人的工作方式，也是低效和焦虑的根源。稀里糊涂地就到了下午，到了晚上，计划难以完成，好像做了很多额外的事情，却又想不起来都干了些什么了。要想摆脱精神涣散的阴影，必须明确地强迫自己“一次只做一件事情，并且必须连续做25分钟”。
张弛有度。根据我的经验，对于一个严重的“再要五分钟综合症”患者，只是自己在心里想着“到九点就休息”是不够的，到时候不是差一点没完成，就是有了新的兴趣点。借助于计时器和“铃声响起立即停止”条款，才能干净利落地根治此症。
不再拖延。拖延症患者大多喜欢追求完美。越是想要做得好，就越容易否定自己，觉得没思路，不够好，信心受挫之下更容易精神涣散。使用番茄法，按下计时器，叮咚，强迫自己没思路也不许干别的，就算干想也要想满25分钟。

娱乐也番茄

书里说空闲的时间就不要用番茄法了。但是我的问题是，因为我觉得刚刚吃饱就工作不太合适，总想先娱乐一会儿。可是一旦娱乐起来就停不下来，所以我想娱乐也可以使用番茄法。比如“看一个番茄的电影”，或者“看一个番茄的比赛”，之后休息五分钟。这样既有利于健康，也有机会决定之后是继续娱乐一个番茄，还是工作一个番茄。

番茄你的计划

把番茄法与你的工作计划结合起来也很简单，就是使用番茄数作为工作项的时间单位。首先，你可以通过经验知道你每天平均能做几个番茄的工作。然后，估算每个工作项需要的番茄数，这样你就能知道明天可以完成哪几个工作项了。每天结束的时候，再回顾一下每个工作项实际使用的番茄数。简单实用，是吧？
也许你还没有做计划的习惯，番茄法可以给你一个很好的起点。因为在按下计时器的开关之前，必须先想好“只能做一件事情呐，这个番茄我要做什么？” 这样子，逐渐的升级为“上午的3个番茄我要做什么？”随着你的技巧越来越娴熟，你会有能力并且愿意做全天的计划，一周的计划——不是随便写写、应付领导的，也不会写完就丢在一边，而是真正切合实际，容易跟踪和度量，通过不断的反馈得到改进的计划。
贴士一个工作项最多5到7个番茄，如果多于这个数，就认为这个任务太过复杂，最好把它分解为几个小任务。如果一个工作项的估值小于一个番茄，把它与其它的小任务组合成一个大任务。
小贴士 你可以在做计划的时候用空心方框“[]”表示一个番茄时间，3个番茄时间就是“[][][]”，把它标记在工作项的后面。实际工作时，每耗费一个番茄时间就在空心方框里打个叉叉，耗费2个番茄时间是就是“[x][x][]”，耗费4个番茄时间时是“[x][x][x]x”）。

本文链接

东芝の印象

2011-09-12T12:18:00Z

1.

东芝有两个挺气派的厂房。说它气派，主要是因为它有好几个又高又宽，大大的卷帘门——方便用卡车直接把电梯运出去。卷帘门平常是关着的，按规定也不允许人走，我每次只能很委屈地走两侧普普通通的、一比较起来就显得很寒酸的小铁门。“要是卷帘门完全敞开了，直接从那么大的门走进去，哇，不知道有多爽呢。”每次深吸一口气弓着腰去拽小铁门的时候我都这么想着。功夫不负有心人，机会是给有准备的人的，总之，有一天我发现了一个大敞着的卷帘门，顿时心中一亮，小鹿乱撞，急忙小跑着过去，四下打量了一下没人，“咻”的一下就穿了过去。可是并没有多爽，反而因为担心挨骂以及头上的卷帘会突然砸下来而提心吊胆的，再说那个过程太快了，也根本来不及爽。唉，想象中美好的东西多半不是那么回事。但是，以后只要发现了敞开着的卷帘门，我还是会四下打量一下然后“咻”的一下穿过去，因为放着现成的、大大门的不走，非要费劲巴力地拽开小铁门走进去，那是多么的白痴啊。

2.

我喜欢聊天，和美女聊天，自由自在、无拘无束的聊天，我喜欢东芝的聊天文化。当然东芝高管们的字典里可没有这一条，要是他们知道聊天成了企业文化不知道会不会气得翻白眼？那时我刚刚步入职场，业务、人头都不熟，整天干坐着心里空落落地挺不好过，看着别人忙这忙那只能干瞪眼。那时候，桌子还是四张四张拼在一起，我对面正巧坐着宁宁和蓉蓉两位美女。我们一开始就聊得挺开心，每天都能聊上一个多小时。我印象最深的是每次宁宁都会特意把脑袋从大大的显示器后面探出来，这对她来说是很自然的事情，但是我总觉得得到了特别的尊重和关注，每次心里都特别高兴。
在东芝，拉家常是一项必备的工作技能。可能因为前身是老国企的缘故，这里到处都洋溢着一股子慵懒——倒不是说大家都很闲——早就不是国企了，大家其实都挺忙，压力也不小，但是就像英国的绅士以不工作为荣，这里每个人见了面都憋着非得拉几句家常不可。每次跟宁宁去别的部门办事，她们都得聊上至少半小时，而我就像被聊得热乎的家长们撇在一边的小孩子，站也不是、坐也不是。
我们聊得多了梁部长会感觉很不爽。有一次开会的时候他就拉着脸说让我们注意工作气氛，那以后他在屋里的时候我们就不怎么聊了。过了一段时间，又开会，梁部长说你们全是年轻人怎么一天到晚死气沉沉的，都没人说话的……我们全部晕倒。

3.

我在东芝呆了五年，跟许多日本人打过交道，由于种种原因相处得不太愉快，有时候我甚至气得骂脏话，日本人估计也会说些不好听的，但是我从没听他们说过“巴嘎”，一次都没有，多奇怪！在动画片里不是也经常出现这个词的么？为什么来中国就不说了呢？我真后悔没直接问他们。是不是来中国前受过培训呢？（要是他们真对我说了这个词不知道我会是什么反应）我知道每个日本人来中国之前都会有短期培训，学一些简单的会话，以及注意事项什么的，这种细致的工作作风挺让人佩服。很多日本人来中国都会主动要求去九一八纪念馆参观，有一次还正好是在9月18号前后，我开玩笑地说他们还真不怕挨打。
前年忘年会的时候，梁部长不无感慨地说“我跟日本人打了10多年交道，老实说，我不了解日本人。”确实，日本人跟中国人长得虽然很像，确是那么不同的一个品种。大事说起来没意思，有一件小事很有趣，我记得很清楚。那天是周六，我们三四个同事还有一个叫星原的日本人一起加班。一个同事带了一袋子油桃，洗了之后分给大家吃。这时候星原进来了，我们想也不能让他看着我们吃呀，于是也分给他一个。星原看着手里的油桃，问“这是什么东东？”我们告诉他是油桃，他听不懂，我们说“是桃子。”他很机警地说“桃子不是有毛的么？这个怎么没有毛？”我们说“诶呀，你看我们不是吃的挺香的嘛，让你吃你就放心大胆地吃好了，婆婆妈妈的。”星原又端详了半天，突然从兜里掏出一把小刀，把桃子的皮给削了，很得意地嘿嘿了两声，然后才吃了起来。

4.

我辞职的时候，按规定必须拿着一张印着所有部长名字的纸，让每个部长在那上面盖章。我拿着那张纸跑来跑去。在楼上的时候（好像是技术部），部长一边盖章一边说“可惜了”，挺痛快。在一楼，贺部长拿着他的印章，看着我的那张纸，自己在那儿琢磨，也不知道在琢磨啥，琢磨了半天，然后撇了撇嘴，掂了掂手里的章，又琢磨了一下，才重重地盖了上去，一边对我说“可惜了，虽然东芝不是最好的选择。”这件事我现在还记得，因为当时想着“怪不得人家能当那么大领导，同样一句话，人家说出来就感觉那么真诚，那么有分量。”

5.

还有一件挺有意思的小事。那是我们刚刚入职的时候，要统一进行入职培训，其实就是HR给我们讲一讲公司的制度、纪律什么的。讲师是一个50多岁感觉很实在的大叔，我们管他叫赵老师。赵老师说“注意上班时的纪律，不允许上网、看报纸，也不要趴在桌子上睡觉”，我上学的时候很喜欢趴在桌子上睡觉，所以当时心里很忐忑地想“不让趴桌子呐，不知道能不能挺得住。”他接着说“中午午休一小时，不允许打扑克。”，还有“我们中午去食堂吃饭，分两拨，第一拨11:50，第二拨12:10分，间隔20分钟。”我因为吃饭比较慢所以很担心地问“要是20分钟之内吃不完怎么办？”他说“一般都能吃得完的。”我还是很担心地问“那万一吃不完怎么办呢？”他说“怎么会吃不完呢？你上了班就知道了，都着急回去打扑克，没有吃不完的……”“啊？你刚刚不是说不允许打扑克的吗？”我狂晕。

本文链接

建模心法(3) 模型的演进——保持简单和弹性的3个建议

2011-09-05T01:32:00Z

问：“对于开发信息系统的程序员来说，最闹心、最上火、最忐忑、最纠结、最不好干、而且肯定会被埋怨的活儿是什么？”
答案是“建立领域模型”。好的（或者说合理的）模型必须基于对业务深刻理解。一个刚刚接触某个陌生领域的程序员，无论他怎么努力，对业务的理解一定是肤浅和片面的。他明知这个时候作出的模型一定是不够合理的，但是又不得不做，可谓明知不可为而为之，怎能不闹心、不上火、不忐忑？随着项目的推进，对业务的理解也在不断深入，需要对模型不断地重构——《DDD》也是这么说的嘛，但是它没提重构的成本有多大。讽刺的是，越到项目的最后阶段，甚至是上线一段时间之后，越容易产生“啊哈！原来是这么回事！”的顿悟。如果你已经完成了100个页面、300张报表，还有几百万条一分钱都不许错的生产数据，这时候，即使把一个字段从一个表转移到另一个表都可能让你闹心好几天。重构还是不重构？你怎能不纠结，不被埋怨？

简单

重构是不可避免的，特别是项目想要产品化，生命周期在5年、10年甚至更久的时候。既然明知道初始的模型肯定是不够合理的——还是咬咬牙承认吧——我们的目标只能（很委屈地）变成“构建一个重构成本比较小的模型”。
那是怎样的模型呢？答案也很普通：“简单的模型”。

建模心法4 初始模型一定要简单。

任何事物，总是由小到大、由简单到复杂的，所以你一准儿在心里吐槽说“这神马破文章，看了半天原来全是废话。”这里的问题是，我们知道领域模型的重构成本很大，对此心有余悸，所以即使想着“就目前的状况来看一个员工只有一个所属科室……”，但是总有个小恶魔在耳边嘀咕着：“就以往的经验和客户的口风，一个员工有多个所属科室是非常可能而且合理的，与其将来重构，不如现在就设计成多对多关系……”

一段时间之后，果然出现了这样的需求：一个医生本来是属于某个住院科室的（例如一病区、二病区……），但是他也要隔三差五地出门诊，他在出门诊时，是属于某个门诊科室的（例如普通门诊、小儿门诊……）。难道我们的前瞻性设计成功了？！再仔细考察一下，就会发现2个问题：1）虽说一个医生可以有多个部门和角色，但是他同一时间不能既是住院医生又是门诊医生；2）当他在住院部工作时，不但所属科室是某个住院科室，而且所需的功能模块也和出门诊时不一样。也就是说，医生有“住院医生”和“门诊医生”两个身份，分别对应不同的科室和角色，他在工作时，必须选择一个身份作为他的当前身份。

在实际实现的时候，考虑到“大多数员工都只有一个身份”以及“员工最多有3个身份”这两个实际情况，可以使用更为简单的结构：

如果某个员工没有第二部门和第二角色，就空着。如果某个员工有第二部门和第二角色，在登录系统时，需要由用户选择一个部门&角色作为他的当前部门&当前角色。
小贴士 在分析业务的时候要注意区分“有限多个”和“不确定数量的多个”，它们往往需要不同的结构。
讨论到这里不难得出结论，把简单模型重构成复杂模型不是件容易的事，但是如果一开始就使用复杂的模型，往往就会需要由一个复杂模型向另一个复杂模型的重构，那可就有点让人望而生畏了。

概念

由于模型的重构成本比较大，所以终归还是希望不要动不动就大改。但是新需求是无法预料的，同时由于前面讨论的原因又不想做太多的前瞻性设计，如何增加模型的弹性呢？为什么那些设计得好的模型总能从容应对需求的变化呢？如果硬要说有什么诀窍的话，那就是——

建模心法5 从一开始就关注实物背后的概念

我不想故弄玄虚，玩概念。这里的概念指的是对实物进行一点儿抽象，考虑它的本质。抽象的意思是指把不重要的属性略去不考虑，重点考量它对客户、对系统的价值和存在的意义。本质指的是那些固有的、不容易发生变化的东西。譬如对于人来说性格不容易改变，所以把握住司马懿多疑的性格，就大概可以料到摆个空城计能令他不敢攻城。同样，如果你能把握住业务中每个对象对客户或系统的价值和存在的意义，能看透哪一部分是固有的、不易变化的，那么，在外人看来你大概也有了料敌机先的本事。
说起来容易，真要操作起来还有几个难题。1）到底应该从什么时候开始，又从何处入手呢？2）哪些是重要的、什么是本质的，可谓仁者见仁，很难找到评判的依据和标准；3）对一个东西的抽象，可以有无数个方向、无数个层次。就像故事里说的明代那个叫王守仁的大牛，年轻的时候立志要成为圣贤，所以决定实践一下朱大圣人的“格物致知”，每天在自家后院“格”竹子，无论风吹雨淋，一直盯着竹子“格”，后来竹子没格成功，自己先得了感冒。
后面两个问题无法可想，它们大概属于“艺术”的范畴。对于第一个问题倒是有个不错的建议——当遇到矛盾的时候，就是一个很好的契机。
看一个具体的例子。如果你去医院看过病，一定对交了费之后拿到的那一大堆收据不陌生。当然，我们一般也不会仔细看它们，都是到了医生那里就把一堆收据全给人家，等人家捡走几张之后再把剩下的揣到自己兜里。所以现在让领域专家给我们讲讲吧。
“这种收据，一般都是‘3联’，也就是3张大小、格式全都一样的纸叠在一起，纸张之间有复写功能，由针式打印机打印之后3张纸就有了一模一样的内容。这3张纸，第一联叫存根联，由收款员留着；第二联叫通知联，由执行科室（也就是负责执行医嘱的部门，像放射线室、化验室、门诊药局等等）留着，所以这一联也叫执行联；第三联叫报销凭证，由患者留着。
“每张收据有一个收据号，收据是一张接着一张连续打印的。对于非药医嘱，每个医嘱一张收据；对于药品医嘱，每个处方（一个处方可能包含1～5种药品）一张收据。收据上打印的主要内容是医嘱名称、数量、金额和整张收据的总金额。
“需要注意的是，上面说的是针对自费患者的规则。如果是医保患者，则变成所有医嘱的总费用打印在第一张收据上，并注明此收据为‘医保总联收据’，专门用于报销；然后再接着打印执行联，其规则是每个非药医嘱一张执行联，每个处方一个执行联。因为执行联也是打印在收据纸上的，所以还要注明‘这是执行联，不可用于报销’的字样……”领域专家说完之后有点小得意地瞟了程序员一眼。
“我艹，这都神马乱七八糟的……”程序员听到这儿都快崩溃了，“不但非药医嘱和药品医嘱的处理方式不一样，自费患者和医保患者的处理方式相差的更多，这要怎么搞？”
说实在的，模型变得臃肿和难以理解很大程度上是拜各种“其它情况”所赐。但是，这些都是每天正在发生着的实际业务。如果说“存在就有它的理由”的话，要是我们能把这些理由搞明白，这反而可以成为加深理解的好机会。
要从哪里开始呢？就从最明显的不一致的地方开始：我们可以发现对于自费患者，收据和执行联是一模一样的（因为是一次打印3联，无论票据号还是内容都完全相同）；对于医保患者，收据和执行联是分开的，且票据号和内容都不一样。这暗示我们收据和执行联可能是2个不同的概念。
从价值和存在的意义考虑，收据的作用是1）作为患者已经交了费用的证明；2）报销的依据。执行联的作用是 1）表明患者已经交了费可以执行医嘱；2）指示医院的执行科室应该执行哪些医嘱。
再抽象一点从拓扑的角度考虑，可以认为收据和执行联都是对医嘱（所对应的收费项目）的分组，只是分组的方法不一定相同。一个重要的问题是这两种分组方法是否有必然的联系？
再回过头来仔细考虑那些规则，看看有多少非本质的因素。当然就像前面所讨论的，是不是本质的很大程度上是主观的、相对的。可以认为，“X光检查和验血不应该打印到同一张执行联上”是本质的，因为这两项医嘱需要在不同的执行科室执行，如果打在一张执行联上，难不成要把执行联撕成两片吗？但是“每个非药医嘱一张执行联”分明是因为程序员想偷懒——判断哪些医嘱属于同一个执行科室有点麻烦，还要考虑医嘱太多的话一张小小的票据可能打不下，另外这样做会使退费更容易处理（退费是另一个有点复杂的主题，本文限于篇幅不再讨论）。“对于医保患者，所有医嘱的总费用打印在第一张收据上”可能是因为医保中心要求这么做，也可能仅仅因为分几组进行医保结算操作技术上很麻烦。
经过一些分析之后，不难得出结论。需要把医嘱（所对应的费用明细）分组打印到票据（收据和执行联）上是本质的（当然将来随着医院和全社会无纸化水平越来越高，这些票据也会逐步消失）。生成这两种票据的分组规则可能完全相同，也可能有很大的不同，这取决于技术上的限制或实现上的方便，它们之间没有必然的联系。

在创建票据的时候，我们给出两种分组算法：GroupMethod1——对于非药医嘱，每个医嘱一组；对于药品医嘱，每个处方一组；GroupMethod2——所有医嘱一组。对于自费患者，使用 GroupMethod1 创建收据和执行联；对于医保患者，使用 GroupMethod2 创建收据，使用 GroupMethod1 创建执行联。打印票据的时候，自费患者只打印收据；医保患者先打印收据，再接着打印执行联。
因为收据和执行联的属性几乎一样，所以实际实现的时候也可以把收据和执行联用一个叫“票据”的实体来表示。另外，由于普通患者的收据和执行联的所有属性值都相同，持久化两条几乎一模一样的数据好像也没什么意思，可以暂且先不创建自费患者的执行联。至于要不要使用子类、弄个 factory 什么的，可以根据实际情况再做决定，本文限于篇幅不再讨论，但是至少应该把那两个分组算法和创建票据的代码封装到函数之中。

功夫在模型外

再说一点题外话。当客户要求我们实现很复杂的功能时，一定要小心——那可能只是客户脑袋发热，没有想到可以有更简单明了的解决问题的方法。这时候，即使可以假设开发团队的水平相当高，可以又快又好的把程序搞出来，仍然还要面对两个问题：1）程序太复杂了，想要向客户证明程序是光荣伟大而正确的很困难，客户需要经过很长时间才能信任程序，这预示着更大的培训和维护成本；2）客户可能没有程序员那么聪明，特别是需要多个部门的基础、利益各不相同的众多用户协作的时候——他们用不明白那么复杂、微妙的程序，最后只能使用最简单的那一部分——程序员应该对程序复杂性的边界心中有数，可以感觉到“这个要越线了”。这时候，如果程序员能给出更简单的方法，客户反而会感谢你，取得双赢的结果。这也可以说是“功夫在模型外”。相信将来企业管理软件的开发会与管理咨询一同进行，由目前的业务驱动开发逐渐转变为信息化建设促进管理改进。

建模心法6 帮助客户找到既简单又有效的解决方案。

这一条要求程序员在更高的层面上思考业务的本质。直觉上可能会觉得这已经和程序无关了，或者至少程序员不是最适合干这个的人选，但是我不这么认为。有句话说得好“想知道自己是不是真正理解了就用程序去实现它”，如果程序员已经成功地创造了一个信息系统来仿真真实业务，他对业务的理解一定比普通的业务人员更深刻、更全面，再加上他又是那么的聪明伶俐，如果他愿意更进一步的话，谁能拦得住？

本文链接

[日记]游长白遇梅花，植物大战僵尸

2011-08-13T15:22:00Z

“旅客朋友们——”我因为坐在面包车副驾驶的位置，所以假装自己是导游，“您即将经过的景点是‘董眼镜修车铺’，请向车窗的左侧观看……”

董眼镜修车铺

“董眼镜修车铺”是怎么回事呢？原来，我们昨天经过这附近的时候爆了胎。从长白山西坡到长白县要3个多小时的车程，大段大段的在修路，差不多 2/3 都是土路，坑坑洼洼的，有些地段铺满了碎石子。我们刚刚行进了不到 1/4 的路程，就被小石子扎爆了左后轮。
那是我跟东芝的老朋友们出来旅行的第二天。我们刚刚从西坡登上长白山的峰顶，很幸运地看到了天池。下午 4 点钟左右，阳光正灿烂，司机换备胎累得满头大汗，我只能帮忙压了几下千斤顶。备胎不宜使用太长时间，所以还得找修车铺补胎。开着车在附近找到一个村子，转了3家修车铺，都对我们摇了头。他们有的说“董眼镜！”，有的指着门外说“去，董眼镜！”。于是“董眼镜”成了我们心目中一个好似银河抵抗组织基地一般既神秘又好玩的所在。其实董眼镜的修车铺就在公路的旁边，挺破烂的一间瓦房，里面有火炕和一台老式电视机。我们大大咧咧地上了炕（后来想想好像真正算是上了炕的只有宁宁），开着各种好玩的玩笑，比如扎爆了我们轮胎的小石子其实是董眼镜的徒弟们故意扔的等等，很欢乐。补胎需要不少时间，以至于我们可以去附近的村子里上趟厕所，还买了雪糕吃。董眼镜是个 60 来岁剃着平头的小老头，皮肤黑黑的，确实带着副大大的眼镜。“我不干这么没技术含量的活儿”董眼镜说，“平时都是我老婆负责补胎的”。也许他没吹牛，过道上摆得满满的车床、电焊机和架子上好几本技术书都是证明。另一间屋子里则摆满了各种汽车的配件，我们都说董眼镜其实是这一片修车行里的老大呢。
就像圣埃克絮佩里说的，“当你在长长的公路上找到了一间修车铺，度过了本该不怎么愉快的一个小时，留下了欢声笑语，看过了修车师傅的全家福之后，对于你来说，它就不再是一间普通的修车铺，对于它来说，你也不再是一名普通的游客。以后，每当你看到它，都会在心底泛起微笑”。

夜行

由于修车耽搁了一个多小时，我们不得不早早地开始走夜路。我是真的喜欢夜路！山路窄窄的，车灯投射在地面上，形成一片小小的淡黄色光芒，周围则渐渐没入黑暗。有时会遇到浓烟和雾气，蜿蜒曲折的山路，好像永远也到不了头似的。路上静悄悄地，很难遇到对头车。黑暗包裹着，你就像一只孤单的萤火虫。有时，飞蛾迎着车头飞过，在车灯的映照下闪着金黄色的光芒，黑夜也平添了一丝绚丽和神秘。如果你的眼神好，偶尔能看见有金色的小东西在地上一跳一跳的，那是蛤蟆想要横过马路，到另一侧的鸭绿江边去。半个月亮很明亮，星空清晰可见。路两旁黑压压的原始森林向你压过来。我心想，要睁大眼睛注意看有没有停在路边还不亮灯的危险车辆……
“啊呀！好危险！还真有这么无德的车！”我们刚转过一个弯角，就看到一辆黑色的轿车停在路边，两个模糊的人影正在后备箱那里忙活着什么。“那辆车……”司机过了几秒钟才说，“八成是干走私的，因为公路那边就是朝鲜，他们有铜和铁，我们用粮食交换，有时也会走私从日本过来的毒品——冰毒一类的。”后来，这样的车我们陆陆续续看到了 3 辆。司机是本地人，朝鲜族，32岁，个子不高，瘦瘦的，既开朗又自信。“路的左边隔着鸭绿江就是朝鲜。注意看那些像萤火虫似的亮点，那就是村民的房子，灯光有些暗，因为都是二三十瓦的老式灯泡。”我们没请导游，全靠热情的司机给我们介绍，“再往前开一段就是朝鲜第三大城市惠山，明天我们返程时可以看一下。”
“师傅你这条路很熟吧？”开始了下山路的连续弯道，司机居然都不用刹车的，弯来转去的公路像一条大蛇扭动着斑驳的腰身，怎么都觉得像是在玩极品飞车一类的游戏。“啊……”司机听到我这么问好像有一点惊讶，过了好一会儿才回答我说，“是挺熟啊，这条路哪里有坑、哪里有包我全都知道。”
有那么几个瞬间，我甚至希望永远不要到达终点。我希望……被大雨耽搁在路上；滚石摧毁铁轨；台风阻断一切交通。也许……司机会突然不省人事——就让我们永远迷失在旅途上吧。

就算只看到一片乌云，那也是天池上空的乌云啊

我的乌鸦嘴向来有点名气。昨天刚说这次唯一的一点遗憾是新买的旅行专用雨衣和一次性鞋套没用上，早上就下起了小雨，我们披上雨衣穿行在十五道沟（官方名称是望天鹅峡谷）的小桥和木质栈道上。峡谷里有一条挺漂亮的小河，两侧的山上有好几个大大小小的瀑布浇灌着青草和绿树。游客很稀少，实际上，很难遇到别的游客，拍起照来很过瘾。有点可惜的是景点有些少，只用了2个小时就游遍了。门口景区地图上的景点有一半都是灰色的未开放状态，不知道是不是因为它是新开发的景区，还没有完全完工。
我们按计划接着赶到长白山南坡，想要再看一次天池，却收到坏消息——受台风“梅花”的影响，山顶刮起了大风，门票全部停售（据说风力强到把一辆汽车的车门都吹坏了）。我们都暗自庆幸幸亏昨天看到了天池，但是其它刚刚赶到的游客就惨了，有一个旅行团找了景区领导，非要买票进门不可。那边的答复是想进去也可以，但是所有景区全部关闭，门票售出不退。即使这样他们也愿意进山，还有一个女游客悲壮地说“就算只看到一片乌云，那也是天池上空的乌云啊”。希望和失望的力量多么强大！它们两个加在一起的杀伤力更是超乎想象。

绿皮火车

晚上，回程的火车没有买到卧铺，好在提前买好了票，有座——13 个小时的车程，总好过站票。老雷他们凑了一桌打扑克。宁宁和我因为很悲惨地明早还要上班，早早地眯起眼睛打盹。这是古老的绿皮火车。我想起了周云蓬的《绿皮火车》。我虽然没有他那么多姿多彩的经历，但是也同样从小就喜欢自己坐火车出去玩。那脏兮兮的地面，局促的空间，深绿色的座椅，还有偶尔钻进鼻孔的厕所味道，都隐隐地勾起了一丝熟悉的旅愁。座椅虽然看上去很宽大，但是靠背太直了，想要打个盹还真是不容易，脖子疼的像是要折了。我一个盹下去，脑袋啪嚓一下砸在宁宁的头上，心里很过意不去，于是把脑袋稍稍偏向珊珊这边一点。过了一会儿，不知怎么搞的啪嚓一下又砸在宁宁的脑袋上。后来，早上的时候，我问她，她却什么也不记得了。
靠窗的桌子很小，宁宁在上面铺了一件厚衣服，趴在上面貌似睡得挺舒服。我琢磨着桌子还剩 20 厘米的一小块地方，也够我趴在上面了。多亏我上学的时候天天练习趴在桌子上睡觉，这么小的地方也能掌握平衡，还做了一个离奇的梦，梦见章弦和……算了，为了他的性命着想就忍着不说了。

植物大战僵尸

早上醒来，居然有一点神清气爽的感觉。背着旅行包直接赶到医院。同事们见了我都说“你这个豌豆射手T恤很漂亮呀”。我告诉他们说这次旅行我们每个人都事先在淘宝上买了一件植物大战僵尸T恤——有的是植物，有的是僵尸。小孩子们见了我们都会抢着说“这个是豌豆射手，那个是寒冰射手……”，等哪天我把合影给你们看看。

本文链接

ExtJs4 与 SASS 的亲密接触——使用 SASS 自定义主题

2011-07-31T03:48:00Z

SASS 是一个在 Ruby 社区兴起的样式语言，支持嵌套、变量、混入、继承等等语言特性，通过命令行工具或Web框架插件生成标准的 CSS 样式（参加SASS主页http://sass-lang.com/）。使用 SASS 定义的样式代码更少、更清晰，更重要的是减少重复代码，符合 DRY 原则。让人高兴的是，ExtJs4 已经转向 SASS，你可以在 ext-4.0.2a\resources\sass\ 找到所有 ExtJs 样式的 SASS 版本。
由于 SASS 支持变量，所以修改/覆盖样式变得更加容易。例如，只要把 ExtJs 预定义的一个名为 $base-color 的变量重新赋值为 #a1c148（绿色），所有 Ext 控件的底色就会全都变成绿色了。在 ext-4.0.2a\resources\themes\stylesheets\ext4\default\variables\ 文件夹里可以找到所有预定义的变量。

下面我们一步一步地演练一下使用 SASS 自定义样式的全过程。

准备工作

Step1 下载 ExtJs4. http://www.sencha.com/products/extjs/download
Step2 下载 Ruby。在 http://www.ruby-lang.org/en/downloads/ 页，如果你是 Windows 用户应该下载“Ruby on Windows” 节下的“Ruby 1.9.2-p180 RubyInstaller”。下载后将 Ruby 安装到 D:\Ruby192\。为方便使用Ruby命令行工具，安装时建议勾选“Add Ruby executables to your PATH”选项。
Step3 安装 Compass/SASS。打开 Windows 命令行，执行
gem install compass
安装后，可使用命令
compass -v
sass -v
检验是否已成功安装了 compass 和 sass。

创建网站，规划目录

Step4 创建一个 MVC 网站，添加一个名为 MyThemDemoController 的控制器，以及配套的 Views\MyThemDemo\MyThemDemo.aspx 和 Scripts\Demo\MyThemDemo.js。把 Step1 中下载的 ext-4.0.2a 复制到网站的 Scripts 目录下。在 IIS 中创建网站，我把端口设成了 6000，你如果想偷懒的话可以下载我建好的整个 Demo 项目，但是要注意 1）别忘了在IIS中建网站，端口是 6000，2）ext-4.0.2a 一共 128M，我为了节省上传、下载时间没有放进去，3）Demo 页 URL 是 http://localhost:6000/MyThemDemo/MyThemDemo.

Step5 把 Scripts\ext-4.0.2a\resources\themes\templates\resources 文件夹复制到 Scripts 文件夹下。把 Scripts\ext-4.0.2a\resources\themes\images\default 文件夹复制到 Scripts\resources 文件夹下，并把它由 “default”重命名为“images”。之后你的目录结构应该如下图所示。

由 SASS 生成 CSS

Step6 修改 Scripts\resources\sass\config.rb 中的 $ext_path 变量，使其指向 ExtJs 根目录。
$ext_path = ".. /.. /ext-4.0.2a"
注意".."和"/"之间不要有空格，天杀的博客园居然会把 “.. /.. /”替换为“http://www.cnblogs.com”，逼得我没办法只好加了个空格进去囧

Step7 修改 Scripts\ext-4.0.2a\resources\themes\lib\utils.rb 第 62 行，由
images_path = File.join($ext_path, 'resources', 'themes', 'images', theme)
修改为
images_path = relative_path
这样 ExtJs 将使用 Scripts\resources\images 下的图片而不是 Scripts\ext-4.0.2a\resources 下的图片。

Step8 打开 Windows 命令行，进入 Scripts\resources\sass 目录下，执行命令
> compass compile
此命令会在 Scripts\resources\css 文件夹下生成 my-ext-theme.css 文件。

修改 $base-color 变量，查看效果

Step9 编辑 Scripts\resources\sass\my-ext-theme.scss，在 “@import 'ext4/default/all';” 这一行之前插入一行
$base-color: #a1c148;
注意对变量的重新赋值的语句都应该放在 “@import 'ext4/default/all';” 这一行之前。

Step10 再次打开 Windows 命令行，进入 Scripts\resources\sass 目录下，执行命令
> compass compile
重新生成CSS文件。

Step11 编辑 MyThemDemo.aspx，添加对 my-ext-theme.css 等文件的引用。

Step12 编辑 MyThemDemo.js，把 Scripts\ext-4.0.2a\examples\themes\themes.js 里的内容全部复制到 MyThemDemo.js 里面。
Step13 打开浏览器，进入 http://localhost:6000/MyThemDemo/MyThemDemo 即可看到效果了。

但是如何能够实时更改样式呢？（以便达到这个视频所演示的效果），偶也不知道。你要是知道的话请告诉我！
本文主要内容来自http://www.sencha.com/learn/theming/。

本文链接

[NHibernate] Guid 作主键速度超慢的背后

2011-07-12T14:32:00Z

最近遇到了一个让人抓狂的性能问题。生产环境里有一张表的数据量目前达到了 70 万条。结果发现无论是匹配主键的查询还是更新，执行一条语句居然需要 3.5 秒！如果把 NH Prof 中截获的 SQL 语句拿到 PL/SQL Developer 里执行，就只需几十毫秒。一开始还以为是NH的问题，后来发现其实另有隐情。
介绍一下环境先。数据库使用 Oracle10g，所有字符类型的字段都是 varchar2 [1]。所有的主键都使用 Guid，在数据库里是 varchar2(36) 类型，相应的，实体的 Id 属性的类型是 string。ORM 使用的是 NHibernate 2.1.0 和 FluentNHibernate1.1。
经过一番排查之后发现，问题的根源是 NH 将 SQL 语句传递给 Oracle 时，所有字符型的参数都是 nvarchar2 类型，而数据库里对应的字段却是 varchar2 类型，这将导致 Oracle 无法使用索引，终于造成全表扫描，所以数据量稍大就慢得不行。
第一种解决方法是，把数据库中所有的字符型字段的类型由 varchar2 更改为 nvarchar2，出于种种原因我们不希望这么做。
第二种解决方法是，让 NH 把 varchar2 作为参数类型传递给 Oracle。
事实上，NH 默认把 .net 的 string 映射为 DbType.String [2]，把 DbType.String 映射为 nvarchar2 [3]。把 DbType.AnsiString 映射为 varchar2 [4]。
所以对于查询比较简单，只要把 HQL 的参数类型指定为 AnsiString 就行了。

var query = Session.CreateQuery(@"select t from Region as t                                   where t.Id = :Id")                     .SetAnsiString("Id", id);

var query = Session.CreateQuery(@"select t from Region as t                                   where t.Id in (:Ids)")                     .SetParameterList("Ids", ids.ToList(), NHibernateUtil.AnsiString);

但是如何设置 Update 和 Delete 语句的参数类型呢？这里有个小小的秘技，把映射文件里的属性类型指定为“AnsiString”即可。

public class RegionMap : TreeNodeMap<Region>{    public RegionMap()    {        Table("INFRA_REGION");        Id(t => t.Id, "REGION_ID").CustomType("AnsiString");        ...    }}

注意一定要使用 CustomType() 而不是 CustomSqlType()。
当然了，要是把每一个配置文件都改一遍实在很烦，好像项目使用了 Fluent NHibernate，只要添加一个 IdConvention 就行了。

public class IdConvention : FluentNHibernate.Conventions.IIdConvention{    public void Apply(FluentNHibernate.Conventions.Instances.IIdentityInstance instance)    {        instance.CustomType("AnsiString");    }}

想要彻底一点的话，可以再加一个 string 类型的 property 的 convention。

public class StringPropertyConvention : IPropertyConvention, IPropertyConventionAcceptance{    public void Accept(IAcceptanceCriteria<IPropertyInspector> criteria)    {        criteria.Expect(x => x.Property.PropertyType == typeof(string));    }    public void Apply(IPropertyInstance instance)    {        instance.CustomType("AnsiString");    }}

把这两个 Convention 加到配置里面：

Session["SessionFactory"] = Fluently.Configure()          .Database(OracleClientConfiguration.Oracle10              .Dialect<Oracle10gDialect>()              .ConnectionString("User ID=iBlast;Password=不可说;Data Source=Moki")              .QuerySubstitutions("true 1, false 0, yes 'Y', no 'N'")              .UseOuterJoin()              .ProxyFactoryFactory<ProxyFactoryFactory>()              .AdoNetBatchSize(1000)              .Driver<OracleClientDriver>())          .Mappings(m => { m.HbmMappings.AddFromAssembly(Assembly.Load("Infrastructure.Repositories"));                            m.FluentMappings.AddFromAssembly(Assembly.Load("Infrastructure.Repositories"))                                           .Conventions.Add<EnumConvention>()                                           .Conventions.Add<HasManyConvention>()                                           .Conventions.Add<HasManyToManyConvention>()                                           .Conventions.Add<StringPropertyConvention>()                                           .Conventions.Add<IdConvention>()                                           .ExportTo(@"F:\temp\"); })          .BuildSessionFactory();

注意倒数第二行的 .ExportTo(@"F:\temp\") 是为了测试一下生成的映射文件对不对而把映射文件输出到了 “F:\temp\”，映射文件应该像这个样子：

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" default-access="property" auto-import="true" default-cascade="none" default-lazy="true">  <class xmlns="urn:nhibernate-mapping-2.2" dynamic-insert="true" dynamic-update="true" mutable="true" where="IsDelete=0" name="Dawn.HIS.Infrastructure.Core.Data.Region, Infrastructure.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" table="INFRA_REGION">    <id name="Id" type="AnsiString">      <column name="REGION_ID" />      <generator class="assigned" />    </id>    <version name="Version" type="System.Int32, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">      <column name="Version" />    </version>    <property name="CreateTime" type="System.DateTime, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">      <column name="CREATETIME" />    </property>    <property name="Name" type="AnsiString">      <column name="NAME" />    </property>    ...  </class></hibernate-mapping>

[1] 之所以使用 varchar2 而不是 nvarchar2，除了考虑 varchar2 可以节省空间之外，主要是为了避免 nvarchar2 排序时的性能问题。
[2] 见 NHibernate-2.1.0.GA-src\src\NHibernate\Type\TypeFactory.cs 第 197 行。
[3] 见 NHibernate-2.1.0.GA-src\src\NHibernate\Dialect\Oracle8iDialect.cs 第 92 行。
[4] 见 NHibernate-2.1.0.GA-src\src\NHibernate\Dialect\Oracle8iDialect.cs 第 88 行。

本文链接