之前在12-Factors时提过我们在搭一个脚手架，这篇简单介绍一下，老话说得好再丑也要出来吓人嘛。
项目模块是基于maven做的项目生成脚手架，基于此脚手架生成 maven 项目模块， 开发人员能快速的基于模版进行开发，减少前期熟悉开发框架时间。同时 也通过此模版来统一平台开发规范，实现工程能力提升，沉淀工程规范。
结构说明
app-bom 工程依赖管理.
app-manager 工程胶合层，service 层通用能力下沉，复杂 dao 组合.
app-repository 数据操作层，与数据库进行交互.
app-rpc-api 服务向外暴露的 rpc api 接口.
app-service 服务业务逻辑实现.
app-web 服务 restful 接口.
最近项目的0.2阶段需要加上权限功能，产品方给了一个需求文档，让我们参与共创。所以借此梳理梳理权限的东西。其实万变不离其宗，我觉得基本上权限设计都是基于RBAC模型来设计的。
我认为的权限应该是分为两种：
权限复杂度的设计依业务场景而定，我是基本上做的都是toB，所以权限这块会相对复杂些。不同的toB系统权限设计肯定也不同。不过我觉得大体可以分为三种toB权限设计场景。私有云、私有云（对客户定制开发并部署在客户现场 的我也归为私有云）、混合云。当然我比较熟的是公有云和私有云的，混合云的我还没涉及到过，不过我觉得是混合云应该和公有云的权限设计比较接近。
下图我参与过的某toB平台，我理解的权限设计。
租户那块为什么单独标注呢，租户是一个比较大的概念，通常表名一个公司或者个人。
下面是我另外参与的私有云项目的权限设计。
这个权限你会发现有一个域的概念，是因为我们的客户是集团性质的客户，会有总公司、分公司、事业部等概念，因为每个分公司或者事业部大体上都是独立运营的，但是他们又是属于一个集团，所以我们出现了域的概念。一个域可以理解为一个公司或者事业部但是我们不强关联，域是扁平的增加了灵活性。还有一点需要注意在这儿部门（组织）是不纳入权限的，我们使用角色来控制，为什么还需要部门，是为了让角色更丰满，部门可为角色打上标签，客户也好理解。同时也减少了复杂性。
资源
因为要打造的是一个APM系统，所以里面会涉及到CMDB，资源这个名称就是CMDB来的当然一般我们叫CI（具体一个配置项，也叫CI实例），要详细讲就要讲到CMDB了，要讲CMDB那就复杂了，不是一两篇能说清楚的，后面有机会我会试着讲讲我理解的CMDB和CMDB在我们系统是怎么定义以及怎么用的。
RBAC
基于角色的访问控制，所以你会发现这个模型能满足大多数的权限设计。至少我没见过没有角色这个概念的权限设计。
google和博客说的更清楚
干了一段时间前端，老想着什么时候能搞明白点什么。要搞明白点前端的东西，前端的技术五花八门的，顾不过来，既然顾不过来那就别顾了，找到他们的基石就对了。不管技术怎么变，最终都得在浏览器解析。所以我想着先搞清楚浏览器是咋工作的，可能会让我对前端没那么惊慌。
一google找到了这个姐妹-Tali Garsiel，看到有好几篇文章都是基于她的文章来的。这姐姐人干了N多年的前端开发，看了各个开源浏览器的源码，用尽洪荒之力总结出了这篇文档http://www.taligarsiel.com/Projects/howbrowserswork1.htm。那我也厚颜无耻的用她写的文章作为了解浏览器的入门。虽然文章的年代比较老，但是浏览器的核心概念是不变的，这点从近年来大家的解读可以看出来。
文章主要是针对开源或者部分开源的Chrome、Firefox、Safari。文章有很多章节，我就挑我喜欢的来说了。
The browser’s main functionality
这个章节我了解到一个很有意思的事情就是浏览器的界面，其实是没有任何规范或者说标准的，几大浏览器厂商你抄我我抄你最后大家就基本上长得一样了。比如都有地址栏，都有工具栏等等。
所以浏览器基本上都有以下几大功能：
The browser’s high level structure
这章节讲的是浏览器的主要结构。
用户界面 包括地址栏、前进/后退按钮、书签菜单等。除了浏览器主窗口显示的您请求的页面外，其他显示的各个部分都属于用户界面。
浏览器引擎 在用户界面和呈现引擎之间传送指令。
呈现引擎 负责显示请求的内容。如果请求的内容是 HTML，它就负责解析 HTML 和 CSS 内容，并将解析后的内容显示在屏幕上。
网络 用于网络调用，比如 HTTP 请求。其接口与平台无关，并为所有平台提供底层实现。
用户界面后端 用于绘制基本的窗口小部件，比如组合框和窗口。其公开了与平台无关的通用接口，而在底层使用操作系统的用户界面方法。
JavaScript 解释器。用于解析和执行 JavaScript 代码。
数据存储。这是持久层。浏览器需要在硬盘上保存各种数据，例如 Cookie。新的 HTML 规范 (HTML5) 定义了“网络数据库”，这是一个完整（但是轻便）的浏览器内数据库。
这几个组件中，最主要的或者说前端开发最应该关注的就是呈现引擎了，你想嘛，你做的everything最终不就是为了让浏览器把你想要的效果呈现给用户么，呈现引擎就是干这个事的。
这个地方可能需要注意一下，可能会有疑惑为什么javascript单独拎出来了，请注意啊，javascript它最初的作用就是操作dom，从而实现一些动态效果而发明的。所以它本身是不能直接作为呈现给用户的，需要一个编译执行的过程，所以不属于呈现引擎的组成部分。当前现在javascript不仅用于前端开发了，后端也常常作为某种函数脚本的存在，比如java8以后的MapReduce可运行对应格式的js脚本、java的mango客户端也能用js脚本…
呈现引擎先主要有两种一种是Firefox 的Gecko，这是 Mozilla 公司“自制”的呈现引擎。而 Safari 和 Chrome 浏览器使用的都是 WebKit。不管是哪一种引擎都是为了让浏览器能更好更多的支持内容的呈现。虽然现在浏览器能呈现的内容远远不止HTML+CSS，但是主要的还是对html和css进行解析呈现。
如图所示，呈现引擎一开始通过网络组件请求需要呈现的文档内容，拿到内容后开始解析，首先解析html，把html分割成大量的标记（标签），进而把每个标记转化为一颗dom tree上的节点，同时解析css样式，并和dom tree转换为另一种树：Render Tree（该树包含有多个视觉属性的矩形，并存在排列顺序）。
接着根据Render Tree进行布局，因为呈现树上包含有视觉属性以及顺序，所以可以为呈现树里各个节点（矩形）分配坐标。
分配好坐标以后由另一个组件用户界面后端进行树的绘制。最终呈现给用户。Gecko，WebKit略有不同但是总体的流程是一样的。
整个过程是渐进的过程，浏览器不会等着所有html文档都解析完再呈现，而是解析过程中就开始构建呈现树和设置布局。在不断接收和处理来自网络的其余内容的同时，呈现引擎会将部分内容解析并显示出来。
专业解释：HTML 经过解析生成 DOM Tree；而在 CSS 解析完毕后，需要将解析的结果与 DOM Tree 的内容一起进行分析建立一棵 Render Tree（呈现树），最终用来进行绘图。Render Tree 中的元素与 DOM 元素相对应，但非一一对应：一个 DOM 元素可能会对应多个 renderer，如文本折行后，不同的「行」会成为 render tree 种不同的 renderer。也有的 DOM 元素被 Render Tree 完全无视，比如 display:none 的元素。
这儿需要注意的是，html的解析是正向的从上到下（从左到右）的（从根节点开始），而css是逆向的从下到上（从右到左）的。为什么html是从上到下的，这个很好理解，你想想html解析后是一棵树，你想想树的构成肯定是先有个主干然后再有分叉，这样才是一个整体，不然不就是一盘散货么。那css为什么就一定要从下到上呢，通过下面的叙述你会知道如果css也采取从上到下的顺序，那dom tree和style rules两个需要对上眼的消耗是很大的（因为通常dom节点多，css样式也多）,从概率上来讲逆向匹配的概率是远远高于正向匹配的概率的。
专业解释：在建立 Render Tree 时， DOM Tree 中的元素需要根据 CSS 的解析结果（Style Rules）来确定生成怎样的 renderer。对于每个 DOM 元素，必须在所有 Style Rules 中找到符合的 selector 并将对应的规则进行合并。选择器的「解析」实际是在这里执行的，在遍历 DOM Tree 时，从 Style Rules 中去寻找对应的 selector。
如果正向解析，例如「div div p em」，我们首先就要检查当前元素到 html 的整条路径，找到最上层的 div，再往下找，如果遇到不匹配就必须回到最上层那个 div，往下再去匹配选择器中的第一个 div，回溯若干次才能确定匹配与否，效率很低。
逆向匹配则不同，如果当前的 DOM 元素是 div，而不是 selector 最后的 em，那只要一步就能排除。只有在匹配时，才会不断向上找父节点进行验证。其实更深入的理解需要深入了解Html Parser和css Parser的工作过程。
关键字解释：
style rules
源引：
为什么是windows版，能别问么。穷啊。这几款是我自己在用的。
Everything
文件搜索工具
Wox
集合各种功能的搜索工具，强大的令人发指那种。
Seer
预览工具，敲空格就能预览各种文件，也是超好用。
Listary
定位，查找文件等功能。
Snipaste
截图工具轻巧好用。
Mobaxterm
免费的远程网络工具，功能非常多，几乎提供了所有重要的远程网络工具（如SSH、X11、RDP、VNC、FTP、MOSH等），以及Windows 桌面上的Unix命令（bash、ls、cat、sed、grep、awk、rsync等）。
Photo by Joanna Kosinska on Unsplash
OBS-Studio
录屏工具。
Typora
MD文档工具。
Google 扩展
Kami、Pocket、Fatkun、沙拉查词、Adblock、OneTab、Scroll To Top、Grammarly
本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。
源引-冯大推荐的少数派：
背景
现公司是传统的ToB业务公司，现在要新开一条产品线，因为公司的之前的产品已经10年了，因为技术等的限制，无法应对现在的快速迭代，公司高层想用现在流行的玩法，寻求突破，刚好之前那家公司的leader，支付宝出来的刚从公司离职，他和事业部的总经理是高中同学，所以瞌睡遇到枕头，就找到他来领头做个事，事业部研发中心在天津，他想做这个事必须得带几个自己信得过并且好用的人（是滴，我很好用），所以我和另外一个同事就通过他的内推去了天津（我是对现在的公司及其失望），那番场景那真就是，新老两派之间充满爱意的碰撞，我们抛弃了之前事业部的所有技术积累，全部从0开始。
这篇文章讲的就是在开垦一个后端脚手架的过程中发现了12-Factors，其实很早以前就听过12-Factors，这次逮着机会好好了解下，刚好最近看jimmysong翻译的《迁移到云原生应用架构》，里面提到了12-Factors，这套理论看来是没过时的，借机学习学习。
I. 基准代码
一份基准代码（Codebase），多份部署（deploy）
我们项目是采用类似git flow的方式来管理代码，首先每个应用肯定只有一份基准代码（master），不管是新功能的开发、bugfix、hostfix、release、tag等最终都是基于master的。这样就保证了所有部署的基准代码相同，但每份部署可以使用其不同的版本
II. 依赖
显式声明依赖关系（ dependency ）
每个应用都有自己的依赖清单，前端是package.json，后端是pom.xml。每个应用都会显示的列出依赖。
III. 配置
在环境中存储配置。
每个应用都有自己的配置文件（yaml），针对不同的场景有不同的配置，发布、预发布、测试等。杜绝把配置写死在代码里的情况发生。
IV. 后端服务
把后端服务(backing services)当作附加资源
数据库、消息队列、数据中心等都是作为基础设施存在的，每个应用是与这些组件都是松耦合。不足是现有的客户场景对可能只能做到逻辑上的隔离，比如数据库虽然逻辑上和应用是隔离的但是物理上可能在一个主机上，因为客户现场可能就跟我们提供几台机器。
**
V. 构建，发布，运行**
严格分离构建和运行。
项目采用的是阿里云的ci/cd方案，构建、发布、运行都是分离的。每个版本对应唯一ID。
VI. 进程
以一个或多个无状态进程运行应用
12-Factor 应用的进程必须无状态且 无共享 。 任何需要持久化的数据都要存储在 后端服务 内，比如数据库。
项目中，进程中无共享，权限、session等都存到redis中。
VII. 端口绑定
通过端口绑定(Port binding)来提供服务
这点没什么说的，项目所有的应用提供服务都是通过端口与应用绑定的。
VIII. 并发
通过进程模型进行扩展。
这一点没做好，后端采用的java语言，都知道java是典型的线程模式。所以只能给应用分配相应的资源，让其能纵向扩展，但其实效果不是很好。当然我们有比较简单的方式可以使其进行横向扩展，即每个应用部署多实例的方式进行横向扩展，不过目前没有实践。后续会完善。
IX. 易处理
快速启动和优雅终止可最大化健壮性。
该原则要求应用可以瞬间启动和停止，因为这将有利于应用快速进行横向扩展和变更或者故障后的重新部署，而这两者都是程序健壮性的体现。
快速启动是做到了，但是优雅的终止还带完善。
X. 开发环境与线上环境等价
尽可能的保持开发，预发布，线上环境相同。
我们的发布部署统一走的阿里云效的流水线，流水线的配置除了机器不同其他都一样。
XI. 日志
把日志当作事件流。
这块没做好，待完善。个人觉得是很有必要的，后期会酌情加上日志处理分析组件。从日志输出到读取，到分析，到加工，到视图一条龙服务。
XII. 管理进程
后台管理任务当作一次性进程运行
官方说明：
开发人员经常希望执行一些管理或维护应用的一次性任务，例如：
一次性管理进程应该和正常的 常驻进程 使用同样的环境。这些管理进程和任何其他的进程一样使用相同的 代码 和 配置 ，基于某个 发布版本 运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。
我理解意思就是应用的管理工具应该随产品一起提供，并且管理任务应该从生产环境中运行最新版本的生产代码的机器上执行此任务。换句话说，从与生产相同的环境中运行一次性管理任务。而不要做类似直接对数据库运行更新这种操作，我理解意思应该是有配套的管理工具而且管理工具是与生产环境同步的，如果需要做一些一次性的维护管理任务，比如数据库移植、A/B测试等任务时不要做手动去改数据库这样很容易造成环境搞乱的操作。
这点在我们项目还是比较弱的，0.1阶段基本上没有统一的管理工具，大家都是通过手动改库等操作达到目的。后期会争取做到这一点。
12-factor 到底好不好，适不适用，我觉得不是绝对的，目前我们遵循这套是因为我们觉得它对我们有指导意义而且是有效的够用的。
源引：
本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。
之前从国外的一篇博客上了解到了ServiceMesh，觉得很感兴趣，感觉它是完全就是为分布式量身定做的以后肯定会大火，不管以后能不能进入运用ServiceMesh思想的公司，先了解是不错的，果不其然，阿里系首先就来了个dubbo mesh和sofa mesh，我参加阿里的dubbo meeting up时，宣布发布了dubbo mesh。以下内容做个这段时间的学习记录。
Service mesh 我理解其实不是新技术是一个新技术理念。
看了很多相关的文章也看了某些案例，准备动手实践一下。很多service mesh的文章和案例通常都会提到两个单词，data-plane和control-plane，即数据面板和控制面板。
顾名思义，我理解数据面主要是负责服务间通信传递信息的相关操作，比如负载均衡、服务发现、心跳检测、路由、监控等等，但是你会发现，如果只有数据面板其实是没用的，因为数据面板功能再多但是它是死的，他就像一台计算机，软硬件都配好了就算你跟他通上电，插好网线他也不能工作，因为它不知道他要做什么和怎么做。
而控制面板恰好就是做这个事的，它告诉控制面板应该做什么怎么做，比如服务间通信的规范、路由的地址以及路由的规则、监控的指标、限流、熔断的机制是什么配置是什么？控制面板才能真正让数据面板变成一套可运行的系统。
其实通过很多案例知道，很多大中型的公司特别是互联网公司，他们很早以前就有了自己的数据面板可能叫代理更合适，因为那时候还没流行service mesh的概念，他们也有控制面板（可能那时候更明确的叫法是库或者配置中心）。所以service mesh只是概念新，但应用应该很早就有了，只是现在的提出的service mesh应该更激进一些，直接把数据面板和控制面板剥离出来作为基础设施，脱离业务。
由于近年云原生、容器、微服务等概念的火热，微服务的落地案例越来越多，带来技术革新的同时也带来了烦恼。即微服务的运维（服务治理、路由策略、性能监控等）复杂度，不管是云原生还是容器都旨在让微服务能更快速更高效的部署，但是服务部署后是需要运行的，这么多服务之间的运行的有效性谁来保证，当然在云原生等概念火热之前，很多公司都有自己的微服务架构，服务之间运维也都有自己的一套。但是很多方案基本上都是把对服务运维的管理的代码或者说库耦合在业务代码里的，比如zk的使用，就是耦合在业务代码中的，而且很多时候是每种编程语言都需要开发一套代码来支持。这就让运维变得越来越繁琐，Dev和Ops耦合程度会越来越高。
现在的Istio、linkerd、sofa mesh等其实就为了解决上面说到的痛点。那怎么解决呢，就是把属于基础设施的组件，属于ops的工作从业务中剥离出来。在业务服务的身边跟他派一个书童，这个书童就是service mesh的应用。书童存在的价值是什么？就是让他的少爷能专心的读书，除了读书其它事情一概不用管。我理解这就是service mesh真正的价值。
云原生（cloud native）
我理解的是什么都在云上做，存储、交付、部署、测试等等，最大的特点就是快。
源引：
本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。
最近关注ServerMesh时，又听到一个Serverless，所以又了解了解，做个笔记吧。
最近google开源了Knative，感觉Serverless可能又要起飞了。
Serverless也是一种架构模式，中文意思是“无服务器”架构。目前，业界并没有给出明确的定义，把其分成两种类型，分别为“Backend as a Service” 和 “Functions as a Service”。
个人理解就是开发是不需要维护基础设施以及基础组件，直接填业务代码。
传统的互联网APP主要采用C/S架构，服务器端需长期维持业务进程来处理客户端请求，并调用代码逻辑完成请求响应流程。而在Serverless架构中，应用业务逻辑将基于FAAS架构形成独立为多个相互独立功能组件，并以API服务的形式向外提供服务；同时，不同功能组件间的逻辑组织代码将存储在Amazon Lambda，Azure Function，Google Cloud Functions等产品上，业务代码仅在调用时才激活运行，当响应结束占用资源便会释放。
个人理解类似事件驱动的感觉，来了请求就触发业务代码。我理解这种形式是不是很有可能比传统的长期维持的方式要慢一些，因为传统是等着你时刻准备着，serverless是你来了我再启用。
Serverless 如果是在高并发而且要求数据安全性、独立性的场景应该是不适用。和云厂商真的是强耦合了。后续有时间继续学习吧。
如果想试一试，可以去Cloudflare](https://workers.cloudflare.com/docs)试试跑一个简单的js脚本感受一下。
参考：
这段时间区块链很火，虽然我没用什么兴趣去做区块链，因为愚笨的我现在还没太看懂区块链到底能进入哪些行业？就像之前看红杉资本的一位VC的访谈，她的成功秘诀之一就是，自己没看懂的行业是肯定不会投的不管它多么火。
但是虽然这么说，我还是得了解一下到底是个什么玩意？虽然网上到处是文章但是都是东拼西凑得，不太体系。所以当我听说caoz大佬要开个区块链的扫盲视频，所以马上付费了解了下同时也看了下MacTalk大佬写的文章….。以下是这段时间对于区块链的一些笔记。
从图中可以看出，现目前区块链的应用主要有两种场景，公有链和联盟链，其实还有私有链
所以首先要了解比特币不是区块链，区块链是一种技术集合的统称，比特币等是区块链的一种应用。
区块链的核心概念：
去中心化
我理解就是P2P，没有集权，数据分布式存储，交易变得平等、透明、公开。这是美好的理想。
共识机制（公共账本）
就是解决信任问题，区块链要求每个联结点在共同的账本上对每一笔交易进行分布式记账。所以每个节点都对账本负责。
加密
通常是非对称加密，用于个人的账户交易。
算法
各种算法，比如分布式一致性算法，加密算法等，作为交易的支撑
激励机制（针对发币的场景）
发币，也可通过挖矿来挣币，没有甜头谁帮你干活，本质就是P2P
其实说白了 感觉就是一堆人在维护一个账本，这个账本每人都有一份，而且还都一模一样。
当然现在很多企业应用区块链，也就是联盟链，很多时候还是利用区块链的理念，在一些环节做到公开透明从而减少成本，提升效率。联盟链是指一些愿意彼此实现共信的机构和组织共同组建的，为各自机构提供共识信用和价值传递的平台，这样只要联盟不存在一家独大的情况，还是可以实现共识基础。
区块链我觉得应该还是一个风口，虽然不如人工智能大风大浪，但是有风有浪是肯定，抓紧时间补补吧。总比啥都不知道要强,另外我始终觉得去中心化，共识机制等强调的公平、透明只是美好的愿望。决定权始终是掌握在部分人手里的，不然为毛这么多人买矿机其实不就是增加自己的权重么。还可能存在算法劫持。所以只是美好的。所以不懂又想乘机赚一笔的就别上了，只能成为韭菜。
名词解释：
POW
区块链怎么工作的，pow为例。首先，每条交易，记账信息，是一条记录，每条记录都会发布到各个不同的节点，节点将检查最新的记录打包到一个新的区块上，然后通过算力证明，将区块发布到网络。但这里的算力证明其实是有极大的偶然性随机性，也就是有非常多的矿机，现状可能是几十万台同时打包和发布数据，但只有一个幸运的矿机，获得了证明，生成了新的区块，并获得了区块的奖励。
当这个区块发布后，其他的节点会很快得到这个信息，然后放弃掉当前已经打完包的数据，开始接受新的数据，进行下一步数据打包，并试图证明算力获得发布权力和区块奖励。所以你会发现其中的空耗是很严重的这就不难解释为什么有那么多矿机但是获得比特币还是特别难特别少。但也正是因为所有节点的概率一致，保证了任意节点被入侵，被篡改，其数据信息，不会被其他节点接受，也就是保障了主链的安全性。
POW目前的局限是出块速度被限定了，比特币差不多10分钟出一个区块，所有交易均需要记录在区块内，所以这样也就限制了交易频率，由于一个区块只有1M，可以承载的交易信息是有限的，所以目前比特币的交易频次被限定在非常低的量级上，差不多一秒才可以支撑不到10个交易。
POS
POS共识算法，也就是基于拥有的数量和时间获得证明的算法。简单解读类似于存本取息，你在系统中存的钱越多，存的时间越长，你所获得的收益就越多，这样算力竞争的意义被弱化，而拥有的意义被强化。
DPOS
在POS之上又有人提出了DPOS，在基于拥有数量的基础上，投票选举工作节点的模式，由投票委任的节点负责运算打包，一旦出现坏区块或者故障，会有一套机制保障自动切换到其他节点，实现平滑过渡
智能合约
来源于以太坊。智能合约，也就是说，在区块中传递的合约，或者说传递的字符串，不是单纯的字符串和信息，而是一段可执行的脚本，比如说，有触发条件，有交互能力。
图灵完备
图灵完备，什么是图灵完备，就是说不考虑硬件限制的情况下，这个脚本的支持性可以满足所有图灵机的功能诉求，图灵机也可以简单理解为全功能计算机。
以太坊
以太坊是一种虚拟货币，这个定义是错的，以太坊是一个平台，上面跑了几千种虚拟货币，其中之一是以太坊自身的代币。而这个平台不但可以发布货币，还可以发布应用，智能合约的应用，这个想象力是蛮大的。
硬分叉
说一下硬分叉，刚才也提到了比特币的第一次硬分叉，所谓硬分叉，是分叉方约定，在某个区块节点开始，启用新的系统架构继续前进，不再和主链保持一致，但同时也继承了该节点之前的所有区块。在这个节点之后，双方各自挖各自的矿，各自爆各自的块，各自走各自的路。
ICO
ICO 是一种基于区块链进行资金筹集的方式，目前市场上的ICO主要分两种类型，一种是股权众筹，一种是代币发行。
从股权众筹来说，ICO虽然通过代码来保障发行规模和你所拥有的比例，也就是说这个你所拥有的部分是不会被篡改，不会被恶意侵吞的，听上去很合理是不是？但问题在于，没有任何一个国家的法规和政策，规定或约束了企业股权与虚拟代币之间的关联，你说你不相信政府，你要去中心化，那么太多人没有意识到，去中心化同时也意味着失去权力机构的保护和制约。发行的代码是算法约束的，但与企业的发展关系，是靠人性约束的，算法是约束不了人性的。
代币模式
另一种代币模式，就是发行的是某个应用场景或平台中的代币，而不是股权，这个代币可以在这个平台中使用，并通过区块链技术保证这个代币的发行是可控的，可信任的。
区块链的商业生态，ICO是非常大的一块，目前也是势头最火的一块，但我个人认为目前问题很大，过于挑战人性，我是非常拒绝现在那些ICO行为的。此外硬分叉，虽然最开始我们说硬分叉有其技术争论的原因；但后来就变味了，借用硬分叉的名义薅韭菜，这里信息不对称因素太大，很多人入场的人根本不知道分叉币的流通盘有多低，不知道一旦大交易所或钱包系统派糖后价格会雪崩下跌。
参考：
参考：
早上地铁上啃kindle里的万万没想到，里面有个小结讲的是穷人和富人的人脉结构。为什么穷人加粗，因为我就是穷人。
里面有两个词语我比较深刻，强联系 弱联系。
所谓强联系其实就是讲的是平时跟你比较近的人，当然反之平时不怎么联系甚至没见过面的则为弱联系。通常我们都愿意跟强联系的人一起做事，因为熟。但是文章里面讲到外国友人做了几个相关的实验，恰恰证明其实真正能帮到你的很多时候是弱联系的人。因为他们有个共同的特点就是不在你当前的社交圈内。这一点很重要，因为强联系的人经常混在一起，你们的想法或者做的事都差不多，所以发现不了什么新的东西。然而弱联系的意义就是把不同的社交圈子连接在一起，从圈外跟你提供有用的信息。所以人脉的关键不在于你融入了哪个圈子，而在于你能接触多少圈外的人。后面还讲了其它几个实验，得出的结论就是，虽然咱们都重视强联系，但是人们的大部分知识还是来源于弱联系。其实很好理解，因为强联系的人愿意跟我们交流我们也经常交流，话多了当然就没什么新意了。
还有个观点，文章是单独拿出来说的，就是别跟熟人合伙。这个其实对中国人来说尤其困难，包括我，里面说到的一点我是很认同的就是创新能力，跟熟人搭伙，创新能力肯定是没有跟弱联系搭伙强的。熟了很多东西反而有限制。
文章实验指出，富人越容易跟不同阶层和不同地区的人联络，而且阶层多样性比地区多样性更重要。虽然富人爱跟各种人联系，但是真正说话的时间比穷人的短。所以知道了吧，要致富先得学会别强依赖，强联系的亲朋好友，得学会接触新的圈子。其实就是信息的传递，通过弱联系，有用的有启发的肯定会比强联系的多，你想想，强联系的才几个人，弱联系的又有多少，就算按比例弱联系也是完胜嘛。
一天看冯大的文章，里面有个词语叫 本位主义，知识渊博的我，不得不去百度一下，看看到底啥意思。然后竟然有意外收获，还找到了其它两个主义，感觉挺有用的，做个记录，告诫自己！
三大主义分别为：
指在处理单位与部门、整体与部分之间的关系时只顾自己，而不顾整体利益，对别部、别地、别人漠不关心的思想作风或行为态度和心理状态。
这种主义是我见过最多的，基本上呆过的公司都存在这种人才，营销尤盛。这种人其实我是很不喜欢的，因为我太无私了，哈哈！没有其实我也顾自己，但是我不只顾自己，我是正儿八经的为大家放弃小家的那种革命人士，只要公司或者领导没有对我不仁我绝对是把公司、领导的利益放在我前面的。好了夸了自己半天，说回正题。本位主义的人他们有个优势，就是通常他们的kpi都是比较不错的，至于原因你想想kpi的重点不就是考核个人么，只为个人，能不kpi好么。幸好我做的是技术岗，通常这类人很少在身边。
老大主义为特权主义、目中无人、不知天高地厚，总感觉自己现在已经是天下第一，殊不知天外有天人外有人。
这类人 是我敬仰的一批人，对他们来说没有所谓的雨天，能装逼天天是晴天。这种人也遇到过，国企尤盛，之前在国企待过一段时间，天天看他们装逼，是在看不下去然后就走了。有两把刷子你在装逼呗。千万不能成为这种人，幸好我看了看镜子中的自己，没有这份潜力，我就安心了。主要是太低调。
怨职主义就是公司某些员工天天抱怨公司不好、产品不好、待遇不好，整天怨天尤人，总认为自己的这份工作干不干无所谓，从不考虑自己是否对这份工作做专、做精、做透、做熟的一种现象。
这类人应该是比较普遍，我也偶有这样的情绪，因为总避免不了遇见傻逼，当然也可能是我看你是傻逼，你看我也是傻逼。我一度自己思考过为什么会抱怨，后来总结了一下主要是两点，一点是不公，另一点是遇见了傻逼队友。现在的我很少抱怨了，因为我发现首先不公是到处存在的，要想天平往你这边倾一点那你就创造更大的价值，说起来俗，但最后其实就是看这个。另一个你不能避免遇到傻逼队友，你知道吧，生活就是这样，哪来一帆风顺，你想想西游记没了猪八戒，你能想象么。而且一个人负能量不能太多，多了容易长皱纹。
要以此为戒，做一个三无主义的好青年。
定义参考：