晴読雨読＠エンジニアライフ

実践テスト駆動開発 Steve Freeman、Nat Pryce（著） 和智右桂、高木正弘 (翻訳) 翔泳社 2012年9月 ISBN-10: 4798124583 ISBN-13: 978-4798124582 4,410 円（税込）

■「実践テスト駆動開発」ーー諸君、これがTDDの実践だ！

　TDDは広まりつつある。しかし……。

　アジャイル開発を行う上で、必須といってもいいプラクティスの1つに「テスト駆動開発・TDD」がある。このTDDのバイブルである「テスト駆動開発入門」をKent Beck氏が世に出してから、10年が経った。その間に、欧米では、すでにアジャイルがメインストリームとなった。日本でも、多くの諸先輩方が実践を続けていくなかで、ようやく広まってきたところだ。TDDを学ぶイベント「TDD Boot Camp」も、毎回キャンセル待ちの人が数多く出る人気イベントとなっている。

　日本でも、TDDに対する裾野はだいぶ広がっているのだろう。しかし、いざ実際の仕事でTDDをやろうとすると、いくつもの壁にぶち当たる。イベント駆動型クライアントアプリケーションの場合、データベースが絡む場合、マルチスレッドの場合、サードパーティのコンポーネントを使う場合。あまりに壁が大きいため、挫折してしまった人も少なからずいるだろう。かくいう私も、こうした壁を前にして、心が折れた経験を持っている。

　そうした、悩めるTDDerに向けて書かれた本が、本書「実践テスト駆動開発」である。本書は、世界中のアジャイリストが10年の歳月をかけて積み上げてきた、“TDDを行う上での壁”に立ち向かう術を教えてくれる、テスト駆動開発の奥義書である。

■そもそもTDDとは何か

　Wikipediaによると、

　プログラムに必要な各機能について、最初にテストを書き（これをテストファーストという）、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。

とある。

　では、TDDをすることで、どういった恩恵があるのだろうか。本書では

　システムを開発する際には、TDDを採用することで、実装（「正しく動くか？」）と設計（「適切な構造になっているか」）両方の質についてのフィードバックが得られる。テストを先に書いて開発することで、投入した労力による恩恵が二重に得られるのだ。

とある。つまるところ、TDDをすることは、設計と実装を小さなスケールで絶え間なく繰り返すことで、正しいソフトウェアを作っていくことに他ならない。

■立ちはだかる壁を内包したアプリケーションを、TDDで育てていく

　では、実際にTDDはどういった形で進めていくのだろうか。本書のサンプル「オークションスナイパー」というサンプルアプリケーションの開発内容を一部紹介していく。

　まず行うのが、アプリケーションの全体像を考えること。必要となるプロトコルや、状態遷移、扱う機能について洗い出す。いきなりテストコードを書くのではないのだ。何をしなければいけないのか。どういった技術基盤の下に行うのか。そうしたアプリケーションの設計を行う必要があるのだ。

　そうしてアプリケーションの設計をした後に行われるのが、「動くスケルトン」と呼ぶものを作ること。これはシステムで必要となるコンポーネントを網羅した形で一つの機能を、エンドツーエンドテストーーユーザーインターフェイスからサーバとの通信を経て、結果が出るまでーーとして成功するものとして構築したものである。

　「オークションスナイパー」システムでいうと、ユーザーインターフェイスやスナイパーコンポーネント、オークションサービスとの通信を網羅した形で一つの機能をTDDで実装するとしている。

　このとき、オークションサービスは実際のものを使わず、同じように動作させることのできる仮想サービスを用意して行う。

　いわば、アーキテクチャの検証である。考えたアーキテクチャが正しいかどうかを検証するのだ。こうしてアーキテクチャの検証を終えた「動くスケルトン」に一つずつ機能を追加していく。

　「オークションスナイパー」システムは、最初偽のオークションサービスとコネクションを行い、オークションの終了を見届けるだけの機能から作成を始めている。そこから一つづつ機能を追加していく形で、入札を行ったり、新しい商品を追加できるようにしていっているのだ。

　もちろん、テストコードを書き、それが全て成功するのを保つようにして追加していくのだ。このようにして、正しいソフトウェアを育てているのだ。

