标签归档：读书笔记

《Rework》

发表于 2010 年 12 月 16 日 由 崔玉松

这本书是近来难得一见的好书，认识字的都应该去读几遍，中文最近也出版了，各大售书网站都可以买到，打完折二十几块钱，非常物有所值，尽管英文版我已经读过，依然忍不住买一本中译本收藏，虽然中译本的名字我觉得很恶俗，这本书和商业思维没有太多的关系，中译本的作者自作聪明的加上这个小标题，有点恶心，另外将rework翻译成“重来”个人觉得也有点欠妥当，还不如不翻译，意思可能会更明确一点。虽然中译本有这样那样的问题，整体来说翻译的不错，不喜欢英文的可以买来看看，鼎力推荐——我本人不会有任何好处 那来的从错误中学习 中国人常说的一句话是：失败是成功他妈。作者引用哈佛商学院的报告证明，失败的创业者再次创业并不比从未创业的人成功的概率更高。有一类人非常明白这个道理，他们有个名字叫VC（风险投资人），VC非常喜欢那些已经或者曾经创业并且干得不错的人，换句话说这些人往往能从VC那里以比较小的代价（损失较小的股份或者少费周折）搞到很多很多的钱用于再次创业或者公司发展 。 何必壮大 这个观点有点意思，几乎所有的企业家都想将自己企业做大，富士康的员工超过百万，而作者觉得大未必是最优的，我非常认同作者的观点，我身边就有很多的公司每年几个亿的业务却只有10个左右的员工。公司越大责任就越大，不仅要自己赚钱还要照顾好这些员工，是一个有责任的企业家应该做到的，而不是压榨。如果你不能，那么就尽量提高效率，少招几个人吧，与人与己都是好事。 工作狂 引用里面的几句话：工作狂实际取得的成就并不比正常人高，他们自诩为完美主义者，但这仅仅代表他们浪费了大量的时间去关注次要的细节，而不是推动下一项任务。真正的英雄是早已想出办法、搞定一切，然后回家了。 Start making Something 我们身边总有这样的人在叹息“XXX我早就想到了，只是没有下手，如果当初我干了，现在也亿万富翁了”，这个观点很可笑，你大脑中有创意跟你实际去创建这样的事情一点关系也没有，在你人生中最有意义的使你做了什么，而不是你想过什么、说过什么或者计划过什么 没有时间不是借口 当你拥有某种极其强烈的渴望时，你就能挤出时间来，不管你身上是否还背负着其他的责任，事实上大部分的渴望不是那么强烈，于是他们总是拿没有时间来做借口进行自我保护。如果我不是这样，我今天已经做出了好几个开源作品了。 =====未完待续======

发表在 Study & Reading | 标签为 | 2 条评论

UDP hole punching 翻译

发表于 2010 年 08 月 08 日 由 崔玉松

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 … 继续阅读 →

发表在 Study & Reading | 标签为 , , | 留下评论

数据库的层次结构

发表于 2010 年 03 月 15 日 由 崔玉松

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

发表在 Database | 标签为 , | 留下评论

代码格式规范的List

发表于 2010 年 02 月 08 日 由 崔玉松

《代码大全》是本好书啊，推荐所有有志于改善自己的程序，或者在编码上寻找进一步提高的人应该仔细研究研究。以下是摘抄自《代码大全》第二版中谈到关于怎样的代码格式更适合人类阅读，更能令人愉悦的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、在没有更好的组织形式的场合，所有子程序都按字母排列了吗？ 这一点我没有做到，没有做到是没有想到这一点，以后编码注意了……

发表在 Study & Reading | 标签为 , | 3 条评论