欢迎参观俺的个人影集

http://blog.joycode.com/joy/gallery/4.aspx

刚才问了几位续任的MVPs。Parrot是俺当年上海MVP Summit时候的室友,目前正在争取加入微软,他本来就在北京,所以这次肯定会参加。

VFan Yan(严伟峰)也是俺的挚交,还未曾谋面,听说酒量可以,他这次也会从云南来北京,可以一试酒量。

知秋一叶以及思归估计是回不来了,如果有空,去美国开MVP Summit的时候,估计可以看得到。

ZEE正在盘算MS是不是给他报销盘缠的事情,如果报销的话,他肯定会来,而且连国庆节都在北京过了。

豆腐则嫌时间有点长了,估计是怕家里面孩子以后再见面的时候不认识了,所以可能不会参加TechED。

而Momoplus、沧海、Playyuer肯定是会参加的,不问也知道了。

MVP大联欢,期待ing!

乱收费

下个月要交两个费用,一个是这个域名快要到期了,要交130元的域名注册费,另外一个就是电子邮件的费用,中华网的信天邮,服务态度不好,还老丢信,不过由于这个邮件地址还不错,所以不得不交费了 🙁

今天博客堂的队伍扩大了,先是思归的加入,而后知秋一叶(QQChen)、讨饭猫、联合广场(五农民出狗)、Parrot这些MVPs都加入了。所以我现在开始想不把本站公开进行申请了,而是通过电子邮件申请,这样可以更加保证本博客站点的技术纯洁性。

如果大家想在这儿申请帐号的话,请在http://blog.joycode.com/joy/contact.aspx里面留一下言,把你所要的帐号等信息告诉我,同时,最主要的一点,把你在原来所在的社区以及ID告诉我。在查验一两天后,我们会通过电子邮件告诉你是否开放以及各种帐号及密码信息。

有三件事情值得注意:

  • 随笔是出现在首页中的,无论你是否加入分类,均会出现在集群站点以及个人的首页上。而文章不会出现在首页上,只能通过“分类”的方式索引,如果你没有加入到分类中,那就是一个人的珍藏品了。原则上来说,文章更加正式一些,适合加入一些精华的文章。
  • 你输入的电子邮件是十分有用的,一是别人通过“联系”页面给你发电子邮件,另外一种是别人看了你的文章后发表的随笔都会通过电邮发给你。
  • 汉化其实还在继续中,所以大家有任何不满意的地方,均可以通过各种方式提出。同时,本站点的首页在日后将做一次大幅度的改动。

希望大家在这儿玩得愉快:D

我要去上海

“我要去桂林呀,我要去桂林,可是有钱的时候,我却没时间;我要去桂林呀,我要去桂林,可是有了时间,我却没有钱”.

多少人有过这种怅惘呀?在我心目中,上海已经不算神秘,毕竟去年四月份我在上海呆了三天两夜。可是终归是匆匆一瞥,大部分是在各种会议以及吃饭、睡觉中度过的。没有来得及多与上海亲近一下,就带着迷茫离开了。

另外,我对微软的软件开发过程一直充满着好奇,总想实战一把,不过在外面的公司里面,很难有哪个企业可以做到Daily Building、Bug跟踪机制,就像学正宗的武术要去少林一样,要想学正宗的MSF,还是要去微软吧。

正好有这样一个机会,可以参加另外一个项目开发,准备本月去趟上海,进入向往已久的“少林武当”学习正宗的软件过程管理。

一切还在待定中,不过至少可以让上海的朋友们破费了,帮俺找房子、请俺吃饭这些是少不了的。我准备就住在ZEE的小房子里面了,呵呵。一呆就是四五个月,也可以逐一拜访上海的各位GGDDJJMM了:P

明天是最后一天

明天最后一天在微软中国工作了。

项目进行了两周,豆腐感觉很不可思议,在两周的时间内完成一个原型开发,感觉速度快了一点。我想一想的确也挺快的。

这个项目使用的技术包括.NET Web Service+.NET Web Application+BizTalk 2004 Server,由于BizTalk 2004 Server在我们开发的过程中(甚至直到现在),一直还是Beta阶段,在这两周内,我们就换了三个Build,所以需要逐渐的熟悉。毕竟与Biztalk 2002 Server改变了太多。

项目组只有两个成员,即我与阿斌同志,阿斌是MS内部的Biztalk专家,所以在分工上,是由他负责Biztalk的开发的,而我主要负责.NET Web Service+.NET Web Application的开发。使用.NET Web Service模拟外部业务模块接口,而.NET Web Application模拟前台界面,然后使用BizTalk来将这些外部模块进行串联,组织一个完整的工作流程。

