HeyBrain

一直以为.net年代内存管理已经不用操心了, 可是没想到连最普通的Menu, ToolStrip也得显式调用Dispose释放资源才行
还有WebBrowser, 也得这样, 而且如果在窗体构造函数而不是Load中Navigate, 那么就是直接Webbrowser.Dispose也释放不了

要显式释放也行, 但你得告诉人一声啊, DevExpress的XtraGrid也得显式调用Dispose, 虽然Control都实现了IDispable接口, 可是如果你不调用
Form的Dispose调用是不顶用的, 只能自己处理, 像我这样一知半解的肯定有很多人, 估计这世上有大量的Winform程序都内存泄露着

中国万网，我很爱你。。。
新网互联，好恨好恨你。。。

曾经，我娶了Feiyiban.NET
这是新网互联寄养给他人的域名（不知道是几级代理！）
很便宜，可是，她的养父也不知道其生母在哪！
于是，我决定先和新网互联离婚
－－自动放弃养护权利（不再去续费了）。。。

从此，我看上了人家Feiyiban.com
这女子和Feiyiban.NET是同年生人，只差一月（恨我下手慢了一个月！）
眼看着，.com的老公宣布修掉了她
于是，我带上椅子
天天坐在民政局门口
就等.com正式离婚（娘家还是新网互联！）

为了掌握.com/.NET是如何与总管离婚的
我苦学了域名状态意义（不同方案，少则8种、多则23种。。。）
于是，我从OK一直等到REDEMPTION PERIOD、PENDING DELETE。。。
传说是要整整65天！
终于，看到了这个样子：
  Status: pendingDelete
  Updated Date: 27-jun-2008
  Creation Date: 28-apr-2006
  Expiration Date: 28-apr-2008
尤其是PendingDelete后，
传说.com/.NET是只要5天就可以正式离婚了。。。
心里开始暗自高兴（看着人家离婚，总是会很高兴的，因为，同时表明我的机会来了。。。呵呵）
我按几套方案算：
1、27－28－29－30－1:最早7月1日可抢到刚刚离婚的娘子
2、28－29－30－1－2:这样7月2也可是抱上她
3、按美国时间与北京时间差一天算：总之，7月1日－3日能够接她回来的。。。

哎。。。
那几天，我是天天在万网查呀！
可恶的万网。。。千刀万剐的万网。。。
天天说已被注册，但信息却一直是：
  Status: pendingDelete
  Updated Date: 27-jun-2008
  Creation Date: 28-apr-2006
  Expiration Date: 28-apr-2008
。。。

按我的暗算：最迟7月4日无论如何劫也要去劫回来。。。
我都把民政局的门槛都坐了个坑了。。。
那刚刚离婚的不属于我，还是会是谁呀？！
非要了她不可！
摆起了一副XXX的样子。。。

可是！
吐血！
我开始恨万网啦！！！
他的消息太让我失望了。。。
.com跟印度人跑了！！！
娘子都跑了。。。
万网还在那说：。。。哎！！！
我恨！我恨万网。。。
通过Whois.org一查：
  Creation date : 2008-07-03/14:52:34
  Updated date :
  Expiration date : 2009-07-03/14:52:34
  Status : ok
我再次吐血！
.com改嫁印度人了。。。

哎，看来，坐在民政局门口
光等不行
还要，上前问：你离婚了么？
离了就抢她！
否则。。。很能又要被老外抢跑了。。。

YAML Ain't Markup Language, 一般会认为Yet Another Markup Lanuage, 结果它表明自己不是标记语言, 按wikipedia的解释: A markup language combines text and extra information about the text. The extra information, for example about the text's structure or presentation, is expressed using markup, which is intermingled with the primary text. 既然YAML说自己非标记性语言, 那么它很清楚的在告诉大家: 在这里, 只有数据!

YAML(tm) is an international collaboration to make a data serialization language which is both human readable and computationally powerful. 所以它的出发点就是对人来说是易读的, 对计算机来说是容易处理的, 主要用来序列化数据, 当然我认为它还包括了反序列化

