Location via proxy:   
[Report a bug]   [Manage cookies]                

世の中から名刺をなくしたい。

名刺交換とかうざい。
私は営業職とかじゃないからだろうが、 もらっても99.9％電話もメールもしない。
だからここ数年名刺は持ち歩かないことにして、「すいません切らしてまして」ということにしている。
実際に連絡を取る人にとっても、無駄の多い馬鹿げたプロトコルだ。（私はそんなことしないで捨てるが）いちいち名刺を見て氏名と電話番号、メアドを連絡先アプリに手で打ち込むとかやってられないし、OCRかけるとかバカげている。はなから電子データで交換すればいいのだ。
そもそも連絡先交換ならTwitterだのFacebookだののIDでも教えてくれれば十分なのだ。むしろこちらのほうがつぶやきから人となりが分かったりアバターなんかで視覚的な識別が可能なぶん情報量が多い。

というわけで世の中から名刺を撲滅するためのサービスを妄想してみた

機能仕様：

  • スマフォアプリとして実装する
  • Bumpのようなやり方で事前に設定した連絡情報を交換できる
  • iPhone <-> Android間でも交換できる
  • 連絡先情報はサーバ側に保存され、連絡先を更新しても、すでに交換した人たちは常に最新の情報を参照する
  • ただしスマフォがオフラインになったりサーバがダウンしてもいいようにクライアント側にもキャッシュする
  • クライアントサイドで検索したり電話したりメールを出したりTwitterのDMだしたりできる

Plaxoみたいな感じかもしれない。
でもこのモデルは機能しないことがすぐ分かる。これだけではこのサービスのユーザ同士でしか連絡先を交換できない。しかしはじめて会う人がこのサービスを利用しているかどうか知るすべがない。

このサービスを使ってる人と使ってない人の間でも上手く機能するやり方を考えなければいけない。

追加機能： ユーザ <-> 非ユーザ間での交換

  • 後方互換モードとして名刺のOCR機能を提供する
    • 携帯のカメラで名刺を撮影するとOCRかけて検索したりできるようになる
    • つまり、最初は単独の名刺管理アプリとしても使えるようにする
  • 非ユーザが写真を撮ることを許可してくれたら、その場で携帯のカメラで撮影して名刺と関連付けて顔画像を保存できるようにする
  • その場で相手を招待するメールを送れる

二番目の機能は必須だ。典型的な成功ストーリーは次のようになる：

  1. 普通に名刺交換する
  2. 普通にミーティングする
  3. 普通にミーティング終わる
  4. 最後にちょっと声をかける
  5. 「ちょっといいですか。実はこういう名刺管理アプリを使っているんですが（名刺と顔写真が並んでいるアプリを見せる）、顔写真を取らせていただいていいですか？」
  6. 「いいですよ。面白そうなアプリですね。私も使ってみようかな」
  7. 「お、それでは招待しましょうか？」

私はヘビー名刺ユーザじゃないので伝聞なのだが、大量の名刺を交換する人たちのライフハックとして、「名刺にその人の特徴をメモっておく」というのがあるらしい。しばらくするとどういう人だか忘れてしまうから。
そう考えると、失礼に当たらなければ顔写真と名刺を関連付けておくのは便利な機能のように思える。（一般的に言って失礼かどうかは良く解らん）
そして、ユーザがこのアプリについて説明して顔写真を撮らせてもらうというインセンティブを用意すると、これは無料でアプリの宣伝をしてもらっているようなものである。撮られる側も何百人かにひとりは「へえ、ちょっといいじゃん。使ってみようかな」と思ってくれるかもしれない。もし撮られるのが嫌なら拒否すればよい。あるいは最初はスルーかもしれないが、同じような体験を何回もすれば認知度が上がっていくはずだ。

こういうのは何でもそうだが、ユーザが少ないうちは誰も見向きもしない。ところがウランの臨界のように、ある狭いコミュニティ内でのユーザ数があるしきい値を超えると、むしろ使っているほうが普通、みたいになるはずだ。そうなればコミュニケーションの1stフェイズはこのアプリでの連絡先交換となり、名刺はまだ使ってない人に対するfallbackになる。ここまでくれば時間の問題で名刺を撲滅できる。そうできなければ凡百のサービスと同じように、単に終わる。

