懒的态度

从广义的角度来说，Domain 指的是一个组织所从事的【领域】。不同行业的组织有着截然不同的领域，它们的认知范围和运营方式构成了自身的 domain。在设计的时候，应当尽可能的将不同的 domain 分离开来，形成 Core Domain、Supporting Domain 和 Generic Domain。 + A Core Domain is a part of the business Domain that is of primary importance to the success of the organization. + 有时候为了支撑业务的运行，必须要创建 Bounded Context 来建立不可缺的模型，这就是 Supporting Subdomain。这些模型是不可缺的 (essential) 但并非最为核心的 (core)。 + 另外，对于业务而言并不具有特殊性但是对于全局 (overall business solution) 而言是必须的部分可以被归入 Generic Subdomain。 书中给出的一个例子是 SaaSOviation 的 collaboration product，在设计的时候，这个虚拟的团队一开始将 `User` 和 `Permission` 这样的 domain 融入了 `Forum`、`Discussion` 之中，导致了不必要的概念引入，从而形成了不必要的 complicated code： public class Forum extends Entity { public Discussion startDiscussion(String aUsername, String aSubject) { if (this.isClosed()) { throw new IllegalStateException("Forum is closed."); } User user = userRepository.userFor(this.tenantId(), aUsername); if (...

刚看完了 Channel 9 上放的一段视频，是大牛 [Andres Hejlsberg 介绍 TypeScript 的视频](http://channel9.msdn.com/posts/Anders-Hejlsberg-Introducing-TypeScript)。 [TypeScript](http://www.typescriptlang.org/) 有一套自己的 Language Specification，其中允许定义 modules、classes 和 functions 等具有强类型的标识对象。tsc 是 TypeScript Compiler，有能力扫描所有的 reference files 并根据类型关系提供 development time 的语法高亮和上下文提示，从 tooling 方面极大的强化了 javascript 在开发大规模应用程序（scalable application）时候的效率。而这恰恰是 javascript 的软肋…… 有一段 demo 展示了如何针对 type script 文件执行重构——传统的 javascript 文件由于没有具体的类型信息无法让 IDE 支持像是“重命名”这样的简单操作，很多时候 IDE 只能以朴素的字符串替换方式来重命名所有的出现地方。而 TypeScript 由于编译器可以推断类型信息，因此重构变得可行。 在视频的最后一段 demo 中，Andres 还展示了 typescript compiler 的“自举” (self boot) —— 编译自身的源代码。 除了编译出 js 文件外，还可以指定生成相应的 *.d.ts 文件列举所有对外可见的 interfaces。这对于所有需要支持 TypeScript 的工具来说都是很要紧的。 总得来看，typescript 很好的弥补了javascript 弱类型的不足，如果在大多数 IDE （如Eclipse、IntelliJ或WebStorm）中能够得到很好的支持的话，应该是web developers手中很好的一枚工具！

最近饭厅里的射灯出了点问题，一个灯座上有三枚灯泡，其中的一枚灯泡不亮了，于是换灯泡折腾了两天…… 周六跑到Bunnings，按照老灯泡的接口买了个飞利浦的35W Halogen小灯泡，而且买了4 pack的套装，价格是10刀。回到家试着装上去，结果发现怎么都没法嵌到灯罩内，仔细一看，因为两个灯泡的长度稍微差了几毫米……结论——新买的灯泡是用不上了，要去退掉。 后来干脆把另一个老灯泡摘了下来，放到了不亮的那枚的灯罩里，结果也不亮了…… 三枚灯泡现在只有一枚亮了，于是陷入无限困惑中，到底是灯泡问题还是灯座的问题。于是整个周六的晚上就在google和youtube上玩命地寻找关键字 “halogen“、”spotlight”、“ pot light ”、“recessed lights” 等，了解了各种卤素灯泡的尺寸、12V和220V+两种接口的区别，以及安装这种射灯时候需要考虑的防火隔热因素，指望找到如何判定问题的线索，一直看到眼皮撑不住了才去睡的。 周日又起来试了试，把几枚老灯泡换来换去旋转进灯座，嘿嘿，发现原本亮的两枚又好了。看来是因为灯座的接触有点问题。这样的话就确认了一枚灯泡坏掉的事实，直奔Bunnings去调货。先退了飞利浦，在货架上的一堆灯泡中寻觅了半天终于找到了Nelson的，尺寸一模一样，也是20W的而且尺寸和老的一致。回来一装就亮了。

接触 Scala 有一段时间了，一开始的时候是因为 Scala 支持 strong type 的缘故感兴趣的，后来慢慢的看了 traits, pattern matching, generics 等语法特性，觉得这个语言夹杂了很多其它语言的特征。不过，就像 C++ 从 C 发源后加入了 OO、 Meta-Programming 等不同性质的语法特性之后整个语言的学习曲线陡增，Scala 对于 Java developers 来说可能也不算是容易上手的 JVM Language。 最近拜读了一篇讨论 Scala 优缺点的文章，颇有想法—— Scala: Sink or Swim Part 1 , Part 2 , Part 3 。之前玩了一阵子的 sbt，最近项目上在用 Gradle （这是用 Groovy 语言编写的一个具有 Ant 和 Maven 二者之长的构件系统），很能体会作者谈到的 sbt 的不爽……

Scala 是一种多范式的编程语言，设计初衷是要整合面向对象编程和函数式编程的各种特性。Scala 运行于 Java 平台（Java 虚拟机），并兼容现有的 Java 程序。它也能运行于 Java ME, CLDC 上。 Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages, enabling Java and other programmers to be more productive. Code sizes are typically reduced by a factor of two to three when compared to an equivalent Java application. Scala 解释器类似于 Unix Shell，它允许用户以交互的方式输入表达式。在命令行中执行 `scala` 命令可以进入 Scala 解释器。 Welcome to Scala version 2.9.2 (Java HotSpot(TM) Client VM). Type in expressions to have them evaluated. Type :help for more information. 如果想要在解释器中跨行输入语句，只要一行行键入。如果输入到一行的结尾还没有结束，解释器将会在下一行自动回显一个 `|` 符号提示等待输入。用户如果发现一些错误而希望终止输入，可以连续键入两次回车取消当前的输入。如果需要离开解释器，只需要输入 `:quit` 或是 `:q` 即可。 有的时候，如果需要在命令行交互中得到更为详尽的提示信息，例如对过期函数调用的提示，或是对于未检查警告的解释，可以在启动 scala 的时候传入参数。 scala -unchecked -deprecation tag: scala

前面说了Scrum的迭代范围， 再来看看人――Scrum的参与者。 涉及到Scrum流程的角色包括PIG和CHICKEN。 Scrum Master和Team算是猪；Product Owner和Stakeholders算是鸡。 在Daily Scrum Meeting中 猪可言 鸡难语～ 每日花15分钟围成一圈站着开Scrum Meeting，是促成团结增进和谐的良方。 一般建议每个scrum team不超过7个人， 如果scrum的团队比较大，可以拆分为若干个team。 这种情况下就需要召开scrum of scrums。 也就是每个team的master或是lead要开一个会。 在老师的ppt中甚至展示了一种超大团队的meeting方式―― scrum of scrums of scrums，当然，这只是theoretically speaking... 在迭代过程中，如果用户的需求发生了改变，要考量impact， 如果小修改可以立即执行，但是如果影响到当前的sprint，尽量应当放到下一次sprint中加入。 原则上一旦sprint的范围确定就不宜修改。

Scrum定义scope有这么几个范围：Project、Release和Sprint。 首先，product owner拥有整个product的vision，他可以是来自客户方的代表，亦或是自己的产品经理。 product owner可以回答关于产品需要的特性、特性优先级等问题。 整个scrum team需要先整理出product backlog。 第二步，scrum team根据能力――capacity，也就相当于朴素的人月概念， 从product backlog中挑选出优先级最高的user stories构成第一个release。 定义release scope的阶段也成为sprint 0 在每个release中，再定义有多少个sprint，大的epic先拆分为合理的user story， 类似的，再将user story细化为task，并估算story point，assign给team member。 估算story point有很多种方法，有一种是planning poker， 扑克的玩法是通过多人估值，分别解释最大值和最小值，在取得共识的前提下再次出牌估值， 直到最终达成大部分的一致。貌似挺民主的做法。 不过印度老师说公司不采用这种方式，残念了…… 因为它的精度不是很高，ADM采用一种estimator，从以往的项目中进行估算。 选择user story的时候有一个顺序问题――优先选取难度最大而价值也最大的user story， 其次选取价值高难度一般的；接下来是价值低难度也低的，最后才选择价值低而难度高的。 这种选取顺序是有道理的，因为一开始就尝试完成风险最高而价值也最大的user story， 可以最早地将潜在的风险给暴露出来，这样万一出现了难以解决的问题可以及早客户沟通。 而反过来，价值最低风险又高的user story放在最后，也有好处， 这样客户可以选择是否在最终的sprint抛弃这个功能。