paste some interesting things.
出于个人习惯，我在终端模拟器（iTerm2 等）中，都是将光标（cursor）设置为 vertical bar，而在 neovim 中则是将 normal 模式的光标设置为 block。
这样一来，当我从 neovim 的正常模式退出时，导致终端的光标样式也变成了 block，非常麻烦。主要是因为终端没有提供 API 查询当前的光标样式设置，因此 neovim 在退出时也不知道要如何重设光标。
思路就是退出 neovim 的时候把光标重新设置为 vertical bar(ver25)。
if $TERM_PROGRAM =~ "iTerm"
" reset cursor when vim exits
au VimLeave * set guicursor=a:ver25-blinkon0
endif其中ver25就是想要设置的样式，也可以是block等等，这样在退出 neovim 的时候就会重新将 iTerm2 的光标设置为 vertical bar。
鉴于 disqus 在国内访问越来越慢，资源和数据请求量越来越大，严重拖慢了页面加载，而且博客也只需要一个简单的评论对话系统，所以开始考虑进行评论系统的迁移。
hashover 满足了我对评论系统的期望，简单，数据本地化，可以轻松迁移。
hashover 的评论数据存储默认基于网站的 path，这就使得在迁移的过程中，只要网站的 path 没变，那么相应的评论数据就可以自动对应。
基于 PHP 也使得它在部署时非常方便，对于 WordPress 的运行环境来说是无缝的。
我选择把 hashover 的数据都直接保存在本地，这样如果以后我有迁移的需求，直接将 hashover 打包传输到新的地方，就可以完成迁移工作。
原先的评论系统是 disqus，所以需要转换到 hashover 的数据存储，在网上找到一个原始的转换器 https://github.com/ianrenton/disqus-to-hashover ，但是它只支持 hashover 1.0 的版本，而我直接使用了 next(2.0) 的版本，所以 fork 了一份，并做了一些改动，使它适配了 2.0 的版本，并且完善了 gravatar 头像的数据支持。
起因是这样的，一开始在项目中写了一个原始的 Popup 组件（通过 react-redux 的 connect 方法接入 redux)，后来有了一个更高级的需求，我就想要直接 extends 这个原始的 Popup 组件，然后覆写一些方法。 然后遇到了一个问题，继承之后的子组件没有父组件的自定义方法。
最初一度怀疑是否是 babel 的 decorator 插件有问题（毕竟不是浏览器天然支持的特性），但是仔细看了 decorator 插件的源码，发现并不存在这种问题。 后来在这个插件的 issues 里看到了这么一个 issue，问题并不算是同一个，但是作者提到，react-redux 的 connect 方法可能实现有一些问题（当然这个地方并不是），我就想到去看看 connect 的实现。 然后就看到了底层方法 connectAdvanced 中有这么一句代码：
export default connectAdvanced() {
// ...
return hoistStatics(Connect, WrappedComponent);
}hoistStatics 是一个第三方库 hoist-non-react-statics，它干的事情也比较简单：
Copies non-react specific statics from a child component to a parent component. Similar to Object.assign, but with React static keywords blacklisted from being overridden.
简单来说，就是复制所有非 React 自有的属性，因为使用了 Object.getOwnPropertyNames()的方法，所以我们定义在 Component 上的所有方法就不会被复制到这个新的对象上了。 而在 connectAdvanced 内部，render 时实际是这样的：
render() {
const selector = this.selector
selector.shouldComponentUpdate = false
if (selector.error) {
throw selector.error
} else {
return createElement(WrappedComponent, this.addExtraProps(selector.props))
}
}通过 createElement 方法给原始的 WrappedComponent 传入额外的 props，来实现 connect 的效果。 总之，最终 connect 方法返回这个对象，其实和原始的 Component 的结构并不一样，虽然它的 WrappedComponent 属性指向了原始的 Component，但是显然在我们的场景下，并不能使用。
通常的推荐解决方式就是『高阶组件』，这样就屏蔽了 connect 的逻辑。
关于这个问题，作者在 这一个 issue 的回答中 也说了很多，总结来说，就是为了避免使用者可以直接的接触到 connect 之后的组件的内部方法，防止因为各种改动导致组件的 "break"，这也算是为了提升健壮性。
build delightful, modern, responsive web experiences. — Google Web Fundamentals
前端的性能指标在通常情况下是一个很难量化的指标，面向的用户群体和环境复杂，在现有条件下，网页的绝对性能仍然取决于用户的网络连接。
因此本文基本参考 Google 在 PageSpeed Insights 中的标准，考量点都是与网络无关的因素：服务器配置、网页的 HTML 结构及其所用的外部资源。
实际上前端的性能优化，非常依赖于开发者的经验，技术和环境的快速发展，大多数开发者还没能建立起完善、可靠的性能优化体系。因此，我更喜欢参考大型企业的标准，来制定优化规则。
首先要提到这个单词，一般来说，它可以被翻译成高性能，不过，在前端领域，其实 Performance 还有另外一层含义，『高表现力』。
高表现力就意味着高可用性、高易用性和高度的用户友善设计。不过这些内容层次太高，本文只讨论高性能这一个环节。
从 Google 建立以来，它一直是这个世界上最顶尖的 Web 技术开发和使用者之一，我认为它所施行和推广的 Web 技术体系，是可以作为我们开发过程中的有效参考的。
首先要介绍的是两个 Google 下属的直接面向前端性能优化的项目，PageSpeed 和 Web Fundamentals。
PageSpeed 是个历史悠久的项目，从建立以来就是针对高性能的网站开发。它的工作流程就是，抓取网页，按照一定的规则去分析网页，给出参考的性能评分和优化建议。
所以首先要看的就是它的规则。在性能方面，PageSpeed 的规则概括为以下几条：
在这些规则之中，有一些是已经成为成熟的方案，而被广泛采用，成为整个技术实现的基本环节，这些规则不再需要阐述，因为大家都在这么做了，比如 Enable compression (gzip 压缩）。所以下面只介绍一些比较容易被忽略的问题。
先介绍一下 Landing Page，根据 Wiki 的定义
a single web page that appears in response to clicking on a search engine optimized search result or an online advertisement.
简单来说就是用户从另一个页面（站点）跳转到目标站点的入口页面，通常情况下就是网站的首页。所以这条规则就是避免首页的重定向。
理由也很简单，最好的情况下，每一次重定向就增加一次往返（HTTP 请求-响应），而糟糕的情况下就会增加很多次。每一次的往返中包含了 DNS 查询，TCP 握手，TLS 认证环节。
以 Snow/Beef （主站退单/手淘退单）为例。为了区分不同的订单退单情况，这两个项目都使用服务器端跳转来引导客户端页面转向到对应的路由（业务逻辑）。
那么从用户的角度来说，这里就多了一次往返逻辑，用户需要多等待一次请求/响应，然后再进入对应的页面。当然，这也是因为受限于客户端（APP）的 WebView 环境而选择一种解决方案。
这个问题主要发生在一些设计素材上，为了保证高度还原而选择高质量的图片，就忽略了图片的大小。
有时候也可以适当考虑，使用 CSS 来实现，以减小图片的使用率。
如同上文所说，这些规则基本上已经成为了业界广泛采用的标准，以现在的环境来看，这些大方向上的实践已经没有太多问题。因此，如果想要更进一步的提升页面性能，那就需要更加细致的挖掘。
Web Fundamentals 是 Google 2014 年发起的项目。
The fundamental knowledge you need to build delightful, modern, responsive web experiences.
项目总结也很简单：提供令人赏心悦目的现代化响应式 Web 体验所必须的基础知识。其中有一个章节『Performance』着重介绍了网页性能这一块的知识，并且，由于项目较新，所以讨论到的内容以及技术也适应了新的环境，比较有参考价值。
这个章节这样总结提高性能的技巧：提高性能表现的过程要从最小化，或者至少从优化用户下载数据开始。提高代码效率的前提是要理解浏览器是如何渲染这些文件的。最后，你需要一些方法来测试你的优化的效果。
最小化（优化）数据内容大小，提高代码效率，测试优化效果。这些就是一个完整的优化方法。
这一节都是关于如何优化『delivery』的效率，作者总结了几个要点：
对比一下之前在 PageSpeed 一节提到的优化点，这里新增了『限制不必要的下载』、『优化 Web Font』。
以金融运营平台为例，引入了 Font-awesome、Glyphicon 两种 Web Font（icon font），Font-awesome 用来处理各种图标，而 Glyphicon 是因为 ui-grid 这个库依赖于它。两个 Web Font 其实非常大，并且 Glyphicon 只有 ui-grid 使用了，并且用到的字体非常少。在后续优化中，针对 Glyphicon 的 CSS 设计，使用 Font-awesome 写了替代规则，从而移除了 Glyphicon。
文章中其实提供了相当多的 Web Font 优化技巧，也可以作为很好的参考。
浏览器在获取 HTML，CSS 和 JavaScript 文件之后，将他们渲染成页面上每一个对应的像素，所经过的步骤就是 critical rendering path，就是也就是概述中提到的理解浏览器如何渲染页面。当然，浏览器引擎对于大多数人来说还是太复杂、太深奥了一点，我们可以了解一下简略的内容。
head 标签中，而把 JavaScript 资源写在 body 标签的结尾处，为了让浏览器优先获取 HTML 和 CSS，不让 JavaScript 阻塞页面渲染。另外，Media type 和 Media query 是可以把 CSS 标记为非阻塞形式，这样就可以保证浏览器只处理需要的资源。不过即使是这样，浏览器还是需要先把所有 CSS 资源下载完成，所以，依然需要保证 CSS 资源的优化。
async 这种特性，使用的比较多的，就是各类页面分析、页面监控服务的 JavaScript 库，因为它们的逻辑和页面主线功能互不影响。
到这里为止，页面的渲染就完成了，在这之后，作者还分享了针对 Critical Rendering Path 的各种优化方法，可以进一步了解学习（都包括在文末参考文献中）。
这一节的主要内容就是如何提升你的代码效率。毫无疑问，你需要了解浏览器处理 HTML，CSS 和 JavaScript 的方式。作者提到：高性能的页面，不仅仅是加载迅速，同时还要能正确地运行；页面滚动必须无延迟跟随手指，动画和交互必须如丝般顺滑，这就是所说的『令人赏心悦目的 Web 体验』。
绝大部分设备 1 秒钟刷新屏幕 60 次，这就是我们说的页面动画必须达到 60 fps 的原因，然后简单计算一下的话，每一帧有 16 毫秒时间，除去浏览器工作的开销，基本上我们在一帧之内有 10 毫秒的时间来完成我们的各种工作，那么，如果说某一个任务超过了 10 毫秒，就会带来一个直观的感受，『页面卡了』。
浏览器的一次工作流程就是：JavaScript > Style > Layout > Paint > Composite 所以也很容易理解，为了提升页面效率，就需要尽可能地减少浏览器的工作步骤，而在上面的五个步骤中，Layout 和 Paint 是可以被避免的，这就是我们优化的关键。
Optimize JavaScript Execution简单来说，在不恰当的时间点运行的 JavaScript 或者运行周期比较长的 JavaScript 代码，就会导致性能问题，这些就是优化的关键点。
当然，首先了解到，实际上在浏览器中执行的代码和你写的 JavaScript 代码并不一样，现代浏览器都采用了 JIT 编译器来优化你写的代码，以提升运行效率，不过这是比较复杂的问题了，我们还是从简单的地方入手。
先了解一个概念 Visual Changes，就是那些不会直接影响页面样式的代码逻辑，比如查找数据和数据排序。
Reduce the Scope and Complexity of Style Calculations这一条很好理解，降低样式的复杂度。由于每一次 DOM 的变更，浏览器都需要重新计算元素样式，进行 Layout（或者 reflow），所以降低样式复杂度，是提升页面渲染效率的很重要的一环。
Avoid Large, Complex Layouts and Layout ThrashingLayout 就是浏览器计算元素在页面内的位置和大小的过程。和样式计算类似，Layout 的开销收到需要进行 Layout 计算的元素的数量，以及一次 Layout 的复杂程度的影响。
Layout 是开销非常大的操作，应该在可能的情况下避免它。对于 Flexbox，目前主流浏览器都已经支持了 Flex 布局，在环境允许的情况下，应当优先选择 Flexbox，并且使用新的规范。
Paint Complexity and Reduce Paint Areas Paint 通常是整个渲染过程中运行时间最长的任务。
这里提到了图层提升这个概念，就类似于 Sketch、GIMP、Photoshop 中的图层，不同的独立图层可以单独计算并最终合并。在 CSS 中，will-change 属性会创建一个新的图层，然后把值设为 transform 就会创建一个合成器层。这个方法支持 Chrome、Opera、Firefox。
那么对于那些不支持的浏览器，就只能使用 3D 变形来创建一个新的图层。利用transform: translateZ(0) 强制进行 3D 变形。需要注意，创建新的图层会增加内存和管理开销，所以需要合理安排图层。
Debounce Your Input Handlers 对各种输入操作的处理进行防抖。输出操作的处理是一个潜在的性能问题，他们可能会阻塞帧的计算，并且增加额外的、不必要的 Layout 任务。
requestAnimationFrame 的回调中进行样式变更。这里举出实际的例子就是，如果监听了 `touchstart`, `touchmove`, `touchend` 之类的事件，并且调用了 `preventDefault()` 那么合成器线程就必须要等待你的事件回调结束，在这段时间内，滚动操作就会被阻止。事实上，即使你没有调用 `preventDefault()` 合成器也还是要等待，就会导致用户的滚动操作被锁住，出现丢帧之类的问题。
以『前端』、『性能』、『优化』之类的关键词 Google 一下，可以得到数不清的结果，关于各类优化的奇巧淫技，不需要累述，我们更需要关注的是，如何有效、高效、科学地进行性能优化，就如同我们优化页面性能一样，去优化我们的开发过程。
app/app.js，执行 init 函数。app/core/config 引入配置参数，实际配置参数是 app/core/settings.js。app/core/core（controller, directive…），功能模块（’app/features/all’）public/views/index.html，参数是 window.grafanaBootData。app/featrures/all.js 中声明过的模块，所以如果有新的功能模块，确保它最终在该文件中声明了。app/core/utils/kbn.js 是各类格式化函数。app/system.conf.js 中加入定义，之后可以直接通过模块名加载。app/app.ts 中的 ngModuleDependencies 数组中加入模块名来加载它。