希望能更加有计划的度过吧，避免不知道做什么而浪费时间。
其实做计划也是一门学问，如何更好地制定计划以能够在能力范围内实现，并且愿意去实现。发现“九宫格”的形式制定计划很多人在使用。
即制定八个大方向，在每个大方向上制定细致的action。
去年“简单”的两项，实质上没有明确的目标，也没有可以衡量的标准，导致没有动力也没有方向去做，陷入迷茫的境地。
基于此，尝试制定明确的目标，看能否做到。
A: “这个接口我传个 JSON 给你，格式是这样的 '[1, 2, 3]'”
B: “等下，这不是数组吗，JSON 应该有键啊，类似这样才行'{ "key": [1, 2, 3] }'”
A: “不，这就是 JSON 格式的数据”
B: “啊，是吗？”
如果你对上面的对话也心存疑虑，可以继续往下看。
本文中的写作均指技术人所写的博客等文字。
作为一个程序员，我们无时无刻不在写作。描述所做项目的业务文档、推广开源项目的使用文档、记录日常的笔记以及输出理论的博客等等。
我们写得如此频繁，从未感觉到”痛苦“，题目是在瞎扯吗？不，因为我们从没有以”正确“的方式来写。
下面从作文、修辞和论证三方面说明为什么痛苦，以及如何解决。
在 10 小时前，我还对kotlin、spring-boot以及gradle不是很了解，但现在已经知道该如何使用它们运行一个简单的CURD应用了（或者说玩具更合适？）
虽然网上已经有很多比我写得更好的教程，不过自己写一遍能够加深印象，并且从初学者的角度记录，所以这篇笔记适合和我一样，之前没有接触过java、spring等等这些后端相关知识的人，或许能够有所收获。
工作了一段时间后，想在前端领域有更深入的学习，购入了这本《前端架构设计》（下称本书），看看前端架构是什么、怎么做、能带来什么好处。
下载后迫不及待的打开阅读，两小时后就扔一边再也没有打开过了。本书没有解决我的任何疑问，作者提出的架构，在我理解中更多是“工作流程”，
前端架构是一系列工具和流程的集合，旨在提升前端代码的质量，并实现高效、可持续的工作流。
这是作者给前端架构下的定义，这些具体是指什么呢？下面分别从“代码”、“流程”、“测试”和“文档”四个部分——这是作者认为前端架构的核心——进行讨论。
这篇笔记的来源是和一个正在学习前端的人聊天衍生出来的。他说他并没有将太多时间花在 CSS 的学习上，理由是有 bootstrap 就够了。
但是我个人看法却很不一样，也不能说对错，只是一个看法而已。
首先要了解 bootstrap 适合在什么场景使用。
Bootstrap 让前端开发更快速、简单。所有开发者都能快速上手、所有设备都可以适配、所有项目都适用。
这是 bootstrap 的官网对 bootstrap 的描述。“所有开发者”意味着包括非前端，既然非前端都能够快速上手，那前端开发者使用 bootstrap 的优势在哪里？答案是 bootstrap 并不是给前端开发者使用的，或者说，打开方式错误。
模块化是现在编写 JavaScript 的必然选择，而模块规范和我们如何写模块化的代码有很大关系，比如AMD规范与CMD规范，而这些规范具体是指什么呢，下面以仿照sea.js的源码自己实现一个简单的模块加载器来具体了解CMD规范。
先来解决开始值与结束值单位不一致的问题。
假设动画元素初始宽度为300px，现在需要将其改变为50%，这就肯定需要将单位与值进行转换了，计算300px是百分之多少，或者计算50%是多少像素，这都和父容器宽度有关，所以首先是要获取到父容器了。
但是，velocity并没有获取父容器的宽度，而是将动画元素的宽度设为10%，再获取到宽度则为父容器宽度的10%，再除以10就得到比率。
用实际例子来说明，假设父容器宽度为1314px，动画元素宽度为300px，首先是将动画元素宽度设为10%后使用getComputedStyle得到宽度为131.4px，再除以10就得到13.14，最后300/1/13.14得到300px占父容器的百分比。
而这个值，恰恰是300/1314/100也能够计算得到的结果。