Web/Game/Programming/Life etc.
在开发动森二维码生成器的时候，对于服装类设计的生成，一开始我并没有很好的想法。游戏中对贴图的是分块绘制的，并且有一个动态模型可以展示衣服绘制的效果。对比同类工具 Animal Crossing Pattern Tool（下称 ACPT），他们也提供了 3D 模型用于展示贴图效果。但要如何在 Aseprite 中实现展示 3D 模型，我并不是很有把握，毕竟这是一款用于绘制 2D 像素图的工具。另外如何给贴图分块，也需要深入分析。本文先记录一下贴图的划分，之后再写一篇分析 3D 模型的渲染。
最近翻到一本不错的像素书：由 Nostarch Press 出版的 Make Your Own Pixel Art。Nostrach Press 专门出版极客类的书籍，里面有很多看到标题就有兴趣读下去的书，非常适合我。
而这本 Make Your Own Pixel Art 的作者 Janeifer 拥有 30 年的像素画经验，在书中非常系统地讲解了像素画入门的各个方面，还提供了不错的练习素材。并且书中使用的编辑器正是我非常喜欢的 Aseprite。正好最近时间比较多，就又拿起来画板和鼠标瞎画点东西。
而更让我惊喜的是，这款买了很久的小而专业的像素绘画软件，居然支持自己编写插件。从 Aseprite v1.2.10-beta2 版本开始，作者引入了 Lua 语言来扩展编辑器，允许用户编写一些定制化的功能。
于是我开始琢磨着用它做点什么。正好最近在玩动物森友会，游戏里允许玩家自己创做像素风格的图案用来装饰各种物品、衣服、地面。另外，新版的 Animal Crossing: New Horizons 可以通过手机 App 扫描早期版本的 Animal Crossing: New Leaf （下称 ACNL） 玩家绘制的图案的二维码，导入这些现存的图案。
但要知道，不像 3DS 上的 ACNL 可以使用双屏 + 画笔来做画。在 Nintendo Switch 上使用手柄做画有多难受，可想而知。虽然基础画板只有 32 x 32 像素，但是切换颜色、工具等操作，实再不如在电脑上作画来得舒服。我想，如果能直接在 Aseprite 这种专业软件中作画，然后直接生成二维码，再传送到游戏里使用，岂不是非常方便。
这两个月受到疫情影响，从四月中开始在家办公，四月底开始降薪，并且到五月初的这两个多星期进入了做三休四的节奏，每周强制休二天年假，不知何时是头。
由于在家工作，有更多的时间做自己想做的事。为了给自己减压，于是入了动物之森 Switch 版开始捡树枝。玩了几个星期发现其实自己并不是很喜欢联机，硬是把一个休闲社交游戏玩成了单机游戏。
不过动森的探索性还是挺强的，光是收集小动物就可以折腾很久。而且游戏时间与现实同步，每过一个月就会有新的物种出现。有时候需要查一下攻略才知道最近新出了啥动物。
在网上浏览这些攻略的时候就想，为啥大家都把数据做成表格的形式，非常不直观，不如做成像游戏中的图鉴，还可以加上自己的改进。例如其它网站上对鱼的影子的描述，只是用文字写着 “Smallest (1)”、“Small (2)”…“Latest (6)” 这样让人摸不着头脑的表述。
公司最近上线了一个主要由我负责的 React 项目。Frontend Team Lead 希望把 Graphql 请求由 POST 方式改成 GET 方式，这样就可以借助 CDN 进行缓存。
由于项目中使用的是 Apollo Client，于是只需要简单地对 ApolloHttpLink 加上一条配置即可：
const client = new ApolloClient({
link: ApolloLink.from([
// ...
createHttpLink({
// ...
useGETForQueries: true,
}),
]),
cache: new InMemoryCache(),
});
export default client;不过我检查了一下项目中的一些 query 定义。有些 query 还是挺大的，其中最长的那个请求有 2288 个字符。我印象中 Internet Explorer 似乎有最长 URL 限制，于是下载了个微软官网的 IE11 虚拟机，随手做了一下测试。
书接上回，续 JetBrains Quest S1E2 之后，3月13日 JetBrains Quest 发布了本次最后一个挑战。因为感冒的原因，休息了一天，在周六深夜才发现题目已经出来了，又精神了起来。迷面如下：
Last Quest #JetBrainsQuest ⚔
SGF2ZSB5b3Ugc2VlbiB0aGUgcG9zdCBvbiBvdXIgSW5zdGFncmFtIGFjY291bnQ/书接上回，续 JetBrains Quest S1E1 之后，@JetBrains 发布了挑战第二弹。废话少说，来看迷面：
Time for the next #JetBrainsQuest!
.spleh A+lrtC/dmC .thgis fo tuo si ti semitemos ,etihw si txet nehw sa drah kooL .tseretni wohs dluohs uoy ecalp a si ,dessecorp si xat hctuD erehw esac ehT .sedih tseuq fo txen eht erehw si ,deificeps era segaugnal cificeps-niamod tcudorp ehT换工作后，新的公司没有提供 Jetbrains IDE 的包年订阅。在这四个多月里，秉承入乡随俗的习惯，我跟新团队一起用 Visual Studio Code 进行项目开发。一开始非常不顺手，后来安装了各种插件并慢慢适应，勉强还能工作。虽然 VSC 也是可以将就的，但就是没有 Webstorm/Phpstorm[1] 来得爽。
Jetbrains 的 IDE 功能强大，就连内置的版本控制都比其它独立的 App 要强大得多。为了配合 VSC，我还得挑选其它的 Git 客户端来协作，先后用了 Source Tree，Git Kraken 和 Fork。
折腾了一圈，到最后还打算自费回到 JetBrains IDE 的怀抱。
来得早不如来得巧，3月9日，@JetBrains 发布了第一个挑战信，内容如下：
JetBrains Quest begins… #JetBrainsQuest
48 61 76 65 20 79 6f 75 20 73 65 65 6e 20 74 68 65 20 73 6f 75 72 63 65 20 63 6f 64 65 20 6f 66 20 74 68 65 20 4a 65 74 42 72 61 69 6e 73 20 77 65 62 73 69 74 65 3f作为解迷爱好者，一下就精神起来了。
最近工作中需要来回在几个项目间切换，即使是使用支持多标签的终端感觉也有点不够用。于是开始寻找新的解决方案。最后遇到了 tmux 感觉有点相见恨晚。
Tmux 是一个虚拟终端管理工具，或者叫终端复用器（Terminal Multiplexer）。它支持同屏多面板（Panel）、多窗口（Window）、多会话（Session），还能够后台挂起、恢复。这些抽象概念都是为了帮助你快速地从中断状态回到工作状态。
终端复用这个概念我之前有接触过。最早的时候使用过的一款叫 GNU Screen 的工具。当你远程登陆到服务器上的时候，由于各种原因断开连接，再重联到服务器，之前在终端运行的各种脚本就不见了，正在运行的程序也会被终止。而 Screen 相当于在服务端运行一个守护进程（Daemon），当你挂起当前终端的时候，它并没有被真的关掉，而是原地待命，直到你再次接入，先前的终端就像没有被动过一样。
而 Tmux 不仅延续了这些基本理念，还发展出了一套非常高级的终端管理方案。此外开源社区还提供了大量优秀的插件给大家自定义。本文简单记录一下我的 Tmux 使用过程。
去年五月份制作这个主题的时候，特别研究了一下博客字体的选型，当时想写个博客记录一下，但是因为曦仔出生后比较忙就忘了。
如今 JetBrains Mono 发布后有一段时间了，在 IDE 中使用了几个星期，感觉非常好。于是想把它放到博客上用，也趁机把这篇博客整理出来。
如果是纯英文博客的话，选字体的事情比较好办，因为直接引入 Web Fonts 的成本非常低（文件小），而且现在 Web Fonts 的兼容性很好，基本上所有主流浏览器都支持。于是只要选择几款好看的 Web Fonts 就能保证各个平台所用的字体的一致性。
但是对于中文博客来说，使用 Web Font 的使用成本太高了。由于中文的复杂性，每个汉字都有专门的字形，而非像拉丁文一样由一些基本字母符号组成单词，这就导致中文字体文件非常之大。所以中文 Web Font 很难流行起来。
于是，中文博客的字体选型最安全的作法，就是从各平台的系统字体中选择可以用的方案。不过对于博客中的代码片段，我们仍然可以选择喜欢的专用字体。
最近在做的新项目是使用 React 构建一个新的网站，实现新的需求的同时慢慢将旧网站迁移过来。其中的一部分工作是建立一个可重用的前端组件库。
实现一个前端组件库需要非常多的工作量，这里有一份详细的 Checklist 可供参考。除此之外，我们还需要为这些可重用组件建立一份文档，这样大家就可以照着文档去使用这些组件了。在对比了一些文档工具后，我选择了 Storybook 这款非常小清新的可视化组件文档生成器。它支持各种主流框架。
集成 Storybook 到项目的过程遇到了不少坑，不过这篇博客我们暂时不讨论这些，有空的话我再另开一篇文章吧。本文我想聊聊写文档的时候遇到的一些需求。
在项目中我们使用了一款自制的图标字体（Icon Font），以字体的形式将网站常用的图标打包成 Web Font，然后再在页面中使用。
从设计师同事那获得的素材文件如下：
~/Downloads/racing20_march
├── fonts
│ ├── racing20.eot
│ ├── racing20.svg
│ ├── racing20.ttf
│ └── racing20.woff
├── icons-reference.html
└── styles.css其中 icons-reference.html 是说明文档，内里介绍了如何使用这个字体，以及一个图标名称及对应字符的映射关系。
所谓映射（Mapping），可以从 styles.css 中看到一些例子：
.icon-article:before {
content: "\61";
}
.icon-calendar:before {
content: "\64";
}
...即 article 图标对应的字符是 \61 即字母 a。
不过使用的时候我们并不需要关心这个映射。只要知道想用这个图标的话，引用对应的英文名即可：
<i class="icon icon-article"></i>我们要做的正是将这个说明文档中的映射关系集成到我们的 Storybook 组件文档中去。以便在文档中显示所有图标，还可以直接点击图标复制组件代码，方便引用。
一个简单的方法就是手动创建这个列表，把映射关系整理到一个数组中。但是考虑到后期的维护，如新增图标或者映射有变化，就需要重新校对这个列表，是一件很麻烦的事。
既然如此，何不一开始就将其自动化？我们只需要写一个脚本将这个 styles.css 中的映射关系提取出来，就可以为我所用。另外这个 styles.css 作为唯一数据源，更新起来也很方便，直接将设计师提供的新文件覆盖旧文件即可。符合 Single Source of Truth 原则。