偏って便利な言葉を使えば全部黒

割と昔から感じているのですが。
結論からいうと「広い視野とバランス感覚が最も重要」だなぁ、と、随所で思う訳です。

一つ目に「極端な見方」がありまして。
どんなものでも、極端な見方をすると全て「有害」になります。
えと…例題。
「水は人にとって必要か？ 有害か？」
ある程度以上の水分を一気に摂取すると「水中毒」という状態が発生して、状況如何では死に至ります。
でも「だから水は毒だ」って、誰が騒ぐんでしょう？
どうしても…特にエンジニアは、Boolean値よろしく「true？ false？」という考え方をしやすいのですが。
そも「完全なtrue」とか「完全なfalse」なんてのは、ほぼ「ない」と思ってよいのではないか？ と思います。

二つ目に、前にもかいた「便利な言葉」を恣意的に使う方法がありまして。
いわゆる「レッテルとかラベルの類をはって一緒くたに語る」なんてのはよい例です。
そのレッテル自体が「批判するための意図を孕んだ」ものであれば…それ以降の議論がどれだけ無意味であるかは言うまでもありません。

だからこそ。
様々な角度から物事を考え見ることができる「広い視野」と。
適切と不適切とを判じる事ができる「バランス感覚」と。
この二つは、とても大切だと思うのですが…どんなもんなんですかねぇ？

書店巡り〜

時々やるのですが、書店をぐるりんこと巡り倒します。
このときのルール。

・好き嫌いをせずに、とりあえず「全てのコーナー」を巡る
・ざっくりとでいいからタイトルくらいは見る
・興味が一瞬でも湧いたら、書店さんにご迷惑ではない程度にざっくりと立ち読み
・特に「見ず知らずのジャンル」の場合、雑誌＆入門書が結構面白い

大体、そこそこの書店で小一時間くらい。
これを月に１〜２度でいいから続けると、何となく色々な「流れ」が見えてきます。
おいちゃんはこれを「いろいろな書店」でやります。そうするってぇと、書店さん毎に「タイトルが見えるように陳列している本」が違うので、結構刺激的なんですね。

ただ…巨大な書店にいくと、２〜３時間かかりますんでそれなりに気合いを入れてどんぞｗ

放浪記始めます

