デブサミ2日目

寝不足でずっと眠かった。
一見普通のセッションに見えて、内部はただ自社の製品をCMするセッションになるのはどうかと思った。
そーゆーセッションだったら、製品名をセッションに書いてCMだということを書いとけと。



面白かったセッションだけをメモを頼りに書いてみる。

web脆弱性診断

資料を公開されるといわれたので公開待ちですw


2つのセキュリティスキャナーが紹介された。


burp suite
web scarab


今までparos使っていたけどこっちのほうがいいのかなぁー
paros との比較表がほしい!!

攻撃練習用のwebアプリbadstore
http://www.atmarkit.co.jp/fsecurity/column/ueno/59.html


セキュリティ診断は業者に頼むと 100万〜300万ぐらいかかるらしい。
→高い!


なぜ自分たちでやらないか。
・やり方がわからない。
・やり方がわからないのでテスト仕様書が作れない。
・やり方がわからないので報告書が作れない。
・自社のテストを顧客に信用してもらえない。


地方自治情報センター（LASDEC）ってところweb健康診断というのがある。


高木先生とかがメンバーに加わっているしっかりしたテストケースらしい。
#web健康診断を網羅しているフリーなセキュリティスキャナーだれか作ってくださいw

google日本語入力を支える情報処理技術

資料は公開されるといいなー
(web学会のときも資料が公開されなかった気がするので望み薄いかも)


メモったヤツを書いてみる。間違っていても知らない。


IMEをセキュリティを確保して実装するのはすごく大変。
imeはdllになっていて、テキストボックスがあるアプリだと自動的にロードされる。
#昔某winsockをフックするヤツを作ったときに似たようなことになった気がした。

Win + L のロック画面にもロードされる。
特権で動くようなところにもロードされるので、ヘタに作るとセキュリティホールになる。


imeが落ちるとアプリも落ちる。
アプリが落ちるとimeも落ちる。
辞書更新のタイミングで上のアプリが落ちると、imeも落ちるため辞書が壊れる。


その上、imeは非常に多彩な機能を要求される。
変換、入力補正、複雑なキーバインド etc...


発想の転換。
落ちてはいけないから、落ちても大丈夫な設計にする。
プログラムは落ちるものだ。


プロセスによる権限分離。

imedllは入力されたものを変換エンジンに対して中継するだけのシンプルなものにする。

入力      imedll(中継)   変換エンジン
  ----A--->
                  ---A-->
                  <------
  ----I--->
                  ---I-->
                  <------
  --SPACE->
                  --SPACE-->
                           変換処理
                  <-------
  <-------

画面に変換候補を出すときも別プロセスのレンダラーに頼む。

imedll  ------>  変換エンジン (キーバインドを受けって変換する)
        |
        ------>  レンダラー (画面にメニューなどを書く)

imedllは非常にシンプル。
変換エンジンとレンダラーは別プロセスで権限分離しているためのっとられても影響がない。
imedllが落ちても影響がない。




変換エンジンが落ちたらどうする？
imedllにはリクエストを再送するプレイバック機能が付いているため、変換エンジンが落ちても影響がない。

入力      imedll(中継)   変換エンジン
  ----A--->
                  ---A-->
                  <------
  ----I--->
                  ---I-->
                  <------
  --SPACE->
                  --SPACE-->
                             クラッシュ

        リクエストを再送する
                  ---A-->
                  <------
                  ---I-->
                  <------
                  --SPACE-->
                              変換
                  <--SPACE--
  <-------

デモで、4秒毎に 変換エンジンを強制終了させながらでもime変換ができることをやっていた。すごい!!!


利点。
アップデートが非常に簡単。
ユーザーがimeを使っていようが変換エンジンをkillして自由に置き換えることができる。
アップデート後に再起動が不要になる。
ユーザはimeが切り替わったことに気が付かないぐらい。


また、バックエンドプロセスはOSに依存する部分が少ないためMacOS等の別OSに移植がし易い。


64bit環境対応はimedllだけを対応して変換エンジン等は32bitで動かす方針を採った。
imedllは非常に簡単な実装のため移植作業は1日で終わり10日ぐらいテストするだけでよかった。



辞書はどこにあるのか？
辞書は変換エンジンのexeファイルの中に埋め込んでいる(びっくり！)
exeだとOSが読み込んでくれるので自分で読み込む手間が省ける。
exeなのでリードオンリーなため間違って壊すことがない。
辞書を利用する変換エンジンと辞書が必ず同一になるためアップデートが非常に楽。
辞書のデータフォーマットを自由に変更しても互換性を考えなくてよい。(素晴らしい!!!!!!)
今後も辞書をより良い圧縮方法、より良いアルゴリズムに簡単に置き換える事が可能になる。


