代码在这里：https://github.com/vcycyv/react-redux-typescript-saga-webpack-springboot-jpa-pomotodo 

使用方法：

1. clone/download the project

2. run "gradle wrapper"

3. run "gradle build" (It will download jar files and js modules dependency)

4. Before importing the project into IDE, comment out "//include 'src:main:frontend" from settings.gradle

5. Import gradle project to IDE. (I use eclipse)

6. create a postgre db named "pomotodo"

7. Start the mid-tier by running Application.java

8. UI development 

   8.1 For projection, navigate to /src/main/frontend and run "npm run build", and go to localhost:8080/pomotodo 

   8.2 For development (hot reloading), navigate to /src/main/frontend and run "npm start", and go to localhost:9090 

使用redux-saga的好处是为了side-effect, 比如下面代码中，const tasks = yield call(ApiTasks.listTasks); 调用后端服务， 

export function* listTasks() {

    const tasks = yield call(ApiTasks.listTasks);

    yield put({

        type: LIST_TASK_SUCCESS,

        tasks

    })

}

再下面一行的yield put语句dispatch了LIST_TASK_SUCCESS这个action，payload就是REST API 返回的数据tasks.

计划继续开发这个项目，最终做一个番茄时间管理的工具。感兴趣的朋友可以在github上star 这个项目，下次可以随时在“your star”中找到它。

开发经理的职责是确保软件产品按时保质发布。流程也为这个目标服务， 但流程本身的作用很有限。软件开发流程理论经历瀑布式，迭代式（RUP, 又称统一软件过程）以及现在的敏捷开发（敏捷在现实中几乎就是scrum），理论越来越成熟完善，但落地执行又不简单。 大量文章都在分析为什么敏捷流程在很多开发团队不起作用。比如最近看到 为什么敏捷开发在亚洲实行不了 里说， “敏捷开发需要大家当面直言问题所在，而这有悖于亚洲文化，因为亚洲人特别注意对别人表示尊重、给别人留面子，这一点与西方文化特别不同，而西方正是敏捷思想的发源地。” 从自己的亲身经历看，这纯属扯淡。讲到留面子，和稀泥，打太极拳，老美一点儿也不输给中国人。流程只是个工具，能否因地制宜执行得好，开发经理起到决定性作用。没有普适的流程，针对一个特定的团队，只有合适的流程。 全栈型的经理比较容易领导团队做正确的事情并做得够快。  能做到这一点，是不是scrum都不重要。他不必在各个方面都是专家，但至少需要能预见技术上重要的风险才能及时采取措施处理。一些技术决定对项目成败有关键性的影响，比如技术选型，搭建软件应用的架构，包括分层, 模块化，secruity, transaction, exception, audit，自动化测试等等。开发经理不必把这些工作都承担了，但至少需要把关，保证这些核心的工作没有明显疏漏。因为最终为产品发布负责的还是开发经理自己，而不是某个犯了错的程序员。不全栈，把关自然就不全面。

开发经理的各项工作中，我认为最重要的就是面试招聘。招对了人，工作中即使遇到棘手的问题，技术好素质高的队员自己就解决了。团队不怕小但要精，队员必须能独当一面。不论前台后端，经理至少应该具备足够好的技术品味过滤掉不合格的应聘者。乔布斯有个观点，一旦招了庸才，两年后，就会轮到庸才做面试招聘，很可能再招进来的还是庸才。如果开发经理不全栈，面试就要靠运气了。反过来说，资历好而水平差的程序员，也可以靠运气进好公司的。

程序员为story估时间（story point）的时候，会不会虚报呢？如果认为scrum的打牌可以避免虚报的话，可以看看上面关于留面子的讨论。即使把story的分配放在scrum打牌之后，经常大家心里已经知道哪个人做哪个story, 比如feature enhancement的story自然是这个feature之前的owner来做。打牌的人很容易会“做好人”倾向于多估时间。（再说一次，这不是中国特色，是人性）心理学有个有趣的关于撒谎的讨论，撒谎的前提是1. 我知道 2.你不知道 3.我知道你不知道。如果经理在产品某项技术上是小白，就容易出现估时间虚报的问题——这样的事情我亲见过很多次了。全栈的经理自然不会被糊弄。

