语雀官方的Graphviz感觉太复杂，我还是写一个简单一点的吧。 两个圆一条线 注意 graph是用来标记无向图，里面只能用–，不能用->，否则无法显然出图片 digraph用来标记有向图，里面只用用-> 不能用–, 否则无法显然出图片 graph easy { a -- b; } 连线加个备注 graph easy{ a--b [label="你真漂亮"] } 你真漂亮，要大点，红色显眼点 graph easy{ a--b [label="你真漂亮", fontcolor=red, fontsize=34] } 两个圆，一个带有箭头的线 注意，这里用的digraph， 用来表示有向图 digraph easy { a -> b; } 如何画虚线呢？ digraph easy { a -> b [style=dashed]; } 椭圆太单调了，有没有其他形状？ shape box 矩形 polygon ellipse circle 圆形 point egg 蛋形 triangle 三角形 plaintext 使用文字 diamond 钻石型 trapezium 梯形 parallelogram 斜的长方形 house hexagon octagon doublecircle doubleoctagon tripleoctagon invtriangle invtrapezium invhouse Mdiamond Msquare Mcircle none record Mrecord graph easy { node [shape=box] a -- b; } 形状也可以直接给节点定义。...

如何学习网络协议？ 大学时，学到网络协议的7层模型时，老师教了大家一个顺口溜：物数网传会表应。并说这是重点，年年必考，5分的题目摆在这里，你们爱背不背。 考试的时候，果然遇到这个问题，搜索枯肠，只能想到这7个字的第一个字，因为这5分，差点挂科。 后来工作面试，面试官也是很喜欢七层模型，三次握手之类的问题，但是遇到这些问题时，总是觉得很心虚。 1. 协议分层 四层网络协议模型中，应用层以下一般都是交给操作系统来处理。应用层对于四层模型来说，仅仅是冰山一角。海面下巨复杂的三层协议，都被操作系统给隐藏起来了，一般我们在页面上发起一个ajax请求，看见了network面板多了一个http请求，至于底层是如何实现的，我们并不关心。 应⽤层负责处理特定的应⽤程序细节。 运输层运输层主要为两台主机上的应⽤程序提供端到端的通信。 网络层处理理分组在⽹网络中的活动，例例如分组的选路 链路层处理理与电缆(或其他任何传输媒介)的物理理接⼝口细节 下面重点讲一下运输层和网络层 1.1. 运输层的两兄弟 运输层有两个比较重要的协议。tcp和udp。 大哥tcp是比较严谨认真、温柔体贴、慢热内向的协议，发出去的消息，总是一个一个认真检查，等待对方回复和确认，如果一段时间内，对方没有回复确认消息，还会再次发送消息，如果对方回复说你发的太快了，tcp还会体贴的把发送消息的速度降低。 弟弟udp则比较可爱呆萌、调皮好动、不负责任的协议。哥哥tcp所具有的特点，弟弟udp一个也没有。但是有的人说不清哪里好 但就是谁都替代不了，udp没有tcp那些复杂的校验和重传等复杂的步骤，所以它发送消息非常快，而且并不保证对方一定收到。如果对方收不到消息，那么udp就会呆萌的看着你，笑着对你说：我已经尽力了。一般语音而视频数据都是用udp协议传输的，因为音频或者视频卡了一下并不影响整体的质量，而对实时性的要求会更高。 1.2. 运输层和网络层的区别 运输层关注的是端到端层面，及End1到End2，忽略中间的任何点。 网络层关注两点之间的层面，即hop1如何到hop2，hop2如何到hop3 网络层并不保证消息可靠性，可靠性上层的传输层负责。TCP采用超时重传，分组确认的机制，保证消息不会丢失。 从下图tcp, udp, ip协议中，可以发现 传输层的tcp和udp都是有源端口和目的端口，但是没有ip字段 源ip和目的ip只在ip数据报中 理解各个协议，关键在于理解报文的各个字段的含义 1.3. ip和端口号的真正含义 上个章节讲到运输层和网络层的区别，其中端口号被封装在运输层，ip被封装到网络成， 那么端口号和ip地址到底有什么区别呢？ ip用来用来标记主机的位置 端口号用来标记该数据应该被目标主机上的哪个应用程序去处理 1.4. 数据在协议栈的流动 封装与分用 当发送消息时，数据在向下传递时，经过不同层次的协议处理，打上各种头部信息 当接受消息时，数据在向上传递，通过不同的头部信息字段，才知道要交给上层的那个模块来处理。比如一个ip包，如果没有头部信息，那么这个消息究竟是交给tcp协议来处理，还是udp来处理，就不得而知了 2. 深入阅读，好书推荐 《http权威指南》 有人说这本书太厚，偷偷告诉你，其实这本书并厚，因为这本书的后面的30%部分都是附录，这本书的精华是前50%的部分 《图解http》、《图解tcp/ip》这两本图解的书，知识点讲的都是比较通俗易懂的，适合入门 《tcp/ip 详解 卷1》这本书，让你知其然，更知其所以然 《tcp/ip 基础》、《tcp/ip 路由技术》这两本书，会让你从不同角度思考协议 《精通wireshark》、《wireshark网络分析实战》如果你看了很多书，却从来没有试过网络抓包，那你只是懂纸上谈兵罢了。你永远无法理解tcp三次握手的怦然心动，与四次分手的刻骨铭心。

