TAKASHINGS BLOG

仕事のこととか日記とか。映画大好きです。

現場のためのSwift4 Swift4.1+Xcode9.3 対応 <正誤表>

現場のための Swift4 Swift4.1+Xcode9.3 対応 <正誤表>


●146ページ 「ライフサイクルメソッドで呼ばれるメソッド」1行目

【誤】 viewDidLoad:インスタンス化された直後
【正】 viewDidLoad:ViewControllerが自身のViewをメモリ上にロードした直後

●157ページ 本文1~4行目

【誤】
これは「print(array[4])」の箇所でエラーが発生します。理由は array が格納している数に対して、それ以上の箇所へのアクセスを行おうとしているためです。あるはずのない箇所=nil へのアクセスを行おうとしているため、クラッシュしてしまいます。

【正】
これは「print(array[4])」の箇所でエラーが発生します。理由は array が格納している数に対して、それ以上の箇所へのアクセスを行ったためです。配列のインデックスの範囲外にアクセスしようとした場合、実行時にクラッシュしてしまいます。

●179~180ページ 本文8行目以降、コード「役割は関数だが、変数として利用したい場合の一例」の最後まで

【誤】
また、クロージャーの一番の使いどころは、関数としての役割を持ちながらも変数として扱いたい場合です。
▼役割は関数だが、変数として利用したい場合の一例[sample-6-8-5.playground]

struct MyStruct {
    var valueOne: Int = 50
    var valueTwo: Int = 55

    // 2つの変数の和が 100 を超えているか判定
    var isOverTotalHundred: Bool {
        return (valueOne + valueTwo) > 100
    }
}

let myStruct = MyStruct()
if myStruct.isOverTotalHundred {
    print(myStruct.valueOne)
} else {
    print(myStruct.valueTwo)
}
// 50(myStruct.valueOne の値を表示)

本来であれば関数として定義しますが、変数として関数の振る舞いを行います。また、変数には値を保持する必要はありません。関数を意識せず変数のように扱えることがポイントです。

【正】
上記内容を削除
理由: 該当箇所はクロージャーについて解説している内容を記載していましたが、サンプルコードの使用方法ならびに、それに付随する解説はクロージャーではなく「計算型プロパティ(computed property)」の使用例、解説となります。深くお詫び申し上げます。
計算型プロパティは一見変数のように見えますが、中身はメソッドのように特定の処理を行うものです。クラス、構造体、列挙型で定義することが可能です。また、計算型プロパティは特定の値を保持することができないという特徴もあります。

●194、195ページ ▼UIViewControllerのviewと同じサイズのUIViewを追加する一例 ソースコード

【誤】

// 上、右、左、下の順でNSLayoutConstraintを使用して制約を付ける
layoutView.addConstraint(NSLayoutConstraint(item: self.view,
                                          attribute: NSLayoutAttribute.top,
                                          relatedBy: NSLayoutRelation.equal,
                                          toItem: layoutView,
                                          attribute: NSLayoutAttribute.top,
                                          multiplier: 1.0,
                                          constant: 0))

layoutView.addConstraint(NSLayoutConstraint(item: self.view,
                                          attribute: NSLayoutAttribute.right,
                                          relatedBy: NSLayoutRelation.equal,
                                          toItem: layoutView,
                                          attribute: NSLayoutAttribute.right,
                                          multiplier: 1.0,
                                          constant: 0))

layoutView.addConstraint(NSLayoutConstraint(item: self.view,
                                          attribute: NSLayoutAttribute.left,
                                          relatedBy: NSLayoutRelation.equal,
                                          toItem: layoutView,
                                          attribute: NSLayoutAttribute.left,
                                          multiplier: 1.0,
                                          constant: 0))

layoutView.addConstraint(NSLayoutConstraint(item: self.view,
                                          attribute: NSLayoutAttribute.bottom,
                                          relatedBy: NSLayoutRelation.equal,
                                          toItem: layoutView,
                                          attribute: NSLayoutAttribute.bottom,
                                          multiplier: 1.0,
                                          constant: 0))

【正】

// 上、右、左、下の順でNSLayoutConstraintを使用して制約を付ける
self.view.addConstraint(NSLayoutConstraint(item: self.view,
                                       attribute: NSLayoutAttribute.top,
                                       relatedBy: NSLayoutRelation.equal,
                                       toItem: layoutView,
                                       attribute: NSLayoutAttribute.top,
                                       multiplier: 1.0,
                                       constant: 0))

self.view.addConstraint(NSLayoutConstraint(item: self.view,
                                       attribute: NSLayoutAttribute.right,
                                       relatedBy: NSLayoutRelation.equal,
                                       toItem: layoutView,
                                       attribute: NSLayoutAttribute.right,
                                       multiplier: 1.0,
                                       constant: 0))

self.view.addConstraint(NSLayoutConstraint(item: self.view,
                                       attribute: NSLayoutAttribute.left,
                                       relatedBy: NSLayoutRelation.equal,
                                       toItem: layoutView,
                                       attribute: NSLayoutAttribute.left,
                                       multiplier: 1.0,
                                       constant: 0))