慢慢地, 面对越来越多的诱惑和需求, YAML开始变得复杂, 有兴趣的可以看它的Specification: http://yaml.org/spec/current.html 估计大多数人要晕了, YAML的初衷是希望它的Parser是易于实现而且只需要单向处理(即不需回溯), 这样可以保证Prase的速度, 但现在, 如果完全实现它的Specification.... 起码C#的YAML Parser: http://yaml-net-parser.sourceforge.net/ 已经歇菜了, 两位作者说实在无法去应对所有的特性

因为我需要很多描述性的数据要存储读取, 包括在程序文件夹和数据库中, 在外部的还得经常编辑, 自然地但想着用YAML来处理, 结果试用了一下Yaml.Net, 很多我需要的功能没有, 所以最后我还是自己写了一个Yaml Parser, 因为它是通过TAB缩进描述的, 所以一般的Parser Generator就派不上用场了, 幸好里面的规则不多

当然我也不会去完全实现所有特性, 取舍之后, 有了很多修改, 到后来原来的YAML语法就不管了, 怎么易读易写就怎么来了

改动之后, TAG功能完全去掉了, 毕竟.Net是可以反射的, 没必要增加编辑文件的痛苦

一段Yaml可以包含多个对象定义
对象定义可以嵌套
字符串如果没有换行,空格和特殊字符 \t \" \' = : & , | >, 可以直接写入
否则可以以\' 和 \" 两种方式标明
换行的有两种表式 | 表示的是多行文件, > 表示的是单行文件写做多行
  string:abc
  string:"abc"
  string:'abc'
  string|  # value is "ab\r\nc"
    ab
    c
  string>  # value is "abc"
    ab
    c

注释以#开始
对象引用以&开始
  value:&object
对象定义后 : 表示继承
  inheritedtype:parenttype

属性和值
  prop:value
泛型的Dictionary
  简单类型  key1:value1, key2:value2
  复杂类型
      key=prop1:value1 prop2:value2
    或
      key
        prop1:value1
        prop2:value2
泛型的List
  简单类型
      value1, value2,...
    或
      value1
      value2
      ...
  复杂类型
      -
        prop1:value11
        prop2:value21
      -
        prop1:value12
        prop2:value22
    或
      - prop1:value11 prop2:value21
      - prop1:value21 prop2:value22
    或
      -
        prop1:value11 prop2:value21
      -
        prop1:value21 prop2:value22

      
测试用例:
public class Person
{
public string name;
public int age;
public float salary;
public bool married;
public DateTime birthday;
public string remark;

public Dictionary<string, Person> Children;
public List<Person> Friends;
public List<string> Titles;
public Dictionary<string, string> Address;
public Person ReportTo;
public Person Parent;
public Company Company;

public Color haircolor;

public Person()
{
Children = new Dictionary<string, Person>();
Friends = new List<Person>();
Titles = new List<string>();
Address = new Dictionary<string, string>();
}
}

public struct Company
{
public string name;
public string address;
}

YAML文件:
#collection:list,dictionary
#property
#simple type:string,int,float,double,datetime,bool
#custom type

simpletype
  name:progame
  age:100
  salary:10.23
  birthday:1979-09-20
  married:false # if married
  
simpletype2
  name:progame age: 100 remark>
...

阅读全文...

SharpHSql 是一个纯C#写就的支持sql92标准的轻量数据库引擎，当我们为了便于发布而选用单DLL的数据库引擎时，SharpHsql以它的100% managed code而受到青睐。大家一下子欢呼：找到access的替代品了!

但实际上，我认为SharpHsql应该谨慎地用于实际生产环境，我们先来了解一下它的存储原理。

不像其它的纯内存数据库或文件型数据库，SharpHSql在存储数据时相当取巧，使用.cfg文件存放一些数据库的信息和其它文件的位置，使用.log存放所有的DDL SQL，使用.data文件存放Cache的二进制序列化流，用.backup存放.data一样的数据，相当于多一个存放多一层保险。

查看SharpHsql源码，里面的处理还是比较简单的：

