Ruby言語やLinuxのネタが多いです。
January 01, 2004 [おもひで]
■ [Ruby-GNOME2] 久々にGType vs Rubyのクラスで悩む
GObjectではgtk_hoge_get_type()みたいな関数（実際はそのマクロのHOGE_TYPE_FUGA）を呼び出すことでその型（というかクラスと言って良いと思うんだけど）が何者かを知ることができる。実際はGTypeというIDが返される。
でも、この*_get_type()というのは１度呼び出されないとそれが何者かどうか確定しない。
実際、アプリケーションが全てのウィジェット（クラス）を扱うわけではないから、このようなLazyな実装はとても都合が良い。
■ ところで、Ruby-GNOME2では初期化時にGTypeとRubyのクラスを紐づけてしまう。そう考えるとそれだけでRuby-GNOME2はC言語版に比べて大層重い処理をやってしまっていることになる。
とはいえ、そこでProperty等の情報を取得してメソッドに自動変換したりしてるのでやむを得ないと思うし、その程度のことなら現在のCPU速度を考慮するとあまり気にしないでイイと思ってる（開き直り）。今のところ他にもいろいろやらなきゃいけないことも多いしね。
でも、このことで１点、困ったことにぶちあたってしまった。
というのは、hoge_get_type()という関数が公開されていないものがあるのだ。
ある特定の関数から呼び出されるようになっていて、いつそのGTypeが確定できるのかがモノによってマチマチだ。
具体的にはGdkの環境依存のクラス(X11, LinuxFB, Win32)のところがそうなってる。もちろん、環境依存の部分は隠蔽すると考えるのであれば、そもそも実装する必要はないんだけど、GTypeとRubyのクラスが1:1にならなくなるのでなんか気持ち悪い。特にGTypeからRubyのクラスに変換するときに、環境依存のGTypeがきちゃうとそれを環境非依存のRubyクラスにマッピングしてあげる必要も出てくる。
■ あ、そうか。逆に言えば、先にRubyのクラスだけ定義しちゃって、確実にGTypeが決まった後にRubyのクラスとGTypeをマッピングできれば良いのか。GOBJ2RVALあたりか。うーん。
■ [Fedora] MozillaでFlashプラグインが動かない
友人からの年賀状Flashを見ようと思ってFlashプラグイン(Shockwave Flash 6.0 r79)をインストールしたんだけどどうにも動かない。何でかなーと思って-gオプション付きでmozillaを起動したら以下のようなメッセージが。(LANG=Cにしたのは文字化け対策)
# export LANG=C # mozilla -g LoadPlugin: failed to initialize shared library /usr/lib/mozilla/plugins/libflashplayer.so [libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory] LoadPlugin: failed to initialize shared library /usr/lib/mozilla-1.4.1/plugins/libflashplayer.so [libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory] LoadPlugin: failed to initialize shared library /usr/lib/mozilla-1.4.1/plugins/libflashplayer.so [libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory]
■ なるほど、ということで、compat-libstdc++-7.3-2.96.118.i386.rpm, compat-libstdc++-devel-7.3-2.96.118.i386.rpmをインストールして再起動したら無事動作した。
January 02, 2004 [おもひで]
January 13, 2004 [おもひで]
January 18, 2004 [おもひで]
■ [Ruby-GNOME2] Logo for Ruby/GtkGLExt
Ruby/GtkGLExt向けのサンプルを書いてみました（と言っても、GtkGLExtのC言語で書かれたサンプルをRubyで書き直しただけです）。
思ったよりフツーに動くのでちとびっくりしました(^^;)。
いろいろと事前に必要なライブラリとかが多いのですが、良かったらマウスでグリグリしてみてください。
■ ちなみに、Linux上では若干再描画が上手にいかないようだ（マウスポインタの部分が絵を壊す）。これはオリジナル版もそうなのでしょうがないと思うんだけど、Cygwin上だときれいに表示されるんだよなー（もちろんCygwin上でも動くYO!）。
■ ところで、Ruby/GtkGLExtでは、RubyのOpenGLバインディングであるOpenGL Interface for rubyを使うんだけど、これってメソッド名がCamelCaseなのね。先頭文字も大文字。
まぁ、悪くはないんだろうけど、他の部分がCamelCaseではないので、その部分だけ浮いた感じがする、ってか、やっぱり見づらいよなー、混在は。
January 19, 2004 [おもひで]
■ [Misc] うーむ
昨日Ruby-GNOME2 MLに送ったメールが届いていない様子。エラーメールも戻ってきた。
急にどうしたんだろう。
そういえば、数日前、オレの使ってるhighway.ne.jpのメールサービスが一時的に動かなくなったんだけど関係してるのかな。
■ [Misc] Software Design 2004-02
Ruby-GNOME2が紹介されてるとのこと。記念に買おうかな。
January 20, 2004 [おもひで]
■ [Ruby-GNOME2] Visecas
Jan Weilさん作。EcasoundのGUIフロントエンドだそうです。Ruby/GTK2とRuby/Libglade2を使ってるようです。
なぜかサウンド関連のアプリケーションが多いみたい。
■ [Misc] やっぱりSFにメールが届かない
一応、Highwayのサポートに届かないんだけど、ってメール出したら、紋切り型のつれない返事。とにかくこちらが書いたモノを読まずに一次回答用のテンプレートを送ってきたようだ。
■ そんなわけで、ちとむかついたので厳しくリプライ。
■ といっても、あの調子ではなかなか解決してくれないだろうから、 ひとまず、XREAのアカウントでSFのMLに入り直してしばらくはそちらのアカウントでやりとりすることにして当面を乗り切ることにした。
■ XREAのアカウントでSFのMLに入れるってことは、少なくともSFとhighway間か、あるいは、mutoh@highway.ne.jpというアカウント自体がまずいのかってとこだよなー。
動きを見ると、他のアカウントからのポスト(XREAのオレのアカウント以外も)はOKっぽいので、mutoh@highway.ne.jp自体がSFにrejectされてるのか？と思ってSF上のドキュメントを漁ってみるとWhy does Sourceforge reject my mail?というのを見つけた。最近のサービス停止でメールサービスの入れ替えを行っていたようなので、これに該当するようになってしまった可能性もありそうだ。というわけで後でゆっくり見てみることにしよう。
ruby-gnome2-devel-en-request@lists.sourceforge.net
SMTP error from remote mailer after RCPT TO::
host mail.sourceforge.net [66.35.250.206]: 550-Postmaster verification failed while checking
550-Called: 61.122.117.161
550-Sent: RCPT TO:
550-Response: 550 unknown user
550-Several RFCs state that you are required to have a postmaster
550-mailbox for each mail domain. This host does not accept mail
550-from domains whose servers reject the postmaster
■ postmasterアカウント(mailbox)がhighway側に存在しないのでrejectされる、ってこと？
January 26, 2004 [おもひで]
■ [Ruby] 正規表現練習帳
MoonWolfさんとこ。ちと遅れたけど、これ便利だなー。練習帳というかデバッグとかにも使えそう。
普段irb使って確認してたりするから非効率的だったんだよな、オレ。
これは是非使わさせていただきたいな。
■ [Misc] 放置されてたので
かなり不機嫌そうな感じでHighwayのサポートセンタに電話してみた。受付の女の子にはかわいそうだが、１週間近くメールサービスがおかしくなるのはちと耐えられない。
んで、ついさっき、折り返しメールが届いた。
ご連絡いただきました件ですが、ご指摘の通り現在「postmaster@highway.ne.jp」のアドレスは存在いたしておりません。
「550-Postmaster verification failed while checking」のエラーが当サービス側のSMTPより応答しておりますので、この部分を中心にエンジニア側と調整確認を取っております。
だと。
■ こういうのの設定とかってとっても苦手だったりするのであまりえらそうに語れないんだけど、postmasterの有り無しでこういうチェックをかけるところがあるのね。
確かにセキュリティ上、チェックしないよりは効果的かも。ってか、そもそも、postmaster無くても良いってことすら知らなかったよ。
そういう意味では勉強になったなぁ。災い転じてってことか...。
＃ってことになればいいんだけど。
■ [tDiary] adulau's diary
たださんのところで知ったんだけど、彼はベルギー人なのかな。Laurentもベルギーに住んでる。知り合いなのかな、それとも偶然か、ちょっと興味深い。
ってか、LaurentはよくtDiaryの質問をオレにくれるんだけど、tdiary-talkはあまり知られてないのかな...。MLであればそれなりに情報も蓄積されるだろうに。
■ [Ruby-GNOME2] Ruby/Libburn
先ほどと同じくLaurentが。また新しいプロジェクトを始めたらしい。すごい。
オプティカルディスクを操作するためのライブラリLibburnのRubyバインディングとのこと。
サンプルにRuby/GTK2を使ってくれているらしい。
■ [Misc] How do you think?
きたさんとこから。オレも結構使ってるのでGoogle検索してみた。
■ "How do you think about" 7,650件
■ "What do you think about" 932,000件
■ なるほど。確かにWhatの方が圧倒的に多い。これからは気をつけないといかんなー。英語は難しいなー。
January 27, 2004 [おもひで]
■ [Java] Webアプリケーション開発者（ってかむしろ運用してる人）のみなさまへ挑戦的な問題です
ロードバランサ・フロント(WebLogic)２台・バック（Oracle,クラスタ構成）のいわゆるWebシステムがあります。
このアプリケーションが最近よく"No resources available"というメッセージのSQLExceptionをあげ、それ以降はそのサーバ上では同じ例外が出続けるため、サービスを提供できなくなることがわかっています。
（調べるまでもないのですが）ログの結果からConnectionPoolから取得したConnectionのリリース漏れが原因のようです。
例外が出ていないサーバ上ではかろうじてサービスを提供し続けることができますが、ロードバランサではラウンドロビンで処理を振り分けているので1/2の確率でエラー画面が表示されることになります。
さて、この状態でサービスを上手に提供しつづけるにはどうしたら良いでしょうか。
■ それではスタート！ チャララララララララー
■ 模範解答Ｆ：特に何もしない
アプリが悪いんだから、アプリ開発ベンダが直すまでは何もしないと言い切るというのは自分に素直な回答といえます。しかしベンダの実力が伴わないとだめです。（特にいつ直してくれるかわからないという状況では）運用するのもこちらなので結局被害を被るのは自分たちです。理想と現実だいぶ違うから夢から覚める必要があります。
■ 模範解答Ｅ：ロードバランサでヘルスチェック
"No resources available"を出したフロントサーバを自動で切り離し、もう片方のサーバのみでサービスを続けます。
模範解答Ｆより少しお利口さんです。でも、結局もう１台の方もすぐに同じExceptionが出てサービスの全停止となるでしょう。それまでにWebLogicを再起動できれば何とかなるかもしれませんが、２台いっぺんに落ちる可能性もあります。これでサービスを連続稼働できるかなんて、まだまだ夢見がちだからもすこし大人になる必要があります。
■ 模範解答Ｄ：ソースコードレビューを行う
DBのスペシャリストとWebLogicのスペシャリストを使ってソースコードレビューを行います。
今までの模範解答よりはだいぶお利口でしょう。模範解答Ｆに比べいくらかクールです。ただ、レビューしても直すのがあのベンダなのでいつ直るかわからないところがつらいです。
でも、そこまで現実わかっているならもうひとがんばりです。
■ 模範解答Ｃ：こちらで引き取ってソースを直す
もっとも限りなく正解に近いです。こちらの工数はかかりますが総合的には安くつく可能性すらあります。でも、全然関係ないバグを見つけてしまったらどうするか（いや、直すしかないですが...)とか、そのソースをアプリベンダがきちんとメンテナンスできるかとか、いろいろ決めなきゃ行けないことも多くなるでしょうから油断は禁物です。
■ この辺のチョイスのセンスでこの後の運用の大変さが大きく左右されます。まるで左右のフロントサーバのように。
■ 模範解答Ｂ：フロントサーバを増やす
サーバを増やしただけでは単なる延命措置にすぎず模範解答Ｆと対して変わらないかもしれないのでなんとも中途半端です。なくても良いけどちょっとはあった方が、なんてそんなの微妙すぎです。
■ 模範解答Ａ：ユーザに使用制限をかけてもらう
ユーザがあまり使わないように頭を下げて回ります。実際には効果的ですが、そんなあなたは卑屈すぎです。アプリ改修は怖くないです。勇気をもてください。
■ 模範解答Ｇ、Ｈとして、サーバのスペックを上げるとかいうことも考えられますがでかけりゃいいってものではないということを肝に銘じて欲しいです。女性の敵ですよ。
■ いろんな模範解答を考えてみましたが、最後に私の言いたいことは、そもそも最初の段階でもう少しまともなアプリベンダをチョイスすべきだったということです。アプリベンダの一部の人が優れたプログラマだからってその人が全部作るわけないのですから、それで全体を判断するのは良くないことです。加えて言えば、スケジュールとリソース管理がきちんとできる、いわゆるプロジェクト管理がきちんとできる人がいるベンダを選ぶべきだったと思うわけです。
■ ラーラララーラララーラララララ....
■ っと、まぁ、ちょっとむりくり何かにあわせたような模範解答（？）は置いておいて、みなさんがこのような状況に陥ったときはどのような解決策を取るのでしょうか。
アイデアを採用させていただいた方にはもれなくRuby-GNOME2のCVSアクセス権をプレゼント！（うそっ）
＃ってかホント、誰かこんな状況下のオイラを救ってくれ...(泣)。
▲ (う) [アメリカにんはiconv使わないから気づいてないだけとか。]
▲ むとぽん [iconv自体がWindowsに最初から入ってないからってことかと思うのですが違うのかな。]