じっくりコツコツおいしい知見シチュー

日々学んだことをアウトプットしていきます.

iOSDC2019に参加しました

はじめまして.川口です.関東近辺の大学に生息してます.

昨年度に引き続きiOSDCに参加しました.

本記事では聴講した一部のセッションの所感を綴ります(これをI will Blogと呼びます).

また,ブースの手伝いをしたのでそれについても.

去年のI will Blog

rivemo.hatenablog.com

聴講したセッション(一部)

speakerdeck.com

タイトルの通り,Swiftにおけるインポートとリンクの仕組みを説明したセッションでした.

前提知識の説明も丁寧だったため,非常に分かりやすかったです.

自分が低いレイヤーに弱いため聴講してみました. 

まず前提知識として,フレームワークとライブラリ,およびインポートとリンクの違いなどを知れたのは非常に良い機会となりました.

そして,それらの概念をXcodeがどのように取り扱い依存関係を解決しているかが分かりました.

今後,依存関係の解決が失敗してしまった場合はこのスライドをもう一度見てみたいと思います.

 

 

speakerdeck.com

(1)わかりやすい,(2)安全,および(3)変更に強いといった特徴を持つ「クリーンコード」を書くためにはどうしたらいいかをユースケースを基に説明するセッションでした.クリーンなコードが書きたいため聴講しました.

取り扱う問題への課題解決方法として主にジェネリクスを用いており,既存のAPI Clienetを抽象化する形式でセッションは進みました.

テスタブルにするためもしくは同じロジックを散らかさないために,自分自身がこういった抽象化をしていくのが好きなので,興味深く聞けました.

個人的には特にModelにIDを生やす下りがキレイで見ていて楽しかったです.

一方で,ModelにapiBaseを生やすのはModelの変更理由を2つ以上にしてしまっている印象を受けたので機会があれば聞いてみたいです.(といってもapiBaseが変わる頻度はかなり低いので問題にならなさそうですが)

同じ著者の別の本は読んだことがあるのですが,クリーンコードに関しては読んだことが無かったので読んでみたいと思いました.

 

www.slideshare.net

開発中のアプリにテストを入れる際に考えた思考プロセスについて紹介したセッションでした.発表者の方がiOSの設計本の共著者であったため聴講しました.

簡単なユニットテストは書いたことがあるのですが,腰を据えてテストを書かざる得ない状況に立ったことが無いため,セッションを通して追体験が出来て勉強になりました.

アプリの可用性を担保するために理想論的には網羅的にテストを書くべきですが,現実問題それは時間・金銭的に不可能な時はあるかと思います.

そういった際に,どういった痛みを許容するかといった視点は非常に有益だと感じました.

また,同じ理由で初期はテストを書かない判断を下すことも多いですが,テスタブルな設計にしておくのは非常に重要だなあと思いました.

 

他にも勉強になったセッションはあるので,順次追記していきます.

 

Swift UI Bookの配布

WantedlyのブースにてSwift UIに関するテックブックの配布を行いました.

たくさんの方が来てくださって,お手伝いの立場でしたが嬉しくなりました.

9/15,9/25にSwift UIに関する勉強会も行われるようなので参加したいと思います.

www.wantedly.com

 

総括

iOSDCは単に勉強出来るだけではなく,来年も参加したいと思える温かいコミュニティのように感じます.

運営してくださっているや発表者の方々に感謝します.

来年はプロポーザルを出します.

それでは.

twitter.com

 

RealmSwiftを使用していてつまずいた点

 

大学生なう川口です.

今回はRealm Swiftを使用してつまずいた点を述べます.

 

Realm Swiftとは?

Realm DatabaseはRDBを提供するライブラリです.

対応言語は,JavaJavascript,そしてSwiftなど.

Realm SwiftはSwift版のRealm Databaseとなります.

(Core Dataのラッパーになるのかな.)

 

Realm SwiftはRDBの形式でデータを永続化する際によく用いられます.

また,リアクティブプログラミングに対応しており,データの変更を通知してくれるといった機能もあり,RDB以外の機能も強力です.

 

www.xlsoft.com

 

つまずいた点①: Realm Objectはスレッド間を跨いだ受け渡しは出来ない

Realmインスタンスや,データ構造を定義しているRealm.Objectを継承したクラスのインスタンスはスレッド間を跨いだ受け渡しが出来ません.

