Road To Nowhere

主にWebまわりのエンジニア的なお仕事に関するようなことのあれこれ。

Twitterの開発者向けイベント「Tokyo Developer Teatime」に参加してきた。

イベント
タイムスケジュール

19:00 オープニングスピーチ 協賛 SCSK株式会社様
19:10 「State of the platform」基調講演
19:30 「iOS 5 インテグレーションについて」
19:50 「10分で理解するトゥギャッター」 トゥギャッター様
20:05〜20:15 休憩
20:15 「土管としてのTwitter」 giftee様
20:30 「デベロッパーコミュニティについて」
20:40 Q&A
21:10〜22:00 懇親会

公式ページ

https://dev.twitter.com/form/tokyo-dev-teatime

Tokyo Developer Teatime のプログラム

http://blog.jp.twitter.com/2011/11/tokyo-developer-teatime-teatimetky.html

公式ハッシュタグ #teatimeTKY のtogetter

http://togetter.com/li/215442

Tokyo Developer Teatime の公式レポート

http://blog.jp.twitter.com/2011/11/tokyo-developer-teatime-teatimetky_21.html


場所はSCSKさんの青山オフィス。
恥ずかしながらSCSKさんのことを存じ上げなかったんですが、
社員も何千人もいて東証1部に上場もしている大きな会社さんなんですね。
とても立派なビルで圧倒されました。


会場も広くてこのにぎわい。
前にたっているのはサンフランシスコからきたtwitterのエンジニア達。


以下、各スピーチのメモです。

オープニングスピーチ

スピーカー、SCSK武田元氏

  • twitterの投稿は今年9月、一日平均2億3千万。
  • そのうち日本人のツイートがおよそ20%らしい。
  • twitterについて
    • 何かの商品やサービスに対してクレームはコールセンターへ連絡することが多く、企業側も認識できる。
    • 一方、よい体験をした場合は連絡せずにtwitterで共有することが多いようだ。
    • twitterにはバランスのよい喜怒哀楽がある
  • モルガン・スタンレーで自社のブローカーにtwitter使用を許可した。つまりtwitterは広報としてだけでなく本業でも使用されてきている。
  • twitter x エンタープライズの可能性
    • 喜怒哀楽の大量データ
    • コミュニケーションのツールとして


ふむふむ。twitter x エンタープライズ。
twitterはもはや個人が利用する単なるコミュニケーションツールではないってことでしょう。

State of the platform

スピーカー、ジェイソンコスタ氏（＠jasoncosta）

  • twitterエコシステムの規模感
    • 750000 developers
    • 15 bilion api requests
    • 1.1Mのアプリケーション


このセッションは英語でスピーチされ、ハッシュタグ#teatimeJPに翻訳が流されるというもの。
英語の聞き取りが不得手なので、#teatimeJPを見ながら理解しようとしたがイマイチ。。


ただしきりに言っていたのは、twitterはエコシステムに対して投資してきて、今とても成功している。
そしてさらに今は絶好のチャンスであり、多くの企業がエコシステムに投資しているということ。


このときはエコシステムって何のことを言っているのかよく理解できなかったんだけど、
エコシステム(えこしすてむ)とは - コトバンク
これをふまえると、twitterを中心として、デベロッパー、ベンダー、サードパーティー、ユーザーが有機的に結びつき、
共に成長していくシステムっていう理解でいいんだと思う。


Quoraは成功している代表的な例で、各ページにtwitter経由で30PV以上のアクセスがある。
Twitterは今検索エンジンの次にユーザーをサイトへ導く重要な導線となっていて、
Twitter for websiteという機能でフォローボタンやツイートボタンを提供している。
ツイートボタン設置でツイートが7倍以上になるよ、と。


http://twitter.com/#!/twj_dev
http://twitter.com/#!/search?q=%23teatimeJP
http://twitter.com/#!/search?q=%23teatimeTKY
このへんを追ってもらえればより詳しく分かると思う。

iOS5インテグレーション

スピーカー、ショーンクック氏（@theSeanCook）
こちらも前のセッションと同様に英語のスピーチにハッシュタグでの翻訳。

  • iOS5との相乗効果
    • twitter 200 million users with 1000000 apps
    • iOS5 たくさんのデバイス
  • ワンクリックでシングルサインオン
    • 「Twitterアカウントにアクセスしようとしています」というダイアログを一度だけクリックすればアプリとアカウントが統合
  • tweet sheet
    • 写真共有、ハッシュタグの埋め込み、リンクの埋め込み、文字数のカウントなどすべてOS側で面倒をみてくれる
  • core signing
    • （ごめん！）
  • photos
    • （ごめん！）


