日記、というよりは雑記、もしくは愚痴

自分一人ならギリギリ何とかなりそうという自信がある。
彼一人でもギリギリだろうが何とかなるだろうという確信がある。

さてここで自分は彼と一緒に挑まなければならなくなりました。
この場合、一体どういう評価になるでしょう?
なんと不思議な事に「これはちょっと無理があるのではなかろうか?」という評価になります。
単純計算1+1=0.7で1/3です、相当ですね。

ぶっちゃけていえば、自分には人を使う才能がないって話。

プログラマーとしてソロでアプリ作成する仕事が回ってきたのが約一週間前
一人で書く前提で一人用のスケジュールを立て、内部の構想や実装実験を終えてようやく完成できそうな見通しが立ったのが昨日。
そんな自分に急遽”彼”という援軍がつき、丸一日かけて概要説明すらままならずにため息つきつつ帰宅したのが今さっき。
で、得たのが上記の結論。

おそらく彼の方がコーディング能力があり、他人に指示するのも上手いでしょう。
ならばなぜ自分が仕切る立場なのかといえば、彼は短期間しか関われないから。
ならいっそ彼に丸投げしてしまえばいいという話なのですが
そんな方法を選べない程度に自尊心(納得できない)と責任(失敗した時が怖い)があるのが難しい話なわけです。
(この辺かなぐり捨てて生きられたら幸せなんだろうなぁと常々思う)

自分は集団開発向いてない、と諦めるなり
就職半年未満の新人にこんな振り方をする上司が悪い! と責任転嫁するなり
まぁなんとかなるでしょ、と現実逃避するなり
色々道はありますが、当分は生真面目にがんばる方向で何とかできないか試行錯誤する。
というか、今ここで出来なかったら今後ずっと出来ない気がするので意地でもがんばる。

とりあえずはスケジュールの練り直し、タスクを同時進行できる形へ切り直し、内部構造を誤差なく伝えるための資料作成などなど
あーもう、プログラマーなのにコード書く時間よりその他に割く時間のほうが多いってどういうことだよ……
コード書かせろ!!!!

th123_ai(仮)の進捗報告その21+α

同日中に二回も更新するのは計画性がないのか、生産力があるのか、単に目立ちたがり屋なのか。

th123_ai.zip@ver0.90c
・is_card_use、my_spell、my_cardが晴嵐時でも通常通りの値を返していた不具合の修正
・内部的にいくつかの環境変数の処理方法を変更
・get_card_cost2において、本来であれば-1を返すべき場面で-2を返していた不具合を修正
・非想天則の極光時にweather_delayが正常に動作していなかった不具合の修正

AIManager@ver0.87b
・0.87aでは表示更新してもダウンロード済みフラグが更新されていなかった不具合の修正

晴嵐関連はよく見たら一部(というか大部分)は漏れていたという話。
晴嵐中は最初っから取れなくするつもりだったので、仕様変更ではなくバグ扱いしたけど、仕様変更の扱いの方が良かったかな……

内部的に~は前回言っていた変更。
結局キャラクター依存のデータはキャラクター情報管理クラスにメソッドつけて管理させる事にしました。
デザインパターン見て回ってみた結果、コード分散と冗長性だったら分散を選ぶ傾向があったのでそれに倣っただけですが。
これでmyとenemyが同じ値になるなんてバグを作りこむ可能性はかなり低くなったはず。

get_card_cost2のバグは、単純に曇天だったらget_card_costの返り値を-1するという頭の悪いコードで
get_card_costが-1返すと、そのまんま-1して-2が返っていたという……
晴嵐調査中に見つけました、よかったよかった。

極光も上と同じく晴嵐調査中に(ry
原因は非想天則で極光の番号が変わったから。
ver0.80の時点で直したつもりだったんだけど、うーむ。

ダウンロード済みフラグは単に実行順間違えて、画面更新→DL開始というケアレスミスしていたせい。
順番直して修正。

そういえば、そろそろ忙しくなりそうなフラグです。
というよりはデスマったおかげで最近暇だっただけとも言うけど。

th123_ai(仮)の進捗報告その20

AI関係ない事をやるからと宣言をやめた途端に開発が滞った、なにを言っているのか(ry
やっぱりあれものすごく効果あったんだな。

th123_ai.zip@ver0.90b
・enemy_hitstopが常にmy_hitstopと同じ値になっていた不具合の修正

一個ぐらいあるだろうなーと思っていたらやっぱりあったmyとenemyの取り違えバグ。
コメントの報告で発覚したバグで、差分を追ってみたら0.80からあったバグらしいという。
いや、本当にもうすいません……

内部的に緋想天or非想天則から値を取得する部分と、それをluaに突っ込む部分って独立してるんですよね。
そのせいで名前をつける部分が冗長になっていて、両方変更したつもりで片方しか変更できていなかったわけです。
キャラクター情報管理クラスにluaを更新する処理を一部つっこんでしまえば冗長性が減ってこういうミスはなくなるけど、lua操作が分散して面倒な事になりそうだし
うーむ、どうするかなー

宣言その7

普通に休日してました。
気の緩みってやーね。

・fflagsとaflagsの詳細調べ
・AIManager起動時に画面更新されていない不具合の修正
・AILibrary開発開始

aflagsとfflagsは普通に調べてもわからなそうだから、今度はきちんと逆汗してがんばる、うん。

Ruby拡張ライブラリの罠

前回の通り、ここ数日Ruby専用DLLである「拡張ライブラリ」なんてものに手を出しているわけですが
割と呆然とする問題に遭遇したので書いてみる。

djpeg.soのコードを弄っていたら突然「Segmentation fault」に遭遇。
コードミスかと思ったがどうにも原因が掴めない為、最小再現コードを書いてみることに。


#include "ruby.h"
#include <stdio.h>
__declspec(dllexport) void Init_djpeg(void) {
	FILE *fp = fopen("bug_test.txt","w");
	fclose(fp);//->[BUG] Segmentation fault
}

で、上記のコードが最小再現コード。
仮にエラーするとしたらfopenに失敗してfpがNULLで、それをfcloseしようとして~という場合が考えられますがそうではありません。

百聞は一見に如かず、ということで説明する前にこちらもご覧ください。


#include "ruby.h"
#include <stdio.h>
__declspec(dllexport) void Init_djpeg(void) {
	FILE *fp = fopen("bug_test.txt","w");
	rb_w32_fclose(fp);
}

これは最小再現コードとまったく同じ機械語にコンパイルされます。
つまり、fclose関数が得体の知れぬrb_w32_fcloseなる関数に置き換わり、さらにその中でエラーしている、というわけです。

上記のような気味が悪い現象に陥っているのはruby.hから#includeされているwin32/win32.h中で「#define fclose(f) rb_w32_fclose(f)」されているせい。
自分の常識では標準ライブラリ関数を#defineするなどまともなプログラマーがする事とは思えませんが、今は置いておいて話を進めます。

で、肝心のrb_w32_fcloseの実態ですが、驚くべき事にどこにも見当たりません。
msvcrt-ruby18.libとのリンクを外すとリンクエラーしたのでこの中にあるか、もしくはmsvcrt-ruby18.libと関連づいているdllファイルの中にあるようです。
ですが、通常この実装はきわめて危険です。
なぜなら、標準ライブラリ関数の実装は仕様で定められているわけではなく、いつ変わってもおかしくないからです。
つまり、コンパイラが変われば動作が変わることもありえます。
なので基本的に標準ライブラリ関数をDLL中で使わない、使うにしても内部で完結させて使う形にするのは必須であり、リンク元と連携する事を前提に専用ハンドルを渡しあうなど正気の沙汰ではありません
最低限、コードに出して一緒にコンパイルするか、FILEやfopenなどといった関連部分全てを置き換えるかするべきでしょう(どちらも危険である事は変わりませんが)

というわけで、libをコンパイルしたコンパイラと手元のコンパイラでfcloseの実装が同じ事を前提として組まれたライブラリによって起きた問題でした。
ruby本体のソースコードまであさったわけじゃないのでrb_w32_fcloseが具体的になにをやっているのかは知りませんが、fopenやfwriteを置き換えていないところを見るに動作とは関係ないもののようなので無視してコードを組むことにします。

ちなみに、「#include “ruby.h”」後に「#define rb_w32_fclose(f) fclose(f)」と書いてやればfcloseを元に戻せます。
不安ならwin32.hから直接該当のコードを削除してしまっても構わないでしょう。

うーん、rubyのこの辺はまっとうなメンテナついてないのかなぁ

djpeg.so

いい加減zipだけ放っておくのはどうかと思うので
特に外部と関係ないものだけでも説明しておこう第七弾
(出来立てホヤホヤじゃね?とか、外部と関係ありすぎじゃね?って突っ込みは禁止)

djpeg.so@ver0.10
Jpegを他の画像形式に変換するRubyの拡張ライブラリ。
色数変更やらグレイスケール化やら地味に色々あるけれど、それは単に他所様のライブラリを使っているから。
自分がやったのはRubyの拡張ライブラリ形式にする部分だけ。

ネット上で友人に「th123_aiのDLL化なぞして遊んでるw」って言ったらなぜかRubyの拡張ライブラリを作る流れになっていた、なにを言っているのか(ry
まぁ楽しかったからいいけどね!
ちなみに、作成理由はexerbなるRubyでGUIアプリを作れるライブラリ(環境?)を使うと標準のjpegライブラリが使えないから、ということらしい。

最初はdllで遊ぶのは息抜きのつもりだったのに気づいたら4時過ぎですってよ。
ハッハッハ、明日起きれるかしら……w

新しい事に手を出したくなる病

というわけで、唐突にDLLを本気出して作りたくなった。
一応HelloWorldなDLLを作ったり、DLL乗っ取り用の偽DLL作ったりしたことはあるけど、実際DLLとして使い物になる物作った事無いんですよね。

といっても、作りたくなっただけで具体的な目標があるわけでもないので、手軽にth123_aiをDLL化してみようと思う。

th123_ai(仮)の進捗報告その19

開発難度<ドキュメント整備難度
3時間もかけたのに全然進まなかったよ!

th123_ai.zip@ver0.90a
・iniのPlayerの設定が1か2以外のとき、強制的に1P扱いするはずが場合により2P扱いしていた不具合の修正
・ゲームパッド使用時、動作側検出処理を微修正

一つ目は2以外のとき全て1として扱う、という処理のはずが1以外のとき全て2として扱う、になっていたという話。

ゲームパッド使用時の動作検出が場合により動かないという報告がちらほらあがっているのですが、手元ではまったく再現しないため原因がわからず。
ゲームパッド判定を緩くしてゲームパッドぽい程度でも識別するように変えたけど効果があるかは不明。

あとdocument.txtの整備を少々。
本当に少々だけどね……


萃香のAIがあがっていたので嬉々として起動してみたが動かない……?
あれ、AIManagerかth123_aiのバグか? でも紫AIとか問題なく動くしなぁ

宣言その6

A実装→B実装→Aバグ修正→C実装→Bバグ修正→D実装だいたいこんな流れだけど、実装前にバグ修正しろよって思うけど直らない。
前回でもバグ修正より上に新規実装きてるし。

・エラーリポート内容の削除が動いてないので直す
・fflagsとaflagsの詳細をのせる
・ゲームパッド使用時に1P/2Pが反転する事があるらしい不具合の調査

上から順にサーバーバグ修正、ドキュメント整備、th123_aiバグ修正とリリース作業必要なさそうなフラグ。
逆に言えばリリースという大義名分がないのでまたツールスレに出せないフラグでもある。


23:30追記:
・ゲームパッド使用時の自動検出挙動を調整完了。
色々試してみたけれど反転する事態に一度も遭遇せず、コード的にも特に問題は見られない。
これは環境依存くさい?
というわけで、脳内で問題ない範囲でパッド検出を緩くしてみた。
これで多少怪しい場合でもパッド扱いしてくれるはず。

23:50追記:
・エラーリポート内容の削除が動いていない不具合の修正完了
単にアップロード先間違えて一個古いCGIが動いていただけで(ry