「Deep Work 大事なことに集中する」を読んだ

大事なことに集中する―――気が散るものだらけの世界で生産性を最大化する科学的方法

大事なことに集中する―――気が散るものだらけの世界で生産性を最大化する科学的方法

rebuild.fm で本書の話しが出てて、最近集中できないことが多いので読んでみるか〜というノリで読み始めた。

言っていることはわかるのだが、ちょっと独善的すぎないか?と思ってしまう。
メールを返すのは1日1回だけで良い、あいつはメールを返すのが遅い人間と思わせたら勝ち みたいなの書いてあって、それはチームワークみたいな話じゃなくて独りよがりすぎないかなあとか思った。

オンラインの誘惑に勝てとか SNS は本当にお前の人生に必要か?という話はめっちゃ身にしみる。
沁みるのだが Twitter やめられねえ… って感じで己の意志の弱さに負けてしまう。

というかそんな Deep Work に命かけるとか人生何のためにいきてるんや!って思ってしまう。しかし Twitter やっている間に Deep Work している人がいると思うと自分はその人に勝てないとも思う。

とりあえず本を読んでから意識的に Twitter はしないようにしている。
就業時間を終えたら会社の Slack も見ていない、今のところ支障はないし無意識に iPhone で Slack 見るみたいなことはなくなって精神的にも良い。

毎朝やること書き出してタイムスケジュール決めて、その通りのスケジュールには行かないけど自分がどの仕事に集中するのか意識すべし、っていうのは良さそう(やれてないけど…)。

Deep Work 実践できたらめっちゃ強いけど自分はそこまで強い意志が持てずつらい、というのが正直な感想です。

以下 wikihub 日報 のまとめ。


読み始めた。まだ40%くらい。
これからは貧富の差が拡大していくから、富の側の人間になろうぜ!!!って導入でウケた。

毎日3~4時間は深い集中で仕事するべしってあって、めっちゃ同意できる。
SNS がどうとかって話が rebuildfm で言われてたけど、それより最近だと Slack が一番厄介だと思う。
仕事だと Slack でカジュアルにメンションくるけどあれ完全にシャローワークなんだよな。

ディープワーク/シャローワークらへんで言いたいことたくさんあるからブログ書こう。

とりあえず明日からポモドーロやってみよう。


50% くらいまで読んだ。
外界と断絶して集中するのがいいけどそうも言ってられないからフロー状態に入れる環境作ろうなみたいな話してる。
オープンオフィスは最悪とのこと。


60% くらいまで読んだ。

  • 就業時間が終わったら翌朝まで仕事のことは完全に頭から追い出す
    • これは最近やってる、就業時間終えたら Slack は見ていない
  • 初心者は1日1時間程度しか Deep Work できない、慣れてくると最大4時間いける、だから夕方になると疲れ果てて仕事は手につかないので定時で帰れ
    • 1日1時間も Deep Work できていない…。
  • オンラインの誘惑に打ち勝ちオフラインにしろ
    • おっしゃる通りだ

読み終わった。

言っていることはわかるし Deep Work の 必要性も感じているが、著者が人生 Deep Work って感じてついていけなさを感じる。
意識が高すぎる。

あと自分が Deep Work するために他者を拒絶する感じがあって、
例えばメールは5分以内に返すのが美徳とされるこの世界においてメールは1日1回しかチェックしません、
というのは働きにくい人間やな〜ってなりそう。
本書的にはそういう人間と思わせれば勝ちってあるけど、うーむ。

  • 60%~
    • Twitter などの SNS はあなたが本当にやりたいことに対しプラスになるのか?
      • なりません…
    • SNS やめろ
      • はい…
    • シャローワークさせらせそうになったらはっきり断れ
      • うーむ、断りたいけど全体最適化みたいなの考えると断れなくね?
    • よくわからんメールとかきたら無視しろ、無視した結果問題が起きたらそれはそれで良い
      • おれにメールを無視する度胸はない…
    • ディープワーク最高だろ?お前もやれよ
      • うむ、最高である、努力してみる。

「オブジェクト指向でなぜつくるのか」を読んだ

