各种工具用下来,还是 Jetbrains 家的 Datagrip 最好,差不多支持所有数据库,PG,MySQL 等等。
https://www.jetbrains.com/datagrip/
欢迎参加 Ruby Tuesday 上海线下活动,每次活动赠送一个 Jetbrain license。
非常感谢你提供使用方法,但我问题是“为什么用 foreman?它和 systemd 的渊源是什么?”
此外我不打算使用它,有两点原因。
1. capistrano-puma 和 capistrano-sidekiq 都提供了脚本生成 systemd 文件,我感觉没有必要再引入一个 gem 做抽象。
cap production sidekiq:install
cap production puma:systemd:config
2. 我基本上不会在本地起守护进程,通常都是开一个新的 terminal 的 tab,然后运行 bundle exec sidekiq
你通常会在本地使用 foreman 吗?
我刚才试了一下这个命令
bundle lock --add-platform jruby
bundle lock --add-platform mingw
结果发现 Gemfile.lock 中的 nokogiri 下载了好几个版本。
如果有些版本需要编译,我的 Mac 电脑下载了 windows 版本,也无法编译啊。
难道 Gem 不同 platform 的版本,都是预先编译好的吗?
(请熟悉编译的同学指导一下)
cc @rocLv
这是 bundler 作者的答复,但是我还是没 get 到他的点。
https://github.com/rubygems/rubygems/issues/4269#issuecomment-758564690
Hi @schneems!
So, I've been sleeping on this issue, and I think what we have now is quite good to be honest. Let me try to explain why we did this, and why I believe it's a good thing.
Context
In previous bundler versions, bundler didn't consider platforms for resolution at all. What bundler would previously do is to resolve dependencies without considering platforms, and then at installation time, pick up platform specific variants with the same version as the resolved version if they exist. That approach had several problems:
- Resolution correctness. Resolution would be incorrect sometimes, since it can happen that for the same gem and version number, a platform specific variant can have different dependencies than the standard variant. Without considering the specific platform for resolution, we might not get a valid set of dependencies, since new unconsidered constraints can be introduced after resolution. This is rare, but not that rare. For example, nokogiri recently released prerelease versions meeting this condition.
- Safety. Not only resolution is invalid, but the previous approach meant resolution was not actually fully locked. Say you're using
foo-1.2.0
in your application. You have a lockfile specifically locking foo to 1.2.0, you test it in CI and in your staging environment, and it's all good. Then someone pushesfoo-1.2.0-x86_64-linux
to rubygems.org, a platform specific variant for foo 1.2.0, that, for example, has a critical bug, or that was pushed by a malicious actor. Then when you deploy to production,foo-1.2.0-x86_64-linux
will be installed because it matches the running platform more closely. To me this is totally unexpected, if you have aGemfile.lock
file, no third party release should be able to change the set of third party code that you run.Resolving for the specific running platform and recording the exact resolution in the lockfile fixes the above issues.
Current situation
- I believe we can improve on it but the current error message is not too bad, and allows for easily fixing the issue.
- This error will only happen if you are using bundler in frozen mode (with
BUNDLE_FROZEN
orBUNDLE_DEPLOYMENT
). If you're not using frozen mode, then bundler will automatically re-resolve using the running platform if it's not already in the lockfile. If you are using frozen mode, I believe it means that you explicitly want to avoid the second issue I mentioned above, so... an error if that can't be guaranteed seems appropriate.Yes, some tutorials could be broken by this, but only under some circumstances:
- If the tutorial provides a
Gemfile.lock
then bundler will respect that. Meaning, if the lockfile was generated with previous bundler versions, bundler will still fallback to how it worked in previous versions. But if you generate a lockfile from scratch, then it will use the more secure and correct mode.- If the tutorial does not set frozen mode, then bundler will re-resolve and just work as mentioned above.
- If the two above are not met, yes, things can break, but just like they could break if there's a new Rails release or whatever dependencies the tutorial uses. I believe that's acceptable, but I'm willing to help updating any popular tutorials that we detect to be affected by this.
Please let me know what you think.
现在大家都上云了,通常整个 flow 是这样的:Application Load Balancer -> Nginx -> Puma
今天我也有类似的疑问,如果有了 ALB,还需要 Nginx 吗?
看完 2 楼的回答,豁然开朗,Nginx 还是需要的。
很好奇 shopify 是如何集成各个 shopify app 的。有空我也学习一下,借鉴一下他们的实现思路。
以下两种情况会导致你所说的问题。
你推送 id 进入 RabbitMQ 的逻辑用的是 after_save
而不是 after_commit
.
通常 DB 有四个级别,serializable, repeatable read, read commit, read uncommitted. MySQL 默认隔离级别是 repeatable read
,不同 transaction 内部未提交数据,对于其他 transaction 不可见,避免了 dirty read, phantom read 的问题。after_save 时,数据库的事务还没提交,其他事务是看不到你创建的记录的。
数据库的隔离级别是一个很有意思的话题,是很多面试必考题目,值得学习。
解决方法:使用 after_commit
就可以避免类似 bug。
primary 和 replica 之间通常有 0.5-10 秒的延迟。在延迟很高的情况下,你的写入成功了,但是从库却没有数据。
解决思路有三种
发送消息时,延迟 10 秒。比如像 sidekiq 的 MyJob.perform_in(10.minutes)
你可以强制这个任务读写都使用 primary database。
使用计算和存储分离的数据库,比如 Aurora,数据库节点之间 0 延迟。
@oslivan-github @xmonkeycn @ericguo @kowalskidark @zfben @lifeixiong
因为台风的原因,本周二活动延期。
我把你的主题加进去了。
给邻居点个赞。
hugo 也不错。
真是愁啊,本来今年想学学前端,结果前端又出了幺蛾子。
(就在我发这条评论时,又有个前端工具诞生了)
过去为了优化前端的加载速度,大家会把把很多小 javascript 打包为一个大文件。
HTTP/2 支持多路复用,这让过去的最佳实践变的没有意义。这是大家去掉 webpack 的原因之一吗?
如果还没用 docker 的话,可以用这个 gem 部署。
https://github.com/capistrano/capistrano
如果 Docker 化了,部署之前需要打包 image,push 到 registry,略微麻烦一点。
炮哥去 PingCAP 了?
👏
非常感谢今年的组织者,我能把门票吃回本了。
看的我好饿啊。
刚才看了一下,Terraform Cloud 免费版本有 5 个名额的限制。
原来 Terraform Cloud 已经免费了呀,那真是太好了,我现在用的 S3 保存 state,DynamoDB 做 exclusive lock
其实文件的组织方式,只是方便人类组织代码。对于 terraform 来讲,它会把所有的 .tf
文件合并为一个。
财务自由(被动收入超过工资收入)是这个社会灌输给普通人的谎言。
创业挺好的,我也在一个创业公司,每天做的东西也很有趣。但是把财富自由的信念寄托在创业上,是它不能承受之重。
赌博的人多了,难免有个别人运气好,连续都赢。但大部分人都是分母,钱来得快,跳楼更快。
等流动性恢复正常时,到时候再看看谁在裸泳吧。
大部分人都是平凡的打工仔,对于普通人而言,控制自己的欲望最切实可行。
所以我觉得这个老程序员说的才是实话:合理储蓄,不要过度消费。在自己的能力圈内持续的投资,比如买套房,或买点低费率的 ETF。
如果你用的是 Aws 全家桶的话,AWS certificate manager 可以自动续签证书,自动更新 cdn 和 loadbalancer 挂载的证书,而且免费。
一开始我想的方案:自己用 jenkins master 起多个 node 并行跑,用 amazon spot instance 做 jenkins 跑测试的 node。
但是折腾起来太费劲了,估计我得折腾一个月,还需要牵扯到日后的运维工作,不如花钱用 circleci 简单。程序员一个月的工资够 CircleCI 跑 2 年了。