はじめに Rubyは毎年12月25日にアップデートされます。 Ruby 3.3は2023年12月25日に正式リリースされました。 この記事ではRuby 3.3で導入された変更点や新機能について、サンプルコード付きでできるだけわかりやすく紹介していきます。 ただし、すべての変更点を網羅しているわけではありません。個人的に「Railsアプリケーションの開発時に役立ちそうだな」と思った内容をピックアップしています。本記事で紹介していない変更点も多数ありますので、以下のような情報源もぜひチェックしてみてください。 動作確認したRubyのバージョン 本記事は以下の環境で実行した結果を記載しています。 フィードバックお待ちしています 本文の説明内容に間違いや不十分な点があった場合はコメント欄から指摘 or 修正をお願いします🙏 それでは以下が本編です！ 言語仕様の変更→なし Ruby 3.3では言語

注意 この記事の実験は実際の運用を正確に反映していない恐れがあります（コメント欄の @hmatsu47 さんの投稿を参照）。 実務のアプリケーションでは異なる結果になる可能性もあるので、本記事の内容はあまり鵜呑みにせず参考程度に留めておいてください。 ※「実務に近い環境で実験してみた」という投稿もお待ちしています！ はじめに データベース（この記事ではPostgreSQLを対象とします）の主キーは1,2,3のような連番の整数値を主キーにするSERIALと、"00009236-b73c-4338-8ebd-e1f6c4f4fdd8"のようなランダムな文字列を主キーにするUUIDがあります。 それぞれメリットとデメリットがありますが、パフォーマンスについてはどうでしょうか？なんとなくSERIALの方がシンプルなぶん、速そうなイメージがありますが、実際はどうなのか調べてみました。 実行環境 Ma

Ruby on Rails Advent Calendar 2021の枠が空いていたので、あとから登録しました はじめに 個人的なプロジェクトになりますが、僕が翻訳しているRSpecの入門書「Everyday Rails - RSpecによるRailsテスト入門」を2022年前半にRails 7.0バージョンにアップデートしようと考えています。 そこでこの本の中で使っているサンプルアプリケーションをRails 7.0でゼロから作り直してみました。フロントエンド周りを中心に結構考え方が変わっている部分があったので、「ここでハマった！」とか「こういうポイントを押さえておくといいかも」という点をあれこれ書いてみます。 なお、Rails 7.0版のサンプルアプリケーションはまだ公開できる状態ではないので、公開はもうしばらくお待ちください🙏 今回作成したサンプルアプリケーションはこちらで公開してい

はじめに これはQiitaで開催されている「新人プログラマ応援 - みんなで新人を育てよう！」イベントの投稿記事です。 前回は「学習用のプログラムと仕事で書くプログラムは何が違うか」というタイトルで、お勉強用に作るプログラムと仕事で書くプログラムはこんなところが違うんだよ〜、というお話を書いてみました。 今回の記事ではみなさんが無事にプログラマとして就職できたと仮定して、「○○さん、このタスクお願いね」と開発タスクをアサインされたときの対応手順を説明してみます。 この記事を書いている人 仕事で20年近くプログラムを書いているプログラマ 現在は株式会社ソニックガーデンでRubyプログラマをやっている Rubyの入門書「プロを目指す人のためのRuby入門」を出版している プログラミングスクール「フィヨルドブートキャンプ」のメンターでもある 対象読者 新卒、または業界未経験の中途入社で最近プログ

はじめに これはQiitaで開催されている「新人プログラマ応援 - みんなで新人を育てよう！」イベントの投稿記事です。 今回は「先輩（ベテランから2年目社員、上級生）からのアドバイス」を書いてみようと思います。 この記事を書いている人 仕事で20年近くプログラムを書いているプログラマ 現在は株式会社ソニックガーデンでRubyプログラマをやっている Rubyの入門書「プロを目指す人のためのRuby入門」を出版している プログラミングスクール「フィヨルドブートキャンプ」のメンターでもある 対象読者 現在プログラミングを学んでいて、将来プログラマ（特にWeb系）として就職したいと考えている人 もしくはこの春から新人プログラマとして仕事でコードを書き始める人 いずれも業界未経験の初心者プログラマを想定 僕が普段Railsを使っているため、この記事ではRailsを使う開発の現場を想定していますが、大

