Wii Fitで運動
やっとWii Fitを購入しました。
以前から買いたいと思っていたのですが、なかなか購入にはいたりませんでした。
ですが、連休中にカラダを動かす予定が入ってなかったので、
この際買っちゃえ！って思いつきのまま購入。
先週の日曜日から今日（火曜日）まででトータル3時間ほど、ヨガや筋トレなどをしたのですが、カラダがこわってます！特に足が･･･。
※こわる ＝ 筋肉痛
所詮ゲームだろうと馬鹿にしていた自分がいたのですが、そんなことはないということを実感しました。
めっちゃ汗かくし、筋肉痛になるし、本当に運動したときの疲れと同じです。
これからは体重管理＆運動を毎日継続していきますっ！
＃ちなみに今上期の目標は体重マイナス10%です
JJUG Cross Community Conference に行って来ました
今回、JRubyとGlassFishの講演を聴いてきました。
そのときのメモを載せておきます。
JRuby on Rails 田中洋一郎（ATLシステムズ）
・Script Engine
・何十とあるがJRubyはその中の一部
・Rubyに関する書籍もトレンドも上り調子
・Rails運用
運用している人はかなり少ない
・RoRアプリの安定運用環境は非常に難しい
・Unix系サーバソフトの知識が必要
・負荷分散を図りにくい
・ビジネストランザクションに対応していない
・JavaEE
・運用面のメリットは非常に大きい
・選択肢の豊富さ
・スケールアウトしやすいアーキテクチャ
・多くの稼動実績
・運用監視の充実
・情報の豊富さ
・開発面は？？
・生産性は頭打ち・・・
・JRubyは？
・100％ピュアjava
・CRubyの1.8.6と互換性あり
・JRubyのテスト
・Ruby on Railsアプリが常に稼動することを意識して開発を進めている
・JRuby
・開発時
・Ruby言語の特性がメリットとなる
・Ruby on Railsの開発環境のよさをそのまま得られる
・運用時
・J2EEの運用環境のよさをそのまま得られる
・選択肢が豊富(glassfish,tomcat,jetty,geronimoなどなど)
・DB接続（2種類）
・Ruby on Railsに標準搭載の接続方法
・ActiveRecord-JDBC
・コネクションプールを利用可能
・Ruby on RailsのコマンドはほぼJRubyでも網羅している
・JRubyでのrailsの実行形態
・開発はWEBrick
・運用はwarを生成してから運用（war生成方法は2種類）
・goldspike
・CGIでなくservletによるマルチスレッドモデル
・CGIと比較すると派フォー万bんす敵に有利
・warbler（内部でgoldspikeを利用）
・CRubyで書かれたものもOK
・今後はこちらがスタンダードとなっていくだろう
・冗長化の際のセッションの扱い
・CookeiSessionの場合
・サーバではなくクライアントに保持されるため、そのままで問題なし
・ActiveRecordSessionの場合
・そのままで問題なし
・FileSessionの場合
・冗長化構成では使えない
・MemCachedSessionの場合
・MemCachedのクラスタ化？で対応
・JRubyならではのアーキテクチャ
・EJBとの連携
・ModelにEJBを適用
・java APサーバ提供の分散Tx環境を利用可能
・RMIの利用
・JRubyならではのJava連携
・オブジェクトのプロパティに対する操作
・setterとgetterを呼び出す必要がない
・Rubyらしいメソッド呼び出し
・JRuby上でRoRを動かす
・IDEの恩恵
・netbeans6.1はRubyコーディングにむいている
・デバッガが使える
・JRubyのデメリット
・日本語のサポートが微妙
・UTF-8以外は全滅と言ってもよい
・携帯アプリを作ろうと思うと致命的
・動いちゃえば早いが・・・
・最初の起動が遅い（安定はするが瞬発力がない）
個人的な感想としては、特に新しい情報を得る機会となったわけでなく、
JRubyを今後利用する上でのメリット・デメリットを再度把握することができた。
EJBと連携させて利用されている事例もぽつぽつ出始めてきているようなので、
連携させたときのメリットなどもまとめておくとよいかも。
GlassFishで一歩進んだ開発をしてみませんか 寺田佳央（サン・マイクロ）
アジェンダ
・Glassfishの紹介
・grizzlyの紹介
・Grizzlyのアーキテクチャ紹介
・Asynchronous Request Processingの紹介
・Cometアプリケーション
・grizzly cometの紹介（サーバ側の実装）
・Grizzletの紹介（サーバ側の実装）
・Glassfishの紹介
・オープンソースコミュニティ
・Java EE 5完全対応
・Web2.0対応
・Ajax、Comet
・WEBサービス
・商用サポートあり
・Sun Java System Application Serverは、GlassFishと内容は同一でインストーラが付属
・Java Web Start
・湾クリックでクライアントアプリケーションの自動DL、自動アップデートが可能
・最新のWEB2.0技術に対応
・Ajaxの動作環境として最適
・Cometアプリケーションの実行も可能
・サーバ側のイベントで動的コンテンツ配信
サーバ側でのイベント発生でクライアントへ通知（オークションなどで利用できる）
・JMaki
・JavaScriptの知識なしでAjaxアプリケーションの開発が可能
・Ajaxを実現するための簡易カスタムタグライブラリを提供
・JRubyなどなど
・SOA基盤
・openESB 2.0搭載
・grizzlyの紹介
・先進的なサーバエンジン
・汎用的なサーバエンジン
・Java New I/Oを使用
・非同期処理を実現
・ハイパフォーマンス
・Cometの動作も最適
Grizzlyのパフォーマンスが良いので、GlassFishのパフォーマンスも良くなっている！！
・GlassFishにおいてHTTP,HTTPSの処理を行いコンテナに処理を転送するコネクタ
・HTTP以外（TCP,UDP,FTPなど）の処理もサポートしている
・WEBサーバの実装の歴史
・プロセスfork()型
・クライアントからのリクエストごとにプロセスをforkする実装で負荷がかかる
・マルチスレッド型
・各リクエストごとにスレッドを実行するが、スレッドの生成はコストが大きい
・blocking I/O型
・grizzlyはblocking I/Oもnon blocking I/O（Java New I/O）もサポートしている
・Grizzlyのアーキテクチャ
１．selectorThreadでリクエストを受け付ける
２．Pipelineでスレッドプール
３．ReadTaskがデータ読み込み
４．StreamAlgorithmでデータ完全性解析（全て読み込まれていなければ再度取得）
５．ProcessorTaskでHTTP処理
６．HTTP Adapterへ渡す
・SelectorThread
OP_ACCEPT、OP_READの処理を行うスレッド
・Pipeline
ワーカースレッドのスレッドプールの実装クラス
・読み込み処理はオブジェクトプールとスレッドプールの2段階構成になっている
・Asynchronous Request Processingの紹介
・C10K（クライアント10,000）問題
・Asynchronous Request Processing技術を実装しているため、1つのスレッドで複数のリクエストを処理できる
・30スレッドで10,000のリクエストを受け付けることができる
・Cometアプリケーション
時間の都合で簡単に説明して終了
・Grizzlyの今後
・1.7.3
・Servlet 3.0 style comet API
・Bayeux仕様への完全対応
・1.8.0
・NIO 2(JSR-203)のサポート（JDK7）
・Comet対応
・Reverse Proxy/Load Balancer
・その他
・2.0
・NIO2のフルサポート
・モジュールのフルサポート
・Grizzletは現在Grizzly1.6以上で動作可能
今回はGlassFish v3の話がなかったのが残念。
しかし、Grizzlyのおかげでglassfishのパフォーマンスが向上しているなど
Grizzlyの内部の話を聞くことができたのが収穫。
かなり深い話だったので、部分部分しか理解できなかったが、ARP（Asynchronous Request Processing）の部分は
Glassfish v3を扱う前に、きちんと理解しておく必要がありそうだ。
Click Framework
・高性能
・Strutsと同等またはそれ以上の性能
・フレームワークを把握しやすい
・学習コストが低い
・拡張しやすい
・トラブルに対処しやすい
・理想と現実の妥協点
・Servlet APIを隠蔽しようとはしていない
・コンポーネントを使わずに開発することも可能
・設定ファイルを記述する必要は（ほとんど）ない
・後方互換性を重視しているので安心して使える
・Spring,Hibernate,Cayenneとの連携機能が用意されている
・国際化されており、日本語も問題なく利用することが可能
・モックによるユニットテストの支援
・Eclipseプラグイン（ClickIDE）