今まで Ruby, Java などオブジェクト指向言語に触れてきたけどオブジェクト指向っていうのが結局よくわかっていない。
クラスとかカプセル化とか継承とかの概念はわかるし使えもするけど、自分の知識は薄っぺらいというか真髄を理解していない気がしているので、オブジェクト指向を完全理解したいというモチベーションを持って読んだ。

しかし、この本ではオブジェクト指向は「クラスは処理を隠して、継承とポリモーフィズムは処理をまとめるだけだよ」みたいに書かれてて、それは本を読む前から理解してるし俺が知りたいのはそれじゃないんや〜って感じだった。
後半は要件定義とか関数型言語の話になって、何の本を読んでいるんだ?という気持ちになってしまった。

しかし、オブジェクト指向が生まれる前の話が書いてあって、昔は全てグローバル変数でサブルーチンがあるだけだったらしい。
なので、それと比較するとクラスで隠蔽できて、継承とかで処理を共通化できるのは素晴らしいことだったんだろうなと思う。
そこらへんの歴史的背景が知れたのはよかった。

自分が知りたいのは多分この本ではなくて、 オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) の方なのかなと思った。

以下 wikihub 日報 のまとめ。


読み始めた。20% くらいまできた。
恥ずかしながらオブジェクト指向をちゃんと理解しておらず、概念はわかるがちゃんと使えていないという状態なのでためになりそう。

  • 「動物クラスから犬のサブクラス作って吠えるってメソッド実装する」って説明じゃ全くオブジェクト指向伝わらない
  • そんなわかりにくい例じゃなくてちゃんと説明するぜ
  • オブジェクト指向と現実世界は同じとか言われるけど全然違うから理解できなくて当然だぞ
  • オブジェクト指向は従来の開発を置き換える新しいものという説明があったりするが、それは間違い
  • オブジェクト指向は、それ以前のプログラミング技術を基礎としてその欠点を補うもの

オブジェクト指向をちゃんと理解できていないの、めっちゃコンプレックスなので完全理解したい…。


なんか読まないほうがいい気がしてきた


書評があまり良くないけど読み進めてる。45%くらいまできた。

  • クラスは関連性の強いサブルーチン(関数)とグローバル変数を1つにまとめて粒度の大きいソフトウェア部品を作る
    • 本当にその理解でいいのか…?
  • ポリモーフィズムと継承は、共通サブルーチンではうまく対処できない重複したコードを一本化する仕組み
    • 本当にその理解でいいのか…?

「書評が良くない」という情報を一度得てしまうと、内容に対し懐疑的になってしまうの良くない。
↑ の理解でいいならそもそもオブジェクト指向を理解していたということになるのだが、本質はそこじゃないと思うんだよなあ。
とりあえずもうちょい読み進めよう。


60% くらいまできた。
知ってる内容ばっかで、おれが知りたいのはそういう話じゃないんや〜ってなってる。


80% くらいまできた。
要件定義とかウオーターフォールとかアジャイルの話とかになってて、おれが求めてた書籍じゃなかった…。
とりあえずもうちょいなので読み切ろう。


なんか最後の方は関数型言語めっちゃいいぞ!って話になってハァ〜って感じだった。
オブジェクト指向の表面だけ舐める感じで微妙な本でした。

「チームが機能するとはどういうことか」を読んだ

単純な業務だったら上司が圧倒的パワーバランスで部下を管理してサボらないように効率化を測れば良いが、複雑な業務であったりイノベーティブな業務にはチーミングが必要。
チーミングのためにはリーダーシップが不可欠であり、心理的安全を高め意見を出しやすくすること、価値観の違いなどの境界を超えること、失敗を咎めずむしろ良いこととするなどし、学習しながら実行する組織を作ろうみたいな内容だった。

前職は完全に心理的安全がなく、失敗はそこまで咎められなかったが許容されている感じでもなかった。
現職はそもそもリーダーがおらんし、自分はチームで働いている訳でもないので寂しい気持ちがある。

本を読んだ後毎回思うのが、「ためになるいい本だった、おわり」という小学生並みの感想しか出てこず、他の人の感想文みてるとすげ〜って思う。
まともな人間になりたい。

