实习日志

2017.9.7

组长说今天感觉经历了好多事情。

今天的安排是把最新的feature给manager demo一下。demo之前由于新requirements 来得晚，我需要在短时间完成，之后又因为种种原因我需要在今天结束之前完成几个requirements. 总之今天一天都在跟时间赛跑，不过challenge 都不大，所以我很顺利地完成了各项任务。

前几天预料到deploy到服务器上会有各式各样的问题，所以提前准备了一下，在ubuntu上建设好了tomcat, tomcat里也部署上去了一个简单war包并测试完成。对于apache配置的准备相信在以后的工作中会派上用处。

今天感受最深的是体会到了前几天文章中看到的一句话：“不要把自己当程序员，instead, 要把自己当设计师或者产品经理。“ 这言论的大概意思就是技术只是工具，不能沉迷其中，写clean code的最终目的也是为了减少开发的开销。减少开销，增加收益，这才是一个人劳动应该有的目的。

2017.9.4

新的星期，本打算用一个星期的时间把网站建设成https, 到了公司以后感觉这是个easy job, 所以就改变了期望，决定在两天内完成这个目标，谁知道一天就把事情搞定了。

我在公司的云服务器上装了apache, 按照网上的create self-signed certificate的方法，自建证书，并配置apache, 通过google和apache error log的共同努力，半天就搞定了https的建设，下一步就是等manager把公司的昂贵证书发给我，然后我建设到网站上去。

自己的项目slot今天完成了4x4的完美涂色表格，挺好玩的东西，我申请了发布，并给了几个体验权限，反馈还是很好的。

2017.9.1

一些工作另一位team member说他能解决，我就focus到其他方面了，今天想主攻的是Berkeley DB带来的dead lock问题。

问题源头是这样的。我有几个api, 他们共用同一个database, 每次request来，api会打开database，返回请求以后会关闭database。由于他们用的database是同一个，api1关闭database以后会导致api2报出很多null pointer exception, 原因就是数据库关了，原来从数据库里得到的pointer都变成了null。

dead lock本不是问题，一开始开发berkeley db的时候我是不关database的，只有web app关闭的时候统一关掉database, 这会导致数据丢失的问题。我之前想解决数据丢失的问题，然后想到berkeley db的官方文档里说你每次使用完要关掉database, 所以我就按照这个思路去改，结果就introduce a dead lock.

为了解决这个dead lock, 我把数据从本地的berkeley db转移到了remote 的MySQL, 有了一个第三方的数据库服务器，既不用担心数据丢失，也不会有死锁的问题，因为死锁有MySQL帮我解决。

转移到MySQL以后并不是可以高枕无忧的，每次api call都需要连接MySQL 服务器，这导致我的api效率很低，每次响应时间长达4秒，总结一下就是 The introduction of MySQL as a database causes unexpected latency with APIs.

在公司PE的帮助下，我开发了一个缓存类，每次应用刚开启的时候和数据库服务器sync一下，之后所有的操作都是在内存中进行，这极大地改善了效率，原来4秒的api 响应时间变成了现在的几乎瞬间反应。当然代价是数据丢失，因为我还没来得及写定时和服务器sync的线程。

感觉数据丢失和dead lock又是一对矛盾，和分布式系统的consistency vs latency一样。

2017.8.30

今天的主要objective还是要让一个页面更加friendly. 这个页面的载入速度有点慢，我想要在页面上加一点个progress bar, 让第一次使用它的人清楚地知道页面是在工作，而不是卡住了。

一开始开发时候是直接写Java的Servlet，于是前端的所有代码都是用java.io.PrintWriter print出来的，并没有使用现在流行的mvc框架，所以后续的开发会有一些困难。基于此我打算把这个后端驱动的模式改成前端API call，然后用Js渲染页面。

这个想法实践起来比想象中难度大很多，上个一星期的某一天我想要一步到位，用一天时间做好这个page, 后来发现一天时间只把API 做好通过了所有测试，前端都没有开始。今天主要的功能都在前端，但是碰到的困难也不小。

主要的困难是用Js渲染出来的HTML 是不属于页面的dom结构的，这就导致页面上其他的Js无法工作（我需要在渲染出来的表格上再做修改，没有dom结构就寸步难行）。

