发布时间：2012-12-23 20:50:52

介绍HTTP Live Streaming的标准课程http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html......【阅读全文】

发布时间：2012-12-23 20:46:30

刚刚看到一篇文章, "敏捷不是为所有人准备的",作者Johnanna, 下面简单翻译一段,...You don’t have to change the culture on Day One. But you do have to change eventually. And starting with the team is a good start. If the team can’t get to continuous integration and small-enough stories to move to two-week iterations, maybe agile is n......【阅读全文】

发布时间：2012-12-23 20:44:07

  完成一个项目或者一个特性相关的开发工作，对于软件工程 师来说就如履行一份合同或者一份契约和承诺。涉及的甲乙双方应该都对合同所涉及的工作、完成日期以及报酬达成一致意见。如果甲方（通常是客户或者是领导）将合同强加给乙方（通常是软件开发团队或者软件工程师），那么在开发工作开始之前就埋下了项目失败的隐患，这时软件工程师是以被动接受的心态开始具体工作的。对于大多数人来说，这往往表现为一种抵触的情绪，进而表现为消极代工，不主动承担责任。也许这低估了工程师们的职业素养，姑且不说心态的影响，那么强加到工程师头上的工作多是讨论不够充分，需求不够清晰的，如果是在充分讨论需求识别风险的情况，那往往是领......【阅读全文】

发布时间：2012-12-23 20:41:32

         “在这个迭代周期就快封版之前，team leader Alice询问特性A是否可以按时提交版本发布，软件工程师Bob回答说已经完成90%，应该可以发布特性。”这样的场景恐怕很多软件开发人员（包括项目经理和软件工程师）都经历过。        已经完成90%的特性似乎距离发布就差百米赛跑的最后10米了，软件工程师似乎再喘口气就能将特性完成了。但实际情况究竟怎么样呢？似乎Bob很有信心，很有把握，特性发布不成问题，这将是最好的结果了。然而最后往往是不遂人意，Bob在封版前找到Alice，代码......【阅读全文】

发布时间：2012-12-23 20:39:28

使用有意义的名字，名字明确了用途，不用更多注释。有时错误的注释会更坏事，即使现在正确，但随着时间的推移，注释和代码多半已经不能对应了。别让名字掺杂有现有数据类型名字，有时会让人误解。也不要使用很难区分差别的名字。使用有意义的名字，别使用0和O，l和1，谁看谁晕。要从名字区分出意义的不同。名字不要包含多余的成分，多个名字之间意义区别明确，一看就知道用哪个，这也有助于写出简洁的代码。名称能够读出来，这有助于讨论交流。名称明确可读有助于代码review。名称的长度应该和其作用域大小成正比，越短的名字使用的范围应该越小，诸如i，i，j， k这样的名字不适合扩大其作用域，限制到越小约好。不使用匈牙利命名......【阅读全文】