Daniel Hu的技术生活博客

Agile

敏捷软件开发模型：SCRUM
闲话：关于敏捷

而敏捷里面所有的实践，质量是隐含的，不可侵犯的.这就是我们所说的Built Quality In.比如，刚开始写Story, 就要和测试人员定义验收条件；开发Story采用TDD的方式，通过测试来检验功能，类似于砌墙的时候先扯水平线，然后开始铺砖.

整个团队只有一个目标：产生高质量的交付

在此目标之下，以尊重 交流 反馈 勇气 简单为基本做事价值观和原则.

Agile Versus Waterfall: Part One

敏捷与能力

丰田精益生产方式中一个经常用的隐喻是“湖水和岩石”。大意是指湖水太深，你无法发现阻碍当前生产的主要原因，只有把湖水讲下去，才能发现真正的岩石在哪里。在精益生产中，湖水是指“库存”，而在软件开发中，对应的湖水则是“迭代周期”。
我们举一个例子，当发现“项目严重延期”时，通常已经是交付时间，不过开发人员最近一直加班，也挺辛苦的呀。不过如果你是项目经理或者客户，你知道开发人员的时间都花到哪儿了吗？如果采用迭代式交付，每两周一个迭代，完成一定的特性，你可能第一个迭代就发现问题

我们可以抱怨团队开发人员能力不够，不过这关敏捷的什么事儿？本来大家都知道的事情，只不过敏捷让它暴露的更严重更突出罢了，谁还会任由你“掩耳盗铃”呢。

敏捷和SCRUM回顾

Javascript

JavaScript Debugging Techniques in IE 6

Java

Top 10 (not so popular) Eclipse Shortcuts

Design Pattern

Design Patterns Uncovered: The Flyweight Pattern

When considering this pattern, you will need to think about intrinsic and extrinsic data. Intrinsic data is the data that makes this object instance unique. Meanwhile, extrinsic data is information that can be passed in through arguments. So, if you can make some data extrinsic for cases that you have a large number of objects, the Flyweight pattern may be exactly what you are looking for.

设计模式学习笔记（十二）——Flyweight享元模式

Flyweight模式的几个要点：

1、面向对象很好的解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight设计模式主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。

2、Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象的状态处理。

3、对象的数量太大从而导致对象内存开销加大（这个数量要经过评估，而不能凭空臆断）

SOA

自底向上的ESB管理 VS. 自顶向下的SOA治理

但创建了一个SOA，自底向上的治理方法关注围绕单独ESB的集成化服务，这些ESB 可以快速装配。该方法因为需要过多的更新和重做而受到非难。

同时，相对的“自顶向下”的治理方法涉及大量严格规划和精确策略执行。这种方法也由于花费过多的时间才能产生结果而不被认可。

SOA治理策略如何抉择？

企业接受SOA的速度比较慢，大多数接受者倾向于接受自底向上的方法。

随着人们开始实施SOA，自身的技术就不够用了，这时就需要一些治理来辅助

Hariharan最后讲到：“如果企业以一种长期的愿景和蓝图来寻求SOA，那么自顶向下的方法是最佳的选择。如果并没有一项企业级的IT 策略以及长期的愿景，IT 可以选择自底向上的方法来实现和展示SOA的好处。”

Linux

使用scp 命令在两台linux上对拷文件或者文件夹

scp 本地用户名@IP地址:文件名1 远程用户名@IP地址:文件名2

拷贝文件夹命令如下：scp -r file username@ip:filepath
多加上一个-r参数即可。

Database & SQL

如何应对表结构经常变化？

第一种方法，预留字段.不管怎样，预留字段的方式还是很解决很多问题的，而且基本不影响性能，除了额外的meta信息描述外，也没有其他的负担。

第二种方法，使用复杂字段.使用复杂字段的好处就在于比较灵活，同一类型的数据可以放在一起（实际上相当于把应该是一个关联表的数据放一个字段里了），操作的性能也不错，但是复杂字段里面的内容查询比较困难.

还有一种方法，将数据的存储和索引（需要查询的内容）分开存放，相当于主表就一个key-value，value就是一个大的xml（或者其他的一坨），把需要查询的字段放到其他单独的表里去，可以参考friendfeed如何使用mysql.

还有column based db，也可以很好的解决这个问题，实际上他就本本回避了加字段的问题，不过现在似乎没有性能很好的实现

公交车路线查询系统后台数据库设计–查询算法

公交车路线查询系统后台数据库设计–关联地名和站点

SOA

SOA(面向服务的开发) 简介

微软SOA平台体系架构介绍

SOA@eBay 读后感

SOA与服务识别

