読者です 読者をやめる 読者になる 読者になる

設定きりわけ大作戦

Misoca開発チームの黒曜(@kokuyouwind)です。

先日秋葉原UDXで行われた技術書典2にサークル参加して情報ガールを頒布してきました。*1

本気で原稿を落としそうになりましたが、なんとか入稿できてよかったです。

f:id:kokuyouwind:20170419175003j:plain

「原稿は早めに書こう」という教訓を得た結果、この開発ブログはそこそこ早めに書き始めています。*2

🔧 環境設定について

今回は設定ファイルの話をします。

MisocaではSettingsLogicを使い、RAILS_ENVに応じて設定を切り替えられるようにしています。*3

しかしアプリケーションの成長に伴い設定ファイルが肥大化し、以下のような設定ファイルができあがっていました。

default: &default
  application: &default_application
    host_with_port: "localhost:3000"
    protocol: http
  service_a:
    host: "<%= ENV['SERVICE_A_HOST']%>"
    token: "<%= ENV['SERVICE_A_TOKEN']%>"
    user_path: /api/v1/user
    issue_path: /api/v2/issue
  # こんな感じで設定が100行くらい続く

development:
  <<: *defaults
  service_b:
    host: dev.example.com
    application_id: misoca_dev
    secret: secret_dev_b
  service_c:
    type: mock

production:
  <<: *defaults
  application: <<: *defaults_application
    host_with_port: "<%= ENV['APPLICATION_HOST_WITH_PORT']%>"
    protocol: https
  service_b:
    host: prod.example.com
    application_id: misoca
    secret: secret_prod_b
  service_c:
    type: api
    application_id: misoca
    secret: secret_prod_c
  # こんな感じで設定が50行くらい続く

こうなると、設定を追加するのも確認するのも大変になってきます。

特にしんどいのは外部サービスの設定で、

  • RAILS_ENVに関わらず、環境変数で設定を変える(service_a)
  • RAILS_ENVで切り替える(service_b)
  • 開発環境ではモックする(service_c)

など設定方法がそれぞれで変わってしまい、設定の見通しを更に悪くしています。

🔪 設定の分割

設定ファイルの肥大化を解決するため、外部サービスの設定は別ファイルに切り出していくことにしました。

service_bの設定であれば、以下のように専用の設定ファイルを読み込むコードを書いておきます。

class ServiceBSettings < Settingslogic
  source "#{Rails.root}/config/service_b.yml"
  namespace Rails.env
end

こうすると、service_b.ymlは下記のようにとてもシンプルになります。

development:
  host: dev.example.com
  application_id: misoca_dev
  secret: secret_dev_b
production:
  host: prod.example.com
  application_id: misoca
  secret: secret_prod_b

同様に、service_cの設定は以下のようになります。

development:
  type: mock
production:
  type: api
  application_id: misoca
  secret: secret_prod_c

元の設定と比べて、環境ごとの設定がわかりやすくなりましたね。

🚩 設定切り替え条件の変更

ステージングサーバと本番サーバで外部サービスの向き先を変えたい場合は、service_aのように環境変数でサーバを切り替えることになります。*4

このような設定は、SettingsLogicのnamespaceを利用して、1つの環境変数で設定項目をまとめて切り替えるようにしました。

class ServiceASettings < Settingslogic
  source "#{Rails.root}/config/service_a.yml"
  namespace ENV['SERVICE_A_ENV'] || 'development'
end

設定ファイルであるservice_a.ymlは以下のようになります。

default: &default
  user_path: /api/v1/user
  issue_path: /api/v2/issue
development:
  <<: *defaults
  host: dev.servicea.example.com
  token: token_dev
production:
  <<: *defaults
  host: servicea.example.com
  token: token_prod

こうすることで環境変数の設定が簡潔になり、各環境での設定内容をきちんと設定ファイルに記述できるようになりました。

🏗 URLの構築

上述の設定ファイルのようにホスト名とパスをそれぞれ定義した場合、URLを使う箇所で"https://#{ServiceASettings.host}#{ServiceASettings.user_path}"のようにURLを組み立てる必要が出てきます。

