精选技术长文、实践记录与系统化阅读
低噪声、高可扫读；标题、摘要、来源、标签一目了然。
采集自各技术站点的近期文章。
（本文中所有汇编代码均采用Intel语法，即dest在左边） C++中的函数被编译成汇编代码的时候，必须遵循一定的规范，如参数怎么传递，栈指针怎么增减。Visual C++中，一共有5种情况： __cdecl __stdcall __fastcall __thiscall 默认情况下，是__cdecl。__cdecl 和__stdcall的区别是：__cdecl是调用者清理栈，而__stdcall是被调用者清理栈。所以，理论来说，__cdecl生成的代码体积会更大。但是，对于varargs函数，由于被调用者并不知道参数的具体长度，所以这样的函数只能采用__cdecl。
从上个月的最后一周（4月21日）到现在，我一直在做对flash的逆向工程，主要是使用IDA做静态代码分析。这方面我完全是外行，上次干这个还是在大3的时候，给宿舍用的电信的802.1x客户端做开源FreeBSD版。下面介绍一下中途遇到的困难以及现在的进展。 首先是用PEiD做壳检测，什么都没查到，我估计是因为PEiD很久没更新了。从PE Header中能看到linker version 是9.0，所以，如果它没有加壳的话，那么PEiD应该能检测到vc++ 2008的runtime才对。就我后续的分析来看，没有发现它带壳。所以这次的工作跟我上次做802.1x客户端相比，简单了很多。
我之前一直有个误解,以为DH的私钥的长度必须跟公钥一样。 今天调试flash的时候发现，它的DH算法用的私钥长度竟然是128位，虽然它采用的同余群的p是1024位的。我然后翻了些资料，看DH算法对私钥的长度有何要求。从Sun JDK的代码来看，对私钥x只有一个要求，1 <= x <= p-2，那么也就是说只要它的长度小于1024就没有问题。
去年CSDN密码泄露案公布之后，很多专家跳出来讨伐说他家的程序员太白痴居然还在数据库里面存明文。最近linkedin的事件出来之后，如何保存密码，这个问题又被拉出来谈。我认为，密码怎么保存与怎么在网上传输，这两个问题不能分开来谈。除非你已经有了安全的信道，如SSL，否则还是存明文为妙。 mysql对其原始的CHAP协议做了些改进： storedhash=sha1(passphrase) reply=xor(passphrase, sha1(public_seed,storedhash) 在网络上发送的是public_seed、reply，数据库里面存储的是storedhash。所以如果只是拿到了mysql.user表里的数据，而没有原始的passphrase，想要构造出reply，还是挺困难的。不过我估计这个算法是工程师自己想出来的，根本就没找安全专家讨论过，未必经得起推敲。
如果你是个Linux用户，你可能听说过不需要去对你的linux文件系统进行磁盘碎片整理。也许你注意到了，在Liunx安装发布包里没有磁盘碎片整理的工具。为什么会这样？ 为了理解为什么Linux文件系统不需要磁盘碎片整——而Windows却需要——你需要理解磁盘碎片产生的原理，以及Linux和Windows文件系统它们之间工作原理的不同之处。 什么是磁盘碎片 很多Windows用户，甚至是没有经验的用户，都深信经常对文件系统进行碎片整理会提高计算机的速度。但并不是很多人知道这其中的原委。 简单的说，磁盘驱动器上有很多扇区，每个扇区都能存放一小段数据。文件，特别是大文件的存储需要占用很多不同的扇区。假设现在你有很多个文件存在的文件系统里，每个文件都会被存储在一系列连续的扇区里。后来你更新了其中的一个文件，它的体积变大了。文件系统会尝试把文件新增的部分存放到紧邻原始文件的扇区里。
在11g之前所有的Oracle数据库后台或者前台进程如果需要获得当前时间信息，就需要调用操作系统的gettimeofday()函数或者说是相类似的函数。而VKTM进程就是专门用来获得时间信息然后将信息存放在SGA中供其它进程使用，这样其它进程当需要时间信息的时候，只要到SGA的某个内存位置去获得就好，而不用频繁调用gettimeofday()函数。毫无疑问，这样效率会更高。
在PHP中, 判断静态与否不是靠”::”(PAAMAYIM_NEKUDOTAYIM)符号, 而是靠calling scope. 那么, 什么是calling scope?
有同学问到group by的实现，发现可能存在误解，简单说明一下。
当有朋友问我，什么是效果营销，我相信这是一个非常好的问题，难道还有营销是不为了追求效果的吗？的确，即使是为品牌造势的活动也是为了追逐品牌的传播和好感。不过，为了让事情变得简单一点(我必须指出，我一直以来在尝试用定量化的方法衡量品牌营销的效果，在我的培训中也有一些案例，但品牌营销效果的衡定确实是一项异常复杂的工作，需要远超过网站分析的专业努力和执行)，我们决定让这个沙龙聚焦在明确产出的营销上，即我们所追求的ROI、转化以及实际能够以金钱或者数量衡量的营销上。这也意味着，我们企图通过数学的方法来实现分析和优化是可能的，并且我们理应探寻其中的规律。
OPTIMIZER_INDEX_CACHING和OPTIMIZER_INDEX_COST_ADJ参数说明
从同事那里借来了一本单墫教授主编的《初等数论》奥数书，看到很多精彩的问题，在这里做个笔记，与大家一同分享。不少问题和答案都有过重新叙述，个别问题有所改动。 问题：找出所有使得 2n - 1 能被 7 整除的正整数 n 。答案：由于 2n 的二进制表达为 1000…00 （n 个 0），因此 2n - 1 的二进制表达为 111…11 （n 个 1）。而 7 的二进制表达是 111 ，要想让它整除 n 个 1 ，显然 n 必须是也只能是 3 的倍数。 问题：是否存在 100 个数，使得它们的和等于它们的最小公倍数？答案...
进程间通信的技术细节繁杂，以Linux 系统为例，就有文件，管道，消息队列，信号量，RPC，UNIX Socket, RPC 等等多种方式。Windows 系统还有邮件槽, COM 对象等等。Mac OS 则有 AppleEvent 等等。在这里我们介绍 Plan 9 系统中一个不太为人所知的 IPC 机制：Plumber，或者叫做管道工。我在”开发人员为何应该使用 Mac OS X 兼 OS X 小史“中曾赞扬过 Mac OS X 系统中的 AppleEvent 进程间通信机制对工作效率的提升。和AppleEvent 类似，管道工也是对图形界面下进程间通信的一个尝试，不过在通信的粒度上有所区别。
从某种意义上来说，工具是个桥梁。工具的设计者是为了解决一类问题而设计工具的，工具的使用者也是为了解决一类问题而使用工具的。这两者对于工具都有自己的理解。工具的设计者通常会预测此工具会被用来解决怎样的问题，在设计工具时预见使用者的偏好，而工具的使用者则根据所面临的问题选择合适的工具。
如何和“老板”沟通 我们是一线工程师的时候，和我们的直接技术管理者沟通是非常容易的。我们的技术架构、代码风格、系统扩展性、工程化全局考虑就是我们赢得信任和信赖的名片。但是随着我们的经验的日渐丰富、层级的提高，我们要面对更高层级的管理者的时候，沟通不是一件容易的事情，需要我们做更多的准备和精炼。 我们要获取资源，要获取执行方向的认同，我们必须建立和高层级管理者建立信任，给与他们持续并一致的事实称述。 只给事实 人不是机器，不是代码，我们有时候会不自觉的扭曲一些描述或者信息，让我自己看起来更能干或者让别人看起来不是那么好，有的时候甚至会在背后痛斥别人的不足。经过一次次的个人经历和重复犯上面的错误后，我知道了那样做是小人所为而已，古人说“君子之交淡如水”，从另外一个角度来解读，我认为君子间的认同和信赖，就是建立在相互沟通“事实“之上，而不是个人好恶。
再谈沟通的策略 什么叫做策略，我的认识就是做事情的方法，有些时候光有很好的原则，而没有好的方法也是不行的。比如淘宝的”十月围城“事件。 哪些策略是我们在进阶之路上需要注意的呢？第一条，也是我感受最深的一条： 说”Yes“而不是”No“ 我在做一名开发工程师的时候，尤其是处理需求的时候，我是经常被鼓励说”No“的。但是后来我慢慢发现，随着我越来越‘老’，我需要更多的说”Yes“了。因为当我是一个按图索骥进行开发的一线工程师时，我的擅自行动不加考虑的说”Yes“会让整体项目受到拖累，但是当我逐渐介入整体设计、架构设计和可行性分析的时候，我要做的事情更多是作为产品业务或者销售人员的咨询师，所以更多的情况是在深入分析需求后，站在尽可能覆盖需求的角度给出，尽可能合适的方案进行选择。 换句话说，我们的角色要求就是”找到一条可行的道路“。
谈谈沟通能力——沟通的准则 如果一名工程师要成长为资深专家或者是架构师或者是技术管理者，沟通是必不可少的技能和工作的工具。 对于资深专家或者架构师，对沟通能力的要求甚至大于技术管理者，因为他们没有行政权力，但是却往往需要主导、指导、控制跨小组、跨团队乃至跨公司的项目，怎么能够把各个组织里面的人有效的驱动起来，沟通能力非常重要。 但是我们工程师在成长过程中，往往不注意或者没有收到这方面的训练，当他技而优则”升“成为专家的时候，问题就来了，尤其是他作为团队中坚，既要和一线工程师交流又要向老板汇报，真的是压力山大啊！ 沟通方式和技巧往往是因人而异的，但是我们还是可以总结出一些基本准则供大家参考。 先说一下沟通的准则： 先听后说 古罗马哲学家Epictetus曾经说过很有意思的一句话，人之所以要少说多听，是因为我们只有一个嘴巴但有两个耳朵。
最近这本书给了我启示《12 Essential Skill for Software Architects》。那就慢慢写下读书笔记吧。 那么怎样才能做到泥？ 保持关系，而不是一味的纠正别人 工程师由于每天都在和大量的程序、机器打交道，工作的重心之一就是订正各种各样的错误，但是人不是软件更不是机器，一味的去订正别人的错误是非常有害的（而且我们当时认为的“错误”其实更多情况下是我们没有全面审视而得出的结论，随着社会压力、生活节奏加快，这点尤其突出）。在纠正别人之前，先学会问自己两个问题？ 1. 这个“错误”是不是非常重要？ 2. 暂时忽略这个错误会不会给公司或者组织带来重大影响？ 如果答案是“NO！”，那么我们应该停止：打断别人去纠正”错误“的行为。
从2010年开始介入量子统计系统的设计到开发，恍然间已经两年时间过去了。很多情况下都是业务在驱动着工程化和站在原来量子统计的架构设计、工程实现上前行（感谢@史绪良爱自由）。 1. 先说一下工程结构吧： 说数据处理的结构又必须啰唆说一下CAP理论（中文、英文） Consistency (所有的节点在同一时间看到的是一样的数据) Availability (无论成功还是失败要快速返回数据处理的业务处理结果) Partition tolerance (系统能够容忍任意的消息丢失) 这三个特性在分布式系统里面是不能兼得的。尽管在做量子数据系统工程化开发的时候，心中并没有这样的概念，但是理论真的很重要，越到后来越重要。
将数据存入数据库 从表面上看，关系数据库，例如PostgreSQL，拥有很多类似于电子表格的地方。但是，当你了解数据库的底层结构，你可以发现它复杂得多，主要因为它有能力通过复杂的方法将表格关联到一起。它可以比电子表格有效地存储更多复杂的数据，并且它有用很多其他功能方便选择存储的数据。例如，数据库可以管理多个用户同时使用。 让我们看看存放我们简单的但表格客户列表到数据库，看这么做有什么好处。在后面的章节，我们将扩展它并看PostgreSQL怎么帮助我们解决客户订单的问题。
周末花了一个下午看了一下《计算机体系结构量化方法》的附录B，是有关Cache原理的介绍。这本书写的还真是好啊，看似一块大砖头，本以为废话很多，其实多数描述很简练，微言大义。例如前些日子写了一个带宽和时延的关系，这本书一句话就写明白了：“时延决定数据第一个接收Bit的时间，带宽决定接收剩余数据的时间”，真实很牛X啊。画了一张小图总结Cache的基本结构。 CPU的处理器地址(我理解就是经过转换后的最终的硬件地址了)被划分为三个部分，Tag，Index，Offset。寻址的时候，首先用Index寻址Cache Set(这个是Cache相关性的产物)。Tag用作Key在Cache Line Set之中匹配Cache Line。Offset用于得到最终对象地址。其他很多概念和Cache Policy就是基于这个简单的数据结构图演化出来的。
