Skip to content

Instantly share code, notes, and snippets.

@hamakn

hamakn/0.yokohamarb_memos.index.md

Last active December 4, 2016 08:55
Show Gist options
  • Save hamakn/6a87a3463794754ac142741d5535f067 to your computer and use it in GitHub Desktop.
Save hamakn/6a87a3463794754ac142741d5535f067 to your computer and use it in GitHub Desktop.
Download ZIP
Yokohama.rbのメモ
Raw
0.yokohamarb_memos.index.md

Yokohama.rbのメモ

何なんすかこの文章（群）

  • Yokohama.rbであの時何やったっけ、を思い出しやすくするためのメモ
  • 次回行ってみようと思うけど何やってるかわからないや... というニーズに応えられると良いなぁ

Index

Raw
68th.md

68th Yokohama.rbのメモ

概要

Rails悩み相談

  • 3年ぶりに仕事でRailsをやることになった（便利だなこのフレーズ！）わたしの悩み相談
  1. 認証するモデルが複数（例: UsersとAgents）ある場合のRailsアプリの作り方
  • UsersとAgentsがどの程度似ているかなどによって変わる
  1. 1model, 1app: よくあるやつ。UserとAgentが似ているならこれで
  2. 2model, 1app: よくあるやつ
  3. 2model, 2app: modelとschemaはengineで共有するとか。やるなら開発初期からやらないと後からこの形にするのは辛い
  • 相談元が仕事の話なため具体的な所に踏み込みにくく、必然的にパターン出しと判断ポイントの話になった
  1. push系のBaaS、SNS、あるいは自前について
  • push件数が大きく育つ（1000万件超/月とか）なら最終的には自前で抱えることになるが、その判断をいつするか/それまでどうするか
  • nodeで低スペックなサーバを横に並べればスループットは出るらしい
  • SNSのスロットル制限
  • BaaS作った人がいて話が弾んでよかった
  • 名前が挙がったサービス
  1. Gemfile見せたりとか
  • autodoc使うならweak_parametersも使った方が良い
  • Gemfileをアルファベット順にしよう
  • airbrake

iOSフィーチャードによるアクセス増の事例

  • by @u1tnk

  • iOSフィーチャード

    • App Storeのトップに掲載されるアレ
    • 経験者の事例を総合した結果、掲載された場合のインストール増は1日 x000件ぐらいらしい

  • t2インスタンス

    • スパイク的な負荷（バッチ処理、テレビでの特集）や周期的な負荷（昼夜間）などには向く
    • 1ヶ月スパンなどの継続的な負荷（フィーチャード＝今回、TVCM x週間）などには向かない

  • マーケ施策には金の弾丸で

    • 一過性のものなので、細かくサイジングする意味が（あまり）ない
    • 状況的に、ビジネス側と合意が取りやすい

  • 二次災害を防ぐ

    • 慌てない / 備えておく
      • 事前に監視を作っておく
      • 金さえかければスケールする設計・アプリにしておく
      • 金さえかければ簡単に増やせるインフラを使う
        • EC2の20台制限は早めに外しておく
    • ちゃんと寝る

ECSによるproduction向けのRails環境構築

  • by @joker1007

  • production環境でRailsアプリをdockerコンテナとしてECSで運用するために考えたこと http://qiita.com/joker1007/items/b8a932c1ae29705cef8d

    • 詳細は↑参照

  • モチベーション

    • docker, Railsでproductionに使えそうな記事がない
    • CentOS6捨てたい
    • chefでミドルウェアのupdateが辛い
      • ローリングアップデートみたいなやつ
    • アプリ寄りの人間が kubernetes とかを運用するのは辛い

  • 最終形

    • アプリ開発者はこれまで通りcap deployでデプロイするが裏側は丸々置き換わっているという状態

その他・飲み会ネタ

  • 東神奈川駅内のプチ鯛焼き屋が潰れた
  • 業界で俺たちがこの先生きのこるには
  • 婚活
  • 伊坂幸太郎、村上春樹、グレッグ・イーガン
  • MHX、オーバーウォッチ、スト5、妖怪ウォッチ3
  • 投資（投信）入門、有効フロンティア、竹川美奈子

次回

Raw
69th.md

69th Yokohama.rbのメモ

