わふうの人が書いてます。

iOSアプリケーション開発、BLEのファームウェアとハードウェア試作のフリーランスエンジニア。

CoreBluetoothとPassookのイントロ

CoreBluetoothの概要

iPhone4S以降のApple社のデバイスにはBluetooth4が搭載されている。
Bluetooth4は、従来の常時接続かつ高い通信速度を目指してきたBluetoothに、低頻度で少量のデータの送受信ができればよく超低消費電力が求められる用途に向けたLow energyが追加されたもの。
Low energyは、データ送受信頻度によるが、目安として、リチウムボタン電池CR20321つで1〜2年間の通信ができる。

Bluetooth4 = Bluetooth3 + Low energy

白板

MFiの開発の敷居の低さ

Bluetooth3までの開発(ヘッドセットやワイヤレススピーカー)にはMade for iPhoneプログラムへの参加が必要。Appleと弁護士を立ててNDAを締結するため、敷居は高い。これはiOS6になっても、同じ。クラシックBluetoothの開発には、それをはじめるために、MFiが必要。
Bluetooth low energyの開発はMFiが不要。CoreBluetoothは一般開発者ライセンスで利用できる。

ハードの開発

Bluetooth low energyの機器開発は、組み込み機器開発してきた会社にとっては、費用も技術も、かなり容易。Wahoo fitnessの心拍や体重計、Pebbleを始めとするスマフォ連携の腕時計。加速度を利用したスマフォ連携の活動量計などが続々出てきている。
Amazonでkey fobが3000円程度で購入できる。

他のモバイルの状況

WindowsPhone8はBluetooth4がハードウェア認定条件。デフォルト対応しているはず。

Wii Uなど、最近出てきているゲーム機器もBluetooth4対応。今後出てくるWii対応のワイヤレスな周辺装置は、電池の持ちが気になるものは、low energyを採用する、かも。それならiPhoneから使える可能性がある(ペアリングや暗号化周りの実装で、iOSでは使えないかも)。

Androidは鬼門。Bluetooth 2/3/4が機種により混在。さらにOSのバージョンが4系になりBT4と混同しやすい。ユーザが混乱する、最悪の環境。

スイッチとLEDで遊べる

ワイヤレスで常時接続するものは、意外と、簡単なものでも、さーびすとの掛け算でので、いくらでも化けるし遊べる。
Keyfob相当の、1つのスイッチと1つのLEDでも、LEDをモータにすればラジコンになるなど、ハードウェアだけを見ずに、全体を見てやると、切り口がたくさんある。

CoreBluetooth

デバイスの発見と接続の管理は、OSは一切関与しない。アプリに全てが任されている。OSの関与するのは、ハードウェアがペアリングする設計であるときのみ、設定のBluetoothの、接続するデバイスリストに、機種名が表示される。

CeltralとPeripheral

Bluetooth low energyのネットワークでは、デバイスは、Central(セントラル)とペリフェラル(Peripheral)の2つに分けられる。1つのセントラルに複数のペリフェラルが接続する、ピコネット。

iOS5まではiPhoneはセントラルのみになれる。心拍やリモコンなど、市販されているセンサーなどを搭載したデバイスは、ペリフェラル。それらデバイスと接続できる。

iOS6からは、iPhoneがセントラルにもペリフェラルにもなれる。これはBluetooth low energyのプロトコル・スタックの変更、ソフトウェアの変更で、実現されている。

加速度やジャイロなど、センサー+Bluetooth low energyで開発するときに、iOS5まではハードウェアを設計しなければならなかったが、iPhoneでペリフェラル相当の機能を実装して、それで開発を進め、並行してサイズや機能を最適化したペリフェラルを、組み込み機器開発の手法ですすめることができる。あるいは、プロトタイピング。

すれ違い通信とか、ありえない発想にも

Bluetooth low energyの機能は、アドバタイズメントと接続通信の2つ。アドバタイズメントは、ペリフェラルが存在することを周囲のペリフェラルに通知する仕組み。うまく使えば、ブロードキャストに使える。(パケットの長さ制約で、送信できるデータは20バイト位だけど)
接続した状態であれば、適切な頻度、適切なデータレート(50kpbs程度まで)で通信もできる。すれちがい通信みたいな応用も、できるだろう。

Passbookのイントロ

白板

Passbookは自社サーバとユーザの接続

Passbookの仕組み自体はとても単純。Appleから受けた証明書を使い、ユーザにJSON形式のデータでパスを渡せる仕組み。
パスの形式は、チケットなど、5つの形式が決められている。パスの取得は、メール、アプリ、ウェブの3経路。
このパスは、自社サーバから動的に更新できる。

パスに時間や場所の条件設定をしておいて、ローカルで、ユーザにノーティフィケーションの通知が可能。

サービス、商売?

どの視点で、また目的で見るかを考えみます。人目を引くイベントを作るための道具として使うのか。また継続してチケットを売る商売をしたいのか、iOS関連の開発事業をしたいのか。

  • 仕組み自体を見るなら、サーバの設定と運用、あるいはチケット管理代理業務がありそう。
  • チケット販売をやるなら、既存業界があるから、そちらとの競争、iOS開発じゃなくて、その業界の新規参入会社になりそう。

iOSでコーディングするときに読んだ本のリスト

iOS開発で読んできた文書や本

“iOSの新しい機能を素早く効率的に吸収する手段はなんですか?“への返答