こちらは公式の対応があり,インスタンスの実態ではなくその参照を表したインスタンスの受け渡しによって,スレッドを跨いだ受け渡しが可能です.

realm.io

一方で,この方法を用いる場合はチームメンバ全員がある処理がどのスレッドで行われるか理解し,更に扱っているオブジェクトがRealm Objectを意識しなくてはいけません.

もし,見落としがあった場合はランタイムエラーが起きてしまうので,実装する際は慎重さが求められます.

僕は,①あるオブジェクトに対してそれがRealm Objectかどうか意識したくない,②ランタイムエラーが怖い,といった理由で下記のような実装にしました.

 

qiita.com

 

この方法の問題点は必要以上に型定義が増えてしまう点だと思います.

しかし,この問題はコードの自動生成によって解決し得ると考えています.

Swiftでは下記のようなライブラリを用いることによってコードの生成が可能です.

github.com

 

つまずいた点②: Realm Objectは複数ターゲットに含めない

テストをする際にテスト対象のファイルをテストのターゲットに含めるかと思います.

その状態からテストをビルドすると,複数ターゲットにRealm Objectをインクルードしてはいない,といった旨のエラーが出ます.

じゃあ,テストするにはどうするかというと下記のような対策方法が有効であると報告されています.

 

qiita.com

 

ターゲットに含めるのではなく,@testableを用いたimportを行えば良いようです.

 

つまずいた点③: 書き込みトランザクションが発生しているスレッドにて別のトランザクションが発生するとランタイムエラーが起こる

完璧に実装の仕方が悪いのですが,仮にそういったことが起きたとしても良い感じにしたいです.

と思い調べたところ下記のような解決方法を見つけました.

stackoverflow.com

書き込みトランザクションが開始しているなら直ちに処理を実行し(既存のトランザクションに処理を追加する),開始していないなら書き込みトランザクションを開始する方法です.非常にシンプルです !! 良い.

 

所感

スレッドを意識したプログラミングはあまりやったことが無かったので,スレッドに関係する部分で躓くことが多かったです.

アプリを作るときはRxSwiftを使って非同期処理をバチバチに行うことが多いので,余計にスレッドにまつわるエラーが出た......のかもしれない.

DBみたいなバチバチな実装の詳細部分によりクラッシュエラーを生んでしまい,ユーザに迷惑をかけたくないのでバチバチに理解していきたい.

 

それでは.

twitter.com

アプリケーションの設計に関する勉強会を始めました

f:id:rivemo:20190809152902p:plain
 

大学生なうの川口です.

最近,アプリケーション設計の勉強会を知人と始めました.

 

きっかけ

勉強会を始めてみた理由は下記の通りです.

1.継続して学びを得るために

僕はモバイルアプリケーションの開発を大学3年生からはじめました.

始めてから1年ほどは日々自分の技術力が成長しているのを感じていたのですが,それ以降はあまり自分の成長を感じられず,それについて課題感を持っていました.
理由としては,実装方法を問わなければ大抵のサービスは実装できる,もしくは実装方法について推測出来るようになったからだと思います(iOSアプリに限って).

解決の糸口を探るべく,周りの優秀そうな同期や先輩方を観察してみたところ,単に手を動かすだけではなく日々コツコツとインプットしていらっしゃる方が多いことに気づきました.

そこで,継続的にコツコツと学びを得るために勉強会を行ってみることにしてみました.

2.チームの力を生かした勉強をするため

これまでの学生生活から,複数人が集まって勉強をするといろいろ良いことが

あると感じています(この考えは大学入試の勉強を友人と集まって行っていた経験に基づいています).

例えば,ある本を読むときに輪講の形式を取ると効率的にその本を読むことが出来ます.
また,読んだ本について議論することによって本の理解度が高まります.

こういった恩恵を得るために複数人が集まる勉強会の形を取ってみました.

 

勉強会の概要

勉強会では,設計に関する本を参加者で回し読みをし,週に1回発表と議論を行います(つまり,輪講です).

また,発表をする際のプレゼンテーションの資料だけではなく,読書中の感想やメモをまとめたものをScrapboxを使って共有するようにしました.

輪講に使用する本は下記の本としました.
この本にはソフトウェア開発における,設計の意義や正しく設計するための手法などが豊富な例と共に書かれています.