self.view.addConstraint(NSLayoutConstraint(item: self.view,
                                       attribute: NSLayoutAttribute.bottom,
                                       relatedBy: NSLayoutRelation.equal,
                                       toItem: layoutView,
                                       attribute: NSLayoutAttribute.bottom,
                                       multiplier: 1.0,
                                       constant: 0))
●214ページ 「イベント通知の身近な例」2行目

【誤】 NSNotificationCenter
【正】 NotificationCenter
※Swift 3.0 より Foundation Framework に含まれる一部のクラス、プロトコルから接頭辞の NS が削除されました。Swift では NotificationCenter を使用します。

●215ページ 1行目

【誤】 NSNotificationCenter
【正】 NotificationCenter

●215ページ 図7-2-1の表題及び図の内部

【誤】 NSNotificationCenter
【正】 NotificationCenter
※Swift 3.0 より Foundation Framework に含まれる一部のクラス、プロトコルから接頭辞の NS が削除されました。Swift では NotificationCenter を使用します。

●223 ページ ▼ SwitchCell クラスファイルにデリゲートメソッドのプロトコルを追加 3 行目

【誤】 protocol SwitchCellDelegate {
【正】 protocol SwitchCellDelegate: AnyObject {
※「AnyObject」の箇所は「class」と書くこともできます。Xcode で「class」の定義にジャンプすると「AnyObject」の定義が表示されるようになっています。

●224ページ ▼SwitchCellクラスファイルにデリゲートメソッドのプロトコルを追加 3行目

【誤】 var delegate: SwitchCellDelegate? = nil // 変数を追加
【正】 weak var delegate: SwitchCellDelegate? = nil // 変数を追加
※循環参照が発生し、メモリリークとなる恐れがあるため。

●229ページ ▼NSNotificationCenterクラスを利用した通知の一例 コードのタイトル

【誤】 NSNotificationCenter
【正】 NotificationCenter
※Swift 3.0 より Foundation Framework に含まれる一部のクラス、プロトコルから接頭辞の NS が削除されました。Swift では NotificationCenter を使用します。

●229 ページ ▼ NSNotificationCenter クラスを利用した通知の一例 1 行目

【誤】 NSNotification.Name
【正】 Notification.Name

●232 ページ ▼ FirstViewController クラス内で行う通知元の設定 6~7 行目

【誤】 NSNotification.Name
【正】 Notification.Name

●233 ページ ▼ SecondViewController クラス内で行う通知元の設定 下から 2~3 行目

【誤】 NSNotification.Name
【正】 Notification.Name

●233 ページ ▼ FirstViewController クラス内で行う通知先の設定 下から 3~4 行目

【誤】 NSNotification.Name
【正】 Notification.Name

●234 ページ ▼ SecondViewController クラス内で行う通知先の設定 下から 3~4 行目

【誤】 NSNotification.Name
【正】 Notification.Name

●485 ページ ▼ iOS のバージョンの分岐処理 3 行目

【誤】 self.navigationItem.title = "記事一覧"
【正】 self.navigationItem.title = "最新記事"

●517ページ 5行目、及び下から2行目

【誤】 ProvisioningFiles
【正】 Provisioning Profile

●518ページ 「ProvisioningFiles」作成の流れ タイトル及び下から2行目

【誤】 ProvisioningFiles
【正】 Provisioning Profile

●518ページ 本文2、3、5行目

【誤】 ProvisioningFiles
【正】 Provisioning Profile

<本書サポートサイト>
http://www.shuwasystem.co.jp/support/7980html/5442.html

<本書に関する補足記事>
http://takashings.hatenablog.com/entry/2018/06/08/002712

「現場のためのSwift4」の訂正・補足

「現場のためのSwift4」(以下、本書)の発売から2週間あまり経ちました。 多くの書店様へご挨拶へ伺うと、複数冊置いていただいたり、書店様によっては「売れていますよ」と教えていただくこともありました。

ご購入いただきました皆様本当にありががとうございます。

現場のためのSwift4 Swift4.1+Xcode9.3対応

現場のためのSwift4 Swift4.1+Xcode9.3対応

また、何人かの方に書評も書いていただきました。 この場を借りて、御礼申し上げます。

blog.personal-factory.com

egg-is-world.com

medium.com

ここからが本題ですが『「現場のためのSwift4」を読んだ by @takasek』の記事にていくつかご指摘をいただきました。

今回はこのご指摘いただいている項目の一部の補足説明をさせていただきたいと思います。 なお、今回訂正・補足の対象は記事内の「nilについて」「継承について」の2点となります。

この2点を取り扱ったのは以下の理由からです。

  • Swiftでは避けて通れない「nil」に対して本書での書き方に不明瞭である部分があったこと
  • 継承で取り扱っている「BaseViewControllerの設計」は現場においてアンチパターンである場合があること
  • また、そのアンチパターンに対する代替案を(個人的に)提示すべきだと判断したため

nilについて

第6章:6-3 nilについて 138P

▼定数の定義時にnil を代入しようとしてもエラーが発生する
let str: String = nil

そもそも、nilは「存在しない」という意味があります。コンパイラは存在しないものを操作しようとすると、どうしていいかわかりません。そのため、コンパイラのレベルでnilの操作を行うとエラーが発生します。

ここで押さえておくべきことは「nilに対する操作はクラッシュする」ということであり、Swiftではコンパイラがnilの扱いを厳密にチェックしているということです。

上記の文章に対して記事内にて以下のご指摘をいただきました。

nilの操作」が何を指すのか不明ですが、少なくともクラッシュすることはありません。

この点について、補足説明いたします。 まず「nilの操作」について補足説明をいたします。「nil」をあたかもコントロールできるように受け取りかねない書き方となってしまったこと、そして適切ではない表現だったことをお詫びいたします。この箇所を訂正する場合「nilへのアクセス」という言葉が適切ではないかと考えています。

冒頭のコード「let str: String = nil」ですが、この一文でアプリがクラッシュすることはありません。 nilを許容しない非Optional型にnilを代入しようとする処理(コード)に対して、ビルドをする前の段階でコンパイラーがエラーを出します。

では、どのような場合にクラッシュするのか。 それはプログラム(アプリ)実行時に発生するランタイムエラーを検出した際にクラッシュします。

import UIKit

// viewDidLoadなどで実行
var myLabel: UILabel!      // nilを許容するOptional型で定義 
myLabel.text = "label"      // ここでエラー

上記のコードでは、コンパイル時にはエラーは検出されません。

プログラム実行時、nilを許容するUILabelの変数・myLabelが初期化されないまま(nilの状態)、「myLabel.text = "label"」で文字列を設定しようとしたため、ランタイムエラーが発生します。

なお、ランタイムエラーはnilにへのアクセスを行おうとする以外にも、型変換を行おうとした際に正常に型変換が行うことができなかった場合なども同様にランタイムエラーになります。

まとめると、nilを許容しない変数へのnilの代入は、ビルド前の段階でコンパイルエラーが発生。 また、コンパイル時にはエラーとならず、プログラム実行時に意図的に(または意図せず)nilへのアクセスを行おうとすると、ランタイムエラーが発生し、アプリがクラッシュします。

○継承について

第7章:継承と拡張 238P

class BaseViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        
        // 戻るのテキストを設定
        navigationItem.backBarButtonItem = UIBarButtonItem(title: "戻る", style: UIBarButtonItemStyle.done, target: nil, action: nil)
    }
}