iOS講座で、”iOSの新しい機能を素早く効率的に吸収する手段はなんですか?“と聞かれたので、返答を考えてみました。いまは講師がいるけれども、一人で周りに知っている人もいない場合に、どうすればよいのか、手段についての質問だったと思います。

2つの”素早く”があります。周りから見て素早いこと、自分にとって素早いことです。

前者の周りからの素早いは、新しい機能を習得していること、になります。情報の吸収能力は、個人レベルではさほど桁違いの違いはありません。そのため、情報に最も早く触れることが必要になります。

それには、iOSでは、この回答は明確です。WWDCにリアルで参加すること、です。そのために必要な条件や能力は:

  • WWDCのチケットの即時チェックと購入準備
    • WWDC2012のチケットは2時間程度で完売しています。購入ページの開設を即時チェック、渡航や宿泊費なども考えると40万円程度の与信があるクレジットカードを用意しておきます。
  • 英語のプレゼンを聞いて情報を集める程度の語学力
    • せっかく開発者がいるので、質問できればなおいいのでしょうが… ()恐れずとりあえず話しかけてみればいいです。)

次はWWDCの1か月後くらいに公開される動画をチェックすることです。

次に、自分にとって素早いこと、はiOS以前の能力の問題です。英語の文書を素早く読み解く読解能力。説明するまでもなく、常識として、プログラムなどの基礎知識を習得していることは、言うまでもありません。

これは王道はありません。できないなら、いまのうちに、この仕事をすることを諦めてください。諦めたくないならば、読むべき量を見積り、それを短時間で読めるように、自分で自分を訓練しつづけてください。

iOS開発でこれは読んどけ文書(コード書く人向け)

日本語ドキュメント - Apple Developer

  • Objective-Cプログラミングの概念
  • Objective-C プログラミング言語
  • Blocksプログラミングトピックス

  • キー値監視プログラミングガイド

  • キー値コーディングプログラミングガイド

たまたま使うことになったフレームワークを学ばないといけないときに、たまたま、日本語ドキュメントがあったなら、それを読むのがいいです。Appleの日本語ドキュメントは、ステップバイステップでコードを書くときも、またフレームワークの全体の知識を得る入り口としても、とても質の高いものです。読まない選択肢は、ありません。

iOS開発で買って読んだ本(コード書く人向け)

自分が読んだ本を列挙しておきます。

2009年当時、Viewのタッチイベントの扱いなど、実際にアプリを作ろうとすると分からなかった情報が書かれていたので、助かりました。現在はAppleの日本語ドキュメントがあるので、買うほどではないと思います。前半のタッチイベントの扱い部分は、読んでおくといいです。

Xcode4.2はGitを使うソース管理機能が統合されました。私はソースコードのリビジョン管理は、コマンドラインでやっています。なんとなくです。
Gitの使い方は、この本で学びました。サブモジュールの使い方など、Gitのドキュメントでは自分が理解できない部分が解説されていて、助かりました。

音周りの開発をするときの、バイブルです。

iOSの新しい機能を解説している、よい本です。
WWDCのサンプルコード+解説を日本語に焼き直したもの、と思えばいいです。

ただし、この中のARCなどの解説は、とても深くわかりやすい解説で、WWDCよりこちらを見るほうが、よいと思います。この部分は達人出版会から出版されています。エキスパートObjective-Cプログラミング ― iOS/OS Xのメモリ管理とマルチスレッド

iOSの開発情報の、収集と更新および追従

今回の講義の内容

11月の6回の講座で、iOSの教科書)を使い、Xcodeの使い方、Objective-Cの文法とメモリ管理、Model-View-Controllerモデル、シングルトンを学び、カウンタアプリを作り、それに機能を追加していきました。

アプリ開発は、この作業の繰り返しです。あとは、フレームワークごとの知識を身につけていきます。フレームワークは、アプリ開発に必要となる機能、カメラや加速度センサーなど、の利用に必要なライブラリとヘッダファイルをアーカイブしたものです。

今回は、Xcodeでフレームワークの概要およびコーディングのための必要な情報の入手方法を紹介します。つぎに、Appleが公開しているiOSのCoreImageの動画を見ます。動画は、要所要所で日本語で解説を、またはまりやすい点を述べます。

ホワイトボード

フレームワークの情報の入手

フレームワークは、リンクするライブラリファイルとヘッダファイルを1つにアーカイブしたもので、カメラやグラフィック描画、あるいはソーシャルネットワーク利用など、アプリ開発に必要な機能を1つのかたまりにして、提供しています。

iOSアプリ開発である機能が必要になれば、その機能を提供するフレームワークを使います。そのフレームワークについての情報は、Appleが公開する1次資料、そして書籍やブログなどの、2次、3次資料から得られます。

自分が必要な情報は何か?

情報を入手するときは、どの立場にあるかで、求めるものが違います。独断で区分してみると:

  • 開発者(ネイティブ・アプリ、ウェブ・サイト、ウェブ・アプリ)
    • 機能するコードを書くことが必要です。WWDCの動画、およびプログラミング・ガイドの熟読と、実際のコードを書くために、サンプルコードの読み込みとクラスの詳細説明の理解が必要です。
  • 開発指揮
    • 開発者に適切に仕事を振り分けて、その実装内容を指示するために、そのフレームワークで何ができるか、どの程度の処理能力が実現できるかを把握している必要があります。
  • 企画立案
    • iOSでその機能が実現可能か、またアルゴリズムの実装難易度や要求速度を満たせるかを判断できるほうが、あとで実装できないなどのトラブルを回避できるでしょう。そのためには、その機能が不可能なものか、頑張ればできるのか、あるいはAppleのサンプルコードを使える容易なものかの、自分たちにとっての開発難易度を推測するための知識が必要です。

