以下这些书单是我认为和投资理财相关，要看的书。部分书有书摘，你可以点击链接查看书摘。
除了上述的图书以外，本站的读书笔记分类中还有一些投资相关的书摘，供你参考。
我在之前的文章 使用 Docked Rails CLI 简化 Rails 的开发 中介绍了 Ruby on Rails 的 Docked 程序，并提供了一个我自己的定制版本。
这里来和大家说一下怎么自定义 Docked 镜像，从而构建一个适合你自己的镜像。
At first ，你需要 Fork Rails 官方的项目
https://github.com/rails/docked
Fork 项目到你自己的名下后，你可以修改一下他的名字，改成适合你自己习惯的名字（比如我就改成 Runs 了，Docked 对我来说太容易打成 Docker 了）。
Docked 最核心的其实就是 Dockerfile ，你可以修改你 Fork 来的项目，并在 Dockerfile 当中添加必要的依赖，引入新的资料等。
比如，https://github.com/bestony/runs/commit/d930a5d6fc389cb6fa8e9f7c41947d01b000da95这个 Commit 就是为了在 Dockerfile 当中添加 PGSQL 的配置，以实现在使用 rails new 命令时，可以选用 PGSQL as DB Backend。
可参考：https://github.com/bestony/runs/commit/31fabe5f914d931834b0e12797b14d76bf56d162
可参考：https://github.com/bestony/runs/commit/5969cc4ee5c0bf8503ebdab5664f365b6719843e
修改完成 Dockerfile 后，接下来你需要修改 Docker镜像产物，以便于你自己在实际使用过程中，直接使用你自己的 Docker 镜像。
修改 https://github.com/bestony/runs/blob/160fe165db7abecc3229be417b15473dcd3aec9f/.github/workflows/docker-publish.yml#L41 的 tags 为你自己的，格式为 ghcr.io/{你的 ID}/{你的仓库名}。
修改好之后，只需要提交 Commit ，等待 Github Action 的自动构建即可。
镜像构建结束，你只需要修改 Readme 中的安装配置命令，这样在后续使用时就不用自己再修改了。重点修改的内容包括 ailas、镜像名以及底部的启动命令。
通过对 Docked 的简单修改，可以实现快速构建一个属于你自己的开发环境命令，帮你优化自己的工作流。
很久没有看 Gmail 了，堆积了一千多条消息。于是今天上午抽了半个小时，清理了一下邮箱。
在 RaiseByTurtles 中找到如何筛选出所有没有标签的邮件，我使用的是下面这个 Query
-has:userlabels -in:sent -in:chat -in:draft -in:inbox通过这个 Query ，我就知道我其实还可以使用 - 的语法来在 Gmail 中搜索邮件（过去我几乎只用 is:unread [query] 来搜索所有包含某个关键词的我未读的邮件）。
在清理过程中，我就可以不断的在其中去叠加一些关键词，来实现，干掉那些已经失效的邮件，比如，通过下方的 Query 就可以实现屏蔽掉所有没有标签且不属于 Substack 和 zhubai 的邮件，从而避免误伤到我订阅的 Newsletter。
-has:userlabels -in:sent -in:chat -in:draft -in:inbox -substack -zhubai
在开发 RoR 的时候，经常需要配置本地的开发环境。但如果你需要在一些云端开发环境（比如 Github Codespaces）中配置你的开发环境时，就会变得比较麻烦。
但得益于 Docker，我们可以直接使用 Docker 镜像来完成我们的开发环境。
Ruby 官方提供了 Docked 来帮助我们完成这个环境的构建。
假设你已经完成了 Docker 的安装，接下来你只需要做如下操作，来配置 Docked Rails Cli
docker volume create ruby-bundle-cache
alias docked='docker run --rm -it -v ${PWD}:/rails -v ruby-bundle-cache:/bundle -p 3000:3000 ghcr.io/rails/cli'为了方便你的使用，你还可以将上述的输入放在 .bash_rc 或 .bash_profile 当中。
接下来，你只需要使用 docked 你要执行的命令 来执行各种命令，比如官方给出的这样的 Sample。
docked rails new weblog
cd weblog
docked rails generate scaffold post title:string body:text
docked rails db:migrate
docked rails server由于官方默认的 docked 没有 PGSQL 的支持，所以我自己 Fork 了一个版本，做了一些更新。
这两天在梳理我的老照片，一边看一边删，也整理出了我眼中，有长期留存价值的照片。希望通过总结出规则，方便自己日常拍照、日常清理照片。
除了定下规则，也需要定期清理照片，这样才能在需要的时候，快速找到自己的照片。照片多并不一定是好事，有价值的照片多才是好事。
翻自己的老照片，明显感觉到，手机拍照记录生活还是更主流。相机虽然也有，但更多是「作品」，而不是「生活」，生活还是得手机。
最近突然想起来，应该把我喜欢的歌手 Share 给大家，互相交换一下自己喜欢的歌手、歌曲，让那些好听的歌曲广为流传。
不用多解释，我们那个年龄段的人都喜欢。
赵英俊的歌我一致都很喜欢，他的歌曲风格独特又深入人心。
我喜欢的歌包括：
他的歌很多时候唱出了小人物的无奈，像我这样的小人物，难免会有一些「他唱出了我的感觉」，所以很习惯。
再加上他的编曲也都不错，人也很有才，所以很喜欢听他的歌。
可惜天妒英才，英年早逝。
汪苏泷的情歌很多，也很值得听。
海来阿木坦白来讲，之前我不是特别的熟悉，因为的确小众。不过听了以后，他的声音还挺有个性的，自带嘶哑的特效，唱起来情歌，自带的撕裂感。
我喜欢的歌包括：
海来阿木算是宝藏歌手了，比较小众，但歌的确很好听。独特的声线值得一听。
我目前已经到了能听懂李宗盛的年纪了。所以，也推荐给大家。
此外，李宗盛之前和 New Balance 拍的一系列广告片也不错，感兴趣的可以找来看看。
过去一直听孟岩讲「投资是认知的变现」，没什么感觉，最近投资拼多多属实让我自己感受到了「投资是认知的变现」这句话。
在股票市场中，所有的盈利来源都可以归结为「低买高卖」，你在低价时购买了股票、基金，并在高价时卖出基金，获得其中的差价。
一种策略是简单的「追涨杀跌」，如果发现一个股票/基金开始出现涨势，就开始买入，并在买入后不久，进行售出。这种行为并非完全不可行，在高频交易和量化交易的过程中，基本上便是基于这样的逻辑进行，并通过机器逻辑来提升交易的频度和粒度，获取高额收益。
另一种策略便是我们所说的「投资」，找到你觉得价值和价格不匹配的股票，以低于市价的标准买入，并以高于市价的标准卖出，获得其中的价差。绝大多数的投资便是如此。
如今有了各种股票基金 App，投资动作变得越来越简单，你不再需要前往股票交易所现场购买，远程在家中，甚至坐在马桶上，都可以完成一次交易，「认知」体现在何处？
认知便是你知道这支股票的价值是多少。当你知道一个股票的价值，你便敢于在市场情绪崩溃的时刻激情买入；当你知道一个股票的价值，你便敢于在市场热捧之时，激情抛售。
我买入拼多多时，正值中美关系冰冻，拼多多股票跌至 70 美元。所以我买入了 20 股，把当时海外的空闲现金全部投入。后续随着中美关系解冻、拼多多的海外版 Temu 业绩不错，拼多多股票一直涨，直到最近的 145 美元。
从 70 买入开始，一直到 110 美元开始，我开始纪律性的卖出，110 美元卖一部分；120 美元卖出一部分；130 美元卖出一部分；目前手头还剩不多，定下的售出价格是 150 美元。虽然尚未达到 150 美元，但已经收回本，剩下的部分其实都是赚的。
在此刻，我深刻的感知到「投资是认知的变现」。我不知道拼多多的价值是多少，所以我会在 110 卖出、120 卖出、130 卖出。如果我始终没卖，可能到了 150 美元卖出，不仅仅是收回本，而是翻倍的收益。
但另一个层面，上面的这些不过是马后炮，拼多多完全有可能从 110 美元跌回 70 美元，甚至跌回 40 美元，这一切都是有可能的。我的认知并不能告诉我拼多多的价值到底是多少，只不过是纪律性的交易让我可以赚钱，本质上是幸运，而不是能力。
一如当下纠结的我，到底该不该卖拼多多？现在是否是已经超过了拼多多的股票价值？我是否应该继续持有还是卖出？我不知道。或许止盈是一个好的选择，既然认知不到位，就应该接受自己认知不到位带来的结果。也像我年初 200+ 卖掉的 NVDA，我的认知没办法想象到 NVDA 可以卖到 400+ ，所以自然无法享受到其从 200+ 涨到 400 + 的收益。
投资不过是认知的变现。
熟悉我的人知道，我是一个胖子，不折不扣的胖子。身高 180 ，体重 110 Kg。我也试图减肥，但一直以来，并没有养成良好的饮食习惯，导致体重一直没有减下来。我也在想，到底是什么让我始终瘦不下来？
答案当然是：迈不开腿、管不住嘴。可真的这么简单嘛？
因为内心有恐惧：
但这些真的是问题么？或许是的，毕竟我还算的上是一个骄傲的人。但同时，这些想法也限制了我的发展和身体健康。
也许是因为在我看来，总有比健身更重要的事情，身体可以往后放一放。但，真的还能往后放一放么？
相比于迈不开腿， 管不住嘴显然是让我持续胖下去更加重要的原因。但，为什么？为什么管不住嘴？为什么习惯性的吃多？
当我无意识的时候，我自然会继续吃多。但真的去思考为什么吃多的时候，我赫然发现，这问题原来是从童年带回来的回忆。
从小时后开始，我吃的就比较多。所以一直以来，给家里人养成的印象也是我比较能吃。从而形成恶性循环。
家里人觉得我能多吃 — 给我安排更多吃的 — 激励家里人给我安排更多吃的 — 进一步多吃。
这种恶性循环使得我被要求吃的更多，而我为了让家里人更开心，所以也在不断的吃的更，久而久之，固化了我吃的多的风格。
但，这解释不了如今我已经离开了家乡，已经开始自己做饭吃饭，为什么还是吃这么多？
我家里并不算富裕，甚至从小我的外食之类的都是很少的。大部分时候我都是在家吃的，对于外面的好吃的其实并没有太多的机会去吃。
这样使我养成了一个坏习惯 — 每当有的机会去吃的时候，就会多吃。因为不知道自己什么时候还能再吃到。这个坏习惯也加重了家里人对于我「吃的多」的刻板印象。
而且，这件事也影响我在其他方面的习惯。举个例子来说，如果我住高档酒店，没有用完的洗漱用品一定会带走。一方面是我觉得不带走浪费。另一方面，的确这些高档酒店的洗漱用品我拿回家依然可以用。
虽然我的收入可能完全可以支付的起一块肥皂的钱，但习惯趋势我还是会把酒店的香皂带回家日常使用。我真的缺这块肥皂钱么？显然不是的。
我其实在朋友的减肥的服务中学了不少，包括理论也都看了，也都学了，但还是减不下来。真的是服务不行么？不是的。
从技能上，我已经掌握了先吃青菜蛋白质，再吃碳水；控制自己摄入食物的比重和顺序。但，习惯性的多吃，让我即使是已经在先吃碳水的情况下，依然大量的摄入了食物。
想要改变这些问题，需要解决我自己的心病、心理问题，最终才能得到解脱。
Fast API 作为一个新兴的 Python Web 框架，不少的开发者都在使用 FastAPI 来开发应用。我最近也在试着使用它。
在开发应用时，我习惯使用 TDD 的方式进行开发，特别是开发飞书机器人时，由于飞书给我提供的请求是可预测的，特别适合以 TDD 的方式来定义行为并实现。
同时，我在使用其他语言开发的时候，也会用到使用 .env 和 .env.testing 这样的配置文件来在不同的环境下加载不同的配置文件，达到在不同环境使用不同的变量来完成任务。
.env.testing 文件想要实现在 FastAPI 中读取 .env 文件，首先，你需要引入 pydantic_settings 包，来完成基本的配置文件的读取。
from pydantic_settings import BaseSettings
class Settings(BaseSettings):
app_name: str = "Awesome API"
settings = Settings()
print(settings.app_name)接下来你可以为这个 Settings 类新增 Config 配置，以实现读取本地的 .env 文件
from pydantic_settings import BaseSettings
class Settings(BaseSettings):
app_name: str = "Awesome API"
class Config:
env_file = ".env"
settings = Settings()
print(settings.app_name)通过上述代码，你的配置项目就会自动读取 .env 文件来加载环境变量，从而实现更加简单的环境变量管理。
.env.testing 文件在测试时，为了避免使用线上的数据，你可以在测试时加载不同的环境变量文件。
如果你只有一个测试环境，可以有一个非常简单的方式来实现：在配置 env file 时，传入一个元组，会自动加载多个文件。
from pydantic_settings import BaseSettings
class Settings(BaseSettings):
app_name: str = "Awesome API"
class Config:
env_file = (".env",".env.testing")
settings = Settings()
print(settings.app_name)需要注意，这里实现的实际上是使用 pydantic-settings 自己的加载顺序来实现。默认情况下，靠后的文件优先级会更高（覆盖了前面的内容）。这样的好处是如果你有些配置测试环生产是一样的，可以在 .env.testing 中加入不同的部分，相同的部分直接复用生产环境的配置项目即可。
但由于使用的是顺序加载多个问题，如果你发现表现和你配置的不一致时，就要看看是不是有优先级更高的环境变量文件覆盖了默认的 .env 文件。
借助 pydantic-settings 的一些配置，你可以快速实现 .env 和 .env.testing 的加载，相比与判断环境变量，这样会比较简单，且可以实现在 .env.testing 中只维护变量，和线上保持一致的部分可以直接继承。
使用 FastAPI 后，你需要写完整的请求体和返回体，以便于生成 API 文档，对于完全从 0 开始构建的项目来说，是不难的，但如果你需要做的是一个项目的迁移，那么写这些类型定义可能需要耗费你大量的时间。
不过，JSON to Pydantic 可以帮助你解决这些问题：
这个网站支持使用一个 JSON 作为 Input，并生成对应的 Pydantic 的代码，对于一些老旧项目迁移的工作来说，可以说是节省了大量的时间。
不少人对于大力出奇迹有一个错误的认知 —— 认为大力出奇迹便是 ALL In。但其实并不是，大力出奇迹更像共产主义的一个特色 —— 集中力量办大事。
实际上，我并不鼓励任何形式的 ALL IN，如果你开始思考要不要 ALL IN 的时候，说明你的路子大概率已经走错了。正确的事情需要投入去做，但不需要 ALL In 的去做。
ALL In 是指你将所有事情都押宝在一件事上，这意味着你不成功便成仁。但当你走到这一步的时候，可能你已经没得选了，大概率面临的是失败，不然为何成功成了千古佳话。
大力出奇迹则是对看重的事情大力投入，而不是停留在推演、思考，主动投入资源去推进一件事的落成，才能帮助你把想要达成的目标给达成。
这两者是不同的，可别乱用。
最近在和朋友在做一些项目的时候，很深刻的感受到了创业公司的一些问题。而其中让我印象最为深刻的是 —— 优先级分不清。
这也引发了我的思考，大公司为什么能成为大公司？小公司为什么总是小公司？是不是有什么是小公司一直没做好的？
思考后我的答案是：小公司往往死于优先级不清晰。
作为一个小公司来说，资源不多是正常的，但不是致命的，有多少钱就办多少事就好。但如果你没有钱，却选择做一个不适合自己的事情，或不把有限的资源投放在最重要的事情上，可能最终一定会面临一事无成，最终无法达成自己的预期。
我们当时的目标是开发一个项目。一个项目中存在主流程和辅流程。我的观点是优先关注项目的主流程，而不是辅流程。而朋友则会关注一些偏表面的体验、颜色、或一些直线流程的产品功能。这里我们存在了优先级的冲突。当然，最终还是按照我的优先级来做事。
在绝大多数的时候，大公司是那个资源更加充沛的角色，这使得大公司可以拥有更多的资源、更多的试错可能机会。对于大公司来说，一个方向的试错，并不会导致大公司彻底死亡。同时，大公司的各种流程的积累，可以帮助大公司尽可能的做出最正确的决策（虽然这个「最」其实是在企业内的最，未必是产品的最）。
但对于小公司来说，由于资源的有限，可能一次失败面临的就是全盘皆输。因此，对于小公司来说，优先级的决策就变得弥足珍贵。对于小公司来说，如果领导者是一个聪明、经验丰富的人，还可以很好的评估项目和工作的优先级，带领大家穿越周期，最终取得预期的结果。但如果领导者不够聪明，或者精力不在做决策上，则大概率走向不好的结果。
不过，这个事情上来讲，也有一点悖论。对于小公司来说，决策会更加重要，但对于小公司来说，招募到一个可用之材也是更困难的事情 —— 因为人才会选择去一些胜率更高的大公司从业，获取更加明确的收益。小公司得到的人才可能往往不是那么的优秀，使的小公司的决策行为更加雪上加霜。
对于小公司来说，需要用更高的赔率去招募合适的人才，才能招到真正优秀的人来一起做事。
大公司因为有标准的流程，即使决策者水平不高，依然可以借助流程提升决策的水平。但对于小公司来说，如果决策者水平不高，大概率会死在路上。好的决策，影响一切企业。
作为一个个人，如果你刚刚走进社会，有机会进入到大公司去感受到大公司的决策流程，那对于你整个从业经验来说都是会有很大帮助的。但如果你没有办法进入到大公司，那么一定要仔细遴选小公司，特别是与小公司的领导者沟通，了解小公司的人领导者是什么样的人，确认小公司的领导者是否是你认可的人。避免浪费自己的时间。
创业公司/小公司可能是每个人必经的道路。但是，我希望你能在这个路上少踩一些坑，走的更稳。