Skip to content

Instantly share code, notes, and snippets.

@mshibuya

mshibuya/RubyKaigi0601.md

Created June 1, 2013 09:07
Show Gist options
  • Save mshibuya/5689758 to your computer and use it in GitHub Desktop.
Save mshibuya/5689758 to your computer and use it in GitHub Desktop.
Download ZIP
6/1 Ruby会議メモ
Raw
RubyKaigi0601.md

Ruby会議 6/1

非同期って同期で書くことじゃん

世界はだいたい非同期と同期でできている

非同期ってなに？

  • 同期的じゃないもの
  • 自分の都合と関係なく起こる何か
    • Unixシグナルとか
    • dRuby RMI
特徴
  • まさに非同期
  • 自分の都合に関係なく呼び出される
  • 呼び出されたことをしらない
  • 伝えるチャンスがあるのは呼び出された側
  • どうやって伝えるの？
    • グローバル変数
    • 同期メカニズム
      • Queue
      • Socket
      • TupleSpace

まとめ

  • 非同期によびだされた結果を知るのは面倒
  • 同期メカニズムを使えるよ

非同期的な状況

即時復帰

  • 処理を受け付けたら制御が戻る
  • やりっぱなしではない
  • 結果に興味がある
    • チケットを使って依頼の結果を待つ

いろいろ一度に待つには

  • どれも同じAPIで待てるように均質にする

まとめ

  • 即時復帰するのはたいてい結果が気になる時
  • 本質的には待ち合わせしている

dRubyは非同期呼び出され

コールバックのパターン

  • 結果を待ち合うと固まる
    • シングルスレッド派
    • マルチスレッドで解く
      • dRubyの実装そのもの

まとめ

非同期におこるいろんなことはだいたいいつも同じように解くんだよ！

===

プログラムの流れを追う

@saturnflyer

  • 読む > 書く
  • 最良のドキュメントはソースコード
  • プログラムは共有メモリ
    • 理解をコードに落とせる

何であるかでなく、何をするかが重要

オブジェクトは

  • state
  • data
  • behavior

の表現

Data, 文脈, 相互作用(DCI)

  • 安定なのと変化するものを分けるのが良いプログラム
  • メンタルモデル
    • 何であるか
    • 何をするか

振る舞いは文脈によって変わる

  • extend
  • delegation

Casting

文脈による振る舞い

  • 疎結合
  • 高凝集
  • よりよいカプセル化
  • システムメンタルモデルを支える
  • 詳細メンタルモデルを分ける

===

制約を少なくすると並行性が増す

@ryandotsmith / heroku

  • なんで並行性？
  • 直列的なコードをとりのぞく動機
  • ロックの問題を理解する
  • 実際のロックフリーな設計
  • パフォーマンスはゼロ和ゲーム

なんで並行性？

問題

遅いwebsiteを早くしたい

典型的な原因

  • 繰り返し処理
  • やらなくてもいいことをやってる
  • 並行性が低い

直列的なコードをとりのぞく動機

  • アムダールの法則
  • 少しの直列的なコードが並行性に大きく影響する
  • 直列的なコードをなくせ！

ロックの問題を理解する

  • ロックは並行性をコントロールする
  • queue
    • Webアプリスタックのあちこちに
    • ロックを取り除くにはqueueに注目
    • Fuzzy FIFO

実際のロックフリーな設計

例えばランダム順に処理するとか、FIFOの制約を取り除くことでより並行性が増す！

http://github.com/ryandotsmith/queue_classic

パフォーマンスはゼロ和ゲーム

  • ロックを取り除くことはできるが、その分複雑さは増す
  • 単純さ/パフォーマンスのトレードオフ

結論

  • ロックはコードを直列にする
  • ロックを取り除くことはsemanticsを変える
  • エンジニアリングはトレードオフ
  • 同時性は並行性ではない
  • スケーラブルなロックフリーstackアルゴリズム
  • 単純・速い・実用的なノンブロックqueueアルゴリズム

===

Netzkeでenterprise webアプリを素早く開発

@nomadcoder

enterprise apps

  • 複雑なデータ
  • 複雑な処理
  • 数百のデータモデル
  • 複雑なview
  • 一枚岩のclient side
  • 独立性の低いserver side

モジュール化されたGUI開発

  • divide and conquer
  • 昔からある発想
  • 複雑なアプリに使う
  • Railsむけではない
  • そこでNetzke

Netzke

クライアントサイドのGUI webコンポーネント

  • Server class(Ruby)
  • Client class(Ext JS)

なんでExt JS？

  • 一貫性のある、テーマ化可能な外見
  • 豊富なコンポーネント
  • プログラム可能なview

利点

  • 再利用可能性
  • 拡張可能性(OOP)
  • モジュール化された開発
    • tests first
  • 組み合わせやすい
    • ネストするのも簡単
  • 動的ロード
  • JSのカプセル化

事例

  • 具体例にそって解説

結論

  • Netzkeコンポーネント != data grid
  • Netzke Coreで再利用可能なGUIコンポーネントを作る
  • Netzke、便利だよ！

Q&A

JSのキャッシュは？

ブラウザがやってくれるから特にやってないよ。

Validationは

Server sideのバリデーションが基本。 client sideでもできるよ。

L10n

Rails / ExtJSがやってくれるよ。

NetzkeはJSを生成してくれるの？

生成する必要はないよ。継承して拡張できるから！

Sencha Touchは?

昔やろうとしたけど、アーキテクチャが違うから…。

===

ライブラリ開発者になろう！