本書内で例を挙げた上記の「BaseViewController」の設計の採用はデメリットが多い、BaseViewControllerの設計を採用すべきではないとのご指摘をいただきました。以下、@takasekさんの記事から引用させていただきます。

継承という仕組み自体の解説としては間違っていないのですが、BaseViewControllerという設計にはデメリットが多いという議論もされています。私もBaseViewControllerは使うべきではないと思っています。なぜなら、こういった処理の共通化のための継承は、例外的なサブクラスの存在を許さず、変更に極端に弱いコードになってしまいます。また責務が不明確なため、容易に肥大化の道を辿り手がつけられなくなります。

「BaseViewController」の設計は共通化を目的にするあまりに肥大化してしまう可能性が高く、細かい変更に対応できずに、「BaseViewControllerA」「BaseViewControllerB」などの派生クラスを作成しかねない、メリットを十分に活かせずにデメリットとなってしまいます。

そのため、「BaseViewController」の一例が「現場」という観点では、今回の継承の例として挙げる例では不適切でした。お詫び申し上げます。

では、どのようにするのが好ましいでしょうか。 一例として、プロトコルを用いた実装が挙げられます。

Swiftには「Protocol-Oriented Programming」(プロトコル指向)という思想・考え方があります。 大まかに言うと「継承によって型の性質を定義するのではなく、プロトコルを用いて型の性質を定義する」ものです。

継承で使用した「BaseViewController」の戻るボタンを共通化する場合を例にしてみたいと思います。

// プロトコルの指定。ここには具体的な実装は行わず、関数、変数名のみ記載
protocol NavigationBackButtonProtcol {
    func setBackButton()
}

// プロトコルを指定
class MainViewController: UIViewController, NavigationBackButtonProtcol {
    
    override func viewDidLoad() {
        super.viewDidLoad()
        // 戻るのテキストを設定
        setBackButton()
    } 
    
    // プロトコルで指定した関数の具体的な実装を行う
    func setBackButton() {
        navigationItem.backBarButtonItem = UIBarButtonItem(title: "戻る", style: UIBarButtonItemStyle.done, target: nil, action: nil)
    }
}

上記のように、プロトコルには定義のみを書き、それをクラス、構造体、列挙型に指定して実装を行います。

継承は親クラスに指定した変数や関数全てが継承されます。仮に使わない変数や関数があったとしてもです。 プロトコルでの実装では、プロトコルごとに性質(変数や関数など)を決め、それをクラスに指定することができます。

継承と異なる点は、親クラスによってクラスの性質を決めるのではなく、プロトコルによって付けたい機能や性質などを決めるという点です。

また、プロトコルの内容を共通化したいのであれば、以下のようにextensionで具体的な実装を行うことで各クラスごとに実装内容を書く必要がなくなり、プロトコルの指定と関数の実行のみを書くことで実現できます。

// プロトコルに書いた関数の具体的な処理を記述
extension NavigationBackButtonProtcol where Self: UIViewController {
    func setBackButton() {
        navigationItem.backBarButtonItem = UIBarButtonItem(title: "戻る", style: UIBarButtonItemStyle.done, target: nil, action: nil)
    }
}

