草原上的建筑- 草原上的建筑模型-玉龍之鄉

1 、错误定律： 别人都不对，那就是自己的错。 2、 效果定律： 在伤口上落泪和在伤口上撒盐，效果是一样的。 3 、嫉妒定律： 人们嫉妒的往往不是陌生人的飞黄腾达，而是身边的人飞黄腾达。 4、 方圆定律： 人不能太方，也不能太圆，一个会伤人，一个会让人远离你，因此人要椭圆。 5 、口水定律： 当你红得让人流口水时，关于你的口水就会多起来。 6 、利用定律： 不怕被人利用，就怕你没用。 7、 成就定律： 如果你没有成就，你就会因平庸而没有朋友；如果你有了成就，你就会因卓越而失去朋友。 8、 馅饼定律： 当天上掉下馅饼的时候，小心地上也有个陷阱在等着你。 9、 错误定律： 人们日常所犯的最大错误，是对陌生人太客气，而对亲密的人太苛刻。 10、 评价定律： 不必好奇别人怎样评价你，想想你是怎样评价他的。 11、葱蒜定律： 太拿自己当根葱的人，往往特别善于：装蒜。 12、 流言定律： 流言是写在水上的字，注定不持久，但是又传得飞快。 13、 害怕定律： 生手怕熟手，熟手怕高手，高手怕失手。 14、 难过定律： 为你的难过而快乐的，是敌人；为你的快乐而快乐的，是朋友；为你的难过而难过的，就是那些该放进心里的人。 15、 傻瓜定律： 把人家都当傻瓜，那一定是自己傻到了家。 16、 吃亏定律： 只要你不认为自己吃了亏，别人也就一定没占着便宜。 17、 风雨定律： 爱情经得起风雨，却经不起平淡；友情经得起平淡，却经不起风雨！

根据用户开发水平的差异，力软敏捷开发框架提供多种实现业务功能的开发模式。 如果您是初级开发者或者您根本就不会编程那也不要紧，系统可以根据开发向导直接进行功能开发，不需要编写一行代码也无需编译就个完成开发过程。 如果您是一名专业的开发人员，需要编写复杂的业务逻辑那么您也可以使用我们的代码生成器完成基础代码的开发，然后把业务逻辑写进去，框架底层集成各类公共操作库这样您也能很快地完成复杂功能的开发。 1、拖拽式表单开发 这种形式的开发，完全基于力软敏捷开发框架，完全没有编程基础的人都可以利用这个组件来开发，开发完表单直接可以发布成菜单功能。无需编译就可以使用。这类功能同样可以受到权限管控。 以往常规的开发都是产品经理先设计完原型，程序员再去做代码实现，用力软敏捷开发框架在完成原型设计的同时您已经开发出了功能。 表单创建完成以后不需要编译，直接可以使用。下面看一下预览效果 2、传统代码生成器与可视化设计结合生成代码 自定义表单再怎么强大，对于那种有复杂业务逻辑的功能模块肯定还是无法实现，所以力软敏捷开发框架提供了可视化的代码生成器，帮助开发者生成基础代码，然后再自行扩展。力软敏捷开发框架的代码生成器已经把常用的开发场景做成开发模板，按照开发向导一步步走，在遇到有复杂业务逻辑的地方稍作修改就好。当然框架提供了源代码，您的开发水平比较高的话可以做深层次的扩展。 系统中已经内置了多套开发模板 开发者可以选中指定数据库中的指定表来生成代码。 向导式的开发，设置表单页面。 经过简单的配置就把所有代码生成了，点击完成后就自动把代码放到项目中去了，开发者可以根据需要再来调整或者编译代码。 3、自定义报表 报表是系统中很重要的一部分，开发者在这一块比较头疼，市面上有很多诸如：水晶报表、 fastreport 之类的第三方报表软件提供商。如果采用这类报表的话确实能满足复杂的报表需求但是这类报表的学习成本比较高，短时间内不好上手，上手了把报表整合到自己的系统中又要花费大量时间。而且这类报表的授权费用也不低，拿去商业化的话成本会提高很多。力软敏捷开发框架的报表组件是以免费的 echarts 报表插件和开源免费的表格组件为基础设计的，开发过程非常简单只要您会 SQL 就可以轻松掌握。您也不用再额外支付第三方报表组件的授权费用，帮您省时、省钱。 首先设置好标题和图表类型。 按照提示写好SQL 语句就可以生成图表，然后直接可以把报表配置成菜单，这样在菜单栏里就多了“销售日报表”这个菜单项。 点击菜单，图表就显示出来了。 同时我们设计出来的报表也可以直接绑定到首页 4、APP 开发 框架中的自定义表单可以直接发布到 APP 中使用，真正的一次开发多处运行。 在 APP 端直接集成了移动审批功能，各类流程审批直接在手机端就能完成 直接在 VS 开发工具中就可以完成调试、打包。 5、权限管理 任何管理系统都离不开权限管控，没有权限还谈何管理。 力软敏捷开发框架中提供了多种形式的权限控制，按角色、按部门、按岗位、按用户、按用户组都可以，操作权限细化到了界面上的每一个按钮。数据权限可以细化到每一笔记录。操作非常简单，基于框架开发出来的功能、报表都可以直接挂到权限体系中来进行授权。做到了权限与业务的分离，您只用关心业务实现。 菜单模块的授权。 操作按钮的授权。 数据权限的授权。 可以进行 IP 段的访问限制。 可以设置用户访问时段。 6、基于 Websocket 的即时通讯组件 力软敏捷开发框架集成了基于 Websocket 的即时通讯组件，用户可以通过这个在线 IM 进行聊天，同时服务端也可以通过这个组件向客户端推送信息。该组件对外提供标准接口 web 应用、C/S 程序、手机 APP 也可以轻松接入。 7、工作流引擎 力软工作流引擎主要包括表单设计、流程设计、流程管理、流程日志等模块。 表单设计器能可视化地设计流程表单，表单设计好了就可以直接放到工作流引擎中流转。 流程设计器可以可视化设计工作流程图，节点设置中可以灵活地配置节点执行人，执行策略。流程执行中可以向执行人发送通知。 可视化的流程配置 流程设计。 设置节点处理人员。 设置该节点的权限。 8、新闻管理后台 在新闻后台可以直接管理 html 新闻，发布后门户页面可以直接链接到新闻内容。 9、文件中心 对用户上传的文件进行管理，用户可以在这里进行文件上传下载操作 10、电子邮件 框架应用案例 为了测试力软敏捷开发框架的效率，于是公司安排了项目开发部的一位同事基于这套框架做 了一套相对简单的 CRM。由于产品开发部的同事对框架比较熟悉测试效果可能不明显，所以特意安排了项目开发部的同事小王来测试框架。 CRM 系统的需求已经整理好了，从建表到完成开发工作一共花了两天时间，下面展示一下开发成果。 虽然基础数据比较多但是所有代码都可以生成，所以不到半天时间就完成了基础数据的开发。 系统提供了时间轴控件，加入进来效果很不错。 客户资料。 客户订单 订单录入界面，简洁大气。 一共就一天半的时间，而且是在不是很熟悉这套框架的基础上开发的，后面项目做多了效率还能更高。

