「鶴の恩返しビジネス」だよね・・・デジタル土方って

「鶴の恩返しビジネスは成立しない」というMake IT 21の話で思うんだけど、デジタル土方って「鶴の恩返しビジネス」だよね。

「鶴の恩返しビジネス」とは、

鶴の恩返しは、自分の毛を抜いて織物にして、それでお金を稼ぐけど、
それって、全部の毛を抜いてしまったらビジネスは終わるわけで、
いつまでも続くビジネスではない。

このような感じのビジネスを指していると思う。いわゆる「体売り」ビジネスで、
ホストの２番手以降
　（No1ホストは、お酒を飲まなくても貢いでくれるのでビジネスになるが、
　　２番以降は、ナンバーワンホストを目指して、お酒を飲んで苦労してお金を稼ぐ。
　　でも、がんばればがんばるほど酒飲むことになるので、いつかは体を壊して辞める）

ドカタ
　（地図にのこるような建物を建てても、一線のドカタは、体が動かなくなったら・
　　病気になったらおわり。あとは、ホームレスになるしかない・・・）

などが、典型的な例として挙げられる。
これらのビジネスは、昔はできたけど（労働人口が増えていたので、使い捨てできた）
今はできない（労働人口が減っている上、ブラック認定されるので）

で、イマドキのこのビジネス・・っていうと、デジタルドカタっていわれたのも、
そうじゃないかなと思う。

ドカタさんが、体を壊したら終わるように、
デジタルドカタさんは、精神を壊したら（うつ病になって職場復帰できなくなったら）
おわりのような・・・仕様書に基づいて仕事をさせられるので、仕様書が間違っていたら
無駄な努力を強要されて、がんばればがんばるほど、消耗していく・・・
って言う意味では、「精神的な体売りビジネス」だよねえ～

「PHPあるあるパフォーマンス対決」を聞いてきた！

１０月３日に、PHPカンファレンス2015に行ってきた！話の続き（これで最後）

PHPあるあるパフォーマンス対決

をメモメモ

---

・「PHPコアから読み解く定石の嘘ホント」の続編
・似たようなスクリプトに対して、どちらのほうがパフォーマンスが高いかを紹介する
・論理（オペコード解析）と数値（測定）

【クイズ１】メソッドチェーンと非メソッドチェーン

　　$ca→testa()→testb()→testc()　（メソッドチェーン）

　　　　と

　　$ca→testa();
　　$ca→testb();
　　$ca→testc();　（非メソッドチェーン）

　のどっちが早い？

＊答え
　非メソッドチェーン

＊理由
　メソッドチェーンは、戻り値を使う為、用いている一時変数の確保等が必要だから

【クイズ２】異次元配列の書き込み
　　$i,$j,$kを１００回づつまわして

　　$list[$i][$j][$k] = 1;　（高次元）

　　　と

　　for文の入れ子にして、$i,$j,$kとまわしていく（低次元）

　とどっちがはやい？

＊答え
　　低次元

＊理由
　　低次元のとき、処理を分散させている
　（$iで行う処理は１００回、$jで行う処理は100*100回、$kで行う処理だけ100*100*100回しているが、
　　高次元は、100*100*100回、全ての処理を行っている）

【クイズ３】関数の引数、スカラーと配列、どっちが早い

＊答え
　　配列

＊理由
　　スカラーは、関数の引数の受け渡しに時間がかかる


・おわりに
　パフォーマンス高いスクリプト書くこと大切
　理解すること大切
　自分で考えてみること大切

マイナンバーがシスログやDBログに書き出されてもアウト！損害賠償？ってことだよね・・

昨日、

「脆弱性があったとき、その責任は発注者？開発者－判決では開発者」という話を聞いてきた！
http://blog.goo.ne.jp/xmldtp/e/3a0b8abaacb7feab2a9d1646735d8f44

の中で、「個人情報をログから閲覧できる」ってかいたけど、
これで、１つ、気がついたことがあるので、書いてみる。

---

マイナンバーって、漏れちゃいけないですよね。
でね、もし、ここで、今、マイナンバーを削除しようとする。

DELETE FROM MYNAMBER_TBL WHERE ID="123456789012";

とかすると、DBのアクセスログにかかれるかもしれませんよね！
（プレースホルダーを使っても、DBアクセス時には、
　SQLが組み立てられているよね。キット。だからアウト！）