// プロトコルを指定
class MainViewController: UIViewController, NavigationBackButtonProtcol {
    
    override func viewDidLoad() {
        super.viewDidLoad()

        // 戻るのテキストを設定
        setBackButton()
    } 
}

簡単ではありますが「BaseViewController」の例と似た形での実装方法をご紹介しました。

なお「BaseViewController」を用いた継承の設計は間違いではありませんが、場合によってアンチパターンとなり得ます。

今回は「BaseViewController」に代わる手法の紹介を重視したため、具体的なプロトコル指向について、継承と異なる詳細な相違点などは割愛しました。 気になる方はぜひチェックしてみてください。

以上となります。 最後に@takasekさんの詳細な例を踏まえたご指摘ありがとうございました。

なお、今回いただいたご指摘の他に、本書内の一部内容に誤りが記載されていたため、正誤表を掲載しています。正誤表は下記のリンクからご確認いただけます。 ご購入いただきました皆様は下記のリンクからご確認をお願いいたします。

www.shuwasystem.co.jp

5/22発売の拙著「現場のためのSwift4 ~実務で「本当に」通用する開発者になるための教科書~」はこんな人に読んで欲しい #Swift不可欠本

f:id:takashings:20180508212914j:plain

いよいよ、2018年5月22日の発売まで2週間を切りました。

拙著「現場のためのSwift4 ~実務で「本当に」通用する開発者になるための教科書~」がもうすぐ書店に並びます。

 

この記事では、どのような人に読んで欲しいのか(つまり、主なターゲット層)、本書にどういう内容が書かれているのかを解説したいと思います。

 

どのような人に読んで欲しいのか

本のタイトル「現場のためのSwift4 ~実務で「本当に」通用する開発者になるための教科書~」とあるように、この本は主にiOSアプリ開発で用いられる開発言語・Swiftの開発本です。

そして、初心者本と異なるのは現場を意識した内容です。つまり、実際のiOSアプリ開発現場(実践)で使える知恵・情報が書かれている本でもあります。

 

発売告知をした記事にも書きましたが、以下の方が主なターゲットとなります。

  • 個人でiOSアプリ開発を本気で取り組もうとしている方
  • iOSアプリ初心者本を読み、次のステップへ上ろうとしている方
  • iOSアプリの仕事にこれから携わろうとしている方
  • iOSアプリ開発現場の全工程を知りたいと思っている方(ディレクター、PMの方など)

「初心者の方が開発初心者本を読んで、次に読む本」という位置づけです。

具体的に言うと「脱初心者したい方向けの本」「初心者の方が中級者への階段を上がるための本」として想定しています。

 

本書の概要

本書は全13章で構成されています。

開発の「企画」「設計」「実装(プログラミング)」「運用」まで、開発工程の最初から終わりまで網羅して書かれています。

  • 第1章:Swiftを使ったiOSアプリ開発の現状と今後の動向
  • 第2章:企画・要件定義
  • 第3章:設計
  • 第4章:プロジェクト管理
  • 第5章:開発効率化
  • 第6章:iOSアプリ開発のためのSwiftプログラミング その1
  • 第7章:iOSアプリ開発のためのSwiftプログラミング その2
  • 第8章:総合演習・iOSアプリ開発 カメラアプリ その1
  • 第9章:総合演習・iOSアプリ開発 カメラアプリ その2
  • 第10章:総合演習・iOSアプリ開発 ブラウザアプリ その1
  • 第11章:総合演習・iOSアプリ開発 ブラウザアプリ その2
  • 第12章:リリース準備〜アプリケーション公開
  • 第13章:リリース後の対応とアップデートについて

全部で550ページほどあり、かなりボリュームがある内容になっています。第6章〜第12章までのプログラミングについて書かれている部分とそれ以外(第1章〜第5章、第12章、第13章)の部分の割合はだいたい半分半分です。

 

章のタイトルだけでは何が書かれているか不透明なので、簡単ではありますが、解説していきたいと思います。

 

第1章:Swiftを使ったiOSアプリ開発の現状と今後の動向

この章では主にSwiftの優位性について書きました。

また、この本のテーマである「開発全体の工程を知ることが大切」ということについても詳しく解説しています。

 

第2章:企画・要件定義

どんなプロダクトでもまずは企画から開発はスタートします。

この章では企画とアプリでどういうことをしたいかをまとめた要件の定義について触れています。

なお、企画の出し方、作り方、アイデアの出し方など具体的な方法論については言及していません。

 

第3章:設計

主に仕様、画面遷移、データモデル設計について解説している章です。

仕様を決める時にはどういうことに気を付けたらいいかなどについても書かれています。

例えば、iOSアプリを作るときにはサポートするiOSのバージョンを決める必要があります。ただアプリを作るだけでなく、どういう環境で動作するかなども考慮する必要があります。このような初心者の方が気付きにくいポイントなどを紹介しています。

 

第4章:プロジェクト管理

まず、プロジェクト管理の方法論については書かれていません。

この章では、プロジェクト進行管理の必要性、開発現場でよく聞く工数の算出、予期せぬ事態の対応、外部ライブラリツールの紹介などを中心に書いています。

個人的には工数の算出は開発現場で求められるスキルの1つだと思うので、ぜひ読んで欲しいところです。

 

第5章:開発効率化