@kou

  • 目的
  • アイディア
  • アイディアを適用
  • その気になってもらう

良いソフトウェア

  • rcairo

  • Rabbit

  • よい

    • Rubyっぽいから

客観的に

  • 似ていると一貫性がある
  • 一貫していると読みやすい
  • 読みやすいとメンテナンスしやすい

Rubyらしい = いいこと

確認する

  • Fileクラス

似ているものが多い = より良い

Remember than Imagine

  • 想像しないで、思い出せ
  • 想像するのは難しい。思い出す方が簡単
  • 思い出すには
    • 当然知らないといけない
      • 経験する
      • 聞く
      • 観察する

何を経験すればいい？

  • Rubyの経験
  • 思い出すのは難しい
    • 思い出す経験が少ないから

ライブラリ開発者になればいいじゃん

  • いいAPIについて考える
  • 理解しやすいドキュメントについて考える

どうするか

  • 何と似ているかについて考え
  • おなじようにする

ライブラリを開発すると

  • よりよいバグレポートとは？
  • よりよいパッチとは？

などについて経験できる

===

Rubyを超えて

github.com/rkh

Sinatra oreilly: AUTHD

言語

  • 言語によって概念が違う
  • プログラム言語は道具

オブジェクト指向

  • オブジェクトはデータ構造ではない！
  • Newspeak
    • 全部がmethod sends
    • global stateがない
    • lexical scope
      • 継承関係によって実現

homoiconicity

  • メタプログラミングを可能に
  • Lisp, Logix, Io, Prolog
  • 何の役に立つの？
    • マクロ
    • 局所的なevaluation
    • 言語拡張

宣言的プログラミング

  • SQL, Prolog

ハードウェアプログラミング

  • VHDL

===

fluent-plugin-riakで気軽にログ収集

@kuenishi

  • fluentdでログを全部集める
  • 何かにつっこむ
  • そこにクエリする

riak

  • 分散key-valueストア

  • 重点

    • 可用性
    • スケーラビリティ
    • 簡単な運用

  • いつ使う？

    • Hadoopは大げさ

    • MongoDBじゃ足りない

    • DocumentDB

    • なんでもいける

fluent-plugin-riak

  • JSONで入れる
  • クエリする時
    • 分散JSのデバッグは大変
    • ripple
      • Riakクライアント
    • Mohair

Mohair

  • JSONに対してSQLが書ける
  • SQL -> (parselet) -> JS -> Riak mapreduce
  • whereはMap時
  • group_by, countはreduce

まとめ

  • NoSQLだからって不便なわけじゃない
  • Fluentdを使ってRiakに入れちゃおう
  • MohairでSQLクエリ
  • Pull Request募集中

===

RubyとFluentd, Norikraで複雑なイベントログ処理

@tagomoris

日々の作業

  • ログ取り
  • 集めて保存
  • 視覚化
  • 解析
  • 異常時に通知
    • システム状態
    • アプリケーションのmetrics

バッチ処理 / ストリーム処理

ストリーム＋バッチのhybrid

Fluentd

手軽に可視化

Norikra

  • Streamクエリ
  • Esper
  • JRuby
  • SQLで書ける！
  • fluent-plugin-norikra

===

Unfactoring

@tenderlove

  • Polymorphism
  • Refactoring
  • Caching

ポリモーフィズム

  • 複雑さを隠す
  • decouple
  • 呼び出し元からロジックを削れる
  • 「キャッシュ」

リファクタリング

  • コードはグラフ
    • 構文木

例：ActiveRecordのコールバック

現状(eval)
  • わかりにくい
  • 変えにくい
  • メモリの使いすぎ
  • 高速
改善（lambdaをを返す)
  • わかりやすい
  • 変えやすい
  • メモリ使用が少ない
  • 高速

キャッシュする

  • 例：AR::Relation
    • クエリプランがキャッシュされる
    • 解析したSQLがキャッシュされる
    • キャッシュの改善策
  • bind_parameters
    • プリペアドステートメントのBindパラメータのみ変更

まとめ

  • リファクタリングで速度を上げる
  • ポリモーフィズムでコードを削れる

===

Rubyに貢献する

@_zzak

少しの行数の変更が多い

貢献するには

[実際の操作をデモ]

  • githubでforkする
  • なにか取り組むものを探す
    • 例えば、RDocコメントとか
    • ドキュメント全般とか
    • RDocで生成されたHTMLのシンタックスハイライトを確認したり
    • C関数のドキュメントだって
  • ブランチを切る
  • githubにpushして、Pull Request

===

多様性と戦う

@akr

###「多様性は善」は言い過ぎ

  • 多様性は敵？

DBM

  • key-valueストア
  • 4つのライブラリをサポート
    • ndbm
    • gdbm
    • Berkeley DB
    • qdbm
  • extconf.rb
    • 環境を調査し、Makefileを生成

DBMの歴史

  • 1970 dbm
  • 1986 ndbm
  • 1990 gdbm
  • 1991 Berkeley DB
  • 2003 qdbm

見分けるのが大変！

現在の状況

  • gdbm(debian)
  • Berkeley DB(Redhat)
  • Berkeley DB in libc(BSD)
  • ?

組み合わせがすごく多い！

結論

  • Rubyのdbmはいくつかのndbm互換ライブラリをサポートしてるよ
  • いろんなバージョンのソースを調べた。ソースコードは重要
  • だいたいの環境では動くよ！

多様性との戦い

  • OSが増えている
  • Ruby実装も増えてる
  • 頑張ってね！
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment