the-thought-of-yii2-rbac

YII2的rbac思路

最近在做一个基于yii2的项目,需要用到权限控制的功能,于是考察了yii2原生的权限解决方案。

一般来说,权限系统有简单做,也有复杂做。我在做的时候,主要有3个点考虑:资源、用户、关系。资源有粒度的概念,比如某种资源、特定资源、部分资源等。用户也有粒度的概念,单个用户、角色、用户组等。而关系,就是描述用户与资源之间,用户是否能够执行某个动作,典型如增删改查。

总体来看,yii2的原生解决方案实现得比较简单,不过思路比较轻巧。

特性

因为我考察的是基于数据库的解决方案,所以下面主要围绕这个实现来说。这个权限控制的特点:

  • 基于角色模型,role base access control
  • 支持角色(Role)、权限(Permission)、规则(Rule)三种控制层次
  • 角色可以继承
  • 一个用户可以拥有多个角色
  • 不支持直接赋予权限给用户,即用户只能有角色,不能直接拥有某个权限
  • 规则只能添加到权限上

《解密无印良品》读书笔记

背景

一直非常喜欢MUJI这个牌子,喜欢这种能够平衡商业和艺术的生意。偶然的机会,在公司的书架翻到松井忠三前辈的写的《解密无印良品》,才有机会了解到muji的内部运作。

以前我的老板跟我说过,“你看那些非常优秀的游戏,背后都是复杂的技术做支撑。”翻完这本书,发现MUJI这个公司的建设过程也印证了这个道理。

建立高效的机制

这本书里面,一再强调的观点,是说,相对于相信传统依赖于人的机制,建立起基于规章制度的机制更加能够保证一个企业的高效运转。

作者就任MUJI会长期间,大力推行一个MUJI指南,尽管中间遇到非常多的阻难,但他还是尽可能的把一个公司的所有能够书面化的事情,都书面化下来。本质上,书面化其实也是为了配合一套机制的运行,推动企业机制的建设才是根本。

note of great blog

连续性的做一些事情

Google SEO 工程师 Mutt Cutts 提出过一种很好的实践方法(TED2011):Try something new for 30 days。偶尔的一次尝试只是为生活平添了几分色彩,但是如果一直做下去,30 days × N 后,你的生活就会发生改变。

Bio

我在学校的时候掌握了电路。

通过自学我掌握了算法之“道”。

不过我发现它们是错误的“道路”。它们的追随者只了解技术之“阳”并且对代码顶礼膜拜。但技术是没有灵魂的,代码没有道德可言。于是我陷入了绝望。

于是我开始寻找新的道路。终于在多个漫长的年头之后,我发现了设计之“阴”,它讲的不是东西,而是人,我开始学习如何根据人的感知和理解来设计界面。

等到我掌握了它,仍旧发现它是错误的“道路”。它的追随者只学会了如何回答问题,但从来不去质疑这些问题。于是我再一次陷入了绝望。

我又开始寻找和思考,并且开始走自己的道路。终于有一天,我悟道了。

真理之路凌驾于任何琐碎的技能之上。这世上并没有所谓的“技术”,也没有所谓的“设计”,只有一个人应该成为什么样的人,以及在这个过程中保持一颗不屈的决心。其他的只是细节。

这就是我的教学方式。

note of mqtt protocol

blog

1
2
- [SSL/TLS配置(证书生成需要注意CN不能乱填)][1]
- [mqtt协议详解][2]

JPush参考发现的一些点:

1
2
3
4
5
6
- 推送信息的保存时间长短(10天?)
- 单设备多用户
- server端记录设备的id,多用户通过别名其它机制来做逻辑的映射
- 但极光的做法是单个设备和别名一对一,不同用户登录,别名会被覆盖
- 提供有限时长过的记录保存
- [极光推送的很多策略值得参考,API设计的也不错][3]

note of learning skills

关于学习的摘抄

You don’t need to learn everything, you just need to be curious about learning. When the time comes that you need it, you’ll be prepared.

