chrishyman (Madao)

我听到有人在说：「?????:??」

chrishyman — Tue, 04 Feb 2020 14:59:25 +0800

如果有人问你在 Ruby 中执行 ?????:?? 会得到什么，如果不尝试执行这个命令，你会觉得结果是什么？

答案是你会得到返回值："?"，外加一个 warning。

warning: string literal in condition
=> "?"

事实上拆解来看懂你就会知道了：?? 在 Ruby 中其实等价于 "?", ?如果在一个单字面前他会把对应的符号变成字符串，官方文档描述如下：

?a       #=> "a"
?abc     #=> SyntaxError

https://ruby-doc.org/core-2.3.0/doc/syntax/literals_rdoc.html#top

心细的人可能已经发现了，刚刚我这个 ?????:?? 其实就是一个三元表达式，也可以写作："?" ? "?" : "?"。那么 Ruby Parser 是怎么样知道他应该如何处理这个情况的呢？

直接打开 Ruby 的源码，找到 parse.y 文件，Ruby Parser 的语法定义来自于 parse.y 这个文件。

一般来说我们查找这个 parse 的分析顺序，第一个一定会是去看parser_yylex 方法，因为这个函数做的是分词的动作。找到'?' 这个 case 你就能找到parse_qmark 这个方法，从源码可以看出。

所以可以得知，? 操作符支持单个字符串，也支持 ascii\utf8 以及一些制表符。

另外顺道一说的是，刚刚的警告 string literal in condition 的代码发生处是在 cond0 方法中，另外如果你是用正则作为三元运算符的判断也会发出类似的警告。

文言文編程語言现已支持 Ruby

chrishyman — Fri, 20 Dec 2019 13:19:41 +0800

大家可以用这个语言念诗了（大雾）。

https://github.com/LingDong-/wenyan-lang

[Ruby Summit 2018 话题分享] 模块化的 Rails，微服务以外的另一种选择

chrishyman — Thu, 18 Oct 2018 00:02:52 +0800

拖延症犯了今天才发，这是今年 Ruby Summit 2018 做的一个话题分享，随着主要的技术栈的转移（前端和 Rust），可能以后对于 Rails 架构的分享更多的就会是翻译相关的（TAT 我没有叛逃）。Slides 在这里

主要分享的内容是 Component Based Rails Application，事实上也是一个 13 年就开始出现了的概念。

最早相关的书籍是 Stephan Hagemann 的《CBRA》
现在这本书的新版本亚马逊有售：https://www.amazon.com/... （翻译本问了出版社那边应该是没希望了）.
这次分享的实践点也参考了：@T_Dnzt 的《Modular Rails Application》
另外，Root Car Insurance 这家公司的 Rails 团队最近发布的文章 The Modular Monolith: Rails Architecture 也给了我非常多地启发，他们最新的文章 Separating Data and Code in Rails Architecture 对于实现 stateless code 的概念也是让我眼前一亮。

最终关于我这次分享的 CBRA(Component Based Rails Application)，我最主要想要表达的点，就是可以「疼痛度最低」地简化一个巨大臃肿的单体应用（monolith），并且给未来的拆分做好准备。但另一方面，这次演说没说到的是：组件化的的 Rails 开发，不一定要从业务领域来起步的，他本质还是提供了你一种插件化开发一些特性的选择而已。

说说 Web 无障碍设计

chrishyman — Mon, 13 Aug 2018 10:35:51 +0800

何为无障碍？

好的网站设计是具有人文气息的，不仅仅是视觉的美观，加载渲染速度的快慢。而是使尽可能多的人能够使用 Web 站点，即便他们有或多或少的缺陷。而「无障碍设计」，就是现代 Web 开发中一个值得关注的分支，来让我们开发易访问的内容的网站。它主要体现在以下几点：

让视觉障碍者可以通过「屏幕阅读器」（Screenreaders）得到友善的听觉体验。
设计需要对听力障碍者友好，通过视觉内容能够做出替代。这部分相关的程序事实上仍未得到足够重视，任重道远。
行动障碍者的优化更多的着重于是否能让用户仅用鼠标的寥寥几个按键就能得到有效的操作。
认知障碍者的优化主要体现在风格统一，用户信息展示要明确，业务逻辑要简洁明了等等。

何为 WAI-ARIA?

