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

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

2012年02月01日

初めてのobjective-c

音を出す方法やアニメーションについても語りたいが、その前にobjectiv-cについて少し語っておこう。
僕がobjective-cを初めて触った時は正直に言って面倒だと感じた。
例えば、メソッドの呼び出し方法だ。
Rubyの場合は
test = Test.new("引数")
test.doing("実行引数", "第二引数")
で終わりです。しかし、これをobjective-cで書くと・・・
Test *test = [[Test alloc]initWithName: @"引数"];
[test doing:@"実行引数" second:@"第二引数"];
[test release];
となる。これだけ見ても分かる通りかなり面倒くさい。
まず、この記述方法に慣れない。たとえ素晴しい言語でも、この記述量は結構なえます。XCodeがある程度は保管してくれるけれど、やはり面倒なものは面倒である。。。
メソッドの引数に名前をつけなければならないのもコードが長くなる原因である。(可読性は上がるかも知れないが、僕は少々面倒だと感じた。)

アラートの呼び出しなんて以下のようになる。
UIAlertView *alert = [[[UIAlertView alloc]
initWithTitle:label.text
message:NSLocalizedString(@"Sure", nil)
delegate:self cancelButtonTitle:NSLocalizedString(@"CANCEL", nil)
otherButtonTitles:NSLocalizedString(@"OK", nil), nil] autorelease];
[alert show];
これはFlickShootingの買い物画面で表示されるアラート部分のコードである。
一つ一つの意味がメソッドを見るだけで分かるが、とても長い事が分かる。
そして、このアラートの呼び出しは非同期処理になるらしくdelegateで処理を委託しなければならない。(delegateに関してはそのうち説明するかもしれないが、ここでは割愛)
※ちょっとびっくりしたのが、クラスメソッドからも呼び出せるところだ。その場合はクラスメソッドの「alertView」にdelegateされるのだ。この感覚は僕の中ではとても新鮮だった。

あと、謎なのが定数の切り方。
constを使うべきなのかdefineを使うベキなのか・・・。このあたりはC言語に慣れている人なら直ぐに答えが出てくるとは思うのだが、、、あいにく僕はC言語はあまり業務で使った事が無く未だに困惑している。
そして、グローバル定数をどこに切るべきかと言うのにも悩んだ。(結局各「.m」ファイルに記載・・・)

まぁ、こんな感じで半分ほどしか理解してない状態で僕はアプリの開発を進めて行くのだ。
続く。

FlickShooting
FlickShooting_icon
※是非、動作確認の為にも買ってください♩
最近の画像つき記事
[ 画像一覧へ ]

2012年01月27日

初めてのXcode

話が若干前後するが初めてiPhoneアプリを作ろうとした2011年4月頃。僕はRubyを学ぶ時に一切本を見ずにネットだけで学んで後々知識に穴がある事を知って後悔した。(この部分は知ってるけど、この部分は知らないと言う事が顕著に出てアプリの品質に影響を及ぼした。)
なので、今回は本の大切さを知ろうと思い本屋へ。
そして買った本が、

改訂2版 基礎から学ぶ iPhoneアプリ開発/林 晃
¥3,360
Amazon.co.jp

である。
本自体は悪くなさそうだが、、、(2012年の今になってもう一度読み直しているところ)
とにかくハードルが高い。
XCode4を元に書かれている為、XCode3で開発している僕にはまるでちんぷんかんぷん。XCode3とXCode4にはそれだけ差があるのだ。
で、結局のところ2週間ほど根性を見せたがこの本を読んでいても僕の作りたいものは出来ないと判断して読む事をやめた。
次は本屋ではなくGoogle先生に聞いて買ったのが、
よくわかるiPhoneアプリ開発の教科書/森巧尚
¥2,940
Amazon.co.jp
である。
この本はサクサク進めれる上に、iPhoneで出来る事をXcode3向きに書いておりとても良かった。ボタンやラベルの配置方法から位置情報の取り方や加速度センサーをUIベースとプログラムベースの2方向から教えてくれるので読み終わる頃には簡単なアプリ程度は作れるようになっているのだ。(ただし、iOS5の開発からはStoryBoradが使えるようになっているので、この本の改訂版かXCode4.2.2以降に対応しているものを学ぶ事をお勧めする。)
ただし、この本の通りに本当にやっていても伸びな無いことは分かっているたので僕は僕なりにアレンジしながらこの本に書いている事をやって行った。
終わる頃にはVBを思い出していた。
※この本の最後に他言語対応とデベロッパー登録の方法が書かれており、こちらも重宝した。)


↓↓↓勉強して作ったソフト↓↓↓


FlickShooting

FlickShooting_icon
ゲーム性はiPhoneとしては十分な出来である。しかし、個人で作っているためゲームバランスやグラフィック等の部分が荒い。

2012年01月25日

初めてのiPhoneアプリ開発する上で読むべき本達