以下、 wikihub 日報 でちまちま書いてたまとめと感想。


  • ブラック企業みたいに上から恐怖で支配するのはもうオワコン
  • チーミングとは、新たなアイデアを生み答えを探し問題を解決するために人々を団結させる働き方
  • 学習するための組織作り
  • 学習しながら実行する

20%まで来た。やはり内容が難しい、というかすっと頭に入ってこないので読むのに時間がかかっている。

  • 昔はリーダーが管理して部下が労働するような仕組みでうまく回ってたが今は違う
  • リーダーが部下を信頼し、リーダーは方向性などを示し失敗に寛容であるべき
  • そうすると部下が自分たちで考え、良い組織になっていく
  • はっきり意見を言うこと、協働すること、試みること、省察することが大事

26%まで来た。相変わらず内容が濃く文章が長く理解しにくい… 俺の脳内メモリが足りないだけともいう。

  • チーミングを妨げる大きな障害は不安であり、明確な共通の目標がないことも努力を妨げる要因
  • 官僚的な煩雑な手続きや矛盾するインセンティブなども妨げとなる
  • はっきり意見を言うより黙っている方が楽、しかし個人は楽だが組織としては良くないこと
  • 従業員を尊敬しているということをリーダーが従業員に伝えると、従業員はやる気100倍になって良い
  • 意見の対立は新たな理解や尊敬、信頼を築く圧倒的チャンス👊
  • 失敗から学ぶことは難しいが絶対に欠かせない
  • チームはみんなが互いに尊敬、尊重しあい、それには価値観を詳しく知ろうとする姿勢を育てる必要がある
  • 学習するための組織作りには4つのリーダーシップが必要
    • 学習するための骨組みを作る
    • 心理的に安全な場を作る
    • 失敗から学ぶ
    • 職業的、文化的な教会をつなぐ

35%くらいまできた。ゆっくりだけど毎日少しずつ読んでる。

  • リーダーは仕事を押し付けるのではなく、みんなを信頼する。
  • そのことをちゃんと伝え、目標を明確にし、反論や議論などを歓迎する。
  • 周りの人は部下ではなくチームのメンバーであり、全員がパートナーである。
  • そんなこんなでメンバーに圧倒的当事者意識が芽生え、プロジェクトが成功する。

周りの人を信頼し、信頼していることを伝え、目標を明確にし、労働でなく意義のある仕事なんだと認識してもらえるように頑張れという感じっぽい。
競合他社に負けないとかの目標で働くのはメンバーが学習や思考をしないのでよくないとのことだった。
友達の友達の会社は完全にアンチパターンにはまっているな〜と思いながら読んでいた :innocent:


48%まできた。
心理的安全について述べられてて、友達の友達の会社はあまり心理的安全を感じないので、まあそういうことなのかなと思って読んでた。

  • 心理的安全とは、関連ある考えや感情について人々が気兼ねなく発言できる雰囲気を指す。
  • 一人だけ心理的安全ということはなく、一人が心理的安全であれば他のひとも心理的安全である可能性が高い。
  • 逆に、一人でも心理的安全でない場合はみんな心理的安全でないばあいがおおい
    • だから、自分が心理的安全を感じなければ他のひとも感じていないということなのである
  • 心理的安全を得るためにはやはりチームを信頼し、率直にはなし、意見を歓迎し、失敗に寛容になることだ
    • 失敗したからといって処罰はしない、失敗は歓迎することでチャレンジが生まれる
  • 心理的安全が高い方が失敗の数が多い、それは失敗を話し合う文化があることで明るみに出やすくなるからだ

60% まで来た。ひたすら失敗を肯定しろという話がされている。

  • 失敗に寛容になれ、むしろ失敗はいいことである
  • 失敗を叱るな、褒めろ
  • 小さな失敗でも見過ごさずなぜその失敗が起きたかちゃんと振り返れ
  • エンジニアが「これはやばい」といっても経営層がヤバさをちゃんと認識せず数ヶ月後にヤバいことが判明するのは勿体無い
    • 友達の友達の会社かな?って感じで読んでた。

