Shinjuku.LT#18に行ってきた

11419 ワード
勉強会 勉強会 テキストリンク

Shinjuku.LTにいってきた

Shinjuku.LT に行ってきたのでレポ
スライドは上がり次第追加していきます。

DI with Reader Monad - @to4iki

tl;dr

  • swiftでDIする時にやり方が確立されていない
  • Reader Monadを使ってみたDIの説明

見たこと・聞いたこと

関数モナド(例)
(input) -> Elementのラッパー
struct Reader <Input, Element> {
    typealias WorkFactory = (Input) -> Element
    private let workFactory: WorkFactory
    func execute(_ input: Input) -> Element {
        return workFactory
    }
}
使用例
let reader = Reader<Int, Int> { $0 + 2 }
reader
    .map { $0 * 2 }
    .map { "value is \($0)" }
    .execute(5) // "value is 14"

reader
    .flatMap {
        Reader<Int, Int> { y in x * y }
    }
    .execute(4) // 24
  • 評価するまで依存を遅延させられるので良い！
  • executeに値を渡した時点で評価が確定する
  • Reader Monadを使うと関数単位で細かなDIが出来る
  • DIしたいものは型をReaderにしないといけないのでロックインされる
  • 型がネストしていったときの扱いが厳しい

まとめ

  • DI手法の一つにReader　Monadがある
    • swiftで扱うには少しむずかしいかも
  • チームや文化に応じて適切な手法を使っていこう

宣伝

builderscon2018 あります！
Battle Conference 2018 あります！

所感

  • 全力で関数型に統一してるコードじゃないと使いづらくなるのかー感
  • モナドもDIも分かってる力無いので勉強しようと思いました

SearchSuiteのシステム構成について

  • 諸般ノ事情ニヨリ割愛

引っ越しを支えるかもしれない技術 - @yuhsno

tl;dr

  • 最近引っ越しをした
  • 知見を共有

引っ越しに使ったサービス

  • 本のダンボール買い取りサービスを使った
    • 引越し後に情報足りないってダンボールごと送り返された
  • ミニクラのような貸し倉庫っぽいサービスで私財減らしておくと良かったかも
  • 物件探しはレインズを使いたい

所感

  • 笑顔が多いLTだった
  • そのうち本買い取ってもらう

ツリー構造のデータをRDBで扱う - @ftsan

tl;dr

  • ツリー構造のデータをRDBで扱う方法三種の説明
    • 隣接リスト
    • 経路列挙
    • 閉包テーブル

隣接リスト

  • ツリーの構造が深くなるにつれて情報の取得、更新が困難になる
    • SQLがややこしい、joinが増える
    • もしくはSQL発行回数が増える(キャッシュ使おう)
  • 隣接リストを使ったツリー構造はナイーブツリーと呼ばれるアンチパターン
    • DBの実装によっては問題なく使える場合もある

経路列挙

  • 親の全部のIDを文字列としてもつ
    • foo/bar/baz のような感じで自分のカテゴリまでのパスを文字列で持つ
  • 参照は簡単
  • 挿入・削除も簡単
  • 更新・削除は参照整合性を維持することが出来ない

閉包テーブル

  • ツリー全体のパスを別のテーブルに格納する方式
    • ツリー名テーブルとツリー構造テーブル
  • 見た目結構複雑な感じになる(に見える)
  • 参照簡単、インデックスきかせやすい
  • 挿入・削除も難しくない
  • 参照整合性を保てる
  • 初見殺し
  • データ量が増える

所感

  • 各手法の最後にまとめがあって分かりやすかった
  • テーブル構造はよく考えよう

第一回 デザインクイズ - @dende6231

tl;dr

問題.1

  • 同系色でまとめていると違いや特徴が表現しづらい
  • コントラストが有ると特徴をはっきりさせやすい
  • シンメトリな配置で比較しやすい

問題.2

  • 写真や雰囲気に合わせて色やフォントに統一感があると良い
  • 色数やフォントの種類が多すぎると統一感なくなる

問題.3

  • 同じような要素の大きさが並ぶと何を強調したいのか分からなくなる
  • 余白がないと読みづらい
  • メリハリがあると一番に伝えたいことがわかりやすい
  • ジャンプ率を利用して余白をもたせると見やすい

問題.4

  • グリッドを利用したレイアウトにすることで情報が要素に分かれるので見やすい

問題.5

  • 関連するジャンルに分類すると見やすい

まとめ

  • 色の使い方に気をつけよう
  • イメージを統一させよう
  • メリハリをつけよう
  • 余白を上手に使おう
  • 揃えるところは揃えよう
  • グルーピングしよう

　「誰のためのデザインなのか、何のためのデザインなのか」

所感

  • イイね富豪になった
  • 普段あまり気にしてなかったけどデザインを見る良い機会だった
  • お菓子美味しかった

Bug Bashを1時間やって他チームに細かいIssueを洗い出して貰いました - @HomMarkHunt

内容

Bug Bash

http://blog.kyash.co/entry/2018/02/02/170530
こちらの取り組みを参考に自分のプロダクトでも実施してみた話

まとめ

  • Bug Bashすごく楽しかった
  • 公然と悪意ある攻撃できるの良い
  • 自分のところでもしたい（したい）
  • Shinjuku.LT#18の話はこちらも

カイゼンジャーニー読んだよ - @_yum_t

内容

カイゼン・ジャーニー

  • 小説+解説な構成
  • 実話のエッセンスも入っているから身につまされる
  • リアルな状況に則した形で色々なプラクティスを紹介
  • 61の手法を紹介

所感

  • LTぽくてよかった！
  • 「それで、あなたは何をしている人なんですか？」には答えられない

過去の内容

Shinjuku.LT#8
Shinjuku.LT#16
Shinjuku.LT#17