Skip to content

Instantly share code, notes, and snippets.

@iyuuya
Last active December 9, 2017 09:07
Show Gist options
  • Select an option

  • Save iyuuya/e093639c7df1aed29b4e64bc8a649665 to your computer and use it in GitHub Desktop.

Select an option

Save iyuuya/e093639c7df1aed29b4e64bc8a649665 to your computer and use it in GitHub Desktop.
Rails Developers Meetup

01

RSpecで気を付けること

  • describeの引数にはテストの対象を書く
  • contextの引数にはテストを実行するための条件を書く

describeの外にテストデータを起かない

ダメな例

descirbe 'sample specs' do
  let(:need_in_b_and_c) { }

  context 'a' do
  end

  context 'b' do
  end

  context 'c' do
  end
end

FactoryGirlのデフォルト値に依存させない

  • ランダム値にする

FactoryGirlでbelongs_to以外の関連をデフォルトで作成しない

悪い例

after(:create) do |user, evaluator|
  create_list(:post, 2)
end

良い例

trait(:with_posts) do
  after(:create) do |user, evaluator|
    create_list(:post, 2)
  end
end

日時に(なるべく)依存させない

  • 相対日時にする
1.month.ago(now).beginning_of_month

updateでデータを変更しない(テストで)

  • FactoryGirlで作成したレコード中のカラムをupdateメソッドで変更すると、最終値が分かりづらい

letを上書きしない

  • 前提条件がわかりづらくなる

抽象化するときはよく考える

  • shared_examplesはよく考えて使う
  • わりとベタっと書いた方が分かりやすい

it_behaves_like 'oo' ooのように振る舞う

https://github.com./willnet/rspec-style-guide


フロントのエラーを疎かにしてはいけない Sentry使いましょう

  1. エラーに気付く
  2. エラーを理解する
  3. エラーを再現する

02

クラシルのwebサイトをちょっとした改善で100倍速にした話

PageSpeed Insights

キャッシュ!

PNGの圧縮 TinyPng

jpegoptim pngquant

デバイスに最適なサイズの画像を使う

http://tech.dely.jp/entry/2017/06/21/191832

ふつうのRailsアプリケーション開発

  • simple: [絶対的]
  • easy: [相対的]

Rails: CoCを規約を知ってる人にとってEasy Rails Wayに全力で乗っかる事でEasy

bunlde update当番

PRで殴り合う

技術的負債とリファクタリング

  • 手抜き、ハック、重複

  • null: false は基本的に必須

  • UNIQUE制約にも気をつける

refinements

ドリコムで使ってるgem一覧

https://sue445.github.io/rails-developers-meetup-2/#/

ペパボで使ってるgem一覧

https://github.com/kenchan/memory/tree/master/rails-developer-meetup-02

データフィードの現場で書く Rails アプリケーション

お休みした

07

https://techplay.jp/event/631429

RailsでECサービスをゼロから作ってみて / @ukstudio

https://speakerdeck.com/ukstudio/rails-developers-meetup

???

  • ちゃんと正規化と外部キーをはる
  • いらないテーブルややりたいことと合わない設計になったらちゃんと直す
    • アクセス数が多くなければ変更に対してそこまでシビアになることもない
    • それよりもくわからん設計のテーブル残す方が困る

データベースのView

  • 正規化していくとN+1の解消やJOINの数が多くてRails上のコードの見通しがわるくなることがある
  • Viewを多段にするとあるViewの構成を変えたいときに面倒になるので注意
  • 似た理由でカラム追加時にこまるのでViewには最低限のカラムを指定するほうがよい
  • アプリ側とDB側にロジックが分かれるのはちょっと悩みどころ

マイグレーション

サービスレイヤ

  • ARのインスタンスを複数使うような処理はサービスレイヤにしていた

購入処理まわりをサービスクラスに

  • クレカの決済処理、注文情報の永続化、ユーザーへのメール通知など
  • コードを再利用するとなったときに使いまわしができずに困るはめに

