投稿

ぎっくり腰

月曜日(2008年6月23日)の朝に机を移動させようとしたら突然グキっときました。 んで、月曜日はほぼ動けずじまいでした。 今日、お医者さんに行ってきたら「筋膜の炎症」との事。 レントゲン撮って貰って、骨には異常なし、という事でほっとしてます。 とりあえず、人生初のぎっくり腰。 腰はホントに重要です、という事を認識+年取ったなぁ、と再認識した次第。 重い物を持つ時は気をつけましょう。 以下、wikipedia情報。 ■ぎっくり腰とは? ぎっくり腰(-ごし)とは一般的に、重いものを持った時や急な体幹の捻転時におこる急性の腰痛を指す。正しくは「急性腰痛症(きゅうせいようつうしょう)」とされており、「ぎっくり腰」という病名は存在しない。欧米ではその病態から「魔女の一撃」とも呼ばれている。地方によってはびっくり腰とも呼ばれる。 急性の筋・筋膜性腰痛や腰椎椎間板ヘルニア(ようついついかんばん-)の病態であることが多いが、稀にスプラング・バック(棘間・棘上靭帯損傷)でも同様の痛みを発する。発生要因等も様々であるが、主に年齢(ヘルニアは若年性だが筋関係は加齢によって好発)や運動不足(急な運動)などが考えられる。なお、腫瘍が原因で起きている場合は、夜間痛・安静時痛が多く起こるので、ぎっくり腰のように損傷時由を特定できる場合は少ない。 ■急な腰痛への対処 ぎっくり腰のような急に激しい痛みがきたときの対処法として、 最初に患部を冷やすことが肝心 である。これは他の急性筋肉疾患でも同様だが、冷やすことで炎症の亢進を抑えて疾患の拡大(腫れ・疼痛)を出来るだけ小さくするための処置であるので、可能な限り早く冷やした方が治療効果も高く痛みも少ない。 急性期を過ぎた後は、今度は 出来るだけゆっくりと温めて血流を良くする と筋の復帰も早い。腹圧を上げる為のコルセット着用も効果的である。 また、下肢の痺れ・感覚鈍磨・歩行困難等が顕れるような場合は、椎間板ヘルニア等の恐れもある為に病院の診察が必要である。

なつかしアニソン

決して兄損ではありません。 ■魔神英雄伝ワタル シバラクのおっさんが好きだった。 ■NG騎士ラムネ&40 ダサイダーが好きだった。 あかほりさとるは今なにやってんだろ?? ■新世紀GPX サイバーフォーミュラ F1にはまってた頃。 今考えると色んなレースを混ぜ込んでたんだなぁ、と思う。 必殺技を叫ぶと早くなるのはお約束。 てか、今見るとキチガイじみた車に乗って、狭いコースをガリガリと走っとるよ。

秒速5センチメートル PV

Java VMパフォーマンスチューニングガイド

イメージ
※気に入ったらアフェリエイトのクリックをお願い♪ ■Introduction 1. チューニングの目的 2. チューニングポイント 3. まずは何もしないでGCを測定してみよう! 3.1. Summary 3.1.1. Heap Capacity 3.1.2. GC Activity Summary 3.1.3. Overall Statistics 3.2. Heap usage 3.3. Duration 3.4. User defined 4. アプリケーションに合わせたGCアルゴリズムを選択しよう 4.1. 「-server」オプションを試してみましょう。 4.2. 「-noclassgc」オプションを試してみましょう。 4.3. 「-XX:+UseParNewGC」を試してみましょう。 4.4. 「-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=32」を試してみましょう。 5. Heapの最適値を探しましょう。 5.1. まずは、「-Xmx1024m」を設定してヒープの上限を見極めましょう。 5.2. 次に、ヒープのextensionを抑制してみましょう。 5.3. 「-Xmn32m」を試してみましょう。 5.4. 「-Xms128m -Xmn64m」を試してみましょう。 5.5. 「-Xmx1024m –Xms256m –Xmn128m」を試してみましょう。 6. 最後に 1. チューニングの目的 一般的に、チューニングを行う目的は実行時間を短くすることです。 本ドキュメントでも、実行時間を短くすることを目的にチューニングを行っています。 2. チューニングポイント 本ドキュメントでは、Java VMの起動オプションを変更することにより、実行速度の向上を実現します。 その際に必要なポイントとしては、以下のものがあります。 ・GCアルゴリズムをアプリケーションにあったものにする。 ・GC回数をなるべく減らす。 ・GC時間をなるべく減らす。 3. まずは何もしないでGCを測定してみよう! JavaVMのパフォーマンスチューニングを行う前に、まずは現在の状態を正確に把握しましょう。そうでないと、チューニングを行った結果、早くなったのか遅

Flex1.5のチューニングポイント

MacromediaのサイトからFlex1.5のチューニングポイントを抜粋。 - flex-config.xml内のキャッシュサイズは十分確保しているか? → flex-config/cache/content-sizeの値を確認。デフォルト値500が指定されていれば問題ないはず。 - flex-config.xml内でproduction-modeをtrueにしているか? → flex-config/production-modeの値を確認 ただし,アプリケーション更新時にアプリケーションかサーバの再起動が必要になることに留意する。 - flex-config.xml内で最適化を有効にしているか? → flex-config/compiler/optimiseの値を確認 ただし,アプリケーション内のtrace文が無効になることに留意する。 - 通信プロトコルにAMFを使用しているか? → MXMLのmx:RemoteObjectタグを利用していれば自動的にAMFが利用されているはずなのでOK - RemoteObjectのtype属性は"stateless-class"か? → MXMLのmx:RemoteObjectタグを確認。未指定の場合はデフォルト値"stateless-class"が使用されるのでOK。 - RemoteObjectのconcurrency属性は"multiple"か? → MXMLのmx:RemoteObjectタグを確認。未指定の場合はデフォルト値"multiple"が使用されるのでOK。

flex1.5のカスタムタグのバグ

カスタムタグを利用してjsp内にmxmlを記述することが出来ます。が、落とし穴がありました。 どうやらリクエスト毎にmxmlのコンパイルが走るらしいです。 しかもその度、mxmlファイルにロックがかかる見たいです。 それがボトルネックになっていたみたい。 先ずは何かしら逃げ道がないかどうかを調べましょう。 mxmlcとか。 無ければhtml化を考えましょう。 てか、そんなイケテナイ実装アリデスカ? そのものズバリ。 http://www.adobe.com/jp/support/flex/ts/documents/1332aa75.htm flex1.5のバグだそうです。 あぁ。

RemoteObject性能問題

RemoteObjectに性能問題がありそう。 5000件のデータを処理するのに1分程度かかってます。 # サーバ側の処理は1秒以下。 「Object.registerClass()」を使うと、ActionScriptとJavaの間で明示的に関連付けが出来るそうです。 その結果、ActionScript(RemoteObject?)が一生懸命探さなくなるので早くなるそうな。 んで、実際やってみました。 実行速度、約2倍。 ぶっちゃけ、2分が1分。 でも、遅い。 それ以上早くするには通信するデータサイズを小さくするしかないそうな。 ていうか、8Mの通信とかありえん。 どんな設計思想だ?これ。