エンジニアが発信する【SE全般】の記事を集めました

エンジニアが作る最新ITブログ トップ>エンジニアの発信する【SE全般】

2012年01月30日

さて、iPhoneアプリを作ってみる。

さて、とりあえずある程度慣れてきたので本格的にiPhoneアプリを作ってみようと思い次の本へ手を出しました。
実践iPad/iPhoneゲームプログラミング/沼田 哲史
¥2,940
Amazon.co.jp
これです。
この本を読めばとりあえず基本的なゲームが作れるようになります。
僕が作りたいゲームは

FlickShooting
FlickShooting_icon

これです。
とりあえず、買ってゲームをして良い評価のレビューを書いてくれればと思いますが(笑
このゲームを作るイメージを持って先ほどの本を読みました。

序盤はiPhoneの機能を使って出来る落ちものゲームの解説がありました。
OpenGLとかを使わなくてもこれだけのゲームが作れるという事を学びました。

さて、ここでは僕が学んだ事を説明します。
僕が一番始めに気になったのがパス。Xcodeではフォルダ(ディレクトリ)の概念がありません。グループと言う概念しか無いのでパスで悩む事が無いのです。なので、違うグループに所属しているファイルでも同じ名前を使う事ができません。(結局全て同じフォルダに入っている為)
この概念はなかなか理解に苦しんだが、慣れるとパスで悩む事が無くなるので小さいアプリでは楽だった。
⇒この概念には慣れとかないとファイル管理が上手く出来ないので、この時点で色々グループを試して慣れておくと良い。

info.plist。
これはiPhoneなどのアプリを作る上での基本設定を行うファイルです。ステータスバーを消したりアイコンやファイル名等を管理しています。iPhoneアプリを公開する上で必ず変更する必要があるものもある。
マルチタスクを有効にするかしないかもここで設定出来る。
⇒僕は必要に応じてgoogle先生に聞いて変更しているので、項目は殆ど覚えてない。

とりあえず、iPhoneの教科書を読めばXibファイルの操作に悩む事は無いだろう。画面遷移に関してもコードを見れば分かるレベルである。(XCode4.2.2からはそれすらもUIで行える。)
ここで重要なのは画面遷移のコード。音を出すコードだ。それ以外は僕の作るゲームでは殆ど使わない予定だった。
ただし、最後にアニメーションは使う事になったのでこのアニメーションのコードは覚えておくべきだろう。
(それにしても、アニメーションのコードはもう少し奇麗に書けるように出来ないだろうか?言語仕様上しょうがないかもしれないけれど、中括弧やインデントを駆使してもう少し簡単にしてくれればと思う。)

画面遷移のコード(FlickShootingでいうギャラリーを表示する場合)
GalleryListViewController *controller = [[GalleryListViewController alloc]initWithNibName:@"GalleryListViewController" bundle:nil];

controller.modalTransitionStyle = UIModalTransitionStyleFlipHorizontal;
[self presentModalViewController:controller animated:YES];

[controller release];
大抵のゲームには画面遷移があるので、このコードは覚えておくと良いだろう。
始めに次の画面のコントローラーのインスタンスを生成します。allocで生成して、Nibファイルの指定をしてます。
そのあと、画面遷移のアニメーション(UIModalTransitionStyleFlipHorizontal)を設定する。この場合はくるっと回るアニメーションである。
そして、こちらをモーダル(presentModalViewController)で呼び出してます。
そのあとのreleaseはよく分からないけど、おそらくモーダルで呼び出す時にretainしているのだと想定。

あ、あとretainとreleaseの関係については覚えておく必要がある。というのも、objectiv-cにはガベージコレクトが存在しないためインスタンスを生成(alloc)した場合は自分で解放(release)しなければならないのだ。不慣れのうちはautoreleaseと言うものが存在するのでそちらを利用しよう!

allocしたオブジェクトはその時点で参照カウンタに1がセットされている。このオブジェクトに対してreleaseを行うと参照カウンタが0になりメモリが解放される。なので、allocとreleaseは必ずセットになる。
しかし、releaseすると必ず参照カウンタが0になるかと言うとそうではない。それがretainである。このretainを使うと参照カウンタを増やす事が出来る。すなわち

alloc⇒retain⇒release

とされてもメモリが解放されない。もう一回releaseを行う必要がある。そう考えるとretainって何に使うんだろうか?と言うと、上記の例のように自分のプログラムでは使わないけど他のプログラムが使っている時にreleaseされないようにする為の仕掛けである。
(XCode4.1から「Use Automatic Reference Counting」が使えるようになったため、メモリ管理をプログラマーが意識する必要は無くなった。)

上記の例ではメインプログラムではcontrollerをallocしてその後にreleaseしている。もし、これでメモリが解放されてしまったらギャラリー画面は一瞬しか表示されない事になる。しかし、実際にはこのコードでギャラリー画面は表示されている。このように自分のプログラムでは使わなくなっても他で使っている時にメモリが解放されないようにretainを使っているのだ。ここではpresentModalViewControllerがretainをしていると想像。そしてdismissModalViewControllerAnimatedでreleaseしているかと思う。(コードは追ってません。)

よくよくコードを理解するととても単純な構造である。allocすると参照カンターが1で作成されてretainすると参照カウンターが1増える。releaseすると参照カウンターが1減って0になるとメモリが解放される。オブジェクト指向でコード書けば管理出来るが、手続き型で書くと参照カウンターの数を調整するのが至難の業である。。。

と言う事で、画面遷移のコードを覚えました。
次回へ続く。(作ったものが気になる人は是非ご購入お願い致します!)

【今だから分かる事】
IOS5で使える「Use Automatic Reference Counting」を使えばretainはもう覚える必要はもう無いんだよね・・・.
最近の画像つき記事
[ 画像一覧へ ]

2012年01月29日

[English]ABCニュース01/27 Navy SEAL アメリカ海軍特殊部隊

the secret rescue mission pulled off by that elite Navy SEAL team 精鋭の海軍特殊部隊が遂行した極秘の救出作戦 sea air land 海 空 陸 seal アザラシ

2012年01月29日

「日本海」「東海」併記 米州法案1票差で否決

「日本海」「東海」併記 米州法案1票差で否決 - MSN産経ニュース

Richmond Sunlight ≫ 2012 ≫ Public school textbooks; when referring to Sea of Japan, note that is also referred to as East Sea. (SB200)

2012年01月27日

[English]ABCニュース01/26 tax return 納税申告書

We’re now seeing his tax returns. 彼の納税申告書を見られるようになった。 return 申告書、報告書 tax rate 税率 tax code 税法

2012年01月09日

cerr と clog

cin, cout, cerr だけでなく clog ってのがあるらしい。

cerr も clog も標準エラー出力につながっているらしい。

cerr はバッファリング無し、clog はバッファリングあり。

普通に試すと、cerr と clog の違いを体感できない。

詳細不明だが ios_base::sync_with_stdio(false); を書いておくと、バッファリングの有無を体感できる。


#include
#include
using namespace std;
int main()
{
ios_base::sync_with_stdio(false);
// clog << "aaa/\/in";
cerr << "aaa/\/in";
sleep(3);
return 0;
}


clog へ出力した場合、三秒待ってから aaa って表示される。

cerr へ出力した場合、aaa って表示されてから三秒待ちが発生する。



2012年01月09日

GARNET CROW カップリング・ベストセレクション

GARNET CROWのカップリング曲ベストセレクションの発売日が決定したようです。
発売は:2012年2月29日

GARNET CROWオフィシャルサイトの情報によると収録曲予定は以下のとおりです。
◎収録曲(予定)
【DISC-1】
 Gor For It
 Secret Path
 For South
 八月の夜
 Circle Days
 Float World
 His Voyage
 lose feeling
 短い夏
 Crier Girl& Crier Boy 〜ice cold sky〜
 Flower
 nonsense
 愛に似てる
 whiteout
 hi-speed スペシャル oneday
 夕立の庭

【DISC-2】

 in little time
 Love Lone Star
 Argentina
 Holy ground 〜just like a" dejavu "arr.〜
 夏の終わりの長い雨
 彼方まで光を
 廻り道
 夜深けの流星達
 blue bird
 Jewel Fish
 未完成な音色
 一番素敵だった日
 トランス・トラップ
 Nora
 live
 たとえば12月の夜に





GOODBYE LONELY~Bside collection

GOODBYE LONELY~Bside collection

  • アーティスト:
  • 出版社/メーカー:
  • 発売日: 2012/02/29
  • メディア: CD


2012年01月08日

[English]ABCニュース01/06 photo finish 大接戦、写真でゴールインを判定するほどの接戦

historically close photo finish in Iowa. アイオワでは歴史的な大接戦だった。 squeaker 接戦、僅差の勝利、辛勝 landslide 地すべり、大勝利 caucus 党員集会

2012年01月08日

[English]ABCニュース01/05 sense of purpose 目的意識

When you exit the service, you lose sense of purpose. 軍務を離れると目的意識を失う。 sense of duty 義務感 call to duty 招集、使命を果たせという呼びかけ inner-city poverty スラムの貧困

2012年01月04日

名前付けがモデリングと言われる理由

あけましておめでとうございます。
今年も本ブログをよろしくお願い致します。
今年一発目のネタは名前の重要性についてです。というのも、本ブログを見に来る人はオブジェクト指向やポインタに興味のある人が多かったので、ニーズを考えたつもりで記事を書いてみます。

プログラムを行う上で命名が重要と言われる理由をここに書こうと思う。
さてこの名前付けがなぜ重要なのかを考えた事があるだろうか?
ぱっと考えつくのは

可読性が上がる

と言う事ではないだろうか?
まずは、その事について考えてみる。

一般的に読み難いプログラムとはどのようなものだろうか?同じコードがあちらこちらに存在しないプログラムの事だろうか?いや、違う。実はコードのコピペによって可読性が落ちる事は無い。コードのコピペはメンテナンス性を下げるだけであり、コードを読む際にはむしろ分かりやすいコードになる。(もし同じコードを一切使わずにコピペだけのコードが作れたら影響範囲が限定的のため、デグレードは発生しないだろう。ただし、他にも同じ処理を入れなければならない時に忘れる事があるだろう。)

読み難いコード、それはコードの中に意図が入っていないコードである。例えば、一つ一つの処理をメソッドや関数等を使ってまとめててもそのメソッドが何をしているかを見ただけで分からなければ結局メソッドの中を追う必要がある。
そういう意味でも何をしているかを分かりやすくする名前付けは重要になる。
そう考えると名前付けは可読性を良くする為に行う事だろうか?ちょっと例を挙げて考えてみるとする。

例えば「hoge」と「save」の二つのメソッドが合って、どちらも保存処理を行っているとする。この二つのメソッドはどちらが分かりやすいだろうか?
・・・と、これは聞くまでもない。saveメソッドは処理の中身を追わなくても保存処理だと分かる。しかし、hogeメソッドは中身を追わないと名前からは何をしているかが分からない。こう考えると名前付けは可読性を良くするためだけに存在してそうだ。
しかし、はたしてそうだろうか?

この二つのメソッドが実装されているプログラムを拡張するときを考えてみよう。例えば保存したら「メールを送信する」と言う処理を付け加えてみるとどうなるか?
「hoge」メソッドの場合はこのメソッドを拡張される可能性がある。しかし、「save」メソッドの場合は「saveAndSendMail」と言う名前に変わるかもしれないし「save」メソッドと「sendMail」メソッドの二つを用意する事になるかもしれない。
そして、そのあとに「ログをとる」と言う処理が加わったらどうなるだろうか?

「hoge」メソッド・・・データを保存してそれをメールしてログをとるメソッド

「save」メソッド・・・データを保存する。
「sendMail」メソッド・・・メールを送る。
「saveLog」メソッド・・・ログをとる。

と言う具合にならないだろうか?
これをみて何か気づくだろうか?
「hoge」メソッドのような名前を付けるとその後どのように拡張されるか分からなくなってしまうのだ。すなわち、今後の保守性が悪くなるのだ。

と言う事は名前付けは

可読性と保守性が上がる

と結論付けれる。
名前をしっかり付けるだけでこれだけの恩恵を受けれるなら是非やりたいところだ。
しかし、名前付けはやれば分かるがかなり難しいのだ。最後にその理由を書いて締めくくろう。

名前付けは、大げさに言うと企業のスローガンや選挙のマニフェストを考える事に似ている。様々な処理をしているものを一言に示して読み手に伝える必要があるからだ。「データを保存する」や「メールを送信する」なんて単純なケースは業務では殆どない。例えば「社外からのメールは社長と部長には無条件でCCで送るが、社内のメールはそのまま送る処理」のような名前をつけなければならないようなケースがたくさんあるのだ。
これだけでも難しいのだが、名前付けが難しい理由はもう一つある。

それが

名前付けの粒度

だ。
先ほどの例だと「保存してメールを送る処理」は「save」メソッドと「sendMail」メソッドに分けるケースと「saveAndSendMail」のように一つのメソッドにまとめるケースがある。これはプロジェクトによってまちまちである。この粒度が揃わないと幾ら命名が正しくても可読性と保守性は良くならない。

また、この粒度がもう少し上のレイヤーで合わないとプロジェクトの保守性はもっと下がる。例えばクラスの名前があやふやだとそれに引きずられてメソッドもあやふやなものが付けられやすい。
と言う事は、上のレイヤーの名前であればあるほど重要になると言う事だ。名前付けがモデリングだと言われる理由はここにあるのだ。

このようにならない為には始めにしっかり名前付けておき、名前を付ける粒度(ルール)を決めておく必要がある。それは、すなわちモデリングのスキルに他ならないのだ。
(ERを書く時にもこの考えが必要だが、これらについてはまたどこかで話すとします。きっと)
  • なうで紹介
  • mixiチェック
  • ツイートする

2012年01月04日

名前付けがモデリングと言われる理由

あけましておめでとうございます。
今年も本ブログをよろしくお願い致します。
今年一発目のネタは名前の重要性についてです。というのも、本ブログを見に来る人はオブジェクト指向やポインタに興味のある人が多かったので、ニーズを考えたつもりで記事を書いてみます。

プログラムを行う上で命名が重要と言われる理由をここに書こうと思う。
さてこの名前付けがなぜ重要なのかを考えた事があるだろうか?
ぱっと考えつくのは

可読性が上がる

と言う事ではないだろうか?
まずは、その事について考えてみる。

一般的に読み難いプログラムとはどのようなものだろうか?同じコードがあちらこちらに存在しないプログラムの事だろうか?いや、違う。実はコードのコピペによって可読性が落ちる事は無い。コードのコピペはメンテナンス性を下げるだけであり、コードを読む際にはむしろ分かりやすいコードになる。(もし同じコードを一切使わずにコピペだけのコードが作れたら影響範囲が限定的のため、デグレードは発生しないだろう。ただし、他にも同じ処理を入れなければならない時に忘れる事があるだろう。)

読み難いコード、それはコードの中に意図が入っていないコードである。例えば、一つ一つの処理をメソッドや関数等を使ってまとめててもそのメソッドが何をしているかを見ただけで分からなければ結局メソッドの中を追う必要がある。
そういう意味でも何をしているかを分かりやすくする名前付けは重要になる。
そう考えると名前付けは可読性を良くする為に行う事だろうか?ちょっと例を挙げて考えてみるとする。

例えば「hoge」と「save」の二つのメソッドが合って、どちらも保存処理を行っているとする。この二つのメソッドはどちらが分かりやすいだろうか?
・・・と、これは聞くまでもない。saveメソッドは処理の中身を追わなくても保存処理だと分かる。しかし、hogeメソッドは中身を追わないと名前からは何をしているかが分からない。こう考えると名前付けは可読性を良くするためだけに存在してそうだ。
しかし、はたしてそうだろうか?

この二つのメソッドが実装されているプログラムを拡張するときを考えてみよう。例えば保存したら「メールを送信する」と言う処理を付け加えてみるとどうなるか?
「hoge」メソッドの場合はこのメソッドを拡張される可能性がある。しかし、「save」メソッドの場合は「saveAndSendMail」と言う名前に変わるかもしれないし「save」メソッドと「sendMail」メソッドの二つを用意する事になるかもしれない。
そして、そのあとに「ログをとる」と言う処理が加わったらどうなるだろうか?

「hoge」メソッド・・・データを保存してそれをメールしてログをとるメソッド

「save」メソッド・・・データを保存する。
「sendMail」メソッド・・・メールを送る。
「saveLog」メソッド・・・ログをとる。

と言う具合にならないだろうか?
これをみて何か気づくだろうか?
「hoge」メソッドのような名前を付けるとその後どのように拡張されるか分からなくなってしまうのだ。すなわち、今後の保守性が悪くなるのだ。

と言う事は名前付けは

可読性と保守性が上がる

と結論付けれる。
名前をしっかり付けるだけでこれだけの恩恵を受けれるなら是非やりたいところだ。
しかし、名前付けはやれば分かるがかなり難しいのだ。最後にその理由を書いて締めくくろう。

名前付けは、大げさに言うと企業のスローガンや選挙のマニフェストを考える事に似ている。様々な処理をしているものを一言に示して読み手に伝える必要があるからだ。「データを保存する」や「メールを送信する」なんて単純なケースは業務では殆どない。例えば「社外からのメールは社長と部長には無条件でCCで送るが、社内のメールはそのまま送る処理」のような名前をつけなければならないようなケースがたくさんあるのだ。
これだけでも難しいのだが、名前付けが難しい理由はもう一つある。

それが

名前付けの粒度

だ。
先ほどの例だと「保存してメールを送る処理」は「save」メソッドと「sendMail」メソッドに分けるケースと「saveAndSendMail」のように一つのメソッドにまとめるケースがある。これはプロジェクトによってまちまちである。この粒度が揃わないと幾ら命名が正しくても可読性と保守性は良くならない。

また、この粒度がもう少し上のレイヤーで合わないとプロジェクトの保守性はもっと下がる。例えばクラスの名前があやふやだとそれに引きずられてメソッドもあやふやなものが付けられやすい。
と言う事は、上のレイヤーの名前であればあるほど重要になると言う事だ。名前付けがモデリングだと言われる理由はここにあるのだ。

このようにならない為には始めにしっかり名前付けておき、名前を付ける粒度(ルール)を決めておく必要がある。それは、すなわちモデリングのスキルに他ならないのだ。
(ERを書く時にもこの考えが必要だが、これらについてはまたどこかで話すとします。きっと)

エンジニアが作る最新ITブログ トップ>エンジニアの発信する【SE全般】

メンバー紹介

タグパネル

ランキング

エンジニアが作る最新ITブログ DODA