Study Mailをバージョンアップしました

Study Mail

　Study Mailをバージョンアップしました。IT勉強会はコミュニティでもあり、その中には地域に根ざした技術者コミュニティとしての性格を持つものがあるのは皆さんもご存知だと思います。また、地方では例外はあるものの勉強会そのものの開催が少なく、とにかく近くでやっていて現実的な範囲で行ける勉強会が知りたい、という需要があることもわかってきました。
　そこで今回のバージョンアップでは精度の向上、対応範囲の強化に加えてコミュニティとエリア、二つのノーティフィケーション機能を実装しました。どちらも地域に関係した機能となります。
　

コミュニティ

　pmのように、伝統的に地名に対象となる技術をあらわす拡張子をつけて○○.xxという形で表記されるタイプの地域技術コミュニティ主催の勉強会に対応しました。拡張子の部分を登録すると、その拡張子に相当するコミュニティの勉強会が登録された時にお知らせします。
　ただし、node.jsのように同じフォーマットで表記されるプロダクトはフィルタリングしていません。地名として緯度経度を求めれば存在しない地名ということでフィルタリングできるかと考えたのですが、試しにGoogle Places APIにnodeと入力したらワイオミングの地名が出てきた時点で心が折れました。
　地名の部分も、後述するエリアとして判定しています。

エリア

　IT勉強会であると判定された場合、先述のコミュニティの地名表記と、atnd、eventATND、zussar、connpassのAPIから取得できる緯度経度情報を元にエリアを判定してお知らせする機能です。
　対応しているのは

  1. 都道府県とその直下の市区町村
  2. 最寄り駅とその路線
  3. 地方名

　
　
　です。
　いつもの電車の降りる駅を少し変えて勉強会に行ってみたらどうでしょうか?

判定ロジックの変更

　判定ロジックを見直して、C++やF#みたいなキーワードにも反応しやすくしました。
　また、フィルタリングを強化して有料セミナーや出会い系まがいのイベント、DJパーティ、関連イベント等と称して大量にキーワードをちりばめるタイプの勉強会の誤判定を減らしています

どうぞご利用ください

BEAR.Sunday Meetup #0に参加してきました

PHP フレームワーク

　PHPのフレームワーク、BEAR.SundayのMeetUPに参加してきました。

Ray.Di Ray.Aopことはじめ

　

Bear.Sundayのコア部分の解説

  1. 「問題の解決に実装でなく設計で挑もうとしている」
  2. さまざまな思想が詰まったフレームワーク
  3. RayとBEAR.Resorceの二つの柱
  4. RayはGoogle Guiceがヒント
  5. RAY,DIはAura.Diベース
  6. とてもクリーン。全て外部から注入され、固定クラスが無い
  7. Doctrin/Common.Annotationsによるアノテーション実装
  8. Symfonyライクな書き方も可能
  9. アノテーションでインジェクションを指定する場合
    1. モジュールで設定を定義
    2. 通常のコンテナで取得
    3. インターフェースを必要とするところに一度に注入できる
  10. モジュールは特定の関心領域についての設定や構成を行う単位
  11. モジュール自身もDIによって入れ替えられる。
  12. ふるまいはAOPで変更する
  13. Ray.AOP
    1. 横断的関心指向プログラミングを実現するフレームワーク
    2. 実メソッドが呼び出される前に処理を挟み込む
    3. インターセプターは実メソッドが呼ばれているかどうか、どういう位置付けにあるかを知らない
  14. Ray.DIはオブジェクト生成のためのフレームワーク、Ray.AOPはオブジェクト利用のためのフレームワーク
    1. 生成と利用の分離
    2. 生成レベルでキャッシュできるので、コストが非常に低くなる

　ここでBEARの開発者によるオブジェクトグラフの説明。

  1. オブジェクト同士の依存関係のネットワーク
  2. Facadeとなるルートオブジェクトを取得すると玉突き式に依存するオブジェクトが取得される
  3. 早期束縛と遅延束縛をフレームワークレベルでわけて扱うことでキャッシュを効率化
  4. 現状はAPCキャッシュのみ。速度と依存関係の解決のため
  5. AOPによって横断的処理だけでなく、モックとの接続や処理の動的分岐、キャッシュの高度化などができる

僕と熊の三年間

　エキサイト(!)でBearフレームワークを全面的に採用したケースについて

  1. 最初期バージョンから全面採用
    1. はじめはエキサイトブログの携帯版
    2. 学習コストの低さから全面的に採用に
  2. 次にBEAR・Suturday
    1. Roaは強烈だった
    2. 学習コストは高くなった(といってもなんとなく動く)
    3. DIシステムでレガシーシステムとの接続を隠蔽できた
  3. 今でも全面的に使用している