什么是呼叫中心？ 呼叫中心又称为客户服务中心。有以下关键词 CTI 通信网络 计算机 企业级 高质量、高效率、全方位、综合信息服务 呼叫中心历史 1956年美国泛美航空公司建成世界第一家呼叫中心。 阶段 行业范围 技术 功能与意义 第一代呼叫中心 民航 PBX、电话排队 主要服务由人工完成 第二代呼叫中心 银行、生活 IVR(交互式语音应答)、DTMF 显著提高工作效率，提供全天候服务 第三代呼叫中心 CTI(电脑计算机集成) 语音数据同步，客户信息存储与查阅，个性化服务，自动化 第四代呼叫中心 接入电子邮件、互联网、手机短信等 多渠道接入、多渠道统一排队 第五代呼叫中心 接入社交网络、社交媒体(微博、微信等) 文本交谈，音频视频沟通 呼叫中心分类 按呼叫方式分类 外呼型呼叫中心（如电话营销） 客服型呼叫中心（如客户服务） 混合型呼叫中心 （如营销和客服） 按技术架构分类 交换机 板卡 软交换（IPCC） 【交换机类型呼叫中心】

2008-2018 十年，往事如昨 2018年已经是昨天，今天是2019的第一天。 2008年已经是10年前，10年前的傍晚，我走在南京仙林的一个大街上，提着一瓶矿泉水，擦着额头的汗水，仰头看着大屏幕上播放着北京奥运会的开幕式。 10年前的夏天，我带着一步诺基亚手机功能机，独自一人去了南京。 坐过绣球公园的石凳，穿过天妃宫的回廊，吹过阅江楼的凉爽的江风，踏着古老斑驳的城墙，在林荫小路的长椅上，我想着10年后我会在哪里？做着什么事情？ 往事如昨，而今将近而立，但是依然觉得自己还是10年的那个独自出去玩的小男孩。 2018 读了10年都没有读完的书，五味杂陈 2018年，在我做手术前，我觉得自己出了工作的时间外，大多数时间都在看书。2018年这一年看的书，要比2008到2018年这十年间的看的书都要多。这都归功于我对每天的看书都有定量的计划，一旦按照这个计划实行几个月，积累的效果还是非常明显的。 2018年，手机几乎成为人的四肢之外的第五肢。对大多人来说，上厕所可以不带纸，但是不能不带手机。 各种APP, 都在极力的吸引用户多花点时间在自己身上 信息流充斥着各种毫无营养，专门吸人眼球的垃圾新闻，但是这种新闻的阅读量还是蛮大的 各种借钱，信用卡，花呗等都像青楼的小姐，妩媚的笑容，说道：官人，进来做一做 共享单车，在今年退潮之后，才发现自己都在裸泳 比特币，挖矿机。不知道谁割了谁的韭菜，总希望有下一个傻子来接盘，最后发现自己可能就是最后一个傻子 AI，人工智能很火，放佛就快要进入终结者那样的世界 锤子垮了，曾经吹过的牛逼，曾经理想主义终于脱去那又黑又亮的面具 图灵测试（The Turing test）由艾伦·麦席森·图灵发明，指测试者与被测试者（一个人和一台机器）隔开的情况下，通过一些装置（如键盘）向被测试者随意提问。 进行多次测试后，如果有超过30%的测试者不能确定出被测试者是人还是机器，那么这台机器就通过了测试，并被认为具有人类智能。图灵测试一词来源于计算机科学和密码学的先驱阿兰·麦席森·图灵写于1950年的一篇论文《计算机器与智能》，其中30%是图灵对2000年时的机器思考能力的一个预测，目前我们已远远落后于这个预测。 最后说一下图灵测试，在AI方面，这个测试无人不知。一个机器如果通过了图灵测试，则说明该机器具有了只能。但是三体的作者大刘曾经说过一句话，给我一种醍醐灌顶的感觉，假如一个机器人有能力通过图灵测试，却假装无法通过，你说这个机器是否具有人工智能。所以大刘的这种说法才更加让人恐惧。机器人能通过图灵测试，只说明这个机器人具有了智能。但是现阶段的智能只不过是条件反射，或者是基于概率计算的结果。后者这种能通话测试，却假装无法通过的智能。这不仅仅是智能，而是机器的城府。 有智能的机器并不可怕，有城府的机器人才是真正的可怕。 如果梦中更加幸福快乐，为什么要回到现实 火影的最后，大筒木辉夜使用无限月读将世界上的所有人都带入梦境，每个人的查克拉都被吸取，并作为神树的养料。 如果真的存在大筒木这样的上帝，那么时间就是查克拉。人类唯一真正拥有过的东西，时间，将作为神树的养料，从每个人身上提取。 各种具有吸引力的术，其实可以理解为无限月读，让人沉醉于梦幻中。 如果梦中更加幸福快乐，为什么要回到现实中承受压力与悲哀呢？ 目前我无法回复自己的这个问题，期待2019年我可以得到这个答案。 工作方面 2019年，我会在做一些后端方面的工作，努力加油吧。

