iOSDC Japan 2019 トーク一覧

他イベントOK レギュラートーク(30分)

もっと便利に使おう、Hyperion

Kenzo Nirasawa nirazo
Hyperion-iOSをご存知でしょうか?
iOSの端末やSimulator上でデザインチェックができる、素晴らしいツールです。
非常に有益なツールなのですが最近は開発が滞っているようで、サードパーティのプラグイン開発手法のドキュメントについては
> The plugin creation guide is a work in progress
のまま動きがありません。

本トークではそんなHyperion-iOSのサードパーティプラグインの実装にフォーカスし、実際に便利なプラグインを作ってみたいと思います。

このトークをきっかけに、Hyperionのコミュニティをより広げ、iOS開発に関わるメンバーがより実用的にこのツールを使い、より良いアプリを作れる世界を目指していきます。
他イベントOK レギュラートーク(30分)

もっと使える!Lottie

Kenzo Nirasawa nirazo
アプリ上でアニメーションを実装する際に、Lottieは有力な選択肢となります。
アプリ上での実装は非常に簡単であり素晴らしいライブラリなのですが、それ故にただ漫然と使用していることも多いのでは
ないでしょうか?
また、
・ちょっとしたアニメーションでしか使わないでしょ?
・デザイナーさんへの修正依頼の往復が地味に面倒…
などの悩みをお持ちの方も多いのでは無いかと思います。

そこで本セッションでは、
Lottieを
「ただファイルを読み込んで使う」から
「多様な使い方をする」「デザイナーとのコミュニケーションをより効率的にする」へ、
より活用するための知識共有や知見の紹介をします。

トーク概要
- Lottieの仕組み
- Lottieでできること
- Lottieに向いていないこと
- Lottie導入時のTips
他イベントOK レギュラートーク(60分)

もっと使える!Lottie

Kenzo Nirasawa nirazo
アプリ上でアニメーションを実装する際に、Lottieは有力な選択肢となります。
アプリ上での実装は非常に簡単であり素晴らしいライブラリなのですが、それ故にただ漫然と使用していることも多いのでは
ないでしょうか?
また、
・ちょっとしたアニメーションでしか使わないでしょ?
・デザイナーさんへの修正依頼の往復が地味に面倒…
・個人開発でデザイナーさんいないしアニメーションなんて作れない!
などの悩みをお持ちの方も多いのでは無いかと思います。

そこで本セッションでは、
Lottieを
「ただファイルを読み込んで使う」から
「多様な使い方をする」「デザイナーとのコミュニケーションをより効率的にする」「アニメーションを自分で作って使う」へ、
より活用するための知識共有や知見の紹介をします。

トーク概要
- Lottieの仕組み
- Lottieでできること
- Lottieに向いていないこと
- Lottie導入時のTips
- Adobe After Effectsを使ったアニメーションの作り方
他イベントOK レギュラートーク(30分)

花火大会向けアプリをサーバレスで作った話

Atsushi ec16091g_cap
地方の花火大会向けのアプリの一部機能をサーバレスで作ったお話です。
なぜサーバレスでやったのか?というところから、
そもそもなぜ花火大会にアプリが必要なのか、花火大会の当日の運用などイベント系アプリ特有の開発・運用の難しさについてトークします。
他イベントOK レギュラートーク(30分)

iOSエンジニアが知っておきたいアプリ分析入門

Atsushi ec16091g_cap
みなさん、リリースしたアプリちゃんと分析していますか?
リリースしたけど、あんまり分析せずに放置。。なんてことも多いと思います。
本セッションでは、アプリ分析って何やったら良いの?という方向けに、次の項目を説明します。
- そもそも分析に必要なデータってどうやって取るの?
- 取ったデータをどう調理するの?
- どういうデータを見ればいいの?

分析する際にアプリの中身を知っていたほうがより深く分析できますが、アプリ開発を行っていない人がアプリ開発を学ぶより、
アプリ開発者が分析手法を学んだほうが早くて、確実です。これは間違いないと思います。
2
他イベントOK iOSDCルーキーズLT(5分)

エセつよつよエンジニアになる方法

uhooi the_uhooi
「つよつよエンジニア」、それは全エンジニアが目指す最強の称号です。

つよつよエンジニアになるためには、長年にわたる努力に加え、第一線で成果を出す必要があり、その道のりは長く険しいです。

しかし、ちょっとした工夫をすることで、誰もがつよつよエンジニアのように見せかけることが可能なのです。

