在kernel编程里面，会经常提到执行上下文（execution context），一般有中断上下文，软中断上下文和进程上下文。在不同的context里面，有不同的限制，比如在中断上下文中分配内存不能有阻塞，比如在多CPU环境里面，要使用atomic access等。程序在哪个上下文中执行，在编译的时候是没法检查出来的，这是动态的，所以很多时候，靠代码review很难发现这类错误。有几个解决办法，一是不同上下文里面用的api完全分开，相互独立，这样做的好处是避免误用，坏处是api的实现大部分是相同的；而是在运行时检查是在哪个context中执行，然后调用不同的api，这样做的坏处是有很多这样的检查会影响程序的性能。最好的办法是在写代码时就能够知道自己的程序在哪个context执行，调用正确的api，当然这对写程序的人要求稍高了一点。

这里有两层含义：
1）写函数的时候，尽量有返回值，最好不要把返回值从参数里面带出来，这样也不利于检查。
2）调用函数时，要检查返回值，这是protection programming的策略，为了避免出错，最好把每个错误都检查一下。如果已经是返回错误了，还继续执行，就会导致其他的风险。当你碰到一些莫名其妙的内存错误时，查一查自己的程序有没有检查了malloc的返回值。在free后，最好把指针置为初始值，避免再次用的时候，没有检查。

Cloud computing的几个不同的视角：

1）cloud is a service
Infrastructure: infrastructure包括，服务器，计算资源；网络，VPN网络资源；存储，存储资源；操作系统；管理系统

Platform：Web, application, database等服务器

Application：比如search, Email, CRM等应用，视频，相册等等

Security: 基本的安全服务和高级安全服务

2）cloud computing 可以是

高效：相同的硬件可以支持多个virtual service，按需分配资源，按workload分配资源，资源管理自动化，用户可以租用服务，用户的load是可预测的，如果不能预测，也应该很容易扩展。

可扩展：资源很容易扩展，与原来的资源可以集成，不会影响原有的服务。

网络和安全分离，可以关注自己所能做的事。

有了cloud computing的平台，用户的程序应该如何设计？比如load balancing由谁负责？High availability由谁负责？编程的时候，能否假设资源是无限的？要不要考虑程序是在一个box上，还是多个box上运行；是在一个cpu还是多个cpu上运行？基于web或者internet的编程模型完全不同于基于pc的编程模型。API由谁来提供，framework由谁来提供？PHP,java,c#还是.net? 或者是SOA？
如果能够提供cloud computing的平台，那么以后的分工就会更加精细，写web的还需要考虑操作系统的知识吗？操作系统的知识对优化web程序还有没有帮助？
以后是rich client还是rich server？在cloud computing的环境里面，client的工作越来越少，这对于microsoft这样的destop厂商，有更大的威胁吧。

bit field在本地用是没问题的，但是如果在网络message里面用，就会涉及到endian的问题，转换起来麻烦，所以建议在网络message里面最好不要用bit field。
还有就是gcc的extension/macro在程序里面也少用，最好用标准的c语言，这样在更换编译器时也能避免麻烦，虽然一般情况下大家是不会换编译器的。就像c++编程，大家一般都推荐用标准规定的东西，用一个最小集合，许多很炫，很fancy的功能，虽然看起来很爽，但是对移植有危害，而且程序也很难读。
想java/c#这样的语言，语言很规范，能用什么，不能用什么，有明确的东西，也不会出现各式各样的程序，这样的语言对写程序和读程序的人都要好处。

前几天，从公司总部来的领导给我们讲公司的mission和values，美国人，用英语讲的都是一些非技术的话题，而且是有关公司战略和文化的部分，我不知道是不是所有的人都听明白了，总之我是虽然听明白了，但是没什么感觉，也就是说，这种宣讲并不能打动人。
现在国际大公司在中国，除了payment是local的外，其他的都是global的。导致local也没什么文化，也没什么可以讲的东西。特别是engineering team，不闻窗外事，只一心一意写好代码。
Sales team不知道是不是local做的好，比如在中国卖东西，关系和路子是少不了的，但相信在美国也是一样，所以这些美国sales和中国sales在一起，是不是也能聊出来点共同话题哪。在中国有很大部门的外企，比如motorola，中国人能说一点话吧，其他的，在中国只有研发中心公司，相对来说，对整体影响了可以忽略为零。