リソース指向のデータ転送

  1. HTML5ではローカルにデータベースがある
  2. 連番IDを採用すると問題が生じる
  3. 課金のようなケースではどうするか？
  4. リソース指向でIDの付け替えを隠蔽
  5. 苦労した割にデータベースの同期くらいしかできないので応用方法を募集中

開発者によるBear.Sundayの開発

Frameworkとは何か?
  1. 設計思想である
  2. 設計思想とはシステムに秩序をもたらす価値観
  3. どのような価値観をもって問題を解くか？

オブジェクト指向とは何か?

  1. オブジェクト指向には二つある
    1. ひとつはアラン・ケイのOOP
      1. ダイナブック構想の人
    2. メッセージング・状態処理のローカルによる隠蔽、遅延束縛
  2. C++の作者のOOP
  3. カプセル化、継承、多態性
データ構造とオブジェクト
  1. データが外部にあるのが手続き型、内側にあるのがOOP
  2. Tell型とASK型
    1. オブジェクト指向では、オブジェクトに｢話す｣
    2. 手続き型では、対象を取得する（ASK）
  3. 手続き型とOOPはお互いに苦手なところが得意

MVC

  1. MVCについては捕らえ方が人によってばらばら
  2. パターンは価値観の表現が無意味
  3. 「MVCはアプリケーションのパターンではなく関心の分離のパターンである」
  4. 典型的なMVCはtellでなくASK
  5. ROAの条件
    1. アドレス可能性
    2. ステートレス性
    3. 接続性
    4. 統一インターフェース
BEAR Sundayの場合
  1. リクエストに対してリソースの表現が返る
    1. 関心事に応じて複雑になる
  2. これならぱtell
  3. アクセスはURIと挙動で
  4. 戻り値は常にリソースオブジェクト
  5. モデルをオブジェクトにしなければもっとわかりやすくなるのではないか?
    1. 世界最大のスケーラブルモデルであるwebの構造をまねする
  6. 状態をViewに変更するのがリソースレンダラ
  7. リソースごとにテンプレートエンジンを注入
  8. リソースは関係性を元にリンクをもち、関係性を隠蔽している
  9. リソースが関係性でつながっている(リソースグラフ)
  10. リソースがURIで表記されることで抽象度を上げ、依存性をなくす
  11. Because Everything is A Resorce

「問題の見方。物事をどう見るのかが大事」

Mongo DB Casual Talksに参加してきました

MongoDB




渋谷のDeNAさんで開催されたMongo DB Casual Talksに参加してきました。業界用語で言うところのカジュアルにふさわしい、ガチの勉強会でした。

MongoDBのアレ

  1. MongoDBはクラスタリングやシャーディングが自動的なのが魅力
    1. ただしシャード設定の不備があると、本当に突然パフォーマンスがダウンする
  2. バックアップはオートバランスを停止してから
  3. ロックがグローバルなのに注意
  4. 障害・ログ
    1. mogostat
      1. faultが多い場合はメモリ不足の可能性あり
      2. Locked%が高い場合は書き込みを分ける
      3. qr|qwもロックの可能性を疑うこと
  5. mongosniff
    1. 複雑なクエリなどを見るときに
  6. Loglevel変更は動的にできるので、何かあった時にあげるといい

「みんなもカジュアルに100シャード運用してみよう！」

Casual Compression onMongoDB

  1. 「今日はデータ圧縮の話をします」
  2. トランザクションは甘え
  3. 標準ではデータ圧縮未サポート
  4. カジュアルに圧縮
  5. レコードひとつひとつフィールド名がある→短くすればサイズ短縮可能
    1. OR Mapperをつかってサポート
  6. 圧縮・伸張の早いアルゴリズムを使う
  7. シリアライズはMessagePack
  8. 効果はあるが副作用も大きい

「大きいデータ扱うならHBaseがおすすめ」

AWSでMongoDB

  1. ロードバランサーの裏でデータセンターをまたいでサーバーとDB
  2. 10genがイメージを出している
  3. ディスクの性能
    1. EBSは複数つけて性能向上
    2. インスタンスを大きくしても回線が太くなってEBSの性能が上がるので大丈夫
    3. それでもダメならばシャーディング
  4. バックアップもスナップショットで簡単
  5. 手順
    1. 静止点を生成
    2. スナップショットを取得
    3. わずか数秒
  6. データセンターをまたいでもそんなに遅くならない