辞書とメモリ。
辞書が物理メモリに載っていないと遅い。
windows vista以前はバックグラウンドプロセスのメモリを積極的に仮想記憶に押し出す。
IMEの変換エンジンのようなバックプロセスはよくメモリに押し出される。→遅くなる。
辞書を物理メモリに配置したいが、それだと特権がないとできない。


次期バージョンでは、辞書を物理メモリに格納するためだけのwindowsサービスを作るらしい。

          --------------------
実メモリ  |    |XXX|     |XXXX|  XXXXは歯抜け
          --------------------

          --------------------
サービス  |                  |  キャッシュ
          --------------------
            ^
            |
           変換エンジン

現代のOSは同じ内容のページは共有するためこれで問題がないらしい。



辞書データ
webから辞書を作っている。完全自動生成。

日本語らしさをモデル化する。


品詞や単語のつながりをモデル化する。
姓→名と連続するモデルを作れば、人名辞書が作れる。(なるほど!)
ただし、これでは読み仮名が取れない。

どういう読み方をするのか、読み方のつながりの確立モデルを生成する。

うまくメモれなかったけど、たしかこんな感じだったような。

山   田
やま　だ
      た
さん　たんぼ

山田という単語は、「やま」と読んだ後「だ」と読む確率が高い。

たまに間違うw


辞書検索は先頭から探すためkey value store方式は当然使えない。
TRIE を作る。データ構造は LOUDS(Level-Order Unary Degree Sequence)。
これをハフマン符号化でごりごりやって 30MB程度に高圧縮している。


TRIE と LOUDSといえばコレとかに近いのかな。
http://www-tsujii.is.s.u-tokyo.ac.jp/~hillbig/tx-j.htm


ハフマン圧縮した状態ということは、圧縮したデータをどうやって利用しているんだろうか、謎だった。
TRIEである程度の枝の下を個別にハフマン符号化とかやっているんだろうなと勝手に思って納得した。


ハフマン符号の解凍って結構早いから現代のCPUだと毎回やっても問題ないのか、それとも、ある程度はキャッシュ領域を作ってそこに配置しているんだろうか。


zlib.dllで地図データの圧縮とかやったことがあるけど、デスクトップでは言うに及ばず、ポケットPC 2003 ぐらいの貧弱なCPU環境でもすいすい動いてびっくりこいたことがある。



なんつーか、googleのエンジニアすげーな。
オレのような雑魚は到底かなわないとレベルの違いを思い知らされた。
この業界上は果てしないぜ。

建築から開発プロセスを学ぶ

先生、資料が、資料がほしいです。
ボールペンが壊れて途中からインクが出たり出なかったりしてうまくメモれませんでした。


全部メモった人がいたのでちゃんとした内容はこっちを読んだほうがいいかも。。。
http://d.hatena.ne.jp/tmtms/20100219/1266634049


XP(エクストリームプログラム)、wiki、デザインパターンの原点をたどっていくと、クリストファー・アレグザンダーさんという建築家にたどり着くらしい。
クリストファー・アレグザンダーさんは建築におけるパターンランゲージというのを定義したらしい。


クリストファー・アレグザンダーさんの直弟子である建築家の中埜博さんのお話。
プログラムの話ではない。


作り手と使い手が分離された心がこもっていない建築

作り手
■ ←→ ■
        使い手

作り手と使い手が同一であれば不一致は請じない。
自分で作って自分で使う。
#オープンソースとかの原点もこれだよねぇ。

作り手   使い手
■       ■
↓↑    ↓↑
■ → → ■ 中間

時代が変換し、構造が複雑化した結果、作り手と使い手の間に中間が入ると、作り手と使い手は分断されてしまう。

作り手   使い手
■       ■
↓↑    ↓↑
■       ■ 1次受け？
↓↑    ↓↑
■ → → ■ 2次受け？

建築では、
昔は大工さんと使い手が一緒になって家を作っていた。
現代では、
使い手は建築会社にまかせっきりになってしまう。
使い手と施工会社や大工等の物を作る人の間が分断されてしまう。


使い手と作り手が分断されることにより、建築に心がこもっていない。


使い手にとって一番よいものを作るには、使い手と一緒になって作る必要がある。




たとえば家でテーブルを作ってみる。
いきなり作るとうまくいかない。
たから失敗してもいいようにダンボールで作ってみる。
どんどん作って、どんどん失敗する。だけどダンボールだから問題ない。
そしてちょうどいい具合になったところで、大工やさんと一緒に本物を作る。



