RWikiと怠惰な私の十年間The last decade of RWiki and lazy me.seki@druby.org

Castoro

おもしろかった！

今日の話

私について

RWikiのこと

某サイトのRWikiのこと

私について

toRuby　

サラリーマンと自称アーティスト

toRuby

toRuby = とちぎRuby ≠ 鳥取Ruby

西那須野公民館を中心に活動

とちぎRubyの勉強会

とちぎRuby会議01,02

とちぎテストの会議（連番なし）

メモのご用意を

とちぎRubyの勉強会

毎月第一水曜日 18:30から

つまり次回は9/1です

Google間違ってるので注意

©2010 Google - 地図データ ©2010 ZENRIN -

栃木県那須塩原市 付近の 西那須野公民館

A. 那須塩原市役所 西那須野公民館栃木県那須塩原市太夫塚１丁目１９４!１ "

0287-36-1143 "

©2010 Google - 地図データ ©2010 ZENRIN -

◀正解はココ

サラリーマン

ちゃんとした会社員

製品のためのプログラミング

eXtreme Programmingだったもの

プロセス・品質系イベントで講演

会社員系イベントJaSST'04 - 忍者式テスト

XP祭り04 - XPと計画ゲーム

デブサミ05 - 複数バージョンを同時に扱う

JaSST'06 - テストレート

ソフトウェア品質シンポジウム06 - 自分たちのもの宣言

JaSST'07 - 規模

デブサミ'08 - TPSとのパネル

オブジェクト倶楽部夏イベント2010 - ロールプレイング ◀先月話した

会社員系の講演

いつもいいことばっかり言ってる

「理想の開発者」とかインチキくさい

重要

そういう話を日本語版に寄稿しました

CC-byなのでいつか公開するけど、まずは買って読んでね

宣伝しなくても売れそう

自称アーティスト

わかって欲しい人にウケるため、自分のためのプログラミング

オープンソースへの愛や正義には興味がない

Rubyと私

20世紀の終わり頃から

書籍、雑誌

講演

ERB, dRuby, Rinda, RWiki, Tofu

重要

2005年夏

まだ初刷買えます!

初刷5周年!!

dRubyによる

関 将俊 著

分散・Webプログラミング

RubyKaigi x 5

2006 dRuby, Again.　

2007 Answering dRuby and Rinda　

2008 erbを偲んで

2009 偉大なBigTableとぼくのおもちゃ

2010 RWikiと怠惰な私の10年間 ◀いまここ

遺産で登壇するのはそろそろ限界か。

9年ぶりのRWiki

2000 Perl/RubyConference

2001 YARPC 19101 ◀ RWiki

しばらくお待ちください

✓ 97プログラマ本✓ 初刷5周年✓ そろそろ遺産が尽きる✓ +03分✓ 次はRWikiのこと

RWikiのことちゃんとした記録がないのでほどほどの正確さで説明します

RWikiのこと

RWikiの現状と今日のテーマ

RWikiの起源と特徴

privateなRWikiとそこでおきた問題と対応について

RWikiの現状

OSSのプロジェクト　

publicなRWiki

privateのRWiki

OSSのプロジェクト　

cozmixngのsvn借りてる。感謝

最近はほとんど変更がない

1.9対応を途中までやったけど飽きた。どちらかと言えば1.9がRWikiに対応して欲しい

publicなRWiki

The RWiki　toRubyの業務連絡とkouさんの読書メモは活発

Rubyのドキュメント関連はRWikiから卒業してしまったぽい

privateなRWiki

某組織の非公開なRWikiサイト

35000ページと25000ページの二つ

わりと活発に更新されてる

RWikiの現状

死んだプロジェクトに見えてもしょうがない。

某サイトでは10年近く活発に更新されてる

RWiki使って!!というテーマではない。実装の自慢と運用の苦労の話

しばらくお待ちください

✓ 今日のテーマは某サイトの運用の話だと念をおす

✓ +06分✓ 次はRWikiの起源と特徴

RWikiのはじまり

[ruby-list:24661]

RWikiのはじまり[ruby-list:24661]

◀dRuby, ERbメソッド化, RDToolのサンプル◀dRubyでサーバとCGIに分離

◀10周年

RWikiのはじまり[ruby-list:24661]

◀軽い嘘もある

OSSっぽい

はじめにNaHiさんが手伝ってくれて一部がNaHiさん色にそまり、その後kouさんがkouさん風に直してくれた

基本的に私の好みを尊重してくれてるので協力してくださる方は不満だったんじゃないだろうか

しばらくお待ちください

✓ まもなくRWiki10周年✓ dRubyなどのサンプル✓ NaHiさんkouさんに感謝する✓ +08分✓ 次はRWikiの特徴

RWikiの特徴機能と実装の特徴

機能

コンテンツの記述にRDを使うWiki

RDoc以前に流行った書式

リンクはRD方式。WikiNameは使えない(ということはWikiじゃないのか？)

機能の数は追っていない

実装