ちょっとした工夫の例↓
・TwitterでIT関連のツイートをする
・Twitterでエンジニアの方と交流する
・Qiitaに記事を投稿する
・Qiitaの記事にコメントする
・勉強会に参加する
・勉強会でLTをする

つよつよエンジニアに見せかけることを、私は自虐的に「エセつよつよエンジニア」と呼んでいます。

私は少しでも他の人の役に立てば「エセつよつよエンジニア」でもいいと思っています。

みんなで優しい世界を作りましょう。
そうすればいつかきっと真のつよつよエンジニアになれる日が来ます!

---

本セッションではエセつよつよエンジニアになる方法を伝授します。
私がどのような思いでTwitterやQiitaを使い、勉強会に臨んでいるか、時間の許す限り語ります。

【想定する聞き手】
・つよつよエンジニアでない人
・エセでもいいので他の人の役に立ちたいエンジニアさん

【ゴール】
・SNSで気軽にエンジニアの方と交流できるようになる
・Qiitaなどを活用して知見を広めるようになる
・iOSDC Japan 2020に登壇する意欲が湧く
2
他イベントOK LT(5分)

無理しないで続ける個人アプリ開発・運用

かっくん fromkk
# TypeというMarkdownエディタアプリの開発・運用を初めて丸2年半が経過しようとしています。「会社での業務をしながら個人的にアプリを開発したり運用したりするのは大変じゃ無いか?」と思われるかもしれませんが、(2019年6月現在)月に一度から二度程度の更新を続けてこれています。ここでは

- モチベーションの保ち方
- どういう方針で更新しているのか
- 問い合わせ対応の方法
- CI/CDの活用

を踏まえてどの様に省エネで開発・運用しているのかを紹介します。
2
他イベントOK iOSDCルーキーズLT(5分)

サービスの価値を最大化するためのテスト戦略

kariad kariad_uu
iOSアプリ開発ではテストは日常的に行われています。
しかし私たちは一体何のためにテストをしているのでしょうか。

やるのが当たり前だからでしょうか?
品質を高めるためでしょうか?

それらの理由もあるかもしれません。
しかし本来私たちが目指す場所はただ一つ、
アプリが提供するサービスの価値の最大化、
すなわちユーザーに喜んでもらうことなのではないでしょうか。

そしてテストは適切に行うことでサービスの価値の最大化のスピードを早くしてサービスの価値を高めることが可能です。

本トークでは今まで何となくテストをしていた…という方に向けて、
サービスの価値を最大化するためにはどのようにテストを行っていくべきかという「テスト戦略」についてお話しいたします。
2
他イベントOK レギュラートーク(30分)

Re: ゼロから始めるWatchApp開発

くろるり kuroruri
AppleWatchが発売されて約5年程たち、我々の生活の中でもスマートウォッチ自体珍しいものではなくなってきました。
ですが我々のアプリはスマートウォッチにきちんと対応できているでしょうか?対応していないか、あるいは発売当初の珍しさに乗っかった一過性のアプリがあるだけだったりしないでしょうか?
ではもし、そんな一過性のアプリを不意にメンテナンスすることになったらどうしましょう?Objective-Cなんて読めないし、使っていたライブラリはメンテされていない、そんなコードなんてメンテできるわけがありません。きっと作り直すはめになるでしょう。
あるいは今あるアプリに対しWatchアプリを組み込んでいくことになったら、iOSとは勝手の違うWatchOSアプリをどう作っていけばよいでしょうか?
本セッションではWatchAppをゼロから作り始める人及び作り直す人向けに、WatchAppの作り方を基礎からプロダクトを実際に作るレベルの発展編まで解説するとともに、開発時のいくつかのTIPSを紹介します。
本セッションのゴールは聴衆がOSSライブラリを使用したiOSアプリとデータをやり取りするWatchAppを作れるようになることです。

#Agenda
基礎編
- iOSAppとWatchKitAppの関係性、WatchKitとWatchExtension
- UIレイアウト
- iOSAppとWatchKitApp間のデータ連携
発展編
- iOSとWatchKitAppでコードを共有する
- carthageを使ってOSSライブラリをWatchExtensionで使う
TIPS編
- ライブラリ使用時の実機デバッグ遅い問題
- Menuボタン表示時のライフサイクルの罠
3
他イベントOK iOSDCルーキーズLT(5分)

VIPERに魅力を感じるのは間違っているだろうか