Apple社の出している1次資料だけでも膨大です。全てに目を通すのは、一人では、無理でしょう。役割や利用目的に合わせた、必要な分の情報を得ましょう。

iOSは毎年機能が更新されて、去年までの知識を更新しないといけないことも、よくあります。”What’s new~”のような更新情報は、目を通しておきます。

英語は必要です

Appleの1次情報は英語です。もしも1次資料を読めなければ、日本語に翻訳された情報、または解説記事などの2次資料を待つほか、ありません。

1次資料からそれら2次資料が作られるまで、半年単位の時間がかかります。そのiOSが公開前ならば、Appleと開発者間に秘密保持契約(NDA)があるので、一般に公開されることはありません。英語ができない=新機能を半年から1年知ることはできない、です。

プレゼンテーションの動画と資料から、内容を理解することが必要です。ここで、動画の英語を一句一文字すべて聞き取れる必要はありません。また、動画を止めては辞書を引いてもいいですし、なにかの自動字幕生成や翻訳ソフト、あるいは翻訳者を雇ってもよいでしょう。英語が得意な開発者を中心にして勉強会を開催するのも、よい方法です。

内容を理解する、ことができればよいのです。適切な手段を工夫してください。

概要から詳細に進みましょう

iOSの機能や開発方法を俯瞰できる資料は、WWDCの動画です。プログラミングの詳細情報は、フレームワークそれぞれのプログラミング・ガイドとクラス詳細の文書です。まず、全体を俯瞰して、そして開発者でコーディングが必要ならば、次に、文書を読み進めましょう。

WWDCの動画

iOS開発者プログラムに参加していれば、WWDCの動画を[Development Videos APple Developer]から入手できます。次の3つのコースがあります:

  • WWDC2010
  • WWDC2011
  • WWDC2012
  • iOS Videos

2010年から2012年まで3年間のすべてのWWDCの動画が公開されています。iOSは変化しつづけています。そのために、あるフレームワークの現在を知るのに、どの年のプレゼンテーションを見ればよいか、初めてでは分かりにくいです。そのときは、iOS Videosを見てください。現在のiOSアプリ開発に使える動画が、掲載されています。フレームワークごとの“最新”情報は、それぞれの年のWWDCの動画から、探してください。

WWDCの動画入手は、[Development Videos APple Developer]のそれぞれの年から、”iTunesで開く”のリンクを開けば、iTunesからダウンロードできます。オンラインでも見られますが、ネットワークが切断する、あるいは閉じると、動画を見ていた位置が失われて最初から再生されるので、不便です。ダウンロードするのが、おすすめです。

iTunesでダウンロードしたすべての動画を保存するには、端末の容量が不足するときは、見たいコンテンツを選択して同期します。

WWDC2012のサンプルコードは、ページ左カラムのリンクから入手できます。WWDC2011のサンプルコードは、項目を開くと、動画やプレゼンテーション資料とともに、サンプルコードへのリンクがあります。WWDC2010のサンプルコードは、このページから入手はできません。WWDC2011以前のサンプルコードは、Xcodeのドキュメントで表示されるサンプルに、登録されている、っぽい、です。

動画のジャンル

ジャンルは、以下4つです。見たままです。

Essentialは、基本的な事柄についてのプレゼンテーションがまとまっています。少なくともタイトルをチェックして、必要だと思ったものはチェックします。

開発ツールはXcodeの効率的な使い方や、Instrumentsの新機能など、開発ツール紹介です。開発者のうち誰が一人が見て、まとめ情報を共有すれば、よいでしょう。

Core OSは、低レベルなライブラリの説明です。ネットワークや音や動画像処理などが紹介されています。

Internet&Webは、ウェブアプリやウェブサイトについて、またHTTP Streamingの動画配信などが紹介されています。

  • Essential
  • Developer Tools
  • Core OS
  • Internet&Web

CoreImage

iOS Dev Videoを見てみる。動画: Using Core Image on iOS

CoreImageは、画処理のフィルタを提供するライブラリである。iPhotoができることを提供していると思えばよい。カメラからの動画のリアルタイム処理、ファイルやUIの画像の処理に使える。

ドキュメント:

サンプルコード

入出力

入力:

  • ファイル (ドキュメントフォルダのファイル、アプリにバンドルされた画像リソース)
  • バイナリ・データ(NSData *)
  • ライブ・カメラ

出力:

  • CGImageRef (UIImageに変換、写真ライブラリに保存)
  • EAGLContext (OpenGLのテクスチャ)
  • CVPixelBufferRef (CoreVideoのフレーム)
  • void* (任意のバイト配列)

メモ

基本のクラスとその働きは、CIImageが入出力、CIFilterがフィルタ、CIContextがレンダリングの設定とその実行を行うクラス。

iPhotoにある基本的な画像処理ができる。さらに高度な処理がある。1つは、顔検出(顔の位置、鼻や目の位置、そして顔の回転向きと回転角度)。また、デジタルカメラによくある、赤目修正、肌色修正、逆光補正などを実現するフィルタを自動構築する仕組みがある。

画像のorientation。iOSの画像の回転は、画像データ自体を操作しない。画像の向きを表す、メタデータで、設定している。そのため、画像処理にそのorientationのメタデータを渡していないと、特に画像の向きが結果に直接影響する、顔検出で想定した動作をしない。

