Webナントカ

╭( ・ㅂ・)و ̑̑ グッ !

Rails Developers Meetup #2 (東京会場)に参加してきた

概要

【増枠】Rails Developers Meetup #2 (東京会場) - connpass

所感

  • @onkさんの話が日常の開発で大切だと感じた
    • ドリコムでの共通認識の作り方が参考になった
      • bundle update当番や野良コードレビューとかはやってみたい
    • 開発環境を良くしていくために投資していきたい
  • DB制約大事
  • 今関わっている案件的にshibaraku使えそう

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

奥原 拓也さん(dely株式会社 リードRailsエンジニア)

  • webの表示改善
    • 59.7sec => 0.70 sec
  • キャッシュの導入
  • 画像の最適化
  • 不要なimportの削除

キャッシュの導入

  • ページキャッシュ
    • 廃止
  • アクションキャッシュ
    • 廃止
  • フラグメントキャッシュ
    • 期間を指定してキャッシュできる
    • 1549ms => 131ms
    • key/valueがあったら読み、なかったら書く
    • 更新したい場合は?
      • 特定のフラグがあるとキャッシュを更新する

画像の最適化

  • 画像の圧縮
    • TinyPNG
    • brew install jpengtim
    • brew install pngguant
  • 画像の最適化
    • デバイスに最適なサイズを読む

不要な外部ファイルの削除

結果

  • 早くなった

その他

  • テックブログ書いてる
  • denyはRailsエンジニア一人らしい

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

大仲 能史さん(株式会社ドリコム スペシャリスト) @onk

  • RailsエンジニアがRailsエンジニアらしい仕事ができること
  • bin/setup, bin/update
    • 1コマンドで開発準備が整うようにしておけという話
  • SimpleとEasyの違い
    • 設計に筋が通っていて、すっきり(絶対的)
    • 使う時に、簡単(相対的)
  • Kaminari
    • 各環境向けのコードをプラグインとして切り出すことで、コアの設計指針をSimpleに保つ
    • 認証系のgemはそうなっていないのでは

RailsとEasy

  • CoCを知っている人にとってはEasy
  • 90%のことをやる
  • 一般的でなくても、使う時にEasyなら取り入れていく
    • rails5.1のsecrets.ymlのshared機能
  • 共通認識の元でEasyであることを加速させていくフレームワーク

ドリコムとEasy

  • Will2Kaminari
  • to_id
  • count_by
  • activerevord-unsigned-column-ext
  • activerecord-turntabke
  • ユーザ認証
    • 自作するが、deviseとIFを合わせる

共通認識を作る

  • まずは個人で始める
    • 自分の認識と世の中の認識を揃える
      • 大量にインプットする
      • はてブ
      • Qiita
  • bundle update当番
    • 使っているgemがどんなもので、どのように開発しているかを眺める
      • 面白い
      • 興味が湧く
  • 野良コードレビュー
    • 社内の複数アプリを全体的に眺める
    • 同じ轍を踏まない
    • not null
    • unique
    • Datetime -> Time
    • ユーザの持ち物はcurrent_userから辿る
    • ユーザの持ち物のモデルにはUserを付ける
  • 重複コードをgem化する
  • 最後まで直しきる
  • 複雑なことはしない
    • MVC
    • FromObject以外はほとんど使わない
    • Serviceはやりきるなら導入する
      • あまり導入しない
  • OSS文脈に乗る
    • onkcop
    • CI/CD

Easyを作る

  • 発生しないようにする
  • 自動化の鬼になる
    • 手順書を見かけたら自動化可能だと思え
    • 全自動が無理ならせめてスクリプト化する
  • 時間がかからないようにする
    • db:migrate:resetではなくdb:setupを使う
  • デフォルト値を入れる
    • 書きたくないものを書かなくても良いようにしたい
  • 認証をbefore_actionでやっているなら、ApplicationControllerに書けないか検討する
    • すべてに適用してから一部を外す
  • 一般的かどうかを意識する
    • DHHに習う
      • 基本はそうだけど、こっちのほうが便利じゃない?

Easyを作る体制を作る

  • 楽をするための努力を惜しまない
  • 足回りは最初に整える
  • テスト
    • もちろん書く
  • CI/CD
    • もちろん回す
  • メトリクス
    • もちろん取る
  • シンプルに始める
    • routes
      • REST準拠
    • schema
      • 正規化を崩さない
    • ブランチ運用
      • github flow
    • Issue / PRのテンプレートを書いておく
  • 改善がまわる環境づくり
    • ふりかえり
    • 定点観測

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