モバイルアプリを開発する上で設計の知識をどのように付けるか悩んでいたところ,iOSの設計手法について本を書かれた方から下記の本を紹介して頂き,下記の本を採用しました.

 

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

 

 

 準備資料

準備資料は以下の2点です.

1.スライド

https://speakerdeck.com/k_kohey/ahurikesiyontesain-5

 

2.Scrapboxに読書メモ(任意)

f:id:rivemo:20190809153613p:plain

読書中に重要だと感じたものをメモしたもの

 

こちらの記事を拝見して,発表資料はScrapboxのプレゼンテーション機能を使用することで準備コストを減らそうかと検討しました.

しかし,今回の勉強会の場合は発表者が読んだ本の知識を発表社以外にしっかりと伝える必要があると感じたためスライドの作成を行うようにしました.

勉強会の回転率が悪そうであれば,再度Scrapboxのプレゼンテーション機能の使用を検討したいと思っています.

qiita.com

 

やってみた感想 

まず,上記の本はモバイルアプリの設計について書かれた本ではないです.
しかし,普遍的・本質的なことが書かれているので十分モバイルアプリに適応出来ます.
「本に書かれていることを,モバイルアプリ開発に適応させるとどうなるだろう?」といった議論が参加者とともに出来て現状とても勉強になっています.
同時に,議論を行うことによって一人で読んでいるよりも知識が頭に定着していると実感しています.

また,勉強会の準備資料として読書中のメモなどをScrapboxで共有するようにしているのが非常に良いと感じています
ちょっと忘れてしまったことがあっても,それを見ると解決することが多いです.
記憶はいつかなくなりますが,Scrapboxの記事はなくらないので,財産を残すという意味で有意義となっています.

最後に,勉強会を始める際は狙っていなかった勉強会をすると良い点が見つかりました.
それは,モチベーションの維持です.
今回取り扱っている本は700ページほどあります.これは辞書ほどの分厚さです.
それを一人で読むのは中々モチベーションの維持が難しそうですが,現状仲間がいるおかげか全く苦に感じていません.

 

課題と今後の展望

コツコツとインプットすることが重要といったことを冒頭に話しましたが,やはり学ぶ上においてもアウトプットは大事です.

なぜなら,知識を得る事と知識を活かすことは別であり,知識を得るだけではなく活かす方法についても学ばなくてはいけないと思うからです(経験則的にこの意識を忘れると,手段と目的が入れ替わる).

今後は,あるソースコードリファクタリングを行うといったアウトプットを行うワークショップなどを開催してみたいと思いました.

 

最後に

今回紹介した勉強会は週1時間ほどしか時間を取っていません.

多忙な学生の方,都内の勉強に行けない僕と同じ地方大学生の方,ぜひ試してみてください.

また,試してみてうまくいった施策などがあればぜひ教えて下さい!

 

それでは.

 

twitter.com

r.com/goosun1110

 

 

 

 

 

 

FabricからFirebase Crashlyticsへの移行でつまずいた点

背景

FabricっていうTwitter社が持っていたサービスがGoogleに買収されてFirebaseのFirebase Crash Reportingっていうサービスと併合されました.New service name is Firebase Crashlytics

グーグル、Twitterの開発者プラットフォーム「Fabric」を買収へ - CNET Japan

 

というわけで移行作業が必要になってくるのですが,少しつまずいた点があったので備忘録を兼ねて記録を残しておきます.

 

環境

objective-CとXcode10です😃

 

問題

Firebaseのドキュメント通りに移行作業を行ったはずが下記のようなエラーログが吐かれてクラッシュログがFirebaseに送信されません.

[Fabric] failed to download settings Error Domain=FABNetworkError Code=-5 ~~ (以下略)

400系のエラーが出ているので,なにか送信している情報が不足しているようです.

解決策

Firebaseに移行するにあたって,<アプリ名>-info.plistに記されていたFabricのキーを消してあげないとビルドが通りません.かつ,この情報はFirebaseがよしなにinfo.plistに挿入してくれるはずです(Firebase Crashlytics setup on iOS? - Stack Overflow)

しかし,どうやら認証情報の受け渡しがうまくいってなかったようなので,FabricのAPIのキーを消さずに&&Build PhaseにFabricをRunさせずに&&AppDelegateでFabricを開始させたらうまくいました.