每一次insert delete (update会分解成先 delete 再 insert，只是 check 会放到 insert 后进行)都分别有一个 transaction 来对应
这个transaction是用于事务回滚时的rollback的，当rollback时，则用 delete 对应 insert ,用 insert 对应 delete
Table 是通过 Cache 来存放 Rows 的，也就是说数据的实际存储是在 Cache 这个类中
Index类是一棵AVL树，用来数据检索，当有row更新时，如果有索引存在，则需要更新这棵树
Channel就是用了区分transaction和权限检查，实际只是一个process中可以多channel访问同一数据库，而其它的process想访问是不行的
因为Database类打开数据库时，使用的是独占式文件打开，因为如果不独占的话，Cache的写入是会出问题的

数据库打开时的步骤：
1、取cfg文件，得到信息
2、反序列化.data，得到Cache
3、执行.log得到数据库结构

所以我们可以看出SharpHsql是独占式访问的，而且是完全加载所有数据到内存的
这样的结构我觉得仍然应该视其为一个内存数据库引擎，对于数据量会逐渐变大的实际生产环境来说，慎用；对于多并发环境来说，别用
所以SharpHsql要出pocket版本，使用compact framework，看来它的定位也是很准确的

如果利用SharpHSql的sql ...

阅读全文...

报错信息：
虽然dataset中使用的connectstring为property.setting时的设置是正确的
但仍然无法打开Dataset designer.
最后删除Server Explorer中的数据库连接解决

一路上到处的桂花香，时间在不知不觉中流逝，而代码，也在不知不觉中膨胀，并且越来越有“坏味道”...

现在IDE的debug功能越来越强悍，当一切回归原始，当你只能自己输出调试信息，只能看到出问题的代码位置和函数名时
你才知道，你的设计是多么地差，有太多不相关的功能耦合在一起，以及一次次的不知所终的调用，还有颗粒性不够细的单元测试

如果你很难根据出错信息迅速地定位你的问题所在，那么这个时候，放心地去怀疑你的设计吧

去用无法直接调试的单元测试检测你代码是否简洁吧，一如我这篇简洁的日志

一个很小的 WINFORM 程序，涉及到 CRUD，一次写入(批量更新)，存储过程交互，数据比较，数据缓存，麻雀虽小，倒也五脏俱全，于是懒得去找那些.Net下的ORM了，省得去代码生成，属性配置，既然ADO.Net2.0已经提供了 QueryBuilder，Typed DataSet，DataBinding，那就直接上吧!

拖，拉，配，拖，拉，配.......

开始很机械的操作，一番云里来雨里去之后，功能是完成了，但就我所体会到的 ADO.Net 2.0 有以下感觉：

优点：

1、性能
据说性能比1.0有巨大提升, 反正我感觉还是挺快的，即使在配置较差的电脑上，另外，使用Sql Profier监测自己软件的SQL还是很重要的， 这样你能更清楚的知道 DataSet 何时提交，提交了什么样的 SQL

2、内存数据操作
这个真是非常好的一个特性，配合 GRID ，可以很好地实现一次写入，也就是可以 Undo 了，不怕误操作再来数据的错误，而且后期的设定 PK ，再用 FIND 方法定位，给两个数据集之间进行比对提供了极大的便利。 此处，可以凭空创建一个 DataTable， 任意改变其中的 Columns, Constrains， 这对于数据处理而言， 意思非常巨大， Table 的行集操作能力结合.Net语言的其它超强处理能力，真的有一种农奴翻身做主人的感觉，因为现在数据完全是可控的了

3、Query Builder
一些既不算简单又不复杂的 SQL 可以写在这里，省却了代码中直接写入的换行+ @ 标识，又没必要搞得 DB 中 SP 漫天飞舞(貌似MS本身特别钟爱在 SQL SERVER 中用超多的 SP，好像在向大家说：量再多也不怕!)，不管如何，我觉得这是很好地把 SQL 和 CODE 分离的一个举措，所以除了 DataSet 中，其它地方我都不会出现 SQL，如果需要写SQL，那么找相关的 DataSet 去 Add Query 就是了

4、版本控制
因为更新时它使用的是set ... = newValue where field = oldValue的方法 所以如果其它人在你修改时改动了数据， 它会报冲突错误的， 当然，好的方法还是自己通过timestamp来控制

5、Typed
总算可以打点了，将就一点吧，能用就行了

缺点：

1、命名空间混乱
...

阅读全文...