关于 WAI-ARIA (Web Accessibility Initiative's Accessible Rich Internet Applications 也就是：Web 无障碍倡议 - 无障碍富互联网应用) 具体可以看我翻译的：WAI-ARIA basics。

WAI-ARIA 核心内容有哪些？

1.Signpost and Landmark (路牌与地标)

WAI-ARIA 给浏览器增加了 role 属性，这允许我们给站点中的元素增加我们想要的语义属性。ARIA 的角色属性值可以作为地标 (Landmark) 来复制 HTML5 元素的语义化（例如 nav tag）。甚至超越 HTML5 的语义，给不同的功能块提供路标（Signpost），例如 search, tabgroup, tab, listbox 等等。

用法举例：

如何用 role

打开地址： https://mdn.github.io/learning-area/accessibility/aria/website-aria-roles/

然后使用 VoiceOver 绑定键（你可以在 VoiceOver Utility 中设置） + U 访问，然后使用光标或者键盘来选择菜单选项。由于是结构化的内容，你通过键盘上下就能听到对应的标题内容来跳转需要的内容。你就能看到：

每一块都很分明，做的不好的，Landmarks 直接没有，或者一个页面一个 banner 三个 navigation。

2.aria-label

<input type="search" name="q" placeholder="Search query" aria-label="Search through site content">

这样当你聚焦的时候就会 VoiceOver 会念出'Search through site content'。

3.aria-labelby

<input type="search" name="q" placeholder="Search query" aria-labelby="searchLabel">
<span id='searchLabel'>Search through site content</span>

2.动态内容更新

内容动态更新是对于无障碍是一个很麻烦的事情，因为早年的网站并没有这个困扰，所以 WAI-ARIA 增加一个新的概念：实时区域（live region）。用属性 aria-live 便可以触发实时区域（role="alert" 也可以），它有四个值：

off: 默认值，更新不会提醒。
polite: 只有用户空闲的情况下提醒。
assertive: 尽快提醒。
rude: 会以打断用户操作的方式直接提醒。

通常来说 assertive 设置足以让你的更新在显示时按时序读出，因此，如果改变多次，那么屏幕阅读器也只会念出最后一个改变。

那么就会有一个问题，如果不断增加子元素，那就会不断的出现提示，增加的子元素的内容。

通过添加 aria-atomic="true" 属性告诉屏幕阅读器去读取整个元素的内容作为一个整体来判断是否提示已修改，而不是里头某个子元素增加删除了。例子如下：

<section aria-live="assertive" aria-atomic="true">

以上内容大略的说说了几个重点，至于具体全面的 aria-* 属性/状态，请看 Definitions of States and Properties (all aria-* attributes) ，关于角色，请看Definition of Roles

3.优化键盘的无障碍操作

Tab 和确认键是 HTML 默认实现的无障碍操作，通过对 tabindex 的合理使用（并不是到处乱用），可以让 webpage 的操作体验变得更好，另一方面组合 aria-setsize 和 aria-posinset 能最大化给屏幕阅读器提供信息。 tabindex 文档

4.非语义控件的可访问性

这是现代复杂 Web 应用的最大问题，为了实现复杂需求会大量使用非语义元素来实现一个控件，对于屏幕阅读器而言是灾难，对于使用者而言页面等于不可用。

首先还是离不开角色，如果你想用 a 标签做一个 button。可以，加上role="button" 即可。
熟悉表单验证用的常规状态属性 aria-required/aria-disabled/aria-selected 等属性。
另外理解刚刚说过的 aria-setsize 和 aria-posinset 能最大化给屏幕阅读器提供信息。
aria-hidden="true" 对屏幕阅读器进行一定程度的隐藏。

If You Can't Measure It, You Can't Improve It

彼得•德鲁克（Peter F. Drucker）说过这么一句话，那么我们介绍两款相关的软件用来测量网站对于无障碍的实现程度。

npm install -g the-a11y-machine

a11ym --standards WCAG2AA,HTML https://developer.mozilla.org/

然后打开当前目录下的 ./a11ym_output/index.html ，你可以看到它对于整体的分析结果。然后 note codes 指向的会是每一个 Web 内容无障碍指南（WCAG）的每一个实现细则，你可以就像完成一个个代码风格错误一样逐个根据情况修复它。

Accessibility Developer Tools

这是一款由谷歌可访问性团队开发的谷歌 Chrome Extension。然后操作如图：

顺带一说，Google 的 Audits 功能是基于 Lighthouse 的，关于它可以再写一整篇文章，按下不表。

然后得到的结果会是这样的：

他的评价体系比起 a11ym 不可不谓温和。但是根据它给出的信息，我们还是可以进行对应的优化。

比起发达国家，国内的互联网技术的发展日新月异，但是从大部分的主流网站可以看得出，除开大厂，大家对于无障碍的支持是不够的。但我觉得这仅仅是出于不了解，如果不得而知，那么就无从做起，所以我们更多地提及无障碍技术，推广它，便能让中文互联网世界的无障碍更进一步。

所以像 Leonie Watson 说的：

It doesn't have to be perfect, Just a little bit better that yesterday.

[译] 再见微服务，从 100 多个问题儿童到一个超级明星

chrishyman — Thu, 19 Jul 2018 10:24:46 +0800

本文翻译自 Alexandra Noonan 的 Goodbye Microservices: From 100s of problem children to 1 superstar。
本文的内容是描述 Segment 的架构如何从「单体应用」 -> 「微服务」 -> 「140+ 微服务」 -> 「单体应用」的一个历程。
翻译比较粗糙，如有疏漏，请不吝指教。

注：下文说的目的地就是对应的不同的数据平台（例如 Google Analytics，Optimizely）

除非你生活在石器时代，不然你一定知道「微服务」是当世最流行的架构。我们Segment早在 2015 年就开始实践这一架构。这让我们在一些方面上吃了不少甜头，但很快我们发现：在其他场景，他时不时让我们吃了苦头。

简而言之，微服务是一个面向服务的软件架构，每一个服务端的程序都是朝着一个单一目标构建的（每一个服务会占据较小的面积）。微服务的主要宣传点在于：模块化优化，减少测试负担，更好的功能组成，环境独立，而且开发团队是自治的（因为每一个服务的内部逻辑是自洽且独立的）。而另一头的单体应用：「巨大无比且难以测试，而且服务只能作为一个整理来伸缩（如果你要提高某一个服务的性能，只能把服务器整体提高）」

2017 早期我们陷入了僵局，复杂的微服务树让我们的开发效率骤减，并且每一个开发小组都发现自己每次实现都会陷入巨大的复杂之中，此时，我们的缺陷率也迅速上升。

最终，我们不得不用三个全职工程师来维护每一个微服务系统的正常运行。这次我们意识到改变必须发生了，本文会讲述我们如何后退一步，让团队需要和产品需求完全一致的方法。

为什么微服务可行曾经可行？

Segment 的客户数据基础设施吸收每秒成百上千个事件，将每一个伙伴服务的 API 请求结果一个个返回给对应的服务端的「目的地」。而「目的地」有上百种类别，例如 Google Analytics，Optimizely，或者是一些自定义的 webhook。

几年前，当产品初步发布，当时架构很简单。仅仅是一个接收事件并且转发的消息队列。在这个情况下，事件是由 Web 或移动应用程序生成的 JSON 对象，例子如下：

{
  "type": "identify",
  "traits": {
    "name": "Alex Noonan",
    "email": "anoonan@segment.com",
    "company": "Segment",
    "title": "Software Engineer"
  },
  "userId": "97980cfea0067"
}

事件是从队列中消耗的，客户的设置会决定这个事件将会发送到哪个目的地。这个事件被纷纷发送到每个目的地的 API，这很有用，开发人员只需要将他们的事件发送到一个特定的目的地——也就是 Segment 的 API，而不是你自己实现几十个项目集成。

如果一个请求失败了，有时候我们会稍后重试这个事件。一些失败的重试是安全的，但有些则不。可重试的错误可能会对事件目的地不造成改变，例如：50x 错误，速率限制，请求超时等。不可重试的错误一般是这个请求我们确定永远都不会被目的地接受的。例如：请求包含无效的认证亦或是缺少必要的字段。

此时，一个简单的队列包含了新的事件请求以及若干个重试请求，彼此之间事件的目的地纵横交错，会导致的结果显而易见：队头阻塞。意味着在这个特定的场景下，如果一个目的地变慢了或者挂掉了，重试请求将会充斥这个队列，从而整个请求队列会被拖慢。

想象下我们有一个 目的地 X 遇到一个临时问题导致每一个请求都会超时。这不仅会产生大量尚未到达目的地 X的请求，而且每一个失败的事件将会被送往重试的队列。即便我们的系统会根据负载进行弹性伸缩，但是请求队列深度突然间的增长会超过我们伸缩的能力，结果就是新的时间推送会延迟。发送时间到每一个目的地的时间将会增加因为目的地 X 有一个短暂的停止服务（因为临时问题）。客户依赖于我们的实时性，所以我们无法承受任何程度上的缓慢。

为了解决这个队头阻塞问题，我们团队给每一个目的地都分开实现了一个队列，这种新架构由一个额外的路由器进程组成，该进程接收入站事件并将事件的副本分发给每个选定的目标。现在如果一个目的地有超时问题，那么也仅仅是这个队列会进入阻塞而不会影响整体。这种「微服务风格」的架构分离把目的地彼此分开，当一个目的地老出问题，这种设计就显得很关键了。

个人 Repo 的例子

每一个目的地的 API 的请求格式都不同，需要自定义的代码去转换事件来匹配格式。一个简单的例子：还是目的地X，有一个更新生日的接口，作为请求内容的格式字段为 dob ，API 会对你要求字段为 birthday，那么转换代码就会如下：

const traits = {}
traits.dob = segmentEvent.birthday

许多现代的目的地终点都用了 Segment 的请求格式，所以转换会很简单。但是，这些转换也可能会十分复杂，取决于目的地 API 的结构。

起初，目的地分成几个拆分的服务的时候，所有的代码都会在一个 repo 里。一个巨大的挫折点就是一个测试的失败常常会导致整个项目测试无法跑通。我们可能会为此付出大量的时间只是为了让他像之前一样正常运行通过测试。为了解决这个问题，我们把每一个服务都拆分成一个单独的 repo，所有的目的地的测试错误都只会影响自己，这个过渡十分自然。

拆分出来的 repo 来隔离开每一个目的地会让测试的实现变得更容易，这种隔离允许开发团队快速开发以及维护每一个目的地。

伸缩微服务和 Repo 们

随着时间的偏移，我们加了 50 多个新的目的地，这意味着有 50 个新的 repo。为了减轻开发和维护这些 codebase 的负担，我们创建一个共享的代码库来做实现一些通用的转换和功能，例如 HTTP 请求的处理，不同目的地之间代码实现更具有一致性。

例如：如果我们要一个事件中用户的名字，event.name() 可以是任何一个目的地里头的调用。共享的类库会去尝试判断 event 里的 name 或者 Name 属性，如果没有，他会去查 first name，那么就回去查找 first_name 和 FirstName，往下推：last name 也会做这样的事情。然后吧 first name 和 last name 组合成 full name.

Identify.prototype.name = function() {
  var name = this.proxy('traits.name');
  if (typeof name === 'string') {
    return trim(name)
  }
  var firstName = this.firstName();
  var lastName = this.lastName();
  if (firstName && lastName) {
    return trim(firstName + ' ' + lastName)
  }
}

共享的代码库让我们能快速完成新的目的地的实现，他们之间的相似性带给我们一致性的实现而且维护上也让我们减少了不少头疼的地方。

尽管如此，一个新的问题开始发生并蔓延。共享库代码改变后的测试和部署会影响所有的目的地。这开始让我们需要大量时间精力来维护它。修改或者优化代码库，我们得先测试和部署几十个服务，这其中会带来巨大的风险。时间紧迫的时候，工程师只会在某个特定的目的地去更新特定版本的共享库代码。

紧接着，这些共享库的版本开始在不同的目标代码库中发生分歧。微服务起初带给我们的种种好处，在我们给每一个目的地都做了定制实现后开始反转。最终，所有的微服务都在使用不同版本的共享库——我们本可以用自动化地发布最新的修改。但在此时，不仅仅是开发团队在开发中受阻，我们还在其他方面遇到了微服务的弊端。

这额外的问题就是每一个服务都有一个明确的负载模式。一些服务每天仅处理寥寥几个请求，但有的服务每秒就要处理上千个请求。对于处理事件较少的目的地，当负载出现意外峰值时，运维必须手动伸缩服务以满足需求。

当我们实现了自动伸缩的实现，每个服务都具有所需 CPU 和内存资源的明显混合，这让我们的自动伸缩配置与其说是科学的，不如说更具有艺术性（其实就是蒙的）。

目的地的数量极速增长，团队以每个月三个（目的地）的速度增长着，这意味着更多的 repo，更多的队列，更多的服务。我们的微服务架构的运维成本也是线性地增长着。因此，我们决定退后一步，重新考虑整个流程。

深挖微服务以及队列

这时列表上第一件事就是如何巩固当前超过 140 个服务到一个服务中，管理所有服务的带来的各种成本成了团队巨大的技术债务。运维工程师几乎无眠，因为随时出现的流量峰值必须让工程师随时上线处理。

尽管如此，当时把项目变成单一服务的架构是一个巨大的挑战。要让每一个目的地拥有一个分离的队列，每一个 worker 进程需要检查检查每一队列是否运行，这种给目的地服务增加一层复杂的实现让我们感到了不适。这是我们「离心机」的主要灵感来源，「离心机」将替换我们所有的个体队列，并负责将事件发送到一个单体服务。

译者注：「离心机」其实就是 Segment 制作的一个事件分发系统。相关地址

搬到一个单体 Repo

所以我们开始把所有的目的地代码合并到了一个 repo，这意味着所有的依赖和测试都在一个单一的 repo 里头了，我们知道我们要面对的，会是一团糟。

120 个依赖，我们都提交了一个特定的版本让每一个目的地都兼容。当我们搬完了目的地，我们开始检查每一个对应的代码是否都是用的最新的依赖。我们保证每一个目的地在最新的依赖版本下，都能正确运行。

这些改变中，我们再也不用跟踪依赖的版本了。所有目的地都使用同一版本，这显著地减小了 codebase 的代码复杂度。维护目的地变得快捷而且风险也变小了。

另一方面我们也需要测试能简单快速地运行起来，之前我们得出的结论之一就是：「不去修改共享库文件主要的阻碍就是得把测试都跑一次。」

幸运的是，目的地测试都有着相似的架构。他们都有基础的单元测试来验证我们的自定义转换逻辑是否正确，而且也能验证 HTTP 的返回是否符合我们的期望值。

回想起我们的出新是分离每一个目的地的 codebase 到各自的 repo 并且分离各自测试的问题。尽管如此，现在看来这个想法是一个虚假的优势。HTTP 请求的发送仍然以某种频率失败着。因为目的地分离到各自的 repo，所以大家也没有动力去处理这类失败的请求。这也让我们走进了某种令人沮丧的恶性循环。本应只需几个小时的小改动常常要花上我们几天甚至一周的时间。

构建一个弹性测试套件

给目的地发送的 HTTP 请求失败是我们主要的失败测试原因，过期凭证等无关的问题不应该使测试失败。我们从中也发现一些目的地的请求会比其他目的地慢不少。一些目的地的测试得花上 5 分钟才能跑完，我们的测试套件要花上一小时时间才能全部跑完。

为了解决这个问题，我们制作了一个「Traffic Recorder」，「Traffic Recorder」是一个基于 yakbak 实现的工具，用于记录并且保存一些请求。无论何时一个测试在他第一次跑的时候，对应的请求都会被保存到一个文件里。后来的测试跑的时候，就会复用里头的返回结果。同时这个请求结果也会进入 repo，以便在测试中也是一致的。这样一来，我们的测试就不再依赖于网络 HTTP 请求，为了接下来的单一 repo 铺好了路。

记得第一次整合「Traffic Recorder」后，我们尝试跑一个整体的测试，完成 140+ 目的地的项目整体测试只需几毫秒。这在过去，一个目的地的测试就得花上几分钟，这快得像魔术一般。

为何单体应用可行

只要每个目的地都被整合到一个 repo，那么他就能作为一个单一的服务运行。所有目的地都在一个服务中，开发团队的效率显著提高。我们不因为修改了共享库而部署 140+ 个服务，一个工程师可以一分钟内重新完成部署。

速度是肉眼可见地被提升了，在我们的微服务架构时期，我们做了 32 个共享库的优化。再变成单体之后我们做了 46 个，过去 6 个月的优化甚至多过 2016 年整年。

这个改变也让我们的运维工程师大为受益，每一个目的地都在一个服务中，我们可以很好进行服务的伸缩。巨大的进程池也能轻松地吸收峰值流量，所以我们也不用为小的服务突然出现的流量担惊受怕了。

坏处

尽管改变成单体应用给我们带来巨大的好处，尽管如此，以下是坏处：

故障隔离很难，所有东西都在一个单体应用运行的时候，如果一个目的地的 bug 导致了服务的崩溃，那么这个目的地会让所有的其他的目的地一起崩溃（因为是一个服务）。我们有全面的自动化测试，但是测试只能帮你一部分。我们现在在研究一种更加鲁棒的方法，来让一个服务的崩溃不会影响整个单体应用。
内存缓存的效果变低效了。之前一个服务对应一个目的地，我们的低流量目的地只有少量的进程，这意味着他的内存缓存可以让很多的数据都在热缓存中。现在缓存都分散给了 3000+ 个进程所以缓存命中率大大降低。最后，我们也只能在运维优化的前提下接受了这一结果。
更新共享库代码的版本可能会让几个目的地崩溃。当把项目整合的到一起的时候，我们解决过之前的依赖问题，这意味着每个目的地都能用最新版本的共享库代码。但是接下来的共享库代码更新意味着我们可能还需要修改一些目的地的代码。在我们看来这个还是值得的，因为自动化测试环节的优化，我们可以更快的发现新的依赖版本的问题。

结论

我们起初的微服务架构是符合当时的情况的，也解决了当时的性能问题还有目的地之间孤立实现。尽管如此，我们没有准备好服务激增的改变准备。当需要批量更新时，我们缺乏适当的工具来测试和部署微服务。结果就是，我们的研发效率因此出现了滑坡。

转向单体结构使我们能够摆脱运维问题，同时显着提高开发人员的工作效率。我们并没有轻易地进行这种转变，直到确信它能够发挥作用。

我们需要靠谱的测试套件来让所有东西都放到一个 repo。没有它，我们可能最终还是又把它拆分出去。频繁的失败测试在过去损害了我们的生产力，我们不希望再次发生这种情况。
我们接受一些单体架构的固有的坏处而且确保我们能最后得到一个好的结果。我们对这个牺牲是感到满意的。

在单体应用和微服务之间做决定的时候，有些不同的因素是我们考虑的。在我们基础设施的某些部分，微服务运行得很好。但我们的服务器端，这种架构也是真实地伤害了生产力和性能的完美示例。但到头来，我们最终的解决方案是单体应用。

博客地址

安利一个活动 Ludum dare，顺便记一下这次参加 GameJam 的经历

chrishyman — Tue, 24 Apr 2018 16:49:00 +0800

我的 LD 41 刚刚结束啦！这里给大家分享一下这一次开发竞赛的记录。

先介绍下 LD，也就是 Ludum Dare, Ludum Dare 是一个经常性以推进个人游戏开发为目的的开发竞赛。参与者需要在 48 小时内针对所设定的主题创作游戏。Ludum Dare 是 Geoff Howland 一手建立的，第一次举办在 2002 年 4 月。

我参加的这一届已经是第 41 届了，早上 9 点，LD 这边就统一公布主题。

这次的主题是Combine 2 Incompatible Genres（合并两种不相容的【游戏】类型）。

在我毫无头绪的时候，已经有好事者做了这个东西 https://boltkey.cz/ld41roller/。一个随机的两个主题组合生成器。生了几次我看到了一个心水的主题。

可编程的游戏+roguelike，主题定了，接下来就是磨素材和故事大纲了。#还剩下 1 天 23 小时。

我参加的类型是 compo ,LD 有两种参赛类型，一种是 Compo，要求单人作战，48 小时，最终要提交源代码。另一种是 Jam 允许团队参赛、不提供代码，并将时间延长至 72 小时。

时间还早，就去做家务做做饭，顺便构思下游戏的思路以及要准备的素材了。#还剩下 1 天 20 小时。

开始憋素材，素材的绘制都是用的 Aseprite。

中间做饭，打打游戏，磨磨蹭蹭，晚饭后开始实现游戏逻辑。（还剩下 36 小时

这次使用的开发框架是 Phaser，由于之前从未用过，花了一些时间看了文档。（还剩下 35 小时

把需要实现的类都写一下，然后就去玩游戏了。（还剩下 34 小时

睡觉。

第二天开始热火朝天地实现大部分的内容，开始构思道具和玩什么梗（尽管由于实现的太糙看不太出来。

实现各个类的内容，调整地图。（还有 12 小时

想到第二天还得 9 点去洗牙，所以预估好 8 点提交游戏。于是乎 10 点就睡觉，周一早上 5 点起来再战。（还有 10 小时

早上 8 点，这款可编程的死循环模拟器就做完了。提交 LD，出门去看牙医。

最后贴上我这个充满 BUG 的可编程死循环 roguelike 模拟器的地址： https://ldjam.com/events/ludum-dare/41/need-for-sleep

如何教会小明实现 Rails 的 Validation

chrishyman — Tue, 20 Mar 2018 17:44:35 +0800

本主题来源于公司内部每周分享，我们正在招聘 Ruby 工程师和架构师欢迎查看我们的招聘信息 https://ruby-china.org/topics/35085 或直接投递简历到 likai@uniqueway.com

前言：直接写一份教程实现未免生涩，所以我尝试用 8bit 漫画的方式写一个教程，渣画技，试试水。

图多不看党可以直接看 github 地址

数学家波利亚说过：「观察未知量！并尽量想出一道你所熟悉的具有相同未知量或者相似题目未知量的题目。」

我们先要尝试归纳出我们需要的或者说已知的内容——「一个 ActiveModel Validator 能实现什么和做到什么？」

可以通过 validates 类方法来验证需要验证的字段
具有 Valid? 方法，可以返回布尔值

课后笔记

这里我们实现了一个最基本的 Validation。
事实上 Rails 的 Validation 更加强大，vaild? 方法执行后会更新执行对象的 errors 变量；options 另外还有类似 on: :create 这类的限制选项；除开 valid? 还有 invalid? 和 validate! （该方法会抛出异常）方法。
Rails 的 Validation 支持 custom Validator (其实就是少了 validates_with 的实现)

练习题：

如何实现 Custom Validator 呢？

五分钟玩一下 Headless Chrome

chrishyman — Thu, 17 Aug 2017 11:44:19 +0800

是什么让前端工程师狂欢，让 PhantomJS 维护者宣告失业，是大企业的良心泯灭，还是 chrome 59 之后的一个新坑？

—— 让我们走进 Headless Chrome。

一、浅尝辄止

让我们先感受下这个东西：

Chrome 的应用程序路径 /Contents/MacOS/Google\ Chrome --headless --remote-debugging-port=8888 http://baidu.com/

remote-debugging-port 是你的绑定端口号
后面这个 baidu 是你要直接生成解析的地址（另外你还有很多体位可以玩弄，例如 --dump-dom【解析 dome】， --print-to-pdf【生成 pdf】， --screenshot【截图】, --remote-debugging-port 和上述功能不兼容，记得去掉。）

二、试

首先我们需要安装 puppeteer (Chrome 提供的一个 Headless API 封装库，安装前请确保自己 Node 的版本在 7.10 以上)

puppeteer 的安装体积会比较大，因为他会下载一个 chrome 内核进来。


const puppeteer = require('puppeteer');

(async() => {
    const browser = await puppeteer.launch();
    const page = await browser.newPage();
    await page.goto('https://google.com');
    await page.screenshot({path: 'google.png'});
    browser.close();
})();

这样就是一个创建截图的例子。

三、悟

官方背景加上非常勤的 API Update，以后服务端解析确实是没 PhantomJS 啥事了。而且 Headless 的 API 支持大量的 Event 操作，以后前端测试的未来就是它了。

每个 Ruby 开发者都需要知道的 5 个 Pry 技巧

chrishyman — Fri, 26 May 2017 12:36:28 +0800

觉得有点意思，就从5 Pry Features Every Ruby Developer Should Know 搬运过来了。

大部分时候，我们都把 Pry 作为一个断点工具来对 Ruby 代码进行调试。但它不仅仅是一个断点工具，他同时也能给我们带来极好的代码交互。接下来我们从两个层面来说说来说说 5 个你需要知道 pry 技巧。

探索可用方法

Pry 提供了一个 ls 方法，让我们可以获取当前 scope 里所有可用的变量和方法，如果觉得出现的内容太多了，是因为他会从多个层级得到对应的方法和变量。

于是我们可以ls --locals 这样就可以只获得当前 scope 的变量和方法。

丢掉文档

Pry 让命名空间下的搜索变得极其容易，例如我们要找一个 Nokogiri 处理 xpaths 的函数，我们只需： find-method xpath Nokogiri，结果如下：

> find-method xpath Nokogiri
Nokogiri::CSS.xpath_for
Nokogiri::CSS::Node
Nokogiri::CSS::Node#to_xpath
Nokogiri::CSS::Parser
....

如果我们需要下列函数具体的信息，我们只需 stat Nokogiri::CSS.xpath_for

> stat Nokogiri::CSS.xpath_for
Method Information:
--
Name: xpath_for
Alias: None.
Owner: #<Class:Nokogiri::CSS>
Visibility: public
Type: Bound
Arity: -2
Method Signature: xpath_for(selector, options=?)
Source Location: /.rvm/gems/ruby-2.3.3/gems/nokogiri-1.7.0.1/lib/nokogiri/css.rb:22

所有内容一览无余，但还不够，我们还能 show-source Nokogiri::CSS.xpath_for

> show-source Nokogiri::CSS.xpath_for
From: /.rvm/gems/ruby-2.3.3/gems/nokogiri-1.7.0.1/lib/nokogiri/css.rb:22

Owner: #<Class:Nokogiri::CSS>
Visibility: public
Number of lines: 3

def xpath_for selector, options={}
  Parser.new(options[:ns] || {}).xpath_for selector, options
end

如果你还是要看文档，Pry 连 show-doc 也提供了。

这些技巧能更好地让我们每日的开发中得到更多的信息，更好地 Debug 代码。一会就去试一下吧！

Rails 缓存，你应该知道的几件事

chrishyman — Sun, 12 Mar 2017 17:29:58 +0800

Page Caching

首先 Page Caching 在 Rails 4 已经被移除作为 Gem actionpack-page_caching 存在了。因为 DHH 在后来要推行他的 key-based cache 实践，事实证明这样的做法更灵活更好。

回到 actionpack-page_caching 的讨论中

1. 原理：

把对应需要缓存的 action 内容，在 public 文件夹中缓存一份地址对应的 html 文件，让 nginx 直接访问这个 html 文件，那 Rails Application 就不会参与任何的处理。

2. 核心代码 (有删减)：

步兵地址

# action_controller/page_caching.rb
ActionController::Base.send(:include, ActionController::Caching::Pages)

# action_controller/caching/pages.rb
module ActionController
  module Caching
    module Pages
      extend ActiveSupport::Concern
      module ClassMethods
        def caches_page(*actions)
          options = actions.extract_options!
          after_filter({only: actions}.merge(options)) do |c|
            c.cache_page(nil, nil, gzip_level)
          end
        end
      end
    end
  end
end

# controller instance method
def cache_page(content = nil, options = nil, gzip = Zlib::BEST_COMPRESSION)
  if (type = Mime::LOOKUP[self.content_type]) && (type_symbol = type.symbol).present?
    extension = ".#{type_symbol}"
  end
  self.class.cache_page(content || response.body, path, extension, gzip)
end

3. 解说：

首先 action_controller/page_caching.rb 让所有的 Controller 都 include ActionController::Caching::Pages 这个 Module。然后在 caches_pages 被声明的 action 就会走一个 after_filter 执行 cache_page 这一个实例方法最后得到 response.body，写进 public 里头的对应目录文件里，下次访问这个路由 Nginx 会直接访问这个文件，应用服务器将不参与任何处理。

4. 优缺点

优点：快，适合变化频率低的数据。

缺点：缓存失效的策略只有一个：手动 expire_page。所以 2012 年就被 DHH 逐出 Rails 4 的核心代码。

Action Caching

Action Caching 也在 Rails 4 中移除作为 Gem actionpack-action_caching 存在了。

1. 原理：

乍一看以为 Action Caching 对比 Page Caching 是新瓶装旧药，但是两者的缓存上的策略和思路是不同的。Action Caching 实现了一个 around_action 的方法，由于是走方法的，所以可以提供「unless」的保存规则。

2. 核心代码 (有删减)：

步兵地址

module ClassMethods
  def caches_action(*actions)
    return unless cache_configured?
    # cache_options 来源有删减
    around_action ActionCacheFilter.new(cache_options), filter_options
  end
end
protected
class ActionCacheFilter
  # before_around 将会执行的部分
  def around(controller)
    cache_layout = expand_option(controller, @cache_layout)
    path_options = expand_option(controller, @cache_path)
    cache_path = ActionCachePath.new(controller, path_options || {})
    body = controller.read_fragment(cache_path.path, @store_options)
    unless body
      controller.action_has_layout = false unless cache_layout
      yield
      controller.action_has_layout = true
      body = controller._save_fragment(cache_path.path, @store_options)
    end
    body = render_to_string(controller, body) unless cache_layout
    controller.response_body = body
    controller.content_type = Mime[cache_path.extension || :html]
  end

3. 解说：

用 around_action 来实现是否进入 action 原有的逻辑代码还是直接访问缓存文件，这一点算是 Page Caching 的强化版本。

如果有缓存，将会直接从 read_fragment 中读取内容，然后直接作为 response_body 返回，如果不，就执行 yield 中代码（本身 action 的代码），然后_save_fragment。

4. 优缺点

和 Page Caching 不同，他最终的缓存访问这个行为会走进 Rails App 的 action 里，所以这个是缺点（不是直接访问文件），也是优点（不会无脑访问文件）。

但是这种在 action 层面上的缓存还是太不自由了，基本上是同时被逐出 Rails 4。

Fragment Caching

前面两位被弃用的主要原因，就是现在 view 方面的需求太复杂了，一步到位的缓存是不存在的。

于是我们就有了在 view 层面上碎片化的 Key-base 缓存方案：Fragment Caching。

1. 原理：

在 View 中用的 cache 方法来自 ActionView::Helpers::CacheHelper，例子如下：如果我们在 View 中写下如下代码

<% cache @article do %>
  <%= @article.title %>
  <%= @article.content %>
<% end %>

_ 我们会往我们的缓存抽象层（cache_store）保存如下地址的 key，内容当然是我们的渲染内容。

views/articles/2-20160829091941000000000/6b45efaa1f600a3b9dffe061fb38ad68
     ^类名     ^article 的 id-updated_at  ^ActionView::Digestor 的digest 方法生成的特征码

值得一说的是，这个虽然是 ActionView 的方法，但是 read_fragment 和 write_fragment 都是 ActionController::Base 提供的。

2. 核心代码 (有删减)：

步兵地址

def cache(name = {}, options = nil, &block)
  # 略了若干判断，以及TextHelper 的 safe_concat 方法
  # cache_fragment_name(name, options) 就是我们的存储key 来源的方法 TL;DR
  fragment_for(cache_fragment_name(name, options), options, &block)
end

def fragment_for(name = {}, options = nil, &block)
  read_fragment_for(name, options) || write_fragment_for(name, options, &block)
end

def read_fragment_for(name, options)
  controller.read_fragment(name, options)
end

def write_fragment_for(name, options)
  pos = output_buffer.length
  yield
  output_safe = output_buffer.html_safe?
  fragment = output_buffer.slice!(pos..-1)
  if output_safe
    self.output_buffer = output_buffer.class.new(output_buffer)
  end
  controller.write_fragment(name, fragment, options)
end

关于 ActionController 如何读写保存碎片的部分，步兵地址摸我。

3. 解说：

事实上从 Key 的内容我们就可以知道，这个以 action + model base attribute + 自定义字符串的玩法，对于现在的 Rails 项目来说再好不过了。更加碎片自定义的信息，更高而且准确的缓存命中，但是坏处非常非常明显，下一部分说。

4. 优缺点：

缓存从一开始就带着开发者对于它可能会发生的「不失效」有着巨大的忧虑。用了 Fragment Caching，在我们不增加其他代码的前提下，意味着我们把缓存的是否失效留给了 updated_at 这个时间戳。在最简单原始的场景下，这倒是万能解决方案。

——直到我们用上了「俄罗斯套娃」缓存，那我们接下来就不得不可能在父子层级的 model 之间加恼人的 touch，然后继续期望缓存会在适当的时候乖乖失效。

SQL Caching

施工中，不日更新

用图片和 Ruby 来说 LCS 问题

chrishyman — Tue, 07 Mar 2017 09:10:43 +0800

当我们在一个 10000 多行的文件里头修改了 20 行代码，然后我们输入一行 git diff 去和某一个分支比较，到底用了什么方法来保证不会因为这一个 diff 让电脑卡死呢？

因为大部分的 diff，本质上就是以行为单位的 LCS。

Longest Common Subsequences（最长公共子序列）

在这里我们只讨论序列长度确定的情况下的解法。

LSD 问题例子：有 OPABIZCA 和 OPIABZCD 则 OPABZ 为这两组字符串的最长公共子串。

PS: 连续字符串不是必要条件，只要字符出现顺序相同即可。

如果我们的解法是暴力求解，然后和另一个字符串做匹配，复杂度就会是 O(KL^2)

如果我们构建矩阵来存储动态规划过程中子问题的解，则复杂度就会大大优化。

话不多说，上代码来解说。

x = ["b", "d", "a", "c", "z", "b", "d"]
y = ["b", "d", "b", "c", "b", "x", "d", "a"]
#在这一步已知结果应该是 bdcbd 让我们往下反推

5.times {|char| y << chars[rand(26)]}
c = Array.new(x.size + 1){Array.new(y.size + 1, 0)}
b = Array.new(x.size + 1){Array.new(y.size + 1, 0)}

def LCS_length(x, y, c, b)
  (1..x.size).each do |i|
    (1..y.size).each do |j|
      if x[i - 1] == y[j - 1]
        # 如果相等，把c 数组的i,j 位置设置为斜上方的值 + 1
        # b 数组的对应位置为 0
        c[i][j] = c[i - 1][j - 1] + 1
        b[i][j] = 0
      else
        if c[i - 1][j] >= c[i][j - 1]
          # 如果不相等而且前一个数更大，那么说明前面正在维护一个子串(有匹配的部分)
          c[i][j] = c[i - 1][j]
          b[i][j] = 1
        else
          # 如果没有，说明x字符串在这个坐标前部分没有匹配的必要
          c[i][j] = c[i][j - 1]
          b[i][j] = 2
        end
      end
    end
  end
end
def Print_LCS(x, b, i, j)
  return if i == 0 || j == 0
  if b[i][j] == 0
    Print_LCS(x, b, i - 1, j - 1)
    printf("%c ", x[i - 1])
  elsif(b[i][j] == 1)
    Print_LCS(x, b, i - 1, j)
  else
    Print_LCS(x, b, i, j - 1)
  end
end



LCS_length(x, y, c, b)

构建完之后得到两个矩阵 c,b

# 最后执行递归函数从后往前比较矩阵来获得我们需要的字符串
Print_LCS(x, b, x.size, y.size)

本文的无码版 https://gist.github.com/Madao-3/caa6bc78d7876fd1917b69b3b0aad007
推荐一个 gem 包 https://github.com/halostatue/diff-lcs
JGit 的 Diff 的实现代码 https://github.com/eclipse/jgit/blob/ebfd62433a58d23af221adfdffed56d9274f4268/org.eclipse.jgit/src/org/eclipse/jgit/diff/HistogramDiff.java

思考题：事实上，React 最值得称道的优点之一，就是他的 Virtual DOM Diff 优化，请问：「它做了哪些优化？」

讨论一下，大家是如何存储时间范围的？

chrishyman — Thu, 18 Sep 2014 14:31:51 +0800

例如一月四号到五月一号。

这样的存储有两个字段存储以外的方法吗？

如何得到某个一个最多的多对多的子类？

chrishyman — Mon, 11 Aug 2014 00:35:32 +0800

标题说的太模糊了，举个例子，我有一个 Post Model 里头有一个 Author Model，关系是多对多的。

如果我要做一个排列，来排列出创作最多 Post 的 Author。有什么比较好的方法？

chrishyman (Madao)

我听到有人在说：「?????:??」

文言文編程語言 现已支持 Ruby

[Ruby Summit 2018 话题分享] 模块化的 Rails，微服务以外的另一种选择

说说 Web 无障碍设计

何为无障碍？

何为 WAI-ARIA?

WAI-ARIA 核心内容有哪些？

1.Signpost and Landmark (路牌与地标)

用法举例：

如何用 role

2.aria-label

3.aria-labelby

2.动态内容更新

3.优化键盘的无障碍操作

4.非语义控件的可访问性

If You Can't Measure It, You Can't Improve It

The A11y Machine

Accessibility Developer Tools

[译] 再见微服务，从 100 多个问题儿童到一个超级明星

为什么微服务可行曾经可行？

个人 Repo 的例子

伸缩微服务和 Repo 们

深挖微服务以及队列

搬到一个单体 Repo

构建一个弹性测试套件

为何单体应用可行

坏处

结论

安利一个活动 Ludum dare，顺便记一下这次参加 GameJam 的经历

如何教会小明实现 Rails 的 Validation

课后笔记

练习题：

五分钟玩一下 Headless Chrome

每个 Ruby 开发者都需要知道的 5 个 Pry 技巧

Rails 缓存，你应该知道的几件事

Page Caching

1. 原理：

2. 核心代码 (有删减)：

3. 解说：

4. 优缺点

Action Caching

1. 原理：

2. 核心代码 (有删减)：

3. 解说：

4. 优缺点

Fragment Caching

1. 原理：

2. 核心代码 (有删减)：

3. 解说：

4. 优缺点：

SQL Caching

施工中，不日更新

用图片和 Ruby 来说 LCS 问题

讨论一下，大家是如何存储时间范围的？

如何得到某个一个最多的多对多的子类？

文言文編程語言现已支持 Ruby