近期部门打算搭建一套开源可控的项目管理软件，做为内部使用。通过各种百度，发现有很多，例如禅道、JIRA、Redmine、mainsoft、Worktile、OpenProject、Jitamin等，通过网上介绍及内部需求，对Redmine进行了搭建，这款软件完成可以满足中小型软件公司项目管理。 Redmine是用Ruby开发的基于web的项目管理软件，是用ROR框架+Mysql开发的一套跨平台项目管理系统，本软件通过“项目（Project）”的形式把成员、任务（问题）、工时、甘特图、问题跟踪以及各种形式的资源组织在一起，大家参与更新任务、登记工时等内容来推动项目的进度，同时系统利用时间线索和各种动态的报表形式来自动给成员汇报项目进度。 官网搭建很麻烦且遇到各种坑，于是便发现了一个支持一键安装的程序包，自动部署Mysql+Apache+Redmine，在Win7安装成功(亲测可用），但Win Server 2012R未安装成功)；并且在Centos6.6-7.2也安装成功,安装非常简单，软件部分功能界面如下所示：

一、 场景需求 总部及多分支机构之间资源或文件共享，传统且常见的方式就是借助一些聊天工具、网络云盘、邮件等方式进行传输，甚至存储，但这些方式带来了便利的同时，也给文件或资源的共享、管理以及安全带来诸多问题，诸如： 1. 总部与分支机构之间采用聊天工具或云盘方式传输或分享，导致文件或资源无法集中管理。 2. 文件传输速率受制于APP或云盘服务提供商的限制，无法最大化使用带宽传输，效率太低。 3. 由于总部与分支机构之间往返传输文件或资源，经常导致存在有大量的重复性文件或资源，导致版本太多，管理混乱。 4. 无法有效或快速协同/协作办公。 5. 文件或资源存储在云盘或聊天工具服务器上的安全性问题，容易被服务提供商所使用或被“大数据”。 6. 日常的聊天工具、邮件或文件传输，大都是以明文方式传输的，存在诸多安全风险，容易被窃取。 7. 文件或资源的传输过程中容易被篡改，导致文件内容真实性或准确性发生变化。 基于以上情况，壹云小壹-小陈建议采用IPSEC VPN的点到多点的解决方案，该方案也是目前总部与分支机构之间采用的最常用最流行的VPN解决方案，它通过建立总部与分支机构之间经过认证可信的IPSEC VPN隧道进行通信，同时对传输数据进行加密处理，同时对数据的完整性进行验证，对数据源身份进行认证等方式，以实现总部与分支机构之间的通信及数据安全，防止数据被非法篡改，确保数据的真实性。 二、 方案思路 如上图示意，IPSEC VPN点到多点的方案并不复杂，壹云小壹提供以下准备工作和部署思路： 1. 总部及分支机构之间部署IPSEC VPN的设备，比如防火墙、路由器或VPN集中器等支持IPSEC VPN的设备。 2. 总部VPN设备出口需要配置静态公网IP地址（如下图所示采用VPN防火墙部署位置）或公网IP地址经过NAT地址映射后的私有地址（一般位于边界路由器后面，公网IP地址配置在路由器出口上）。 3. 分支机构的IPSEC VPN设备出口无需静态公网IP地址或映射。 4. 以下是根据以上示意拓扑图对VPN进行了简单规划，以一个总部和2个分支机构为例介绍。 三、 配置步骤 本配置步骤共分为两大部分，一是总部IPSEC VPN配置，二是分支机构的IPSEC VPN配置： A．总部IPSEC VPN配置 第一步，配置IPSec安全提议 IPSec安全提议是安全策略或者安全框架的一个组成部分，它包括IPSec使用的安全协议、认证/加密算法以及数据的封装模式，定义了IPSec的保护方法，为IPSec协商SA提供各种安全参数。IPSec隧道两端设备需要配置相同的安全参数。 #ipsec proposal prop10516444584 encapsulation-mode auto //选择封装方式 esp authentication-algorithm sha2-256 //选择认证算法 esp encryption-algorithm aes-256 //选择加密算法 第二步，配置ike安全提议 IKE安全提议是IKE对等体的一个组成部分，定义了对等体进行IKE协商时使用的参数，包括加密算法、认证方法、认证算法、DH组和IKE安全联盟的生存周期。 #ike proposal 1 encryption-algorithm aes-256 //配置加密算法 dh group14 //配置dh组 authentication-algorithm sha2-256 //配置用户认证算法 authentication-method pre-share //配置用户身份验证方式 integrity-algorithm hmac-sha2-256 //配置用户完整性算法 prf hmac-sha2-256 //配置用户编码脉冲 第三步，配置ike Peer 配置IKE动态协商方式建立IPSec隧道时，需要引用IKE对等体，并配置IKE协商时对等体间的一系列属性。 # ike peer ike105164445848 exchange-mode auto //配置交换方式 pre-shared-key xxxxxxxxxxxx //配置预共享密钥 ike-proposal 1 //配置ike建议 remote-id-type none //配置远程id类型 local-id 1.1.3.1 //配置本地id dpd type periodic //配置dpd类型 ike negotiate compatible //配置ike协商兼容 第四步，配置高级ACL 采用ACL方式建立IPSec隧道包括通过手工方式和IKE动态协商方式建立IPSec隧道。在对等体间镜像配置ACL，筛选出需要进入IPSec隧道的报文，ACL规则允许（permit）的报文将被保护，ACL规则拒绝（deny）的报文将不被保护。这种方式可以利用ACL配置的灵活性，根据IP地址、端口、协议类型等对报文进行过滤进而灵活制定安全策略。 # acl number 3000 rule 5 permit ip source address-set 10.1.1.1 destination address-set 10.1.2.1 rule 10 permit ip source address-set 10.1.1.1 destination address-set 10.1.3.1 第五步，配置IPSec策略模板 配置IPSec安全策略时，通过引用ACL和IPSec安全提议，将ACL定义的数据流和IPSec安全提议定义的保护方法关联起来，并可以指定SA的协商方式、IPSec隧道的起点和终点、所需要的密钥和SA的生存周期等。 # ipsec policy-template tpl105164445848 1 security acl 3000 //配置相应的安全策略 ike-peer ike105164445848 //配置ike peer proposal prop10516444584 //配置提议支撑 tunnel local 1.1.3.1 //配置本地地址 alias 001 //配置别名 sa duration traffic-based 10485760 //配置sa持续流量 sa duration time-based 3600 //配置sa持续时间 第六步，调用IPSec策略模板 ipsec policy ipsec1051644458 10000 isakmp template tpl105164445848 第七步，将策略应用到接口上 为使接口能对数据流进行IPSec保护，需要在该接口上应用一个IPSec安全策略组。当取消IPSec安全策略组在接口上的应用后，此接口便不再具有IPSec的保护功能。 # interface GigabitEthernet1/0/1 undo shutdown ip address 1.1.3.1 255.255.255.0 ipsec policy ipsec1051644458 B．分支机构的IPSEC VPN配置 第一步，配置IPSec安全提议 IPSec安全提议是安全策略或者安全框架的一个组成部分，它包括IPSec使用的安全协议、认证/加密算法以及数据的封装模式，定义了IPSec的保护方法，为IPSec协商SA提供各种安全参数。IPSec隧道两端设备需要配置相同的安全参数。 # ipsec proposal prop1451731338 encapsulation-mode auto //选择封装方式 esp authentication-algorithm sha2-256 //选择认证算法 esp encryption-algorithm aes-256 //选择加密算法 第二步，配置ike安全提议 IKE安全提议是IKE对等体的一个组成部分，定义了对等体进行IKE协商时使用的参数，包括加密算法、认证方法、认证算法、DH组和IKE安全联盟的生存周期。 # ike proposal 1 encryption-algorithm aes-256 //配置加密算法 dh group14 //配置dh组 authentication-algorithm sha2-256 //配置用户认证算法 authentication-method pre-share //配置用户身份验证方式 integrity-algorithm hmac-sha2-256 //配置用户完整性算法 prf hmac-sha2-256 //配置用户编码脉冲 第三步，配置ike Peer 配置IKE动态协商方式建立IPSec隧道时，需要引用IKE对等体，并配置IKE协商时对等体间的一系列属性。 # ike peer ike1451731338 exchange-mode auto //配置交换方式 pre-shared-key xxxxxxxxxxxx //配置预共享密钥 ike-proposal 1 //配置ike建议 remote-id-type ip //配置远程id类型 remote-id 1.1.3.1 //配置对端id local-id 1.1.5.1 //配置本地id dpd type periodic //配置dpd类型 remote-address 1.1.3.1 第四步，配置高级ACL 采用ACL方式建立IPSec隧道包括通过手工方式和IKE动态协商方式建立IPSec隧道。在对等体间镜像配置ACL，筛选出需要进入IPSec隧道的报文，ACL规则允许（permit）的报文将被保护，ACL规则拒绝（deny）的报文将不被保护。这种方式可以利用ACL配置的灵活性，根据IP地址、端口、协议类型等对报文进行过滤进而灵活制定安全策略。 # acl number 3000 rule 5 permit ip source address-set 10.1.2.1 destination address-set 10.1.1.1 第五步，配置IPSec策略 配置IPSec安全策略时，通过引用ACL和IPSec安全提议，将ACL定义的数据流和IPSec安全提议定义的保护方法关联起来，并可以指定SA的协商方式、IPSec隧道的起点和终点、所需要的密钥和SA的生存周期等。 # ipsec policy ipsec1451731329 1 isakmp security acl 3000 //配置相应的安全策略 ike-peer ike1451731338 //配置ike peer proposal prop1451731338 //配置提议支撑 tunnel local applied-interface //配置隧道局部应用界面 alias 001 //配置别名 sa trigger-mode auto // 配置sa触发模式自动 sa duration traffic-based 10485760 //配置sa持续流量 sa duration time-based 3600 //配置sa持续时间 第六步，将策略应用到接口上 为使接口能对数据流进行IPSec保护，需要在该接口上应用一个IPSec安全策略组。当取消IPSec安全策略组在接口上的应用后，此接口便不再具有IPSec的保护功能。 # interface GigabitEthernet1/0/1 undo shutdown ip address 1.1.5.1 255.255.255.0 ipsec policy ipsec1451731329 四、 效果验证 1. 通过IPSEC监控列表查看一下IPSEC协商是否成功，如下图示意。 2. 通过总部与分支机构之间的内部文件/资源共享或应用程序是否可以直接使用。

