Rails Developer Meetup 2019で"自己修復的なインフラ"という登壇した #railsdm2019

3/22(金)、3/23(土)に開催されていたRails Developer Meetup 2019に参加し、登壇させて頂きした。

色々と記憶があるうちにブログに書いておく。

スライド

www.slideshare.net

イベントの感想

参加者は250人以上で、登壇者も3トラックx2日ととても多かった。 これだけの規模のイベント運営はとても大変だと思うし、運営スタッフならびにカルパスさん本当にありがとうございました。

登壇者の方がアップロードしていた資料をいくつか読みましたが、自分が知らない知見が色々と書かれていて勉強になります。 まだ全てに目を通せてないので、楽しみにしながら少しずつ読みたいと思う。

他にも感想を書きたいところなのですが、実は2日目の午後からの参加だったので、あまり感想を挙げらない...。すまない。

登壇のふりかえり

いくつかあるので、将来の自分のためにふりかえりをしておく。

😀良かった: Decksetでスライドを作成した

今回のスライドでは初めてDecksetを使いました。

慣れているMarkdown形式で書けるし、シンタックスハイライトにも対応していて、便利でした。 ただ、画像の位置調整には癖があるので、そこは慣れが必要そう。

次のスライドもDecksetを使ってみようと思っている。

😣失敗した: テーマを詰め込みすぎた

スライドの中で、話したい事として以下4つを挙げていました。

  1. AWS IAMの基礎とロール設計
  2. インフラ開発環境の構築
  3. Railsアプリケーションのデプロイ
  4. 自己修復的なインフラという話

2月にテーマを入稿したときには「いっぱい知見あるので、色々と伝えるぞ！」と思って詰め込みました。

そして、スライドを作り始めてから「これ、1つの項目で30分くらい必要だぞ...」みたいになった。

  • 深掘りしすぎると30分に全く収まらない
  • テーマとして挙げたのに触れないのも微妙

と、スライド構成を決めるのに苦戦していました。 もうちょいテーマを絞って、1点突破みたいな内容にするべきだった。

😀良かった: 「参考になった」という感想を頂けた

前述のようにスライド構成に不安があり、しかも部屋が満員という状況での登壇だった。

あまり話すの得意でも無いので説明が分かりづらい点もあったとは思いますが、登壇を聞いた方に何か知見を伝えられたようで良かった。

😣失敗した: AWSの構成図は時間かかる

AWSの構成図を作るのは地味に時間がかかるので、普段のスライド作りよりも少し時間を多く見積もるべきだと思った。

Cacooで図を作って、pngでエクスポートして、Decksetの画面で文章とあわせて確認して....を繰り返していた気がします。

話せなかった内容について

スライドの最後に書いたように、E2Eテストを試したり、自動revertプルリクは近いうちに挑戦してみようと思っている。

ただ、それ以外にもいくつかスライドに含められなかった内容があったりする。

  • Terraformの詳細な話
  • DevSecOps的な話
  • ECS(Fargate) + Railsの詳細

この辺りは別の機会を見つけて、そのうちアウトプットしていきたい。

神戸市の働き方に関する勉強会に参加した #forkwell

Forkwellの中の人からイベントに誘われ、リモートワークや地方の働き方には少し興味あったので参加してみた。

forkwell.connpass.com

トークで印象だった話

話聞いてたときにメモったりしてなかったので、自分の記憶に残っている話題だけ書いておく。

ACALL株式会社

www.acall.jp

  • ACALLのサービス紹介
    • 入退室の自動化は便利そう
    • 導入企業が多くて、順調に成長してる
  • 使っている技術はRailsやVue.js、AWS
  • CTOが唎酒師（ききさけし）
  • ブログ書いてる時に気づいたけど、 freee さんの受付のやつじゃん！
    • 使ったことあった

株式会社職人さんドットコム

www.shokunin-san.com

  • 職人の需要に対して、供給が足りてない
    • ITで作業効率を上げる方針なのすごく良い
  • 職人向けの商品を扱うお店の検索ができる
    • 狙いが尖っていて、ビジネス的には良さそう
  • マネタイズ対象は企業やショップで、職人は無料で使える
    • 広告などが収益源
  • 使っている技術はPHP（GCPを使っていたような気がするけど記憶に自信がない）
  • 本社は神戸に置きつつ、東京に開発拠点を作ろうとしている
    • エンジニアを募集中

神戸市

kobeliveandwork.org

  • 神戸の良いところの紹介
  • 山から見える景色の良い写真を紹介しながら「出社前に登ったりできます」
    • いや、出社前は流石に疲れるのでは...と思ったけど、体力ある人なら気持ち良い出社かもしれない
  • 市でスタートアップの支援を色々としてる