便于记忆的集中方法

1
2
3
4
5
6
7
8
9
10
11
12
- 把长时间的学习分割为几个单位,使“最后”和“最先”的情况大大增加,理想的学习时段是10分钟到45分钟,中间休息时间2-10分钟。
- 运用连锁关系和出色醒目。即编造本不相干的A、B关系,使其练习起来。然后把A、B夸大,使其变得荒唐或者幽默,而且尽可能想象自己触碰到它的外形,听见它的声音,看见它的画面,闻到它的气味等等。
- 每天,去观察人的某个特定部位,多多观察其特异性,就比较容易记住自己所遇见的新面孔。
- 学习一个时段后休息大约10分钟,然后首次复习,隔一天再进行第二次复习,1周以后第三次复习,1个月以后第四次,4个月后第五次复习。
- 用关键字句,特殊的画图记日记。
- 有意识地反复回忆一些事情。
- 经常在脑中展现生动形象,色彩丰富的画面,这样能训练右脑的思维。

reading note of about face 3

定义交互框架

1
2
3
4
5
6
7
8
9
10
11
12
13
- 定义外形因素、姿态和输入方法
- 定义功能和数据元素
- 决定功能组和层次
- 勾画出大致的交互框架
- 构建关系线路场景和剧本
- 通过验证性的场景剧本来检查设计
- 形式(工业设计师、图形设计师)+ 内容(信息架构师、文字编写人、动画制作师) + 行为(交互设计师)

reading note of mosquitto

背景

之前在游戏公司的时候,需要自己搭建一套推送服务,顺道研究了下一些开源实现。mosquito的代码库,代码量少,而且也写得比较好懂,对推送协议的实现也是比较ok的,所以就撸了一番。虽然后来没用上,但是还是把当时的一些想法记录下来。

缺点

1
2
3
4
5
6
7
- 基于poll的事件模型,没有epoll的性能好
- 内存分配策略简单,来一个生成一个,存在优化空间
- 比如改用初始2倍,到达一定数量后,以后每次改用增加额定数量的算法
- 数据结构过于简单
- 常用结构为单向链表,查找耗时为O(n),存在性能问题
- 内存占用过大
- 没有使用数据库,数据都堆在内存里面,可能无法应付大数据量

notes of learning erlang

背景

之前因为要想实现一个基于DHT网络的站,就找了一些代码实现,发现一个前辈写的erlang实现,好奇也看了起来,顺便学了下erlang。

感悟

  • erlang 太有趣啦,通过模拟进程创建,看到内存和CPU资源是怎么被吃掉的,給人很直觀的感覺哇~而且erlang同时支持事务和热代码替换,这两项特性碉堡了啊!!!
  • erlang的并发编程模式,其实我觉得写起来还是读起来都非常的通俗,上手也不难,但有些约定有点反人类,或者语法有点多,约定俗成的东西还要靠看书来回忆…
  • erlang的并发编程模式,有两个关键的地方:server端本身的loop无限循环;提供对外进行调用的rpc接口. 一开始我对rpc的概念是不清楚的,现在可好了,原来它是把客户端发送过来的请求,做了一个转发.
  • 那转发给谁呢? 我猜如果是BS架构的话,rpc就转发给对应的server”进程”,然后receive轮询,等待对应的pid返回处理结果,rpc再转发回去

sharding of mongodb

blog教程

分片概念

集合可以被分片,一个片可以包含多个区间,一个区间可以包含多个块,一个块可以定大小.所有这些概念都是逻辑上的,真实的物理存储并不存在这样的一一对应关系.如下图:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
分片1----
|
|
+++++++++++
+ |------ 块1 + 区间1
+ |------ 块2 +
+++++++++++
|
|
+++++++++++
+ |------ 块3 + 区间2
+ |------ 块4 +
+++++++++++
|
|
+++++++++++
+ |------ 块5 + 区间3
+ |------ 块6 +
+++++++++++
逻辑概念与物理概念上并不一致