この記事が参考になりました

medium.com

 

 

それでは.

 

 

スカラーシップ枠でiOSDC2018に参加してきました.

はじめまして.
大学生なうの川口です.
今回はWantedlyさんのスカラシップスポンサー枠でiOSDCに参加してきました.

 

www.youtube.com

 

スカラシップサポンサー枠

まず,スカラシップサポンサー枠について簡単に説明します.

iOSDCについはご存知のご存知の方は多いと思うのですが,スカラシップサポンサー枠についてはご存知でない方はいらっしゃると思います.

下記のリンクからスカラシップサポンサー枠の概要を引用すると

【概要】 
2018/8/30-9/2に開催されるiOS Developers Conference Japan 2018に向けて、iOS開発者の大学生・大学院生を対象に、参加費および旅費(宿泊費・交通費)を支援し、コミュニティーへ参加する機会を提供させていただくことになりました。

 

つまりiOSDCに無償で参加できる可能性がある学生限定の枠 !

今回はありがたいことにその枠で参加させて頂きました.

www.wantedly.com

 

 

会場の雰囲気

ざっくりiOSDCの会場の雰囲気について.

会場に着いたら,まずステッカーやフライヤーがたくさん入った袋と,身元を照明する首にさげるやつをもらいます..今回はWantedlyさんがスポンサーとなっているスカラシップ枠での参加ということで,ステッカーを貼らせて頂きました.

f:id:rivemo:20180905003754j:plain

 

会場に入ると企業ブースが!! ぶらぶら歩いているだけでも楽しい......
特に印象的だったのは,アンケートが盛んに行われていたことです.このコードどうやって書く?? アーキテクチャなに使ってる?? といったような.

MVCって以外に使われてるんだな~~」とか,逆に 「こんな書き方あんの?!」といった世の常識を知れたりして楽しかったです.

例えば,guarrd let self = self else { ... } といったふうに`self`の名前を使ってselfをキャプチャ出来ることをここで知りました.

f:id:rivemo:20180905004935j:plain

 

あと毎日,お昼ごはんが入った箱を配布してくださっていてそれが美味しかったです.

f:id:rivemo:20180905011440j:plain

こんな感じの会場に4日間居ました.

発表について

本題です.

iOSDCでは4つの部屋で行われている登壇者による発表を自由に聴講する事ができます.夏フェスをイメージしていただけると分かりやすいと思います.

毎セクションどれを見に行くか非常に悩みました笑.自分は,自分でも試せそうな事,今のトレンドっぽい事,の2つを指標にして選びました.

今回,自分が聴講した中から幾つかピックアップして概要や所感をまとめていこうと思います.

標準アプリから学ぶ、HIGが教えてくれないiOSデザインのこと

speakerdeck.com

 

新しいインタフェースの誕生するコンテクストを

  1.  技術的制約・進化
  2. ユーザの進化
  3. より高度な要件

の3つに分類した考察は納得の行く所が多く,勉強になりました.

開発者はアプリを通じて,ユーザ体験を提供します.それを伝える架け橋となるインタフェースへの理解は,よりよいアプリ開発のために,開発者も知っておいて絶対に損は無いな,と思いました.

 

キラリと光るテクニック、アプリをデモするときの心構え/iOSDC Japan 2018

speakerdeck.com

プロダクトを展示する際に気をつける事をまとめた発表です.
最近,AR系の作品の展示を行ったこともあり,自分の実体験と重なるところもあって楽しかったです.シンプルに貴重な知見なので,もし次展示することがあれば,また読み直したいと思いました.

 

とある端末の触覚技術 -フィードバック-

speakerdeck.com

 

iPhone6s以降のハードウェアから導入された触覚フィードバックについてのTipsです.

どのように触覚フィーダバックを発生させるかといった使い方から,どのような場面に使うと良いかといったユースケースまでの説明があり,今日からでも使える実用的な知見を得られました.

自分の学びをまとめると以下のような感じです.

  1. フューチャーしたい機能には触覚フィードバックを検討してみる.
  2. 音と一緒に使ってみると効果的
  3. 多用はしない

Introduction to micro interactions for iOS apps

speakerdeck.com


アプリの使い心地を向上ために,アニメーションを導入してみよう,といったお話でした.