とにかく開発者にとっては実装が非常に簡単になり、ライブラリのダウンロード不要で、
しかもoauthの複雑な仕様を理解する必要がなくなるので、非常によいことだと。
近々パートナーアプリが続々ローンチされるらしい。

10分で理解するトゥギャッター

スピーカー、トゥギャッター吉田氏

  • togetterについて
    • 2009/9release
    • masasonが使用してブレイク
  • 裏側
    • 使用しているAPIは少ない
    • t.co問題
    • Tweet Entities
      • 個々のツイートのメタ情報
      • t.coの展開後のURL
      • pic.twitter.comの画像パス
    • bitlyなど、それでも展開できない場合もある
    • TOLS（独自の仕組み）
      • ツイート内のURLをアーカイブ
      • bitlyなどのを展開して独自に保存
      • 将来公開したいけど予定はなし。希望があれば。
  • 新サービスお披露目

土管としてのtwitter

スピーカー、giftee yanase氏（@i7a16k）

  • about giftee
    • twitetrでgiftをおくる。店舗で商品を受取る。
    • 3月ローンチ。60店舗ほど。商品100種類。無印とも提携。
  • giftee demo
  • gifteeにとってのtwitter
    • ギフトカードを届けるための土管
    • ただの土管じゃなくて透明な土管
      • 送る人のフォロワーに伝えることができる。
    • バッドポイント
      • mensionなので忘れられる可能性がある。
      • 分かりやすいツイート。再送・リマインドが必要。
      • クジラが土管を防ぐ可能性。
        • 運用で逃げる。


透明な土管ではあるけど、商品が魅力的に見えるかという点では、facebookの方が上。
facebookはソーシャルグラフを使用して、いいね！した人が分かるが、twitterではツイート数しか分からない。
twitterにはぜひソーシャルグラフを活用して、フォローしている人がその商品についてなんと言っているか分かるようにしてほしい。


とのこと。後半に部分はまさにおっしゃる通り。納得でした。

デベロッパーコミュニティについて

スピーカー、Twitter Japan 山本裕介氏（@yusukey）


日本は大きなマーケットで日本語ハッシュタグやユニークなクライアントもあり、独特の文化を持っている。
問題はAPIのドキュメントが英語で公式コミュニティも英語のみだったが、日本での展開を進めている。
またTwitter APIを使ったハッカソンなどデベロッパーコミュニティのイベントを企画しているとのことでした。


正式な日本デベロッパー向け公式アカウント
@twj_dev


公式日本語メーリングリスト
http://bit.ly/tdt-ja


twitterのオープンソースソフトウェア
@TwitterOSS

QA

  • アンドロイドのインテグレーションはいつ？
    • yes, 早ければ来年早々。
  • 採用について。日本とSFでの採用状況は？
    • 今年夏から日本で積極的に。進行中。
    • バックエンドは似言語処理、検索。
    • フロントエンドは多様なモバイル
    • 日本からSFへのリロケーションもアリ。
    • 日本を拠点とするエンジニアもアリ。
  • 日本語URLの開発しているのでURLの国際ドメイン対応は？
    • ドメインの国際化が遅れている。日本語パスも対応できていない。
    • 日本語URLに区別、判断、ロジックが難しい。
  • 日本でローンチパートナーになる基準は？
    • 地元SFのエンジニアと交流している
    • 日本でもいっしょにプロモートしたい
  • userstreamで抜けがよくあるが対応は？
    • 問題は認識している。対応中。なおします。
    • 日本語でもトラブル対応、サポート可能。MLへどぞ。
  • APIコールの制限によくかかる。有料化ある？
    • 課金の計画はない。
    • 範囲内で使うように設計してほしい。
    • 和やかだった雰囲気にちょっと緊張感が・・・
    • firehorse（全世界のパブリックなツイートを全部取得可能）は限られたサイトのみのAPI
    • site ( or user ) streamingAPIを使うとよい
  • アクティビティのAPIを公式に公開する予定は？
    • yes。時期わからず。it's coming。