1. demo 如果你对下面的代码没有任何疑问就能自信的回答出输出的内容，那么本篇文章就不值得你浪费时间了。 var var1 = 1 var var2 = true var var3 = [1,2,3] var var4 = var3 function test (var1, var3) { var1 = 'changed' var3[0] = 'changed' var3 = 'changed' } test(var1, var3) console.log(var1, var2, var3, var4) 2. 深入理解原始类型 原始类型有5个 Undefinded, Null, Boolean, Number, String 2.1. 原始类型变量没有属性和方法 // 抬杠, 下面的length属性，toString方法怎么有属性和方法呢？ var a = 'oooo' a.length a.toString 原始类型中，有三个特殊的引用类型Boolean, Number, String，在操作原始类型时，原始类型变量会转换成对应的基本包装类型变量去操作。参考JavaScript高级程序设计 5.6 基本包装类型。 2.2. 原始类型值不可变 原始类型的变量的值是不可变的，只能给变量赋予新的值。 下面给出例子 // str1 开始的值是aaa var str1 = 'aaa' // 首先创建一个能容纳6个字符串的新字符串 // 然后再这个字符串中填充 aaa和bbb // 最后销毁字符串 aaa和bbb // 而不能理解成在str1的值aaa后追加bbb str1 = str1 + 'bbb' 其他原始类型的值也是不可变的, 例如数值类型的。...