70% まで来た。
リーダーシップについて語られている、とりわけ境界という他者との違いを受け入れチームとして働く為には〜という話がされている。

  • いまどきの社会は価値観が全く同じ人が揃うことはまずなく、みんな考え方が違う。
    • それを境界と定義する。
  • その境界を繋ぐことが大事。
  • 成功しているチームは境界を超えて協働する、しかし境界は軽視されがちなので境界を受け入れよ。
  • より上位の目標を上げることでチームをうまく動かすリーダーシップが必要になる
    • 「例えばドリルで穴を開ける」という目標ではなく「落石に埋もれた人を助ける」など

80%まで来た。
学習しろみたいな話がひたすらされてた。あまり覚えていない。

  • 実行するな学習せよ
    • 実行というのはマニュアル通りにやり、改善することや決められたことをいかに素早くやるかみたいなやつ
    • 学習は試してナンボ
  • 学習しながら実行せよ
  • 学習しながら実行し続けるにはリーダーシップが不可欠
  • 何をするにしても心理的安全や失敗はむしろ良いことなどが絶対に必要とのこと

読了。

  • リーダの極めて重要な仕事は、短期的には高くつくが長期的には費用対効果の高いことにお金を出してもらうこと
  • 人々をリードするのは良い答えを提供することではなく、良い質問を多くすること
  • 進歩には分野や国家を超えたチーミングが必要になる。
    • その新たな試みは間違いなく失敗を経験するので是非学ぼう

まとめ

  • チームが機能するにはリーダーシップが不可欠。
  • サボらないように監視するやり方は複雑な業務に向いていない、メンバーを信じメンバーに考えてもらうことが大事
  • チーミングのためには心理的安全、境界を超えること、メンバーを仲間として尊敬しあうこと、目標を掲げることなどが大事
  • 学習しながら実行する
    • そのためには失敗すること、失敗を怖がらないこと、失敗を咎めないこと、
  • 仕事といっても「ルーチンワーク」「複雑な業務」「イノベーティブな業務」がある
    • ルーチンワークとかは失敗とかより改善とかスピードだけど、その中にも挑戦や失敗がないと後で詰む

macOS Sierra にしたので Karabiner が使えなくなってやったこと

やったこと

参考にしたもの

Karabiner 使えない対策: Hammerspoon で macOS の修飾キーつきホットキーのキーリマップを実現する - Qiita

hammerspoon Config file

local function pressFn(mods, key)
    if key == nil then
        key = mods
        mods = {}
    end

    return function() hs.eventtap.keyStroke(mods, key, 1000) end
end

local function remap(mods, key, pressFn)
    hs.hotkey.bind(mods, key, pressFn, nil, pressFn)   
end

remap({'alt'}, 'h', pressFn('left'))
remap({'alt'}, 'j', pressFn('down'))
remap({'alt'}, 'k', pressFn('up'))
remap({'alt'}, 'l', pressFn('right'))

RxSwift で NotificationCenter を使う

Notification を送る側

let name = Notification.Name("notification")
NotificationCenter.default.post(name: name, object: nil, userInfo: ["key": "value"])

Notifiactin を受ける側

disposeBag があるので購読やめるとかしないでよい。

NotificationCenter.default.rx.notification(name, object: nil)
    .subscribe(onNext: { notification in
        log?.debug(notification)
    })
    .addDisposableTo(disposeBag)

結果

f:id:star__hoshi:20170326175758p:plain

補足

引数の object ってなんだ?

NSNotificationの通知を受け取れるパターンと受け取れないパターンについて - Qiita

iOS Test Night #3 でカバレッジの計測について話してきた

カバレッジについて話したが、カバレッジが高けりゃいいわけじゃなくて、計算ロジックとかは絶対に書いた方がいいけどそうではないところは書くメリット小さいかなと思っている。

とはいえテストがないと影響範囲読めないし、「俺たちが書くコードは完璧だから絶対にバグが起きないぜ😎」という自信がある人以外はテスト書いた方がいいんじゃないかと思っている。

今日の勉強会では「そもそも静的解析で間違いを発見するべし」みたいな話が出ていて、素晴らしいと思った。
そもそもバグを生み出さない仕組みがあればテストいらんよねという話である。

iOS Test Night の雰囲気