Oracle MySQL Developer Day – Tokyoに参加してきた。

MySQL

アジェンダ

10:00〜12:00 MySQLエッセンシャル＜技術概要＞
12:00〜13:00 昼食タイム
13:00〜13:45 MySQLレプリケーション&スケーラビリティ
13:45〜14:30 MySQL Cluster
14:30〜14:45 休憩
14:45〜15:30 MySQLパフォーマンス&チューニング概要
15:30〜16:15 MySQL管理&運用
16:15〜16:30 閉会

場所は青山のオラクル本社。
初めて行きましたがとても立派な建物でオシャレ！
社員さんがうらやましい。

以下走り書きの自分用メモ。気が向いたら補足します。
全体的にMySQLの初歩的な部分が多かったのでかなりはしょってあります。
正直言って日常の業務でMySQLを触っている人には物足りない内容だったかもしれません。

MySQLエッセンシャル＜技術概要＞ スピーカー梶山氏

  • mysql 5.6
    • optimizer
      • (small)limit使用時のファイルソート高速化
      • index condition pushdown ICP
      • batch key access BKA
        • join時、サブクエリ時のパフォーマンス改善
        • join bufferを増やせば増やすほど高速に
        • diskゴリゴリ使用時に劇的に改善
      • explainの改善
      • 更新系のクエリでもexplain可
      • optimizer trace
        • selectの内部処理をtraceできる
      • innodbのoptimizer staticsを永続化（？）
    • こちらが詳しい http://nippondanji.blogspot.com/2011/04/mysql-56.html
    • preformance schema
    • replication
      • slaveのクラッシュセーフ
      • slaveのスレッドをマルチスレッド化（スキーマ単位）
      • time delayed replication
        • わざと時間差をつけて同期する。スナップショットのようなもの。
    • not only sql options
    • other
      • partitionごとのimport export強化
      • notonlysql mysql
    • under develop
      • full text search(under develop)
      • smaller page size(under develop)
      • binlog api
      • global transaction id
      • マルチコアスケーラビリティ
      • サブクエリ高速化
      • explain 結果の構造化。見やすく。
      • オンライン操作。インデックス関連。
      • ssd 最適化。

MySQLレプリケーション&スケーラビリティ スピーカー奥野氏

  • このセッションで期待すること
  • レプリケーションタイプ
    • 非同期
      • ずっと接続しておく必要がない
    • 準同期
      • 最低ひとつのスレーブが書き込んだことを確認
    • 同期
      • すべてのスレーブでデータが完全同期
  • フォーマット
    • 文ベース
      • データが少ない
    • 行ベース
      • データ量が多い
    • mixed
      • いいとこどり
  • レプリケーション短所
    • システムダウンでデータロストの可能性あり
    • ひとつ以上のスレーブでのフェイルオーバー、フェイルバックが煩雑。
    • リカバリされたマスタはバイナリログに欠損の可能性あり。
    • スレーブとマスターでタイムラグがある。
  • レプリケーション利用法
    • 高可用性
    • スケーラビリティ
    • セキュリティ、バックアップ
    • 分析
      • スレーブを集計用に利用するのによい。
    • 長距離感のデータ配布
      • ネットワークがつながっていればOK。
  • binlog(バイナリログ)について
    • マスターのすべての変更を記録している。
    • binlogインデックスファイル
      • どのバイナリログが存在するかの情報
    • ポイントタイムリカバリに使用可能。
    • show binlog events;
  • マスターのクローニング
    • 省略
  • 書き込みのスケールアウト
    • シャーディングまたは分割。