面向服务架构（SOA）已被作为一种通过对齐IT和业务来促进业务机动性的方法被广泛接受。这种方法的主要不同之处在于，用相对较低的成本就能轻易 地获得某种机动性。在较高的层次，该方法试图将第n次业务变更所产生的增量成本降低到零或接近于零。组织推行SOA项目目的就是为了在他们的SOA之旅当 中尽早达到这个难以捉摸的第n个迭代。在实践中，要达到这种最佳状态的时间可能得花数年，甚至更长时间。

Architecture & Design

探秘：AOP能否解决紧密耦合的难题

虽然动态横切（其中对象的运行时行为可以改变）被认为是AOP的根基之一，但静态横切却是一种远不为人所知的技术。

Scalability

大规模集群下的http 状态解决方案

Java

Java 语言中的函数编程

Jrebel原理剖析

Reloading Java Classes 401: HotSwap and JRebel — Behind the Scenes

Difference between HashMap and IdentityHashMap

Linux

关于cronExpression的介绍

其他

我在QQ邮箱的这四年（一） [转]

张小龙（Foxmail的作者）认为互联网团队中的管理不是管人，而是管理产品体验，以产品体验为核心，产品设计和开发人 员与产品共同提升，共同进步。小龙之于QQ邮箱的影响正如乔布斯之于苹果的影响。

当时(2005)的javascript代码有很重的面向对象的味道，用传统的软件工程思想构建了 整个web框架，从软件的开发流程来说，这并没有什么问题，但是产品却有很大的问题出现了–慢，不是一般的慢，当时除了较快的电信网用户可以登陆进邮箱 之外，其他的用户基本上都被卡在登陆上。06年的大部分时间，整个团队都在解决速度慢的问题，尝试了很多方法，把js容量压缩掉了一半，js混淆之后又压 缩了很多，js文件分开为多个，但始终没有根本的转变，速度的提升仍然不能被用户接受。现在回过头分析这个问题，我觉得物理上的压缩和分割js文件之所以 解决不了问题是因为问题的根本在于js的逻辑架构上，当时的js有明显的基类和继承类结构体系，这种结构并不适合物理上的分割，即使分割开，渲染消耗的时 间是节省不下来的。

Javascript

实用的JavaScript 测试及效验工具

Java

ThreadLocal是什么

深入探讨在集群环境中使用 EhCache 缓存系统

WEB

加速Javascript：DOM操作优化

Linux

Linux内存模型

文件默认权限：umask

查看方式有两种，一种是直接输入umask，可以看到数字类型的权限设置分数，一种是加入 -S（Symbolic）参数，就会以符号类型的方式显示权限。

在默认权限的属性上，目录与文件是不一样的。由于我们不希望文件具有可执行的权力，默认情况中，文件是没有可执行（x）权限的。因此：
• 若用户建立为”文件”则默认“没有可执行（x）项目”，即只有rw这两个项目，也就是最大为666分，默认属性如下：
-rw-rw-rw-
• 若用户建立为”目录”，则由于x与是否可以进入此目录有关，因此默认为所有权限均开放，即为777分，默认属性如下：

umask指定的是“该默认值需要减掉的权限”。因为r、w、x分别是4、2、1，所以。也就是说，当要去掉能写的权限，就是输入2，而如果要去掉能读的权限，也就是4，那么要去掉读与写的权限，也就是6，

Architecture & Design

IOU 设计模式介绍及应用

IOU 思想是人们在处理日常债务关系时行之有效的一种方法，即：

• 债务人通过可靠的第三方保管账户，向债权人发放 IOU 债务凭证；
• 债务人通过向第三方保管账户提交结果以终止 IOU 债务；
• 债权人凭此 IOU 债务凭证通过第三方保管账户履行债权并进行结果赎回。

债务人和债权人之间的债务关系，通过可靠的第三方保管账户，实现了在时间和空间上最大程度的分离和解耦。

IOU 设计模式是 IOU 思想在软件设计领域的应用，最早由 Allan Vermeulen 于 1996 年首次提出。在软件设计领域，债务关系发生在方法调用者和方法体之间，债务对象就是方法的返回结果。普通方法的调用模型是方法体同步执行然后返回结果，调用者必须等待结果返回后才能继续执行。在 IOU 设计模式下，方法体将立即返回一个 IOU 对象，并且承诺 IOU 对象最终一定会被终止，调用者在 IOU 对象被终止后可进行结果的赎回。在此期间，调用者无需等待就能够继续进行其它有价值的事务，从而达到了提高程序整体的并发性和异步性的目的。

IOU 设计模式完全不依赖于任何一种异步机制，IOU 对象的提供者可以选择任意有效的方式来执行服务并最终终止 IOU 对象，比如启用独立的线程/进程执行、驱动异步事件产生、通过远程方法调用或是等待用户终端输入等等。这是 IOU 模式具备普遍适用性的一个重要因素。

Q1技术回顾

SOA

Services vs. Applications

