可以把你的博客个人项目什么的全部迁移过去，最常见的几个服务 EC2, RDS, S3, CloudFront 用用，注意别破产。。
其他的服务实在是多如牛毛，基本只有真的用到的时候，才会去查文档去看怎么用，个人项目很少使用到。

还有一种方法就是出来创业，被逼着没办法只能研究 aws 怎么回事。之前有两段创业经历，熟悉了 EMR, EKS, ECR, Athena 这类个人不太用的服务

干过一年技术咨询。一般咨询是不写代码的。
我在的企业不是咨询公司，而是一个行业软件公司的咨询部门，专门解决主营产品没法很好解决的客户问题，给人做 POC 然后看有没有机会把这些解决方案合并回主营产品。

体验十分不佳，理论基本忽悠用户，工程实践基本为 0 。客户在迪拜，同事在美国，白天工作，半夜开会，间歇性睡眠，感觉还不如 996.
乙方的滋味不好受，客户说啥只能受着。帮助用户创造价值也都是扯，我自己一个刚毕业的小屁孩，对着从业 10 多年的客户一阵忽悠，心理发憷。

考个 CKA，顺便了解一下 k8s 的底层组件把？
我买了这个作为考试准备： https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/

Python Vue PostgreSQL
Go 写 k8s 的 operator
Terraform 管理 infrastructure

基本和上面提到的 One man saas 差不多。这套技术也是久经考验，初创公司特别适合，开发速度比较快，多面手

有些共享办公空间，注册个会员可以提供地址代收服务

> 其他调用方会来调用我服务，调用的输入为字符串比如{"R2", "R3"}。
> 每次要计算的结果的数量是不确定的，其他调用方可能只要 R1 和 R2，那我就不想去调用 C 数据源了。

这个操作叫 Cull，是图优化的一种。具体做法就是，对你需要的输出，例如{"R2", "R3"}，获得它们的所有依赖，和依赖的依赖... 然后将图里面不属于依赖的节点删除，就得到一个精简以后的 DAG 。

> 每个来调用接口的独立请求里，我这里的数据源我只想调用一次，比如我不想算 R1,R2 的时候获取两次 A 数据源，以及如果在算过 R2 之后，再去算 R3 的时候要再算一边 R2 。
我想从下往上算，比如 R3 的逻辑里里 go 出去 R2 和 C，R2 里再 go 出去 A 和 B，那我后续算 R1 的时候，怎么直接取刚刚算 R2 时的获取过的 A，A 写成单例？只要被调用后，再次被调用返回数据源？ -当然还有其他的，比如错误中断之类。

计算的顺序可以将所有节点按照依赖关系进行拓扑排序，就可以保证一个节点计算的时候，它的所有依赖节点都是被计算过的。
计算过的节点的结果，可以用个 dict 保存一下，下次需要的时候直接按照节点名称取出就不会重新触发计算了。

vs code ssh 插件 https://code.visualstudio.com/docs/remote/ssh

terminal 都是远程的。看到的也都是远端的文件。

这种一次性，简单并行循环的任务，建议可以考虑[dask]( https://dask.org/)框架。代码非常好写，改动很小，纯 python 框架，不依赖外部服务（数据库、消息队列等）。
建立一个 scheduler 和多台 worker 机器的集群也十分简单。

很多单位（例如 Facebook ）的全栈岗位，都是不需要碰 SQL 的，也不给碰 SQL，封装好 ORM 给大家用，不容易出性能和安全问题。

看点基本语法，然后找个以前实现过的项目，拿 go 重新写一遍，找找感觉就差不多了。

我的第一个 go 项目是个 k8s 的 operator 。有个代码生成器，已经给你把架子搭好了，你往里填实现，补一些测试，了解一些周边工具使用方法就上手了。

LZ 是不是把 monte carlo 模拟和离散事件模拟记反了。后面那个并行比较困难，前面那个处开 MCMC，是最适合并行的算法了。

xbox 三大俗：车枪球。
感觉车 和 球 对操作要求都不太高。
枪 有些射爆游戏，要求也不高。

Go 是来解决现在的小年轻写 C 写不好的问题。大公司内部（例如 G ）需要大量的做 infrastructure 的工程师，因为性能问题，一般又都选择 C/C++来写。可是这类工程师现在又特别不好找，小年轻也都不肯好好学这类语言，初级工程师写出来的代码质量也都难保证（指针瞎用，奇怪的性能问题）

有了 Go，至少能大幅降低，给这类 infrastructure 产品贡献代码的难度，让小年轻也能愉快的和老鸟一起做 infra 。这个也是语言被发明出来的初衷。
go 的王牌项目（ k8s, docker, InfluxDB, CockroachDB ）都属于这些领域范畴。

在业务层误伤 php 、python 、java 感觉属于副产品。

我觉得应该称 go 为云时代的 C

对标 P7，跳槽需要升一级，P8 走起。就像 G L5 没事也不会左右横跳 F E5，A I6，因为意义不大，不如原地等升级（除非一些特殊情况，例如干的不开心，升级不顺利等）

可以做 GPU 工作站，装好环境，卖给学校、实验室，和对算力有需求的小公司做开发使用（ aws 这类服务生产可以，但是开发用有点贵），还是有不少生意的。https://lambdalabs.com/
但是在国内做这个可能得有点关系，不然打不开局面。

看着和 firebase 和 parser 像

推荐 hugo，简单够用

1 可以问的更宽泛一点: 做 infrastructure 相比做业务后端如何？

小公司基本不需要做 infrastructure，也没这个时间和人力
做 infrastructure 对基础知识的要求还是挺高的。
Infrastructure 方向还是挺广的，有很多领域，数据存储，网络通讯，分布式，甚至搞机器学习加速的，都算。
在公司的存在感没有做业务的大，除非你搞出了什么王牌开源项目。
Oncall 压力确实比较大。但是 infrastructure 工程实践质量比普通的业务代码要好几个数量级。
据我观察，职业安全性相当不错，这块东西可能是为数不多，小年轻不一定干的过老年人的领域了。随着年限上升，可以做的相当深入。

有趣的一个观察: 入职一个公司，参加一个新员工培训，员工年龄段泾渭分明，明确的分成了刚毕业的小年轻，和一群中年人。公司招人是不分方向的，员工培训完之后再根据双向选择分配到不同的团队。和年轻人聊选组意向，大部分都对做产品开发感兴趣。和中年大叔聊，都是对做 infrastructure 感兴趣。不少以前是做编译器的，现在想来搞深度学习框架加速。原来是数据库的，现在想来做分布式存储。