dRubyの長生きなサーバとCGIで構成

CGIは単なるhttpのインターフェイス

全てのコンテンツを一つのプロセスの中にオブジェクトとして配置

RWiki

CGI

CGI

HTTP dRuby

長生きRWikiと短命CGI

実装

dRubyのアプリケーションの典型的なプロセス構成

ふつうのデスクトップのアプリケーションにWebのUIを載せてる感じ

起動時

RWiki

log

読み込み

RWikiCGI

log

view

RWikiCGI

log

書き込み

edit

拡張

プラグインの機構は用意されないがdRubyで外部から操作し放題

実装 view

htmlを生成するオブジェクトの話

本文の部分はコンパイルされたERBオブジェクト

共通の部分はERBメソッド化

リンク先の更新時刻等わざわざ動的に

実装 view

RD→ERBソース→コンパイル済ERB へ変換。最終的なERBオブジェクトを保持する。

RDtoolによるRDの解釈、ERBのコンパイルなど時間のかかる処理は事前に

html生成時はERB#resultだけ

In-Memory

全てのデータをRubyオブジェクトで表現してプロセス内に配置するだけ

要素が数万ならArrayやHashで充分

ものすごくふつう

In-Memory

ファイルを読むのは起動時だけ

再起動の際に必要な最低限の情報をログする。編集結果はplainな文字列

いわゆるデータベースをもたない。当然SQLとか関係ないし、O/Rマッピングとか要らない

NoSQL?

むしろRWiki自体がデータベースのように見える

ドキュメント指向データベース？

dRuby経由でページのCRUD

ページに対する演算

しばらくお待ちください✓ RWikiはふつうのdRubyプログ

ラミングの構成✓ なんでもプロセスの中に✓ 流行のbuzzwordを押さえてる✓ +14分✓ 次は本題の某サイト

某サイト

某サイトの紹介が今日のテーマ

ほぼ10年近い運用の中でおきた問題と対応について

某サイト

2001年頃から使っているある大きなチーム向けのRWiki

開発メモ、日記、BTS、チケットシステム、テスト計画、履歴の管理

ソースの変更履歴のブラウズ

利用者

開発者とスタッフ、マネージャなど、100人よりちょっと少ないくらい

規模

35000ページと25000ページの二つのRWikiが一台のマシンで稼働

全ての情報をプロセスにためてしまうので一つのプロセスは1.2Gくらい

意外と大丈夫。Ruby強い!!

メモリと速度

マシンに余裕があるのかメモリを喰らっても他のサービスに影響なかった

Xeon 4core x2、 32GB RAM

実行中のレスポンスも問題ない

問題になるのは再起動にかかる時間

カスタマイズ

小技

Pageオブジェクト

StoryCard拡張

TestSuite生成システム

小技

CIにあわせたスタイルシートの使用(gotokenさん作)

簡単なことだけど仕事してる感を増幅する魔法

Pageオブジェクト

RDのソース、htmlを生成するerbオブジェクト、正・逆リンクなど基本情報

RDの木構造を処理することで求まる属性を集めた任意のオブジェクト。Propertyと呼んだ機構

どの情報もdRubyから触れる!

StoryCard拡張

チケットシステム、計画ゲームを支援する拡張

チケット情報をPropertyを使って取得

dRubyを用いたチケット情報を処理するツールがたくさんある

StoryCard拡張

運用中にチケットの属性、書式もワークフローもどんどん変更できる(た)

紙やExcelに近い無法っぷりが長期間の運用には必須である

チケットシステムのインストールとチケット駆動には関係がない

TestSuite生成システム

StoryCardに記述されたテストケースを抽出し一覧する機能が基本

全て見せると多すぎてやる気なくす

テスト計画、成績、鮮度、脆さなどの属性を元に今日のおすすめプレイリストを生成するシステム

TestSuite生成システム

iTunesスマートプレイリストのパクリ

会社員系講演で何度も話したネタ

Pageオブジェクトのリンク情報とStoryCard拡張のPropertyを利用

その他のツール

CVSに対するsvn風の変更履歴のブラウズ、開発メモとの融合

チケットの遷移の統計情報

試験成績履歴の地図

しばらくお待ちください

✓ 某サイトのRWikiの概要✓ PageとProperty, StoryCard拡張✓ ツールの多くは外部に✓ +20分✓ 次は問題だよ

たくさんの問題

基本的に「遅いんですけど問題」

起動遅いんですけど問題

irbで操作すると遅いんですけど問題

全文検索遅いんですけど問題

たびたび起こる問題

起動が遅いんですけど問題

原因はさまざま

再起動は数ヶ月に一度なのでがまんできなくもない

起動シーケンス

起点となるページを読みながらリンクされているページを再帰的に読む

RDの木は再帰的に生成されRDの森になりオブジェクト数が膨大に。GCの処理で非常に遅くなる。(気がする)

起動シーケンス

再帰的に辿りつつ、リンク先をキューに積むことで、木を同時に一つだけ生成することに

