菜鸟提问需知

对新人来说，最好的学习方式是：去找个DM，让他手把手的教你。你会发现，这只不过是个游戏而已，并不难学.

新手需要的不是160RMB的“精装”PHB，而是一种态度——认真、热情、严谨、谦虚，呃，还有好奇心和想象力，在这个快餐文化的时代，并不是人人都具有这些东西。

不要到IRC的公共频道里去寻求帮助，那里都是BT和烂人，他们最喜欢KUSO那些大喊大叫的新人-____-b

————哥布林诗人给新手的忠告

以上文字采自最深的地下城，这是一个很上等的网站。在我做网游开发的时候，经常去看。我想以后我还会重新回到那里，毕竟我这种人对一个到处是坑的站点还是充满亲近感的。

上面那段话，给我深刻的印象，因为在国内的大多数IT社区，包括CSDN、Python中文，以及大大小小的QQ群，小论坛等等，无不充满了大喊大叫的新人。

很不幸，那里也游荡着各种不靠谱的BT和烂人……于是，我们每天都可以看到有无数的新人在抱怨对他们充满敌意的恶劣环境，这样的环境下，年轻人如何成材？中国如何有希望？等等等等……

然而，实际上，初学者们不正确的交流方式，大大影响了他们得到帮助的机会。总结起来，以下几种表现，几乎是一定会被BT的。

• 大喊大叫。特别是在QQ群里，使用过大的字体，过于鲜艳的颜色，都会严重影响阅读。本来QQ默认的窗体尺寸就小，你放一堆二号字上去，何况又是鲜红或嫩绿的二号字，让人怎么读？技术交流首先要保证消息的可读性，不要没事儿走视觉系。要知道每天坐办公室啃代码的老家伙们骨子里跟非主流艺术青年八九是不搭界的。黑色或靛蓝等传统的书写颜色可以让人舒服的阅读。
  
• 使用一个不好读的ID。这一点可能不太容易被人理解。然而如果你的ID别人都没办法念出来，大家就很难给你一个私密的回复。与其说是技术原因，更多的是心理因素。理由同上。不要指望每天坐办公室的老coder会跟你一样喜欢玩儿非主流视觉系。事实上靠谱的老程序员们往往跟这帮子家伙很不搭界。至少他们进入编码的心理状态时，是非常不喜欢看到一个花里胡哨的家伙跳出来在他面前画火星文。我从来没见过哪个靠谱的家伙顶着一个火星文ID在IM上写一堆鲜红嫩绿的二号字初号字。这些人最多也就是在QQ或MSN的签名上放几个表情而已。我曾遇到一个非常悲惨的实例。有个朋友多年来一直因为ID的问题在我们这个小圈子里被人BT，事实上他的名字一个火星文都没有，甚至也是一个合乎文法的名词词组。然而这个名字非常奇怪，念上几遍就会让人有想去抽他的冲动。于是大家不约而同的对他进行疯狂的BT。好在这位兄台有非常强健的神经，就像踩不死的小强一样生存了下来，并且在这种互相精神攻击的恶劣交流状态下学习到了很多东西。他的顽强还表现在工作的风格上。事实上这些年来他解决了很多很BT的技术问题，写出的代码搞定了很多我看来完全发疯的需求。就这一点，我是非常佩服他的学习精神、钻研精神以及娱乐大众的牺牲精神。为此我就不告诉你们他的ID叫“想你的我”，因为太难念，我们一致称他为水煮鱼。另外我要说的是，如果你没有水煮鱼那种被人切成一片片还要丢进锅里水煮再浇上辣椒也不怕的精神，还是起一个正常点的，好念的ID吧……事实上用自己真名的新人往往会得到比较亲切的帮助，不信你试试？
• 不要没事儿就在公共地盘报怨没有人帮助你。要知道在自由软件社区帮助你的人，九成九都是义务劳动，他们还要牺牲自己的工作和休息时间。没人欠你的。有个家伙因为五分钟没有人在QQ群里回答他的白痴问题，就开始大骂，于是他被我用各种方式羞辱了几个星期。没人会同情他。好吧，我不是一个心胸开阔的人。就是我这样一个小心眼又虚荣的家伙曾经在没有任何报酬的情况下翻烂了一本牛津高阶词典来翻译Python tutorial。这件事是我在失业的时候蜷缩在冬天冰冷的小屋里完成的，而且五年来我还把这件傻事重复做了四遍，正准备做第五遍。如果你能做到同样的程度，你也一样有资格去BT那些乱喊乱叫的家伙。如果你觉得应该支持比我更有RP的前辈，那可以无视我，请你去花钱买一本陈儒的Python源码剖析，或者去吹捧一下ZQ、Limodou、黄冬这些为大家做了很大贡献的人（不知道他们是谁？你真的是Python中文社区的成员吗？那你一定是新警察……）。
• 尽量少问软件破解的问题。我是说在自由软件社区。我不想争论道德高度的问题，这样的问题已经讨论过太多次了。我只想说，在自由软件社区找人要破解版或注册机，真的看起来很蠢。
• 语气请低调一些。趾高气扬的菜鸟只会被加倍的BT。这一点不需要多解释了，提醒一句：这个世界比你想像的NB的多。
• 遇到一个厚道的解答者，请珍惜，不要把他当作垃圾桶，什么白痴问题都丢过去问。学着自己解决问题永远是一种美德。如果你是一位青春美少女，对方是一个单身的宅男coder，另当别论，看在他厚道的为新人解答问题，任劳任怨的份上，嫁给他吧。
• 尽量帮助和你一样的菜鸟，不要BT他。这会使高阶的人力资源得到更有效的利用。就好像不要总是在游戏公会里请求顶级玩家帮你做新人任务一样，其实找个高你5级的帮手就很豪华了。同样你也应该多帮一帮比你更低级的玩家。
• 被BT时，请先检讨自己是否使用了挑衅技能。对于一个小圈子，往往BT新人会是老鸟们的重要福利之一。乱凑热闹或者灌水过多，都有可能招致灭顶之灾。在QQ群里发连锁消息尤其愚蠢。如果被BT，请先不要回击，通常来说，正是你这个新来的家伙破坏了生态平衡。如果觉得留下来学习更重要，就闭上嘴巴，多听少说。
  