MySQLパフォーマンス&チューニング概要 スピーカー梶山氏

  • チューニングの基本
    • 設定の確認
      • show variables like 'auto%';
      • 大量のソート処理をｓるときは、 set で一時的に変更するのもあり。
      • show にもsession とgloabalがある
    • 何が起こっているのか確認
    • slow query logを有効にしておくこと！
  • チューニングのルール
    • いきなり本番でやらない
    • ちゃんとしたベンチマーク
    • 一回で一つのことをやって確認する。コンビネーションはあとから。
    • 結果をよく見る
      • cpu
      • io
      • クエリ
    • 結果を記録しておく
  • ストレージエンジン
    • innodb
      • myisamからするとデータファイルは2-3倍
      • 圧縮可能
    • myisam
      • 参照ははやい
      • データファイルがの信頼性がいまいち
      • コンパクト
  • innodbチューニング
    • innodb_buffer_pool_size
      • 一番重要
      • なるべく大きく確保してデータをメモリにのせる
      • データが全部メモリにのると劇的に早くなる
    • innodb_flush_method = O_DIRECT
      • 性能が変わる可能性がある。遅くなる可能性も。
  • myisamチューニング
    • key_buffer_size
      • インデックスのメモリのサイズ。データはのらない。
      • あまり大きくしてもしょうがない
  • connection
    • thread_cache_size
      • 一回ずつ接続するアプリケーションの場合
      • 作ったスレッドをキャッシュしておける。
      • つないで切ってを繰り返す作りだと有効かも。
      • mysqlはシングルスレッド・マルチプロセスなので神経質にならなくてもいい。
  • sessionごとのパラメータ
    • sort_buffer_sizeなど
      • なるべく初期値にしておいて、大きい処理を行うときだけ変更するのが吉。
  • query cache
    • ジキルとハイドのような！
      • クエリが一文字でも違えば別のキャッシュ。
      • 場合によっては使わない方がいいときもある。
  • インデックス
    • prefix index
      • カラムの先頭何文字という指定でインデックスを作れる
    • join対象の列それぞれにインデックスあると吉
    • indexのつけすぎはよくない
      • 更新負荷が高くなる
  • explain
    • optimizerの動きを見る
  • query
    • フルテーブルスキャンをしない
    • log_query_not_use_inde
      • インデックスを使っていないクエリをはきだし
    • 前方一致はインデックス使うけど、広報一致は使わない
  • schema
    • 最小のデータサイズ型
    • procedure analyse
  • performance schema
    • どちらかといえば内部の開発者にとってうれしい

MySQL管理&運用 スピーカー奥野氏

  • 基本コマンド
    • mysql
    • mysqladmin
      • サーバ構成
    • mysqlcheck
    • mysqldump
      • backup
    • mysqlimport
      • restore
    • mysqlshow
    • mysqlslap
      • 負荷をかける
    • mysqld
    • mysqld_safe
      • log のセットアップなど
    • mysql_server
    • mysqld_multi
  • 内部スキーマ
    • information_schema
      • anci sql
      • sqlで参照できる
      • 表、ビュー、ストアド、トリが、イベントなどを見る
  • パフォーマンススキーマ
    • mysql開発者がボトルネックなおをさぐれる
    • コードに埋め込まれているinstrumetntation pointを使ってデータ収集
  • mysql workbench
    • official gui アプリケーション
      • SQL開発
      • データ設計
      • 管理者
  • mysql workbench ユーティリティ
    • 各種
    • 積極的に開発されている
  • バックアップツール
    • ホットバックアップ（オンライン）
      • 有償
  • mysqldump
    • 長所
      • 小規模向け
      • DBが壊れてなければ確実
      • SQlでバックアップ
    • 短所
      • リストアが遅い
      • オンラインではない（テーブルロックを必要とする）
      • 増分バックアップができない（毎回フルバックアップ）
      • 一貫性がとれない
  • レプリケーション
    • 動作継続（マスタに負荷がかからない）
    • クイックリカバリ
    • ブロックしない
    • 他のバックアップオプションと連動
    • 短所
      • 非歴史的
      • アーカイブじゃない
      • 論理障害につかえない（まちがったクエリ発行に無力）
  • mysql enterprize backup
    • 物理バックアップなのではやい
    • フレキシブル
    • 圧縮可
    • 一貫性あり
    • いいことづくめ
    • 短所
      • プランニングが必要
  • モニタリング
    • enterprize monitor(商用)
      • 統合ビュー
      • 企業向けサポート
      • クエリ分析
      • エキスパートアドバイザ
        • 140以上のルール、50以上のグラフで監視可能
        • upgradeした方がいいとアドバイスくれたり
      • レプリケーションモニタ
        • 同期チェック
      • クエリアナライザ
        • 実行クエリの分析
        • ひとつひとつのクエリのドリルダウン。explainなど
      • 新ルールの追加も可能
  • パフォーマンスとストレステスト
    • sysbench,DBT2は単純な性能試験
    • 最終的には実アプリケーションでの試験が必要
  • QA
    • oracleとmysqlどっちがいいの？
      • スペックをおさえた状況ではmsyqlのが優秀
      • クエリにもよる。いちがいにいえない。
    • mysql 5.6、cluster 7.2はいつリリース？
      • 5.6の年内のGAリリースはない。
      • 7.2も開発中。約束できない。
    • 来年2月にリリース案件があるが7.2本番で使える？
      • 海外ではすでにリスクをとって動かしている例もあるが。

