Full-Stack Web Developer
In case you missed it, Node now supports async/await out of the box since version 7.6. If you haven’t tried it yet, here are a bunch of reasons with examples why you should adopt it immediately and never look back.
谢邀。对前端工程化有了新的认识，对部分内容做了修改。 目前来说，Web业务日益复杂化和多元化，前端开发已经由以WebPage模式为主转变为以WebApp模式为主了。 现在随便找个前端项目，都已经不是过去的拼个页面+搞几个jQuery插件就能完成的了。 工程复杂了就会产生许多问题，比如：如何进行高效的多人协作？如何保证项目的可维护性？如何提高项目的开发质量？ …前端工程化是前端架构中重要的一环，主要就是为了解决上述大部分问题的。而前端工程本质上是软件工程的一种，因此我们应该从软件工程的角度来研究前端工程。 那么前端工程化需要考虑哪些因素？本人总结经验，认为前端工程化主要应该从模块化、组件化、规范化、自动化四个方面来思考，下面一一展开。
如CommonJS、AMD和CMD等，某些框架也会有自己模块系统， 比如Angular1.x。现在ES6已经在语言层面上规定了模块系统，完全可以取代现有的CommonJS和AMD规范，而且使用起来相当简洁，并且有静态加载的特性。 规范确定了，然后就是模块的打包和加载问题：
按道理，一个模块化的文件应该要隐藏内部作用域，只暴露少量接口给使用者。 而按照目前预处理器的方式，导入一个CSS模块后，已存在的样式有被覆盖的风险。 虽然重写样式是CSS的一个优势，但这并不利于多人协作。为了避免全局选择器的冲突，各厂都制定了自己的CSS命名风格：BEM风格； Bootstrap风格；Semantic UI风格；我们公司的NEC风格； …但这毕竟是弱约束。选择器随着项目的增长变得越多越复杂，然后项目组里再来个新人带入自己的风格，就更加混乱了。 所以我很赞同这句话：与其费尽心思地告诉别人要遵守某种规则，以规避某种痛苦，倒不如从工具层面就消灭这种痛苦。 从工具层面，社区又创造出Shadow DOM、CSS in JS和CSS Modules三种解决方案。Shadow DOM是WebComponents的标准。 它能解决全局污染问题，但目前很多浏览器不兼容，对我们来说还很久远；CSS in JS是彻底抛弃CSS，使用JS或JSON来写样式。 这种方法很激进，不能利用现有的CSS技术，而且处理伪类等问题比较困难；CSS Modules仍然使用CSS，只是让JS来管理依赖。 它能够最大化地结合CSS生态和JS模块化能力，目前来看是最好的解决方案。Vue的scoped style也算是一种。
更重要的是它的万能模块加载理念，即所有的资源都可以且也应该模块化。资源模块化后，有三个好处：依赖关系单一化。 所有CSS和图片等资源的依赖关系统一走JS路线，无需额外处理CSS预处理器的依赖关系，也不需处理代码迁移时的图片合并、字体图片等路径问题； 资源处理集成化。现在可以用loader对各种资源做各种事情，比如复杂的vue-loader等等。 项目结构清晰化。使用Webpack后，你的项目结构总可以表示成这样的函数： dest = webpack(src, config)## 组件化首先，组件化≠模块化。好多人对这两个概念有些混淆。 模块化只是在文件层面上，对代码或资源的拆分；而组件化是在设计层面上，对UI（用户界面）的拆分。 从UI拆分下来的每个包含模板(HTML)+样式(CSS)+逻辑(JS)功能完备的结构单元，我们称之为组件。其实，组件化更重要的是一种分治思想。 Keep Simple. Everything can be a component. 这句话就是说页面上所有的东西都是组件。页面是个大型组件，可以拆成若干个中型组件，然后中型组件还可以再拆，拆成若干个小型组件，小型组件也可以再拆， 直到拆成DOM元素为止。DOM元素可以看成是浏览器自身的组件，作为组件的基本单元。传统前端框架/类库的思想是先组织DOM， 然后把某些可复用的逻辑封装成组件来操作DOM，是DOM优先；而组件化框架/类库的思想是先来构思组件，然后用DOM这种基本单元结合相应逻辑来实现组件，是组件优先。 这是两者本质的区别。其次，组件化实际上是一种按照模板(HTML)+样式(CSS)+逻辑(JS)三位一体的形式对面向对象的进一步抽象。 所以我们除了封装组件本身，还要合理处理组件之间的关系，比如（逻辑）继承、（样式）扩展、（模板）嵌套和包含等，这些关系都可以归为依赖。 其实组件化不是什么新鲜的东西，以前的客户端框架，像WinForm、WPF、Android等，它们从诞生的那天起就是组件化的。 而前端领域发展曲折，是从展示页面为主的WebPage模式走过来的，近两年才从客户端框架经验中引入了组件化思想。 其实我们很多前端工程化的问题都可以从客户端那里寻求解决方案。目前市面上的组件化框架很多，主要的有Vue、React、Angular 2、我们公司 @郑海波 的Regular、Avalon等。你感兴趣可以都研究一下，选择一套中意的。 其实Vue文档中的对比其他框架一文已经讲得很详细了。
规范化其实是工程化中很重要的一个部分，项目初期规范制定的好坏会直接影响到后期的开发质量。 我能想到的有以下一些内容：目录结构的制定编码规范前后端接口规范文档规范组件管理Git分支管理Commit描述规范定期CodeReview视觉图标规范 …其中编码规范最好采取ESLint和StyleLint等强制措施，配置git hooks可以实现Lint不过不能提交代码等机制，因为人是靠不住的。 前后端接口管理可以了解一下我们公司出的NEI - 接口管理平台。
所以我也认为，前端工程化的很多脏活累活都应该交给自动化工具来完成。
不要再用Icomoon了，统一走Webpack吧。### 持续集成### 自动化构建### 自动化部署### 自动化测试前端自动化测试能够提高代码质量、减少人肉测试等， 这些优点是不言而喻的。市面上前端测试框架有很多，选择哪个都不会有太大问题，我们用的是：Karma + Mocha + Chai
链接：https://www.zhihu.com/question/20215561/answer/157908509
https://www.zhihu.com/question/28687373
在使用vue一个多礼拜后，感觉现在还停留在初级阶段，虽然知道怎么和后端做数据交互，但是对于mounted这个挂载还不是很清楚的。放大之，对vue的生命周期不甚了解。只知道简单的使用，而不知道为什么，这对后面的踩坑是相当不利的。
chatbot无疑是当前非常火的一个研究领域和产品方向，简单地可以分为两类，开放域bot和封闭域bot，开放域bot倾向于解决所有的事情，而封闭域bot倾向于解决某一个细分领域中的事情，旨在用AI技术提高效率，提高生产力。现阶段的开放域bot我个人感觉更像是多个常用封闭域bot的叠加，当用户发起一个请求，系统会判断出属于哪个细分领域，然后转到相应的程序中去执行并给出反馈，顺着这个逻辑来看，研究简单场景下的chatbot是个重要的基础工作，这类研究或者产品的质量直接决定了复杂场景或者开放域bot的质量。当然逗乐型的bot并不属于本文讨论的范围。
图片来自paper The Dialog State Tracking Challenge Series- A Review
最近业务比较忙，但是我们追求3D世界的脚步不能停下来~某天在路上看到一辆辆飞驰而过的汽车，想到要不要弄一个赛车类的游戏
没有再用原生，而是使用了threejs，毕竟大点的3D项目，再用原生就是自己给自己找麻烦了……
本文从0到1讲解了这个游戏的开发过程，其中没有专门的介绍webgl和threejs，没有基础的同学可以结合threejs文档一起看，或者先学习一下webgl的基础知识~
游戏地址如下：
https://vorshen.github.io/simpleCar/
操作如下：
w前进
a、d左右转
space减速可漂移
一、什么是DNS？
DNS( Domain Name System)是“域名系统”的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，它用于TCP/IP网络，它所提供的服务是用来将主机名和域名转换为IP地址的工作。你可以把它想象成一本巨大的电话本。
举例来说，如果你要访问域名math.stackexchange.com，首先要通过DNS查出它的IP地址是151.101.129.69。
如果你不清楚为什么一定要查出IP地址，才能进行网络通信，建议先阅读我写的《互联网协议入门》。
DNS就是这样的一位“翻译官”，它的基本工作原理可用下图来表示：
二、DNS域名空间结构
域名系统作为一个层次结构和分布式数据库，包含各种类型的数据，包括主机名和域名。DNS数据库中的名称形成一个分层树状结构称为域命名空间。
根域：DNS域名使用中规定由尾部句点'.'来指定名称位于根或者更高层次的域层次结构。
顶级域：用来指示某个国家、地区或者组织。采用三个字符，如com -> 商业公司，edu -> 教育机构，net -> 网络公司，gov -> 非军事政府机构等等。
二级域：个人或者组织在Internet使用的注册名称。采用两个字符，如：cn -> 代表中国，jp -> 日本，uk -> 英国，hk -> 香港等等。
主机：主机名处于域名空间结构中的最底层，主机名和域名结合构成FQDN，主机名是FQDN最左端的部分。
三、DNS的获取流程
DNS是应用层协议，事实上他是为其他应用层协议工作的，包括不限于HTTP和SMTP以及FTP，用于将用户提供的主机名解析为IP地址。
具体过程如下：
①用户主机上运行着DNS的客户端，就是我们的PC机或者手机客户端运行着DNS客户端了。
②浏览器将接收到的url中抽取出域名字段，就是访问的主机名，比如http://www.baidu.com/，并将这个主机名传送给DNS应用的客户端。
③DNS客户机端向DNS服务器端发送一份查询报文，报文中包含着要访问的主机名字段（中间包括一些列缓存查询以及分布式DNS集群的工作）。
④该DNS客户机最终会收到一份回答报文，其中包含有该主机名对应的IP地址。
⑤一旦该浏览器收到来自DNS的IP地址，就可以向该IP地址定位的HTTP服务器发起TCP连接。
四、DNS服务的体系架构
DNS服务的作用：把域名解析为IP地址，将IP地址解析为域名。
假设运行在用户主机上的某些应用程序（如Webl浏览器或者邮件阅读器）需要将主机名转换为IP地址。这些应用程序将调用DNS的客户机端，并指明需要被转换的主机名。（在很多基于UNIX的机器上，应用程序为了执行这种转换需要调用函数gethostbyname（））。用户主机的DNS客户端接收到后，向网络中发送一个DNS查询报文。所有DNS请求和回答报文使用的UDP数据报经过端口53发送（至于为什么使用UDP，请参看为什么域名根服务器只能有13台呢？ - 郭无心的回答）经过若干ms到若干s的延时后，用户主机上的DNS客户端接收到一个提供所希望映射的DNS回答报文。这个查询结果则被传递到调用DNS的应用程序。因此，从用户主机上调用应用程序的角度看，DNS是一个提供简单、直接的转换服务的黑盒子。但事实上，实现这个服务的黑盒子非常复杂，它由分布于全球的大量DNS服务器以及定义了DNS服务器与查询主机通信方式的应用层协议组成。
五、DNS为什么不采用单点的集中式的设计方式，而是使用分布式集群的工作方式？
DNS的一种简单的设计模式就是在因特网上只使用一个DNS服务器，该服务器包含所有的映射，在这种集中式的设计中，客户机直接将所有查询请求发往单一的DNS服务器，同时该DNS服务器直接对所有查询客户机做出响应。尽管这种设计方式非常诱人，但它不适用当前的互联网。因为当今的因特网有着数量巨大并且在持续增长的主机，这种集中式设计会有单点故障，通信容量（上亿台主机发送的查询DNS报文请求，包括但不限于所有的HTTP请求，电子邮件报文服务器，TCP长连接服务），远距离的时间延迟（澳大利亚到纽约的举例），维护开销大（因为所有的主机名-IP映射都要在一个服务站点更新）等问题。
DNS服务器一般分三种，根DNS服务器，顶级DNS服务器，权威DNS服务器。
六、DNS服务的工作过程
当 DNS 客户机需要查询程序中使用的名称时，它会查询本地DNS 服务器来解析该名称。客户机发送的每条查询消息都包括3条信息，以指定服务器应回答的问题。
● 指定的 DNS 域名，表示为完全合格的域名 (FQDN) 。
● 指定的查询类型，它可根据类型指定资源记录，或作为查询操作的专门类型。
● DNS域名的指定类别。
对于DNS 服务器，它始终应指定为 Internet 类别。例如，指定的名称可以是计算机的完全合格的域名，如im.qq.com，并且指定的查询类型用于通过该名称搜索地址资源记录。
DNS 查询以各种不同的方式进行解析。客户机有时也可通过使用从以前查询获得的缓存信息就地应答查询。DNS 服务器可使用其自身的资源记录信息缓存来应答查询，也可代表请求客户机来查询或联系其他 DNS 服务器，以完全解析该名称，并随后将应答返回至客户机。这个过程称为递归。
另外，客户机自己也可尝试联系其他的 DNS 服务器来解析名称。如果客户机这么做，它会使用基于服务器应答的独立和附加的查询，该过程称作迭代，即DNS服务器之间的交互查询就是迭代查询。
DNS的查询过程如下所示：
1、在浏览器中输入www . qq .com 域名，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
2、如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。
3、如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/ip参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
4、如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。
5、如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(http://qq.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找http://qq.com域服务器，重复上面的动作，进行查询，直至找到www
. qq .com主机。
6、如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。
从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间就是的交互查询就是迭代查询。
在了解什么是三次握手之前，我们将通过一系列术语并理解它们。我们将逐步走向
tcp三次握手。如果您觉得自己对本教程中的内容不了解，可以通过slashmaster@slashroot.in将您的quries邮寄给我。
首先让我们知道什么是TCP。
大多数人已经知道传输控制协议是它的完整形式。现在让我们了解传输控制协议究竟是什么。
这个名称确实告诉我们，它是以可靠的方式控制数据传输的东西。
让我们了解当网络中的两台机器相互通信时，TCP何时何地发挥作用。
市场上现有的每个操作系统，无论是Windows，Linux，Mac，Unix还是Symbian，Android，Ios等移动操作系统，都
包含了tcp堆栈。如果操作系统的内核没有内置TCP网络堆栈，则
该设备与其他设备之间不可能发生通信。
TCP堆栈包含以下内容。TCP堆栈中的内容存在于层中，它们如下所示。
第5层：这是我们的应用程序尝试与服务器建立连接的层。例如，假设
您的计算机上安装了Firefox浏览器，并且您正尝试与www.google.com建立连接。现在，浏览器知道如何打开临时端口并请求连接到
www.google.com服务器上的80端口。此层称为应用程序层，我们所有应用程序都尝试建立连接。无论是浏览器，ftp客户端，ssh客户端
等。
第4层：这是我们的主题进入图片的层，该层被命名为传输层，该层有两个协议（TCP，UDP）。的任何一方
可以使用，大多数在我们的日常生活中我们使用TCP（因为大多数应用程序需要TCP提供的可靠连接）。例如，也
使用UDP作为查询DNS服务器我们通常使用UDP协议。大多数人一定听说过网络中的段或MSS（最大段大小），现在TCP通过
称为带重传（PAR）的肯定确认来提供通信的可靠性。
现在，使用PAR的系统会重新发送数据，除非它确认数据到达目的地是正常的。传输层中的数据块
称为段。机器发送的每个段还包含校验和，用于检查在接收方结束时收到的数据是否正确。如果收到数据
在接收方端没有损坏，然后接收方发送肯定确认，如果它被损坏，则接收方丢弃该段（并且发送方
重新发送未收到肯定确认的所有段）。
现在有一个重要的问题。为什么三方握手称为三方握手??????????
因为在发送方和接收方之间交换了三个网段，以便建立可靠的TCP连接。
我将逐一详细解释上述三个步骤。
步骤 1：机器1想要启动与机器2的连接，因此机器1发送具有SYN（同步序列号）的段。该段将通知机器2机器1想要开始与机器2的通信并且通知机器2它将开始其段的序列号。
注意：序列号主要用于按顺序保存数据。
步骤2：机器2将响应机器1并设置“确认”（ACK）和SYN位。现在机器2的ACK段做了两件事; 他们如下。
I’ve been excited about React ever since it came out but haven’t been able to blog about it. So naturally when ReactNative was introduced last year I was super anxious to try it and even more when the Android support was released.
关于如何在mac下搭建React环境这里就不详细介绍了，有兴趣的朋友可以看：在Mac上搭建RN基础环境，今天要说的是如何在mac下使用Atom＋Nuclide组合环境来开发项目。
1.Default Parameters in ES6 var link = function(height = 50, color = ‘red’, url = ‘http://azat.co’) { //set default value to the parameter … }
JavaScript 标准参考教程（alpha） 浏览器环境 浏览器环境概述 GitHub TOP 浏览器环境概述 来自《JavaScript 标准参考教程（alpha）》，by 阮一峰
Next you can update your site name, avatar and other options using the _config.yml file in the root of your repository (shown below).
先回答我：为什么模块很重要？
答：因为有了模块，我们就可以更方便地使用别人的代码，想要什么功能，就加载什么模块。
但是，这样做有一个前提，那就是大家必须以同样的方式编写模块，否则你有你的写法，我有我的写法，岂不是乱了套！
于是下面三个模块规范出来了，这篇文章也出来了（拼出来的 {捂脸笑}）。
JS中的模块规范（CommonJS，AMD，CMD），如果你听过js模块化这个东西，那么你就应该听过或CommonJS或AMD甚至是CMD这些规范咯，我也听过，但之前也真的是听听而已。 现在就看看吧，这些规范到底是啥东西，干嘛的。本文包括这三个规范的来源及对应的产物的原理。
一、CommonJS
1.一开始大家都认为JS是辣鸡，没什么用，官方定义的API只能构建基于浏览器的应用程序，逗我呢，这太狭隘了吧(用了个高端词，嘎嘎)，CommonJS就按耐不住了，CommonJS API定义很多普通应用程序（主要指非浏览器的应用）使用的API，从而填补了这个空白。它的终极目标是提供一个类似Python，Ruby和Java标准库。这样的话，开发者可以使用CommonJS API编写应用程序，然后这些应用可以运行在不同的JavaScript解释器和不同的主机环境中。
在兼容CommonJS的系统中，你可以使用JavaScript开发以下程序：
(1).服务器端JavaScript应用程序
(2).命令行工具
(3).图形界面应用程序
(4).混合应用程序（如，Titanium或Adobe AIR）
2009年，美国程序员Ryan Dahl创造了node.js项目，将javascript语言用于服务器端编程。这标志"Javascript模块化编程"正式诞生。因为老实说，在浏览器环境下，没有模块也不是特别大的问题，毕竟网页程序的复杂性有限；但是在服务器端，一定要有模块，与操作系统和其他应用程序互动，否则根本没法编程。NodeJS是CommonJS规范的实现，webpack 也是以CommonJS的形式来书写。