导读：数字时代，认知冲击非常大。传统企业要在产业互联网的助力下实现转型，提升数字竞争力，首先要实现认知上的转变。如果产业自己的认知能力不提升，那么产业互联网和技术赋能以及数字化很难嫁接进去。本文为陈春花教授在第二届「国家数字竞争力」论坛上的发言。 文章来源：北大国发院 1 传统产业，为什么必须提升认知能力？ 我从微观的角度来谈数字化跟产业互联网之间的关系。企业组织研究中最大的挑战，就是传统企业在转型过程中，对数字经济、数字时代和数字技术难以准确理解。 认知能力是认识客观世界、获取各种知识最重要的能力。过去，很多认知是基于经验，而且经验可以帮助我们解决问题，认知冲击没有那么大。我们经验过的事情，都可以直接判断。 但是，互联网带来的最大挑战是经验没有了用武之地。对很多传统产业的认识，进入数字时代之后不一样了，这是非常大的改变。这包含五个方面的能力。 第一，是你对言语信息的理解，也就是你要回答这个世界是什么样的，比如说进入数字时代后，我们对世界很多问题的回答是不一样的。 第二，就是你有没有技能去回答「为什么和怎么办」的问题。 第三，就是你的策略。你可不可以去调节或者兼顾，或者加工认知过程。当数字经济和互联网深入到每个行业的时候，它的变化完全不一样。刚才也介绍了5G和4G的根本区别，很多人可能不能完全理解这个改变到底在哪里，这就是你认知策略上的不同。 加上态度和动作的技能，也就是说你还得能实现认知。 我过去六年来感受最深的就是传统产业和企业的认知能力调整得不够快。我们制定出很多政策，但在传统产业中很难落实。产业互联网，是要产业自己提升认知能力；如果产业自己的认知能力不提升，那么产业互联网和技术赋能以及数字化很难嫁接进去。 2 六个关键认知 1.一切正转化为数据 以前可能是产品为核心，后来是服务为核心，再接着是技术为核心。但今天变了，是数据为核心。 当数据为核心的时候，商业模式在变，效率也在变。为互联网企业一开始服务于消费端，正是因为那是商业模式变得最快的部分。接下来是制造端，是要解决所有产业的效率问题。一切转化为数据、以数据为核心的时候，第一个变的就是你如何理解这个市场，我称之为「数据即洞察」，你了解市场不能凭自己的感觉，必须凭数据。 比如我研究柯达为什么在2012年申请破产保护，这个非常领先的企业到底发生了什么。事情的转折点在2002年。2002年，数字成像技术进入这个领域，但是当时柯达产品数字化率只有20%，所以后来破产了。 今天看中国的工业企业和传统企业，看的就是数字化的占比。我最近跟金蝶做联合研究，希望在所有的报表中有一个战略性的报表，不是看你今天的经营，而是看你在数字化率上的投入和占比是多少。这就是「数据即洞察」。 数据即包容。今天如果企业不能够更大地去拓展你的包容性，你的链接，增强彼此的关联，你就没有办法真正理解数字带来的改变到底是什么。 数据的应用已经无所不在。现在已经有产品可以把文本转化为手语，就是用了数字计算。这就改变了3000多万聋哑儿童跟这个世界的直接关系。因此，数字行动计划在今天就显得非常重要。如果你没有能力去做数字行动计划，你在今天可能就会离这个世界比较远。 2.联接比拥有更重要 工业企业有一个缺点，就是必须控，必须边界清楚，必须拥有，如果不拥有就觉得很困难。甚至包括最简单的人才，也觉得是自己的人才能用。 但数字时代，这个认知一定要调整，这就意味着你可以理解什么叫公开、什么叫迭代、什么叫做集合智慧。从人类的运行方式到组织方式，所有做连接、共享、创新的价值，都是一步一步显现出来的。 沈阳机床厂通过数字技术转化组织模式的实践给人以启发，我们可以把一个非常传统的企业完全更新掉。我们也可以看到海尔的转型为什么如此备受关注，就是因为它用了一个很开放的数字平台，让更多人连接在一起，形成一个非常大的联合创新。华为也在大量连接创新项目和创新机构，全面拥抱一个全链接时代。 你要努力去链接，而不是去拥有。这也是国发院跟腾讯研究院一定要一起开这个论坛的初衷，我们要推动更广泛的链接。 3.可信与开放协同是关键 数字时代，最重要的是信任。如果没有安全信任作为底线，就无法实现数字化。你能不能建立命运共同体，是根本性的东西。 7-Eleven不是互联网公司，但是成长性更强，原因是它很早迎合了今天数字时代的要求，做到了可信和开放协同，建立了命运共同体。 另外一个是小米。小米是非常有竞争力的公司，原因在于它与开发者之间的关系。它从两个平台去集合个体、集合机构、集合智能设备。当把这些都集合起来的时候，我们就可以想象到它未来的发展。 腾讯在赋能于产业互联网时，一个立场就是，它只做连接器。在这个连接器之下，连接的范围就变得非常宽广，人与人、人与商业服务、人与智能硬件都连接起来。甚至马化腾说，合作伙伴自主生长的策略是没有疆界的，大家可以感受和想象这个发展的空间和科技进步的力量。 4.从竞争逻辑转向共生逻辑 我最近一直在推「共生」这个词，原因非常简单：过去对于因为技术限制无法做的事，只能用比较优势，去满足需求，获取盈利空间。今天，如果你可以把生产力要素通过技术、数字能力，让它变得空间更大、弹性更大的时候，所有的行业都可以重新定义。这就是为什么我们一定要转向共生这个逻辑，这是一个非常重要、没有输赢的概念。 数字时代的战略转变，最重要的就是从以企业为中心转向以客户为中心。 我们传统的战略逻辑，是想做什么、能做什么、可做什么，是有边界的。想做什么是初心、能做什么是资源能力，可做什么是产业环境。 但是在数字时代，这三个都可以变，想做什么你可以重新定义，能做什么你可以跟别人连接，可做什么你可以跨界，你会发现有数字作为基础的时候边界全变了。这个变化解释了今天为什么有很多独角兽，为什么有很多可以迭代，为什么有很多新兴产业的成长速度比我们想象的快得多。 5.顾客主义 你一定要回到顾客价值这一端。数字能帮助我们真正和顾客走在一起。 今天我们更清楚地知道人们的需求，更清楚地知道整个市场的环境，更清楚顾客需要的东西到底是什么。顾客主义的战略逻辑可以从两个维度上展开，一个是从顾客端，叫做需求派；一个是从技术端，叫做技术派。你在战略上有四种全新的选择，你可以成为一个颠覆者，也可以成为一个引领者，或者推进者，或者革新者。 数字对于工业、对于制造业、对于传统产业的帮助可以超越所有人的想象，至少在战略上是四个维度的空间有机会。如果你愿意回到顾客端，那么基于四个方向都有机会去做。 今天，我们一定要问自己四个问题： 1.你知道顾客的期待是什么吗？2.你能给顾客带来想象吗？3.未来有哪些技术进步能对我们的领域产生影响？4.你有突破常规、应用激进技术的决心和能力吗？ 这些问题的核心就是你能不能真正回到顾客价值。 6.长期主义 今天，可能比以往更需要你有长期主义，如何在不确定中确定。过去我们一直要求你面对不确定性，但是从2019年开始，我要求你面对确定，因为不确定是基本的。在基本不确定的背景下怎么确定，就变得非常关键。 今天，高速铁路在祖国大地飞奔，你回看整个技术的发展过程，从2004年开始确定到现在，正是不断学习跟踪先进技术的过程。当然中国中车在学习跟踪的过程中，没有放弃「我要拥有核心能力」这一长期追求。他们一路这样做，到2015年，才真正拥有核心技术。 同时，我们一定要回归人性。只有回归人性，企业才能真正具有长期能力。华为对整个5G技术的追求，就是要推动无处不在的连接。 范式一改变，世界也随时改变。数字时代是范式改变了，因此全世界都在变。如果我们在范式认知上没有努力、不做出改变，我们可能就真的没有机会了。 卢梭说，人类走向迷途，不是由于无知，往往是由于自以为是。希望大家不要用工业时代的逻辑来应对数字时代！（本文完）

