墜落日記 - 2009年7月の墜落
2009年7月22日
次のドルフィードリームは八神はやて、ではないらしい(爆)
次のドルフィードリームの情報が公開された。
で予想の通り八神はやて………ではなく(爆)、久寿川ささらとルイズと来たようだ。
なんかよう分からんレパートリーだが、いい加減に高町なのはとフェイト・Ｔ・ハラオウン、ヨーコとニアと続けてきて息切れなんだろうか………？
ぶっちゃけ手間暇掛けてもオークションで未だに売れ残っているフェイト・Ｔ・ハラオウンを見て危機感がつのったのかもしれんが(爆)
この経済危機で流石に金銭感覚くるった諸兄の財布の紐もきつくなったという事実に、攻めの姿勢もとうとう限界が来たか(汗々)
かく言う自分も、いろいろとやらかしちゃう後の当面の生活費を工面しておかないとならないので、財布の紐がキチキチに締まっていたりなんかするのだけど………
と言うわけで、今回のドルフィードリームは高確率でスルーと相成りまして、ちょっと安心している自分。
もっとも、ダイナマイト素体じゃなかったら最近のドルフィードリームの中では価格的にも抑え気味なので考えたかもしれんけど。
（ダイナマイト素体はエスカレイヤーで「もう、いらね」と思った瑞輝智佳）
てか、金無いです、dynabook SS RX2 の支払いもまだ来ないし。
ちなみに、分割するとネチネチと痛いし分割数を多くすると支払いが終わってないのに給料が無くなるなんて事態にもなりかねないので、一発でドカンと痛い一括払いを計画中(涙)
それにサーバのハードディスクと部屋のクーラのどちらが先に壊れるかなんてチキンレースもしていて非常に心臓に悪い。
で、結局のところ節約なんてまったくもって似合わないことをしている超常現象なみの今日この頃である。
なんか今日も色々と些末かつ面倒な事態が色々と………
こう経済危機が長引いて仕事もなくなって、たとえありつけたとしても日頃の要員売価よりも安く出さなければならなかったり（今までが高すぎるという噂もあるが）、仕事にありつけなくて中小企業助成金を駆使したり、某茄子なくなったり昇給無くなったりすると、今までは何も考えずにスルーしていた問題も重箱の隅をつつくかのようにチクチクと………
会社の体勢を組み直したら受託案件の考慮はすっぱりさっぱり抜け落ちているとか間抜けな事態になっているし………
資産管理上一人一台しか PC が貸与されない―――しかも型遅れのロートルノート―――とか、とても受託開発なぞ出来ないので、プロジェクトの予算で開発用機を買ったらガタガタ文句言われ、しかし開発用機を揃える申請パスは無しとか………
開発機も開発サーバも移動端末も自己資産で、しかも部下に更に２台の自己資産の開発機を貸し出し、会社資産と自己資産が混在するのはマズイからと MSDN まで個人契約して仕事を回している俺は一体どうすりゃいいんだ？
※ISMS に引っ掛かって色々とややこしいことになるだけです、合掌
え？ 見積に乗せろって？ お前、プロジェクト終わったら納品する仕入品じゃないんだから(爆)
ま、どうでもいいや。
取り敢えず今やっているプロジェクトが完遂できれば、当面の目標は達成したことになるし(爆)
後のことは後になってから考えよう。
ぶっちゃけ、もう全部が面倒くさくなったし(嘲笑)
2009年7月15日
OP25B と覚悟完了？
とうとうイーモバイルで OP25B が実施されたらしい。
数日前からイーモバイル経由での自社 SMTP サーバが利用できなくなった。
昨日と本日、実は身内の不幸があったため仕事が出来ずにイーモバイル経由でメール送信できなくなったこと自体で問題が起こったわけではなかったのだが………
明日からまた職場復帰、そうすると出先からメールが送れない問題点が浮上する。
社のシステム管理の対応は全くもって消極的で「イーモバイルから通知が来れば考える」というレベル。
「考える」であって「対応する」ですらないのが馬鹿としか言い様がない。
そもそも法人契約と個人契約では取扱が違うことも当然あるし、各々の ISP や出張先でのホテルの回線などで OP25B が適用されていたらアウトというケースも全く考慮されていない。
かといってグループウェアに業務上のメールの全てを管理しきれるだけの容量が用意されているかというとそれもアウト、個人に割り当てられた容量はたったの 50M である。
100 人も居ない会社で 50M であるっ！！ 嗤えっ！！(爆)
ま～、社のシステム管理と正面切って戦うという無駄に体力と精神力をすり減らす行為はとっくの昔に放棄した（というかシステム管理の対応を待っていたら仕事が止まる）ので、自分でどうにかする。
自宅サーバの特定のポートに届いたパケットを社の SMTP ポートに転送してしまう。
と言うのも、自宅は固定 IP アドレスを取得している契約上の配慮で OP25B の対象外となっているので、自宅サーバからの 25 番ポートは問題なく飛ぶのである。
なので、一端自宅サーバへ 25 番ポート以外でパケットを投げて、それを社の 25 番ポートへそのまま転送―――自宅サーバでの透過型プロキシ動作を実現した。
そうすると問題なく社の SMTP サーバへメールの配送依頼をかけることができる。
頑張れ自宅サーバ！！
システム管理がサブミッションポートを提供するか、俺が退職するその日までっ！！
さてさて、話は変わるが。
そろそろ覚悟完了しようかと考えている。
今まで色々とあったのをグッと我慢してきたが、いい加減に限界だ。
と言うか、馬鹿馬鹿しくてやってられない。
自分にとってメリットがあったり無二であったりすれば話は別だが、メリットをデメリットが遙かに凌駕していたり、メリット自体が実はデメリットだったり、代替策が存在してしまう現状では、我慢する意味もない。
もう裏切られて当然の希望を抱く気力もないし、自分が何かアクションを起こしたからといって小さい割には硬直化した構造を変革することは不可能であろうと思える。
そもそもそのアクションを起こすとしてそこに費やされる労力は自分の目的を遂行するのに必要な労力を確実に浸食する―――無論それは自分の本意では断じてない。
それにもう二重投資も限界が来た。
自分の目的を遂行するのに必要だったとは言え、手段を常に二系統維持する予算は正直筆舌に尽くしがたい負担だし、それを維持する方策が無くなってしまった現状ではこれ以上の負担には耐えられる筈もない。
なので、もう覚悟完了する時期に来たと考えている。
何を言っているのかって？
ま、大体分かるでしょ？
分かってもまだ口に出しちゃダメよ？
2009年7月9日
ま、予想はしていたけど
出ませんでした。
はい。
何がって？ アレですよ、アレ、某茄子(涙)
正直言うと、実は予想していた。
別に何の肩書きも持っていない平社員の自分が会社の口座の出納や、取引銀行への与信残高を見ているわけではないけど、ちょっと見渡せば第一クォータで某茄子が出せる利益は絶対に上がらないと容易に予想できた。
それはむしろ確信に近いので、某茄子をアテにした計画などは立てていなかった。
しかし予想していたとは言え現実に起きるとキビシイ。
これから想定外の修羅場に突入するということで、次の３連休に控えていた旅行も泣く泣くキャンセルしたというのに、とどめにコレであるから夢も希望もない。
と言うか、コレでは下でガシガシ働いてくれている連中に残業を指示することすら憚られる。
なんかお偉い経済学者とかが景気は下げ止まったとかほざいているけど、要は散々派遣切りだ給与カットだなんだと大騒ぎして帳尻合わせただけで、実際に景気が上向いたワケではない。
割を食ったのは労働者階級の我々で、我々が景気が上向いたと実感できるのは（本当にそんな時が来ると仮定しても）数年先から十数年先だろう。
ぶっちゃけ大企業の経営状態が数字上でなんとかなったって、実は国民生活にはほとんど影響ないのである―――悪い意味で。
それに無秩序な人員削減で生産能力が激減した製造業がすぐに勢いを取り戻せるとも思えない。
株価だけ見ていてもそれは崩壊したマネーゲームを続けているだけに過ぎないのだ。
しかし、利益が上がらなかった原因を経済危機にばかり求めてはいけない。
知人の会社（同業他社）の話なども色々と聞くけど、どうも経営者の中には今日の様な危機は全くの未経験で見当違いの対策や、確実に間違った判断をしてしまっていることもあるようだし―――業界自体は幼いからね―――、そもそも問題自体は元々あって経済危機をトリガーにして急浮上しただけというケースもある。
景気がそんなに悪くなかった時には耳を傾けなかった指摘に、その指摘が現実の物となった今になって雁首揃えて取り組んでいる―――タイミング的には遅すぎる―――なんて馬鹿げた話しもある。
しかもこの手のケースでは大概にして、現在進行形で自分達が直面している問題が実は「過去に既に指摘されていた問題であったという事実」を忘れていることが多い様だ。
流石にそんな経営層の下には居たくない(汗々)
ま～どう転んでも知人も自分も経営者ではないし、最後の最後で経営者の判断には従わざるを得なくなるわけで。
それが嫌なら会社を辞めて新たな雇い主を探すか、自らが経営者となるか、さもなければフリーエージェントでもおっぱじめるしかない。
まったくお寒い時代でやんすねぇ～
2009年7月8日
今回はメモリリークと戦いまっす！
面白い記事があった。
大型汎用機なんかつまらないぜっ！
最新技術でバリバリ構築だっ！！
とか言っている連中や、最新技術が大好きでそれをビジネスの世界に無秩序に持ち込もうとする現代の風潮に色々と思うところがあった自分だが。
なんか自分の危惧をそのまま代弁してくれたような記事である。
元々はメインフレームで構築されたレガシーシステムを短絡的に罪悪だと定義して、どうオープン系に入れ替えていくかという論調で始めたかったようだが、最終的には常々自分が考えていた「オープン系は安い」の嘘や、オープン系で基幹システムを構築する場合の予想外のリスク、「オープン系レガシーシステム」の存在などが語られている。
アルファギークでも新技術を追っかけるのも良いけど、それだけで企業の基幹業務を遂行するシステムを構築すると思わぬところで足下をすくわれかねない。
メインフレームを駆逐されるべき害悪だと短絡的に考えている技術者には一読をお勧めする。
さて、今回の本題は別にあって、PHP のメモリ管理の話である。
PHP では変数で利用されているメモリは自動的に解放される。
変数は実際には変数の実際の情報を格納しているメモリ領域への参照で、メモリ領域には参照カウンタが存在する。
最初に変数を定義した際にはメモリ領域の参照カウンタが 1 となり、別の変数からメモリ領域が参照されたりすると参照カウンタが +1 される。
メモリ領域を参照している変数がスコープから抜けるなどして解放されると参照カウンタが -1 され、それが 0 になった時点でメモリ領域も解放される。
PHP の場合、ガーベージコレクションは変数の利用停止から遅延して起こるのではなく、即座に起こるようだ。
しかし参照カウンタがうまく 0 にならないケースが存在する。
単純な話だが、循環参照が起こった時だ。
例えば、クラスＡのフィールド変数に配列を保持し、その配列にクラスＢのインスタンスへの参照を保持するリストクラスを考える。
この時、クラスＡはリストを制御する情報を保持する必要があるため、クラスＢのインスタンスへの参照を保持する―――これは当然。
しかしクラスＢの方から自分自身を保持するリストを識別するためにクラスＡのインスタンスへの参照を保持したり何かすると、ここに循環参照が発生する。
そうすると、クラスＡのインスタンスとクラスＢのインスタンスがお互いの参照カウンタを握りあってガーベージコレクションに引っ掛からなくなる。
これ、自作の PHP 基盤ライブラリであるところの Ag:PURE 2.0 に装備されるデータベース接続の抽象化ライブラリで起こった。
JDBC の様に準備されたステートメントに変数をバインドする仕組みを隠蔽し、ここに前述の例のような構造を用いたのだけど、別にリソースに割り当てたわけでもデータベースドライバ側からの参照が発生したわけでもないのにメモリに残り続ける。
結果、ステートメントを作って変数を割り当てる処理を繰り返すとメモリが一杯になって PHP が Fatal Error を吐きやがる。
HTTP 上で一回のリクエストで発生する処理が少なかったりするとメモリ上限に達する前に終わって、レスポンスの送出と共にメモリが解放されるから問題ない。
しかし CLI を利用してバッチ処理なぞ書いてみると、これがアっと言う間にメモリ上限に辿り着いてしまう。
仕方ないからステートメントを閉じる際にバインドした変数を管理するクラスのインスタンスを保持した変数を片っ端から unset してやるようにした。
ガーベージコレクションが走らないならデストラクタも走らないから、このタイミングしかない。
当たり前の話だが、ガーベージコレクションを前提とした言語はガーベージコレクションの仕様を知らないと思わぬ怪我をすることがある、ということである。
JAVA でガーベージコレクションが度々問題になるように、CLI を実装した PHP も実はガーベージコレクションを考えなければならない局面に入ったわけである。
ま～ PHP でバッチ処理を書く奴も希だろうけど(笑)
2009年7月5日
PDT 2.1 も結局使い物にならん
つい先日公開されたばかりの PHP の統合開発環境であるところの PDT こと PHP Development Tools だが………
やっぱダメでした。
糞重すぎて話になりません。
一挙手一投足全てにおいてモタモタして、とてもではないけど快適なタイピングは出来ない。
コード補間も駆使してコーディング速度を上げているというのに、コード補間させるより自前で打つ方が早いんじゃないか？ とか思うくらい、とてつもなく重い。
さっさとコーディングしてテストしたいのに、思考をことごとく妨げられて非常に苛つく。
Pleiades のせいじゃないかと疑ったけど、どうもそうでもないらしい。
PDT Project から持ってきた All-In-One パッケージを普通に持ってきて、普通に展開して、普通に使っただけで重いのだから主犯は PDT に相違ない。
と言うか、職場は Core i7 940 でメモリ 4GB、ハードディスクも SAS 15,000 回転でスワップ行ったってそんじょそこいらの SATA よりも快適だ。
自宅も同様、Xeon X5450 (3.0GHz、FSB 1333MHz) のデュアルでメモリ 4GB、ハードディスクも SAS 15,000 回転でスワップ行ったってそんじょそこいらの SATA よりも快適だ。
にも関わらず、重い。
一体 PDT 作っている連中はどんだけの化け物マシンで開発しているのだ？
さもなければ、どんだけコーディング遅い奴をターゲッティングしてるんだ？(爆)
自分のコーディング速度は決して速くない（タッチタイプも出来ないしな）にも関わらず、この自分にすら付いて来られないとなると、開発者達が本当に使い物になると考えて出したのか怪しいところだ。
Zend Studio for Eclipse も PDT ベースのハズだから、結局重くて使い物にならないんだろうし………
結局また 1.0.3 に戻る俺が居る、お粗末。
しかし PDT のやつ、このままだといくら待っても使える状態にならんのんと違うか？
5 年後のマシンだと快適に動きますみたいな、時間が解決してくれるパターンを期待しているわけじゃないよな？？
2009年7月2日
新型モバイル dynabook SS RX2 環境移行中
6月29日の深夜に東芝ダイレクトPCへ発注した新型モバイルノート、dynabook SS RX2/W9H だが。
実は7月1日の朝には届いてしまった。
恐ろしい早さである。
なので、昨晩と今晩で環境移行作業にいそいそと勤しんでいるのだが………
二晩かかっても移行が完了しない俺のモバイルって一体！？
とか思ってしまって今夜も夜が更ける。
取り敢えず未だに Vista は色々と問題が多いので、添付されているダウングレードメディアで唐突に XP にダウングレード。
色々と突っ込んでいるが、これがまた難儀である………
さて、dynabook SS RX2 だが、外見的にはぶっちゃけ dynabook SS RX1 のマイナーチェンジの感も否めないのだけど、実は見えないところで暗躍的に色々と改良されている様だ。
CPU やチップセットの更新は言うに及ばず、最大メモリの増加、重量も若干軽くなったらしい。
eSATA が増設されたのは嬉しい改善だ。
タッチパッドの位置も筐体に対して中央に配置されていた RX1 から改善され、ホームポジションに対して中央に配置されたが、これってなにげに基盤を色々と弄る必要がある大がかりな改良だったのではないかと思う。
ディスクアクセスなどの状況を通知する LED は明るく見やすくなっていて、特に SSD だとディスク I/O の音が聞こえないから状況が分かりやすいのは助かる。
なにげに気づきにくいけど、筐体の剛性が全体的に向上している感じだ。
これだけ薄い筐体なのに涙ぐましい改善だと言えよう。
あと、廃熱スロットも増設され、より熱を逃がしやすくなっている模様だ。
AC アダプタが地味に小さくなったのもモバイルとしては助かる改善。
W9H は 128GB SSD 搭載を搭載した2009 年春の東芝直販限定モデルだが、SSD 搭載によって足回りが劇的に改善され、ディスク I/O が足を引っ張らなくなった様だ。
とてもモバイルノートとは思えないキビキビ感が小気味良い。
と言うか、現行の RX1 から RX2 へファイルをコピーしていたら、あまりのアクセス速度の差に RX1 側が追い付けずにハング状態となってしまった(笑)
RX1 の SSD モデルは高値過ぎて手が出なかったが、RX2 の SSD モデルは手が届く価格帯に落ちてきたので嬉しい選択肢と言えよう。
（流石に 512GB SSD の夏モデルは手が出なかったけど）
dynabook SS RX1 は可搬性と性能を双方共に高いレベルで満足させた逸品としてお気に入りなのだが、dynabook SS RX2 はそれにさらに改良が加えられた高次元の完成度を感じさせる機体だと言える。
機動性が重要なビジネス現場や、外回りで歩き回る営業のお供として dynabook SS RX2 は非常に強力な選択肢と言えよう。
またネットブックでは満足できないヘビーなモバイルユーザも満足させるだろう。
なんにしろ、これは良い機体である。
東芝、良い仕事していると言わざるを得まい。