总结一下,开发周期比原来预定的多了一天,而且每天基本上都要加班到晚上九点钟以后,有时候还到半夜十二点,周末也一直在加班(阿斌同志比我要累多了)。不过开发周期基本上还算控制住了,基本上在两周多一些完成了。在刚进入项目的时候,我们本来还认为可能会需要一个月左右。

当然,也有一些经验需要汲取的,就是在刚开工的时候,我们把太多考虑放在了技术上面,过早的进入了代码实施阶段,其实在第一周所编写的代码被废弃了好多。因为我们随着我们的代码编写过程,才逐渐的发现了一些原来不甚清晰的业务逻辑,而不停的修改接口,直至上周六用UML序列图方式确定了最后的调用关系,整个开发才算步入正轨。

在此,开心向阿斌以及其他微软中对开心予以各种帮助的朋友表示衷心的感谢!对小马哥及小马哥的那位MCT朋友的推荐表示感谢!对所有阅读开心Blog的人表示感谢! (似乎有点过于官面文章了,开心请吃饭吧!)

热烈庆祝开心就好重新荣获MVP称号:D

 

一直在等这个消息,终于当选名单今晚公布了,虽然没有去年发布的时候那样异乎寻常的激动,但对我来说的确是一个好消息。

今年的MVP名单有些长,http://asiacommunity/china/community/content/news/2003sepMVP.aspx,共有78个,里面有很多我们熟悉的名字,金雪根、朱其盛、彭进、吕科、严伟峰、豆腐、笨猫猫。陈锐等等都一一再次当选。

期待着九月底与大家相聚在北京!(金雪根光思归,却不归)

 

Smart Client培训资料下载

小气的神小马哥 之托,现在将 小气的神 培训的资料提供下载。下载地址为,请大家自由下载,不过由于空间及带宽原因,不一定能够保留在什么时候的。http://210.82.112.46/download.zip

总共大小差不多是80M左右,大家量力而行,另外下载后,请把后缀名改为.exe,是一个自解压的文件。我个人在家里面试验的时候,诺顿企业版报警说这个文件有病毒,所以请大家一定要小心!

主要内容是 小气的神 在香港培训时所获得的资料。相信对那些有志于在Smart Client上进行.NET开发的人员是有很大帮助的。

营业执照:P

今天晚上加班的时候,给Scott先生写了两封信,一封是问技术问题,另外一封是问License的。Scott先生都很快的回复了邮件。

其实在汉化.Text的刚起步的时候,我就仔细阅读了Scott先生的License,现在通过邮件再次得到确认。终于可以自豪的说,我们现在是有照经营了

Hi Joy,

That would be great. Feel free to use it anyway you see fit. The licence is
here:
http://scottwater.com/License/

In short, you can do whatever you want with it…but I love to know how it is being used

-Scott

预祝小马哥一路平安

 小马哥 下周二去秦皇岛讲课去了,在这儿预祝 小马哥 一路平安。其实一直没有听过 小马哥 的课,真希望有什么时候可以听小马哥专门为俺讲一课的。

小气的神 的PPT看到了,虽然没有亲身去一趟香港听这堂课,不过有PPT也算一种弥补吧。但就算 小马哥 说的,没有机会与 小气的神 碰面,不能不说是遗憾,尤其是他只在广州讲课,而不来北京,太让人失望了。

讲两个小笑话吧,在微软经历的,一位女孩问一位阿姨:阿姨,请问“土星”在哪儿?阿姨说:你跟我走,我带你去。

还有就是在茶水间的时候,阿姨接电话:好的,“地球”要两杯咖啡,马上就到。

微软的会议室都是以行星命名的

 

Anders Hejlsberg语录

刚刚在http://www.artima.com/intv/handcuffs.html看到了这段话,我感觉这可能是中国程序员的一个比较明显的通病,贴在这儿,希望对大家帮助,最重要的是,提醒自己,不要再犯同样的错误。

If you ask beginning programmers to write a calendar control, they often think to themselves, “Oh, I’m going to write the world’s best calendar control! It’s going to be polymorphic with respect to the kind of calendar. It will have displayers, and mungers, and this, that, and the other.” They need to ship a calendar application in two months. They put all this infrastructure into place in the control, and then spend two days writing a crappy calendar application on top of it. They’ll think, “In the next version of the application, I’m going to do so much more.”

Once they start thinking about how they’re actually going to implement all of these other concretizations of their abstract design, however, it turns out that their design is completely wrong. And now they’ve painted themself into a corner, and they have to throw the whole thing out. I have seen that over and over. I’m a strong believer in being minimalistic. Unless you actually are going to solve the general problem, don’t try and put in place a framework for solving a specific one, because you don’t know what that framework should look like.