司会の人とかだいぶ緩い空気出してて、 LT 以降は酒飲みながら、懇親会はシースーが出てくる感じでゆる〜くて良かった。
また次回も参加したい 😊

実はめっちゃ練習した

自分にとってはほとんど初 LT みたいなものだったので、だいぶ緊張した。
本番で頭真っ白になったらどうしようとかめっちゃ不安で、5分のライトニングトークなのに多分20回くらい練習した。

大して面白い発表はではなかったけど、まあ失敗はしなかったので良かったと思う。
他の勉強会にも出て行きたい。

iOS 10.3 から、アンインストールすると Keychain が削除される → されませんでした

顛末

  1. iOS 10.3 beta でアンインストールすると keychain が削除される問題が発見される
  2. これはバグか?という議論がなされる中、 Apple スタッフから 「これは仕様だ」とコメントが入る
  3. しかし iOS 10.3 beta7 でアンインストールしても keychain から消えない、元の仕様に戻った
  4. iOS 10.3 Public でもアンインストールしても keychain は消えない ← イマココ!

以下 keychain 削除について

nextstep.fm by nextstep.fm on iTunesiOS 10.3 について話されていて、どうやらアプリをアンインストールすると Keychain が削除されるらしい。
これはバグでそうなっている可能性もあるらしく、修正されるかもしれない。
→ 仕様とのこと。
iOS 10.3 beta7 からアンインストールしても消えなくなったとのこと…。

forums.developer.apple.com

友達の友達から聞いた情報によると、 iOS 11 からアンインストールで keychain が消えるらしいが、ググってもそれらしいのは見当たらなかったのでガセかもしれない。
判明したらまた追記します。

動作

  • いままで
    • アプリをアンインストールしても Keychain のログイン情報は残ったまま。
    • つまり再インストールすると前回のログイン情報を引き継ぐ。
      • (再インストール後の初回起動時に Keychain を削除することで引き継がせないアプリもある)
  • これから
    • アプリをアンインストールすると Keychain も消える。
    • 再インストールしても前回のログイン情報を引き継がなくなったため、常に初回起動と同じ動作になる
    • ただし、 keychain が他のアプリと共有されている場合、他のアプリも消さないと keychain は消えない。

バグの可能性

Keychain の変更は iOS 10.3 の仕様に記載されている事項ではなく、今後の 10.3 正式リリース時までに削除される可能性があると話されていた。
まあ beta 版での話なので、杞憂に終わればそれで良い。

コメントで教えていただいた、これは仕様とのこと。
→上記に書いた通り、仕様になったが beta7 からまた元に戻った。

https://forums.developer.apple.com/thread/72271 このスレッドに Apple スタッフからの回答がありましたよ。

This is an intentional change in iOS 10.3 to protect user privacy. Information that can identify a user should not be left on the device after the app that created it has been removed. It has never been a part of the API contract that keychain items created by an app would survive when the app is removed. This has always been an implementation detail. ユーザーのプライバシーを守るための意図的な変更とのことです。

対策

開発者的に何かすることはおそらくないと思う、常に初回起動と同じ挙動になるだけ。(Analytics のトラッキングが正常に動作しない可能性はある?)

ただ、「再インストール」というのを特定するために Keychain を使う必要があったが、それができなくなる。
アプリの再インストールを検出する - Qiita

一応 iOS10.3 以上とそれ以下で実装を気をつけたほうがよさそう。

参考

iOS 10.3 Beta 2 autodeletes keychain items afte... | Apple Developer Forums
iphone - iOS 10.3 beta 3 doesn’t persist data of KeychainItem - Stack Overflow

fastlane の increment_build_number で Cannot find が発生した時の対処法

エラー内容

fastlane で increment_build_number を使ったら以下のようにエラーが出て increment されなかった。

