Origin of Ray

无论你是想要设计高性能 Web 应用，还是要优化现有的 Web 应用，你都需要了解浏览器中的网络流程、页面渲染过程，JavaScript 执行流程，以及 Web 安全理论。

这篇文章简单介绍下浏览器的架构演进。

最近看了几篇关于浏览器原理的文章，对浏览器的渲染流程有了个比较系统的了解，在这里简单总结下并顺便讲下老生常谈的重排和重绘是怎么回事。

在上一篇博客中，我们从执行机制和上下文的角度讲了javascript中的变量提升。

正是由于 JavaScript 存在变量提升这种特性，从而导致了很多与直觉不符的代码，这也是 JavaScript 的一个重要设计缺陷。

虽然 ECMAScript6（以下简称 ES6）已经通过引入块级作用域并配合 let、const 关键字，来避开了这种设计缺陷，但是由于 JavaScript 需要保持向下兼容，所以变量提升在相当长一段时间内还会继续存在。这也加大了你理解概念的难度，因为既要理解新的机制，又要理解变量提升这套机制，关键这两套机制还是同时运行在“一套”系统中的。

只有理解了 JavaScrip 的执行上下文，你才能更好地理解 JavaScript 语言本身，比如变量提升、作用域和闭包等。不仅如此，理解执行上下文和调用栈的概念还能助你成为一名更合格的前端开发者。这次我们就从上下文的角度讲一下js的变量提升。

上周的博客中我们讨论并实现了图的拓扑排序，这周我们继续学习图的另外一种基础的算法，最短路径算法Dijkstra算法，以及如何将其改造成我们平时导航或者游戏中经常使用中用到的寻路算法。

今天看了一篇关于拓扑排序的思路和应用的文章，自己手动实现记录一下。

数据结构

算法是构建在具体的数据结构之上的。针对这个问题，我们先来看下，如何将问题背景抽象成具体的数据结构？

我们可以把源文件与源文件之间的依赖关系，抽象成一个有向图。每个源文件对应图中的一个顶点，源文件之间的依赖关系就是顶点之间的边。

如果 a 先于 b 执行，也就是说 b 依赖于 a，那么就在顶点 a 和顶点 b 之间，构建一条从 a 指向 b 的边。而且，这个图不仅要是有向图，还要是一个有向无环图，也就是不能存在像 a->b->c->a 这样的循环依赖关系。因为图中一旦出现环，拓扑排序就无法工作了。实际上，拓扑排序本身就是基于有向无环图的一个算法。

这周POC了几个渗透测试工具，分别是Burp Suite，OWASP Zap。

其中Burp的很多功能都是收费的，免费版基本只是用来做请求拦截的。

所以最后选择Zap对一个Express项目进行了扫描了漏洞修复，这里简单记录一下Zap的使用教程，以及Express的一些安全实践。

上周在使用一个elementUI的table是，发现每次点击table的checkbox的时候，页面都会卡顿接近两秒钟，于是就用vue的devtools去记录了下每次的操作时间消耗在哪里，发现主要是因为elementUI的table虽然提供了树形数据和懒加载的功能，虽然子级节点没有展开，但是已经渲染出来了。

所以elementUI的table提供了懒加载的功能，但是这个懒加载的功能是有问题的，因为懒加载函数只会调用一次，以后无论如何变化数据，子节点都不会发生改变。

经过对vue和elementUI的源码分析，找到原因后适当fix了一下，在这里记录一下。

前面的六篇博客已经帮助我们基本搞清楚了，vue的响应式原理，数据驱动，组件化和组件更新等概念和原理，而其中关于组件化和组件更新的部分，我们是在已有render函数的基础上来讲的，也就是说我们已经有了vnode，再去讨论的vnode如何渲染更新的。

这篇博客我们就回过头来看看vue的compiler是如何将template变成render函数的。

了解编译的流程有什么好处呢？我个人觉得可以帮助我们对于一些vue自身的语法糖的原理有个更好的理解。

由于Compiler的细节非常多，所以大概有个结论和印象即可，其中很多关于vue自身的语法处理也不会细讲，只会用slot来做个例子。

数据结构与算法是一个非常大的范围，各种不同的问题需要不同的算法，这些算法或复杂或简单。这篇博客简单通过经典的背包问题介绍四种非常基本且常用的算法思想，分别是贪心，分治，回溯，动规。

这四种是算法思想，不是具体的算法，主要是理解其思路，而不是具体的实现。

这篇文章主要是帮我我把以前略显零散的知识点重新总结一下，所以很多具体内容在以前的其他博客中。