Slim3でTwitterのbotを作ってみた

TwitterのbotをGoogleAppEngine（Slim3）+Twitter4Jで作ってみた。
やれやれ、1～2日で終わらせようと思っていたのに、3連休全部使ってしまった(苦笑)

Slim3ではControllerをbuild.xmlで自動生成できるのが、地味に便利だ(笑)
URIに紐づいているのがパッケージ名・クラス名だけなので、Strutsだとstruts-config.xmlとかを書く必要があるけど、そういうのが無いから修正も楽だ。

Controllerの生成は、jspの生成を伴うものと無いものに分かれているのも良い。
Twitterの認証の様に他のURIにリダイレクトする場合はjsp不要。
Strutsでも出来るけど、Struts風の書き方ではなくなるような気がする。

botでつぶやこうと思ったらbot用のユーザーIDでOAuth認証を通しておく必要があるけど、毎回パスワードを入れるなんて有り得ないのでどうしようかと思ったが。
OAuthの申請時に「クライアント」と「ブラウザ」の2種類あって、GAEは当然ウェブアプリだからブラウザタイプと単純に思い込んでいたのがいけないようで、クライアントアプリにして暗証番号を画面から入力できるようにすればいいだけだった。（アクセストークンは当然DBに保持する。GAE・Slim3便利だ！）
つーか、このやり方でいいのかどうか分からんけど(苦笑)

GAEのcronやqueueも便利だ～。
定期的につぶやく（Twitterに投稿する）にはcronを使うし、その際に実際の実行はqueueに任せるようにすれば、エラー時にも勝手にリランしてくれる。
もっとも、データに問題があって常に例外が発生するようなパターンだと、何度もリトライすることになってしまうが(汗)
そういえば、cronとかqueueって「どうやって実行するプログラムを指定するのか」と事前には思っていたけれど、実行するURIを指定するのな。ウェブAPIを使うことに慣れてなかったからその発想はしてなかったけど、もう当たり前なんだろうな～。

GAEの管理コンソールもさすがに一通り揃ってる。
DB（Datastore）の中も見られるし、削除も出来る。（プログラム内で検索条件・ソートに指定した項目は、自動的にインデックスも作られるようだ！）
ログも確認できるし、cronやqueueの実行状況、各URIのアクセス数なんかも分かるようだ。
強いて言えば、日付時刻はローカル（つまり自分だと日本・JST）に合わせて表示してくれるといいんだが。
（そういえば、Twitter4Jを使うと、起動時にログが出ちゃうんだよな。GAE上ではあまり意味が無いし邪魔なので、消す方法も調べたいところ…）

さて、でも今回作ったbotは、まだテストが完了してないんだよなぁ。
なにせ登録した文言を75日後にツイートするものだから(爆)
もしかしたら同じような発想のbotも既にあるかもしれない、というか有っても不思議じゃないし＾＾；

Slim3をマスターした！（大嘘）

Slim3をマスターしたなんてのには遥か全く遠いが、JSPとControllerを定義して一連の画面遷移（入力画面・精査・DB登録・DB取得と結果出力画面）は出来たから、基本は出来たと言ってもいいのではないかと。
おっと、HttpSessionがちゃんと使えるかどうかについてはまだ試して無かったな…。
そもそも実際のインターネット上で動かしてもいないのだが＾＾；

やったことはほぼSlim3日本語サイトのスタートガイドそのままだから、いかにこの説明がきちんと網羅されているかって話だよ。素晴らしい。
若干、DB登録用のControllerクラスの命名をどうするかとか、Validatorはどこで実装するかって事は悩んだけど。
あと、テストのコーディング例まで書いてあるのは、「テストをきちんと書け」という意思表示なんだろうな、きっと。…今回はサンプル的なものを作っただけなので全部のテストケースまでは書かなかったけど＾＾；

自分はStrutsのActionとJSPをごりごり書く古いパターンしか知らないので、でもSlim3でもそんな感じで書けたので分かり易かったのかもしれない。（つまり古いタイプの人間でもとっつきやすい）
DBから値を取ってくる為のQueryの項目指定の方法なんかは、今まであまり見かけないコーディングパターンだったので、興味深かったし。