uhooi the_uhooi
「RxSwiftなどのMVVMアーキテクチャが主流でも、私はVIPERを使い続けています」

---

みなさんは「VIPER」というアーキテクチャをご存知でしょうか?

一言でいうと「Clean Architecture + MVP + Router」を組み合わせたアーキテクチャです。

5つのレイヤーに分かれているのが特徴で、各レイヤーの頭文字を取って「VIPER」と呼ばれています。
・View (GUI)
・Interactor (ビジネスロジック)
・Presenter (ビューロジック)
・Entity (エンティティ)
・Router (DI、画面遷移ロジック)

実は、私は約半年前までVIPERを知りませんでした。

しかし、VIPERを知って実際のプロジェクトで使うことで、魅力を感じるようになりました。

非常に優れたアーキテクチャなのですが、あまり使われていないように感じており、寂しいです。

本セッションでは、VIPERの概要とメリット・デメリット、そして魅力を熱く伝えます。

【想定する聞き手】
・VIPERを知らない人
・VIPERを使っていない人

【ゴール】
・VIPERを好んで使うようになる
2
他イベントOK レギュラートーク(30分)

RxSwift だけで満足してない?サーバ上のデータの変更もリアクティブに受けとる仕組み

辰濱健一 tatsuhama50
昨今リアクティブプログラミングが注目され、RxSwift を使った iOS アプリ開発が主流となっています。
そして、WWDC 2019 では Apple からも Combine Framework が発表されました。
これにより、一層リアクティブプログラミングの導入や推進がされていくことが予想されます。

しかしながら、クライアントサイドだけに RxSwift を導入して満足していませんか?
サーバ上の最新のデータを取得するために、ポーリングを用いたり画面表示のたびに API の呼び出しをしていませんか?

本セッションでは、アプリケーション内に表示する未読件数バッヂの API を題材として
・Silent Notification
・Firebase Cloud Firestore
・GraphQL(AWS AppSync)
など用いて、サーバ上のデータ変更をリアクティブに受け取る方法への置き換えと、それぞれの特徴について紹介します。

この機にクライアントサイドだけに導入していたリアクティブプログラミングの考え方を、サーバ上のデータの変更にも広げてみませんか。
そして、通信やサーバ負荷になっている(かも知れない)ポーリングに別れを告げましょう。
5
他イベントOK iOSDCルーキーズLT(5分)

iOS 11.1でUIAlertViewの選択肢がタップできなくなる絶望から復帰した物語

uhooi the_uhooi
約2年ほど前、iOS 11.1のβ版でアプリをテストしていたときのことでした。

「あれ?アラートの選択肢がタップできない」

発生しないこともあるので、最初は気のせいかと思いました。

しかし、気のせいではありませんでした。

調査した結果、「iOS 11.1以降で、UIAlertViewの選択肢がタップされるのをウェイトしている場合、アラート表示のトリガーとなるボタンなどを『素早く』タップすると、選択肢がタップできなくなる」ことがわかりました。

原因がよくわからず、アプリの広範囲に及ぶクリティカルな不具合。

iOS 11.1のリリースが迫る中、私たちがとった行動とは…?

※本セッションではObjective-Cのコードのみ扱います。ただし、Swiftのみ扱っている方でも理解しやすい内容となっています。

【アジェンダ】
・不具合の概要と発見した経緯
・不具合の調査結果
・対応策の検討と、実際に対応した方法

【想定する聞き手】
・クリティカルな不具合の発生時、どのような行動をとればいいか悩んでいる人
・レイヤーを気にせず、どんなクラスからでもUIAlertViewを表示している人
・UIAlertViewを使い続けている人(UIAlertControllerでもこの不具合は発生します)

【ゴール】
・クリティカルな不具合の発生時、どのような観点で行動すればいいかわかる
・iOSのβ版でテストするのも大切だということを理解する
・MVCなどのアーキテクチャに沿って実装することの重要性を認識する

クリティカルな不具合の発生時、アプリの規模やユーザー数、緊急度によって対応方法は変わってくると思います。
本セッションで紹介する対応方法はあくまで一例ですが、少しでもみなさんのお役に立てば幸いです。
2
他イベントOK レギュラートーク(30分)

何故に私達(特に私)はアプリのアニメーションやUI表現に魅了されるのか?そして共存と向き合いを考える