Services	Applications
Perform a single or a few specialized operations.	Perform a wide range of operations, and may even expose some of these operations as services.
Most often accessed by other programs.	Often (but not always) accessed by humans.
Often (but not always) targets part of a larger problem domain.	Often (but not always) targets a whole problem domain.

try catch finally 语句说明

try catch finally是javascript语言提供的异常处理机制。语法结构如下

try {
  //这段代码从上往下运行，其中任何一个语句抛出异常该代码块就结束运行

}
catch (e) {
  // 如果try代码块中抛出了异常，catch代码块中的代码就会被执行。
  //e是一个局部变量，用来指向Error对象或者其他抛出的对象
}
finally {

  //无论try中代码是否有异常抛出（甚至是try代码块中有return语句），finally代码块中始终会被执行。
 }

try…catch…finally…语法中除了try以外catch和finally都是可选的（两者必须要有一个），也就是说try…catch…finally…语法有以下三种形式

如果有一定catch，一旦try中代码抛出异常以后就是先执行catch中的代码，然后执行finally中的代码。如果没有catch语句,try中的代码抛出异常后,就会先执行finally中的语句，然后将try中抛出的异常以异常的方式继续往上抛。

不管try代码块的执行时如何被终止的（出现异常、return、自然终止）finally中的语句始终会被执行，正是由于finally的这种特性，通常finally用来执行一些清理工作。如果try中代码是以return,continue,break的方式终止的，Javascript引擎会在执行完finally中的语句以后再执行相应的try中的返回语句。

throw语句说明

    throw语句在javascript1.4中已经实现。try的语法很简单，如下

throw expression;

其中的expression可以是任何一种类型，也就是说throw “There is a error” 或是throw 1001都是正确的。但通常我们会抛出一个Error对象或是Error对象的子类。关于Error我们稍后介绍，先看一段throw的样例代码。

function factorial(x) {
    // If the input argument is invalid, throw an exception!
    if (x < 0) throw new Error("x must not be negative");
    // Otherwise, compute a value and return normally
    for(var f = 1; x > 1; f *= x, x--) /* empty */ ;
    return f;
}

Error对象

Error对象和它的子类是在javascript1.5中实现的。Error的构造函数有两种

new Error( )

new Error(message )

Error有两个基本的属性name和message。message用来表示异常的详细信息。而name指的的是Error对象的构造函数。此外，不同的js引擎对Error还各自提供了一些扩展，例如mozilla提供了fileName（异常出现的文件名称）和linenumber（异常出现的行号)的扩展，而IE提供了number（错误号）的支持。不过name和message是两个基本的属性，在firefox和ie中都能够支持。Javascript中Error还有几个子类EvalError, RangeError, ReferenceError, SyntaxError, TypeError, URIError，各自的意思就不在这里详细描述了，读者可以在我提供的参考文档中找到相应的参考。

Javascript的异常处理机制和window.onerror句柄

当javascript代码中出现错误的时候，js引擎就会根据js的调用栈逐级寻找对应的catch，如果没有找到相应的catch handler或catch handler本身又有error或者又抛出新的error，最后就会把这个error的处理交给浏览器，浏览器会用各自不同的方式（IE以黄色三角图案显示在左下角，而firefix会显示在错误控制台中）显示错误信息给访问者。很多场景下，我们会觉得这种错误提示方式不够友好，而且提示信息很隐蔽，那么我们机会自定义这种错误提示的方式吗？答案是有，就是window.onerror属性。

javascript的window对象有一个特别的属性onerror，如果你将某个function赋值给window的onerror属性，那么但凡这个window中有javascript错误出现，该function都会被调用，也就是说这个function会成为这个window的错误处理句柄。

// Display error messages in a dialog box, but never more than 3
window.onerror = function(msg, url, line) {
    if (onerror.num++ < onerror.max) {
        alert("ERROR: " + msg + "\n" + url + ":" + line);
        return true;
    }
}
onerror.max = 3;
onerror.num = 0;

onerror句柄会3个参数分别是错误信息提示，产生错误的javascript的document ulr，错误出现的行号。

onerroe句柄的返回值也很重要，如果句柄返回true，表示浏览器无需在对该错误做额外的处理，也就是说浏览器不需要再显示错误信息。而如果返回的是false，浏览器还是会提示错误信息。

window.onerror=function(){

alert(”xx”);

return true; //如果注释掉该语句，浏览器中还是会有错误提示，反之则没有。

}

function throwerror(){

throw new Error(”cc”);

}

我们在开发HTML的过程中避免不了一些Js的异常，通常我们也不可能依赖客户打开浏览器的错误提示框（如上图）来为我们定位bug提供线索，而利用window.onerror句柄我们就可以讲错误提示信息显示出来，客户只要在错误出现的时候，提供相应的截屏就可以了，这点可以很好的帮助开发人员定位，分析javascript相关的错误。

参考资料

Mozilla Javascript1.5核心参考

Javascript犀牛(JavaScript: The Definitive Guide)