[14:33:08]: ------------------------------------
[14:33:08]: --- Step: increment_build_number ---
[14:33:08]: ------------------------------------
[14:33:08]: $ cd /Users/kensuke/Documents/xcode/hoge && agvtool next-version -all && cd -
[14:33:09]: ▸ Setting version of project hoge to:
[14:33:09]: ▸ 5.
[14:33:09]: ▸ Also setting CFBundleVersion key (assuming it exists)
[14:33:09]: ▸ Updating CFBundleVersion in Info.plist(s)...
[14:33:09]: ▸ $(SRCROOT)/hoge/SupportingFiles/appStaging.plist
[14:33:09]: ▸ Cannot find "$(SRCROOT)/hoge/SupportingFiles/appStaging.plist"
[14:33:09]: ▸ $(SRCROOT)/hoge/SupportingFiles/appDev.plist
[14:33:09]: ▸ Cannot find "$(SRCROOT)/hoge/SupportingFiles/appDev.plist"
[14:33:09]: ▸ Updated CFBundleVersion in "hoge.xcodeproj/../appTests/Info.plist" to 5
[14:33:09]: ▸ Updated CFBundleVersion in "hoge.xcodeproj/../hoge/SupportingFiles/Info.plist" to 5

発生状況

TARGETS を app, appStaging, appDev, appTests のように分離していて、 Info.plist が 4 つできている状態になっていた。

対処法

Xcode⌘ + Shift + f を押して INFOPLIST_FILE で検索する。
そうすると $(SRCROOT)/hoge/SupportingFiles/appStaging.plist などと書いてあるところが出てくるので、そこの $(SRCROOT)/ を削除する。

hoge/SupportingFiles/appStaging.plist なるようにする。

結果

[14:41:41]: ------------------------------------
[14:41:41]: --- Step: increment_build_number ---
[14:41:41]: ------------------------------------
[14:41:41]: $ cd /Users/kensuke/Documents/xcode/hoge && agvtool next-version -all && cd -
[14:41:42]: ▸ Setting version of project hoge to:
[14:41:42]: ▸ 6.
[14:41:42]: ▸ Also setting CFBundleVersion key (assuming it exists)
[14:41:42]: ▸ Updating CFBundleVersion in Info.plist(s)...
[14:41:42]: ▸ Updated CFBundleVersion in "hoge.xcodeproj/../appTests/Info.plist" to 6
[14:41:42]: ▸ Updated CFBundleVersion in "hoge.xcodeproj/../hoge/SupportingFiles/Info.plist" to 6
[14:41:42]: ▸ Updated CFBundleVersion in "hoge.xcodeproj/../hoge/SupportingFiles/appStaging.plist" to 6
[14:41:42]: ▸ Updated CFBundleVersion in "hoge.xcodeproj/../hoge/SupportingFiles/appDev.plist" to 6

参考

fastlane cannot update project version · Issue #329 · fastlane/fastlane

iPad 向けアプリで iTunesConnect 提出時に ITMS-90029 が発生した時の対処法

設定

iPad 向けになってる。

f:id:star__hoshi:20170214102719p:plain

iTunesConnect に申請してみる

iPad 向けにしてるのに iphone の storyboard がウンヌンって言われてる。

f:id:star__hoshi:20170214102555p:plain

Info.plist 見てみる

邪魔そうなのがいる… 👀

f:id:star__hoshi:20170214103008p:plain

消してみる

もう一回申請すると

エラーが消えました 🙌

Swift 実践入門 を読んだ

Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plus)

Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plus)

全体感想

良い本だった、書名になっているが初心者向けではなく実践入門なので、実践的な内容が多くためになる。
だいたい 16 時間くらいで読みおわった。

普段ゆるふわで書いているとクロージャジェネリクスなど使いこなせていないし、非同期処理なども注意がおそろかになりがちだし、循環参照とかも起きてしまう。
そこらへんちゃんと理解してちゃんと書いていこうという内容であるし、この本を読みながら既存のアプリをリファクタリングしていきたい。

読み終わったら終わりな本ではなくて、手元に置いておいて Swift 書きながら読み返して体に染み込ませていくのがいいのかなと思いました。

石川さんから『Swift 実践入門』を頂いたので、見所などを綴ってみました。 にまともな書評がある。

以下メモ

1章 Swift はどのような言語か

ざっくり Swift こんな言語だよ〜って説明。
静的型付けで Optional 良いよねとかそんな話。
OSS にもなってるよ、コマンドラインとかからでも実行できるよ〜みたいな内容。

2章 変数、定数と基本的な型