CIImageとCIContextはimmutable。スレッド間で安全に利用できるCIFilterはmutable。スレッド間での同時利用はできない。

CIFilterの入出力を接続して、必要な画処理をするフィルタを構築する。使えるフィルタは、iOSでは48種類。ユーザがフィルタを実装することは、iOSではできない。

CIImageをUIImageにするには、UIImageクラスに、CIImageからの変換のクラス・メソッド(+ imageWithCIImage: ,+ imageWithCIImage:scale:orientation:)を利用するのがいい UIImage Class Reference

CIFilter。フィルタのインスタンスは、文字列で指定して生成する。フィルタごとにCIFilterを継承したクラスがあるわけではない。

CIFilterそれぞれの、パラメータは、文字列をキーとして、値を指定する。フィルタごとのパラメータ詳細はCore Image Filter Referenceに解説がある。

この文字列で指定するオブジェクト指向っぽくない実装方法は、Coreなんとかでは、ところどころで見られる。よく知らないけど、Obj-Cの文化?

レンダリングはCIContextでおこなう。CIContexのインスタンスは1つを使いまわす。

写真ライブラリへの保存は、レンダリングにCPUを使う。GPUだと、機種ごとにGPUが処理できる最大画像サイズが異なる。またCPUにしておけば、バックグラウンドでの処理ができる。

メモリ管理。CIFiterやCIImageはObjective-CのARCでメモリ管理されている。だが、CGImageRefは、メモリ領域のポインタ。C言語の仕組みで管理されている。なんとかRefとあるのは、たいてい、開発者が開放してやらないといけない。

CGImageRefは開発者自身が開放してやらないといけない。もしも開放し忘れていると、メモリがリークして、そのうちにアプリが使えるメモリがなくなり、アプリが落ちる。メモリリークは、あとから見つけるのは手間なので、忘れず開放するように、コードを書くときの習慣づけとするのがよい。

Octpressインストールメモ

Macbook Air 11(2012 mid)にOctpressを導入したときの、メモ。

octpressを使うと:

  • Markdown記法(Markdown syntax guide)で書いたテキストを、ローカルで静的にHTMLに変換できる。
  • ソースと静的に生成されたウェブページはGitで管理できる。
    • ローカルで編集して好きなタイミングでリリースできる。
  • テーマやプラグインがあり、見た目のいいブログサイトを手間なく構築できる。カスタマイズもできる。

みたい。

プログラミング関連の記事を書くときに必要なソースコードのハイライト表示等が設定なしで使えるのが便利そう。
オフラインで書いて、そして静的に生成されたページは、ローカルのウェブサーバでプレビュでき、Gitで管理できるから、オンラインエディタを使う時のネットワークの切断を気にしなくてもいいのは、ストレスがなさそう。

環境構築
-

octpressインストールガイドの手順に従えばできる。octpressはruby 1.9.3以降を必要とするが、Macのは1.8系。そのためRubyの環境構築が必要になる。

octpress SetupでrbenvもしくはRVMを使う方法が紹介されているが、私は使い方がわからなかった。Homebrewで環境構築をした。

GitはXcodeのCommandline toolをインストールしていたので、すでにインストール済。
まずhomebrewをインストールして:

1
$ ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go)"

rubyをインストール。

1
2
$ brew doctor
$ brew install ruby

~/.bash_profile にパスを設定して、1.9.3のRubyを先に見つけるようにする。

1
export PATH=/usr/local/bin:$PATH

コンソールを新しく開いて、先ほどの環境を反映させて、rubyのバージョンを確認する。

1
2
3
4
5
$ ruby --version
ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-darwin12.2.1]

git clone git://github.com/imathis/octopress.git octopress
cd octopress

先ほどインストールしたruby関連コマンドを実行:

1
2
/usr/local/Cellar/ruby/1.9.3-p327/bin/gem install bundler
/usr/local/Cellar/ruby/1.9.3-p327/bin/bundle install

octpressがプレビューに使うコマンドを、実行パスにシンボリックリンクで置く。

1
2
3
4
5
6
7
cd /usr/local/bin	
ln -s ../Cellar/ruby/1.9.3-p327/bin/jekyll ./
ln -s ../Cellar/ruby/1.9.3-p327/bin/compass ./
ln -s ../Cellar/ruby/1.9.3-p327/bin/rackup ./

cd path/to/octpress
rake install

設定
-

Rakefileと_config.ymlの設定項目を書く。ブログのタイトルや、メールアドレス、Githubのアカウントなど。ここに設定しておけば、その関連情報を適当に表示してくれる。

ブログを書く
-
コマンドラインで新規ページを作れる。

1
rake["octpress-install-memo"]

source/_posts/ 以下にファイルがあるので、それにコンテンツを書く。プレビュー時や、deployするときは、ファイルが変更されると静的なページが自動生成/更新される。書いている途中に、それを禁止しておきたい時は、

1
published = false

ヘッダにこの1行を入れておく。

編集環境
-
Macで動作するMarkdowプレビュ・エディタを使うと、レンダリング結果を見ながら書ける。また、Markdownの記法に従いハイライトされるので、読みやすい。

編集とプレビュー
-
ファイル編集が完了したら

1
% rake generate

プレビュにしておくと、ブラウザで表示結果を確認できる。Markdownのソースファイルが変更されたら、変更を検出して、自動的に静的にページを生成する。コンソールのコマンドでプレビュを立上げる。これはCtrl-cで終了する:

1
% rake preview

