MySQL中sql_mode、隐式类型转换、5.6/5.7的默认配置引发的问题

先介绍下标题中的三个锅 sql_mode 以下是MySQL官网文档原文: The MySQL server can operate in different SQL modes, and can apply these modes differently for different clients, depending on the value of the sql_mode system variable. DBAs can set the global SQL mode to match site server operating requirements, and each application can set its session SQL mode to its own… Continue reading MySQL中sql_mode、隐式类型转换、5.6/5.7的默认配置引发的问题

良好的源代码控制管理十戒

转自IT瘾投稿 我还没有见过比源码版本控制这样跨任意编程语言更基本的工具。 这是我们用过的最基本的工具,是很多开发团队的生命线。 那么,为什么我们经常会用错呢? 为什么一些真正的核心,版本控制系统的基础往往知之甚少? 我总结了10个实践 或“戒律” – 这通常是发生故障或错误理解的开始, 是与版本控制产品和编程语言无关的。 我会从Subversion和.NET挑选一些例子,但它们广泛适用于其他技术。   1. 如果还在使用VSS,马上停手 平心而论,在1995年VSS曾是一个伟大的工具。  不过因为有了像Subversion甚至分布式的如Git和Mercurial工具变得黯然失色。 很多年前微软已经明确表明废弃它了! 由于一系列的重大缺陷,VSS曾受到广泛的几乎一致的鄙视, 俗称为微软的源代码破坏系统 。   2. 如果源代码没有处在版本控制,那等于还没有 每天重复此咒语 – “进步的唯一标准是工作代码处在源代码控制中”。 直到你的成果出现在源代码控制里 – 变成源控制库中的项目 – 否则它根本不存在。 当然,你已经把代码做好在本地计算机上的某个地方,但,对其他人来说这不是真的做好了,对吗? 他们不能拿到你的版本,他们不能合并他们的修改,你无法部署它(除非你部署出错 ),一旦发生硬盘损坏你将永久丢失这些文件。 你要保持除非提交否则根本还没有的心态,一大堆的其他良好的运作因为没有提交开始陷入困境。 你应将任务分解成更小的单位,这样你可以原子地提交。 您应频繁地整合,保证自己不受本地硬件故障的影响。 但更重要的是(至少对你的团队领导来说),你证明你实际做了东西。 燃尽图曲线下降或分解列举任务列表是很棒的,但他们真的顺畅吗? 除非这些与工作源码控制中的工作代码关联上,他们才意味着完成。   3. 尽早提交,频繁提交,越快越好 继续上一点,只有这样,才能避免“幽灵代码” -那些只有你可以在你本地计算机上能看到的代码-要尽快地尽早地频繁提交到VCS版本控制系统里 。 上面提到的是应尽早和经常的完成提交,但其中有几点可以使你的工作方式有意义: 1,每个提交的修订版能给你一个回退的位置。如果你完全搞砸了,你想回滚一个小时的变化还是一个星期的吗? 2,合并噩梦的风险不会显着增加。合并从来就没有乐趣。 当你几天没提交代码时,你突然发现到你已经与其他人的变化有50个冲突,你肯定不开心。 3,它会强迫你将功能隔离在分散的工作单元。比方说,你已经有了一个3人天功能需实现。 通常,因为他们想试图整个地构成一个逻辑单元直到这段时间结束才提交。 当然,像这样大的一个任务不可避免地由小规模,分散的功能组成,频繁提交迫使你识别这些原子小任务,然后逐一地完成它们提交给VCS。 当你以这种方式工作时,你的提交历史形成一个有规律的模式,每天多次提交。 当然,并不总是保持这样不变的模式,有时我们停止开发和重构进入测试阶段,或任何其他中断正常的开发周期的活动。 然而,当我看到一个独特的 – 甚至整个项目,在一个正常的开发周期,有整天甚至很多天什么没提交,我很担心。… Continue reading 良好的源代码控制管理十戒

Objective-C内存管理

总结表格: 获得方式 临时变量 成员变量 通过alloc/copy/init方式获得 用完release 再dealloc中release 其他方式获得 啥都不用管,也不用release 调用retain,并在dealloc中release 这其中的原因是alloc/copy/init方式获得的对象有retainCount = 1,所以在生命周期结束时需要手动release,不管是临时变量还是成员变量。对于其他方式获得的对象,由于约定这种对象都是autorelease的。所以对于临时变量正好啥都不用做。但是成员变量啥都不做就不行了,因为出了生命周期就会autorelease了,所以额外retain一下即可。既然retain了,在成员变量所属的类的dealloc中再release。 以下是Learn Objective-C on Mac的例子: 对于临时变量: [c light=”true” toolbar=”false”] NSMutableArray *array; array = [[NSMutableArray alloc] init]; // count: 1 // use the array [array release]; // count: 0 NSMutableArray *array; [/c] —————————————————————– [c light=”true” toolbar=”false”] array = [NSMutabelArray arrayWithCapacity: 17]; // count: 1,… Continue reading Objective-C内存管理

打算翻译一篇catch22上的关于拖放操作的文章

原文地址是 在这里 最近看了一下ole的拖放操作。之前看过一点点COM。还能理解。于是打算翻译这篇我觉得还不错的文章。 全文一共6部分。还蛮长的。不知道能不能坚持翻完。也打算一部分一部分来。 时间标记一下:11/16/2010 Update 0: 刚开始第一章的翻译,今天发现原来在csdn上就已经有一篇翻译了。那我就不重复造轮子了。 给出链接:http://blog.csdn.net/UImaking/archive/2009/12/19/5039650.aspx 不过这篇也是转帖,更早的帖子在这里: http://www.cppblog.com/windcsn/archive/2006/03/01/3598.html

CALLBACK(__stdcall)调用方式

今天写一个程序,用到HOOKPROC,HOOKPROC的定义是必须使用CALLBACK定义的。结果我在写一个键盘钩子的时候忘记了加上CALLBACK,也正是因为没有加CALLBACK,使我在__declspec(dllexport)后这个函数在DLL中的名字也没有变形,一般加了CALLBACK后,即使声明为extern “C”也没用,必须要用上module definition file 来LINK才行。这是等会儿讲。先说漏了这个CALLBACK的事情。我写好了DLL,dumpbin一看函数都导出了。于是在主程序中开始LoadLibrary GetProcAddress等。这里要说一下GetProcAddress这个函数,其返回值是FARPROC,FARPROC的定义中是有WINAPI的,也就是__stdcall的,但是如果要求从DLL中Get一个没有__stdcall定义的函数出来也不会有问题。然后传给HOOKPROC类型的函数指针也没问题。于是这样就把一个原本没有CALLBACK的函数用于了SetWindowHookEx。而要是没有这样一圈兜下来。原本将没有__stdcall定义的函数传给SetWindowHookEx是会编译错误的。这里错误主要还是在将FARPROC的函数强转成了HOOKPROC。导致最后我的程序对于键盘事件总是没有钩住。可能在,还有莫名奇妙的crash,最后甚至蓝屏了,SYSTEM_SERVICE_EXCEPTION(0x3B)。后来仔细看了HOOKPROC的声明,发现了CALLBACK,加上。这次是自己基本功差了。发现DLL的名字总是不能以C方式输出。其实加了extern “C”后对于__stdcall的函数还是会加上一些修饰的,形如_Function@2,要彻底没有修饰,仅以Function名字出现还需要在LINK时加上/DEF:”hooh.def” (在VS的LINK中的INPUT中有Module definition file)。这样名字就对了。问题就都解决了。