Facebook Chat APIをrubyでつかってみたよ

https://developers.facebook.com/docs/chat/

Facebook連携アプリを作る際に、アプリを認証してくれたAさんからAさんの友達のBさんにメッセージを送るには2つの方法があります。１つは、Mention Taggingでもう一つは、chat。前者はAさんのWallとBさんのWallに表示されるので（Bさんが許可してれば）Publicですが、後者はPrivateなものになります。今回は、Privateなメッセージをおくるためのchat APIについて解説してみます。

ドキュメントにある通り、FacebookのChatはXMPPというプロトロルを使用しているらしく、これは今はなきGoogle Waveも採用していたプロトコルですね。あー、懐かしい。。
で、細かいことは抜きに動くものが欲しい人は↓のブログを参照するといいと思います。
http://dalibornasevic.com/posts/35-how-to-send-private-messages-with-facebook-api
permissionとしてxmpp_logicが必要なのが注意です。コード自体は数行なのですぐにお試しいただけるかと思います。

あと、注意点として、ちゃんと規約を守りましょうということで、以下のBest Practicesに反する行為をしていないかをよくよく確認してからアプリをつくりましょう。Chatの中身はユーザがタイプしたものじゃないとダメとか、URL、広告は入れちゃダメとかはGraph API、Open Graphの規約と似ていますね。

Best Practices

In order to provide the best user experience, we recommend your chat integration do the following:

Your Facebook Chat integration should only be used for applications facilitating real time conversation or interaction between users. Links or advertisements should not be sent via chat, unless the sending user types in this message.
Your Facebook Chat integration should only be used for sessions that are expected to be long-lived. Clients should not rapidly churn on and off.
vCards retrieved through Facebook Chat will contain profile pictures if available. Clients should cache these pictures using the content hash, not the user ID, as the key. vCards should only be fetched if the client does not already have that user's picture cached.
Clients should not automatically reconnect if they receive a stream-error of type conflict.
Clients should be able to handle a single contact with multiple group elements.
Incoming messages from the JIDs chat.facebook.com or facebook.com should be displayed as administrative messages.

in the right place at the right time

先日、職場での飲みの席で、今度、一緒にはたらくR君の転職理由がすばらしいというか、説得力のある理由だったので紹介したい。

彼は現在、某コンサル会社に勤務しているのだが、非常に優秀なため、Amazon, Huluといった誰もが知っている大企業から、名も無きスタートアップ、ベンチャーから誘いを受けていた。最終的に、名も無きスタートアップの弊社からのオファーを受けることなったのだが、その理由を別の同僚S君が何気なく尋ねて、R君が以下のように答えた。

AmazonとかHuluはいつでもいけるし、自分がいなくても問題ない。だから、自分がいないとダメな場所、自分ができないことができる人がいる場所で勝負したい。

要約するとこんな感じだったのだが、非常に腑に落ちた転職理由であった。

JINSクレカ情報漏えい事件について

http://www.jins-jp.com/info.pdf

2013年3月14日、JINS PCで有名なJINSのサイトがクラックされて、顧客のクレカ情報が漏洩してしまったそうだ。

同社の情報によると、以下の情報が漏洩したようで、いわゆるECサイトでクレカ決済するときに必要な情報が全部漏れているのでただごとではない。

①カード番号、②カード名義人名、③セキュリティコード、④カード有効期限

漏洩されてしまった人はもちろん、同社のサイトを運営されている中の人のことを考えるといたたまれなくなってしまうが、今回の漏洩事件はセキュリティ上、どこが問題だったのだろうか。

ネット界隈では憶測がはびこっているが主に、2つのどちらかが流出の経路として考えられる。

• DBに漏洩したクレカ情報を保存していて、そのDBに不正アクセスされた
• クレカ情報を入力するフォームのソースコードを改ざんされて本来、POSTすべきでないサーバにデータをPOSTしていた

以下、@ITの記事を参照する限り、後者が原因らしいがこのJINSが公表しているPDFからはフォームが改ざんされたといったことは一切明記されていないので、独自に取材をして得た情報なのだろうか。
http://www.atmarkit.co.jp/ait/articles/1303/15/news106.html

ソースコードを改ざんして全然無関係なサイトにポストするというのは、技術的にはできそうだが、なぜそれに気づかなかったのかが非常に気になる。ソースを改ざんできたということは、サーバに侵入して直接書き換えるか、そもそもコードをかいてたプログラマが悪意をもってやったことも考えられる。

中国がアメリカにサイバーアタックを仕掛けたりで、すでに戦争はサイバー空間に移行してるようだし、日本もセキュリティ人材を強化してほしいものだ。

名著まとめがいしました