住みやすさ、食事の美味しさ、交通の利便性、...など神戸のQOLは高そうという印象を受けた。

交流会

神戸市の美味しい食べ物を頂きつつ、個人的に興味のあった神戸の金銭事情についていくつか聞いた。

  • 神戸市のエンジニアの年収帯
  • 家賃の相場感
  • スタートアップの支援について
  • 社内や神戸のエンジニアの人数に関する話
  • ....など

答えにくい直球なお金の話に、しっかり回答して頂けて個人的には満足した。

全体の感想

普段はなかなか聞けない話をお聞きできて、面白い会でした。 神戸がスタートアップ支援してるの知らなかったし、聞けてよかった。

ただ、企業のトーク時間が短くて、プロダクトの紹介で終わっていたのは少し残念。 東京では出来ない働き方や会社の制度、技術的な取り組みをもう少し聞きたかったなーと。

東京以外の勉強会の少なさによる不安

勉強会で好きな技術に関して話すのは楽しいので、その機会が減りそうなのは少し気になってる。

あと、自分の勉強する機会が減りそうという不安もある。
東京だと勉強会で野生のコミッターにぶつかって、新機能やバグ修正を本人から聞けるイベントに遭遇したりする。 こういうイベントで「アウトプットしよう」とモチベーションが高まったりする。

東京以外だとQOL高いのは魅力的なんだけど、東京を離れるデメリットも結構多くて、まだ東京を離れる選択はできない。

RailsアプリでElasticsearchを扱うならchewyがおすすめ

ruby rails elasticsearch

Twitterでツイートしたり、表参道.rbの懇親会では紹介していたけど、ブログに書いていなかったので今更ながらまとめておきます。

github.com

Chewyの利点

READMEを一通り読んでもらうと 最高に便利なのが分かる とは思うのですが、それだと身も蓋もないので個人的に良いと思ってる機能を3つだけ紹介します。

  1. 複数のストラテジ
  2. ゼロダウンタイムのインデックス更新に対応したrakeタスク
  3. Named scopes

1. 複数のストラテジ

Chewyにはデフォルトで複数のストラテジが用意されてあります。

  • :atomic: 一括でインデックスを登録する
  • :urgent: 1つずつインデックスを登録する
  • :bypass: インデックスに登録しない
  • :active_job: 非同期処理でインデックスに登録する（ :sidekiq などを直接使う事も可能）
  • ...など

これらのストラテジは最初から良い感じに設定してあります。

また、一時的にストラテジを切り替えることもできます。

Chewy.strategy(:bypass) do
  City.popular.map(&:do_some_update_action!)
end

2. ゼロダウンタイムのインデックス更新に対応したrakeタスク

READMEから説明を引用して紹介します。

Performs zero-downtime reindexing as described here. So the rake task creates a new index with unique suffix and then simply aliases it to the common index name. The previous index is deleted afterwards (see Chewy::Index.reset! for more details).

要は、「新しいインデックスを作って、エイリアスで切り替えるとゼロダウンタイムで更新できる」というもので、これに対応したrakeタスクが標準で用意されています。 しかもrakeタスクは最初から並列実行に対応しています。

あと、フィールドに updated_at が含まれていれば chewy:sync のタスクでDBとElasticsearchの同期を簡単に行うことができます。 基本的には使わないのですが、何かしらの理由でデータ不整合が起きた時に簡単に修正できて便利です。

参考: https://github.com/toptal/chewy/blob/v5.0.0/lib/chewy/type/mapping.rb#L192

3. Named scopes

ChewyではActiveRecordのようにScopeを定義することができます。

class UsersIndex < Chewy::Index
  def self.by_name(name)
    query(match: { name: name })
  end
end

UsersIndex.limit(10).by_name('Martin')
#=> <UsersIndex::Query {..., :body=>{:size=>10, :query=>{:match=>{:name=>"Martin"}}}}>

これは検索機能のように複数の条件を組み合わせるときに便利です。

class UsersIndex < Chewy::Index
  def self.by_name(name)
    # 検索フォームに未入力の場合を考慮
    return all if name.blank?

    query(match: { name: name })
  end

  def self.in_followers(user)
    query(match: { follower_ids: user.follower_ids })
  end
end

UsersIndex.by_name(params.dig(:q, :name)).in_followers(current_user)
#=> <UsersIndex::Query {..., :body=>{:query=>{:bool=>{:must=>[{:match=>{:name=>"Martin"}}, {:match=>{:follower_ids=>[1, 2]}}]}}}}>

まとめ

RailsでElasticsearchを使う場合、elasticsearch-railsを選ぶ人が多いとは思いますが、是非Chewyも検討してみてください。

私は去年の11月にchewyを見つけたけど、READMEを読んでelasticsearch-railsからchewyへの乗り換えを決めました。

「privateメソッドのテストについての考え方」を読んで #yochiyochirb

ruby rspec

highwide.hatenablog.com

を読んで、「自分なら設計を変えて、publicにしてからテストを書くなー」と思ったので、考え方・直し方の一例としてブログを書く。

元の設計

元記事のスライドの途中に出てくるコードはこんな感じで、バッチ処理などでよくある設計。

module Tasks
  module Hoge
    class Sender
      def self.execute
        data = aggregate_data
        processed_data = process_data(data)
        send_s3(processed_data)
      end
    end
  end
end

コードの臭い

個人的なリファクタリング原則で「引数が1つのメソッドは、その引数のインスタンスメソッドに書き換えられる」がある。*1

あと、元コードだと「データ収集、加工、s3に置く」のが1メソッドになっていてテストし辛いので、そこも分ける。

module Tasks
  module Hoge
    class Sender
      def self.execute
        instance.process_data.send_s3
      end

      def self.instance
        data = aggregate_data
        new(data)
      end

      def self.aggregate_data
        # データを集める処理
      end

      def initialize(data)
        @data = data
      end
      attr_reader :data

      def process_data
        processed = data.group_by(&:first)
          .sort
          .map { |key, value| [values[0], values[1]] }

        # Immutableの方がメンテしやすいので、新しいインスタンスを返す設計にしてある
        Sender.new(processed)
      end

      def send_s3
        # s3に置く処理
      end
    end
  end
end

この構造にすると、データ収集・加工・s3アップロードをそれぞれテストしやすくなる。

まとめ

単にpublicに変えるわけじゃなくて、設計を見直した結果publicになるものかなと思ってます。

*1:個人的によく使う原則なんだけど、何か名前あったりするのかな

Railsアプリでrakeタスクのログを見やすくする

ruby rails

rakeタスクのログを調べやすくするために、ActiveSupport::TaggedLoggingを使って読みやすくする方法のメモ。

# lib/rake_logger_rails.rb

module RakeLoggerRails
  # rakeタスクでログを出力するとき、自動的にタグ付けを行います。
  #
  #   task foo: :environment do
  #     logger.info('hello')  # Logs "[RAKE] [foo] hello"
  #   end
  def execute(*)
    if Rails.logger
      Rails.logger.tagged('RAKE', name) { super }
    else
      super
    end
  end
end
Rake::Task.prepend(RakeLoggerRails)

def logger
  Rails.logger
end

Rakefile の中で上のファイルを読み込む。

# Rakefile

require_relative 'config/application'
require 'rake_logger_rails'

Rails.application.load_tasks

これで、タスク内では logger を簡単に使える。

task foo: :environment do
  logger.info 'hello' #=> [RAKE] [foo] hello
end

Gitで更新頻度の高いファイルを見つける方法

git

というツイートを見かけて、ブログの下書きに眠っていたこの記事を公開した。

$ git log --name-only --oneline | grep -v ' ' | sort | uniq -c | sort -n
（...略）
  10 .rubocop_todo.yml
  10 README.md
  10 app/models/authentication.rb
  11 app/views/dashboard/show.html.slim
  11 config/environments/production.rb
  13 config/application.rb
  13 spec/rails_helper.rb
  14 circle.yml
  14 config/initializers/omniauth.rb
  14 db/schema.rb
  24 .rubocop.yml
  31 config/routes.rb
  68 Gemfile
 132 Gemfile.lock

可視化はしてないけど、どのファイルが変更されるのかは分かる。

上の出力で「bundle updateしてるけど、機能作ってない個人Railsアプリ」ってのが分かる。

自分のプロジェクト管理に関する考えのまとめ

scrum

ここ最近は色々とあってプロジェクト管理、スクラム開発について勉強していたので、それを整理するためにまとめた。

あたりを読んで勉強したので、スクラムに関する理解はそれなりになっているはず。

ただ、評価や役割に関するところは自分の好みで少し脚色があるので、これが「スクラム開発なのか！」みたいに勘違いしないように注意。

ソフトウェア開発の前提（スクラムはあまり関係ない）

「なぜソフトウェア開発をするのか？」という前提の話を最初に書いておく。 多くの企業の目的は サービス(製品)を開発し、ビジネスで利益を上げるため になるかなと思う。*1

また、1週間で計画に使える時間は最大でも 40時間/人 です。 残業しないと終わらないような計画を立てている時点で「プロジェクト管理として失敗してる」ので、マネジメントしてる人は勉強し直した方が良いです。*2

スクラム開発の役割

スクラム開発の書籍だと決まったように「プロダクトオーナー」「スクラムマスター」「開発者」「顧客」あたりの役割が出てきますが、責任が不明瞭だったので自分なりの理解をまとめた。

プロダクトオーナー(PO)

プロダクトの機能、実装する優先度、中長期の計画を立てる責任がある。

  • 顧客の要望を聞いて、ストーリーとしてプロダクトバックログにまとめる
  • 開発者と相談してUI/UX、見積もり、優先度を決める
  • 次イテレーションで開発する範囲を決める
  • 優先度を決めるため、市場の調査、KGI/KPIを把握しておく必要がある
    • ただし、自分でSQLを書く必要までは無い
    • 開発者や顧客に協力してもらっても構わない
  • どのストーリーが収入増加（支出減少）につながるかを気にする
    • ビジネスに近いところを判断するので、コスト感覚を少しは身につけた方が良い

スクラムマスター(SM)

他メンバーの動きを計測し、みんなが「スクラムらしい振る舞い」をできるように促す責任がある。

  • 他メンバーを教育するため、スクラム開発のプロセスを熟知している必要がある
  • プロダクトバックログ、スプリントバックログが整理されているか気にする
    • PO（開発者）に整理することを促す
  • デイリースクラムで問題点が無いか気にする
    • 顧客からの割り込み作業が無いか
    • スプリントバックログの進捗に問題ないか
  • ふりかえりの準備として、バーンダウンチャート、残業時間、コミット状況、テストの失敗率などを見える化する
    • これらを見える状態にして、問題に気づきやすい環境を作る
  • スクラムイベントのファシリテーター役をするための準備

開発者

正しい見積もりと、コミットメントした機能の実装に責任を持つ。

  • 見積もりが大きくブレないようにする
    • 不安なら事前にスパイクを打つストーリーを積む
    • 残業してる時点で、見積もりダメなので反省してください（余計な人件費がかかります）
  • 完了条件の曖昧なストーリーを受け入れない
  • コミットメントした機能の実装は 絶対に終わらせる
    • どうしても無理なら、早めにPOに相談する
    • 責任を果たしていないので、評価が下がるのを覚悟する

顧客

PO、SM、開発者以外の全てが顧客です。運営メンバー、営業、上司などを顧客として見た方が良い。

  • スプリントレビューで製品の質をチェックする
    • 「リリース判断可能な成果物」をレビューして「リリース判断」をする
  • 要望をPOに伝えることができる
    • 開発者に要望を直接伝えてはいけない
  • ストーリーの優先度について要望を挙げることができる
    • ただし、最終決定権はPOが持っている

スクラム開発チームの外側

スクラム開発チームの外側の人の役割について。

上司

サービス（製品）の売上目標に責任を持っていて、開発・営業の各チームリーダーから報告を受ける人。

  • POと連携して、売上の上がる施策を考える
  • POの判断と売上を分析し、POを評価する
  • 営業から挙がった施策をPOに伝える
  • 開発から挙がった施策を営業に伝える

エンジニアリングマネージャー(EM)

最近流行っているので、エンジニアリングマネージャー(EM)にしてみた。 別に上司が評価できるなら、EMを置く必要はないと思う。

  • スクラムマスターをフォローする
    • チーム全体のスクラムの知識が少ないとうまく回らないため
  • 開発者の見積もり、実装状況を計測して評価する(以下は評価の例)
    • 残業なし + 実装完了 => +2点
    • 残業あり + 実装完了 => +1点
    • 残業なし + 実装なし => +0点
    • 残業あり + 実装なし => -1点
  • 開発者のフォロー
    • 技術的な知見の共有
  • エンジニアと1on1して、目指すキャリアにあった役職を与える
  • 役職が埋まらなかったら、どうにかして調達する

まとめ

顧客により良い製品を届けるため、POは責任を持ってプロダクトバックログを作る。

開発者は「見積もり」と「コミットメントした範囲の実装」に責任を持つ。 見積もり通りに実装を終わらせたら、次イテレーションの準備をしても良いし、早めに帰っても良いと思う。

スクラムマスターは業務がうまく回るように見える化、改善を促す。 メンバーが自発的に改善し始めて、SMが仕事をサボっても問題ないのが理想だと思う。

スクラム開発チーム外の役職者（もしくはエンジニアリングマネージャー）は開発チームがうまく回るようにフォロー、育成する環境を用意する責任がある。

*1:一部の企業には、世界平和やより良い未来のために開発してる人はいるかも

*2:ただ、スタートアップの企業などで40時間を守っている場合じゃないことはある