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

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

iOSデザイナのキャリア設計

12月27日のiOSアプリの講義は、iOSアプリのUI/UX設計の漫談です。UI ユーザ・インタフェース, IT用語辞典 e-Words, UX ユーザ・エクスペリエンス, IT用語辞典 e-Words

深津さんの”使ってもらえるアプリの考え方”を見ながら、漫談をしました。

iOSアプリ開発の技能の使い所

まず、自分にとっての、iOSアプリ開発の技能の使い所を考えてみます。

フルタイムとパートタイム

最初に、仕事としてのiOS開発に、自分の時間の割り振り割合で、区分します。

  • フルタイム
    • 雇用
      • 専業開発者 (コーディング、デザイン)
      • 企画、保守、運用の担当者
    • フリーランス
      • 専業開発者 (コーディング、デザイン)
      • 開発情報のエバンジェリスト(講演、著作、セミナー)
  • パートタイム
    • 雇用
      • 社内でのアプリ企画の作成
      • アプリ外注のやりとり、社内での担当者
    • フリーランス
      • クラウドワークスなどで、都度案件を取る
      • 開発情報のエバンジェリスト(講演、著作、セミナー)
  • たまに使うかも?
    • 雇用
      • なんか、企画出すときの知識くらい?
    • フリーランス
      • 場面を思いつかない。たまにしか使わないなら、iOSなんて時間のかかる学習に時間をかけるの、正直、無駄でしょ。

フルタイムとなると、絵や音楽、画面設計やコーディングを含めた専業開発があります。専業開発者の雇用形態は、企業もしくはフリーランスのいずれでも、ありうります。ここでのフリーランスは、個人で事業をする個人事業主の意味です。自分で会社をたちあげて起業した場合でも、法人のなかで経営者(ひょっとすると開発者も)をするので、これは雇用に分類して、ここでは区別はしません。

事業のためのiOSアプリならば、その企画保守運用の担当者も、フルタイムに区分できるでしょう。これは、フリーランスでは、まずありえない形態です。

###収益の流れをみてみる
次に収入で考えてみましょう。まず一人が生活する最低限の収入は、地域格差はありますが、病気や老後への備えを無視しても、最低でも年間400万円は必要でしょう。

収益の仕組み、を考えておくことが重要です。

  • 開発の成果物を収益とするもの
    • AppStoreで販売
      • 新規ユーザが増えてる場面なら、既存アプリが売れる。
      • 飽和した時が、考えもの。運用保守で、あるいは利用される都度、収益が取れるアプリでなければ、潰れる。
    • どんなアプリでも開発しますな受託
      • 開発し続けなけばならない。
      • 都度発生する顧客との打ち合わせコストなど、効率は最低。
      • 自社の得意分野があり開発リソースを使いまわしできない限り、長続きは、しない。立ち上げ期の一時的な収益確保には使える。
  • アプリを使ってもらうことで、収益が発生するもの
    • いわゆるソーシャルやゲーム、広告表示など
    • 自社事業のアプリ
      • 賃貸の物件検索など、本質、販売者と購入者をつなげる手数料が収益源の事業は、iOSアプリと相性がいい

専業開発者かつフリーランスでiOSアプリのストア販売収入であれば、有料85円のアプリを年間6.7万DLする必要があります。ユーザ数が爆発的に伸びている間は、新規ユーザがアプリを購入するため、伸びしろが期待できます。ユーザ数が飽和すると、バージョンアップで新規購入が期待できない場合は売上が急速に激減します。またアプリがサーバを利用する場合は、広告やユーザの行動履歴が収益になるものでなかれば、その保守運用費用で潰れます。

受託開発は、いまのiOSではSDKの機能が多くなり、現時点で、すでに個人で開発できる規模を超えていると思います。サーバとクライアント、iOSアプリと画面設計が全て独りでできる人は、とても数が少ないですし、またそのような人は、すでに仕事を沢山抱えていて、半年以上の待ちだったりします。外注先として、その人でなければならない、よほど特殊な合理的な理由がないかぎり、待ってられないでしょう。

