既存アプリやライブラリへの影響が大きく、この変更に対してネガティブなフィードバックも多かったためリバートされました。 github.com 概要 表題の通り、Rails v7.1.0 で APOSTROPHE (U+0027) が SINGLE QUOTATION MARK (U+2019) に変わります。 github.com 既存のRailsアプリをアップグレードする際に影響が大きそうなので、記事を書きました。 影響範囲 テストでエラーメッセージを検証していた場合、Rails v7.1.0 のアップグレードによって検証に失敗するようになります。 Expected: "can't be blank" Actual: "can’t be blank" 今回の変更を知らない場合、このテストのエラーメッセージだけで ' と ’ の違いを見分けるのは厳しそう。 SINGLE QUOTATION

備忘録。 具体的な例 先日に登録されたissueを例にしてみる。 github.com 再現コードを少し書き換える v5.2.3と6.0.0.rc2でsqlite3の依存周りでエラーが出たので、Gemfileのあたりを少しだけ弄った。 # frozen_string_literal: true require "bundler/inline" gemfile = File.read(File.expand_path("Gemfile", __dir__)).strip version = gemfile.lines.find { |line| line.include?('sqlite3') } .then { |sqlite3_line| sqlite3_line.strip.split(',').last.delete('"') } gemfile(true) do source "h

ここ最近は色々とあってプロジェクト管理、スクラム開発について勉強していたので、それを整理するためにまとめた。 スクラムガイド スクラム現場ガイド SCRUM BOOT CAMP THE BOOK スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) Regional Scrum Gatheringの2018, 2019の全スライド ryuzee.com の2017, 2018のスクラムに関する記事 あたりを読んで勉強したので、スクラムに関する理解はそれなりになっているはず。 ただ、評価や役割に関するところは自分の好みで少し脚色があるので、これが「スクラム開発なのか！」みたいに勘違いしないように注意。 ソフトウェア開発の前提（スクラムはあまり関係ない） 「なぜソフトウェア開発をするのか？」という前提の話を最初に書いておく。 多くの企業の目的は

Rails Developers Meetup 2018 Day 1で「Railsアプリの育て方」という発表をしました。 railsdm.github.io 発表資料 余談 本当は4月から放送されるシュタインズゲートゼロみたいな流れにしたかったけど、ちょっと上手く話の流れを作れなかったので、今回は普通に作りました。 明日の資料をシュタゲゼロっぽい感じにしたかったけど、無理だったので普通の感じで作っている。本当はβ世界線でコードが破滅的になり、DメールでRuboCopを導入したらα世界線ではLintによるディストピアになってる話をしたかった。— 神速 (@sinsoku_listy) 2018年3月23日 世界線の収束により、どんなに頑張っても同じ日にデスマが起きる話したかった。— 神速 (@sinsoku_listy) 2018年3月23日 資料を作るのは難しい。

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

最近やっているけど、これ良い勉強になっているのでブログで紹介する。 読むようになったきっかけ 先月、永和システムマネジメントさんのOSSパッチ会に参加しました。 agile.esm.co.jp この会の懇親会では Rails の Issue やプルリクの話題が多く出ました。 ただ、私が知らない話題もいくつか出ていて、もっと Rails の更新内容を知りたいと思いました。 その結果、酔った勢いで rails/rails を Watching にしてみました。 毎日だけど、雑に読む Rails は活発に開発されているため、Issue(プルリク)は毎日たくさん増えます。 しかし、これを隅々まで目を通すのはとても大変です。 なので、雑に目を通しています。 興味のないやつは読み飛ばす 自分が使用していない機能(ActionCable, ActiveStorageなど)の Issue やプルリク 英語

2018年2月末に株式会社groovesを辞めます。 おそらく、退職エントリってやつです。 株式会社groovesでやってきたこと Forkwellの開発を担当していました。サービスの詳細はリンク先を読んで頂くとして、私が主に関わっていたのは下記の2つです。 Forkwell Jobs: エンジニア専門の求人サイト Forkwell Portfolio: エンジニア向けのポートフォリオサイト 特にPortfolioの「エンジニアの技術力を可視化する」というコンセプトは私の提案から始まっていて、仕様の作成、設計、実装とだいたい全てを担当していました。 技術的にやってきたこと 新しい機能の実装以外で、開発環境を色々と改善してきました。 Werckerを導入して、ブランチ毎にテストを実行するようにした Jenkinsをリストラした wheneverでcronの設定をコード化した RuboCopを