LT1 mongodbを使ってみたい

  1. MongoDBは嫌い
  2. でもクエリーは好き
  3. だからMongoDBと同じクエリでMySQLが使えるORマッパー作ったよ
  4. リーダブルコードにしたい

LT2 mogodbでカジュアルなタイムラインの実装(資料)

  1. 実際にサービスで使っているもの
  2. MySQLで重くなるものをMongoDBで
  3. スキーマは残念
  4. CappedCollectionが最適→無駄にコレクションが増える→限界がすぐ来る→DBがたくさん→止まりまくり（^^;）

「Mongoはカジュアルに導入しない」

LT3 カジュアルに非公式データパックアップ(資料)

  1. Mongoexportはデータが壊れる
  2. Mongodumpはデータが大量に出てしまう
  3. データ量が多いとリストアも大変
  4. とりあえずsecondaryを落としてみると意外と早い?
    1. lockした方がいいかも?

LT4 アーキテクチャ的な何か(資料)

  1. 追記型のメリットデメリット
    1. 書き込み周りがシンプル
    2. 代わりにゴミが増える、インデックスの更新などのデメリット
  2. 追記を避ける為にpadding facter
    1. insert以外で増える

LT5 カジュアルなMongo　dbの運用

  1. 一年サービス運用した経験から
  2. 定期的なチェック重要
    1. シャーディングの偏りチェック等
  3. バックアップ
  4. 定期的な最適化
    1. ただし時間がかかるので注意
    2. V2系からコレクション単位で最適化
    3. ただし物理サイズは減らない

LT5 casual sukcks(資料)

  1. Mongoの不満点
    1. スワップしまくり
    2. Rubyクライアントでデータが飛ぶ
      1. 治ってないらしい
    3. RubyのBSONの実装が異なる二つのバージョンがある
    4. 名前についての制限がマニュアルにない
    5. まだででないバージョンでドキュメント化
      1. 全然足りない

「MongoDBなんてみなさんもう使うこと無いと思うんですけど☆」

LT6 mongoengineでカジュアルな有向グラフ(サンプルコード)

  1. 「有向グラフがわからない人はニュアンスでお願いします」
  2. MongoDBで有向グラフを作って分析できるPythonライブラリ
  3. カジュアルに使えるが、あまり大きなデータはダメ

「MongoDBさんはスモールデータには最適だよ!」

LT7 MongoDBとfluentdの素敵な関係

  1. はてなのCTO
  2. Mongoはリソースくいということでメイン使用はしてない
  3. ファイルで疎結合
  4. ソケットでつなぐとデーモンの不具合に巻き込まれたりする
  5. プラグインを書いてログの集積にしよう
  6. Mongoはフロントエンドも素敵
  7. 基本的に一週間程度のログを保存。のこりはファイルに

「スモールデータを保っています」


※追記

　お寿司、おいしゅうございました。

Pythonでの日本語メールはUTF-8がベストかも

Python Django

　Study Mailの開発で日本語メールの問題にぶつかりましたので、その解決方法を公開します。結論としては、Pythonの場合はUTF-8でエンコードしてしまうのがベストのようです。

Dajngo　EmailMessageで文字コードを指定する

　よく知られているように、日本語で書かれたメールを送信する場合はiso2022でエンコードするのが一般的です。二バイト文字のエンコードに問題の多いことで知られるPythonですが、幸いエンコードそのものについては部品として切り出して使えるwebアプリケーションフレームワークDjangoを利用することで問題なく行うことができます。
　Djangoには電子メールのメッセージを表現するEmailMessageクラスがあり、メールとしてのメッセージの組み立てを簡易化してくれます。文字コードについてもドキュメント化こそされていませんがソースを読むとencodingというメンバ変数があり、そこで指定できることがわかります。
　Django1.2以降におけるもっとも単純な日本語メールの送信方法は以下のようになります。

from django.core.mail import EmailMessage,get_connection

email = EmailMessage(subject, message, from_email ,to = recipient_list)
email.encoding = 'iso-2022-jp'
connection = get_connection(backend = 'django.core.mail.backends.smtp.EmailBackend' ,host = {ホスト},port = 25, username = {smtpのユーザー名},password = {パスワード})
connection.open()
connection.send_messages([email])

　ここで問題となるのはエンコードに使う文字コードです。Pythonの場合はエンコードできない場合は送信できないので、実際のところは単純にiso2022では対応できません。

