墜落日記 - 2009年3月の墜落
2009年3月30日
ひたひた………来る、きっと、来る、ひぃ～っ！？
修羅場の足音がひたひたと迫ってくる………
来る、きっと、来る、絶対、来る………ひぃ～っ！？
夜道を歩いていたら街頭の薄暗い灯りの下に鮪の尾ヒレをむんずと片手に掴んでぶら下げつつもう片方の手に血糊の付いた出刃包丁をひっさげつつ無言でサイドチェスト風味にポージングする筋骨隆々で黒いブーメランパンツ一丁のボディビルダーの兄貴の爽やかすぎる白い前歯が餃子のよう形の笑顔に遭遇したような恐怖感が、ひたひたと迫ってくる。
自分でも書いていて全然シチュエーションが想像できないのだが、取り敢えず、ひぃ～っ！？ とムンク作「叫び」―――ムンク作「叫び」であって「ムンクの叫び」ではない、ふひひ―――な感じで奇声を発しておく、うけけ。
昨日、寝る前にちょっとだけ SO4 に復帰して、ワンダリングダンジョンに潜ったら、なんか凄いことが起こった。
ま～なんだかんだでじっくりゆっくり殺り込んでレイミ嬢の最強装備と思われるメデューミスティックボウまでは作っていて、ATK+18% のファクターを付けまくったおかげで ATK が最大値の 9999 まで行っていたりするのだが、気が付いたら絶対無理だと思われていたアーツ『最大ダメージ 99999』をスルッと偶然にクリアしてしまった。
しかもアルマロス不完全体を相手に、である。
なんかアーツ『最大ダメージ 99999』があったおかげで諦めていたレイミ嬢のアーツ 100% 攻略が見えてきてしまった。
あとなにげに面倒なのが『マヒ状態の敵撃破数100』だと思うが、これはマヒ属性付けた武器でちまちまと狩っていくしかない。
しかし時間を掛ければチキンな俺でも問題なく出来る範囲だ。
駄菓子菓子、時間が無くなった。
本格的になくなった。
なにげに現実逃避してサクッとやってしまうかもしれないが、なんにしろ時間がない。
でもアーツ 100% の特典は欲しいな～とか地味に………（ダメ人間）
こちら、サクッと忘れていたのだが、NOD32 の更新時期が来た。
そうか、コレってば 1 年間だったな～とか呆然と通知メールを眺めてみる。
色々と背景があって会社資産の NOD32 ではなく自己資産の NOD32 を 5 ユーザーパックで維持しているのだけど、流石にコレの更新を怠るわけにはいかないよな………
しくしく………
でも、なんか Windows Server 2003 に対応した 2.7 系列は今年の 12 月でサポート切れてしまうらしい。
最新の 3.0 は Windows Server 2003 に対応していないし、サーバ対応バージョンはサクッと値段が跳ね上がる。
（パッケージではダメで、ライセンス製品でしかサポートしない）
コレって要するに値上げだよなっ！？ → Canon IT Solutions
2009年3月27日
Photoshop CS4 と intuos4 の組み合わせが熱い？
久しぶりに職場で徹夜こいた。
ま、自宅ではままあることなのだが、職場じゃないと出来ない仕事で徹夜こいたのは久しぶりである。
なんかも～精神錯乱と書いてナチュラルハイと読むという感じで、結構イライラと一晩過ごしてしまったが………
ま、そんなことはどうでもいい。
まずは intuos4 である。
なんか方々のサイトで intuos4 が紹介されているようだ。
全然チェックしていないし、ここ何年も絵自体を描いていないので今更なのだが、今回は Photoshop CS4 と組み合わせるとキャンバスをグルングルンと回せるらしい。
ついに来たよコレっ！？
タブレットで絵を描く際にどうしても困ってしまったのがキャンバスの回転である。
紙で描く場合には手の動き、手首のスナップの可動範囲に対して無理がかからないように紙をグルングルンと回すのが通常であるが、今まで Photoshop でこれをやろうとするとデータ自体をぶっ壊す物理的な回転しか機能がないから精々 90 度単位でしか回せなかった。
（90 度単位の回転なら理論上データが壊れる心配はない）
で、Photoshop CS4 になってとうとうデータを壊さない見た目だけのキャンバスの回転をサポートしたわけだが、intuos4 を利用すると更にペンから手を放さずにこれを操作できるということらしい。
これはなかなかである。
ちょくちょくと絵を描いていた当時なら間違いなく飛びついていたに違いない。
と言うか何気に欲しいし Photoshop CS4 と intuos4 ………
こちらは実際に購入したのだが………
久しぶりに Delphi の本を購入した。
-
DELPHI 2009 HANDBOOK - Delphi 最新プログラミングエッセンス
著者 Marco Cantu
訳者 藤井 等
監修 エンバカデロ・テクノロジーズ
判型 B5変型判、464頁
税込価格 5,250円（本体 5,000円）
ISBN 978-4-87783-222-3
去年の秋口に発売された Delphi 2009 の最新機能を詳解する本である。
今回の Delphi 2009 は Unicode サポートやジェネリクスサポートなど、かつて無い大規模な言語拡張が行われた戦略的なバージョンであり、これら新機能を詳解するこの本は一読をお薦めできる。
2009年3月23日
あまりにも唐突ですが ai sp@ce ってどうなってんの？
あまりにも唐突なネタなんだが、大分前にドワンゴなんかが立ち上げた ai sp@ce って今一体どうなってるんだろう？
ぶっちゃけちゃうと、全然情報が露出しないから存在自体を忘れてしまいそうになる。
そもそもニコニコ動画アカウントが必要という時点で個人的ポリシーから触れることが出来ない世界ではあるのだけど………
（見た瞬間にエロゲ版ハビタットと思った自分は………げふんげふん）
そもそもキャラクタへの拘りって公式ストーリあっての拘りであって、キャラクタとストーリの不可分の関係をぶった切ってキャラクタだけを自立させようとした時点で本末転倒というか、ファン心理が分かっていないネタだよな～とか思ってしまったけど。
最初から公式ストーリが存在しない初音ミクなんかの盛り上がりとは全く別の次元で考えないといけないような気はするんだが、そこんとこどうなってんだ？
ま、前述の通り個人的ポリシーから触れることが出来ない世界なので、確認することも出来ないのだけど。
（自分は基本的に 2ch 界隈の匿名前提の世界が生理的に無理です）
と、ま～下らない話はどうでもよくて。
本日は日本がアメリカに勝ったようで、決勝戦に駒を進めたのは目出度いことである。
もちろん生中継を見ることは出来なかったし再放送も見ることは出来なかったが、ワケ分からない誤審もなく、日米ともに試合後の会見に至るまでスポーツマンシップに則った試合だったようである。
ダイジェストで見る限りでは、日本の侍も、アメリカの英雄もそれぞれ非常によい仕事で戦い抜いたようだ。
これなら勝っても負けても気分の良い試合と言えよう。
やはりスポーツはこうでなければならない。
次の決勝戦はまたスポーツしてるんだか戦争してるんだか分からない気分の悪い試合になるのだろうが、ここまで来てしまったからには日本にはスポーツマンシップのある態度を貫いてもらって、スポーツとはかくあるべきという姿を精神的後進国に見せつけて頂きたいわけである。
ま、日本の侍は改めて望むまでもなく当然そうするでしょうから心配はしていないのだけど(汗々)
2009年3月22日
１ヶ月掛けてやっと SO4 クリア
昨月の 23 日からプレイしていた STAR OCEAN 4 だが、本日やっと一通りクリアした。
仕事を持ち帰る日々が続いていたのでホントにちまちまとしか進めていなかったから、やっとである。
ま、本編自体は少し前に終わっていたのだが、クリア後の殺り込み要素のひとつである七星の洞窟までは取り敢えず進めてクリアとした。
その後にワンダリングダンジョンとかあるのだけど、流石にソコまで殺り込み要素に付き合っていられん。
ちなみに、途中のイベントで強制退場した時以外は基本的にレイミ嬢をリーダにして操作していたので、尻を眺める時間が非常に長かった。
これでフィールド移動のキャラクタもリーダになる仕様だったら一体何時間レイミ嬢の尻を眺めていたことか(爆)
取り敢えずレイミ嬢とミュリアは LV.255 でカンスト。
エッジ、バッカス、リムル、メリクルは LV.200 でカンスト。
エイルマットまではカンストさせても良かったんだけど面倒になって放置、サラは多分―――いや絶対―――精神的に耐えられないからガン無視。
それに LV.200 超にするためには個々人のアーツを 50% まで引き上げてレベルキャップ解除しないといけないので、使い込んでて勝手に解除したレイミ嬢は別として、ミュリアを解除したまでやって面倒になって力尽きた。
基本的に殺り込み要素には付き合いきれない根性無しの自分である。
それでもレイミ嬢で闘技場のシングルバトル優勝してタトローイの石像はレイミ嬢のガッツポーズに変えておいたし、チームバトル優勝も果たしている。
ま～よしとしよう。
レイミ嬢の尻と太股で充分に元取ったし(爆)
あ、あとアーツの達成率を上げて追加されるレイミ嬢のバトルボイス、SURPRISE ATTACK 時のセリフの困り加減が妙に可愛いです。
話変わって WBC、次の試合で日本が米国に勝てば決勝ではまた韓国とやり合うことになるワケだけど………
ハッキリ言って、もう韓国と戦う姿は見たくないのが本音。
なんか韓国と戦った時って勝っても負けても気分悪い。
そりゃ～日本には勝ってもらいたいと思うのは当然なんだが、韓国戦の後は勝敗に関わらない後味の悪さが残るのである。
ぶっちゃけるとナショナリズムがスポーツの世界に色濃く滲み出すぎているのが後味が悪い最大の理由である。
ナショナリズムが不要とは言わないがナショナリズムがスポーツマンシップを越えて出てくると、それはスポーツの名を借りたタダの戦争であってスポーツではないわけである。
つまり韓国とやっている時はスポーツの試合を見ている気分にならないのである。
マウンドに太極旗を突き刺す姿を見てスポーツマンシップを感じろと言うのは無理だろう？
自分はむしろ即座に全員射殺したい戦場のような気分すら感じる。
だから、韓国なんて精神的後進国とは少なくともスポーツの世界では関わりたくないのが本音なのである。
こんな気分を味わっているのは自分だけだろうか………？
2009年3月20日
Internet Explorer 8.0 が出ても糞面倒な状況は少しも改善せず
Microsoft の Internet Explorer 8.0 正式版がダウンロード公開された。
IE 8.0 検証用の仮想マシンに導入してちょこちょことテストをしてみたが、下逸とはとても信じられない程にブラウザとしては充分まともに仕上がっている。
コンシューマの IE ユーザなら素直に乗り換えても良いだろう。
しかし、ビジネス分野ではコレでまた検証しなければならないバージョンがひとつ増えたに過ぎないことに絶望感。
Windows XP と同様に Internet Explorer 6.0 の時代が長すぎて、実はまだまだ淘汰されていない。
IE 6.0 のリリースは 2001 年 9 月だが、IE 7.0 のリリースは 2006 年 10 月、自動更新で配布されるようになったのが 2008 年 2 月である。
少なくともバージョンアップに 5 年間はかかった計算で、この間に IE 6.0 による環境は広く深く浸透してしまった。
ビジネスアプリケーションを考えるとコレが絶望的な期間の長さである。
IE 6.0 が浸透していた期間が長すぎた上に IE 6.0 にはへんなバグが数多く放置されていたため、悪い意味で技術的な蓄積がなされてしまっている。
そして、一般的にシステムの寿命は 5 年程度と言われるが、2006 年カットオーバのシステムが IE 6.0 前提であったとすれば（そして改修がされないとすれば）これは少なくとも 2011 年までは利用される。
その間、そのシステムのポリシーは IE 6.0 前提を脱さないから、IE 6.0 前提で駆使された悪い意味で技術的な蓄積は 2011 年まで引きずられてしまうのである。
これが Microsoft がいくら頑張って IE 7.0 や IE 8.0 で汚名を返上しようとしても、しぶとく汚名が生き続ける要因のひとつである。
しかも正しく歪んだ資本主義の権化である強欲なウォール街の金融ヤクザ共が引き起こした世界的な経済危機で、世界のシステム更新は何年も遅れるだろう。
実にタイミングが悪い。
そうすると、通常まともに多くのユーザをサポートしようとする開発者は IE 6.0 以降は必須として動作検証を行うだろう。
即ち、IE 6.0、IE 7.0、IE 8.0 の 3 つのバージョンである。
しかも Microsoft が IE 6.0 の支配的立場にあぐらを掻いていた間に Firefox や Safari などの標準準拠度の高いブラウザが登場し、無視できなくなってきた。
更に Google の阿呆が Chrome でちょっかいかけてきて面倒な状況を引き起こしている。
結局、開発者は都合 6 種類のブラウザでの動作検証を強いられるわけである。
これは Netscape Navigator / Communicator と Internet Explorer を両立していた当時とさして変わらない手間である。
ま、利用者をある程度コントロールできるのであれば Safari と Chrome 辺りは無視するかもしれないけどね。
既に Opera はガン無視だし。
順当に考えれば、IE 6.0 と Firefox の双方で同時並行して開発と検証を行うのが第一段階だろうか？
IE 6.0 と Firefox の挙動は恐ろしく違うので、ある程度開発が進んでしまってからどちらかで動作確認を行おうなどと考えると手痛いしっぺ返しを喰らうことがある。
特に Firefox で作ってから IE 6.0 で検証すると絶望感が味わえるから、この 2 つは最初から同時並行して開発と検証を行う必要があるのだ。
しかし Firefox で動作する物は割と IE 7.0 や IE 8.0 でも動く。
なので第二段階として IE 7.0 と IE 8.0 での動作検証を行う。
これが開発と動作検証の現在もっとも妥当な手順ではないだろうか？
どちらにせよ面倒な話しである。
とにかく、IE 7.0 が出ようが IE 8.0 が出ようが IE 6.0 でばらまかれた環境汚染は簡単には払拭できないのが純然たる事実である。
流石にいい加減そろそろ勘弁して欲しいものである………
そう言えば、大量の公的資金の投入を受けている AIG で高額報酬が支払われていた事件が最近大騒ぎのようだが。
要はこの米国式の報酬の在り方が今日の金融危機を引き起こした直接のトリガなのである。
自分達が役員をしている間になんとしても収益を上げて大量の報酬と退職金を巻き上げて後は知らないよと立ち去っていく、言うなればハイエナ優遇の報奨制度だ。
だから自分達が在籍している間の短期的な儲けを狙うことだけを目的に、たとえ刹那的で崩壊すると分かっている手段でも躊躇わず使う。
そこには本来銀行や会社が持つべき公共に益する社会性などは微塵も存在し得ない。
米国系の企業や財団が突然福祉事業に手を出したら疑ってかかるべきだ。
きっと彼らは発芽しない実を付けるように品種改良した種を売って歩くような姑息極まりない手段をとってくる筈だ。
これが米国式資本主義の正しい姿だ。
オバマが大統領になろうが変わることのない、正しく歪んだ資本主義だ。
いい加減に世界は目をさまさなければならない時期に来ている。
2009年3月18日
《ななみ》はやっ！？ はやーっ！？
現在進行している仕事で、Windows Server 2008 を利用する予定であることは、以前に VMware Server 2.0 の導入のゴタゴタやその後の「おそっ！？ おそーっ！？」の大騒ぎで書いたが………
今回、仕事用ワークステーション《ななみ》に仮想マシンを移動させてきて、動かしてみた。
仕事用サーバ《ぷれすとにあ》は元々自宅で使っていたワークステーションを転用した物で、今となってはスペックは大分低いと言わざるを得ない。
では最新の Core i7 では！？ と思い立ったわけである。
（ちなみに vmx ファイルに mainMem.useNamedFile = "FALSE" の設定を追加してスワップファイルの作成を抑止したので当初よりはずっとレスポンスは上がっている）
しかし、仕事用サーバではメモリを 6.0GB 積んでいて PAE 有効にしているので 2.0GB のメモリを奢っていたが、仕事用ワークステーションでは 32bit 版の Windows XP がホストとなるのでソコまでのメモリは割り振れない。
なのでメモリを 1.0GB にして、そのかわりと言ってはなんだが CPU を 2 つ割り当ててみた。
ストレージは SAS の 15,000rpm ドライブに配置。
すると………
《ななみ》はやっ！？ はやーっ！？
なのである。
異様に速いのである、仕事用ワークステーションに放り込んだ仮想マシンが。
弩ビックリなのである。
Windows Server 2008 の CPU 依存度が極端に上がったのか、VMware Server 2.0 の CPU 依存度が上がったのか正確には不明だが、とにかく驚愕に値する速度改善なのである。
ぶっちゃけ開発はこっちだな。
とか思ってしまうのである。
バリバリ開発するような状況における Core i7 の能力は何気にズバ抜けているのかもしれぬ。
（コンシューマで利用する分には Core 2 Quad 辺りの方がコストパフォーマンス的にも適している様だけどね）
ただ、仕事用ワークステーションはどういうわけか ICH10R 側で RAID 構成すると SAS からブートできないなどという変な制限があるので、SATA 側で RAID を組むことを諦めている。
なので大容量のワークストレージが接続されていないという現状がある。
基本的に開発用データベースなどは仕事用サーバに振ってしまうから大丈夫だと考えていたのだが、場合によってはそれなりに高速で大容量のワークストレージを接続する算段―――例えば SATA RAID カードの増設―――を考えないといけないかもしれない。
自宅サーバの新調も NAS の追加もしたいんだが………(涙)
2009年3月14日
PHP で任意精度の演算を - 完結編
PHP で任意精度の計算を行うクラスの開発を行っていた自分だが、なんか実装が冗長的であることに気づいた。
と言うか、GMP 値で整数部分と少数部分を別個管理する必要性など全くなく、1 つの GMP 値の下位の桁が小数点以下だと考えれば良かっただけなのである。
つまり、任意精度整数値である GMP 値で、"1234567890123456789" という整数値を管理して、精度を 4 とか保持しておけば、下位の 4 桁は小数点以下であると認識することが出来るので、"123456789012345.6789" という任意精度の固定小数点数として処理できる。
それだけである。
こうすると四則演算もそう難しくない単純な実装で行うことが出来る。
精度が違う除算はやや厄介だが、それだけである。
なんか、当然と言えば当然だが、連続した徹夜紛いの戦いをしていると、そんな単純な事にすら思い至らないらしい。
で、結局出来たクラスは JAVA で言うところの BigInteger と BigDecimal に相当する。
精度の考え方も JAVA から輸入。
こうすることで JAVA プログラマも抵抗なく利用できるはずだが、ぶっちゃけ物理計算的な有効桁数を導入するのが面倒だっただけである(爆)
んで、データベース抽象化ライブラリとの連携も実装し、Oracle や PostgreSQL との任意精度数値のやりとりが可能になった。
（他のデータベースとのドライバはまだ書いてない、ぶっちゃけ必要な物から書いた）
さて、マニュアルは全然書けてないけど、そろそろ実戦で利用する事になるので先行して公開してしまわないといけないな………
2009年3月10日
PHP で任意精度の演算を
PHP は歴史的に異常とも言えるほどデータ型が弱い。
ま、言語が既に破綻しているという噂もなきにしもあらずで、今更データ型が云々感ぬん言うのもどうかというレベルではあるが、なんにしろ異常とも言えるほどデータ型が弱い。
整数型は 32bit 整数しかない。
64bit 環境でコンパイルすれば 64bit 整数しかないことになるのだろうが、どちらにせよ固定だ。
で、小数点が入ると途端に float、浮動小数点となる。
しかも演算結果が整数型に入りきらないと勝手に浮動小数点になってしまうと言う熱い仕様まである。
熱すぎて火傷しそうである。
だから、大きな桁の計算や、計算誤差が許容されない通貨計算など、非常に難儀することになるわけだが、これを解決するために PHP では任意精度の値を計算する方法として、大別して2つの方法がある。
ひとつが BCMath 任意精度数学関数で、これは常に値を文字列として取り扱い、任意精度の計算を可能としている。
実はコレで大概のことは出来てしまうはずなのだが、データ型が文字列である関係上、不意の事故が起こりやすい。
要は任意精度数値としての文字列型なのか、単純に例えば HTTP リクエストで渡された直後故の文字列型なのか、はたまた整数型と文字列型の区別が旨く出来ない初学者故の文字列型なのか区別できないので、予期せぬ不具合の温床となりやすいわけだ。
もう一つが GNU Multiple Precision (GMP) ライブラリを利用する任意精度数学関数で、これは値をリソースとして保持しており、パース処理が少ない分だけ計算自体は速いだろうが、如何せん整数値のみである。
大別して2つの方法があるとは言え、どちらも一長一短で、コレだっ！！ というソリューションが存在しない。
なので、作ってしまうことにした。
前述の GMP 関数群で利用する GMP 値で整数部と固定小数部を整数値として管理、固定小数部の精度と符号を別途で管理する、合計 4 つのパラメータで任意精度の固定小数点数を構成するクラスを作ってしまおう。
JAVA であれば丁度 BigDecimal の様な構成だ。
（ま、BigDecimal の内部がどのように実装しているのかは知らないけど）
ついでに BigInteger に相当するクラスも作ってしまおう。
思い立ったが吉日、取り敢えず昨晩にバタバタとコーディングして PHP 版の簡易 BigDecimal と BigInteger クラスを実装してしまう。
色々と計算を通して簡単なテストをして、取り敢えず使えそうなトコロまで明け方には完成した。
あとはこれをデータベース抽象化ライブラリと連携して使えるようにしてあげないといけないけど………
2009年3月8日
MSDN 更新と Shuriken 2009 導入
今月末に迫った MSDN 契約期間の満了を目前にして、とうとう契約更新に踏み切った。
ま～契約更新するか否かを悩んでいたわけではないので、踏み切ったとは即ち銭払ったということなのだけど(汗々)
かねがね言っているとおり、個人用、仕事用の開発環境二式をほとんど全て自己資産でまかなっている自分としては、デスクトップ OS にサーバ OS、開発環境やデータベースがインストールし放題の試し放題というのは非常に有難いわけで、2 年契約で 12 万円というのも実は安い買い物と言うことになる。
（12 万円なんてサーバ OS 一回で吹っ飛んでしまう金額である）
自分は別にオープンソースでなければ嫌だとか、コピーレフトでないと許せないとか原理主義なこと息巻いているわけではなく、オープンソースもコピーレフトもプロプライエタリも適材適所に選ぶのが妥当だと至極順当に考えているので、その選択肢の準備として MSDN 契約自体には抵抗はない。
少なくとも今後もサーバ OS にデスクトップ OS が試し放題、環境作りたい放題というのは得難いレスポンスを与えてくれるのだ。
ま、下逸に金払うこと自体に抵抗がないとは言い難いけど、これで今後の 2 年間は安泰ということになるわけだ。
しかし先日も書いたが、ホントに eOpen のサイトの管理ツール群は全く持ってデザイン自体を完全に間違えている程に使いにくいしワケ分からないしナンセンス極まるデザインである。
そもそも MSDN の契約自体が複雑怪奇なのに、そのツール群まで複雑怪奇にして、ツールを使った結果が全く予測できないというのはアプリケーションのデザインとしては返品物の木偶の坊である。
少なくないライセンス料を取っているのだから、少しは努力して欲しい。
ライセンス料を支払ってまで Microsoft 製品を維持している顧客の身にもなれってもんだが、ライセンス料を払っちゃったカモは今後も仕方なく継続するだろうから放っておけって事なんだろうか？
なんか借りる時はお茶付きケーキ付き美人の受付付き、返す時は背中が賑やかな血で血を洗う自由業の皆さんに囲まれる闇金みたいだよな(笑)
話は変わるが、メーラを JUSTSYSTEM Shuriken 2009 に乗り換えてみた。
まだ体験版だけど、製品版が出たらダウンロード販売で購入予定。
（もちろん ATOK 2009 は導入済みだ）
自宅では Becky!2 を使っていたが、Becky!2 自体にあまり文句はないのだけど、日々増え続けるスパムメールの処理にどうしてもフィルタが追いつかない。
バージョンアップすると誤検知率も上がって、スパム扱いされてゴミ箱に飛んでいったメールの中からスパムではないメールをサルベージするのも負担になってきた。
職場では Thunderbird だが、なにかの条件が揃っている時にフォルダの最適化をすると送信箱から下が消えてしまって涙目になるとか、正直使っていて怖い部分があった。
あと複数アカウントの管理が馬鹿すぎて複数アカウントを維持するのが前提の自宅に導入するのは無理があったとか、標準ではシステムドライブ以外にメールを保存できないとか、色々と面倒な部分もあった。
なので、自宅も職場もまとめて Shuriken 2009 に地殻変動させてしまった。
ま、同時に使わなければ複数端末にバカバカ放り込んでも違反にならない素晴らしい柔軟性の ATOK 使用許諾契約と違い、Shuriken 2009 の使用許諾契約は 1 台のコンピュータにインストールする権利しかないから、少なくとも 2 ライセンスは買う必要があるだろうけど。
ちなみに、データ移行は Becky!2 からの移行に関しては全く問題はなかったが、Thunderbird からの移行は非常に難儀した。
前述の通り Thunderbird は標準ではメールデータをシステムドライブのユーザフォルダに強制的に格納するが、これではビジネスで使っていると簡単にシステムドライブを圧迫してしまう。
（Linux 系だと "/home/ユーザ名" の下なのだろうからちゃんとパーティション切ってあれば問題は無いだろうけど、Windows ではそうはいかないってこと少しは考えろ）
なので、アカウント単位でメール保存のフォルダを別ドライブに変更していたのだが（最初はリバースポイントで繋いだのだがトラブルが多くてやめた）、Shuriken 2009 のメール変換ツールはこれを追いかけきれない。
なので、一時的に色々と設定を元に戻して、標準インストールだとこうなっている筈だという環境を作り出してやって、なんとか移行できた。
もう一つ厄介だったのはアドレス帳の変換だ。
何でか知らないが、しかも法則性もなんにも分からないが、姓と名が入れ替わったり入れ替わらなかったり、組織名が引き継がれたり引き継がれなかったり、とにかく中途半端にデータをぶっ壊す移行しかしてくれない。
いくらなんでも製品版に近い体験版で一発通せば丸わかりのバグを放置しているとも考えられないので、Thunderbird 側のデータの持ち方が滅茶苦茶なのかもしれないが、これが結局一件一件目視で修正する羽目になった。
と、ま～いくつかのハードルを乗り越えて Becky!2、Thunderbird から移行した Shuriken 2009 だが、今の所操作性の違和感以外で特に目立った問題は無い。
細かいところではちと気に入らない部分はあるが、使っていくウチに色々と試して、文句は JUSTSYSTEM に要望という名で送っておくことにしよう。
しかし、阿波徳島と手裏剣か。
手放せない物として着実にメイン環境へ食い込んでいる JUSTSYSTEM が憎いぜコン畜生。
2009年3月4日
Vista をスルーした人間が Server 2008 を弄ること自体が間違いの始まりか
未だに Windows Server 2008 を満足に環境設定できないで四苦八苦している。
単純なインストールだけなら最初の VMware Server 2.0 への移行に関連する手間以外は何とかなったが、いざ運用レベルを想定してミドルウェアを放り込んでみたりスクリプト書いてみたりすると途端につまる。
もともと Vista を完全スルーしている自分なので、一番邪魔なのが UAC である。
UAC の発想自体は、管理ユーザと言えども普段は制限ユーザで利用しつつ必要に応じて権限を昇格するという至極真っ当な物だが、その実装は世間一般が騒いだようにかなり馬鹿なようだ。
そもそもコマンドレベルで権限昇格するための手段が存在していないのが問題だ。
バッチファイルで色々と処理を書いている際に、唐突に UAC の認証画面が出ずに例外発生するケースなんかが非常に厄介。
権限がないとダメだと分かっているのなら、そのプログラムを実行する前に一時的に権限昇格すれば済むはずで、Linux 辺りだとバタバタとコマンドを打っている最中なら su でユーザ切り替えたり、シェル実行中なら sudo で実行したり出来る。
しかし Vista 系列の UAC はコマンドプロンプト自体を管理権限で起動しないと二進も三進もいかない。
起動するのが exe なら最初から管理権限で起動する設定があるようなのだが、bat だとアウトなのである。
PowerShell だと上手い回避方法があるのかも知れないが………
Windows Server 2003 は不覚にも割と良くできたサーバ OS だと思ってしまった。
GUI 管理に慣れているユーザには必要充分な管理ツールが―――やや分散はしているが―――揃っているし、Windows 2000 Server の様に初期状態でフル機能が稼働していたりはしていない。
DirectX などのマルチメディア系の機能は有効にするのに苦心惨憺する程にちゃんと停止しているなど、クライアント OS の持つ無駄に CPU リソースを食い尽くす機能が軒並みストップされている。
サーバの環境がちゃんと揃うまでファイアウォールで着信拒否しているのも地味に感心した。
ハードウェアにかかる負荷も高くなく、割とバランスが取れているサーバ OS だと感じた。
だが、Windows Server 2008 は第一印象最悪である。
Vista から導入された UAC を基盤にしたセキュリティ設計は、ガチガチにしようとする余り勇み足で間違えてしまった感じに思える。
マルチメディア系の機能や Aero 機能もどうやら簡単に導入できるようで、Vista を無理矢理サーバ仕様に仕立て上げた急造感がある。
クライアント OS は XP から Vista への移行が難航しているが、もしかしたらサーバも 2003 から 2008 への移行に難航する事態に遭遇するかもしれない。
ServerCore も思ったほどではなさそうだしな。
（比較対象が Linux や UNIX では勝ち目無いけどね）
というわけで、3 月末以降の出荷分から Windows Server 2003 のプリインストールはしないとか、ダウングレードは別途費用とか抜かしたらしい NEC の営業を締め上げてやりたい衝動と戦っている日々である。
というか、Windows Server 2008 の販売開始って去年の 2 月末だよな？
前バージョン切り捨てするの早すぎないか？ NEC さんよ！？
だいたい Windows Server 2003 のサポート期間って 2013 年まではあるはずだろっ！？
2009年3月3日
さらに VMware ESXi を導入、暇が無くて七海に会えない
昨日は Windows Server 2008 を試験するために VMware Server 2.0 の導入に踏み切った自分だが、今度は VMware ESXi を導入した。
現在仕事用ワークステーションとしての職務は Core i7 を核とする《ななみ》に移管され、先代の仕事用ワークステーションは職務から解放されている。
しかし先代の仕事用ワークステーションの次の職務が見付かっていないのも事実で、どうせなら試験環境として生き延びてもらうために VMware ESXi を導入しようと決意したのが経緯。
Windows Server 2003 を放り込んで VMware Server 2.0 というネタもあったのだが、先代の仕事用ワークステーションは Prescott コアの Pentium IV 3.2GHz と今となってはそう速くもない CPU であるわけで、ホスト OS にリソースを割かれてしまうくらいならハイパーバイザを乗っけた方がよかろうという判断が働いた。
VMware ESXi の導入は至極順当で全くトラブルなく完了。
ホスト機側に用意される BIOS 画面とさして変わらないイメージの設定画面で最低限度のネットワーク設定などを行って、残りは VMware Infrastructure Client から操作するイメージだ。
先に VMware Server 2.0 で VMware Infrastructure Client の使い勝手には大分慣れていたので、この辺りも問題ない。
VMware Infrastructure Client は VMware Server 2.0 と VMware ESXi に繋いだ時でインターフェイスの細かなところがちゃんと変わって、双方を違和感なく管理できる様だ。
VMware は仮想化ソリューションと言うよりもインフラソリューションと言った方がもはや妥当であるが、VMware Infrastructure Client の統一されたインターフェイスは―――微妙に間違っているにしても―――重要になってくるだろう。
今の内に慣れておくのも、自宅サーバ環境を仮想化する際の礎として無駄にはなるまい。
で、試しに VMware ESXi 上に Windows Server 2008 を放り込んでみると、何というかホスト OS が存在しない分だけパフォーマンスはよい感じ。
ま～ CPU が単一コアの Hyper Threading のみなので、２つ以上の仮想マシンを立ち上げると途端に動かなくなるだろうけど………
ちなみに、先日 Windows Server 2008 が異様に重い旨を書いたが、VMware Server 2.0 の仮想マシンに対する設定値も関係していたようだ。
まずメモリ。
[ホスト機] の [構成] タブの中に [ハードウェア] の構成がある。
この [メモリ] の [プロパティ...] を選択すると“追加メモリ”という設定があるので、これを「全ての仮想マシンのメモリを予約済みのホスト RAM に組み入れ」を選択する。
そうすると VMware Server 側のメモリのスワップが抑止され、ディスク I/O が減るようだ。
ただし、これはホスト OS 側にちゃんとメモリを積んでおかないとかえって凄いことになりかねないことに注意。
64bit 版のホスト OS でどかどかメモリ積むか、32bit 版でも PAE で 4.0GB 超を認識する OS（Windows Server 2003 なら Enterprise Edition 以上）のご利用を。
次ぎにハードディスク。
こちらは個々の [仮想マシン設定の編集] から開く設定画面でハードウェアの中からハードディスクを選択。
すると“モード”という設定項目があるので、これを「独立型」にし、かつ「通常」にするとスナップショットの作成に影響を受けなくなり、ディスク I/O が減るようだ。
※もちろんスナップショット機能を使いたいなら設定しちゃダメだ
これだけで大分速くなる。
ま、それでも Windows Server 2008 の重さの根本的な解決にはならないんだけど、気休め程度には変わるから実運用環境でないのならやってみる価値はあるだろう。
※実運用環境でこれら設定を行う場合には充分に吟味のこと
………って、ああ、くそ。
余裕がある時ならまだしも、同時多発テロが起こってる最中にインフラ調査なんて時間のかかる作業はマジ面倒くせぇ。
しかも試験環境向けに会社資産を調達するなんて確実に間に合わないから、また個人資産でゴリゴリやる羽目になるし………
そんなこんなで糞忙しい状態に突入しているため、STAR OCEAN 4 は停止中。
レイミ嬢の尻を眺めている暇もない。
もちろん、せっかく届いた CHAOS;HEAD NOAH に至っては全くの手付かず。
“超妹”七海ルートを堪能する暇もない。
鬱だ、とても、鬱だ。
2009年3月2日
Windows Server 2008 と VMware Server 2.0、同時多発テロと萎える気力、今度の仕事が終わったら
唐突だが、いや、本当に唐突だが、Windows Server 2008 に挑戦している。
本音は Windows Server 2008 なんて枯れていないサーバ OS には手を出したくない。
しかし遙か彼方昔に書いた見積が当然あるべき見積前提条件の見直しもないまま見積有効期限とスケジュールだけがスライドした結果、いざ動き出してみたら Windows Server 2003 でのハード調達が難しくなってしまったとかいう間抜け極まる事態に遭遇したのである。
（と言うか、ホントか？ クラサバ市場にでも出向いて確認したろか？）
で、困るのが動作検証である。
ハッキリ言って見積前提条件を引っ繰り返すのだから追加工数請求したろかとか思いつつ、でもそんなことしたらこの御時世食いっぱぐれる現実とかもあるわけで、仕方なく動作検証を行う。
だが、非常に困るのはハードウェアの余剰はないということであるわけで、仕方ないので仮想環境に放り込んでしまおうかと思うわけである。
で、VMware Server Console を起動してゲストを作ろうとしたら………無いのである、Windows Server 2008 が。
現在利用している VMware Server は 1.0 系最新の 1.0.8 だが、どうも Windows Server 2008 は 2.0 以上かららしいのだ。
無理すりゃ動きそうな気もするが、動作検証を取る目的からするとちゃんとやりたい。
仕方ないので VMware Server 2.0 をダウンロードしてみる。
しかし現在稼働している仮想環境を上手くマイグレーション出来ないと、現在同時多発テロを起こしている様々な案件でシャレにならないことになるので、壊していい環境でマイグレーション試験をしてから実環境をバージョンアップ。
VMware Server 2.0 は 1.0 系と比すると色々と管理系の機能が拡充された替わりに、VMware Web Access なんて変な物導入して間違えたとしか思えないユーザインターフェイスを提供している。
しかも VMware Web Access の TOMCAT が普通に開発用の TOMCAT とポートがぶつかる様なので、VMware Web Access を容赦なく止めて VMware Infrastructure Client を導入。
VMware Infrastructure Client も VMware Web Access の代替インターフェイスを前提としているためか間違えたとしか思えないユーザインターフェイスが節々にあるが、VMware Web Access はマシだろうと言うことでこれ一本で行くことにする。
で、早速 Windows Server 2008 Standard Edition をインストールしてみるわけだが………
Vista ベースってことで先に気付いてしかるべきだが弩エラク糞重い。
Windows Server 2003 ならストレス無くサクサク動いている仮想マシンで、Windows Server 2008 だとガタガタと馬鹿みたいにレスポンスが悪いのである。
VMware Server を 1.0 から 2.0 に上げたせいかとも思ったが、Windows Server 2003 のリモートデスクトップでのレスポンスは大して変化していないところを見ると、Windows Server 2008 自体が重いようなのだ。
どう考えてもちょっと弄れば Aero が動きそうな GUI が糞重いようにも思えて VMware Tools を導入してみるがさして変わらないし、VMware Console ではなくリモートデスクトップで繋いでも重い印象は拭えない。
一瞬 Server Core でも入れてやろうかという気にもなったが、結局 Server Core では何も出来ないことが分かりきっているので、サーバなのに無用な GUI を使わざるを得ない。
ハッキリ言って Windows Server 2008 はイケてなさ過ぎである。
これは R2 を待つなりしたほうが実運用環境ではベターなのではないかとマジで思う。
そもそも初期から Service Pack 1 が当たった状態で出荷されたらしいのも馬鹿である。
Windows Server 2008 はまだ出たばかりで評価期間を出ていないという認識の方が妥当かも知れない。
というか昨晩から本日深夜までかかって出た第一印象がコレだから気力も萎える。
この後に SVN や PostgreSQL、Apche + PHP や IIS + PHP の動作検証などやらなければならない検証は目白押しで、追加工数請求したろかという本音が喉元まで出かかっているのをなんとか飲み込んでみるわけだが………
こんなことやってると同時多発テロ捌ききれないのが明白だよな。
2004 年の夏に突入した５ヶ月連続 200 時間残業とかが再来する危険性が本格化してきた感じである。
今度の仕事が終わったら思い切って全部を投げ捨てて IT 屋から離れたろうかな、マジで。
ま、自分に他の能があるとも思えないけどな………
2009年3月1日
そんな物よりも、むしろ
《白い悪魔》高町なのはの次の DD は既に受注受付を開始しているという本末転倒なことやってます、ボークス。
次の DD は天元突破グレンラガンよりヨーコとニア、らしい。
元ネタ知らんし、元ネタ知らんと面白みのないデザインだし、ヨーコに至っては DDDy 素体だしで、限りなく濃厚なスルーなのだけど。
商品詳細の発表が４月中旬から下旬というスケジュールで先行受注受付って、そりゃキャンセル期間を設けるという当たり前のことはしているにしても、随分と思い切ったというか何というか………
要は「天元突破グレンラガンのヨーコとニア」という単語だけで飛びつく連中の数を想定しやすくして生産調整かける狙いでもあるのだろう。
そんな物よりも、むしろ商品詳細が公開されている《白い悪魔》高町なのはで完全受注受付した方が売上稼げると思います。
しかも３月２２日のドルパ京都６の前に現金入金させれば年度末に間に合います(爆)
ドルパ京都６では会場即渡し限定分と前金で完全受注して、受注受付分は５月発送とかすれば生産計画も立つでしょう。
（もっとも納品が完了していない時点で勘定としては前受金だろうけど）
この御時世、オタク共の財布の紐も堅くなってきているわけで、確実かつ計画的に現金化できるスケジュールを立てていくべきだ。
変に限定戦略を採ると需要を取りこぼすばかりか、転売屋に無用な利益を上げさせてボークスの悪名ばかりが上がる結果になるし、かといってスタンダードにいつでも入手できるモデルの拡充は不良在庫管理を強いられる可能性がある。
なので、今後は完全受注生産方式に変えて生産計画の見える化を測るのが肝要かと考えるが、どうだろう？