@sinsoku_listyさん(株式会社grooves)

  • DB制約
  • 変更しやすいコード
  • リファクタリングいつする?

DB制約

  • null: falseは基本的に必須
  • null: falseがつけられなければ、Tableを分ける
  • unique制約

変更しやすいコード

  • コードの可視性
    • private
    • Refinement
  • 読みやすいコード
    • 命名
    • ABCSize
    • 過剰なDRYより分かりやすさ

リファクタリングいつやるか

  • 良いコードは伝説
  • ソフトウェア開発は難しい
  • 少しずつ直していく
  • コードを読んでいくタイミングで
    • 理解した内容をコードに反映する
    • スコープを狭くする(未使用なら消す)

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

@sue445さん(株式会社ドリコム)

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

  • 11アプリのGemfileを集計
    • 集計スクリプト書いた
    • 社内gemは除く
  • メジャーどころ集まりすぎたので、マイナーどころを紹介
  • komachi_heartbeat
    • 死活監視
  • global
    • yamlの設定をいい感じに扱う
  • onkcop
    • ドリコムのrubocop
  • spec-parameterized
    • パラメタライズをテストする
  • shibaraku
    • start_at/end_atがあるmodelを扱うgem
  • activerecord-simple_index_name
    • index名からtable名を除く
  • activerecord-turntable
    • DBを水平分散する

『ペパボで使ってるgem一覧』

@kenchanさん(GMOペパボ株式会社)

  • shu-cream.net
  • こちらもメジャーどころではなくテーマを絞る
  • 文字系
    • moji
    • makimoto/romaji
    • mwunsch/rumoji
    • willnet/gimei
      • 日本語のテストデータ作成
  • ペパボ発
    • hsbt/minitest-power-asert
    • yml_ref_resolver
    • capistrano-release-notification
    • rspec-default_http_header
    • global_sign

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

@284kmさん(株式会社フィードフォース)

  • Webmockの話
  • データフィードの現場とは
    • データフィードとは
      • 保有している商品などのデータを外部サービス(広告配信先など)のフォーマットに変換して送信する仕組みのこと
  • ふつうでありたい
  • とはいえ、特殊もある
    • koala
    • google
  • テスト
    • http
    • web mockを使う
      • httpリクエストがあたかも行われたかのように振る舞う

初めてOSSにコントリビュートをした

対象PR

Fix auto diagram generation by kikunantoka · Pull Request #252 · voormedia/rails-erd

経緯

  • 下記のように、公私で作るRailsアプリケーションは大体、タスクを追加して、rails db:migrateするとER図が自動出力されるようにしていた
  • ただ、プロジェクト毎に、同じタスクを生成するのも面倒なので、ジェネレータを作ろうと試みている時に、本家にジェネレータがあることに気づいた
  • しかし、下記issueにもある通り、動作していないようだった
  • issue内に修正方法が提示されていたので、修正を行い、ドキュメントを追記し、PRを送った
  • 1ヶ月ぐらい放置された後、しれっとマージされて、リリースされていた

結果

rails-erd 1.5.1からrails generate erd:installするとタスクが生成され、開発環境で、rails db:migrateする際にER図を出力できるようになった。

しれっとマージされた様子

今後

RailsやReactでアプリケーションを書くようになって、OSSにはお世話になりっぱなしなので、ドキュメントでもなんでも構わないので、機会があれば、貢献していきたい所存。

mochaを買った

MacのHatena Blog用のMarkdownエディタとして、mochaを買った。240円。

mocha

mocha

  • Reo Hokazono
  • ライフスタイル
  • ¥240

使い初めて3ヶ月ぐらい経ったけど、継続して使っている。

それまでMarkdownエディタとして、kobitoでHatena Blogの記事も書き、タグで管理していたが、Hatena Blogといい感じに同期をして欲しかったので、探してみた。

要件として、

  • Hatena Blogと同期を取ってくれる
  • Markdownで書けて、プレビューできる
  • シンプル

の3点があり、mochaはこれらを満たしていた。

ウィジェット系はサポートされていないので、下書き専用として使っていて、公開時にWeb上からウィジェットを追加して、予約投稿を行っている。

ウィジェット系と予約投稿のサポートと少しのUI改善があれば、文句なしだが、現状でも240円出す価値は十分あると思う。

以下、購入時の感想