ヒマワリさん「クリスマス中止のお知らせ出したいねー」

だんでぃさん「そっすねー」

ヒマワリさん「じゃあ文案お願いしていい？」

だんでぃさん「いっすよー」

 

以上が、実際にすぴばる及びweb拍手ニュースとして告知しちゃった経緯です。

 

 

おいらも笑わせて頂きましたが、個人的には「クリスマスをカップルのためのイベントと喧伝するムード」が嫌いなだけなので、お子様のいらっしゃる温かなご家庭にまで中止のお知らせをお届けする必要はないんじゃないかなーと思ったんですが。この意見は以前映像配信時にだんでぃ社長に全否定されたので、今回は見守らせていただきました。

 

さて、手描き（仮）の進捗報告です。UNDO周りは（後述の調査点を除いて）無事実装成功したのですが……細かい問題が色々生じてしまったため年内リリースは見送らせていただきます。。ご期待頂いていた方々には申し訳ないです。

 

以下、毎度の技術者モードで済みません＾＾；

 

現在、手描き（仮）Flashプラグインが稀に応答不能になる問題が確認されてます。

現在疑ってる点は、ガベージコレクション（通称GC）に起因する問題ですね。

フリーズ後に何分も待つと、Flashプラグインが「デフォルトのタイムアウト時間である 15 秒を超えてスクリプトが実行されました」という警告を出して、続けるボタンを押すと直ったりするケースがあります。

現在の設計ではとにかくコードをコンパクトかつ局所的に把握できる記述にする目的で、イベントリスナに匿名関数を大量に割り当てているので、まずここが怪しい。きっちり再調査しておこうと思います。具体的には全部名前付き関数で書き直して再検証。弱参照の使いどころもよく分からないのできっちり調べ直さなきゃ（うわー恥ずかしい）。。。

……とまあ、これらのタスクがTODOに入った時点で、年内リリースは諦めざるを得ませんでした＞＜；；

 

それにしても、イベントリスナが絡み合ってる程度で数分ものフリーズがあり得るもんだろかなぁ……。

そのため、次点で実装したばかりのヒストリ管理クラスの設計を疑ってます。

ヒストリ管理クラスは、いわゆるUNDO/REDOを管理するクラスです。UNDOとひとことで言っても、「UNDO上限値を越したら古いバッファを捨てる」「UNDO時はREDOにできるようにバッファを残す（残すといっても実際にはVectorへの参照ポインタを移動する形で実装）」「UNDO後に操作されたらREDO領域を捨てる」などの若干怖い処理が目白押しです。

クラス自体は小規模なんですが、見落としがないか精査が必要なところですね。いくらテスト通っても、テストユニットに不備があるかもしれないし……。

 

最後の砦が、ブラシツールに問題がないかどうかの調査。

こちらは一から設計しなおすくらいのつもりでいます。現在ブラシはツールクラスとして抽象化設計してますが、今後多彩なツールの実装要望が出そうなところですので不安を残したくない。幸いなことに、今日の作業で必要なパラメータはシングルトンクラスに集約できたので、各種ツールクラスは徹底的にリエントラントな形に書き換えたいと思います。

ただこれは再実装コストが問題。イベントリスナとヒストリ管理側に問題がなければ、メモリーリークさえ視認できなければ今回は保留する予定です。

逆に言えば、真っ先に疑うべきところではあるけど割と自信がある部分なんですよ。使い回さなければいけないデータと、毎回破棄しなきゃいけないデータの切り分けがかなり明瞭なコード。

 

バグのないソフトウェアは存在しない、などという俗言がございます。より正確には、「バグが存在しないことを立証する方法はない」んですね。バグゼロを目指すのは、正直、交通事故ゼロを目指すのと同じ程度に難しい目標※です。。。

 

何か適切な仕組みがあれば必ず達成できる、というモノではない訳です。。

とはいえ、工夫一つでバグを激減させる手段はまだまだあると信じて疑いません。

引き続き頑張りたいと思います。

目標を一月中リリースに改めて、明日から仕切り直します。

 

バグの存在を、仕方ない物だと開き直ったら、そこで試合終了ですよね。