Born Too Late

久々に Padrino で開発していて, データベースには MongoDB, データ永続化層として Mongoid を使っています.

ところがインデックスの作成が上手くできませんでした.
Padrino x Mongoid という構成では, インデックスの作成に以下のコマンドを使います. (長い)

コンソール上では特に問題無く終わったかのようにみえるのですが, 実際は何も起こらずに終わっていました.
MongoDB のコンソールを見ても, 特にインデックスの作成が試みられたようなログは残りません.

調べた所, rake タスク自体に問題がありました.

これはモデルクラスを探索し, 見つかったものを Class オブジェクトの配列として返すものなのですが, モデルクラスのファイルの位置の指定に間違いがあり, 常に空の配列が返って来ていました.
これだと, 探索が行われるのが app/models/*.rb と /models/*.rb となってしまいますが, 実際には models/*.rb を探索する必要があります.

1 Byte の追加でうまく問題が解決しました.
テストはもともと無かったし, ファイルシステムが絡むからめんどいなーと思って書いてません.
すいません…

GitHub で報告したらすぐに取り入れられました.
gem でのリリースはまだですが, これもそんなに時間はかからないと思います.

どうも Padrino のモデルクラスの置き場所が, ./app/models から ./models に移ったようで, そのときの変更のときからずっと壊れていたようです.
多分 7 ヶ月間ずっと動いていなかったみたいなんですが, Mongoid ってあんまり使われていないんでしょうか…

ウェブサービスを作ろうとするとフレームワークのバグにハマり, それの修正で満足してしまって結局ウェブサービスが完成しない, という現象に名前が欲しい.

社内で, 主に MySQL 初学者を対象とした勉強会をやってきました.
社内勉強会ということで, というと言い訳になりますが, いつも以上にゆるふわな内容となっています.

改めて見るとソースどこだよ? っていう情報がいくつかあるので反省.
(「RDBMS を使いつつ, NOSQL で最適化というパターンがほとんど」とかどこのことだよと. まぁ Tumblr とかはそれにあたるみたいですが)

あと, インデックスの仕組みを単純化して話すために B-Tree じゃなくて Binary Search Tree について紹介してますが, この辺も詳しい方の突っ込みが欲しい所です.

ところで勉強会に参加していてよく思うのですが, 勉強会というのは自分で発表してナンボだということです.
これは勉強会で人の話を聞くのは意味が無い, ということではなくて, 自分で調べたときの方が 30 倍ぐらい身に付くんじゃないか, という感覚によります.
どう考えても発表した方がコストパフォーマンスの高い学習ができる.

自分のスキルアップに繋がるからそれはそれでいいんですが, やっぱり社内でとなると, 貴重なみんなの時間を使わせてもらうことにもなるので, 出来る限り聞いてる人の身に付くような工夫を心がけたいなと思います.

そこで今回は, みんなで Binary Search Tree を作る, という参加型の企画を仕込んでみました.
作る, といってもいきなり実装するのはハードルが高いので, ひとりひとりに適当な名前 (タロウとかハナコとか) を順に挙げてもらい, ホワイトボードに Binary Search Tree を書いていくというものです.
(今思えばこれ写真に残しておけばよかった)

思いのほか盛り上がったし, ちゃんと理解してもらえたようでした.
Head First データ構造という感じでおもしろかったです.

あと, スライド中で紹介しているんですが, ハーバード大学のコンピュータサイエンスの授業の動画はオススメです.
教授のテンションがやたら高くて白熱教室という感じ. (ついていくのが大変そうな感じではある)

今回の発表では, Binary Search の文脈で 4:30 辺りの, 電話帳で Binary Search と Linear Search をやってる部分をみんなで観ました.

先週はビッグデータ時代の非ビッグデータ戦略として, MySQL でサクッと MapReduce する話を書きました.
しかしよく考えると, 非ビッグデータを前提とする以上は, やはり普通に GROUP BY とかで済ませてしまうのがよりカジュアルと言えます.

しかしそれをどう見せるか, ということを気にしだすと, これが何気にめんどくさい.
集計時にメールで報告しつつ, 管理ツールのダッシュボード的な画面でも閲覧可能にしたい, という要求はどこにでもあると思いますが, そのときどきで書いていると, クエリを書く何十倍もの時間がかかってしまったりします.

そこで, 例えば RDBMS の結果セットを与えると, それをサクッと見やすく出力してくれる Tablr というのを書きました.
The MIT License にて GitHub で公開しています.

yuya-takeyama/Tablr – GitHub

今どき PHP5.2 で書かれていますが, その辺は何となく察して下さい.
大した機能は無いですが, 個人的にはこれで日頃の問題をいくつか解決できそうなので, 明日からの仕事に使っていく予定です.

使用例

以下は二次元の配列をもとに, プレーンテキストの表を出力するスクリプトです.

ちょっと長く感じますが, require_once や表のデータの部分を除けば, 表の出力に関しては 5 行ほどしかありません.
ここではデータを直接記述していますが, 実際は RDBMS に対して SELECT クエリを発行したときの結果セット等を与えることを想定しています.

これを実行すると以下のような表が出力されます.

以下では Tablr の機能についてより詳細に紹介します.

フォーマッタ

二次元の配列をもとに, いくつかの形式に出力するためのものです.
これが Tablr を作りにあたっての一番のモチベーションとなっています.

現在利用可能なフォーマッタは以下の 2 つのみとなっています.

• プレーンテキストフォーマッタ
• HTML フォーマッタ

アグリゲータ

それぞれのカラムで集計を行い, テーブルのフッタにその行を追加します.
現在利用可能なアグリゲータは以下の 2 つのみとなっています.

• 合計アグリゲータ
• 平均アグリゲータ

とりあえず必要最低限の機能を実装した, という感じで, 作り込みはかなり甘い感じです.
使えそうな感じであれば, またさらに改善して行きたいと思います.