ここでは、Xcodeのショートカット、iOSシミュレーター、ブレークポイントについて解説している章です。

注目して欲しい点として、開発には絶対的に欠かせないブレークポイントについて解説しています。これがないと仕事にならないので、初心者の方はぜひチェックしてください。

 

第6章・第7章:iOSアプリ開発のためのSwiftプログラミング 

第6章と第7章はSwift初心者の本にも書かれている内容を少し交えながら、文法や記法などを紹介する基礎パートに加え、クロージャーやエクステンションなどの応用パートについても解説しています。

また、Swift 4.0やSwift 4.1で改良された点についても紹介しています。

記事投稿時(2018年5月11日現在)、Swift 4.1対応の開発本はこの本だけかと思います。


第8章・第9章:総合演習・iOSアプリ開発 カメラアプリ

ここからは総合演習。実際にサンプルアプリを作ります。

第1弾はカメラアプリです。他の開発本と違うのは、いきなり作り始めるのではなく、これまでの本で学んだ内容に沿って、開発します。

要件を定義したり、実際に工数を算出してみたりなど実践を交えて開発します。

写真を読み込んで、フィルター加工して、それを保存する、というものを作ります。

 

第10章・第11章:総合演習・iOSアプリ開発 ニュースアプリ

総合演習の第2弾はニュースアプリです。

WordPressAPIを利用して、記事一覧の取得、記事の検索、通知機能の実装を行います。

今の時代、通信処理の実装はほぼ必須と言っても過言ではないです。

その通信処理を用いたアプリをテーマにできればと思い、このサンプルアプリを作る章を作ってみました。


第12章:リリース準備〜アプリケーション公開

アプリをリリースする前の工程であるリリース準備について解説しています。

具体的にはiTunes Connectで用意するデータや情報などについて詳しく書いています。

ここまで詳しく書いた本はないと思います(iTunes Connectの仕様変更があると怖いですが、、、)。リリースするときの心構えやリジェクトされたときのこと、NDAについても触れています。


第13章:リリース後の対応とアップデートについて

最後の章では、運用について解説しています。

ダウンロードを増やすための施策や、アプリをリリースした後のアップデートのことを書きました。

なお、ダウンロードを増やすための施策では、広告を用いた方法については一切触れていません。こういうことをすると、注目される可能性がある、こういうことをすると親切だよ、というようなことを中心に書いています。

 

 

1つ1つの章を解説したので、長くなってしまいましたが、初心者向けの開発本には書かれていない開発現場でしか得られない知識や、現場で求められるスキルについて解説しています。

一通り読むと「こういう風にしてアプリは作られるのか」という流れを理解することもできる本に仕上がっています。個人的にこの本はiOSアプリ開発の教科書のような本だと自負しております。

 

少しでも興味を持っていただいた方はぜひ「現場のためのSwift4 ~実務で「本当に」通用する開発者になるための教科書~」をチェックしてください!

 

何かご質問などありましたら、Twitterでお声がけください。

 

現場のためのSwift4 Swift4.1+Xcode9.3対応

現場のためのSwift4 Swift4.1+Xcode9.3対応

 

 

5月22日に執筆した「現場のためのSwift4 ~実務で「本当に」通用する開発者になるための教科書~」を発売します! #Swift不可欠本

f:id:takashings:20180508212914j:plain

※2018/05/12:表紙とサブタイトル変更のため、一部修正をしました。

 

2018年5月22日にSwift・iOS開発本を出します。
タイトルは「現場のためのSwift4 ~実務で「本当に」通用する開発者になるための教科書~」です!

 

現場のためのSwift4 Swift4.1+Xcode9.3対応

現場のためのSwift4 Swift4.1+Xcode9.3対応

 

 

本書は自分とウェブ開発に従事されている今村哲也さんとの共著で、株式会社MASHの染谷昌利さんに執筆のきっかけをいただきました。

そして、コードレビューには同郷で同じくiOSアプリ開発者の@frnkさんにご担当いただきました。

出版元はIT本やビジネス書でおなじみの秀和システムさんから出させていただきます。


初心者向けに書いた現場で役立つ開発本

エンジニアの方であれば、すでにご存じかと思いますが、アプリの開発現場では、プログラムを書くだけではありません。

 

例えば、プログラムを書くために行う設計や、その前段階の企画・要件定義、そして、リリースした後には運用やiOSのアップデートがあれば、その対応…と、たくさんの工程を経てアプリは開発されます。
本書ではiOSアプリの開発プロジェクトの「企画」「設計」「実装(プログラミング)」「運用」の各工程に沿って、はじめから終わり(運用は続きますが)まで開発現場の知識を紹介 ・解説しています。

 

ターゲットとなる読者、以下のような方向けに書いています。

  • 個人でiOSアプリ開発を本気で取り組もうとしている方
  • iOSアプリ初心者本を読み、次のステップへ上ろうとしている方
  • iOSアプリの仕事にこれから携わろうとしている方
  • iOSアプリ開発現場の全工程を知りたいと思っている方(ディレクター、PMの方など)

執筆した「現場のためのSwift4 ~実務で「本当に」通用する開発者になるための教科書~」は「初心者〜中級者の階段の間の人」に向けて書いています。この読者層の本はおそらく、ほとんどないのではないかと思います。

 

