年终总结记录人成长和发展的历史，而，人有肉体和思想，只有思想的进展，我们才算有进步，才有历史可言。
而人的思想分为「能力」和「态度」两个方面，能力创造价值，态度调配价值。只有将创造出来的价值「合理调配」，才能成为是一身心健康的人。我们一直以追求着这个目标，找到能力和态度合理的调配点，成为健康的人。
在2019以前，我一直被认为是一个“不健康”的人（包括我自己都这样认为，至少是个非主流），主要原因，对照上面的历史哲学的结论，我的社会生产能力没有达到一个合理的水平[注]上，创造的社会价值很小；态度方面，我自知问题所在，态度还是不错的，但由于生产能力不足，无价值可调配，从主流价值上看，综合起来，我依然是一个“不健康”的人。提高实际生产能力水平，迫在眉睫。
注：什么叫合理的水平，和合理的调配点，依然需要进一步分析，例如我不是没有能力，只是我的实际社会生产力和我的年纪不相匹配，个中有很复杂的个人，生物，和社会原因。
为了顺利的再进职场，最近一个月来都在做有目的训练，训练自己的实操能力（因为这是我的一个弱项——前端项目经验薄弱，加上在特长上，编码和分析更倾向后者），而不是任意的自由的学习。然而，在具体的学习主题上，除了参考和对比常规面试题，找出一些基础主题外，对什么是“最有价值”的学习主题，我没有指引。
其实我一真很相信自己的直觉，但是难免有盲区，和价值冲突，我不清楚明天面对面的考官他希望我具备什么能力。我的担心不是没有原因的，因为软件开发技术岗位向来都是既难招亦难找，企业不知道怎么考核应聘者实力，求职者不知道学什么最重要。
这里边有一个推理，在面试和通过面试的情景里，假设把企业，和求职者分两类：
那么会出现四种面试情况：C1P1 C1P2 C2P1 C2P2
如果假设成立，那么通过面试的只有 C1P1 和C2P2，但是真正算成功面试只有C1P1，因为只有这种结合才是良性的。
有一种引人思索的事实，就是在职的开发者不必全知全会，就可入岗；这个事实存在合理性的前提是：
所以更实际的情景是，你的专业技能越来越完满（通过有效的学习），从团队的一个角色跃进到另一个角色。
作为一名JS入门者，如何进阶，从一个次要的角色转变为更有价值的角色，对他们来说非常重要。我以为 Ben McCormick的《Ten Things A Serious JavaScript Developer Should Learn》作了一个尝试，尝试列出了JS进阶的技能清单，我觉得很有趣，于是略译出来。
本文摘译自MongoDB官方迁移白皮书《RDBMS to MongoDB Migration Guide》。
关系数据库作为企业数据管理系统的技术基础已经有四十年了。但是，我们今天构建和运行应用程序的方式，加上新数据源和用户负载的持续增长，正在 将关系数据库推向超出其极限。这会抑制业务敏捷性，限制可扩展性，并使预算紧张，迫使越来越多的组织迁移到替代方案。
从关系数据库迁移到MongoDB过程中最根本的变化是「数据建模」的方式的改变。
与任何数据建模练习一样，每个用例都是不同的，但是对于大多数Schema迁移项目，有一些一般的考虑事项。
算法 对编程专业 很重要大家都认可，但怎么个重要法？算法好难学，怎么入门？这些问题则是对大家来说更为有意义的一个问题。
很多人，和专家都推荐《算法导论》这本书，有点捧为经书的意味。我读了一下以后，我觉得，名不符实。叫导论实有误导的嫌疑，更不能算入门书。我个人认为此书有以下一特点（不足）：
好书应该行文流畅，深入浅出，这两条此书都不合格。就深入浅出而言，浅出是绝没有的，深入的话，深入到哪里去？数学内容这么多，可是算法的核心是数学（数学证明）吗？这一本书由几位从事计算机科学教学研究的应用数学家编著的，不是算法专业（也没有这个专业）的专家，也不是教育家，阅读体验可想而知。（以上只是个人初步的分析，或许有偏颇）
React 是第二代Web前端UI开发框架，最新进展的hook抽象也算一个重要里程，但还不能算第三代。理解这句话需要很多基础，React作为专业工具是众多基础的交叉应用。
写年终总结已经成了我一年一度的功课，自2008年起已经写了12年，但即使听起来很有写总结的经验，但对于写年终总结，我依然有一些困惑。主要有两个困惑，第一，要不要写，值不值得写，这个问题在今年年终我特别忙的时刻反思了好久；第二个问题是，有没有写作的技术。
其实第一个的问题，我默认的答案是肯定的，所以我在12月第一天就提醒自己注意分配时间，因每年写总结都是收获巨大的，无一例外，但是我最近时间很紧张让我产生了犹豫，我需要更多确切的证据来说服自己写总结。
现在我已经把今年的年终整理下来了，我的新理据是，如果一年里「发散性探索」太多，不作一次综合性总结，那这些探索有可能白费。因为人会淡忘，下一年有下一年的任务，上下文切换成本很高，回看一下两年三年的年终总结和对应的研究碎片就会有体会（这里揭示了写总结的策略或技术，就是写什么，多久总结一次，后面小结）。这种自学经历有大量发散性思考的话，都需要有一次总结，不然自学不完整。一句话，收获过去，并以此为基础开展新的未来，总结是我们成长的成果，也是美好未来的基石。无论多忙，总结还是要抽时间写。
webpack 这个工具在前端社区异常的流行，以至于我在一年前就简单的研究过（看这里 ，和这里 ），当时发现webpack在无意中提出了「Web模块」的概念——任何web app组成都可以是模块（JS模块是一种），对其进行依赖跟踪，当在发布时可解释最新依赖后打包出最新版本。「Web模块」的概念确让人耳目一新，不过由于一直没有参加具体商业项目，对 Wepback 没有多少经验，也谈不上有太深刻的认识（包括本质和意义）。
最近正在着手做一些实验项目，开始触及项目构建。读了《Setting up an ES6 Project Using Babel and webpack》，发现 webpack 的目标就是 给现代JS项目开发引入 构建 一步（ introduce a build step into your process），这个观点我觉得很关键，和深刻。
最初的JS项目开发是比较简单的，纯手工，开发和构建（编译）混在一起。但显然，当项目规模增大，手工需要转向自动化。 然而，什么东西需要自动化呢？这个问题针对JS项目（Web程序结构很复杂），初学者具有异常的困难。所以学习使用 wepback 一开始是不容易的。
首先明白一点，编译（将一种码转为另一种码）只是构建的一步，模块打包也是一步而已，而自动化构建的具体任务（WHAT）和过程顺序（ORDER），根据项目性质的不同，工作流（WORKFLOW）不同会有不同。例如，项目使用了不同CSS架构方法，那「CSS样式开发」的流程就会不同。
我们爱有经验，尤其是丰富经验，包括生活经验，和工作经验。因为经验能扫除阴暗、未知和危险，能给人安全和幸福。然，什么是经验？丰富经验如何获得？最近的学习发现，原来 我们开发者社区常讨论的 「模式」 就是工作经验的一种表现。掌握某种作业模式，就是获得了某种经验。「经验」的元知识，转向了「模式」的元知识。
那什么是模式呢？我们可以从一些常见的「模式观」来看看当下的通识。
在开发者社区最流行的「模式讨论」莫过于 设计模式了。但是其实 设计模式 只是编程模式（编程经验）的一种，不代表所有。而且我发现设计模式的常识理解不够准确。这里，我们先从设计模式的一般定义开始，再经 代码模式，语用模式 等特例，尝试总结一下，什么是模式，从而了解获得编程经验的可能捷径。
JavaScript的基础打得够扎实了，开始关注 TypeScript。在读到一些对比文章和图书导论后，我的第一直觉是，TypeScript和JavaScript的关系就像，OOP和FP，CSS 里 flexbox和NP的关系相似，它们不是互相吃掉谁的关系，是完成同一种任务的两种特别设计的工具。也就是说，TypeScript不是替代JS，而是用来开发不适宜使用JS开发的项目。这里理解的关键是，编程语言作为一个工具（一种比 编程范式更高级别的工具）是可以如何被设计的，就像编程范式的两种不同设计思想，产生OOP和FP编程。
编程语言作为一种工具，它有一个类型系统（typing）的属性，这个属性影响你以何种方式编程（编程算法的分析和表达），这个工具属性影响你编写程序（任务）的效率和效果，包括设计，分析，开发和维护等任务。
我觉得这篇文章（《TypeScript vs JavaScript: A Fight for the Web》）比较精简，略译出来。
工程就是由专业分工不同的工程师协作完成的，每个专业都有自己的专业技能要求，和专职任务。那，我们平时常说的前端开发者，他的专业技能是什么呢？又负责怎么样的专业任务呢？这个问题非常重要，它对求职者准确定位自己的学习目标，和面试官准确锁定合格候选人都有重大意义。
写作前文《不参加工作获得“三年经验”的一些策略》的契机，是我花了很长时间为前端开发打下基础，结果却被一个“缺乏项目经验”拒于门外后，反思如何获得所谓经验，并且开始发现那两本书很有参考价值，故作一分析和推荐。不过，那两本书虽然很薄，消化读通并不容易（后续会写文章介绍）。而，更关键的问题，那两本书的内容在丰富我们的开发经验上起到怎样的作用，这还要进行一步的分析和归纳。
关于面试官想要的“经验”，我在前一文给出一个初步的定义，还给出一些没法参加工作情况下获得与“三年经验”相当能力提升的策略[em]。然则，前一文其实还没有探讨完毕，例如 面试官想要什么样的经验，什么叫三年经验，经验可以用时间来衡量吗？
其实面试官要求所谓“丰富经验”是指，你作为专业开发者，能完成甚至最好高效高质量的完成自己的专业任务，只是由技术岗的困难而出现种刁难求职者的现象。所以，核心问题还是说，辨清前端开发者的专业任务，和完成它的专业技能。在有了这个前提之下，我们才有评估“丰富经验”的可能性。
求职需要求职者具备一定的经验，这是常识，因为商业公司不是培训机构，更不是慈善机构，个人和公司是一种互惠的合作关系。但是，对于刚入行（例如大学生）的人说，不参加工作就没有实际经验，又怎么拿到公司的offer呢？本文是写那些（和我现在一样）转行的，刚入行，或是非科班出身的求职者看的。
十月底我自觉重新进入职场准备的差不多后，慢慢开始投递一些职位申请，每天三两个申请。一周多了没有接到面试电话，有朋友看了我的简历后说，我的简历里最近三年的空白是硬伤，没有项目经验会处处碰壁。听了后，我才正式思考「经验」这个问题。
在没有工作的前提下如何获得“TMD经验”，不只是一个笑话（看这个图），对刚入行的人（包括像我这样的转行的，或非科班出身的）来说是很现实的问题。但反过回来想想，经验不也是知识吗？亲身经历只是获得知识经验的一种方式，不是唯一方式！间接经验，抽象经验不也是经验？可见，有关什么是经验，如何获得有价值的经验存在认识混沌。