Attack on Life ⚔️

个人博客当前使用的搜索服务是Swiftype，但有一定试用期，到期后402报错。而local search的体验很差，于是我切换到使用algolia。发现这么个服务配置，网上说法不一，多少还是踩了点坑的，这里简单Mark下。

当前博客主题版本

• hexo - v3.9.0
• hexo-theme-next - v7.2.0

注意：版本不同，配置确实可能存在出入

algolia站点服务注册

最近思考如何在Alfred中实现印象笔记的检索功能，好在社区中已经有好人实现了一版，但其支持的是Alfred3及Evernote，所以需要进行下改进。当然如果功能有不满意的，还需定制自行改进下，不过问题不大，开搞。

当前效果

下载地址：戳这里

想知道如何做到的，继续看。

最近在刷题，发现很多公众号为了保护个人知识版权，都是用图片来发题，这样在测试时，每次都需要从零手写，这样就很浪费时间。于是考虑搞个截图识字来节约时间。

OCR服务-百度

OCR服务商还是挺多的，谷歌，腾讯，百度等。因为百度的SDK支持NodeJS，而腾讯不行，谷歌毕竟在墙外，可靠性弱一些。所以选择百度。

个人不喜欢百度，但是毕竟OCR服务有限量免费，不用白不用。

Workflow实现

现象

分析

WEB用到了自定义字体，DOM解析渲染时，字体还未加载完全，立即使用缺省字体显示，字体加载完成后，重新渲染替换

手段

经常需要登陆公司VPN，一直使用脚本登陆，但还是不够高效，于是为了节约时间，利用Alfred来实现一键VPN

workflow

workflow中的关键点有以下几步

1. keyword获取用户输入的手机验证码
2. 临时存储keyword到变量中，原因是还需要用户进一步选择服务器节点
3. list filter的keyword随便输入一个且与第一步的keyword不同即可
4. 脚本使用了expect，所以最终执行需要terminal command,无法选择Run Script
5. 因为系统密码及VPN账户我走的workflow环境变量而command是不支持环境变量解析，所以增加Run Script解析变量

三元表达式在简单的判断取值中使用，还是很简洁的，但是当遇到嵌套逻辑时，可读性就变得很差，实际项目中，我是这么要求团队=》禁用。

1

var foo = bar ? baz : qux === quxx ? bing : bam;

no-nested-ternary

为了约束这类代码的存在，eslint中会增加no-nested-ternary。

规则介绍戳这里

最近阿里发布了阿里巴巴Java开发手册（泰山版），花了点时间阅读下，这里MARK下个人感受

无规矩不成方圆

• 有些人觉得没规矩不挺好？但假如项目中10个人，10个风格，10个规矩或者没规矩，代码又存在交集，这样的代码能维护吗？能不出问题吗？impossible！
• 规矩，标准是为了提升协作性，降低门槛儿，代码差异化一定程度降低，每个人都这么做，熟悉了规矩，无论是自己coding还是看别的人code，自然就快，那么bug率自然也就降低了
• 假如我是个独立开发，只有我一个人，我就不需要规矩了？我之前也这么认识，但逐步我改变了这个认识，就是个人也需要有自己的规矩，风格，因为这会让你效率越来越高，规矩的背后是标准化，统一化。
• 这些规约的背后是前辈们，或者同行们从无数的坑，无数的雷中总结出来的，不一定恒对，但值得学习，值得参考，值得借鉴。

so，没规约，不见得单个问题解决不好，但不久的将来，一定出问题，害人害己。

之前年终Review时，与同事探讨一个项目总是会面临各种情况，而项目底层的架构，也是一直在发展，架构背后的人也是在发展，面对这种发展，我们需要系统反思、调整、分享。只有这样才能校正，才能统一整个team的认知等。

在交流中同事推荐我去了解 Architecture Decision Records (ADRs)，这个概念之前只是喵了一眼，毫无印象，答应要学也一直没有去学=》惭愧。于是今天还债。

ADR

ADR全称Architecture Decision Records,汉化后就是架构决策记录，之所以有这样一个概念，其背景正如上述我所提到的，项目是一个变量，在发展，而在这变化中，我们需要去系统记录梳理这些变化点。对于所有的成员也需要一种形式可以了解这些，而最合适的就是文档化。

当前我们是如何做的

1. 博客，我喜欢博客去总结一些变化
2. 公司文档-Confluence
3. 个人脑中

当前装饰器还只是ES提案[Stage 2]，在过去，还没定下来的东西，我们无话可说。但今天，项目中使用的是TypeScript，Babel，本身存在转译，所以我们往往可以用些超越当前的特性。比如Angular2框架中就有装饰器的大量存在。

这块之前我也只是在NG中较多的使用，并不算熟悉，于是冲下电。

装饰器

装饰器模式，顾名思义，就是将某个类重新装扮下，使它在功能上更强
大，但是作为原来的这个类，使用者不应该感受到装饰前与装饰后有什么
不同，否则就破坏了原有类的结构，所以装饰器模式要做到对装饰类的使
用者透明

类别

最近花个把小时阅读了谷歌工程实践，当然现在只有CR，MR部分，但是仍然很有触动。这里谈下个人的感受

官方文档：戳这里

CL的规范化

1. CL means changelist
2. CL提交新的subject，采用祈使句，一个命令的形式言简意赅的表达这次提交的改变是什么，如果需要详细的上下文，关联的卡号，就在body中说明。
3. 有些人会积攒一堆的change，一次性的提交，然后在一次性的MR，实际上大量的change增加了review的风险，MR的风险和回滚的风险。所以刻意训练分解问题，确保每次的CL尽可能的小，是有利可行的。