神様の目でみたら…

元ネタというかきっかけの一つは、ここ。
http://www.fnn-news.com/news/headlines/articles/CONN00226921.html

(アンケートには、教師の対応の中に「紙を食べさせられた、首を絞められた、一度先生は注意したけれども、そのあとに一緒になって笑っていた」と。教師としてありえない対応だと思うが?)
これが事実なら、加害者です。教員もいじめていたことになる。

まぁ、近しい事象は他にも多々。
近しいってのは
・何かが目の前で行われているんだけれども
・助けをさしのべない
あたり。

で…何度か引用しておりますが、今回もパタリロから。57巻です。タイトルは「名探偵の犯罪」。

パタリロ! (第57巻) (花とゆめCOMICS (1435))

ミス＝メープルという、少しお年を召したご婦人がいらっしゃいまして。パタリロはそこに招待されます。年に一度の「名探偵が集まっての親睦会」です。
そこで殺人事件がおきます。まぁぶっちゃけると「ミス＝メープル」が、参加者の一人を殺害したわけなのですが(厳密には違いますが、その辺は今回の話とは関係ないのでオミット。興味がある方は是非単行本を読んでみてください)。

殺されたジレット神父は、殺害される前日の夜、こんな話をしてました。
「皆さんは血なまぐさい話題を平気で口にされるが、あたくしのような平凡な聖職者にそんなまねはとてもできません。
　二年ほど前でしたか、こんな事件がありました。
-中略-
　食事も終わり、ワイン ワインですよ をたしなんでいたころ、、そばにいた二人の若者が口論をはじめ
　もみあっていたかと思うと一人が足をすべらし、その場に転倒しました。
　さあ それから救急車がくるわ 警察がくるわで大さわぎ
　その場はコッソリぬけだしましたが、後日聞いた所によると、警察でその晩の目撃者を探しているとのこと。
　もちろんあたくしは名のりでませんでした。
　なぜってあたくしは聖職者ですよ
　そんな犯罪まがいの事件に関わるわけにいかんのです。
　聖職者たる者、常に潔白でなくてはならないのです。」

　ミス＝メープルは、こんな話を始めます。
「署長さん、覚えておいででしょう。
　二年前、私の息子が酒場で友人と口論をし、そのあげくに相手を突き倒して打ち所が悪かったために友人を死なせてしまった事件を。」
「たしかに、あの時ご子息は、相手が足をすべらせたのだと言い張ったが。
　陪審員は信用せず有罪の判決をくだしたのです。
　そして…お気の毒だが、ご子息は自分は潔白だという遺書を残して首つり自殺を図り、一命はとりとめたが、その後、警察病院でずっと意識不明の状態が続いているのでしたな。」
「あの折、息子は酒場の奥にもう一人お客がいて、その人が一部始終を見ていたはずだと言いました。」
「そうそう。しかし目撃者は現れなかった。」
「ジレット神父こそが、その目撃者だったのです。
　ジレット神父は何もしませんでした。
　でも何もしないことによって犯す罪もあるのです。
　人間の作った法律ではいざしらず神様の目から見れば神父がその手でロープを息子の首にまきつけたのも同じことです。
　あの時、この人さえ名乗り出てくれたらと思ったら、わけがわからなくなり気がついた時には拳銃が手の中に…」

この手の話は、割合とちょくちょく耳にします。
かつ、厳密に考えると「とても難しい」所を多々含んでいます。
ただそれでも。「十分に助けられる可能性があった相手」を見殺しにするってのは、やはり色々と「良心の呵責」とかがあるものなのではないでしょうか？

もちろん「手助けをすることによって自分まで一緒につぶれてしまいそうになる」ような状態で「手助けしろ」とかは全く思いません。
二重遭難してもしょうがないですし。

でも。
まぁ「神父が酒場にいっとったんかい」って突っ込まれるかもしれないにしても「こんな事がありましたよ」くらいは、ジレット神父も告げてよかったんじゃないでしょうか？
とりあえず「ワインは嗜みましたが、ワインはキリストの血であって、酒ではありません」とか一端逃げつつ心の中で「あぁもうちょっと生活態度改めよう」って思い直すよいきっかけにしてみるとか。
いじめのほうは…正直状況が見えないすぎるのでなんともですが、少なくとも「見ているのに見ていないふり」は、その空間の責任者として、あまりにも無責任に過ぎる態度なんじゃないでしょうか？

法律で罰せられることは、多分、ない事象だと思います(法律疎いんで、もしあったらごめんなさい)。
でも「だから無問題」とは、あまりにも言いにくい状況ではないでしょうか？

