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

はじめに 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

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

はじめに 1週間ほど前、内閣府の「国民の祝日」CSVがひどい、みたいな話が話題になっていました。 参考： 【悲報】内閣府の「国民の祝日」CSVがひどいと話題に なぜ「ひどい」と言われていたのかというと、普通のプログラマが期待する「日付と名前が上から下に並ぶCSV」ではなく、「2016年の列 => 2017年の列 => 2018年の列」のように年単位で列方向（横方向）に繰り返すフォーマットになっていたからです。 （しかも一番下に「月日は表示するアプリケーションによって形式が異なる場合があります。」みたいな注意書きが入ってる！） まあ、ひどいと言えばひどいんですが、これを扱いやすいフォーマットに変換するプログラムを作るのはなかなか面白そうだなと思いました。 というわけで、そんなプログラムを作りました！ 国民の祝日.csvをパースするプログラム、とりあえずコードは書いた。https://t.co

はじめに 去る2017年2月23日、Rails 5.1.0.beta1が公開されました。 Rails 5.1.0.beta1: Loving JavaScript, System Tests, Encrypted Secrets, and more - Riding Rails Rails 5.1ではマイナーバージョンアップと言えど、かなり大きな変更点が多数入っているようです。 そこで上記公式ブログの内容を僕なりにまとめてみます。 おことわり この記事は公式ブログやpull requestの内容を読んで、筆者が個人的にまとめたものです。 実際に動かして試したりはしていないので、おかしな内容や誤解している内容が含まれている可能性もあります。 もし、「これは明らかにおかしい！」という内容を見つけた場合は、コメントや編集リクエストで優しく指摘してやってください。 サンプルコードについて この記事

はじめに この記事はByebug（バイバグ）というgemを使ったデバッグ方法を説明するチュートリアル記事です。 JavaやC#のようなコンパイル型の言語ではEclipseやVisual StudioのようなIDEを使って開発することが主流です。 なので、自然とIDEに標準装備されているデバッガを使ってステップ実行したりすることが多いと思います。 一方、RubyではRubyMineのような有料IDEもあるものの、IDEではなくテキストエディタを使って開発している人の方がまだまだ多いと思います。 そうすると、初心者の方はなんとなく「Rubyでデバッガを使ってデバッグするのは無理なのでは？」と考えてしまう人も多いかもしれません。（僕は初心者の頃そう思ってました・・・。） ですが、そんなことはありません！ RubyでもIDEを使わずにターミナル上でデバッガを使ってデバッグすることは可能です。 とい

はじめに 2016年9月にRuby 2.4のpreview2が、11月にpreview3が、12月11日にrc1がリリースされました（参考1、参考2、参考3）。 僕は早速インストールして新機能を試してみましたが、みなさんはいかがでしょうか？ というわけで、この記事では僕が実際に動かして確認したRuby 2.4の変更点や新機能をサンプルコード付きでまとめます。 この記事は大きく分けて次のセクションに分かれています。 文法上の変更点 後方互換性が失われる変更点 パフォーマンス改善 オブジェクト全般の新機能 主に数値に関連する新機能 主に文字列・正規表現に関連する新機能 主に配列・ハッシュに関連する新機能 ディレクトリやファイルに関連する新機能 その他の標準ライブラリに関連する新機能 スレッドに関連する新機能 なお、Ruby 2.4は2016年12月25日にリリースされる予定です。 本記事はrc

はじめに：Arelって何？ みなさん、Arel（アレル）ってご存知ですか？ ArelはActive Recordの内部で使用されるSQL生成ライブラリです。 Railsのクエリの書き方をググると、ときどきArelを使った実装例が見つかるので、見たことがある、もしくは何度か使ったことがある、という人もいると思います。 Arelをよく知らない人のために、Arelの利用例をちょっと見てみましょう。 たとえば「コメント文中に、"ruby"が含まれるユーザープロフィールを検索したい」という場合、Rails標準のクエリインターフェースを使うと条件部分のSQLを文字列で書く必要があります。（PostgreSQL環境を想定） Profile.where( "profiles.comment ILIKE ?", "%ruby%" ).to_sql #=> SELECT "profiles".* # FROM

はじめに Ruby 2.3が2015年12月25日にリリースされました。 そこでこの記事ではRuby 2.3の主な新機能を紹介していきます。 対象となるバージョン 以下のとおり、この記事では ruby 2.3.0 を使っています。 参考文献 今回紹介するサンプルコードは下記のサイトにあったコードをベースにしています。 New features in ruby 2.3 - BlockScore Blog ただし、実行結果を確認するために Minitest を使ったり、コードをいくつか変更したりしています。 サンプルコードはGitHubにあります この記事で使ったサンプルコードはGitHubに置いてあります。 興味のある方は手元で動かしてみてください。 JunichiIto/ruby-2.3-sandbox それではここからRuby 2.3の新機能を紹介していきます。 深い階層にあるハッシュの