概要

  • 2016-06-11(土) 17:30〜
  • 13人
    • 初参加は4人、のはず、結構多め
  • 前半: Rubyレシピブック第3版 230〜233
  • 後半:
    • 競馬のデータの取得と分析を始めた by @anonaka
    • 勉強用に作ったRailsアプリをみんなで読む by @kae_kasui

Rubyレシピブック第3版 230〜233

競馬のデータの取得と分析を始めた

  • by @anonaka

  • 昔競馬の予想ソフトを作るベンチャーにいたとのこと

  • 過去20年分のJRAのオッズやレース結果が 販売されている

    • これをDBに取り込むツールがある 後記:これを利用したとのこと
    • 3連単のオッズのデータもあるのでレコード数は結構ある
    • レース中の馬の位置のデータもある

  • Rやpythonで分析する

  • まずは、人気順と回収率の関係をグラフにした

勉強用に作ったRailsアプリをみんなで読む

  • by @kae_kasui

  • 公開している勉強用のRailsアプリ について

    1. herokuにdeployしたものをデモ
    2. ソースを参加者でレビュー

  • アプリの概要

    • お小遣い帳
    • Rails4.2 + Angular1

  • ソースレビュー

    • 流れ
      1. Gemfile
      2. config/routes.rb
      3. 辛いModelやControllerってどれ？
      4. spec
      5. db/schema.rb
      6. Angular, gulp, bower
      7. CI(wercker), deploy(heroku)
    • みんなのコメント
      • 「gemを読むことはあるがRailsアプリを読むことはあまりない（そもそもpublicになりにくい）ので良かった」
      • 「話の背景的にもっと辛いModelやControllerがあるかと思ったらそうでもなかった」
      • 「 イラストも自分で描ける のつよい」
      • 「みんなこういうのを公開していて今日みたいな話ができれば、採用面接も楽なのに...」
      • 作者が感じた指摘 https://twitter.com/kae_kasui/status/741682585672114176

その他・飲み会ネタ

  • プログラミング言語基礎勉強会（同日開催だった）
  • service層（を追加する仕事やひっぺがす仕事）, Trailblazer, 前回のginza.rb
  • 定番業界トーク, 600万, 転職エージェントに会う際の注意点
  • 定番婚活ネタ（テーブルが離れていたので今回わたしは聞いてなかった）
  • 領収書じゃんけん

次回

Raw
70th.md

70th Yokohama.rbのメモ

概要

Rubyレシピブック第3版 234〜237

どう書く in Yokohama.rb

その他・飲み会ネタ

  • どう書くは年に3回ぐらいはやりたい
    • ペアプロでやるのも良い（その方が他の場所でやっているどう書くとキャラ分けできる）
  • AWSの中の人に質問してみた
  • 定番業界ネタ, 転職, 銀行案件
  • Rust
  • twitterアカウントから見える性癖

次回

Raw
71th.md

71th Yokohama.rbのメモ

概要

  • 2016-08-06(土) 17:30〜 https://yokohamarb.doorkeeper.jp/events/47082
  • 7人
    • 初参加は2人
      • どうやって見つけた？
        1. Twitterをうろうろしていたら発見
        2. doorkeeperをさまよっていたら発見
  • 今回は恒例のレシピブックはお休みだった
  • 前半: 誰も発表しないいわゆる「もくもく会」だった
  • 後半:
    1. 仮想通貨決済のECサイトを（Railsで）作る by みやもとさん
    2. （いまさら｜いまから）はじめるActionCable by @hamakn

仮想通貨決済のECサイトを（Railsで）作る

  • by みやもとさん
  • bitcoin, モナーコインで決済可能なECサイトを開発している
  • Rails4.2, AWS(EC2, RDS, VPC, SES)な構成
  • devise, whenever
  • 仮想通貨なら振り込みを早くできるので売掛金リスクを低減できる
  • コードレビューやデザインを依頼したいかもしれない
  • Q&A
    • 仮想通貨の取り扱い: APIが充実しているのでそれを使うといい
    • https://purse.io/ とかどうですかね

（いまさら｜いまから）はじめるActionCable