はてブを眺めてたら、なんか Git の記事がバズってたので、便乗して Git の話を書いてみた。 Oh, shit, git! http://ohshitgit.com/ 「Oh shit, git!」を簡単に和訳してみた。(追記あり) - Qiita https://qiita.com/KaminoHiroki/items/391fb421e94e82c00128 基礎知識 git-reset は危ない git reset --hard は作業ディレクトリにコミットしていない変更があった場合、全てを吹き飛ばしてしまう可能性があります。 使う前に必ず git status を実行して、作業ディレクトリの状態を確認をした方が良いです。 git-checkout は遅い checkout コマンドは作業ディレクトリの状態を変更します。このとき ファイルアクセスが発生するため遅い です。 git

一応、お仕事で Ruby やっているプロだけど、本の内容が気になったので買ってみました。 昨日、先行販売している紀伊國屋書展 新宿本店で購入（正式発売日は11月25日）。 新宿紀伊国屋は残り2冊だった。危ない。ギリギリだったけど、なんとかプロになれそうだ！ pic.twitter.com/m44TiPjNez— 神速@Rubyエンジニア(プロ) (@sinsoku_listy) 2017年11月20日 ラス2だったので、結構ギリギリ。そして、一気に読んでみた。 プロRuby本を読了した。索引除いて445ページでなかなか厚いけど、なんとか1日で一通り読めた。(流石に写経まではしてない)— 神速@Rubyエンジニア(プロ) (@sinsoku_listy) 2017年11月20日 技術書は油断するとすぐ積み本に進化するので、意識高まった時に読み切った方が良い。 私のRuby力 プログラマ歴は1

6/1(木) の表参道.rb でLTしてきました。 omotesandorb.connpass.com 資料 「他人がどうやって Ruby/Rails を学んできたのか？」って意外と聞く機会は無いと思うので、自分のふりかえりも兼ねて発表してみました。資料は Qiita で公開してます。 qiita.com 経歴について RESTful を知らずにコード書いてた時代 ソシャゲ案件で QuestsController#execute とか書いてた 実は Rails チュートリアル未経験 SQL を ActiveRecord 無しでちゃんと触ったのは最近(3年前くらい) それまで都度、ググっていた と、恥ずかしい話もありますが、今 Ruby/Rails 勉強している人に何か役立てば…と思って、自分が触ってきた技術的なネタを時系列で紹介してみました。 初心者向けの Ruby/Rails の勉強方法

技術書典は書く側で参加したい気持ちはあるけど、書くネタと書く時間があるかどうか…— 神速@リリカルエンジニア (@sinsoku_listy) 2017年4月9日 あー、自分の知ってるRailsアンチパターンとか書きたいかも。自分の犯した罪(アンチパターン)を贖罪したい…。— 神速@リリカルエンジニア (@sinsoku_listy) 2017年4月9日 技術書典2 に行ったら無性に本を書きたくなったけど、本書くのは 面倒 大変です。 というわけで、とりあえずブログに記事を1つ書いてみた。 factory_girl factory_girl はテスト用データを作成するときに使う gem です。 下記は User のモデルを定義するファクトリーです。 FactoryGirl.define do factory :user do first_name "John" last_name "Doe

2013/10/16: Githubのhelp「Remove sensitive data」について追記 先日、初めて知ったのですが、GithubのプルリクをCloseは出来ても、削除は出来ない。(*1) 普段使う上では困らないのですが、パスワードなどの公開すべきでない情報がプルリクに含まれると、結構ヤバい事になる。 結論 結論を先に書くと「リポジトリを作り直すしかない」 試したこと プルリクしてるブランチを上書きする パスワードなどの情報をコミットから(rebase -iなどで)消してからブランチを上書きしてみた。 $ git push -f origin topic_branch プルリクに上書き前後の履歴が全て表示される... プルリクエストしたブランチを削除する 実はGithubでプルリク中のブランチを削除すると、自動的にプルリクがCloseになる。 Closeになるだけだった..