以前から気になってたんだけど無視してたらznzさんに指摘された。しょうがないから直した。起動がすごく速くなった。と思う。あやふや。

起動シーケンス

自分で気づいていても、指摘されるまで行動しない。

ちゃんと検証しないで直してみたけどうまくいった。

キャッシュの導入

再起動のたびにRDを木構造に変換してるのでもったいない

RDから変換されたhtml片、メタデータをMarshal.dumpしておいて、再起動時にMarshal.loadだけで済まそう

キャッシュの導入

確かに速くなった!

初期の設計思想からちょっとずれてるような気がする。敗北感？

最低限のログにこだわらないことにした。たとえリッチでも、ログはログだ

自分に言い聞かせることで解決

レスポンスの悪化

ページ数の増加にともないプロセスが太る

あるときからレスポンスが悪くなる←これってGCじゃね？

レスポンスの悪化

GCで遅いと言えばオブジェクト数だろ

とするとRDの木構造？

案の定インスタンス変数がRDの木を参照してる部分があった

覚えないように変更

レスポンスの悪化

メモリ半減、快適。起動も速い

めずらしく自主的に直した

たまにやると気分がいい

irb遅いんですけど

irbから使うとよくメソッド名をtypoしてしまう→間違えると反応が非常に遅くなる問題

NoMethodErrorの際にinspectが呼ばれ最終的にRWikiの根となるオブジェクトのinspectが実行される。これが長い

irb遅いんですけど

[ruby-dev:41329] NoMethodErrorなどのmessage

ruby-devで相談するも「咳さん」のアクセントの話題になってしまい議論終了。なにかの魔法をかけられたよう。

irb遅いんですけど

全然関係ないんですが、私の住んでる地方では

 関さん  ̃___

 咳さん  _̃__

 積算    __̃_

で、ぜんぶアクセントが違うので、文字で書くとかなり違和感があるのですが(心の中で「咳さん」を「関さん」のアクセントで読んでる)、好奇心にかられるのは、これは他の皆さんもそういう風に感じているものなんでしょうか。

irb遅いんですけど

http://www.hcn.zaq.ne.jp/myattun/tochi/hatsuon.html発音の特徴　次に、栃木弁の発音について下にちょっと詳しく説明しておきましょう。

(1)　アクセントによる単語の区別がありません。(中略)栃木の場合、アクセントによる単語の区別がなく、なおかつ固定した位置にアクセントが置かれるわけでもないので、無アクセントの方言と呼ばれます。

ということで、栃木県民としては無問題です。

irb遅いんですけど

栃木県民的にアクセントは解決したが肝心のNoMethodErrorが解決せず

今回はRWikiサーバでのObject#inspectを再定義して回避したので追求しない

matzの魔法に注意

全文検索

なんの工夫もなく35000のStringをscanしていた

最近なんとなく遅い

ユーザにはバレてないが直して遊びたい

全文検索

この話はパス

たまにポジティブに修正する

問題の傾向

全てのオブジェクトを一つのプロセスに配置するのはとても自然

予想通りメモリの問題、それによる速度の問題に出会う

メモリというよりオブジェクト数？

この規模まで育てば、の話

問題の傾向

それ以外のトラブルはなさげ

設計があまりにふつうだから？

解決の傾向

不要なオブジェクトを保持しない生成しない

問題がおきてから考える

態度の傾向

基本的にがまんする

外部から指摘があってから動く

たまに自発的に直すが、実はみんなは困ってなかったりする

態度の傾向

規模が大きくなるのに備えて最初から準備をするのはムダ

どんな風に大きくなるか、どこが大きくなるか予想がつかない。大きくならないかもしれない

一つの作戦で全ての大きさに対応できるとは考えない

態度の傾向

問題に出会ったときに状況に応じた適切な解を考えるべき、かな

さらなる不安

オブジェクト数の限界は？

サーバが64bit OSに変わったので気にしないことにした

最終的にはページ名ごとにRWikiサーバを分割するかもしれない

肯定的なまとめ

大きなRubyのプロセスは、意外に丈夫でまだまだいけそう

dRubyの典型的なアプリケーションの配置はこのくらいのちょっとしたツールに適してる

DBMSを中心に考える必要なんてあるのかなあ

肯定的なまとめ

数GBのGCはそこに

GC開発者はRWikiに挑戦するべき

まとめ

今日はRWiki10周年イベントでした

某サイトのRWikiとそこでの問題を紹介

RWikiの構成でもまだまだいけそう。いつか限界がきてしまうと思うけど、それはそのとき考える

重要

2005年夏

まだ初刷買えます!

初刷5周年!!

dRubyによる

関 将俊 著

分散・Webプログラミング

重要

日本語版に寄稿しました

宣伝しなくても売れそう

しばらくお待ちください✓ RWiki10周年✓ 初刷5周年✓ 97プログラマ本✓ RWikiまだいけそう✓ あまりだらしない人だと思われ

ないように

なにかご質問は