AMD 是 RequireJS 给出的模块加载方案。 支持递归依赖解析、模块异步加载，夜兼容 CommonJS 可以在 Node.js 里用。 虽然目前已经不再流行，很多站点更倾向于编写 ES Modules 并直接 Webpack 打包， 但 AMD 是完整的，兼容性良好的，支持动态加载的模块化方案，在大型的、独立部署的、异构的项目中仍然有一席之地。 所以还是决定写一篇关于 AMD 最佳实践的文章，致敬老式的 Old School 的 Web 开发。

TL;DR

• 源文件中，模块应该匿名编写。区分好“使用 AMD 语法”和“模块化”，充分利用 AMD 又不被套牢。
• 一个模块对应一个文件。每个模块是一个单独的源文件，每个文件只包含一个模块定义。
• 避免手动写依赖列表，可以通过编译工具自动生成。
• 独立维护的工具模块，应当通过打包编译隐藏其内部结构。

这又是一篇短命的（short-lived）描述当下技术框架的博客文章。 DI（依赖注入、Dependency injection）是一种设计模式，常用来提升代码的可复用性、健壮性和可测试性。 DI 在前端的流行很大程度上归功于它在 Angular1.x 中的应用。 Angular 2 以后借助 TypeScript 的类型分析，可以干脆省去了 Angular1.x 中冗余的依赖声明。 本文用来解释这个魔法是怎么工作的，以及相关的标准化 Proposal 和实现 Trick。

对于不熟悉依赖注入的同学可以参考我的另外两篇文章 什么时候应该使用依赖注入 和 JavaScript 依赖注入实现， 或者 Wikipedia: DI。这里还有一篇 Angular 的教程：https://angular.io/guide/dependency-injection

在 MacBookPro 上安装 ArchLinux 后最大的问题就是那一排功能键和触摸板还能不能用。 功能键比较复杂涉及你的桌面系统或窗口管理器的选择， 本文解释 MacBook 触摸板如何在 ArchLinux 下进行配置。 依赖的软件只有触摸板驱动 xf86-input-mtrack 和 X11，本文应该对绝大多数 Linux 发行版都适用。（不过 Ubuntu 貌似是 Wayland 窗口服务？）

我们重点解释如何恢复 OSX 下独有的触摸板手感和功能： 自然（反向）滚动、三指选择和拖动、四指横向滑动、滚动惯性、鼠标加速（Pointer Acceleration）。 触摸板的通用配置比如敲键时禁用触摸板、手掌识别等，可以参考 Harttle 的另一篇文章： Linux 下的触摸板设置

TL;DR

文中主要介绍一些技巧和原理。心急的同学可以直接按以下步骤操作：

1. 安装 AUR 包 xf86-input-mtrack
2. 把 50-mtrack.conf 下载到 /etc/X11/xorg.conf.d
3. pkill x 或者 sudo reboot

AUR（ArchLinux User Repository）是 ArchLinux 的社区驱动的软件仓库， 属于不受支持的软件仓库（unsupported）。 但它却是 Arch 社区最有活力的仓库，很多官方仓库（Official Repositories）中的包都来自于 AUR。 AUR 之于 ArchLinux 官方仓库，类似于 Boost 社区之于 STL，类似于 PPA 之于 Ubuntu 官方仓库。 Harttle 在 MacBookPro 上安装 ArchLinux 时就用到了非常多的 AUR 包。

由于 AUR 中的包不受支持，ArchLinux 的官方包管理工具 pacman 不支持从 AUR 安装。 这就需要额外的工具，几年前 yaourt 独大，在很多 ArchLinux 安装教程中都会介绍如何安装 yaourt。 时至今日 yaourt 已经停止开发（discontinued），官方更愿意推荐 AUR 工具而非安装器。 因为这些包属于 unsupported，你要为安装和维护它们负责，ArchLinux 认为你应当知道一个包是怎样编译和安装进入你的系统的。

本文先介绍 ArchLinux 提供的软件包构建/安装方式，以及如何手动从 PKGBUILD 构建/安装一个软件包。 最后再介绍一些 AUR 工具。

很久以前写过一篇 安装 Arch Linux 的文章，解释在普通 PC 上安装 ArchLinux。 如今需要把一台 MacBook Pro（2013 Late）用于工作，而且 ArchWiki 上介绍安装系统的 Beginners’ Guide 也已经没有了，就借机写一篇如何在 MacBook Pro 上安装 ArchLinux 的介绍。

注意：本文介绍的是在 MacBoot Pro 上安装 ArchLinux 单系统。其他方案请直接参考 https://wiki.archlinux.org/index.php/Mac。

从 AJAX（Asynchronous JavaScript + XML，异步JavaScript和XML）开始应用， 尤其是 AngularJS 推出之后 SPA（Single Page App，单页应用）已经成为前端 App 的必选方案。 SPA 可以在客户端提供完整的路由、页面渲染、甚至一部分数据处理； 这往往需要一个比 jQuery 时代更重的 JavaScript 框架，来实现这些原本发生在后端的逻辑。 多数框架如 React、Vue 还会内置组件化机制来帮助开发者组织代码， 它们甚至进化到专门负责视图组件的程度，路由和数据交由各种插件来处理， 比如 vuex、Redux、Vue Router 等等。 这些工具已经相当先进和完整，提供了路由方案、服务器端渲染方案、前端状态管理方案。

但 SPA 的本质还是浏览器端 App，底层技术仍然依赖 history API、defineProperty、AJAX。 这些 API 的能力和完备性，决定了 SPA 能达到的用户体验和上层架构设计。 也正是这些底层 API 的不足和缺陷使得 SPA 很难企及原始 Web 的架构优势。 比如在内容可访问性（Accessibility）、服务的独立部署和演化（Independent Deployment） 等方面远不及十年前搭建的同类站点。同时还在不同程度上破坏了 HTTP、URL、HTML 的语义， 这些缺陷使我们需要花费大量精力去修复日志统计、性能优化、首屏渲染、静态分析和测试等环节。 而陷阱在于决策使用 SPA 方案时不一定能有足够的远见看到这些问题对架构带来的深远影响。

与此同时 Web 标准也在持续迭代，诸如 Web Bluetooth、Push API、Web of Things、Service Worker 的标准已经在主流浏览器（尤其考虑国内 webkit 内核的普及程度）有不同程度的支持。 尤其是 PWA（Progressive Web App，渐进式 Web 应用）概念的提出， 给出了一种在不破坏 Web 架构的前提下实现流畅用户体验的方式。 本文就 SPA 架构的一些不足展开讨论， 并探讨 PWA 方案（这里说是方案，其实更是一种技术方向的选择）的价值和私有平台的最佳演化方式。

ES5 没有定义文件之间引用方式，在浏览器中文件之间引用需要通过类似 define, require, __webpack_require__ 这样的全局变量，它们由不同的模块化框架定义。 ES Modules 从标准上定义了 JS 文件间的引用方式，而且现在主流浏览器和 Node.js 都已经有了实现。 本文介绍 Node.js 中新写的 ES Modules 怎么和旧的 CommonJS 模块相互引用， 以及如何引用 npm 上成千上万的 CommonJS 模块。即 ES Modules 和 ES5 Script 间的互操作问题。 ES5 Script 有多种模块化实现，本文集中讨论 Node.js 中的 CommonJS。