UTF-8を最初から使うという選択肢

　元の入力がUTF-8の場合、iso2022では以下の文字に対応していません。

  1. 〜(波線)
  2. ノーブレークスペースをはじめとするUTF-8特有の空白文字
  3. 半角カナ
  4. 「はしご高」等のIBM拡張文字列

　このうち、前の二つまでは比較的単純な文字列置換で対応できます。

body = body.replace(u'\uff5e', u'\u301c').replace(u'\xa0',u'').replace(u'\u2028',u'').replace(u'\u2029',u'')

　また半角カナについては拡張iso2022で対応可能です。
ただし最後のIBM拡張文字列に対しては大規模な対応テーブルを作成する必要があり、非常に手間がかかります。さらには最近のスマートフォンのメールクライアントには拡張iso2022に対応していないものがあります。このことに気がついたのは私の使用しているAndroid携帯のデフォルトメーラーがきっかけでしたので、現状では全てのAndroidのデフォルトメーラーで拡張iso2022が表示できない可能性があります。
　将来的にいわゆるガラケーは退場してスマートフォンが主流になっていくことを考えると、現実的には最初からUTF-8で送信してしまうのが確実でシンプルでしょう。

勉強会関連のツールとかのまとめ

勉強会

　ちょうど、Study Mail関連で面白いことも解ったのでまとめておきます。

勉強会を探す

　まず、はじめて勉強会に行こうとする場合はイベント支援サイトを見るか、検索、あるいはまとめ系のサイトを参照にするかの二つの方法があります。
　まず前者ですが、IT系の勉強会が告知されているイベント開催支援サイトは以下の5つです。

・ATND BETA
・Event ATND
・zussar
・connpass
・partake

　まとめや検索のサイトとしては、以下のようなものがあります。

IT勉強会カレンダー
IT勉強会カレンダー検索
azusaar

　このあたりで、気になる勉強会をみつけて探してみるといいでしょう。いきなりすごいことになったりはしませんので、気軽に参加してみてください。

勉強会を追いかける

　定期的に勉強会に行くのは、日程あわせ以上に手間がかかります。
　ざっくりいいますと、現在、Study Mailで捕捉している範囲に限っても一日あたり15〜20件程度の勉強会の告知があり(日曜日はさすがに少なくなりますが)、開催場所は東京だけではありません。またどのイベント支援サイトにも勉強会以外のさまざまなイベントが毎日のように投稿されています。なので、手動で追いかけるのは現実的ではありません。
　まず、行った勉強会がコミュニティによって定期的に開催されている場合はメーリングリストを公開していることが多いので入っておくといいでしょう。
　もしそれ以外の勉強会情報を追いかけたいのであれば何らかのツールなりサービスなりを利用する必要があります。
　先述のIT勉強会カレンダー、私の開発したStudy Mailの他に、以下のようなツールがあります

・atnd Notify
・ZussarNotify-modoki

また、IT系の勉強会が掲載されているイベント開催支援サイトには基本的に対応するtwitter botがあります

・atnd(非公式。繰上りがあった時にも投稿)
・zussar
・connpass
・partake

　ただ残念ながら一日あたりの告知数があまりにも多いため、お守りくらいに考えておいたほうが無難です。

まとめ

　勉強会に行くと人生変わるかも?　なんて言われますが、別にそんなことはありません。なので、気楽に行きましょう。うまくはまるとすごくいい刺激やヒントになるのは確かです。外れだったら別の勉強会に行けばいいのです。
　ただし、追いかけるのは少し大変なのでツールをうまく活用する必要があります。

IT勉強会の自動チェックサービスを作りました

勉強会 Study Mail

　本日、Study Mailというサービスをリリースしました。気になるキーワードを登録しておくと、対応している6つのサイトにそのキーワードがメインテーマ(らしい)勉強会が告知されたのを検知してGoogleかFacebookのアカウントに紐づいたメールアドレス告知されるサービスです。
　最近、イベント開催支援サイトも開催数そのものも増えてきて、すでに追いかけにくくなっている現状の私なりの解決策です。

　開発中には水道橋にあるコワーキングスペース「ネコワーキング」のぬこをはじめ、さまざまな方のアドバイスをいただきました。この場を借りてお礼を申し上げます
　
　なお、どこかのサービスに名前が似てしまいましたが本当に偶然です。
　

仕組み