まとめ

最初にもちょっと触れたけど毎日MySQLを触っている人にとっては新しい情報が少なく物足りない内容だったかもしれない。
収穫らしい収穫はMySQL5.6のGA版が年内にはでないとはっきりわかったことだろうか。
ただMySQLの概要から運用テクニックまで改めて聞いてみると、本当に素晴らしいソフトウェアだと再認識。
無料で使わせてもらっていることにもうほんと感謝感謝！
最後に、こんな充実したセミナーを無料で、しかも弁当まで用意していただいて、オラクルさんありがとうございました。

スレーブのリレーログが増殖してサーバのディスクを圧迫した

MySQL

とある日、スレーブの1台からディスク容量がいっぱいになっているというアラートがきたので、そのときのトラブルシューティングやあれこれ。

環境と現象

  • MySQL: 5.5.8
  • MySQLのレプリケーション機能を使って、マスター1台 x 複数のスレーブ という構成で運用している。
  • とある日、スレーブの1台からディスク容量がいっぱいになっているというアラートがくる。（nagiosで監視）
  • show slave status で調べると、そのスレーブだけデータの同期（Slave_SQL_Running）が止まっていた。
  • 実際どのファイルがディスクを圧迫しているか調べると、リレーログ（ファイル名はhost-relay-bin.00XXXX）がやたら増えているのが判明した。

解決方法

  • エラーログ（host.err）やshow slave statusで同期が止まった原因を特定＆対応（またはskip slave なんて手もあるが・・）して、slave startを実行。つまり正常に同期を再開させた。
    • 実際に何をして同期を再開させたかは運用事情が複雑なので避けるが、更新クエリで参照しているテーブルがこのスレーブだけなかったので、他のサーバからdumpしてもってきたということにしておく。
  • 同期が進むと自動的に古いものからリレーログがなくなっていって、無事ディスクの容量圧迫問題は解決した。

なぜそれで解決したのか？

解決するのに時間はかからなかったが、リレーログの役割やレプリケーションの仕組みについて理解を深めるのに役立ったので、メモがてら書いてみる。

1. マスタで処理された更新系のクエリが逐次、マスタのバイナリログに記録される。
2. スレーブのI/OスレッドがマスタのBinlog Dumpスレッドに接続する。
3. マスタのBinlog Dumpスレッドは、バイナリログの内容をどんどん送信する。Binlog Dumpスレッドはこの処理を繰り返す。
4. スレーブのI/Oスレッドは、受け取ったマスタのバイナリログをスレーブ内に保存する。これをリレーログと呼ぶ。I/Oスレッドはこの処理を繰り返す。
5. スレーブのSQLスレッドは、リレーログからクエリを読み取って実行する。SQLスレッドはこの処理を繰り返す。

  • 手順1〜3は特に難しくなく、誰もが想像している通りの動きではないかと思う。
  • 手順4に注目。スレーブはマスタのバイナリログの情報を受け取ったらそのままスレーブのデータに反映（もしくはSQLを実行）するのではなく、一度リレーログに書き出すということ。これはなるほどと思う人が少なくないんじゃないか。
  • 今回のトラブルでは、データの同期（つまりSQLスレッド）が止まっていた間もI/Oスレッドは動いていて、マスタからバイナリログの情報を受け取ってリレーログに溜め込み続けていたということになる。
  • また上にも書いたが、データの同期が止まった問題を解決してSQLスレッドを再開（slave start）すると、リレーログからマスタの更新情報をスレーブのデータに反映して、反映が終り次第、ファイル単位でリレーログはなくなっていった。


バイナリログとリレーログ、SQLスレッドとI/Oスレッド。
このあたりのレプリケーションの基本のおさらいができて、有意義なトラブルシューティングだった。（ポジティブシンキングv(￣ｰ￣)v）

大きなサイズのデータをmyisamからinnodbに移行する検証をしたメモ

MySQL