当函数执行到this.agents.splice()时，我设置了断点。发现传参index是0，但是页面上的列表项对应的第一行数据没有被删除， WTF！！！ 这是什么鬼！然后我打开Vue Devtools, 然后刷新了一下，发现那个数组的第一项还是存在的。什么鬼？？ removeOneAgentByIndex: function (index) { this.agents.splice(index, 1) } 然后我就谷歌了一下，发现这个splice not working properly my object list VueJs, 大概意思是v-for的时候最好给列表项绑定:key=。然后我是试了这个方法，发现没啥作用。 最终我决定，单步调试，如果我发现该问题出在Vue自身，那我就该抛弃Vue, 学习React了 单步调试中出现一个异常的情况，removeOneAgentByIndex是被A函数调用的，A函数由websocket事件驱动。正常情况下应该触发一次的事件，服务端却发送了两次到客户端。由于事件重复，第一次执行A删除时，实际上removeOneAgentByIndex是执行成功了，但是重复的第二个事件到来时，A函数又往agents数组中添加了一项。导致看起来，removeOneAgentByIndex函数执行起来似乎没有设么作用。而且这两个重复的事件是在几乎是在同一时间发送到客户端，所以我几乎花了将近一个小时去解决这个bug。引起这个bug的原因是事件重复，所以我在前端代码中加入事件去重功能，最终解决这个问题。 我记得之前看过一篇文章，一个开发者调通过回调函数计费，回调函数是由事件触发，但是没想到有时候事件会重发，导致重复计费。后来这名开发者在自己的代码中加入事件去重的功能，最终解决了这个问题。 事后总结：我觉得我不该怀疑Vue这种库出现了问题，但是我又不禁去怀疑。 通过这个bug, 我也学到了第二方法，可以删除Vue数组中的某一项，参考下面代码。 // Only in 2.2.0+: Also works with Array + index. removeOneAgentByIndex: function (index) { this.$delete(this.agents, index) } 另外Vue devtools有时候并不会实时的观测到组件属性的变化，即使点了Refresh按钮。如果点了Refresh按钮还不行，那建议你重新打开谷歌浏览器的devtools面板。

本文重点是讲解如何解决循环依赖这个问题。关心这个问题是如何产生的，可以自行谷歌。 如何重现这个问题 // a.js const {sayB} = require('./b.js') sayB() function sayA () { console.log('say A') } module.exports = { sayA } // b.js const {sayA} = require('./a.js') sayA() function sayB () { console.log('say B') } module.exports = { sayB } 执行下面的代码 ➜ test git:(master) ✗ node a.js /Users/dd/wj-gitlab/tools/test/b.js:3 sayA() ^ TypeError: sayA is not a function at Object.<anonymous> (/Users/dd/wj-gitlab/tools/test/b.js:3:1) at Module._compile (module.js:635:30) at Object.Module._extensions..js (module.js:646:10) at Module.load (module.js:554:32) at tryModuleLoad (module....

shields小徽章介绍 一般开源项目都会有一些小徽章来标识项目的状态信息，并且这些信息是会自动更新的。在shields的官网https://shields.io/#/, 上面有各种各样的小图标，并且有很多自定义的方案。 起因：如何给私有部署的jenkins制作shields服务？ 私有部署的jenkins是用来打包docker镜像的，而我想获取最新的项目打包的jenkins镜像信息。但是私有的jenkins项目信息，公网的shields服务是无法获取其信息的。那么如果搭建一个私有的shields服务呢？ 第一步：如何根据一些信息，制作svg图标 查看shields图标的源码，可以看到这些图标都是svg格式的图标。然后的思路就是，将文字信息转成svg图标。最后我发现这个思路是个死胡同， 有个npm包叫做，text-to-svg, 似乎可以将文本转成svg, 但是看了文本转svg的效果，果断就放弃了。 最后回到起点，看了shields官方仓库，发现一个templates目录，豁然开朗。原来svg图标是由svg的模板生成的，每次生成图标只需要将信息添加到模板中，然后就可以渲染出svg字符串了。 顺着这个思路，发现一个包shields-lightweight var shields = require('shields-lightweight'); var svgBadge = shields.svg('subject', 'status', 'red', 'flat'); 这个包的确可以生成和shields一样的小徽章，但是如果徽章中有中文，那么中文就会溢出。因为一个中文字符的宽度要比一个英文字符宽很多。 所以我就fork了这个项目，重写了图标宽度计算的方式。shields-less npm install shields-less var shieldsLess = require('shields-less') var svgBadge = shieldsLess.svg({ leftText: 'npm 黄河远上白云间', rightText: 'hello 世界' }) var svgBadge2 = shieldsLess.svg({ leftText: 'npm 黄河远上白云间', rightText: 'hello 世界', style: 'square' }) var svgBadge2 = shieldsLess.svg({ leftText: 'npm 黄河远上白云间', rightText: 'hello 世界', leftColor: '#e64a19', rightColor: '#448aff', style: 'square' // just two style: square and plat(default) }) 渲染后的效果，查看在线demo: https://wdd....