酒井文也 fumiyasac
私達が普段からよく利用しているアプリや平素での開発を通じて、アニメーションやユーザーインタラクションを利用した表現やUI実装に向き合う機会は、どのような局面においてもあるかと思います。

今回の発表では下記5つのトピック

1. iOSアプリ開発におけるアニメーションやUI表現はなぜ必要なのか?
2. アプリの見え方や使用感 / 触り心地という観点でのもたらす効果は?
3. 実装に至るまでに考慮しておくべき点はどの部分か?
4. コードに落とし込む際にポイントとなるのはどこか?
5. アプリにおける「触り心地」と「機能」との両立をいかにバランスを取るか?

(時間があれば、開発者の観点から見た「アニメーションのやりがいや魅力」とはもお話できればと思います)

という着眼点から、サンプルコードやアプリ事例から考察したものや考えを、お話倒していければと思います。
そして皆様の平素の開発において、豊かなUI表現を実装していくためのアイデアやヒントにほんの少しでもなれば嬉しく思います。
他イベントOK LT(5分)

iOS開発でありがちなConflictの解消による弊害とそれを解決するGitテクニック

417.72KI 417_72ki
XcodeGenの登場により、我々は.xcodeprojをGit管理する必要が無くなりConflict問題から解放される術を得ました。

しかし、それと同時にbranch切り替え時にファイルの追加/削除を気にしなければならなくなりました。
なぜならそれらは.xcodeprojが把握していたものだからです。
.xcodeprojが変更されないため、ファイルが増えたり減ったりしていてもプロジェクトには反映されないのです。

CocoaPodsやCarthageでも同じことが言えます。
PodsやCarthageフォルダをGit管理していない場合、Podfile.lockやCartfile.resolvedが変わっていないか気にする必要があるのです。

このセッションでは、この問題を解決するために使ったGit hooksという仕組みについて簡単に話します。
他イベントOK レギュラートーク(30分)

「型を使う」の意味について考えよう ~型安全と心理的安全を求めて~

shiz stzn3
Swiftは型を持つ言語です。
私たちはSwiftを使っている限り型を必ず使用しています。

しかし、型をいつも意識してコードを書くことはあまり多くないのではないでしょうか?

私はこれまでに仕事で複数の言語を扱ってきましたが、
型というものを当然あるものとしてあまり意識してきませんでした。

しかし、iOSエンジニアとして働くために
Swiftという言語と向き合う時間を増やしていく中で
型に関しての意識が強くなり
型を意識して使うことでより安全に安心して開発を進めることができると思うようになりました。

今回は

「型ってなんだろう?」
「型を使うことで何が良いんだろう?」
「型を意識したコードの書き方ってどういうものがあるんだろう?」

などについてお話ししたいと思います。
※コンパイラの話は出てきません。

私ようにこれまで型について何となく使っていたという方が

「型があるって良いな」
「型をもっと意識して使ってみよう」

と思えるきっかけになり
より安全に安心した開発を進めるための一助になりましたら幸いです。
8
他イベントOK レギュラートーク(30分)

環境設定をYAMLで管理したかったのでツールを自作してみた

417.72KI 417_72ki
「AdHocビルドでは検証環境向けたいからこのURL、Releaseビルドでは本番環境向けたいからこのURLをセットする」
「Releaseビルドとそれ以外でログの出し方を変えたい」
といった設定、皆さんはどうしていますか?

R.swiftというツールの登場により、画像やstrings等のリソースをほぼ全て静的に扱えるようになりましたが、
これのベースになっているAndroidにはRの他にBuildConfigという自動生成ファイルがあり、
これを使ってデバッグ時とリリース時で環境を切り替えることができます。

このBuildConfigと同じことをiOSでも実現したいと思い、
YAMLファイルを読み取ってPlistとSwiftファイルを自動生成するBuildConfig.swiftというツールを開発しました。

このセッションでは、以下についてお話できればと思います。
- デバッグ、ステージング、リリースで変わるもの
- なぜYAMLで管理するのか
- BuildConfig.swiftについて
2
他イベントOK LT(5分)

はじめてのこんとりびゅーと ~OSSは怖くない!~

417.72KI 417_72ki
OSSへのContributeというと始めは気が引けるものです。
しかし業務でどうしても欲しい機能があったため、勇気を出して自分で実装してPRを出してみました。
その時の体験談をお話しします。
2
他イベントOK レギュラートーク(30分)

雰囲気でやっていくRxSwift