業界によっては難しいだろうが、ギーク層とかネット業界とかの新しい物好きクラスタではそれなりに受け入れられそうな気もする。

とか妄想した金曜の昼。

ソフトウェアエンジニアが知っておくべき偉大な30人

@ockeghem「ケン・トンプソンとデニス・リッチーを知らない…」をトリガーとして、ソフトウェアエンジニアが知っておくべき偉大な30人とか誰か書かないかな。もうある?
http://twitter.com/ockeghem/status/51110649429889024

適当に挙げてみた。ケン・トンプソンやK&R辺りからの連想なので粒度がまちまち。こういうラインアップだと、チューリングとかシャノンとかノイマンとかはなんか違う感じ。

名前 特に有名なand/or影響が大きい実績
ケン・トンプソン C, Unix
デニス・リッチー C, K&R, Unix
ブライアン・カーニハン C, K&R
アラン・ケイ オブジェクト指向, Smalltalk
ダイクストラ 構造化プログラミング
ジョン・マッカーシー Lisp (関数型言語)
ドナルド・クヌース TeX, the art of computer programing
リチャード・ストールマン GPL, Emacs
ティム・バーナーズ・リー www, URI, HTTP, HTML
マーク・アンドリーセン Mosaic, Netscape
リヌス・トーバルス Linux
ビル・ゲイツ MS-Dos, Windows
ディッフィーとヘルマン 公開鍵暗号モデル
RSAの3人 公開鍵暗号の実装

世界初の高級言語FORTRANのジョン・バッカスとかどうなのよ？とか言われそうだけど、僕は調べるまで名前を知らなかった。
それなりにメジャーな言語の発明者系だとストラウストラップ(C++) ゴスリン(Java) ラードフ(PHP) ラリー(Perl) 松本(Ruby) とかは↑の人たちと比べると影響度がやや小さい気がする。<追記>
気が向いたときに追記

名前 功績
アントニー・ホーア クイックソート, CSP
ニクラウス・ヴィルト Pascal,「アルゴリズム＋データ構造＝プログラム」
ジョンバッカス FORTRAN, BNF記法
エドガー・F・コッド リレーショナルモデル(RDB)
ビル・ジョイ BSD, vi, csh, SUN
アンドリュー・タネンバウム MINIX

[SQLインジェクション対策]Webアプリケーションとかの入門本みたいのを書く人への心からのお願い。

SQLインジェクションについて書くときに以下のメッセージを必ず含めて欲しいです。

なんでこんなことを書くかというと、同僚が献本されてた「プロになるためのWeb技術入門」なる本のSQLインジェクションの項で、SQLインジェクションの対策として以下のように書いてあったからです*1。

ダメです。間違っています。単に間違っているだけでなく救いがたく間違っています。正しいSQLインジェクション対策はこう書くべきです。

イケてない本を書く人はなんで値のバリデーションをプリペアドステートメントよりも先に書くんですか？値のバリデーションは必要ですが、それはプログラムの正常な挙動を担保するためであって、SQLインジェクション対策のためではありません。*2
そもそもSQLインジェクションされる脆弱性というのは、単にマヌケがプリペアドステートメントを使わずに文字列結合でSQLを作るようなバグプログラムを書いたというだけです。SQLインジェクションはクラッカーの巧妙な攻撃手法とかではありません。単なるバグです。対策はプリペアドステートメントを使うことだけです。大事なことなので何回も言いました。詳しく知らない人は上記の「安全なSQLの呼び出し方」を読みましょう。
なお上記の本とは関係ないのですが、"SQLのメタキャラクタを適切にエスケープせよ"というメッセージは、字面だけ見れば正しいのですが、現実的には間違っています。私は10年プログラマをしていますが、Web系でプリペアドステートメントがサポートされていないような環境でプログラムを書けといわれたことは一度たりともありません。だから初心者向けの本では「単にプリペアドステートメントを使え」というメッセージで十分だと思います。
SQLのメタキャラクタを適切にエスケープしてSQLを作らなければならない、作るべき場合というのは、ぱっと思いつくのは以下のような場合です*3。

  • あなたが作ったRDBMSにはプリペアドステートメント機構がないのでプリペアドステートメントを実装している
  • あなたが作ったプログラミング言語にはRDBMSへ繋ぐクライアントライブラリの既存の実装がなく、Cで書かれたライブラリを呼び出すこともできない設計なので仕方なく自分で実装している
  • あなたの製品が動く環境は組み込みデバイスなので、既存のRDBMSのクライアントライブラリがコンパイルできず、相当するものを自分で作っている

