从事编程行业以来经常会遇到编程语言的争论，其中最火的莫过于 PHP 是最好的编程语言。这么多年以来关于编程语言的优劣之争从来都没有中断过，不管是各种各样的社区论坛，还是微信群，QQ群又或者是程序员的线下聚会上。可以说有程序员的地方就有编程语言之争。 我们热爱自己所学编程语言本身没有什么问题，这也是我们在自己技术领域前进的内在驱动力。但是我们应当避免卷入编程语言之争。 编程语言的好坏与语言本身无关 编程语言的好坏与语言本身无关， 编程语言只是一个我们表达思想的工具。能够用它做出什么的样事情与编程语言本身的关系不大，更多的是在于作为使用者的我们。 对于绝大多数业务，更多的是写 CURD ，对于 CURD 各个语言之前的差距并没有特别明显的差距，也不能拉开程序员之间的差距。 就如一个人会用 100 种语言说”你好“一样，如果仅仅停留在说”你好“的阶段，去扩充说语言的数量是没有意义的。语言本身是用于交流的，抛弃了语言是用于交流的本质去追去数量，是一种本末倒置的做法，实不可取。 质胜于量 金庸老先生笔下有独孤求败这样一个角色，其武功修为有如下四个阶段： 1、弱冠之前，倚仗宝剑之刚猛凌厉。 2、30岁之前，善用软剑之技巧变幻。 3、40岁之前，重剑无锋、大巧不工。 4、40岁之后，不滞于物、草木竹石均可为剑 武学如此，编程亦如此，在编程初期质胜于量。有了前期的积累，后期在学习其他编程语言，无论是速度还是处理问题的深度，都要远胜于一开始就看中数量的方式。 从系统的角度看待编程语言 现实生活是一个系统，虚拟世界作为现实的一种投射，本身也是系统的。我们是没办法通过一种编程语言去解决一个系统的问题。因此为了提高解决问题的效率，也就衍生出了很多的编程语言，这些语言之间多是有各自适用的领域，也都存在其优势与劣势。 也正是因为这样从事各个语言开发的程序员也就展开了各种各样关于语言优劣的争论。编程语言的选择要根据自身业务去决定，脱离业务谈语言优劣是没有意义的。 

