i am hades
i am hades
Hey! I've meet some trouble. I have some components ,use dynamic components to change the view. index.vu is the first page. ``` javascript module.exports = { el: '#app', props: ['view'],...
# 团队内部践行的技术栈 ## 系统环境 Mac系统，整套技术栈也围绕着mac系统来打造。至于为什么选择mac？[理由太多了...](http://mp.weixin.qq.com/s?__biz=MjM5ODIyMTE0MA==&mid=211925064&idx=1&sn=341e2b97415619edfbf656d9ab0b9c51&scene=4#wechat_redirect) ## 系统架构 系统整体采用微服务架构，其中前端部分的开发采用前后端分离的开发模式。这样前端只负责数据的渲染和提供页面路由；后端只负责提供restful风格的数据接口，后端所有服务以rpc的方式进行相互调用。 ## 相关技术 ### 项目管理 - `git` : 版本控制的最佳方案.... - `git-flow` : git虽好，但是具体的branch管理方案并没有提供，而git-flow则提供了一套非常完整的[流程管理模型](https://ihower.tw/blog/archives/5140)，为自动化打好基石。 - `gitlab` : 开源的git服务端，提供各种webhooks 的回调，为自动化部署，发布，集成做好铺垫。 - `slack`: 用于工作沟通，文档管理，异常通知。对于新加入频道的人，其也能看见频道之前的聊天记录，这个特点对于需求沟通或者事情告之，非常方便。其跟邮件系统，gitlab ，Jenkins 都可以进行很好的集成，集成后，slack由于其全平台覆盖的特性，其能变成一个事件通知软件，任何时候都能获取状态通知，非常方便。...
## Express VS Koa 这几天使用了一下Koa.js, 之前很多次听人说起它的精简，优雅。 于是我怀着这样的心情来使用它，但是用下来后，我发现它的api设计有些不合常理。 我们来对Express 和 Koa 做一个对比：  从上面的对比中，我们可以看出来，Koa精简是有原因的，因为它只保留了核心模版，其他的路由，模版，富响应（下载文件，JSONP等）都需要以插件的方式来进行按需安装。这...不精简有鬼了。 我们来谈一下流程控制部分，在Koa中借助Generator函数，使用Co来对它进行流程控制。 这种方式的引入，是Koa被人接受的最大理由,个人也非常认同这种方式的处理。这种方式带来了什么？ > 使异步变成同步的书写方式，可读性增强 > 异常处理变的可控 > 避免callback hell问题，以及Promise不够自然的链式问题，冗余代码问题 > 中间件以装配器模式引入，跟Express的链式模式不同 **Koa中的req,res** 关于这点，是我个人非常不喜欢koa的一个最重要的原因，有些过度封装。在Koa中，没有明确的response，request。 如果你想返回参数，用this.body=data 的方式。这样等于弱化了web开发的很多概念，非常不好。 > 如果我们能在Express中引入基于Generator的流程控制，那么Express就能变的更加的强大。因此个人开发了[power-express插件](https://www.npmjs.com/package/power-express)，通过它，可以使得在Express中像Koa中一样，使用Generator来进行流程控制。并且对于中间件来说，并没有严格要求使用Generator函数，这使的链式跟装配器模式共存，它能为开发上带来更多的灵活性。...
现在JS代码的静态质量检查在项目质量保障方面的重要性与必要性已毋庸置疑。 ESLint是一种开源方案，广受大家喜欢。我们团队中的各个项目也引用了它作为代码检查的插件。 ### ESLint的规则参数说明： > - 0：表示不验证 > - 1：验证不对的话，以警告的方式提示 > - 2 : 验证不对的话，以异常的方式抛出 ### 规则说明： > "no-alert": 0 //禁止使用alert confirm prompt > "no-array-constructor": 2 //禁止使用数组构造器 > "no-bitwise": 0...
### flux是什么？ flux不是一个具体的框架，而是Facebook提出的一种代码架构。 React只是一个视图库，mvc中react只是v，flux是在React基础上对于前端整体的组织方案。Flux中包括了存储(store)，动作(action),分发器(dispatcher),视图(view)，我们可以理解成react只是flux中的一部分，flux中可以不采用react，使用一些其它类似的来代替，都没有关系。它只是一种设计思想，它并不局限于某种框架。为什么facebook会推出它，传统的mvc只适用中小型系统，对于大型系统来说，mvc复杂度过高，因为mvc一般来说，一个m或者一个v都会对应一个c，他们会有一个对应关系，如果mvc的其中一部分变得非常复杂，那么就会导致整个mvc结构非常庞大，并且逻辑关系，依赖关系非常复杂。 **flux的目的就是保证逻辑清晰，数据流向清晰，依赖关系清晰。**当你用mvc来开发一个大型项目的时候，你会发现很多是耦合的，你不知道一个操作会产生什么后果，你修改了一个m，会导致很多c很多v 无法正常工作，因为他们之间的关系非常隐蔽非常复杂。但是fulx中，把这些关系都清晰罗列出来，并且每一部分，都专注于自己的事情，而且数据流是单一的，这和react中的思想是一致的。flux贯彻了这一点，在整个项目中都保证了单向的数据流动，这就大大减少了整体的依赖关系，复杂关系。  上图为flux的数据流动图，从中我们可以看出其分四个大块，Dispatcher，Store，React Views，Action Creators。 **我们从一个简单的小列子来读懂这张图**：我们构建了一个表单，当用户输入一个值后，其会触发User Interactions，这个时候就会把这个触发操作，传递给action creators，这个action creators 会根据你的要求来产生一个action，比如说输入一个值，那么产生一个对应的action，这个action会传递给dispatcher,dispatcher可以理解成一个大脑，它接受到这个aciton之后，它会处理这些数据，这个本质上就是一个数据在不断流动，dispatcher中会调用不同的store，sotre就是mvc中的m，你可以这么理解，当然他们中有些差别，总的来说store就是用来存储数据。每建立一个新的sotre，就会向dispatcher中去注册，等于我告诉dispatcher，我这里有一个新的store，如果你需要就来找我。这样的话如果有一个action到达dispatcher，然后就会去dispatcher中找，谁能处理这个action，比如说这个表单，对应一个store，dispatcher找到之后就会说，我找到了你的store，然后就会把这个action传递给store，因为store在注册的时候会告诉dispatcher有个回调函数，也是就是callback，所以说dispatcher就可以通过回调函数把一些操作发送给store，这个时候数据就流动到了store，sotre拿到数据后，就是非常简单了，进行一些增删改查，完毕之后，它会发出一个event事件，广播一个事件，比如说，它添加了一条记录，它就会发出一个事件说，我添加了一纪录，这个事件就会广播到整个view，如果view中有人关心这个事件，我们知道view中可能有很多东西，比如评论，表单，用户，文章等组件，但是每个组件关注的数据不一样，比如说表单组件收到这个更新表单的事件，它就会知道这是我需要的，它就会向sotre获取新数据，store就会把更新后的数据给veiw，view拿到数据后setState来更新自己的状态，状态更新之后了就会触发对应的reader，界面就会发生变化。这个完整的流程就结束了。 > 数据流向的简单总结：首先是view界面，用户进行操作之后，view会触发一个action，action负责具体的操作，action知道了你的改动之后就会操作传递给你的dispatcher，dispatcher拿到你的操作之后就会去找对应的store，把操作应用进去。store修改玩数据之后，会广播一个事件，事件广播出来之后，哪个view关心哪个veiw就去要数据，更新整个组件视图。 一般来说我们不止一个view，一个dispatcher，他们之间不是一对一的关系，也就是说不必非要一个store对应一个view，一个store可以对应多个veiw，一个view也可以对应多个action。这样做了分层抽象思想，store中处理数据的时候不用担心谁去用它，它的作用只是单纯的处理数据，view拿到数据后，不同的view会根据不同的情况进行展示，这个跟store没有关系，这样就解耦开了，同样action，dispatcher原理也一样，这样的抽象，分层，就可以比较好的提高聚合度，减少耦合性。
前后端分离的这种开发模式，在移动时代迅速普及开。 CDN在其中扮演的角色发生了一个巨大的变化，以前只是作为一个优化策略存在，如今其可是作为高性能的静态服务器而存在。 ### 什么意思？CDN还可以做服务？ 是的，它不但能做服务，而且其做的服务，具有非常大的性能优势。 我们来简单分析一下原因，大家知道CDN的主要作用是存放静态资源，从而提高网站访问速度。（[为什么能提速网站？](http://mp.weixin.qq.com/s?__biz=MzI4MjA4ODU0Ng==&mid=402603447&idx=1&sn=a66afa8393ffe5b8272ec0733f3ad1fa&scene=2&srcid=03085jwKbPsa6GysR9gWgv6E&from=timeline&isappinstalled=0#wechat_redirect)）在现代前端里面，前后端是分离开发的，后台只负责提供rest api，前端负责页面渲染。既然是这样，那么整个工程的前端部分都是静态资源，它是可以放到CDN上的（后端部分我们不在这篇文章里面讨论）。 ### CDN做服务是否靠谱，优势是啥？ 首先： 网站对抗DDOS的攻击，大家知道最有效的方法么？嗯，页面静态化，上CDN。 再次：带宽有限的情况下，最大化提高网站的承受能力。为什么？ 看如下对比：（假设网站带宽为100M同时只考虑带宽的影响，其他服务器的性能优化默认为最优）  哇，这个差距太明显了。这个其实说明了为什么像tomcat这种性能很糟糕的容器，wordpress这种php写的大众博客，他们的性能那么低，为什么还能广泛流传使用。因为对于大多数场景来说，其性能瓶颈不在服务本身，而是在网络带宽啊，亲们。 ### 我们来看看实战中是如何利用CDN来构建服务 我们项目中用的云服务是阿里云的OSS（七牛也是可以的，思路一样），所以我们针对OSS来操作。 首先开通OSS服务后，在Bucket管理目录中，点击右上的新建Bucket，在弹出来的对话框中取好BucketName(我们取名为thisisatest),选择好所属地域，读写权限选择为‘公共读’，如下图：  创建好名称后，进入Bucket概览中,里面的OSS域名栏，如下:  里面的自定义绑定域名，点击进去，添加上自己的域名，然后点击下一步，添加CNAME记录勾选'自动添加‘ 就可以了。...
开发一个新项目，部署开发环境是第一步，但是会由于各种原因，导致配置开发环境很费时间，针对这种情况，其实可以轻松用docker来统一部署开发环境。详细如下： 我们的每个项目都在Bitbucket上有自己的group,创建了一个名为development的分支。分支的同一层级有README.md(理论上)和docker-compose.yml两个文件。 当新程序员加入项目时，只需在Bitbucket上浏览developmentrepository，根据README.md的步骤就可以快速搭建环境。具体步骤如下所示： ``` $ git -v $ docker -v $ docker-compose -v $ git clone [email protected]:/development.git && cd $ git submodule init && git submodule update $ git submodule...
### mac下安装Homebrew 在终端中输入： ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" 如果不是管理用户，需要用sudo命令来执行。 安装完成以后，如果在运行 brew install 命令的过程中，出现错误提示： /usr/local/bin/brew: line 26: /usr/local/Library/brew.rb: Undefined error: 0。 输入以下命令进行修复即可： cd /usr/local/Library git pull origin master ### mac下安装Docker的管理工具Panamax brew...