#81 开源编程字体

开发者 字体 2023-11-14

已经有的开源字体：

厂商 字体 协议 网址
Adobe Source Code Pro OFL https://adobe-fonts.github.io/source-code-pro/ / Repo
Google Noto OFL https://fonts.google.com/noto / Repo
GitHub Monaspace OFL https://monaspace.githubnext.com/ / Repo
JetBrain Mono OFL https://www.jetbrains.com/zh-cn/lp/mono/ / Repo

Adobe 的 Source Code Pro 补上 CJK 文字就成为了我们熟悉的思源黑体系列。

Google Noto 其实就是思源黑体的基础上，再补充其他语言，试图给所有语言文字一个统一的展示效果。
Noto 这个名字来自 No More Tofu。

Maple Mono

https://font.subf.dev/zh-cn/
https://github.com/subframe7536/maple-font

VSCode 中字体配置加上 “Maple Mono Normal CN” 就好了。
中文字符宽度等于两个英文字符。
NL：不含连字
Normal：去掉手写风格（默认字体在斜体场景下会有手写风格）
NF：包含图标字符

支持这些符号：

[DEBUG] [INFO] [WARN] [ERROR]
[TODO] [FIXME]

# Maple Mono
brew install --cask font-maple-mono
# Maple Mono NF
brew install --cask font-maple-mono-nf
# Maple Mono CN
brew install --cask font-maple-mono-cn
# Maple Mono NF CN
brew install --cask font-maple-mono-nf-cn

# Maple Mono Normal
brew install --cask font-maple-mono-normal
# Maple Mono Normal NF
brew install --cask font-maple-mono-normal-nf
# Maple Mono Normal CN
brew install --cask font-maple-mono-normal-cn
# Maple Mono Normal NF CN
brew install --cask font-maple-mono-normal-nf-cn

#79 奔 35 程序员的职业生涯思考

开发者 开发者的思考 2023-10-22

周一被问到这个问题，我真的是一身汗，因为我发现自己真的很长一段时间没有思考过这个问题了。
每天按照固定的步骤处理各种问题，时间久了，工作就成为了一种惯性。
或许很多人都是这样，但我认为这不是一种积极的，上进的人生态度。

生活中充满了变化，我们应该能够适应不断变化的生活，而不是在稳定中消磨掉自己的斗志。
运气好的话，一直稳定下去，运气不好，今后要摔大跟头的。

我刚开始工作时，经理告诉我们，大家在这里相聚，应该要有一点基础的认知，大家都不是杰出人才，只有资历深浅而已，没有谁高人一等。
我认为说的非常实际，现实就是这样，大多数人都是普通人。我也是一个一般水平的开发者。
这么说并不是要打击个人的积极性，这完全不耽误我们大家在工作学习中力争上游。只是说，我们要清楚认知到我们力争的这个“上游”在社会上的一个真实位置。
如果我们没有这个认知，可能对职业生涯的规划产生错误的影响。

好，现在开始说说职业生涯规划的事情。

TODO: 未完待续...

#77 什么是全栈？

开发者 2023-01-15

关于全栈开发者，我之前的理解是，能做前端、后端、移动端的开发，或许再包括小程序。

方向比较多，如果说要精通各个方向的话，实在是有点费力，要么是天才，要么是技术狂。
所以比如说着重后端的的话，再学一下 React，能对 React 开源项目二次开发，再用 RN 做移动端，就可以了。

今天，看到的这篇文章却提出来更多的要求：The Full Stack

作者举了一个例子，认为掌握以下三项远远谈不上全栈：

  • Ruby，Rails，Postgres，React Native，iOS，Android
  • Docker，Kubernetes
  • 谷歌云计算

上面只是技术，还应该包括：

  1. 和人打交道：

  2. 基础设施团队

  3. 管理人员
  4. 产品人员
  5. 业务人员

  6. 客户

  7. 业务

  8. 产品设计
  9. 合规

#76 服务丧尸？为什么

开发者 2022-10-31

发现一个问题，暂时没有任何思路：

一个线上执行了 66 天的服务，突然在前天凌晨 1:30 没有日志输出了，从外网连接不上，内网可以连上。

等后续有了进展再更新。

#75 代码中的 TODO 注释

开发者 2022-08-19

《Stop Using TODO for Everything》建议采用更加明确的标记来注释代码：

  • FIXME/BUG 需要修复（缺陷）
  • CHECKME/REVIEW 需要审查
  • DOCME 需要文档
  • TESTME 需要测试
  • HACK/OPTIMIZE 需要优化

我就是喜欢在代码中写 TODO，以后可以照着这个建议搞些花样。

#74 应该如何做 Code Review

开发者 2022-06-17

Review 的三点好处

  1. 帮忙发现问题
  2. 相互学习
  3. 统一编码风格

应该怎么做

  1. 找出相应的变更（提交），开发者做简单说明，约好评审时间
  2. 参与评审的人尽快找时间从头到尾检查每一处变更，提出意见发出来
  3. 不可能一点意见都没有，每个人都应该能发出几条
  4. 编码风格也行
  5. 然后约一个会，在会上讲解整体的逻辑流程，每人提出评审意见

参考资料与拓展阅读

#73 一些微不足道的开发经验

开发者 开发者的思考 2022-06-17

设计

  1. 方案设计要留有余地，在满足需求的前提下，尽量更加通用一点。
    前提是要认真理解需求，认真理解现有的架构，多想想，再多想想。
  2. 但是也要避免过早地、过度地优化。
    我们应该了解对团队来说更有价值的事情是什么，然后把主要的精力放在更加有价值的业务上。
    基于这个认知，我们就能更清楚需求到底是什么，应该如何去设计。

编码

  1. 遵守业界通用的编码规范非常重要。
  2. 代码可读性非常重要，简洁、美观。
  3. 如果一个逻辑有好多步骤，尽量分成几个更小的单元实现。
  4. 避免写重复的代码，将重复的部分抽离出来（有时需要考验设计能力）。
  5. 关键的点打印日志很重要，尤其是功能刚上线的时候，嫌多的话可以后面调整。

协作

  1. 沟通非常重要，沟通非常重要，沟通非常重要。
  2. 要通知到相关人，不只是消息发送出去就行，要确保他们真的理解你的意思。
    有些时候，作为经手人，还需要继续跟踪，了解他们的后续操作以及整件事情的进展。
  3. 对接时须对细节再三确认，然后形成约定，比如接口提供方将小数统一整理成保留两位，接口提供方应该保证默认排序规则。
    如果不确认，形成约定，日后有变更，可能就是意想不到的坑。
    如果是一些简单的工作，两边都处理一下也未尝不可。

工程

  1. 开发的预估时间往往是比较保守，及时你认为这个时间绝对没问题，也往往免不了延期。
  2. 可能是需求会变化，可能是方案的实现中会遇到一些变数，还可能是有别的事情会占用时间。
  3. 即便是在公开会议上也应该顶住压力，留有余地。如果真的是非常紧急，至少需要确保优先级真的比较高。