我们经常会遇到这种情况：

      object1 --> object3
                   ^
                   |
     object2 ------+

在object1和object2里面保存object3的指针。如果object3被释放了。
object1和object2再引用object3就会出错。
有几种办法来解决这个问题
1）reference count，这是最经典和有效的办法，如果reference count不是0，就不能释放。当然，如果没用好，就会出现memory leak等等问题。
2）reference list, object3有反向的reference list来track所有指向它的object，在释放object3之前，先把reference清空。
3）Add object3 to object1,object2，使得object1,2,3有相同的生命周期和state，当然这个方案不够好。
4）object3里有signature或者state，在释放时，修改signature或state，但是不能立即释放，等所有的reference解除之后，才能释放。

最好的办法就是在object上加state和reference count或者在object里面引用local object而不是global object，让object成为一个整体。这些在设计的时候要先考虑清楚。

写程序的时候，有些人喜欢写了一大段代码之后再调试；而我喜欢的是写小段，调试，运行，能够正确运行之后，再往下走。这就好比做饭，有些人喜欢把锅碗瓢盆都放到灶台上，干净的，脏的堆在一起，最后再收拾；而我喜欢随时收拾，把脏的尽快洗干净收起来，用的时候再拿出来，这样，到把饭做完，灶台上也不会有多少东西，总是保持整洁。

写大段的代码，如果一开始思路就是错的，后来再改，花费的时间更多；不如一开始就保持正确，整洁，避免过多的ifdef和comment out，小步快跑，而不是一步登天。

这就是一个积累的过程，一个正确的小步骤，比一个未知的大步骤有效的多，保守一点，这样才能避免犯错。

按照wiki的定义http://en.wikipedia.org/wiki/Software_framework，software framework有以下特性

1）inversion of control: 控制反转。也就是程序的流程不是由framework之上的software决定的，而是有framework决定。比如什么时候初始化，什么时候退出，接收什么样的事件，返回什么样的值等等。

2）default behavior：framework一般都提供自动生成代码的功能，这些自动生成的代码就是缺省的行为。用户可以修改这些行为，比如在收到某个事件时，应该做什么事。

3）extensibility：用户可以继承和扩展default behavior，并不是要修改framework本身。

4）non-modifiable framework code：用户不应该修改framework的代码。在OO编程环境里面，用户可以继承framework的class，并实现自己的行为。

framework提供了一个编程环境，它会提供Utility，一些类接口，一种编程模式。熟悉一个framework可以减少一些重复的工作，但是也会局限于framework提供的功能。framework提供了一些编程范式，但是它有时并不能覆盖os提供的所有功能。这个时候，需要一些变通。

这里的trace和counter指的不是debug版本的trace和counter, 而是release版本的trace和counter。在用户的production环境里出来问题，你所能依赖的只能是trace和counter了（当然拓扑，packet capture有时也是必须的，这要看支持人员的经验了）。所以，在代码的关键路径上打出trace和记录counter就是一个非常重要的代码基本功。当然，这也不是免费午餐，trace会增加代码的长度，counter会消耗一定的计算资源（特别是在多cpu情况下，每个counter都会打断流水线）。但是，这样的付出是值得的，特别是你在解custom issue的时候。

了解并熟悉系统的trace和counter是快速熟悉系统的捷径，这对解决客户问题也很有帮助。建议把trace和counter打印成手册，经常翻翻看看，就会有收获。

TCP有两个window:
sliding window: 这是对方接收buffer的大小，对方在buffer大小变化的时候更新这个window。
congest window: 本方的发送窗口，控制本方的发送速率。虽然可以发送最多sliding window大小的data，但是在网络拥塞的情况下，发送越多越会加剧拥塞的程度。所以用congest window再加一层控制。congest window在RTT和ACK retransmission时变化。
如何调整sliding window和congest window，在TCP协议里面有很多技巧。因为这两个window是决定TCP的传输性能。
这里有一个很好的文档，可以看看。