@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%」，就为后继面试埋下了伏笔。在面试过程中，我可以就这些内容引导面试官展开深入讨论，比如：

Chrome 上碰到过同样问题。

解决办法：Developer Tools 里，清空 Application 下的所有项目。

https://github.com/jorgef/engineeringladders

- Technology: knowledge of the tech stack and tools
- System: level of ownership of the system(s)
- People: relationship with the team(s)
- Process: level of engagement with the development process
- Influence: scope of influence of the position

---
如果非要凑够六个维度，也许可以加一项个人成长向的，比如自驱力？

@lamls #11
@orangy #12

我碰到过几次冬天早上无法唤醒的情况。原装电池，晚上室温大概 0~5°。
要充电几分钟才能开机，开机进系统显示电量 0%。

所以我怀疑「天冷掉电」是电脑锂电池的通病，不是第三方电池的锅。

我的处理方法：冬天夜里把 MBP 放卧室里（室温 > 10°）。

同 15’ MBP 2015 ，三年前通过苹果官方的电池召回计划换过一次。
https://support.apple.com/zh-cn/15-inch-macbook-pro-battery-recall

今年 8 月份发现又开始鼓包了。
苹果不支持再次召回了：「 您输入的序列号不符合这项计划条件。记录显示，您的设备已通过这项计划进行了维修。」

现在机器除了发热厉害点儿，日常使用需求都能满足。迫于穷，还想再让它继续服役一两年。

想问一下 OP 换的是什么品牌的电池，什么价位？
后继使用过程中如果有啥问题也希望 OP 能持续更新。
谢谢。