时常会在各种论坛看到一些关于 35 岁裁员的话题，大家都很恐慌自己会在 35 岁被裁员。
但说实话，这个事情其实没有那么复杂，你是否 35 岁被裁员，只与你的竞争力有关。
当然， 不同的人和环境竞争力和年龄的相关性是有区别的：
以绝大多数人感知到 35 岁裁员的消费互联网为例：消费互联网主要需要的是快速迭代的能力和对于用户行为、用户需求的感知，这里需要的更多是随机应变的能力，自然也就更多需要加班、卷。当然，你也可以通过一些别的手段来增强自己的竞争力 —— 比如质量、效果。并不是快就是绝对的好，快但是在错误的方向蒙眼狂奔，也是一种悲哀。
而对于传统的To B 的行业软件领域，虽然可能增长没有那么快，但由于需求明确、变化少，更多是自己在行业当中的经验的产品化，则不需要那么快的迭代速度 —— 毕竟你的用户不会迭代那么快。在这样的行业当中，你待的时间越久，积累的行业 Know How 越多，自然竞争力也就越强。
选择一个适合你的领域，提升自己在领域的竞争力，才是无惧 35 岁裁员的唯一手段。
相比于使用 Uniapp / Taro 之类的，我其实更喜欢使用小程序的原生来进行开发。主要是减少中间商赚差价，性能损耗更少一些。当然，也少了不少好用的体验 —— 比如随便引入 NPM 包，好在是现在的小程序开发者工具也提供了 NPM 构建的能力，所以一些基本的使用是没有问题的。
不过，小程序本身环境的特殊性，我在使用 NPM 包的时候还是会有一些谨慎的 —— 要选择尽可能小的、不受平台依赖的包，来缩小小程序的包。所以当我发现一个可以在小程序中使用的包的时候，我就会将其写下来， 以备不时之需。
在涉及到 Web 开发时，一个比较常见的场景是构建 HTTP 中的 QueryString，以便在发送 GET 请求时传递参数。但自己手拼参数还是比较痛苦的，所以用一些 package ，可以有效的提升开发的体验。
你可以在小程序环境中使用 <a href="https://www.npmjs.com/package/querystring-es3">querystring-es3</a> 来进行 querystring 的构建，包的体积不大，可以达到比较好的效果。
const { encode } = require('querystring-es3')
encode({
page:1,
pageSize: 10
})
// return 'page=1&pageSize=10'
Code language: JavaScript (javascript)qsquerystring 的处理包当中，比较出名的除了 node 内置的 querystring 之外，应该就是 qs 了，但实际在使用过程中，小程序的静态分析依赖了 qs，导致开发者使用时要么关闭提醒，要么换包。考虑到我还是希望使用小程序的静态分析，所以就只能替换包了。
去年买了小米的电视，但一直都闲置在那里，没怎么看。毕竟对于我来说，电脑是一个更加高频度使用的设备，完全没有怎么看过电视。
但过去一年里，没有什么文娱活动，更多都是刷抖音，刷信息流，时间被大量的消耗。在跨年的时候，突发奇想，我是不是可以把电视抱到卧室，在睡前看看电影啥的，毕竟我一直想看电影，但说实话，疫情的原因，让人不太敢和别人在一个密闭空间待两个小时。
说干就干，我把电视抱到卧室，开始用小米电视看电影。
配置好之后，两三天里，我看了好几部之前想看，但没有看的电影 —— 《十万个冷笑话》、《坏蛋联盟》、《小黄人大眼萌 2 ：神偷奶爸前传》。
目前我觉得比较好的有：
不太好的点
结合小米的广告的尿性，我感觉后续我的最好的方案是一个比较好的传统电视 + 一个电视盒子，这样体验会好点。 Apple TV 买起来！
如果说，一个人最重要的是什么，那便是判断力。有了判断力，做事便有了轻重缓急，有了不同的资源调配。
大部分人终其一生，不做选择，而是随大流，别人做什么，我也做什么。这样带来的结果是终其一生，如浮萍跟随时代和他人的步伐，飘摇不定。
想要摆脱这种不确定性，拥抱确定性，则需要学会做出选择，做那些重要的事情，达成自己的目标。
在查看一些技术文章的时候，看到一个不错的技术文章的范式，记录一下，这样后续我的技术文章也可以写的更有价值一些，而不仅仅是一个笔记。
以下内容为对应的范式和我的批注。
Shortcuts taken ：可以快速带走的 intro，也可以理解为是 tldr 的内容
今年的最后一个月，到了尘埃落定的时刻，也到了一年的总结时刻。今年的一年，是毫无收获，躺平的一年。。。
12月市场开始回暖，我的基金也开始回暖。终于算是回归了本金。今年的投资收益非常的惨淡，一方面有市场的因素，另一方面，我认为我的 KR 本身有问题。这个到年终总结再讨论吧。
无变化
没出门， 也就没超预算。不过这个月有一些紧急支出（指阳了以后，买了大量的储备物资，现在还没吃完。。）
暂无进展
这个月没有出去玩。。
没有进行文娱活动。
这个月没有啥变化。
暂无进展
12月份起草了两篇文章的大纲，但没有写成正式的文章。
暂无进展。
Swagger 算是 Code 2 Doc 的默认选项了，各种语言都提供了生成工具，此外官方还提供了一套方便使用的默认 GUI。
不过，Swagger UI 本身其实并不够好用，所以社区就会提供一些 Swagger UI 的替代品，方便大家使用。
ReDoc 是一个前端的开源项目，在 Github 上拥有超过 1W + 的 Star。对我来说，我觉得他最好的点是左中右三栏模式，左侧切换 API，中间查看 API 详情，右侧查看接口调用的 Sample，比 Swagger 官方的 UI 瀑布式的要舒服。
Angular Swagger UI 同样是一个开源的项目，界面简洁明了，虽然是瀑布式布局，但由于在界面上更加简洁，所以同样可以在同样的屏幕中，获取到更多的信息。
我自己在使用 Taro 开发小程序的时候，一定会开启的两个配置：
Taro 在预览模式生成的文档比较大，对于小程序的预览来说，不是很友好，所以开发的时候，我经常会打开压缩，以便于在小程序开发者工具进行预览。
修改也比较简单，只需要在你的 package.json 当中加入对应的环境变量 NODE_ENV=production 来支持即可。
diff 见下
Taro 可以开启 webpack 的持久化缓存，以便加速 webpack 的构建速度，因此我也会开启这个配置，以提升构建的速度。
这本书总体和之前看到过什么小岛经济学之类的风格很像，虚构一个环境，并在这个环境中演绎金融学，可以读一读，对于我们所熟悉的金融机构有一些了解。内容总体来说比较薄。
不知道，你有没有关注过开发者文档的信息结构。下图是 Google Docs 的 API 文档。
在菜单中 Google Docs 提供了 Home、Guides、Reference、Samples、Support。你有没有想过，这些内容为什么如何设计？在我看来，这是开发者文档内容的三种层次。
典型代表：API Reference
绝大多数开放平台也好，To Developer 产品也罢，首先要解决的问题是让开发者知道我有什么样的能力。而最简单、最直接最高效的方式，便是 API Reference。
各大产品在进行对外开放时，首先准备的便是一套 API Reference。在 API Reference 当中，你可以看到开发者应该如何调用一个 API；某个 API 的入参是什么、出参是什么；如果出现了失败，应该如何处理这些错误。
当一个 API Reference 为开发者提供了简洁、明确、易懂的文档内容之后，开发者基本就可以准备开始进入开发流程了。
Opinionated Notes：RESTFul API 的 API Reference 理论上不应该存在多层级的资源关系。
优秀的 API Reference 参考：
典型代表：API Overview、单个业务领域的 API Guides & API Tutorial
作为开放平台，当完成了 API Reference 之后，便算是及格了。但及格不应该是目标，目标应当是卓越。抵达卓越，则需要更多内容的帮助。
API Reference 回答了「能用什么」的问题，但没有解决「如何使用 API」的问题，特别是复杂的业务场景下，同一个业务内可能会需要多个不同的资源来进行 API 的操作，这个时候，如何使用这些资源，并将这些资源包装、关联起来，就成为极具业务属性的 Know How 知识。
举个例子来说，以服务端 OpenAPI 为例，日历的资源就涉及到用户、日历、日程、会议室、参会人、权限管控等多个不同的资源，如何串联这些 API 才能达成你的业务目标，就成为一个非常重要的说明。对于日历的能力熟悉的开发者可能很快就可以找到调通的方式，但对于不够熟悉的，这些 API 之间的串联，可能需要他花费一天，甚至一周的时间才能真正理解背后的含义。如果想要降低开发者调通过个 API 的时间，那么介绍这些不同 API 之间的关系，其在业务系统之中的含义就尤为重要。
如果你对于服务端的 API 感触不深，那么客户端的 API 可能会让你感受更加深刻，以微信小程序的中的蓝牙设备开发为例，如果你作为一个从未开发过蓝牙能力的开发者，看到了蓝牙提供的这一系列 API，只怕马上头皮发麻，需要每一个都看一遍才能理解其含义和价值；在蓝牙这件事上阻塞个半周一周也是常态。
一个好的 API Guide / Tutorial 可以有效的降低开发者在调试这些 API 过程中所耗费的时间。当然，微信也意识到了这个问题，提供了一套非常好的 API 说明。
优秀的 Tutorials 参考
典型案例：Code Sample，Demo App，场景化的使用教程
API Tutorials 可以解决的是面向场景化的单个领域的内容。它帮助开发者很好的解决了一个领域内的产品能力的串联。但在实际的业务场景当中，开发者面对的不是已经拆解到 API 粒度的任务，而是面向场景设计的不同问题。对于开发者来说，把场景拆分成 X 个 API 并没那么容易（特别是如果经验不足的时候），因此，一套标准的 Code Sample ，甚至是 Demo App ，都可以帮助开发者快速解决面向场景化的问题。它可能涉及到了客户端、服务端，或者是面向了多个不同的领域。这些内容帮助开发者可以快速 landing。
以飞书开放平台为例，飞书开放平台在开发教程里提供了多个领域、不同方向的场景化教程（虽然还不够多，远远不够），帮助开发者快速完成某个特定领域的功能的开发。
这些内容可能未必能完全满足开发者的需求，但确实可以给开发者一定的借鉴意义，帮助开发者理解整个业务流程和对应场景下的具体的实现，帮助开发者快速完成业务需求。
前面三层解决了有什么、怎么用的问题，而在整个应用的生命周期当中，怎么用并不是终极问题。下一步需要解决的是如何用好的问题。不过这个问题不在本次阐述的内容当中，所以我们留一个悬念，下次再说。