ペンギン村 Tech Blog

技術をこよなく愛するエンジニア集団が在住するペンギン村から、世界へ役立つ(かもしれない)技術情報を発信する技術系ブログです。某アラレちゃんが済む村とは一切関係ありません。んちゃ!

【iOS】RxSwift + Realmでバックグラウンドでの書き込み完了イベントを受け取る

前書き

久々にペンギン村で記事を書きました(10ヶ月ぶり3記事目)、ナガクラ(@nagakuta)です。

今回はリハビリも兼ねて、RxSwiftRealmを組み合わせた小技を紹介します!

TL;DR

今すぐこれをコピペして Realm+Rx.swiftファイルを作成するんだ!!

import RealmSwift
import RxSwift

extension Realm: ReactiveCompatible {}

public extension Reactive where Base: Realm {

    /// Write objects in background queue
    func asyncWrite(objects: [Object]) -> Completable {
        let config: Realm.Configuration = self.base.configuration

        return Completable.create { (observer: @escaping PrimitiveSequenceType.CompletableObserver) -> Disposable in
            DispatchQueue(label: "hogehoge").async {
                autoreleasepool {
                    do {
                        let realm: Realm = try Realm(configuration: config)

                        try realm.write {
                            realm.add(objects, update: true)
                        }

                        observer(CompletableEvent.completed)
                    } catch {
                        observer(CompletableEvent.error(error))
                    }
                }
            }

            return Disposables.create()
        }
    }

}

なぜ「書き込み完了イベント」を受けたいのか

だって、永続化されたデータが正しく更新されているのか分からないのは気持ち悪いじゃない!!?(個人の感想であり、所属する組織の公式見解ではありません)

Realmで書き込み系の操作をしていていつも思うのが、「書き込み処理をかけたけど、実際に書き込みが完了しているのかは分からない…」ということです。 (そこは、「Storageの処理が完了したかどうかは操作側が知る必要ないのでは」というのもあるかとは思います。というか、そちらの考え方のほうが一般的…?🤔)

永続化しているアプリ設定を更新するとき、in-memoryでキャッシュを作成するときなど、正常に更新されたかどうか(言い換えると、更新エラーを検知できるかどうか)を知ることはつまり、正常系と準正常系/異常系のハンドリングを行えることに繋がります。

正常/異常ハンドリングによる結果でViewの表示を変更することで、ユーザフレンドリーなアプリに近づきます。

つまり、我々は「Realmへの書き込み処理が正しく完了されたことを知る必要がある」ということになります。

なぜRxSwiftなのか