ハマってなんとか解決したことや、現状困ったりしていることを書いてみる。

前置き

  • 対象のデータ（現在1テーブル）は、約1億レコード、50G。引き続き膨張していくことが予想される。
  • 今はmyisamで運用。更新処理が非常に高負荷。しかもロックが発生するため、オンライン中の更新ができない。1日1回新旧のテーブルを置き換えることで更新。
  • 目指すところは、参照のパフォーマンスを落とさずにリアルタイム更新。次の方向で検証中。
    • まずテーブルを参照時の条件に沿う形で分割。さらに更新する単位でパーティショニング。これにより参照＆更新のパフォーマンスアップを狙う。
    • myisamからinnodbにすることでロックなしでオンライン中の更新を実現にする。

検証環境

  • OS: CentOS 5.5
  • MySQL: 5.5.8
  • サーバの搭載メモリ: 32G

ibdata1、大きくなり過ぎ！

  • myisamと違ってinnodbのデータファイル（ibdata1）はデフォルトでは一つにまとまっていて、何もしないとこれが際限なく大きくなる。
  • db全体で100G程度のサイズ。でもデータの更新などを繰り返すうちに200G以上にサイズが膨れ上がった。つまりibdata1だけで100G以上に。
  • これを回避する方法は以下2つ
  • 際限のない膨張は回避できたが、既に膨れ上がったibdataのサイズを縮小するのはけっこう大変。
  • 最後もうひとつメモ。innodb_file_per_tableを設定した状態でテーブルのパーティショニングを行うと、パーティション単位でデータファイルができ、だいぶ扱いやすいサイズになった。

innodb_buffer_pool_sizeは欲張るな！

  • メモリの7割から8割のサイズを設定すると言われているが、とち狂って32Gに対して28G(約9割！)を設定してしまっていた。
  • 22G（7割程度）にしてかなりパフォーマンス改善。バランス大事。

更新処理時のデータのオーバーヘッドが大きい！

  • truncateしたあと、データの挿入を行うとデータファイルが500Mに。あれ？テーブルをoptimizeすると、300M程度のサイズまで減少。
    • innodbでは、「optimize」は「alter table t1 engine=innodb」と一緒！
  • 放っておくとdb全体の容量がどんどん大きくなるので、何らかの対応が必要。
  • 今回パーティショニングの単位でデータの入れ替えを行うことにしているので、さしあたり以下の流れ。
    • alter table t1 truncate partiton p1;
    • flush table t1;
    • insert into t1 〜
    • alter table t1 rebuild partiton p1
  • insertの後、テーブル全体でoptimizeするよりもパーティション単位にrebuildした方が効率がよさそう。

show table statusが遅い！

  • これがいまだに原因分からず、苦戦中。とても重い処理をやっているとは思えないshow table statusの実行に何秒もかかる場合がある。
  • show table statusに限らず、テーブルを参照するクエリなどを発行すると、プロセスの状態が「Opening tables」となっているのをよく見かける。
  • テーブル分割を行った結果、一つのスキーマに数百のテーブルができたが、これが原因かもしれない。
  • 引き続き検証必要。

というわけで

主に更新に関するあれこれを書いてみた。実際のところ更新に関しては、課題はある程度クリアできているのかなといった状況。
一方、参照の方のパフォーマンスについても少しづつ検証しているが、思ったようなパフォーマンスが出せず、けっこう前途多難な感じ。
innodbはけっこうじゃじゃ馬ですなぁ。
しかしまぁ良さを引き出してナンボなので、もっと突っ込んでやってみようと思う。楽しみつつ！


進展があればまた書いてみようと思います。

キュレーションについて

Webサービス

最近「キュレーション」という単語を何度か見かけて、ちょっと調べてみるとCGMサイトに携わっている身としては刺さってくる内容だったのでメモ。

キュレーションて何？

まずは佐々木俊尚氏のこの記事。
キュレーション・ジャーナリズムとは何か | 佐々木俊尚公式サイト

キュレーションという言葉に、的確な日本語訳はない。私はこう定義している。「キュレーションは情報を収集し、選別し、意味づけを与えて、それをみんなと共有すること」。

また、キュレーターというのは学芸員を指すとのこと。
ふむふむ。何となく分かったような、でもまだピンとこないような。

次の記事。
キュレーション　王者グーグルを追う人力の新興勢力