もしかしたら、URLなどにも番号が載るかもしれないですよね
（CakeやZendで開発してていて、rewriteとか、してる場合）
それ、シスログとか、アクセスログとかに、載るかもしれませんね！

・まず、コレが個人情報として、漏洩したら完全にアウトです。
・そうじゃなくても、このログは、マイナンバーの保存時間経過後、
　すみやかに削除されるか、その部分をマスキングしないといけませんね！

そして、重過失の基準は「経済産業省などから注意喚起があった場合」とするならば、

もし、このこと（ログにもマイナンバーを残さないように）
を、マイナンバー関連のお役所が言ったらアウト、

ログにマイナンバーを出ないようにしていなかったら、
開発者の責任ということで・・・
まあ、損害賠償までは行かなくとも、
無償で修正は、ありえることでしょ～な～
（瑕疵ですからねえ～、立派な・・・ログとはいえ）

そしてもし、

消費税還付にマイナンバー活用案　課題も多く
http://www.nikkei.com/article/DGXZZO76056900T20C14A8000065/

なんてことになったら、いたるところでマイナンバーの通信のやりとりが
されるわけで、

そこでもし、あるメーカーが、ログ中にマイナンバーを
書き出してしまったりしたら・・・

日本全国すみずみの、極少零細八百屋さんとかに、
東京の一流メーカーの勝ち組エリート社員が頭下げていくんでしょ～かね～
ログ出力プログラム直しに（＾＾；）

・・・あ、ありえねえ～！！


・・・徳丸先生、いまどきになって、そんなことを思い出させるなんて・・・！！


P.S　そもそも、極少零細八百屋さんは、
マイナンバーを読み取って、センターに送る装置が
買えるのか？通信料が払えるのか？操作できるのか？

「徳丸先生に怒られない動的ＳＱＬの安全な組み立て方」を聞いてきた！

１０月３日に、PHPカンファレンス2015に行ってきた！話の続き


「脆弱性があったとき、その責任は発注者？開発者－判決では開発者」という話を聞いてきた！
http://blog.goo.ne.jp/xmldtp/e/3a0b8abaacb7feab2a9d1646735d8f44

の中に、「どうすればよいかは、午後へ」とあるけど、その午後の話

「徳丸先生に怒られない動的ＳＱＬの安全な組み立て方」

をメモメモ

---

・発表の背景：裁判と損害賠償
　　ＳＱＬインジェクションの裁判
　甚大な被害額
　　４８００万～１億円

・目的
　ＳＱＬインジェクションが起こる新の原因と起こさない方法
　→プレースホルダを使えより

・なぜＳＱＬインジェクションが発生するか
　　エスケープしろ！
　　プレースホルダーを使え！
　プレースホルダーを使ってもＳＱＬインジェクション
　→文字列連結でＳＱＬを組み立てるから
　　これこそが真の原因
　　変数の埋め込みも同じ


・なぜ文字列連結でＳＱＬをつくるのか？
　プレースホルダーではできないことがあるから
　　　要素数が同的に変わる
　ＳＱＬを文字列で指定できてしまうから


・ＳＱＬインジェクションを防ぐには
　・文字列連結を使わない方法で動的ＳＱＬを組み立てる
　・ＳＱＬもじれるではない方法でＳＱＬを指定できるようにする

・ＳＱＬインジェクションが発生する本当の原因は
　ライブラリやＳＰＩのインターフェースに
　欠陥があるからである
　間違いを誘発するものを使い続ける限りなくならない

・ＳＱＬテンプレート
　ＳＱＬを生成するためのテンプレート
　ＳＱＬインジェクションが発生しない（原理上は）

・SQLTempl8
　コンセプト実装

・なぜＳＱＬテンプレートだと発生しない
　文字列連結が書けない

・is not distinct from ＜＝＞

・やっぱり埋め込み使いたい
　テーブル名かカラム名

・ＳＱＬ構文木
　木構造で表現したデータ
　　　通常は専用の専用のライブラリ
　　　Ｏ／Ｒマッパーを使う
　値に応じて自動的に変換できる
　　→悪意ある文字列をうけとっても。
　　　意図しない変更はできない

まとめ
・動的ＳＱＬを作るのに文字列結合を避ける
・本質的にはＡＰＩやインターフェースの欠陥