单元测试:从 Jest 到 Karma+Mocha+Chai

我所参与过的 Web 项目大部分都使用 React 框架。Jest 是我们曾经最主要使用的单元测试 (Unit Test) 框架。Jest 配置足够简单,功能也足够丰富。但是随着前端开发逐渐进入深水区,Jest 的短板开始逐渐显现。我在经过探索和尝试后,迁移到了 Karma+Mocha+Chai 的解决方案。在此分享这两种技术方案的区别和取舍,希望对遇到同样问题的同学有所帮助。

继续阅读 →

前端勿学清单

前端技术发展很快,有些技术如常青树,有些则已日渐式微。刚入门前端学习新技术的时候,需要避免在这些陈旧技术上浪费时间。

继续阅读 →

编程英语基础

编程是一门语言艺术。要写出赏心悦目的代码,最重要的便是恰当的命名变量,函数,类和包等。每种编程语言都自己独特的语法和代码风格。比如 C 语言常用 snake_case 命名,而 Java 语言用 camelCase 命名。这篇文章将不去探讨具体语言的特有规范,而是去介绍通用的命名的英语语法,比如变量类型与词性的关系,词组和短语的顺序,省略的用法,近义词的辨析等。示例以 Java/TypeScript 为主。正确示例标记为✔️,错误示例标记为❌。

本文有待完善,欢迎读者意见。

继续阅读 →

position: fix 没用?你大概是被 transform 坑了

在 CSS 里很多位置布局都是相对于容器的。但是 position: fixed; 比较直白,只相对于窗口,通常不会被干扰。但是我最近就遇到了这么个问题:

transform:scale(1);
position:fixed; right:10px; bottom:10px;

这不对呀,我明明写的是 position: fixed; 为啥没用呢?

于是我一个一个翻看父元素的 CSS 布局属性,发现一个 Modal 库有个奇怪的 transform: scale(1); 。这个属性没有任何视觉的效果,显然是动画执行之后留下的。然而在技术实现上,即使是 scale(1)translateX(0) 这种没有任何效果的 transform ,也会重建一个坐标系,导致内部元素的 position:fixed 不再相对于窗口,而是相对于这个 transform 元素。

这是不是某个浏览器实现的缺陷呢?实际测试 Firefox 和 Chrome 都是一样的效果。这也许是一个 Web 标准中比较含糊的灰色区域。

解决方法比较简单粗暴,把 transform: scale(1) 改成 transform: unset 即可。在实践中,尽量避免对比较大的容器使用 transform,比如 Sidebar 和 Modal。如果要用的话,则要确保子元素不会用到 position: fixed,比如一些 Popup。

Web 内嵌字体格式

简而言之,WOFF2 是你唯一需要的字体格式。如果你需要支持 IE11,那么就加上 WOFF 作为备用字体格式。

@font-face {
  font-family: 'Source Code Pro';
  font-weight: 400;
  font-style: normal;
  src: local('Source Code Pro'),
    url('source-code-pro-regular.woff2') format('woff2');
}
继续阅读 →

比较 HTML 和 JavaScript Input 验证

如果你想验证表单输入是否有效,比如你想让输入框只接受整数,而不是小数或文字,在 HTML5 中你可以用以下代码轻松实现:

<input type="number" pattern="[0-9]*" />

但是,用户仍然可以输入无效信息:

  1. 在 Firefox 里,你可以输入任何字符:比如“fsielfs”。
  2. 在 Chrome 里,你可以输入一些无效的数字:比如“1..2.2.2”。
继续阅读 →

Btrfs 断电损坏

强制关机是危险的,至少对于 Btrfs 文件系统来说。

即使如今 Linux 桌面的稳定性已经极大改善,使用滚动发行版或特殊显卡驱动的用户仍然可能会遇到系统卡死的情况。这时候很多人就会直接长按电源键关机。这会导致系统强制断电,而文件系统读写尚未完成(可能是文件系统层面,也可能是存储硬件层面)。

