BPStudy#25に参加してきました
BPStudy#25 パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ という勉強会に参加してきました。
最近、忙しかったので久しぶりの勉強会参加＆ブログ書き込みです（汗）。
スピーカーは、id:kazuhookuさん
プレゼン資料は、いくつか組み合わせた感じだけど、この２つの資料をメインに説明をしてました。
とても濃いお話だったので、自分はついていくのがやっとって感じでしたが、とても楽しかったです。
今回は、勉強会で自分が印象に残ったことを書いてみます。
どこまでやるかの指標を設定する
パフォーマンスチューニングはきりがないから、処理速度には上限があるはずなのでどこまでチューニングするかの指標を設定することが大切。
たとえば、理論上の最速値（MIPSとかバンド幅とか）の70%に到達することを指標にするとか。
とても納得。でも、指標を設定するにはそれなりのスキルがいるので指標を設定できる人になる必要がありますね。
自分はそのスキルをもってないので、まずはそのスキルが必要ですな（汗）。
mysql_timelineってツールを使うことで指標を出すことができるっぽいので、一度試してみようと思います。
スケールアウトは2000年代のトレンド
スケールアウトは2000年代のトレンド。
コミュニケーションツール（mixiとか）はシステムの規模は大きいが、データのつながりが弱いのでスケールアウトが容易。
スケールアウトの流行は、スケールアウトをしやすいシステムが増えてきているからって話。
当たり前の話かもしれないけど「複雑な業務システムでスケールアウトなんてことはやっちゃだめなんだなぁ」って思いました。
雑誌の特集とかを読んで、どこかのお偉いさんが「次のシステム移行はスケールアウトで！！！」なーんてことがあったりすると悲惨なプロジェクトが生まれそうなんで、ちょっと怖いです。
とりあえず、無茶なスケールアウトについては「やめましょう」っていえるエンジニアでいようと思いました。
スケールアップの逆襲
革新的なサービスが登場しなければ、コスト的にスケールアップがまたはやるのではないか
やっぱりハードウェアの性能をアップすることで解決できるなら、それが一番楽。
案件によってはスケールアウトが必要な局面もあるかもしれないけど、スケールアップで解決できるなら、そちらを選択したいですね。
大規模ウェブサービスの課題
大規模ウェブサービスのチューニングはRDBMSのパーティショニングが多数解となっている。
初期は、アプリケーション毎のパーティショニングで、最近はユーザーごとのパーティショニングが主流となっている。
この問題点は、事前の分割設計が難しいこと、運用開始後の再分割が難しいということがあげられる。
ここらへんの話は、大規模ウェブサービスの仕事をしたことがない自分には「へー」という感じでした。
ユーザーだけではなく、ユーザーと商品と倉庫でパーティショニングをしているところもあるらしいです。
あと、経験がなくても事前の分割設計が難しいということは、パーティショニングしているシステムがどういう処理をするのかを説明してもらったので自分も理解できました。
RDB使ってると、正規化さえしていればリリース前に仕様変更が入ってもなんとかなったりしますが、パーティショニングしているとかなり厳しそう。
これは最近はやりの分散KVSにも同じことが言えそうですね。
こういった案件では、開発の初期段階でかなりしっかり設計をしていく必要がありそうです。
Incline & Pacific
RDBMSと分散KVSのいいとこどりを目指しているプロダクト。RDBMSの動的パーティショニング技術。
Inclineは、ノード間のデータ同期に専念。pacificはRDBMSのshardに専念。
ここまでディープになると、自分は「ぽかーん」って感じです（苦笑）。
でも、RDBMSのパーティショニングを実施するのに、自動化できる部分は自動化した方が絶対よいはずなので正式版がでれば使われるのではないでしょうか。
参加した人にしかわからないかもしれませんが、運用後の再分割の説明をする際に「ユーザーから書き込み権限をとっちゃうんで整合性は大丈夫です」って内容はとても面白かったです。
まとめ
チューニングの基本的な考え方もふまえて説明してもらったので、とても勉強になったし、楽しかったです。
自分は、BPStudy#22で初めてBPStudyに参加したのですが、その時も同じように感じたので、これからも参加していきたいですね。
ナレッジ蓄積について
ナレッジの蓄積について、ちょっと考える機会があったのでちょっと自分の考えをまとめてみます。
ナレッジ蓄積について考えたきっかけは、知り合いの参加したセミナーで「ナレッジ蓄積に重要なのは仲介知だといっていた」という話を聞いたことです。
内容としては、大体こんな感じ。
ナレッジを蓄積するためには、熟練者の持つ暗黙知をいかに形式知にするかが重要だが、熟練者ほど初心者が何が分からないか分からない。そこを埋める「知」が重要になる
この内容が間違っているとは思いませんし、個人レベルでは、今後重要になるスキルかもしれません。でも、これがナレッジ蓄積が上手くいかない要因ではない、と自分は感じました。そんなわけで、じゃあ、ナレッジの蓄積で何が重要だと自分が思っているかを考えてみました。
自分が思うナレッジ蓄積が上手くいかないケース
蓄積したナレッジに対してどこにどのようなものがあって、自分に必要なものがどれかをすぐに見つけ出せるようにする仕組みを作れないことが、ナレッジ蓄積が上手くいかない原因だと思います。たとえば、特定のテーマに対して資料をまとめて共有サーバーにファイル溜め込むだけでは、そのようなファイルがあることが認知されず、結局使われない無駄な蓄積になります（自分の会社ではまさにこの状態）。
ナレッジ蓄積に対する過去の自分の試み
ナレッジを蓄積するため、一昔前にwikiを利用していました。試行錯誤の末、仕組みとしては非常に良いものができ、自分のプロジェクトでは非常に上手く利用できていたと思います。
ただ、自分が管理者のプロジェクトにはかなり上手く活用できたものの、それが他のプロジェクトに広がることはありませんでした（利用者は非常に便利だと感じてくれていたのですが・・・）。そんなことがあって、蓄積の仕組みだけ上手く作って、利用者がその有用性を認めてもらえてもそれだけで広がっていくことはないんだなぁ、と感じました。
自分のプロジェクトがどれだけ上手くいっていても、それだけだと他のプロジェクト管理者にその仕組みが広がっていかないんですよね（wikiのプレゼントかもしましたが、それだけだと全然足りていない感じがしました）
ナレッジ蓄積に対して自分が重要だと思うこと
ナレッジ蓄積のポイントは、蓄積するための優れた仕組みに加え、組織全体で同じ仕組みを使用して蓄積していく（少なくともその組織のプロジェクトの管理者全員が同じインフラを使って蓄積していく）ことが必要だと思います。
でも、管理者は自分なりの管理手法や主義主張があり、ある程度の規模の組織が途中からはじめるには後者はかなり難しいように思いますね。「かかる労力に見合う効果があるの？」って言われたら、相手を納得させるような説明をするのも難しいし・・・
最初に感じた違和感
「仲介知の問題なんかもでてくるかなぁ」と思うのですが、企業レベルでみると問題としては枝葉の部分だと自分が思っているから違和感を感じたんですね。でも、ナレッジの蓄積に対して自分の考えをまとめるいい機会になりました。
candycaneソース公開されました
candycaneのソースが公開されました！
candycaneのソース
さっそく、お昼休みにでもじっくりソースをみようと思ったのですが、こういう時にかぎって、お仕事の都合がままならなかったりするんですよね（泣）。
昨日までは、時間に余裕があったのに。。。
んー、日頃の行いに問題があるのかな？
そんなわけで、まだじっくりみれていないのです。。。
ざっとみただけですが、candycaneのソースのファーストインプレッションはこんな感じ！
candycaneのファーストインプレッション
- コメントがいんぐりっしゅ！！！
- 頑張れ！おいら（笑）
- 国際化対応している
- コメントもいんぐりっしゅだし、最初から世界を意識！
- CSVとPDFのライブラリがphp4とphp5両方ある
- 話には聞いていたけど、php4対応しようとしてるって感じ取れた！
- モデルに、hasAndBelongsToManyという関連があった
- hasAndBelongsToManyは多対多のリレーションで使うらしい
- redmineはけっこうきれいなテーブル設計なのかな？って勝手におもっていたのでちょっと意外
- rssを出力する処理がある
- cakephpではこういう風に作るんだって感じ。勉強になりました
- プラグインの作り方はまだよくわからない
- MenuManagerComponentの_prepareMainmenu関数あたりをみながら、プロジェクトのメニューに追加するのはどうやればいいのかな？？？なんて思ったり、思わなかったり・・・
また、時間をとってもう少し中身をみてみようと思いますー
shibuya.Tracの勉強会に参加してきました
「redmineの勉強会で、かおるんさんが識別できなかったので識別しよう」というとっても不真面目な参加動機（ごめんなさい）。
かおるんさんは受付だったらしく、発表が始まる前にあっさりと目的は達成。
以下は、おまけで聞いてきた勉強会の感想です（笑）。
Tracは3年ぐらい前に試して挫折した経験があって、それ以来ほとんどさわってません。
今思うと「自分の使い方に問題があったなぁ」って思うので、Tracに罪はないんですけどね＾＾；
redmineでも使えるノウハウとかあると思うので、そこらへんに期待してました。
感想は・・・ほんと参加してよかったです。
もう４回目ということで、Tracの基本とかはなかったですが、やっぱり刺激になりますね。
どんな刺激をうけたかというと・・・
受けた刺激
- 発表者のプレゼン資料のデザインがすごくて感心しました（Trac関係ないですが＾＾；）。
- 他にも、画面がズームで見やすくしたり、iPodでPCを操作したりとか、基本的なPCに対する知識とスキルに圧倒された（笑）
- scrumの考え方にふれることができた(これもTrac関係ない？)
- 導入に対する心構えや、対応とか、経験者の声を聞くことができた（Redmineでも使える）
- 昔よくチェックしてた「HirobeのHack倉庫」のhirobeさんが見れた
- sharepointが、どんな感じかイメージができるようになった（今までみたことなかったんで）
個別に刺激をうけた点をあげると・・・
どこでもTracWiki＋Mylyn改造計画
ScrumとTrac
- Scrumの考え方は、仕事の役割分担を改善できる要素があるように思ったのかなり興味がわいた
- スプリントプランニング、スプリントレビューといった要素を自分のスタイルにうまく導入できないかなぁ・・・
- ツールや開発手法に関する姿勢にはかなり共感
- 理論どおりに完全になぞるのは逆効果、チームが納得したものをやっていくことが大切・・・現実的で迷った時に使える判断基準だと感じた
- マニュアル作りとか説明会とか、自分ももうちょっとやらないとね（新規メンバーが入った時は、毎回redmineの説明会やろうかな）
ライトニングトーク
- Googleチャート使ってグラフを表示しているプラグインがあった。redmineの勉強会でも使っているって人がいたのでこれも使えると便利そう（open-flash-chartはcakephpから使ったことあり）
- かおるんさんが「フロントエンドたくさんあっていい」という話をされていたけど、たしかにそうだなって素直に思った。マクロのツールとか結構作るんで、かおるんさんのPGを参考に自分もなにか作れればと思った
- SourceRepoは、tracだけじゃなくredmineも使えるみたいなのでかなり試してみたい（興味深々・・・こんど情報収集しよう）
あとは、全般的に雰囲気がよかったですね。
同じようなメンバーで何回か続けているからですかな？
アットホームな雰囲気で、初参加の自分もくつろげました。
redmine勉強会に参加してきました−完璧なRedmineなど存在しない
4個目のプレゼンは、id:junoさん。
プレゼンの資料はこちらです。
自社の実績
- 2008.10〜
- 18プロジェクト
- 1696チケット
- 22ユーザー
- １つのプロジェクトが大量にチケットを登録しているなど、かたよりがあるとのこと
移行にあたってやったこと
- マニュアルを作成（pdfで30ページ）
- 段階的な導入
- 積極的な要望の吸い上げ
- 自分が率先して使う
積極的な要望の吸い上げ
- wikiの記法をマークダウンの拡張に
楽しく利用できる工夫
パッチのプラグイン化
実際にredmineの導入を推し進めていった経験についても語ってくれたのですが、なんかものごとを前に進むパワーみたいなものを感じましたね。
こういう人が「redmine使いましょう！」って言ったら、関係者も使うんだろうなぁ、って感じです。
組織でこういったツールを導入するには周りの人も巻き込んでいくパワーを持った人が必要だよなぁ、なーんてプレゼンを聞きながら思ってました。
個人的には、孤独に使うのもステキだと思うんですけどね（笑）。
あと、プラグインについても参考になる情報がたくさんありました。
こういう話を聞くと「自分もプラグイン導入しよう！！！」という気持ちになりますねー
redmine勉強会に参加してきました−効率的なアジャイル開発の実現に於けるRedmineの運用事例ご紹介
３個目のプレゼンは、id:tsuyoshikawaさん
id:tsuyoshikawaは、OOPJogを主催して、Sinatora勉強会も企画中ということでした。
活動的ですね。
プレゼンの資料はこちらになります。
で、以下が自分のメモ書きを垂れ流すわけなのですが、プレゼンが非常にスピーディだったので、自分はメモるどころか要点もあやしい感じになってしまいました。。。
というわけで、かろうじてメモれた内容がこんな感じです。。。
夢
・全工程を一元管理
現実
振り返って
- 活動で、現場の一体感がでた
- 活動をRSS登録することが大切
・・・ほとんどメモれてませんね（苦笑）。
でも、自分もpukiwiki＋影舞＋subversionをいろいろ工夫してプロジェクトの情報をまとめていたので、共感できる部分は多々ありました。
プレゼンの中に、redmineのwikiはいらない子って話があったのですが、wiki大好きな自分ですらredmineのwikiは使ってないです。
今、有効にしているモジュールは、
の３つだけ。
pukiwikiで育てたwiki文化が、redmineが生かせないのは痛いですね。
とはいえ、pukiwikiの独自プラグインをがんがん使っているサイトと同じことを、redmineのwikiじゃできないし・・・
先日、redmineを若手に使ってもらおうと説明している際に、話の流れでpukiwiki＋影舞＋subversionで管理してたサイトも見せたのですが、そっちの方が好評で複雑な気持ちに・・・なんてことも。
redmineのwikiがpukiwikiになればいいのに、って思います。
redmine勉強会に参加してきました−Redmine活用術 〜孤独なシス管の場合〜
２個目のプレゼンは、id:kirara_397さん
「redmineはもっと評価されていい」というブログ記事を書いた方です。
プレゼンの資料はこちらです。
自己紹介
- 5プロジェクトごと一括管理
- 各プロジェクトの成果物をsvnで管理
- 「トラブル」、「要望」、「タスク」等にカテゴライズ
- 実質一人でつかってます
- 関係者にはニュースからメールを発行
運用時のトラブルになるポイント
活用した上で工夫したこと
- 用語を分かりやすくした（チケット＝課題等）
- Active Directoryアカウントでログインできるようにした（アカウント管理の簡素化）
- 自分好みにCSSを修正
- サービス化した（mongrel_serviceというgemを利用）