这篇文章分享一下最近一个项目的部分架构设计，主要还是根据对业务的理解来构思。主要是对部分功能的设计，涉及到消息中间件、内外网隔离、故障隔离等相关的技巧。 项目需求 项目是进行社交媒体的发布，需要对接微信、微博、以及海外的Facebook、Twitter、Youtube等平台，通过定制的编辑器对稿件进行编辑，然后一键发布到所对应的平台上。 业务流程 编辑器：可对所有类型的稿件进行编辑，它会对不同类型的稿件进行不同的条件限制以满足最终的发布要求。 中间层：收到编辑器的签发请求开始对数据进行封装，依据不同平台的数据格式进行处理。 发布层：对中间层封装好的数据发布到对应的平台。 本文主以获取微博官方表情的接口为例，发布层定时调用微博服务器进行表情的获取，对获取到的数据写入文件再上传到nas并通过mq通知中间层，目前的mq是备用方案，中间层也可以定时从nas中读取文件并更新数据到数据库，编辑器则直接调用中间层进行数据获取，由于一些别的因素此处并未引入缓存。这就是获取微博官方表情接口的一个大概流程，下面会结合构架设计图来说明为什么要这么设计。 架构设计 设计初衷 出于安全考虑发布层需要部署到接口机上直接跟外网进行交互，而发布层部署在内网服务器，发布层调用接口获取到的数据先写入nas服务器的文件中，然后中间层去定时读取nas中文件进行读取并把数据入库。nas是可以供内外网访问的，这样的话如果有人对发布层进行恶意攻击的话也不会影响到中间层和其他的服务，从而进行内外网隔离并起到一个故障隔离的作用。 细心的小伙伴可能发现发布层和中间层既然已经加入了mq为什么中间层还有再定时去读取nas中的文件呢？ 假设在单机情况下mq挂了的话中间层就无法取到最新的数据，假如发布层的接口是每隔1一个小时调用一次，然而中间层一个小时之内并没有收到数据的话那么他就主动的去读取nas中的文件，当然具体的实现中还需要进行相关的处理。 总结 对设计来说没有什么是最好的，所有的设计都需要在不断的实践中进行调整。所以大家在工作中不要以为设计是多么难做的事情，总要去不断的进行尝试，如果说碰到一个还不错的公司给你这种机会的话一定不要错过，也不要怕出什么问题，既然有人信任你那你就一定要去尝试，慢慢的等你在面试过程中说起这种经历的时候你就会知道你曾经的努力都没有白费。 路过的朋友帮忙点个赞转发评论一下吧，谢谢啦！

近几年，在国家及政府的大力支持下，BIM技术得到了广泛的推广及应用。BIM在业内也变成了比较有争议的话题，有持反对意见的，也有非常认可BIM技术的，接下来跟着小编一起来看看有都有哪些争议，对于BIM，你又是怎么看的呢？ 1 争议一：BIM是什么？ 针对BIM的定义，有各种各样的说法，在慧都君看来：BIM技术产生的BIM模型就是一个数据库，是一个工程多维度结构化的数据库。什么叫多维度结构化？就是很多维度参数确定了以后所需要的数据都能统计出来，分析出来结构化最重要的特点之一。所以有了这个数据库，施工企业计算数据的能力就大不一样了。 工程业一直是经验主导性的行业，企业投标的时候要报什么价拍脑袋，要组织多少生产资料、多大队伍也要凭经验来拍板，这些都导致资源浪费、工期拖延。而BIM技术的出现，可以帮助企业构建出多维度结构化的工程数字模型，确定好维度参数所需要的数据就可以分析得到，数据粒度也可以精细到构建级，有助于分析成本指挥生产，组织资源计划。 生产、施工、设计甚至运维中所有的工程数据和业务数据都可以加载上去。这个加载在于有关联性，只要找到这个构建的设备所有关联的数据就可以被调出来。所以有一句话总结，有了BIM，搞工程的才有了项目管理一直需要的一个最重要的支撑平台，在数据获取方面可以帮我们随时随地获取准确及时、完整的工程数据库。 2 争议二：BIM能否实现协同应用？ 传统方式下，建筑业很难像制造业一样，为了造一台电脑把真实的样机造出来，并且设计很多遍，不断完善，这是造工程不能承受的。但是有了BIM技术，可以运用BIM技术和三维技术，在工程施工前，在电脑里将整个施工过程模拟一遍，把设计阶段出现的所有的问题先解决掉、所有的数据全部精算用于精确的计划后，再开始破土动工，这样可以大大地提高效率。所以，BIM技术帮助行业解决了一个大的时空难题。 3 争议三：BIM技术现在成熟吗？ 目前，国家及政府已出台了很多关于BIM的政策，那是否就是说BIM技术就很成熟了呢？其实大家还有很多的疑问，因为很多小伙伴都在吐槽，BIM技术我用过，不好用，只有投入，没有产出。小编认为，用三句话来总结现阶段的现状是比较合理的： （1）BIM如今处于发展阶段，如果把各种软件厂商的解决方案都用出来，在施工阶段已有上百项价值很高的应用，这个毫无问题，但是相对于BIM技术发展的潜力、发展空间来讲，BIM技术仍处于发展阶段，还未得到大规模的使用； （2）价值已经非常巨大，把现有的应用用好，根据工程特点和实施阶段，把现有的应用用好，选择正确的方案和方法，完全可以获得很高的价值回报； （3）BIM技术是建筑业革命性的技术。这意味着企业把BIM技术用好了，并不一定能成为行业第一， 但如果不用，就会被市场淘汰。 4 争议四：三边工程BIM技术有用吗？ 中国的工程都比较大，大都是是三边工程，也经常听到很多老总抱怨：试点工程上大楼造好了，BIM小组的电脑里模型还没有建好，效率这么低，要BIM技术有啥用呢？那么BIM技术是否适合中国的工程呢？如果方案选择正确，越大型复杂、越三边、越工期紧成本压力大的工程越适用，而且BIM的价值体现越明显。哪怕是一个小门房，在成本计划管理方面也有大的价值可以挖掘。关键是BIM建模，模型的调整、 运算、协同的应用速度能力要强，如果有这样的建模平台，完全能够适应三边工程。 5 争议五：数据透明后施工企业的利益怎么办？ 建筑行业几乎是最不透明的，同时，利润几乎也是最低的。因此，不透明的建筑业没有给企业带来髙利润。所以现在施工企业要改变自己经营的理念，要改变鸵鸟思维主动拥抱透明，这也是行业的趋势。在行业透明的情况下，拼成本、拼质量、拼进度，特别是成本方面如何比别人更低，企业才能立于不败之地。 6 争议六：有没有超级的BIM软件？有没有超级的BIM团队？ 现在搞BIM技术，很多企业其实都在做试点，效果不太理想。因为有一些BIM软件厂商希望所有中国的用户，从设计到施工到运维一竿子插到底都用他的软件，这个给施工企业带来一个灾难性的问题。因为工程实在太复杂了，信息量巨大，工程的技术、成本管理、质量问题、安全问题等等，太多太杂，不可能用一个软件通吃设计、施工、运维三大阶段。认清这一点之后，从现在的BIM技术特点来看，一定是要找每一个阶段最专业，最能落地的专业化能力最强的软件拿来用，一定可以得到很好的投入回报。 7 争议七：信息安全怎么办？ BIM技术现在已经到了广域网应用的阶段，越来越多的BIM模型被放到云端，放到服务器上共享，协同去做各种各样的应用。那么，BIM模型应该放到哪里的服务器上呢？其实，现在任何的BIM技术厂商都能够提供企业级的方案，不管是云端的解决方案还是企业级私有云的方案。而企业要把自己把数据保护好，当然要用最安全的技术，所以不能为了做一个简单的应用模型，将大工程自动传到国外公司的服务器上，这是相当有问题的。所以要研发具有自主产权的BIM软件和应用技术，以保障建筑模型的信息安全。 8 争议八：投资回报率高不高？ 十多年的BIM技术应用实践，得出的结论已经非常明确：选择正确的BIM技术方案和实施方法，可以实现10%以上进度追赶，10%以上的返工减少。而BIM的数据能力可以减少少算漏算，提髙结算收入，可以大幅度提升现场质量安全的管理能力，提升协同能力。 利用BIM技术可以降低对现场管理人员的经验要求，可以把很多的规范经验的数据库形成一个后台的支撑为前端的项目管理人员提供强大的数据支撑、技术支撑。最后形成一个工程竣工模型，这个模型可以用到工程的全生命周期，每一年都可以用来节省资源。 虽然BIM一直非常有争议，但有一个观点已经没有争议，就是BIM技术会成为我们行业发展的趋势。

