Week 2 - Wed. & Thu.

困，写在开头。

Wednesday

也就是昨天，Elian和Jonathan讲了Mockito，他们故意把mock搞得很有悬念，浪费了不少练习时间。对Mock我们比较熟悉了算是，但是还很不深入，比如annotation在Mockito里的用法及其优劣，准备研究研究。

Kai终于开始讲Database相关的东西了，我可能是头一次写Jdbc的代码吧，不过感觉还算亲切；SQL语句写得还是很顺溜，自己很开心。session开始一小时后，终于讲到Hibernate了，的确是头一次看到Hibernate的代码。原来Hibernate采用了object-relational mapping（ORM）的思想，通过annotation将数据库表和表间关系与对象和对象间关系映射了起来，同时对直接访问数据的底层行为进行了包装，这样我们可以通过操纵对象来访问数据库，不需要自己直接操作数据库连接和写DML（Data Management Language）型的SQL语句。不过台下不少人对数据库都不怎么行似乎，甚至有说从没弄过的，所以Kai一开始还想讨论第三范式，可一看根本不行，就从简单的让连起了。我比较有意见的是，关于Hbernate，这个session的主角，Kai只是不停的说，不停地翻代码，最终也没个practice，搞得大家挺困，我最终甚至连Hibernate在自己的程序中怎么搭起来用都没搞清楚，只有自己请教google了。

6点了，就在我要欢呼回去吃晚饭的时候，pecha kucha开始了。其实挺有意思，每个人20页PPT，串起来讲每页20秒不多不少，内容不限。就准备材料和presentation而言，是挺好的锻炼；对中国人又多了两项：说辞和应对问题，只是因为语言。

 

Thursday

上午Jonathan讲springMVC，dear god，幸好胡凯兄曾经给我们科普过关于spring的知识，我在Jonathan导演的现场剧中扮演spring（当然不是春哥，而是程序中的component），我要指挥其他角色的行为，比如初始化singleton的Services和DB，为controller注入dependencies，从dispatcher那把request引导到相应的Controller那去，在处理完请求后tear down创建的对象等等。Spring 3里的annotation很多（虽然我也只是看到old school代码里的spring没这么些东西），感觉annotation越来越受欢迎了，如JUnit 4、Mockito、Hibernate和现在的Spring。

比较遗憾的是课堂上我发现mac上的wireless network挂了，很彻底的，搞得没办法当堂完成tutorials，只能眼巴巴跑去pair看Tom在他那实现。中午吃了饭跑去求助IS那帮人，下午3点时伤愈出院的mac终于被送回来了。

今天和BA一起做Estimation联系，总共有两个，一是BA拿出一堆stories让dev来估计难度，标准是已经设定好难度的几张参照卡；二是假设共9对pair，拿出一部分stories让dev安排进三个Iteration。采用的方式很奇怪，圆桌边6把椅子，只坐5个人，只要有另一个人坐第六把椅子，那就得有个原来坐着的人站起来离开椅子。

我开始对这些事十分不明白，于是去问trainer们。

Elian告诉我椅子相当于token，持有token才能正式讨论，不过她没解释到底token轮转的规则是什么，事实上大家在应该谁站起和谁坐下的问题上确实很混乱。

我对第一次Estimation的依据很不明确，Julie提醒了我两个词：release estimation和iteration estimation。确实，这只是个release estimation，它的目的是让team过一遍所有stories，试图去scope将为这些story花费的effort，只给一个高中低难易度的区分。我原以为我们需要知道些story细节，或者推理stories之间的依赖关系，以此做为依据来断定stories的难易度，但不是这样的，Julie说release estimation时不需要考虑那么许多（那需要考虑什么呢？只是简单比比看?!）。我觉得这些stories都是比较固定functionality的story，对它们的估计其实并不能估算出我们将做出的effort，因为当project开始后客户会基于已完成的情况提出story更改或新的story，JK同意这种看法，他说等项目中间会re-estimate，这样应该能解决问题，于是我更觉得他们现在正在做的这种estimation不需要花太多时间了（他们讨论了1个半小时，在午饭时间，饿的我呀）。

我对第二次Estimation其实也不明白，我觉得这种为几个iteration而做estimation和plan需要考虑三方面的因素：customer values，stories dependencies 和 stable velocity。而他们似乎只是为了9对pair安排不同难易程度的stories到三个iterations里，有什么因素在考虑呢，问Errol，答曰只是试图去估计各个iteration做哪些story比较平衡，不是在为三个iteration里以什么顺序、做哪些stories而plan，好吧，我忍，不知道这些BA凭空想出来的story名字卡有什么好排的。问Elian他们BA怎么编出来的，她说还真有client，原来是Sumeet，Sumeet又哪来的需求呢？事先计划好，再对着BA们照着facebook当例子提出来的。唉，1个小时之后…… 看！外面暴雨好大，哗啦哗啦……

和Kai聊了下周项目的dbdeploy脚本的事，起因是发现项目里写了几十delta SQL脚本了，怎么最初安装时还得手动拷两行脚本去mysql执行以建立数据库？一定是当初脚本没建立在0基础之上，于是问题有了：如果项目做了半个月了，写了50个delta sql脚本文件了，突然发现种最初的相当于setup的工作忘记放进脚本之中，那应该怎么办？显然不能去把50个脚本文件重名个名（文件名都是以递增编号为前缀的，常常是连续的），然后在最开始加上一个“001_*"文件了事儿。Kai的答案是，database migration，我有点好奇，如何呢？和dbdeploy有什么区别呢？ 唯一的两点线索来自与formula migration和ROR里的数据库版本控制有个命令带migration，显然第一点没可能（废话），第二点其实是和dbdeploy很类似的但文件内容不同的东西（不是单纯的SQL脚本）。还是求助google大神吧，不过没能立刻找到什么简单明了的，决定研究ROR里的吧。另一个问题是production code如果客户上周的需求是删掉columnA，比如觉得Age对Student这个表没用处了，但这周后悔了，又要加上，那么那些原来的数据找不回来了不说，现在的Student表中Age列还不得不重新填，咋整？他的答案太简单了，我光荣的脸红下：首先不推荐在project online之后删除表的列；如果非要删，那别真删，那是死心眼，做个列的mapping就行了，把不要的列放在mapping之外，对用户就不可见了。不过这个情况还真是少的，哪个客户会轻易对自己的数据开刀呢？