初めてiPhone開発をすると言う事で僕はまず本を買いに行った。
・・・というのも、初めて学ぶ言語はある程度体系的に学んだ方が後々自分の身になる事を経験で知っている。だから僕の場合は、ネットで調べてちょいちょいと行うより本を買った方が最終的な効率が良いのである。


と言う事で購入した書籍がこちら。
改訂2版 基礎から学ぶ iPhoneアプリ開発/林 晃
¥3,360
Amazon.co.jp
はい。間違えました。
読んだ事がある人なら分かると思うが、、、この本はXcode4についての本なのだ。Xcode3ではない。しかし、僕はIDEなんてただのツールだしXcode4の部分をXcode3に読み替えてやれば良いと思って2週間学びました。
そして、挫折しました。

初学の場合は本当に初心者でも学べるものを選ぶべきなのだ。僕は基礎が重要と言ってるくらいなので、、、
と言う事でこちらの本を買ってみた。

よくわかるiPhoneアプリ開発の教科書/森巧尚
¥2,940
Amazon.co.jp
もう、これは王道です。鉄板です。iPhoneアプリ開発をまじめに考えている人は少なくてもこの本を2日かけて実践すべきでしょう!(Xcode4に対応した本も出ている模様です。)
正直に言って簡単です。どれもこれも本に書いている通りに行えば出来るように細かく解説が書かれています。僕はこの本を通して最低限のiPhone開発スキルを身につけてXcode3の使い方を学びました。(その後Xcode4に移行して行く様子もいずれ書きます。)

これも終わるといよいよゲームを作る準備です。この時点で僕が作りたいゲームのイメージは出来てました。なので、次に読むべき本は自ずと決まってました。
ここで重要なのは何を作るかのイメージが出来ているかどうかです。イメージがあれば作るものの最低限必要な情報が何かを判断出来ます。僕がこの時点でイメージしていたのは「自機をフリックすると弾が出て敵にぶつけるゲーム」と言うものです。
その為に考えるのがiPhone上でオブジェクトを動かす為の技術が必要です。そうなるとどんな技術があるのか?

1.X座標やY座標を意識したコードを各必要がある、
2.オブジェクト指向を使える書き方が自分に合っている。

これらを満たす為の本を探したところ、、、OpenGL(Windowsアプリ開発で言うところのDirectXみたいなもの)と言う技術がある事を知った。そして、この技術を使う事で描画を行うと言う事を知り候補に挙がった本が以下になる。

OpenGLで作るiPhone SDKゲームプログラミング/横江 宗太(株式会社パンカク)
¥2,940
Amazon.co.jp
実践iPad/iPhoneゲームプログラミング/沼田 哲史
¥2,940
Amazon.co.jp
とりあえず、両方買ったのだが読み始めたのは下の「iPhoneゲームプログラミング」の方である。その理由としては、僕のイメージしているシューティングゲームが題材になっていたのとMVCを意識したコードが書かれていたのが決め手であった。
後々書く事になるが、この本はかなりの良書だった。(FlickShootingを作る上での基礎コードは全てこの本に書いてあった。)

一方で、上の「OpneGLで作る・・・」の本はと言うと、、、これもかなりの良書だった。しかし、この本はOpneGL ESに主軸をおいて書かれている為読むにはそれなりの知識が必要になる。
OpneGL ESの基本的な概念を学べる良書なので是非読んで欲しいところだが、敷居が高いのも事実。ある程度Xcodeやobjectiv-cに慣れたら読んでみよう。描画を多々行う為には避けて通れないOpenGLに関しての本としてはまさにバイブルと言えるだろう。

では、次回からは僕がiPhoneアプリを作って行った過程を書いて行く。