「2ちゃんねるまとめ」、「togetter」、「NAVERまとめ」とかなじみのサイトが出てきた。
佐々木俊尚氏の定義と合わせて考えるとだいぶキュレーションがイメージできるようになった。
最初は集合知を洗錬した役立ち情報を得るというイメージだったけど、どうもネタ系というかおもしろ系サイトばかりだな。


その他、参考記事。
キュレーションはメディアを救えるか？
キュレーション時代の幕開け
NAVERが「まとめ」をリニューアル――作成者のキュレーション活動を加速

代表的なWebサービス

「2ちゃんねるまとめ」や「togetter」のように結果キュレーションの役割を果たしているというのではなく、
キュレーションという概念を意識して実践している（であろう）サービスをいくつか挙げてみる。

NAVERまとめ

キュレーションについて調べるとかなりの確率で挙げられている代表的なサービス。
公式ブログでもキュレーションに最適化しているサイトだと言っている。
投稿ユーザーが自由にテーマを決められるのも面白いし、そのテーマにそってみんなで作り上げていくのも面白い。
役に立つというよりもついついだら見してしまう。ネタ系の印象が強い。

OneTopi

このサイトの特徴は一つのテーマに対し特定の一人（キュレーター）が情報をピックアップしているということ。
一人なので筋の通ったまとめができるんだろうけど、いいまとめ情報になるかはキュレーターのセンスによる。
というか、これだとブログやtwitterと変わらんのではないの？
専門家によるキュレーションというのはいいと思うんだけど、ネタがつきたのか（あるいはモチベーション？）更新が止まっているものも散見されるしちょっと残念。

タウンノート

こちら東京（とソウル）に絞ったローカル情報のクチコミサイトで、キュレーションしてるのがみんなのタウンガイドという機能。
NAVERまとめのように投稿ユーザーがテーマを決め、それに合ったスポットをまとめたもの。他のユーザーもスポットを追加できる。
まだユーザーが少ないサイトなので数は多くないが質はよい。
ノマドワーカーにオススメの電源や無線LANが借りられるお店
週末に子どもとお出かけするスポット（首都圏近郊）
このへんのまとめは個人的に参考にしている。


他にもあるかもしれないけど、今日はこのへんで。

雑感

キュレーションを志向するWebサービスに関して言うと、不特定多数でまとめるときにどう質を担保するか難しいなと。
最初は比較的善意のユーザーが多いかもしれないけど、荒らし的なユーザーも当然いるわけで。
テーマごとに管理人を設けるのも手だけど、そうなると管理人の手腕に質が大きく左右されることになる。
またOneTopiのように一人の専門家という風になってしまうと、それってブログやtwitterと変わらない気がするしな。
数人の共通認識を持ったメンバーでというのがいいのかもしれないけど、バランスが難しいところだ。


ちょっとキュレーションとは離れて、世間にはたくさんのクチコミもしくはレビューサイトがあって、
それらが成功しているかどうかの判断はたくさんレビューが集まっているかどうかだったりすると思う。
ところが最近そういうサイトを見ていて思うのは、例えば一つの商品に対してレビューがいくつも投稿されているんだけど、
どれもこれも自分の言いたいことを言っているだけで客観性のないものばかりだととても残念になる。


nanapiやcookpadのように投稿のハードルを上げて質を担保するやり方もあるが、雑多なレビューの中から何らかのテーマでそれらのレビューをピックアップするキュレーションというのも一つの方法なのかもしれないなんて思った。

最後に

キュレーションについて見る側の立場でまとめたり思ったことを書いてみたりしたけど、自分自身が実際に情報を収集して、選別して、意味付けして、共有することもすごく重要かなと。
ということで、キュレーションについてキュレーションしてみたというオチ＼(^o^)／

投資信託の銘柄を物色してみた

投資

冬の賞与ももらって若干へそくりもたまってきたけど、そんなに欲しいものもないし、
ちょっと投資でもしてみるかと投資信託の銘柄を物色してみた。
ちなみに株式投資は株価が気になって毎日そわそわしてしまうので、
基本的に放置できる投資信託をたまにちょろっと買ったりしています。
今日見ていて気になったのは2つ。

フィデリティ・ＵＳリート・ファンドＢ