昔は「おてんとうさま」なんて言い方もありました。
神様の目から見た時に、少なくとも「胸を張って」答えることができるように。「何もしないという罪」に落ちないようにしたいなぁ、と、常々思います。

…いやまぁ「やっても無駄だったからあきらめて見限って見捨てる」ってのは時々あるんですがね B-p

CSRF実装の一案

注意
結構「状況限定」なので、本当に「一案」程度。

前提
セッションIDが定期的に変わる。だから「セッションIDをtokenに」しにくい。

一案
「消すのが面倒くさければmemcachedにすればいいぢゃない」作戦

CSRFで引っ掛けたい画面を「画面A → 画面B」の遷移である、と仮定します。

画面Aでの処理
・ディードなIDを作成( http://d.hatena.ne.jp/gallu/20120607/p1 のコメント参照。トークンそのものは http://d.hatena.ne.jp/gallu/20120402/p2 を参照)
・ディードなIDをkeyに、ユーザIDをvalueに、寿命を10分(この辺適当)にして、memcachedにぶち込む
・ディードなIDをhiddenに埋め込んでおく

画面Bでの処理
・hiddenからディードなIDを取得
・memcachedに確認
・ユーザIDを確認
・all OKなら
　・memcachedの該当情報を削除
　・OKな処理をぶちかます

こんな感じ？
とりあえずざっくりだけど、ヘンにゴミもたまらないし、楽に実装できるんじゃなかろうか、って思うんだけど、どだろ？
あんまり高圧だともうちょい考えたほうがよいかもなのだけど…結構な圧まではいけそうな気もする。

今度、チャンスとタイミングを見計らって、検証でもしてみますか。

5冊目！

あぁ４冊目と誤認してた５冊目だわ。
１〜３冊目は http://d.hatena.ne.jp/gallu/20091119/p1 を、４冊目は http://d.hatena.ne.jp/gallu/20100724/p1 をご覧ください。
で、待望の５冊目は、こちら。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

近しい書籍はいくつもあって、あわせて読みたいところではあるのですが。
「コメントの書き方」と「コメントの重要性」は、ここ数年、おいちゃん的には「いや増しに増している」重要関心事項なのですが…よもや15章中で2章もの分量をそこに割いているとは…ふぁびゅらすま〜〜っくす！！！

毎度のことで恐縮ではございますが、この書籍について申し上げるべき一言はたった一つでございます。

「読め」。

いやなんていうか…「美しい」書籍でした。えぇ。
発売数日で重版もかかるわな、こりゃ(笑

「学習と継承の流れ」のためのSECIモデル

名前をすっかりとド忘れするので。
このBlogに最もふさわしい「おいちゃんが記憶から落とすのを防ぐための」メモ書き。
検索ワード的には…多分「暗黙知と形式知、教育または教える」あたりで自分はきっと検索をするはず！！

閑話休題

覚えておきたいのは「SECIモデル」っていうナレッジマネジメントの仕組み。

・「共同化」(Socialization)
・「表出化」(Externalization)
・「連結化」(Combination)
・「内面化」(Internalization)

という円環で、教え教わるものらしい。…あぁなんかすげぇよくわかる。

http://www.atmarkit.co.jp/aig/04biz/seci.html
http://nedwlt.exblog.jp/15786516/
http://www.atmarkit.co.jp/im/carc/serial/world/30/03.html
http://ja.wikipedia.org/wiki/%E3%83%8A%E3%83%AC%E3%83%83%E3%82%B8%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88
あたりが面白げなURI群。
で、整理。

まず「師匠から弟子」に、共同化によって「暗黙知」が「暗黙知の状態で」伝授される。まぁすげぇ大事なところだし、多分一定レベル以上において、この部分がないと「そこから先に進まない」。

ただ「全部暗黙知」はさすがに色々と歪みやすいので、そのうち可能なモノについて「明文化」「公式化」とかやって、形式知に落とし込みます。
頭んなかで整理できる部分も沢山あるんじゃないかと。もちろん、所詮明文化したものなんで「古人の糟魄」な部分があるのを否定しないけど、それでもなお、部分的にでも「形式知」に落とし込むのって大切だと思う。

で。あちこちの(場所/時間/人)形式知を編纂することで「串刺しに見えてくる」ものなんてのもまぁ出てくると思われるわけなんですね。
あと、明文化したモノを「読む」ことで、知識を得るための「入り口」に入ることができる。これは「自分の今までの経験や知識」と「新しく読んだ知識」との連結、って見方もできると思う。

ただ結局「読んだモノは読んだもの」でしかなくて。形式知を入り口にして、かみ砕いて習熟して理解して守って破って離れて、その結果として「得た知識を、自分の中の暗黙知として受け入れる」事ができて、初めて「理解が出来た」って所に到達をするんだと思う。
ここで初めて、形式知(に付随してくる暗黙知込みで)を「自分の暗黙知」として受け入れることができるんだと思う。

うん、非常に美しい「学習と継承の流れ」だと思う。

「アジャイル宣言」に関するおいちゃんの見解

たぶん近いうちにどこかで使うことになりそうなので、先に文面まとめておこうというライフハックｗ

http://agilemanifesto.org/iso/ja/

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

個人の対話を重視します。もちろん、道筋をつけるためのプロセスや、対話のためのサポートとしてのツールは大切ですが、それらは「個人との対話」をより頻繁に、円滑に、充実させるためにあるものである、と考えます。
ちなみに「個人の」対話、ね。10人の会議で「Topが下知する」事を、おいちゃんは「個人の対話」とはみなしません。

ドキュメント大切だけど…そもそも「DRYなドキュメント」ってあんまり見ないよねぇ B-p
って部分をさしおいたとしても、やっぱり「動いてるソフトウェア」は一番大切。
ただ、それらを「運用保守引き継ぎ継承」するために、要点を押さえた「必要最低限のドキュメント」は要求します。

「顧客」は、二重の意味で重要。つまり「システムを扱う会社さん」であり、同時に「そのシステムを使うことでお金を落としてくれる顧客」である。
契約交渉は…残念なことに、これもまた大切。
なので、この２つは「等価に」扱われるべきだと思う。ただ、お互いが「半歩づつ譲り合う」ことでよりよいシステムができる可能性は高いので。契約を杓子定規には解釈をせず、相手の態度に品性と理性が存在する限りにおいて「顧客との協調」をより強く考えるべきである。

もしあなたが「完全な予知能力」を持っているなら、その計画にしたがってもよいと思う。
しかし現実的には「将棋の一手目で、最後までを読み切る」のは、おそらく、人間には不可能なので。だとすると、常に「PDCAをぶんまわし」適切な「変化への対応」をすることは必須だと思う。
ただ、同時に「２手〜５手」くらいまでは読んでいるのもまた、将棋の指し手のスキルの一つなので。「口に出したら秒単位で変化に対応せよ」なんてことには、必要性を全く感じない。基本的には「イテレーション単位」程度には、柔軟であると同時に計画的であるべきだろう。

tokenizerともう一つのトークンの考察

MagicWeaponには「tokenizer」という「一意のトークンを発行する」クラスがあります。ちょっとしたDBのPKに死ぬるほど便利なのでよく使います。
一方で、以前に書いたのですが( http://d.hatena.ne.jp/gallu/20120402/p2 )、違うトークンの作り方もあります。

で。おいちゃんは「使い分けてる」ので、その辺の話をもやもやと。
「ぢぢぃの世間話を聞いてる」くらいの生ぬるいスタンスで読んでくださいｗ

大まかに結論先に書いちゃうと。
tokenizerは「一意であることを保証したい」ケースで使って、もう一個のトークンは「推測困難性がほしい」時に使います。

ん…まず、うちのtokenizerの仕様から。
前提として「62進数」ってのを使ってます。
62進数表記にすると、0-9とa-zとA-Zで表現できるので、ま〜ま〜便利です。素直にbase64でもよかったのですが、できたら英数だけで表現したかったので作りました。

んで。
tokenizerは、デフォルトで
・現在のエポックタイム(実際には、数値がでかいんで、固定の数値を減算してます)
・現在のマイクロ秒
・プロセスID
・乱数
の４つの数字を、デフォルトだと「−(ハイフン)」でつなげてます。
オプションで「自分のIPアドレス」をここに足せるのと、CとJavaで組んでた時には「スレッドID」も足してました。
PHPにはスレッドないんで、いったん省いてます。

これをやると。乱数以外の部分でかぶるのが「同じマシンの同じプロセスID上で、同じ秒＋同じマイクロ秒で、処理が２回以上走る」場合で、これほぼほぼありえないので。
ゆえに「一意である」ことを大変簡単かつ確実に取得できるんで、好んで使ってます。
で…実装当初、とはいえ数字を普通に連結すると「すげぇ長い文字列」になったので、62進数作りましたｗ
現在、だいたい20〜30文字以内くらいで収まります。

んで。
このtokenが「推測困難か？」って問われると、個人的には「可能ぢゃね？」って思ってます。
乱数もさほど気にした関数使ってませんし(PHPの場合mt_randつかってまふ)、エポック秒は容易。マイクロ秒もある程度あたりはつくでしょうし、プロセスIDだって、案外と。
なので、tokenizerは「一意であることを保証したいとき」に使います。

一方で。
セッションIDとか、今度書くけどCSRFの割符なんかに使いたいのは「推測困難な文字列」なので。
そうすると、以前も書いたのですが

$token = hash('sha512', file_get_contents('/dev/urandom', false, NULL, 0, 128), false);

とすると…
・urandなので、たぶんきっと、ある程度質の良い乱数であると期待できる(はずｗ)
・sha-512なので、結構空間広いので、そう簡単に「偶然当たる」ってのもあるまいて
というあたりの発想から「推測困難なIDがほしい」時に重宝します。

一方で。いやまぁ「ねぇだろ」とは思うのですが、一応、可能性としては「いつかどこかで、以前発行したIDと重複する」可能性が０ではないので。
基本的には「一意のIDがほしい」用途では、あんまり使わないです。

時々聞かれるので、説明を省略する意味合いを込めて、めもｗ

PS
そういえば…「推測困難」なほう、MagicWeaponに組み込みたいのですが…名前どしよ？
UUIDっぽい使い方をするのですが…一応「UUIDは16バイトの数値」って決まりがあるしなぁ…「似非UUID」とかって名前にしようかしらん？ｗ

判定値でみても仕方がないんだが…

インスパイア元
■新卒に言う即戦力とは何だろう
http://el.jibun.atmarkit.co.jp/101sini/2012/05/skkpart-3-551e.html

まぁ、新卒に限らず。
以前から思っていたのですが…まとめると「見るべきは持っているダイスの種類＆数と修正値」であって「判定値」見てもあんまり意味ないざんす。

限りなく脱線をしてから本筋に。
サイコロがあります。TRPGゲーマーは大抵「ダイス」っていいますが。
一般的に知られているいわゆる「サイコロ」は、６面体なので、あれは「６面ダイス」と呼称します。
わざわざ６面というからにはほかにも種類がありまして、ポピュラーなところで、４面、６面、８面、10面、12面、20面があります。また、少しマイナーになると、30面と100面が存在します。

通常、TRPGゲーマーの表記規則として、例えば
2D6
なんてのが存在します。Dはダイスを意味して、その左側は「サイコロを振る数」、右側は「サイコロの種類」を意味します。
ですので、2D6は「６面ダイスを２つ振る」を意味します。

また。実際には「2D6+3」とかいう修正値がつくこともあり、この場合「６面ダイスを２個振って出た値に+3する」を意味します。

もうひとつ。ゲームにもよりますが「クリティカル(critical success、またはcritical hit)」というのがありまして、通常より「よい数字」になります。
「絶対成功」を意味するものもありますし、数値が増えるものもあります。
今回は「そのダイスの最大値を出したら振りたし」としてみましょう。
６面ダイスで６が出たら「もう一度そのダイスを触れる」わけですね。
これで、2D6であっても13以上を叩きだせる可能性が、可能性としては、残っています。

さて。
ここで、あるビジネスで、Aさんが20という達成値を叩きだしました。
その実績を前提に「達成値22が必要なビジネス」を、Aさんにやらせるのは適切でしょうか適切ではないでしょうか？

大抵の場合「今回20の達成値を出すことができたんだ22だってきっと出せるはず」となります。

が、ここで、Aさんの「振ったダイスと修正値」をみてみましょう。
並行世界αのAさんのダイスは「10D6+3」でした。…期待値38*1のはずなのですが、まぁダイス目が悪かったんでしょう。
並行世界βのAさんのダイスは「5D6+2」。期待値19.5…まぁぎりぎりですねぇ。
並行世界γのAさんのダイスは「2D20」。…期待値はともかく、ちょっとふれ幅がでかいので、少々ばくちの様相を呈しています。
並行世界δのAさんのダイスは「3D6」。クリティカルが１回でないと達成できません。「たまたまラッキー」の気配がむんむんです。
並行世界εのAさんのダイスは「1D6」。…クリティカルを連発したんですねぇ。綱渡りというより「期待しちゃいけない」結果です。

さて。各並行世界のAさんに「期待値22」のお仕事を、渡せるでしょうか？
「並行世界εのAさん」あたりに出すと、なにか色々とおもしろそうではあるのですが。

なんだかんだ、特にビジネスにおいて「結果」ってのは大事です。ただ、その結果「だけ」を見ちゃうと、結構ひずみます。
皆さん、サイコロを振ってでた「値」は見るんですけど、その人の持ってる「サイコロの種類＆数と修正値」には、あんまり意識を払っていないケースが多いんですよね。

いつも気になっているので、ちと書いてみました。

*1:クリティカルによる振り足しを含まない