変数とか定数、基本的な型(String, Int, Optional など…)の話。
強制アンラップはやべーよなとか、キャストとかも書いてある、ほとんど知ってたけど Swift 書くなら一度読んでおいた方が良い内容。

メモ

  • 定数は宣言時に値を代入しなくても、宣言した後に1度代入されるように書かれていれば問題ない。
  • String の n 文字目を取得するのは characters 型の offetBy を使う、ここら辺は面倒だ。
  • command + control + ? (英字keyの場合は command + control + shift + / ) で型情報見れる。
    • 知らなかった、便利だ。今まで画面右の Quick Help で見てた。
    • 長いのでエイリアス当てておきたい

3章 制御構文

if, switch, guard などのはなし、深く実践的な内容が書かれている。

メモ

  • if case 1...10 = value みたいに書く。この書き方いつも忘れる。
  • switch casewhere はあまり使ってない、というか存在を忘れていたので今後使っていこう。
  • switch の default を書いちゃうと今後増えた時に全部 default 入っちゃってよくないから default は極力書かないようにしよう。
  • for-case in という書きかた普通に知らなかった、便利だ。
  • while は嫌いだから俺は使わない
  • defer は遅延処理
  • enum はもっとうまく使わないとなあ

4章 関数とクロージャ

関数は他の言語と大体同じ。
クロージャは使いこなせておらず知らいことが多い、めっちゃ便利だがそれなりに難しく、後3回くらい読み直したい。

メモ

  • インアウト引数はあまり使い慣れない
    • 関数先で渡した引数が更新されるのわかりにくくない?
  • クロージャは1行の時だけ return 省略できる
  • キャプチャ
    • クロージャ内部の変数を保持することができる。
    • 用途によって色々使えそう。
  • 関数の引数にクロージャ渡すとかめっちゃ便利そうだが複雑になって脳内メモリ足らなくなる

5章 型の構成要素

class, struct, enum で利用出来るプロパティやメソッドの説明。
今まで雰囲気で Swift 書いてきた人間はこの章で死ぬ。

メモ

  • プロパティオブザーバ
    • willSet, didSet あたりあまり使いこなせてない
  • 失敗可能イニシャライザ使いこなせたら強そう
  • subscript 全く使いこなせてない
    • コレクション要素にアクセスできるやつ、 array[0] の [0] の所とか
  • UIAlertController の initializer の所良い、真似しよう。

6章 型の種類

class, struct, enum の説明。
class は参照型、struct は値型で、参照型は意図せぬ値の変更などが起きうるのでなるべく値型を使い、参照の共有が必要な時だけ参照型を使おう。

メモ

  • クラスは参照型で継承が可能、多重継承は出来ない
    • final つければ継承やオーバーライドできなくなる
  • クラスメソッドとスタティックメソッドの違いはオレバーライドできるかできないか
  • enum に値を持たせるのを連想値という

7章 プロトコル

他の言語でいうインターフェースに近い。
100回読みたい。

メモ

  • associatedtype つかえばいま開発中のアプリのやばいところ綺麗に書けそう
  • プロトコルエクステンションにwhereで型制約つけると、その型の時だけ有効になるエクステンション作れる
  • Equatable で URL の一致書こう

8章 ジェネリクス

100回読みたい。

メモ

  • ジェネリック型に具体的な型を与えることを特殊化という。
    • Optional に String とか渡すのもそう。
  • ジェネリクス + 型安全で最高のプログラミング

9章 モジュール

配布可能なプログラム形式(import するやつ)、フレームワークとかを作ろうって話。
普通にプログラム書いてる分には Framework 作ることはないかなと思う。

メモ

  • ドキュメントコメント
    • // や / / は普通のコメント
    • /// や /* / はドキュメントコメント
      • ドキュメントコメントでは Markdown が書ける。

10章 型の設計指針

クラスより構造体を使うべき。
ただしクラスの方が向いている処理もあるので、状況を見て判断すること。

メモ

  • Array や Dictionary はサイズがでかいかもしれないから、それをコピーする時はコピーオンライトって仕組みがあって、必要になるまでコピーされないようになっている。
  • クラスは、参照の共有やインスタンスのライフサイクルに合致した場合などに有用なので、そういう時に使うこと。
  • クラスの継承よりも protocon-extension に優位性があるので、なるべく protocol-extension-struct を使うこと。
  • protocol-extension ではストアドプロパティの保持ができないため、そういう時は class を使う。

