工作福音
赞美工作的人。——在对『工作』的一片颂扬声中，在关于『工作福音』的喋喋不休中，我看到一种隐蔽的动机，这种动机与那使人们赞美公益的、非个人行动的动机是相同的：对于任何个人性存在（Individuellen）的恐惧。所谓工作，总是意味着高强度和长时间的工作；人们现在感到，这样的工作不啻最好的警察；它给每个人都带上了一副沉重的镣铐，使他的理性、贪欲和独立意识几乎没有机会可以成长。由于工作几乎用尽了所有的精力，所以，他的一切反思、筹划、梦想、忧虑、爱和恨的冲动都被迫退出战场，而只盯着工作为他树立的眼前的目标，享受着工作提供给他的容易的和经常的满足。因此，一个充满不断的紧张工作的社会也是一个更为安全的社会，而安全现在正被奉为最高的神明。——现在！多么可怕的现在！实际上，变得『危险』的不是别人，正是这些『工人（Arbeiter）』！到处都挤满了『危险的个人』！在他们的身后站着各种危险的危险者——真正的个人。
ーー弗里德里希・尼采，《曙光——关于道德偏见的思考》，第三卷，第 173 节
- 注文完了画面的计测 IE 出错 △
- p/g 画面评论 AB 测试 sid 位遗漏
- jq 版本弄错造成链接计测出错 ○
- g 页面购物车按钮 AB 测试中商品图片失效
- 活动码和优惠号互换 API 延迟错误页面失效
- p 分类级别类初始化改修遗漏
现在是2018年9月11日。前些天浙江大学文学院博士后陈新榜弟兄说我称自己眼里有光是一种骄傲。我并不觉得是这样。拥有希望并不是一种骄傲。但是，我现在还是很在意。因为纷争还没有得到化解。他也许是在指责我自以为义。
刚刚还看到了之前在纸上记下的一些愤怒的备忘：
1° 下周无视计划。按照顺序把被山口先生删掉的任务也做完。
2° 用 IntelliJ 的 Bookmark 标记自己的担心。测试的时候再一次全面深入地考察（Double Check）一遍。
3° 争取在下次小组问题回顾会议之前不犯错。如果下次会议之前没有犯错，说明 2° 的方法比较有效。如果在下次会议之前没有犯错，在会议上就说，”振り返りはあまり意味がないと思います。”
如果在下次会议之前犯了错，那就总结注意点。在会议上，单纯地叙述现象，并说，”問題を気にならなかった。”、”テストは足りないです。”
→ 实际上，这几个月以来我都没有犯什么错，也一直就再没开过什么小组问题回顾会议。我真是感到针对我个人满满的恶意。
被开发环境的设计实现验证的问题困扰了三天之久
设计、实现、验证，分别对应，调查、开发、测试。
（突然明白，日语中的「実装」实际上就是汉语中的「实现」，英语是「implement」。）
主要原因在于两点：
- 构建开发环境的经验不足、灵感匮乏
- 设计、实现、验证的思维的混杂
新的设计意味着要改变用户的思维惯性。所以，必须用极其鲜明的方式来表现，让用户能够充分注意到。
新的实现的灵感可能会提示新的设计。
好的设计，意味着，用户无需理解实现就能够很容易地很深入地理解设计。
2020/7/13 21:30
对于需求和实现的学习往往有三种方式：
- 对于需求细节和实现细节的对应关系，有相应的文档。
- 有概述的需求和具体的实现，需要自己根据实现中的具体细节去弄清所对应的需求细节。
- 有具体的需求和概述的实现，需要自己根据需求中的具体细节去完成所对应的实现细节。
- 有概述的需求和概述的实现，需要自己弄清需求细节和完成实现细节。
对于第１种方式，广泛的阅读比深入的阅读更重要。
第１种方式的最主要的效果在于提高交流表达的能力。
第２种方式的最主要的效果在于深入地掌握工具的运用方法。
第３种方式的最主要的效果在于深入地掌握工具的开发方法。
第４种方式是高度探索性的。
从第１种到第４种方式，学习难度越来越大。
所以，高效的学习策略是把学习任务逐级分解为较低一级难度的任务。
以 PayPay 的测试为例，最初还没有明确需求的时候，就开始尝试明确实现。为了解决方便地试验代码和记录结果的需求，从 Java/Spark Notebook 这个关键词出去，找到 Zeppelin。
因为之前有通过第１种方式学习过流处理的文档，所以这次很快就明确了流处理的需求。但是，在还没有明确会话化的需求的时候，就过早地尝试理解 Twitter 流处理的实例，并决定这次使用 Scala 开发。在此实操过程中，陷入各种与最初需求无关的具体问题中。由实时可视化的问题，提出可视化的需求，联想到 Zeppelin。Twitter 流处理的实例只满足了流处理的需求而不满足会话化的需求。以会话化、流处理、Spark 进行谷歌搜索可以得到更好的实例。
第４级向第３级转化的过程中，需求并没有充分的具体化，就过早地向第２级转化。导致任务过于广泛地发散。