@IndexOutOfBounds #5

> - skip_too_short_threshold: 0
> match_re: ^[\s\S]{0,300}$ # 丢掉 300 字以内的短文
> action: drop_feed

如果我理解正确的话，这是通过 yaml 来配置和启用“系统内置”的插件。
已经有了初步的插件化支持。👍

我更期望后继能扩展到支持用户自己编写插件、上传系统、沙盒执行。

比如说我订阅了 V2EX 的 RSS 源，希望有一个功能：在主题发布两天后统计它的回复数，感谢数和红心数。
这可能是一个非常小众的需求，不一定会内置在系统里。那就只能既往插件机制来支持用户自行编写。

大赞！

请问是否有计划做一个插件系统：通过执行自定义插件，对 RSS 内容进行标记/过滤/增强/……
如果要支持插件，也许我也能贡献绵薄之力。

我去年就整理了 RSS 阅读器的一些需求，主要关注插件支持能力。但是一直拖延着没动手……
https://github.com/users/HuangJian/projects/1/views/1

Rime 处理这个问题的标准答案是使用「模糊音」。

speller/algebra/+:
- derive/^([zcs])h/$1/ # z, c, s => zh, ch, sh
- derive/^([zcs])([^h])/$1h$2/ # zh, ch, sh => z, c, s
- derive/([aeio])n$/$1ng/ # ang, eng, ing, ong => an, en, in, on
- derive/([aeio])ng$/$1n/ # an, en, in, on => ang, eng, ing, ong
- derive/([iu])a(o|ng?)$/a$1$2/ # tain => tian

---------
启用模糊音会带来两个问题：
1. 候选词数目会大量增加。如“zhangk”会候选「展开」，不过我还没有体感到候选条目增加引起的性能卡顿；
2. 增加的候选词可能会带来预料之外的词频排序。还是“zhangk”，我机器上「展开」会排在「掌控」前面。

因为我用的是全拼，所以写了一个根据输入编码和候选词拼音匹配程度重新排序的插件，也算处理掉这个问题了。
https://github.com/HuangJian/rime-frost/blob/hj/js/sort_by_pinyin.js

@yibie #12

> 有没有基于这个开发的新插件，作为一些例子？

✨ 看看我们的实力！ 白霜拼音的所有 Lua 插件都已完美重写为 JavaScript 版本 。

https://github.com/HuangJian/rime-frost/tree/hj/js

@Vitta #4

> 成熟的话应该很好用了，这样的话是不是就可以支持 api 请求了

如果是说通过网络调用来实现类似「云输入法」的功能，已经有人基于 Lua 插件引擎做过了。

理论上说，JavaScript 插件引擎应该也能做，而且比较 Lua 还有一个优势：充斥宇宙的 npm 库 😄。
一个障碍是：quickjs 不一定能无缝使用 nodejs 的类库。这个问题暂时还不在我的计划内。

@Vitta #4

> 成熟的话应该很好用了，这样的话是不是就可以支持 api 请求了

如果是说通过网络调用来实现类似「云输入法」的功能，已经有人基于 Lua 插件引擎做过了。

@luoyou1014 #2

> 有个疑惑，Rime 类型的仓库，不会有老外看吧，为啥 ReadMe 默认是英文的

1. 在技术领域，英文表述通常比中文更严谨更精准。
2. 用英文能避免大陆简体和港澳台繁体的表达差异（ Rime 创始人和很多贡献者都不是内地人）。
3. 据说有基于 Rime 的日文和韩文输入法。
4. 稍微提高一丢丢技术门槛，也许后面能减少一些不太认真不够严肃的社区噪音。

感谢分享，期待后继内容。

> Skim：浏览，有「 Read Quickly 」之意，希望能提供给用户高效的信息阅读体验。

我自己开的阅读器坑，也取名叫 Skim 。/握手
还没精力动手做，只整理了一些需求和信息，供参考： https://github.com/users/HuangJian/projects/1

核心问题：职权错配。
OP 现在相当于顶着「技术总监」的头衔，做半个「架构师」的事（只做规划，不推实施）。

建议解决方案一：主动要事要人要权，做真正独当一面的技术总监
精心准备一个工作汇报，跟大老板谈公司的机遇和问题（机遇为主，问题为辅）。
详细论证如果保持当前的技术管理体系，机遇将会如何错失，问题将会如何延续，新问题将会怎么发生。
提出自己的解决方案一二三，分别要做哪些事什么资源多长周期，在哪些里程碑节点可以达到什么可观测的质效指标。
如果大老板认可你的方案，就必须要给事给人给权；如果不认可，说明你与大老板的认知规划严重不符，早谋退路吧。

