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 是什么意思, 方便给个例子了解下吗?

@binux 我完全同意你的观点, DynamoDB 本身不应该出现在这个 stack 里面, 这样我们也不会踩这个坑, 说起来可笑, 虽然我是 infra 工程师, 但是一个资深但没怎么用过 Cloudformation 的前端程序员同学不顾我的多次抗议强烈要求所有的资源放到一个 stack 里面去, 我实在是拿这个人无语.

好多 AWS 同学冒泡了, 感谢各位捧场.

@whileFalse 之前我想的是把这个大的 stack 拆掉, DynamoDB 的生命周期和 lambda 本身就不一样, 这样也能绕过这个问题, 而且架构会更合理. 也看到讨论说 changeset 是更被推荐的部署方式, 不过我更期望这个明显的 bug 能被修掉. 问题 2 我们目前准备去掉这个宏, 因为不知道后面还会不会再踩坑. 问题 3 我们现在的部署不是 blue-green 的, 不过后面有时间应该会做. 至于验证 cfn 模板, 真觉得是目前 cloudformation 自带的验证只检查语法, 实在不够用. 能增强一点儿就增强一点儿, 至少构建出来的模板会更可靠些.

@timle1029 我看到文档里面有提到`cloudformation validate`仅检查语法, 我也认同你提到的, cfn 验证唯一靠谱的办法是在沙盒环境中部署. 但是这样未免测试时间也太长了. 我们的模板里还有 Cloudfront, 一个 distribution 部署下来半个小时是跑不了的. 所以我们这儿说增强的目的是能在 30 秒内尽最大努力测试模板里面是不是有问题, 不求一定能找到坑, 只求能够把开发同学的低价错误给抓出来. 至于 cfn 特性添加太慢的问题, 有兴趣也可以围观 reddit 上这个贴: https://www.reddit.com/r/aws/comments/as21r7/cloudformation_feature_support_lag_is_way_out_of/

@laxenade 我们给 lambda 的 Role 里面也添加了不少的 policy, 还好没遇到坑. 我现在准备全部去掉这个宏, 希望能够好些.

旁敲侧击一下, 不鼓励不反对. 的确有能力有人品, 不过毕竟是拿着东家的工资给前东家做事.

你是不是对漫游有什么误解...

虽然我只看过目录, 但你这些技巧或者说知识真的都只是入门级的, 对于没学过 Linux/Unix 的人可能有点用...