合理地设计 URL

HTTP URL 路由

URL 是 Web 三大基石之一,在 Web 开发、运维和使用过程中随处可见。 而且在 Web 开发中遇到的第一个设计问题,可能就是 URL 的设计。 在很多 MVC 架构下的开发者眼中它的作用却只是路由到一个控制器,这正是一切罪恶的开端。

继续阅读

禁用 package-lock

NPM Node.js 缓存 版本

npm(Node Package Manager)是由 JavaScript 编写的 Node.js 默认的包管理工具, 会随 Node 一起安装。NPM 是伟大的工具,在它的基础上构建了现在的整个 JavaScript 生态。 这些模块有每周数十亿的下载量,可以用来构建 Web 服务命令行工具,IoT 节点, 桌面应用,甚至操作系统。

npm 5.0 开始会自动生成 package-lock.json,解决 npm 无法递归锁定版本的问题(类似 yarn)同时使用该文件作为缓存来加速依赖解析。 但现在看来 package-lock 制造的问题比解决的问题还要多,有些争议性的处理细节仍在讨论。

Harttle 不建议现在使用 package-lock,文章尾部给出了禁用 package-lock 的方式。

继续阅读

恢复 TMUX 工作区

Bash Session Tmux

Harttle 此前介绍过 Tmux 的使用,我们知道 Tmux 可以把所有打开的 Shell 都保存在服务器。 你的 Terminal 重启不会丢失任何东西,但 Server 重启后 Session 会全部丢失。 如果你像 Harttle 一样在开发 PC 本地运行 Tmux Server 的话,每次开机后都需要重新建立各种会话和窗格。

本文介绍一个 Tmux 插件:tmux-resurrect, 可以一键保存当前 Tmux 状态,包括 Session、Window、Pane 布局,甚至 Vim 状态也可以恢复。

如果你更偏向 The Hard Way,可以参考 恢复 TMUX 工作区 - The Hard Way,手动完成一切初始化工作。

继续阅读

CLI 测试:文件与标准输出

BDD Mocha Node.js 测试 Ramdisk

利用 Mocha 进行 BDD 风格测试 中介绍了 Node.js 下如何做单元测试,要确保软件的质量我们还需要 e2e 测试, 确保整个系统在真实场景下能够正常工作。

End-to-end testing involves ensuring that the integrated components of an application function as expected. The entire application is tested in a real-world scenario such as communicating with the database, network, hardware and other applications. – techopedia

本文 Node.js 的命令行程序(CLI)为例,介绍如何测试一个可执行程序的输入输出以及文件修改。 样例代码可参考 APM 的 e2e 测试代码

继续阅读

客户端渲染有哪些坑?

MVVM 异步渲染 路由 兼容性 pushState popstate

从别的角度出发,客户端渲染有很多其他名字比如前端渲染、前端异步、前端 MVC。 今天的 Web 稍有交互的站点都会做一套前端渲染,从早期的 Backbone,AngularJS 1.0, 到现在的流行的 Vue,React。基于这些技术做 MVVM 的同时甚至可以完成服务器端渲染。 但浏览器的客户端渲染(也就是前端 MVC)仍然存在不少限制,这些限制都是前端渲染绕不过的问题。

继续阅读

利用 Plex 和 Syncthing 搭建媒体中心

Plex Syncthing Archlinux SSH systemd

因为软件都是朋友介绍的,这篇文章本来是不打算写的。 但由于在坑上浪费不少时间还是写出来或许对新接触 NAS 的人有所帮助。 本文记录如何利用 PlexSyncthing (可以用FTP替代)搭建家用 NAS,具体地实现了这些功能:

  • P2P 的文件备份。
  • DLNA 媒体服务。
  • 随时上传媒体文件。

笔者的设备:Acer 笔记本(Archlinux),小米 TV(Android)。 可能和您的设备有所区别,但原理类似。我了解到即使对 Windows 版本,用户和权限等策略都是一样的。 或者你可以 安装一个 Arch

继续阅读

浏览器的 16ms 渲染帧

DOM JavaScript 异步 性能 重绘

由于现在广泛使用的屏幕都有固定的刷新率(比如最新的一般在 60Hz), 在两次硬件刷新之间浏览器进行两次重绘是没有意义的只会消耗性能。 浏览器会利用这个间隔 16ms(1000ms/60)适当地对绘制进行节流, 因此 16ms 就成为页面渲染优化的一个关键时间。 尤其在异步渲染中,要利用 流式渲染 就必须考虑到这个渲染帧间隔。

TL;DR

为方便查阅源码和相关资料,本文以 Chromium 的 Blink 引擎为例分析。如下是一些分析结论:

  • 一个渲染帧内 commit 的多次 DOM 改动会被合并渲染;
  • 耗时 JS 会造成丢帧;
  • 渲染帧间隔为 16ms 左右;
  • 避免耗时脚本、交错读写样式以保证流畅的渲染。
继续阅读