↓↓↓勉強して作ったソフト↓↓↓
大体イメージ通りに出来たが、もう少しゲームバランスやグラフィックに力を入れたいところ。。。
読んだ本は上記に説明している4冊のみで「iPhoneアプリの教科書」以外はどれも途中までしか読んでいない。その程度の知識で作れるものに興味を持った人は是非このゲームをダウンロードして欲しい。
そして、レビューに良い評価を書いてくれ!(笑

FlickShooting

FlickShooting_icon
ゲーム性はiPhoneとしては十分な出来である。しかし、個人で作っているためゲームバランスやグラフィック等の部分が荒い。


【補足~今となって分かってる事~】
objectiv-cはメッセージ型のオブジェクト指向である。そのためJavaやRubyよりもSmallTalkに近い言語であり、メソッドの概念が無い。代わりにメッセージの概念がある。その為か、コード量が多くとてもJavaやRubyと言ったオブジェクト指向型言語よりコード量が多い。しばらくは慣れない言語であるが、慣れてくるとコード量の多さ以外は理にかなっていると思う不思議な言語だ。(コード量の多さは未だにきつい。コードを書くのが苦痛になるくらいのコード量である。)
また、拡張しを「mからmm」に変える事でC++でもプログラムが出来るのでC++に慣れている人はこちらで記載するといいだろう。

ちなみにOpenGLとOpenGL ESは似てるが別物である。OpenGLをモバイル向けに軽量化しているものがOpenGL ESである。

2011年12月26日

技術者にとってアジャイル開発が難しい理由

ウォーターフォールは今のビジネス速度に適さないし、開発が失敗しやすい。そのように僕はブログに書いていたし、実際そう思っていた。世の中でもXPとかスクラムとかが流行りだした頃だ。
しかし、実際にやってみるとこの難しさがよく分かった。今日はその事を技術者視点で書いて行こうと思う。
ちなみに、比較対象はウォーターフォールだ。

簡単にウォーターフォール開発とアジャイル開発の事を書いておく。(後で話がしやすいように、この記事に合わせた説明を書いておく。)
ウォーターフォールは始めに要件を固めてから開発に入る手法だ。この方法は始めに要件を固めているため、開発者に優しいと言う利点があるが後で仕様齟齬がおこりやすい。なのでプロジェクトの最後にデスマーチと言う忙しい日々が待っている場合が多い。
アジャイル開発は要件を聞いてそれをあるローテーョンで仕様策定者(使い手)に見せて行くものである。作ったものを見て舵を取れるので使い手に優しいと言う利点がある。しかしどこまでも要求が出来るため、開発も使い手もかなり忙しい。

ウォーターフォールはお客様の要求に応え難いと言う理由から、アジャイル開発が流行りはじめた。
実際、アジャイルはのれば相当気持ちの良い仕事ができる。プロジェクト期間が半年未満のものならかなり良い開発プロセスである。しかし、半年以上続くプロジェクトとなるとなかなか難しくなる。
先ほどウォーターフォールが開発者に優しいと書いたが、その最たる理由は作るものが決まっている事である。そのため、多少無茶をしても動けば良いコードが優先される。なぜなら、仕事の目的は仕様にそった動きをするものを作る事であって奇麗なコードを書く事ではないからだ。
しかし、アジャイル開発は違う。要件を聞いて動くものを作ってから、それがイメージ通りかを合わせて行く必要がある。すなわち、仕様が変わった時に即座に対応出来る汎用性が高いコードが優先される。
僕が半年未満の場合は良い開発プロセスと書いたのは、ここにある。

いつまで汎用性の高いコードを書くべきか?

これが開発者泣かせなのだ。動けば良いコードを書ける人はそこそこ居るが、汎用性に富んだコードを書ける技術者は非常に少ない。ある程度の期間を耐えれば良いのならフレームワークに頼る事で切り抜けれる。(それこそRuby on Railsはかなり汎用性に高いWebサービスが作れる)
しかし、半年位した後に「あ、その仕様ってどうなってたっけ?そこの部分ってやっぱり変えれない?」とか言われるととてもフレームワークの汎用性だけでは耐えれない。かといって、動けば良いコードを量産しているとプロジェクトが進めば進むほど開発速度が落ちてしまう。(これは、ウォーターフォールで開発して納品後や二時開発時に泣かされるので必ずしもアジャイルだけとは限らないが・・・。)

アジャイル開発で一番難しいと感じたのがこの部分だ。もう少し分かりやすく言うとリファクタリングがとても難しいのだ。
動くプログラムを作っといてと言って出来る技術者は多いが、奇麗なコードを書いてと言うと主観が入るためどれが正しいコードなのか分からなくなる。また、汎用性が高いと言う言葉もとても曖昧になってしまう。これが、アジャイル開発を行う上で一番難しい事なのだ。
動くコードは目に見えるが、汎用性が高いと言う事は目に見えずに計測もしにくいためバランスをとるのがとても難しいのだ。

僕のブログを読んでくれている人なら、これが何を示すかが分かるはずだ。
アジャイル開発はウォーターフォール以上に属人性にかかっていると言う事であり、それはマネジャーを育てる事が難しいと言う事なのだ。すなわち、プロジェクトの量産が出来ないのだ。
これを考えずにアジャイルは良いから

やり方を教えるからやってみなよ!

とは行かないのだ。


※ちなみに僕が携わっているプロジェクトはASPサービスなので、提供と開発が同時に走る為少し特殊かもしれない。しかも、プロジェクト期間はとても長い・・・。(ってか、終わりがあるのか?)
  • なうで紹介
  • mixiチェック
  • ツイートする

2011年09月06日

2011年09月05日のツイート

@nobusue: ぶさかわ / 今日のマシマロちゃん URL 2011-09-05 19:00:40 via Hatena @nobusue: WebDriver - あすかぜ・ねっと URL 2011-09-05 17:06:33 via Hatena @nobusue: Rhodes[1]Rubyでネイティブモバイルアプリを作成 - ツールで楽々!Androidアプリ開発:ITpro URL 2011-09-05 14:02:23 via Hatena ...

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

メンバー紹介

タグパネル

ランキング

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