Casbin 是一个强大的、高效的开源访问控制框架，其权限管理机制支持多种访问控制模型。 通俗来讲就是一个权限管理的框架，把常见的权限管理集成在框架中，使用者只需要根据框架规范就可以很方便的实现相应的权限控制。 Casbin 支持的权限管理如下： ACL (Access Control List, 访问控制列表) 具有 超级用户 的 ACL 没有用户的 ACL: 对于没有身份验证或用户登录的系统尤其有用。 没有资源的 ACL: 某些场景可能只针对资源的类型, 而不是单个资源, 诸如 write-article , read-log 等权限。 它不控制对特定文章或日志的访问。 RBAC (基于角色的访问控制) 支持资源角色的RBAC: 用户和资源可以同时具有角色 (或组)。 支持域/租户的RBAC: 用户可以为不同的域/租户设置不同的角色集。 ABAC (基于属性的访问控制): 支持利用 resource.Owner 这种语法糖获取元素的属性。 RESTful: 支持路径, 如 /res/* , /res/: id 和 HTTP 方法, 如 GET , POST , PUT , DELETE 拒绝优先: 支持允许和拒绝授权, 拒绝优先于允许。 优先级: 策略规则按照先后次序确定优先级，类似于防火墙规则。 Model 概念 Model 相当于框架的配置文件，如我想在系统里有可能实现 是ALC 或者 RBAC ，应该如何告诉 Casbin 框架，我实现的是那种类型的权限控制呢?答案就是通过 Mdoel 来配置。 ...

在 web 开发领域，前后端分离越来越普遍，前后端之间的技术壁垒也随着提高。混合开发的年代，后端多多少少都要会写一些前端的代码，而现在后端已经越来越无法写前端的代码，如果后端想学习前端技术，该如何入手呢？接下来讲讲我的一些经验。 打破思想障碍 前端的发展十分迅速，且生态和标准十分割裂，这对专业的前端也是一个比较大的挑战，对于后端而言难度就更可想而知了。 幸运的是，我们如果只是想做前端入门并且能够开发一些普通的项目的为目标的话还是没有这么大的阻碍的。我们可以花费 20 % 的学习时间解决，80 % 的前端开发问题。剩下的 20% 开发问题，你可以有两个选择： 交给专业的前端去做 继续精进前端技术，自己解决 确定学习目标 学习前端主要有以下几个部分： CSS JS 框架 (VUE ,React, angular) CSS CSS 部分是前端很重要的一个部分，也是大多数后端都不是很擅长的部分，关于 CSS 部分，我们可以借助 UI 框架去解决问题，UI 框架会封装很多组件，我们只需要用相关组件进行布局即可。 CSS 布局就变得十分的重要了，好在现在前端有了 flex 布局，在兼容性和开发便利性上来说都对程序员十分友好，因此对于 flex 布局这部分应该要重点学习和掌握。 CSS 布局另一个比较重要的就是「定位」，因此「定位」这部分的知识也是需要重点掌握的。 掌握了 flex 和 「定位」两部分知识，基本上绝大多数的布局都没有什么问题了，配合上 UI 框架的加持基本上普通页面的开发就可以完成的七七八八了。 js 框架 一般想学习前端的朋友心中都会有自己想学习的框架了，这里建议挑选你周边前端在使用的一些框架，对于你后续的学习能有一些帮助。 学习方法 关于 CSS 的学习方法，主要是看文档和练习，把布局重点学习即可，下面介绍主要介绍一下 JS 框架的学习方法。 阅读文档 这部分可以根据自身掌握情况有选择的进行，如果你对所选 JS 框架，文档已经通读并且对文档结构有了一个掌握就可以跳过这部分。 文档不需要过于深度的掌握，有些概念不理解也可以跳过，随着后续开发的深入，你慢慢就会对一些难以理解的概念有所顿悟。 但是对于文档的结构需要熟练掌握，要做到你遇到问题你能知道到文档的哪个部分去找就可以了。 抄作业 找一个所选 JS 框架的后台管理系统，跟着管理系统文档框架进行一些管理后台功能的开发。 通过抄一些原本原理后台实现的功能，你会对整个前端代码的目录组织和后端通讯有一个比较完整的认识，同时对于 JS 框架的一些用法也会有更深入的了解。 更新一步 如果你对于管理后台的开发已经迎刃有余，那前端的 JS 框架，以及前后端通讯，还有一些基础的页面布局都有了一个系统的了解。接下来可以尝试写一个 H5 项目，进行一些移动端开发。 ...

在 go 开发中，首先遇到的一个问题，应该怎么设计开发架构。一个好的架构可以在后续的项目开发中能够更好的使用项目的推进，同时能够让团队的配合更加的顺利。 一个简洁的架构应该具有如下几个特点： 不依赖框架：好的架构应当是独立的，不依赖框架可扩展的 不依赖 UI：UI 应该很容易修改，而不需要改业务部分代码 独立于数据库：不绑定数据库，可以在不改动业务代码的情况下，更换其他数据库 可测试的： 能够比较方便测试用例的编写 下面目录结构引自 《go 整洁模板》 ├─cmd 应用入口 │ └─app ├─config ├─docs // 存放文档 ├─internal │ ├─app │ ├─controller // 控制器 │ │ ├─amqp_rpc │ │ └─http │ │ └─v1 │ ├─entity // 实体层 │ ├─middleware // 中间件 │ └─usecase │ ├─repo // 数据库操作 │ └─webapi // RESTful API ├─migrations ├─pkg //以被外部程序安全导入的包 │ ├─crypto │ ├─httpresponse │ ├─httpserver │ ├─logger │ ├─mysql │ ├─postgres │ ├─rabbitmq │ └─redis 分层介绍 ...

接口定义 应该定义在接口所使用的包中，而非接口实现的包中。 以io包中的io.Reader/io.Wirter为例，接口定义在io包中，而他的实现bytes.Buffer、os.File等都是在不同包中。 接口实现应该返回具体类型 应该返回对应的结构体或指针，这样实现类如果扩展新的方法就可以直接添加，无需改动接口定义部分，更加灵活。 //为了方便演示，本实例代码未遵循「接口需要在使用包中声明」规范 package demo import "fmt" type Demo interface { show() error } type MyDemo struct { } //这里的返回值应该是 `MyDemo` 或 `*MyDemo` 而非 `Demo` func NewMyDemo() *MyDemo { return &MyDemo{} } func (md *MyDemo) show() error { fmt.Println("show") return nil } 接口应该什么时候定义 在当前模块有依赖外部服务的时候，这时候就会定义一个接口，来对外部的依赖资源进行抽象解耦，屏蔽接口的实现。相反，依赖的提供方在不知道使用方需求的时候，定义接口也就没什么意义。