hello，大家好今天跟大家分享下我们如何批量将手机号码的中间设置为四个星号，在利用手机号抽奖的时候我们经常会看到这样的操作，如下图 跟大家分享三种方法，都能达到这样的效果 一、快速填充 这种方法是最简单的方法，我们只需要在旁边输入一个模板，然后按快速填充的快捷键Ctrl+E，即可快速完成，如下图，我们在第一个单元格中输入129****2358，然后按Ctrl+E 二、使用left与right函数 Left函数的的作用是从左提取数据，他的第一参数是要提取的字符串，第二参数是要从左提取多少位 Right函数的作用是从右提取数据，他的第一参数是要提取的字符串，第二参数是要从右提取多少位 在这里我们可以使用left函数从左提取3位，然后使用rigth函数从右提取4位，最后使用连接符，连接四个*号即可 公式：=LEFT(A2,3)&"****"&RIGHT(A2,4) 三、使用substitute Substitute函数的作用是将指定的文本数据替换为新的文本数据 第一参数：想要替换数据的字符串 第二参数：要替换的数据 第三参数：替换为的新数据 第四参数：Instance_num，如果说第二参数的数据出现多次，用于指定替换第几次的数据，省略的话则全部替换 了解了他的参数，我们就来看下它是如何隐藏手机号码的吧 公式：=SUBSTITUTE(A2,MID(A2,4,4),"****") 第一参数：A2，就是我们要替换的手机单元格区域 第二参数：想替换的字符，MID(A2,4,4)，在这里我们使用mid函数提取中手机中的中间四位，以第一个号码为例，这个函数提取的结果为6541 第三参数：替换为的新字符，"****"，输入四个*，必须用英文状态下的双引号将其括起来，否则会报错 第四参数：在这里我们直接省略了，表示全部替换 在这里函数会将6541替换为四个*号，就达到了我们想要的效果

