奋斗足迹|崔玉松 » 读书笔记

《Rework》

崔玉松 — Thu, 16 Dec 2010 13:58:23 +0000

这本书是近来难得一见的好书，认识字的都应该去读几遍，中文最近也出版了，各大售书网站都可以买到，打完折二十几块钱，非常物有所值，尽管英文版我已经读过，依然忍不住买一本中译本收藏，虽然中译本的名字我觉得很恶俗，这本书和商业思维没有太多的关系，中译本的作者自作聪明的加上这个小标题，有点恶心，另外将rework翻译成“重来”个人觉得也有点欠妥当，还不如不翻译，意思可能会更明确一点。虽然中译本有这样那样的问题，整体来说翻译的不错，不喜欢英文的可以买来看看，鼎力推荐——我本人不会有任何好处

那来的从错误中学习

中国人常说的一句话是：失败是成功他妈。作者引用哈佛商学院的报告证明，失败的创业者再次创业并不比从未创业的人成功的概率更高。有一类人非常明白这个道理，他们有个名字叫VC（风险投资人），VC非常喜欢那些已经或者曾经创业并且干得不错的人，换句话说这些人往往能从VC那里以比较小的代价（损失较小的股份或者少费周折）搞到很多很多的钱用于再次创业或者公司发展。

何必壮大

这个观点有点意思，几乎所有的企业家都想将自己企业做大，富士康的员工超过百万，而作者觉得大未必是最优的，我非常认同作者的观点，我身边就有很多的公司每年几个亿的业务却只有10个左右的员工。公司越大责任就越大，不仅要自己赚钱还要照顾好这些员工，是一个有责任的企业家应该做到的，而不是压榨。如果你不能，那么就尽量提高效率，少招几个人吧，与人与己都是好事。

工作狂

引用里面的几句话：工作狂实际取得的成就并不比正常人高，他们自诩为完美主义者，但这仅仅代表他们浪费了大量的时间去关注次要的细节，而不是推动下一项任务。真正的英雄是早已想出办法、搞定一切，然后回家了。

Start making Something

我们身边总有这样的人在叹息“XXX我早就想到了，只是没有下手，如果当初我干了，现在也亿万富翁了”，这个观点很可笑，你大脑中有创意跟你实际去创建这样的事情一点关系也没有，在你人生中最有意义的使你做了什么，而不是你想过什么、说过什么或者计划过什么

没有时间不是借口

当你拥有某种极其强烈的渴望时，你就能挤出时间来，不管你身上是否还背负着其他的责任，事实上大部分的渴望不是那么强烈，于是他们总是拿没有时间来做借口进行自我保护。如果我不是这样，我今天已经做出了好几个开源作品了。

=====未完待续======

UDP hole punching 翻译

崔玉松 — Sun, 08 Aug 2010 02:30:37 +0000

3.3. UDP hole punching UDP打洞技术
The third technique, and the one of primary interest in this document, is widely known as “UDP Hole Punching.” UDP hole punching relies on the properties of common firewalls and cone NATs to allow appropriately designed peer-to-peer applications to “punch holes” through the middlebox and establish direct connectivity with each other, even when both communicating hosts may lie behind middleboxes. This technique was mentioned briefly in section 5.1 of RFC 3027 [NAT-PROT], and has been informally described elsewhere on the Internet [KEGEL] and used in some recent protocols [TEREDO, ICE]. As the name implies, unfortunately, this technique works reliably only with UDP.

第三种技术，也是这篇文章主要要研究的，就是非常有名的“UDP打洞技术”，UDP打洞技术依赖于由公共防火墙和cone NAT，允许适当的有计划的端对端应用程序通过NAT“打洞”，即使当双方的主机都处于NAT之后。这种技术在 RFC3027 的5.1节[NAT PROT] 中进行了重点介绍，并且在Internet[KEGEL]中进行了非正式的描叙，还应用到了最新的一些协议，例如[TEREDO,ICE]协议中。不过，我们要注意的是，“术”如其名，UDP打洞技术的可靠性全都要依赖于UDP。

We will consider two specific scenarios, and how applications can be designed to handle both of them gracefully. In the first situation, representing the common case, two clients desiring direct peer-to- peer communication reside behind two different NATs. In the second, the two clients actually reside behind the same NAT, but do not necessarily know that they do.

这里将考虑两种典型场景，来介绍连接的双方应用程序如何按照计划的进行通信的，第一种场景，我们假设两个客户端都处于不同的NAT之后；第二种场景，我们假设两个客户端都处于同一个NAT之后，但是它们彼此都不知道(他们在同一个NAT中)。

3.3.1. Peers behind different NATs 处于不同NAT之后的客户端通信

