序：去年为了总结本身所学习/接触过的技术，也顺便为初学者少走弯路指明一些方向，惋惜后来诸事缠身未能继续，十分遗憾，现放到本身的BLOG上来鼓励本身将此继续下去。
"Win32编程”
很不幸，我从开始学习编程到理解这个名词中间隔了很长的时间（上个世纪的学习环境可见一斑）。很长时间里我都不明白32是指什么，我用过Dos,Win31,win95,win97...但好像没用过名为Win32的操做系统啊？好久之后我才知道，32在这里并非指操做系统的版本号,而是指32位。微软操做系统在win31及其之前都是DOS系统，windows只是在dos下运行的一个大程序而已。在其后win95则稍有改变，windows除了DOS核心之外也真正成为了操做系统的一部分，提供着各种操做系统提供的服务。应该说，在win95以后的windows(新近的64位win系统之前)均可以称之为win32系统平台(95/98其实是16与32位混合)。因此在这样的平台上，直接或间接使用系统提供的API编程，就称之为Win32编程。对Visual Studio而言，Win32编程通常指SDK、MFC、ATL这几类开发方法,其中ATL在国内应用不是很普遍，通常应用于以COM组件为架构的中大型软件产品。
"SDK" ：Software Development Kit,常译为软件开发（工具）包
在Win32编程领域通常指与MFC这类框架编程相区别的，直接调用Windows提供的API的开发方式，与字面原意有一些区别。另一个常常见到的说法就是某软件（硬件）带有本身的一套SDK，这里其实通常是指一套API库函数或者类库，供上一层的开发者调用。又譬如常说的DX的SDK，实际上是微软开发的一套COM组件，供上层开发者使用。总之，供程序员使用的比较完备的代码库，就能够称之为SDK；
“MFC”: Microsoft Fundation classes 微软基础类库
你们都知道，使用SDK编程方式每每有不少每次都重复的固定不变的一些代码，为了提升编程的效率，减小上千个API带给开发人员巨大的精神压力，微软开发出了这么一个类库，注意，这个类库与操做系统自己无任何关系，它只是对API进行了一个面向对象的封装，固然，还给出了一系列编程的框架。使用SDK的方法，使用Visual Studio，经过调用Windows API，MFC你也能够作得出来。MFC把一些固定不变的代码已经写好了，只在编译时候链上，因此咱们的代码里看不到WinMain(),而事实上整个程序的运行，和SDK的方式无任何区别，初学者请记住这一点。另，补充一点我的感想，MFC的初衷，带给开发人员更多的便利，我以为并不太成功。学习MFC所费的力气和最终的所得，并不太成正比。
"API"：Application Programming Interface，应用程序接口
这个词的出现频率很高，从某种意义上来讲，也能够看做是SDK的一个子集。这也是作给程序员的程序，不过通常指用导出函数的方式提供服务的函数库，不包括类库和组件。
“GDI”：Graphic Device Interface，图形设备接口
这个是Win32程序下最经常使用的显示方式，与DirectX、OpenGL处于同一级。在DOS要显示一些东东可不是容易的事，最简单的是调用一些C的图形库函数来实现显示，不过通常也就是些画线，填色，输出几个文字，效果很弱（因此DOS程序界面通常都不怎么样，且实现起来不是通常的复杂），要复杂一点的动画/图片显示什么的，常常要用到的就是硬件中断，调用一些显卡自身的子程序(固化在显卡内的）来作。由于每个显卡都不一样，因此DOS的游戏兼容经常因为显卡的差别而很糟糕。到Windows下你们就幸福多了，Windows将硬件这一层屏蔽起来，用一个表格（Device Context）来表明一个显示，咱们要作的就是在这个表格上填好相关参数，而后画上咱们想画的东东，而后操做系统会依照这个表格（DC），把相应的显示内容（通常是一块
显示内存）传送到指定显卡的指定的显存，再由显卡传给显示屏。咱们再也不须要与不一样的显卡打交通，这是一个十分伟大的胜利！GDI中最经常使用的是双缓存技术，就是说你能够在内存中建立（也就是复制）一个DC，只不过在这个DC中显示的再也不被传送到显示器上。有什么用呢？由于它的各参数是与当前屏幕DC一致的（COPY嘛 ，固然是这个结果），因此它的显示内容能够完整无失真地传送到屏幕DC上。咱们一般在内存DC上画图，譬如画一圆，再画一条直线，画完后一次性地传送到屏幕DC上，这样对用户来讲屏幕只刷新了一次，能够解决你画一点内容屏幕即刷新一次致使的闪烁问题。固然，双缓冲甚至多缓冲还有不少别的用处，那就要靠本身揣摩了。
"DirectX"
一般简称为DX（读音：低叉）这是个很吸引人眼球的名词，读起来就很上口：）。Windows为咱们做了许多屏蔽底层硬件的工做，其中DX是最知名的技术之一。操做系统要与各种硬件打交道，特别是多媒体相关的，譬如显卡、声卡、手柄输入、多媒体流的网络传输等等，这些事情若是都本身来弄的话，那就太要命了（这些通常都涉及系统底层，本身也很难作出来）。而DX则正是这么一套操做系统提供的隔离多媒体硬件与程序员的间质，DX自身通常并不实现处理的能力，它是一个标准，要求硬件来知足，比如DX提供一个函数名，硬件来实现函数内容同样。经过它咱们能够很是简单而快速地调用硬件提供的各种服务。它主要包括DirectDraw(经过直接访问显示硬件来提供快速的图象处理能力),DirectSound(提供了软硬件的低延迟声音混频和回放，以及直接访问音频设备的能力),DirectPlay (它明确的提供了通用环境链接能力来简化你应用程序之间的通信服务),Direct3D(DirectDraw的3D版），DirectInput（简化你的应用程序访问鼠标、键盘和操纵杆设备的能力），DX5.0以后又增长了一些(如DirectShow)，再也不详述。DX一个重要的特色就是你能够经过它直接访问硬件而无需知道硬件的具体细节。譬如DirectDraw,就可以越过内存而直接访问显存，这样的速度将比GDI快不少，不在一个数量级上。补充一点：DX是以组件的方式提供的，而不是一般的导出API的形式。DX SDK的最新版本是9.0
"COM”：component object model，组件对象模型，通常简称组件。
这是微软为了解决代码重用的一个重要机制。重用代码的最简单办法是源代码重用，把写好的函数和类加到本身当前的代码中,编译便可。简单是简单，敝病却显然的多。另外一个经常使用的方法是单独作成模块，以DLL的形式分发，DLL导出函数或者类，客户程序用动态/静态连接的方法将其加载，这显然比前一种源代码的方法好一些，难度也不大，最为经常使用。但DLL也有一些不足，最根本的，它不是二进制兼容，DLL版本升级一次就须要与客户程序代码重连接一次，有些时候这几乎是不可能的任务。为了更好地让编程像“搭积木”同样简单，让模块能够完美地配合，完美地替换，COM产生了。COM不是类库，不是代码，不是操做系统的服务，而是一套编程模型，理论上来讲，它与语言无关，与操做系统无关，unix下一样能够作COM。COM是一种程序结构模型标准，你作的DLL或EXE在结构上知足这么一个标准，那这个DLL或EXE就是一个组件，它将在该平台上成为二进制兼容。COM主要利用了注册表来登记本模块的信息。客户程序调用时首先查注册表，找到所需组件的位置（这实现了位置透明），而后就用Loadlibrary把它加载进来，这和普通调用没有本质区别，区别在于因为组件特殊的实现方法使得整个过程当中用户程序都不知道组件的位置，组件的类的实例化过程，如何销毁，不能直接访问组件的任何实现细节，用户只与组件的几个public接口打交道。这将实现真正的模块之间的独立。对用户程序而言，对于目标组件的认识，除了接口，一无所知。在接口不变的状况下，组件可任 意替换而客户程序不做任何改动，无需编译，仅这一点，在中大型程序的模块集成的过程当中就将节约至关多的时间。 "STL"：Standard Template Library,标准模板库
这是最先由Alexander Stepanov和Meng Lee（蛮像中国人的名字）完成，于1994年提交给ANSI/ISO 标准C++委员会并经过而成为标准C++的一部分。望文生义便可知这是一个代码库标准，不是语法标准。简单地说，STL是以C++中的模板语法为基础创建起来的一套包含基础数据结构和算法的代码库。STL的特色是实现了“类型参数化”，即STL的代码中可处理任意自定义类型的对象，若是不使用模板技术的话，这是一件至关困难的事。也由于这个缘由，在最新的java及C#语法中均加入了对模板语法的支持，可见其重要性。另一个有关STL重要的话题是GP（Generic Programming),泛型。这是与面向对象相并列的另外的一个编程模型，它以模板为基础，弱化了实体类型的差别，简化了编程时问题抽象的模型，提供了更好的封装性和弹性，对于繁杂的面向对象编程毫无疑问是一种解脱，至少是精神上的。GP并非用来取代面向对象的，而是做为一个有益的补充体，是面向对象很好的合做伙伴。ＧＰ是最近几年软件架构的一个研究热点，但国内真正的应用彷佛并很少见，这项技术自己还基本处于研究前沿。<<Modern C++ Design>>一书对C++中的GP应用有很好的诠释，而这本书对脑细胞的杀伤力之大，也是其它C++书藉可望不可即的。想知道C++的代码技巧能够作到怎样的出神入化吗？不妨看看这本书。
"ATL"：Active Template Library，活动模板库
这在
VC编程下应该算是比较高级的话题了，它集COM和模板技术于一身，带来了极方便的组件编写方法和极高的学习门槛。能够说，进入ATL领域就算是进入了中级以上的编程领域。ATL是为组件而生，它的目的是为了让程序员更方便地编写组件（纯用C++写一个最简单的组件实现一个“Hello World”对初学者来讲都是要命的），同时它使用模板技术来相似于MFC同样创建了一个开发COM的框架代码库(模板库），使用该框架及模板库能够相对方便地进行组件开发。ATL中的一个特色就是你本身的类将成为ＡＴＬ代码库中某些类的父类，这是一件颇有趣的事（这也是模板技术的一个特色）。
"HANDLE": 句柄
这是一个中文翻译很古怪的字，对初学者来讲是百思不得其解的东东。这其实等价于void*（顺便提一下，初学者每每对VC代码中各类古怪的符号、类型标记/宏等百思不得其解，其实它们大多来自基本类型的#define或者typedef,请将光标移到这些符号上（譬如HANDLE），而后按下F12，编译器自会把你带到它的声明处，反复使用几回，你终会见到它的原貌，而后长吁一口气：原来不过如此而已。没用过的初学者请牢记：F12）。不少初学者总想知道一个HANDLE表明一个什么对象，个人建议是不要去理解为某对象，而就是理解为访问某一个对象的入口，事实上HANDLE大多数时候是一个整数索引（标志该对象在操做系统的某表中的位置,就好像一个数组的下标同样），Windows系统核心中主要是几张大表，这样一个整数索引就是标记目标在这个表中的位置，供操做系统访问时查询用。偶而它的确是指向某对象的指针，有时它还携带一些额外辅助信息。总之，咱们不要去直接访问它，把访问HANDLE的任务交给操做系统好了，除非你还嫌写程序不累：）。
"DLL": Dynamic Link Library 动态连接库
DLL的一个特色就是能够动态加载（顾名思义），即在主程序（我更喜欢称为客户程序）须要该模块时才由操做系统加载到内存。毕竟一个大型应用程序咱们常用到的功能并很少，这样一些不经常使用的功能模块（DLL）在程序运行时通常将不被载入，可极大节省内存开销。DLL同时也是目前最经常使用的分发模块的方法，便于彼此协做。程序中对DLL的调用主要有两种方法：1 针对使用DEF文件导出函数的DLL，使用API函数LoadLibrary（“DLLModuleName" ）加载，而后使用GetProcAddress（）获得函数指针，进而调用 2 直接将类、函数等导出，客户程序使用同一份头文件声明，加入对应的lib连接库，便可在客户程序中直接使用DLL中的类或函数，无需LoadLibrary。
"Process": 进程
进程是一个动态的概念,包括从进程的建立申请,PCB(Process Control Block进程控制块,通常操做系统实现为一个表格(struct))的建立,地址空间的内存分配,模块代码载入并执行,执行完之后进行撤销,整个过程被称为"进程"。在Win32下，一个进程有4G的逻辑空间。但咱们也常把它做为静态概念来使用，在Win32下，一个EXE的执行就是一个进程(若是它内部又开了新进程，另当别论）。
"Thread": 线程
为了更有效的提升CPU的利用率，更好地实现多任务并发，微软将进程进行进一步分割，实现了CPU任务调度的新对像：线程。一个进程拥有至少一个线程。咱们在实现多任务并发的时候一般是创建一个新线程（创建线程的系统开销要小于进程），线程以咱们本身的一个函数做为入口,函数执行完毕自动撤销（固然你也能够在执行过程当中强制结束该线程）。顺便提一下，在UNIX下并无线程这个概念，想来是由于UNIX主要是以多进程的并发服务为主（因此它更适合于作服务器），系统运行时一般已经有了太多的进程，因此没有必要再对进程进行细化，由于这样作甚至会下降系统效率（CPU调度不过来）,固然，这是我我的的猜测：）
"C语言"
到目前为止，C语言应该是传播最为普遍的语言，特别在UNIX的世界里依然扮演着主角的位置，在其他如硬件开发，嵌入式系统（如手机）皆有十分突出的表现，即使在win32平台下SDK的开发中也有一席之地。更主要的是它是大多数国内（国外我不敢说）程序员的启蒙语言，经过它许多人才领会了程序的思惟。C最大的特色就是快，除了汇编之外效率能够达到最高，而它的灵活性，对硬件的直访性也彻底符合程序员自由的天性。若是说学习别的技术尚有犹豫和徘徊，那么学C只有一句话：相信我，没错的！也有许多人主张能够直接学习面向对象语言，我不太赞成。面向对象语言对机器模型的抽象十分容易让程序员迷糊，心中难以创建准确的程序运行时的模型。毕竟咱们是程序员，不是用户，咱们不能把全部的问题都想固然地交给编译器和操做系统去解决，它们也解决不了。至少学习一门面向过程的语言，才能知其因此然。
C++
这是贝尔实验室的又一杰做，同时，也伤透了全球太多程序员的心,脑细胞杀伤力十分之大。C++比大多数初学者想像的都要复杂得多，它基本包括：一个类化了的C语言，模板，标准模板库.不少初学者掌握的C++仅仅只是一个类化了的C语言的一个子集（不相信的话，你不妨看一看<<Modern C++ Design>>中的C++代码，看看能理解多少）。更麻烦的是使用C++不得不谈到面向对象的编程风格，这一样比初学者想像的难不少，要有打持久战的准备。而最让我这类C++爱好者忧心的仍是它目前在Win平台中的前景,在.net平台上很难找出不用C#而使用C++写新代码的理由：（ 。而它的复杂性和目前许多诸如java/C#及一些动态语言(python/ruby)比起来，开发效率显然的低，大有退出上层应用程序开发的趋势。这么一个包含了最多范式的近乎完美的语言，我实在不想放弃。我惟有祈祷在将来C++的路能够走得更远更好一些。
源代码版本控制
这是软件开发中一个十分重要的工程手段，几乎是必须的一个Process(过程)。不少做坊式的开发团队在采用软件工程的一些方法的时候，第一个要进行改进或增长的，每每就是这个过程。对初学者学习而言，建议在开始进行实践小项目的阶段即进行源代码版本控制，由于这在之后的工做中，是必定会用到的。
源代码版本控制的基本原理以下：
在服务器端创建该项目的数据库，并保存你选定的项目源文件的第一个版本。客户端任一用户要得到某源文件的修改权利，需进行check out操做。以后客户端通常每完成一个无编译错误的版本想保存的时候，进行check in操做，将当前版本保存在服务器端上并成为最新版本（注意，不是覆盖之前的哟）。任一客户端能够方便地获得服务器上的文件的任意版本（若是有权限的话）。通常还实现了一个重要的功能是版本比较，任一客户端能够利用版本控制工具对某文件的不一样版本进行版本比较，它会标记出不一样版本的同名文件的不一样点，能够轻易地看出版本内容的演化，这一招很经常使用。 下面介绍一下我接触过的三种版本控制工具（也是国内用得比较多的）：
VSS: Visual Sourcesafe
这是微软Visual Studio自带的源代码版本控制工具，它最大的特色就是易安装（与Visual Studio集成在一块儿，装VC/VB的时候就顺便搞定，不用别外费工夫），使用简单（服务器端设置相对容易，通常我的稍加摸索就能够轻松搞定，客户端更是只管check in/out），基本功能完善，版本比较很直观（我喜欢）。它的特色是某人check out了某版本之后，别人将没法对此版本check out,也就是说同一时间只有一个能够修改某一个文件，这样就避免了不一样的人对同一文件的修改形成彼此冲突（注：可经过设置服务器端实现多人check out,但几乎不会这样作，由于那样就失去了VSS的一个最重要的功能）。另，VSS可集成于VS环境，但根据个人经验，直接在VC里对版本的check操做，经常不生效，因此最好仍是到VSS程序里去进行check操做。补充：单机上也能够使用VSS，这样的好处是在对当前某些文件进行了误操做或大规模地误修改以后，能够恢复到最近的无错误的版本，最大程度地挽回损失。VSS实际应用较广泛，若是你是走Visual Studio路线的话，必定要用一下。
CVS: Concurrent Versions System
这个也是一个大名鼎鼎的开源的版本控制工具，主要活跃在UNIX世界。CVS我使用很少，通常而言好像功能比较偏向于命令行方式（UNIX下开发不少人也都使用着命令行方式）。固然，Windows下面也实现了几个版本的CVS，也能够集成于VS，好像还有一个能够挂接在IE上的，我没试过。著名的开源项目管理网站sf.net也是用的CVS，若是你要和全世界的程序员一块儿协做开发，CVS是必需要安装的。在JAVA的世界里，也是以CVS为主。
Rational Clearcase
这个工具就比较上档次了，Rational公司(如今是IBM）的出品，价格昂贵。我最初参加工做的时候用过一小段时间，简单谈一下。这个工具的特色是复杂，安装及设置就十分复杂，个人印像中客户端甚至不得不加入到NT域里面去，致使我在本机的权限都不够，安装新程序都很麻烦，很郁闷（不知道是否是咱们公司的相关人员安装设置错了，想来应该是这样，但其复杂性可见一斑）。对使用而言，它有一个功能挺有用的，就是它可以根据你每次check的版本号，自动生成版本树（一个树状图表），你能够清晰地看到版本的演化过程。因此严格地说，像CVS/Clearcase这样的才真正称得上“版本”控制，VSS还太勉强。Clearcase的功能十分强大，我不详述了（我还不想出书），较适于大型软件公司实施软件配置管理时采用。虽然它的名气十分之响亮，但我不知道国内有多少公司在真正使用正版的Clearcase这样的工具，想来应该是十分之少。
OpenGL
OpenGL至今很有一点英雄落寞的味道，这一套标准是实现得如此之好，以致于曾经一度成为游戏界面华丽的标准。它的低落也是一个必然，毕竟在微软的强力打压下鲜有不挫败的。但它曾经可以给微软带来如此的压力，至今也依然在工业界被普遍使用，大多数游戏/显卡依然保留着对它的支持（CS里我喜欢的仍是OpenGL)。而它的性能在某些方面与D3D比较，依然占着上风。不幸的是DirectX在不停地向前发展，而它，几乎止步不前了，前景并不光明。OpenGL目前在工业领域应用较为普遍，它的优秀的矢量图的操做性能，华丽的色彩，在专业的图形图像处理领域表现突出。游戏中使用相对之前而言则是愈来愈少。新近据说微软的最新操做系统Vista对OpenGL进行了极大的打压，不但性能上折扣，支持的版本也只到1.4(最新版本好像是2.0)，不知道最后如何收场，拭目以待。
DirectDraw & D3D
大凡像样的2维Windows游戏，几乎都是采用此技术来实现显示的。DirectDraw有两种模式：全屏和窗口。其中全屏应用更多一些。在全屏下，DirectDraw有一个十分著名的“换页”技术，即在两个显示页面之间用“交换”来实现显示刷新，这个速度十分地快，只是一个显存内一个指针的交换，比你用BitBlt复制一屏的像素快太多太多，游戏的高效的动画效果大多源于此技术。DirectDraw主要用于娱乐领域和一些实时显示要求较高的场合，如医疗图像。D3D是目前大多三维游戏的标准采用，我没钻研过，不敢多言。它的效果嘛，玩玩游戏就知道了：）
UML:Unified Modeling Language，多译为统一建模语言
这个语言是一种图形语言，主要是做为设计时建模的一种标准的图形模型，便于程序员与程序员、程序员与客户、设计员与代码员之间的沟通，同时它也帮助设计人员将头脑中的基于程序代码的对程序功能的理解造成文档，便于理清头绪，进行下一步编码的工做。换言之，设计过程的产品，能够表现为一些文本文档，或者一些框架代码，或者一些伪代码，但比较标准通用的，是表现为一堆UML图。UML包括动态图和静态图两大类，其中静态图中的类图最为经常使用。不少人初学时不知道该怎么作设计，写小软件时经常没有设计过程，其实很简单，把软件的类图画出来就行了。学作设计时未必要找一个像Together或者Rational Rose同样的巨无霸。用一些简单的能够作UML图的工具就好，专门用来画UML图的小工具不少,网上容易找。补充一点：画UML图不要面面俱到，不要什么都画，突出重点方便理解就好，甚至使用不规范的记号也没关系（当UML的功能是草稿的时候）。
RTTI: Runtime Type Information 运行时类型信息
在程序中，当咱们获得某一个对象的实例或者指针时，大多数时候并不能直接确定它的类型（都是继承以及类型转换惹的祸），这个时候，依靠VC4.0或更高版本的编译器提供的RTTI支持，调用库函数typeid()便可在运行时获取这个对象的“类型信息”，在一些动态处理中“类型信息”很重要,获取了类型信息之后，你就能够有十分把握地调用该类型的相关操做，或者类型转换，或动态生成。因其重要性，在JAVA和.net库中借助单根继承和“虚拟机”对此有了更优雅的作法，每个自object继承的类自然就有了表述本身类型信息的能力（继承的好处），而且容易扩展，如今你须要类型信息的时候，大可直接ask那个对象：tell me, what type are you?它就会告诉你答案。
debug & release 调试 & 发行
你们都知道，debug是调试版，release是发行版，区别在于debug版生成的程序中包含大量供调试用的场景代码（不是真正运行须要的），而release通常去掉了这些信息，并进行了某些代码优化，因此release版的程序会比debug版的程序小不少，运行速度也快一些。同时，debug版为了便于调试，每每会对调试使用的诊断代码加上DEBUG一类的宏，使得在release下不对这些代码进行编译。正因为两种版本编译使用的源代码的差别（以及release糟糕的优化），经常使得两种版本运行时产生大相径庭的效果，一个正常一个崩溃是大多数人都遇到过的。致使问题的可能性不少，注意事项详见各论坛的诸多精华贴。另，同一个程序若是DLL之间的连接使用了不一样版本（譬如EXE是release版，dll是debug版），有时会没法正常运行，因此我通常的作法是每个DLL针对不一样版本使用两个DEF文件，编译生成不一样名的两个文件（debug版文件名后加d)，调用时各个版本针对本身的版本调用，这在必定程度上可避免混乱。另，release也是可调试的，在工程设置里把调试信息打开便可。
XP:eXtreme Programming 极限编程
这是近几年才时兴起来的开发模型,国内大体是01/02年开始有所宣传。
它主要是针对中小型开发团队在开发时间要求紧、需求不稳定的中小项目（大多数软件项目都是这个状况）时使用。它打破了传统软件工程的框架，很是新巧。譬如整个开发过程当中文档不多，大量使用“卡片 （如CRC卡片）”来描述开发计划和内容；没有真正意义上的软件功能规格说明书，取而代之的是一系列可测试的用例；没有独立的设计和测试阶段，它们老是在迭代中增量反复进行；设计：尽量小和简单；通常没有代码复审（code review),你们共同拥有代码。而它的最显著的一个外在特征是它常使用“成对开发”，即一台机器前坐两个开发人员，共同开发（一个看，一个写），这乍听起来真是蛮有趣的：）,它的基本出发点是认为成对开发的效率在必定条件下要高于两我的独立开发的和。不要以为
天方夜谭，在不少项目中，这种作法的有效性已经被证明。
XP的特色能够用“快、小、灵”来归纳，它和传统瀑布模型（自顶向下）的区别在于它使用迭代增量（设计->代码->测试->设计->代码...)的方式。想法很简单：没有什么目标是能够一开始就容易肯定的。用登山来作一下比喻的话，传统的是在山下研究地图，选好一条路线，而后沿着此路前进，XP则是走一走，停一停，看一看，对下一步的方向做出新的选择，在不少时候，这样作会让你选择到更好的捷径。
ICONIX:
这个字相信不少人都没见过，我也不知道是什么字拼起来的，做为开拓眼界，我仍是提一下吧。这是一种界于XP和RUP（Rational Unified Process)之间的开发模型，换言之，它比XP“大”，比“RUP”要小。它采用了UML的一个子集，特色是用例驱动，保持良好的进度跟踪能力。它的目标是用最短的时间来把用例变成代码。具体来讲，这种开发模型相对精简的XP而言，更增强调用例的创建、分析和代码化，用例是其中心地位。
RUP：Rational Unified Process
前面已经提到了，相信你已经感受出它是一个丰富的软件开发模型。这是由IBM提出来的软件工程模型，它使用完整的UML图，对开发的各阶段（需求、设计、代码、测试、维护）均有十分完善而复杂的标准，就不详述了。RUP本质上是迭代式开发，在每一次迭代中均完成如下四个阶段：初始阶段（inception)、详述阶段（elaboration）、构建阶段（construction）、转换阶段（transition）。
CMM:Capability Maturity Model 软件成熟度模型
这是卡内基*梅隆大学软件工程研究所（个人专业正是软件工程，因此这也成为我心目中的圣地）的一大力做，一度曾造成了席卷全球软件开发的CMM浪潮。CMM分为五级，大多数软件企业都处于第一级，而获得第五级认证的全球也没有多少，国内去除掉挂羊头卖狗肉的，也是寥若星辰（嗯，比星辰是寥多了）。因此CMM实施通常是从第二级开始，能作到第三级的都是很有实力的软件公司了。CMM是以Process（过程）为中心的模型，从二级始每一级都有几个Key Process(关键过程），每个KP又分为若干Key Active(关键活动）。CMM的实施通常不能越级实施，而且每一级的实施一般都要一年以上，因此要达到较高等级是一级很困难的事。另，CMM不只可用于较大规模公司，一样也可实施于小公司，小项目组（这是不少人所不知道的）。实施视具体状况等级之间可交叉，譬如实施时采用二级的某些KP再加上三级甚至四级的KP，但你只有实施了全部二级的KP，你才能也只能经过二级认证，即使你采用了某些四级的KP。CMM最新发展成果是CMMI（Integration),这主要是新考虑了软件与非纯软件因素的关系（譬如系统），以及团队之间的协做问题。CMM在国内的发展彷佛有点走向ISO一样的道路，这实在不是一个好消息。
Callback Function: 回调函数
在侯sir的<<深刻浅出>>中一开始就提出了这个概念,大概的提法是说回调函数是操做系统调用而你永远不要去调用的函数。这个提法让初学者有点望而生畏，觉得是一种多么高深而难以领会的系统底层的核心技术。其实否则，这个技术本质很简单，并且很经常使用。它实质就是函数指针的基本运用（若是不知道什么是函数指针的话，翻翻书）。在一个模块中，有时想让一部分功能由其它模块实现，譬如说一个作显示的模块，它只想实现显示的资源配备，画面的刷新，缩放等控制功能，而把画具体实体（譬如圆、多边形，均可以有不少种不一样效率的实现方法）的代码由别的模块来实现，怎么办呢？用函数指针。在本身的类中放一个画圆的函数指针，使用时由外部为这个函数指针赋值（其实就是指向了一个外部的函数），在本身的代码中直接调用这个函数指针来画就能够了（本模块彻底不知道外部模块是怎么画圆的）。那个外部的函数在这里就是回调函数！
在不少系统API中就使用了这种函数回调的方法，让咱们开发的代码实现能够嵌入到API的代码实现当中，其实咱们就是传了一个函数地址给它而已。换句话说，这些API搭好了某些运行的代码框架，咱们来为它具体实现。
XML: Extensible Markup Language 可扩充标记语言
也许你还在为选择.net和j2ee而徘徊不前，若是是这样的话，不妨先着手学一下它们所共通的一个基础：XML。有了HTML为何咱们还要XML？很简单，HTML重在表现文本/图片以及一些多媒体内容，它很难表达数据，由于它的标记是固定的，而数据类型千千万，根本没法描述。.net和j2ee都要解决一个信息传输格式标准化的难题，这个格式要能承载文本/数据，最好还能描述程序接口，同时又应该像HTML同样简单，具备通用性，可以在HTTP下很好的运做。在这种要求下，XML产生了。它的特色正如其名，和HTTP同样，它也是一种标记语言，可是它的标记不是固定的，是可自定义（也就可无限扩展）的，这些自定义标记可以很好的描述数据类型以及对应的数据内容（乍看起来很像数据库表的定义）。除此之外，XML还能够描述程序接口，因此XML能够方便地与网络程序构件（COM、EJB等）直接交互。因为它也是一种ASCII文本流，因此与当前的HTTP兼容，在当前的internet上畅通无阻（这很重要）。有了以上功能，XML就名副其实地成为了新一代互联网技术的标准信息载体，在.net和j2ee的网络架构中，各类“构件”的信息交互都交给了XML，可谓任重而道远。
XML我本身没怎么写过，单就学习上的经验而言，感受语法上比HTML更琐碎一些，小细节更多，没那么容易速成：） 好在根本同源，有HTML基础甚至WEB开发基础的，学起来也很轻松。
Java2:
这是近几年最吸引大众焦点的语言,在Web开发,网络平台,
移动开发的世界里发光发热。你能够不用java,但你不能够不了解java，毕竟这是一个极大且丰富的软件开发领域。有些没使用过java的VS阵营里的人可能还不明白java2里的那个2是什么意思，容我先解释一下。Java最初正式推出1.0时，并无受到如此多的好评，受到颇多责难，因而它不断地推出新版原本完善本身，其中变化显著的一个版本是1.2(我没记错吧），Java的每个新版本除了语法上的更新，还有一明显的标志，那就是JDK（Java Development Kit,就是Java自带的一套SDK）的更新，版本1.2之后的java为了在宣传上与之前的java相区别，便被称为java2。目前用得比较多的jdk是1.3/1.4 ,最新的JDK是1.5(代号tiger)。java开发的IDE国内主要以JBuilder为主，另外就是在开源领域如雷贯耳的Eclipse,而sun也力推本身的开源java IDE：Netbeans（从sun的网站上可下载，免费）。Java运行是虚拟机机制，至关于在操做系统上增长了一个软操做系统，源码被编译成一种字节中间码，由虚拟机解释执行，只要有对应的虚拟机，java程序就能够在该操做系统上运行，这就是java号称的一次编译，处处运行的由来。而附带而来的不可避免的性能问题也让Java难以成为桌面程序开发的主流。补充一下：对初学者学习而言最好的Java IDE我推荐使用JCreator,这是一个C++写成的IDE，几MB的大小，比Eclipse快十倍以上的启动速度，对初学者带来极大的便利。
J2EE:
Java实际上又被分为3类：J2EE/J2SE/J2ME,不一样类分别对应不一样的JDK，J2EE针对企业平台开发，J2SE是标准版，J2ME针对移动平台开发。J2EE如今实在是热得烫手，我前不久翻了一下程序员早期的杂志，发如今第一期创刊号里（2001.1)已经有了j2EE方面的讨论，如今已是2004.6了，你对它的认知又多了多少？J2EE不是一种单纯的技术，而是一种体系架构以及组成该架构的诸多标准。企业平台开发和桌面/简单Web数据库开发有很大的不一样，它的程序规模每每很大（不是一个或者几个EXE能够搞定的），用到的每每是海量的数据库和海量的通讯，而且经常是不可中断的，这些特殊性都使得企业平台开发更多地去关注架构的问题。而咱们写一个熟悉的java客户端程序，或者消息处理中间件，又或者数据库处理程序，都只是这样一个架构里的一小部分。J2EE是很宠大的，因此请不要写了几个EJB(这是java世界里的构件，概念上大概是相似于COM）的例子程序就感受本身精通j2EE。
J2EE中传递消息时每每引入了一个被称做消息管理器的中间件，在服务器端使用EJB的容器来管理和调用EJB。在J2EE中一个重要的概念是Transaction(事务）处理，事务的概念最先普遍应用于数据库技术。这其实是一个封装了不少操做的单元，它的做用是中间任何一个操做失败，能够自动依次总体撤销，因此一个transaction就是操做成功/失败的最小单元，不存在一个transaction只成功了部分操做的状况。
在企业服务平台开发中比较知名的有一个叫BEA公司（这是一家不错的公司，应该知道它的名字），它的产品是Weblogic。
.net
.net是微软为下一个十年准备的技术，你呢？.net也是一种平台技术，而不是单一技术。它主要分为.net运行时平台（对应java的虚拟机）和.net类库（对应java的jdk)。目前只有Windows2003是自然集成了.net运行时平台的操做系统，因此如是你写的.net程序想要在别的操做系统上运行，该操做系统必须先安装.net平台，这是一件蛮烦人的事，也是为何到目前为止，尚未太多的人改用.net来写程序（尽管可极大提升开发效率）。但愿Longhorn的出现能够扭转这一现状。那咱们就终于能够和MFC这样过期的框架类库说再见了，一大快事。
.net采用了不少最新的技术和思想，对走VS路线的人来讲（特别是有COM概念的），学起来相对轻松且很过瘾，前人推荐的“.net框架程序设计“和”.net本质论“都是很好的书。固然，看它们以前你最好基本掌握一门.net语言，譬如C#，掌握语言对咱们来讲是最easy的。
聊了这么多技术,下面让咱们来放松一下:)
公共密钥: （也常被译为公开密钥）
"密码"已是一个老小皆知的词,想从银行里把钱取出来吗?没密码可万万不行。不知从何时开始，这么一个军事级的词汇已经走进了千家万户,妇孺皆知。不过知道“密钥”这个词的人就少多了，知道“公共密钥”的人就更少了，不但知道并且了解其原理的人则少之又少，固然，若是你之前不清楚的话，那么你即将加入这少之又少的行列：）
long long ago,随着军事的日益发展，情报的重要性日益提升,如何得到准确的情报成为军事上的一大重点，伴随而来的另外一个问题则是如何尽可能保证本身的情报在被敌人截获后（这老是无可避免的）敌人依然没法得到该情报的信息，防止情报外泄。不妨让咱们以今人的智慧来设身处地的想想，有什么好的解决方法……首先想到的固然是用密文不要用明文，把明文按某种规则打乱为密文、或者让明文与密文有某种一一对应的规则 ，这样即便密文泄露，只要敌人不知道个人明文与密文之间转换的规则，它将一无所得。这是一种简单且行之有效的方法，即使到了近代一战二战中，还被普遍使用着，固然它的这个规则每每是动态的，甚至可能至关复杂。然而这样的方案在理论上有一个重大的缺陷，那就是你如何安全地传递“规则”？两地之间要确保能互相将密文变成明文，必须有共同的规则，那么就至少须要"一次"安全地将“规则”从一地传到另外一地,这在理论上是没法保证的，因此整个的安全体系也就没法让人彻底地放心，一旦规则泄露，对密文体系的打击则是致命的。有没有什么更好的办法呢？嗯，若是你之前没有接触过的话，我估计你是想不出了。解决的方法正是公共密钥体系。
让咱们再回头来看一看咱们是如何将明文变成密文的，最简单的是将它从新打乱，或者进行某种线性或
非线性变换，马上就让人难以阅读，但这也是最容易破译的，由于这种自身的变换在数学上相对容易求解，在如今的计算机的帮助下，经过必定量密文明文的统计分析，很容易找到其变化的规则。高级一点的，能够再用一组密码（能够是动态改变的，譬如随日期而改变），让明文与这组密码进行某种组合变化，从而获得一组密文，这样，因为这个“组合变化”多是很是复杂的一种数学变换，仅经过密文或者加上必定量的明文也很难找出这组密码以及这个“组合变化”的规则。这就是目前绝大多数加/解密的根本原理。而这里的这组密码，咱们就把它称做密钥。 可是这只是提升了得到密文者的对密文的破译难度，并无解决咱们前面提出的问题。如今就要来看看“共公（共开）”的含义了。在数学上有一种运算是单向的（在数学理论上截止目前为止），从一个方向算过去很简单，可是它的逆运算当缺乏正向运算时加入的一些信息时，就会变得几乎不可能（譬如大素数的分解，分解是困难到几乎不可能的，分解后的两个数乘回去是简单的，小学生就会，这就是著名的RSA的原理）。这就构成了咱们的“共公密钥”的理论基础。 具体使用以下：咱们首先产生一对密钥，一把称为加密密钥，一把称为解密密钥，它们是相关但不相同的。加密时咱们把明文与加密密钥一块儿采起“不可逆”数学运算进行“组合变化”，造成密文，解密时把密文与解密密钥一块儿采起相似的运算进行解密，注意，这处由于加密密钥与解密密钥产生时便是相关连的，因此解密密钥可以完成这样一个“逆运算”。同时，解密密钥也能够用来加密，相应的，加密密解也能够用来解“用解密密钥加密的密文”。具体使用的时候很简单，把加密密钥看成公共密钥，分发给任何想要获取的人，解密密钥由本身妥善保管做为私钥。当拥有加密密钥的人要传递密文给本身时，他只要使用自由获取的个人公共密钥来加密该明文便可，固然，他加密之后他本身也是不能解的，可是传到我手里之后，我则能够用解密密钥来解密，这样就很好地解决了前面提出的没法安全传输“规则”的问题，如今个人公共密钥是公开的，你要拿就拿去好了：） 而私钥我本身好好保存，不用把它放出来。 公共密钥另外一个重要做用就是用来签名。我使用私钥对本身的文件加密后，你来使用我发放的公钥来解密，若是解密成功，则可证实这的确是我发出来的文件。 在如今网络信息安全经常使用的证书体系中，“证书”的背后其实也是这样的一种公共密钥体系。