关于《C&P》这本书

为什么要写这样一本书？

当然，我可以理直气壮的说，我想赚些稿费（笑）。不过，要想赚钱，写作实在不是一个直接有效的方法。对我来说，写一本关于Python的书，是长久以来的心愿。而当我深入到Python与C/C++的混合开发领域，惊觉这方面的书竟然一本也找不到。

在与bug奋斗的日子里，我在想，既然没有人做，那么我就写一本介绍C/C++与Python结合开发的书吧。

C是一门高效的编程语言，C++是一门强大的语言，相比它们的强大和高效，Python是一门简单易学，容易使用，资源丰富，结构完备，但相对比较低效的脚本语言，双方取长补短的话，可以达到理想的平衡。难得的是，Python与C语言有良好的接口。我们可以用C语言编写Python的扩展模块，在Python代码中像普通的Python字节码包一样加载和调用，以此实现Python程序的性能优化。另一方面，也可以在C代码中嵌入Python虚拟机， 将它做为一个运行时的C框架来使用。这种优秀的结合能力加上C++的代码抽象能力，将C/C++语言与Python的结合简化到了一个很容易接受的程度。这得益于boost和swig等优秀的工具库对Python的有力支持。而我在这本书中，也着重介绍通过工具库（主要是boost::python）来实现混合开发。这本书定位于如何在C/C++中混入Python技术，而不是Python虚拟机的运行原理，这方面据我所知，国内也有一位专家正在撰写相关的书籍，而且会在本书面世之前与大家见面。

为什么这本书拖延这么久？

说起这个话题，我很惭愧，自元旦以后，我到现在才有一些比较整块的时间继续写作。中间这三个月，主要是搬家占用了太多的时间。再加上我决定改用ubuntu linux做为写作平台，这也占用了一些时间。但是今后我将会保持一个稳定的写作速度。

为什么要用windows之外的平台？

其实，我的本职工作是一个VC程序员。本书中所使用的代码，基本上都可以通用于windows和linux平台。我使用ubuntu linux做为本书的环境，最重要的原因，是希望可以摆脱盗版软件的问题。这么多年来，因为各种原因，我不得不使用各种各样的盗版软件。无论有什么样的理由，现在是时候甩开它们了。Python本身是一个开源技术，我不希望在这本书中满是各类破解软件的截图和使用说明，这对于秉承OpenSource精神发明和推广Python、Boost等技术的大师们，是一种不敬。

另一方面，做为有10年VC使用经历的我，深刻感觉IDE是一把双刃剑。VC并非不好，对于软件开发工作，好的IDE绝对可以大大提高生产力，而VC也的确可以达到这个目标。但是对于学习者，知其然且知其所以然，方能游刃有余。这里我也不会刻意使用过于简陋的工具，更不会强制读者使用这样的东西。但是我希望能够通过使用手动或者不那么“自动化”的工具，可以帮助大家了解代码之下的来龙去脉。所以我使用了GNU体系的开发工具，并且使用Emacs之类的编辑器来编写代码。这样的工具也一样可以有助于我们编写代码，但是它们不会影响我们了解底层的编译和调试过程。

Ubuntu Linux 6.10内置的Python是2.4，这给我带来了一些麻烦，但是我还是决定使用Python2.5做为主要的Python版本。很简单的原因——成书也需要时间，等到这本书面世，恐怕Python2.5已经成为主流的Python版本，到那个时间，再介绍Python2.4的内容，恐怕读者会有过时之感。

实际上，这可以说是一个假像，Python2.4到2.5的改进主要在在语言和VM效率方面，而Python API几乎没有什么变化，何况我们使用封装工具库来工作，这就将版本差异给混合开发带来的差异降到了可以忽略不计的程度，使用Python2.4甚至2.3的读者，都可以从这本书中找到对您有价值的内容。

技术的使用和选择，基于什么样的标准？

当然，每个操作系统都会有些自己的特产。不过，我们的讨论重点是与Python有关的混合开发技术，而不是操作系统的优劣，所以我尽可能使用跨平台的框架和技术。比如，在windows上，gcc/g++的表现并不见得就好过vc，但是前者有mingw和cygwin，vc却没有*nix实现。这方面，显然g++胜出。GUI框架的选择也是如此，选择wxWidgets，并非因为它的功能优于GTK或QT，甚至是WTL等，只是因为它是最容易使用，兼容性最好的GUI框架，在c++和Python上都有不错的表现。

编译工具方面，我本来准备使用make，但是在比较之后，我决定使用scons，这是一个使用Python脚本的编译工具。著名的3D软件Blender，就使用scons编译。相比make，对于Python使用者更容易上手。相信在国内，没有学习过make的C++程序员不在少数：），如果在同一个起步点上，Python语言更有学习趣味。而有makefile脚本经验的程序员，学习scons也不会是一件有任何难度的事。

我在本书中使用Emacs为主要的编码工具，这是因为近一段时间来，我业余时间使用最多的就是Emacs，它可以保证我用一套工具完成包括C++、Python以及其它多种编程语言的使用。但是，这不等于读者也一定要使用Emacs，我们介绍的是如何实现软件，不是如何使用编码的环境。您可以使用VI，也可以使用VC或Eclipse来编写同样的代码。这可以说是无IDE编码的一个优点。