いや放浪記っちゅか「おいちゃんはこんな生活しています」程度なのですが(苦笑
どっかのタイトルのインスパイアとかンなこと気にしちゃいけないよｗ

データベースと契約者固有IDとVB(特にVB.netではないVB)とPHPの共通点

いわゆる「データベース」屋さんと。
携帯サイトを中心にWebアプリケーション作成をしていて、恒常的に契約者固有IDを使っている人と。
特にVB.netではなくて、VB6とかを好んで使っているVBerな人と。
PHPしか使えない、PHPerな人と。

の間に、しみじみ感じる共通点を感じたので。つれづれと。
一言で片付けると「LIFE CARDの枚数が異様に少ない」。

上述のいずれも、それを用いる事によるメリットデメリットの双方があり、かつ「状況如何では乗り換える事を念頭に置く」必要もあるのですが。
上述「だけ」をある程度やりこんじゃった「すぺさりすと」な方々は、全てを(或いは控えめに言っても可能な限り多くを)「自分のテリトリーだけで」片付けようとする傾向があるのです。
で…彼らにそれが不適切である事を話すると、帰ってくるのは概ね「今まで自分はこれでやってきた」＋「可能なんだから問題ない」。
とりあえず…彼らの発言から、二つの事を学んでみたいなぁと、切実に感じるです。

「できる」と「適切」の間には、深い溝がある

無常(つね ならず)

一つ二つ、思考の「抽象レイヤー」を上げれば(抽象度を高くすれば)、見えてくるものもあると思うんですがねぇ。
どうなんでしょ？
エンジニアたるもの、手持ちのLIFE CARDの枚数は、呆れるくらいの数にしておきたいところです…っておいちゃんは思うのですが。

量で語り出したら多分アウチ

前書き
いつも以上にきっつい内容なので…どこぞの時代のどなたか様ではありませんが、省略を大量に使用させていただきたく思います。

「PHPで作る携帯サイト」ではどうやってセッション管理をすべきか

なんかご大層なタイトルにしてみましたが。
元ネタはこちらです。

携帯電話向けWebアプリのセッション管理はどうなっているか
http://d.hatena.ne.jp/ockeghem/20090714/p1

ちなみに、会話対象になっているのは、この書籍

PHP×携帯サイト 実践アプリケーション集

最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。

えと…正直、PHPのセッション関連の関数は、あれはあれで色々と「如何なものか」とは思われるので。
個人的には大変に好んでいないのですが。
つまり、上述書籍が「PHPのセッション関数がちょっとアレゲで以下略なので、別途作成を考えてみます」的方向性であるならば、おいちゃんは一定の評価をさせていただきたい、と思うのです。

えぇもしソンな事があれば、ですがねぇ。
実際の所は、以下の通り、らしいです(えぇ伝聞形ですとも。読んでないし)。

そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。
* 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う
* 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する
* そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる

多いですねぇこの系列。

ただ…

これは、携帯電話向けWebアプリケーション開発の定石とは言えないだろう。

徳丸浩さんすみませんこれは多分「ダウト」です。
「定石」という言葉の定義にもよろうかとは思うのですが…定石を、本来の意味である「最善とされるもの」であるとするならば、まさしく正しいのですが。
一方で、もし定石を「一般に最善と考えられている方法・手順」であると捉える場合…「一般の、つまりは大多数のエンジニア」は、契約者固有IDに関して「原子の一欠片ほども問題意識がない」のが、現時点における、現場の実情だと思われます orz

まさに上記のような、『「セッションID」という概念を知らない』技術者、『契約者固有IDがないとWebアプリを作れない』技術者を量産するような内容になっているのだ。

えと…ここは笑うポイントですか？ 血の涙を流すポイントですか？ orz

<form action="deletediary.php?guid=ON" method="post">
<div style="text-align:right;">
<input type="hidden" name="exec" value="1" />
<input type="hidden" name="id" value="<?php varout($entry['id']) ?>" />
<input type="submit" value="削除実行" />
</div>
</form>

えと…IDが何を指し示すかにもよるのですが。もし「メッセージID」ではなくて「ユーザID」であるとするならば…あぁSSL想定ですかね？
ちといくつか思考が散らかるのですが。

SSLではない状態でユーザID(契約者固有ID)を引数で持ち回しているのだとすれば、純粋に「奇異」です。
SSLであるのならばやむを得ないのですが…おっしゃる通り、抱腹絶倒ものにシンプルで愚かな脆弱性を抱え込む事になります。
メッセージIDであるのなら…次へ。

一方、本書の姉妹書のような体裁のPHP×携帯サイト デベロッパーズバイブルの方は、かんたんログインによる認証結果をPHPのセッション管理機構で保持するという、定石的でまともな作りになっている。これであれば、ログイン部分を取り替えるだけで、別の認証方式（たとえばパスワード認証）に変更することも容易だ。このような一般的・汎用的な方法を広く普及させるべきだと思う。

見ていないのですが…その後のセッションIDは「どうやって持ち回ってる」んでしょうか？
えぇもちろん最近のDoCoMoさんを前提にさせていただいてよろしければ「Cookieに保存」で終了、となるわけですが。目出度い事に。

認証成功時にセッションIDの再生成をしていないので、セッションフィクセーションの脆弱性が生じる（参考 http://d.hatena.ne.jp/ockeghem/20090515/p1 ）。session_start();の後に、session_regenerate_id(); を追加する必要がある。携帯向けWebアプリの場合、URLにセッションIDを埋め込むので、CSRF脆弱性の余地がない代わりに、セッションフィクセーションの攻撃は受けやすくなる。忘れずに対策しておきたい。

とあるところを見ると埋め込み前提っぽいのですが。
まぁこのあたりは携帯っつより「PHPのセッション関数を使う時」の心構え、ですね。

いずれにしても…色々と厄介で問題で邪魔だったりする事の多い契約者固有IDですが。

このあたりも含めて、携帯電話向けWebアプリケーションのセッション管理をどのように書けばよいかは、近くまとめようと思っている。

とあるので、ちと期待しながら待ってみたいなぁとか思ってます。

尤も。
おいちゃんが、上述以上に気にしてるし心配しているのが。
http://itpro.nikkeibp.co.jp/article/Keyword/20081007/316269/
あたりに書いてあるような「複数の、悪意ある業者達がやらかしてしまうエトセトラ」ではあるのですが orz

「便利な言葉」という危険な言葉

うちの子(おいらと同じ現場でリアルタイムに教育していた子)には、ある程度耳タコな話なのですが。
おいちゃんがよくいう発言のひとつにこんなんがあります。

「便利な言葉を使うな」

さて。
「便利な言葉」ってのは何を指し示して。んで、便利なのに、なんで使ったらいかんのざんしょ？
ってあたりを。

この文脈で使う時の「便利な言葉」の指し示すものは比較的簡単で。
「一言で言い表す事が出来て、まるでお互いが共通の認識を持てたかのように誤認してしまう言葉」です。
一般的なあたりで、常識とか普通とか正義とか愛とか恋とか。
技術に寄るなら、バグとかサニタイズとか最適とか効率とか。
「あなたのためだから」「有益だから」とかって偽善系の単語もそうですねぇ。
その他結構色々。

正直。ある程度細かく説明して具体的に表現してもなお、ある程度の齟齬が起きるのがコミュニケーションってもんです。
それを「いかにも共通認識が出来たかのような幻想を想起させるがごとき単語」で片付けようとすると…それはもぉ。楽しいくらいに齟齬齟齬です。

基本的には「ちゃんと自分の言葉で、詳細までかみ砕いて発言する」だけでよいのですが…問題がありまして。
「ちゃんと自分の言葉で、詳細までかみ砕いて発言する」ためには。「自分の言葉で語れる」、つまり「理解している」事が前提となっているわけです。
しかるに。もし、万が一、仮に、ごく稀なケースとして、例外的に*1「何となくイメージで語っているだけで理解していないしするつもりもぶっちゃけない」ような状況の場合…少々、問題が発生します。
バズワードを無駄に使う御仁なんかに見られる傾向でもあるのですが。

つまり。
「ちゃんとかみ砕いて話をしましょうよ」と相手に促す時に、それは時として「あんた理解してる？」と、相手の理解度をはかる指針になる可能性が、０では、ないわけです。困った事に。いや困りませんがっていうか「意味もわからずに上っ面で語られる」ほうがよっぽど困った事なのですが。

「便利な言葉」は。「理解していないんだけど何となく相手にイメージを伝えて後は丸投げ」なんて時には、本当に便利です。最終的に結果がよろしくなければ「おまえの理解の仕方が悪い」って言い切れますし。
つまり。「やらかされる」側としては、たまったモンじゃない言葉な訳ですね。

わかった「つもり」になれる便利な言葉。
あなたは、つい、使ってませんか？

*1:大切に過ぎるのでなんども言ってみましたｗ