2020年に「コミットログは良くならない」というのを悟ったので、現実的な解決案である「git-notesでメモを残す」について記事を書いておきます。 前回の記事 sinsoku.hatenablog.com git-notes 詳細は git notes --help を読んでください。 概要は以下の通りです。 コミットログとは別にメモを残せる コミットはそのままなのでshaは変わらない shaが変わらないのでCIの再実行が起きない 他人のコミットにメモをつけられる 他人に作業を依頼する必要がない メモもリモートにプッシュできる 過去のコミットにメモを残せる 使い方 メモを書く git notes edit <sha> でメモを書くと、git log のときに一緒に表示される。 $ git notes edit d2cdf0b $ git log -1 d2cdf0b commit d2c

定期的にDevise批判の話が出てくるので、個人的な考えを書いてみます。 Railsに詳しくないなら、Deviseを使わないべきか？ 「認証自作、 Rails 、 Devise」の記事で以下のような記載がある。 「Rails について深い理解がないならば、 Devise は使うな」とあります。この方針は10 年近く前から書かれています。 これ元の英語とあってない気がするんですよね。 If you are building your first Rails application, we recommend you do not use Devise. Devise requires a good understanding of the Rails Framework. In such cases, we advise you to start a simple authenticatio

転職活動で面接に行くと、だいたいどの会社も現年収を聞いてくる。 この文化が本当に嫌いなので、その気持ちをブログにまとめてみた。 最近の Twitter のツイートまとめ だいたいどの会社も現年収を聞いてくるけど、これ本当に無くなって欲しいな...。現年収の情報を加味して提示年収を考えたりしてるんだろうけど、それが本当に嫌い。— 神速 (@sinsoku_listy) 2018年2月16日 内定では社内の評価基準に準じた提示年収を出して、入社後の最初の1ヶ月とかで見込み違いだったら理由を述べて年収を下げてくれる方が納得感がある。もちろん、見込み以上だったら上げて欲しいけど。— 神速 (@sinsoku_listy) 2018年2月16日 前職の給与を聞くな！社内の評価規定をベースにして、採用したい人なら高く提示するなり、調整するなりしてくれ！ 前職の給与を考慮した金額を提示される方が嫌だ。—

Rails で RESTful な Web API を作る場合、色々な方法があると思います。 今回、私が API を作るときによくやっている設計をブログに書いてみます。 コード 説明するより、コードを見てもらった方が早いと思うので、コードを書く。 # config/routes.rb namespace :api, defaults: { format: :json } do namespace :v1 do resource :user, only: :show end end # app/controllers/api/v1/users_controller.rb module Api module V1 class UsersController < ApplicationController before_action :doorkeeper_authorize! def show