Merge branch 'master' of https://github.com/dt-fe/weekly

49.精读《Compilers are the New Frameworks》.md

@@ -0,0 +1,120 @@
+本期精读文章 [《Compilers are the New Frameworks》](https://tomdale.net/2017/09/compilers-are-the-new-frameworks/)
+
+## 1 引言
+
+本期文章篇幅短小却言简意骇，文中开头作者就抛出自己的观点 **Web 框架正在从运行库转变为优化编译器**。
+
+作者主要从编译性能方面入手，也提到 WebAssembly 可能将会是下一代 Web 应用的落脚点，因此他也建议 Web 开发者们深入了解学习编译器的工作原理。
+
+## 2 概述
+
+目前业界流行使用一整套工具来搭建前端项目，如 webpack、webpack-dev-server、babel、scss、react、redux、react-router ...，在项目开发期间需要花费大量时间去进行工程性能优化、编写大量的构建配置项等，从现在前端工程的复杂度以及前端开发的工作量来看，前端框架已经不能再仅仅只是一个单独的视图层或数据处理层，而应该是一套相对完整的框架，它不仅提供如何编写前端页面的方法，同时也应该考虑代码构建编译的性能、页面间路由的跳转、新语法的兼容等一系列问题。
+
+这也正是本期精读文章抛出的观点，Web 框架正在从运行库转变为优化编译器，或者说 Web 框架需要将优化编译性能考虑进去。
+
+### PriJs & UmiJs
+
+[PriJs](https://prijs.github.io/pri-docs/) & [UmiJs](https://umijs.org/docs/zh-Hans/getting-started.html) 二者正是以上述观点为基础的，基于 react 并包含了工具 & 路由 & 性能优化 & 数据流等强约定弱配置的前端一站式框架，通过约定、自动生成和解析代码等方式来辅助开发，减少开发者在性能&配置&路由&构建上耗费的时间，可以更专注于业务逻辑。
+
+#### 构建工具
+
+webpack 是目前主流的前端代码构建工具，但其复杂的配置一直是前端开发者头疼之处，PriJs & UmiJs 框架内部解决了这一难题，它们将 webpack 复杂的性能优化配置全部内置化，使项目在 0 配置的基础上直接支持 PWA、Automatic code splitting、Tree Shaking、Auto dll、Import on demand、Auto pick shared modules、Scope Hoist、Dynamic import、Service Worker、Sass Loader 等。
+
+#### 页面&路由
+
+PriJs & UmiJs 提供页面生成模版，并自动根据项目页面生成路由，通过单页面或多页面特性决定路由跳转的类型，默认提供 404 页面。
+
+#### 数据流
+
+PriJs & UmiJs 虽然是基于 react 的前端一站式框架，暂不支持 vue、angular 等，但并不局限数据流的使用的方式，可以根据项目需求使用任意数据流方式，如 redux、mobx 等。
+
+#### 插件机制
+
+PriJs & UmiJs 提供了灵活的插件机制，使项目能够拥有强大的定制能力，通过插件机制可以变更 webpack 配置、修改路由规则、修改页面模版、新增命令、使用任意数据流、定制项目规范和约定等。
+
+#### 其它
+
+此外，PriJs 还支持 markdown 格式、支持 Deploy to github pages、支持 Typescript 等。
+
+PriJs & UmiJs 前端一站式框架实际上是提供了一整套的前端开发解决方案，它不仅仅只是单纯的一个运行库，而是将构建性能&工具&路由等一系列问题全部解决，这种做法在一定程度上不正是在说明 Compilers are the New Frameworks。
+
+读者们对此肯定有很多不同的观点和看法，不妨各抒己见。
+
+## 3 精读
+
+精读文章作者建议 Web 开发者学习编译器工作原理，对于前端开发者来说可以从与前端现在和未来息息相关的 JIT 和 WebAssembly 入手学习编译器相关原理。
+
+### JIT
+
+JIT（Just-in-Time）主要是针对 javascript 这一解释型语言所做的性能优化，即浏览器引入[编译器](https://baike.baidu.com/item/%E7%BC%96%E8%AF%91%E5%99%A8)来解决[解释器](https://baike.baidu.com/item/%E8%A7%A3%E9%87%8A%E5%99%A8)性能低效的问题，形成混合的模式。
+
+#### 监视器
+
+浏览器在 js 引擎中增加一个监视器，用于监控通过解释器的代码的运行情况，并将同一行代码运行若干次标记为 **warm**，将同一行代码运行很多次标记为 **hot**。
+
+#### 基线器
+
+JIT 会将 **warm** 代码段放到基线编译器中，并将编译结果存储起来。该代码段的每一行都会被编译成一个 stub，并以 **行号 + 变量类型** 为索引。如果监视器监视到了执行同样的代码和变量类型，就直接将对应的已编译版本提交给浏览器执行，而不用重新通过解释器来翻译，通过这样的做法可以加快执行速度。
+
+#### 优化器
+
+JIT 会将 **hot** 代码段放到优化编译器中进行代码优化，不过需要遵循优化规则：即如果代码循环中每次迭代的对象都有相同的形状，那么就认为它以后迭代的对象的形状也是相同的。但 javascript 是没有类型定义的，就无法确保每次代码迭代的对象都会具有相同类型，因此在代码运行前会检查其规则是否合理，如果合理则执行优化代码，如果不合理则丢弃优化代码，重新回到解释器或基线器。大多数浏览器为了防止引起 **优化 - 丢弃优化** 的无限循环，一般会对优化次数做限制，比如 JIT 做了超过 10 次 **优化 - 丢弃优化** 的操作，那么就不再执行优化编译。
+
+JIT 在优化提升 javascript 性能的同时也会增加多余的其它开销，主要是对代码的监视和编译时间的开销，具体包括：
+
+- 优化和丢弃优化的开销
+- 监视器存储的内存开销
+- 丢弃优化时恢复存储的内存开销
+- 基线版本和优化后版本的内存开销
+
+而 WebAssembly 从更底层去解决这部分多余开销，进一步提升 Web 应用的性能。
+
+### WebAssembly
+
+为什么说 WebAssembly 更为高效，性能更好？
+
+在 JS 引擎中性能消耗的分布大致为：将源码转为解释器可运行代码 -> 基线&优化编译器的运行 -> 优化-丢弃优化的过程 -> 执行代码 -> 垃圾回收&内存清理，这个过程是交叉进行的。
+
+![](https://user-images.githubusercontent.com/3983192/37875422-882e5cf2-3071-11e8-873f-497d45040084.png)
+
+而 WebAssembly 却只要简单的三个步骤即可完成 JS 引擎的整个交叉执行过程。
+
+![](https://user-images.githubusercontent.com/3983192/37875442-e3e03a5c-3071-11e8-9186-b65843520aa0.png)
+
+#### Parse
+
+当到达浏览器时，JS 源码需要被解析成 AST（抽象语法树）变成字节码提供给引擎编译，而 WebAssembly 却不需要这种转换，因为其本身就是字节码，因此它只需对代码进行 decode 并检查其正确性即可。
+
+#### Compile + Optimize
+
+这是执行代码编译和优化的阶段，在这个阶段 WebAssembly 的性能优于 JS 的主要原因为：
+
+- WebAssembly 是有类型定义的代码，不需要在编译前运行代码来获取变量类型
+- WebAssembly 不需要像 JS 那样当变量类型改变时需要将代码编译成不同版本
+- WebAssembly 不需要在编译阶段做太多的优化工作
+
+#### Re-optimize
+
+当 JIT 在执行 JS 阶段发现变量类型不合理，就会丢弃优化代码重新进行 **优化 - 丢弃优化** 的循环，而 WebAssembly 中的变量类型都是确定的，JIT 不需要检查变量类型的合理性，因此并没有重优化阶段。
+
+#### Execute
+
+如果开发者了解 JIT 的内部实现机制，当然是可以针对性的写出符合 JIT 标准的代码，使之具有更高的执行效率，但通常开发者为了代码可读性更好而使用的编码模式往往却不适合编译器对代码的优化，而且不同浏览器的优化规则也不尽相同，导致 JS 的执行效率并不高。
+
+WebAssembly 正是为了编译器而设计的，很多 JIT 为 JS 所做的优化 WebAssembly 并不需要，使得 WebAssembly 专注于提供执行效率更高的指令。
+
+#### Garbage collection
+
+JS 不支持开发者手动清理内存，而是由 JS 引擎自动做垃圾回收，因此垃圾回收的时机并不可控，有可能会在一个不合适的时机执行，而且也会增加代码执行的开销。而对于 WebAssembly 而言，其内存操作是由开发者手动控制的，虽然会增加一些开发成本，不过这也使的代码执行效率更高。
+
+## 4 总结
+
+本文从 **Web 框架正在从运行库转变为优化编译器** 这一观点切入，讨论了 PriJs & UmiJs 前端框架的思路转变，简洁的描述了 JIT 的工作原理以及 WebAssembly 相比于 JS 的性能优势。
+
+本文主要希望读者可以积极参与讨论此观点，因此并没有长篇剖析 JIT & WebAssembly 的深刻原理，但我相信深入学习编译器的工作原理对 Web 开发者来说绝对是受益匪浅的事情，后续文章将对 WebAssembly 进行深入探讨和剖析。
+
+## 5 更多讨论
+
+> 讨论地址是：[精读《Compilers are the New Frameworks》 · Issue #69 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/69)
+
+**如果你想参与讨论，请[点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，每周末发布。**

50.精读《快速上手构建ARKit应用》.md

@@ -0,0 +1,52 @@
+# 精读《快速上手构建ARKit应用》
+
+原文地址: [how-to-make-your-own-arkit-app-in-5-minutes-using-react-native](https://medium.com/@HippoAR/how-to-make-your-own-arkit-app-in-5-minutes-using-react-native-9d7ce109a4c2)
+
+## 引言
+ARKit是苹果推出的增强现实套装，而react-native-arkit是基于此的上层封装。对于前端开发而言，这可能是最快上手ARKit的方式了，本周精读让我们来初窥ARKit和React Native ARKit这个库。
+
+## 概要
+本次精读我们带来的是一篇《快速上手构建ARKit应用》，原文链接如上。原文标题更加直接，直译的话是“如何在5分钟里利用react native搭建出你自己的ARKit应用”。确实，这篇文章整体也非常明确，以跑起整个ARKit Demo为最直接最主要的目的。
+
+跑起ARKit，也很简单。硬件上，只要有一台iPhone 6S以上的手机；软件上，只要准备好最新版本的XCode和日常开发要用的Node环境了就好。按照`react-native-arkit`的里面的README就可以跑起来了。这个库不
+
+## 3 精读
+在开始精读前，我先抛出我的问题三连：Why AR? Why ARKit? Why React Native ARKit?
+
+### 3.1 Why AR?
+在之前的第43期精读评论中，我们探讨了AR对于和前端结合的可能性。总的来说，AR把前端开发不再局限在有限的屏幕空间上，对于可视化等对前端展示空间有强烈需求的细分领域，AR是一个很值得研究的内容。如果对于这一块内容有兴趣，欢迎回看第43期精读评论 [《精读〈增强现实与可视化〉》](https://github.com/dt-fe/weekly/blob/master/43.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%A2%9E%E5%BC%BA%E7%8E%B0%E5%AE%9E%E4%B8%8E%E5%8F%AF%E8%A7%86%E5%8C%96%E3%80%8B.md)。
+
+### 3.2 Why ARKit?
+为什么选择 ARKit 入手进行实验？其因有二。第一，相比于 Microsoft HoloLens 的价格，售价只有它三分之一的iPhone X无论是体积重量，还是性价比，抑或是保有量都是大大占优的。噢对，说到保有量，iPhone 6S及以上都支持ARKit。所以说iPhone是我们身边最容易接触到的AR设备是不为过的。第二，ARKit对于硬件的利用能力非一般的前端库可以做到的。大部分的AR前端库可以做到利用陀螺仪来构建一个三维立体空间。但是ARKit更进一步，他利用高频调用摄像头，通过对图像进行识别分析，可以进行空间感知，例如可以识别出一个平面。而这些都是ARKit所提供的，我们只需要调用它的能力就好了。对于开发者而言，ARKit会比一般的AR库更近一步。
+
+### 3.3 Why React Native ARKit?
+对于当下的前端开发，所有事情可以分为两种——0. 可以用 JavaScript 写的 1. 其他。至于为什么选择`react-native-arkit`这个库，原因自然也可以理解。相比于用原生的Swift来开发，React Native 的开发方式对于前端而言明显是更加容易上手了。对于尝试新东西，这也未尝不可。
+
+### 3.4 About Demo
+相比于原文中从初始化开始的步骤，官方还提供了一个已经配置好的[官方Demo](https://github.com/HippoAR/ReactNativeARKit)。使用这个，如果环境没有问题，的确只需要5分钟就可以跑起来一个ARKit应用了。
+
+![](https://img.alicdn.com/tfs/TB11dGFiFmWBuNjSspdXXbugXXa-540-960.jpg)
+
+上面的图片来自原文，可以看到，在`react-native-arkit`这个库里面的所支持的9种基本图形和文字。使用如下已经封装好的React Native组件就可以直接使用了。
+
+```javasctipt
+<ARKit.Box
+  pos={{ x: 0, y: 0, z: 0 }}
+  shape={{ width: 0.1, height: 0.1, length: 0.1, chamfer: 0.01 }}
+/>
+```
+
+[几何构造](http://v.youku.com/v_show/id_XMzUxMjk3NjUxMg==.html)
+上面的一个视频片段是我们在跑起来Demo后的立体效果。可以很清楚地看到，ARKit感知到了房间这个立方体空间后所构建出来的AR的效果。
+
+[平面识别](http://v.youku.com/v_show/id_XMzUxMjk3OTc0NA==.html)
+而最后的这段视频会更加有趣一些，中央的红圈的出现逻辑是停留在最近识别出的一个平面上。我们可以看到首先识别出了地面，红圈随地面而动；再移向桌面时，很快又识别出了桌面，重新生成了一个停留在桌面上的红圈。通过这一段可以看出无论是明暗划分明显的地面，还是堆满杂物的桌面，ARKit都可以很轻松的识别出来。
+
+## 4. 总结
+苹果的ARKit对空间平面的感知能力胜过了一般的AR渲染库。而iPhone 6S就能跑的特性又让我们觉得AR其实并没有那么遥远。在此基础之上的React Native封装`react-native-arkit`，让我们通过JS就拥有操作ARKit的能力。这的确是一个快速上手ARKit的方式。
+
+
+## 5 更多讨论
+讨论地址是：[精读《快速上手构建ARKit应用》 · Issue #70 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/70)
+
+如果你想参与讨论，请[点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，每周末发布。

51.精读《Elements of Web Dev》.md

@@ -0,0 +1,214 @@
+# 1 引言
+
+本周精读, 来一起总结web开发的环节, 知识块和技能点. 是不是像xx速成班宣传的一样, 培训三个月, 经验顶三年, 入职BAT, 年薪三十万?
+
+本文虽然是罗列知识点, 但我想很有意义. 对于学习的人来说, 提供一个路线图. 对从业者来说, 对全局有更好的把控, 利于看到自己的强项和不足. 对组建团队, 更能起到一个点将谱的作用.
+
+在网上我没有搜到任何深入全面的总结, 提供的那几篇已经算稍微好一些的了. 其他的要么太过笼统(前端-后端-数据-运维, 完毕)要么太细太窄(并不是不好, 只是和本文性质不一样). Generalist和Specialist之间永远是一对辩证矛盾, 持续思考.
+
+本文提供了有层级的列表形式, 如果有兴趣的读者可以把它做成概念图形式, 相互关联与距离相关, 可能会有意料之外的效果.
+
+# 2 列表
+
+列表形式, 方便搜索浏览, 加上一些解释和列举
+
+## Backend
+
+- authentication, oauth
+
+- API design, RESTful, GraphQL
+
+- payment integration
+
+- social integration
+
+- session/cookie management
+
+- user management
+
+- Server, e.g. nginx, connection model, conf, rewrite
+
+- CRM
+
+## Deployment, Env management, Container
+
+- rollback/rollforward
+
+- no downtime, non-disruptive deployment
+
+- deploy to downstreams, e.g. npm, chrome extension store
+
+- artefact management, e.g. gzips, OS specific builds
+
+- container technology e.g. Docker, AWS ami
+
+## DB
+
+- schema design
+
+- ORM
+
+- language/env specific driver
+
+- test/seed data
+
+- backup
+
+- batching, DB perfgomance
+
+- query syntax, e.g. SQL, mongo query syntax
+
+- connection pool/concurrent connection management
+
+- connection restriction e.g. localhost only
+
+## MessagingQueue/Middleware
+
+## Testing
+
+- parallel execution
+
+- UI automated testing
+
+- browser/OS compatibility, e.g. headless browser, cloud solutions
+
+- screenshot diff regression
+
+- unit test, isolation
+
+- mocking
+
+- integration test techniques
+
+- coverage (line coverage, path coverage etc.), permutations
+
+## Security
+
+- CSRF, XSS, SQL injection, DDoS, brute force etc.
+
+- automated tools
+
+
+## OS
+
+- OS differences, e.g. filesystem, path separator
+
+- run daemon, startup job, process manager
+
+- ssh
+
+- everything bash, zsh, powershell, e.g. wildcard, expansion, syntax
+
+- everything *nix, du, filesystem, ps, process model, netstat, pipes
+
+## networking
+
+- HTTP, and everything it entails e.g. CORS, MIME types, chunked
+
+- websocket
+
+- webworker, service worker
+
+- proxy
+
+## Web visualization technologies and principles
+
+- webgl
+
+- 2D/3D coord system and calculations
+
+## Web standards, e.g. webassembly
+
+## performance tuning
+
+- frontend: lighthouse
+
+- backend: load balancing, perf monitoring and profiling
+
+## Source control
+
+- work flow
+
+- tagging, release, branching
+
+- PR, collaboration
+
+- commit message conventions
+
+## Project management, Product management
+
+- main success scenario
+
+- PRD doc, sketch
+
+- milestone, timeline, estimate
+
+- daily report, weekly report
+
+## Software Monitoring
+
+- performance monitor
+
+- exception monitor
+
+- alert and alarm rules
+
+- logging
+
+## Engineering
+
+- lint, prettier, custom rules, autofix
+
+- editor, IDE, plugins, e.g. intellisense
+
+- debugging, remote debug, debug mobile
+
+## Analytics
+
+- heatmap
+
+- conversion
+
+- bounce rate
+
+## Frontend
+
+- data flow
+
+- state management
+
+- componentization
+
+- transpile, packing tool, e.g. webpack gulp coffeescript Typescript
+
+- templating, e.g. handlebar
+
+- ajax, jsonp etc.
+
+## Design / styling
+
+- cascading rules
+
+- preprocessor, e.g. scss less
+
+- box model
+
+- z-index
+
+- flexbox
+
+- design principles, layout, color, theme
+
+# 3 参考阅读
+
+https://medium.com/coderbyte/a-guide-to-becoming-a-full-stack-developer-in-2017-5c3c08a1600c
+
+https://medium.com/codingthesmartway-com-blog/the-2018-roadmap-to-fullstack-web-development-8884ff02557a
+
+https://www.lynda.com/learning-paths/Web/become-a-full-stack-web-developer
+
+# 4 更多讨论
+
+> 讨论地址是：[精读《Elements of Web Development》 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/71)
+
+**如果你想参与讨论，请[点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，每周五发布。**