2011/12/30 | Written by
rust | under
Blog
そろそろ振り返りの時期かな〜と言うことで。
今年やったこと
TokyuRubyKaigi
TokyuRubyKaigiを2回ほど開催してました。詳しくはここなりを参照してください。毎回カオスな感じになるのですが、ある意味、意図してるところはあります。司会的に。ただ敷居が低いということで勉強会初参加の方が来られると、カオスさにいろいろ誤解されるかもしれませんが、まあそれはそれで開眼できていいのではとも思ってます。来年も夏ごろにまたやるので、懲りずにご参加ください。普通のTokyu.rbも目黒でやってるので、こちらも是非に。特に白金台という近場にいる人は来るべきだと、ここで宣言しておきます。
今年もjpmobileネタで発表してきました。スマートフォン全盛時代ですが、まだ残ってるガラケーに対応するためにもいろいろやっていきます。欲しい機能などあったら、github/issuesにでも登録しておいてください。
本を書いた・書いている
Gitによるバージョン管理
- 著者／訳者：岩松 信洋 上川 純一 まえだこうへい 小川 伸一郎
- 出版社：オーム社( 2011-10-25 )
- 単行本（ソフトカバー）：320 ページ
結構長い間かけて書いたGitの書籍が発売になりました。主にチーム開発とリモートリポジトリ、あとはツール関係のところとか書いてます。長ったらしい文章を書く技術が身についた気がしてます。気が。
あとはRubyの教科書的なものとかjpmobileの本とかも執筆中です。来年も、まあなんとかそっち方面でも頑張っていきたいなーとか思ってます。
今年買った物など
Kindle 4
やっぱいま話題の電子書籍の流れに乗らないと！というのと、ちゃんと英語読まないと忘れてしまうんで、その防止用ということで買ってみました。液晶に比べて目が疲れにくいのがいいですね。頑張って話せるようになりたいです。
MacBook Air 13.3inc
いまのユニボディ白MacBookを買って2年ちょい経ったんで、えいやっと買ってしまいました。古いのは妻のこたつ用PCになってます。いや軽いですね、そして冷たい。あとSSDの威力か、ほんとにSWAPしても重くならないのがいい感じです。
銀河英雄伝説 Blu-ray BOX
TSUTAYAで次巻が借りられていて、えいやっと買ってしまいました。まあ1年に2回ぐらい観るので、そのうち元は取れるでしょう。
三国志 Three kingdoms DVD-BOX
これも次巻が（ｒｙ。
今年の総括と来年への豊富など
今年は書籍の執筆という新しいことができた年でした。またTokyuRubyKaigiを公民館じゃなくIT企業の会議室を借りて開催できました。あとスポンサーがついたのも大きいですね。毎回同じようなことを同じようにするという、ある意味簡単そうでできないことを4回も続けられたのは、スタッフや参加者の協力があったからこそだと思います。いろいろとありがとうございました。
来年もまた新しいことをやってみたいですね。結構な歳だったりするんですが、それにも負けずに何かやりたいですね。まだ具体的には決まっていませんが。ただTokyu.rbについてはいつものようにいつもどおりにやっていきたいと思ってます。来年もよろしくお願いします。
Tags:
jpmobile,
RegionalRubyKaigi,
Ruby,
書籍
2011/01/05 | Written by
rust | under
Blog
年末年始はまったくと言っていいほど、ネットからは離れていたので、いまさらながらにこの話題を。
DebianのRubyパッケージメンテナ辞任で騒動に
まあこういうのはある意味仕方ないことかなと思ってます。だいたいそれぞれのdistributionにはパッケージに関する思惑があるわけで、それと言語自体の考えや開発スピードがうまくマッチすればいいんですが、そうならない場合にはいろいろ問題が起るわけで。あとRubyGemsはパッケージ化してもらわない方がいいと思うんですが、どうなんですかね。頻繁にアップデートできるならともかく、そうではない場合にはaptやyumでインストールしても古いとなると、使わなくなりません？
まあRubyGemsに関しては、インストールディレクトリをlibではなくshareにするとか、いろいろできそうなところはあると思うので、頑張ってもらいたいところです。
Ruby community
日本語と英語と言う言語と文化の差があるのでどうしようもない部分もある。日本人としては、「いままで日本人は歩み寄って行ってたんだから、Rubyのときぐらい、こっちへ来いよ」と思わないでもないんだけどね。一人を除いて、ちょっとでも日本語を読めるようになろうとしている英語圏の人がいないのが寂しいところ。まあそうは言っても日本語は奇怪な言語なので、それを覚えろと言う気にはなれませんが。
で、どうするかというのは、やっぱりmanagerを設置すべきかなぁと思いました。要するにfull timeな@yuguiさんを作り出せばいいんですが、そう簡単ではない。その人がちゃんとmanagementしてくれれば、「ruby-devとruby-core合体させようぜ」とならなくても大丈夫になるのかなと。それが無理なら、いままでやってきたこのスタイルを継続していくしかないんじゃないでしょうかね。
1.8.8
メンテナンスしている方々には申し訳ないのですが、出て欲しくありません。むしろ1.8.8にリソース割くなら、1.9.2に力を入れてくれと思ってます。開発側の思惑がどうなのか知りませんが、「1.8.8のリリース」は「まだ1.9.2へ移行しなくてもいいよ〜」と言う意思表示にしかならないと思うんですよね、やっぱ。1.8.8には1.9.2からのバックポートがあるらしいのですが、いかんせんEncodeが入らないのであれば、実際問題意味がないと思うわけです、jpmobile的には。
「是非1.9.2を使って欲しい！」のであれば、1.8.xはsecurity fixのみにしてしまって、あとは1.9.2 or laterに全力Tokyu投球してもらいたいところです。
Tags:
Debian,
Ruby,
コミュニティ
2010/11/22 | Written by
rust | under
Blog
と言うわけで、去る2010/11/20(土)にRailsDevCon2010を開催してきました。今回は実行委員と言いつつ、当日まであまり何もできなかったので、会場係として、明い緑のパーカーと言う季節もへったくれもない格好でいろいろ動きまわってました。
実は企画自体はRubyKaigi2009の直後ぐらいから @ysakaki さんといろいろ妄想を語ってたのですが、当時のスタッフの都合などもあり、なかなか開催に踏み切れませんでした。そんなとき、RubyWorldConference 2010での @a_matsuda さんの講演を聞いて、「これはやらんといかんな！」と思い立ち、急遽開催することになりました。少ない準備期間でこれだけの資料を準備していただいたスピーカーの方々、また当日の設営と撤収作業を手伝っていただいた当日スタッフの方々、そして事前の準備に奔走したスタッフの面々、そして隣で仕事と共に頑張ってくれた副実行委員長、本当にありがとうございました！このRailsDevConは定期的に開催できればいいなーと思ってるので、その時はまたみなさんご参加ください。
そして次は TokyuRubyKaigi 03 の司会へと続きます。
Tags:
Rails,
Ruby
2010/11/08 | Written by
rust | under
Blog
と言うわけで、先週の11/01に楽天で開催されたNOSQL AFTERNOON JAPANに行ってきました。全体的に、もうRDBMSじゃなくてKVSなんだなぁと感じさせるような賑いでした。以下、当日のログを。
Hibari/NOSQL for BIGDATA @ Gemini Mobile Tech.
- Function programing world conference will hold at Japan
- About Gemini
- Products
- MMSC for Japanese mobile carriers
- 2010/07 Hibari open source
- @geminimobile
- @hibaridb
Hibari
- for GB mailbox webmail
- chain-replication
- good performance for read big data
- Linux distribusion supported
- Erlang/OTP R13B03
- supports Amazon S3, JSON, native Erlang client API
- “read-optimized”
- Admin server
- Why NoSQL?
- necessary to support TB data
- needs
- Durability, Strong Consistensy, Low Latency, High Avalilabirity
- Heavy READ
- Big DATA
- Features
- fsync()
- Chain Replication
- Chain order : Head -> Middle -> Tail
- Keys serves to Multi-servers
- Automatic rehashing (Fault Tolerance)
- Benchmarking
- Hibari Stub
- Hibari and Cassandra
- Hibari : 150k ~ 70ms
- Cassandra : 100k ~ 70ms
- Langurage Barrier
- Roadmap
Q&A
- Admin server’s availability
- CAP 定理でどれが重要か
- Erlang にパッチを当てないといけないのか？
- Chain Replication はどの単位？
- Key, Value の最大値は？
- 特にないが、各値がサーバのメモリで処理できるかどうか
Summary
- 読み込みに特化した KVS
- 特に巨大なデータの読み込みに特化している
- 携帯ウェブメールとかSNSとか
- オンメモリで動作している模様
CAP 定理について
- どれに特化するかはもちろん場合によりけりなので、一概に言い答えを出すことはできない
Okuyama @ Kobe Digital Labo
- Name from Okuyama Drive-way
- made by Java
- for small data
- Persisitence, Network, Replication
- Master nodes -> Data Notes (x3)
- Persistence
- Memory, Disk, Disk+Memory
- Network
- Original Protocol, Memcached(not CAS), HTTP(get only)
- Redundancy / Avalilability
- Data stored by Multi servers
- Persisntent Mechanism
- Memory -> Fastest mode
- Disk -> Key and Value have saved in separeted files
- Diska and Memory
- Type 1 : Save to file
- Type 2 : Save to file, and keys stored in memory
- Network
- Original Features
- Tagged value
- JavaScript run in Data Nodes
- Data locking
Q&A
- タグで指定する場合のスピードの差は？
- Disk mode の用途は？
- Master / Data Notes のスケーラビリティは
- Data note を増やせば上昇する
- Master node は stand-by のみでスケーラビリティはまだない
Summary
- 小さなデータを扱うことに特化している
- タグが特徴的で、それで性能劣化が低い状況下であれば良さそう
- 問題は scalability と availability で、その部分がまだ不十分というか、未検証かなという感じ
Introduction to Apache Cassandra
- by @zznate
- Casanndra -> Inbox Search -> Amazon Dynamo’s clustering infrastructure and BigTable’ data model
Cassandra
- Scaling
- Scaling up by adding data hosts, and separete keys into added and exist hosts
- Reliablitiy
- データはいくつかのホストに分散保存しているので、障害体制がある
- またホストが落ちたときも、すぐに再生できることができる
- Tunable Consistency
- Flexible Data Mode
- Not a Key/Value store
- Column famiries like BigTable or Dynamo
- Super columns
- column grouping
- apple -> colA, colFoo, fram in key “a”
- Supports secondary index in Version 7
- Analytics
- Monitoring
- Community: Clinet Library
- Pythin/Java/Ruby/.NET/PHP(new!)
- Add-ons
- Lucandra: Lucenne + Cassandra for full text search
- Munin configuration
- Chef recipes
- Riptano
- Supports and Training
- Clustering Visualizing Tools
- Administration Tools
Q&A
- Compaction Problem : More memory and CPU usage
- Need to configure and tuning parameters, so resolve such problem
- ???
- Range ???(25件取得するために10000件なめる必要があるときがある)
- 状況にによりけりだが、Secondary index で解決できるのではないだろうか
- Avro or Slate for searlization format
- ノードの障害時に、隣接するノードに対する負荷が上昇して、さらに障害が発生する、と言う連鎖に対する解決方法は？
- 適切な設計をすればいいのではないだろうか
- 適切な性能計画、サーバの選定などを行う必要がある
- Amazon EC2 2台で10万リクエストとか厳しいでしょ？
- I/O QPS に対応するかどうか
- Slate Priority in Version 0.7
Summary
- Hadoop 使うには良さそう
- 何が特徴かがこのプレゼンでは不明だったので、あとで調べる
- 書き込み性能重視にしている
ROMA – User-Customizable NoSQL Database in Ruby
- ROMA is development in Rakuten
- ROMA used by Rakuten services
- session data, personal page view history
- ex)
- ROMA features
- High Availability / Scalability
- Fault-tolerance
- Better throughput
- Plugin Architecture
- DSL
- Technology
- Consistency Hashing, Virtual Node, Chain-replication, lamport clock
- Access to data
- client -> some nodes
- returns node ID which stores such data
- Chain-Replication to N nodes
- Message Protocol
- Extended Memcached Protocol
- Failure Detection
- plugin features
Q&A
- Ruby の GC は気にならないか？
- ボトルネックは I/O なので、そこは気にならない
- 基本的な script は公開されていたりするのか？基本的な script をライブラリとして提供してはどうか？という提案
- Licence
- Why Ruby ?
Tokyo Tech の Nakamura さん
- 飛び入り
- Cassandra = Dynamo + Bigtable
- Cassandra の SSTable を MySQL のストレージエンジンに変えてみた
- JDBC 経由で MySQL にアクセスするだけ
- Future Work
- MySQL と Cassandra のいいところ取りした NoSQL プラットフォームのようなものを作りたい
MongoDB
- @mongodb
- 90000 downloads per month
- production usages
- Implemented by C++
- 32/64bit Windows, Linux, MacOS X, FreeBSD, Solaris
- Ruby/Rails/Java/C#/JavaScript/C/C++/Erlang/Pythin/Perl/etc.
- NoSQL
- non-relational, next-generation operational datastores and databases
- no joins + no complex transcations
- Horizontally Scalable Architectures
- Terminology
- Table -> Collection
- Row -> JSON Document
- Index -> Index
- Join -> Embedding & Linking
- Partition -> Shared
- Partition key -> Shared key
- API
- db.posts.save(JSON Document)
- db.posts.find #=> JSON Document
- Index
- db.posts.ensureIndex({autho: 1}) # 1 -> ASC, -1 -> DESC
- db.posts.find({author: ‘roger’}) #=> JSON document
- Query operators
- conditional operators : $exists, $size, $type, $lt, $gt, …
- Regexp search
- db.posts.find({author: /^k/})
- Extending the Schema
- update = {‘$push’ : {comments: comments JSON Document}}
- db.posts.update(JSON document, update)
- posts.comments -> Array of comment JSON Document
- Secondary Index
- db.posts.ensureIndex({“comments.author” : 1})
- Generate sub-model’s index
- Deploying MongoDB
- 1st step
- 2nd step
- Primary -> Secondary replication
- Read <- Secondary
- 3rd step
- Secondary -> Secondary for Backup
- Read/Write Scalability
- ReplicaSet
- Primary / Secondary / Secondary for Backup
- Key Shading on some ReplicaSet
- Monitoring
- MongoDB makes building applications easy
- Map/Reduce, Capped Collections, Tail-able Cursors, Geo indexing
Q&A
- どのようにRepicaSetを見つけるのか？
- 各Shadeがキーに対応するshadeを知っている？
- Shadingを追加したときの負荷は？ベンチマークは？
- 日本での展開は？
- サポート体制を立ち上げる
- MongoDB Conference を2月に行うかも？
- Availability について
- データセンター障害の用無い場合でも Primary が落ちても自動的にどれが Primary に適切かを判断して切り替わる
Summary
- 後発だけあってかなり負荷とかデータモデルを頑張ってる感じ
- ReplicaSet の追加で shading が勝手に行われるというのはいい感じ
- データモデルを設計しなくてもいいので、スタートアップ的に作るのに向いている
- Ruby/Rails との相性がいい
Kumofs and The MessagePack Project
kumofs
- Distributed key-value store
- Dymanic Re-balancing
- Not automatically, but dynamic
- Needs
- Manage heavy random reads and writes
- Low latency
- Archtectures
- kumo-manager : node manager
- kumo-gateway : installed in application server
- kumo-server : data-store
- Local Database : TokyoCabine
MessagePack / MessagePack-RPC
- MessagePack
- binary-based object serialization format
- MessagePack-RPC
- Cross-langurate RPC format
- Event-driven I/O
- Production users
- Ameba now
- Apache SoIr + MessagePack
- Sedue
Q&A
- TokyoCabinet のように一つのキーに複数の値を保存するなどは？
- どういうきっかけでこういうプロジェクトを始めたのか
Summary
- kumo-gateway がサーバ群の構造を隠して分散してくれるのはありがたい
- バックエンドに TokyoCabinet を使っている
RELAXING WITH COUTHDB
- for beginner
- schema-free database management sysytem
- Erlang
- Top-level Apache project
- Robust, concurrent, fault-tolerant
- RESTful JSON API
- Bi-directional replication
CouchDB
- JSON Document
- RESTful
- Suddenly server restarting does’t affect CouchDB
- VIEWS
- INCREMENTAL INDEXES
- REPLICATION
- peer-based, bi-directional replication using normal HTTP
- “ground computing” : offline replication
- MULTI-COUCH SETUPS
- Master-slave
- Master-Master
- Rubust Multi-Master
- CONFLICTS
- リビジョン管理により、コンフリクトが発生したときのデータをすべて保存しておける
BigCouch
- “Without the clustering, it’s just OuchDB”
- What is ‘Scaling’
- Horizontal Scaling
- Transparent to the application
- NO SPOF
- BigCouch -> Couch + Scaling
- Inspired from Dynamo
- on github
- Best Practice for BigCouch
- Fractral Scaling
- Paraphasing the crowd
- Many cons will be improved, improving
- External Indexers : CouchDB-Lucene
- Mobile Couch by CouchOne
- 2GB free account on cloudant
Q&A
- Differences between MongoDB and CouchDB
- CouchDB : MVCC
- MongoDB : Update
- How about Ad hoc query in CouchDB ?
Summary
- RESTful APIであるところが特徴
- “ground computing”が革新的かも
- BigCouch を使えばクラスタリングができるのかな
- Clustering はまだまだという感じ
- RESTful アクセス以外に弱いのかもしれない
Apache Hadoop and HBase @ cloudera
- Data is everywhere / Data is important
- Data analytics is important
- Are you throwing away data?
- Log/SQL log/etc. are throwed out?
Hadoop
- HDFS, Map/Reduce
- A Typical Look
- 5-4000 comodity servers
- 8-core, 24GB RAM, 4-12TB, gigabit-E)
- Cluster nodes
- Master nodes
- NameNode for metadata server and database
- JobTracker for scheduler
- Slave nodes
- Saving file -> Nama node splits a file -> Save each of splitted file data to 3 DataNodes
Map/Reduce
- map, reduce function
- map
- reduce
- (k, v1) , (k, v2) -> (k, v1+v2)
Hive
- Add SQL support to Hadoop
HBase
- open source, distributed, map
- HBase = HDFS + random read/write
- MVCC of row/colun
- Consistency over Availability
- Great Hadoop integration
- Ordered range partitions
- Automatically shareds/scales
- Sparse column storage
Q&A
- HBase はリアルタイムウェブで使える？
- 使える。Facebook でもそのうちリリースされる
- Switch について
Summary
- Hadoop は大量のデータ処理に向いている
- Hive は Map/Reduce をSQLでやる試み
- HBase は BigTable のような NoSQL
Tags:
BigTable,
Cassandra,
Hadoop,
HBase,
Java,
kumofs,
MapReduce,
MessagePack,
MongoDB,
NoSQL,
ROMA,
Ruby
2010/09/04 | Written by
rust | under
Blog
はじめに注意
個人的にはいままで参加したRubyKaigiには非常に満足しています。またスタッフやスポンサーの方々には言葉では言い尽くせない感謝の気持ちで一杯です。その上で、今後のRubyKaigiやRuby界を考えたときに、これだけは言っておきたいことをつらつらと書いてみます。スルー力を持たない人は読まない方がいいかもしれません。
RubyKaigiの問題点
一番の問題は目的を見いだせないこと。いや「開催すること」が目的になってしまっていることか。なんせRubyKaigiは大人が開催する有料「学園祭」になっているので、「やって楽しいこと、来て楽しいこと」を考えて構成されていると感じるとれる。「おもてなしの心」なんて言っている時点で、そっちがメインになってしまうのだろう。でもそれって参加者も含めて自己満足でしかなくて、それ以外の人たちになんら影響を与えられていない可能性がある。
そこで今一度考え直さないといけないと思うのが、開催する目的。開催趣意書には目的が書いてある。しかし、それ以前に、一体なんのために開催するのか。Rubyist の交流にためと言うのもあるかもしれないが、@tdtdsさんも言うように、もうそのステージは卒業しているはずだし、それならそもそも東京でやる意味が大きいとは思えない。交流のためなら地方に大物Rubyis を連れて行った方がいい。Rubyistにとって心地いい場所の提供ばかりしていても、もう仕方ない時を迎えたんだと思う。むしろ日々Pで始まりPで終わる言語やお茶みたいな言語を扱って疲れていたりするRubyistの癒しの場になっている。つまり逃げ場になって現実逃避しているだけじゃないだろうか。
スタッフのやり遂げた感がやばいと感じること
これはスタッフにも言えて、「来年もスタッフとして頑張ろう」なんて思ってるとしたら、それも逃避に近い。みんながみんなそうだとは言わないが、高橋会長やかくたにさん、島田さんや設楽さんなんかは、スタッフとして走り回ってる場合じゃないんだよ。あなた達にはもっとやるべきことがあるはずだ。Rubyの将来やRubyistのことを考えるなら、学園祭で盛り上がって参加者におもてなしなんてしててはいけないはずだ。その辺にいるRubyist達が勝手に盛り上がって開催しているならそれでもいいのだが、日本Rubyの会として開催していることがもうダメなんだと感じる。
組織としての日本Rubyの会
日本Rubyの会はその公式サイトにあるように支援やイベント開催をその目的にしていると言うことだが、こちらもそろそろ次の段階へ行くべきなんじゃないだろうか。振興という意味ではエンジニアの中では浸透してきたのだから、それを仕事へつなげやすい環境を作るべきだろうと思う。そういう意味では、いまの組織体制だときついのだろう。だいたい全員が別に仕事を持っていてボランティアベースと言うところからして限界があるのは当然のこと。ならば組織として法人化するなりしてはどうかと思う。たぶん内部的にはこの話は出てるんだろうが、じゃあ誰がそこに所属する？となったときに答えが出ないのだろう。そりゃみんな自分の会社や生活があるわけで、そこはどうしようもない。かといって誰だかわからない人に任せるわけにもいかないので、辛いところ何だろうなと思う。でもやはり何かしら痛みを伴ってでもやってしまうべきだと思う。
エンジニアを幸せにする会議へ
で、そうやって日本Rubyの会を法人化したとして、どういうRuby会議をやるべきか。それはRubyistを幸せにする会議。「いやー、楽しかったねー」と言うだけでは、仕事上がりの宴会と変わらない。そりゃその場の楽しさはあった方がいいだろけど、じゃあそれで仕事でもRubyを使えるようになり、アジャイルに仕事が進められるとは限らない。何というか、「瞬発力のあるその場の楽しさを胸に抱きながら、仕事の辛さに耐える」ような人が少なくなればいいかなと思う。
そのために自分ができること
では自分には何ができるのか。まずはRubyを使って仕事をし、さらにRailsやjpmobileなどで貢献していくこと。そうすることでRubyを使える場所や仕事が増えるようになればなと思う。あとは可能であれば日本Rubyの会の運営に関わること。外から意見を言うだけでもいいし、中の人になるのでもいいけど、とにかく何かにつけて意見を言っておきたい。と言うかみんなも「RubyKaigi楽しかったです！」じゃなくて、言いたいことはちゃんと言うべきだと思う。あとは地域Ruby会議へもっと参加していこうと思う。いろんな地域のいろんな意見を聞くことは、今後の自分のためにもなるし、Ruby界隈のためにも繋がる。
まとめにならないまとめ
つらつら書いたので全然まとまってないですが、いまの状況に対して漠然とした危機感というのを感じています。こういう話をいろんな人としたいですね。そういう場所として地域Ruby会議の懇親会とかいいんじゃないだろうかとか思います。とりあえず、まだまだ頑張ろうと思います。
Tags:
Ruby,
RubyKaigi
2010/08/28 | Written by
rust | under
Blog
と言うわけで準基調講演とかいろんな冷やかしを受けながらもなんとか発表終わりました。いやー、緊張しましたがなんとか発表できて良かったです。あとは今日のjpmobie Kaigi 2010が終われば、ようやく楽しめるようになるんじゃないかと思っています。
ところで、コミュニティ・ナイトのあとに懇親会行ったのですが、外国からの参加者が7割以上を占めるという、ある意味過酷な環境でした。英語慣れしてないのでかなり疲れましたが、それはそれで楽しかったです。さて、今日の懇親会はどうなることやら。
Tags:
jpmobile,
Ruby,
RubyKaigi
世田谷区在住のエンジニア。主に Ruby on Rails でのサービス開発とインフラ設計とか負荷分散とか、いろいろやってます。