なかなか読む時間が取れなくて積み本になっていたのを週末に読んだので、その感想です。 現場で使える Ruby on Rails 5速習実践ガイド(特典PDF付き) 作者: 大場寧子,松本拓也,櫻井達生,小田井優,大塚隆弘,依光奏江,銭神裕宜,小芝美由紀出版社/メーカー: マイナビ出版発売日: 2018/10/19メディア: 単行本（ソフトカバー）この商品を含むブログを見る ちなみに、読み終わった直後の感想はこれ。 #現場rails を読了。図で分かりやすく説明されてたり、実際の開発の流れを想定した説明があったり、実務でありがちな要件をRailsで実装する例を紹介していたり、なかなかに実践的な本だなーという感想。Railsエンジニアはとりあえず読んでおくと良いと思う。— 神速 (@sinsoku_listy) 2018年11月17日 全体の感想 Twitterにツイートしてあるように、良い本だ

その1って書いたけど、続くかは不明。 今回は使っているgemの読み込み時間を測ってみた。 Benchmark を仕込む config/application.rb でgemを読み込む前に Kernel.require を上書きして、計測する。 +require 'benchmark' +$result = {} +Kernel.singleton_class.prepend(Module.new do + def require(feature) + ret = nil + $result[feature] = Benchmark.realtime { ret = super } + ret + end +end) Bundler.require(*Rails.groups) +$result.sort_by { |_, t| -t }.take(20) + .each { |featur

rails new してから steep check が通るまでにやってみた作業をまとめておく。 GitHub コードはGitHubで公開しているので、詳細な手順を知りたい方は参照してください。 github.com 手順 gemを入れる steepとrbs_railsをGemfileに追加する。 # Gemfile group :development do gem 'rbs_rails', require: false gem 'steep', require: false end bundle install を実行する。 $ bundle install rbs_rails のREADMEの手順に従って lib/tasks/rbs.rake を作成する。 # lib/tasks/rbs.rake require 'rbs_rails/rake_task' RbsRails::Rak

突然ですが、あなたはRailsのissueとプルリクがいくつあるかご存知でしょうか？ 2019年10月17日現在、それぞれ issue 384 / PR 803 になります。 多いですよね...。 個人的に、最近このissueを減らすのを少しでも手伝えないものかとissueにコメントしてみたり、パッチを書いたりしてるけど、 なかなか大変なので、コントリビューターの敷居を下げるためにブログ記事を書いてみました。 コントリビュータが増えれば、きっとissueも減るはず！！ Rails への貢献について Railsガイドに丁寧な説明が記載されているので、読んだ事がない方は一読するのをオススメします。 railsguides.jp この記事で紹介すること Rails への貢献方法は色々なものがあります。 新機能の追加 バグの報告 バグを修正するプルリク作成 ドキュメントの追加や修正 ...etc

定期的に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

人に説明するときに記事あると便利なので、開発環境向けのDockerfileとdocker-compose.ymlを書いておく。 Dockerfile FROM ruby:3.0.0 WORKDIR /app # Using Node.js v14.x(LTS) RUN curl -fsSL https://deb.nodesource.com/setup_14.x | bash - # Add packages RUN apt-get update && apt-get install -y \ git \ nodejs \ vim # Add yarnpkg for assets:precompile RUN npm install -g yarn # Add Chrome RUN curl -sO https://dl.google.com/linux/direct/google-ch

ECSを触っていて今まで難しいと思ったことを雑にまとめておく。 ECSを仕事で運用するときに必要な知識が多すぎる。こんなの社内に1人AWSマスターいないと無理だ...— 神速 (@sinsoku_listy) 2021年8月10日 タスクロールとタスク実行ロールの違い ECSを長く触っているのに、いつも混乱する。 タスクロール コンテナ内の権限 S3やSESなどの権限をつける タスク実行ロール コンテナ外の権限 ECRやParameter Storeの権限をつける ECSのデプロイ時に静的ファイルが404になる ECSを触った初期に遭遇した。 詳細は以下のQiitaの記事が分かりやすい。 参照: ECSのデプロイ時に一定確率で静的ファイルが404になる問題を回避する 回避する方法はいくつかある。 静的ファイルをS3に置く CodeDeployの OneAtATime を使う CodeDep

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