Be and aware who you are.
置顶随笔
摘要: 别被下面那些复杂的表达式吓倒,只要跟着我一步一步来,你会发现正则表达式其实并不像你想像中的那么困难。当然,如果你看完了这篇教程之后发现自己明白了很多,却又几乎什么都记不得,那也是很正常的--其实我认为没接触过正则表达式的人在看完这篇教程后能把提到过的语法记住80%以上的可能性为零。这里只是让你明白基本道理,以后你还需要多练习,多查资料,才能熟练掌握正则表达式。
阅读全文
2008年6月22日
1,安装
Web Deploy Projects2,在VS里右击Web项目, Add Web Deployment Project, 确定
3,设置新添加的项目的属性. 其中的"Compilation"页中 Output Path即为要发布到的目录.
4,在项目属性的Deployment页中,选中"Enable Web.config file section replacement",在下面输入"connectionStrings=connectionStrings.config;",确定
5,在原来的Web项目中添加一个connectionStrings.config文件,在里面输入发布版/生产环境版的connectionStrings:
<connectionStrings>
<add
/>
</connectionStrings>

6,原来的Web项目里的web.config文件里,connectionStrings节里只需要包含开发时用到的连接字符串.
7,要发布时,执行一下deployment项目的"生成"操作,即可从自己设置的Output Path里找到可以直接发布的文件和目录结构了
另,如果一些文件不希望发布(比如文件file1.name和file2.name,目录dir1.name和dir2.name ),可以打开deployment项目的项目文件,通过下面的修改来实现:
<ItemGroup>
<RemoveFileAfterBuild Include="$(OutputPath)\file1.name"/>
<RemoveFileAfterBuild Include="$(OutputPath)\file2.name"/>
<RemoveDirAfterBuild Include="$(OutputPath)\dir1.name"/>
<RemoveDirAfterBuild Include="$(OutputPath)\dir2.name"/>
</ItemGroup>

