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
内容
- AWS Lambdaの話をしようと思ってやめた
- 代わりにこちらを参照
Bug Bash
http://blog.kyash.co/entry/2018/02/02/170530
こちらの取り組みを参考に自分のプロダクトでも実施してみた話
まとめ
- Bug Bashすごく楽しかった
- 公然と悪意ある攻撃できるの良い
- 自分のところでもしたい（したい）
- Shinjuku.LT#18の話はこちらも
カイゼンジャーニー読んだよ - @_yum_t
内容
- カイゼン・ジャーニーの紹介
カイゼン・ジャーニー
- 小説+解説な構成
- 実話のエッセンスも入っているから身につまされる
- リアルな状況に則した形で色々なプラクティスを紹介
- 61の手法を紹介
所感
- LTぽくてよかった！
-
「それで、あなたは何をしている人なんですか？」には答えられない