数人で開発会社を起業した場合、デザインと開発と営業で担当を分けて、それぞれの領域で、時間あたりの案件処理件数を効率化して拡大することになります。複数人で事業として運営するならば、受託開発はありでしょう。1回開発したものを顧客ごとにちょっとカスタムすれば製品になる立場が得られれば、収益率が上がるでしょう。

###事業のアプリ活用に関わってみては?
賃貸やピザ配達などで、iOSアプリを活用する事例があります。賃貸の手数料が、家賃1ヶ月分で仮に6万円とすれば、極端な表現をすればアプリでワンクリックされれば6万円の収益が得られるわけです。これは、85円のアプリを1000本販売したのと同じ収益です。

自社の事業のためのアプリは、今後、あって当たり前になるでしょう。現在はまだ、ウェブサイトでネイティブ同等の使った時の快感が出せるほどの応答速度は出ません。クーポン発行も、まだ10年は電子メール併用でしょうが、そのうちに、アプリ連動でプッシュするあなただけの特別な個人にカスタムした発行が当然になっていくでしょう。それらは、アプリをインストールしないと、実現できないものです。

社内でのiOSアプリ担当では:

  • 企画、見積りと予算確保
  • 開発、導入、運用
  • 破棄

があります。ソフトウェアの企画は、それが使われて、破棄されるまでの流れで、とらえます。ライフサイクルのソフトウェア・ライフサイクル・プロセス, IT用語辞典 e-Wordsなど規格もあります。

iOSアプリの開発は、Windowsのアプリ開発とは、全く違います。外注で外に出して納品されれば数年は小さな改修だけで使い続けるようなものではありません。外にいるお客向けの店舗のように、必要に応じて全く違うものを開発する必要すら、生まれるでしょう。

そのようなアプリを運用していくには、その事業をよく知っている社内の人間が関わるほか、ありません。現在のiOSアプリとの関わり方としては、コーディング自体はできなくても、企画から破棄までの流れを自社事業視点で説明ができる能力を身につけ、部署を立ち上げ、そこのヘッドとして立ち位置を強めていくのが、最良でしょう。その会社の事業が継続する限り、顧客への情報流通という、最強の立場が得られます。取締役への確実かつ最短の経路です。

このほか

9ページ目からアプリの設計のプレゼンがはじまります。色々話しましたが、冒頭30分だけでこの分量になり、残り4時間分を書くのは大変なので、ここで筆を置きます。

発想法

  • KJ法
    • 文化人類学者川喜田二郎がデータをまとめるために考案した方法。収集した情報を小さなカードに書き、それをグループ化、分類する過程を通して、知見を得ていく発送方法。得られる結果がぼんやりしているときに、収集したデータから浮き彫りにするときなどに役立つ。
  • マインドマップ
    • 発想を木構造に広げて書き出す思考・発想の表現方法。私には、木構造を色や太さで絵的に表現するところに価値があるように思うので、PCなどのソフトウェアもあるが、手書きが一番だと思う。
  • ファシリテータの道具箱
    • ファシリテーションとは、会議やミーティングで、発現や参加の促進、話の流れの整理や認識のまとめなどをすること。そのための分析や可視化の手法が列挙されている。

デシケータで真空脱泡(メモ)

前職で実験室でちょっと脱泡するときに真空デシケータ+真空ポンプを使っていたので、メモ。

ググると自作している人がいる:

デシケータは実験用の樹脂製のもの。ポリカーボネートがもたない溶媒や高温なものには使えない。

デシケータには、穴が開いた板が底に欲しい。泡で樹脂が溢れても、その樹脂が下に流れていれば、容器が樹脂に沈まずに取り出せる。真空計があると、動作を目視できるので便利。

デシケータとポンプを組み合わせるのもあり:

デシケータは、いろいろある。

真空ポンプは、オイルレスがいい。ミストフィルタをつけておくのもありだけど。

ポンプは、オイルを使うロータリーポンプと、ダイアフラム型のものがある。ロータリーポンプは安価でよく引く。オイルミストを入れれば、オイルの飛沫が舞うこともないし、逆流防止機能がついているから、オイルが装置側に逆流することもないのだけど、油が入ってるのが心理的に抵抗感がある。ダイアフラム型は、その点は、安心。脱泡用途なら十分引く。

真空ポンプというほど引かないけど、真空ピンセットとかに使ってたやつ:

  • リニコン真空ポンプ
    • 2万円くらい
    • -33kPaで、大気圧の1/3くらいしか引かないけど、サンプルのチャックとかに使ってた。手のひらサイズで外付けのコンデンサもないので、手軽ではある。

デシケータとポンプは、チューブでつなぐ。間にT字バブルを入れて、排気したあと、ポンプにつながっているチューブを大気圧に戻す(オイルを使っていないなら、不要かもだけど)、またデシケータを大気圧に戻せるようにしておく。

StoryBoardとAutoLayout

  • StoryBoard
    • 画面設計と画面遷移
    • セグエ
  • AutoLayout

ドキュメント

AutoLayout

メモ:

  • WWDC 2012 Session 202, Introduction to Auto Layout for iOS and OS X

    • View階層に関係なく、見た目の任意のView間で制約をかけられる
      • View階層の共通の親がConstrainを持つ
    • 優先度が設定できる(デフォ 1000)
    • 35:23,コーディングで制約をASCIIアートで表現可能( H:[View1]-10-[View2] みたいに)
  • WWDC 2012 Session 228, Best Practices for Mastering Auto Layout

    • コードでViewを移行する
      • [view setTranslateAutoresizeMaskIntoConstrains:NO]
      • -(void)layoutSubviews { フレームサイズや位置の設定 }
    • デバッグ
      • IBは制約の矛盾や不足を自動で手当。手動コーディング時は、ログを見るなど。
      • [view hasAmbigousLayout]
      • [view exerciseAmbiguityInLayout]
      • [window visualizeconstrains:@[]]
      • [view constrainsAffectingLayoutForOrientation/Axis:…]
    • 矛盾する制約はサイズを0にする
      • foo.height = foo.width * 2
      • foo.width = foo.height * 3
      • この制約を満たす値は、0。Viewは表示されない。
    • アニメーション
      • CoreAnimation、Layout制約、いずれか。
      • Layout制約でアニメすると、制約を守ったまま、遷移する。
    • インターナショナル
      • 言語の向きに合わせて、制約の方向が自動切り替え
        • ボタンのテキストサイズとか、制約により自動で幅設定
        • 左から右に書く言語での制約なら、逆の向きに書く言語なら、左右対称で反転

更に進んだ話題:

  • Session 219 Advanced Collection Views and Building Custom Layouts

棚のような表示をするCollectionViewControllerのレイアウト部分をカスタムにすることで、円形に並んだ要素や、写真のフロー表示など、自在な表示をさせている。

AutoLayoutを使うべき?

現在のiOSの開発でのメリットは、

  1. iPhone5とiPhone4S以前の縦方向のサイズを、コードで区別する必要がなくなる
  2. 縦向きと横向きの画面を、レイアウトと制約ベースの設計にすると、楽かもしれない

適当なタイミングで切り替えてもいいのでは?程度。
ただし、Appleは、大きな切り替えが必要になるフレームワークを、それが必至になるハードウェアが出てくる前に、2年ほど先駆けて公開してくる。

おそらく来年、遅くても再来年には、AutoLayoutを使わないとやってられない、画面サイズの種類の多様化(縦方向サイズが3種類以上になる、あるいはベゼル部分までピクセルが拡張されて横幅比率が非整数なものが出る)、状態になるだろう。

ゲーム開発のように、OpenGLやCocos2dなどで、独自の画面設計をするものならば、使わない画面領域を黒色にしておくなどで、対応ができるだろう。

iOSのViewを使う通常アプリは、メインのViewの高さをAutoLayoutで可変にする手順を、テンプレ化して、使っていけばいいだろう。

CoreAnimationの概要理解と解説

  • Blocks
    • 概要の理解、さらりと。CoreAnimationで必要になれば、また戻って。
  • UIViewクラスのアニメーション
    • 基本のアニメーションを押さえます。
  • ViewControllerの紹介
    • アニメーション効果をふんだんに使っているCollectionViewControllerを紹介します。
  • CoreAnimation
    • 文書ベース、WWDCのデモ動画で動いてるところを見ながら理解
    • タイミングとパターンの指定方法。作りこみに必要っぽいのでそこを重点的に。

白板

ドキュメント

Blocksの概要

UIViewのアニメーションをするなら、Blocksを使うほうが圧倒的に便利。Delegateとの違いは:

  • アニメーションの処理を、その場 でかける
    • この部分はbeginAnimation/commitAnimationで囲むだけのdelegate利用と同じ
  • アニメーション終了時の処理を、その場でかける
    • ここが大きい。イベント処理の連結にBlocksは便利。
    • 次のアニメーションにつなげるなど。
    • delegateは、処理完了が1つのメソッドに集中する。そのため、コンテキストを渡して、どの文脈のアニメーションかをメソッド内部で判別しなければ、ならない。とても手間&コードの場所が別れるため、コードがとても読みにくい。
  • 変数を渡せる
    • Blocksは、変数を渡せる。デフォルトで読み込みのみ。書き戻したい時は__blocks修飾子をつける。
      • 変数は、値型(intやdoubleなど)と参照型(インスタンスなど)がある。
      • 値型を書き戻す用途は、多分ない(変更タイミングがわかんない書き戻しはしないだろう)
      • 参照型(インスタンス)は、そのメモリポインタからのメソッド呼び出しは自由だから、書き戻しを意識することなく、普通に使えばいい。

UIViewのアニメーション

WWDC 2010 Session 123 Building Animation Driven Interface

アニメーションを書く場所。View内部のアニメーションなら、View自体に書いたほうが、すっきりする。複数のViewを動かしたいなら、ViewControlleに書く方がいい。

やり方は、[viewController layoutIfNeeded]で-(void)layoutSubViews {} ?(やったことないから、わかんない)

ViewController

今では、ViewControllerで、必要な表現は間に合うようになっています。UIViewでは実現ができないアニメーションが必要になる場面は、ほとんどありません。ViewControllerは、次の2つのドキュメントを参照します:

UIViewCollectionController

iOS6から、iBooksのような、グリッドのレイアウト・コントローラが導入されました。その解説スライドは:

  • WWDC 2012 Session 205 Introducing CollectionViews
  • WWDC 2012 Session 219 Advanced Collection Views and Building Custom Layouts

です。Session205は、グリッドレイアウトの使い方を解説しています。APIはUITableViewと同じ、DataSourceを提供して、Cellは再利用されます。Cellは同じ幅である必要はありません。レイアウトを柔軟に配置をしてくれます。
TableViewででもですが、iOS6から、セル名をクラス名にしておけば、reusablel cellは、内部でインスタンスが作られるので、nil判定をする必要はなくなります。

Session219は、更に進んだCollection Viewの使い方です。レイアウトの制御コードを与えることで、グリッド以外の、写真やCDアルバムの表示に使われるフリップや、アイテムを円形に並べるなど、アイテムの任意のレイアウトが実現できます。

このCollection Viewと同等の表示を自分で実装するのは、大変です。それは、これがレイアウトに加えて、その表示のアニメーション、必要な数だけCellをつくり、またCellを再利用するという、付属の制御部分がかなりの量があり、UIViewでアニメーションで作れる、といった類のものではないからです。

コレクションの表示の時に、活用してください。

CoreGraphics(描画)

CoreImage

WWDCの動画を見るのが、てっとりばやい。CoreImageは、動画のフィルタ効果にも使える汎用の画像処理フィルタの仕組み。
CoreImageを使うなら、QuartzComposerを使うのもいいかも。CoreImageのフィルタを適用した時のプレビュツール。

4.5.2のXcodeでは、デフォルトでははいっていなくて、別にインストールする。

の一番下のを選ぶとブラウザが開く。
Graphics Tools for Xcode(いくつかあるので最新版を選んで)ダウンロードして展開すると、QuartzComposerがある。いっしょにOpenGLの最適化ツールもあるので、グラフィックな開発をするなら落としておくのがいいかも。

CoreAnimationをマスターしたい方には

Githubにあるサンプル・コード:

  • Core-Animation-Demos 基本のアニメーションが押さえてあるので、これ1つでOKだと思う。

静電容量分布を測るのに便利なmtouch、製品ラインナップ一新しすぎですorz

お手軽静電容量の評価

iPhoneを始めとするスマートフォンが身の回りにわんさと溢れかえり、タッチパネルが当たり前となっていますが、いまどきなタッチパネルが採用している方式は、ほぼ静電容量方式です。iPhoneサイズで5点、iPadサイズで10か11点検出がデフォルトとなっています。

液晶とタッチパネルが一緒だったのが、今はインセルタイプという、液晶と一体化したものまで登場していて、お金が動いている市場があれば、なんでも作ってきちゃうものだなと思うこのごろです。

ガジェット開発のために面分布を知りたい

さて、そんなiPhoneのタッチパネルと連携するガジェットを開発していると、“いまの静電容量の面分布はどれくらいだ?”と客観的に知りたくなるわけです。iOS SDKで取れるタッチ情報は、タッチした/していないの0/1情報だけです。そんな0/1情報だけでは、この作りがいいのか、わるいのか、どっちの方向に進めばいいのか、まったく判断のあてになりません。

できればiPhoneのパネルを使って、パネル評価に使ってそうな測定装置を買ってきて、実機相当の測定がそのままできればいいのですが、まずiPhoneのタッチパネルのコネクタピン配置なんて、ググっても出てこず、見つけるのが一苦労しそうです (コネクタは見つけたので、今度やってみようと思いますが) そして静電容量の測定装置も、お手軽価格とはいえず…

静電容量方式のタッチパネルの開発キットのゲット、結構大変

そうなれば、静電容量方式のタッチパネルの開発キットをゲットして、その生データ引っこ抜けばいいじゃんと思って探すのですが、一般に販売してくれるところがないのです、これが。Cypress、 ATMEL、Texus Instruments、いろんな会社がタッチパネルのコントローラを販売しています。TI社なんて、代々iPhone採用されるくらいですiPhone 3GS Uses TI Touch Screen Chip

それで、開発キットをくださいません?と問い合わせをすると、年間んー万個売るのが最低条件ね♡、と素敵な返答が返って来ました。そりゃそうですよね、囲い込みたい技術情報を、小口一般を相手に公開するわけがないですよねorz

そんななかで、唯一、一般に開発キットを販売していたのが、Microchip社です。mtouchというブランドで。素敵>ω<

10月にPIC16F707の開発キットmTouch Projected Capacitive Development Kitをゲットしてて、これが3.5インチのタッチパネル+センサーで、デモソフトが自己容量と相互容量の生データ表示と、まさにこれが欲しかったのよの、素敵すぎる仕様です。

PCからはUSBシリアルで見えてるから、あとはシリアルからデータをひっこぬいて表示する独自アプリを作れば、なんでもできると思っていました、10月までは。

ラインナップ一新してますがなorz

それが12月になってみたら、mtouchのラインナップ一新してて、ソフトまで統合されてて、素敵な状況にorz
10点タッチ検出&3Dジェスチャー検出の素敵な石が開発されてて、2013年2月から開発デモキットが出荷される状態みたいです。なんて、はざまにはまったのでしょうかorz

いや、開発キットだから、なくなれば自分で作れっていうものなので、これくらいの変化は仕方ないんでしょうけどね…

オーバレイのタッチパネルなら3Mのが便利

余談ですが、タッチパネルを簡単に使いたいなら、3MのMicro Touch Systemがおすすめ。
3Mは抵抗方式のもだしているけれど、それではない方式のもの。Digikeyで購入できるのが、素敵です。

http://www.digikey.com/scripts/dksearch/dksus.dll?FV=fff40008%2Cfff802ca%2Cfffc0013&k=3m+touch&vendor=0&mnonly=0&newproducts=0&ptm=0&fid=0&quantity=0&PV-5=22891&PV-5=22892

原理は、容量検出のはずだけど、説明を読んでても、実物を見ても、よくわからない。
サイズは、7インチから32インチまで、タッチは20~60点の同時検出。
コントローラはシリアルとUSB接続があって、どっちも信はシリアルなデータ垂れ流し状態。

タッチ情報を、ドライバ経由でWindowsに持って行く事もできるし、3Mが出している開発キットを使ってタッチ点やジェスチャのデータをWindowsを介さず直接とりだすこともできる。(C++のサンプルとlibがある)。なかなか便利。

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時間もかからずに、解決できるでしょう。