程序员经常会在一个技术问题上产生不同的意见，这很正常，技术上很多事情本来就要做取舍。这时候经常需要开发经理介入做决定。经理做合理的决定不但对项目重要，对队员的个人感受也重要。决定不能是随机的选A或选B, 需要有决定的依据。程序员往往都有点小骄傲，经理技术上捉襟见肘的时候，程序员就容易想，“你还不如我呢，凭什么做决定。”

开发经理需要做coding的工作么？我认为是需要的。 英语里有句谚语， He that would command must serve。至少也要做比较多code review的工作。评价队员工作效果是开发经理的重要职责之一。技术不全面的经理经常依靠听队员自我评价（吹牛），数代码行数等这种不靠谱的方式评价工作。错误地认同或不认同严重影响团队氛围。身先士卒的经理容易长期保持住团队良好的氛围。我没有能力定义什么样的氛围才算是好的，起码，我带团队时，成员互相之间心存善意。

澄清一下自己观点：经理一定要全栈或技术精湛才能带好团队么？不是，但是很多管理的难题在全栈的经理眼里都不是问题， 比如上面提到的评价队员工作。带不好团队就无法好好职业发展么? 不是， 我见过太多靠吹牛，人事等各种非技术技巧成功哄骗二线三线经理的了。管理的路越往上走，技术越不重要，而政治越重要。问题是，作为程序员或开发经理，你的目标是把项目做好还是获得上级认可？我觉得这是职业价值观最根本的分歧， 但， 不想讨论。

最近的一年回了三次丹东，其中两次是带着大猪和老虎儿一起回去的。每次老虎儿都跟爷爷奶奶玩儿得很高兴。虽然他们不常见面，血缘还是能瞬间拉近他们，很奇妙的事情。大猪坚持十年如一日地傻乐呵，开始喜欢上唱歌，最频繁的时候一周唱好几场KTV，比职业歌手还辛苦...我跟她说，她的性格很好，如果没有嫁给我，她跟很多人都适合；而我性格不好，适合我的人很少，能够有她是很幸运的事。然后，她就常说，我跟她在一起我多幸运啊。真是一点儿阳光也不能给她，要不然控制不住她的灿烂。老虎儿越来越聪明了，常会说些令人惊讶的话。精力无限，春节回家睡了三个晚上，最早的一天是11点40睡的。不过，他太爱哭了，还有半年就要上幼儿园了，爱哭鼻子估计要把老师折磨死了。

大猪和我都得到了升职，大猪做了副处，我做了manager。从表面上看，应该是挺殷实的家庭，但其实我们俩都是升职不加薪。加入SAS时，决没期望会在SAS工作五年这么久，还是很感谢Emily一如既往的支持，最近的一年和以往一样，很多愉快和不快，很多抱歉和感激。

今年用过的两个密码是thank you和principle.

过去的一年，有多少事情会被永久的记住，假如这些事情是本该忘记的，忘记之后又有什么其他值得我记得？

视频文件在：https://docs.google.com/open?id=0B22ayLe4teeYQm56QnhaWkUxM2s

ppt在：https://docs.google.com/open?id=0B22ayLe4teeYdEhsMkItTk16UDg

有人说google drive上不容易下载大文件，建议压缩一下，但是我不太会用视频压缩软件，压过之后效果不好了，倒是也能将就着看：

1. 老婆说，她工作压力挺大的。我说，我来看孩子，你快去忙吧。老婆说，她不去，她压力最大的地方就是不知道该忙什么….

2. 我拍打儿子逗他玩儿，老婆不喜欢我这么逗儿子，威胁我说，你再打我儿子，我就打你儿子了啊。我：……

3. 老婆爱抚儿子的头，不无得意地向我炫耀，“这小家伙是从我肚子里生出来的，你能体会么？”，我回答，“这小家伙是我射你肚子里的，你能体会么？”
4. 老婆把腿伸给我，说，"帮我抻长点儿"，我装模作样抻几下，她把另一条腿也伸过来，"这条也抻抻。"