　実際のアプリケーションをTDDで開発していくのにここまでやる必要があるのかと、私は圧倒された。しかし、ここまでやるからこそ正しいソフトウェアを育てていけるのだろう。ウォーターフォール型開発で最後にテストを行なうことで、バグが吹き出して苦しい思いをする。それに比べれば、こちらの方が、開発は大変ではあるが、安心して開発ができるように思う。

■すべてのTDDの難問に対する解はここに

　この「オークションスナイパー」のサンプルには現れていない、TDDをする上で陥りやすい罠や立ちはだかる壁はまだ多くある。こうした難問に対しても、本書は解を示している。

　例えばデータベースを扱う際のTDDはどのようにして行えばいいのか。永続データの消去をテストの開始前に行うのだ。整合性制約があるので、テーブルから行を削除する順序を一つにまとめ、行うのがよいとしている。

　トランザクションを必要とする場合はどうすればいいか。トランザクション管理を行うオブジェクトを抽出し、そのなかでユニット・オブ・ワークパターンを用いればよいとしている。

　他にもマルチスレッドでのTDDや非同期処理でのTDDなど、「こういう場合のテストはどう書けばいいんだ……」という、TDDerの悩みに本書は応えてくれるだろう。

■TDDを学び、本書を携え実践しよう

　残念ながら、本書はこれからTDDを学ぼうとする人が読むには敷居が高いだろう。初めてTDDを学ぶならば、やはりKent Beck氏の「テスト駆動開発入門」を読み、実際にコードを打ち込んで、体験する必要があるだろう。もちろん、TDD Boot Campへ参加するのもいいだろう。

　そうやって、TDDを学んで実際に使い始めると「こういう場合どうすればいいんだ……」という場合が必ず訪れる。そのときこそ、本書はあなたの力になってくれるだろう。私もまた、本書を携えてTDDを実践していこうと思う。