まずHIGにあるように,アニメーションのためにアニメーションを導入する訳でない無いという事を念頭に置いたあとに,アニメーションを導入する意義やその実装についての説明がありました.

実装の説明もすごく丁寧でありがてぇ....🙏
気軽に試してみる事ができる内容だったので,聞いててワクワクしました.
また,アニメーションの実装について心理的障壁がグッと下がりました.

AutoLayoutエラー診断所 ~発狂しないためのデバッグ手法~

speakerdeck.com

 

Auto Layout でハマりがちなエラーを,実演方式で解決していく発表でした.

発表を聞いた感想は...

  • 私の所持するパソコンは非常に重く,デバッグに時間を要します.
  • コードでレイアウトするのでエラーが動かすまでわかりません.

この2つの制約から,多くの時間をAuto Layoutに食われてきました.

しかし,この発表を見てから,Auto Layoutに使っていた時間をジムでのトレーニングや家族への時間に使えるようになったのです.

....

実際にAuto Layout のデバッグ時間を家族への時間に当てられるかはわからないですが,間違いなく効率化はできそうです

今後は下記のサイトを利用したり,” e*1.backgroudColor = [UIColor red]

” といったふうにデバッグ画面でUIを操作しながらデバッグしていきたいです !!

WTF Auto Layout?

Synchronized iPhones

speakerdeck.com

タイトル通りですが,発表者が複数の端末において同期した処理を行った話です.
自分はこの発表で紹介された技術についてより,発表者が発表者の持つ課題を解決していくプロセスがとても興味深く,聞いていて楽しかったです.

方法論も学べる発表ってこれから学んでいく人間にとってとても勉強になります.

学びとしては,使用を検討する技術や仕組みは徹底的に調べる,仮設をしっかり立てる,検証する,といった感じです.何かうまくいかないときは,何が問題なのかといった視点を常に持ちたいです. 

 

他にも勉強になった素晴らしい発表が無限にあったのですが,無限にブログを書き続けることも出来ないので今回はこのあたりにしておこうと思います.
やっぱりインプットだけでは分かりきっていないところもあると思うので,紹介されていた技術を実際に使ってみて,改めて感想を綴れたら良いなと思ってます.

 

その他の催し

登壇者による発表以外にも,懇親会やライブコーディングなどが行われました !

懇親会では,発表者の方やWantedlyさんの方々と話す機会があり,とても有意義な時間でした!

f:id:rivemo:20180908094912j:plain

懇親会で配布されていたビール

 

 

f:id:rivemo:20180908095046j:plain

LT会のビール

 

 

Wantedlyさんによるライブコーディング

github.com

 

トントン拍子でコードが出来上がっていくのを見るのは,エンタメ的な楽しさがありました.

もちろん,勉強になった点もいくつかあって,ReactorKitには以下のようなメリットがることが分かりました.

  • 状態管理の見通しが良くなる.
  • シンプルで強い制約があるので迷わない.
  • 適切な粒度に責務が分割出来る
  • reduceが純粋関数なのでテストがしやすい

 

終わりに

こういった大規模なカンファレンスに参加すると,今トレンドの技術などのキーワードを高速にキャッチアップすることが出来ると感じました.

また,発表内容自体にも多くの学びがあり,とても楽しかったです.

そして,いつかは自分もiOSDCで登壇したい,と思いました.

 

Wantedlyさん,iOSDCの関係者の皆さん,今回はお世話になりました.ありがとうございました !!

 

それでは. 

 

*1:UIView*)addres

成績開示の結果

本学の入試かというところで受け取りました。お金はいらないみたいです。

以下がその結果です。

 

外国語:97 / 100

専門科目:143 / 200

総合:240 /300

 

ボーダーすれすれの200点を攻めてるかと思いきや、結構余裕がありました。

8割取れてるってことは結構良い方じゃないんだろうか.

先人から教わった、とにかく解答用紙に文字を書きまくり理解してる感を演出する作戦が当たったようです。

私の勉強期間や勉強方法と照らし合わすと編入試験対策の材料になるかもしれない.ならないかもしれない.

 

 

筑波大学 編入体験記 

筑波大学情報学群情報メディア創成学類編入学試験(H29)の体験記です.

 私自身が先輩方の編入体験記に助けられていました.
これから編入を志す方々の参考になればと思い公開します.

続きを読む