查看原文

Meltdown 是 2018 开年遇到的第一个大事件，关于这件事情，我们要做的事情就只有一个：立刻马上升级内核不要停。内核开发者们现在都忙着在给 CPU 擦屎，如果遇到性能下降，be considerate。

查看原文

本文介绍了 Atom 开发者如何提升这款编辑器的性能，相当于 Atom 团队写的一篇 2017 的年终总结。

• Atom 使用 JS 编写，求快求更强大的扩展，但相对的也更容易遇到性能问题。他们使用了 V8 引擎的新特性：custom startup snapshots，它可以让一些 Atom 的启动时间转换到编译时，其中最重要的提升可能是堆中的对象依赖图也能在编译时就构建好。相应的，这项改进引入了一些规约，例如启动时不能搞 DOM 操作，所以他们重构了不少代码。
• 打字延迟不能忍啊。他们的做法是引入跟 React 有点像的库 etch：搞 DOM 操作的时候渲染依然没啥问题。另外，对批量文字变更做优化。
• 用 C++ 写扩展做大文件的缓存加载，数据结构选用 Piece Table。

衍生思考：性能优化万变不离其宗：用空间换时间 …

查看原文

好图表要易于阅读，但貌似很少人考虑过色盲的体验。例如有些人 #FFA800(黄色) 和 #4AC200(绿色) 其实看到的一样的颜色(土黄)。色盲的人口比例不至于低到可以忽视的程度。其中最常见的是红绿色盲。由于这是天生的，我们在开发可视化组件的时候只能想办法绕过一些同色的情况。下面是一些解决办法：

• 调 色调(hue), 饱和度(saturation), 亮度(brightness)
• 用不同的贴皮(texture), 例如柱状图不同的柱子可以用斜线和点加以区别

查看原文

本文列出了学习 Linux 的一些非常有用的资源。

• Linux 发行版的 Wiki: Red Hat Enterprise Linux, CentOS wiki, Arch Wiki, Gentoo Linux Wiki, Ubuntu Wiki, IBM Developer Works, FreeBSD Document & Handbook
• 文档: Bash Hackers Wiki, Bash FAQ, OpenBSD FAQ, Howtoforge, Slackware Book Project, The Linux Documentation Project(TLDP), Catonmat
• 书: Advanced Linux Programming, Linux Sea …

查看原文

本文介绍了软件定义网络(SDN), 网络功能虚拟化(NFV) 相关的网络技术在开源运动的帮助下日渐成熟。基本上能叫得出名字的整个 IT 行业的大公司(google, m$, facebook, amazon, at&t, etc) 都在推这项技术。SDN/NFV 技术有大量的组织参与了标准指定，以及代码实现。这项技术旨在通过软件来定义基础的网络架构。Github 项目 sdnds-tw/awesome-sdn 搜罗了不少有用的资源。

查看原文

git-instaweb 可以让你在本地 Web 浏览器中浏览一个 Git 仓库。假设你已经安装了 webrick (gem install webric, 或者任意其它服务器之一：apache2, lighttpd, mongoose, plackup), 你就可以通过这个命令：git instaweb -d webrick --start 启动 Web 进程。启动成功后，访问 http://localhost:1234 即可看到一个简易的管理系统。

习题：运行上面的命令，看看自己的项目在 Instaweb 中长啥样子。

查看原文

git-bisect 一个用二分法帮你找到 bug 的 git 内置工具。它的基本原理是标记提交日志的两头一边好，一边坏，它帮你跳到正中间的提交，让你来标记是好的还是坏的，如此往复直到找到那个点，这个流程正是二分法。它的使用方法如下：

• git bisect start: 开始
• git bisect bad: 标记当前是引入了 bug 的提交
• git bisect good v0.1.0: 标记 v0.1.0 标签对应的提交还没有引入 bug
  • 这时候 git-bisect 会自动跳转到 v0.1.0 ... HEAD 正中间的那个提交
• git bisect bad: 继续标记，直到找到拐点
• git …

查看原文

Unix 文档使用 Markup 语言编写，并编译为最终的格式。它不同于 WYSIWYG 风格的文档。

• 原因
  • WYSIWYG 风格的编辑器在业界早期不多，大家都用 Markup 语言写文档。
  • 屏幕上看到的其实往往和打印出来的还是有区别，也算是无法解决的硬伤。
  • 再往深了说，GUI 下面藏着的其实还是 Markup 语言标记的文档，但又把这些细节藏起来。
• 早期的 Unix 文档标记其实没有人分得清什么是 展示性的标签，什么是 结构性的标签。区别在于一个搞样式，一个搞内容组织。
• Markup 语言如果提供了宏机制，让你可以封装功能性的需求，那么你就越来越可以专注于内容。

衍生思考：时代在进步， WYSIWYG 编辑器也在不断改良，但它的核心依然是 Markup 语言这个没有改变。大量程序员们写技术文档依然更偏爱 Markup。

查看原文

TAOUP 一书中曾经提到一些 Unix 常用的命令行选项，这篇文章做了一些摘要。a-z 都各有场景，例如 -c=command/check, -d=delete/dir/debug, -e=execute/edit, -f=file/force, -h=help, -o=output, -r=recurse/reverse, -s=silent, -v=verbose, -V=version。

头脑里面有个大概的印象猜测猜测一个命令，可以省去一点点看文档的功夫。另一方面，其实也只能当作投机取巧的手段，最后还得看文档才行。

查看原文

py_compile 是 Python 的一个标准库，它用于编译源代码为 byte-code。粗看起来似乎没什么场景，但其实，总是会有使用场景的：Python 源代码需要转为 pyc 文件被执行，若是终端用户没有文件系统的写权限，酱紫就写不粗来 pyc 文件，也就运行不了代码了。

这个模块最重要的方法是 py_compile.compile(file)，它编译源代码，并输出到 pyc 文件去。例如 /path/to/my_vanilla.py 会被编出 /path/to/__pycache__/my_vanilla.cpython-36.pyc 酱紫的文件。

py_compile.main() 也可直接在命令行被调用：

$ python3 -mpy_compile ./my_vanilla.py
$ ls ./__pycache__.py …