ational)软件技术盛宴在奥兰多市Walt Disney World Swan and Dolphin Hotel正式拉开序幕。IBM高级副总裁兼软件与系统集团总经理、IBM软件Rational全球总经理Kristof Kloeckner等高管登台演讲，为全球技术人员分享了软件生命周期管理、开发者职能角色演变、未来软件(系统)开发新模式以及IBM的最新策略。今年大会的主题围绕软件给企业带来的竞争力与核心优势展开，关键词是整合、协作、敏捷、软件计量经济学、云计算、应用安全...不少观点颇为有趣，CSDN记者在现场为您发回图文直播和解读。(注：直播进行中，本页面可不断刷新)
主会场Walt Disney World Swan and Dolphin Hotel外景图
IBM Innovate2011即将开始
VP，Marketing,IBM Rational Gina Poole
北京时间20:00大会正式开始。VP，Marketing,IBM Rational Gina Poole为大会致开场白。她阐述了软件为企业带来的竞争优势以及本次大会的亮点。Gina Poole谈到了要引歌高唱、享受每一天，会场中突然出现了舞者响应。
在分布在会场各处的引舞者的带动下，现场听众也一起站立舞动起来。(跳舞的反映的寓意也是协作，如同爵士乐进行曲一般进行软件开发)
喜剧演员、作家Felicia Day作为第一天上午主会场的主持人。她从自己多年来的舞台话剧的经历来演绎自己对Rational软件开发的理解，她感触最深的有两点，其一是Massive(大规模)，大型的软件；其二是Interdependence，即和演话剧一样，在Rational软件的设计、开发、实施过程中，所有的成员都需要彼此依赖，互相依靠。
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 喜剧演员、作家Felicia Day
上台演讲。他在几个月以前才被任命为IBM软件Rational全球总经理，在此之前他担任IBM全球战略与企业技术副总裁兼IBM云计算的CTO。Kristof介绍，本次Innovate2011大会是为Rational的实践者(Practitioners)开的，而不是为Rational技术的制造者。
Gina Poole把话题交给了Kristof
软件开发是所有人的事 实践者创新时代来临
Kristof表示，Rational软件走过了这么多年，经历过很多变化，但有几个关注点是始终不变的，即协作(Collaboration)、整合(Integration)、优化(Optimization)、高效(Efficiency)。本次大会的所有内容也可以用这8个字概括。他强调，如今软件的设计、开发、交付、部署、安装使用，所有的步骤都需要Communnity的人一起来做。而不是像以前那样相对割裂开的，软件开发完了给测试人员，测试完了给部署安装团队...。而是大家一起来设计、开发、部署和使用！
Kristof再次谈到了敏捷(Agile)，他认为敏捷开发的中心就是重复使用(Reuse)，他以Rational软件为例，即使在跨众多不同行业的大型企业应用中，也有很多基础模块是重复的。这也是Rational提供给用户的中心议题&&模块化、反复的重新使用。
他认为软件开发的方式已经发生了改变。过去流水线似、机械的软件开发模式已经在受到抛弃，在那样的模式下，开发者只是完成已经设计成型后的Coding的工作。更加鼓励让更多底层实践者(Practitioners)进行创新(Innovate)的时刻已经到了(仅凭老板拍脑袋创新的时代已经过去了)。
Kristof在总结中表示：(1)现在搞软件开发要靠工具(Tools)，而不是靠规矩(Rules!)，不要再像以前那样有那么多的条条框框；(2)企业应该在工具上投资(Investment)；(3)实践者(Practitioners)为主；例如Rational软件在医药行业的应用，所有的护士、医生都是主人，而不只是开发者；(4)在应用层面进行软件的生命周期管理，从设计到开发贯穿安装部署和使用的全过程，应用安全都是最重要的问题。同样的，在云计算的实施过程中应用安全也一样重要。
IBM Rational首席软件经济学家Walker Royce登场。Walker每天的主要工作就是不停的研究客户用于软件开发和交付上的投资是否划算的计算模型和标准。具体说来，就是从软件开发、交付以及系统开发、交付过程中获取技术成果，帮助理解和定义标准，并根据这些标准衡量技术成果对业务的影响，从而确定如何设定更符合客户业务目标的技术指标。
IBM Rational首席软件经济学家Walker Royce
他认为软件交付是一项经济学纪律(Economic Discipline),并引用了MIT研究员Lo Andrew和Mark Mueller的观点将软件交付的成熟度分为五个档次：Completely irreducible uncetainty、Partially reducible uncertainty、Fully reducible uncertainty、Risk without uncertainty、Complete certainty。
Walker Royce提到了一些重要的观点。
软件开发中能用到的资源有什么？他给出一个公式Resource=Complexity'Agility*Collaboration*Automation
软件开发的复杂性(Complexity)让人们不断研究创新模式，复杂的业务模型和需要处理的海量数据也给软件开发带来了新的机会；敏捷方法论(Agility)决定创新开发的过程；大规模的Teamwork；自动化(Automation)换个词也可以理解为工具(Tools)目前正在走向成熟。
据他的调查，人们对软件开发的关键文化正在转变，可计量性(Measures)正在受到越来越多的关注和采纳。在动手开发之前就通过软件计量经济学的标准和理论进行度量，这样就可预见开发过程和费用、可能会带来的变动成本和实施变更的难易程度、能否达到客户的要求，在最后经济上的投入是否是最佳选择，由此作出相应的判定和选择。
补充：在会后接受CSDN记者采访时，Walker Royce表示软件计量经济学作为一项相对较新的理论(概念)，目前更多的是需要在开发文化和管理方式的转变，而非工具。当然，它的推广必然是一个渐进的过程，而且是混合式的(理念+工具)。
Rational如何在实战中让软件开发过程可重用(Reuse)和协同革新(Collaboration Improvement)，GM(通用汽车) Technical Fellow William Bolander上场。
GM Technical Fellow William Bolander
在主会场里展示的通用Volt车系混合动力车
通用的Volt车系是美国市场最火热的双料动力车型。William Bolander表示：如果没有核心软件系统，Volt就只是一堆废铁和橡胶组成的废品，毫无竞争价值。但凭着高度复杂的嵌入式软件带来的各种智能化功能，它成了当今美国市场最火热的产品。他举例，如果按照过去的传统软件开发，Volt 的开发过程要用54个月，但与IBM Rational解决方案全面合作后，通过通用公司分布在全球有16个开发和应用中心的协作开发(包括在中国的研发中心)，全套产品从设计到开发到投入市场只用了29个月。里面的大量代码都是基于模块化的再利用，其中发动机引擎就有超过90%的代码是长期复用的，两套功能强劲的电控系统有超过80%的代码是可长期复用的模块...
Danske Bank开发主管Peter Rasmussen开始题为《Using Measurements as a Lever for Improvements》演讲。
Danske Bank开发主管Peter Rasmussen
采用可度量前后对比
Peter以采用可度量的软件研发的计量经济学方法论的前后对比为例，分享了他的看法：(1)软件开发效益要以结果为导向，而不是文档；(2)协作要从最开始设计阶段就进行，这样可以最大程度上减少后期的不确定性；(3)协作开发不仅是程序员的事，要在所有利益相关者中进行广泛协作。
IBM软件中间件高级副总裁Robert LeBlanc发表《Innovation that matters》的演讲。
IBM软件中间件高级副总裁Robert LeBlanc
他以加拿大路政管理公司、荷兰阿姆斯特丹机场和菲律宾的三家公司为例，号称IBM Rational和中间件将自动化性能和(基础架构、代码模块)的可重用性做到了极致。
在第一天Innovate2011的活动上，IBM还宣布了一系列的新产品发布计划。包括Collaborative Design Management(协作设计管理工具)、New Support for SAP(针对SAP和非SAP项目的统一管理器)、JazzHub for Academic Community(面向学术社区的部署在云上的RTC工具，目前是Beta版)、Accelerating growth and adoption of OSLC(加速OSLC的发展和采纳)、Rational developerWorks Community(在dW中新建Rational社区)、IBM Champions Program for Rational(面向社区领袖和杰出贡献者的奖项)，以及一系列的产品增强方案。
Keynote现场
21:40第一天主会场Keynotes的活动到此结束。
关于第二天的活动请查看：
[CSDN.NET记者/付江@奥兰多现场报道]在，IBM软件Rational全球总经理、IBM Rational首席软件经济学家Walker Royce等人已经登场，为全球技术人员分享了软件生命周期管理、开发者职能角色演变、未来软件(系统)开发新模式等话题。在大会第二天，IBM高级副总裁兼软件系统集团总经理也闪亮登场，他的演讲围绕着整合的至关重要性(Integrations that matter!)展开。
IBM高级副总裁兼软件系统集团总经理Steve Mills
作为IBM全球软件系统集团的掌门人，Steve Mills首先简要回顾了IBM软件集团的成长历程，他再次强调了IBM的软件业务策略：即不做直接面向消费者的应用软件，而聚焦在企业级软件市场(尤其是大规模用户的平台级软件)。对于软件的重要性，Steve Mills做了一个形象的比喻：软件是把双刃剑&&就像一把火，用得好可以取暖御寒，玩得不好也有可能把房子烧了。(烂软件的确会让事情变得一塌糊涂)
Steve Mills表示，对于大多数用户来说，现阶段绝大部分的IT投资都用在了管理已有的混乱的IT设备上，已经没有更多的预算去升级IT系统和购买新的设备。于是靠优化来提升现有IT设备性能和效率已经迫在眉睫。他认为具体的方式有三种：(1)硬件资源的整合；(2)消除软件和数据里的冗余部分，优化软件交付方式(例如通过SOA架构、数据压缩、重复数据删除、集成、存档相关的技术)；(3)改进服务交付方式(可视化、可控性、自动化、云计算等等)。
IT系统越来越简单
他以IBM自身内部IT基础设施的演化为例，基本原则是让IT越来越简化！
IBM内部的IT部署方式经历了从从Sprawl&&Consolidated&&Service Pooling&&Integration四个阶段，用到的核心技术包括了全面虚拟化、协调和大规模的服务器部署(Ensembles and Scalable Servers)、融合网络资源(Converged networks)、软件系统交付、端到端服务管理、云计算。
整合内部IT资源的5个建议
Steve Mills认为当前阶段首先需要重点解决的是充分整合已有的IT资源，让它们发挥出最大效率。他提到了几点建议：(1)优化服务器利用率；（2）提升存储效率和最佳实践；(3)消除冗余的软件（功能）和数据资源；(4)优化软件和系统交付；(5)投资组合的合理化(Portfolio Rationalization)，其中他谈到了收购在投资组合中的重要性。
软件系统价值最大化的不二法则
他在演讲中强调了，在他近40年的软件解决方案职业生涯中，他发现没有任何方法比重用(Reuse)和管理(Management)更能带来价值和高效。他提到了三个关键词：Catalog、Govern、Share!
Asset Reuse and Management
对于软件开发模式中的协作和分享，他以本次大会新推出的协作设计软件(Collaborative Design Management)为例，他认为将分析师、设计师、程序员、架构师、测试工程师、部署工程师连结成一体团队,用统一的集成开发工具(IDE)进行全过程的协作开发将成为未来的主流。当然，Steve Mills谈到的每一种解决方案里都有IBM相对应的解决方案和服务。
导读：本文是从《》这篇文章翻译而来，译文来自外刊IT评论《》。程序员在写程序时，往往自我观点性很强，文中给出了例举了程序员的七大坏毛病，并提出建议改之。
以下是文章内容：
1.所有的程序都写的很烂，除了我的。
我要告诉你一个坏消息，兄弟，所有的程序都写的很烂，包括你的。无论你在上面花多少功夫，其他大多数程序员总是会认为你写的代码很烂、他们能写出比你好10倍的程序。我在前几篇文章里已经讨论过了这个问题，你可以读读和，从中你可以理解我所说的所有的程序都写的很烂究竟是什么意思。
如何纠正：不要挑剔别人的程序，有一天也许你的程序会被人放在聚光灯下挑剔。要保持客观和专业的评论，不要轻易判断。要谦虚，从周围人哪里学习经验，警戒自己不要写出这么糟的程序。
2.我几秒钟就能把它改好，不用走变更流程了。
homer-simpson-doh
抄捷径充满诱惑，每个人都想抄捷径。有时候抄捷径是必要的，但总的来说，抄捷径是危险的，非常危险，应该避免这样做。走捷径也许会节省你数小时的时间，但如果走错了，它可能会给你带来数月的麻烦。
如何纠正：遇到需要慎重处理的事情时不要太过自信。让其他人来复查你的所作所为。如果你计划要走捷径，请确保让你的负责人知道这样做的理由以及其中的风险。每次在走捷径时最好都让你的经理来确认实施成功，也就是&让他给你擦屁股&。
3.这是个几分钟就能搞定的事。
在我的家乡Barcelona，那里的圣家族大教堂让我非常的自豪，它的举世闻名来自于它的美丽，也来自于它的建筑完工日期的规划(它动工于1882年，目前仍未完工)，但这可能是因为他们没有让一个程序员去估计这个完工时间，否则的话，估计出的完工所需的时间很可能2周。
如何纠正：从一开始，你就必须严肃的认识到，对于一个有一定规模的软件开发过程来说，进行精确的时间评估是不现实的，我们能做的只是猜测。同样要记住的非常相似一点是，我们通常会发现有很多事情根本不能预见到它们会花去我们数倍于我们初始估计的时间，我通常的做法是把估计的时间乘上1.5或2。
4.唯我独尊
很多程序员参与的讨论会基本上看起来就像是一场斗鸡，而不像是人类的讨论，这通常会出现在关于设计和架构问题的讨论会上。你基本上很容易看出其中各自都怀有顺我者昌逆我者亡的心态，你基本上可以把大多数的争论者所说的话直接换成咕咕！咕咕嘎！咕咕咕咕咕咕！咕咕嘎！
如何纠正：把你的自负留在心底。太过自负是所有程序员身上的一个非技术性的最大的一个毛病。凡事要三思而行。
5.这不是我的错！
在我看来，这另外一个大多数程序员都会有的坏毛病是缺乏责任心。我们总在找借口&就比如有人会说，如果在正常情况下，这个错误绝对不会出现，但说老实话，这很难让人信服。
如何纠正：犯了错误不需要去捶胸顿足，也不需要用刨腹自杀来谢罪。我们应该怀有一种健康的态度，说出这样的话：&呀，抱歉，我们现在就去改正这个错误，是我的错&，这是一种很敬业的态度，这能帮助我们树立一个好的声誉，更好的得到你的同事的尊重。
6.没有激情
重复的和简单的任务通常不会带来什么动力，但这些事必须要完成，当程序员被要求去完成这些事情时，通常会显得无精打采，没有效率。
如何纠正：纪律问题。很不幸，我再也想不出其它的治疗这种毛病的良方。
我发现大多数程序员对&干完&这个词很纠结。请记住，干完意味着：测试过(不仅仅只是单元测试)，文档完整，提交过，合并过&
如何纠正：这是一个很麻烦的问题，相对于完全的完成某些功能性问题而言，这些并不是显得很有必要的任务会很庞杂和难处理，通常需要你有纪律性和受过培训。也许，这最简单的能让一个程序员理解他的开发是否真正的完成的两个办法就是：相互复查和演示。
译文出自：
自从iPhone在全球热销，iPhone应用也开始繁荣发展，游戏应用尤其如此，有些销量甚至堪比AAA巨作。主流游戏开发商纷纷把iPhone视为现有产品的推广平台，甚至决定为该平台量身打造游戏产品。
对于独立游戏开发者来说，iPhone也是个重要的开发平台。因为其拥有庞大的用户群，所以该平台的游戏很快就能从小众需求变为大众产品。
新机遇的出现，为那些刚刚从经济衰退中复苏的人们开启了新的冒险旅程&&在商机无限的信仰感召下，新开发者们建立新游戏公司，着手制作新平台的游戏。
独特的界面、庞大的用户群、强大的可接入性和应用软件属性（&短简精&、可玩性高的游戏应用）等得天独厚的条件，为iPhone游戏的开发创造了无限可能。
目前，游戏质量的门槛如此之高，要在iPhone这样的&娇小&的设备里安装如此&壮硕&的游戏应用，想必不是件易事。更确切地说，游戏音频设计者将面临怎样的挑战？
除了所有游戏都存在的音频设计难题，在常规进程当中还面临着一系列附加难题和特殊难题。如果说这只是给游戏音效设计工作增加了一点难度，那么，信息不足就确实是设计者们面临的艰巨考验了。
要通过这个考验，iPhone音效设计者应该明确自身所面临的挑战、克服的办法和iPhone游戏音效的含义。在本文，我将探究设计者应该明确的设计依据、音效对软件的影响、技术难点、iPhone要解决的特殊难题，还将涉及用户行为、iPhone音频开发应用类型等方面。
以上也是我在与iPhone音效设计工作打交道过程中遇到的问题，并且我依次（但不是所有）找到了解决方法或者做出解释说明。我希望能将自己的经验与其他开发者分享。
那么，有效的iPhone音效设计到底要具备什么？动态音景、浸入式声道和高明的创意&&这些只是增加一点点难度。
众所周知，iPhone与其他平台相比有许多自身特点。从用户界面到用户特点，不止是不同，甚至到达了天差地别的程度，所以就产生了一些需要深思熟虑的设计要素。音效设计也不例外。我希望读者通过阅读本文的下半部分，了解作为一名游戏开发者应该明确的设计考虑。
ios_iphone4()
iPhone音效制作者最大的关切莫过资产大小。不过这个话题的范围太广，恐怕无法在一篇概要里完全解释清楚。（游戏邦注：作者在另一篇文章&Audio for iPhone: Size Matters&里也谈到了这个话题）以下内容主要是为读者阐明开发者面临的挑战。
苹果的无线传输大小限制是20MB，这意味着，如果不通过Wi-Fi，而是通过3G服务下载，那么所下载的应用大小不能超过20MB。这种大小限制对iPhone应用病毒式营销的有效性来说至关重要。
如果潜在用户必须找一个Wi-Fi网络热点（能够访问Wi-Fi网络的地方），或者等到回家再购买应用，那么这个销营过程就被破坏了，所以20MB的上限十分必要。
顺带说一下，如果完整版应用大小超过20MB，但仍然允许通过3G服务出售简化版，有DLC（追加内容下载包）就便利多了，因为DLC可以添加到新买的应用上。
考虑到音频资产的大小，缺少文件空间对音频制作者而言已经是个很大的挑战了，更别说与其他制作文件竞争空间了。你最多能指望占到50%，也就是10MB。在这种困境下，浸入式、动态、创新的音轨看似很棘手吧？这相当于你说服正在制作这款游戏的其他人相信你的理念占了整个游戏价值的50%！
怎么？难度太大了？记住，你要把这活当成你的最后一份工作好好做，所以别半途而废或是草草应对挑战。迎难而上，做出更上乘的音效才是王道。
iPhone在这个资产大小的问题上同样犯难，因为它在任何时候都只能解码一个压缩文件，这意味着大多数的音频（除了一些精选以外）都不能做成压缩的PCM格式（这种格式相对比较大）。但有不少方法可以缓和这个缺陷，如使用文件基础生成音频设备、交叉淡入淡出循环技术、精选渲染效果。
我最近还想出另一个巧妙的方法。压缩格式通常不能循环，因为在压缩过程中，音频文件的前后都被补上&填料&。正常情况下，这意味着音频不应该是压缩的，但我最近学会使用一个移除&填料&的程序生成无缝循环的MP3。
这个软件的具体工作原理我并不清楚，想知道就Google一下吧。我过去曾使用&Compu Phase&编制成的这类应用软件&&但PCM格式的音频大多需要源文件。这个软件能有效地移除未压缩文件格式的源文件请求，这点很重要。
除了这个方法，Apple文件详述了这么个系统，允许你以编程的方法移除&填料&，从而达到无缝循环。这个方法的缺点就是需要额外编码，但这也就是说，你可以使用M4A（AAC）编码，在低比特率下，M4A的音效确实比MP3好得多&&至少我个人这么认为。
那么，iPhone应用的制作重点是什么呢？这些问题在其他游戏音频中也存在，只是在移动设备市场显得更重要，因为玩家听游戏声音的方式不尽相同。听声音的方式不同是因为玩家的游戏环境和播放形式不同。
一般来说，玩家的游戏环境不外乎卧室或者客厅，使用的设备也就是电视扬声器或家庭影院。而对于iPhone就不是这么一回事了&&从厨房到公交车，设备从内置喇叭到任何玩家能接入的东西，都有可能是玩家的游戏环境。
我们不妨做一些假设&&在满足音频运行要求的环境下，大多玩家只会使用内置喇叭（iPhone 、 iPod 和iPad的音效是不同的）或者耳机（每一款Apple产品之间的音效差异非常小）。
尽可能在游戏中或者设备上测试音效。在游戏中的音效测试非常重要，你应该已经测过了吧，iOS设备尤其需要测试。如果能用上录音室专用的监听设备作测试，那你大概可以听到天籁之音了。不过，Apple耳机能不能产生符合要求的音效，就是另一回事了。
请记住，要在不同的设备、不同的环境中（厨房、巴士、公园甚至是洗手间）、有无耳机等的情况下测试游戏音效。显然，在这么多情况下，不可能有哪一种完全达到要求的，所以关键就是在这么多条件下取得最佳中间点。
我第一次摸到iPhone时，我的第一个反应是：屏幕的触感不太好，或者说缺乏触感功能的界面设置（除了主页铵钮）。稍后我会更详细地讨论触感的问题。我之所以现在就提出来是因为触感的缺乏往往要靠某种反馈来弥补，而这个重任恰恰就落在音效上（因为玩家的手指挡着屏幕，所以很难看到按了什么键）。
大多情况下，对玩家按键的再次确认反馈就是发出悦耳的&叮&或&砰&的声音，但这种声音必须让用户听到。iOS的菜单选择声的音效还是很不错的。内置喇叭发出的声音主频很容易再现，总体音效又不会被喇叭反复发出的频率所掩盖。
也就是说这个&叮&声是作为一个小过渡&&这种声音不会被切断也不会失真，更说不上难听，而且还很入耳。在耳机的条件下也一样。作为音效师，你可以好好利用这个特点，不过还是不要忘了所有设备都是不同的。
因为小喇叭（耳机或内置式）的特性，精确的声音播放长度难免受限。大多的低频率声音是根本无法播放的。如果硬要这么做的话，就不得不牺牲高频率的音质。
最好的办法是，把iPhone声音的最大频率值上限变小。大多音乐缩减频率20到70 Hz就能听得出来了，但考虑到播放的可能形式，这个缩减量还得往上提。尽管缩减低频可以&存活&高频，但除此之外就没有任何好处了。这么做还会引起音量峰值的增加，无论你使用什么数码音频工作站软件都是这样的。所以还是小心剪辑为妙。
最后一点是音量能力（在不失真的情况下能达到多大的音量）剪辑。所有设备都存在谐声共振失真的现象，无论是回放大音量还是某个频率。如果玩家一直调高设备音量，内置喇叭放出的声音就会失真。如果玩家是在比较喧闹的环境下使用设备，那么失真的现象就很普遍了。这未必就是玩家的错，不过音效听起来很差倒是不假，而且也损害了整个游戏的形象。
不幸的是，我对这个问题也是不知所措啊&&因为这是设备本身的问题。我们能做的就是减小最大音量，直到某个点上，在这个点上音量峰值不会引起破音或失真，不过这么做的话，当前游戏可能比其他处于同一音量值的游戏要安静得多。也难怪这会被看成是缺陷了。
我能想到的唯一一个行得通的办法就是，允许音量在正常的范围内增大，且音量能达到的峰值也是正常的上限。这个办法也不是尽善尽美的，但好歹是个方案吧。
我给iPhone制作音效的惯用工具不外乎标准的DAW软件。能编写、能录音、能生成、能混音、能剪辑、能优化、能编码和能采样，这就是你所需的所有功能了。我本人一般是使用Logic Pro （只用这款软件的时候越来越多了）和 Cubase（游戏邦注：它是集音乐创作、音乐制作、音频录制、音频混音于一身的工作站软件系统，由德国Steinberg推出）就能做好所有工作了，不过其实任何带编码器（要好一点的）和采样功能的软件就我够用了。
我用Logic Pro（由Apple推出的业内领先的音乐创作和音频制作软件）挺顺手的，是因为苹果的M4A编码器很好用，MP3编码器也不赖（游戏邦注：iPhone开发工具Unity 3不再支持M4A了）。
还有其他专门的采样软件包，也是有用的。
我个人只使用Logic Pro，各位只要使用自己顺手工具就好了（当然，得保证这个软件会做比挑拣采样更复杂的工作，我通常采样声音文件的频率是从44.1Khz到24Khz）。
除了这个软件，我很少再使用其他软件了&&我觉得没必要把创作过程复杂化，软件的切换总是会增加创作时间。
只要你能满足开发者的要求，使用什么软件都不要紧。通常情况下，我预期可交付的成品和我实际做出的成品出路不大。我上交的所有声音和音乐都是未编辑、标准化的PCM文件格式，频率至少是44.1Khz。
这样我所交出的文件就能达到游戏的要求了，文件的采样/编码版本是混音和编辑过的。除此之外，我会提供一个技术文件，详述各个样本的用途、解释使用目的、使用方向、文件名等和所有可能用到的特殊细节。
就各个开发环境如何不同方面而言，差别很小。我前面提到Unity 3不再支持M4A，所以如果这是默认的文件格式我就会使用，但如果客户使用的是Unity 3或者自己创建的开发工具，我就会改用MP3格式或者ogg格式（游戏邦注：它是一种新的音频压缩格式，普遍使用于预订的开发环境）。
我使用过的所有开发工具都要求任何要在3D空间播放的声音都必须有单声道声音文件，但基本上所有平台都是这样的。顺便提醒一下，大多数Mac用户没有办法打开Word DOC文件，所以我通常以简单的text文件格式发送优化兼容性的内容。
iPhone作为移动游戏设备推向市场，我前面提到过，你必须认真考虑iPhone的使用地点。这个问题对许多设计过程都有重大影响，音效设计也不例外。最后别忘了尽量多选几种设备做测试。
iPhone games(from ec-base.net)
我们知道iOS设备各不相同（iPad, iPod, iPhone）和有什么不同，但你知道他们的界面有什么不同吗？界面对iPhone游戏设计有何影响？其实所有游戏的设计原则都大同小异。
iOS的独特之处会影响玩家的行为，这些特点是：拥有六维加速器、主界面是触屏、屏幕较小，最重要的是，它是个面向广大用户群体的移动设备。
拜这个独特的用户界面所赐，玩家终于被迫学习与新技术的互动方式&&这也是开发者的设计内容。但这对音效设计意味着什么？与视觉效果这个主角相比，游戏的音效时常充当的是无名英雄的角色。如果玩家还是在吵闹的环境下玩游戏，那就别指望玩家能听到无名英雄的声音了。
更惨的是，大多数玩家怕吵到别人，所以就调低音量；因为使用耳机只有玩家自己能听到声音，这显然不符合社交需求，所以玩家很少会使用耳机&&正是这种设备的可用性和普遍性限制了无名英雄出头的机会。与他人分享游戏、把游戏转手给他人玩、随便在一个地方和别人一起玩，正是这种增强的社交需要使无名英雄的地位一低再低，最后终于被封杀（关闭）了！
在头戴耳机的情况下，玩家很可能一边听音乐（说到底就成了个iPod），一边玩游戏。我第一次注意到这种行为是在新游戏初测时。如果玩家发现自己的游戏打扰到别人，玩家就会调低音量。
玩家向别人展示游戏时，通常会消音后把设备给别人；在已经很难得到音效反馈的情况下，我发现我自己和其他玩家都没有意识到声音的存在。这真是太令人沮丧啦。说到底，成千上万的人在玩你的游戏，听到了什么、有多少人在听，是无从知晓了。但是任何加强音效的游戏，都更可能给人留下深刻的印像。
如前所述，因为iPhone界面如此独特，所以有几个设计问题要考虑到。我首先注意到的是iPhone的所有控制都缺乏触感。作为互动联系的两个主要方式，触屏和加速给用户的反馈却相当有限。所以操作问题就变得棘手了&&因为用户的每一个操作未必都有反馈，所以用户就不断地质疑他们的操作是否已经被设备接收。
一个真实的按钮有这么几个特点：物理移动受限（固定在设备上）、不用看就能识别它的位置及与其他键区分开来（在游戏中这个特点非常必要）。另外，在画面和声音的结合下，所有交互作用都能在游戏中得到加强。
就最基本的层次上讲，游戏只是对玩家交互作用的正反应，但iPhone把一切都改变了。因为玩家只有通过触屏才能知道碰到了什么、发生了什么，但通常要看的地方都让手指挡掉了，人机交互过程就是样被复杂化的。
小屏幕就这样阻碍了设备对玩家的反馈；而加速器的存在，意味着屏幕会四处移动。在这种情况下之下，玩家只能指望声音来指点迷津了。你看看，声音的作用就在于此！
综合考虑到以上所有要点，和开发者共事确实要处理一大堆问题。开发者（除非是我指导音频设计工作）往往列出一份清单，上面列出音效、音乐、环境声音等他所需要的声音，还会标明预期用途、运用位置和长度（是否循环）另外还附上一个简短的效果描述。
一般来说这么做没什么不好，但把这份清单运用于iPhone音效设计就会产生几个问题。如，我需要五个一分钟的循环音乐片段，每一个片段都是相同的长度、循环、环境声音，且每个都要在不同的主题中同时演奏。这个摘要描述得相当合理，不过在iPhone上是行不通的。
首先，在磁盘上，一个一分钟长度、频率为24Khz的PCM文件大小是5.8 MB。所以单单是音乐加环境声音就已经达到58MB了，这大大超过20MB的无线传输限制了。假设不需要考虑资产大小，处理这么大的文件，存储器的工作也是相当繁重了。
所以你要压缩文件了，是吧？还是算了吧，iPhone每次只能回放一个压缩文件。在这种条件下，环境声音和音乐要同时播放的话&&成不成问题，你懂的。
怎么可能没有解决办法呢？每个问题的解决办法我都提过了，万事俱备，只欠东风&&执行方案就是最后的挑战了。显然音效设计需要明确方向、详尽计划和周全思考，而不是大部分人都指望的那样&&只盯着一份音效清单就开工。
更恶劣的是，音效往往是在游戏开发的最后阶段才添加上去。&我们现在要开始第一次测试了，把音效加上去吧&，这种想法行不通。音效现在已经是游戏设计和开发的一部分，不再是孤立的环节，所以通盘考虑是必要的。因此，游戏开发者们，叫音效设计师从头到尾都要参与工作&&音效设计师们，准备接受挑战吧。
如果非要列出一份音效清单的话，我会要求玩这个游戏然后再自己列出清单。这不是因为我自视甚高，而是因为音效就是我的专长，并且如果能从头开始做设计，执行各种设计要素肯定容易得多。
我这么说绝不是叫你抛掉开发者列的那份清单。相反地，你应该按清单来做&&只是别那么盲目罢了。加上声音生成系统、结合资产、压缩等技术，音效会更好，不过这些技术本来对音效设计就很重要了。这些通常是开发者不会想到的要求。
为什么开发者想不到？iPhone音效设计又不是他们的专业，而是音效设计师的工作。在独立游戏开发者带领的小团队中，作曲家和声音设计师也得充当监督、设计师和领导者。在iPhone游戏的开发过程中，一个人搞定iPhone的游戏音效，这类人简直成了单人乐队中的多面手了。
其他考虑要素
我想返回用户行为的话题&&如何促成病毒式营销。就iPhone而言，病毒式营销方式发挥了重要作用。这得归功于iPhone作为移动设备的特性、简单的网页链接能力和低廉的应用价格，iPhone无处不在也就不足为奇了。要让别人知道你在玩什么，发出声音最管用。不像画面，别人得看到了才知道你在乐呵个什么。
就已经树立的品牌来说，这不难，因为大多响当当的图标已经成为品牌的一部分了，所以声音和品牌不费吹灰之力就能认出来了。开发新产品，创建品牌是最讲究技巧的部分，而声音则是关键特征。记着这点吧，你会发现声音如何在游戏之外的世界大展身手。
iPhone的游戏类型不胜枚举，有相当多是在现存的类型基础上开发出来的，也有不少是新作品。各种游戏纷纷在iPhone平台上扎营，有些是从其他平台移植过来的、有些是专为iPhone平台开发的，有些在制作上则对设备要求欠考虑。有些游戏运作得不错，有些就不太乐观。就数量上看，很可能早就大大超过5万个游戏了。就音效来说，所有游戏都有音效，只是上乘之作不多。
还是这个道理，成功的iPhone游戏已经把质量的门槛提得太高了。所以，音效显然必须配得上高标准的游戏。尽管这种挑战看起来太棘手，但也绝对不是无法应对的&&所以，迎难而上吧，有超级游戏就有卓越音效！
原文链接：
[CSDN.NET记者 付江@奥兰多现场报道]北京时间6月6日晚上八点钟，IBM一年一度的(Rational)软件技术盛宴在奥兰多市Walt Disney World Swan and Dolphin Hotel正式拉开序幕。IBM高级副总裁兼软件与系统集团总经理Stive Mills、IBM软件Rational全球总经理Kristof Kloeckner等高管登台演讲，为全球技术人员分享了软件生命周期管理、开发者职能角色演变、未来软件(系统)开发新模式以及IBM的最新策略。今年大会的主题围绕软件给企业带来的竞争力与核心优势展开，关键词是整合、协作、敏捷、软件计量经济学、云计算、应用安全...不少观点颇为有趣，CSDN记者在现场为您发回图文直播和解读。(注：直播进行中，本页面可不断刷新)
主会场Walt Disney World Swan and Dolphin Hotel外景图
IBM Innovate2011即将开始
VP，Marketing,IBM Rational Gina Poole
北京时间20:00大会正式开始。VP，Marketing,IBM Rational Gina Poole为大会致开场白。她阐述了软件为企业带来的竞争优势以及本次大会的亮点。Gina Poole谈到了要引歌高唱、享受每一天，会场中突然出现了舞者响应。
在分布在会场各处的引舞者的带动下，现场听众也一起站立舞动起来。(跳舞的反映的寓意也是协作，如同爵士乐进行曲一般进行软件开发)
喜剧演员、作家Felicia Day作为第一天上午主会场的主持人。她从自己多年来的舞台话剧的经历来演绎自己对Rational软件开发的理解，她感触最深的有两点，其一是Massive(大规模)，大型的软件；其二是Interdependence，即和演话剧一样，在Rational软件的设计、开发、实施过程中，所有的成员都需要彼此依赖，互相依靠。
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 喜剧演员、作家Felicia Day
上台演讲。他在几个月以前才被任命为IBM软件Rational全球总经理，在此之前他担任IBM全球战略与企业技术副总裁兼IBM云计算的CTO。Kristof介绍，本次Innovate2011大会是为Rational的实践者(Practitioners)开的，而不是为Rational技术的制造者。
Gina Poole把话题交给了Kristof
软件开发是所有人的事 实践者创新时代来临
Kristof表示，Rational软件走过了这么多年，经历过很多变化，但有几个关注点是始终不变的，即协作(Collaboration)、整合(Integration)、优化(Optimization)、高效(Efficiency)。本次大会的所有内容也可以用这8个字概括。他强调，如今软件的设计、开发、交付、部署、安装使用，所有的步骤都需要Communnity的人一起来做。而不是像以前那样相对割裂开的，软件开发完了给测试人员，测试完了给部署安装团队...。而是大家一起来设计、开发、部署和使用！
Kristof再次谈到了敏捷(Agile)，他认为敏捷开发的中心就是重复使用(Reuse)，他以Rational软件为例，即使在跨众多不同行业的大型企业应用中，也有很多基础模块是重复的。这也是Rational提供给用户的中心议题&&模块化、反复的重新使用。
他认为软件开发的方式已经发生了改变。过去流水线似、机械的软件开发模式已经在受到抛弃，在那样的模式下，开发者只是完成已经设计成型后的Coding的工作。更加鼓励让更多底层实践者(Practitioners)进行创新(Innovate)的时刻已经到了(仅凭老板拍脑袋创新的时代已经过去了)。
Kristof在总结中表示：(1)现在搞软件开发要靠工具(Tools)，而不是靠规矩(Rules!)，不要再像以前那样有那么多的条条框框；(2)企业应该在工具上投资(Investment)；(3)实践者(Practitioners)为主；例如Rational软件在医药行业的应用，所有的护士、医生都是主人，而不只是开发者；(4)在应用层面进行软件的生命周期管理，从设计到开发贯穿安装部署和使用的全过程，应用安全都是最重要的问题。同样的，在云计算的实施过程中应用安全也一样重要。
IBM Rational首席软件经济学家Walker Royce登场。Walker每天的主要工作就是不停的研究客户用于软件开发和交付上的投资是否划算的计算模型和标准。具体说来，就是从软件开发、交付以及系统开发、交付过程中获取技术成果，帮助理解和定义标准，并根据这些标准衡量技术成果对业务的影响，从而确定如何设定更符合客户业务目标的技术指标。
IBM Rational首席软件经济学家Walker Royce
他认为软件交付是一项经济学纪律(Economic Discipline),并引用了MIT研究员Lo Andrew和Mark Mueller的观点将软件交付的成熟度分为五个档次：Completely irreducible uncetainty、Partially reducible uncertainty、Fully reducible uncertainty、Risk without uncertainty、Complete certainty。
Walker Royce提到了一些重要的观点。
软件开发中能用到的资源有什么？他给出一个公式Resource=Complexity'Agility*Collaboration*Automation
软件开发的复杂性(Complexity)让人们不断研究创新模式，复杂的业务模型和需要处理的海量数据也给软件开发带来了新的机会；敏捷方法论(Agility)决定创新开发的过程；大规模的Teamwork；自动化(Automation)换个词也可以理解为工具(Tools)目前正在走向成熟。
据他的调查，人们对软件开发的关键文化正在转变，可计量性(Measures)正在受到越来越多的关注和采纳。在动手开发之前就通过软件计量经济学的标准和理论进行度量，这样就可预见开发过程和费用、可能会带来的变动成本和实施变更的难易程度、能否达到客户的要求，在最后经济上的投入是否是最佳选择，由此作出相应的判定和选择。
补充：在会后接受CSDN记者采访时，Walker Royce表示软件计量经济学作为一项相对较新的理论(概念)，目前更多的是需要在开发文化和管理方式的转变，而非工具。当然，它的推广必然是一个渐进的过程，而且是混合式的(理念+工具)。
Rational如何在实战中让软件开发过程可重用(Reuse)和协同革新(Collaboration Improvement)，GM(通用汽车) Technical Fellow William Bolander上场。
GM Technical Fellow William Bolander
在主会场里展示的通用Volt车系混合动力车
通用的Volt车系是美国市场最火热的双料动力车型。William Bolander表示：如果没有核心软件系统，Volt就只是一堆废铁和橡胶组成的废品，毫无竞争价值。但凭着高度复杂的嵌入式软件带来的各种智能化功能，它成了当今美国市场最火热的产品。他举例，如果按照过去的传统软件开发，Volt 的开发过程要用54个月，但与IBM Rational解决方案全面合作后，通过通用公司分布在全球有16个开发和应用中心的协作开发(包括在中国的研发中心)，全套产品从设计到开发到投入市场只用了29个月。里面的大量代码都是基于模块化的再利用，其中发动机引擎就有超过90%的代码是长期复用的，两套功能强劲的电控系统有超过80%的代码是可长期复用的模块...
Danske Bank开发主管Peter Rasmussen开始题为《Using Measurements as a Lever for Improvements》演讲。
Danske Bank开发主管Peter Rasmussen
采用可度量前后对比
Peter以采用可度量的软件研发的计量经济学方法论的前后对比为例，分享了他的看法：(1)软件开发效益要以结果为导向，而不是文档；(2)协作要从最开始设计阶段就进行，这样可以最大程度上减少后期的不确定性；(3)协作开发不仅是程序员的事，要在所有利益相关者中进行广泛协作。
IBM软件中间件高级副总裁Robert LeBlanc发表《Innovation that matters》的演讲。
IBM软件中间件高级副总裁Robert LeBlanc
他以加拿大路政管理公司、荷兰阿姆斯特丹机场和菲律宾的三家公司为例，号称IBM Rational和中间件将自动化性能和(基础架构、代码模块)的可重用性做到了极致。
在第一天Innovate2011的活动上，IBM还宣布了一系列的新产品发布计划。包括Collaborative Design Management(协作设计管理工具)、New Support for SAP(针对SAP和非SAP项目的统一管理器)、JazzHub for Academic Community(面向学术社区的部署在云上的RTC工具，目前是Beta版)、Accelerating growth and adoption of OSLC(加速OSLC的发展和采纳)、Rational developerWorks Community(在dW中新建Rational社区)、IBM Champions Program for Rational(面向社区领袖和杰出贡献者的奖项)，以及一系列的产品增强方案。
Keynote现场
21:40第一天主会场Keynotes的活动到此结束。
浏览器安全模型规定，XMLHttpRequest、框架（frame）等只能在一个域中通信。从安全角度考虑，这个规定很合理；但是，也确实给分布式（面向服务、混搭等等本周提到的概念）Web开发带来了麻烦。
为了实现跨域通信，通常的解决方案有3种：
本地代理：需要一些硬件设施（没有服务器的客户端无法运行），并且带宽和潜伏时间也要加倍（远程服务器－代理服务器－客户端）。
Flash：远程主机中需要部署一个crossdomain.xml文件，而且，Flash作为一门专有技术，其前途尚不明朗；换句话说，开发人员很可能要学习一种目标不确定的编程语言。
Script标签：无法确切知道内容是否有效，没有标准的实现方法，又可能被认为是一种&安全风险&。
在此，我建议使用一种新技术，也是一种独立于标准的方法，即通过script标签来跨域获取数据，名为JSON with Padding，或者就叫JSONP。JSONP的原理很简单，但需要服务器端给予相应配合。大致来说，JSONP的实现思路就是在客户端编程时作好使用JSON数据的准备，然后再通过圆括号将这些数据括起来以创建一条有效的JavaScript语句（可能是一次有效的函数调用）。
也就是说，客户端可以使用一个用于命名jsonp的查询参数来决定可以获取的数据。最简单的情况下，如果jsonp参数为空，则返回的数据就是被括在圆括号中的JSON。
下面，我们就以为例，来说明JSONP的原理。该API有一个&script tag&变量（即，可以将下面的URL作为script标签的src属性值，用以加载del.icio.us这个API提供的数据。&&译者注）如下所示：
http://del.icio.us/feeds/json/bob/mochikit+interpreter:
if(typeof(Delicious) ==&'undefined') Delicious = {};
Delicious.posts = [{
&&&&"u":&"",
&&&&"d":&"Interpreter - JavaScript Interactive Interpreter",
&&&&"t": [
&&&&&&&&"mochikit","webdev","tool","tools",
&&&&&&&&"javascript","interactive","interpreter","repl"
如果用JSONP的方式来表示，那么与此具有相同语义的URL应该是这样的：
http://del.icio.us/feeds/json/bob/mochikit+interpreter?jsonp=if(typeof(Delicious)%3D%3D%27undefined%27)Delicious%3D%7B%7D%3BDelicious.posts%3D
单纯看这个URL似乎没有什么，但我们可以要求服务器在数据有效时给出通知。因此，我可以编写一个用于跟踪数据的小系统：
var&delicious_callbacks = {};
function&getDelicious(callback, url) {
&&&&var&uid = (new&Date()).getTime();
&&&&delicious_callbacks[uid] =&function&() {
&&&&&&&&delete&delicious_callbacks[uid];
&&&&&&&&callback();
&&&&url +=&"?jsonp="&+ encodeURIComponent("delicious_callbacks["&+ uid +&"]");
getDelicious(doSomething,&"+interpreter");
根据以上假设，用于获取数据的URL应该如下所示：
http://del.icio.us/feeds/json/bob/mochikit+interpreter?jsonp=delicious_callbacks%5B12345%5D
delicious_callbacks[12345]([{
&&&&"u":&"",
&&&&"d":&"Interpreter - JavaScript Interactive Interpreter",
&&&&"t": [
&&&&&&&&"mochikit","webdev","tool","tools",
&&&&&&&&"javascript","interactive","interpreter","repl"
可见，由于使用圆括号括住了返回的数据，这就相当于把一个JSONP请求转化成了一次函数调用，或者得到了一个纯粹的JSON直接量。服务器所要配合做的，就是在JSON数据的开头添加一小段文本（即回调函数的名称。&&译者注）并将JSON数据放在括号中！
当然，接下来最好是使用Mochikit、Dojo等框架来抽象JSONP，从而让自己省去动手编写DOM以插入script标签的麻烦。
没错，JSONP只是解决了标准化的问题。假如远程主机想通过script标签向页面中注入恶意代码，而不是返回JSON数据，那么页面安全可能会随时受到威胁。不过，一旦实现了JSONP，那么对开发人员来说肯定是一件省时省力的大好事，在此基础上各种一般化的抽象、教程及文档也会应运而生的。
注：缩写词 JSONP 由 Bob Ippolito 在一篇名为 && 的文章中提出。但许多支持以 JSONP 技术实现跨域通信的厂商没有称其为 JSONP。例如，雅虎公司就称这种技术为 &JSON with callbacks&。另外，原文发表于日。
在《Pragmatic Ajax&A Web 2.0 Primer 》中偶然看到对readyStae状态的介绍，感觉这个介绍很实在，摘译如下：
&0: (Uninitialized) the send( ) method has not yet been invoked.&&1: (Loading) the send( ) method has been invoked, request in&progress.&&2: (Loaded) the send( ) method has completed, entire response&received.&3: (Interactive) the response is being parsed.&&4: (Completed) the response has been parsed, is ready for harvesting.&
&0 －&（未初始化）还没有调用send()方法&1 －&（载入）已调用send()方法，正在发送请求&2 －&（载入完成）send()方法执行完成，已经接收到全部响应内容&3 －&（交互）正在解析响应内容&4 －&（完成）响应内容解析完成，可以在客户端调用了&
对于readyState的这五种状态，其他书中大都语焉不详。像《Foundations of Ajax》中，只在书中的表2-2简单地列举了状态的&名称&－－The state of the request. The five possible values are 0 = uninitialized,&1 = loading, 2 = loaded, 3 = interactive, and 4 = complete。而《Ajax in Action》中好像根本就没有提到这5种状态的细节。《Professional Ajax》中虽不尽人意，但还是有可取之处：
There are five possible values for readyState:&0 (Uninitialized): The object has been created but the open() method hasn&t been&called.&1 (Loading): The open() method has been called but the request hasn&t been sent.&2 (Loaded): The request has been sent.&3 (Interactive). A partial response has been received.&4 (Complete): All data has been received and the connection has been closed.&
readyState有五种可能的值：0 (未初始化)： (XMLHttpRequest)对象已经创建，但还没有调用open()方法。1 (载入)：已经调用open() 方法，但尚未发送请求。2 (载入完成)： 请求已经发送完成。3 (交互)：可以接收到部分响应数据。4 (完成)：已经接收到了全部数据，并且连接已经关闭。
在《Understanding AJAX: Using JavaScript to Create Rich Internet Applications》中，则用下表进行了说明：
readyState Status Code
Status of the&XMLHttpRequest&Object
(0) UNINITIALIZED未初始化
The object has been created but not initialized. (The&open&method has not been called.)（XMLHttpRequest）对象已经创建，但尚未初始化（还没有调用open方法）。
(1) LOADING载入
The object has been created, but the&send&method has not been called.（XMLHttpRequest）对象已经创建，但尚未调用send方法。
(2) LOADED载入完成
The&send&method has been called, but the status and headers are not yet available.已经调用send方法，（HTTP响应）状态及头部还不可用。
(3) INTERACTIVE交互
Some data has been received. Calling the&responseBody&and&responseText&properties at this state to obtain partial results will return an error, because status and response headers are not fully available.已经接收部分数据。但若在此时调用responseBody和responseText属性获取部分结果将会产生错误，因为状态和响应头部还不完全可用。
(4) COMPLETED完成
All the data has been received, and the complete data is available in the&responseBody&and&responseTextproperties.已经接收到了全部数据，并且在responseBody和responseText属性中可以提取到完整的数据。
根据以上几本书中的关于readyState五种状态的介绍，我认为还是《Pragmatic Ajax&A Web 2.0 Primer 》比较到位，因为它提到了对接收到的数据的解析问题，其他书中都没有提到这一点，而这一点正是&(3)交互&阶段作为一个必要的转换过程存在于&(2)载入完成&到&(4)完成&之间的理由，也就是其任务是什么。归结起来，我觉得比较理想的解释方法应该以&状态：任务（目标）+过程+表现（或特征）&表达模式来对这几个状态进行定义比较准确，而且让人容易理解。现试总结如下：
(0)未初始化
此阶段确认XMLHttpRequest对象是否创建，并为调用open()方法进行未初始化作好准备。值为0表示对象已经存在，否则浏览器会报错－－对象不存在。
此阶段对XMLHttpRequest对象进行初始化，即调用open()方法，根据参数(method,url,true)完成对象状态的设置。并调用send()方法开始向服务端发送请求。值为1表示正在向服务端发送请求。
(2)载入完成
此阶段接收服务器端的响应数据。但获得的还只是服务端响应的原始数据，并不能直接在客户端使用。值为2表示已经接收完全部响应数据。并为下一阶段对数据解析作好准备。
此阶段解析接收到的服务器端响应数据。即根据服务器端响应头部返回的MIME类型把数据转换成能通过responseBody、responseText或responseXML属性存取的格式，为在客户端调用作好准备。状态3表示正在解析数据。
此阶段确认全部数据都已经解析为客户端可用的格式，解析已经完成。值为4表示数据解析完毕，可以通过XMLHttpRequest对象的相应属性取得数据。
概而括之，整个XMLHttpRequest对象的生命周期应该包含如下阶段：创建－初始化请求－发送请求－接收数据－解析数据－完成
在具体应用中，明确了readyState的五个状态（XMLHttpRequest对象的生命周期各个阶段）的含义，就可以消除对Ajax核心的神秘感（语焉不详的背后要么是故弄玄虚，制造神秘感；要么就是&以其昏昏，使人昭昭&），迅速把握其实质，对减少学习中的挫折感和增强自信心都极其有益。
比如，通过如下示例：
//声明数组
var states ＝ [&正在初始化&&&,
&正在初始化请求&&成功！
正在发送请求&&&,
正在接收数据&&&,
正在解析数据&&&,
//回调函数内部代码片段
if (xmlHttp.readyState==4)
var span = document.createElement(&span&);
span.innerHTML = states[xmlHttp.readyState];
document.body.appendChild(span);
if (xmlHttp.status == 200)
var xmldoc = xmlHttp.responseXML;
//其他代码
//别忘记销毁，防止内存泄漏
var span = document.createElement(&span&);
span.innerHTML = states[xmlHttp.readyState];
document.body.appendChild(span);
结果如下：
正在初始化请求&&成功！正在发送请求&&成功！正在接收数据&&完成！正在解析数据&&完成！
我们很容易明白XMLHttpRequest对象在各个阶段都在做什么。因此，也就很容易对Ajax的核心部分有一个真正简单明了的理解。
介绍一下，为什么要写《软件框架设计的艺术》？
原因很多。在动笔之前，我也时不时地会产生写本书的冲动。但真正促使我下决心写书，还是在一次家庭聚会上。我当时跟表弟谈到想写一本书，他问我：&既然你知道一些别人不知道的东西，也有那么多写书的素材，连出版社都是现成的&&，那你还犹豫什么呢？这样不对啊，赶紧写吧！&于是，我决定联系一家合适的出版社，写作和出版这本书。
说说这本书吧。什么是API，准确地说？
&准确地说？&好吧，API就是沟通。你可能会感到意外，我说的沟通不是指开发人员与计算机之间的沟通，而是人与人之间的对话。正因为如此，&什么是API&这个问题才会有各种各样的答案。一切有助于开发人员之间沟通的东西，都可以或者说都应该称为API，比如数据库的结构、硬盘里保存文件的路径、文件的内容、应用程序监听的端口，以及服务器的URL，等等。&
那这本书的读者对象就是那些设计API的人了？
这本书适合所有希望跟其他人对话的开发人员。不用说，只要是编写代码并需要与团队其他成员共享代码的程序员，都有必要看一看这本书。我把这本书分成三在部分。第一部分介绍一些与API有关的面上的知识，包括API相关的术语及评价其质量的方法和标准。接下来的部分进入实战，讨论了不同的API设计模式。最后一部分更进一步，展示了前两部分的建议在实际中的应用、如何组织API设计团队的工作，以及需要在哪些问题前作出妥协。除了这三部分，书前书后的前言和后记为这三部分提供了背景和上下文。
读者看了这本书能学习到什么？
我以前一位领导常说：&正确的决断源于经验，而经验源于错误的决断。&我相信，从这个意义上说，NetBeans 团队已经掌握了非常高的API设计技术。然而技术虽高明，却不是什么魔法。我们能对API设计有这样深刻的认识，完全是因为10年来犯过了许许多多的错误。读者通过看这本书，有可能会避免重犯我们犯过的错误，提高自己在设计API时的决断力。
能不能通过一个例子展示一两个建议？
一两个建议还真是很难给，因为这样很容易让人觉得这两个建议比其他建议更重要，搞清楚这两个建议就万事大吉了。所以，我给不出两个这样的&魔法&建议。
不过，如果必须要找两个结论讲一讲，我可以推荐下面这两个：
&API的第一个版本绝对不会完美&
&不可能知道使用你的库的所有人&
这两个结论道出了构建带有API的库和构建内部系统之间的根本差异。API就像是星星， 一旦被人发现，就要永远悬挂在苍穹，发出永恒的光辉。星星不能突然无缘无故地从人们的视野中消失。如果一个库随便跟用户玩消失，你的信誉何在？这违背了正确设计的规则。库应该根据API设计领域的规则不断地改进。
你希望本书读者通过这本书获得哪些知识？
各个方面的知识，我在书中讨论的都是广义的API设计命题。我相信，这些话题触及了任何API设计的本质，对开发现代软件至关重要。但大家对这个问题的重视程度还远远不够，对设计API与设计常规的内部系统有什么区别也没有认识到位。欢迎大家访问，跟我和其他人分享自己的经验。
我注意到，越来越多的（主要的）开源库需要更多开发人员。我希望能够为所有这些框架的维护人员节省一点时间，让他们不要再重蹈我们的覆辙。希望大家积极地分享经验，而且都能使用切实有效的工作方法。这样，才能开发出更好的库，只有开发出更好的库，才能在它们基础上构建出更好的应用。
最后，我想再强调一下，前面提到的一个人不可能预知所有用户这个结论是很重要的。即使是开发内部系统，即使你真的知道所有用户， 这个结论也是非常有用的。从编写代码之初就准备好应对未来的变化，可以为将来发布新版本避免很多麻烦。对于那些30几个人或更多人组成的开发团队来说，本书讨论的API设计方法绝对是非常有用的。
谈谈写这本书的感受？花了多长时间？你觉得写书是一件好玩的事吗？
写这本书的素材我已经收集了10年之久了，因此我知道这本书绝不可能在短时间内写完。自从去年夏天，我表弟促使我下定决心之后，写这本书大概花了整整一年时间，包括整理笔记和修改润色。我很欣慰，现在，过了一年，这本书已经上市了，在此我想感谢所有帮我把出书这件事做成的人。如果大家想知道都有谁，可以看看这里：。
对其他想写编程类图书的作者，你有什么建议？
我发现很多讲编程的书没有使用语法高亮。比如，关键字没有加粗，运算符和字符串与常规的文本也没有区别。虽然是意外发现这个问题，但这让我思考怎么在自己书里的代码示例中加点&高亮&。做到这一点不容易，因为出版社还没有注意到这个问题，也没有什么现成的解决方案。不过，我相信我们最终成功了。本书中所有代码的&颜色&是灰色，这样至少要好一点，而且读者看起来也会感觉更自然。我的建议是：如果你想写编程方面的书，别忘了也给自己的代码示例加点&颜色&。
还有其他话想对大家说吗？
分享！我是说，大家一起分享。我自认为对设计API有一定的研究，但同时我也深知，我对设计API仍然还是知之甚少。如何设计API，还需要大家共同探索，希望大家踊跃加入我们的发现之旅。如果你有什么提示、建议、想法、模式，欢迎到发表。大家需要这些知识让将来的软件开发更简单，也更可靠。
????????"？还记得HTTP中的Accept-Charset、Accept-Encoding、Accept-Language、Content-Encoding、Content-Language等消息头字段？这些就是接下来我们要探讨的。
1.基础知识
计算机中储存的信息都是用二进制数表示的；而我们在屏幕上看到的英文、汉字等字符是二进制数转换之后的结果。通俗的说，按照何种规则将字符存储在计算机中，如'a'用什么表示，称为"编码"；反之，将存储在计算机中的二进制数解析显示出来，称为"解码"，如同密码学中的加密和解密。在解码过程中，如果使用了错误的解码规则，则导致'a'解析成'b'或者乱码。
字符集（Charset）：是一个系统支持的所有抽象字符的集合。字符是各种文字和符号的总称，包括各国家文字、标点符号、图形符号、数字等。
字符编码（Character Encoding）：是一套法则，使用该法则能够对自然语言的字符的一个集合（如字母表或音节表），与其他东西的一个集合（如号码或电脉冲）进行配对。即在符号集合与数字系统之间建立对应关系，它是信息处理的一项基本技术。通常人们用符号集合（一般情况下就是文字）来表达信息。而以计算机为基础的信息处理系统则是利用元件（硬件）不同状态的组合来存储和处理信息的。元件不同状态的组合能代表数字系统的数字，因此字符编码就是将符号转换为计算机可以接受的数字系统的数，称为数字代码。
2.常用字符集和字符编码
常见字符集名称：ASCII字符集、GB2312字符集、BIG5字符集、GB18030字符集、Unicode字符集等。计算机要准确的处理各种字符集文字，需要进行字符编码，以便计算机能够识别和存储各种文字。
2.1. ASCII字符集&编码
ASCII（American&Standard&Code for&Information&Interchange，美国信息交换标准代码）是基于的一套系统。它主要用于显示，而其扩展版本EASCII则可以勉强显示其他。它是现今最通用的单编码系统（但是有被Unicode追上的迹象），并等同于国际标准ISO/IEC 646。&
ASCII字符集：主要包括控制字符（回车键、退格、换行键等）；可显示字符（英文大小写字符、阿拉伯数字和西文符号）。
ASCII编码：将ASCII字符集转换为计算机可以接受的数字系统的数的规则。使用7位（bits）表示一个字符，共128字符；但是7位编码的字符集只能支持128个字符，为了表示更多的常用字符对ASCII进行了扩展，ASCII扩展字符集使用8位（bits）表示一个字符，共256字符。ASCII字符集映射到数字编码规则如下图所示：
图1 ASCII编码表
图2 扩展ASCII编码表
ASCII的最大缺点是只能显示26个基本拉丁字母、阿拉伯数目字和英式标点符号，因此只能用于显示现代美国英语（而且在处理英语当中的外来词如na&ve、caf&、&lite等等时，所有重音符号都不得不去掉，即使这样做会违反拼写规则）。而EASCII虽然解决了部份西欧语言的显示问题，但对更多其他语言依然无能为力。因此现在的苹果电脑已经抛弃ASCII而转用。
2.2. GBXXXX字符集&编码
计算机发明之处及后面很长一段时间，只用应用于美国及西方一些发达国家，ASCII能够很好满足用户的需求。但是当天朝也有了计算机之后，为了显示中文，必须设计一套编码规则用于将汉字转换为计算机可以接受的数字系统的数。
天朝专家把那些127号之后的奇异符号们（即EASCII）取消掉，规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（他称之为高字节）从0xA1用到 0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。在这些编码里，还把数学符号、罗马希腊的 字母、日文的假名们都编进去了，连在ASCII里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的"全角"字符，而原来在127号以下的那些就叫"半角"字符了。
上述编码规则就是GB2312。GB2312或GB2312-80是，全称《信息交换用汉字编码字符集&基本集》，又称，由发布，实施。GB2312编码通行于中国大陆；等地也采用此编码。中国大陆几乎所有的中文系统和国际化的软件都支持GB2312。GB2312的出现，基本满足了汉字的计算机处理需要，它所收录的汉字已经覆盖中国大陆99.75%的使用频率。对于、等方面出现的，GB2312不能处理，这导致了后来及汉字字符集的出现。下图是GB2312编码的开始部分（由于其非常庞大，只列举开始部分，具体可查看）：
图3 GB2312编码表的开始部分
由于只收录6763个汉字，有不少汉字，如部分在GB 2312-80推出以后才简化的汉字（如"啰"），部分人名用字（如中国前总理的"镕"字），台湾及香港使用的，及汉字等，并未有收录在内。于是厂商微软利用GB 2312-80未使用的编码空间，收录GB 全部字符制定了GBK编码。根据资料，GBK是对GB2312-80的扩展，也就是字码表 (Code Page 936)的扩展（之前CP936和GB 2312-80一模一样），最早实现于简体中文版。虽然GBK收录的全部字符，但编码方式并不相同。GBK自身并非国家标准，只是曾由标准化司、科技与质量监督司公布为"技术规范指导性文件"。原始GB13000一直未被业界采用，后续国家标准技术上兼容GBK而非GB13000。
GB 18030，全称：GB 《信息技术 中文编码字符集》，是现时最新的内码字集，是GB 《信息技术 信息交换用汉字编码字符集 基本集的扩充》的修订版。与完全兼容，与基本兼容，支持及的全部统一汉字，共收录汉字70244个。GB 18030主要有以下特点：
与相同，采用多编码，每个字可以由1个、2个或4个字节组成。
编码空间庞大，最多可定义161万个字符。
支持中国国内的文字，不需要动用造字区。
汉字收录范围包含繁体汉字以及日韩汉字
图4 GB18030编码总体结构
本规格的初版使中华人民共和国信息产业部电子工业标准化研究所起草，由国家质量技术监督局于发布。现行版本为国家质量监督检验总局和中国国家标准化管理委员会于发布，实施。此规格为在中国境内所有软件产品支持的强制规格。
2.3. BIG5字符集&编码
Big5，又称为大五码或五大码，是使用（正体中文）社区中最常用的电脑标准，共收录13,060个汉字。中文码分为及两类，Big5属中文内码，知名的中文交换码有、。Big5虽普及于、与等繁体中文通行区，但长期以来并非当地的国家标准，而只是。、等主要系统的字符集都是以Big5为基准，但厂商又各自增加不同的造字与造字区，派生成多种不同版本。，Big5被收录到CNS11643中文标准交换码的附录当中，取得了较正式的地位。这个最新版本被称为Big5-2003。
Big5码是一套，使用了双八码存储方法，以两个字节来安放一个字。第一个字节称为"高位字节"，第二个字节称为"低位字节"。"高位字节"使用了0x81-0xFE，"低位字节"使用了0x40-0x7E，及0xA1-0xFE。在Big5的分区中：&
保留给用户自定义字符（区）
0xA140-0xA3BF
、希腊字母及特殊符号，包括在0xA259-0xA261，安放了九个计量用汉字：兙兛兞兝兡兣嗧瓩糎。
0xA3C0-0xA3FE
保留。此区没有开放作造字区用。
0xA440-0xC67E
，先按笔划再按部首排序。
0xC6A1-0xC8FE
保留给用户自定义字符（造字区）
0xC940-0xF9D5
，亦是先按笔划再按部首排序。
0xF9D6-0xFEFE
保留给用户自定义字符（造字区）
Unicode字符集&UTF编码
3.伟大的创想Unicode
&&不得不单独说Unicode
像天朝一样，当计算机传到世界各个国家时，为了适合当地语言和字符，设计和实现类似GB232/GBK/GB18030/BIG5的编码方案。这样各搞一套，在本地使用没有问题，一旦出现在网络中，由于不兼容，互相访问就出现了乱码现象。
为了解决这个问题，一个伟大的创想产生了&&Unicode。Unicode编码系统为表达任意语言的任意字符而设计。它使用4字节的数字来表达每个字母、符号，或者表意文字(ideograph)。每个数字代表唯一的至少在某种语言中使用的符号。（并不是所有的数字都用上了，但是总数已经超过了65535，所以2个字节的数字是不够用的。）被几种语言共用的字符通常使用相同的数字来编码，除非存在一个在理的语源学(etymological)理由使不这样做。不考虑这种情况的话，每个字符对应一个数字，每个数字对应一个字符。即不存在二义性。不再需要记录"模式"了。U+0041总是代表'A'，即使这种语言没有'A'这个字符。
在领域中，Unicode（统一码、万国码、单一码、标准万国码）是业界的一种标准，它可以使电脑得以体现世界上数十种文字的系统。Unicode 是基于（Universal Character Set）的标准来发展，并且同时也以书本的形式对外发表。Unicode 还不断在扩增， 每个新版本插入更多新的字符。直至目前为止的第六版，Unicode 就已经包含了超过十万个（在，Unicode 的第十万个字符被采纳且认可成为标准之一）、一组可用以作为视觉参考的代码图表、一套编码方法与一组标准、一套包含了上标字、下标字等字符特性的枚举等。Unicode 组织（The Unicode Consortium）是由一个非营利性的机构所运作，并主导 Unicode 的后续发展，其目标在于：将既有的字符编码方案以Unicode 编码方案来加以取代，特别是既有的方案在多语环境下，皆仅有有限的空间以及不兼容的问题。
（可以这样理解：Unicode是字符集，UTF-32/ UTF-16/ UTF-8是三种字符编码方案。）
3.1.UCS & UNICODE
通用字符集（Universal Character Set，UCS）是由制定的ISO 10646（或称ISO/IEC 10646）标准所定义的标准字符集。历史上存在两个独立的尝试创立单一字符集的组织，即国际标准化组织（ISO）和多语言软件制造商组成的。前者开发的 ISO/IEC 10646 项目，后者开发的项目。因此最初制定了不同的标准。
前后，两个项目的参与者都认识到，世界不需要两个不兼容的字符集。于是，它们开始合并双方的工作成果，并为创立一个单一编码表而协同工作。从Unicode 2.0开始，Unicode采用了与ISO 10646-1相同的字库和字码；ISO也承诺，ISO 10646将不会替超出U+10FFFF的UCS-4编码赋值，以使得两者保持一致。两个项目仍都存在，并独立地公布各自的标准。但统一码联盟和ISO/IEC JTC1/SC2都同意保持两者标准的码表兼容，并紧密地共同调整任何未来的扩展。在发布的时候，Unicode一般都会采用有关字码最常见的字型，但ISO 10646一般都尽可能采用。
3.2.UTF-32
上述使用4字节的数字来表达每个字母、符号，或者表意文字(ideograph)，每个数字代表唯一的至少在某种语言中使用的符号的编码方案，称为UTF-32。UTF-32又称UCS-4是一种将字符编码的协定，对每个字符都使用4字节。就空间而言，是非常没有效率的。
这种方法有其优点，最重要的一点就是可以在常数时间内定位字符串里的第N个字符，因为第N个字符从第4&Nth个字节开始。虽然每一个码位使用固定长定的字节看似方便，它并不如其它Unicode编码使用得广泛。
3.3.UTF-16
尽管有Unicode字符非常多，但是实际上大多数人不会用到超过前65535个以外的字符。因此，就有了另外一种Unicode编码方式，叫做UTF-16(因为16位 = 2字节)。UTF-16将0&65535范围内的字符编码成2个字节，如果真的需要表达那些很少使用的"星芒层(astral plane)"内超过这65535范围的Unicode字符，则需要使用一些诡异的技巧来实现。UTF-16编码最明显的优点是它在空间效率上比UTF-32高两倍，因为每个字符只需要2个字节来存储（除去65535范围以外的），而不是UTF-32中的4个字节。并且，如果我们假设某个字符串不包含任何星芒层中的字符，那么我们依然可以在常数时间内找到其中的第N个字符，直到它不成立为止这总是一个不错的推断。其编码方法是：
如果字符编码U小于0x10000，也就是十进制的0到65535之内，则直接使用两字节表示；
如果字符编码U大于0x10000，由于UNICODE编码范围最大为0x10FFFF，从0x1FFFF之间 共有0xFFFFF个编码，也就是需要20个bit就可以标示这些编码。用U'表示从0-0xFFFFF之间的值，将其前 10 bit作为高位和16 bit的数值0xD800进行 逻辑or 操作，将后10 bit作为低位和0xDC00做 逻辑or 操作，这样组成的 4个byte就构成了U的编码。
对于UTF-32和UTF-16编码方式还有一些其他不明显的缺点。不同的计算机系统会以不同的顺序保存字节。这意味着字符U+4E2D在UTF-16编码方式下可能被保存为4E 2D或者2D 4E，这取决于该系统使用的是大尾端(big-endian)还是小尾端(little-endian)。（对于UTF-32编码方式，则有更多种可能的字节排列。）只要文档没有离开你的计算机，它还是安全的&&同一台电脑上的不同程序使用相同的字节顺序(byte order)。但是当我们需要在系统之间传输这个文档的时候，也许在万维网中，我们就需要一种方法来指示当前我们的字节是怎样存储的。不然的话，接收文档的计算机就无法知道这两个字节4E 2D表达的到底是U+4E2D还是U+2D4E。
为了解决这个问题，多字节的Unicode编码方式定义了一个"字节顺序标记(Byte Order Mark)"，它是一个特殊的非打印字符，你可以把它包含在文档的开头来指示你所使用的字节顺序。对于UTF-16，字节顺序标记是U+FEFF。如果收到一个以字节FF FE开头的UTF-16编码的文档，你就能确定它的字节顺序是单向的(one way)的了；如果它以FE FF开头，则可以确定字节顺序反向了。
UTF-8（8-bit Unicode Transformation Format）是一种针对的可变长度（），也是一种。它可以用来表示Unicode标准中的任何字符，且其编码中的第一个仍与兼容，这使得原来处理ASCII字符的无须或只须做少部份修改，即可继续使用。因此，它逐渐成为、及其他或传送文字的应用中，优先采用的编码。（IETF）要求所有都必须支持UTF-8编码。
UTF-8使用一至四个为每个字符编码：
128个US-ASCII字符只需一个字节编码（Unicode范围由U+0000至U+007F）。
带有的、、、、、、及则需要二个字节编码（Unicode范围由U+0080至U+07FF）。
其他（BMP）中的字符（这包含了大部分常用字）使用三个字节编码。
其他极少使用的Unicode的字符使用四字节编码。
在处理经常会用到的ASCII字符方面非常有效。在处理扩展的拉丁字符集方面也不比UTF-16差。对于中文字符来说，比UTF-32要好。同时，（在这一条上你得相信我，因为我不打算给你展示它的数学原理。）由位操作的天性使然，使用UTF-8不再存在字节顺序的问题了。一份以utf-8编码的文档在不同的计算机之间是一样的比特流。
总体来说，在Unicode字符串中不可能由码点数量决定显示它所需要的长度，或者显示字符串之后在文本缓冲区中光标应该放置的位置；组合字符、变宽字体、不可打印字符和从右至左的文字都是其归因。所以尽管在UTF-8字符串中字符数量与码点数量的关系比UTF-32更为复杂，在实际中很少会遇到有不同的情形。
UTF-8是ASCII的一个。因为一个纯ASCII字符串也是一个合法的UTF-8字符串，所以现存的ASCII文本不需要转换。为传统的扩展ASCII字符集设计的软件通常可以不经修改或很少修改就能与UTF-8一起使用。
使用标准的面向字节的排序例程对UTF-8排序将产生与基于Unicode代码点排序相同的结果。（尽管这只有有限的有用性，因为在任何特定语言或文化下都不太可能有仍可接受的文字排列顺序。）
UTF-8和UTF-16都是文档的标准编码。所有其它编码都必须通过显式或文本声明来指定。
任何的都可以用于UTF-8的数据（只要输入仅由完整的UTF-8字符组成）。但是，对于包含字符记数的正则表达式或其它结构必须小心。
UTF-8字符串可以由一个简单的算法可靠地识别出来。就是，一个字符串在任何其它编码中表现为合法的UTF-8的可能性很低，并随字符串长度增长而减小。举例说，字符值C0,C1,F5至FF从来没有出现。为了更好的可靠性，可以使用正则表达式来统计非法过长和替代值（可以查看上的验证UTF-8字符串的正则表达式）。
因为每个字符使用不同数量的字节编码，所以寻找串中第N个字符是一个O(N)复杂度的操作 & 即，串越长，则需要更多的时间来定位特定的字符。同时，还需要位变换来把字符编码成字节，把字节解码成字符。
4.Accept-Charset/Accept-Encoding/Accept-Language/Content-Type/Content-Encoding/Content-Language
在HTTP中，与字符集和字符编码相关的消息头是Accept-Charset/Content-Type，另外主区区分Accept-Charset/Accept-Encoding/Accept-Language/Content-Type/Content-Encoding/Content-Language：
Accept-Charset：浏览器申明自己接收的字符集，这就是本文前面介绍的各种字符集和字符编码，如gb2312，utf-8（通常我们说Charset包括了相应的字符编码方案）；
Accept-Encoding：浏览器申明自己接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate），（注意：这不是只字符编码）；
Accept-Language：浏览器申明自己接收的语言。语言跟字符集的区别：中文是语言，中文有多种字符集，比如big5，gb2312，gbk等等；
Content-Type：WEB服务器告诉浏览器自己响应的对象的类型和字符集。例如：Content-Type: text/ charset='gb2312'
Content-Encoding：WEB服务器表明自己使用了什么压缩方法（gzip，deflate）压缩响应中的对象。例如：Content-Encoding：gzip
Content-Language：WEB服务器告诉浏览器自己响应的对象的语言。
参考文献&进一步阅读
百度百科. 字符集.&,
维基百科. 字符编码.&,
维基百科. ASCII.&,
维基百科. GB2312.&,
维基百科. GB18030.&,
维基百科. GBK.&,
维基百科. Unicode.&,
Laruence. 字符编码详解(基础).&,
Jan Hunt. Character Sets and Encoding for Web Designers - UCS/UNICODE.&
作者：吴秦出处：/skynet/本文基于许可协议发布，欢迎转载，演绎或用于商业目的，但是必须保留本文的署名（包含链接）.
那日，我与一友人漫步。他资质过人，少言寡欲, 刚二十出头。
他经常问我应该怎么走程序员这条路。
我不是什么大师，但仗键(盘)游走江湖已有数十载，吃过不少苦头。自以为不敢说到达了洪七公那种级别，但离江南七怪应该距离不远了。（注：洪七公和江南七怪都是郭靖的师父）
我闭目沉思，悟空（七龙珠版），青铜圣斗士，健次郎（北斗神拳），郭靖（射雕），段誉和乔峰（天龙八部）等历史著名斗士冲入我的空间，我提指在 iphone 里写下《码斗士的修炼之路》我不是说我做到了这些，只是&路漫漫其修远兮，吾将上下而求索&， 但与大家共勉：
健次郎和悟空的一大特色就是遇强更强，或者说他们善于从对手／朋友学技术。有些程序员怕公司里增加比自己强的同事，也不太愿意和别人分享自己的绝活，这其实恰巧断了自己的一条发展之路。
千万不要担心能力强的同事抢了你的饭碗，你的敌意和警惕性不仅让你树敌还减少了你从他那里学到你所需要的东西。&当可怕的沙鲁出现的时候，小林问悟空：&当比弗利沙更强的敌人出现的时候，你是害怕还是高兴。& 悟空的回答是：&两者都有& -- 标准斗士的好强心态！ 悟空的另外一个名言就是：&你真的很强, 我很兴奋！&
斗士们在某一个阶段身边会不断的冒出比他强大的，因此他们不一定是生下来就立于最高点。青铜圣斗士开始连白银圣斗士都比不上，黄金圣斗士基本上都不屑于与在他们过招，但是他们居然一路杀将过来，晋升为最高级别的神斗士。
斗士们的大环境永远不变，变的只是故事。不要抱怨微软或谷歌又更新API或者开发工具，有新的知识出现，给更年轻的程序员超过你的机会。你必须面对逆水行舟的事实。&放弃追求单一的公平，对于这种环境斗士们只能不断进步，这就是造就斗士个性的过程。
没有龟仙人和界王神就没有超级赛亚人；没有九指神丐就没有郭大侠。想快速了解好的软件架构？想掌握网站开发的动态？找到一个专家就至少省你一个月修炼的时间。名师可遇不可求，有几个人好运可以遇到名师呢？像段誉一样走运的人不多，像乔峰一样不走运的人也不多。
&三人行，必有我师&--多开口，多问 -- 锻炼了你与人交流的能力，对身体也有好处。
有一种能力会让你永葆青春--自学的能力。&这一能力可以培养，且应该非常重视这方面能力的培养和不断强化。&没有名师的指引，自学能力就尤为重要了。所以不要害怕新的事物，尝试去了解它，通过各种渠道获得信息并自我归纳。
有时我们可以把这种能力称为：&悟性& -- 观察，收集，融会贯通，像健次郎练成无相转身；像悟空练成龟波气功和舞空术。
淡薄名誉, 简单的生活，专注于自己的修行，宁静以致远 -- 似乎没有什么能够阻止斗士们向上的决心, 他们时刻保持一种纯真，这一点在乔峰和健次郎身上化成了豪气和超凡的情怀。
青铜圣斗士们对名著的大牛们的敬仰和有时傻乎乎的言论不会让他们以后的光芒减少。-- 标准斗士的单纯心态！&贝吉塔第一次以超级赛亚人露面时说&我静下来了，完完全全静下来了。&
悟空的纯洁无瑕的心也让他可以毫不费力的宁静下来。
不要轻易为身边花花世界所动，否则你一生追求名利，反而适得其反。
不要给自己画上Mircosoft / Linux , dotnet,Csharp 等栅栏。&学什么？Java? C++? C#? php? -- 其实你可以先找项目，不要太在乎你对哪个公司更有信心。-- 有时三年河东，三年河西，技术的更新，编程思想的进步会让你眼花缭乱。关键是你要开始学一样，然后尽量的深入。等到你比较好的掌握一样，你会发现路会越来越宽。
要精通一样，但是不能只精通一样。否则你会处于非常危险的境地，让自己缺少选择。
试试开发一个小的iphone程序，或在android摸索几天，会让你消除对它们的陌生感。
我不是让你什么都学，而是说不要太在乎门派之争。
当悟空情急之下使出&太阳拳&的时候，救了整个宇宙。
终极的演变就是掌握北冥神功的段誉：引世人之内力而为己用，取百川而汇海。 -- 世上有几位码斗士能一览众山小呢？
纵观古今中外著名漫画小说连续剧，哪位斗士在死亡线上走过一遭（否则也没有收视率了）&平静的水面锻炼不了精干的水手，安逸的生活出不了时代的伟人，轻松的政府部门里打造不出码斗士。&没有经历过连夜赶工，系统出错救火，维护多年老代码就体会不到代码重用，代码整洁，代码管理和项目架构的精神。&&当别人有不同意见是，你会有自己的笃定，因为你经历过血海的洗礼。
赛亚人的特点之一：死而复活之后，能力暴增；圣斗士们也是在生死边缘不断升级。
不要因为害怕承担责任而将升级的机会放弃掉 -- 现实生活中的码斗士大不了就是被炒鱿鱼（，或者被公司保安追杀？）
参考资料：七龙珠 圣斗士 北斗神拳 射雕英雄传 天龙八部
本文来自于&转贴请注明出处