Suppose clients A and B both have private IP addresses and lie behind different network address translators. The peer-to-peer application running on clients A and B and on server S each use UDP port 1234.? A and B have each initiated UDP communication sessions with server S, causing NAT A to assign its own public UDP port 62000 for A’s session with S, and causing NAT B to assign its port 31000 to B’s session with S, respectively.

我们假设 Client A 和 Client B 都拥有自己的私有IP地址，并且都处在不同的NAT之后，端对端的程序运行于 CLIENT A,CLIENT B,S之间，并且它们都开放了UDP端口1234。 CLIENT A和CLIENT B首先分别与S建立通信会话，这时NAT A把它自己的UDP端口62000分配给CLIENT A与S的会话，NAT B也把自己的UDP端口31000分配给CLIENT B与S的会话。如下图所示：

Now suppose that client A wants to establish a UDP communication session directly with client B.? If A simply starts sending UDP messages to B’s public address, 138.76.29.7:31000, then NAT B will typically discard these incoming messages (unless it is a full cone NAT), because the source address and port number does not match those of S, with which the original outgoing session was established. Similarly, if B simply starts sending UDP messages to A’s public address, then NAT A will typically discard these messages.

假如这个时候 CLIENT A 想与 CLIENT B建立一条UDP通信直连，如果 CLIENT A只是简单的发送一个UDP信息到CLIENT B的公网地址138.76.29.7:31000的话，NAT B会不加考虑的将这个信息丢弃（除非NAT B是一个 full cone NAT），因为这个UDP信息中所包含的地址信息，与CLIENT B和服务器S建立连接时存储在NAT B中的服务器S的地址信息不符。同样的，CLIENT B如果做同样的事情，发送的UDP信息也会被 NAT A 丢弃。

Suppose A starts sending UDP messages to B’s public address, however, and simultaneously relays a request through server S to B, asking B to start sending UDP messages to A’s public address.? A’s outgoing messages directed to B’s public address (138.76.29.7:31000) cause NAT A to open up a new communication session between A’s private address and B’s public address. At the same time, B’s messages to A’s public address (155.99.25.11:62000) cause NAT B to open up a new communication session between B’s private address and A’s public address. Once the new UDP sessions have been opened up in each direction, client A and B can communicate with each other directly without further burden on the “introduction” server S.

假如 CLIENT A 开始发送一个 UDP 信息到 CLIENT B 的公网地址上，与此同时，他又通过S中转发送了一个邀请信息给CLIENT B，请求CLIENT B也给CLIENT A发送一个UDP信息到 CLIENT A的公网地址上。这时CLIENT A向CLIENT B的公网IP(138.76.29.7:31000)发送的信息导致 NAT A 打开一个处于 CLIENT A的私有地址和CLIENT B的公网地址之间的新的通信会话，与此同时，NAT B 也打开了一个处于CLIENT B的私有地址和CLIENT A的公网地址(155.99.25.11:62000)之间的新的通信会话。一旦这个新的UDP会话各自向对方打开了，CLIENT A和CLIENT B之间就可以直接通信，而无需S来牵线搭桥了。(这就是所谓的打洞技术)！

The UDP hole punching technique has several useful properties. Once a direct peer-to-peer UDP connection has been established between two clients behind middleboxes, either party on that connection can in turn take over the role of “introducer” and help the other party establish peer-to-peer connections with additional peers, minimizing the load on the initial introduction server S. The application does not need to attempt to detect explicitly what kind of middlebox it is behind, if any [STUN], since the procedure above will establish peer- to-peer communication channels equally well if either or both clients do not happen to be behind a middlebox.? The hole punching technique even works automatically with multiple NATs, where one or both clients are removed from the public Internet via two or more levels of address translation.

UDP打洞技术有很多实用的地方：第一，一旦这种处于NAT之后的端对端的直连建立之后，连接的双方可以轮流担任对方的“媒人”，把对方介绍给其他的客户端，这样就极大的降低了服务器S的工作量；第二，应用程序不用关心这个NAT是属于cone还是symmetric，即便要，如果连接的双方有一方或者双方都恰好不处于NAT之后，基于上叙的步骤，他们之间还是可以建立很好的通信通道；第三，打洞技术能够自动运作在多重NAT之后，不论连接的双方经过多少层NAT才到达Internet，都可以进行通信。

数据库的层次结构

崔玉松 — Mon, 15 Mar 2010 14:01:39 +0000