初心者の方がある程度初心者向けの本を読んで、次に何を読んだらいいんだろう?と言ったときにこの本がベストだと思っています。
若干誇張して言うならば、「iOSアプリの開発現場の教科書」のようなものに仕上がった気がします。

 

具体的には、開発の工数見積もりの話、ブレークポイントiOSシミュレーターの使い方、リリース時にやらなくてはいけない手続きまとめ、リリース後の話など、他の本ではあまり書かれていないけど、開発現場では求められているものを詰め込みました。

 

全章の概要をこの記事で書きましたので、興味を持たれた方はぜひこちらをチェックしてみてください。

最新版のSwift 4.1対応です

そして本書はSwift 4.1に対応しています!

主にSwift 4.0を中心に、もちろんSwift 4.1にも触れています。
おそらく、現在出版社から発売されているiOSアプリ開発本でSwift 4.1に対応しているのは今のところこの本だけだと思います。

 

発売まで1ヵ月を切りましたが、ぜひチェックしていただけると嬉しいです。


ちなみに、Amazonではすでに予約が開始されております。
ぜひチェック(予約)してください!よろしくお願いします!

現場のためのSwift4 Swift4.1+Xcode9.3対応

現場のためのSwift4 Swift4.1+Xcode9.3対応

 

 

楽天でもすでに予約開始されています。こちらからどうぞ。


 

UX JAM 24に行ってきた

f:id:takashings:20180227212904j:plain

2018年2月27日、ソフトバンクグループ株式会社さんで行われたUX JAMというイベント・勉強会に行ってきました。
UX JAMはUX(User eXperience)に関するLTを披露する勉強会(わりとゆるゆるな)。今回は2回目の参加で、150人の定員もあっという間に埋まる人気イベント。

 

UXって少し前からのトレンドとなって、今はもう当たり前のようにUX、UXと開発の現場だけでなく、どこでも言っている気がする。

 

だけど、ユーザー体験をいかによくするか?ということに注力するのもいいけど、「サービスやプロダクトはどうあるべきか?どうありたいか?」を考える「プロダクト・エクスペリエンス(「PX」になるのかな?)」も大事だよね、という話を聞いて、ハッとした。

 

例えば、ユーザーにいかに満足度が高くするため、高く維持するために機能を追加したり、デザインを変更したり、アプリではアイコンを変更したり、といろんな施策を実施するけど、それって「プロダクトのアイデンティティ」を崩壊させていることにならない?と問いかけることが大事かもしれない。
使ってもらうユーザーをきちんと見なくてはいけないけど、それを提供するサービス自体が芯が通っていなかったり、このサービスはこうあるべきだというある種の哲学みたいなものを失ったら、サービスの価値って低くなるはず。

 

プロダクトやサービスに対する誇りやブランドみたいなものもデザインしてこその、UXっていうものなのかも、なんて思った。

 

雑感でしかないけど、そんなことを思った。

フリーランス1年目の2017年を振り返ってみました

f:id:takashings:20170813103635j:plain

2017年ももう少しで終わりますね。
2017年を振り返りたいと思います。

フリーランスになった年

2017年5月末に前の会社を辞めてフリーランスになりました。
去年までは自分がフリーランスになるなんて思ってもいなかったですが、2017年末でフリーランスももう半年が経ちました。

フリーランスになってからは1本の中規模なアプリケーションを開発した後に、
縁があって、別の案件にジョインさせていただいています。

今まで仕事をするチームがこれまでは前の会社のメンバーだけでしたが、
はじめましての人と仕事をするのは大変なこともありますが、
とても新鮮な気持ちでした。

2018年はこれまで自分が携わったことがないことをしていきたいと思っています。

映画ライターになりました

フリーランスになる少し前から「シネマズby松竹」というメディアでライターをさせていただいています。
映画を観ることが好きで、これまた縁があって、ライターをさせていただくことになりました。

せっかくなので、2017年観た映画を並べてみたいと思います。
※URLがあるものが映画ライターで記事を書いたものです。

●映画館で観た作品

  1. ファンタスティックビースト
  2. ネオンデーモン
  3. ドクターストレンジ
  4. ミスペレグリンと奇妙なこどもたち
  5. サバイバルファミリー
  6. 恋妻家宮本
  7. マリアンヌ
  8. ラ・ラ・ランド
  9. 素晴らしきかな、人生
  10. 彼らが本気で編むときは、
  11. チア☆ダン~女子高生がチアダンスで全米制覇しちゃったホントの話~
  12. SING/シング
  13. モアナと伝説の海
  14. キングコング:髑髏島の巨神
  15. パッセンジャー
  16. ハードコア(https://cinema.ne.jp/recommend/hardcore2017040306/
  17. レゴバットマン ザ・ムービー
  18. 夜は短し歩けよ乙女https://cinema.ne.jp/recommend/kurokaminootome2017041006/
  19. ReLife リライフ(https://cinema.ne.jp/recommend/relife2017041706/
  20. ムーンライト
  21. 美女と野獣https://cinema.ne.jp/recommend/beautyandthebeast2017042406/
  22. ゴースト・イン・ザ・シェル
  23. 帝一の國https://cinema.ne.jp/recommend/teiichi20170501/
  24. 無限の住人
  25. 追憶(https://cinema.ne.jp/recommend/tsuioku2017050806/
  26. ガーディアンズ・オブ・ギャラクシー:リミックスhttps://cinema.ne.jp/recommend/gog-remix2017051507/
  27. メッセージ(https://cinema.ne.jp/recommend/message2017052207/
  28. ちょっと今から仕事やめてくる(https://cinema.ne.jp/recommend/choi-yame2017052907/
  29. LOGAN/ローガン(https://cinema.ne.jp/recommend/logan2017060507/
  30. 22年目の告白(https://cinema.ne.jp/recommend/22-kokuhaku2017061206/
  31. ハクソーリッジ(https://cinema.ne.jp/recommend/hacksawridge2017062606/
  32. メアリと魔女の花https://cinema.ne.jp/recommend/maryflower2017071006/
  33. スパイダーマン:ホームカミングhttps://cinema.ne.jp/recommend/spiderman2017080718/
  34. パイレーツ・オブ・カリビアン 最後の海賊
  35. カーズ クロスロード(https://cinema.ne.jp/recommend/cars2017071706/
  36. 怪盗グルーのミニオン大脱走https://cinema.ne.jp/recommend/minion2017072507/
  37. 東京喰種
  38. 銀魂
  39. ジョジョの奇妙な冒険 ダイヤモンドは砕けない 第1章
  40. 打ち上げ花火、下から見るか?横から見るか?https://cinema.ne.jp/recommend/uchiagehanabi2017081006/
  41. 散歩する侵略者https://cinema.ne.jp/recommend/sanpo-movie2017090806/
  42. ワンダーウーマンhttps://cinema.ne.jp/recommend/wonderwomen2017082406/
  43. きみの声をとどけたいhttps://cinema.ne.jp/recommend/kimikoe2017082506/
  44. 三度目の殺人
  45. 亜人https://cinema.ne.jp/recommend/ajin2017092616/
  46. 奥田民生になりたいボーイと出会った男すべて狂わせるガール(https://cinema.ne.jp/recommend/tamioboy2017091417/
  47. ダンケルク
  48. 先生!、、、好きになってもいいですか?(https://cinema.ne.jp/recommend/sensei2017102706/
  49. ナラタージュ
  50. スキップ・トレース
  51. ミックスhttps://cinema.ne.jp/recommend/mix2017102105/
  52. アトミック・ブロンドhttps://cinema.ne.jp/recommend/atomic-blonde2017102005/
  53. ザ・サークルhttps://cinema.ne.jp/recommend/thecircle2017110906/
  54. バリー・シール アメリカをはめた男
  55. 斉木楠雄のΨ難
  56. GODZILLA 怪獣惑星
  57. オリエント急行殺人事件
  58. IT/イット “それ”が見えたら、終わり。

●家で観た映画

  1. ペット
  2. トレインスポッティング
  3. 打ち上げ花火、下から見るか?横から見るか?(テレビ版)
  4. クレヨンしんちゃん ガチンコ!逆襲のロボとーちゃん
  5. アナと雪の女王
  6. スパイダーマン
  7. スパイダーマン2
  8. スパイダーマン3
  9. トランスフォーマー
  10. トランスフォーマー/リベンジ
  11. トランスフォーマー/ダークサイド・ムーン

もしかしたら、抜けがあるかもしれないのですが、ここに書いただけで69本の映画を観ていました。
去年は44本映画を観たようなのですが、それを上回る数を観ているのは自分でもびっくりしました。

2018年も観たい映画がたくさんあるので、非常に楽しみな1年になりそうです。
ちなみに、今一番観たい映画は「勝手にふるえてろ」です。綿矢りささん、好きです。

スタッフをしているバンドがメジャーデビューしました

僕がスタッフをしているバンド・THE PINBALLSが12月6日に「NUMBER SEVEN」というミニアルバムからメジャーへ移りました。
あまり内部的なことは言いませんが、これから新たなフィールドへ移って、より多くの経験をバンドとしてしていきます。
その中で少しでも多くの人に彼らの音楽を知って欲しいなと思っています。

今年リリースした「NUMBER SEVEN」の楽曲を貼っておきますので、ぜひ聴いてみてください。


THE PINBALLS「蝙蝠と聖レオンハルト」(Official Music Video)


THE PINBALLS「七転八倒のブルース」(Official Music Video)

NUMBER SEVEN

NUMBER SEVEN

  • THE PINBALLS
  • ロック
  • ¥1200

2018年とこれから

2018年は2017年から水面下でがんばっていることがあって、それが2018年に花咲く形になる予定です。
これまでの人生の中でも大きなことなので、きちんと形になるように引き続きがんばっていきたいと思います。

あと、ここ最近は健康にすごく気を遣うようになりました。
睡眠不足を少なくするようにしたり、あまり無理はしないようにどうしたらいいか?みたいなことを考えた1年だった気がします。
フリーランスでは自分の替えがいないので、引き続き健康を目標にがんばっていきたいと思います。

そして、自分の行ったことがない土地ややったことがない経験を多くしていきたいです。
少しでも多くの経験ができたらいいな、と思いながら、2018年を生きていきたいと思います。

あ、もう少しブログも書いて行けたらいいな。。。とか思ってます。

ではでは、来年もよろしくお願いします。

iOSDC 2017 1日目に参加してきました #iOSDC

f:id:takashings:20170916100149j:plain

去る、2017年9月16日(土)。 iOSDC2017へ行ってきました。

iOSDCとはiOS開発者の大規模な開発のお勉強会。

本当は9月15日(金)の夜の前夜祭、9月17日(日)の2日目もありましたが、 用事があり、1日目のみ参加することとなりました。

2016年にも開催されましたが、参加できず今回初参加。

オープニングでいきなりカウンターパンチが。 あの声優の三石美琴さんのナレーションでスポンサー紹介されるという度肝を抜かれる演出。


iOSDC Japan 2017 スポンサー紹介

よくこんなお金あるなぁ…どうやってやってもらったんだ…といろんなことを考えてました。

自分が気になって参加した講演をいくつかだーっと書いておく。

Auto Layoutのアルゴリズム

稲見 泰宏 (@inamiy)さんの講演。

興味のあるAutoLayoutの話でしたが、いきなり数学の話になって文系出身の僕は若干混乱。 だけど、よくよく聞いてみると、数学の公式でAutoLayoutをやっている、と思うとすごいな、という感想。 高校の数学の知識があれば、AutoLayoutは理解できる、ということを言われていた。

両OSやるマンという選択

ジャンボ (@jumboOrNot)さんの講演。 Androidも昔若干やっていたので、iOS開発者としては気になっていたので参加。

iOSAndroidの売り方、作り方、作るもの、デザイン、コードなどのいろんな視点から比較をしていて、すごく勉強になった。

特に一番学んだ&共感できたのは「違いを意識してプロダクトに落とし込むことが一番重要」ということ。 iOSAndroidは共通化出来る部分もあるけど、基本的には違うものだから、それぞれの考え方や哲学、思想などをきちんと理解する必要があるということを以前から思っていたけど、講演を通してそれは間違っていない考え方だと思った。

アプリエンジニアはどのように事業に貢献すべきか

フリルのエンジニア・クライアントチームリーダーのhuin (@huin)さんの講演。

個人的にはこの講演が一番良かったと思った。 技術的な話ではなく、割とエモい話だった。

huinさんの出した答えが、 「サービスの価値を理解して、それをアプリに落とし込むことがエンジニアのミッション」 ということだった。

これには個人的にもすごく同意で、結局のところエンジニアはアプリケーションを作るのが仕事だけど、 それはあくまでもユーザーがサービスを利用する手段の1つを作っているに過ぎないわけです。

サービスをいかに魅力を最大限引き出せるか、ユーザーにとってサービスを最大限に満足してもらえるか。

それにはまず「サービスの価値を理解すること」が大事。

基本的なことだけど、忘れてはいけないことだと思った。

モバイルアプリで困らないエラーハンドリングとロギングのベストプラクティス

多賀谷さん (@yoichitgy)の講演。

普段使っているCrashlyticsにまつわる話。 すごく勉強になったのは、システム系のログと自分で出力するログを絵文字入れるようにすると、わかりやすい、という内容は目から鱗が落ちた。

LTコーナー

どの方もすごく短い時間にためになるお話をされていてびっくりした。 特に@frnkさんの「第3の課金形態「寄付モデル」ってどうなの?」の話は面白かった。

なかなかお金の話は共有される場所が少ないから、非常に貴重な話だよなぁ…と思いながら聞いていた。 そしたら、その日のベストLTに選ばれて、レアな商品をゲットされていた。

その他諸々思ったこと

他にも驚いたことがある。それはお土産。

f:id:takashings:20170916094142j:plain

オシャレなエコバッグにTシャツやケーブル、タオル…と参加費を完全にペイできるものが配られたことに驚き。 しかも、お昼ご飯も参加費に含まれていたり、フリードリンク、懇親会のお金も全部含まれていた。 スポンサー様のおかげです、ほんと…mm

多くの情報量を一気に詰め込んだからか、全部終わったあとはバタンキューな状態で、帰りの電車でいつの間にか寝てしまっていた。

だけど、終わった後の充実感はすごくあった。 気持ちも前向きになった気がした。

それはiOSDCにたくさんの開発者の方からの刺激を受けたからだと思った。 ここまで大きな勉強会に参加する機会はあまりなく、みっちりと勉強した。

なんか自分もできるんじゃないか?とか 明日からもがんばろう、とか 何かエネルギーをたくさんもらった気がした。

正直、ここまでいいイベントになるとは参加前は思っていなかったので、本当にいい時間を過ごせて幸せだという気持ちしかなかった。

唯一残念だったことは、 いくつかの講演を立ち見で参加したこと。 ノートが取れず、資料を見るだけというのはつらかった。 参加人数の兼ね合いもあるんだろうけど、ちょうどいい感じなところを次回は期待したい。

かなり走り書きでここまで書いたが、来年も行こうと思ったし、何か自分もLTとかできたらいいな、と思った。 参加していた人も楽しそうだったけど、発表する側の方が一番楽しそうに見えたから。

最後にスタッフの皆様、本当にお疲れ様でした。 これだけの規模感のイベントを成功させ、大きな混乱もなく(と思っている)、終わったことはスタッフの皆様のおかげだと思う。 ありがとうございました。