これは使いづらかったので、以下のように設定クラスを拡張し、*_urlに対応する設定が見つからない場合には*_pathからURLを生成して返すようにしました。

class ServiceASettings < Settingslogic
  source "#{Rails.root}/config/service_a.yml"
  namespace ENV['SERVICE_A_ENV'] || 'development'

  # *_urlが見つからず、対応する*_pathがある場合はhostを含めたフルURLを生成して返す
  def method_missing(name)
    if name =~ /_url\Z/ && host
      path_key = name.to_s.gsub(/_url\Z/, '_path').to_sym
      url = URI.join("https://#{host}/", send(path_key)).to_s
      create_accessor_for(name, url)
      url
    else
      super
    end
  end
end

これで、ServiceASettings.user_urlのようにアクセスすることができるようになります。

設定ファイルを切り分けることで、こういった各設定ごとのヘルパーも生やすことができるようになり、なかなか便利です。*5

📢 宣伝

Misocaでは設定ファイルを綺麗にしたいエンジニアを募集しています。

*1:リンク先はおためし版になってます。全文PDFはいろいろ手直しがあり、現在頒布準備中です…

*2:結局、あまり余裕のない時間に書き上がりました

*3:類似のGemにconfigなどがあります。最近だとこちらのほうが主流かもしれません。

*4:RAILS_ENVとしてstaging環境を追加する方法もありますが、環境を増やすとそれだけ複雑になるためMisocaでは行っていません。

*5:設定クラスでやるのは邪道かもしれませんが、このためだけに別のラッパークラスを作るのもなぁ… と迷った末、今回はこうしました。

❄️frozen_string_literal

こんにちは、mzpです。最近はBuckleScriptで、OCamlJavaScriptに変換して遊んでいます。

先日、Misoca開発チームでfrozen_string_literal を有効にするようにしたので、そのときの話を紹介したいと思います。

🔥有効にする前に起きたこと

Ruby 3.0からfrozen_string_literalが標準で有効になるという話もあって、一部のコードに # frozen_string_literal: true が登場するようになりました。

次第に、 # frozen_string_literal: true を書いてないと、レビューで指摘が入るようになりました。

f:id:mzp:20170411172750p:plain

f:id:mzp:20170411173000p:plain

🚓 Rubocopの設定変更

機械的にチェックできる項目をレビューで指摘するのは好きではないので、RubocopのStyle/FrozenStringLiteralCommenteを有効にし、自動でチェック・修正できるようにしました。

f:id:mzp:20170411173235p:plain

その際、既存のコードにはすべて ruboocp:disable をいれて、このルールに検知されないようにしました。

# 既存コードは frozen_string_literal: true を書いてなくても許す
%w(app lib spec config).each do |name|
  Dir["#{name}/**/*.rb"].each do |path|
    content = File.read(path, encoding: 'utf-8')
    if content !~ /\A# frozen_string_literal: true/
      File.write(path, "# rubocop:disable Style/FrozenStringLiteralComment\n" + content)
    end
  end
end

🔪Ripperによる自動書き換え

大半のファイルに rubocop:disable が書いてあるのは微妙かなと思ったので、安全に書き換えれるファイルでは frozen_string_literal を有効にするようにしました。

具体的にはRipperで全ファイルを走査して、文字列リテラルを使っていないファイルではfrozen_string_literal を有効にするようにしました。

f:id:mzp:20170411174755p:plain

require 'ripper'

class FindStringLiteral < Ripper::Filter
  def on_tstring_beg(_, data)
    data = true
  end

  def on_tstring_content(_, data)
    data = true
  end

  def heredoc_beg(_, data)
    data = true
  end
end

def string_literal?(path)
  content = File.read(path)
  FindStringLiteral.new(content).parse(false)
end

%w(app lib spec config).each do |name|
  Dir["#{name}/**/*.rb"].each do |path|
    unless string_literal?(path)
      content = File.read(path, encoding: 'utf-8')
      if content =~ %r{\A# rubocop:disable
Style/FrozenStringLiteralComment}
        File.write(path, content.gsub(/\A.*/, "# frozen_string_literal:
true"))
      end
    end
  end
end

🚀今後の予定

残ったファイルは自動では修正できないので、別の修正するたびにちょっとづつ書き直しています。ボーイスカウトルールです。

f:id:mzp:20170411175109p:plain

🔉宣伝

Misocaではコードを綺麗にしていくエンジニアを募集しています。

Controllerのリファクタリング ~または私は如何にして肥大化していくControllerをやめてDHHによるControllerの書き方を愛するようになったか~

こんにちは!
Misoca開発チームのめろたん(@renyamizuno_)です!

最近LEGOランドが開園したので行きたいのですが、地味に遠いため行けてないマンです。

最近あった面白いことは、 スマホでスクショとか撮れないなぁと思って色々確認したら、

アプリとかキャッシュとかがスマホのストレージ容量をありえないくらい超越してたことです。

はい。

今回は最近ありえないほど大きくなってしまったControllerをいかにリファクタリングしたか*1というのをざっと書きたいと思います。

おおきくなるController

どうしても大きくなっちゃいますよね。

なにも考えないと大きくなっちゃうのは知ってたので*2、 Controllerのアクションをmoduleとして切り出して、Controllerにincludeするようにしていました。

# app/controllers/hoge_contoller.rb
class HogeController < ApplicationController
  include HogeController::FugaActions

  def show
  end
    
  # ...
end

# app/controllers/hoge_contoller/fuga_actions.rb
class HogeController
  module FugaActions
    def fuga
      # ...
    end
  end
end

最初の頃は、「これめっちゃええやん。最高かよ。」と喜んでいました。

ですが、これで思考を停止してしまい機能を増やすたびにHogeActionsを増やすという愚行をやっていました。 思考を停止しているのでなーんにも気にせず追加していたのですが、ある時メンバーから 「これは…ひどいよ…。」 という声が上がってハッとして見直したら

class HogeController < ApplicationController
  include HogeController::FugaActions
  include HogeController::FugaFugaActions
  include HogeController::FugaFugaFugaActions
  include HogeController::FugaFugaFugaFugaActions
  # ...

  before_action :hoge
  before_action :hogehoge, only: :add_hoge
  # ...

  def show
  end
    
  # ...
end

実際のコードを乗っけるのは流石にアレなのでざっくりとしかかけないのですが、 実際はもっとひどくてなんか大変でした…。

さあリファクタリング

現状がやっべぇのは認識できたのでそこからどう直すか考え方針をまとめて、
メンバーにレビューしてもらい方針を固めました。

大きく3ステップで進めようとなりました。

1. たりとらんテストを足せ

そもそもなんでテスト足りてないんだよ…という話なのですが、申し訳。

Misocaではビジネスロジックをクラスに切り出して「ユースケースオブジェクト」と呼んでいます。 Controllerはユースケースオブジェクトを呼び出して、ビジネスロジック処理の結果を受け取るという風にしています。 でそのユースケースオブジェクトのユニットテストが明らかに足りていないものが多くありました…。

リファクタリングをして動作が壊れてもテストがないとわからないので、まずそのへんのテストをちゃんと一通り書こうとなりました。

2.責務を切り離せ

ユースケースオブジェクトに「『これ』をやって『これ』をする。」のような感じの物がありました。 具体的には「権限を確認」して、問題なければ「なにかを作る」のような感じでした。

これは複数の事を一つのクラスでおこなっているため良くないね。というような感じになりました。 なので責務を切り分けて、別のクラスに切り出しました。もちろんテストもちゃんとかきました。

3.HogeActionsをHogeControllerに

最後にHogeActionsとなっているのをHogeControllerに変更します。

方針としては、下の記事を参考にしてやりました。

postd.cc

これはとても一般的なパターンですよね。私も以前はもっとこのパターンを使っていました。 しかし今は「いやいや違う」と思うようになりました。indexという単一のメソッドのみを持つInboxes::PendingsControllerという、新しいコントローラを持つのです。

基本的に彼が言っているのは、コントローラはデフォルトのCRUDアクションindex、show、new、edit、create、update、destroyのみを使うべきだということです。その他のアクションはどれも専用の(それ自体はデフォルトのCRUDアクションしか持たない)コントローラの作成につながるのです。

現状のコードを見ると、

class HogeController
  module FugaActions
    def fuga
    end
  end
end

となっている。

のでこれを上の記事に従ってControllerに書き換えます。

module Hoge
  class FugaController
    def create
    end
  end
end

このfugaアクションはFugaを作るものだったので、DHHの教えに従ってcreateにリネームしました。

あとはroutes.rbを修正するのみです。

resources :hoge, only: [:show] do    
  member do
    post :fuga
  end
end

というのを

resources :hoge, only: [:show] do    
  member do
    resources :fuga, only: :create, module: 'hoge'
  end
end

のように修正して完成です!!!

まとめ

まだリファクタリング途中なのでアレですが…

before

class HogeController < ApplicationController
  include HogeController::FugaActions
  include HogeController::FugaFugaActions
  include HogeController::FugaFugaFugaActions
  include HogeController::FugaFugaFugaFugaActions
  # ...

  before_action :hoge
  before_action :hogehoge, only: :add_hoge
  # ...

  def show
  end
    
  # ...
end

after

# app/controllers/hoge_contoller.rb
class HogeController < ApplicationController
  def show
    # ...
  end
end


# app/controllers/hoge/fuga_contoller.rb
module Hoge
  class FugaController < ApplicationController
    # アクセスできるできるユーザか確認
    before :authenticate

    def create
      # ...
    end

    private

    def authenticate
      # ...
    end
  end
end

別のクラスになるのでどこまで影響があるのかわかりやすくなりましたね。 たとえばbefore_actionが、 別ファイルにあるアクションに影響が〜とかがなくなったので良いですね。 またCRUDアクションだけになるので、なにをするのかがControllerの名前だけみればわかるようになったのも良かったです。

あとDHHがこれやってるっていうのがめっちゃ安心感があってよかったです。

さいよう

Misocaではキューブリック作品が好きな人を募集しています!

*1:実際は現在進行系

*2:われわれはかしこいので

スナバからのリモート勤務

前記事の@mugi_uno と同様、3月からMisocaにリモートワーカーとしてjoinした @lulu-ulul です。

自己紹介とjoin した経緯、名古屋でのオンボーディングの後にMisocaでフルタイムのリモート勤務を1週間やってみた所感を書いていきます。

前記事で触れられてる事は私も感じていますが、繰り返しになるので省きます。

tech.misoca.jp

about me

鳥取県鳥取市在住

rubyistにはおなじみの島根と同じ山陰地方にあります。 中国地方の北側にある山陰地方、その右側担当です。 f:id:lulu-ulul:20170330102109j:plain

Misocaには松江オフィスがあるので直線距離では手前ですが、 名古屋への飛行機は無いためオフィスへのアクセスの悪さでは上かもしれないです。

鳥取の中でも東側なので関西圏へのアクセスの方が良かったりします。 大学は関西に出てましたが、Uターンで地元に戻ってきました。

鳥取

f:id:lulu-ulul:20170330101650j:plain ©鳥取県

有名な所だと砂丘・松葉ガニ・梨・山陰海岸ジオパーク辺りでしょうか。 ここ数年のネット界隈ですとスナバコーヒーやポケモンGOのスポット等が記憶に残っているかもしれません。

都市部みたいな遊びには向いてませんが、のんびり暮らして行く上では住みよい町なんじゃないかなーって思ってます。

山・海・スノースポーツ・ツーリング・温泉めぐりと一通りできるのでアウトドア派には良い土地でもあります。

今はAmazonを始め通販が充実してきているのでインドア派の自分も生活する分には特に不満はありません。

略歴

地元のシステム開発会社で研究開発やRubyを中心とした受託開発をやっていました。

県外のクライアント相手の機能追加案件が多かったため、gitベースの納品やリモートでのやり取り等に慣れる事ができました。この経験は、Misocaで生かされていると感じています。

一度退職して家族の介護をしていましたが状況が落ち着いたので就職活動を行いました。

最初は東京に出る予定で、転職先も決まりました。

しかし祖母を置いて行くのはなあという思いが強くなり、フルタイムのリモート勤務(以下フルリモート)ができる企業を探しました。

Misocaを選んだ理由

以下の理由から総合的に決めました。

  • 鳥取からフルリモートで働ける
    • くわしくは後述します(※1)
  • 自社サービスを行っている
    • 運用等も含めて全体に関わって行きたいという気持ち
    • 一つのサービスを育てていくという過程を経験してみたい
  • 地元に間接的にでも貢献できそう
    • 鳥取は中小企業の割合が高いため
  • リモート勤務が一部の人のものではなく全員の選択肢になっている
    • くわしくは後述します(※2)
  • 選考の中で社員の方やオフィスの雰囲気が掴めた
    • 選考の中で一日名古屋オフィスで作業しました!

鳥取からフルリモートで働ける(※1)

これが一番大きい理由です。

居住地を選ばない働き方ができるのは私の理想でした。

リモート勤務が一部の人のものではなく全員の選択肢になっている(※2)

名古屋在住の人も当たり前の様に利用しているので、自分だけリモートで特別扱いされている、という感覚はありません。

ミーティングの参加者全員リモート参加という日もありました!

また、フルフレックス制ではなくコアタイムを合わせて名古屋オフィスに皆が繋ぐ形態です。 オフィスを拡張した様なイメージを感じています。

リモート勤務をしてみて

良かった事

適宜家族の様子を窺う事ができる

  • 小休憩する時等についでに様子を見れるので安心できます
  • いざという時にすぐ対応できるという安心感も!

通勤時間が無い

  • 朝や夕方に家族との時間を取れる
  • 朝昼晩一緒に御飯を食べられる!

ちょっとしたタスクをこなせる

不定期に5分くらい家族の世話をしないといけない時があるのですが、すぐに対応できます。 (もちろん採用時にちゃんと伝えてあります!)

これはオフィス勤務だとまずできない事なので大変助かってます。

お魚がおいしい

鳥取は田舎ですが海産物のコスパに関してだけは都会には負けません!

白イカ!ノドグロ!もさえび!蟹!etc…

お刺身おいしい。 f:id:lulu-ulul:20170330164001j:plain

困った事

ビデオ会議の負荷が高い

MisocaではGoogle hangoutsを勤務中繋ぎっぱなしにするのですが、人数が多くなると2016年モデルのMBPでも負荷が気になるレベルでした。

→これは後日ハングアウト専用のノートPCを支給してもらえたので解決しました!

タスクに直接関係無いコミュニケーション

雑談とかの頻度はやっぱり対面でやるより減ってしまいますね。

Misocaでは最初に名古屋で14営業日程のオンボーディングがあって、人となりが大体掴めたので大分助かってます。

またSlackの個人用チャンネルが整備されていたり、日報のコメント欄でのやり取りといった文字ベースのコミュニケーションもあります。

これについては私も何か良い案があればフィードバックしていきたいなと思ってます。

他に感じた事

改善サイクルが早い

提案に対してのアクション、フィードバックが早いと感じています。

例えば全体の振り返りミーティングでは、私が入ってからでもフォーマットが2回変わりました。

単に不要な情報を削るだけではなくて、情報の出す順序を変える事で質も上がっています!

まとめ

フルリモート勤務をするにあたって、私が期待していた以上の環境がありました。

後は私がキャッチアップして期待に応えていくだけだと思っていますので頑張っていきます!


株式会社Misocaでは、家族と一緒に暮らしながら地方で頑張るエンジニアも募集しています!

Misocaと富山と私

3月からMisocaにjoinした @mugi_uno です。

joinしたらブログでしょ!という流れに乗って、簡単な自己紹介と所感を書いてみます。

自分について

富山県に住んでいます。

Misocaのオフィスがある名古屋とは、地理的に岐阜県を挟んで真逆に位置しています。 バスで片道4時間弱。遠いですね!

富山を出発して名古屋に着くころには体がバキバキです。体の衰えを感じます。

Toyama.rb

Toyama.rbというRubyのコミュニティを月1程度の頻度で開催しています。 派手な活動はしていませんが、かれこれ1年半ほど続けています。

f:id:mugi1:20170316183204p:plain

富山?

富山県は魚がとっても美味しく、特にブリが絶品です。お越しの際には食べてみてください。

※ブリしゃぶ f:id:mugi1:20161212190811j:plain

魚以外では、ブラックラーメンというB級グルメがあり、かなり塩気が強いため賛否両論あるようですが、私は大好きです。 f:id:mugi1:20120715123012j:plain

リモートワーク

富山と名古屋という位置関係もあり、自宅の一室を使いフルタイムでリモートワークしています。 (ずっと家に居るので、説明出来ていないご近所さんにどう見えるのかは少し心配です)

地方転職とMisoca

転職理由

前職は、いわゆる地方の中小SIerに新卒で入社し、8年ほど働いていました。

ただ、長い間「自社のWEBサービス開発にかかわってみたい!」という考えがあったことと、開発手法など技術的な面でも新しいやり方を取り入れているところに身を置きたいと思っていました。

地方転職の難しさ

最初は地元での転職活動も考えましたが、自分が望むような会社はほとんど都会にしか存在せず、ほぼ困難というのが実情でした。 また、既婚で子供がいることもあり、家族を置いて自分だけ都会に行くというのは選択肢として考えていませんでした。

リモートワークで探す

地方や家族を言い訳に諦めたくはないと思い、リモートワークを視野に会社を探し、フルタイムでのリモートワークを採用している会社として最終的に出会ったのがMisocaでした。

なぜMisoca?

採用活動が本気

まず、採用活動に多くのリソースを割いており、真剣に人を見ていることが伝わってきました。

面談の回数も多く、最終的には名古屋にあるオフィスに直接足を運び、エンジニアと1日関わるという機会もあります。

自分自身も、リモートの面談だけでお互いに理解できるのか?と考えていたので、こういった手順を踏んでいるのは安心できました。

また、代表の豊吉を含め、皆さん真摯な対応で、かつ本気であることが会話していても良くわかりました。

リモートワークへの理解と改善意識

Misocaでは、遠方のメンバーだけではなく、全メンバーが自由にリモートで働くことができます。

そのため、リモートワークという働き方は全員で共有されているものであるため、メリットもデメリットも理解されています。

常日頃からメンバー全員の改善意識も高いため、

  • 思ったことは言おう!
  • 困ったことはガンガン相談して解決していこう!
  • やってみよう!

という文化で、ここでならリモートで困ったことがあってもやっていけそうだな、と思えました。

実際にjoinしてからも、このとき感じたことは間違ってなかったです。

Misocaに入って感じたこと

速い

まずこれを一番に思いました!なによりミーティングのスピードが速い!

基本的に沈黙の時間はありません。

ミーティングというのは参加者全員の時間を並列に奪っていくため、いかに効率良く進めるかを全員が意識しており、かつ実践されています。

豊吉ブログの過去エントリでも言及されていましたが、「それは後にしましょう」というワードは、年齢や役職などは関係なく頻繁に耳にします。 実際に目の当たりにした時には「ひー!これ開発ブログで見たやつやー!!」と思いましたが、すぐに、これが人格否定ではなく効率良く進めるために全員が理解したうえで行われてるんだな、ということが解りました。

夜は帰る

「基本的に残業せずにみんな帰ります」と事前に聞いており、正直なところ心の奥底では「本当かな〜?」と思ってる部分がありました。 実際にjoinしてみると、大半のメンバーは午前10時ごろにオフィスに来て、夜の7時過ぎには帰っていきます。 (時間は人によって多少前後します。私は9時〜18時で働いています。)

残業ではなく、いかに決められた時間内で最大のパフォーマンスを出すかを皆が真剣に考えているからこそ出来ていることだと思います。

改善意識の高さ

Misocaでは複数のプロジェクトが動いており、週に一回プロジェクト単位でのふりかえりが行われます。同時に全体でのふりかえりも行われ、悩みや相談ごとはここで共有されます。内容も

  • ○○というフレームワークが使いたい
  • はじめてプルリクエスト出した!うれしい!
  • 部屋が暑い
  • 備品が足りない

と様々です。

この時に出したActionは次回のふりかえりで進み具合を確認するため、「いつかやりたいけどな〜」で腐っていくことがなく、素早い改善が繰り返されています。

みんないいひと

漠然としていますが、素直に「皆さん良い人だな〜」と思います。slackで困っている人にはすぐに救いの手が飛んできますし、実際に会話をしていても皆さん本当に人格者です。

ミーティング中に少しピリッとしても、終われば普通に笑いあって会話している姿を見ると、メリハリがしっかりしているのも良いなと思えます。

というわけで

f:id:mugi1:20170317185612j:plain

まだ日が浅く、速さについていけず戸惑っているところもありますが、良い環境に来れたと思います。

「joinしてくれて良かった!」と言ってもらえるよう頑張ります!


株式会社Misocaでは、家族が大事な地方で頑張るエンジニアを募集しています!

よいコミットメッセージ・よくないコミットメッセージ

こんにちは、mzpです。

今日はMisocaのesaに書いていた「よいコミットメッセージ・よくないコミットメッセージ」という記事を紹介したいと思います。

あらすじ

開発チームでは「コミットメッセージには変更理由を書いて欲しい」「コミットメッセージはWhatよりもWhyが大事」という話を何度かしているのですが、なかなか徹底できていません。

ので、もう少し具体的に「こういうコミットメッセージはよくないですね」というまとめを作ってみることにしました。

ちなみにこの過程でみつけたコミットメッセージに、こんなものがあります。 一切情報がなくておもしろいですね。

f:id:mzp:20170313132724p:plain

ファイル移動を移動した事実しか書かない

これは以下のようなコミットメッセージです。

ファイルを移動したことはコミットメッセージを見なくてもdiffから分かりますが、なぜその移動をしたかが分かりません。 ので、移動した理由を残すようにするとよいです。

  • 責務を適切に表わすファイル名に変更
  • ライブラリのバージョンアップに伴いディレクトリ変更
  • 似た内容のファイルをまとめるためにディレクトリ移動

「指摘対応」としか書かない。

これは以下のようなコミットメッセージです。冒頭にあげたコミットメッセージもこれですね。

  • レビュー対応
  • 指摘対応
  • Rubocop対応

なぜその変更をしたかが後から見たときに分かりません。 指摘があった場合はその内容を残すとよいです。(参考: 自分の言葉で書かれたコミットメッセージが好き - 準二級.jp)

  • 一行が長すぎるので修正
  • Style/IndentHash による自動修正
  • メソッドが長すぎるので修正
  • Array#map を使ってリファクタリング

「修正した」としか書かない

これは以下のようなコミットメッセージです。

  • specを修正
  • CI対応

繰り返しになりますが、なぜその修正をしたかがあとから分かりません。 CIやspecで確認していることをコミットメッセージに残すとよいです。

  • xがnilのケースを想定していなかったので修正
  • specが意図したものになっていなかったので修正
  • CIでの実施内容が間違っていたので修正

コミットメッセージに理由を書こう

Misocaではコミットメッセージに理由を書くエンジニアを募集しています。

Misocaの開発を支える名駅ランチTrelloボード

こんにちは。sunflatです。 最近FF15PS4を買ったのですが、DQ10が忙しくてあまり遊べてません。

さて、Misocaでは開発のタスクや課題を管理するために、Trelloを使っています。

trello.com

付箋感覚でカードを貼ったり移動したりできて便利なので、開発プロセスのふりかえりやブレインストーミングなどにも利用しています。

こんな便利なツールを、開発のためだけに使うのはもったいない!

ということで、Misocaオフィスが名古屋駅に引っ越した時から、オフィス周辺の昼食が食べられるお店をTrelloで管理するようになりました。

f:id:sunflat:20170224145156p:plain

「いってみたい」リストに気になるお店の情報を書いておき、そのお店に行った人は、感想や写真をコメントに書いて「いった」リストや「2回以上行った」リストに移動する、という仕組みです。

Misocaオフィスから近いお店の一覧がすぐに分かるし、新しいお店を新規開拓するモチベーションのアップにもつながるので良いですね。

というわけで今回は、Misocaオフィス(名古屋駅)周辺の、僕のお気に入りのランチスポットを紹介します。

担々麺

杏亭

http://tabelog.com/aichi/A2301/A230101/23009093/

f:id:sunflat:20170227102226j:plain

他のお店の担々麺とは違う、何か独特のスパイスの味がして、クセになる美味しさ。

それほど辛くはないので、辛いのが苦手でも大丈夫かも(ただし油っこい)。

汁有り担々麺と汁無し担々麺がある。汁無し担々麺は一見量が少なめだけど、実は結構多い。

ランチタイムはご飯無料サービス。汁が服につくとやっかいので、紙エプロンをもらったほうが良い。

カレーライス

ERICK SOUTH

https://tabelog.com/aichi/A2301/A230101/23060430/

f:id:sunflat:20170224153319j:plain

南インドカレーのお店。オフィスから近いので良く行く。

パリパリしたせんべいみたいなやつを割って、カレーとご飯に混ぜて食べるとクリスピーで美味しい。

いくつかのカレーのなかから3種類をチョイスできるセットがお気に入り。

ただし、ラムカレーはかなり辛いので注意が必要。

レジの横に置いてある口直しのスパイスは、刺激が強いので一気に口に含むと危険。

肉餃子 THE GYO

https://tabelog.com/aichi/A2301/A230101/23060136/

f:id:sunflat:20170224154837p:plain

肉餃子の専門店なのだが、ランチタイムにはカレーライスやザーサイ等が食べ放題で、しかも値段がセットで580円〜と非常にお得。

肉餃子は、汁がたっぷり入った小籠包風の皮が厚い餃子。オフィスのメンバーにはあまり好評ではないけど、個人的には悪くないと思う。

カレーライスは安心できる普通の味。むしろこっちがメイン。カレーライスをお腹いっぱい食べたくて、しかも財布がピンチの時には、この店がおすすめ。

もうやんカレー

https://tabelog.com/aichi/A2301/A230101/23059172/

色々なカレーやおかずが食べ放題のお店。

カレーは濃厚。とても美味しいのだが、食べ過ぎて行動不能になってしまうので、午後は早退する覚悟で食べに行く必要がある。

海鮮丼

めしの助

http://tabelog.com/aichi/A2301/A230101/23054149/

f:id:sunflat:20170227103133j:plain

値段がちょっと高めだけど美味しい。

でも、いつも混んでて行列ができているので、なかなか行く機会がない。

雰囲気がよく、安心できる味。お客さんを連れていく場合に良いかも。

さかなやま

https://tabelog.com/aichi/A2301/A230101/23004280/

海鮮ちらし(数量限定)が、ボリュームもあって美味しい。

入り口で札を取って入店するシステム。お目当てのメニューの札が無くなっていたら諦めよう。

魚正宗

https://tabelog.com/aichi/A2301/A230101/23031848/

漁師丼がリーズナブルで美味しい。

量も多め。おでんが無料でついてくることもあった。

明日のMisocaのランチを支えるのは君だ!

オフィスが名古屋駅に引っ越してから半年以上が経ち、最近はあまり新規のお店に行かなくなってしまったように思います。

株式会社Misocaでは、入ったことのないレストランにも果敢に入店する探究心のあるエンジニアを募集しています。