面对这个问题我想到最近在做微信小程序时候使用的数据驱动页面的方法，google了一阵，又和同事们讨论了一阵以后发现facebook的react库比较适合这么做。然而我犯了一个错误，就是在下午3-4点多的时候开始学习新的框架。通常学习应该放在上午，因为这个时候你的时间比较充裕，即使多学一点下午也能够补上进度。今天下午学起react就直接导致我整天只完成了半个objective. 当然这和身体状况有点关系，但这样子的错误以后要尽量避免。

2017.8.24

做的项目由于功能强大，它即将扩大适用范围，即又有两个人要用我的应用了而且他们远在大洋彼岸，使用的问题不能够及时反馈给我，我也没办法及时给他们使用指导。说实话我有些panic, 这是对设计的一个挑战，HCD(Human-centered Design)的需求异常强烈。

今天先改良了一下一些数据存储方式，保证即使网站被异常关闭，重要信息也能够保留下来，而不是像之前的一个Ctrl-C就删掉了所有数据。

2017.8.18

TGIF! 谈一下knowledge in the world 和knowledge in the head.

The Design Of Everyday Things 一书本应该是讲设计的，但却花了很大的篇幅在讲knowledge in the world 和knowledge in the head的区别，阅读的时候很不解，但看完以后，自己着手设计起自己项目，就发现这两个概念非常重要。

拓展一下词汇量！

今天写了一些脚本，一个是自动把ticket信息的源头从CDT改成本地文件，一个是把它从本地文件改成CDT. 这样的做法可以由上文的两个概念来解释。我们先来解释一下上下文。

最近在开发的应用，它的核心功能是收集总结测试的结果，然后把结果反馈到Jira上。收集流程的第一站就是要知道哪些domain被测试到了，production上的应用需要在CDT找到所有的ticket, 从这些ticket的信息中知道本次收集需要关心的domain.

当我需要测试新功能的时候，不应该在真实的ticket里面加comment, 这是deprecated的，因此我自己开了两个专门用来测试的ticket, 并指定好它们各自需要哪些domain, 这些设定信息就保存在本地的文件中。因此测试和production需要两个不同的ticket信息源头。

这个切换信息源的需求其实早就出现了，由于所有需要这个信息源的类都是统一从一个类中找到这个路径的，所以我每次测试前就把这个类修改一下，测试完上production再改回去。操作很简单，一直使用了很久。“每次上production”之前需要改ticket信息源头，这是一个很容易记住的knowledge in the head.

随着项目的进一步发展，production上的一些地方需要用到我本机的ip地址，然而测试的时候需要在同样的地方使用localhost, 因为浏览器里输入本机ip是访问不了localhost的。这就让每次从测试状态切换到production的过程比较繁琐，这种手动改的过程已经持续了一两天了，我觉得这个knowledge in the head已经过于庞大，我需要认真对待了。

分析一下，我有两个选择，一个就是花时间记住这个流程，比如在纸上多抄写几遍，强行让自己记住，还有一种方法就是把流程写在纸上，然后贴到计算机屏幕。第一种情况优势在于一旦记住，该流程会进行地很快，相比于看着纸质指令的逐行操作，劣势在于我需要花时间去学习这个流程，而且这个流程在以后可能还要改，一旦改动，之前为了记住流程而花的时间就浪费了。第二种情况正好相反，优势在于写写流程很简单，比强记容易得多，劣势之一是以后的流程进行速度慢，之二是太占空间，我的办公桌空间有限。那么有没有更好的方法呢？

有的，就是自动化的脚本。开发脚本的一个好处就是让我接触到了Java nio, 这个库据说很强大，我很高兴今天能够接触到。使用脚本的成本就是需要知道切换之前要跑一下脚本，不过这个成本换句话说就是要知道切换之前有个步骤，这是在之前各个方法中都存在的，所以并不是什么大问题。脚本的另一个好处就是把knowledge in the head转化成knowledge in the world, 我知道的切换的步骤可以用代码来表达，之后我就不需要再去记住它们了，我的精力就可以转移到更重要的地方去。

Automation Rocks man!

2017.8.17

今天有一个user story准备完成。主要收获是为了实现JavaScript开发的测试驱动，用Node.js 安装了Karma 工具。算是我对Angular框架的第一次使用。测试驱动会有很多overhead的消耗，但有了它，编程更稳健。

今天最后的dilemma在于不知道新的story是用原有的我讨厌的servlet 输出所有前端的方式继续更新系统，还是start from scratch用 Spring MVC重写主要功能。走在回家的路上有了选择，在原有的基础上给artifact们加id，这样不需要“革命“式的修改，简单加一些轻量级API就可以完成这个story了。