2019年3月21日（木）、3月22日（金）の２日間に渡って行われたカンファレンスと、
3月23日（土）に行われたワークショップに参加してきました。
https://www.tryswift.co/events/2019/tokyo/jp/
また、その前日に行われた「Global Communication Workshop for try! Swift」にも参加してます。
https://tryswifttokyo.connpass.com/event/118413/
覚えているうちに、その中でも印象に残ったセッションについて覚書を残しておきます。
全部まとめて書こうと思ったのだけど、長くなり過ぎたので日付分割。
雑感
「Global Communication Workshop」、またカンファレンスに参加して思ったのは
月並みですが、「英語勉強しないと損だな」という感想。
どちらも、ある程度リスニングはできるんですがわからない単語が多すぎる。
単語がわからないと、結局何を言ってるのかわからない状態。
conversationすらわからないと、そりゃ会話の意味も通じないよね。
カンファレンスには同時通訳があるんだけど、やはり話している内容とは時差が生まれてしまうのと
意味とか、どうしてそういう言い回しになっているのかまで含めて訳しているわけではないので
同時通訳を聞いていてもあまり頭に入ってこない。 場合によっては通訳レシーバー外してしまった。
日本の人でも挑戦してみたいってことで英語で登壇している人が多くて、
twitterなんかだと好意的に受け取ってる人がかなり多いみたいだったけど
私としては、日本語話せる人には日本語でやって欲しかった。
ただ、その中でもMichael Ilsemanさんの「賢者のString」発表では英語のセッションなんだけど
通訳待ちもしながら時間内に発表を綺麗に納めていて凄かった印象。
あとは、大半のセッションについては「どういう話をするか」ってのはわざわざプレゼン内で言ってくれないので
事前に確認しておくことが内容の理解を助けることになった。
1日目午前中のセッションまではそのまま話を聞いていたせいで、何が話したいのか理解するまで時間がかかることも。
native macOS application、またはAppKitの世界
https://speakerdeck.com/1024jp/native-macos-application-or-the-world-of-appkit
macOSのアプリを開発している人は、会場でも5%程度しかいない。
nativeとは何か？
iOS appならば frame = device となるため、Title Bar なども独自性の高いデザインにしても違和感はない。
macOS app では frame = window。 自由に窓のサイズを変えることもできるし、１つの画面に複数の window が並んでいることを前提として考えないといけない。
どの window でも、同じ目的を持った、同じ用途の部品は同じように動くことが必要。
ユーザーは個々のアプリケーションのみを使っているわけではなく、「macOSのアプリケーション」を使っている。
native であるということは、開発者のエゴを消すこと。
ユーザーにとって一番良いことは、ユーザーが特別なことは何も考えずに目的へ集中できること。
APPKit's API と macOS Human Interface Guide をちゃんと使おう。
Mazipanがそろそろ来ることも考えなければいけない。
（iOS⇔macOS⇔iPadのクロスプラットフォーム）
雑感
macOS に native なアプリケーションの考え方。
確かに普段使っているmacOSのアプリは Title Bar の色やアイコンのテイストなど、標準を意識して作られているものが多く、またそれが重要なことがわかる。
今後のMazipanに対応した実装がどのようになるかわからないけど、
両対応を考えるならばアプリとしての統一感より、macOS に配慮したレイアウトを気をつけなければ。
この次のセッションも含めて聞いて、ちょっとmac OS向けのアプリが作りたくなっていたので
macアプリに関するworkshop 選択しておけばよかったかなとは思った。
さすがに疲れてて、24日の勉強会にも参加できなかったけど・・・。
アクセシビリティのためのカラーコントラスト
ユーザーに正確な情報を届けるためのカラーコントラスト
これが明るすぎないか、読みやすいのかはどう判断すれば良いのか。
白と黒を使えば一番コントラストが強い。しかし、色というのは非常に強力なコミュニケーションツール。
例えば「止まれ」という看板。日本語がわからないと書いてあることの意味はわからないが、
赤で表現されていることで、注意を喚起している、ということはわかる。
白黒だけではいけない。では、どうやって好きな色を使いつつコントラストを気にすれば良いのか。
HIG（Apple's Human Interface Guidelines）は重要な出発点。
https://developer.apple.com/design/human-interface-guidelines/
Appleからは特定の比率になるように、という記述がある。
Use sufficient color contrast ratios.
Insufficient contrast in your app makes content hard to read for everyone.
Icons and text might blend with the background, for example.
An online color contrast calculator can help you accurately analyze
the color contrast in your app, to ensure that it meets optimal standards.
Strive for a minimum contrast ratio of 4.5:1, although 7:1 is preferred
because it meets more stringent accessibility standards.
では、その数字がどこから来たのか。 これはWeb Content Accesibility Guidelinesを参照する。
https://www.w3.org/TR/WCAG20/
少なくとも4.5:1、テキストが小さいときは7:1以上を使うことが書いてある。
ではこの比率はどのように計算すれば良いのか。
これに関しては計算してくれるツールを公開しているサイトがあるし、REST APIも提供されている。
https://webaim.org/resources/contrastchecker/
macOSの一番注目された機能はダークモードだった。
Asset Catalog は色を指定することにも利用でき、macOSでは明るいモード、暗いモードの色を定義できる。
iOSでも同じような機能が実装されるかもしれない。
雑感
色の指定はこれまで完全にデザイナーさんに任せていて、
少し視認性が悪そうなデザインがあった場合にも感覚的に見辛いとか、そういった表現しかできていなかった。
このセッションのおかげで、カラーコントラストについての具体的な数値を出せるようになった。
今後デザインフィードバックを返す際に、参考にする。
テストケースでMemory Leakを発見する
https://www.icloud.com/keynote/0v-uQow7QXtpwDMs2CN8LHxiQ#try!swift2019tarunon
メモリリークはどのように防止すれば良いか。
- コードレビュー
- コーディングルール
- Lint
- Memory Graph Debugger
でも、すごく時間がかかって面倒なところがある。
そこでテストケースを作ろう。
Mirrorとweakの箱を使います。 MirrorはSwiftにおけるRefrectingの機能。
画面を鏡に写すと、全てのプロパティが見えるようになるので、それを全てweakリファレンスの箱に入れる。
そうして元の画面を解放すると、weakの箱の中身も全てなくなるはず。
これを実現したのが、XCTAssertNoLeakになります。デモは失敗。
https://github.com/tarunon/XCTAssertNoLeak
ただし、Swift4.2では動作しない。 なぜか。
Mirrorでweakなプロパティにアクセスするとretainされてしまう・・・。
メモリリークのテストをしようとして関数を通すと、メモリリークが起こる。
雑感
絶対メモリリークしてそうなので、1回アプリにテストケース通してみたいんだけど
Swift4.2で運用してるから使えない・・・。
Swift5では大丈夫そうなので、覚えていたら1年後くらいに使ってみる。
ARKitのアプリを作ろう
https://github.com/namratabandekar/talks/blob/master/SoYouWantToBuildAnARKitApp.pdf
ARKitを使ったアプリの紹介や、ARKitを使うときの注意点など諸々。
雑感
ARKitを実際に使うときに参照しながら見た方が良い内容。
直近で作る予定は無いが、実際に使ってみようかなと思わせるセッションだった。
ARには、1回使ってみることで見えてくる発想もあると思う。
Introducing SourceKit-LSP
LSP（Language Server Protocol）とは
エディタなどで補完やクイックヘルプなどの機能を実装するためには、
そのままだと各言語ごとに実装が必要になってしまう。
それを解決するのが、LSP。
JSON-RPCでエディタと各言語がやり取りを行う。
例えばこれを使うことで、VimでSwiftの開発を補完ありで行うことも可能になったり。
雑感
最初はXcode使えばいいじゃんって感じで思っていたのだけど
Server Side Swift のことなどを考えるとLSPって重要だなと。
try Prototype!
なぜ私たちはコードを書くのでしょう？私は疑問に思っていました。
コードはどれくらいの期間存続すると想定されていて、どれだけ使い捨てられるのでしょう？
最終目標がユーザーに優れた便利な機能を提供することである場合、
堅牢なコードに到達するために使い捨てるコードを書く価値はあるのでしょうか？私たちは優れたプログラマーとして、技術に磨きをかけますが、ただ正しくものを構築するのではなく、
正しいものを構築するためにこれらすべての知識をどのように活用できるかを見てみましょう。
それぞれの問いに対する答えは自身の状況に合わせて考えていただければ。
ライブデザイントーク。
Q0. Why are you a developer?
なぜみなさんはデベロッパーなのでしょう。なぜいまデベロッパーとして仕事をしているのでしょうか。
PROTOTYPE MINDSET
Know your motivations
自分のモチベーションを知る
Q1. Who do you write code for?
コードはだれのために書いているのでしょうか。
（自分のため、会社のため、ユーザーのため、etc...）
PROTOTYPE MINDSET
Saying yes, means saying no
なにかにYesと言うことは、なにかにNoと言うこと。
当たり前かもしれないけど、あえて一度止まって考えることで自分のモチベーションを意識する機会が生まれます。
Q2. What do you do when technology changes?
世の中が変わったらどう対応しますか。
専門分野が変わったときに、どう対応できますか。
PROTOTYPE MINDSET
Learn how to learn
開発の中で大事になってくるのは、学び方を学ぶこと。学びながら同時にコードをリリースする。
Q3. When writing code, how do you factor in how long it needs to last?
コードを書くときに、コードがどれくらいの期間存在するべきと考えていますか。
We care about good, robust code
PROTOTYPE MINDSET
Be less precious about code
コードに特別感は持たない方が良い。技術スタックはすぐに変わる。
考え方を分けて行くことが重要だと思います。コードにどのように実務的に対応するのが良いか、考えていく。
Q4. What has held you back from shipping your work?
何があなたのコードリリースを阻害しているのか
私にとっては「恐怖感」です。
もっと改善できたのではないか、適切な条件になっていないとレビューやユーザーに
出すべきではないと思ってしまう。 本来、それほどこだわる必要はないのに。
PROTOTYPE MINDSET
Overcome fear
リリースするときには、あまり心配するようなことは実際にはない。
進捗を早くすることが大事。方向性を早く打ち出し、フィードバックを得る。
そうした方が長期的に正確度も高まり、早くリリースすることができる。
Q5. How often do you test?
最後に、どれくらいの頻度でテストしていますか？
PROTOTYPE MINDSET
Test early. Test often.
できるだけ頻度を高くしてテストすることが重要。
なぜ、だれのために、世界が変わったときにどう順応するのか、
コードをどう変更していくのか、阻害要因はなにか、どうテストしていくか。
私の経験は皆さんとは違うかもしれません。 でも、数年間私は自問自答してきました。
なので、共有しました。
といにはこうしたことも考えることが必要になると思います。
PROTOTYPE MINDSETは、何が、何を、どのように解決しようとしているのか。
素晴らしい知識を個々で養い、素晴らしい、美しい物を構築してください。
雑感
初日のセッションというか、全体を通して1番好きなセッションだった。
自分がなんのために開発者をやっていて、何がしたいのか、どうすべきなのか。
それぞれに問いかけて考えさせてくれた。
ユーザーよりの開発を心がけていたはずなんだけど、
最近そこの意識が下がっていた。
自分の職能の範囲でさりげない改善をするのが好きだったんだけど。もう一度やり直そう。