プログラマの雑談部屋 ★376

プログラマの雑談部屋 ★376 (1002ﾚｽ)
上下前次 1-新

488: 11/20(木)12:23 AAS
>今回はまさに成功することが確定しているケースって書いてるし

どこに？

489: 11/20(木)12:24 AAS
無能なやつは仕事をできるだけ振らないようにして社内ニートにさせてる方が全体で見たら仕事が増えなくて良い
無能に仕事をさせると周りの人間がフォローのために仕事が増える

490: 11/20(木)12:27 AAS
海外のSEの方が平均学位が高いんだけど、とにかく仕事が雑

491(1): 11/20(木)12:28 AAS
この話題が始まったところに

492(1): 11/20(木)12:32 AAS
botのフィルターかけてないやつもいるんじゃない
知らんけど

493: 11/20(木)12:41 AAS
>>492
公式もそれについては言及しているね

>Customers who were not using our bot score in their rules did not see any impact.

494: 11/20(木)12:49 AAS
>>491
外部データに依存しているなら、成否は外部（今回で言えばDBの構成変更に伴うファイルの肥大化）に依拠するわけで
しからば「成功することが確定しているケース」なわけもなく

495(1): 11/20(木)12:55 AAS
では、アプリケーションの設定ファイルがどういうわけか狂っていた時に
落とす以外にどうするのが正しいエラーハンドリングだったでしょうか？あなたならどうする？

496: 11/20(木)12:57 AAS
少なくともexceptでなんか書くかな…

497(1): 11/20(木)12:59 AAS
Javaでもバッチ処理が落ちるのだけは許されないってことで
特に対処法もないあらゆる例外をキャッチして潰してログだけ出して
ハンドリングしたとして処理を続行させるのは定番だけどお前らの仕事もそういう感じ？

498: 11/20(木)13:00 AAS
なんか書くだけなら誰でもできるからな
それこそなんかって出力するだけだし

499: 11/20(木)13:11 AAS
>>497
逆に怖すぎるだろ

500: 11/20(木)14:03 AAS
>>495
フォールバックやフェールオープンなど可用性を念頭に置いた設計をする
例えば外部データの異常（今回でいえばサイズ上限超過）の場合

1．直近の正常設定にロールバック
2．ボット判定機能を一時的に停止
3．エラーログ吐いて通知

機能停止などに関しては安全側にどれだけ倒すかのサービス判断
それでも回復不能な場合にプロセス停止
少なくとも「unwrapしてパニック」みたいな「初手で落とす」はサービスの性格からして普通に悪手

501(1): 11/20(木)14:08 AAS
バグった設定プログラムが生んだ設定が原因でしたって調査後の後付だからわかってるけど
実際この行でパニック=設定ファイルが壊れてる！って単純なもんじゃねえし勝手に設定戻して動くって怖くね？

502: 11/20(木)14:20 AAS
本番クローン環境でテストするやろ

503: 11/20(木)14:26 AAS
っていうか最終的に落ちたプログラムがRust製だから嫉妬で叩かれてるけど
SQL修正ミスってそれをテストで検知できず壊れた設定配布したプログラムは何製なの？

504: 11/20(木)14:28 AAS
しっぽりしてえなあ

505: 11/20(木)14:30 AAS
>>501
>勝手に設定戻して動くって怖くね？

つ >可用性を念頭に置いた設計をする

506: 11/20(木)14:35 AAS
むしろ「外部データが正しい = 成功するからunwrap」のほうが設計としてはよほど怖いと思うのだけど

507: 11/20(木)14:36 AAS
盗んだコードでバグを出す

508: 11/20(木)14:36 AAS
客とのファイル送付に未だに謎のサービスに月5000円払ってる会社
そんな流出したらヤバいような極秘情報扱ってるわけでもないのにgmailでいいですやん

509: 11/20(木)14:42 AAS
Gemini「ごちそうさまでした。」

510: 11/20(木)14:56 AAS
生成を自動化してるからまるで他システム連携みたいに感じるけど
俺らが位置づけ的には手作業で置く設定なんだろう

511: 11/20(木)15:24 AAS
１２月のカレンダー無慈悲すぎひん？

512: 11/20(木)17:26 AAS
感想するかすべてを無にして死ぬかだろ