WEBrickが4000番ポートで立ち上がるので、ローカルで http://127.0.0.1:4000 を開いて確認する。

iPad miniでプレビュ

iPad miniなど、外部から確認するときは、IPアドレスを調べて、開く。例えば:

1
2
3
4
$ ifconfig
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.0.1.9 netmask 0xffffff00 broadcast 10.0.1.255
^^^^^^^^^^^^^^ この端末のIPアドレス

無線ルータが割り当てたこの端末のIPアドレスは10.0.1.9なので、iPad miniから、http://10.0.1.9:4000 で開く。自宅で無線ルータを利用しているならば、MACアドレスに対してIPアドレスを指定して、同じ端末に同じIPアドレスが割り当てられるようにしておけば、常に同じURLでプレビュができるので、便利。

公開
-
ソースファイルはsourceブランチにある。Github pagesを利用しているなら、

1
% rake deploy

でmasterブランチに静的にHTMLファイルを生成、githubにpushする。これでuser-name.github.com でページが見られる。このページなら、http://reinforce-lab.github.com

その他
-

画像を入れるには?

octpressで画像を表示するには、画像プラグインで画像のURLを指定する。
私は、画像ファイルもmarkdownテキストと同じレポジトリで管理したい。そこでoctopressのsourceにpost_imagesというフォルダを作り、そこに画像ファイルを置いた。octpressは、sourceフォルダ以下に置いたフォルダとファイルを、自動的にサーバ側にコピーしてくれるみたい。

1
2
3
cd octopress/source
mkdir post_images
mv img_1261.jpg ./

img_1261.jpgはこのエントリで使った画像のファイル名。この画像を読み込むには:

1
{% img /post_images/img_1261.jpg %}

‘/’で始まるURLは、サーバのルートに置換してくれる。画像の幅だけ指定しておけば、縦横比はそのままで表示される。

レポジトリの扱い:今あるファイルがdeployされる

Gitpagesは、masterブランチにpushされたmarkdown形式およびhtmlのファイルを、jekyllで処理して静的に公開する仕組み。

‘rake deploy’で、今のローカルにあるファイルが、静的にhtml変換されて、masterおよびgithubにpushされる。sourceブランチにpushする必要はない。だから、一時的なお知らせのようなページも、sourceブランチにpushせず一時的に変更したままの状態で、’rake deploy’でgitpagesに公開できる。

Octpressのソース・ファイルはsourceブランチで管理されている。masterブランチは、ローカルから見えなくしてあり、’rake deploy’で、生成したhtmlファイルをmasterブランチにpushして、それをGitpagesにpushしてくれる。

部分的なファイルの読み込み

リンク・リストや、著作権表示のような、様々なページが参照する共通の情報や定形文章には、[render partial]機能を使う。
Jekyllは、ファイル名もしくはフォルダ名がアンダースコアで始まるものは、レンダリングの対象外にする。

利用方法:共有するリンク集

[render partial]を使い、ブログで頻繁に参照するリンク・リストを、別ファイルにして共有する例。
まず_source/_link.markdownというファイルを作り、

1
[render partial]: http://octopress.org/docs/plugins/render-partial/

そこにリンクのリストを書く。この書き方は、テキストタグとURLをリンクさせるmarkdownの記法で、本文中の[render partial]は、自動的にURLリンクに変換される。
そして本文の適当な場所に

を入れておく。先程のリンク集が本文によみこまれ、そこリンク集のタグを’[タグ]’で使える。相対パスの始点は、sourceフォルダなので、パスの頭に”_posts/“が必要。

岐阜人材育成講座 ~はじめるにあたり~

これは

2012年の岐阜県、スマートフォンアプリ開発関連人材育成事業でiOSアプリ開発の講師をしています。その講義で口頭で話した内容の概略メモです。
情報工学を受講したことがなく、C言語などは知らない方に、iOSアプリ開発に参加する上で知っておくべき、プログラミングの概念と技術の概要を伝えるのが、目的です。
このテキストは、講義を受けた方が、あとで内容を思い出すためのメモです。思い出すための糸口として概略をまとめています。

受講内容と想定している受講者

講義回数はは、1週間に2回、ほぼ1日の講義を、2ヶ月、全16回の予定です。
受講者は、C言語を知らない、またC++などで開発経験があるなど、スキルはさまざまな、経歴もさまざまです。

ぶっちゃけゼロから作れる開発者になるのは困難だと思っています

iPhoneの登場初期のような、真っ白な画面を表示するだけのアプリが”照明アプリ”として何十万ダウンロードを達成する時代は、大昔に終わっています。
iOSが出てから5年ほどですが、iOSアプリを企業また個人で作っている人の中には、10歳からプログラミングをしている人が、ゴロゴロいます。

そのなかで仕事としてiOSに関わるならば、たった数十時間で開発者になれる、という言葉の内容と意味を、自分が今まで受けた教育や蓄積した経験をもとに、考えてください。
私は、開発者になるのは困難だと思っています。無理だと言ってもいいでしょう。

しかし、iOSアプリの価値は、気持ちいい絵と音楽とユーザインタフェースです。純粋な開発者はそれを支える縁の下の力持ちです。この状況は、Windowsのような業務アプリとは全く違い、おそらくは、ゲーム開発会社に近いでしょう。その世界では、開発者の仕事が理解できて、アニメーションのパラメータ設定であれば自分で”コードを触れる”ことには、意味があります。