だって、技術選定時にRxSwiftを使うかどうかって話になるくらい、現在のアプリ開発では準必須級なものじゃない!!?(個人の感想であり(ry)

完了したことを検知する方法にはいくつかあると思います。NotificationCenterで通知を送信したり、完了時にDelegateメソッドを発火させたり。 ただし、それらは時に扱いづらく感じてしまう場面もあると思います。

その方法の一つとして存在するのがRx(Reactive Extensions)です。

桃太郎の童話のように川(Stream)に桃(イベント、値)を流して、それを検知する(しかも非同期で)ことでデータの伝達の流れを作る、というものです。

僕自身、仕事でも個人開発でもRxSwiftを採用しています。面白いですよね、Streamを繋げるの。

Realmを扱うクラス(レイヤー)から非同期で流されたイベントをViewで検知してからのハンドリング実装が行いやすい、というのが、僕がRealmRxSwiftを組み合わせる利点だなと思っています。

どうやって実装するの?

実装環境
  • Swift: 4.2
  • Realm: v3.11.1
  • RxSwift: 4.4.0

Realmでのバックグラウンド更新

Realmでバックグラウンド更新をかける方法については、こちらのCookbookを参考にしました。

realm.io

import RealmSwift

public extension Realm {
    /// Write objects in background queue
    func asyncWrite(objects: [Object]) {
        DispatchQueue(label: "hogehoge").async {
            autoreleasepool {
                do {
                    let realm: Realm = try Realm(configuration: self.configuration)

                    try realm.write {
                        realm.add(objects, update: true)
                    }
                } catch {
                    // エラーハンドリング
                }
            }
        }
    }
}

これで、Realmのバックグラウンド更新が可能となりました。

注意点としては、この実装で更新可能なオブジェクトはスタンドアローンなものになります。 (スタンドアローンである = Realmに管理されていない = Realmから取得したオブジェクトではない、という意味です)

何故かと言うと、Realmの管理下にあるオブジェクトに対して、取得処理が走っているスレッドとは別スレッドで更新処理をかけるには、ちょっとおまじないをかけてあげる必要があるからです。ちょっと面倒…😥

ちなみに、Realmの管理下であるオブジェクトをスタンドアローンにするには、

// ↓この時点ではRealm管理下にある
let object: HogeObject = /* Realmから取得 */

// ↓これでスタンドアローン化
let standaloneObject: HogeObject = HogeObject(value: object)

とする必要があります。

更新完了イベントの送信

さて、ではRxSwiftを利用して、書き込み完了通知の送信を実装します。

この実装で返すイベントはCompletableです。先程、RxSwiftを説明する際に、

桃太郎のように川(Stream)に桃(イベント、値)を流して、

と説明しました。

通常、イベントには値(Int、String、Boolなど)が含まれる場合がほとんどですが、今回は「更新が完了したというイベント」を送信するので、特定の値を送信する必要がありません。その場合に利用するオペレータがCompletableです。

RxSwift.Completableを用いて書き込み完了通知を流す実装が以下になります(3分クッキング)👨‍🍳

import RealmSwift
import RxSwift

extension Realm: ReactiveCompatible {}

public extension Reactive where Base: Realm {

    /// Write objects in background queue
    func asyncWrite(objects: [Object]) -> Completable {
        let config: Realm.Configuration = self.base.configuration

        return Completable.create { (observer: @escaping PrimitiveSequenceType.CompletableObserver) -> Disposable in
            DispatchQueue(label: "hogehoge").async {
                autoreleasepool {
                    do {
                        let realm: Realm = try Realm(configuration: config)

                        try realm.write {
                            realm.add(objects, update: true)
                        }

                        // ここで完了イベントを送信
                        observer(CompletableEvent.completed)
                    } catch {
                        // ここでエラーイベントを送信
                        observer(CompletableEvent.error(error))
                    }
                }
            }

            return Disposables.create()
        }
    }

}

やっていることは、言ってしまえば単純で、do-catch内で問題なくバックグラウンド更新処理が走れば完了、エラーをcatchしたらエラーを送信するようにしているだけです。

これで、バックグラウンド更新の完了イベントを送信できるようになりました👍

Usage

このメソッドの使い方は、

let realm = try! Realm()

realm.asyncWrite(objects: standaloneObjects)
    .subscribe(onCompleted: {
        // 完了イベントを受けて発火する何か
    }, onError: { (error: Error) in
        // エラーイベントを受けて発火する何か
    })

のようにして、完了/エラーイベントを受け取ったクラス/メソッドでアレコレするようにします。

まとめ

これでRealmのバックグラウンド更新の完了を非同期で検知することができるようになりました👍

みんなもRealmの更新処理をハンドリングして、いいアプリを作っていきましょう!!!(๑•̀ㅂ•́)و✧

GKE / Kubernetes で稼働していた「このすばCfP」をOSSとして公開しました

「OSSを公開する」と心の中で思ったならッ! その時スデに行動は終わっているんだッ!

ジョジョ5部は面白いですね、どうも @tobi462 です。

そんなわけで iOSDC 2018 のプロポーザル検索サービス「この素晴らしいCfPに祝福を!」のソースをOSSとして公開しました。

github.com

このすば CfP は衰退しました。

このすば CfP は、 iOSDC 2018 のプロポーザルをもっと快適に見れたら便利だろうという思いつきが発端となり、ペンギン村の有志で開発・公開したサービスです。

GKE / Kubernetes をインフラとして採用し、バックエンドの API には Python、フロントエンドには Vue.js、CSS フレームワークには Bulma を採用し、SPA な Web ページとして公開しました。

おかげさまでそこそこ好評をいただけて、iOSDC リジェクトコンの「俺コン」ではスペシャルサンクスをいただきました。

しかし・・・ 姉さん、事件です。 f:id:yu_dotnet2004:20181203225132p:plain

その後、別のアカウントで GKE 上にサービスを一度復活させたのですが、やはりこの料金で稼働させ続けるのは無理という結論が出たので、現在もサービスは停止中です。

OSS 公開

そんなわけでこのサービスの世界線はしばらく止まっていたのですが、「せっかく作ったんだしOSSとして公開したらいいんじゃない?」という話が上がりました。

今回選択した技術スタックは「このすばCfP」の開発陣にとってはじめてのものばかりで、決して褒められたコードばかりではないという懸念もありました。しかし、こんなソースでも誰かの役に立てたらそれはとっても嬉しいな・・・ ということで公開することになりました。

ご注文はローカルでも Kubernetes が動かせる環境ですか?

そして、また思いつきで以下のような発言をし、

f:id:yu_dotnet2004:20181203225201p:plain

自分で発言した手前引っ込みがつかず、対応しました。

f:id:yu_dotnet2004:20181203225212p:plain

しかし、これどう考えても注文したの自分ですよね?

まぁコマンド1発で、ローカルに Kubernetes クラスタが構築できるようになったのは良いことでしょう。

$ ./bin/deploy-local-k8s.sh

今であれば Helm や Skaffold を使うのがベターなのでしょうが・・・まぁ Done is better than Perfect というやつです。 Kubernetes の Job まわりで面白いテクニックも発見したのですが、それはまた別の機会にでも。

おわりに

というわけで penginmura による OSS 公開の第一弾 ということになりました。決してきれいなソースでは無いですが、何かの役に立てればこれ幸いです。

ペンギン村の住人たちのことです。きっとこれからも OSS として公開していくものもあるのではないでしょうか。

つまりはこれからもどうかよろしくね!

Merpay Tech Talk #2 に参加してきました

はじめに

お疲れ様です。最近寒くてオフトゥンから出られないかむいです。

勉強会に足を運べていない日が続いていたのですが、今回はメルペイさんが主催する『Merpay Tech Talk #2』にお邪魔して来たので、レポートをまとめたいと思います!

mercari.connpass.com

この日はペンギン村の村民でもある@natpenguin氏も主催側で参加されており、久々にお会い出来て良かったです😃
発表されたテーマはUIにフォーカスを当てたものが多く、どれもiOSエンジニアにとっては関心の高い発表内容でした。  

「Cloning Photos app fluid interface」by @masamichiueta さん

 

speakerdeck.com

WWDC2018でもセッションがあった、iPhone Xなどに使われる操作インターフェースであるDesigning Fluid Interfaceについての発表でした。

メルペイのミッションに「信用を創造して、なめならかな社会を創る」という言葉があるとのことで、この発表でも滑らかな動きをどう実現し、ユーザーにどう体感してもらうかというテーマでお話をされていました。
  実際にWWDC2018のセッションで紹介されたFluid interfaceの話から「いつでも行ったり戻ったり出来ること」というポイントを取り上げ、実際にiPhone XとiPhone 8とのアプリのバックグラウンドへの退避例を挙げて説明をされていました。

また最後には標準の写真アプリにもFluid interfaceを意識した仕組みが用意されていることを例に挙げ、実際にクローンして動きを紹介しながら仕組みを説明してもらいました。

t.co

確かに何気なく使っている端末のジェスチャー1つ1つに、ユーザーの意思決定と並行にジェスチャー操作が行えるのは使いやすいですよね。
アプリ開発者としてUIを考える際に意識しないとなぁと再認識しました(・ω・)

「UIViewController in XIB + IBDesignable」by @akifumifukayaさん

speakerdeck.com

画面をレイアウトする際、iOSではStoryboardファイルがよく使われますが、Storyboardのデメリットを挙げつつ、xibファイルを使うとどんなメリットがあるかについて発表をされていました。
またIBDesignableを合わせて使うことで、よりxibが便利になることも合わせて紹介していました。

実際にメルペイのプロダクトでも画面レイアウトにはこの形を採用しているとのことで、@natpenguinさんからも発表にあったようなメリットがあることを教えてもらえました。

僕が所属するプロジェクトでは、Storyboardファイルを使いつつ、独自でDIを行える仕組みを構築し画面レイアウトに取り組んでいますが、内製化・堅牢化が過ぎると、今度はそのルールを理解するための取り組みが必要になるデメリットもあるんですよね。
(そこはチームの方針や運用ルールをしっかり決めれば問題は無いのですが)

今回のようにiOS SDKが標準で提供している仕組みを使い、新規の人でも「xibのイニシャライザを使ってDIを実現する」というシンプル且つiOSエンジニアには馴染みのある仕組みを採用する取り組みもまたメリットがあるなぁと感じました。  

「Functional programming for UI」by @Teddyさん

speakerdeck.com

トリを飾ったのは「UIのための関数型プログラミング」について発表された@Teddyさん。
ニューヨークから昨年来られたとのことで、英語の方が発表しやすいらしく、その注意を完璧な日本語で謝っておりました
個人的に問題の無さを感じつつも、この発表は英語で行われました。
(英語耳が育って無い僕ピンチ…!😇)

発表されたコードは、ある起点に吹き出しの矢印をあてたBalloonViewのポップアップ表示処理を連続でアニメーションさせる実装についてです。

大抵の場合は数が多ければ多いほど、コールバック地獄になりそうな処理をどう綺麗にまとめるかという点で、下記のREAD.meにも記載されているような関数を使うと、階層が深くならないコーディングを実現できるという処理について説明されていました。

 github.com

個人的に >>> が視覚的にわかりやすくて好きです。
(pbxpojファイルの競合箇所かと一瞬思ったのは内緒)

ソース上で使用それているキャラクターが可愛く、発表中にも良いアクセントにもなっていました。

BalloonViewに限らず、こうしたアニメーション処理を複数回連続で実施したいということは多くあることだと思うので「どのようにReadableなコードを実現するか」参考になる発表でした。

何よりもインパクトがあったのは発表後の質問タイムで、参加されてた@hatakenokakashiさんはじめほとんどが英語で質問し(!?)、またその質問に対する返しをTeddyさんが普通に日本語で返す(!!?)というやり取りが凄かったです。

皆さん外国語も技術力と兼ね揃えていてヤバみが深いです😇😇😇

ちなみに懇親会でTeddyさんと少しばかしお話させて頂きましたが、日本語の勉強期間をお聞きしたところブランクも含めてざっと3年ほどだそう。
自分がそのスパンで英語をどれだけ理解出来るようになったかと思うと目眩がした次第です笑

メルペイさんには凄いエンジニアが続々と参加されているなぁと感じた瞬間でした…!

f:id:kamui_project_tony:20181115210651j:plain
お肉だー!🥩 ✨ (あまり多く食べれなかったのが心残り笑

 

最後に

最近のiOSの勉強会では主に設計やテスト、CI/CDといったアプリ開発を支える技術のテーマが多くなってきている印象だったので、久々にUI実装の発表を多く聞けて楽しかったです。

参加者の関心度も高かったようで、まったく質問の手があがらないというようなことも無かったのが素晴らしいと感じました。僕も英語の勉強頑張らねばと痛感しました笑

楽しい勉強会の場を催して頂き、メルペイの皆様、ありがとうございました!

DroidKaigi 2019 のプロポーザル一覧を閲覧できる「とあるDroidKaigiの提案目録」をリリースしました。

どうも、最近涼しくなってきたので温泉が最高に感じる今日この頃な tobi462 です。

そんなわけで iOSDC Japan 2018 に続き、DroidKaigi 2019 のプロポーザル一覧を快適に見れるかもしれないサービスを開発・公開しました。

droidkaigi-index.penginmura.tech f:id:yu_dotnet2004:20181111195637p:plain

前回と同様に SPA で快適に検索・閲覧出来ることを目標としています。 また iOSDC とは違い、いわゆるプロポーザルの詳細画面が公式になかったので、SNSでシェアする目的にも使えるように用意してみました。

f:id:yu_dotnet2004:20181111195707p:plain

きっかけ

例によってペンギン村Slackでの発言がきっかけでした。 f:id:yu_dotnet2004:20181106214156p:plain

あいかわらず雑なノリだと感心しますが、賛同してくださった開発メンバーで作ることになりました。

それにしても間違って去年のDroidKaigiのURLを貼っているあたり本当に雑だと思います。

利用技術について

インフラ

前回は技術検証という意味も込めてインフラには「GKE(Kubernetes)」を採用しましたが、今回は「Firebase Hosting / Firebase Cloud Function」を利用したシンプルな構成にしました。

やはり「GKE」はランニングコスト的に厳しいものがあり、我々が支払い続けるのは無理だという結論が出ました。(そして前回の「この素晴らしいCfPに祝福を!」はサービスダウン中です)

そんなわけで、今回は逆に如何にランニングコストを下げられるか、ということで巷で流行りの「Firebase」をインフラとして採用してみた次第です。 まぁ料金を除いても、GKE(というか Kubernetes)は小規模なサービスに対しては複雑すぎるという真面目な理由もありました。

Webフロント

Webフロントには前回は「Vue.js」を使っていましたが、今回は巷で流行りの「Nuxt.js」を採用してみました。 最初はSSR(サーバサイドレンダリング)してSEOも考慮してとか考えていたのですが、最終的にはサーバレスで「Firebase Hosting」を利用しています。

まぁこのあたりは流行りの技術を使ってみたかったという気持ちが大きかったかもしれません。

デプロイ

デプロイは流行りの「Google Cloud Build(beta)」を使って自動化しています。 Firebase デプロイ用のトークンを暗号化するために「Google Cloud KMS」なんてものを使う必要があったりして、正直わりと面倒だったのですがそのあたりの話は機会があれば。

サービス名について

読み方は「とあるかいぎのいんでっくす」です。 なんだかとあるアニメのタイトルと似ている気がしなくもないですが偶然でしょう。

前回の iOSDC 向けには「この素晴らしいCfPに祝福を!」という SEO を120%無視したサービス名をつけたばかりにグーグル検索からたどり着けないというのが最大の反省点でした。

にもかかわらずこのサービス名・・・ペンギン村のメンバーは検索性よりもネタの方が重要なようです。

今後

開発メンバーのモチベーション次第ですが、機能追加とかはもう少ししていく予定です。 要望などがあれば対応していきたいという想いはありますので、Twitterなどで適当にコメントいただければと思います。

ということで、久しぶりにサービス告知の記事でした。

Swift 4.2 の変更点を iOSDC 2018 で話してきました

どうも、最近は「進撃の巨人 3期」が楽しみな tobi462 です。

しかし、最近一部の人達から「シュタインズ・ゲート ゼロ」を強烈に推されプレッシャーを感じる今日このごろです。いや原作こそ未プレイですがアニメ初期は見てますし、全話配信されたら見ようと思ってはいたんですよ?

レギュラートーク30分

はい、ということで iOSDC Japan 2018 にて 30分 のレギュラートークをさせていただきました。

去年は LT で発表させていただいたのですが、今年はレギュラートーク、しかも今までに経験したことがない 30 分の発表ということで、資料作り・発表練習ともに苦労した面も多いのですが、良い経験が出来たと思います。

正直なところを言うと、こんな平凡な(あるいは中身の透明性が高い)テーマを聞きに来る人はいないのではないかと思っていたのですが、予想に反して聞きに来てくれた人が多かったので嬉しかったです。

このテーマであれば後で資料を見れば十分だ、と判断された方も多いのではないかと思います。少なくとも私が参加者であればそういう判断をしていたと思います(苦笑)。まぁしかしスライドの出来はわりと良いと自負しているので、参加されなかった方もよろしければご覧いただければと思います。

今年の iOSDC

f:id:yu_dotnet2004:20180903003226p:plain

正直なところ「疲れた」というのが一番の感想でしょうか(笑)

登壇も含めて 3.5日 という日程はさして生易しいものではなく、もう若くない私としては日に日に消耗していた感もあります。 (ええぃ!スタッフの体力は化物か!)

しかし、イベントの質としては明らかに去年よりパワーアップしていました。とくに、

  • ルーキーズLT、iOSエンジニアに聞いてほしいトーク
  • Wifiネットワークの高速・安定化、無限コーヒー

といった点は非常に良かったと私は感じました。

初心者でも登壇しやすい空気を作りつつテーマの幅を広げ、イベント参加者がよりイベントを楽しめるようにする仕組み、ということを実現したスタッフの方々には頭が上がりません。

異なる関わり方

今回、iOSDC を陰ながら応援しようと思い、CfPの検索サービスを「ペンギン村 Tech」の一部の有志で開発しました。

blog.penginmura.tech

実は iOSDC 最終日に GCP の無料枠を使い果たしサービスダウン しているのですがそれはさておき。

当初、CfP の一覧を快適に見られるようにし、興味のあるトークを見つけやすくすることで、開発者の興味があるトークをSNSやブログでシェアしやすいようにするという狙いがありました。

今年は CfP が(たしか) 540 本も提出されたのですが、公式のプロポーザル一覧は検索もなければ10件ごとのページングによる画面遷移が必要で、とても興味があるトークがSNSでシェアされるようなUXが提供されているとは感じられなかった為です(そもそもプロポーザル一覧のページさえ見つけられない人もいたのではないかと思います)。

それゆえにこのサービスの企画初期の時点から SPA で開発することは決定していました。

この取り組みが功を奏したのかは実際のところわかりませんが、Twitterでは「役に立った」というコメントをいくつかいただけ、間接的ながらイベントに関わることが出来たのではないかと思います。

実のところ「API提供」や「iOS/Androidアプリの提供」も視野に入れていたのですが、開発メンバー3名のうち2名がレギュラートークに登壇することもあり、リソース的にそれは叶いませんでした。このあたりは来年(もありますよね?)、改善していけたらと思ったりします。

終わりに

まぁ、つまるところ「楽しかった!」です(笑)

私は基本的に人見知りで、こういう場でのコミュニケーションが苦手なのですが、発表・聴講・スピーカーディナーなどを通じて多くの開発者とコミュニケーションが取れて嬉しかったです。

私自身が iOS アプリ開発からしばらく離れていることもあり、他の登壇者のトークではとても多くのことを学べたと感じます。

そんなわけで関わってくれた多くの人に感謝の意を示しつつ、来年もまた楽しみにしています。 f:id:yu_dotnet2004:20180903003150p:plain

では。

iOSDC2018に参加してきました!

ども、かむいです。

 

僕は今回iOSDC初参加でした。
以前から行きたかったのですが、お仕事が…参加費が…CfPが…ごにょごにょ


そんなこんなでCfPは見事に不当選だったものの、ついにスポンサーチケットという素晴らしいアイテムを駆使して参加することが出来ました!


f:id:kamui_project_tony:20180902195937j:image


行った感想ですが、マジでハッピーな4日間でした!!


普段の勉強会でも参加するだけで刺激を受けるというのに、著名な方や初めてお会いする方、初めて登壇される方々のセッションをずーーっと1日中聴けるという体験は今年一番の思い出になりました。

 

f:id:kamui_project_tony:20180902200004j:image

ランチはどれも美味しかった…


また今回僕の同僚でもあり、31日のルーキーズ枠でも登壇した@hayatanさんの発表は応援する側ながら僕も緊張しっぱなしでした。無事終えられて良かったです。お疲れ様でした!mm
f:id:kamui_project_tony:20180902200031j:image

この人数の前で発表をやってのけるとか…メタルスライム倒した時並のレベリングが出来たに違いありません。


特に彼の発表テーマであった設計の話は、今彼と一緒に死にそうになりながら取り組んでいることの内容でして、その成果を以下の著名な方々に評価して頂けたことは彼と同じくらい僕も嬉しいツイートとなりました。

 

 

 

 

なお、前回の記事にもあった通りペンギン村から2名が参加し、彼らの勇士もしっかり見届けることが出来ました。きっと彼らからも思いの丈が追って聞けることでしょう(チラッ


最後に、参加された方々は(ほぼ)iOSエンジニアで、同じ苦労をされてる人たちとお話できたのはとても良かったです。
普段勉強会でお会いしてる人、改めてどんな仕事をしているか深くお話しできた人、はじめましてな人。
ここまで繋がりを多く持てるイベントもiOSDCならではなんだなぁと思えました。


また来年こそは、CfP投げまくって、登壇を勝ち取りたいと思います!


f:id:kamui_project_tony:20180902221541j:image

 

運営スタッフの皆さま、登壇・参加された皆さま、登壇頑張った同じ村民のtobi462さんk_miyasakaさん、そして自分、乙!!!

ペンギン村 Tech から 2名 が iOSDC 2018 に登壇します

f:id:yu_dotnet2004:20180829182353p:plain

どうもご無沙汰しています tobi462 です。iOSDC Japan 2018 の開催がついに明日にせまりましたね。

以前の記事で軽くふれましたが、ペンギン村 Tech からは私と k_miyasaka の2名が登壇します。

blog.penginmura.tech

せっかくなのでトークに対する一言コメントを紹介したいと思います。まぁお約束的な感じですね(笑)

Swift 4.2 はどのような進化をしているのか

  • tobi462
  • 2018/08/31 11:20〜 Track B レギュラートーク(30分)

Xcode 10 から Swift 4.2 に変更となりますが、変更点のチェックはお済みでしょうか? CfPを出す現時点で Swift 4.2 には 18個の Proposal が実装されています。 本トークでは時間の許す限りで、すべての Proposal についてその解説を努めていきたいと思います。

https://fortee.jp/iosdc-japan-2018/proposal/a355f634-3855-40ff-882e-328704bd6136

一言コメント

コメントするまでもなく内容が透けて見えるトーク概要ですが(苦笑)、30分という短時間でプロポーザルをざっと駆け巡って「効率的にキャッチアップしてもらう」というのを目標にしています。

ただ、それだけだと味気ないと感じたので 今までの Swift の歴史を振り返ってみた上で、Swift 4.2 がどのように進化しているのかという構成にしてみました。

30分という短時間で多くを語ることは出来ませんが、楽しんでもらえたらと思っています。

果たして30分以内に本当にすべてを喋り切ることができるのか、それもあるいは見どころの一つかもしれません(が、がんばるぞい・・・)

LLDBを最大限活用してみる。

  • k_miyasaka
  • 2018/09/02 15:10〜 Track B レギュラートーク(15分)

XCODEのデバッグ機能は便利で、スタックトレースとpoコマンドの入力だけでもゴリゴリとデバッグできる方が多くいらっしゃると思いますが、 それらはLLDBの機能の氷山の一角です。 不具合の原因検知、修正だけでなく、 リビルドせずにコンソールからUIを変更するなど新規コーディングでも活用できる方法を発表致します。

https://fortee.jp/iosdc-japan-2018/proposal/db9e05a4-2357-4140-8274-c642e158f1d9

一言コメント

現在のSwiftはOptional Bindingやenum、structなど、静的に安全を保障できる機能が多々あります。

その反作用として、デバッグ実行時の操作のの自由度はObjective-Cに比べると格段に下がっています。

プログラミングはデバッグの時間が大半を占めるといわれているので、Swiftのデバッグ手法については改善の余地が多々あると思います。

今回はLLDBのもつ無限のポテンシャルを生かし、そのいくつかの手法、方針を提案させていただきます。

おわりに

そんなわけで、登壇者からの一言コメント紹介でした。

あとは皆様との機会があえば当日の発表でお会いしましょう。(べ、べつに私達のトークを聞きに来てほしいってわけじゃないんだからね///)

では。