https://speakerdeck.com/motokiee/iosfalsezi-dong-hua-toshi-zu-mihua-kodotoshe-ji-niji-zhong-suru
メルカリのiOS周りの自動化・仕組み化の話。
Dangerでリリースノートの更新を促したり、ドキュメント化を促進してるのは良さげ。（具体的にはどうやってるんだろ？
CIについて、メルカリではBitriseを使ってるんですね。
自社の中核サービスであれば、ここまでしっかり作る意味は強いけど、受託で短期間のプロジェクトでどこまでやるか、というのは検討が必要な気がしますね。手軽に導入しておけば、しきい値はかなり下げられそうですが。
http://tech.kitchhike.com/entry/2018/04/29/222634
ディープリンク周りの歴史・経緯の紹介と、React Nativeでの具体的な導入事例。
Firebase Dynamic Linksの仕組みについても紹介されているので、中身がわかって良い。
この記事で紹介されているFirebaseコンソールからのDynamic Linkの作り方は、キャンペーンページなど、特定のページに飛ばしたい場合に有効ですね。
https://firebase.google.com/docs/dynamic-links/use-cases/web-to-app などのドキュメントを見ると、 link などを動的にしていしても良いらしく、動的なページでも同じような仕組みで処理できそうですね。
https://techracho.bpsinc.jp/hachi8833/20180426/55463
ActiveSupport::Notifications を使って、性能の計測などが出来る話。
この記事では、slow queryに該当するものを、アプリケーションのレイヤーで取得した話。
ActiveSupport::Notifications を使えば、クエリだけじゃなく、他のものも取れそうなので、性能面で困ったときにはスッと書けると良さげ。
また、Rubyで書けるので、ちょっと複雑なフィルタリングとかも簡単に書けそうでよいですね。
http://www.life-is-bitter.com/entry/ui_checklist
Web系のデザインを、実装するときに「こんな場合は？」と聞かれないためのチェックリスト。
逆に、エンジニアとしては、デザインを受け取って実装を始める前にチェックしたほうが良いリスト。
案件によっては、focusやhoverが必要無い場合もあると思うのですべてを定義してもらう必要は無いですが、観点としては一通りチェックしたほうが良さそうですね。
http://www.yasuhisa.com/could/article/design-sytem-color-name/
色に名前をつけましょう、また、そのつけ方の工夫の紹介。
特にAndroidでは、colors.xmlなどで色を一括で管理し、各UIではその色を利用します。 デザインをPSDなどのデザインデータだけでもらっていると、実装するときに名前を付けなければならず、「redとつけたら、後から他の赤っぽい色が何個もあった」といったことが起こります。 実際にデザインしたデザイナであれば、「この赤はXXXという意図があり、こっちの赤とは別」といった意図があると思います。 そういった意図をエンジニアと共有するのは時間がかかるので、デザイナの方で色名を決めてくれるのは良さそうだなーと思いました。(意図まで共有した方が良いんですけどね)
Twitterで募集したクソコードをカテゴライズして、経験とともにコメント入ったもの。
結果、リーダブルコードの逆を言っているだけのものも多そうですね。 また、個人的には「場合によってはOKじゃね。」ってのもありました。
とはいえ、わかりやすくまとまっていて、時間が経っても基本的に変わらないものだと思うので、いいまとめでした。