<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>TOM&#39;s zone</title>
    <link>https://hasaki.xyz/</link>
    <description>Recent content on TOM&#39;s zone</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>ZH-CN</language>
    <copyright>Early 2016 ~ 2020 &amp;copy; TOM&#39;s Zone</copyright>
    <lastBuildDate>Sat, 21 Mar 2020 11:34:17 +0800</lastBuildDate>
    
	<atom:link href="https://hasaki.xyz/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>系统设计入门-缓存</title>
      <link>https://hasaki.xyz/blog/2020-03-21-%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1%E5%85%A5%E9%97%A8-%E7%BC%93%E5%AD%98/</link>
      <pubDate>Sat, 21 Mar 2020 11:34:17 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2020-03-21-%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1%E5%85%A5%E9%97%A8-%E7%BC%93%E5%AD%98/</guid>
      <description>本文是根据 system-design-primer（系统设计入门） 整理，本文主要讲缓存
 从操作系统的角度来看，不同存储之间的读写速度是有区别的。缓存就是把低速存储的结果，临时保存在高速存储的技术。
在实际业务当中，缓存可以提高页面加载速度，并可以减少服务器或者数据库的负载。在这个模型中，应用会先查看请求之前是否被响应过，如果有则将之前的结果直接返回，来省掉真正的处理。
下面我们会以从客户端请求到 web 应用服务器这个流程当中可能涉及到的缓存为例来简单说一下。
Service Worker 缓存 Service Worker 是浏览器在后台独立于网页运行的脚本，可以提供请求拦截、推送通知、后台同步等功能。
Service Worker 需要浏览器支持，也需要 HTTPS，并且对应的生命周期完全独立于 网页生命周期（Page Lifecycle API）。
在成功安装 Service Worker 之后可以通过监听 fetch 事件来决定是否需要缓存：
self.addEventListener(&#39;fetch&#39;, function(event) { event.respondWith( caches.match(event.request).then(function(response) { // Cache hit - return response if (response) { return response } return fetch(event.request) }), ) })  Service Worker 对应的 API 和最佳实践都比较复杂，我们可以采用官方推荐的 workbox 来配置和部署，并且也提供了以下 缓存策略：
 CacheFirst: 缓存优先 CacheOnly: 仅缓存 NetworkFirst: 网络优先 NetworkOnly: 仅网络 StaleWhileRevaidate: 取缓存，再走网络更新缓存  客户端缓存 客户端缓存可以位于操作系统或者浏览器，在移动互联网当中也可以存在于 App 当中，可以减少服务端请求，避免文件重复加载。</description>
    </item>
    
    <item>
      <title>系统设计入门-负载均衡</title>
      <link>https://hasaki.xyz/blog/2020-03-18-%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1%E5%85%A5%E9%97%A8-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1/</link>
      <pubDate>Wed, 18 Mar 2020 14:03:17 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2020-03-18-%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1%E5%85%A5%E9%97%A8-%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1/</guid>
      <description>本文是根据 system-design-primer（系统设计入门） 整理，本文主要讲负载均衡
 数据流量过大的网络中，尤其是高并发（High Concurrency）网络，单一设备一般是无法承担的，需要多台设备进行数据分流，而负载均衡（Load Balance）就是将请求或者数据均匀分摊到多个操作单元上执行。
高并发常用的一些指标有：
 响应时间（Response Time） 吞吐量（Throughput） 每秒查询率（Query Per Second），简称 QPS  没有负载均衡的 web 架构大概如下图：
用户直接连接服务器，这个时候如果这台服务器挂了，那么就整个网站挂了。
有负载均衡的架构如下图：
用户不直接访问后端服务器，而是访问负载均衡服务器，由负载均衡服务器再次转发到后端服务器。
如果这个时候有一台后端服务器挂掉了，那么负载均衡服务器会剔除掉它，将后续请求都转发到好的那台，这样就不影响网站的正常运行。
这个时候我们也需要考虑负载均衡服务器会不会挂掉，那就引入第二个负载均衡服务器来缓解一下。
负载均衡器能帮助水平扩展（Horizontal scaling），提高性能和可用性。相对使用商业硬件的性价比更高，并且比在单台硬件上垂直扩展（Vertical scaling）更贵的硬件具有更高的可用性。
 水平拓展：增强单机硬件性能或者优化单机架构 垂直拓展：只要增加服务器数量，就能线性扩充系统性能  针对负载均衡有各种各样的实现，我们来简单梳理一下。
客户端负载均衡 简单来讲，客户端会有一个服务器地址列表，由客户端自行选择目标服务器的 IP 地址。
客户端不存在缓存的问题，也能检查服务可用性来选择可用 IP。
DNS 负载均衡 DNS 维护着域名与 IP 地址之间的映射关系，而且是可以接受我们控制的，因此可以在这里实现负载均衡策略。
 DNS 负载均衡可以通过 NS 记录将域名解析指给多台智能 DNS，以保障解析高可用，通过 IP 地址库及指定算法进行智能解析，可根据不同运营商、地理位置、内部应用情况进行智能解析分配。
 DNS 负载均衡技术实现比较灵活，成本较低，也可以根据域名解析成用户地址最近的一个服务器地址。
缺点也很明显：
 可靠性没有保障：DNS 并不检查服务器的可用性，即便目标服务器宕机或者无法访问了，也返回其 IP 地址 更新不及时：DNS 的解析结果往往会被层层缓存，记录更新无法立即生效 流量分配策略较为简单，支持的算法较少  另外一个问题，DNS 负载均衡默认采用的是 round-robin 算法，不能区分服务器之间的差异，也不能反应状态。</description>
    </item>
    
    <item>
      <title>2020年流水账</title>
      <link>https://hasaki.xyz/life/2020-03-12-2020%E5%B9%B4%E6%B5%81%E6%B0%B4%E8%B4%A6/</link>
      <pubDate>Thu, 12 Mar 2020 16:47:55 +0800</pubDate>
      
      <guid>https://hasaki.xyz/life/2020-03-12-2020%E5%B9%B4%E6%B5%81%E6%B0%B4%E8%B4%A6/</guid>
      <description> 3 月  今年真的太难了
 3 月初经大佬内推了 2 家公司，这两家我都是请假在家视频远程面试
石墨一面后没有下文了，印象中面试的时候问了非递归实现斐波那契 + 尾递归优化，当时在面试官的指导下勉强做了出来
币安 3 场技术面都结束了，HR 那里没有了下文。
币安面试中问了 编译器原理 和 状态机，这两个点回答的不是很好，比较有意思的有 前端监听 CPU 占用 和 最长公共字符串，其他的内容都还好，个人认为回答的不错。
第三面的面试官是技术经理 ，得到的评价是基础不错，建议以后多看一下 webpack 和 React 源码学习学习
另外一家是阿里，一面和去年一样是同一个面试官，感觉是走过场，二面是个在线伯乐招聘系统，在线写代码，面试题很简单，接下来也没有下文
最后，其他的投递皆无音信
虽然说面试和相亲一样看缘分，而且大多数情况下运气比能力重要，但是没有能力的话运气也把握不住
 币安于 3 月 18 日下午发了 offer （我都快自我否定了），接下里准备阿里三面
 </description>
    </item>
    
    <item>
      <title>转：人生的意义是什么</title>
      <link>https://hasaki.xyz/life/2020-02-20-%E8%BD%AC%E4%BA%BA%E7%94%9F%E7%9A%84%E6%84%8F%E4%B9%89%E6%98%AF%E4%BB%80%E4%B9%88/</link>
      <pubDate>Thu, 20 Feb 2020 10:55:55 +0800</pubDate>
      
      <guid>https://hasaki.xyz/life/2020-02-20-%E8%BD%AC%E4%BA%BA%E7%94%9F%E7%9A%84%E6%84%8F%E4%B9%89%E6%98%AF%E4%BB%80%E4%B9%88/</guid>
      <description> 本文转载自知乎答主：赵曾良，对应链接为 https://www.zhihu.com/question/24329745/answer/39941769
 看你从哪个路径出发了
按照泰戈尔《流萤集》的说法，你不应该去追寻或者试图证明自己的存在，因为你原本就存在，你也不应该去追寻或者试图证明自己存在的意义，因为你存在的本身就是意义，如同流萤、如同星空，如同草长莺飞，四时消长的万物，人也只是自然的一部分，你只是按照规律繁衍与更替。
但是对于我来说，我没法被这样的环状逻辑所说服。
在我看来，人生并没有什么意义，活着也并没有什么意义，没有意义就是没有意义，后面不用跟上一个转折，在没有意义的前提下再次赋予意义。
意义这种东西，由于可以被赋予，所以因人而异，这个世界上到处存在着这样的事情，某些人觉得毫无意义，另一些人觉得意义非凡。如果在同一件事情上，意义的尺度可以被拉成无限小至无限大，而且任意的两个尺度之间不存在证伪的可能性和必要，那么，意义其实并没有什么价值。换一种说法就是，意义本身并没有什么意义，它并非是万物自带的固有属性。
意义本身依附于人而存在，当人这种生物出现的时候，意义才随之产生，当人类社会消亡的时候，所有一切的意义也会随之消亡。
而意义的出现，恰恰是为了抵御和对抗对消亡的恐惧。
所有被着重赋予意义的，都是那些趋向于消亡和无价值的东西。
 注：意义是人类赋予的概念，比如某个人，某个事物等等。
 比如说苦难，我们赋予了苦难太多的意义和价值，甚至于歌颂、赞美和感激那些苦难，许许多多的文章说苦难让我们变成了更好的人，感激苦难磨砺了自己。可实际上苦难是没有价值的，苦难就是苦难，你要做的永远都是摆脱它。
一定会有人说，可是苦难真的让我变成了更好的人，苦难让我超越了自己，做到了以前无论如何不敢相信自己能做到的事情，苦难让我重生。那么一定要警惕这样的想法，这里赋予了苦难更高一层的含义，隐藏着这样的信息：苦难让我超越自我，超越了过去的我所在的那个档次\阶层，所以，苦难使我更高贵，我瞧不起那些未曾经历过苦难的温室里的花朵。
诚然，苦难塑造了很多优秀的人，但苦难也同样碾压了更多的人，有些人变得更优秀了，有些人则没有，这其间的主要原因和丑小鸭变白天鹅是一样的，归根究底是因为丑小鸭原本就是白天鹅，而不是嘲笑与讥讽让它变成白天鹅的。
如果一定要感激，也该感激那些抵御苦难的特质和自己，而不是苦难本身。
赋予苦难价值，正是因为苦难没有价值，没有价值的苦难让我们承受了如此巨大的痛苦，这听起来很难让人接受，这说明你的痛苦没有价值，连带你生命中的那段时期价值都很低，为了掩盖这个事实，于是大量地赋予苦难崇高的意义，以此来说服自己，那段时间是有价值的，一切都没有白费。
如同我之前在爱在三部曲的影评里所寻求到的思考回路一样，偶遇是没有意义的，不断回溯过去赋予偶遇一个决定性的意义，主要是为了掩盖偶遇并没有意义这个事实。
我们所频繁赋予意义的东西，主要就是为了掩盖事物的消亡与无价值。
爱情经常被赋予一种神圣的意义，主要是为了掩盖爱情其实并不神圣这个事实。不仅仅是这种直白地赋予意义的方法，就连隐性的也是，很多人喜欢说，爱情走到最后，就变成了亲情，这话暗含了一种这段感情已经升华了的意义，频繁地强调这些，主要是为了掩盖你已经被降等了的事实。
有一种说法，其实唐明皇并未对杨贵妃情比金坚。
证据就是这段海誓山盟：
七月七日长生殿，夜半无人私语时。 在天愿作比翼鸟，在地愿为连理枝。
理由就是相处地好好的，为什么非要发誓说什么永远在一起，说什么三生三世，这样的行为太不自然了，之所以要许下这样的心愿，是内心感受到了这段感情即将会消亡的恐惧。
所以，爱发誓的人，他们的话往往不可信，频繁的发誓只是为了掩盖他们的话并没有价值的手段而已。
就像我们对自己说，这没什么好怕的，主要是因为感受到了恐惧，如果并没有害怕，是不会对自己说这句话的，也像很多人，喜欢在微博上写，随你们去说，我不在乎你们的看法，之所以要这样写，主要是因为很在乎别人的看法。
所以，一切不大自然的行为，背后就会有一个更自然的原因。
一件事情如果显而易见地有其价值，往往不需要人为地去赋予意义，这些事情自然地发生，自然地结束，人甚至很少会想到回溯过去再去赋予其意义。
比如说，很少有人会问，吃饭的意义是什么呢？也很少有人会问，人为什么非要穿衣服呢？我更没见过，有人问，中大乐透的意义是什么呢？我更想象不出来，有人会说，唉，我都中了大乐透了，突然有了好几个亿，我还活着干嘛呢？
可却频繁能够听到有人感慨，生活的意义到底是什么，活着的意义到底是什么？
最开始说了，意义本身没有意义，是人为去赋予的，所以当你感受到生活其实没什么意义的时候，主要不是生活没什么意义，而是你感受不到自己的价值。
你频繁地去寻找生活的意义，主要是为了抵抗自我的空虚。
 注：迫于现状只能消减、克制自己的欲望，进行自我阉割，也会导致失去生活的意义，这种情况难道只能降低标准来找到合适的欲望点或者意义点吗？
或者说转移注意力，但是这些只是一时之策、只是逃避罢了。当然谁都会说积极的话，走出舒适区，提升自我价值，如果真的这么简单就不会存在低欲望社会了。
 在这个路径的末端出现了两条路：
一，提升自我价值，也就没有去寻找意义对抗空虚和掩盖事实的必要了，你自然会觉得，生活挺有意义的。
二，由于意义本身都没什么意义，只是一个人为投射的附属品，所以，一件事情，不仅仅是生活，到底有没有意义，也就不重要了。
人生如同无限交叉小径的花园，我们却只能择其一而走。
选择自我路径吧。
 注：读了这么多，似乎没有太大的作用，一切照旧。然而对 意义 这两个字有了更多的哲学思考，也算是一种进步。
 </description>
    </item>
    
    <item>
      <title>转载：现代浏览器内部揭秘</title>
      <link>https://hasaki.xyz/blog/2020-01-20-%E8%BD%AC%E8%BD%BD%E7%8E%B0%E4%BB%A3%E6%B5%8F%E8%A7%88%E5%99%A8%E5%86%85%E9%83%A8%E6%8F%AD%E7%A7%98/</link>
      <pubDate>Mon, 20 Jan 2020 13:21:35 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2020-01-20-%E8%BD%AC%E8%BD%BD%E7%8E%B0%E4%BB%A3%E6%B5%8F%E8%A7%88%E5%99%A8%E5%86%85%E9%83%A8%E6%8F%AD%E7%A7%98/</guid>
      <description>现代浏览器内部揭秘
 Inside look at modern web browser (part 1) Inside look at modern web browser (part 2) Inside look at modern web browser (part 3) Inside look at modern web browser (part 4)  中字翻译：现代浏览器内部揭秘
 现代浏览器内部揭秘（第一部分） 现代浏览器内部揭秘（第二部分） 现代浏览器内部揭秘（第三部分） 现代浏览器内部揭秘（第四部分）  中字本站 Archive：
 现代浏览器内部揭秘合集  </description>
    </item>
    
    <item>
      <title>2020年1月杂记</title>
      <link>https://hasaki.xyz/gallery/2020-01-15-2020%E5%B9%B4%E7%AC%AC%E4%B8%80%E4%B8%AA%E6%9C%88%E4%BB%BD%E6%9D%82%E8%AE%B0/</link>
      <pubDate>Wed, 15 Jan 2020 14:50:30 +0800</pubDate>
      
      <guid>https://hasaki.xyz/gallery/2020-01-15-2020%E5%B9%B4%E7%AC%AC%E4%B8%80%E4%B8%AA%E6%9C%88%E4%BB%BD%E6%9D%82%E8%AE%B0/</guid>
      <description></description>
    </item>
    
    <item>
      <title>浅读《机器学习实战》</title>
      <link>https://hasaki.xyz/blog/2020-01-09-%E6%B5%85%E8%AF%BB%E6%9C%BA%E5%99%A8%E5%AD%A6%E4%B9%A0%E5%AE%9E%E6%88%98/</link>
      <pubDate>Thu, 09 Jan 2020 11:13:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2020-01-09-%E6%B5%85%E8%AF%BB%E6%9C%BA%E5%99%A8%E5%AD%A6%E4%B9%A0%E5%AE%9E%E6%88%98/</guid>
      <description>机器按照是否 分类 和 回归 可以分为两种：
 监督学习  监督学习需要分类和回归，这类算法必须知道预测什么，即目标变量的分类信息。
监督学习的用途有：
 k-近邻算法（KNN） 朴素贝叶斯算法 支持向量机 决策树 线性回归 局部加权线性回归 Ridge 回归 Lasso 最小回归系数估计  我们在本文当中会逐个说到上诉用途
 非监督学习  与监督学习相对应的是无监督学习，此时数据没有类别信息，也不会给定目标值。在无监督 学习中，将数据集合分成由类似的对象组成的多个类的过程被称为聚类；将寻找描述数据统计值 的过程称之为密度估计。
此外，无监督学习还可以减少数据特征的维度，以便我们可以使用二维或三维图形更加直观地展示数据信息。
无监督学习的用途有：
 K-均值 DBSCAN 最大期望算法 Parzen 窗设计  KNN  kNN（k-Nearest Neighbor）算法的核心思想是如果一个样本在特征空间中的 k 个最相邻的样本中的大多数属于某一个类别，则该样本也属于这个类别
 KNN 是机器学习中最简单易懂的算法，它的适用面很广，并且在样本量足够大的情况下准确度很高，多年来得到了很多的关注和研究，K-近邻算法采用测量不同特征值之间的距离方法进行分类。适用数据范围：数值型和标称型
kNN 当中的 k 取不同值时，分类结果可能会有显著不同。
 优点：简单，易于理解，易于实现，精度高、对异常值不敏感、无数据输入假定。 缺点：计算复杂度高、空间复杂度高。  下面是 k-近邻算法当中带有 4 个数据点的简单例子，例子当中对 4 个数据点进行了简单分类为 A 和 B：
import numpy as np import matplotlib.</description>
    </item>
    
    <item>
      <title>云原生基础及调研</title>
      <link>https://hasaki.xyz/blog/2019-12-12-%E4%BA%91%E5%8E%9F%E7%94%9F%E5%9F%BA%E7%A1%80%E5%8F%8A%E8%B0%83%E7%A0%94/</link>
      <pubDate>Tue, 12 Nov 2019 13:09:31 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2019-12-12-%E4%BA%91%E5%8E%9F%E7%94%9F%E5%9F%BA%E7%A1%80%E5%8F%8A%E8%B0%83%E7%A0%94/</guid>
      <description>老规矩，列出本机器环境
 system_profiler SPSoftwareDataType : macOS 10.14.1 (18B75) Darwin 18.2.0 docker -v : Docker version 19.03.5, build 633a0ea Docker desktop GUI : 2.1.0.5(40693) stable kubectl version : 根据 Docker desktop GUI 而定  概念 提到云原生（Cloud Native）可能部分人会陌生，但是如果说 Serverless 相信很多人就知道了，实际上两者并不等价。Serverless 是一种理念或者服务交付形态，目标是屏蔽硬件和运维细节。
而云原生则是实现此类目标的一种规范以及基础设施。
再进一步，介于 Docker 天然的隔离性和高效等特点，以及 Kubernetes 成为事实意义上的 Docker 编排标准，凡是见到云原生或者 Serverless 的地方，几乎都可以认为是基于 Docker + Kubernetes 的一种实践。
单个点展开讲太枯燥，索性我们从历史的角度看看为什么会有云原生。
Docker 先申明下，Docker 是一种容器技术（具体可深入 namespaces 和 cgroups），而不是虚拟化技术，真正的虚拟化比较常见的是 Xen 和 KVM，可能有同学要举手了：老师，那我们经常用的 VirtualBox 和 VMware 算虚拟化么？当然算！不过大多数情况下，它们用在桌面虚拟化领域
可能大家之前经常遇到这样的场景：为什么在我这可以运行在你那就不行了？为什么刚刚可以运行现在就不行了？最终解决下来，大多是环境不一致导致的问题。这里的环境除了开发环境还包括操作系统。
所以一般给别人代码的时候还需要告诉别人此代码可运行的操作系统版本，所依赖的各种软件的版本，甚至目录、磁盘、内存、CPU 都有要求！</description>
    </item>
    
    <item>
      <title>随便放点什么照片</title>
      <link>https://hasaki.xyz/gallery/2019-11-07-%E9%9A%8F%E4%BE%BF%E6%94%BE%E7%82%B9%E4%BB%80%E4%B9%88%E7%85%A7%E7%89%87/</link>
      <pubDate>Wed, 06 Nov 2019 15:39:30 +0800</pubDate>
      
      <guid>https://hasaki.xyz/gallery/2019-11-07-%E9%9A%8F%E4%BE%BF%E6%94%BE%E7%82%B9%E4%BB%80%E4%B9%88%E7%85%A7%E7%89%87/</guid>
      <description></description>
    </item>
    
    <item>
      <title>转载：这可能是最通俗的 React Fiber(时间分片) 打开方式</title>
      <link>https://hasaki.xyz/blog/2019-10-23-%E8%BD%AC%E8%BD%BD-%E8%BF%99%E5%8F%AF%E8%83%BD%E6%98%AF%E6%9C%80%E9%80%9A%E4%BF%97%E7%9A%84-react-fiber%E6%97%B6%E9%97%B4%E5%88%86%E7%89%87-%E6%89%93%E5%BC%80%E6%96%B9%E5%BC%8F/</link>
      <pubDate>Wed, 23 Oct 2019 14:01:30 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2019-10-23-%E8%BD%AC%E8%BD%BD-%E8%BF%99%E5%8F%AF%E8%83%BD%E6%98%AF%E6%9C%80%E9%80%9A%E4%BF%97%E7%9A%84-react-fiber%E6%97%B6%E9%97%B4%E5%88%86%E7%89%87-%E6%89%93%E5%BC%80%E6%96%B9%E5%BC%8F/</guid>
      <description>本文全文来自转载文章 这可能是最通俗的 React Fiber(时间分片) 打开方式
 读者可以直接去查看原文，如果原文链接丢失，可以下载这个 PDF 备份</description>
    </item>
    
    <item>
      <title>Tensor &amp;&amp; flow</title>
      <link>https://hasaki.xyz/blog/2019-08-09-tensor--flow/</link>
      <pubDate>Fri, 09 Aug 2019 13:22:30 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2019-08-09-tensor--flow/</guid>
      <description>本文只是简单 TensorFlow 的一些理解和介绍，并不包含详细的安装、API、以及更多深层内容。
 首先简单说一下 标量（Scalar）、向量（Vector）、张量（Tensor）。
下面会以 physical student 和 cs student 两个角度来解释。
Scalar 在物理学角度，标量是遵循简单代数规则的一些量，与坐标系的选取无关。例如，加法，减法等。标量也可以被定义为仅需要识别幅度的量。例如温度，电流等
CS 里面可以简单认为是一个常量（constant）
Vector 物理学角度向量是空间中的箭头，也可以是矢量。
决定一个向量的是它的长度（length）和它所指的方向（direction），而且只要以上特征相同，你一个任意移动一个向量而保持它不变。比如速度和力。而且平面中（平面直角坐标系）的向量是二维的，处于我们生活当中的向量是三维的。
举个例子，一个二维向量 [-2,3] 以平面直角坐标系来表示为：
 第一个数代表沿 X 轴走多远，第二个数代表沿 Y 轴走多远。
 图中的黄色箭头就是向量，可以看到一个向量都有一个唯一一对对数
而一个三维向量 [2,1,3] 以平面直角坐标系来表示为：
 第一个数代表沿 X 轴走多远，第二个数代表沿 Y 轴走多远，第三个数代表沿 Z 轴走了多远
 CS 角度向量是一个二维数组（二维）、三维数组（三维）或者说是矩阵。代表有序的数字集合。
线性代数 向量在线性代数当中可以叫做矩阵（matrix），矩阵可以做一些基本的运算，对应的加法和乘法规则是：
 两个矩阵行列数必须要相同才能进行求和运算。   两个矩阵要相乘，前一个矩阵的列数必须要等于后一个矩阵的行数，也可以看成是列的加权求和   至于更多的矩阵求逆、求导超出本文的范畴，请自行学习线性代数。
 我们也可以换一种方式来看向量的坐标，把一个 [1,1] 的向量定义为 基向量。
上文的二维向量 [-2,3]，对应的每个坐标可以看作一个为 Scalar（标量）。这个向量可以看作把基向量按照标量的大小进行缩放所产生。-2 代表往右 2 倍，3 代表向上 3 倍</description>
    </item>
    
    <item>
      <title>My Recent Notes (mostly entertainment)</title>
      <link>https://hasaki.xyz/life/my-recent-notes-mostly-entertainment/</link>
      <pubDate>Sat, 27 Jul 2019 13:12:30 +0800</pubDate>
      
      <guid>https://hasaki.xyz/life/my-recent-notes-mostly-entertainment/</guid>
      <description>此文稿列出了我最近的一些安排，主要是娱乐安排，比如电影、电视剧、游戏、旅游之类的，每个种类已经手动按照时间进行排序 其中 ✅ 代表当前电视剧已经完结、游戏已经通关等等
 Books  《机器学习实战》 《苍穹浩瀚》  Code Github Projects
Movies  ✅ 硅谷 第六季 Silicon Valley Season 6 (2019) 首播: 2019-10(美国) ✅ 苍穹浩瀚 第四季 The Expanse Season 4 (2019) 首播: 2019-12-13(美国) ✅ 星际迷航：发现号 第三季 Star Trek: Discovery Season 3 (2020) 首播: 2020-01(美国) 苍穹浩瀚 第五季 The Expanse Season 5 (2020) 首播: 2020-12(美国) 星际迷航：皮卡德 第一季 Star Trek: Picard Season 1 (2020) 首播: 2020-01-23(美国) 新世纪福音战士新剧场版：终 首播: 2020 人体奥秘 Inside the Human Body  爱，死亡和机器人 第二季 Love, Death &amp;amp; Robots Season 2  曼达洛人 第一季 首播：Nov.</description>
    </item>
    
    <item>
      <title>奥德赛和2k HDR 显示器</title>
      <link>https://hasaki.xyz/life/2019-07-27-%E5%A5%A5%E5%BE%B7%E8%B5%9B%E5%92%8C-2k-hdr-%E6%98%BE%E7%A4%BA%E5%99%A8/</link>
      <pubDate>Sat, 27 Jul 2019 13:12:30 +0800</pubDate>
      
      <guid>https://hasaki.xyz/life/2019-07-27-%E5%A5%A5%E5%BE%B7%E8%B5%9B%E5%92%8C-2k-hdr-%E6%98%BE%E7%A4%BA%E5%99%A8/</guid>
      <description>最近沉迷刺客信条-奥德赛
why Odyssey 奥德赛这个名字，它是古希腊最重要的两部长篇史诗之一。承接《特洛伊》的剧情。
讲述了奥德修斯归乡 10 年间惊心动魄的传奇旅程。设定在 2400 多年前的伯罗奔尼撒战争时期——雅典和斯巴达为争夺希腊世界的主导权打了 10 多年的仗。
虽然育碧的游戏是典型的套公式类游戏，核心受众明显是轻度历史爱好者+喜欢刷任务的强迫症爱好者。比较明显的是 幽灵行动：荒野，大型玻利维亚观光游戏，虽然任务重复但是质量很高。
但是我还是强烈推荐奥德赛：
 美术 这次的美术是真棒，古希腊、斯巴达还原度很好，尤其是 亚特兰蒂斯 BGM 推荐原声带 育碧模式  本来是 cpy 版本的，后来第一个大型 DLC 亚特兰蒂斯 促使我入正了，官方是这样推荐的：
 探索源自希腊神话的三个新世界——极乐世界，冥界以及亚特兰提斯！
 朋友赞助 40 大洋，然后淘宝 5 大洋买了个育碧八折券，最后 326 大洋买了黄金版的奥德赛（带有一年季票，一年内的 DLC 可以任意畅玩）
更换显示器 我之前的显示器是很便宜的 AOC 12490PXH5 1080p 的显示器，只要 998 就买得到了，之前一直感觉大颗粒比较明显，前天剁手买了一个 DELL U2518DR 2k HDR 显示器，花了 1999 大洋，简直是最大的提升了。
没有选择 144HZ 第一个是我不常玩 FPS 游戏，显卡 1070TI 也带不动，4K 更不用说了
而且 1080P 到 2k 的提升比较明显，还有 HDR 10 ，所以选择了这款稍微便宜的显示器</description>
    </item>
    
    <item>
      <title>some interview question</title>
      <link>https://hasaki.xyz/blog/interview-question/</link>
      <pubDate>Tue, 23 Jul 2019 14:01:30 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/interview-question/</guid>
      <description>下面是个人列出的一些前端面试方面的问题（没有先后顺序，也没有优先级之分）
 这个是我自己总结的一些面试内容集合
 手动实现的轮子  call、apply、bind 符合 Promise/A+规范的 Promise、 asyncawait、co EventEmitter new 双向绑定 JSON.stringify、 JSON.parse 简易模版引擎  浏览器工作原理系列  关键渲染路径 浏览器的工作原理：新式网络浏览器幕后揭秘 Inside look at modern web browser (part 1) 中字 Inside look at modern web browser 浅析浏览器渲染原理 浏览器渲染全过程以及常遇到的问题 life of pixel 【中字】像素的一生 Life of a Pixel - Steve Kobes(Chrome Team)  JavaScript  ES6 class 与 ES5 function 区别及联系 JavaScript 执行（四）：try 里面放 return，finally 还会执行吗？ 最详尽的 JS 原型与原型链终极详解，没有「可能是」 new 的实现 Babel Class Extend 的实现 我的博客 谈谈 Node.</description>
    </item>
    
    <item>
      <title>使用 Rust 编写 WebAssembly </title>
      <link>https://hasaki.xyz/blog/2019-07-20-%E4%BD%BF%E7%94%A8-rust-%E7%BC%96%E5%86%99-webassembly-/</link>
      <pubDate>Sat, 20 Jul 2019 15:42:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2019-07-20-%E4%BD%BF%E7%94%A8-rust-%E7%BC%96%E5%86%99-webassembly-/</guid>
      <description>老规矩，列出本机器环境
 system_profiler SPSoftwareDataType : macOS 10.14.3 (18D42) Darwin 18.2.0 cargo --version cargo 1.38.0-nightly (e3563dbdc 2019-07-16) rustc --version rustc 1.38.0-nightly (311376d30 2019-07-18) wasm-pack -V wasm-pack 0.8.1 clang --version x86_64-apple-darwin18.2.0 posix LVVM Apple LLVM version 10.0.0 (clang-1000.10.44.4)  JavaScript 历史 JavaScript 于 1995 年问世，它的设计初衷并不是为了执行起来快，在前 10 个年头，它的执行速度也确实不快。被人们广为传播的“性能大战”在 2008 年打响。许多浏览器引入了 Just-in-time 编译器，也叫 JIT。JavaScript 代码的运行渐渐变快
随着性能的提升，JavaScript 可以应用于后端开发的 Node.js。性能的提升使得 JavaScript 的应用范围得到很大的扩展。
现在通过 WebAssembly，JavaScript 的性能可以再次提速。
JIT 计算机使用的是机器语言，也就是 010101 二进制，而我们编写的 JavaScript 代码是基于人类的认知而设计出来的高级编程语言，所以需要引擎把把人类的语言转换成机器能看懂的语言。
这就像电影《降临》中，人类和外星人的互相交流一样
在代码的世界中，通常有两种方式来翻译机器语言：解释器和编译器。
 如果是通过解释器，翻译是一行行地边解释边执行 编译器是把源代码整个编译成目标代码，执行时不再需要编译器，直接在支持目标代码的平台上运行。  这两种翻译的方式都各有利弊。</description>
    </item>
    
    <item>
      <title>转载：七牛云许式伟：我所理解的架构是什么</title>
      <link>https://hasaki.xyz/blog/2019-06-17-%E8%BD%AC%E8%BD%BD%E4%B8%83%E7%89%9B%E4%BA%91%E8%AE%B8%E5%BC%8F%E4%BC%9F%E6%88%91%E6%89%80%E7%90%86%E8%A7%A3%E7%9A%84%E6%9E%B6%E6%9E%84%E6%98%AF%E4%BB%80%E4%B9%88/</link>
      <pubDate>Mon, 17 Jun 2019 17:52:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2019-06-17-%E8%BD%AC%E8%BD%BD%E4%B8%83%E7%89%9B%E4%BA%91%E8%AE%B8%E5%BC%8F%E4%BC%9F%E6%88%91%E6%89%80%E7%90%86%E8%A7%A3%E7%9A%84%E6%9E%B6%E6%9E%84%E6%98%AF%E4%BB%80%E4%B9%88/</guid>
      <description>本文转载于许式伟在 INFOQ 大会上的演讲，原文地址为：七牛云许式伟：我所理解的架构是什么
 从软件工程说起 大家好！
我已经很久没有做技术类的演讲了，因为我最近确实比较忙，很少会出来。为什么会突然又想谈一下架构呢？这是我个人的宿愿，我是技术出身，虽然现在比较少写技术相关的东西，但我在公司内部做了很多分享，分享课里我讲的东西与架构相关的占三分之二，基本都是和架构相关的。
所以今天借这个机会谈一谈我自己理解的架构到底是什么。
国内现在比较少真正意义上符合 “架构师” 这个词的定位的角色，我们的教育和工作氛围很难出真正意义上的架构师，比较凤毛麟角。我自己理解的架构师是从软件工程概念开始的，也许大家都学过软件工程，但如果我们把软件工程这门课重新看待，这门学科到底谈的是什么？是软件项目管理的方法论？
无论如何，软件工程是一门最年轻的学科，相比其他动辄跨世纪的自然科学而言，软件工程只有 50 年的历史。这门学科的实践太少了，任何一门学科的实践时间短的话，都很难沉淀出真正有创意的实践总结，因为这些经验总结总是需要很多代人共同推动来完成。
为什么只有 50 年时间呢？我们来看看 C 语言，一般意义上可能认为它是现代语言的开始。C 语言诞生于 1970 年，到现在是 49 年。再看 Fortran，它被认定为第一个高级语言，诞生于 1954 年，那时候主要面向的领域是科学计算。Fortran 的程序代码量不大，量不大的时候谈不上工程的概念。这也是为什么软件工程这门学科很年轻，它只有 50 岁，在这样一个年轻的学科里我们对它的认知肯定还是非常肤浅的。
软件工程和建筑工程对比可以发现二者有非常大的区别，具体在于两点：
 1）快速变化。建筑工程在完工以后就结束了，基本上很少会进行变更，除非对它进行软装上的变更，软装更像是今天的软件。但其实软件工程里，软件生产出来只是开始，而且只要软件的生命周期没有结束，变更就一直存在，很像建筑里的软装一样，而且比软装变化剧烈得多。 2）不确定性。为什么软件工程有很大的不确定性？因为没有两个人的工作是一样的，虽然大家都在编程，但是编程的内容是不一样的。每个人昨天和今天的工作也是不一样的，没有人会写一模一样的代码，我们总是不停地写新的东西，做新的工作。这些东西是非常不同的，软件工程从事的是创造性的工作。  大家都知道创造是很难的，创造意味着会有大量的试错，因为我们没有做过。这会导致软件工程有非常大的不确定性。
以上这两点都会导致软件工程区别于传统意义上的所有工程，有非常强的管理难度。过去那么多年，工业界有非常多的工程实践，但是所有的工程实践对软件工程来说都是不适用的，因为二者有很大的不一样。
今天站在管理的视角再看软件工程，我们知道管理学谈的是确定性，我们如何去创造确定性是管理学中的追求，否则管理管什么呢？某种意义上来说管理学的目的就是要抑制不确定性，产生确定性。比如说开发的工期，时间成本是否能确定。其次，人力成本，研发成本和后期运维的成本是不是确定性的。所以软件项目的管理又期望达到确定性。这是一对矛盾。软件工程本身是快速变化的，是不确定的。但是软件工程管理又希望得到确定性，这就是软件工程管理上的矛盾。我们的目标是在大量的不确定性中找到确定性，这是我认为这件事情最核心的点。
程序员的三个层次 软件工程管理到底在管什么？和所有的管理活动一样 无非就是人和事。所有的工程项目都希望找到最好的人，当然是在能给出的预算以内找到最好的人，有的人可能找不起。不同项目最大的差别就是事，不同的事在哪里？从做事的角度来讲我们招到的人可能会分三个层次（程序员三个级别），大家经常开玩笑说我是做搬砖的，所以第一个 level 我把他叫软件搬砖师，再然后是软件工程师、软件架构师。
软件搬砖师可以有很多。但今天数量其实还不算太多，因为我们知道这门学科只有 50 年的历史。但是好的一点是，产生软件搬砖师并不难，我做了一个长达四年的实践：从小学二年级开始教小学生编程。结论是做搬砖师不难，小学生也能做到。这是很有意思的一件事情，编程并不是非常复杂的学问，只要具备基本的逻辑能力，把常规的业务代码按部就班地垒出来，基本上可以算打到搬砖师水准。我自己认为这并不难。
软件工程师会相对难一些，我心目中的软件工程师首先在代码上会非常追求可读性、可维护性。另外，毕竟我们工程是群体协作，所以在群体协作上还是有自己的方法论和思考。比如说代码评审、单元测试。在我看来搬砖师和工程师的区别有很大不同。只要看他写的代码有没有注意可维护性，会和同伴交流的时候刻意去追求让同伴更好地理解自己的思想，是不是对单元测试比较抗拒，是不是比较乐意去做代码评审并且非常认同这件事情的价值，基本上通过这些事情就可以评判这个人是搬砖师还是工程师。
软件架构师的能力要求 谈到软件架构师，由于我毕业后两年在从事架构性质的工作，因此对软件架构师的特性有一些总结。首先在用户需求上，有判断能力和预见能力，此处的判断可以理解为对需求的鉴别，虽然这可能与产品经理最为相关，但架构师需要具备自己的判断力，当然这也包括对未来需求的预见能力；产品迭代上，有规划能力，判断需求哪些应该先满足，哪些后满足。架构师应该源于程序员，但不应局限于程序员视角。系统设计上，有分解和组合能力。技术选型上，有决策力。技术选型应该被认为是架构的一部分，我们非常反对开发人员随意选用开源组件，这是一件需要认真探讨的事情。人力资源上，有统筹能力，通俗地讲是 “看菜做饭（看人下菜）”。
综上不难看出，架构师对综合能力要求比较高。这是因为我认为架构师需要对软件工程的结果负责，在不确定性和快速变化中寻找确定性。全局看软件发布流程，其比较重要的子过程有：需求分析（需求梳理 =&amp;gt; 产品定义），系统设计（子系统划分 =&amp;gt; 模块定义），模块设计（模块详细设计），编码实现，单元测试，代码评审，集成测试，灰度发布，正式发布等一系列过程。虽然有些过程看起来不属于架构师的范畴，但是这些活动过程属于软件工程的一部分，架构师一样需要全面参与把控。如果没有架构师把控就没有人观察得到全貌。正因为如此，软件架构师的要求相对较高。
如上所言，软件架构师需要具备产品经理的部分能力，因为需要对用户需求进行分析，并进行判断和预判，以及对产品迭代优先级进行把控。我自己习惯用如下图片表达软件架构师和产品经理之间的关系
我认为，产品是“桥”，连接了两端，分别是用户需求和先进的技术。我一直认为，用户需求的变化非常缓慢，那么为什么产品会产生迭代？这是因为技术在迭代。本质上讲，产品迭代是技术迭代导致的需求满足方式的变化，所以产品实际上是一种需求满足的方式。
从这个意义上讲，架构师更多是从技术方案的角度看产品，而产品经理更多是从用户需求来看，但二者一定会碰头，只要能力提升到角色所期望的样子，越厉害就越具备两侧的能力。所以我认为，产品经理和架构师是一体两面，本质上对人的能力、诉求是相通的。产品经理在做产品架构，架构师在做技术架构，但最终目的一样。
从产品和需求视角看架构师 如果展开讲解产品定义过程，首先需要进行需求梳理，关心用户反馈。但是，很多用户反馈并不代表其根本性需求。有很多用户反馈需求的时候，往往已经带着他自己给出的解决方案。这种需求反馈已经属于二次加工的需求，而非原始需求。这个时候我们要多问多推敲，把它还原到不带任何技术实现假设的根源需求。
如上图所示，根源需求可能会有非常非常多的技术方案可以满足它。我们上面示意图中的小圆点是一个个用户反馈的需求。在用户提这些需求的时候，往往可能会带着他熟悉的技术方案的烙印。
产品都是通过提供相应的技术方案在满足用户的根源诉求，但技术一直在迭代进步，从而导致原有的解决方案过时落后，这种情况下需要新的解决方案出现。如果对用户反馈的需求全部满足，产品就会变得十分庞大，编程一个四不像的东西。
其次，在这个过程中，有些用户需求是稳定的，有些是变化的。举例来说，计算机系统结构从计算机诞生之后到现在没变过，但电子设备的形态发生了很大变化，从最早的大型机，到个人电脑，到笔记本，到手机，再到手表，形态变化剧烈。但为什么计算机系统结构能够适应需求而不用改变架构，这其实是非常值得思考的事情，其根源就是对变化点的抽象，找到系统需求的变化点，预见变化并做对应的开放式设计。本质上讲，架构师关心产品的核心根源就是预测变化。
最后，理清产品边界。同样以计算机为例，经过多轮迭代，多样化外设（键盘等）变化较大，但 CPU、内存演进较小，所以在变化点上做相应的开放式设计是必要的。同样的，需要与合作伙伴做边界设定，把变化开放出去让合作伙伴做，只有这样的产品才能达到较好效果。
从产品和解决方案角度来看，产品往往需要适应很多行业，但这个过程会让产品变得非常庞大。在我看来，产品应该为行业解决方案提供能力，行业解决方案优先选择合作伙伴做，以更加开放的心态看待这件事情，避免把行业方案视作产品的一部分。
梳理需求中比较关键的点是市场策略，需要解决的需求有非常多现成的方案，但哪些方案是主流的，哪些是最关键的都需要思考。虽然不能放大产品需求覆盖面，但也需要为某些关心既有市场的玩家做桥梁，这些桥梁也是产品的功能点。我倾向于认为关键市场可能会把既有玩家的能力适配到产品上作为很重要的功能，但是大部分市场主流方案我们还是提供“桥”，而不是自己解决掉。
从技术视角看架构师 以上是从产品和需求维度看架构师，从技术视角看，架构师很重要的能力是具备技术的全局视角，所谓的技术全貌是指从底到上的核心骨架，比如最底下的硬件结构、操作系统、编程语言，甚至浏览器等，只有掌握每一层的核心思想，才能在架构设计中没有技术盲点。</description>
    </item>
    
    <item>
      <title>Serverless 入门</title>
      <link>https://hasaki.xyz/blog/2019-04-12-serverless-%E5%85%A5%E9%97%A8/</link>
      <pubDate>Fri, 12 Apr 2019 12:52:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2019-04-12-serverless-%E5%85%A5%E9%97%A8/</guid>
      <description>老规矩，列出本机器环境
 serverless -v 1.46.0 node -v v10.15.0 system_profiler SPSoftwareDataType : macOS 10.14.3 (18D42) Darwin 18.2.0 云平台 aws vsCode for editor  什么是 Serverless Serverless 是一种架构模式。
根据 CNCF 的定义，Serverless 是指构建和运行不需要服务器管理的应用程序的概念。(serverless-overview)
 Serverless computing refers to the concept of building and running applications that do not require server management. &amp;mdash; CNCF
 简单来讲，Serverless 指的是在构建 Web 应用程序的时候，而不用担心如何配置服务器，但是这并不意味着应用程序不会在服务器上运行，而是说服务器的管理都可以尽可能地交给相应的云平台，从而最大程度地减轻开发人员的部署与配置工作。与之对应的一个名词可能就是 Function As a Service（FAAS），由 AWS Lambda 这个命名上就能想到，当我们在构建 Serverless 架构时，实际上我们是在写一个个的 Function 即函数而已
云计算发展模式 云计算有常用的三种模式，如下图：
云计算的三种模型是 PaaS，SaaS（软件即服务）和 IaaS（基础架构即服务）。</description>
    </item>
    
    <item>
      <title>gRPC 浅谈与实践</title>
      <link>https://hasaki.xyz/blog/2019-03-04--grpc-%E6%B5%85%E8%B0%88%E4%B8%8E%E5%AE%9E%E8%B7%B5/</link>
      <pubDate>Mon, 04 Mar 2019 11:32:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2019-03-04--grpc-%E6%B5%85%E8%B0%88%E4%B8%8E%E5%AE%9E%E8%B7%B5/</guid>
      <description>由于不同的环境下面的例子可能会存在一些误差，下面列出本机环境：
 Docker -v ：Docker version 18.09.1, build 4c52b90 docker-compose -v ：docker-compose version 1.23.2, build 1110ad01 go version : go version go1.12.4 darwin/amd64 system_profiler SPSoftwareDataType : macOS 10.14.3 (18D42) Darwin 18.2.0 IDE golang latest  RPC RPC 全名为 Remote procedure call ,直译过来就是 远程过程调用 ，也就是说两台服务器 A，B，一个应用部署在 A 服务器上，想要调用 B 服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。
调用的基本流程可以看下图：
RPC 的协议可以简单分成两大类。
一类是通讯层协议，通讯层协议一般是和业务无关的，它的职责是将业务数据打包后，安全、完整的传输给接受方，HSF、Dubbo、gRPC 这些都是属于通讯层协议。
另一类是应用层协议。约定业务数据和二进制串的转换规则，常见的应用层协议有 Hessian，Protobuf，JSON。
why RPC 为什么 RPC 呢？就是无法在一个进程内，甚至一个计算机内通过本地调用的方式完成的需求，比如比如不同的系统间的通讯，甚至不同的组织间的通讯。由于计算能力需要横向扩展，需要在多台机器组成的集群上部署应用，
http vs RPC HTTP 调用其实也是一种特殊的 RPC 。RPC 可以基于 HTTP 协议实现，也可以直接在 TCP 协议上实现。</description>
    </item>
    
    <item>
      <title>使用 nextcloud 搭建个人私有网盘</title>
      <link>https://hasaki.xyz/blog/2019-02-12-%E4%BD%BF%E7%94%A8-nextcloud-%E6%90%AD%E5%BB%BA%E4%B8%AA%E4%BA%BA%E7%A7%81%E6%9C%89%E7%BD%91%E7%9B%98/</link>
      <pubDate>Tue, 12 Feb 2019 10:58:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2019-02-12-%E4%BD%BF%E7%94%A8-nextcloud-%E6%90%AD%E5%BB%BA%E4%B8%AA%E4%BA%BA%E7%A7%81%E6%9C%89%E7%BD%91%E7%9B%98/</guid>
      <description>国内各大云网盘要么限速要么需要充值 vip 、超级 vip、超超级 vip。
国外的一些优质云网盘如 google drive 和 one drive 等由于和谐因素又无法顺利的访问。
本来想买个 nas ，看到价格和组 raid 的成本放弃了。
刚好我有一台新组装的主机电脑，平时也是偶尔开着，所以特意买了个 2t 的希捷数据盘，准备搭建一套私有云的环境给家庭用。
开源云盘选择  其实在搭建之前，考虑过自己写一个简单的文件系统上传预览，后来发现需要考虑的问题太多卒 🤣
 搭建前我仔细看了一下各个开源私有云盘的实现，有以下几种：
 owncloud sealife nextcloud  对这几家比较了以下，考虑了以下因素：
 开源且免费，可以自定义插件开发 全客户端的支持，免费更好，ui 视觉还能过得去 支持外挂磁盘，可以随时更改，不需要分块、加密和过多的文件控制、权限控制等等，简单就好 部署难度，vm 还行，最好可以 Docker  最终我选择了 nextcloud，至于更多的详细差异，大家可以根据需求选择。
内网穿透 由于家里的电信没有外网 ip ，打电话给运营商也无济于事，只能选择内网穿透。
内网穿透选择了很多办法：
 根据开源实现自己部署到一台公共可访问的服务器上，比如：frp、ngrok 等等 使用现有的内网穿透服务商，比如：花生壳、natapp 等等  最终我选择了 natapp 免费使用版
开始搭建 我个人的网盘需求只是偶尔让我爸妈把照片上传到我的主机上。
对性能、速度、可持续性都没有太高的要求，所以很多条件都可以简化，只要保证数据完整性就可以了。
首先在 Windows 上安装所需要的环境： Docker 、Python 等。并且在 E 盘下创建了特定的 nas 文件夹来作为 nextcloud 的目录。</description>
    </item>
    
    <item>
      <title>working tips</title>
      <link>https://hasaki.xyz/blog/working-tips/</link>
      <pubDate>Mon, 23 Jul 2018 09:23:43 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/working-tips/</guid>
      <description>将 ssr 转换为 http 代理  前景概要：我用的魔改版本的 ssr ，不带 http proxy，但是我需要在 terminal 当中使用代理。而且公司原因完全没有 sudo 权限，brew 也废掉了。但是本地 git 是可以通过 sock5 代理的。
我知道可以通过 proxychains4 或者 proxychains-ng 可以实现。也由于懒不想换 ss 或者 v2ray，而且由于 mac sip 的原因没法成功，主要还是没有 sudo 权限。
 找了好久，查到了解决办法，利用这个库 polipo 是可以实现所需要的功能，具体步骤如下。
#!/usr/bin/env bash # 下载 polipo 源码本地编译 git clone https://github.com/jech/polipo.git cd polipo &amp;amp;&amp;amp; make # 设置 socks5 代理自动给 http proxy 的端口 ./polipo socksParentProxy=localhost:1086 &amp;amp; # 默认的 http proxy 端口为 8123，可以参照下面的 wiki 来配置 config file export http_proxy=&amp;quot;http://127.</description>
    </item>
    
    <item>
      <title>Data Structure</title>
      <link>https://hasaki.xyz/blog/data-structure/</link>
      <pubDate>Wed, 23 May 2018 12:33:21 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/data-structure/</guid>
      <description>List list 是n(n≥0)个相同类型的数据元素构成的有限序列。
ADT List { Data: Operation: InitList(&amp;amp;L) CreateList(&amp;amp;L) ListEmpty(L) ListLength(L) LocateElem(L,e) PriorElem(L,cur_e,&amp;amp;pre_e) NextElem(L,cur_e,&amp;amp;pre_e) ListInsert(&amp;amp;L,i,e) ListDelete(&amp;amp;L,i,&amp;amp;e) GetElem(L,i,&amp;amp;e) ListTraverse(L) DestroyList(&amp;amp;L) }//ADT List  list 简单实现 /** * List Structure */ class List { /** * 顺序表初始化操作，申请使用内存 * @constructor */ InitList() { this.list = [] } /** * 判断顺序表是否为空 * @returns {boolean} * @constructor */ ListEmpty() { return this.list.length === 0 } /** * 顺序表求表长操作 * @returns {number} * @constructor */ ListLength() { return this.</description>
    </item>
    
    <item>
      <title>javascript 沙箱</title>
      <link>https://hasaki.xyz/blog/2018-04-21-javascript-%E6%B2%99%E7%AE%B1/</link>
      <pubDate>Sat, 21 Apr 2018 17:43:01 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2018-04-21-javascript-%E6%B2%99%E7%AE%B1/</guid>
      <description>在一些业务场景当中，我们提供给用户插入自定义逻辑的能力，类似于沙盒、沙箱，允许执行自定义代码，产生的变化可以随后随时删除。
无论是客户端上的沙箱还是服务器端上的沙箱，我们都要确保安全性，用户自定义的脚本必须收到限制和隔离，不能影响到当前宿主程序。
javascript 本身有很多种方式可以实现沙箱，各有千秋，各有使用的地方。
 eval new Function with proxy Node VM Deno  eval 最简单的方式就是直接使用 eval 执行：
eval(&#39;console.log(&amp;quot;a simple script&amp;quot;);&#39;) // a simple script  eval 只是一个普通的函数，只不过他有一个快速通道通向编译器，可以将 string 变成可执行的代码。
 eval 的特性是如果当前域里面没有，则会向上遍历，一直到最顶层的 global scope：比如 window global ，他还可以访问 closure 内的变量。
 使用 eval 也带来了安全隐患，首先它可以访问和修改它外部作用域中的变量，其次被执行的代码（例如从网络来）可能已被篡改。
global.name = &#39;TOM&#39; eval(&#39;console.log(&amp;quot;i am &amp;quot; + name + &amp;quot; from eval&amp;quot;);&#39;) // i am TOM from eval  并且 eval 可读性较差，调试难度较高，也会轻微增加性能消耗。
对于 eval 开发者是贬褒不一，eval 是魔鬼 以及 eval 不是魔鬼</description>
    </item>
    
    <item>
      <title>使用Swift开发React Native组件</title>
      <link>https://hasaki.xyz/blog/2018-03-23-%E4%BD%BF%E7%94%A8swift%E5%BC%80%E5%8F%91react-native%E7%BB%84%E4%BB%B6/</link>
      <pubDate>Fri, 23 Mar 2018 14:28:25 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2018-03-23-%E4%BD%BF%E7%94%A8swift%E5%BC%80%E5%8F%91react-native%E7%BB%84%E4%BB%B6/</guid>
      <description>本人只是一个前端，偶尔写一点其他语言来拓展开发技能。
因业务当中使用到 RN，所以对如何实现 RN custom module 也比较感兴趣并简单学习实现了一些功能。本文可能有些地方可能比较浅显或者有错误，还望读者海涵并指正。
 环境准备 由于 swift 的断崖式升级以及 RN 不同版本，所以下面的例子可能会存在一些误差。本机环境为：
 RN：0.45.1 swift：4.1 Xcode：9.3 OS：high sierra 10.13.4  CocoaPods CocoaPods 是专门为 iOS 工程提供对第三方库的依赖的管理工具，通过 CocoaPods ，我们可以更方便地管理每个第三方库的版本，而且不需要我们做太多的配置。直观、集中和自动化地管理我们项目的第三方库。
我们都有这样的经历，当我们添加第三方库的时候，需要导入一堆相关依赖库，更新的时候也要删掉重新导入然后再配置。当我们需要更新某个第三方库的时候，我们又要手动移除该库，导入新的库，然后再配置。这些是很麻烦且没有意义的工作。
安装 CocoaPods 需要用到 gem 。gem 是 RubyGems 的缩写，属于 ruby 上的包管理工具。
这里建议切换国内镜像源地址，当然你也可以加上 -p 参数来配置 proxy
gem sources --remove https://rubygems.org/ &amp;amp;&amp;amp; gem sources -a https://gems.ruby-china.org/  将 RubyGems 升级到最新版本，不然有可能导致配置 CocoaPods 失败。
sudo gem update --system  可以使用下面命令来查看替换镜像位置是否成功：
gem sources -l  结果应该是：</description>
    </item>
    
    <item>
      <title>谈谈 Node.js 的单线程</title>
      <link>https://hasaki.xyz/blog/2018-02-08-%E8%B0%88%E8%B0%88node.js%E7%9A%84%E5%8D%95%E7%BA%BF%E7%A8%8B/</link>
      <pubDate>Thu, 08 Feb 2018 14:22:25 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2018-02-08-%E8%B0%88%E8%B0%88node.js%E7%9A%84%E5%8D%95%E7%BA%BF%E7%A8%8B/</guid>
      <description>本文较长，内容较广，涉及内容也比较多，可能存在一些纰漏，希望读者读到本篇时如果遇到错误请指出，感激不尽。
 前言 从 Node.js 进入人们的视野时，我们所知道的它就由这些关键字组成 事件驱动、非阻塞 I/O、高效、轻量，它在官网中也是这么描述自己的。
 Node.js® is a JavaScript runtime built on Chrome’s V8 JavaScript engine. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient.
 Node.js 结构 我们可以看到，Node.js 的结构大致分为三个层次：
 Node.js 标准库，这部分是由 Javascript 编写的，即我们使用过程中直接能调用的 API。在源码中的 lib 目录下可以看到。 Node bindings，这一层是 Javascript 与底层 C/C++ 能够沟通的关键，前者通过 bindings 调用后者，相互交换数据。实现在 node.cc 这一层是支撑 Node.js 运行的关键，由 C/C++ 实现。 V8：Google 推出的 Javascript VM，也是 Node.js 为什么使用的是 Javascript 的关键，它为 Javascript 提供了在非浏览器端运行的环境，它的高效是 Node.</description>
    </item>
    
    <item>
      <title>从jwt到OAuth</title>
      <link>https://hasaki.xyz/blog/2018-01-02-%E4%BB%8Ejwt%E5%88%B0oauth/</link>
      <pubDate>Tue, 02 Jan 2018 11:31:25 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2018-01-02-%E4%BB%8Ejwt%E5%88%B0oauth/</guid>
      <description>JWT JWT 是 JSON Web Token 的缩写，可以简单理解为生产者颁发给消费者一个令牌。参照 JWT 规范 对其所做的描述是：
 JSON Web 令牌（JWT）是一种紧凑的、URL 安全的方式，用来表示要在双方之间传递的“声明”。JWT 中的声明被编码为 JSON 对象，用作 JSON Web 签名（JWS）结构的有效内容或 JSON Web 加密（JWE）结构的明文，使得声明能够被：数字签名、或利用消息认证码（MAC）保护完整性、加密。
 这个规范允许我们使用 JWT 在用户和服务器之间传递安全可靠的信息。
JWT 的构成 JWT 由三部分构成：
 Header ：头部，即 JOSE Header Claims ：声明，即 JWT Payload Signature ：签名，即 JWT Signature  JWT 由这三部分组成，每一部分都是使用 base64url 编码的，并使用句点（.）连接起来
 这里使用base64url编码而不是普通的 base64，是因为 base64 编码会产生+和/，这两个字符在 URL 中是有特殊意义的，会导致 JWT 不是 URL 安全的。
 头部(JOSE Header) JSOE 是 JSON Object Signing and Encryption，即JSON对象签名与加密的缩写。</description>
    </item>
    
    <item>
      <title>React Native ART 介绍与实践</title>
      <link>https://hasaki.xyz/blog/2017-12-13-react-native-art/</link>
      <pubDate>Wed, 13 Dec 2017 15:29:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2017-12-13-react-native-art/</guid>
      <description>React Native ART 由来 React-Art  是 Reactjs 团队基于 Art（一个兼容各个浏览器 SVG 绘制的 API 封装）开发的模块，让 React 开发者能使用 jsx 语法绘制 svg。
React Native 团队分别在 0.10.0 和 0.18.0 也添加了 iOS 和 Android 平台对 react-art 的支持，官网文档至今对其只字未提。本文旨在介绍安静躺在 react-native/Libraries/ 里的ART，并展示一些实践结果。
在 React Native 中 ART 是个非常重要的库，它让非常酷炫的绘图及动画变成了可能。但是可能是知道的人真的不多导致文档及少中文更少。很多都是把英文的参数列表翻译过来，也没有案例。
为什么用 ART React Native 本身自带的 &amp;lt;Image&amp;gt; 有很多缺陷：
首先是不支持 SVG 格式的资源，目前的解决方案有通过 ReactNative-SVG 进行实现，但是这个库需要更改客户端 bundle 文件，带来一定的风险。
其次是 Image decoding can take more than a frame-worth of time，图片的解码由于不在主线程中进行，所以不能确保所有图片和内容在同一帧内出现，使用 &amp;lt;Image&amp;gt;标签的制作的组件里的图（比如 icon）可能是三三两两“闪现”出来的，让人怀疑是个webview，体验远不如原生，尤其是在开发环境下最为明显。
其次就是不能支持矢量图形，必须放置 @2x 或者 @3x 对应的图片。</description>
    </item>
    
    <item>
      <title>React 模式，技巧，技巧和窍门</title>
      <link>https://hasaki.xyz/blog/2017-11-02-react-%E6%A8%A1%E5%BC%8F%E6%8A%80%E5%B7%A7%E6%8A%80%E5%B7%A7%E5%92%8C%E7%AA%8D%E9%97%A8/</link>
      <pubDate>Thu, 02 Nov 2017 15:29:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2017-11-02-react-%E6%A8%A1%E5%BC%8F%E6%8A%80%E5%B7%A7%E6%8A%80%E5%B7%A7%E5%92%8C%E7%AA%8D%E9%97%A8/</guid>
      <description>这篇文章整理了学习 React 过程中以及实际开发应用当中一些模式，技巧，技巧和窍门。
大部门内容是基于 React 框架下面产生的一些内容，有很大的局限性，但是确实带来了新的理念和开发方式，仁者见仁智者见智，多学习一点内容总归对职业生涯有好处。
 本篇文章还在持续更新中，如果有错误烦请指正。
 Normally React 一些常见的关于 React 需要了解的内容，就简单列举如下。下面只会列到本人认为比较值得重视的部分进行详细陈述。
 语法层面——基础入门
  JSX 语法、React 基本内容等 Derocator 或者 async await 等常见 ES6、ES7 的内容 React Lists and Keys   常用层面——日常开发必备
  smart component and dumb component container component and presentation component stateless component Events handler bind this：bind this 或者 Derocator 或者 proposal-class-public-fields-declarations Conditionals render in JSX 或者 IIFE render in JSX 或者 methods render in JSX Dynamic router 以及 Dynamic component，甚至于 Dynamic redux injection HOC Render props 16.</description>
    </item>
    
    <item>
      <title>前端性能检测和错误捕捉</title>
      <link>https://hasaki.xyz/blog/2017-09-12-%E5%89%8D%E7%AB%AF%E6%80%A7%E8%83%BD%E6%A3%80%E6%B5%8B%E5%92%8C%E9%94%99%E8%AF%AF%E6%8D%95%E6%8D%89/</link>
      <pubDate>Tue, 12 Sep 2017 15:29:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2017-09-12-%E5%89%8D%E7%AB%AF%E6%80%A7%E8%83%BD%E6%A3%80%E6%B5%8B%E5%92%8C%E9%94%99%E8%AF%AF%E6%8D%95%E6%8D%89/</guid>
      <description>在复杂的网络环境和浏览器环境下，自测、QA 测试以及 Code Review 都是不够的，如果对页面稳定性和准确性要求较高，就必须有一套完善的代码异常监控体系好的产品，这样才能很好的得到用户的反馈从而不断的迭代改进我们的产品。
而且复杂的用户终端设备，也需要通过性能监控发现部分前端性能瓶颈，以便进行优化；通过错误日志收集，及时获得前端的运行时错误
收集错误异常  错误异常分为 web 错误异常和React-native 错误异常
 web 错误异常 总体来说：平时收集日志的手段，可以归类为两个方面，一个是逻辑中的错误判断，为主动判断，如try...catch；一个是利用语言给我们提供的捷径，暴力式获取错误信息，如 window.onerror；当然也存在另外一种错误，那就是Promise unhandlerejection
try…catch 判断一个代码段中可能存在的错误：
try { doSomeThing() // code... } catch (e) { // send format error Reporter.send(format(e)) }  window.onerror 这个用来捕获全局错误：
window.onerror = function() { // send format error var errInfo = format(arguments) Reporter.send(errInfo) return true }  在上面的函数中返回 return true，错误便不会暴露到控制台中。下面是它的参数信息：
/** * @param {String} errorMessage 错误信息 * @param {String} scriptURI 出错的文件 * @param {Long} lineNumber 出错代码的行号 * @param {Long} columnNumber 出错代码的列号 * @param {Object} errorObj 错误的详细信息，Anything */ window.</description>
    </item>
    
    <item>
      <title>译文:Understanding ASTs by Building Your Own Babel Plugin</title>
      <link>https://hasaki.xyz/blog/2017-08-13-%E8%AF%91%E6%96%87understanding-asts-by-building-your-own-babel-plugin/</link>
      <pubDate>Sun, 13 Aug 2017 15:29:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2017-08-13-%E8%AF%91%E6%96%87understanding-asts-by-building-your-own-babel-plugin/</guid>
      <description>原文地址
Language Overview  We want to design a plugin that will allow us to use regular object and array literals, which will be transformed into persistent data structures using Mori
 我们想要设计一个插件：它将允许我们通过使用常规对象和数值文本，可以使用Mori转化为持久性的数据结构。
 We want to write code like this:
 我们要写这样的代码：
var foo = { a: 1 }; var baz = foo.a = 2; foo.a === 1; baz.a === 2;   And transform it into code like this:</description>
    </item>
    
    <item>
      <title>Mavic Pro 初见</title>
      <link>https://hasaki.xyz/blog/2017-07-04-mavic-pro-%E8%AF%84%E6%B5%8B/</link>
      <pubDate>Tue, 04 Jul 2017 15:29:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2017-07-04-mavic-pro-%E8%AF%84%E6%B5%8B/</guid>
      <description>早在今年 2、3 月份的时候，我就已经知道御姐 Mavic Pro 的存在了，当然是通过（万恶）的微信朋友圈，被安利、洗脑了一波，当时就很感兴趣，想买一个自己玩玩:haha:。
 下定决心要买 为什么会买呢，我也不知道，感觉是脑子一热吧
最近刚换了一份新的工作，压力有点大，中午的时候无聊看了一下官网，晚上就直接叫着女朋友去了新天地的专卖店看了下，然后就直接剁手了。。。
感觉最近不单单要吃土，还要吃灰了。。
初见 刚拿回来的时候好大的一个箱子，现在就只剩下一点东西（东西太多，放不下就直接把无用的盒子扔掉了），还好我提前拍了一张整体开箱图：
另附一张机箱开箱图：
机身和 Mac 大小对比图：
Mavic pro 装上防撞翼：
为什么选择 Mavic  无人机目前主要市面上的分为多旋翼、固定翼、直升机，Mavic Pro 就属于四轴的固定翼
 就拿大疆目前的产品线来说，几款主流品类为精灵 3、精灵 4、悟 1、御，价格从 2k+到 2W+不等，最早入手的基友们应该买的是精灵 3 或者 4。
精灵 3 有几种款型，Standard 相对来说比较初级因为图传距离理论可以 1km 实际也就六七百米，很容易失去图传对于新手而言看不见图像就会非常的慌乱，所以我自己不太推荐精灵 3S 及之前的款型作为入门机型。
大家购买的时候可以从Phantom 3 Adavanced及之后开始考虑，图传距离可以达到 5km 且比较稳定，上升高度也可以达到 500m。
然而如果你看过价格和开箱对比图的话，最好的还是御姐，适合经常需要轻装旅行的朋友，因为足够小巧加上高性能的传感器、相机，非常便于携带（把妹神器。
按照官方的性能数据：
 重量：743 克 飞行速度：最大 18m/s（65km/h 飞行时间：27 分钟（实际有折扣 图传距离：国内 4km 国外 7km（详见FCC 与 CE 与 SRRC 高度：500m 相机：4k@30fps/1080p@96fps 云台角度：78°  这已经很强了好不好！4k，27 分钟，4km 图传，500m 高度（可以自己改装飞到 1.</description>
    </item>
    
    <item>
      <title>前端的10000个小时</title>
      <link>https://hasaki.xyz/blog/2017-03-24-%E5%89%8D%E7%AB%AF%E7%9A%8410000%E4%B8%AA%E5%B0%8F%E6%97%B6/</link>
      <pubDate>Fri, 24 Mar 2017 15:29:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2017-03-24-%E5%89%8D%E7%AB%AF%E7%9A%8410000%E4%B8%AA%E5%B0%8F%E6%97%B6/</guid>
      <description>我又开始扯淡了
 本篇文章出自原文，深有感触，有删改。
 10000 小时定律 著名的 10000 小时定律，我想大家都不陌生，『要成为某个领域的专家，需要 10000 小时』，这个定律来源于《异类》的作者，格拉德威尔。
作为一个程序员，每天工作 10 小时，每周工作五天，大约 4 年就能达到 10000 小时，那是不是每个程序员认真工作，勤勤恳恳的过完 4 年他就能成为专家呢？答案是显而易见的。
首先 10000 小时只是必要条件，并非充分条件，也就是说，即使你花了这 10000 小时，可能也没什么用，再次简单的工作重复 10000 小时并不能给你带来什么提高，自然也就成不了专家
 一万小时定律 并非适合所有领域，即使有很强意志力，也很难在某些领域成为世界顶级，这里只是强调在某些领域去努力、去花费很大的精力。我觉得，这需要 实力与运气共同作用的结果
 简单的工作重复 10000 小时 吴军老师在《智能时代》一书中提过一个这样的观点：
 在未来的智能时代，真正受益于技术进步的个人可能不超过人口的 2%。
 之后他又补充了一句：
 坦率的讲，仅仅会写几行 JavaScript 的人不属于我说的 2%的行列，这些人恰恰在未来是要被计算机淘汰的。
 当时看到这里，我其实十分不解，吴军老师是不是太久没撸码了，现在 JavaScript 这么火，Node 那么牛掰，什么 React Native，Grunt，Gulp，Webpack，Vue，Weex，微信小程序等等，这些都是风生水起啊，怎么 JavaScript 就跪了呢？还有，我们高大上的前端工作怎么就挤不进这 2% 呢？
后来仔细想想，这里定义的是『仅仅会写几行 JavaScript 』，事实上，如果 10000 小时都花在改界面，修改 DOM，改个色值，切个图，替换下图标这种简单重复的工作里面，当然挤不进这 2% 。事实上，要学的东西远远不够，前端要有危机意识。
再来看，前端工作怎么就挤不进 2% 的人呢？ 2% 看起来还挺多，可是想想，每种职业都有其 2% ， 搬砖的有搬砖的 2%，写程序的有些程序的 2%，总不可能写程序的去抢搬砖的活儿吧。能不能挤进这 2% 要看是否善于使用智能工具，很不幸，我发现一些热门的技术的发起都和前端没啥关系，什么数字化，VR/AR，基因测序，大数据，机器学习，人工智能……</description>
    </item>
    
    <item>
      <title>koa 源码简单解读</title>
      <link>https://hasaki.xyz/blog/2016-09-03-koa%E6%BA%90%E7%A0%81%E7%AE%80%E5%8D%95%E8%A7%A3%E8%AF%BB/</link>
      <pubDate>Sat, 03 Sep 2016 15:29:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2016-09-03-koa%E6%BA%90%E7%A0%81%E7%AE%80%E5%8D%95%E8%A7%A3%E8%AF%BB/</guid>
      <description>Koa 是一个类似于 Express 的 Web开发框架，创始人也都是 TJ
Koa 的主要特点是，使用了ES6 的 Generator 函数，进行了架构的重新设计。Koa 的原理和内部结构很像 Express，但是语法和内部结构进行了升级，最近已经发布了2.x版本，我们来直接看一下2.x版本的koa
创建 Koa 应用 我们可以按照官方的说明很简单的创建一个koa应用
const koa = require(&#39;koa&#39;) const app = new koa() app.listen(3000)  或者可以这样：
var koa = require(&#39;koa&#39;) var http = require(&#39;http&#39;) var app = new koa() http.createServer(app.callback()).listen(4000)  这两种方式是等价的：
第一种方式:listen在内部主动创建一个一个http server并调用实例内部的 callback方法，把返回的handleRequest函数作为创建http server服务的回调函数，然后内部主动去listen。
参考源码 listen方法：
listen() { debug(&#39;listen&#39;); const server = http.createServer(this.callback()); return server.listen.apply(server, arguments); }  第二种方式:主动创建一个http server并主动调用实例的callback方法来生成一个handleRequest函数，最后listen端口号。
我们先以第一种写法作为入口，切入进去来分析源码。
首先实例化了一个koa实例，然后调用了listen方法:
简单解读: koa 本身是没有定义事件处理机制的，其事件处理机制继承自Node 的events模块，本身就是在events模块上继承的一个实例</description>
    </item>
    
    <item>
      <title>如何创建一个Node.js 的 Docker 开发环境</title>
      <link>https://hasaki.xyz/blog/2016-06-22-%E5%A6%82%E4%BD%95%E5%88%9B%E5%BB%BA%E4%B8%80%E4%B8%AAnode.js-%E7%9A%84-docker-%E5%BC%80%E5%8F%91%E7%8E%AF%E5%A2%83/</link>
      <pubDate>Wed, 22 Jun 2016 15:29:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2016-06-22-%E5%A6%82%E4%BD%95%E5%88%9B%E5%BB%BA%E4%B8%80%E4%B8%AAnode.js-%E7%9A%84-docker-%E5%BC%80%E5%8F%91%E7%8E%AF%E5%A2%83/</guid>
      <description>本文以构建一个 Node.js Docker 应用 为目标写的一个教程。当前操作系统环境 Mac OSX Sierra 10.12.4
 Docker 介绍  Docker 是个划时代的开源项目，它彻底释放了计算虚拟化的威力，极大提高了应用的运行效率，降低了云计算资源供应的成本！ 使用 Docker，可以让应用的部署、测试和分发都变得前所未有的高效和轻松！
 Docker 引擎的基础是 Linuxring 器(Linux Containers，LXC)技术。这个并不是一个新生的概念，很早前已经出现，比如操作系统上的chroot工具、以及Solaris Containers和FreeBSD jail等等，虽然这个技术非常成熟，然而这些工具使用起来非常不方便。Docker 的出现解决了这些问题。
Docker 容器虚拟化有很多好处：
 更高效的利用系统资源：由于容器不需要进行硬件虚拟以及运行完整操作系统等额外开销，Docker 对系统资源的利用率更高。 更快速的启动时间，Docker 容器应用启动时间很快 一致的运行环境和环境隔离 持续交付和部署 更轻松的迁移服务  既然 Docker 这么好，我们来试试如何跑一个 Node.js Docker 应用。
安装 Docker 使用 Docker 之前，我们需要安装。Docker 支持在主流操作平台上使用：包括 Ubuntu、CenterOS、Windows 已经 MacOS 系统。
Ubuntu 在 Ubuntu 上安装 Docker 可以直接使用以下 shell script
// 最新的Docker安装需要先移除老的Docker sudo apt-get remove docker docker-engine sudo apt-get update sudo curl -sSL https://get.</description>
    </item>
    
    <item>
      <title>利用 Shadowsocksr 和云主机翻墙</title>
      <link>https://hasaki.xyz/blog/2016-04-03-%E5%88%A9%E7%94%A8-shadowsocksr-%E5%92%8C%E4%BA%91%E4%B8%BB%E6%9C%BA%E7%BF%BB%E5%A2%99/</link>
      <pubDate>Sun, 03 Apr 2016 15:29:40 +0800</pubDate>
      
      <guid>https://hasaki.xyz/blog/2016-04-03-%E5%88%A9%E7%94%A8-shadowsocksr-%E5%92%8C%E4%BA%91%E4%B8%BB%E6%9C%BA%E7%BF%BB%E5%A2%99/</guid>
      <description>世界那么大，我想去看看，但是被墙了… 以前用的 VPN，叫做什么green vpn，总体来说，还不错，但是最近老断，于是就搞了个新的法子。申请一台云主机，在上面搭一个 Shadowsocks，然后就可以在所有客户端看 YouTube 了，当然，这所有的一切都是免费的。
 Shadowsocks 已经河蟹，这里不再说 ss，只说 ssr：一个基于 ss 的新分支
 搭建 Shadowsocksr 服务器 首先需要搭建一台云主机，首先阿里云或者青云都是挺好的，但是都需要国外的主机，要不然怎么去翻墙，你也可以选择 linecode、vultr、aws、azure、GCE（google）。这些大部分都有一年的免费期限，也会有免费赠送不定的体验金的福利。中间会要求绑定信用卡。
主机建议选择 Ubuntu 或者 debian，申请下来了后就可以安装 ssr 了。
可以从这个地址上找到 ssr，然后可以参照这个wiki来进行配置安装，在这里记录一下步骤吧：
 如果你的服务端 python 版本在 2.6 以下，那么必须更新 python 到 2.6.x 或 2.7.x 版本。
 首先需要有 git：
apt-get update &amp;amp;&amp;amp; apt-get install -y git  获取源代码：
git clone -b manyuser https://github.com/shadowsocksr/shadowsocksr.git  进入子目录：
cd ~/shadowsocksr &amp;amp;&amp;amp; bash initcfg.sh &amp;amp;&amp;amp; cd ~/shadowsocksr/shadowsocks  快速运行，当然也可以通过配置文件运行，具体请看wiki：</description>
    </item>
    
  </channel>
</rss>