ステートフルJavaScript ――MVCアーキテクチャに基づくWebアプリケーションの状態管理 Alex MacCaw （著）、 牧野 聡（(翻訳） オライリージャパン 2012年6月 ISBN-10: 487311554X ISBN-13:978-4873115542 2940円（税込）

■JavaScriptを堅牢に扱いやすくするための本

　JavaScript関連の本を読むときに気を付けなければならないこと。「この本は、どの立ち位置なのか？」「何が言いたいのか？」を知ること。

　これらをきちんと理解して読まないと、とんでもない回り道をするはめになる。サーバサイドからクライアントサイドまで、JavaScriptがカバーする範囲は幅広いからだ。

　さて、本書の立ち位置はというと、カルーセルやアコーディオンのような、見た目を変化させるjQueryプラグインの紹介は一切ない。ユーザーインターフェイスを求めている人向けの本ではない。

　サブタイトルには「MVCアーキテクチャに基づくWebアプリケーションの状態管理」とある。ぼんやりとでも、この意味が分からなければ、読み解くことは難しい。ここでもあえてMVCの説明はしない。MVCの話が出るということは、「フレームワークの解説か」と思いきや、それも違った。もう少し細かいパーツの世界、フレームワークを構成する部品についての話である。

　つまり、JavaScriptを堅牢に扱いやすくするための本だと思えばいい。本書は、「フレームワーク」という大きな世界観を構成する小さな部品について書かれている。これは、JavaScriptで世界を築くための道しるべとなる。

■目次

• 1章　 MVCとクラス
• 2章　イベントと監視
• 3章　モデルとデータ
• 4章　コントローラと内部状態
• 5章　ビューとテンプレート
• 6章　依存性の管理
• 7章　ファイルの操作
• 8章　リアルタイム Web
• 9章　テストとデバッグ
• 10章　アプリケーションのデプロイ
• 11章　 Spineライブラリ
• 12章　 Backboneライブラリ
• 13章　 JavaScriptMVCライブラリ

　前半はパーツ寄り、後半はライブラリの紹介だ。このコラムでは前半部分、その中でもアーキテクチャよりのトピックを拾いながら考察を深めよう。

■Class is difficult to use

　アーキテクチャ寄りの話では、関数型言語的側面からJavaScriptを攻略するのが最近の流行である。しかし、本書では、JavaScriptをオブジェクト指向言語として扱う。不易流行。

　まずは、クラスの考察から本書は始まる。

　JavaScriptはプロトタイプに基づく言語であり、それゆえにネイティブなクラスの実装というものは存在しません。しかしクラスの性質をエミュレートするのは容易です。

　JavaScriptでクラスを扱うのは難しい。オブジェクト指向言語では当たり前にある、クラスにアクセス制限を与えることでさえ、容易ではない。アクセス制限は、匿名関数の空間を閉じ込めることで、プライベート変数やプライベートメソッドを実現する。カプセル化を実現するためだけでも、知っておくべきことは多い。

　本書のサンプルから、もう少しかんたんな例を見よう。

var Person = function(name){
    this.name = name;
}

var alice = new Person('alice');
var bob = Person('bob'); // undefined!!

　JavaScriptは、細心の注意をもって記述する。こんなシンプルなコードが new演算子1つで変わる。new をつけない Person('bob') を実行するとどうなるだろう？ 変数 bobが undefinedになるだけではすまされない。恐るべきことに、このコードはnameというグローバル変数を生み出してしまう。

　なぜか？

　new演算子は、コンテキストであるthisをインスタンス固有のオブジェクトに設定する。しかし、new演算子がなければ、単なる関数呼び出しでしかない。 関数呼び出し時のthis は windowオブジェクトを指す。つまり this.name は window.nameとなり変数nameはグローバル変数となる。それが邪悪な行為であることは言うまでもない。

■Event is easy to use

　JavaScriptのイベントと聞いて、何を思い浮かべるだろうか？ まっ先に思い浮かぶのは、マウスのクリックや、入力エリアの値が変更されたときに連動した動きなどだろう。そういったユーザー操作のイベントは別の本に任せておこう。

　JavaScriptでは、プログラマが任意のタイミングで好きなイベントを発生できる。そして、そのイベントを自在に受け取れる。この仕組みがJavaScriptを輝かせる。イベント駆動のプログラムがかんたんに組めるメリットは、先ほどのクラスを作るためのデメリットを相殺する。

　イベントベースのプログラミングは、アプリケーションのアーキテクチャを疎結合化できるという点で非常に強力です。

　パブリッシュ／サブスクライブと呼ばれるメッセージ交換パターンは、プログラム間の依存性を低め、オブジェクトの独立性を高める。イベントというトリガーを自分自身のなかに持つことができるからだ。イベントベースのオブジェクトは他者から直接、呼び出されることなく状態が変化する。そのメリットが理解できなければ本書を読むのはまだ早い。

　かつてのMVCパターンはページが軸であった。1つのリクエストは、1つのページを表示することが当たり前の世界であった。StrutsなどのMVCアーキテクチャはページ単位を基本とする。せいぜいフレームやパネルという単位で疎結合であれば十分であった。

　Ajaxは世界を変えた。Ajax全開のアプリケーションでは、時としてDOM要素の1つ1つが、MVCの最小粒度になる。コンポーネントですら依存関係を持つことは許されない。Wicketやclickのようなコンポーネントベースのフレームワークの出現がそれを物語る。もはやMVCはページ単位ではない。主役の座はコンポーネントである。

　あるボタンを押すことや、ちょっとしたマウス操作をきっかけに、何かが変わる。そんな要件を満たすためにパブリッシュ／サブスクライブパターンがかんたんにできる言語は強力な武器となる。複雑な動作をするコードは「なんか、よう分からんけど、動いたからいいか」ではダメだ。

　本来、疎結合なプログラム、堅牢なプログラムは言語に依存しない。この本にはMVCアーキテクチャを実現するために考えるべき要素がたくさん詰まっている。特定の言語を抜きにして触れるのも面白い。

■How to build software

　JavaScript本を読むと、小さなテクニックの断片が目立つ。油断すると、ブラウザごとの差異やちょっとしたTipsをたくさん知ることがJavaScriptを勉強することだと勘違いする。そして、それをどれだけ知っているかが優秀なJavaScripterであるかのような錯覚をする。

　プログラム言語を学ぶとは、そんなことではない。「べからず集」を覚えることがプログラムではない。

　ロジックをいかに組むか――オブジェクト指向だけでなく関数型言語やファーストクラスオブジェクトを理解するとがJavaScriptの真の学習であるはずだ。本書が、プログラムとは何かを考えるきっかけの1つになればと思う。

たのしい開発 スタートアップRuby 大場寧子、大場光一郎、五十嵐邦明、櫻井達生（著） 技術評論社 2012年7月 ISBN-10: 4774151661 ISBN-13: 978-4774151663 2604 円（税込）

■なぜRubyistに惹かれたのか

　Rubyへの心変わりは誰の影響だっただろうか。

　業務と関係なければ、勉強しなくていいと思っていたはずだった。アジャイル系コミュニティに参加したしばらくあと、地域Rubyコミュニティに迷い込み、いつしか彼らと楽しくお酒を飲むようになっていた。

　アジャイル系コミュニティの人々が仕事について・技術について話している姿は楽しそうだった。

　彼らはRubyistでもあった。彼らの姿に惹かれ、僕もRubyを学び始めた。

　そうして門を叩いた地域Rubyコミュニティの人々も、アジャイル系コミュニティと同様に、技術について話している姿は輝いていた。

　そして、他の言語コミュニティとは、暖かさが違っていた。その暖かさに触れ、僕も彼らの仲間になりたいと思うようになった。

　なぜ僕は彼らに惹かれたのか。本書の中にその答えはあった。

■Ruby入門書というよりは、Rubyist入門書

　本書は、それまでのRuby入門書、いや、言語全般の入門書とは趣が異なっているRuby入門書というよりも、「Rubyist入門書」といった方が正しいだろう。

　本書の構成は次のように成り立っている。

• Chapter1 「たのしい開発」を求めて
• Chapter2　Rubyの基礎知識
• Chapter3　Rubyを使ってみよう
• Chapter4　Ruby on Railsとは
• Chapter5　Railsを触ってみよう
• Chapter6　Rubyの文化
• Chapter7　自動化されたテスト
• Chapter8　アジャイル開発とRuby
• Chapter9　Rubyのコミュニティ
• Chapter10　とある企業のRuby導入事例
• Chapter11　「たのしい開発」の答え

　言語仕様についてではなく、Ruby on Railsや自動テスト、アジャイル開発やコミュニティについてなど、Rubyを取り巻く世界全体について書かれている。そしてRubyの文化は、これらの要素が合わさることでできている。

■Rubyの自由さ

　そもそもRuby自体が、自由度の高い言語である。Rubyは自分のやりたいことを直感的に表現できる言語であると、著者らは述べている。

　さらに、Ruby on Railsが進化の速いフレームワークであり、アプリケーションの自動テストを作っておかなければ、バージョンを上げることもままならないと述べている。そうした背景があり、RubyやRailsによるアプリケーション開発では、自動テストを作ることが当たり前となった。

　つまり、Railsを取り巻く世界では、自動テストの文化も発展していく。RSpecやCucumberなどはその典型であろう。その思想はいまや他の言語にも伝わりつつある。

　また、そうした自動テストツールにアプリケーションが支えられることで、要件が変わったりすることにも柔軟に対応できるようになった。

　結果として、Railsが

　プロセスやツールよりも、人と人の対話を
　包括的なドキュメントよりも、動くソフトウェアを
　契約交渉よりも、顧客との協調を
　計画に従うことよりも、変化への対応を

という、アジャイルマニフェストに従うことが容易になり、Rubyの自由さをより体現している。

■Rubyが楽しい理由

　このようなRubyの自由さ、プログラマを大切にする価値観の構成要素はこうして生まれていく。

　その結果、新しい技術に挑戦するプログラマにとっても、世界を変えようとするベンチャー企業にとっても、お客様に対する価値を最大化したいと願う受託開発プログラマにとっても、Rubyの開発そのものが楽しくなっていったのだろう。

　さらに、そうした開発を楽しむ人々がコミュニティに集って情報交換をしたり一緒に学んだりするのだ。コミュニティが楽しいに決まっている。企業もコミュニティを支援することで、その企業には優秀なエンジニアも集まってくるようになる。すると、その企業も盛り上がっていく。

　この流れはこれからも続いていくのだろう。だから著者たちは本書のカバーでこう宣言しているのだろう。「これからRubyはもっと楽しくなる」と。

■楽しい開発を目指そう

　では、どうすれば楽しい開発への一歩を踏み出せるのだろうか？

　著者らはこう述べている。

　やりたいこと、やりたくないこと、自分がどうしたいのか、どうしたらうれしいのか。それらに素直に目を向け、受け入れることが「楽しい開発」につながります。

　まずは著者らの言うとおり、そうした自分の想いを見つめ受け入れる。その上でRubyを学びたいとなれば、本書を皮切りにRubyについて1つずつ学んでいけばよいのではないだろうか。

　残念ながら、本書だけでRubyを使ったアプリケーションを作れるようにはならない。それは、本書であまりに広範な話題を扱った結果であり、文化を伝えるためには必要なことだったのだと思う。その代わり、本書の巻末で著者らはRubyを学ぶ道筋を示している。その道をたどっていけばよい。

　楽しい開発を目指そう。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック Dustin Boswell (著)、Trevor Foucher (著)、角征典 (翻訳)  オライリージャパン 2012年6月 ISBN-10: 4873115655 ISBN-13: 978-4873115658 2520 円（税込）

■このコード、なんだかにおうよ

　「コードのにおい（code smell）」という言葉がある。なんとなくこのコードは良くないぞ、バグを含んでいるか、あるいは将来にバグを引き起こしそうだぞ、という兆候のことだ。

　未熟、怠慢、無知などの理由によって生まれた駄目コードからは、往々にしてこの「コードのにおい」が漂ってくる。多くの責務を抱え込んだクラス、巨大で分岐の多い関数、繰り返し現れる同じ処理（それぞれちょっとだけ違ったりすると最悪）。しかし、書いた本人はたいてい「自分のコードが臭い」などとは、夢にも思わずに書いている。何が臭くて、その結果どのような良くないことが起きるかを学ぶ機会がなかったからだ。

　一方、良いコードはびっくりするほどシンプルなことが多い。変数やメソッドには分かりやすい名前がつき、処理の流れは見通しよく整理されていて、重複部分はすっきりと分割して再利用されている。

　同じ「コード」だというのに、この違いは何だろう？ プログラマに「コードのにおいを嗅ぎ取る能力」があるかどうかだ。よいプログラマであろうとするならば「自分の書いたコードが臭い」なんてことには耐えられないはずだ。しかし、「何が臭いのか」を知らなければ、臭くないコードを書くこともできないだろう。

■においの見張り番

　本書「リーダブルコード」は、そんな「におうコード」のサンプルをたくさん収録している。

　コードのにおいを嗅ぎ取る能力があるプログラマにとっては、思わず鼻をつまみたくなるようなサンプルコードを載せ、それがなぜいけないか、そのコードのどこがにおうかを丁寧に解説し、そして「におわないコード」になるようにリファクタリングするまでの流れを、においの種類別に何度も見せてくれる。

　簡単な例を引用してみよう。

if/else 文のブロックは、並び順を自由に変えることができる。例えば、以下のように書くのと、

if (a == b) {
    // 第1のケース  
} else {
    // 第2のケース  
}

以下のように書くのは同じことだ。

if (a != b) {
    // 第2のケース  
} else {
    // 第1のケース  
}

　これまであまり深く考えなかったかもしれないけど、この並び順には優劣がある。

p.86 7.2「if/else ブロックの並び順」より

 

　「えっ、何か違うの？？」

　そう思った人は、ぜひ本書を手に取って「なぜ優劣があるか」を学んでほしい。

　ちなみにこのページには、このコードがどう「におう」のかをユーモラスにあらわしたイラストがついている。このイラストは、普段から「におわない」コードを書いているプログラマにとっては、本文を読む前にニヤッと笑えることだろう。そうでないあなたも、ぜひ本文を読んでこのサンプルコードの「におい」を嗅ぎ取れるようになり、そしてこのイラストで笑えるようになってほしい。

■においがつかない無臭コードだ！

　本書の帯には「周囲の皆が喜んで使ってくれるような、リーダブルなコードを書く方法を楽しく解説！」とある。

　現実のあれこれと同様、「臭い」コードを「みんなが喜んで使ってくれる」とはとても思えない。チームで開発していたり、コードを公開したりしているプログラマの皆さんは、ぜひ本書を読んで、「臭くない」コードを書く技術を身に付けてほしい。

　そしてすでに「臭くない」コードを書けるプログラマのみなさんも、やっぱり本書を読んで「うんうんあるある」とうなづくだけの簡単なお仕事をしてみてほしい。

　もしかしたら、意外と知らなかったり忘れてたりしたことを発見するかもしれないし、そうでなくても、たくさんのユーモラスなイラストを眺めるだけでも楽しい時間が過ごせる。先ほど引用したp.86では「自分のペット紹介」で笑えるし、p.16「超硬い金属のクギを打ちつける棒状のもの」、p.174「あれでいいかもね」などが特に気に入っている。

■においは元から絶て

　世の中から臭いコードを減らすことは、回り回って皆さんの、そして私の仕事を楽しく快適にすることに直結する。本書がきっかけで「臭いコード撲滅運動」が盛り上がり、どんどん「臭いコード」と「臭いコードを書くプログラマ」を駆逐していくのが、今から楽しみである。

（『Wife Hacks ～仕事と家族とコミュニティと～』
コラムニスト　kwappa）

iOSアプリケーション開発入門 新居雅行（著） 技術評論社 2012年7月 ISBN-10: 4774151564 ISBN-13: 978-4774151564 3129 円（税込）

■自作アプリの経験はありますか？

　スマホ業界の勢いはますます加速している。この流れに乗って、スマホ業界への転職を考えているエンジニアもいることだろう。そして、スマホ開発企業は、「業務か自作での、アプリ開発経験」を採用基準とするところが多い。

　Titanium MobileやPhoneGapといった、ネイティブコードを触らずともクロスプラットフォームでアプリ開発できるプロダクトも登場している。私自身、Titanium Mobileを使ってiOSアプリをリリースしたことがある。

　しかし、今のところ仕事としてスマホアプリ開発に携わるなら、大半の現場ではiOSならObjective-C、AndroidならJavaで書くことを求められる、と感じている。

　本書は、スマホ業界に挑もうとする人にとっての先導役といえるだろう。

■書上のハンズオンセミナー

　著者 新居雅行氏は、iOSアプリ開発の講師業もしている。そのためか、実際に本書の内容を試すと、まるで著者のハンズオンセミナーを受けているような感覚でアプリ開発を体験できた。

　iOSでの各種オブジェクトの使い方とそのサンプルコードが載っているような本とは明らかに一線を画しており、実践的な開発を学べる本である。

　本書で扱う内容は次のとおり。

• Chapter1 iOSアプリケーション開発者を目指そう
• Chapter2 iOSアプリケーション開発の流れ
• Chapter3 画像ファイルを表示するビューアを作ろう
• Chapter4 スクロールする画像ビューアを作ろう
• Chapter5 クラウド住所録を作ろう（ネットワークアクセス編）
• Chapter6 クラウド住所録のインタフェースを作ろう（iPhone編）
• Chapter7 クラウド住所録のインタフェースを作ろう（iPad編）
• Chapter8 電子ブックビューアを作ろう
• Chapter9 カメラと画像の顔検出機能を利用する

■実践的なアプリ開発トレーニング

　私にとって、一番の読みどころは、Chapter 5～7の「クラウド住所録を作ろう」だった。

　この章では、Amazon Web ServiceのSimple DBを使って、住所録アプリ開発を行うのだが、その中でネットワークアクセスやSAXによるXMLパースについて取り上げている。ここで取り上げている内容が、Web APIを使ったアプリを作る際に大いに役立つのではないかと思う。

　実際はオープンソースのDOMパーサライブラリやiOS5から標準で使えるようになったJSONパーサを使うことになるかもしれない。それでも、この章の内容を理解していれば、さほど苦しまずに開発していけるのではないか。

　また、本書ではiOS5から利用できるようになった「ストーリーボード」というGUIデザイナを用いた開発も紹介されている。iOSにおけるモダンな開発手法を学びたい人にとっても、参考となる1冊だろう。

■スマホ業界に挑む、最初の一歩

　一方、本書で取り上げていないことも数多くある。例えば、ローカルデータベース（SQLite）の扱い方やユニットテストの扱い方、バージョン管理（Git）の扱い方などだ。これらについて学ぶ場合は、別の書籍やWeb上の情報を参考にする必要がある。

　とはいうものの、これからiOSアプリ開発を学ぼうというエンジニア向けの書籍としては、初めからこれ以上の量を扱うのは苦しいとは思った。上記のような技術は、Objective-Cでの開発にある程度慣れてからでないと理解が難しいかもしれないからだ（私自身、かつてローカルデータベースを扱うあたりでObjective-Cの学習に挫折したことがある）。

　本書は、これからスマホアプリ開発を学びたい、もしくはそれを仕事にしたいと考えるエンジニアにとってよい助けになることだろう。