1、树状结构
在历史上，层次数据库最早出现，将数据库保存为文件中的记录，各种逻辑被嵌套到一起，而没有将同样的记录按照线性排列。层次数据库对某些查询非常适合，但是过强的结构限制了人们对数据的自由操控，后来出现的网络（CODASYL）数据库，虽然灵活了很多，但数据操控仍然很困难，知道关系型理论的出现，才证明的了数据库设计是科学而不是工艺，然而，因为层次模型很有弹性，所以层次结构依然极为常见（至少层次描述非常常见），例如XML和LDAP等层次技术非常活跃，严格的说HTML也算是一种层次存取数据的方式。
层次式数据不太容易理解，比如ERP系统中最基本的物料单，层次结构之所以复杂，主要原因不是因为组件之间的关系表达，而是访问树的方式，我们访问树的部分或全部节点，通常按照顺序返回这些节点，访问树通常由DBMS引擎以过程性方式实现，而过程性操作正是违背关系理论的主要表现之一。
2、树状结构和主从结构
很多人认为“父子关系”和“主从关系”没有什么不同，实际上这两种关系有着很多的不同。
1）树状结构保存只需要一个表。代表层次结构的树，其所有节点完全相同，叶子节点的类型有时可能不同，例如文件系统中的文件夹和文件节点，如果撇去这点，所有的节点类型完全相同，我们可以用相同的方法描述，而且同一个表来代表节点，换句话说，表与它本身之间有种主从关系，而不是两个类型不同的表关系。
2）深度。层次结构中，与根节点的距离本身是重要的信息，而在主从关系中，不是主表就是明细表。
3）所有权。主从关系中，可以明确的外键完整性约束，例如，每个表中订单必须与另外一张表的已存在的ID对应，但层次结构，比如，虽然比如经理的工号虽然是参照已经存在的员工的工号规则来的，但是经理向老板报告，不跟员工报告，这会导致NULL值问题。
4）多重父节点。以父节点似乎别数据结合子节点，是假设一个子节点只有一个父节点，实际上生活中，很多情况下都不是这样，比如机械零件和螺丝钉，那就不是树了，父子关系就无能为力了。
其实某位大牛曾经说过：从关系理论角度去理解树的结构，树有两种实体类型，一个是节点，另一个是节点之间的连接。这样的设计世界上是解决了完整性约束的的问题，因为只有实际存在连结的节点才能被描述。这种描述实际上最后能描出一个图来，也就是能解决一个子节点对应多个父节点的问题。
DBMS厂商常常实现了空间数据处理或全文索引等特殊功能，但对层次结构的支持很薄弱或者根本没有。
处理层次结构的主要困难在于树的访问，当然仅仅为了在图形用户界面中显示树状结构，每次用户点击将树展开并没有什么问题

代码格式规范的List

崔玉松 — Mon, 08 Feb 2010 02:13:26 +0000

《代码大全》是本好书啊，推荐所有有志于改善自己的程序，或者在编码上寻找进一步提高的人应该仔细研究研究。以下是摘抄自《代码大全》第二版中谈到关于怎样的代码格式更适合人类阅读，更能令人愉悦的Check List。对照List进行自检和反省，令人欣慰的是List中80%以上我都做到了，在我的上一个项目中做得比较失败，由于时间的原因，很多注释没有加上，逻辑也不够清晰。在重构中解决，借此反省。
一般问题：
格式化主要是为了展现代码的逻辑结构吗？
2、你的布局方案能统一运行吗？
3、你的布局方案能让代码易于维护吗？
4、你的布局方案是否有利于代码的可读性？
控制结构的布局
1、你的代码中避免begin-end 或对｛｝的双重缩进了吗？
2、相邻的块之间用空行分割了吗？
3、对复杂表达式格式化时考虑到可读性吗？
4、对只有一条语句的块布局始终如一吗？
5、case语句与其他控制结构的格式化保持一致了吗？
6、对goto语句格式化是否让其显眼了呢？
还好目前PHP只有5.3以上版本才会有goto
单条语句的布局：

1、为逻辑表达式、数组下标和子程序参数的可读性使用了空格了吗？
2、不完整的语句在行末似乎以明显又错的方式结束吗？
3、后续行按照标准数码缩进了吗？
4、每行顶多只有一条语句吗？
这一点是团队中比较头痛的问题，很多人不按照这个规则来做，结果它成了一种风气
5、所写的每个语句都没有副作用吗？
6、每行顶多只声明一个数据吗？
注释布局：
1、注释与其所注释的代码所尽量相同吗？
2、注释风格便于维护吗？
子程序的布局：
1、你对每个子程序的参数格式化方式便于看懂、修改、注释吗？
2、采用空行分割子程序各部分了吗？
4、文件中子程序用空行清楚分开了吗？
5、在没有更好的组织形式的场合，所有子程序都按字母排列了吗？
这一点我没有做到，没有做到是没有想到这一点，以后编码注意了……

您可能也喜欢：
代码格式规范的List	数据库的层次结构	UDP hole punching 翻译	N-Gram学习笔记	linux进程管理笔记
无觅

您可能也喜欢：
TCP和UDP的区别	代码格式规范的List	《Rework》	数据库的层次结构	程序语言评估标准
无觅