<Target Name="AfterBuild">
<RemoveDir Directories="@(RemoveDirAfterBuild)" />
<Delete Files="@(RemoveFileAfterBuild)" />
</Target>
2008年6月16日
| Type | ToString() | ContainsGenericParameters | GenericParameterAttributes | GenericParameterPosition | IsGenericType |
| Dictionary<,> | Dictionary~2[TKey,TValue] | Y | - | - | Y |
| < | Tkey | Y | None | 0 | N |
| > | Tvalue | Y | None | 1 | N |
| Dictionary<string,int> | Dictionary~2[String,Int32] | N | - | - | Y |
| <string | String | N | - | - | N |
| int> | Int32 | N | - | - | N |
| Type | IsGenericParameter | IsGenericTypeDefinition | GetGenericArguments() | GetGenericParameterConstraints() | GetGenericTypeDefinition() |
| Dictionary<,> | N | Y | [TKey,TValue] | - | Dictionary~2[TKey,TValue] |
| < | Y | N | [] | [] | - |
| > | Y | N | [] | [] | - |
| Dictionary<string,int> | N | N | [String,Int32] | - | Dictionary~2[TKey,TValue] |
| <string | N | N | [] | - | - |
| int> | N | N | [] | - | - |
2008年6月14日
原始来源:
RegexLib.com修改后加入了两个新功能:
1,匹配类似 "lc <deerchao@xxx.com>" 这样的包含姓名的格式.
2,添加了四个命名组: name, email, user, domain. 这样可以方便取出相应的信息.
Regex re = new Regex(@"^((?'name'.+?)\s*<)?(?'email'(?>[a-zA-Z\d!#$%&'*+\-/=?^_`{|}~]+\x20*|""(?'user'(?=[\x01-\x7f])[^""\\]|\\[\x01-\x7f])*""\x20*)*(?'angle'<))?(?'user'(?!\.)(?>\.?[a-zA-Z\d!#$%&'*+\-/=?^_`{|}~]+)+|""((?=[\x01-\x7f])[^""\\]|\\[\x01-\x7f])*"")@(?'domain'((?!-)[a-zA-Z\d\-]+(?<!-)\.)+[a-zA-Z]{2,}|\[(((?(?<!\[)\.)(25[0-5]|2[0-4]\d|[01]?\d?\d)){4}|[a-zA-Z\d\-]*[a-zA-Z\d]:((?=[\x01-\x7f])[^\\\[\]]|\\[\x01-\x7f])+)\])(?'angle')(?(name)>)$", RegexOptions.Multiline | RegexOptions.ExplicitCapture);
MatchCollection mc = re.Matches(@"l c <abc@example.com>
Abc@example.com
aBC@example.com
abc.123@example.com
");
foreach (Match ma in mc)


{

}

原表达式的最大优点就是匹配能力强大,能吃下各种符合
规范(RFC2882)的表达式.
匹配
WikiPedia上的10/11个合法邮件地址格式,不合法的一个也不匹配:
Valid e-mail addresses
- abc@example.com
- Abc@example.com
- aBC@example.com
- abc.123@example.com
- 1234567890@example.com
- _______@example.com
- abc+mailbox/department=shipping@example.com
!#$%&'*+-/=?^_`.{|}~@example.com (all of these characters are allowed)- "abc@def"@example.com (anything goes inside quotation marks)
- "Fred Bloggs"@example.com
- "%()[]\;:,<>"@example.com
Invalid e-mail addresses
Abc.example.com (character @ is missing)Abc.@example.com (character dot(.) is last in local part)Abc..123@example.com (character dot(.) is double)A@b@c@example.com (only one @ is allowed outside quotations marks) %()[]\;:,<>@example.com (none of the characters before the @ is allowed outside quotation marks)
2008年6月12日
由于厌烦了手写Sql,在几个小项目中尝试着使用了Db4O.DAL层写起来是爽了,但是,还是有很多其它东西会绊你的脚。
- 没有主键的概念(因为对象的内存地址,或者引用就能标志一个对象了).因而外界想指向一个具体的对象就比较困难(比如本页的url里的1079505).
- 激活/保存层次的问题.获取一个对象,它的字段引用了其它对象,那么到底激活多少层次合适?保存时也是如此.层次深了伤性能,层次浅了用着不方便(动不动就是Null reference).
- 对象引用问题.RDBMS里我们能很轻易地明白一个引用指向的是对象的浅拷贝(因为只引用了一个主键).而一旦与内存中的对象勾搭起来,那深拷贝和浅拷贝就不容易区分了,很难说清我删除了一个对象会不会让某个其它对象的某个字段变成null(同样,修改对象也不容易看清其影响范围).
- 对象生存期问题.这是个看起来很奇怪甚至愚蠢的问题:没有被其它对象引用的对象是否应该存在于数据库中?换句话说,ODBMS要不要拥有GC功能?如果有GC功能的话,能够避免误删除被其它对象引用的对象,而且能够清除不再需要的数据.但是相应地,它让开发必须考虑更多的问题,保证每个对象的静态可达性.
- 数据库版本进化难以跟踪.由于数据库的结构与对象的结构基本一致,对对象模型的任何修改都会导致数据库结构的变化,而这个过程中原有数据如何处理必须加以特殊处理(Db4O里提供了字段改名之类的api,但是至少我很讨厌每修改一次对象就要写几行这样的代码).换句话说,我觉得数据库和对象之间耦合严重了,不利于修改.
- 没有类似Sql的成熟且流行的查询语言(或者你必须学习一种新语言)进行数据管理.很多时候,直接操作数据库也是必须的,这时你会非常想念Sql.
总体而言,对于熟悉关系数据库及基于关系数据库进行软件开发的人而言,对象数据库并不仅仅意味着换个存储方式.要真正高效地使用它,可能需要很长时间的摸索和适应.对我而言,Db4O是看起来很美,用起来很玄 :)
2008年6月11日