Hadoopソースコードリーディング第5回

Hadoopソースコードリーディングに（開催はもう5回目なのに）初めて参加しました。
（→Hadoopソースコードリーディング第5回 ハッシュタグまとめ）

今日の会場は楽天タワーだー。品川シーサイド駅から徒歩1分。
って外に出るまでの地下が長いじゃん。やられた＾＾；

---

最初はNTTデータの濱野さん。Hadoopチーム11人でやってるそうで。

・数十TB～100TBをPostgreSQLでやってきたが
・10億件超・60万件/時でHadoop
・2008年ごろから数十～数千台のクラスターを動かしてきたので、環境の同一性確保や故障時の再構築といった運用面のノウハウがある。
・2～3台ではHadoopを生かせない。20台くらいのクラスターが今後増えてくるのではないか。

・台数を増やすとスペックの違うマシンが混在するようになってくる。すると処理遅延や処理失敗を引き起こす。★★★
300台構成のクラスターは、全部同じスペックにした。
（◆●どういう理由で処理が失敗するんだろう？？）

・1000台構成だと、エンドのスイッチは安めだが、ラック間は10Gとか。ラック内も1Gとか。

・クラスターの台数は、MapReduceの処理（ジョブ）数ではなく、データ数から決めている。★★★
1TBのハードディスクを4玉、CPUはそれに見合ったもの。

---

次はNTTデータの山下さん。Hadoop Summit 2010の紹介。（◆●6/29、サッカー日本代表の試合の日だったそうだｗ）

Yahoo：
5億クリック/日、のデータを使用して個人の嗜好を分析。
なお、Yahooでは「リアルタイム」を5分間隔としているらしい。★★★
YahooメールのスパムフィルターはGmailより優秀だとか。

Amazon：
今まではHadoop0.18.3・Hive0.4・Pig0.5
これからはHadoop0.20・Hive0.5・Pig0.6
SPOT INSTANCE
Elastic MapReduceで処理時間が短縮・値段も20％削減。

Facebook：
2250ノード・2万3000コア・32GB RAM/ノード・36PB Hadoopクラスター
ジョブの95％はHive
障害に備えて、2クラスターに全く同じデータを入れている。★★★
（◆●実際に障害が発生したことってあるのかな？？）

Twitter：
HBase使用（◆●なんか久しぶりにHBaseの名前を聞いた＾＾；）

その他：
天体画像（星の位置関係を計算）でHadooop利用

◆●Hadoop関連プロダクトの“マスコット”一覧にみんな失笑。“マスコット”という言葉から連想されるような可愛いキャラは皆無だ(爆)

---

@okachimachiorzさん『ClouderaのHdoopトレーニングについて第4回』
（◆●けど自分は初参加なので、前が分からない＞＜）

『グラフアルゴリズムin MapReduce』
グラフはリストや行列で表せる！★★★
行列は数学的には扱いが楽で、逆ポインターも分かる。が、0が多いので無駄が多い。
リストは逆ポインターは分からないが容量がコンパクト。プログラムはこっちを使用する。

探索は深さ優先探索と幅優先探索がある。
深さ優先…再帰的
幅優先……キュー。MapReduceはこちら
MapReduceは関数型だが、分散処理するので幅優先で探索すべし。★★★

『ダイクストラ法』（◆●名前だけは聞き覚えがあるが…）
スタートノードからつながっている全てのノードの距離を幅優先で算出。
次に一番近かったノードに対して同様に処理していく。
しかしこの方法はMapReduce向きではない。（◆●理由はよく理解できなかった＞＜）
なお、Hadoopトレーニングではダイクストラ法は1分で説明が終わったらしい(爆)
→@cocoatomoさんの文系 Hadooper でも分かる Dijkstra アルゴリズム

『SSSP：単一始点最短距離経路』
（◆●説明が早口だったのでほとんどメモ（理解）できなかったorz）
ダイクストラ法が最小のノードだけを調べるのに対し、こちらは全ノードを検索する。
（◆●まぁ数が多くても力技で処理するのがMapReduceか＾＾；）

データによっては、ごく稀に間違った結果が出ることもある。
どこまで行ったら終わりにするかという終了条件が重要。
大抵はベストエフォートでよさそう。（値が一定になってきたら終わる）
原価計算とかなら確実な値が必要。（いつ終わるか分からないけど、最後まで計算する）

『PageRank』
原理：ページの持っているポイントをリンク先に配る
あるページには、複数のリンク元からポイントが入ってくる。（ただの足し算）
そのページから、複数のリンク先へポイントを配る。（ただの割り算）
（ただの足し算と割り算。Googleも大したことないね！by okachimachiorzさんｗ）
ただし、リンク先が無いとそのページにポイントが溜まってしまうので、全ノードにポイントを配る。
このMapReduceを繰り返すと、そのうち収束してPageRankが確定する。

『Hadoopでのjoin』
方法は3通り。
・Mapサイドjoin…王道。ただしメモリーに収まる範囲でやること
・Reduceサイドjoin…join用のキーを同一にしておけば、勝手に集めてくれる。分かり易いがReduceの負荷が上がるのにスケールしないので、やるべきではない
・分散キャッシュ…全ノードにデータを配っておく。トレーニングではmemchachedを使用

（応用として？）分割Map-join…マスターを分割して個別にMap-join。
（◆●マスターを分割してどうして結合できるのか、ちょっと理解できなかった…重要そうな話なのに＞＜）

◆●自分はMapReduceのプログラム方法に興味があるので、join方法の話は面白かった。
分散キャッシュというのは、象本でもSequenceFileをプログラムと共に配布する例が載っていたような。
今度豊洲でHadoopトレーニングがあるらしいが、日本語だったら受けてみたい感じ。

---

@nokunoさんの『MapReduceアルゴリズムデザイン』
（◆●昨日資料が公開されていたけれども、やはり話を聞いた方が理解しやすい＾＾）

パフォーマンス改善の為に、Shuffleフェーズのデータ量を減らそうという話。★★★
Mapperの中で計算して（Combinerと同じことをして）、Combinerを使わないようにする。
Combinerはシリアライズしてたりするので、オーバーヘッドがあるから。
ただし当然メモリーの制限は気にする必要がある。

また、PairsパターンよりStripesパターンの方が良い理由は、エントリーの数が減る、すなわちソートのコストが減るから。★★★

出現頻度が高い単語だけを抽出するような場合、頻度の少ない単語はカットしてしまうような方法が考えられる。
ただしCombinerでカットしないよう注意。（◆●合算すると頻度が高くなるケースも有り得るから？）

キーを可変長整数VIntWritableにすると、キーの量が減らせる。（◆●そういえば、VIntWritableはそのまま大小比較が出来たような気もするので、便利なのかも）

セカンダリーソート：GoogleのMapReduceにはセカンダリーソートがあるらしいが、Hadoopには無いので自前でComparator等を用意する。

◆●初めてHadoopチュートリアルのWordCountを勉強していた頃、「Mapperの中でHashMapに格納して単語数を計算しちゃえばいいじゃん」と思ったけど、そうするとMapReduceらしくないのでダメなのかと思っていた。
今日の発表は、まさにMapperの中で単語数を計算してしまえ、という話だったｗ
「Combinerを使わない」と盛んに言っていたけれど、冗談なのか本気なのか、どちらなんだろう？(爆)

---

最後は@quarterkotaさんのAmazon Elastic MapReduce（EMR）の話
（今日の会場では、EMRを使ったことがある人は1人だけだった模様＾＾；）

なぜEMRを導入したか？
MySQL：
○情報が多い、事例が多い（工数見積もりがブレにくい）
×件数億単位は無理、Oracleに買収されてから怪しい（◆●発表時には敢えて読まれなかった一文ｗ）
Hadoop：
○大量データに強い、事例が増えてきている
×ノウハウ不足、ハードウェアを決定できない（≒スモールスタートできない）
↓
で、AWS勉強会で偶然聞いたEMRに着目
○大量データに強い、スモールスタートに向いている、環境構築工数が少ない
×国内事例がほとんど無い、パフォーマンスが未知数
↓
で、Hiveを使ってパフォーマンスを測定してみた（2・4・8ノード）。
LOADはインスタンス数が多いとオーバーヘッドが多くて遅くなる。
SELECTはほぼインスタンス数に応じた時間になっている。（2ノード→4は半分より良い、4→8はちょうど半分程度）
（でも2ノードではあまり使わないだろう）

EMRは管理性が良い（GUIがある）、Hadoopの知識はそんなに要求されない。
（◆●実際のところ、パフォーマンスを追及すれば、やはり知識が必要になってくるものらしいが）
EMRの情報は少ないが、AWSユーザーコミュニティーがサポートしてくれる（忍者も！）。
EC2の通常のインスタンスとは使い勝手が少し違う。

使われないサーバーリソース（在庫）を自社で持つとコストがかかるが、EMRならAmazonに持ってもらえる。
US-EASTのsmallインスタンスなら1時間0.1ドル。
常駐型でなく、Hadoopを自動起動・自動終了すると良い。

1億2千万件（百数十GB）を8サーバーでSELECTしたのが1200秒＝20分。EMRは1時間毎の課金なので、0.8ドル。

ちょっと別件：S3に構築したら2～3割スピードが落ちた。（その程度で済んでいるとも言える？）

---

◆●最後に、ピザの片付けを手伝いました（残すともったいないので、腹回りを気にしつつも？ｗ）。それくらいしか役に立てなくてごめんなさい。
発表者や会場の皆さん、ありがとうございました。

R&R EXTRA『まるごと一冊 冒険企画局』

Role&Roll EXTRA『まるごと一冊 冒険企画局』

Role&Rollの別冊と言えば『Lead&Read』っていうイメージがあったので、冒険企画局で別冊って、何だそりゃって感じ(笑)

しかし冒険企画局ってTRPGの団体かと思ってたら、色々やってたんだなー。
あまりにも色々ありすぎてすぐには読み切れないので、ひとまずリプレイ部分だけ見ると。

各ページの下の方にTwitterで何やら募集した結果が載ってて「フンバルト・ヘーデルホッヘ」の名が！！(爆)
どこで見たかは忘れていたが、その名前だけはしっかりはっきりくっきり覚えてる。そうか、こいつは冒険企画局の仕業だったのか！おぼろげだった記憶がしっかり固定されてしまった。もう一生忘れまい！？
つーか、確かにファンタジーRPGクイズは見たことある。持ってはいなかったから、誰かから借りたんかなぁ。

いやいや、話がのっけからちょっと逸れたけど。
リプレイは“読者投稿リプレイ”～？　さすが冒険企画局、何でもアリかｗ
でも、さすがに採用されているだけあって、いいね。
自分が作ったシナリオじゃないから、“シナリオをどこまで読めばいいか”なんてことでも迷ってる姿が新鮮だなぁ(笑)

改めてざっと見ると、冒険企画局の各作品ともそれぞれ根強い人気が残っているようだよね。
『光と闇のレジェンド』なんて、けっこう中途半端な感じで終わって惜しいもんなぁ。急遽盛り上がった今が完結編を出すチャンスだ！
あと、エディスと猫の続きも見たいよ。『タイムスライダー』も膨らませると面白いと思う。
つーか個別にリクエストを出すのが面倒なので、この際だからアップルベーシック全部まとめて続編をｗ

Slim3の始めの一歩

ちょっとGAE（Google App Engine）で作れるんじゃないかと思ったものがあって、画面から入力したものをDBに保存するならMVCモデルを使いたいよなーと思い、それならということでSlim3を使ってみることにした。
トランザクションはとりあえず要らない予定だけど、JDO/JPAよりDBアクセスが高速だと言うし(笑)

ただ、Slim3って、付け焼刃では厳しい／最初のハードルが高いかも＞＜
チュートリアルの手順通りに進めていって、一応サンプルとしては動いたけれども、何を設定したんだかよく分からない…。
ブランクプロジェクトからの初期設定が多いので、気軽に作り直しもしづらいし。
部品作りは自動生成できるけど、不要な場合にどれを消せばいいのかよく分からないし。
Strutsと違って設定ファイル類が要らないようなので、慣れれば簡単そうなんだけどな＾＾；

ちょっとしたものを作りたいだけの場合、どこまで学習コストをかけるか、微妙だなぁ(苦笑)
他にやりたい事も色々あるからなぁ…。