おしゃーようやくコンパイルできたぞ!
そしたら考えられるのは生成しているクライアントに問題があることくらいしかなくない?
あかん,何もわからなくなってしまった.迷子や
手元から叩くと成功するということが判明してしまった.余計わけわからんわ,なんでcontrollerから叩くとタイムアウトするねん
etcdを殺したときにmasterが複数台エラーになるんだけど,その状態から復旧できないパターンがあるなぁ
この件,codecovから顧客情報まで抜かれたの,結構珍しいと思ったけど,ソースコード上に顧客情報乗っかってたのね
GitHubに上げてたソースコードに顧客情報が含まれてたんだ.それにしてもCodecovから漏れるのはすごいな / 他8件のコメント https://t.co/CStIReghs7 “「Codecov」への第三者からの不正アクセスによる当社への影響および一部顧客情報等の流出について | 株式会社メルカリ” https://t.co/q7ZvjrZrvD
kubeletのオプションから--network-pluginとか--cni-conf-dirが非推奨になるけど,これってもともとdocker-shimsでしか使ってなかったの?ということはcontainerdやCRI-Oを使っている場合にCNIのconfとかってどうやっていじればいいんだ?これってCRIの方になにか定義されているの?それにしても,その設定値をkubeletからいじれなくていいのか?
あーFISでもapi-internal-errorとかだとdurationを指定できるので,これは一定時間エラーを出し続けることができる.難しいなぁ
あーStop conditionはあくまで中止の条件であって,終了条件ではないのか.targetにしていたものがcompleteしたらstop conditionが上がってなくても終了しちゃう
FISって終了条件がむずいな.インスタンスを殺し続けてほしい場合は単にStartするだけじゃダメなのか.現存するインスタンスを殺し終わった時点でexperimentがcompleteになってしまう.Stop conditionにcloud watch指定したらもっと長期間殺し続けてくれるかな
それはそう思う.自社サービスのスタートアップの場合,品質を上げて利益を得るのは将来の自分たちだけど,受託開発で品質を上げ続けてもそれが利益になるのか?というのは怪しい.受託の方は全然温度感わからないので,そういうのを評価してくれるところもあるのかもしれないが
秤についてはt-wadaがいつもいいこと言ってるので,このへんに全部書いてあるとして.結局短期的な機能追加は得られても,長期的には品質を下げ続けるので,成長したときに苦労しろよって話でしかない
https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition
でもマジで書かない派の人は平時に何言ってもあんまり響いてないので半分諦めている.そういう意味でも "でもそれは、スタートアップだからでもスピード優先だからでもない。自分達が未熟だからで、そこには向き合うべきだと考えます。" というところは同意.書かないのではない,未熟だから書「け」ないのである
それはまぁ一人で開発してるならそうだし,別にいいんだけど,仕事で複数人でやるとなると状況はまったく逆転するよ.他人がかいたコードを確認する時間でテストコード一つ書けるよ.っていうのが人数分発生する
実際最近副業で入ったスタートアップが,全然テストがない(テストがないからCIという概念もない)んだけど,そのくせパフォーマンスが悪いからリファクタリングしてほしいと言う.リファクタリングするのにテストがないとはどういうことなのか.
PRを出すと毎回CTOが手動でpullして本番DB相当のデータを用意してポチポチいじって「ここでバグりました」みたいな報告を上げてくる.これを修正するたびにやるので,普通に1PRをマージするのに1ヶ月以上かかる.こんなのでいいのかスタートアップ?と思ってるんだけど,本人は危機感がまったくないらしく,テストを書く気もないらしい
一人ならともかく,複数人で開発するようになると,テストなしで他人のPRのレビューしてマージするのがかなり怖くなる.それをいちいち手元やdev環境用意して手動確認する暇がスタートアップにあるのか? / “「スタートアップだからテストを書かない」は正しいか - An Epic…” https://t.co/HvZV75BAjA
fedibirdがemoji_reaction対応した結果,パースできないイベントがいっぱい飛んできている
星野源といえばSAKEROCKやってたイメージしかないのに,いつの間にか結婚してたし,いつの間にか解散してた
削除系のレビューは,削除範囲が正しいかの判定をするためにかなり広範囲のコード知識が要求されるんでむずかしいよね.とあるメソッドを削除しても問題ないかは,参照先をある程度把握してないと判断できない.
kube-apiserverの--client-ca-fileと--etcd-cafileって別のCAであっても問題はないよな?つまりクライアント認証に使っているCAと,k8s内のコンポーネント同士が通信する際のCAって別物でいいはずだよな
あーわかっちゃーtruncateするときにschema_migrationsまでtruncateしてはいかん.これマジ大事
Subway Tooterはいいぞ、いいぞ / 他37件のコメント https://t.co/961BZ9snMU “突然、紹介されるオススメAndroidアプリ集” (167 users) https://t.co/ByuLz4m8MV