自分にとっての、iOSの知識と経験の活用を考えてください。また、自分が10時間でできることは、他人も10時間でできます。しかし、5年前に10時間でやったことをもとに、5年間の経験と蓄積を重ねているならば、その5年間はだれがやっても5年間かかります。その意味で、知識と経験の活用を、考えてください。

達成目標

習熟の目標設定は:

  • Obj-Cの言語仕様が”だいたい”わかる
  • サンプルコードをいじり(アニメーションの動きなどを変化させる)、そのいじった内容を論理的に他人に説明できる。

です。

テキストと資料

このほか、Appleの開発者サイト[https://developer.apple.com/devcenter/ios/index.action]には、ドキュメントおよびフォーラムがあります。

”プログラミング”の経験がある方は、”動くからいい”、を捨ててください

ProcessingやArduino、MAXなど、何かしらの動作制御やデータ処理をコンピュータでした経験があるならば、それはプログラミングの経験と呼べます。
この講座を受ける方は、”動くからいい”、”動けばいい”、という考えを捨ててください。

  • 考えて作らない
  • 経験を蓄積しない
  • 非効率な開発をする

考えて作らない

コードを書いたなら、それが当たり前に動くから、プロとしてやっていけます。それは、目の前で動くのみならず、仕様の範囲での”ありとあらゆる状況”で動くもので、あるはずです。
しかし自分の想定と違って、思ったように動いていない場合は、よくあります。
その場合は:

  • 開発時の、こう考えて、こう作れば、こう動くはずだ、を再確認する
  • その確認に基づいて、思ったような動きをしていない部分の、コードを読み直す、またデバッグなどでその部分を特定する
  • その部分の動きを確認する、予想と照らしあわせて、差異を見つける

手順を取ります。そして、修正します。
”動くからいい”と考える場合は、このフローが身につかない人が多いと、私は思っています。

経験を蓄積しない

動かない場合も、上記のフローを通して、なぜ動かなかったかを、知識として整理して、それが発生する状況を把握して、はじめて経験となります。

非効率な開発をする

iOSの開発に使うXcodeは、ステップ実行、ブレークポイントなど、アプリケーションの実行状態を直接確認できるデバッグ機能があります。

アプリケーションを1行づつ実行して、値の変化を追って、”動くようにした”という方がいるかもしれません。おそらく、それは、とても時間のかかる作業だったでしょう。
しかしそれは”作業”です。開発者に徹夜をして欲しいと思う人は、誰もいません。徹夜の回数を誇られても、残業代がかさんだなとか、トラブルメーカーになりそうだから、次の仕事ではこいつは外しておこうと、思うだけです。

もしも最初から、上記フローを使い、また経験を活用して、原因箇所を限定すれば、コードをよく読みなおすだけで、修正できたかもしれません。
動くものを作ることが仕事です。その結果に至るまでの、最も楽ができる、最も効率的な開発手法を、自分以外の人でも使える汎用なフローとして、身につけてください。

”プログラミング”をするまえに

概念を理解してください

概念はとても大切です。

  • それは、どんな概念か、
  • 歴史的な変遷もふくめて、どこから、どうして、その概念が生まれたのか、またそれが、こうして教え継がれる価値はなにか、

を吸収してください。

実作業の前準備が仕事の8割を決めます

目の前にある作業、コードを書くとか、Xcodeで何か作業をするとか、は肉体的な充実感があり、仕事をした気になります。
ですが、実作業をする前に、このクラス設計は正しいか、自分がこれから書こうとしているコードは、どこでどうつかわれるかを、理解しているか、”わかっているか”をチェックしてください。

英語は必要です

英文を読むことにアレルギーがあるなら、それを克服するか、この仕事は諦めてください。
ここでの”英語が必要”は、文章を読み開発に必要な情報を自分で吸収できること、です。

  • 英語構文の知識は、中学3年で十分です。
  • 技術用語およびわからない単語は、都度調べて覚えてください。
  • プログラミングガイドのような、長文を読むときは、文章の構造を利用して、短時間に無駄なく、どの詳細の階層を読んでいるかを意識すると楽ができます。
    • 英語は重要な情報が頭にくる、そして詳細が後ろに続く言語です。
    • タイトルと見出しは内容を濃縮した情報です。じっくり読んで全体を把握します。
    • タイトルに続く”概要”は、だれにむけて、どんな情報を、どう書いているのか、それを読むと何が得られるのか、をまとめています。読むべきか否かを判断するのに十二分の情報がここに含まれています。
    • 段落は、先頭の1行がその段落の内容を表しています。1行を読むのも時間が惜しい時は、接続詞と主語と助動詞(must, may, shall, そしてnotの有無)そして動詞を見ます。

独学はよいのですが独善になっていないか気をつけましょう

プログラミング言語でソースコードを書くときの、変数や関数の命名、また設計パターンは、何十年の先人が経験を蓄積してきた、定番の方法があります。独学はよいのですが、この点で、独善にならないように気をつけましょう。
プログラムのソースコードは、必要な機能をプログラミング言語で人間が読んでも分かりやすく表現する活動です。ソースコードで、他人が読みにくい”おりじなりてぃー(笑)”あふれるソースコードは、害悪です。もしも私がマネージャをしているなら、そのようなメンバーは即時はずします。それは、”開発後期”になって、原因が分かりにくい不具合を混入させる、その人のソースコードが読みにくい場合は他のメンバーにゼロから書きなおさせることになると、経験が告げるからです。
独善にならないよい方法は:

  • 事前にコーディング規則に目を通すこと、
  • 開発チームで良いコードを書くと言われている方のソースコードをよく読むこと、
  • チーム内でレビューを重ねてお互いにわかりやすいか、悪い意味で属人性の強い書き方になって
    いないかを指摘をもらうこと、

です。

1次資料、2次資料、3次資料を使い分けましょう

ここでは、

  • 1次情報:Appleが公式に出している情報およびAppleが運営するサイト
  • 2次:の情報が1次、著作物を残したりStackOverflowで評価が高い開発者の回答
  • 3次:その他のGoogleなどの検索で出てきた情報

とします。

1次資料は、例えばフレームワークの全体から詳細までを網羅した情報です。何かを開発するとき、”わかったつもり”にならず、公開されている1次情報の読むべき該当情報は、ひと通り目を通します。
開発をしていると、”個別の”、うまくいかないことや、どう作ればいいのかわからないこと、にぶつかります。そのような個別の情報は、Appleの1次ドキュメントから読み取ることは、大変です。そんなときは、Q&AサイトやGoogle検索を使います。

StackOverflowは回答の質を評価し、評価が高い回答が上位に表示されていて、役に立ちます。Google検索は site:http://stackoverflow.com と検索対象サイトを限定するのもよいでしょう。

Google検索で漠然と検索するときは、時間の使いすぎに注意します。検索1ページ目に回答そのもののページが見つからない場合は、検索ワードを変えるなどしましょう。もしも、検索結果ページに目を通しだしたら、脱線も含めて、回答が得られるまで3時間かかること、つまり今日の仕事の半分の時間はそれに通夜してしまうことを、を覚悟してからにしましょう。

検索の前に自分の状態を把握しましょう

2次、3次情報を探すときは、自分の状態を確認してからにします:

  • エラー発生箇所もエラーメッセージも分からない
    • 検索以前に自分が何をしているかが把握できていません。自分の能力を超えている仕事です。自分にはできないかもしれないと悟り、他の方と相談するなり、他の手段を考えましょう。
  • エラー発生箇所とエラーメッセージを読み取ったが、内容が理解できない
    • エラーメッセージは、同様の事例検索の強力なキーワードです。望むらくはそのエラーメッセージが、あまりにありきたりで、ありふれていて、数多くの様々な原因が、そのエラーメッセージを出さないものであることを、祈りましょう。
  • エラーの発生条件やエラーメッセージが把握できていて、SDKのバグではないか?など、自分なりに原因推定がついている、
    • 裏付けがほしい、程度で情報を検索するレベルです。おそらく1時間もかからずに、解決できるでしょう。

PassKit雑感メモ

Pass Kit 技術利用の予測

これは

6月13日に作成した、PassKitの技術概要から、iOS6が登場する2012年9月後半からの、動きの勝手想像。
PassKitについては、プログラミングガイドを参照

クライアントにメールで送ってたのだけど、ふっと見つけたので、ここに公開。

要点

iOSをプラットホームとして、電子メール、ウェブ(URL)、アプリから、ユーザにカードを提供する仕組み。

ビジネスなモデルは、i-mode。コンテンツを提供するインフラ。時代が違うのは、ユーザに直接かつリアルタイムに働きかけ行動を制御できる、チケットという概念を利用した、コンテンツとノーティフィケーションな代物。そのカードの提供には、Appleへの手数料はかからず、カード情報は、提供者自身のサーバから提供する。強いリアルタイム性が利用できる。

ユーザに広告チラシを渡して、それを所持し続けてもらえる感じ。その広告チラシ、メンバーズカードを通して、通知や提案ができて、それらがデバイスIDでヒモ付されている。

概念として、通知専用のウェブアプリをユーザヒモ付でワンクリックインストールする仕組みと理解すれば、応用の発想がしやすいだろう。

ユーザが、スマートフォンを持っていれば自動的に提案がくる、自動機械になる大きな転換点。もう、検索したり、操作したり、能動的なわざわざやらねばならない行動は面倒なだけな、強い方向性の提示。所持しておけば後は自動的に快適なものを提供する、糸口としてのモバイルなデバイス。

技術的には:

  • ビジュアルなカードを通知する、ノティフィケーション
  • 提供者は、自前のRESTfulなウェブサービスを通じて、JSON+画像をアーカイブ、電子署名した情報を、提供する
  • URLにはデバイス識別子が含まれる(デバイスの個別識別が可能)
  • 提供者は、パスをユーザのデバイスに、挿入、更新、削除、ができる
  • 扱いは、アプリへのノティフィケーションと同様。Appleに支払う手数料は発生しない。

Appleが提案する利用場面:

  • (航空券などの)チケット、クーポン、メンバーズカード
  • ユーザへの行動の催促、あるいは制御:(お店など)位置近接、(搭乗や上映)時間

ブレスト

  • こんなサービス提供しているところ、今までなかった?
    • インフラ的に提供しているとこは、しらない。Grouponとかが業態近いけど、メール保存のいちいちクリックでウェブなチケット表示?
  • アプリでもできたよね?
    • 自社アプリで同様のことはできた。アプリのインスト不要で、URL踏めばチケットなのが、違い?

ぱっと思いつく感じ、どんな感じ

  • 毎月、おすすめ商品写真がかわるメンバーズカード
    • 美容院の担当の方、予約可能時間が分かる、ワンボタン予約機能付きメンバカード
    • 先着100人限定クーポン
      • 100人きたら、クーポン消滅。もしくは、有効期限が翌日に伸びる。
  • キャンセル待ち予約チケット
    • キャンセルが出たら予約確定させます?な表示が出るチケットとか
  • 中古本売り買いだと
    • メンバーズカードー>買取価格をポイント化で10%アップ。
    • 購入した履歴にあわせた、在庫ありのおすすめ画像をカードにアップデート表示。限定キャラ絵とかもいいよね。
    • 買って売るユーザには、適当なタイミングで買取の提案してもいいかも。
  • チケット会社へのインパクト
    • 個人にチケットヒモ付により、自動的な転売屋の排除。

動き

対応する会社

  • POSなシステム (チケット管理システムとして、ウェブとアプリとその運用を必要とする)
  • チケット会社(ぴあ、セゾン)
  • イベント参加なウェブ会社 (ATND)
  • プリペイド発行会社

ギーク

  • 6月末には、ウェブサービスの基本ライブラリとサンプルアプリコードを使いこなすだろう
  • NDAで外には出せないので、社内やうちわで評価するだろう

技術手段な会社

  • Parse.comなどのノティフィケーションの代行サービスは、PassKitの代行サービスを提供するだろう。
  • iOSのPassKitを使いやすく、また同時にAndroidに同様なサービス提供できる形で、かつiOSのPassKitを一般の人が使えるウェブサービス会社が登場するだろう。
  • PassKitの代行会社は、ユーザの行動履歴を手にするだろう。ビックデータから、いかに適切にかつ好まれる提案ができるか、高い解析能力とセンスがあるところが、大きな成長を遂げるだろう。

機器メーカ

  • バーコードに限らず、汎用の画像を表示できるので、液晶画面のその表示を読み取ることで、既存のPOSを利用できるだろう
  • システム自体に組み込むことは容易なはずだが、iOSに必要なウェブサービスまでを開発/運用する能力はないだろう。→ 外注もしくは外部委託

特需?

  • 既存のメンバーズカード発行会社が、組み込むには。富士通とかあのあたりのものに増設。システムを分離すればいいから、難易度は低いが、動きは遅いだろう。ー> 食い込むチャンスかも
  • ビックデータでユーザの行動履歴分析のフラグが立っているから、NTT系列あたりが、システムごと移行でしかければ、楽かも
  • ヤマダ電機が、自社ポイントでゲーム、自社のポイントを仮想のゲームに投入して引当金を現金化させず、かつユーザを自社に惹きつけ留めようとするところは、利用価値、ありそう。

チケットなサービスの移り変わり

Grouponがサービス提供をするだろうが、後発のウェブサービスのみにしぼった後発の会社の登場で、衰退するだろう。
自身の店のチケットを発行する、低価格でだれにも使いやすいウェブサービスが登場するだろう。それは、iOSおよびAndroid(独自アプリ)を通じて、パスを発行し、またアップデートをするだろう。その手数料はとても安く、Grouponに支払う手数料分を、さらに割引に使うことが可能になるだろう。
ウェブサービス提供者は、デバイスを個別に識別するIDにひもづけられた行動履歴を入手するだろう。それは、より的確なクーポンの提案を可能とし、ウェブを見ない人に、消費活動を引き起こすだろう。

Googleは対応しない

Googleは対抗しないだろう。
PassKitが提供するクーポンは、極めて低価格になったチケット発行と管理コストでういた広告コストで、さらなる割引を可能とする。これは、ユーザに魅力的な広告だが、しかしウェブサービスを通さず、ユーザに直接届く。チケットが作る市場は、ローカルの流通に、入り込むだろう。
これは、Googleが欲しいが、手に入れられない市場だろう。だが、もしも、広告手数料を収入とするGoogleが参入するとすれば、iOSのプラットホームで3rdパーティが提供するウェブサービス自体を含めて、Androidで、提供することになるだろう。しかしそれは、Androidに露骨な利益を誘導する自社サービスをいれることであり、端末メーカはそれを許さないだろう。

開発特化な会社としてのやり方は

技術:汎用。最初の切り込み方向はi-mode向けのシステム会社がたどったような感じだろう。サーバやコンテンツのアップデートをサービス提供。ただし、ユーザの行動履歴が取れるので、その分析をする/しないで、本質i-mode時代とは違うものになれる。ただ、それがチケットなサービスから切り込めるかどうかは、知らない。最適チケット発行で食い込んで、そのうち、これいいじゃんと気づかせて、本社のカードなシステムに食い込む感じだろうけど。

囲い込み:弱い。立ち上げの開発コスト。たぶん、プロトなら2週間x6人。ウェブとアプリ開発者+ディレクタ構成で。1000万はかからないイメージな、むちゃ安。だから、どこもやるだろう。iOS6 NDAがとけた時点で、外に出るんだろうけど。システム自体は、いちどやったら、初期立ち上げの手間があるから、最初にやって、囲い込んだもの勝ちかしら。

Android向け開発:とりあえず独自アプリで同じチケット環境提供でやればいいだろう。Androidは無視はできない。アプリでAndroidのほうの、囲い込みにもなるし。Googleが本気でやれば、半年で実装して出すだろうけど、その時はそちらを利用に切り変えればいいくらい。

雑記

2010年にAppleが出したConnect Ticket+、パテント。
http://www.patentlyapple.com/patently-apple/2010/04/apple-introduces-us-to-a-new-itunes-concert-ticket-system.html

”クラウド チケット”で検索すれば、いろいろ出てくる。やることは、おんなじだよな。費用が、初期10万、月額〜、とか、かなり属人的に消耗戦な課金。
おそらく、初期導入費用ゼロで、使った分だけ課金な商売をやったところが、勝つのかな。