11章 イベント通知

UI のタップとかのイベントをどう取り扱うか。 デリゲート、クロージャ、オブザーバパターンなどある。

循環参照について書かれている、100回読みたい。

メモ

  • ボタンタップとかの命名は didSelect などにするのが良さそう
  • delegate は weak にして弱参照にすること
  • クロージャのキャプチャリストを使うときは weak や unowned をつけ弱参照としないと循環参照おきる
    • weak はアクセス時に nil でも死なないが unowned だと実行時エラー起きる
  • self を使うと循環参照する -> 今作っているアプリのあそこ循環参照してる気がする
  • typealias でクロージャの型を作れる

12章 非同期処理

マルチスレッドのはなし。
スレッドを使うにはGCD、OperationQueue、 Thread のどれかを使う。
Thread を使うケースは稀で、簡単な非同期は GCD、複雑な非同期は OperationQueue を使うのが良さそう。

めちゃくちゃためになるというか、真面目に考えないといいアプリにならないがなかなか難しい。
スレッド書くときは読みながら書きたい。

メモ

  • GCD は CPU の負荷などを見ていい感じにスレッド使ってくれる。
    • この手法をスレッドプールという。
    • GCD はシンプルな非同期処理の実現に向いている
      • サブスレッドで実行しその結果をメインスレッドで表示したいとか
      • タスクのキャンセルとかは向いていない
  • Operation, OperatioQueue クラス
    • 内容がだいぶ複雑で頭に入ってこない
  • Thread クラス
    • 継承してクラスそのものを thread にできる

13章 エラー処理

エラーハンドリング。
Optional, Result<T, Error>, do-catch, try, fatalError, アサーションなどの使い方や使い分けなど。

最後にどういういう時にどのエラーを使うべきかという流れが書いてあって便利。

メモ

  • Result<T,Error> はエラーのパターンを判別しハンドリングしたい時に使う
  • try! は危険のように思えるが、失敗したらしゃーないって意図がある
  • do-defer を使うと失敗した時に必ずずっこうしたい処理が書けて良い。
  • do-catch はエラーが起きたかというので取れるので、 Result よりも幅が広く、ネストしたエラーも do-catch であればネストせず行ける。
  • do-catch は エラー処理を強制させる
  • fatalError は想定されていないケースに使う。
    • fatalError が呼ばれることこそが問題だからアプリを落とすという判断
    • fatalError は Never 型を返す。
      • Never 型は空ではなく、そこでプログラムの実行をやめるという意味で何も変えさない
  • アサーション
    • これが有効なのはデバッグ時のみで、リリース時には影響しない

14章 実践的な Swift アプリケーション

API Client を作っていく。
APIKit を作っていく感じ。
Protocol + Extension で抽象的なプログラムを書くの楽しい。

全部写経した。
starhoshi/GitHubSearchRepository: Swift 実践入門

15章 Swift から Objective-C を利用する

Objective-C は実績のある言語だから、過去に書かれた ObjC を Swift で書き直していくにはどうすべきか?みたいな話。
Swift から ObjC の参照の仕方や、 ObjC もちゃんと書いてないと Swift から利用するのはむしろ逆に辛いかもしれないので、 ObjC もちゃんと書こうという話がされてる。

そもそも ObjC 全然詳しくないので勉強にはなるけど、正直 ObjC に努力値振る暇あったら Swift の知見深めたいところではある。

メモ

  • Swift から ObjC を使うときは Bridging-Header を使う
    • Swift 1 のときはライブラリ使うために必要だったな :relaxed:
  • ObjC のランタイムを使うと動的にメソッドの入れ替えなどが可能になるらしい
  • Swift から ObjC を使うにしても、漫然と書かれた ObjC は危険がたくさんなので、 ObjC も気をつけて書いた方が良い
    • ライトウェイトジェネリクス, nullableなど使っていこう
    • id 型はやめろ
  • ObjC から Swift も利用できるけど、制限が多いのでメリットはあまりない