RDBMSが強すぎる件 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
以前、「RDBMSを採用すると、無料で外部キー制約とかチェック制約とかトランザクションが付いてきてオトク！！！」という発言をしたことがあって、その考えは今もあまり変わっていない。 RDBMSは単なる便利な箱じゃなくて、データの整合性を守るための仕組みがたくさん備わっている。もちろん、これらの仕組みは「タダ」で使えるわけではなく、データモデリングを学んだり、データ構造を学んだりという「投資」の結果うまく使えるようになるものだけれど。 ところで問題（？）は、RDBMSは強すぎる、ということです。 たとえば、トランザクションの話。「本質的にはトランザクション整合性である必要がなく、遅延してあとから整合性が取れてればよいような処理（つまり、結果整合性でよいような処理）」というのは、意外と多い。 多くの開発の現場では、トランザクション整合性が必要とされるか結果整合性でよいのかについてあまり考えず、「
Re: チャットとかでパスワードを教えるとき暗号化すると良い - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
この記事。3ヶ月以上前のやつなんだけどちょうどいい題材なので今更これに反応してというか勝手に乗っかって秘密鍵と公開鍵のことについて書く。 この記事では同じキーを使って暗号化と復号化を行っているけれど、これだと「じゃあそのキーをどうやって共有するの」っていう問題がある。ネットワーク越しにデータのやりとりをしているけど、結局キーをやり取りするためには電話とか口頭とかでそのキーを伝える必要があり、それならばパスワードを電話や口頭で伝えるのとあまり変わらなくなってしまう。あるいは、件のブログに書いてあるとおり「事前にキーを共有」しておく必要がある。 人間同士のやり取りならば例えば「キーは俺の電話番号ね〜」とかなんとかで一応キーを伏せたままやりとりできるけど、たとえば機械と機械の間で暗号化と複号化を安全に行うためには、事前に安全な形でキーをお互いに持っておかないといけない。 そんなわけで、じつはこの
後方互換性についてさいきん考えていることを書く - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
後方互換性を守るべきブロダクトと、そこまで気にしなくていいプロダクトがあると思っている。 後方互換性を守るべきもの これはもうシンプルで、「依存関係の下のほうにあるプロダクト」。下のレイヤーを担うことを狙っているものについては後方互換性を守って行かないとみんなが困る。多くのライブラリがすでに依存してるライブラリとか、あとはまあデータフォーマットとかも変わるとそもそも溜め込んだデータとかが使えなくなったりするので困る。 Perl5 が後方互換性を保つことに熱心なのは、そもそも Perl がシステムツールによく使われていることと無関係ではないはずだ。system perlのversion上げたらシステム動かなくなりましたみたいなことになったら困るからかなり気を使ってる。その点、Python が 2 系から 3 系に移行するときにばっさりと後方互換を捨ててしまったのは失敗だったんじゃないかなと私
状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない？横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になり鬱になり死
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
middleman 良かった - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