どうすればよかった

  • サービスレイヤは出来る限り薄くする
    • そうするとRailsの場合、コントローラーに掛けばいいやっていうのも多々ある
  • ドメインモデルの設計力を鍛える

フォームクラス

  • 正規化すると大体においてフォームとモデルが1:1にならない
  • フォ0ムごとにフォ0ムクラスを作るのが結局はラク
  • form objectを使ってみよう

バリデーションをどこで行うか

  • あとからフォームクラスを導入したので当初はモデルにバリデーションがあった

フォームクラスに直接書く

  • フォーム実装するときにフォーム単位でバリデーション考える方がらんかラク
  • モデルでバリデーションすると困るケースもある
    • 特定カラムは他のカラム同士の計算によって埋められる場合
    • バリデーション時に計算するコストを支払う必要がある
    • フォームの値をバリデーションしたいのでフォームでそこをあまり気にしたくない
  • モデルのバリデーションに頼らない
class HogeModel
  validates_presence_of :title
end

class HogeForm
  def initialize(title)
    @title = title
  end

  def valid?
    HogeModel.new(title: @title).valid? # よくない
  • 似たバリデーションを書くことも…
    • フォーム継承とかで対応

  • プロダクトマネージャーと開発者の意思疎通は大事
  • Rails開発において多まかな原則について勉強する
    • アジャイルソフトウェア開発の奥義 とか
  • 意図的に手を抜くとかでない限り、上限が自分の実力で決まる
  • 実装レベルだと決まり手がないことも多い
  • その辺の試行錯誤は恐れない

スタートアップでのRails開発/運用でよかったこと / @swdyh

https://github.com/swdyh/swdyh.github.com/tree/master/rails_developer_meetup7

グローバルサービスを作る時に考えておくこと / @m_nakamura145

タイムゾーン

  • Rails/DBのタイムゾーンをUTCに
  • default_timezoneはUTCの方がいいかも
  • ActiveSupport::TimeZone::MAPPING
    • 正式な文字列のを記録する方がよい(Asia/Tokyoなど)
  • Time.current
  • start_at = Time.zone.at(params[:start_at].to_i)

祝日

  • holidaysなどは使ってない
  • holidayマスターモデルを使っている
  • 国によって祝日の制度が違う
    • アメリカだと州ごとにも決められている
    • 宗教毎の祝日などがある

SMS

  • Twilio

クックパッドでのWebアプリケーション開発 2017 / @eagletmt

https://speakerdeck.com/eagletmt/web-application-development-in-cookpad-2017

  • デプロイ: rundeck, hako
  • タスク: kuroko2, barbeque
  • sentry, vault

機密情報管理

分散トレーシング

  • AWS X-Ray

コンテナは友だち! in Rails Developers Meetup / @udzura

プロセス

  • Linuxプログラミングインターフェイス
  • procfs
ls -l /proc/${pid}
ls -l /proc/${pid}/cwd
cat /proc/${pid}/environ
cat /proc/${pid}/maps
etc

コンテナ

  • 仮想化の一種
    • ハイパーバイザー型(ネイティブハイパーバイザ)
    • ホストOS型(ホストハイパーバイザ)
  • 小さな独立した環境を、1つのOSの上に作る技術
  • コンテナは特殊なプロセス

実装

  • Docker - Golang
  • LXC/LXC - カーネルのコンテナレファレンス実装的立ち位置
  • Haconiwa - mruby + Cでできたコンテナ

  • Linuxコンテナはカーネルのリソース「分離」と「制限」の機能を使ったプロセス
  • どんなに難しそうなツールでも、誰かが買いたものであれい、そしてOSSである限りは中身を深く知ることができる
  • なるほどUnixプロセス

2017

https://techplay.jp/event/631431

レールの伸ばし方 / @willnet

適切でない抽象化

  • before_filterでやりまくる

    • 何してるのか分かりづらい
  • MVC、正しくつかえてるか

  • MVCだけではレイヤ足りないのでは

