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参数即可。

项目

不信任的博弈

进度必然是符合质量的功能点的交付，而不是狭隘的代码完成。

需求入门 － 用Kano模型来确定需求优先级

Scalability

HBase vs Cassandra: 我们迁移系统的原因

Management

敏捷个人－认识自我，管理自我

10步让您成为一名优秀的 Web开发人员

SOA

为什么现在SOA成功的关键是数据建模？

数据库

 XtraDB/Innodb内部结构示意图

Data Access Layer（DAL）方案

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 测试及效验工具

Architecture & Design

Mediator Pattern applied to Javascript

The diagram below is a general representation of the interaction between a mediator and colleagues. Each colleague stores a reference to the mediator and the mediator stores a reference to each colleague. Colleagues are unaware of each other and messages are broadcast through the mediator.

Two of the benefits of using the Mediator pattern are that that it decouples colleagues and simplifies object interaction. Instead of using the Observer pattern to explicitly set many-to-many listeners and events, Mediator allows you to broadcast events globally across colleagues. The biggest drawback of using Mediator pattern is that due to the centralized control, the mediator can become difficult to manage.

向对象开发与面向组件开发的区别
养成面向组件编程(COP)的习惯
面向组件还是面向对象

既然类和组件有着这么多类似的地方，那么传统的面向对象编程和面向组件编程有什么区别呢？简单的说，面向对象关注的是组合在一个二进制可执行文件中的各个类的关系，而面向组件的编程关注的是在彼此独立的基础上模块之间的交互性，这种交互性使得你并不需要熟悉它们内部的工作原理。

面向对象与面向组件小议

面向对象技术的基础是封装－－接口与实现分离，面向对象的核心是多态－－这是接口和实现分离的更高级升华，使得在运行时可以动态根据条件来选择隐藏在接口后面的实现，面向对象的表现形式是类和继承。面向对象的主要目标是使系统对象化，良好的对象化的结果，就是系统的各部分更加清晰化，耦合度大大降低。 

组件技术的主要目标是复用－－粗粒度的复用，这不是类的复用，而是组件的复用，如一个dll、一个中间件，甚至一个框架。一个组件可以有一个类或多个类及其它元素（枚举、）组成，但是组件有个很明oo显的特征，就是它是一个独立的物理单元，经常以非源码的形式（如二进制，IL）存在。一个完整的组件中一般有一个主类，而其它的类和元素都是为了支持该主类的功能实现而存在的。

最后强调一点，组件的目标是粗粒度的复用，组件的核心是接口。

用Qi4j进行面向组合编程

Java

SortedMap JavaDoc

Database and SQL

Efficient Pagination Using MySQL

高效的MySQL分页

SOA

服务和耦合的真正意义

基于设计的组件：首先：SOA和基于设计的组件不一样。在一个SOA架构中的服务是分布式的。而基于设计的组件中的这些组件是代码片段，通过他们所处每个系统来打包这些片段。从这种意义上来讲，EJB 能够作为服务和组件。

基于重用的组件通常比基于重用的服务简单。在服务重用时，在重用组件中变更带来的影响更是难以控制。其中可能有使用我的服务以及我没有关注的系统。在组件中，也许也是这种情况，但每个系统不得不有意识的做决定来升级组件，所以在一个系统中任何意外的破坏都与系统中那个早期的变更有关系。

耦合：这是“耦合”的真正意义。如果一个系统的改变很可能需要另一个系统的改变，那这两个系统是紧耦合的。这是一个很难通过观察代码来衡量的标准，然而很多人相信可以用代码的度量来理解耦合。

其他

一个老程序员的感悟：做技术二十多年，突然明白的道理

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.

Agile

Agile: The New Era

The study found that iterative and agile practices have a significant impact on defect and productivity factors, as indicated by the following points.

• Releasing a system with 20% of the functionality complete is associated with a decrease in the defect rate of 10 defects per month per million lines of code as compared to waiting to release a product until 40% of the functionality is complete, and an increase in productivity of eight more lines of source code per person-day.
• Continuous Integration, the idea of integrating and testing code as it is released to your source code repository, resulted in a decrease in the defect rate of 13 defects per month per million lines of code, and an increase in productivity of 17 lines of source code per person-day.

The first two are deeply embedded in the ideals of agile software development.

• Releasing early and often to project stakeholders, using an iterative lifecycle.
• Continuous integration, with daily builds including regression testing.
• Teams with broad experience delivering multiple projects.
• Careful attention to modular and loosely coupled, componentized architectures.

OOD and OOP

An (Overlooked?) Use Case for the Strategy Pattern

SOA

Enterprise Service Bus (ESB): a critical part of SOA

Agile

结对编程如何才能真正起作用

敏捷项目管理体会-鸟瞰

DocShare Plugin

SOA

程立谈大规模SOA系统

程立谈架构、敏捷和SOA实践

最近读完了《SOA实践指南——分布式系统设计的艺术 》这本书，以下是这次的读书笔记。

什么是SOA  

在计算科学中，术语“面向服务的架构”（SOA）表达了一种软件架构的概念，它定义为使用服务来满足满足软件用户的需求。在SOA环境中，网络上的节点以独立服务的形式将自己的资源开发给网络上其他参与者，其他参与者按一种标准的方式使用资源。大多数对于SOA的定义都提到了实现SOA时使用Web Services(即使用SOAP或REST）。然而，可以使用任何基于服务的技术实现SOA。

……

与传统点对点架构不同，各种SOA都由松耦合、高度可以互操作的应用服务构成。这些服务基于某种格式定义进行互操作，该定义独立于底层平台和编程语言（例如，WSDL）。接口定义封装（隐藏）了供应商和语言相关的实现。SOA独立于开发技术（比如JAVA和.NET)。由此，软件组件将具备非常高的重用性，因为接口按与标准兼容方式定义。