Rubyで型チェック！動かして理解するRBS入門 〜サンプルコードでわかる！Ruby 3.0の主な新機能と変更点 Part 1〜RubyrbsSteepTypeProf はじめに Ruby 3.0ではRubyのコードに型定義情報を提供するRBSという仕組みが導入されます。 この記事では簡単なサンプルプログラムを通して、RBSとその周辺ツールの使い方や役割を説明します。 なお、説明する内容はあくまで初歩的な内容です。予めご了承ください。 動作確認時の実行環境 本記事の執筆時点ではまだRuby 3.0は正式にリリースされていません。 正式リリース時、または今後のバージョンアップによってこの記事の内容と実際の挙動が異なる可能性もあります。 本記事の執筆時に使用した実行環境は以下のとおりです。 Ruby 3.0.0dev (2020-11-13T16:46:08Z master 782621054

はじめに Webアプリケーションの開発時やテスト時にはテスト用のユーザーを作成するために適当なメールアドレスとパスワードを登録することが多いと思います。 このとき、みなさんはこんなふうにデタラメなドメインをメアドに使ってないでしょうか？ 「こんなデタラメなドメイン、あるわけないやろ！」と思うかもしれませんが、自分はデタラメに付けたつもりでも意外とかなりの高確率でそのドメインは実在します。 実際、上の例で挙げたドメインをブラウザに入力すると、いずれも何かしらページが表示されます。 つまり、そのドメインは現在誰かが使っているということがわかります。 https://hoge.com/ http://testmail.com/ https://www.bbb.org (bbb.com から転送される) 実在するドメインだと何が困るの？ 何らかの間違いでその実在するドメインに向けてメールが送信され

warning: URI.escape is obsolete warning: URI.encode is obsolete この警告の直し方を見ていきましょう！ 歴史について少しだけ Ruby 2.7.0ではURI.escapeまたはエイリアスメソッドのURI.encodeを呼びだしたときに警告が出ます。これはあたかも新しく追加された警告のように見えますが、実際はなんと・・・10年以上も非推奨とされ続けていたのです！どうしても今までこの警告を目にしなかったんだろう？と不思議に思っている方へ。答えはこうです。これまではverboseモードでスクリプトを実行したときだけ表示されていました。そして、この仕様が最近変わりました。これがその理由です。 じゃあなんでURI.escapeは非推奨メソッドなの？ 「URIをエスケープする」という概念は実はやっかいです。なぜならURIは多数の要素（pat

「よいサンプルコード」ってどんなサンプルコード？ 〜Qiitaや技術ブログを書くときに気を付けること〜QiitaRuby はじめに Qiitaやブログに技術記事を書く場合は多かれ少なかれ、サンプルコードを書くと思います。 たかがサンプルコード、されどサンプルコード。 技術記事に書くサンプルコードはどうあるべきなのでしょうか？ いろいろな観点があると思いますが、この記事では僕が考える「よいサンプルコード」について語ってみようと思います。 なお、この記事のサンプルコードはRubyで書いていますが、記事の内容自体はRubyに限らずどんな言語にも適用できるものです。 どういったサンプルコードが理想的なのか（大雑把なレベルで） 細かいポイントの説明に入る前に、大雑把なレベルで理想的なサンプルコードについて確認しておきましょう。 以下は僕が考える理想的なサンプルコードです。 読み手（＝見知らぬ第三者）

はじめに Railsアプリケーションを長く運用していると避けて通れないのがRailsのバージョンアップです。 古いバージョンのRailsは順次サポートの対象から外れていく（＝不具合修正やセキュリティ対応がされなくなる）ため、バージョンアップをせずに運用するわけにはいきません。 そこでこの記事では僕・伊藤淳一がRailsアプリのバージョンをアップグレード（アップデート）する手順を紹介します。 この手順はこれまで何度もRailsアプリケーションをアップグレードしてきた僕の知見が詰まった、いわば「秘伝のタレ」的なアップグレード手順です。 想定するRailsアプリケーション この記事で想定しているのは以下のようなRailsアプリケーションです。 開発者1人でもなんとか面倒が見れるレベルの規模（＝アップグレードは1人で作業する想定） 趣味で作っているのではなく、外部のユーザーがいるRailsアプリ（

はじめに 僕は「プロを目指す人のためのRuby入門」（通称チェリー本）というRubyの入門書の著者です。 本書は発売以来、非常に多くのみなさんに読んでいただき、筆者として大変喜んでいます。 しかし、その一方でQiitaを見ていると、「これ、明らかにチェリー本の説明文やサンプルコードを参考にして書いてますよね？」という記事をよく見かけます。 中にはきちんとマナーを守って記事を公開されている方もおられますが、残念なことに僕から見て「悪意がないのはわかるけど、そのスタイルで公開されるのはちょっと困る」と感じるケースがかなり多いです。 この記事では、書籍やネット上の情報を参考にしてQiitaに記事を公開する際の最低限のマナーについて説明します。 また、この記事の内容はQiitaのみならず、自分のブログに記事を書くときにも意識すべき内容になります。 備考：「そもそもこの記事ってガイドライン違反じゃな

はじめに Rubyは毎年12月25日にアップデートされます。 Ruby 2.6については2018年12月6日にrc1がリリースされました。 Ruby 2.6.0-rc1 Released この記事ではRuby 2.6で導入される変更点や新機能について、サンプルコード付きでできるだけわかりやすく紹介していきます。 2018.12.26追記: 内容を一部更新しました 2018年12月23日と、Ruby 2.6.0リリース後の2018年12月26日にそれぞれ内容を一部更新しました。 具体的な変更点は以下のdiffをご覧ください。 2018年12月23日の変更点 2018年12月26日の変更点 本記事の情報源 本記事は以下のような情報源をベースにして、記事を執筆しています。 Ruby 2.6.0のリリースノート Ruby 2.6.0のNEWS リリースノートやNEWSに記載されている各種issue

ただし、後置ifが使えるからといって、無理に普通のif文を後置ifに書き直す必要はありません。 むしろ、後置ifを使うとかえって読みづらくなるケースもあります。 後置ifが不向きなケース たとえば、あなたがコードレビューをしているとき、こんな（物騒な）コードを見かけたらどう思いますか？ 「おいおい、頭大丈夫？」と思うようなコードですが、実はこのコードは後置ifで書かれていました。 （ユーザがゾンビだった場合のみ、メッセージを返すメソッドだった！） 後置ifを読むときは条件文があとにやって来ます。 コードが横に長いと条件文がぱっと目に入らないため、「えっ、なんでこのタイミングでこんな処理が入るの！？」と読み手を困惑させる原因になります。 こういったケースでは普通のif文で書いた方が可読性が高くなります。 def message_to(user) # 普通のif文で書けば、特定の条件のみメッセ

はじめに 「テストコードを書きましょう」とはよく言われるし、テストコードが大事だってことも理解できるんだけど、何をテストしたらいいの？どんなテストを書いたらいいの？と迷っている初心者プログラマさんは意外と多いのではないでしょうか？ そんな方たちに向けて、この記事では僕が普段意識しているテストコードの方針を紹介します。 おことわり 本来であれば具体的なコード例も豊富に入れたいところなのですが、かなり時間がかかってしまうので、いったん文章メインで記事を公開します。 もしかすると、そのうちコード例も一緒に盛り込んだ「リッチバージョン」を公開するかもしれません。 この記事の前提条件 この記事ではあくまで、「今現在、筆者が仕事で書いているテストコードの方針」です。 そのため、状況が異なると適用しづらい方針も出てくるかもしれません。 筆者は以下のような現場でコードを書いています。 月額定額で、お客様と

はじめに 先日、RSpec 3.7がリリースされました。 参考: RSpec 3.7 has been released! 上記ブログの中で「今回のリリースはRailsのSystem Testの統合機能をいち早く使ってもらうためのリリースだ」と書いてあります。 実際、ブログの中で触れられている新機能は「System Spec」機能の追加だけです。 というわけで、この記事はrspec-rails 3.7で導入されたSystem Specの紹介と使い方の説明をしていきます。 実行環境 この記事は以下のバージョンを対象にして書かれています。 rspec-rails 3.7.1 Rails 5.1.4 Ruby 2.4.2 selenium-webdriver 3.6.0 Capybara 2.15.4 Chrome 62 ChromeDriver 2.33 サンプルコード この記事で使用したコー

はじめに 先日、Redditでこんな記事が載っていました。 AMA: The authors of "Effective Testing with RSpec 3", Myron Marston and Ian Dees : ruby この記事は書籍「Effective Testing with RSpec 3」の筆者であるMyron Marston氏とIan Dees氏が、書籍に関する質問に何でも答えます、という企画です。 この2人のうち、Myron Marston氏はRSpecの開発者（リードメンテナ）です。 Q&Aを読んでいると、RSpecの開発者ならではの意見だなと思うところがたくさんあり、なかなか興味深い議論になっていました。 というわけで、この記事では先ほどのQ&Aから「これは日本のRubyプログラマにも役立ちそう」と思ったやりとりをピックアップして翻訳してみます。 ピックアッ

はじめに Rubyは毎年12月25日にアップデートされます。 今年はまだpreview版がリリースされていませんが（2017年10月10日時点）、今年もそろそろリリースの日が近づいてきました。 Ruby 2.5については2017年10月10日にpreview1がリリースされました。 Ruby 2.5.0-preview1 Released そこでこの記事ではこの2.5.0-preview1を参考にして、おそらくこんな感じでリリースされるであろうRuby 2.5の新機能や変更点をまとめてみました。 2017.12.25追記: Part 2もあります！ この記事を公開したあとにも多数新機能が追加されました。この記事に追記すると長くなってしまうので、Part 2として公開しています。こちらもあわせてご覧ください。 サンプルコードでわかる！Ruby 2.5の主な新機能と変更点 Part 2 - Q

【アンチパターン】Arrange、Act、Assert（AAA）を意識できていないRSpecのコード例とその対処法RubyRailsRSpec # トレーニングジムの予約システムを開発していると仮定してください describe 'キャンセル処理' do let(:user) { create :user } let(:reservation) { create :reservation, user: user, start_at: '2017-08-10 10:00'.in_time_zone } context '24時間前をすぎるとキャンセル料が発生する' do before do travel_to '2017-08-09 10:00'.in_time_zone reservation.cancel! end after { travel_back } let(:billing)

はじめに 先日参加したRails Developers Meetupの中で、「コミットの粒度がわからない問題」が少し話題になっていました。 「commitの粒度がわからない」すいません、私もです…！よく迷っちゃいます…！！！ #railsdm — まえとー (@maetoo11) July 20, 2017 commitの粒度がわからない問題、ある。（ほんとわからない） #railsdm — おおた (@ota42y) July 20, 2017 普段僕は感覚的に「それっ、ここでコミット！」とコミットしているんですが、具体的にどういうルールでやってるの？と聞かれると、きれいに明文化しづらいものです。 とはいえ、できるだけ明文化できるよう、模範解答を考えてみました。 この記事ではそんな「適切なコミット粒度」について解説します。 動画で明文化・・・！？ すいません、「明文化した模範解答」という

はじめに：コードを良くするためなら遠慮は不要 昨日Twitterに投稿した内容が思った以上に拡散されていたので、タイムラインに流れてしまわないようにQiitaにも書いておきます。 内容は上に書いてあるとおりです。 コードレビューはコードの問題点を指摘し、そのコードを良くすることが第一の目的です。 そのため、少しでもおかしいと思った部分は遠慮せずにどんどんツッコむ必要があります。 しかし、レビューする側が「これ、自分もあまりできてないんだよなあ」「お前もできてないじゃん！って言われたら返す言葉もないし・・・」などと思って遠慮してしまうと、コードを改善できるせっかくのチャンスが失われてしまいます。 「自分ができているかどうか」と「そのコードを改善すること」は、それぞれ別の問題です。 なので、レビューする人は自分のことを棚に上げてでも、コードの問題点を指摘する必要があります。 また、レビューされ