Controllerを正しく使う

  • FatController
    • Modelに処理を寄せる
  • Controllerの責務
    • モデルのメソッドを呼ぶ
    • インスタンス変数への代入
    • ビューの選択
    • メイラーぐらいは許容
  • ぱっと見分かる範囲ならOK

モデルの正しく使う

  • FatModel

    • モデル同士が密結合になっている
      • 密結合は修正が連鎖しやすい
      • Aクラスのメソッドを修正したらBクラスも修正が必要
  • POROに切り出す*(AR以外のクラスを作る)

    • PostWithNotifications
      • .create
      • #initialize
      • #create! メドピアのブログを参照

(Viewはまあ大体大丈夫でしょう)


これだけで平均以上の可読性


  • 大量のbefore_filter

    • 自分が気にしているコンテキストでなにが実行されているのかが分かりづらい
    • 最終的にインスタンス
  • before_filter → action

  • クエリメソッド化(@hogehoge = fetch_hogehoge)

    • インスタンス変数が多いとつらい
      • ViewModel(ViewObject) (データを持てる, ロジックは持たない)
        • @view_model = PostIndexViewModel.new
  • validationの場合分け

    • フォームごとにクラスを分ける*FormObject
      • モデルからバリデーションを外してFormObjectでやる
      • PostForm
      • AdminPostForm
  • callbackの場合分け

  • アクションでモデルのやることが多い

    • ServiceObject
      • PORO = Service?
      • アクションの細々した部分をまるっと担うオブジェクト

  • ViewModel コントローラのコンテキストの情報どうすんの?
  • FormObject
  • ServiceObject

導入するには、チーム内でわかりやすいドキュメントが不可欠 統一した書き方に誘導できるツールがあるよ良い willnet/yuba

Professional Rails on ECS / @joker1007

  • クラスタ管理
  • kubernetesが覇権取った感ある(白目)
  • EKS

