年终总结记录人成长和发展的历史，而，人有肉体和思想，只有思想的进展，我们才算有进步，才有历史可言。
而人的思想分为「能力」和「态度」两个方面，能力创造价值，态度调配价值。只有将创造出来的价值「合理调配」，才能成为是一身心健康的人。我们一直以追求着这个目标，找到能力和态度合理的调配点，成为健康的人。
在2019以前，我一直被认为是一个“不健康”的人（包括我自己都这样认为，至少是个非主流），主要原因，对照上面的历史哲学的结论，我的社会生产能力没有达到一个合理的水平[注]上，创造的社会价值很小；态度方面，我自知问题所在，态度还是不错的，但由于生产能力不足，无价值可调配，从主流价值上看，综合起来，我依然是一个“不健康”的人。提高实际生产能力水平，迫在眉睫。
注：什么叫合理的水平，和合理的调配点，依然需要进一步分析，例如我不是没有能力，只是我的实际社会生产力和我的年纪不相匹配，个中有很复杂的个人，生物，和社会原因。
为了顺利的再进职场，最近一个月来都在做有目的训练，训练自己的实操能力（因为这是我的一个弱项——前端项目经验薄弱，加上在特长上，编码和分析更倾向后者），而不是任意的自由的学习。然而，在具体的学习主题上，除了参考和对比常规面试题，找出一些基础主题外，对什么是“最有价值”的学习主题，我没有指引。
其实我一真很相信自己的直觉，但是难免有盲区，和价值冲突，我不清楚明天面对面的考官他希望我具备什么能力。我的担心不是没有原因的，因为软件开发技术岗位向来都是既难招亦难找，企业不知道怎么考核应聘者实力，求职者不知道学什么最重要。
这里边有一个推理，在面试和通过面试的情景里，假设把企业，和求职者分两类：
那么会出现四种面试情况：C1P1 C1P2 C2P1 C2P2
如果假设成立，那么通过面试的只有 C1P1 和C2P2，但是真正算成功面试只有C1P1，因为只有这种结合才是良性的。
去年总结，我在展望新年时做了一个小小的预言，就是2019年会重新进入职场，而直到写年终总结为止，未兑现结果。对于这个事实，我想说的是， 其实一直以来我都是个看重过程实质，而轻视表面上结果的人。比如说，开发者的实质就是技术水平，2018年底，我的软件开发水平是稳定的，随着学习会稳步增长，但是不会突飞猛进。能力是我个人的，进展也是我个人的，跟进不进企业，没有关系。进了企业公司，我只是多一份收入，学习的方向会有所调整，仅此而已，正所谓幸福不会突然降临，我的人个水平，不会因为进了集体有某种跳跃。我不担心是否在职这个事实。
再说，进入了集体，有了保障也会失去一定的得个人自由，商业资本不会让你按自己的想法随意创造的，商业资本会让你用个人自由来兑换收入。 总言之，2019年我个人专业水平是有很大进展的，进职场也是可见未来内可期的。
有一种引人思索的事实，就是在职的开发者不必全知全会，就可入岗；这个事实存在合理性的前提是：
所以更实际的情景是，你的专业技能越来越完满（通过有效的学习），从团队的一个角色跃进到另一个角色。
作为一名JS入门者，如何进阶，从一个次要的角色转变为更有价值的角色，对他们来说非常重要。我以为 Ben McCormick的《Ten Things A Serious JavaScript Developer Should Learn》作了一个尝试，尝试列出了JS进阶的技能清单，我觉得很有趣，于是略译出来。
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经验”，不只是一个笑话（看这个图），对刚入行的人（包括像我这样的转行的，或非科班出身的）来说是很现实的问题。但反过回来想想，经验不也是知识吗？亲身经历只是获得知识经验的一种方式，不是唯一方式！间接经验，抽象经验不也是经验？可见，有关什么是经验，如何获得有价值的经验存在认识混沌。
对刚接触JS的人来，「偏函数」是一个让人困惑的概念，其实「偏函数」指代的不是一个特殊功能的函数，而是 一种有目的函数式编程（功能编程），这个目的可概述为，将一个目标函数 Fo“偏化”（什么叫偏化，本文后面会讲），简化对Fo的调用（Fo功能的使用），从而提高代码维护质量。
与偏函数一样高度相关的，同样让新手困惑的是，柯里化函数。它们的相关在于，都是对一个目标函数Fo进行某种改造，只是改造的目的不同。
理解偏函数和柯里化函数的实质 需要很多基础，偏函数是柯里化函数的理解基础（例如参数application），而「高阶函数」是它们的基础，更基础的是「函数式编程」，当然还有一个终极的基础，「编程」是什么。
函数式编程 是一个很大的题目，不容易讲清楚；「编写高阶函数」是 函数式编程 的重要特征，同样高阶函数也需要很多解释。但是，我们可以从以他们为基础的应用技术——偏函数技术——的实例，比较具体的了解函数式编程的实质和意义。
关于偏函数技术的应用例子，我自己不写，略译此文《How to use partial application to improve your JavaScript code》作为引子。