论文阅读: 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课上教授的语言。其实都只是了解了皮毛，仅仅停留在“会用”这个层面。