Dockerize

  • staging/productionのイメージは分けない

  • 手元で開発する用のDockerfileは分ける

  • capistrano-dockerbuild

  • assetsはイメージには含めない(ビルオ時に解決するがビルド自体とは独立させる

開発環境

  • docker-composeとマウント
  • Macはボリュームマウントが死ぬ程遅い
    • docker-syncなど

GentooというLinuxがあってだな

Randomly Failing Specs / @

  • Fakerにはunique methodがある
  • globalな値を代入しているのはスタブを使う

GMPペバボの Rails & Vue.js プロダクト開発の現場 / @kenchan, @kymmt90

カラーミーリピート

droneやっぱり使ってるんだ

プロジェクトの経ち上げ

  • インセプションデッキ
  • ドラッカー風エクササイズ
  • 類似サービスのモデリング

開発

  • 1週間スプリントのスクラム開発
  • ユーザテスト
  • 自由研究
    • 不安要素やチェレンジしたいトピックを自由に研究し、そのKekka wolissueで共有する

スキーマファースト開発

新規プロジェクトへの Vue.js x SPA x SSR の導入

  • Rails API モード
    • SPA
  • Sideki, sidekiq-schedular

API定義

  • Specifiation First Development
  • endpoint, request, status code, response

OpenAPI / Swagger

  • API定義を書くための形式

  • API BlueprintやRAMLなどが他にある

  • JSON/YAMLで書く

  • 2017年現在 主流

  • JSON Schemaと似てる

  • YamlRefResolverを使ってマージして1つのJSON化

  • Swagger Editorを補助的に使ってsyntax errorを避ける

チームレビュー

開発

  • フロント
    • Swagger CodegenでOpenAPIからスタブやドキュメントをつくる
  • バック
    • 整合性を保って開発
      • SchemaConformist
      • committe-rails

結合

作らない技術 / @ppworks

  • YAGNIのバランス感覚
  • いらないものは作らない
    • 世界感を保つ

  • 欲しくてつくる
  • コンセプトドリブン開発


  • 作る仮定に価値がある

    • 作ったものに価値があるかどうかではない
  • bundle update

    • deppbot/tachikoma.io

「Railsでまだ消耗しているの?」ー僕らがRailsで戦い続ける理由ー / @toshimaru_e

Why Ruby

  • ナイスなRubyコミュニティ
  • 日本製
  • 情報のググリやすさ・質問のしやすさ
  • 巨大なRubyGems資産
  • 柔軟な言語仕様
  • 直感的
  • etc

Why Rails

  • DRY

  • CoC

  • CoC >>>>> DRY

  • xxの方が速いよ

    • 処理系の早さがユーザーに直結しない
    • dev.toなんかもRailsだ!!
    • でも開発速度は速いよね
    • 高速化の努力もあるし

Rancherで作るお手軽バッチ処理環境 / @zyunnosuke

  • staging/社内ツールに良い

Rails SQL / @jnchito

https://qiita.com/jnchito/items/625bef4187e360d7f4bc

複雑な集計処理

  • SQLはERBで書く
  • Connectionオブジェクトから直接SQLを実行する

Rails React / @masuidrive

  • webpackerはあまり良くないらしいw

    • parcelきたぞーw
  • 環境を混ぜると危険

    • 開発速度・リリースタイミングの違い
    • 言語・環境の違い
    • ラッパーは大抵めんどくさい
  • Nodeの環境を別で作る

    • dockerでrailsとreactの環境を分ける
    • ビルド環境あ津に管理
  • /

    • /react : REact舞のソースと環境
    • /app/javascripts : ビルドされたREactコード
  • Viewからの呼び方

    • 画面毎に読み込むJSをどう決定するか
    • パラメータをどうやってReactに渡すか
  • metaにcontroller/actionを書いてJSでルーティング処理をする


  • Redux
  • Hot load

便利そうなライブラリ

  • react-json-schema-form

  • csrf
  • /posts/:id

メタに載せてそこから取得するようにしている

となる企業のモバイル対応 / @_yasaichi

  • MFI

  • レスポンシブ

  • ユーザーエージェントで切り替え

2018年から始めるRubyによる深層学習入門 / @hatappi

  • Rubyに対応してそうなやつ
    • tensorflow.rb
    • ruby-cntk
    • 将軍
    • pycall.rb
    • Red Chainer

OSS雑メンテ / @sue445

  • CI

    • gemならtravis

    • アプリならcircle ci, wercker

    • 定期ビルド

      • 依存gemのアップデートなどで壊れることがある
    • tachikoma

    • .deppendent

  • sue445/my-ci-badges

マルチテナント・ウェブアプリケーションの実践 / @__gfx__

  • Kibela
    • GraphQLつかってる

keyword: onk graphql


  • マルチテナント・ウェブアプリケーション(MTWA)

    • SaaSにおいて1つのシステムで複数の組織のチームを同居させるウェブアプリケション
    • BtoBウェブサービスとほぼ等価
  • MTWAのアカウントモデル

    • サービス全体でアカウント共有
    • テナント毎にアカウントを作成する
  • URLの名前空間

    • domain vs path
    • セッションCookieはチーム毎に独立し、共有しない
    • ループバックドメインを利用
      • $team.lvh.me:3000など
  • ストレージの名前空間

    • Postgresql database - schema - table
    • いずれDBインスタンスの分割が必要かも

JITコンパイラはいかにRailsを速くするか / @k0kubun

TD のRailsサービス

  • Treasure Data Service
  • Customer Data Platform
  • Enterprise Fluentd Management Console
  • Embulk config management API

MJIT

  • CRubyのためのメソッドJITコンパイラ
  • JITコンパイラだけでなく、ベースのVM命令も置き換え
  • JIT用pthreadがgccやclangをfork, execしてdlopen, dlsym

YARV-MJIT

  • MJITフォーク
  • VM命令は置き換えない
  • ruby 2.5より高速
  • MJITより遅い
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment