|
|
1,使用No!Flash这个软件,对是否允许网页显示Flash进行切换以后,无法使用Ctrl+N的方式打开新的IE窗口立即看到Flash或者立即屏蔽Flash。这是IE对ActiveX的显示与否作了改变。
2,新的firewall对UDP通信的防护没有原来的版本严格。我开发的一个使用了UDP通信的远程画笔软件可以毫无问题地穿过SP2的firewall。而在原来XP环境下,则根本无法这样做。我不清楚这是否是SP2的漏洞,但我觉得这样很危险。
重粒子@不要相信任何firewall
如果你使用VSS管理你的源程序,那么可以程序开头加上这样的注释
/*
* $Header: $
*
* $History: $
*
*/
然后打开VSS的Admin管理程序,在「工具」->「选项」的第一个Page的第2个textbox处添上你的源程序的后缀,比如:*.cpp,*.h
今后的版本信息,文件名,更新时刻都会自动作为添加到你程序里了。
$Header: $这样的keyword有好几个,而且也不一定要放到注释里。比如VSS的Help里说可以这样用
Last modified on <!--$$JustDate:--!> <!--$-->
灵活应用这个技巧,你可以做得更好。
这是我的第3篇关与native event的随笔。第一篇对native event作了简介。第二篇报告一个BUG。这一篇我们看看native event是如何实现的,并且尝试解决我们遇到的BUG。
从VC7(Microsoft Visual C++ .NET (2002) )开始MSVC提供了native event这一机制,试图为C++引入一个实现delegate的办法。一共提供了4个扩展关键子:__event (定义一个event),__raise(触发一个event),__hook(将一个成员函数连到event上),__unhook(去掉指定的函数),和两个作用在类上的特性:event_source(一个事件源),event_receiver(一个事件接受者)。
为什么会提供这么多看上去很丑陋的关键子呢?这些关键子生成了什么样的代码呢?
可以使用下面的编译命令来编译我在第二篇随笔里的代码。
cl /Fx /Fas native_event.cpp
/Fx编译选项会生成一个native_event.mrg.cpp,这是MSVC编译器对特性作了展开以后生成的源代码。/Fas编译选项生成相应的汇编代码。
我们看看native_event.mrg.cpp就足够了解native event的实现方法了。
__event关键子被展开成为一个事件函数链表指针,一个虚构造体,一个模板构造体,3个模板函数,一个名为__RemoveAllEventHandlers的成员函数,一个与event名同名的inline函数。除此以外还有4个辅助结构体。 可见event机制是非常类似宏定义的实现方案。
__hook通过__AddEventHandler模板函数将函数指针追加到函数链表里。__unhook从链表中删除函数指针。
__raise本身没有什么用处。实际调用的事件函数的时候,会循环调用函数链表里的函数。函数链表的每个节点里都存储了对象实体指针(this)和成员函数指针。成员函数指针同void*指针的转换利用了__eventingGetAddr这个灵巧的辅助类。
虽然代码看上去有点乱,但并不是很长,应该很容易看懂。
我在第二篇随笔里提到的bug,发生在
??????? int __isEqual(void* p, void* pfn)
??????? {
??????????? return ((T*) p == this->p) && (__eventingGetAddr::__getMAddr(pfn) == (void ( T::*) ()) pmfn);
??????? }
这个函数里。多继承的情况下对(void ( T::*) ()) 形式的指针做比较是比较微妙的,明明相等的指针确返回了false。查看汇编代码发现一共比较了8个byte,两个DWORD PTR,具体为什么这么做我还需要做一些分析。
看上去一个可行的代替方案是:
??????? int __isEqual(void* p, void* pfn)
??????? {
??????????? return ((T*) p == this->p) && pfn == __eventingGetAddr::__getVAddr((void (T::*) ()) pmfn));
??????? }
将函数指针转换成void*,然后再做比较。从asm看到这产生了高效的代码。
这个BUG导致的后果就是:无法在ATL/WTL中使用native event。这使的这一机制几乎失去了意义。
警告:使用native event要小心。
建议:在MSVC改正BUG之前不要使用native event。
CodeProject里有一篇最近发表的文章提出一种FastDelegate方法,似乎是不错的single-target delegate 解决方案。boost的function和signals则是更加值得关注的。
SYMPTOMS当在一个使用多继承类作为event_receiver的未托管应用程序中unhook (__unhook) 一个native events时, 将会失败。__unhook将返回1(表明没有成功地unhook。在应用程序结束以后native event机制造成了内存泄漏.
CAUSE这个问题发生在事件的接受者(event_receiver)是多继承类的情况下。在unhook的时候event的注入代码无法正确比较成员函数指针。
WORKAROUND
这个问题可以使用下面的代码重现:
#include
class A
{
?int a;
};
class B
{
?int b;
};
[event_source(native)]
class CSource
{
public:
?? __event void MyEvent(int nValue);
};
[event_receiver(native)]
class CReceiver : public A, public B //多继承
{
public:
?? void MyHandler1(int nValue) {
????? printf("MyHandler1 was called with value %d.\n", nValue);
?? }
?? void MyHandler2(int nValue) {
????? printf("MyHandler2 was called with value %d.\n", nValue);
?? }
};
int main() {
?? CSource source;
?? CReceiver receiver;
?? __unhook(&CSource::MyEvent, &source, &CReceiver::MyHandler2, &receiver);
?? __hook(&CSource::MyEvent, &source, &CReceiver::MyHandler1, &receiver);
?? __raise source.MyEvent(1);
?? __unhook(&CSource::MyEvent, &source, &CReceiver::MyHandler1, &receiver);//失败
?? __hook(&CSource::MyEvent, &source, &CReceiver::MyHandler2, &receiver);
?? __raise source.MyEvent(2);
?? __unhook(&CSource::MyEvent, &source, &CReceiver::MyHandler2, &receiver);//失败
?
}
运行结果
MyHandler1 was called with value 1.
MyHandler2 was called with value 2.
MyHandler1 was called with value 2.
MyHandler2没有被正确unhook。
The information in this article applies to:
- Microsoft Visual C++ .NET (2002)
- Microsoft Visual C++ .NET (2003)
- Visual C++ 2005 Express Edition Beta
1,WindowsXP的SP2已经正式进入Windows Update了,至少日文版是这样。
防火墙,放病毒等等基于安全性的考虑会对广大用户产生什么影响?
2,我遇到奇怪的MSDN内容无法显示问题已经若干个月了。在我安装最新的2004.7版本以后更是完全无法使用MSDN了。我的开发环境是Windows XP Profession SP2+VS.NET 2003。MSDN的所有页面都显示'This page cannot be displayed' ,在我以前安装的msdn版本里还能有个别页面可以显示文字。这回变的更加彻底了。而我在另外一台windows2000的机器上安装这套MSDN则完全没有问题。
我google以后还真找到了难兄难弟http://www.dotnet247.com/247reference/msgs/48/243646.aspx,
"The help wouldn't work at all, I keep getting 'This page cannot be displayed' and the error is 'Cannot find server or DNS Error Internet Explorer', so finally I re-installed MSDN for VS.NET 2003 and i still keep getting the same problem. Even clicking on 'Help on Help' was coming up with the same error"
同我遇到的症状一模一样。如有人知道原因,还望不吝赐教。
刚刚安装,实验了visual c++ 2005 express。
安装过程很smooth,没有遇到任何障碍,安装过程类似IE的安装,首先下载安装引导程序,执行后,他会自动下载需要的安装文件。经过一次重起以后就可以使用express了。
express没有提供atl/mfc头,只有标准库。所以只适合体验一下VC8带来的C++新特性。
我通过设置目录让express使用VS2003的atl·mfc库,发现无法编译。
因为VC8改变了一些语言规范,比如不允许在拷贝构造函数上使用摸板特例化,否则会发生Compiler Error C2299
' function ' : behavior change: an explicit specialization can not be a copy constructor or copy assignment operator
Previous versions of Visual C++ allowed explicit specializations for a copy constructor or a copy assignment operator.
The following sample generates C2299:
Copy Code
// C2299.cpp
// compile with: /c
class C {
template
C (T t);
C (const C& ); // OK
template <> C (const C& ); // C2299
};
在编译atlbase.h时就会得到这个错误。
看来编译windows程序还是需要下载包括包括atl/mfc的完整vs2005
经过改良的帮助系统也感觉挺舒服。
追记:对纯SDK的程序没有问题。
经过对atlbase.h等头文件的改造,又调整了若干参数,WTL提供的samples也已经被顺利编译过去了。
重粒子@本文今后也许会适当更新
zhanbo说他的下一个Quiz会从他的随笔里出题,我就随便翻看了一下他的一些技术随笔,第一个就看到了Perf: Conditional("DEBUG")对性能的影响 这一篇。
我想不好的编码习惯再加上使用这个了ConditionalAttribute会影响到代码的正确性。利用MSDN里的例子举例并评论如下:
using System;
using System.Diagnostics;
class Class1
{
[STAThread]
static void Main(string[] args)
{
TextWriterTraceListener myWriter =
new TextWriterTraceListener(System.Console.Out);
Debug.Listeners.Add(myWriter);
Console.WriteLine("Console.WriteLine is always displayed");
int i=0;
Method1(++i); //使用++i会导致不可预料的结果,因为根据不同的编译条件,这一行可能不会出现在IL里
Method2(++i,++i);//上一行的有无会影响这一行里i的值
//Method1("abc"); 即使根据条件这一行不会出现在IL里,也会在编译时检查参数类型。这会导致编译错误,而不是执行错误。MSDN错误地写成了type-checked at run time
}
[Conditional("CONDITION1")]
public static void Method1(int a)
{
Debug.Write(String.Format("Method1 - DEBUG and CONDITION1 are specified:{0}\n", a));
Trace.Write("Method1 - TRACE and CONDITION1 are specified\n");
}
[Conditional("CONDITION1"), Conditional("CONDITION2")]
public static void Method2(int a,int b)
{
Debug.Write(String.Format("Method2 - DEBUG, CONDITION1 or CONDITION2 are specified:{0},{1}\n", a ,b));
}
}
D:\DOTNET>csc /target:exe /d:CONDITION2,DEBUG,TRACE /out:CASCS.exe CAS.cs
上面举例说明了,在分工合作进行开发的情况下,应该避免使用在调用函数的参数里更改变量。因为你的调用命令并不一定会被编译到最终的结果里。会发生看被调用方脸色而定的情况。我们使用 #if 或者 Debug.Write这样的命令都是可以预料结果的,而这个Attribute确让我们心神不定。
推而广之,这个Attribute使得调用方编写的任何函数调用都有可能不翼而飞。如果我写编码规范会禁止使用这个Attribute。
昨天，WTL的创造者Nenad Stefanovic将最新的WTL版本 7.5.4133放到了 SourceForge.net上。这是继 Wix之后的第二个由微软贡献的开放源代码项目。 可以说MS走出这一步，真的很不容易。从2003年4月12日MS的Pranish Kumar发mail说WTL将会开放到2004年5月12日真的走出这一步，耗时13个月。 另外听说WindowsXP的盗版用户也可以安装即将推出的SP2，MS的Barry Goffe说："It was a tough choice, but we finally decided that even if someone has pirated copy of Windows, it is more important to keep him safe than it is to be concerned about the revenue issue." 无论怎样，看上去MS变得更加灵活和开放，他们对社会的贡献度变得更大。
To: wtl@yahoogroups.com
From: "Nenad Stefanovic"
Date: Wed, 12 May 2004 15:57:08 -0700
Subject: [wtl] ANN: WTL moves to Open Source!
Hello everybody,
WTL is now available as an Open Source project on SourceForge.net. WTL
is now part of the Microsoft Shared Code initiative that enables the
community to contribute to the project.
You can find the project at http://sourceforge.net/projects/wtl.
Feel free to send your questions/comments/suggestions to me.
Cheers,
Nenad
在中文版.Framework SDK文档的里的"从对话框的父窗体检索信息"一节写的不清楚,英文MSDN联接在 这里。 原文如下: 根据对话框的用途，可能希望访问该对话框的父窗体提供的信息。对话框的初始化可能需要此信息，或者此信息可能涉及有关父窗体的应用程序状态的特定详细资料。
使用该对话框的 Form.ParentForm 属性访问父窗体的公共成员。应当将由 ParentForm 属性返回的引用显式转换成适当的类型。 下列代码演示如何使用 ParentForm 属性访问父窗体上的属性（在此示例中为 Text 属性）：
' Visual Basic
Public Sub GetParentText()
Dim x as String
x = CType(Me.ParentForm, Form1).Text
End Sub
// C#
public void GetParentText()
{
string x = ((Form1)this.ParentForm).Text
}
可是所谓的 父窗体指的是什么呢? 这里的ParentForm属性只有在MDI环境下的子窗口才有效,可见父窗体指的是MDI风格的父窗口。(在MSDN里这之前的章节里根本没有提到过MDI字样) 如果你是通过一个普通的ShowDialog(Me)显出出来的窗口,那么千万不要被MSDN误导,这时候的父窗口需要通过Owner属性取得。我想Owner这个属性的用途远远大与ParentForm。(为什么会弄出两个属性呢???) 读MSDN很有用。我知道了Close()并不会真正关闭窗口,只是Hide()而已。Dispose()才是生死判官。呵呵。
C#不支持缺省参数。只能通过重栽来实现缺省参数的需求。VB.NET和C++都支持。可是特性(attribute)确支持缺省参数。
另一方面,属性property的set里面有缺省参数value。
难道不自相矛盾吗???
1,使用System.IO.Path.GetFullPath(.)或者System.IO.Path.GetFullPath("c:")这样的命令,每次运行可能得到不同的结果。特别是是使用VS.NET开发时。而且Framework1.0和1.1的运行结果也可能不一致。比如:GetFullPath("c:")「注意不是C:\」,在VS.NET 2002下经常会得到C:\Program Files\Microsoft Visual Studio .NET\Common7\IDE这样的结果,但有时也会得到C:\。即使你将CurrentPath设成C:\也没有用。由于Path的IL内部使用经过优化或者是native的nGetFullPathHelper()函数取得FullPath,我无法分析具体的原因。MSDN上也没有给出足够的信息。
2,通过继承Control来定制自己的控件的时候,请注意属性初始化的位置。
方案(1) 变量声明既初始化
Private _path As String = System.IO.Directory.GetCurrentDirectory ''初始位置
Public Property Path() As String
Get
Return _path
End Get
Set(ByVal Value As String)
_path = System.IO.Path.GetFullPath(Value)
End Set
End Property
方案(2)在New里初始化
Private _path As String
Public Property Path() As String
Get
Return _path
End Get
Set(ByVal Value As String)
_path = System.IO.Path.GetFullPath(Value)
End Set
End Property
Public Sub New()
MyBase.New()
Me._path = System.IO.Directory.GetCurrentDirectory ''初始位置
End Sub
方案1,一般情况下不会出现问题。方案2,VS.NET的DesignMode会自动将你项目所在目录的写入Form的InitializeComponent()里。
如同,
.... ...
MyControl.Path = "C:\MyProject\TestControl"
.... ...
这样你的程序配布到其他机器上的时候,可能会出现目录不存在的错误。
以上代码为VB.NET。
不管你是否相信,BUG永远与我们同在。包括开心喜欢调侃的使用JAVA的"勇气"与"机遇"号火星探测器。 今天遇到的问题是来自.NET Framework 1.0/1.1的FileStream。 现象: 当我将一些文本内容写到软盘里的一个文件的时候,出现了IOException,磁盘容量已满。我的catch部分捕获了这个异常,但是我无论如何无法关闭已经打开的文件。结果就是在软盘里生成了一个0字节的文件,在我的程序不完全关闭的情况下,我用文件管理器无法删除它。 原因: 我发现这个异常是由Close引起的,Close方法在内部调用了Flush方法将缓冲区里的内容写到软盘里去的时候,发生了这个异常。异常发生以后,FileStream没有关闭文件句柄(HANDLE),导致文件一直被占用。即使我试图用CloseHandle来关闭文件句柄也不成功,原因是取得Handle这个属性在内部会调用Flush方法,导致异常发生。 解决办法: 1,不用.NET Framework 1.0/1.1提供的FileStream,自己封装Win32 API (太不现实了吧  ) 2,在write之前,先调用SetLength。SetLength这个方法会改变stream的大小,你需要预先计算一下你准备写多少字节到文件里去。如果磁盘已满,在这个方法上就会发生异常,这时候内部缓冲区里还没有内容,所以Close会正确关闭。 3,Close之前清空内部缓冲区。FileStream的设计者为了保证数据都会被写入文件,在这个类的很多地方都调用Flush来将内部缓冲区的内容写到磁盘上,而没有给用户提供直接操作这一缓冲区的方法。 只好用一些黑客手段达到目的了。 ... catch( IOException excep ) { // 清空内部缓冲区 Type streamType = stream.GetType(); System.Reflection.FieldInfo field; // 得到private int _writePos 的FieldInfo field = streamType.GetField( "_writePos",BindingFlags.NonPublic | BindingFlags.Instance ); // 设置缓冲区指针的位置为0 field.SetValue( stream, (int)0 ); } finally { stream.Close(); // Close 成功。 } 总结: 方法3无法保证对.NET Framework 今后的版本也有效。方法2对于很多情况不是很有效。方法1需要高超的技术水平。方法0,期待MS改进它的Framework 。 参考: 1,http://mag.autumn.org/Content.aspx?id=20040202140342(日文) 2,http://www.gdncom.jp/general/mllog/tech/techDetail.aspx?ID=215(日文)
几乎是在不知不觉中VC7为C++提供了native event这一扩展功能。
背景和动机:
当一个对象改变了状态,他怎么通知"关心"它的其他对象呢?
C++一直没有一个很好的机制解决这个问题。一般的作法是采用从C语言继承过来的回调函数的办法。
函数指针的定义方法
int func(int a,int b,int c);
int (*fp)(int ,int ,int) ;//fp是一个函数指针，
fp=func;
这种回调机制有几个问题
1,一个回调函数只能通知一个接受对象,无法同时通知多个接受者
2,如果没有接受对象需要单独判断
3,使用类函数做回调函数会比较麻烦,一般使用静态函数
boost::function是一套对回调函数的封装类。多少缓解了上面的几个问题。
如果是windows编程的话,可以利用另外一些机制完成这种对象之间的"通知"任务。比如消息,EventObject。但这些方式都依赖与复杂的SDK API。不是C++语言本身的功能。
总之C++其实没有一个属于自己的事件模型。
模型:
从VC7开始,MS提供了一个扩展的C++事件模型:Unified Event Model。 这个模型统一提供了一致的方法来解决在native C++(非COM) , COM, 和managed classes中的事件通知需求。
适用:
这种模型支持对象之间事件通知。支持多线城并发。支持从拥有事件类继承,也支持子类里拥有事件定义。
例子:
MSDN上提供了基本native event的例子。网址为:
http://msdn.microsoft.com/library/en-us/vccore/html/vcconEventHandlingInNativeC.asp
分析:
我们通过一个小程序看一下,native event的内部机制。这个小程序和分析结论来自http://lamoo.s53.xrea.com/diary/diary2003a.html
我对其做个小的修改。(见附件)
1,一个event占用4bytes的内存。
2,分配内存的时候一个类里定义的event会集中在类的最后集中分配。
3,按照追加(hook)事件的顺序,内存中维持一个单向链表。
4,hook事件的接受对象如果被删除(delete),不会自动被unhook。如果没有明确地unhook,下一次raise事件是,会有不可预料的错误。
5,event_source和event_receiver属性可以省略。
实做:
我在自己的一个程序中使用了native event,那是一个通过HTTP协议自动下载更新模块的类。那个类实例运行在单独的线城里,通过event将联接网络,下载的进度通知父线城,父线城是一个对话框,将收到的信息显示出来。这一切类似IE的下载对话框。也就是说事件是垮线城通知的。
如果你熟悉ATL7,那里面有一个CAtlHttpClient类,它的通知方式采用的是回调函数。而通常的作法往往是SendMessage给一个父线城的窗口句柄,通过windows的消息循环调用显示状态的函数。
课题:
我们现在面对两个问题:
1,一个hook必须对应一个unhook,这就像分配内存是一个new必须对应一个delete一样。如果忘记unhook就会发生内存泄漏。
2,任何一个接受者对象被delete以后,不会自动unhook。
所以我们有一个课题,就是对这种事件模型进行包装,制作一个包装类(wrapper class)来解决上面这两个问题。这个类应该类似auto_ptr,利用析构机制自动unhook,还要像boost::function一样支持各种各样的event函数。
参考
1,http://msdn.microsoft.com/library/en-us/vccore/html/vcconEventHandlingInNativeC.asp
2,http://lamoo.s53.xrea.com/diary/diary2003a.html
3,http://www.boost.org/doc/html/function.html
dev-club上有一个让开心就好FT的问题
其题目的本意是希望能够方便地调试存储过程,希望能将存储过程的执行细节用log打出来。
照我的理解
由于存储过程编译执行的,内部处理不是简单的字符串置换,是无法实时输出完整的执行细节的。
sql server内部有一个fn_get_sql函数,可以得到当前告诉锾存里的sql文,这个sql应该只是输出调用命令,而不是解析以后的存储过程内容。
如果希望在存储过程里输出一些信息到客户端以方便了解存储过程执行了那些条件分枝,可以使用PRINT命令。PRINT出来的结果,在客户端可以通过SqlException的Errors分别得到。每一行PRINT都会形成一个SqlError存储在Errors这个集合里。
但是这些信息只有发生SQL异常的时候才能得到,如何没有发生异常也得到调试信息,我不知道。
你知道吗?
JGTM'2004 [MVP]
Sure. One can use SqlConnection.InfoMessage event to get all these information. HTH. :)
谢谢JGTM
对于一个严格的项目来说,画面的大小,颜色,所用的字体等等细味的地方都是有要求的。
今天遇到一个恼火的问题:我用VB.NET开发了10几个winform,按照设计规约设置了form的属性,包括字体,ControlMenu和size。这些属性都可以在design模式的属性窗里指定,真是很方便的。而且我还使用了form的继承这一技巧,使这10几个form的外观都一致。今天遇到的问题是我的程序拿到另外一台机器上,打开项目,一查看我设置的属性。为什么size都不对了呢???这真是一个涉及个人名誉的严重问题。这么点小事情也做不好可不行啊。
调查开始了.....(省略若干字)
答案:
在VS是根据我的设定生成的代码里根本就没有size这个属性,只有ClientSize。MSDN上说,
窗体工作区的大小是除边框和标题栏外窗体的大小。窗体的工作区是窗体内可放置控件的区域。当执行图形操作或调整窗体上控件的大小和位置时，可以使用此属性获取正确的尺寸。若要获取整个窗体的大小，请使用 Size 属性或使用单个属性 Height 和 Width。
可是这个size是根据windows的desktop设置决定的,你的windows使用不同的theme,不同的字体大小都会影响一个form的边框大小和标题栏大小。
VS的生成程序聪明地用你指定的size减去当前的边框大小和标题栏大小,认为只需要记住clientsize就可以了。可是用户可是只能设置size啊,这样的在不同的theme下按照同一个开发约定开发出来的form大小就可能不一致。
这是一个BUG???我认为是。
重粒子@请去朝圣的MVP们转达民情。
从n年前大学的毕业设计开始到现在,大大小小的软件项目做了很多。切身体会是如果一个项目不想最后演变成垃圾,重要的就是交流。
我的大学毕业设计是给一个国外大公司的做的,当时自觉已是C语言高手,2周做个dos下的editor都是小case,何况有一个学期的时间去"发明"(笑)一个排序程序呢。除了验收前一天,硬盘损坏,通宵重写了部分代码以外,程序做的还算顺利。考验来自后来的code review,先是部长写了review计划书,指定参加review的人员,review的方式和目标。参加人员是同一个部门的先辈和我的同级生,5个人左右。review方式采用面对面方式(另外一种方式是回览,既将代码打印交给review人员,不讲解,由他们在自己方便的时间进行检查)。review的目标指出1000行代码应该发现的bug数目,当时的计划好像是每千行发现25个bug。
首先由我介绍这个程序用途,我的实现方案,然后一个函数一行一行的进行了讲解。其他人可以随时打断我。
...............
"这个变量有什么用途?怎么会叫这个名字?"
"这段代码是不是应该这么写......."
"这里应该有一些注释"
"哦,我发现了一个bug!"
...............
我们随时对出现的问题做讨论,有一个人负责记录我们讨论的结果,将不妥当程序的行号,原因,处理办法都记录在review报告书上。
经过两个小时的review,头冒汗声发抖,实实在在地发现很多以前想都没有想到的问题。
改正这些bug以后,感觉心里塌实了很多,对自己的程序质量有了很大的信心。
后来我也参加了其他人的document review, code review,一直到我带领项目,组织review。切实感觉review是非常好的质量保证手段同时它促进了集体技术水平的提高。
我带过一些刚毕业半年的newbie做过两个项目,没有review的话那结果将无法想像。
其中一个项目工期极其紧张,在设计好框架以后的两周里,5个pair居然没有一个能拿出可以运转的模块,计划可是2个人一组1周做出两个模块啊,当时真是急得火上房。主要是大家的思想还没有统一,对如何写出程序来还不清楚。关键时刻review发挥了重要作用。我参加了一组的coding工作,实际指导和暗示了程序的写法,随后立即进行review。通过作者们的讲解,以及大家的提问和讨论,大家清楚了程序越来是怎么编出来。以后的开发效率明显提高,10个人两个月50个模块(ASP+COM+Oracle StoreProcedure)艰苦地完成了,要知道10个人里面大部分是刚毕业半年的新手。
review不是万能的,也会导致一些问题
1,得罪人。在我指出一个同级生的bug时,他恨得要命,后来同我说,当时差点就想跑过来掐死我了(:>
2,惨不人睹。有的code实在太难看,作者有时自己都看不懂了,review根本就无法进行,代码必须重写。
3,导致时间紧张。有时工期非常紧张,如果每个人的代码全都进行面对面review的话,会延误工期,这时候就需要manager做出判断,进行回览形式的review。
4,bug是永远存在的。不能完全依赖review来找出所有的bug,review以后的测试才是主要的除错手段。
重粒子@到了写回忆录的年纪了
为了准备马上到来的MyDoom.B的攻击,微软准备了备用网站。 https://information.microsoft.com早些时候,SCO集团也使用了备用网站 www.thescogroup.com。 如果,MyDoom.A和MyDoom.B是同一个人写出来的话,他们他/她最少价值50万美元。这就是一个程序员的价值,虽然不好兑现:> 网络的安全从来不是空洞的。即使我们这些整天摸键盘的人也是防不胜防的,想指望那些未入门,刚入门的初级用户了解网络的风险更是困难的事情。broadband的时代有broad risk。
FeedDemon真是一个漂亮的shareware, 程序从界面到功能看上去都极其专业。用它来读blog和news确实方便。用了这个软件才真正感觉到基于XML的RSS不经意见就有所成就了。
这个软件在多国语言上还有一些bug,我只好用english界面。通过这个软件来看博客堂,还能发现博客堂的一个bug,就是RSS的头没有改成自己的。
这个channel描述信息在.Text的Dottext.Web.Rss这个类里面,是用硬编码写的。
//Channel Description
writer.WriteElementString("title","WebLogs @ ASP.NET");
writer.WriteElementString("link","http://weblogs.asp.net");
writer.WriteElementString("description",".NETWeblogs by .NET Developers");
writer.WriteElementString("generator",Dottext.Framework.VersionInfo.Version);
这个BUG要是不改正,在加channel到FeedDemon的时候可能会和已经存在的WebLogs @ ASP.NET冲突,必须手动改名。而且随笔的出处联接也都是http://weblogs.asp.net。
.Text好多地方为了重用,搞的结构很复杂,在这个小地方用硬编码确实不可理解。也许是作者对RSS功能不是特别重视吧,不过毕竟还不是最终版本。
说到bug,我还遇到了asp.net 1.1的bug。在写一个page template的时候,我将form放入一个ascx中就会导致一个客户端script错误。详细的错误描述在msdn上有描述
http://support.microsoft.com/default.aspx?id=818803
这个bug需要等待一个新的NET Framework 1.1 service pack问世。
暂时的措施是:http://www.asp.net/Forums/ShowPost.aspx?PostID=206709
在另外一个地址上有一些已经发现的bug列标。
http://support.microsoft.com/default.aspx?kbid=821156
遇到奇怪的问题先查一下KB是好的习惯。
重粒子@BUG是程序的魅力之一
1)恨不得大骂。竟然有如此SB的项目。 面对那个白痴项目,我想让它稍微聪明一点。对Oracle COM用一个类封装了一下,用起来类似MS的data access block。 居然被否定了一半。 原因是不能用缺省的VB弹出的出错信息。不是那个出错信息太少, 而是太多了。 靠靠。 2)最近连着读了日经BP网<中国故事--日本最大的离岸开发成功启示录> （1） (2) (3) 外包项目确实是趋势, 中国人件费的廉价,导致如此多的项目发注到中国去。外包项目其实对双方都是有利的。日方可以用相对廉价的代价开发出项目来。中方获得相应的外汇收入,而且一般很少发生拖欠项目经费的事情。 这样的项目一般来说都是日方写出需求说明书,概要设计书,甚至很多项目要写出详细说明书。这个写说明书的工作一般叫做上游工程。项目流到中国去以后,由中国程序员作详细设计和codeing,这个工作叫做下游工程。 外包项目怎样能够保证成功呢?软件的质量怎么控制呢?看看上面那篇文章里成功和失败的对比就很清楚了。 1:交流。交流充分与否是一个项目能否成功的基本前提。 2:热情。一般来说作下游工程没什么passion可言。日方的说明书往往写的详细之极。有的甚至到变量的名称。能否调动出中方的积极性来作这种"体力劳动"呢? 3:跟踪。项目的每一个阶段,是否有明确的负责人,日方是否清楚项目的进度。中方是否及时反应了遇到的困难? 4:测试。中方一定要作充分的单体测试,否则交给日方以后,低级的错误往往导致合作不愉快,会对中方的开发能力产生怀疑。 5:理解。相互的尊重和理解是基本的做人前提。任何的居高临下,阿谀奉承或者种族歧视都是分裂的触发器。 日本也有作下游工程的公司。比如我现在作的这个SB项目就是作详细说明和coding。日本的开发者往往听话地听作苦力。作法是否愚蠢不管他们的事。中国开发者往往是想提出自己的见解,耽误了项目的schedule。任何过分的作法都是不对的。
定论:我现在做的这个项目是极端白痴的。
说明:这是一个从VB6升级到VB.Net的项目。一小部分程序直接使用VS.NET的转换结果。大部分程序都要重新写,主要是因为数据库(oracle)的设计有一些变更。
看看我们经客户定案的程序规约:
1,使用.net framework 1.0 (not 1.1)
2,使用Oracle In Process OLE Automation Server, 而不是ADO.Net的OleDB或者OracleClient。理由1,OleDB或者OracleClient是MS做的,MS不值得信赖。(反驳意见:VB.NET也是MS做的) 理由2:VS.NET的自动转换结果使用的就是Oracle In Process COM
3,每一个函数,类,模块都有一个变量,标明它的ID,输出出错信息和log的时候用
4,共通模块使用link文件的形式引入项目,不是用DLL参照或者项目参照。
5,所有的变量都要有前缀,3个字母, 而不是1个。因为3个字母更清楚。boolean->bln,integer->int,structure->typ
6,所有的函数和过程都有前缀,3个字母加一个下滑线,表明返回值的类型。例:bln_CheckInput()
7,不仅仅服务器上要安装oracle server,客户端也有一个oracle server,用来存储客户端的数据。
8,项目里的文件路径指定使用绝对路径。D:\MDB\XXX9,
9,不要使用TRY...CATCH...FINALLY,要用ON ERROR...
这个世界一定是哪里不对了?是哪里呢?
聪明的你能告诉我吗?
年终了,今天是今年最后一天上班,下午开了"纳会",前几天项目组还开了"忘年会",前者是领导总结一下一年的工作,给大家拜个年,大家聊聊天。后者纯粹是吃吃喝喝了。 接下来一周时间,准备在家编程序。每天觉得时间不够用,这下子有一周假期,还真不适应呢。前几天一个电视节目里问:如果出了某种变故,你被告知仅有一天的寿命了,你会利用这一天做些什么?这真是一个无聊的问题,面对这样的问题,每个人有自己的回答。我想我仍然会利用这最后一天编程序的。有过太多IDEA,真正实现的寥寥无几。如果只有最后一天,还是希望实现自己的价值。  总结一下上一周: 1, No! Flash 2.0 release了,在屏蔽flash的基础上,增加了block spyware的功能。除了新浪,网易这样的新闻网站,3721,Baidu也成了 No!Flash屏蔽的对象。对那种毫不尊重浏览者选择权的粗暴广告方式实在忍无可忍。特别是对播号上网和机器型号比较老的用户而言,直接占用了他们有限的带宽和CPU。没有No!Flash的时候真想大骂这些恶德业者。 2,写了一篇对话形式的小文章。" MM与GG的对话---关与printf和字符数组"给C语言的初学者。 3,看了大怪兽 关与const的随笔,我想有必要总结一下const在C++里的各种用法,开始写一篇文章,现在写了一半,还在blogger的draft里,希望下周release它。 4,用了这么多年C++,真的没有好好总结一下,没有一个好得hint,也不会去想对于初学者会遇到些什么问题。今天在dev-club里,为了回答一个问题,总结了一下作为函数的参数时,什么情况下必须用"引用": (1)引用保证了你传入的确实是一个对象的引用并且在函数里不会像指针一样改变用途。 void fun( X *px )和void fun( X &x )的不同在于 你可不可以这么用 fun(0); 用指针就可以传入一个0(或者其他整数),也许是一个非法的地址,而且在fun函数内还可以改变px指向的地址。例如 void fun( X *px ) { X aaa; px=&aaa; } 用引用就不会有这些问题。传入0是违法的。引用在传入的时候被初始化以后,绝对不会再被改变成为另外一个对象的引用。 (2),作为重栽运算符时的参数方式。 如果你写成 X operator+( X *a, X *b ) 用的时候就只能 &val1+&val2 了。 使用引用不会有这样的尴尬。 声明的时候这样 X operator+( X &a, X &b ) 使用的时候这样 val1+val2
1,微软建议的开发流程,在这篇文章里进行了详细的论述。Team Development with Visual Studio .NET and Visual SourceSafe。特别是提供了一个叫做BuildIt的小工具,可以自动从sourcesafe里checkout最新的代码,编译,更新version,设置vss的标签,对于nightly build和每日编译真的很有用。
2,VS.Net2003提供了before build,after-build的项目选项。可以做编译前预处理,编译后的收尾处理工作。ms petshop提供了足够好的例子。
3,“星轨工作室”的Orbit翻译了CodeProject上的介绍WTL的系列文章,WTL for MFC programmer ,真是做了伟大的贡献。相信所有使用WTL的中国程序员都会感谢他的。
4,看到一篇趣文:
<<大腕 之过度设计>>
一定得选最先进的架构，
怎么也得也要分布式的，
做就要规范，
把设计模拿过来，
什么Builder呀，Adapter呀，Bridge呀，
能用不能用的全用上，
多服务器，负载均衡，
搬它几台曙光来做集群，
支持十亿用户同时访问。
同行不是用CORBA 就是用EJB，
你要用一DCOM，你都不好意思和人打招呼。
客户端旁边还要做一帮助精灵，暴可爱那种，
一口一个"May i help you sir"
一口地道西雅图腔，
倍(儿)有面子。
你说这样的程序，怎么着也要花个十万八万的吧？
十万八万？那是电费！
八千万起！
你别嫌贵 还不打折。
您得研究顾客的心理，
拿国家钱来搞研究的，
根本不在乎多花点钱。
什么叫研究你知道吗？
就是只要最炫，不要最好。
- 感谢uestc95,在他的努力下,"使用 Microsoft .NET 的企业解决方案模式"的PDF文件被重新制作出来了。新的版本没有日文字体,繁体中文字体的困扰了。虽然里面个别联接因为我不够认真而没有设置正确,但是应该不影响阅读。下载 (FROM NETEASE)
- Windows Template Library WTL 7.1 刚刚被release了。新版本完全支持Visual Studio .NET 2003,并且可以用来开发面向Windows CE的程序。 enjoy!
- 向P.J. Plauger致敬。我昨天用文本编辑器打开我的No!Flash程序时,惊讶地看到里面有他的版权信息。因为我的程序使用了Standard Template Library (STL)。他做出的贡献影响了世界,甚至No!Flash这样的小程序。
这篇来自中文MSDN的文章" 使用 Microsoft .NET 的企业解决方案模式"确实很好,很重要。我读了大约1/3。文章里面提到的内容有些是我熟知的,有些是生疏的。但感觉他们确实给我今后的asp.net项目开发提供了很好的理论基础和实践指南。我制作了PDF文件,希望在不引起任何版权纠纷的情况下,大家可以将自己的comment加进去,共同理解提高。 PDF的下载
有开发winform经验的人都知道,要想使程序在windows XP下真正拥有XP风格,需要按照下面这篇文章所说的去做。Windows XP Visual Styles for Windows Forms
首先如果你的画面上有Button,CheckBox,RadionBox,GroupBox的话,需要改变他们属性FlatStyle为System,然后追加一个manifest文件到exe文件的同一个路径下。就像App.config文件那样。
当然,在.Net Framework 1.1下,你可以不必这么麻烦,只需要加一句Application.EnableVisualStyles();就可以了。
遗憾的是,我再做的项目要用1.0，在1.0里可没有这么方便了。
我有10几个小winform程序都需要这样做,所以我首先想到建立一个模板。就像往项目里追加一个app.config一样。我仿照app.config模板作法,复制一个模板,修改里面的app.config成app.manifest文件。改好的模板放在这里了。
AppXPStyle.zip
我在修改C:\Program Files\Microsoft Visual Studio .NET\Vb7\VBProjectItems\Local Project Items\Utility\LocalUtilityProjectItems.vsdir以后可以追加manifest进入项目了,但是文件名变成了App1.manifest,而且编译以后,它不会同App.config一样被改名,拷贝到exe所在的文件夹下。
App.config真是一个magic file啊,VS是怎么做的?
我改变想法,考虑用macro来自动生成manifest,可是不知道如何得到当前所在的project,以及它生成的exe文件的路径。
|