最近我遇到了一个 bug，我试着通过 Rails 在以“utf8”编码的 MariaDB 中保存一个 UTF-8 字符串，然后出现了一个离奇的错误： Incorrect string value: ‘\xF0\x9F\x98\x83 <…’ for column ‘summary’ at row 1 我用的是 UTF-8 编码的客户端，服务器也是 UTF-8 编码的，数据库也是，就连要保存的这个字符串“ <…”也是合法的 UTF-8。 问题的症结在于，MySQL 的“utf8”实际上不是真正的 UTF-8。 “utf8”只支持每个字符最多三个字节，而真正的 UTF-8 是每个字符最多四个字节。 MySQL 一直没有修复这个 bug，他们在 2010 年发布了一个叫作“utf8mb4”的字符集，绕过了这个问题。 当然，他们并没有对新的字符集广而告之（可能是因为这个 bug 让他们觉得很尴尬），以致于现在网络上仍然在建议开发者使用“utf8”，但这些建议都是错误的。 简单概括如下： MySQL 的“utf8mb4”是真正的“UTF-8”。 MySQL 的“utf8”是一种“专属的编码”，它能够编码的 Unicode 字符并不多。 我要在这里澄清一下：所有在使用“utf8”的 MySQL 和 MariaDB 用户都应该改用“utf8mb4”，永远都不要再使用“utf8”。 那么什么是编码？什么是 UTF-8？ 我们都知道，计算机使用 0 和 1 来存储文本。比如字符“C”被存成“01000011”，那么计算机在显示这个字符时需要经过两个步骤： 计算机读取“01000011”，得到数字 67，因为 67 被编码成“01000011”。 计算机在 Unicode 字符集中查找 67，找到了“C”。 同样的： 我的电脑将“C”映射成 Unicode 字符集中的 67。 我的电脑将 67 编码成“01000011”，并发送给 Web 服务器。 几乎所有的网络应用都使用了 Unicode 字符集，因为没有理由使用其他字符集。 Unicode 字符集包含了上百万个字符。最简单的编码是 UTF-32，每个字符使用 32 位。这样做最简单，因为一直以来，计算机将 32 位视为数字，而计算机最在行的就是处理数字。但问题是，这样太浪费空间了。 UTF-8 可以节省空间，在 UTF-8 中，字符“C”只需要 8 位，一些不常用的字符，比如“”需要 32 位。其他的字符可能使用 16 位或 24 位。一篇类似本文这样的文章，如果使用 UTF-8 编码，占用的空间只有 UTF-32 的四分之一左右。 MySQL 的“utf8”字符集与其他程序不兼容，它所谓的“”，可能真的是一坨…… MySQL 简史 为什么 MySQL 开发者会让“utf8”失效？我们或许可以从提交日志中寻找答案。 MySQL 从 4.1 版本开始支持 UTF-8，也就是 2003 年，而今天使用的 UTF-8 标准（RFC 3629）是随后才出现的。 旧版的 UTF-8 标准（RFC 2279）最多支持每个字符 6 个字节。2002 年 3 月 28 日，MySQL 开发者在第一个 MySQL 4.1 预览版中使用了 RFC 2279。 同年 9 月，他们对 MySQL 源代码进行了一次调整：“UTF8 现在最多只支持 3 个字节的序列”。 是谁提交了这些代码？他为什么要这样做？这个问题不得而知。在迁移到 Git 后（MySQL 最开始使用的是 BitKeeper），MySQL 代码库中的很多提交者的名字都丢失了。2003 年 9 月的邮件列表中也找不到可以解释这一变更的线索。 不过我可以试着猜测一下。 2002 年，MySQL 做出了一个决定：如果用户可以保证数据表的每一行都使用相同的字节数，那么 MySQL 就可以在性能方面来一个大提升。为此，用户需要将文本列定义为“CHAR”，每个“CHAR”列总是拥有相同数量的字符。如果插入的字符少于定义的数量，MySQL 就会在后面填充空格，如果插入的字符超过了定义的数量，后面超出部分会被截断。 MySQL 开发者在最开始尝试 UTF-8 时使用了每个字符 6 个字节，CHAR(1) 使用 6 个字节，CHAR(2) 使用 12 个字节，并以此类推。 应该说，他们最初的行为才是正确的，可惜这一版本一直没有发布。但是文档上却这么写了，而且广为流传，所有了解 UTF-8 的人都认同文档里写的东西。 不过很显然，MySQL 开发者或厂商担心会有用户做这两件事： 使用 CHAR 定义列（在现在看来，CHAR 已经是老古董了，但在那时，在 MySQL 中使用 CHAR 会更快，不过从 2005 年以后就不是这样子了）。 将 CHAR 列的编码设置为“utf8”。 我的猜测是 MySQL 开发者本来想帮助那些希望在空间和速度上双赢的用户，但他们搞砸了“utf8”编码。 所以结果就是没有赢家。那些希望在空间和速度上双赢的用户，当他们在使用“utf8”的 CHAR 列时，实际上使用的空间比预期的更大，速度也比预期的慢。而想要正确性的用户，当他们使用“utf8”编码时，却无法保存像“”这样的字符。 在这个不合法的字符集发布了之后，MySQL 就无法修复它，因为这样需要要求所有用户重新构建他们的数据库。最终，MySQL 在 2010 年重新发布了“utf8mb4”来支持真正的 UTF-8。 为什么这件事情会让人如此抓狂 因为这个问题，我整整抓狂了一个礼拜。我被“utf8”愚弄了，花了很多时间才找到这个 bug。但我一定不是唯一的一个，网络上几乎所有的文章都把“utf8”当成是真正的 UTF-8。 “utf8”只能算是个专有的字符集，它给我们带来了新问题，却一直没有得到解决。 总结 如果你在使用 MySQL 或 MariaDB，不要用“utf8”编码，改用“utf8mb4”。这里（https://mathiasbynens.be/notes/mysql-utf8mb4#utf8-to-utf8mb4）提供了一个指南用于将现有数据库的字符编码从“utf8”转成“utf8mb4”。