前后端分离应用的架构 在前后端分离架构中，为了避免跨域以及暴露内部服务地址。一般来说，我会在Express这层中加入一个反向代理。 所有向后端服务访问的请求，都通过代理转发到内部的各个服务。 这个反向代理服务器，做起来很简单。用http-proxy-middleware这个模块，几行代码就可以搞定。 // app.js Object.keys(proxyTable).forEach(function (context) { app.use(proxyMiddleware(context, proxyTable[context])) }) http-proxy-middleware实际上是对于node-http-proxy的更加简便的封装。node-http-proxy是http-proxy-middleware的底层包，如果node-http-proxy有问题，那么这个问题就会影响到http-proxy-middleware这个包。 最近的bug http-proxy-middleware最近有个问题，请求体在被代理转发前，如果请求体被解析了。那么后端服务将会收不到请求结束的消息，从浏览器的网络面板可以看出，一个请求一直在pending状态。 Cannot proxy after parsing body #299, 实际上这个问题在node-http-proxy也被提出过，而且处于open状态。POST fails/hangs examples to restream also not working #1279 目前这个bug还是处于open状态，但是还是有解决方案的。就是将请求体解析的中间件挂载在代理之后。 下面的代码，express.json()会对json格式的请求体进行解析。方案1在代理前就进行body解析，所有格式是json的请求体都会被解析。 但是有些走代理的请求，如果我们并不关心请求体的内容是什么，实际上我们可以不解析那些走代理的请求。所以，可以先挂载代理中间件，然后挂载请求体解析中间件，最后挂载内部的一些接口服务。 // 方案1 bad app.use(express.json()) Object.keys(proxyTable).forEach(function (context) { app.use(proxyMiddleware(context, proxyTable[context])) }) app.use('/api', (req, res, next)=> { }) // 方案2 good Object.keys(proxyTable).forEach(function (context) { app.use(proxyMiddleware(context, proxyTable[context])) }) app.use(express.json()) app.use('/api', (req, res, next)=> { }) 总结 经过这个问题，我对Express中间件的挂载顺序有了更加深刻的认识。 同时，在使用第三方包的过程中，如果该包bug，那么也需要自行找出合适的解决方案。而这个能力，往往就是高手与新手的区别。

IE11有安全设置中有两个选项， 跨域浏览窗口和框架 通过域访问数据源 如果上面两个选项被禁用，那么IE11会拒绝跨域请求。如果想要跨域成功，必须将上面两个选项设置为启用。 第一步 打开IE11 点击浏览器右上角的齿轮图标 点击弹框上的 Internet选项 第二步 点击安全 点击Internet 点击自定义级别 第三步 找到跨域浏览窗口和框架 如果这项是禁用的，那么要勾选启用。 找到通过域访问数据源 如果这项是禁用的，那么要勾选启用。 最后在点击确定。 最后，如果跨域浏览窗口和框架,通过域访问数据源都启用了，还是无法跨域。那么最好重启一下电脑。有些设置可能在重启后才会生效。