なんというか、基礎力がないのを近頃痛感しており、世間で騒がれている目先の知識・スキルにとらわれずに、腰を据えて勉強し直そうと思い、以下をまとめ買いしました。
どれも分厚く、精読するのも時間がかかるが、世界的権威のタネンバウム先生の本だけあって、本当の意味での基礎力がつくものばかりだと思います。1冊あたり1万弱するので躊躇しましたが、あれこれ読みやすそうなものをいくつか買うよりもコスパはいいのかなあと思いポチリまくりました。まあ、ページ数と内容を加味すると消して1万弱でも高い気もしないですが。

コンピュータネットワーク第4版

オペレーティングシステム 第3版

モダン オペレーティング システム 原書 第2版

分散システム　第二版

構造化コンピュータ構成 第4版―デジタルロジックからアセンブリ言語まで

ちなみに、これのPDF版も購入しましたが、じっくり読む書籍は電子版よりも紙のもののほうが適してる気がします。

コンピュータアーキテクチャ 定量的アプローチ 第4版 (IT Architects’ Archive)

チャンピオンズリーグ マンＵ vs レアル戦から学ぶスタートアップのとるべき戦略

先日、チャンピオンズリーグにてマンUとレアルというサッカー好きにはたまらない一戦があった。
結果はレアルの勝利に終わったわけだが、2戦目にナニがレッドカードをもらうというハプニングがあった。個人的にはあれはレッドじゃないだろと突っ込みたいが、今回はこのカード判定について議論したいわけではない。そのあとのマンUの戦い方に注目をしたい。
なぜなら、あの1点ビハインドになった状態でのマンUの戦い方にスタートアップがとるべき姿が見え隠れしたからだ。

あの試合を知らない人のために、軽く説明をすると、後半ナニがレッドカードで退場になったあと、1点リードしていたマンＵはディフェンスを固めざるを得なく、レアルの猛攻をうける。だが、後半21分にモドリッチのものすごいミドルシュートで失点。そのあと後半24分にもう1点を失点しまった。ここであなたがファーガソン監督だったら、どうするだろうか。

当然、1-2のままでは1回戦敗退だ。2点以上とらなくては2回戦に進めないので攻撃をこれまで以上に重視しなくてはいけない。ただ、10人とひとりすくないのでオフェンスを重視するとカウンターでさらに失点する可能性がある。実際、ファーガソン監督は失点覚悟で攻める戦略を取った。まあ、敗退なら1-2も1-3も変わらないので当然といえば当然の戦略なのだが、似たような状況が筆者が所属しているようなスタートアップにもあるのではないかと思ったのだ。

スタートアップはどこもやることに対して圧倒的に人手が足りないものだ。大企業と比較しても、人員のアロケーションの失敗は会社にとってインパクトが大きいとおもう。
やるべきタスクは大きく分けて攻めと守りの2つに分類することができる。ここで、攻めのタスクとは直接的、短期的に利益になるもの、守りのタスクとは間接的、長期的に利益になるものとしよう。スタートアップは資金的に体力が大企業と比較して弱いので、割合は攻めを多くして、2,3年で黒字を目指すのが一般的だ。守りのタスクをやりすぎて黒字化までに体力がなくなり倒産してしまっては元も子もないのである。つまり、ある程度守りを薄くして、それは承知の上でどんどん攻める、例であげたレッドカードで10人になったマンUのような試合運びをすべきなのだ。
例えば、ある機能を追加, 更新, 削除する場合に、すべてのユーザからいい反応を得ることは難しい。100%を追求するあまり、開発スピードが損なわれてしまっては意味がないわけで、ある程度、批判覚悟で80%程度でリリースしてしまったほうがよいわけだ。もちろん、やりすぎるとクレームの荒らしでヘタすると炎上してしまい、立ちなおれない傷を負うこともあるので限度があることは忘れてはいけない。

以上のようなことを、夜な夜な試合を見ながら思っていたのでまとめてみたわけである。

RailsでMySQLのLOAD DATA LOCAL INFILEを使う方法

パフォーマンス重視で大量のデータをDBにロードするにはやっぱLOAD DATAコマンドですよね。
で、以下のコードをRails(3.2.11)から投入しようとしたら

ActiveRecord::StatementInvalid:Mysql2::Error: The used command is not allowed with this MySQL version

ってエラーがでました。
たぶん、local-infileオプションが聞いてないんだろうなぁと思ってたら案の定そうで、
いろいろ調べ結果、以下で解決しました。

• mysql2のgemのversionを'0.3.12b6'にする
• database.ymlに"local_infile: true"を追加する

rubyでワンライナー

とある仕事で必要になったワンライナー。
入力はTSVファイルで、頭の要素が1だったらその行を出力するもの。