「ファミコンエミュレータを作る」と聞いて何を思い浮かべますか?
多くの方は何をどうしたら良いのか全く想像が付かないと思いますし、私もそうでした。
2016年2月にPHPで書かれたゲームボーイエミュレータ php-terminal-gameboy-emulator が話題になりました。このとき、PHPならばということでコードを読んでみました。エミュレータのコードを読んだのは初めての経験だったのですが、大きな衝撃を受けました。私は以前からこの頃のゲーム機に共通する仕様や、CPUやメモリについての知識は持っていたのですが、php-terminal-gameboy-emulator のコードにはそんな仕様がそのままPHPのコードとして表現されていたのです!
そしてその2年後、あるカンファレンスでファミコンエミュレータに関するトークを聞いた時に、2度目の衝撃が私を襲いました。そこで紹介されたコードは初めて見るにもかかわらず、断片を見るだけで内容が理解できたのです。
このトークでは2度目の衝撃を受けて私がPHPで書いたファミコンエミュレータ php-terminal-nes-emulator を題材に、エミュレータのコードの特長や設計、そしてその魅力をお伝えします。
CPUの動作(メモリアクセス, I/O, …)
エミュレータでの実装
ハードウェア仕様のソフトウェアとしての表現
エミュレータは決して難しいものではなく新しい言語の学習や設計の練習にちょうどよいテーマでもあります。このトークを聞けばきっと一度エミュレータを書いてみたくなるでしょう。
昨今やっとマイナンバーカードが普及してきており、マイナンバーカードを読み取って本人確認を行ったり、確定申告の電子申告を行ったりするサービスが増えてきました。
今後も(政府が頑張れば)マイナンバーカードは色んな情報を取得するのに使われていくでしょう。
今回では実際にマイナンバーカードの読み取りをプロダクトに組み込んだときの話を織り交ぜながら、マイナンバーカード読み取り機能の実装方法を紹介していきます。
[Target]
・今後マイナンバーカード読み取り機能を開発予定の方
・マイナンバーカードの読み取り方法について興味がある方
・マイナンバーカード読み取り機能をプロダクトに入れたときの苦労話を聞きたい方
[Goal]
・マイナンバーカード読み取り機能を実装する際に障壁無く実装出来るようになっている
・マイナンバーカード読み取りをプロダクトに導入するには何が必要なのか知っている状態
ソフトウェア開発において、チームのパフォーマンス改善は皆さんが継続的に取り組んでいる課題の1つだと思います。
チームのパフォーマンスを定量的に評価する代表的な指標として、GoogleのDORAという研究チームが確立したFour Keysがあり、これらの指標を使ってチームをそのパフォーマンスに応じてエリート、高、中、低に分類することができます。
iOSのチーム開発においても、デリバリーフローやオブザーバビリティを改善していくことでエリートチームを目指すことができます。
このトークでは、まずFour Keysとその定義を紹介し、計測方法について整理します。次に、iOSアプリ開発におけるボトルネックと、Four Keysに取り組む上での難しさについて解説します。また、私達のチームでの具体的な取り組みを紹介し、みなさんのプロジェクトでも明日からエリートチームを目指せるようにしたいと思います。
Swift向けのコードテンプレートを作成できるStencilを知っていますか?
実はSwiftGen, Kitura, Sourceryといった著名なOSSでも使用されている面白い言語です。
用意されたコマンドを用いることで、OSSでは簡単にコードを生成することができますが、自分でカスタマイズすることも可能です。
このセッションでは、どのようにしてStencilを使っているのか紐解いていきます。
また、Xcode templateやSnippetといった既存の言語テンプレートとの比較も交えて、どのように使っていくのかをご紹介していきます。
参考文献
Stencil: https://github.com/stencilproject/Stencil
StencilSwiftKit: https://github.com/SwiftGen/StencilSwiftKit
ネイティブではもう無理だと 諦めていたのにどうしたの?
あの頃 僕達はさ 何でもできる気がしてた
2軸で表を描いては たくさん点を打ったね
でも見てよ今の僕を クズになった僕を
Chart.jsをWebViewで見せても 何も感じ取れなくてさ
別にChartを求めてないけど 急に出されると思い出す
ラインチャート(折れ線グラフ)&バーチャート(棒グラフ)の そのグーラフのせいだよ
このトークでは、WWDC22で発表されたSwift Chartsフレームワークについて話します。
まだ発表直後でベータ版ですが、できる限り様々なチャートを触り、見た目や使い方などを紹介します。
Firebaseには、NoSQL DBのCloud Firestoreやバックエンドコードを実行可能なCloud Functionsといった機能を備えており、インフラのことをほぼ意識せずとも、サーバーレスなアプリを立ち上げられる他、クライアントに提供されているSDKを利用し、クライアント間でのデータ同期や、オフラインデータの永続性といったアプリの体験に寄り添った機能を享受できます。
一方、DBはスキーマレスであることや、クライアントから直接DBにアクセスするなど、馴染みがない仕組みも多く、仕様や特徴を踏まえた開発を行わないと、セキュリティやユーザー体験に悪影響を及ぼしたり、負債となる要因になり得ます。
本セッションでは、クライアントエンジニアのみのチームでサーバーレス開発を行う中で見えてきた、効果的にFirebaseを利用する方法を事例と合わせて紹介します。
CombineはiOS13から登場した時間変化による値の変化を処理するための宣言的なAPIを提供するフレームワークです。
今秋にはiOS16が登場し、iOS14以上をサポートできるアプリも多くなった昨今。
Combineは新しい技術ではなく、当たり前の技術となりました。
一方コミュニティを見回すと、当たり前のようにCombineを使いこなす層とまだまだCombineの勘所を得ることができない層との間に断絶があるように感じます。
SwiftUIとも密接な関係があり、せっかくのApple標準のフレームワークであるCombineを覚えないのはもったいない!
ということで、興味がある方みんながCombineに入門できるようなトークをしたいと思います。
本トークでは概念を頭で理解するというより、ちょっとずつステップを踏むことで「手を動かしていったら自然に理解が進んだ」を目指します。
ディープリンクは、ブラウザや他のアプリからターゲットとなるアプリへのシームレスな遷移のために重要な技術ですが、まとまった情報が意外なほどありません。
iOS / Androidのアプリをディープリンクに対応させるときに悩んだことと、それにどう対処したかについてお話しします。
アプリのCIサービスとしてBitriseはそれなりに定着してきてますが、アップル自身もXcode Cloudをベータリリースしており、そして今年正式リリースされると予想されます本日のWWDCで正式リリースしました。
ちょうどBitriseが料金体系を改訂して従量課金しかなくなったからトライ&エラーのコストが高くなるからメリットが非常に薄くなるし、何よりアップル本家が作っているという安心感(?)。
というわけで、これまでBitriseで回してたプロジェクトを、試しにXcode Cloudに移行してみたので、その過程をみなさんと共有したいです!
Storyboard辛い!Auto Layout難しい!でもSwiftUIのおかげでこれらとおさらばだ!!
そんな甘い思い、私にもありました…まさに若さゆえの過ち…
そう、SwiftUIがリリースして3年経った今でも、まだ我々はレイアウトのナイトメアから解放されていません…
この発表は、そのSwiftUIにまつわってよくある落とし穴やぶつかりやすい壁を紹介し、それらの理由と正しい回避策をお伝えしたいと思います!
チーム開発を経験されてるあなた、「静的チェック」は聞いたことあるでしょうか?そう、CIを回す時に、Lintを適用するとか、スペル確認を行うとか、そう言った機械的なチェックを行うことです。
そしてある程度の経験がある方でしたら、DangerというRuby制のツールを聞いたことある、あるいは今でも使っている方もいらっしゃるではないでしょうか。
実はそのDanger、本来はRubyでスクリプトを書かないといけないですが、Swiftでスクリプトを書くDanger-Swiftも存在しているんですよ!
この発表はSwift信者として、そのDanger-Swiftの良さを全力で伝えたいと思います!
みなさん、証明書管理やデプロイなど何使ってます?やはりFastlane?ですよねーFastlane便利ですもんね
でもFastlaneはRubyで書かないといけないからそこ大変ですよね、Rubyは型が保証されないから使うときドキドキするし、初心者がそもそもRubyの導入で躓きやすいので。
というわけでSwiftlaneを使ってみてはいかが?我々iOSエンジニアが使い慣れてるSwiftで書けるからとっても書きやすいですよ!はいこの発表はSwiftlaneの布教です!
Carthageでビルドしたframeworkを共有キャッシュとしてS3などで管理できるツールのRomeがついにXCFrameworkにも対応しました。
Swift Package Manager対応のライブラリも増えてきていますが、まだまだCarthageを利用されている方もいると思います。
今回はRomeに関する以下の内容について、具体的な設定ファイル、スクリプトコードを用いて説明します。
・共有キャッシュの導入することでビルド時間をどれだけ短縮できるか
・XCFrameworkを共有キャッシュとして、S3およびローカルドライブで管理する方法
・(現状のリリース版に残っている)Romeのバグに遭遇した際の対応方法
iOSアプリ開発の周辺技術としてRubyは非常に人気な言語です。パッケージ管理のCocoaPods、静的検査のDanger、そしてCI/CDスクリプトのfastlaneなどなど、Rubyは幅広く使われています。
しかし初心者にとってRubyも一つの鬼門なのです。たとえば誰でもPermission Denied問題に一度は会ったことあるでしょう。右も左も分からない初心者がネットで検索するとすぐ「sudoすれば上手くいくよ」と悪魔の囁きを目にします。怖いですね。
というわけでRubyを開発過程から排除できないか?誰でも簡単にできるより安全な環境構築の仕方ないか?この発表はその脱Rubyの仕方をお伝えします。
普段とりあえず入れて何気なく使われているCrashlytics
CrashlyticsはCrash検知だけでなく、Error・Bug検知にも使えます
本当は必要なErrorを取り逃がしていませんか?
Errorの設計や、実装方法と活用を紹介します
Flutterで利用したアプリケーションでは初期状態だとパッケージ管理ツールはCocoaPodsが設定されます。
今までSwiftで開発をしていた人はCocoaPodsだけではなくCarthageやSwift Package Managerを利用している人もいると思います。
実際に試してみた
mamariではオンボーディング強化のため、昨年末からFirebase Remote Configを用いたABテストを繰り返しています。
このトークでは、ABテストを継続的に続けることで得た知見をできるだけシェアしたいと思います。
モニタリングはサービスの開発・運用において重要な要素です。
しかし、ノウハウがある程度確立しているバックエンドやインフラ領域に比べ、クライアントサイドではまだ事例が少ないこともあり、手探りの運用にならざるを得ないケースが多いのではないでしょうか?
本トークでは、バーチャルライブ配信アプリ「REALITY」の事例から、指標収集のための実装や、FirebaseやBigQueryなどの外部サービスとの連携など、継続的品質改善のためのiOSアプリのモニタリング手法についてお話しします。
iOSで無線通信 Bluetoothを扱うために存在するCoreBluetoothはiOS 5.0の時代からある歴史のあるものです。
昔触ったことのある人であれば、CoreBluetoothは一部のBluetoothの用途でしか使えない、ごく機能の限られたもの、という印象があるかもしれません。
しかし最近のCoreBluetoothは新規のAPIの追加という形では少ないものの、LE 2M PHY対応やBR/EDR向け対応など、できることは確実に広がっています。
そんなiOSのBluetoothに関して、2022年現在改めてCoreBluetoothではどういったことが実現できるのか、CoreBluetoothについて紹介し、iOSの無線通信の可能性を見出すトークとする予定です。
「REALITY」アプリでは、クライアントとサーバ間のHTTP通信の定義にProtocol Buffersを導入しました。
Protocol BuffersとはGoogleによって開発されたシリアライズフォーマットであり、共通のスキーマからSwiftやKotlin、Goなど各言語向けに必要なコードを自動生成します。
gRPCとセットのイメージのProtocol Buffersですが、バイナリに変換してHTTP通信のbodyに載せることで、プロトコルはHTTP通信のままに、共通のスキーマや、高速、軽量のシリアライゼーションなどProtocol Buffersの恩恵を受ける事が可能です。
このトークでは、Protocol Buffersを使ったHTTP通信の定義に加え、Swiftで独自のprotocのpluginを実装し、クライアントで必要なコードを自動生成する方法を紹介します。