　基本的な流れとしては以下のようになっています

  1. 対応しているサービスが公開しているRSSを取得
  2. タイトルと説明文をひとつの文章にまとめてから、Yahooキーフレーズ解析で抽出
  3. 抽出したフレーズとタイトルを正規表現で処理してさらに候補を取り出す

　正規表現では「カタカナのみ(クラウドとか)」「英語と一部の記号のみ(言語名など)」「漢字のみ(関数型言語など)」「三つのハイブリッド(継続的インテグレーションとかFacebookアプリとか)」を取り出すようにしています。キーフレーズ抽出だけではいまひとつだったのですが、このステップを加えることでITの技術用語を高い確率で取り出せるようになりました。

バックエンド

　個人的な勉強をかねてサーバーはdotCloud+MySQL、フレームワークはDjango。画面はTwitterbootstrapをベースにしています。dotCloudは実質ひとつしかない無料枠とはいえcronもメールも無料で使えるのが魅力的なのですが、データベースがそのままだとlatainだったり、cronで動かすときとwebサーバー経由で動かす時とCLI経由で動かす時で微妙に環境変数が異なったりと意外とはまりどころが多く苦労しました。
　Djangoも、疎結合でいじりやすいのはいいのですが書く部分が多いのが大変でした。実は未だにセッション周りとか不安が無いわけではありません。

TODOとか

　すでにいくつか要望をいただいているので、ぼちぼちと手をつけていこうとおもっています。緊急性の高い課題として、私が所有しているandroid携帯では文字コードの関係でメールが読めなかったりするのでここは早めに改修したいです

　

泥水の上澄みは飲めない

開発手法

なぜ CoffeeScript がダメか - 冬通りに消え行く制服ガールは✖夢物語にリアルを求めない。 - subtech
なぜ CoffeeScript がよいか - 0xff.toBlog()

　CoffeeScriptの是非をめぐる議論が盛んです。私個人としてはCoffeeScriptには懐疑的ですが、それは置いておいて一歩引いて考えるとここで挙げられている論点のほとんどは開発手法であれ技術であれ何か新しいものを取り入れる時にかならず出てくるものです。
　果たして、新しいものはいつ取り入れるべきか?　結論としては、泥水の上澄みは飲めない、ということになります。特にインターネット系の技術開発では比較的簡単に変化できるソフトウェアとソフトウェアに比べて簡単に変化できないが他の産業に比べれば変化が早く、かつ仮想化やクラウドなどの影響で加速がハードウェアの両方に影響されるため、最終的には何らかの形で積極的に新規技術を取り入れるハイリスクな行動と枯れた技術を保守していくような堅実な行動をミックスさせて対応するしかありません　


デメリットはメリットである

　二つの議論はどちらもメリットとデメリットを挙げるという形式になっていますが、抽象度を上げた形で書き直すと次のようになります

メリット
  1. 難しかったことが簡単になる、あるいは不可能だったことが可能になる
  2. 失敗が少なくなる
デメリット
  1. 従来の手法・知識が使えなくなる
  2. 将来の保証がない

　こう並べて行くと単純にメリットデメリットを切り分けられそうですが、実はそうではありません。
　従来の知識や手法が使えなくなるということは逆にまったく新しいものを作り出すチャンスでもありますし、また従来ではできてしまった危険な行動に対して制限がかけられるということでもあります。また将来の保証がないということは、失敗する可能性と同様に大化けする可能性も意味しています。しかし、簡単にできなかったことが簡単にできるということは人材や対外的な努力の証明などに一定以上のラインが必要な場合に問題が生じる可能性もありえます。

フリーランチはないが、腹痛は分散できる

　結局のところ、結論としては冒頭で述べとおりフリーランチがなく泥水の上澄みだけを飲めない以上は何らかの形でお腹を壊す覚悟で新しいものを取り入れ続けるしかありません。
　歴史的に見て新しい道具であるため、ベストエフォートからフレームワーク、業務システムの導入までIT技術と呼ばれるものは今まで何か大きなものをあきらめることでより大きなものを手に入れる、という特性が強いです。おそらく自爆覚悟のスクラップビルドは当分必要になるでしょう。
　CoffeeScriptであれ、それ以外の新技術であれ、デメリットが強く出るだろうと想定される領域にまで踏み込んで事例を蓄積していくことはどうしても必要になりますし、またOSSであれ業務であれそういった活動を支援していくことが最終的には自分の腹痛を和らげることにもなるはずです。
　フリーランチはないですが、おそらく腹痛は分散できます。なによりあなたが積極的にお腹を壊すことで、誰か腹痛がやわらげられるならばそれはきっとすばらしいことです