Google 现在狠吸引眼球嘛
另外一个Google好玩的地方：
在Google的Preferences页面。
Interface Language 选项里面有个“Hacker” 在中文界面里是最后1项。
选中保存一下，很好玩的。hehe
posted on 2004-05-21 05:17:00 by zee 评论(3) 阅读(2195)
猫咪照片更新
@http://blog.joycode.com/zee/gallery/798.aspx
posted on 2004-05-20 05:02:00 by zee 评论(17) 阅读(7268)
Tips: Debuging your windows service code
偶以前做的项目里，曾经用C#写过一个Windows Service，当时觉得调试这个Service 实在是比较郁闷：我只有在 AdminTool的Service里启动我这个Service，然后再在VS.Net里的Debug-Process里找到进程，Attach上去，才可以开始调试，偶当时是在 Service 里放了一个 Timer实例，定时回调一个Scan 方法，Scan出需要处理的东东的时候，就新开个线程处理。当时Timer 设置的回调时间是每5s一次，有时候手慢点，Process还没有Attach上去的时候，子线程都已经处理完了。
当时就想，如果Windows Service 也能和WinForm App一样，设好断点，Push个F5就可以慢慢等着Run 到断点中断就爽了，可惜，WinService Proj 输出的是.exe,目前还没有办法作为引用加入到一个测试 Project的引用中去（JGTM 似乎提到过说以后exe 也可以作为类库被引用？那样就好乐，hehe）。
现在给出偶认为最舒服的解决方案：
1. 新建一个WinForm App 或者 Console App，随便，能执行就成。
2. 在这个Project 里加上和Windows Service 相同的Reference，比如System.ServiceProcess什么的。
3. 然后，在这个Project 上选择 “Add Exist Item”
4. 在Add Exist Item的文件选择对话框里，选定一个Windows Service Project中的cs 文件—别急着Open
5. 点Open 按钮旁边的乡下箭头，在列表中选择 “Link File”
6. 重复3-5，加入调试需要的所有文件
7. 现在，你可以在 Console 的 Main方法 或者 Win Form的Button-Click 事件里，慢慢地玩弄你Windows Service里的代码了。
这办法好处是不需要更改Win Service Proj 项目下的任何设置，你尽可以玩些Daily Build，Auto Test之类的应用，不需要担心项目设置不对。而且因为调试程序是以Link 方式连接Win Service Proj下的程序文件，在Test时候做的修改实际上就是对Win Service Proj 相应文件的修改—省得Copy了。
不过也有个小缺点，VSS会拒绝加入这个Project到Database,因为这个Proj的某些文件处于VSS DB的其它位置。不过也没有关系--把这个项目留在VSS 外面把。
posted on 2004-05-04 08:07:00 by zee 评论(3) 阅读(3577)
为什么不建议在C#里使用this？
偶还在上海的时候，曾经翻译过 IDesign 的一份 C# 编码规范， 改了改就拿来做公司内部的C# 代码规范。
这份规范其中有一条是这样的：
- Do not use the this reference unless invoking another constructor from within a
constructor.
|
//Example of proper use of ’this’ |
后来公司有兄弟问我，为什么要有这么一条规则，当时没有答出来，后来空下来的时候，在网上找了一下，在装配脑袋的
《VB.NET是怎样做到的》系列里，在讨论VB 的 WithEvent 的时候，他提到了一种说法：
不过在分析这段IL的时候，我也发现了VB.net在翻译时小小的问题，就是ldarg.0出现得过多，这是频繁使用Me或this的表现，所以我们在编码过程中一定要注意，除了使用到Me/this本身引用以外，使用它的成员时不要带上Me/this，比如Me.MyInt = 1就改成MyInt = 1，这样的小习惯会为你带来很大的性能收益。
再后来，偶准备从上海来LA的那几天里，虽然事情很多，但在公司的时候还是挺有空的，就用C#写了个Sample App 做实验，不过结果却令人意外： 无论是否使用this reference 引用 class 的 property/field/method, C# 编译器生成的IL代码是一样的，而且这一结果不受是否打开编译器的优化选项的影响--this.MyInt=1 从来就不会比 MyInt=1多发出一条ldarg.0, 反之亦然。
后来又猜想，（这里已经有点瞎猜的味道了 
）也许是否使用this reference在某些情况下语义会有些不同，比如说，对一个virtual 方法Method1， 鸡肋中的this.Method1() 也许和 Method1() 不是指的一回事情？继续试验，还是不对。
为什么要避免使用this reference, 目前我还没有答案，也许在dotNet 1.0中，会有this.MyInt 比 MyInt 多发射一条ldarg.0 指令的情况？ 手头没有相应环境，暂时没有办法试验的说。
今天发了封Mail给IDesign.Net的一个人，得到的答复如下:
Hi Zee,
We include this recommendation for the same reason we recommend removing superfluous namespace information from variables injected by the designer: more readable/maintainable code. The only reason to have the this reference in front of a member is to get intellisense, and you can get that by using the CTRL-space keystroke. It is just a matter of visual clutter, not for performance reasons.
Hope that helps,
Brian
----------------------------------------------------------------------------------------------
看来这个Rule 在咱们这里还真不能要----因为通常来说CTRL-space 在大家的系统里都是派其它用处的 :D
posted on 2004-05-04 07:11:00 by zee 评论(19) 阅读(4288)
Installing SPS 2003--- 真令我郁闷
久未更新，随便写点。顺便妒忌一下国内的兄弟们，51长假好幸福啊！！！
偶开发用的机器很不错，P4 2.4G CPU *2 + 1G Memory + 100G HD * 2 + SONY 19Inch TFT * 2,这么好的配置，不装几个虚机实在有点可惜。正好想玩弄一下SPS 2K3， 就在VPC 2004 上忙活开了......
偶有个坏习惯是装机器之前不喜欢看Install Guide，于是装好Win2K3， 升级AD；装好SQL2K之后就开始装SPS了。装了半天，总在进行" Configure Server Farm Account Settings "的时候出错，告诉我说IIS里的一个App Pool 不存在。自己乱试了半天，自己建了个App Pool 都没有用，迫不得已查KB：
搞了半天安装的时候输管理员账号一定要带上Domain Name，FT，按照KB的指示，卸载SPS重装。
这下Configure Server Farm Account Settings 算是过去了，但是装好以后，在配置的时候，Single Signon Service 总是说未找到服务。
这次没有从KB找答案，在从领导那里拿的一本《Microsoft SharePoint: Building Office 2003 Solutions》上，偶似乎找到了原因： SPS 2K3 的最小安装也需要至少2台机器，即使你把Win2K3 AD Exchange2K3 SPS2K3 的所有服务全放到1台Server上，你还得提供1台独立的Server 来放SQL 2K。
比较郁闷。决定有空再申请台Server 来玩SPS， 现在暂时先放下了。
posted on 2004-05-04 06:14:00 by zee 评论(18) 阅读(5104)