#XPでいうところの顧客と一緒になって開発するというやつでつね。


マインドマップには批判的。
ツリーはトップダウンで見るときれいにまとまっているが、ボトムアップで見るとばらばらになってしまう。

A→B|→D
  | |
  | |→E
  |
  |
  |C|→F
    |
    |→G

ツリー末端のD E F Gは相互につながっていない。

相互につなげる
E -- C ---- D---G
|           |   |
B           |   |
            A---F

つながりがあるところは プラスなり、つながりがないところはマイナスになる。
全部がプラスになるように要素を固めていく。
つながりが強い部分と弱い部分に分かれた。
#なんかニューラルネットワークに似ているような気駕する。。。


つながりがあるところ、重なるところを集めてボトムアップ。
これがパターンランゲージの原点らしい。


広場配置のパターン??

広場は、みんなが通るところの横においておくのが適切らしい。

端っこに置くとアクセスしづらい。
       ------
-------|広場|
       -----|
これだと通行の邪魔
       ------
-------|広場|---------
       -----|
通りの横に配置するのが便利
----通り----------
       |広場|
       -----|

こういうパターンが253ぐらいあるらしい。


感想

なんつーか、これってパターンというより、ベストプラクティス(よい事例)のような気がした。
デザインパターンとかも、うまくいった事例の紹介であるともいえるよな。
こういう場合は、こういう設計をやったほうがうまくいきましたよ。と、いう事例の紹介なんだな。

つまり、

物を作るときは、それを使う使い手と一緒にできるところから小さく始める。
過去のうまくいった事例を集めて、こういう場合はこうやったほうがよいという事例を参考にやってみる。

過去の事例は、現在の問題解決には、もしかしたら当てはまらないかもしれない。
だけど、使い手が一緒にいるから、間違いは早めにわかるし、スモールスタートだからそれほど問題はない。

ダメだったら、合うように少し変えてみればいい。

その成果をみんなで持ち寄って、コレでうまくいったことが新しいパターンとして定着すると。
失敗した事例はアンチパターンとなるのかもしれない。

絶対ダメなのは、過去にコレでうまくいったから今回もうまくいくはずと使い手を無視して突き進むことや、この事例にはパターンを入れるのは絶対であり変化してはいけないと神聖不可侵になることではないかと思った。
そうやって硬直化した結果、使い手にもそっぽを向かれ、つくり手も疲弊してしまうのかなと。

なんかこれがうまく回るのは(下請けではない)小さいベンチャーのような顧客と作り手の位置が近いところかなぁと。
うまく回らないのが、下請けや大規模な企業のような気がした。

日本の中小ITベンチャー9割りがどっかの下請けという話をどっかで聞いた。
んで、顧客との距離が近い欧米のベンチャーが大活躍していき、そうではないところが没落していくのは自明なのか。。。

スライドシェアで上がっていた面白そうなセッション

・Windows 7のトラブルに立ち向かう〜Troubleshooting Packご紹介
http://www.slideshare.net/kkamegawa/18d5windows-7troubleshooting-pack

windows7にはこんな素敵な機能があるのね。
だけど、windows7からだったら後数年は使えないかー。
xpからサポートしていてくれればうれしいんだけどなぁ。


・クラウドサービスAmazon EC2を活用した「SKIPaaS」構築事例
http://www.slideshare.net/namikawa/amazon-ec2skipaas

あれ、、こんなセッションあったのか。。。
一日目のクラウド構築事例ってヤツか。
気が付かなかった。


・Agile Estimating and Planning
http://www.slideshare.net/kakutani/agile-estimating-and-planning-3222545

アジャイル。
昔、会社でストーリーボードとかやろうとしたけど、うまくいかなかった。
部屋が狭すぎてホワイトボードまでたどり着くのが大変だったというのと、
俺の字が汚すぎて誰も読めなかったというw

何で、ソフトウェアでホワイトボードを使ったストーリーボードができないものかと思ってます。
これなら、字が汚い人でも、ホワイトボードまでが遠くても問題なし!!
物理的にホワイトボードおかなくてもいいし。。。

ただ、ホワイトボードだと非技術者の人でもわかるんだけど、これだと非技術者の人には直感的にわからないんだよなぁ。
それだけが問題点。

ただ、電子データになれば、どうしてもガントチャートぢゃなきゃイヤだという人とか、WBS(ワードビジネスサテライトw)を出したいとか、絶対に原価計算したいんですという非開発者なスーツの人にもわかるんでお互いメリットがあるから、いいような気がします。