建议解决方案二：低调做事盘人谋权，以技术收复管理
既然什么资源都不给，那就别做中长期规划了，先把推到你手上的技术问题解决掉。
但要注意，这些问题不要大包大揽自己全部搞定。
每个问题，都带一两个小弟小妹一起做，美其名曰「传帮带」，共事时用你的经验技术人品征服他们。
要人了肯定会和产品规划的项目节奏有冲突，找准机会小吵几架，逐步谋取排期/分任务/打绩效/招人权。
如果能撑个一年半载，研发团队里人听你的事归你管了，自然而然就从产品团队里独立出来。

---
关于大老板：既然招了你进来，肯定是对现在的研发产出不满意。看你如何向他传递「破而后立」的思路了。

关于产品老大：你来了相当于分掉他一半的职权，从你行文来看，我不倾向于他会真心配合你开展工作，没必要舔。

关于研发组长：不知道研发团队规模，如果少于 15 人，这个岗位可以撤掉，你直接管理整个团队；如果多于 20 人，建议分成几个十人规模的小组，分别设一个研发组长向你汇报。

MBP 15' Mid 2015 ，A1398 ，官方免费更换一次的电池，使用三年后再次鼓包。

去年六月初 DIY 更换了京东买的绿巨能电池，实付 318 元。
作为生产力工具和主力娱乐工具，每日使用约 10 小时，其中拔电使用 2+ 小时。
用到现在体验良好，未感觉到与原厂电池有差别。

使用 [bclm]( https://github.com/zackelia/bclm) 设置最高充电至 90%，现在的使用情况：
Charge Information:
Fully Charged: No
Charging: Yes
Full Charge Capacity (mAh): 9289
State of Charge (%): 84
Health Information:
Cycle Count: 158
Condition: Normal

赞同楼主的想法！

我上半年做一个 STM32 的小板子开发，开发流程体验极差，效率很低：
- 没有支持 macOS/Linux 的工具链，需要远程桌面连接到 Windows 系统开发调试；
- 在 VSCode 上写代码；
- 用 Kail μVision 编译烧录；
- 用图形化串口工具 debug 。

主要痛点：
1. 没有跨平台的工具链；
2. Kail μVision 的开发体验过于远古；
3. VSCode 设置为普通的 C/C++ 项目，有些头文件没有包含进来，会提示编译错误；
4. 不能在命令行里编译/烧录/调试；
5. 串口工具不支持脚本自动化；
6. 项目配置麻烦，用不上 makefile 、gcc/llvm 编译选项、linter 、单元测试……

前段时间也动过折腾一个基于 VSCode 的跨平台开发工具链的念头，因为懒，调研了一些材料就搁置了。
- https://github.com/glegrain/STM32-with-macOS
- https://github.com/bbrown1867/stm32-makefile
- https://github.com/adamheinrich/cm-makefile
- https://www.davidrojas.co.uk/stm32f3discovery-on-mac-os-x-using-eclipse-gcc-arm-and-openocd/

如果 OP 打算以开源项目来推进这个想法，也许我能一起做些贡献。

Append：

我司目前开放的岗位，均需要不定期到办公室工作。
所以我们更倾向于和定居合肥的人才合作。

纯远程的合作方式虽然也还可以商量，但是需要是极其合适极其匹配的人才会考虑。

在面试过程中，我可以就这些内容引导面试官展开深入讨论，比如：
- 如何发现这些冗余代码的？ → 静态分析、代码覆盖率
- 如何保证删除代码之后系统仍然正常工作？ → 单元测试
- 为什么以前的系统性能那么差？使用了什么优化技术？ → 算法复杂度分析、C++内存管理
- 如何比较优化前后的性能？ → profile

能把握到这些亮点的面试官，肯定也对这些工作内容的过程和难点充满兴趣。

@wintercoder #37

PS. V2EX 的回复系统有问题……按回车就直接发布了。

在面试过程中，我可以就这些内容引导面试官展开深入讨论，比如：

> 比如「第二周开始优化重构老系统代码」、「负责「数据输入」模块的设计和开发，带领两位同事使用 C++重写 VB 老项目」 面试官可能会觉得重构很正常，没啥好问，但实际上里面遇到了难点，但简历没提

后面紧跟着的数据描述，「一个月内删简 4000+行冗余代码」和 「数据输入性能提升 90%」，就为后继面试埋下了伏笔。在面试过程中，我可以就这些内容引导面试官展开深入讨论，比如：