如果日韩不能部署后端服务器, 依赖网络传输的话, 可以试试 GCP 的服务, 看看是否能满足要求.

平均来说, 三家里面, G 家的网络好些.

你们是只要 CDN 服务还是后端服务器也要部署在日韩 /欧洲?

只要 CDN 服务的话自己找大一点的 CDN 提供商, 另外自己在欧洲 /日韩多找几个不同厂商 /地点, 买 VPS 测试下速度.

如果要连服务器也部署在这两个地区的话, AWS/Azure/GCP 里面挑一家吧.

自己写一个脚本把文本全部提取出来然后爱怎么搜怎么搜? 有这功夫不如克服下心理对 sportlight 的不悦之情...

各个型号都测试下, 找个时间允许范围内最省的.

测试一下也就花几块钱, 不贵的.

@0hey0 您是不是眼神有些问题?

先问是不是, 再问性能如何, 上面这么多无脑 ping 的是在送金币吗?

numpy, 还是 C 的

据我理解(因为真没用过)第一个备份应该是全备, 后面都是增量. 全备的话这种 block 级的存储是不管里面用没用都会备份的.

于是又想起来我的 nano 4...

我也觉得不应该把这个装饰器放到这个类里面, 可以放到含有这个类的文件里面. 当然除非你这个文件里面已经有很多很多的类了, 那么我个人会写一个 utils.py 文件, 来放这些工具类的东西.

关键是, 我看不到这个装饰器里包含任何类属性 /方法的地方. 所以逻辑上这个装饰器不属于这个类.

当然, 如果你实在想要这样做, 可以参考这段代码:

https://gist.github.com/xiaket/3853a44dc02b127b5f8cac762f889b1a

为了孩子

为了实现自己想要的效果还专门用 golang 写了一个程序什么的, 这儿是当时写下的 blog: https://blog.xiaket.org/2018/bash-prompt-in-golang.html

希望这个 asciinema 链接能工作: https://asciinema.org/a/g03MQikLqBg8UcHBCd5yPFJB3

要求是在 50 毫秒内能够尽量多给出有用信息.

一直 omnifocus

@zhshch 这两个都谈不上特性, 而只是个人喜好而已, 而且在 Django/Flask 的框架下, 也可以做到.

我支持学习为出发点的造轮子, 不过先全面读一下这两个框架的源码才能取长补短.

有啥(相对于 Django 和 Flask)你想要加的特性吗? 还是只是想自己写一个学习一遍?

@clavichord93 等作者发善心更新... lol

我现在都用 kitty 了, 比 iTerm2 实在是快一圈, 而且配置文件比 iTerm2 管理方便太多了.

@whileFalse 感谢回复, 现在这个项目开发人员也就五六个, 所以还没到用不同 iam role 部署的程度, 不过有比较成熟的部署脚本了, 搭建个人 Stack 比较方便. 不过要做完整的部署, 即使不考虑创建 Cloudfront 层, 仍然快不起来, 因为 Cloudfront 的 cache invalidation 仍需要五分钟或更多.

@laxenade 我们之前的做法是在 cfn 上加一层 python 逻辑, 部署的时候再是一层 Jenkinsfile 的逻辑. 不过由于人手不够, 有些新项目(比如用 SAM 的这个)就没有用这种做法, 而是直接拿 cfn 搞. 外面部署逻辑套一层脚本, Jenkinsfile 里的逻辑也简化了很多. 我周围的所有同事使用的方式都是你所说的第二种, 因为在 cfn 的 best practice 里面提到, 不同生命周期的资源应该尽量放到不同的 stack 里面去. 我能理解你说的多个 yml 拼成一个完整的 stack 这样的做法, 因为这样可以把相似资源的集合放到一个文件里面去, 方便重用. 不过我觉得这样仍可能有坑. 多个 stack 在部署时会有问题, 在于中间某个 stack 部署失败可能影响整个 app 的稳定性, 我们的解决方案是通过脚本来实现整体部署. 每次部署一个版本, 如果中间有一步出错, 全部回滚. 这套逻辑在线上也已经跑了一段时间, 稳定性还可以. 我不太明白你说的服务不支持不是 cfn managed S3 bucket 是什么意思, 方便给个例子了解下吗?