ひろん hironytic
全て熟知する必要はありません。雰囲気さえ掴めば自
然とRxSwiftが使えるようになります。本トークでは、
わたしが普段思い描いているRxSwiftの動作イメージを
かんたんなポンチ絵とともにゆるく共有します。それ
らは正確性よりもイメージを優先したものですが、み
なさんの理解をきっと助けます。さあ雰囲気でやって
いきましょう!

RxSwiftというオープンソースライブラリがあります。UIとデータのバインディング機構を持たないiOSプログラミングにおいて、MVVMアーキテクチャーを実現するためによく使われているライブラリであり、今さら?と思う人がいるくらいには普及してきたと言っていいでしょう。
しかし、手続き型プログラミングに慣れた人にとってRxSwiftのリアクティブプログラミングの考え方は取っ付きづらいこともあります。その原因は、何がどう動いているのかを想像しづらい点にあると思います。
RxSwiftの人気が出始めたSwiftがまだ2〜3の頃、データの流れるストリームを川に例える話をよく見かけました。私も当初はそのようなイメージで触り始めましたが、それでは引っかかる点もあり、現在は全く違ったイメージを持っています。
本トークではRxSwiftの初心者を対象に、私の持つRxSwiftの動作イメージを紹介します。「オブザーバーパターン」や「関数型プログラミング」といったキーワードは登場しません。プログラムの動作の雰囲気をゆる〜く解説します。
5
他イベントOK 技術パッション共有トーク(60分)

ファミコンエミュレータづくりの魅力

マスクドPHPer MaskedPHPer
「ファミコンエミュレータを作る」と聞いて何を思い浮かべますか?
多くの方は何をどうしたら良いのか全く想像が付かないと思いますし、私もそうでした。

2016年2月にPHPで書かれたゲームボーイエミュレータ php-terminal-gameboy-emulator が話題になりました。このとき、PHPならばということでコードを読んでみました。エミュレータのコードを読んだのは初めての経験だったのですが、大きな衝撃を受けました。それ以前からCPUやメモリ、この頃のゲーム機に共通する仕様のことは知っていたのですが、php-terminal-gameboy-emulator のコードに見たものはその仕様がそのままPHPのコードとして表現されたものだったのです!

そしてその2年後、あるカンファレンスでファミコンエミュレータに関するトークを聞いた時に、2度目の衝撃が私を襲いました。そこで紹介されたコードはその場で初めて見るにもかかわらず、断片を見るだけで内容が理解できたのです。

このトークでは2度目の衝撃を受けて私が書いたファミコンエミュレータを題材に、エミュレータのコードの特長や設計、そしてその魅力をお伝えします。
エミュレータは決して難しいものではなく新しい言語の学習や設計の練習にちょうどよいテーマでもあります。このトークを聞けばきっと一度エミュレータを書いてみたくなるでしょう。
1
他イベントOK 技術パッション共有トーク(60分)

ファミコンの画面描画を知る

マスクドPHPer MaskedPHPer
ファミコンの画面は8x8ピクセルで定義されたキャラクタを敷き詰めた画像(BG)の上にやはり8x8ピクセルで定義されたキャラクタ(スプライト)を重ねて描画されています。その名の通り多くの場合BGでゲームの背景を、スプライトでゲームの主人公や敵キャラを表現することになります。

この「BGとスプライトでゲーム画面を描画する」という設計はファミコンに限らず、PCエンジン, ゲームボーイ, メガドライブ等々、PlayStationより前のゲーム機に共通する設計でした。
すでに発売されているゲーム機より高い性能、より良い表現を求められるであろうゲーム機の設計においてなぜ画面描画に関する設計は共通になっているのでしょうか。それには当時の技術的な制約、出力先である家庭用テレビの仕様が影響していました。

このトークでは私が書いたファミコンエミュレータのソースコードを題材に、ファミコンの画面描画の仕組みや、画面描画をエミュレータでどの様に設計・実装しているのかを解説します。
そして、このトークを通してエミュレータのコードが「得体の知れない難しいもの」ではなく読んで楽しく、書いてみたくなるものであることをお伝えします!
1
  • 1
  • 2 (current)
  • 3
iosdc-japan-2018 sponsors iosdc-japan-2018 potential-sponsors 開催後請求
ブースWL 要支払確認 要モノクロロゴ
仮採択 採択しない Rookie
仮採択 採択済 保留 情熱加点 採択しない 前夜祭 目玉 ルーキーズLT参加
Order#確認 アンケートメール不要