Python + flask/django. FastAPI 的问题是是暂时 community 不太成熟。比较有经验，有信心去 stackoverflow 自问自答的朋友可以尝试 fastAPI

thinkpad 小红点？似乎更靠谱一点。

我遇到过类似的。最后使用 presigned url 稍微增加了 手动 call api 的难度。

1. client request for address updates -> server
2. server return a presigned url for posing address chagnes and the url timeout in 200ms(一般是你 request response round trip 正常的时间范围)
3. client update address with presigned url.

因为 2. 返回的 presigned url 有 200ms timeout 而且只授权指定 ip. 所以，至少用户没办法手动操作直接 call api. 怎么着也要再搞个脚本 自动化一下。其实就拦截了不少特定场景下的用户了。

但是我觉得你的用户如果都是程序员，而且直接 call api 的动机很强，那基本上就没有用了。

为什么是百度一下。。你这是不是正经 Google

我在国内用过 pixel 。。有梯子就还好。。但是国内很多 App 比如地图会不太好用。。请求一堆权限，然后很多原生 google map 能实现的东西都没有。。没有用的东西一大堆。。 但是 google map 在国内又是个废柴。
反正我是不会长时间用，水土不服。可能没有国产手机丝滑。

看你怎么定义 “运维”。。
我是 oncall 过比五万台更多的机器的服务。高度自动话以后。。其实 5 万还是 10 万台机器，差距不大。manual operations 也不是很多。。甚至有>50%的时间写代码，开会什么的。更多的就是：
- 工作时间 alert 都看一看。
- 非工作时间 高 priority 的 alerts 看一看。低的直接忽略。
- 出事了有各种 data set, logging 。 有经验的话很快就能找到问题大致方向。熟悉了（因为出了 SEV 都要 review 的）也能知道大致会经常遇到的问题。
- 搞不定就把别的 oncall 拉起来。怀疑 downstream 拉 downstream .怀疑是谁的 change 就把谁叫起来问。纯粹需要帮助也可以拉别人起来。
- oncall 结束以后总结一下，noisy alerts 想办法调一调。有些简单的问题想一想能不能搞个 auto remediation(比如有些情况明显是 auto-scale 有问题，那就在这种条件下让他自己关了 and scale to max size 等第二天上班时间再解决。这样你非工作时间就不用搞这些了。。还有比如某些 feature 还不问题也不中要，那你监控到它挂了直接给他关了然后把 alert forward 给 onwer 等天亮了再说 等等等).

所以我觉得是需要点经验的事情。。但是多数时间一个人搞的定的。当然偶尔也有倒霉的时候。

一直都用 click. 不过看了这个 fire 感觉好棒。下次有机会试一试

对追求高性能的大型服务后台影响非常大。这些 binary 为了追求极致性能，常年反复压榨，往往把编译器能用的所有 option 已经调了一个遍，全都要重新做。另外部署的时候各种多线程的优化，kernel 层面的已有优化，甚至是代码风格的要求都会有变化。

Linux Device Drivers, 3rd Edition https://www.amazon.com/dp/0596005903/ref=cm_sw_r_cp_apa_glt_fabc_PCXGXFHSRPM7F25AT88E 我觉得是比较有意思的一个。因为你可以跟着写写 helloworld. 缺点是书太老。。你得自己 google 照着书敲代码多数不 work

@aeli 又水弹的电动的。我有朋友买过，还挺真的。。只不过一个好的玩具 glock 和真的也差不多钱。另外由于是 1:1 所以像枪套，瞄准之类的配件 甚至可以通用

公司发的 patagonia 好像前司发的也是这个

我在玩的：
$$$ 汽车。上赛道。有点烧钱烧时间，逐渐放弃了。
$$ 山地车。最近开始的，感觉很有意思。可以循循渐进。1w 人民币足够买个入门 hard tail MTB 了，可以慢慢来。
$ 我还玩枪，不过这个在国内不合法。。可以玩具枪，也挺好玩的。主要是这个非常便宜。还可以认识好多朋友。
我业余还看书。写一些有意思但是没有用的小东西。比如最近在 AWS 搭建一个小服务。这些基本属于完全免费的兴趣安好

@OMan 精辟了。就是这个道理，人能跑又便宜，就不用优化代码。

有时候就是没必要啊。等各位工资更高了，不这么卷了，人力成本上去了，自然自动化程度，工程质量就要被迫提上去。p7, p8 也不过是和您一样的打工仔。代码人人都会写，不是你写的多，写得好就能升职加薪的。到了这一步，你要给上头拿出来可以量化的成绩。
如果各位工资再高一点，并且不加班，招不到这么多小弟人海战术。业务需求还是那么多，那肯定有一帮 ledership 站出来我们要 better engineering 。

很厉害的。感觉很有意思。start 一下

一个小问题。https://windmark.pro/ "Examples" 没有 link

Dev server 256g 内存 1t 硬盘。不用 GUI 直接 ssh/mosh 进去。想要 UI 可以用 vscode 公司有和 MSFT 合作开发各种插件和技术支持。编译也有分布式编译，各种 cache 优化，不过特别大的 executable 还是非常慢。这没办法。

你这个问题大的可以写本书。个人经验，遇到的最重要的困难是：
获得并维持开发者对测试的信任和信心
具体的技术问题都会有答案，就这个是一个负责大型项目自动化测试的 tech leader 最重要的任务

对于本科一样的。可以去查培养计划。。所谓差别也就是几门课吧。
与其在这问，建议去问问所在院校学生，哪个教学质量更好。一般会学校内部有侧重的。哪个是学校亲儿子专业，就选哪个。

没有测试这个职位。连 google 都已经把 software test engineer merge into software engineer 了。大概思路就是，engineer 开发测试软件，自动化测试，调试测试系统，保证结果 SLO/SLA. 测试基本交给自动化。至于跑测试，解读结果，谁开发谁负责。