「UNIXという考え方」を読んだ - えいのうにっき
以前に、kabuという半分ネタのCLIツールを作ったことがあった。Goの手習いに、という目的もあったのだけど。 blog.a-know.me 今でも月に一度は使うくらいの（自分にとっての）便利ツールなのだけど、このコマンドについて、「コマンドとしてあるべき姿」といった観点で、同僚からいくつか指摘をもらうことができたことがあった（「ネタにマジレスだけど......」と前置きしつつとても丁寧に添削してくれた :pray: ）。 引数がない場合は標準入力から取ると良い いま標準出力に出してるようなメッセージは、標準エラー出力に出すと良い。そうすると他ツールとの連携がしやすくなる -verbose オプションを設け、それがonのときだけ出す、などとする 候補が見つからなかったときは、non zero exit statusで終わるのが綺麗 こうした指摘は大変ありがたい一方で、「そういう感性みたいな
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
