Twitter にアクセスするだけで参加できます。
順番を待たずに、 Twitter で気軽に質問できます。
発表内容に直接リプライ・リツイートできます。
発表中に内容を見返し、自分のペースで理解できます。
発表者・参加者が同じ時間に集まっていることで、質問や議論をリアルタイムに進めることができます。 Twitter とはいえ、普段面識のない人には話しかけるのは遠慮してしまいがちですが、同じ Swift Tweets の参加者なら相手もそのために時間を割いていることがわかるので、懇親会で話すかのように気軽に話しかけることができます。
JOIN US のエンジニア。 Qiita (@mono0926) ・ Medium の Publication ・ Build Insiderオピニオン などで、多数の Swift ・ iOS 系記事を書いている。開発だけでなく最新ガジェット使うのも好き。
Qoncept のエンジニア。小学 4 年生のときにゲームを作りたくてプログラミングを始める。そのときの経験を元に、 RPG を作りながらプログラミングを学ぶ SWIFT QUEST を開発中。 Qiita での Swift に関する投稿が人気。
Wantedly の新規アプリ開発エンジニア。 Swift について発表したり Qiita (@susieyy) で Swift について書いたりしています。
「たるのんだよ。すいふとをかくけど、おぶじぇしいもかくよ。」博多で Swift 書いてます。 associatedtype
でガチガチに固めたコードを渡すと喜びます。 GitHub はこちら。
22:00 |
オープニング |
---|---|
22:05 |
"Swift時代に悩ましいUIViewControllerをどう扱うか"@susieyyiOS アプリ開発において 今回ご紹介する方法が一般的により優れているということではなくアプリの要件、開発規模、チームメンバー構成、設計方針により適応できるかどうかはケース・バイ・ケースになると思うので開発の選択肢の1つとして捉えていただけると幸いです。 |
22:35 |
"Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい"@koherSwift Core Team がエラー処理について言語設計時に考察した “Error Handling Rationale and Proposal” というドキュメントがあります。その中で、プログラミングにおけるエラーが次の四つに分類されています。
考えれば考えるほど、この分類が本質的で素晴らしい、 Swift に限らないものだとわかってきました。 Swift を書く上でエラーをどう設計すれば良いのか、 Java の検査例外はなぜ失敗したのか、多くの言語のエラー処理機構には何が足りないのか、この分類を通して考えたことを紹介します。 |
23:05 |
"Swiftの型の限界を超える"@tarunonSwift で |
23:35 |
"SwiftのString(文字列) APIとの付き合い方"@_monoSwift の String (文字列) API は、文字列の概念を厳密に扱うようになっており良くできています。その反面、難しい・取っつきにくい・普段取り扱う際に不便、など気になる点もあります。そんな Swift の String API とどのように付き合っていけば良いだろうか、という考察をしていきます。 前提として以下の記事に記載されている内容を理解済みとして、 Unicode・Swift の String API の仕様自体の説明は発表では最小限とする予定です。 |
24:05 |
"型推論のビルドが遅いらしいから調べてみる"@jpmartha_jp |
24:10 |
"恐怖!忍び寄るライブラリへのロックイン"@takasek |
24:15 |
"関数型プログラミングの実際のところ"@S_Shimotori_pub |
24:20 |
"Never GiveUp"@es_kumagai |
24:25 |
"iOSにおけるクリーンアーキテクチャよもやま話"@ktanaka117 |
24:30 |
"Clean Architecture 開発ツールの話"@yhirose741 |
24:35 |
フリートーク発表内容やその他 Swift について、自由にツイートする時間です。普段は、いきなりメンションツイートで何かを質問したり意見を聞いたりすることは難しいと思いますが、この時間はオフラインの懇親会のように自由に交流して下さい。 Swift Tweets の参加者一覧はこちらです。 |
24:55 |
クロージング |