概率那块看起来还有一点数学，DP 、DC 那里说白了不就是 leetcode 讲解吗。。

算法和数据结构都应该是数学为主 pseudocode 为辅，上来就是特定一种语言的实现不能算吧

顺便提一下推荐的做法，就算都是 prod，每个 region 都应该有自己的账号。

好处很多，除了上面说的权限分离、好算钱以外，另一个好处就是 limit 增加了。每个 aws service 都有自己的 limit，有些可以找客服提升有些不行，就算那些可以提升的总有一天也会碰到 hard limit，账号分开的话就能延缓这个情况。

你可以开一个月付费的那种客服，然后直接找客服。

所以能部署到 aws 或者 azure 吗

windows 上可以用 newton(就是很早很早以前的 cloudmagic)，但是一年订阅 50 刀好像，而且基本上没什么功能。

提问：USAGING 是个啥

我之前也有这样的问题，后来我自己花了 2 天时间写了一个简单的 node 脚本来管理。基本思路是跑完一个脚本之后，立马把它存起来(例如 snippet save <名字> --tag <...> --description <...> !!)，就我的 use case 来讲完全够用了。

*奇技淫巧* 手动狗头

这么低的税，那也只能是西雅图或者奥斯丁了呀。3 年有这个包的怕不是只有 oci 和 f 了。

@msg7086 你不爱雷姆了吗

硬核科幻片 the expanse

@xiaket #11 "我们的解决方案是通过脚本来实现整体部署. 每次部署一个版本, 如果中间有一步出错, 全部回滚" 不好意思没看懂，这和所有东西都放在一个 stack 里有什么区别。我说的在一个 stack 也不是说所有东西都在 main stack，你可以把 component 拆分放进 nested stack，如果 nested stack 报错了，main stack 也会回滚所有 nested stack。我说的第二种拆分指的是那种被拆成好几个老死不相往来的 stack。

理论上如果你的部署会对生产环境造成影响，你们有可能需要想一下怎么解决这个问题。

有些服务不支持非 CFN managed S3 bucket 指的是（记不太清了）如果你在 Lambda 是通过 S3 触发，那 CFN 规定你的 Lambda 和 S3 必须都是在同一个 stack 里。(可以通过 SNS 绕开限制)

自己建机房=放慢增长=晚上市=自掘坟墓，有时候成本不仅仅是看得见的东西啊。

拆分有两种，一种是你把 json 或者 yml 拆开来但是部署的时候还是一个 stack，另一种是多个 stack。这两种有利有弊，但我偏向第一种。第二种的弊端太多，一旦写错了，发现错误的时候太晚了(因为你肯定是要一个一个 stack 部署的)。而且有些 service 不支持不是 cfn managed s3 bucket 虽然你在另一个 stack 里定义了 bucket，但在这个 stack 眼里就不是 cfn managed 的。

SAM Lambda 内部支持就一般，遇到 IAM 和 S3 event 问题更多

@msg7086 姐竟然回国了
嗯 我选择 tower

最起码也要有 kernel 级别的隔离 比如在 vm 这个层次上 物理机隔离成本太高了

有直接上机做 java 题的，给你 test case 让你写代码，也就是 tdd 啦。