はじめに Railsアプリケーションを本格的に作り込んでいくと、「エラー」とは無縁ではいられません。 しょうもないバグでエラーが発生することもありますし、ほとんど不可抗力ともいえるような大規模なネットワーク障害でエラーが発生することもあります。 エラーの種類がなんであれ、エラーが起きた場合は「原因を素早く特定し、速やかに復旧させること」と「あるエラーが引き金になって、さらに大きなエラーに引き起こさないようにすること」が重要です。 エラー処理を適切に実装していれば、原因の特定や復旧もすばやくできますし、さらに大きなエラーを引き起こす可能性も少ないです。 また、ソースコードも比較的シンプルに保てます。 逆にエラー処理が不適切だと原因の特定に時間がかかったり、異常なデータがどんどん増えてさらに大きなエラーを引き起こしたりします。 ソースコードにも無駄に複雑な処理フローや条件分岐がたくさん出てきて

はじめに みなさんこんにちは！ この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入ってこない場合はじっくり本文を読んだり、実際に自分で写経しながらコードを動かしたりするなどして、少し時間をかけながら理解するようにしてください。 今回は以下のような内容を説明します。 モックの基本的な使い方 モックを使った検証 モックでわざとエラーを発生させ

（2021-8-28追記） この記事の改訂版を書いてみました。改訂版の方が易しい内容になっているので、プログラミング初心者の方はこちらを参考にしてみてください。 はじめに：「引数があるよりは、ない方が良い」？ 先日、同僚の西見さん（@mah_lab）がこんな技術ブログを書いていました。 インスタンスメソッドとクラスメソッドはどのようにして使い分けるべきか？（Rubyの場合） 同じ内容を僕だったらどういうふうに書くかな～？と思って、ちょっと書き始めてみたんですが、わかりやすく実践的な説明をするのは意外と難しく、内容も西見さんのブログとほぼ同じになりそうだったので、途中で断念しました。 というわけで、インスタンスメソッドとクラスメソッドの使い分けが未だにあやふやだという方は、ぜひ西見さんのブログを読んでみてください！ ・・・なんですが、1点だけ気になる点がありました。 それはインスタンスメソッ

はじめに 条件分岐はプログラミングの基本です。 しかし、複雑な条件分岐が出てくると非常にコードが読みにくくなります。 さらに、その複雑な条件が unless と組み合わされていたりすると、ぱっと理解するのが非常に困難になります。 そこで、この記事では複雑な unless の条件を攻略する方法を説明します。 質問: "unless person.married? && !person.rich?" が真になるケースは？ ifとunless たとえば以下のコードは「personが結婚していたら'Yo!'と声をかける」コードです。

はじめに 有名な初心者向けのRSpec入門記事として、和田卓人さん(@t_wada)の「RSpec の入門とその一歩先へ」という記事があります。 僕もRSpecを全く知らなかった頃に参考にさせてもらいました。 今読んでもとても素晴らしい資料なのですが、RSpecのバージョンが古く、現状の書き方とマッチしなくなってきているのが少しもったいないところです。 そこで、この記事では和田さんの記事をRSpec 3バージョンに書き直してみようと思います。 各イテレーション(RSpec 3バージョン)へのリンク 第1イテレーション(本記事) 第2イテレーション 第3イテレーション ソースコードのURL https://github.com/JunichiIto/rspec3-for-beginners/tree/end_of_iter1 本記事のライセンスについて 本記事は クリエイティブ・コモンズ 表

はじめに: Vimならではの便利機能をマスターしよう！ かれこれ数年前、僕がVim(というか、たぶんVi)と初対面したときは、「なんて使いにくいエディタなんだ！！」と最悪の印象でした。 しかし、周りのプログラマやネット上のエンジニアたちはみんな「Vim便利！」「Vim最高！」と言います。 なのでその言葉を信じ、僕も最悪の印象だったVimともう一度正面から向き合うことにしました。 そして、月日が過ぎ・・・僕もいつしか「Vim便利！」「Vim最高！」と叫ぶようになってしまいました！！ これって洗脳？ いやいや、洗脳じゃありませんw Vimにはメモ帳の延長線上にあるエディタでは実現できないような数々の便利な機能があります。 覚えるまでにはちょっと苦労しますが、覚えてしまえばメモ帳系のエディタでは追いつけないようなスピードでテキストを編集することができます。 とはいえ、そもそも覚える以前に「そんな

はじめに: 「素のVim」から「プラグイン付きのVim」へ Vimを使い始めた当初、僕は.vimrcの設定だけで実現できる機能に限定した方が「ポータブルなVimスキル」になる気がしていたので、プラグインは全く使わずに「素のVim」を使っていました。 しかし、Vimを使って実務でRailsを開発し始めるとそんなことも言ってられなくなりました。 やはり素のVimだけでは限界があります。 Vimを使って効率よくRailsを開発するためにはプラグインに頼らざるを得ません。 ネットの情報などを参考にしてあれこれプラグインを入れてみましたが、これは手放せないというプラグインもあれば、思ったほど使わなかったというプラグインもあります。 今回の記事では前者のような「これは手放せない！」と僕が考えているプラグインに限定して紹介していきます。 また、後半ではプラグインを使わない.vimrcの一般的な設定につい

はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例: