最近一两年写前端项目时一直都有接触 ESLint，很多文档和博客也一直都推荐使用开发者 ESLint，但是一直以来都没有好好地学习过它。最近因为使用 Nuxt 开发时 ESLint 缓存出问题导致浪费了半个小时，我越发觉得有必要深入地了解一下这个前端开发中最常使用的代码风格规范工具了。（不得不说，Nuxt 这个框架真的有点难用。）
ESLint 是在 ECMAScript/JavaScript 代码中识别和报告模式匹配的工具，它的目标是保证代码的一致性和避免错误。维基百科上这样解释的：lint, or a linter, is a static code analysis tool used to flag programming errors, bugs, stylistic errors, and suspicious constructs. 就是说 ESLint 是写 javascript 时用来分析静态代码是否存在语法错误、代码风格错误和可疑结构的工具。
之前说过想要学习 React，秉持着边学边记录的想法，我随即开启了这篇帖子。
我是一个 Vue 的忠实粉丝，虽然没有全部读过 Vue 的源码，但是对它的基本实现原理和大体的使用方法还是比较熟悉的。我自己思考过，我觉得我喜欢 Vue 大概率是因为我最早接触的前端开发框架就是 Vue。记得是 2018 年参加一项 SRT 的时候，为了开发一款简单的后台管理系统，我开始学习 javascript 以及 Vue。
当时我还是第一次接触脚本语言，对没错，我接触 javascript 比接触 python 更早一些。熟悉了 C/C++ 的继承机制之后，突然要接受 javascript 的原型链继承一时间有点缓不过来。但是后来还是被磨平了棱角，被迫接受了原型这一设计。为了开发 Web 应用通过一位学长的介绍接触到了 Vue 这个框架。我直接惊为天人，还能这样写？因为根据我更早之前的一些浅显的印象，Web 开发是分别要编写 HTML，javascript 和 CSS 三种文件的。现在用 Vue 一个文件就可以生成一个完好的页面，着实非常酷炫。也是在 Vue 这里，我了解到了组件、生命周期、全局状态管理、前端路由等等一些重要的概念，所以先入为主地对 Vue 有强烈好感也正常吧。
在上一篇博客《聊聊微信小程序及其框架》里面立了个调研微信小程序开发框架的 flag ，这篇博客就来填这个坑——我迫不及待地想要掌握一个能够“舒适编写”小程序代码的框架。
我之前提到我最想先要了解的是 WePY 和 uni-app 这两个小程序框架，WePY 是微信官方出品的小程序框架，uni-app 是使用 Vue 开发小程序的最火的小程序框架，但是这两个框架都让我特别失望。
微信很早就有一套专用的JS-SDK在微信客户端上面使用，其开放了录音、二维码、地图、支付等几十个 API，能够支持微信服务号的运转，当时大部分支付、扫码等功能的对接方都是这样的服务号。但是在 2016 年 1 月 11 日微信之父张小龙表示服务号还不够优秀，微信正在研究一个新的服务形态，起名叫做“微信小程序”。在 2017 年 1 月 9 日，第一批微信小程序低调上线，而选择这一天也是为了向 iPhone 1 代的发布致敬。
我很喜欢记录，就像首页那句话说的“有着记录的想法，没有记录的时间”一样：我喜欢把生活里有趣的、激发自己思考的事物都记下来，倒不是为了写给谁看或者写给未来的自己看，光是写下来的过程会让我觉得很好，不知道怎么用语言形容的一种“满足感”；但是在学校的时候事情实在是太多了，学习、社工、项目还有各种琐碎的事情让我根本没有时间把所想所见记录下来，所以也就有了这个博客里年更的情况出现了。
2019 年的 12 月 31 日，我在自己的非主流 QQ 空间发了一篇名为《别了，我的一零年代》的日志，回顾了一下自己的中学和大学本科时期的得与失，2020 年年底实在是太忙了，没能够再写一篇“年终总结”。不过现在想起来也不是很遗憾，因为 2020 年不是很能激起我的记录欲。好！在！已经研一，兵荒马乱的研一上学期也已经度过了，至少未来一年半内不会有太多课程上的压力，这样可以让我有更多连续的时间能够用来记录。这是让我非常开心的，我猜我今后会多写一些东西在博客上吧，应该会。
“活动宣传写个H5就可以了”，”学生节不如做一个H5小游戏吧，比如之前那种学堂路躲避乌鸦“……在这几年的学习和生活中我听到过很多次H5，也真正看到过、使用过、制作过H5，但是我对H5这一个词的真正定义还是不太了解。它给我的直观印象就是在手机上运行的、包含许多动画甚至音乐的纯前端/弱后端页面，最常见于微信群、公众号和朋友圈，或许这也是大多数人对其的印象。对自己接触的东西一点也不了解是不能接受的，所以要简单调查调查。
论文阅读: Role-Based Access Control Models, 1996
论文描述的方法简称 RBAC，基于角色的访问控制，是目前非常主流的访问控制方法。用户（User）、角色（Role）和权限（Permission）是论文中最主要的三个概念。角色和用户组这个概念很像，但是用户组仅仅只是一个用户集合，而角色则联系着用户和权限。说到底都是为了让用户获取权限来执行相应的操作，不管是加入角色还是用户组，都只是一个中间态。
RBAC0 是基础模型，是任何系统实现 RBAC 的最低要求。RBAC1 和 RBAC2 都包含了 RBAC0，但是分别加入了不同的特性。RBAC1 加入了角色层级特性，即角色 A 可以通过继承角色 B 获取角色 B 拥有的权限。RBAC2 加入了约束特性，控制用户对 RBAC 中不同资源、组件的权限。而 RBAC3 包括了角色层级和约束。示意图如下所示，其中基础模型 RBAC0 是实线部分。
在毕业设计时捣鼓了一会应用的持续集成(Continuous Integration, CI)和持续部署(~ Deployment, CD)，发现确实可以为自己省下很多力气：
之前在公司实习时所有的分支合并都会涉及到 CI 和 CD，当时为了让代码编译通过费了很多心思。虽然自己push代码的时候比较费劲，但是确确实实可以给应用的部署和可用性提供保障。
最近在看阮一峰大神的技术博客时偶然看到了Github Actions的入门基本教程，发现 github 把 CI 脚本商品化、组件化放到 Marketplace 里供用户挑选和使用是一个非常不错的思路，让 github 的开源文化更加吸引人了。
我把上面那篇博客看完之后发现其实和 Travis CI 差不多，或者说其实所有的 CI 系统都差不多。抱着接触新事物的热情，我还去看了 github actions 的官方文档，下面对我所了解到的一些信息进行一个汇总。
已经实习四周了，学院安排的实习期已经只剩下一周，但是直到这两天公司 Buddy 才给我安排了一个比较重要且连续的工作，让我有点左右为难：下周之后我到底还去不去呢？
之前四周的工作都是延续暑假前所做，多是一些较零散、不系统的碎活儿，其实这样的安排确实容易让人觉得枯燥无味，缺乏意义和价值。
“摸鱼”让我觉得内心有愧，如果要做自己的事情，为什么不回学校呢？
一周五天上班的日子让我分外珍惜周末的两天，因为周中下班回到宿舍已经快晚上 8 点了。这一晚上一般就会在我是要刷题，还是要看一些资讯，还是看 B 站这样的纠结之中过去，第二天有点后悔，但是回来之后又重复前一天的过程。究其根本，我觉得是因为我暑假想做的事情太多了。
- 实习
- 刷题
- 社工
- 上线小程序
- 写诸如这篇博客的东西
- 学习一些奇妙有趣的东西
- blabla
（我觉得这个引用框好好看
暑假我也更加清晰地认识了我的本质，我对不了解的事物很难提起兴趣，但是一旦喜欢某件事物之后就会开始不断的去了解去接触，就是这样一个循环。所以，我的生活好小啊。
看到手机上给自己的警言：“想的多了，做的就少”，这是高中时期自己给自己打气用的，希望自己能够心无旁骛地做自己该做的事情。
但是来到大学之后发现，没有明确的事情是那么的该做了，只有想做的事情比较明确，然而想做的事情太多，在纠结之中又会不经意掉入“想太多”的境地。
给自己定一个小目标吧，8 月里把心沉下来，否则这个暑假将和去年暑假一样浮躁。
对Python,Golang和C++三种语言GC机制的简单调查
在公司一项任务是需要调用Python的SDK爬取相关的数据信息，数据的量在10亿这个量级，故不能够一下子得到结果。
这个程序运行十来天的可能性比较大，但是问题来了，程序跑过一阵子（1小时）之后爬取效率明显降低。
重启之后效率恢复，这就让人有点不爽了，本来数据量就多，用初速度爬取也需要十来天，这样一减速得爬到什么时候呢？
通过使用top工具，观察到爬虫脚本在运行过程中占用的内存从800MB上升到了1.4GB，速度也随内存占用量的上升而减慢。（图片来自MacOS的top，与程序的运行环境中的top不太一样）
我猜可能是内存泄漏了，各种查资料之后用python的gc和objgraph进行程序内存使用情况分析。
虽然针对于爬虫程序的分析无果，但是对GC机制有了一点兴趣，于是稍微了解了一下。
下文的 GC 既指 Garbage Collection， 也指 Garbage Collector。
接触Python一年多，Golang九个月，C++是大一时OOP课上教授的语言。其实都只是了解了皮毛，仅仅停留在“会用”这个层面。