その他・飲み会ネタ

  • 転職先で同期になる人と出会うという超展開ｗ
  • 定番業界ネタ（転職相談、就職相談、SIerあるある）
  • 基礎力、大学の授業の勉強をちゃんとやるの大事、SICP
  • インド、プネー、シュルンベルジェ
  • 次回からdoorkeeperの有料化に伴い値上げ（200円 => 500円程度）

次回

Raw
74th.md

74th Yokohama.rbのメモ

概要

  • 2016-11-12(土) 18:00〜
  • 9人
    • 初参加はゼロのはず
  • 前半: Rubyレシピブック第3版 238〜
  • 後半:
    • （非公開コンテンツ）
    • accept_nested_attributes_for
    • DBの設計について（こういう要件だとどうする？）

Rubyレシピブック第3版 238〜239

（非公開コンテンツ）

accept_nested_attributes_for

  • by @hamakn

  • 機能の説明

    • モデルに親子関係（has_(many|one) ~ belongs_to）がある際に、両方を一度に作れるやつ

  • 良いところ

    • 親子モデルのvalidationを同時にできて便利
    • 似たようなものを自前で作るにしても（四角い）車輪の再発明になるから使える物は使った方が良いのでは （実装とかテストを見て自分で書いた方が良いというならそれでもいいんじゃないかな...他人がメンテすることがあるならそれも含めた上で）

  • 悪いところ

    • STIと一緒に使うと動かない事例があった

  • やりたいことと課題

    • 「親オブジェクトに関連付けられる子オブジェクトの上限」を制御したかった
    • limitオプションは「1回のリクエストに付属できるnested_attributesの数」であって「親オブジェクトに関連付けられる子オブジェクトの数の上限」ではない
    • allow_destoryについて、例えばlimitが3だとすると、2個追加して2個消すようなリクエストは(3 < 4(=2+2))になって通らない

  • どうする？

    • そもそもaccept_nested_attributes_forを含むアプリサイドでの実装では「親オブジェクトに関連付けられる子オブジェクトの数」の厳密な管理はできない
      • validates_uniqueness_ofと同じ話
      • 厳密な管理が必要な要件ならDBに制約をかける、check制約とかトリガーとか
    • 厳密でなくて良いなら...
      • accept_nested_attributes_forと組み合わせて、before_validationなどで数を数えればだいたい上手く行きそう
      • allow_destroyで_destory:1が立っているnested_attributesはlimitのカウント対象から外すモンキーパッチをする（ダメ〜微妙）
      • allow_destroyとvalidationが組み合わされるケースで、追加と削除を同時にやろうとすると、追加がvalidationで失敗すると見かけ上の入力数が上限を越えるのでダメ
        • そうなるとdestroyはajax等で都度行った方が良さそう、そうなるとallow_destroy要らないのでは...

DBの設計について

  • by @hamakn

  • お題

    • User has many Itemsなテーブル
    • Itemには有効・無効がある
    • あるUserが持てる有効なItemは1つだけ
    • あるUserが持てる無効なItemはいくつあってもよい
    • Itemテーブルは属性によって検索・ソートできるように1テーブルであることを保ちたい
    • ...ときに、どうテーブルを設計するか
      • (追記)
        • Itemにはアイテム種類があって、あるUserが持てる有効なItemはアイテム種類について1つだけ、としたかったけど説明するの忘れた...

  • 質問/前提の確認

    • Itemの変更はどの程度の頻度で行われるか
    • 一度無効になったItemが再度有効になることはあるか

  • 回答群

    • User側にactive_item_idのようなものを持たせてそれで管理する => 良いんじゃねとなった
    • DBでcheck制約等をかけてあるユーザについて有効なアイテムは1つだけとする
    • Itemに時刻を入れて、最新の時刻のもののみ有効にする
    • [user_id, 有効無効フラグ, 有効なら定数/無効ならユニークな値] の3カラムでunique制約をかける、最後のカラムの制御はアプリでがんばる...
    • Itemにassociationがあまりないなら、無効なItemはテーブルを分ける、検索はがんばる...

  • その他コメント

    • これ結局論理削除の問題では

その他・飲み会ネタ

  • へっぽこ人生でもサービス当てて成仏がしたい!!
  • RDBMSの知識大事
  • PSVR、サガの新作、サガで詰んだリオファネス城で詰んだ、シャドウハーツ
  • 業界あるあるネタ
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment