Hatena::ブログ(Diary)

senzogawaのNな日々 このページをアンテナに追加 RSSフィード

2004 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 12 |
2011 | 01 | 03 | 04 | 05 | 06 |
2012 | 01 | 08 | 09 |
2013 | 02 |

2006-01-26 本当の問題点

名馬がいないのか、それとも

| 名馬がいないのか、それともを含むブックマーク 名馬がいないのか、それとものブックマークコメント

 この記事( 組み込み開発フォーラム - MONOist(モノイスト))だが、優秀な技術者が増えたとして、体制が変わらなければ、結局同じことになるだろう。

 潰しが利く技術者を増やすのなら、尚更、他の分野への流出に歯止めがかかるまい。


 本当の問題は、社会的生産力を最大限に活用することを考えず、個々の生産力に問題を絞ろうとする、その姿勢にあると、常々感じている。

 この文(雑説)のような気分だ。


 狭い仕事場、細かすぎる報告要請、残業織り込み済みの工数

 どこから改善すべきかなんて、わかりきってるような気もするが、どこの業界もこんなものなんだろうか。


 ETSSそのものは、管理技術も含まれているようなので、それには期待したいし、基準の明確化は自分の位置の把握に役に立つので歓迎したいところだ。


 ただ、スキル標準が問題を解決するとか言われると、その導入だけで満足されるんで、かえってまずいこともおきるだろう。

 「高レベル技術者をこんなに集めたのに、何で遅れてるんだ!」とか。


 なんにしろ、記事のETSSに対する捉え方はちょっと気に入らない。

 残業続きなんで、愚痴になってしまったなあ・・・

トラックバック - http://d.hatena.ne.jp/senzogawa/20060126

2006-01-25 ほほう

選択肢学ってあるのか

| 選択肢学ってあるのかを含むブックマーク 選択肢学ってあるのかのブックマークコメント

 こちら(id:kmt-t:20060125#1138195783)で紹介されていたブログを覗いて見たら、このエントリ(id:epics:20060122:1137922810)で、選択肢構造の分類について記述されていたので、今回作成に関わったものがどれに当てはまるかを考えてみた。

ツリー(樹枝)型 or ホーキ(箒)型

選択肢で分岐し、その後、合流せずにさらに選択肢で分かれていくような型。

迂回路型 or チョーチン(提灯)型

途中で分岐しても必ず本流に戻る迂回路集積型。

樹枝・迂回路複合型

道筋の数を絞り、その流れに沿って迂回路を設ける型。

飛躍移行 or アミダクジ型

複数の道筋を用意し、選択肢によってその道筋が切り替わることにより、偶然の計算外の効果を狙う型。『街』のザッピングシステムも含む?

組紐型

樹枝・迂回路複合型よりもっと筋が絡み合っており、複雑な条件で筋が切り替わるもの。『彼岸花』など。

綾織型

組紐型の横幅がずっと大きくなったもの。『弟切草』など。

 うーん。多分、樹枝・迂回路複合型でいいのかな。

 用いた選択肢(分岐)そのものは以下の通りだ。

  1. 通常の選択肢
    普通に選ぶ選択肢。基本的に大きな分岐をしかける。
  2. 逓減選択肢
    見た目は普通の選択肢だが、選んだ選択肢から減っていく。特定の選択肢が終了条件。
  3. 割り込み式選択肢
    無視できる選択肢。主に迂回路型であり、パラメータの変化が多い。
  4. パラメータによる分岐
    特定のパラメータが特定の値に達した場合に自動的に別のシナリオに行く場合と、選択肢が変わる場合とがある。

 一応4つに分けてはみたものの、大きな構造としてはそこまで複雑なつくりではないはずなので、組紐型にはあてはまらないだろう。

 自分で分岐構造を組んだわけではないから、実はよくわからないが。


 選択肢学そのものについては、ググってみたが24件しかヒットせず、特に情報が無かった。

 「彼岸花」を知らないせいか、組紐型と綾織型の質的な違いがイマイチわからなかったのだが、紹介されてる本には詳しく書いてあるのだろうか。


 あと、選択肢学とは直接関係ないが、モデル検査による自動検証というのは確かに面白そう。難しすぎて理解しきれないけど。

 シナリオスクリプト言語が共通化されれば絶大な効果を発揮する、と思ったが、そういう認識でいいのだろうか。

トラックバック - http://d.hatena.ne.jp/senzogawa/20060125

2006-01-24 忘れた頃に

ことの顛末

| ことの顛末を含むブックマーク ことの顛末のブックマークコメント

 そういえば、去年の末は早めにエントリを休めてしまったので、開発日記が中途半端になっていた。

 せっかくだから、何をしたか書き残しておくことにしよう。


実装した機能

 実装した機能で特徴的なのは、以下の通り。

  • セーブデータの保存年表示
    savegame2とgetsavestrはこれに使った。
    すぐ年越しだったので、どうしても入れたかった。
  • メニューバーの上下位置変更設定
    テスト不足で前回は外したが、実装したコードがあったので楽だった。
  • バックログのスクロールバー対応
    バーの高さを出す演算で、丸め誤差によるズレが生じていて、ぎりぎりで直した。
    小数を扱えないということの影響を初めて味わった。
  • ランダム起動デモ画面
    まだ見てないものがあればそれを、全て見ていればランダムで表示するようにした。

実装しなかった機能

 実装しなかったのは、ほとんどが時間的な理由で実装できなかったものだ。

 引きずったバグがあったのが痛かった。

  • プレイヤキャラクタ情報入力の方式を変更する。
    textfield使いたかったが、いかんせんテストの暇がなかった。
  • コンフィグに「デフォルトに戻す」を入れる。
    レイアウト的に入れる箇所を決めるのが難しかった。
  • コンフィグの音量設定にスライダを追加する。
    とりあえず数値表示+トグル操作にしておいて、結局そのまま。
  • コンフィグをエクスポートする。
    テストの暇がなかった。
  • オートモード時のカーソルを切り替える。
    画像が考えられなかった。

総括

 流用箇所でモロにバグが出てしまい、何度か修正する羽目に陥ってしまった。

 落ち着いて設計しなおせばよかったものを、忙しさの余り、最初に何の根拠も無く軽視したために、ことの重大さに気づかなかった。


 冷静になるよう努めていたつもりだが、全然なっちゃいなかった。流用部分のバグにはもっと気をつけよう。


 あと、ファイル数が40余りになり、シナリオと合わせると90近くなってしまい、スクリプトファイルは合計100までしか使えないNScripterの限界を少し感じた。

 実際にはファイル連結すればいいだけなので、100を超えたところで問題はないけど。


 バグ件数は50件足らずだったが、比較対象があるわけでもないので、量については何ともいえない。

 内容的には、仕様・設計・実装で大体満遍なく出た。

 先行して単体テストをきちんとした部分は、ほぼバグが無かったので、テストの重要性をますます認識した。


 期間的には2ヶ月半くらいだけど、仕事も忙しかったので、実質1ヶ月程度だろう。我ながら無茶なことをしたな・・・

トラックバック - http://d.hatena.ne.jp/senzogawa/20060124

2006-01-16 要求と仕様の間で

「要求を仕様化する技術・表現する技術」を買ってみた

| 「要求を仕様化する技術・表現する技術」を買ってみたを含むブックマーク 「要求を仕様化する技術・表現する技術」を買ってみたのブックマークコメント

 要望指向を考えながらWebを眺めていたら、ふと「要求を仕様化する技術・表現する技術 - 入門+実践 仕様が書けていますか?」という本が目に入ったので買ってみた。

 そんなに読んでないけど、簡単に感想を書いておく。


 趣旨としては、「ちゃんと要求仕様書を作れば開発はうまくいく!だからこのノウハウを使って要求仕様書を作れ!」といったものだと思う。


 流れとしては、まず第一部で要求の仕様化に関連する問題点を挙げていって要求仕様の必要性を説き、第二部で、ではどうやって要求を仕様化すべきか、という具体的なテクニックに触れ、最後に第三部でちょっとだけ要件管理の話がある、という感じだ。


 このうち、第二部はやたら具体的に書いてくれていて、また、このレベルの仕様書はあまり書くことが無い自分には、Excelでの書き方が新鮮だったので、結構ためになる。


 ただ、著者の清水吉男さんがAgile嫌いなようで、開発方式に関してはあまり深い話が無い。

 あくまでもウォーターフォールが前提での要求の仕様化の話。

Ver.2.61新規命令の追加

| Ver.2.61新規命令の追加を含むブックマーク Ver.2.61新規命令の追加のブックマークコメント

 getspmodeとdebuglogを追加。

トラックバック - http://d.hatena.ne.jp/senzogawa/20060116

2006-01-14 冬の夜は静かだ

NScripter Ver.2.61 リリースされる

| NScripter Ver.2.61 リリースされるを含むブックマーク NScripter Ver.2.61 リリースされるのブックマークコメント

 内容は新命令追加が2件、機能追加が1件、バグ修正が2件だ。

新命令

 新命令は、スプライトの表示非表示取得命令のgetspmodeと、デバッグモードでの文字列をファイルに吐き出す命令のdebuglog。


 getspmodeは何で今までなかったんだろうというくらい、欲しかった命令だ。

 スプライト個別に表示のサスペンド・レジューム処理をするのには無いと困るんで。


 debuglogの方は、変数の衝突など、バグの要因を見極めるのに助かる。

 ステップ実行で追うのは大変だし。

機能追加

 機能追加は、複合ボタンで使うスプライトの制御文字列において、"C100-150"のような範囲指定が可能になったそうだ。


 大量に連続してスプライトを使う場合は、指定がかなり楽になる。

 "C100-150P105"のようにして、全非表示の後に一つだけ表示するというやり方をすると、汎用性が高そうだ。


 ちなみに、試してみると"P100-150"のような表示のケースはダメだったが、おそらく、あまり使うようなことは無いからだろう。

バグ修正

 あとはバグ修正だが、BBSから引用。

デバッグウィンドウをはさむと文字列を正しく取得できないバグ

・mode320,mode400,mode800のモザイクエフェクト強制終了


 それにしても、自分が使い始めた時より大分使いやすくなったな。

 その分、使いこなすのは難しくなってきただろうけど。

トラックバック - http://d.hatena.ne.jp/senzogawa/20060114

2006-01-11 ガーベッジコレクションが無くても

C/C++でもUML

| C/C++でもUMLを含むブックマーク C/C++でもUMLのブックマークコメント

 前(id:senzogawa:20050109)の続き・・・みたいなもの。

 では、「C/C++では、UMLは有効か」と問われたら、自分は「確実に有効」と答えるだろう。


 ガーベッジコレクションの無いC/C++では、メモリの解放が重要だからだ。

 先日記述した部分を考慮することによって、実装時の負荷や漏れを未然に防ぐことができる。


 自分が失敗したのは、C++UMLの習得を別々に行ったからであり、事前にきちんと考慮しておけば問題は無かった。

 また、現在出ているUML本の多くはJAVAC#を念頭においているため、その当たりの話が抜けており、C/C++向けのUMLの使い方ができなかった。


 特に、モジュール間の依存性を低くして、結合度を抑えようとした時には、メモリの確保と解放のタイミングが崩れることが多いので、気をつけたほうがいい。

 というかここで引っ掛かった。


 失敗は成功の元とは言うけれど、センスで解ければ、もっと楽なんだけどなあ・・・

トラックバック - http://d.hatena.ne.jp/senzogawa/20060111

2006-01-09 ガーベッジコレクションが無いと

C/C++とUML

| C/C++とUMLを含むブックマーク C/C++とUMLのブックマークコメント

 「実装する言語に関わらず、UMLで同じような設計を行うことができるか」と問われたら、自分は「部分的には難しい」と答えるだろう。

 ガーベッジコレクションの無いC/C++では、メモリの解放が重要だからだ。


 静的には、メモリリークを防ぐためにメモリを解放するクラス(あるいはモジュール)を明確にしておく必要があり、動的には、不正参照を起こさないよう、メモリを解放するタイミングを明確にしておく必要がある。


 特に非同期処理の場合には、イベント通知のタイミングが狂った時の考慮が漏れやすいので、注意しておく方が良いと思う。


 上記を考慮すると、C/C++UMLでの設計にあたっては、クラス図では包含が重要であり、シーケンス図ではメモリの確保・解放タイミングを明示することが重要だ。


 もし、考慮せずに設計を行った場合、そのままでは実装できないことが後で判明し、設計を見なおす羽目になることもあるだろう。

 というか、そうなったことがある。

トラックバック - http://d.hatena.ne.jp/senzogawa/20060109

2006-01-08 NScripterでSTG?

GetKey Ver0.2

| GetKey Ver0.2を含むブックマーク GetKey Ver0.2のブックマークコメント

 no titleさんから、キー取得プラグインgetkey.dllの新版が公開された。

 ジョイスティックへの対応と、IsDownのバグ修正が入ったとのこと。


 中にシューティングゲーム向けのサンプルが入っているが、NScripterシューティングゲームが席巻する日も近いか?

トラックバック - http://d.hatena.ne.jp/senzogawa/20060108

2006-01-06 NDS売れすぎ

もっと脳を鍛えるカート

| もっと脳を鍛えるカートを含むブックマーク もっと脳を鍛えるカートのブックマークコメント

 年末に『もっと脳を鍛える大人のDSトレーニング』と『マリオカートDS』を購入したので、年始からずっと遊んでいる。


 『もっと』の方は、前作は既に持っていて、漢字認識の面白さに期待して入手することにしたが、こちら(id:tonotonotono:20051229)でも言われている通り、「7」の認識が悪くなった気がする。


 具体的には、左に短く縦棒を引っ張らないと「17」とかは確実に読み違えられてしまう。

 説明でのフォントの「7」と同じ書き方でダメなのはインタフェースとしては良くないと思うが。

 改善を期待してたんだけど、少し残念。


 でも、漢字は結構汚くても認識してくれるし、漢字は好きな方なので新しいコンテンツは楽しく遊べている。

 前作は計算関連がほとんどだったので、数字ではなく文字の方が好きな人は『もっと』の方が楽しめるかも。


 『マリカ』の方はグランプリモードで全クラスを制覇できた。

 どのクラスでもスペシャルカップにてこずったが、何度も繰り返した挙句、何とか乗り切った。

 結局のところドリフトするポイントが重要と思ったが、それはレースゲーム共通なのかな。


 中々爽快感もあったが、グランプリモードは攻撃を連続で受けたりしてストレスが溜まることも多く、ストレス解消には逆効果のリスクが大きすぎる。

 タイムアタックモードの方は、その点はいいけど、微妙な空しさが残る。


 あとはWiFiに繋いでみるくらいだろうけど、AirEdgeではさすがに無理だな。

 充分楽しめたから問題は無いが。

トラックバック - http://d.hatena.ne.jp/senzogawa/20060106

2006-01-04 寒中お見舞い申し上げます

2006年始動

| 2006年始動を含むブックマーク 2006年始動のブックマークコメント

 2週間ぶりだけど、随分と久々な気がする。

 書いてない間、仕事以外ひたすら冬コミ向けソフトの開発をやっていたが、一応売りに出せると思えるものが作れたので、ほっとしている。

 覚悟していた通り、大して売れなかったけど。


 振り返って、2005年はそれなりに充実していたが、最後が締まらなかったので、精神的に追い込まれている時は活動を自制するよう今年は気をつけたい。


 とはいっても、精神的に穏やかな時って書きにくい。勢いが無いから。

 でも、自分の考えたことや感じたことをどこかに残しておきたいってことはあるので、書く量を少し増やそうかとは思う。


 仕事とか現状に対する憤懣や悲哀など、負の感情ではなく、作成や学習などによる達成や知的満足などの正の感情を利用した勢いで書くように努めることが、ブログ上での目標。




 というわけで、皆様、今年もよろしくお願いします。

トラックバック - http://d.hatena.ne.jp/senzogawa/20060104