後に客が並んでるのは、レジに充分な数の店員を配置しない、店の問題であるので、客が気にすることではない。
No.32697 店員「当店のポイントカードはお餅でしょうか」
ルールを作ることと、それを使って別のルールに対抗するのは全然別の話だと思うがなあ。
ルール - UEI/ARC shi3zの日記
一徹
〒103-0005 東京都中央区日本橋久松町１０７
現代的には「 あなたといっしょだと 月が綺麗ですね」と読めばよいという解説があったけど、どこで読んだんだっけな。
「i love you」＝「月が綺麗ですね」 - Yahoo!知恵袋
まあ継承に関しては「親クラスへの機能追加が頻繁に発生しないこと」が重要だと考えている。そのためには充分に枯れた概念(例えばWebのMVCフレームワーク)の実装だったり、
ごく限られた責務のみ実装していることが必要になると思うのだけど、後者を実現するためにはmixinとしての多重継承がないと実用的ではなさそう。
共通部分を親クラスにまとめようという発想は悪手。共通部分は必要に応じて増えていくものだし、共通だと思ったら実は例外があったりして複雑になる。具体例を挙げると、親クラスにメソッドを1つ追加するときには、全ての子クラスが同名のメソッドを持ってないことを確認する必要がある。
特定のプロダクト向けのライブラリ群、あるいはフレームワーク的なものを作って、どう育てていくかというに興味がある。というか、あった。改めて考えてみれば、そういうのが必要になったのは今まで関わってきたプロダクトが少々特殊で、データの持ち方が普通のRDBではないためActiveDirectory系統の技術が活用できないとか、簡単ログインや携帯の画面のためにコントローラの共通部分を厚くする必要があるとか、ビューの機能を厚くする必要があるとか、まあそういう事情があったわけだ。
そういう環境を離れてみると、枯れてる技術の組み合わせで多くのことが実現できるんだよね。そういう事情があってフレームワークを作っていくことにあまり興味がなくなってしまった。
一方で、パッケージソフトウェア的な方向に興味が出てきた。共通ライブラリを作って複数の場所で使うというのと実質的にはあまり変わらない気もするけど、1つのソフトウェアを作って複数の場所で設定だけ切り替えて使えればいいんじゃないかな、みたいな。そこまで一般化したソフトウェアの設計は困難だろうとは思うんだけど、まあやってみたい話ではある。
vendor の命名に困るんだよなあ。英語のニュアンスが不明なんだけど、「現時点での開発者の名前」である必要がなく「最初の開発者の名前」という解釈でいいのかしらん。
PSR-0 を和訳してみた
mixinはよい継承。PythonでもJSでも大活躍した。悪い継承もあるけど、あれってなんなんだろうなー
・Template Method Pattern はユニットテストの体制を整えるのがめんどい
・親クラスに頻繁に変更が入るのは互換性がしんどい
というのはあるな。
ScalaでDIというかServiceLocator的な名状しがたい何か - Yamashiro0217の日記
#!/usr/bin/php
<?php 以下略
としてPHPをCGIとして使っていた我々に死角はなかった。
CGI版PHPにリモートからスクリプト実行を許す脆弱性(CVE-2012-1823) | 徳丸浩の日記
引用の場合は「法令上の」とは言わなくても著作権法でいうところの引用のことを言ってる例をよく見るけど、個人情報の方はそうでもないのかなあ。
もし図書館の貸出履歴が個人情報でないとすれば - 一本足の蛸
Atom Feed