いずれも初心者が遭遇するような場面ではありません。病的な例外と言ってもいいです。したがって、SQLインジェクションの対策メッセージは、現実的にはこうなります。
「単にプリペアドステートメントを使え」
それ以外のSQLインジェクションの文脈では些末すぎること（バリデーションやエスケープ）が書いてある本は燃やしてもいいのではないかと思います。

2011-11-09 追記

今までもid:ockeghemさんには何度か紹介してもらっていたが、改めて「SQLインジェクション対策」でGoogle検索して上位15記事を検証したという記事で紹介してもらった。
この記事は"SQLインジェクション対策"ではちっとも検索にひっかからないようなので、タイトルにそういう文字列を入れた。

*1:セキュリティの章の記述がすごく残念な感じだったので、Amazonへのリンクとかは貼らないことにします

*2:不正な文字エンコーディングによる文字コードSQLインジェクションへの対策として、プログラマが文字コードのバリデーションをしなければならない処理系は存在しますが、この場合でも主客が逆で、まずはプリペアドステートメントであるべきです

*3:あとO/Rマッパーを書く場合というのもあるのだけど、話がそれるので略します

減量はどうなっているか？

こうなっています。

脂肪重量は(体重)*(体脂肪率)での推測値です。グラフだとわかりにくいですが、かなりばらつきがあります。体脂肪率の正確な測定は難しいと聞くので測定誤差でしょう。
大域的にみれば、脂肪と体重がほぼ同じくらいの傾きで減っているように見えるので、概ね脂肪を燃やして体重が減っているようです。
ダイエット初期は毎日3kmくらい走っていたのですが、さすがに時間が取れなかったり花粉の季節になって外を走るのが辛くなってきたりしてきつかったので、今は週2〜3回走る感じになっています。
したがって現在の減量メニューはこういう感じになっています。減量は簡単に継続してやれる小さなことをたくさん積み重ねるのがいいんじゃないかという気がしています。ビバちりつも。

  • 食事制限はしない
  • ただし酒は飲まない
  • 会社への往復(片道1.2km)を歩く
  • 会社ではなるべく階段を使う
  • 週2〜3回走る(花粉の季節はジムで走る)
  • 水を2リットル程度飲む(オカルト)

細かい数値で見ると、開始から44日でこうなりました。

＼ 開始 現在
体重 71.55kg 63.30kg
体脂肪率 26.3% 19.4%
脂肪重量 18.8kg 12.3kg

この調子で57.0kg, 体脂肪率15%をめざしていきます。

減量続報

ちゃんと真面目に減量しています。体重の計測は朝シャワーを浴びたあと下着とTシャツだけで測っているので、かなり均一な条件で計測出来ていると思います。
真面目な減量するのは初めてなので、いろいろ気付きがあって面白いです。人間って1日の中でも軽いときと重いときがあって、1kgくらいは体重のばらつきがあるとか。
ただ、1日100g、1ヶ月3kgペースでいく予定なのですが、なんか1週間で1.2kgくらい減ってしまいました。元が太り過ぎなのでまあ減らすのも楽ということでもあるのでしょうが。
基本食事制限なしなものの、次の日の計測を考えると心情的に高カロリーな食事を選択しづらいということもあり、食事は抑えめです。
あんまり急激に減りすぎて、いわゆる停滞期みたいなのに突入するのもいやなので、ゆっくり減量していきたいのですが…。食事制限なしで運動してカロリー消費する減量でも停滞期みたいのってあるのかな？あんまり急減量するとあるだろうなあ。

日付 体重(kg)
2/13 71.55
2/14 71.30
2/15 71.00
2/16 71.05
2/17 70.80
2/18 70.75
2/19 70.60
2/20 70.30

というわけで今日の昼はステーキ300gとか食ったりしてみました。あとで調べてみたらステーキ300gって800kcal〜1500kcal(脂肪の量によって異なる。和牛霜降りなどはカロリーが高い)とかなんですね。僕が食ったのは和牛霜降りとかじゃないから多くても1000kcal位だと思いますが。