投資信託 フィデリティ・ＵＳリートＢ／マネックス証券
グラフをパッと見るとなんか冴えない感じだなぁと思うけど、注目すべきは分配金実績。
毎月もれなく100円ずつ分配されているが、これは10000口持っている人に毎月100円分配されるということ。
12/22現在6163円で10000口購入できるので（正確には購入手数料が必要だけど）、6163円投資すると毎月100円ずつチャリン。
100円というとだいぶしょぼい感じがするけど、6万ちょっとの投資で毎月1000円、一年持っていると12000円。
あなどれない。
そもそも基準価格が下がる可能性もあるわけだけど、ここ2年ほど安定してるしなぁと。
ただリスクメジャー5と最高値なのはすげー気になる・・・見なかったことにしておくかな。。。
ちなみにこちらは現在基準価格5860円で毎月分配100円だからよりおトクな気はする。
ただチャートを見ると基準価格がずっと下がり続けてて、今は買うのはちょっと無理！！ってな感じ。
なんでこっちはリスクメジャー3なんだろう？？？
というわけでリスクメジャーは信じないことにする。

PCAインドネシア株式オープン

投資信託 イーストＳインドネシア株式ＯＰ／マネックス証券
今日見つけて興奮したのはこれ。
注目は基準価額デイリーチャート。
徐々に上がっていって暴落（5月と11月）というパターンが分かる。
実はこれにはちゃんと訳があって、これも分配金実績を見ると明らかで、5月に2500円、11月に1500円と大きな分配。
分配金狙いで5月と11月に向けてみんなが購入して徐々に基準価格が上がっていって、
分配金をもらったらすぐ手放してしまうので基準価格が暴落するというのが見てとれる。
つまり・・・今買って5月の頭に上がったてきたところで売ればいいんじゃない？
どうも5月は11月よりも分配金は多いようだし、1割か2割くらいは基準価格上がるんじゃない？
一つ心配があるとすれば、5月の分配前に売るのを忘れてしまうことかな。
まぁそれでも分配金はもらえるし、長期的に見たらその方がよかったなんてことになる可能性もあるし。


テンションあがってブログまで書いてしまったけど、お酒も飲んでるし、今買うのは危険過ぎる。
もう2,3日置いてからもう一回このエントリーを見て、それでも納得したら買ってみようかな。


最後に。
言うまでもないけど、投資は自己責任で！

Scala勉強会に行ってきた

イベント

「WebプログラマのためのScala入門勉強会＠渋谷」始めます - hito_asaの日記
http://atnd.org/events/9054
「Webプログラマのための」「Hello, World!からはじめるよ」という甘い言葉に誘われて、11/2（火）全く馴染みのないScalaの勉強会に参加してきました。
ブログに書くのがちょっと遅くなってしまいましたが、備忘録として軽くまとめておきます。

事前にやったこと

当日

さて勉強会ですが、渋谷セルリアンタワーのGMOメディアさんの会議室で。さすがシャレオツなオフィスでした。参加者には飲み物（ペットボトル）も無料で配られるなどありがたい限り。（しかも飲み物が余ったのでお土産にもう一本！）GMOメディアのスタッフのみなさん、ありがとうございました。

資料はこちら
https://docs.google.com/fileview?id=0B3gzkyf0Dd_5MWRkZTA0NmUtMDgwMS00MzFlLWI3OGMtMGRkMmJlMjA1MGVl&hl=ja
講師の浅井さんはこちら
http://twitter.com/#!/hito_asa

メモ

感想

Scalaというプログラミング言語自体は非常に興味深くてもっと掘り下げていきたいんだけど、実際の業務のなかで（いや業務じゃなくてもいいんだけど）どういう場面でどういう風にこのScalaを使うといいのか知りたかったなと。
GMOメディアさんでは実際の業務で使用されているとのことなので、そのへんのところをつっこんで聞けばよかったなぁ。まぁまたの機会に。
そうそう、Scala勉強会は隔週で開催されることになり、次回のテーマは「Scalaで何を作りたいのか。Scalaに何を期待するのか。」
残念ながら次回は参加できないけど、面白そうなテーマなのでUstで見守りたいと思います。
http://atnd.org/events/9664

Scalaスケーラブルプログラミング[コンセプト&コーディング] (Programming in Scala)

Scalaスケーラブルプログラミング[コンセプト&コーディング] (Programming in Scala)