为什么偏偏 Btrfs 会特别敏感呢?

其实 Btrfs 本身并没有特别弱势的地方,但是使用 Btrfs 的发行版,比如 openSUSE,会定期进行 btrfs-balance 和 btrfs-cleaner。这些 Btrfs 维护任务会带来巨大的 CPU 和 IO 负担,让桌面更容易卡死崩溃。假如你正在玩一款特别占用资源的游戏,而这时 btrfs-balance 开始了,系统很可能会被卡死。如果此时强制断电,btrfs-balance 的数据转移就会被中断,从而使文件系统处于异常状态。

再次开机时,则可能会遇到无法挂载分区,无法进入系统,甚至无法启动的情况。通常系统的 /home 分区或子卷读写最频繁,也最容易因为断电而损坏。无法挂载 /home 分区或子卷的表现为:能进入登录界面却无法进入桌面。

这时要怎么做呢?

第一,重启后即使无法进入系统,也请先让机器继续运行。这可以让 SSD 硬件断电保护机制工作,将之前未完成的数据操作恢复,这可能需要几分钟。请尽量等待时间长一些,以确保数据写入已经完全完成。

第二,再次重启。如果第一步有效,那么您应该能够正常进入系统了。您可以多试几次。如果最终仍然不能进入系统,那么您还需要检查和修复 Btrfs 文件系统。

第三,制作救援盘,从救援盘启动。

第四,插入移动硬盘,使用 btrfs restore 将数据恢复出来。这一步是完全安全的,不会更改已有文件系统。接下来的步骤都或多或少有些风险,因此建议您先保留数据。

第五,按照维基上的 Btrfs 修复教程操作。需要注意的是,这些修复方法的风险依次增大。某些情况下,btrfs check --repair /dev/sda1 甚至可能会完全摧毁一个 Btrfs 文件系统。

Code Journey #11

九月亮点:高分屏BUG修复模拟器打包

KDE:

  • Kompare 高分屏渲染支持 [patch]
  • Filelight 高分屏渲染支持 [patch]
  • KSysGuard 系统卫士高分屏渲染支持,传感器折线图尚未支持 [patch]
  • 字体管理器高分屏渲染支持 [patch]
  • 字体管理器的 enablefont 和 disablefont 图标 [patch]
  • KWallet 钱包高分屏渲染支持 [patch]
  • KWin 高分屏渲染支持 [patch]
  • Krita 加载界面高分屏渲染支持 [patch]
  • Kate/KonsolePart 多屏渲染问题 [bug] [patch]
  • Spectale 多屏渲染问题 [bug] [patch]

openSUSE:

  • 更新 python-PyMuPDF 包并修复库链接问题
  • 更新 arcanist 包并提交到 Factory [request]
  • 提交 PCSX2 包到 Factory [request]
  • 更新 retroarch 包使之开箱即用 [request 1] [request 2]
  • 创建 retroarch-assets 包 [request]
  • 创建 retroarch-joypad-autoconfig 包 [request]
  • 创建 libretro-core-info 包 [request]
  • 创建 libretro-database 包 [request]
  • 创建 libretro-mame2000 核心包 [request]
  • 创建 libretro-genesis-plus-gx 核心包 [request]
  • 创建 libretro-flycast 核心包 [request]
  • 创建 libretro-yabause 核心包 [request]

Code Journey #10

KDE:

  • 修复 JuK 每次启动都弹出文件夹设置对话框的 BUG
  • 翻译 TechBase
  • 修复每日一图不更新的 BUG
  • 研究蓝牙耳机自动连接后无法识别的 BUG。确认是 Linux 内核的问题,已经汇报给上游。

openSUSE:

  • 更新维基 FAQ 页面,还在继续
  • Chameleon 主题:新的导航栏的页脚设计,以及暗色模式
  • 更新文档网页主题
  • 更新维基网页主题