基于SOA的逻辑架构模型

无状态服务为什么更好

    首先，对于无状态服务来说，在服务层做到负载均衡和失效备援相当简单。ESB仅需实现能使用下一个最容易获得的服务实例即可。它甚至可以是其他消费进程以前使用过的线程。这意味着如果一个系统失败了，其他系统可以轻易地接手，继续工作。如果服务层的通量不够高，你可以将服务实例的数量翻倍，从而是通量翻倍。这意味着解决方案能线性伸缩，并且，如果一个服务实例意外死亡，其他服务实例能投入进来。

而有状态服务的缺点是，它们绑定在会话上。这样一来，知道消费者会话结束（或者连接失效）之前，为它们分配的资源都绑定在一个特定的消费会话上。除此以外，你必须能让ESB把连续的服务调用路由到同样的服务实例上。

然而，要注意的是，有状态服务仍然可以线性伸缩。使用一种“粘性”路由的政策，根据可用的资源，你在第一个服务调用被执行时找到你的服务实例。这一来，对服务实例数量的翻倍就又能将可能的会话数量翻倍了。然而，此时不具备服务资源可以在不同消费者之间共享的优点。并且，如果一个服务实例意外死亡，会话状态就丢失了。

同时也要注意，有状态服务可以有失效备援机制（并且仍然可以线性伸缩）。此时，每个服务器不但返回它自己的会话ID，还返回失效备援会话的ID。只要这个失效备援会话不在一个中央服务器上，而是在邻近的服务器上（并且，每个服务器的邻近服务器各不相同），这样就不会造成瓶颈。

等幂性

等幂性是服务的一种可能的属性。在服务的上下文环境中，它意味着对同一服务调用的多次递交/处理不会引发问题。假设你有一个向银行中增加钱的服务。如果一个消费者调用这个服务（例如，为了处理银行转账）并且没有得到应答，消费者不会知道服务的请求还是服务的应答失败了。例如下图中，服务可能在请求处理之前或之后丢失。

在后一种情况下，从供应者的角度来看，服务成功了，指定数量的钱被增加到了银行账户上。在前一种情况下，服务没有影响（即没有增加钱）。

当服务的消费者没有得到应答时，它不知道服务是否成功了。为求确保，它可能重试服务调用，再次发出同样的请求。结果是，达到供应者的服务请求可能有一次或两次。如果服务是幂等的，那么，服务请求到达多少次都没有关系：同一服务调用的多次请求只产生一次的效果。

刚刚描述的银行服务不是幂等的，因为，它依赖于第一次服务调用失败发生在何处，客户的余额可能最终被增加了两次，而不是消费者想要的一次。为了避免这样的问题，通常说来，只要有可能就是服务幂等是个好主意。

所有的读取服务都是幂等的，因为一个服务供应者无论多频繁地执行返回数据的请求都没有关系。然而，要注意，一旦做了类似每个请求都写一个备忘录项这种事，读取服务就变成了写入服务。如果这个备忘录和业务有某种关联，这就可能成为问题（例如，对同一样的事项，最终可能有多个备忘录项）。

写入服务可能是幂等的，也可能不是。当一个服务调用的影响依赖于后端现有的状态时，写入服务不是幂等的。举个例子，在前面的例子中，银行账户的最终余额依赖与最初的余额。如果开始的余额是500美元，服务调用增加100美元，结果将是600美元。如果因为最初的应答丢失了，另一个请求到达并且得到处理，最后的余额将是700美元。

一个幂等的写入服务的例子是，一个通过发送所有地址来设定客户地址的服务。供应者处理多少次请求都没有关系，结果将是一样的。

注意：你总是可以避免让服务不幂等。例如，我们可以修改银行服务语义，发送新值而不是应该增加的值，从而使服务幂等。这就是说，不是调用：

addToBalance(100);

我们可以调用：

setBalance(600);

这个调用可以反复地发送和处理，余额的结果都会是600。当然，其他服务也能在相同的账户中增加或减少资金，这就带来了问题。这就带来了问题。你如何才能知道最终的余额应该是多少呢？正如你看到的，从业务的角度来看，让服务幂等可能变得复杂。

除此以外，从业务角度来看，有的服务内生就是不幂等的。所有创建某些东西的服务都没有办法和一个状态去比较(除非你知道创建新资源的工厂的状态）。例如，如果你有一个创建银行账户的服务，你就是在创建账户，仅此而已。

如果从业务的角度来看，引入幂等性是个难题的话，那么，你需要一些对幂等性的技术支持。实现幂等性的普通方法相当简单，消费者发送数据的方式必须能让供应者看的出两个技术性的请求其实是同一个。为此，消费者可以随着每次新请求发送一个唯一的ID。如果消费者没有得到应答，它的每次重试都是同样的ID。下图是对此的图解。

在处理每个进入的请求前，供应者应将请求及相关联的唯一ID存储到一个中央数据库中。如果供应者收到一个ID已经在存储库中的请求，它就知道该请求已经被处理过。于是，供应者就不会再处理它，而是向消费者重新发送最初的应答（应答在第一次被送出去之前，也保存下来）。如果第二次请求到达是，服务实现正处于运行中，则供应者可以回复一个应答，说服务调用在运行中，或者供应者可以等到第二次请求处理完毕以后，再次把应答发送出去。

作为一项优化，消费者能和请求一起发送一个标志，这样供应者就知道此请求是否是一个重试。这样能做到改善性能，因为如果调用没有被标记为重试的华话，供应者就不必验证请求是否已经在存储库中了。