勝ちにこだわる姿

今日、WBCの日本代表と西武が試合をテレビで放映していたのでみました。

正直に西武はすごいなと思いました。何がすごいかというと勝ちにこだわるところです。

それをなぜ思ったかというと、西武の攻撃で、ランナー2、3塁からスクイズをした場面です。

正直、スクイズはないなと思っているところにスクイズをしてきたからです。
多分、あのときに内野を守っていた選手もないだろうと思っていたに違いありません。

有名なスポーツ選手は遊びでも必ず勝ちにこだわり続けるといいます。

この場面でスクイズを決めてくる西武の勝ちにこだわっている姿に「あっぱれ」です。

それにしてもあの場面でスクイズを決めた選手の体に向かってきたボールをスクイズできた技術もすごいなと思います。

HAYST法は難しい?

最近、HAYST法を勉強して非常に難しいなと思います。正直私の頭では理解できないのが正直な感想です。

線点図がでてきたり、色々な数式が登場してきて、実際にどうしたらいいのだろうかと思っています。

実際に自分で具体的な事例で試したり、色々なことを調べていないので、まったくわかりません。

ただ少し調べた結果によると、自分で試して見ないとわからないなと思います。

まだまだ始めたばかりでわからないことだらけですが、少しでもバグが減ればいいなと思います。

マインドマップと原因結果グラフ

先日、+Lhacaという圧縮・解凍できるソフトを使って、マインドマップによるテストケース作成を行ってみました。

まず最初に、仕様分析から始めて、メインブランチに、ドラック＆ドロップと作成しました。そして、圧縮・解凍というブランチを作成しました。

仕様分析をしていくうちに、解凍できるファイルの種類であるけど、チェックボックスをOFFにしていると、圧縮できるという条件がでてきて、このチェックボックスの設定により、圧縮と解凍が切り替えることができるというのがわかりました。

正直、仕様書がない状態でしたので、ヘルプを見ながら作成していきました。

これは、マインドマップの書き方を間違えました。
ドラック＆ドロップをメインブランチにするのではなく、ソフト名がメインブランチにあり、その中で、設定ごとに出していくのが良かったと思います。

作成していて、AND条件やOR条件があるので、もしこのまま作成するなら、原因結果グラフの方が良かったと思います。

基本的なスタンスとして、AND条件やOR条件がある場合には、原因結果グラフを用いて、仕様の条件を調べるのには、マインドマップが有効であるなと思いました。

スタック領域とヒープ領域でのアクセス速度

パフォーマンスチューニングをしているときに、あることに気がつきました。

スタック領域は、領域がそのまま使えるの高速で処理することができる。
ヒープ領域は、ポインタアドレスから実体を見にいくので、若干速度が遅い。

実際にどういうことかというと、昔のアルゴリズムはInt（スタック領域）での比較をしているのに対して、新しいアルゴリズムでは、オブジェクト（ヒープ領域）で比較してある処理をする際に、ループ回数が多いと、かなりの違いがでてきます。

対策としては、比較する前に、Hashtableにオブジェクトを代入しておき、検索回数を、減らすことでかなり処理速度が向上しました。（実際には、IndexOfしていところをContainsに置き換えた）

パフォーマンス向上はループ回数を減らすこと

少し前まで自分が作成したアルゴリズムの性能を検証してみると、かなり遅いことがわかりました。

パフォーマンスチューニングをする必要があります。
まずは、どこの処理に時間がかかっているかを検証しました。調べると、あるメソッドのところで極端にレスポンスが悪くなっていることがわかりました。

対策として、そのメソッドの処理を変更するのではなく、そのひとつ前のメソッドで、レスポンスが悪くなっている箇所のループ回数を減らすことを考えてプログラミングを行いました。

なんと、パフォーマンスが劇的に変化しました。

作成しなおす前のアルゴリズムよりも現時点で約3分の1程度になりました。

おそらく、まだ無駄な処理をしているところがあるので、もう少し速くなると思われます。

ループ処理を変更するだけでこれだけ変化があるので、今までどれだけ無駄な処理をしていたのだろうと思います。

ドラクエ発売延期にみるソフトウェア開発

ドラゴンクエストの発売が3月から7月に変更されました。

ある程度システムテストが順調に進みそうだなということがわかっていたからリリース日を発表したと思います。しかし、上記のとおりに延期になりました。

ソフトウェア開発ではよくある話です。

なぜなら、どんな人もバグを埋め込もうと思って、プログラミングをしているわけではありません。

そもそもどこにバグがあるかを予想できていたら、最初にフィックスしているからです。また、仕様変更も頻繁に発生するので、リリース日を最初にコミットしてしまうと、デスマーチへの道まっしぐらです。

通信関連でうまくいっていないようなので、バグフィックスは非常に困難を極めているからこその延期だと思います。

この仕事をしたことがない人からすれば、なんでだと思います。したことが無いので、わからないのは仕方がないことだと思います。

ただ、みな一所懸命やっています。それだけはわかってほしいなと思います。

何年も開発をしている会社でも当たらないのだから、ソフトウェア開発の見積もりというのは当たらないと思います。

最低限のパターンを見つける

バグフィックスを早くするためには、最低のパターンでバグが発生するパターンを出さなくてはなりません。

例えば、ある特定のデータでエラーが発生するや期待した結果が得られない場合には、最低限必要なところまで絞り込まなくは、デバッグしていても非常に時間がかかるだけとなります。

そのため、最低限のデータを用意しなくてはなりませんが、これが非常に厄介です。

このデータを見つけるまでに非常に時間がかかります。

しかし、これさえわかれば、バグフィックスは早くなるし、根本の原因を特定することができます。

初心者の人にありがちなのが、こういった最低限必要なパターンを抽出することをせず、いきなりデバッグを始めてしまいます。

そして場当たり的な対応をしてしまい、わけがわからないコードになってしまいます。

そうならないためにも根気よく最低限のパターンを見つける努力を怠ってはいけません。

見つけるためにも自分が作成したコードがどうなっているかや他の人がどうやって作成しているかを理解しておく必要があります。

定期的に体を動かすと疲れにくい

今年に入ってから筋トレをしている効果があるのかは不明ですが、体が疲れにくくなってきました。

大体、木曜日くらいになると、いつも疲れがピークで、金曜日になると後1日で休みだからと頑張るといったような生活をしていました。

しかし、今年から、エクササイズホイールを使用して、ひざをついて、背筋を意識して、30～40回、ひざをつかずに、10～15回を1日置きにしています。そして次の日には、スクワットをおろすのに30秒・あがるのに30秒と計1分かけてスクワットを5～7回行っています。

これを繰り返すことで、疲れにくいからだができてきました。

元々は、お腹周りと体脂肪があがってきていることから始めました。

最初は、あまり回数をこなすことができませんでした。
だんだんと成果が現れてきて、上記のような回数をこなすことができるようになりました。

高校生の頃には簡単にできたことが今はかなりできなくなってきているので、毎日トレーニングして、夏には腹筋が少しでも割れているようになればと思います。

定期的に簡単な運動をすることで、疲れにくい体になることを実感している日々です。

ようやくゴールが見えてきた

最近、ずっとプログラミングをしていたアルゴリズムがようやくゴールが見えてきました。

後は、ひとつのパターンのテストコードが通れば、ほぼ大丈夫であろうというところまできました。

それにしてもある部分のアルゴリズムが非常に様々なパターンがあり、それを抽出するのもプログラミングすることも非常に難しかったです。

前にも書きましたが、裏紙に様々なパターンを書いて、それを実際に机上でトレースしたりしました。

今回、学んだことは複雑になればなるほど、手で書くことは思考が整理されたり、きづきを得ることの重要性です。

男の料理：ハンバーグ

昨日、息子とお風呂に入っているときに、明日どこかに出掛けたいというので、「どこにいきたい」と聞くと「ハンバーグ屋さん」というので、まだ下の息子が小さいので、家族で外食ができないので、「明日作ってあげるよ」ということから、今日、ハンバーグを作りました。

ハンバーグは何度か作ったことがありますが、毎回思うのは、難しいなと思います。なぜなら、絶妙な硬さにならないからです。

お店で食べると、硬すぎもせず、やわらかすぎもせず、絶妙な硬さになっています。

やはり、プロとアマチュアの違いですね

ただ、家で食べる分には非常に好評だったので、またチャレンジしようと思います。

それにしてもハンバーグ専門のお店って、差別化などが難しいだろうなと思います。