概述 最近一周主要是在梳理Oracle、mysql、sqlserver的权限，所以今天顺便总结下mysql用户和权限管理。 MySQL用户权限表 MySQL的认证是“用户”加“主机”而权限是访问资源对象，MySQL服务器通过权限表来控制用户对数据库的访问，权限表存放在mysql数据库中，由mysql_install_db脚本初始化。存储账户权限信息表主要有：user,db,tables_priv,columns_priv,procs_priv这五张表（5.6之前还有host表，现在已经把host内容整合进user表），5张表其含义分别是： 1、user表 user表时MySQL中最重要的一个权限表，记录允许连接到服务器的账号信息，里面的权限是全局级的。例如：一个用户在user表中被授予了DELETE权限，则该用户可以删除MySQL服务器上所有数据库的任何记录。MySQL5.6中user表有43个字段，这些字段大概可以分为4类，分别是用户列、权限列、安全列和资源控制列，详细解释如下图： 2、db表 db表存储了用户对某个数据库的操作权限，决定用户能从哪个主机存储哪个数据库。User表中存储了某个主机对数据库的操作权限，配置和db权限表对给定主机上数据库级操作权限做更细致的控制。这个权限表不受GRANT和REVOKE语句的影响，字段大致可以分为两类：用户列和权限列，详细解释如下图： 3、tables_priv and columns_priv表 tables_priv表用来对表设置操作权限，有8个字段分别是Host、Db、User、Table_name、Grantor、Timestamp、Table_priv和Column_priv，各个字段说明如下： 1） Host、Db、User和Table_name4个字段分表示主机名、数据库名、用户名和表明。 2） Grantor表示修改该记录的用户。 3） Timestamp字段表示修改该记录的时间。 4） Table_priv表示对表的操作权限包括、select、insert、update、delete、create、drop、grant、references、index和alter。 5） Column_priv字段表示对表中的列的操作权限，包括select、insert、update和references。 4、procs_priv表 存储过程和存储函数相关的权限，分别是Host、Db、User、Routine_name、Routine_type、Grantor、Proc_priv和Timestamp，各个字段的说明如下： 1） Host、Db和User字段分别表示主机名、数据库名和用户名。Routine_name表示存储过程或函数的名称。 2） Routine_type表示存储过程或函数的类型。 3） Routine_type字段有两个值，分别是FUNCTION和PROCEDURE。FUNCTION表示这是一个函数；PROCEDURE表示这是一个存储过程。 4） Grantor是插入或修改该记录的用户。 5） Proc_priv表示拥有的权限，包括Execute、Alter Routine、Grant这3种。 6） Timestamp表示记录更新时间。 MySQL访问控制两阶段 1、客户端连接核实阶段 客户端连接核实阶段，当连接MySQL服务器时，服务器基于用户的身份以及用户是否能通过正确的密码身份验证，来接受或拒绝连接。即客户端用户连接请求中会提供用户名称、主机地址和密码，MySQL使用user表中的三个字段（Host、User、Password）执行身份检查，服务器只有在user表记录的Host和User字段匹配客户端主机名和用户名，并且提供正确的面貌时才接受连接。如果连接核实没有通过，服务器完全拒绝访问；否则，服务器接受连接，然后进入阶段2等待用户请求。 2、客户端操作核实阶段 客户端操作核实阶段，当客户端的连接请求被MySQL服务器端通过其身份认证后。那么接下来就可以发送数据库的操作命令给服务器端处理，服务器检查用户要执行的操作，在确认权限时，MySQL首先检查user表，如果指定的权限没有在user表中被授权；MySQL将检查db表，db表时下一安全层级，其中的权限限定于数据库层级，在该层级的SELECT权限允许用户查看指定数据库的所有表中的数据；如果在该层级没有找到限定的权限，则MySQL继续检查tables_priv表以及columns_priv表，如果所有权限表都检查完毕，但还是没有找到允许的权限操作，MySQL将返回错误信息，用户请求的操作不能执行，操作失败。其过程大概如下图： MySQL权限管理 权限管理主要是对登录到MySQL的用户进行权限验证，所有用户的权限都存储在MySQL的权限表中，不合理的权限规划会给MySQL服务器带来安全隐患。数据库管理员要对所有用户的权限进行合理规划管理。MySQL权限系统的主要功能时证实连接到一台给定主机的用户，并且赋予该用户在数据库上的SELECT/INSERT/UPDATE和DELETE权限。 1、MySQL权限说明 账户权限信息被存储在MySQL数据库的几张权限表中，在MySQL启动时，服务器将这些数据库表中权限信息的内容读入内存。其中GRANT和REVOKE语句所涉及的常用权限大致如下这些：CREATE、DROP、SELECT、INSERT、UPDATE、DELETE、INDEX、ALTER、CREATE、ROUTINE、FILE等，还有一个特殊的proxy权限，是用来赋予某个用户具有给他人赋予权限的权限。 2、MySQL用户授权 授权就是为某个用户授予权限，合理的授权可以保证数据库的安全，MySQL中可以使用GRANT语句为用户授予权限。授权可以分为多个层次： 全局层级：全局权限适用于一个给定服务器中的所有数据库，这些权限存储在mysql.user表中。 数据库层级：数据库权限适用于一个给定数据库中的所有目标，这些权限存储在mysql.db表中。 表层级：表权限适用于一个给定表中的所有列，这些权限存储在mysql.tables_priv表中。 列层级：列权限使用于一个给定表中的单一列，这些权限存储在mysql.columns_priv表中。 子程序层级：CREATE ROUTINE、ALTER ROUTINE、EXECUTE和GRANT权限适用于已存储的子程序。这些权限可以被授予为全局层级和数据库层级。而且，除了CREATE ROUTINE外，这些权限可以被授予子程序层级，并存储在mysql.procs_priv表中。 PS：MySQL中必须拥有GRANT权限的用户才可以执行GRANT语句。