メモリもストレージも潤沢でないパソコン、仕事にならない
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
KDDIとローソンが連携 ドコモのポインコ兄弟CMの「悲哀」 - ライブドアニュース
https://news.livedoor.com/lite/article_detail/17540252/
ASCII.jp:松屋のビーフシチュー、お肉とろとろでごはんに合う (1/2)|モーダル小嶋のTOKYO男子めし
https://ascii.jp/elem/000/001/994/1994772/
"Responsible Disclosure" doesn't mean "downplay at
maximum to avoid damage to the bottom line"草
ThinkPad A275を1ヶ月間使ったレビュー|みぞらぴ|note
https://note.com/mzrapid/n/n7816792310bb
この人いるじゃん
Sony Bank WALLETがGoogle Pay対応。スマホかざしてVisaのタッチ決済(Impress Watch) - Yahoo!ニュース
https://headlines.yahoo.co.jp/hl?a=20191218-00000170-impress-sci
アプリから連携できるやつはじめたの
MastodonとかのRailsでSAFETY_ASSURED=1つけないとdb:migrateできないのは、まぁそのコミット書いた人のミスでバグみたいなもんなんですが、ヤバイのは、じゃぁいつもつけとけばいいんだねってことで.env.productionに書いたり、投稿やブログで「これをつけます」とか書いて、それをみんなが真似することであります。
これ、Strong Migrationsっていうgemによるもので、安全でないデータベースへの変更を開発段階でキャッチして、より安全な方法で書こうねって奴で、配布前に潰しておくものなので、配布後にひっかかっちゃダメなワケです。
で、SAFETY_ASSUREDという環境変数はこれを回避するもの。なので、常時つけといたら安全装置の意味がないのです。まぁ、デプロイに失敗しなくなるのでありがたいっちゃありがたいんですが、たとえばデータベースを長時間ロックする奴とか、うっかり実行してしまう。
今回のbackupsテーブルは、そもそもメッチャ小さいので、型を変更しても瞬時に終わります。
statusesでやったらDBロックされて固まります……。