Rails関連のことを調べてみた

gem ‘debug’ではスコープ内の変数を優先して参照する

最近プロダクトコードの調査をしていたとき、’debug’ gemについて理解していなくて戸惑ったので残しておこうと思います。

### ことの発端
こんな感じのコードを調査中に見かけました。
同名のローカル変数とプライベートメソッドが定義されています。
レコード取得の条件に大きな違いはなさそうで、なぜメソッドのbarを使わないのか意図が分からずにデバッガを挟みました。
“`ruby
class HogesController < ApplicationController def show # debuggerをここに入れた bar = Bar.where(...) end private def bar @bar ||= Bar.where(...) end end ``` 上記の位置で`bar`を実行すると、プライベートメソッドの値が確認できると期待していたのですが、実際に返ってきたのはnilでした。 ```ruby (rdbg) bar nil (rdbg) self.bar [#

モンキーパッチとは？Rubyモンキーパッチの利点とリスク

## モンキーパッチとは？

モンキーパッチは、プログラミングにおいて既存のコードを変更する技術です。Rubyでは、既存のクラスやモジュールに新しいメソッドを追加したり、既存のメソッドを上書きしたりすることが可能です。これにより、アプリケーションの特定のニーズに合わせてカスタマイズできます。

## モンキーパッチの具体的な利用シナリオ

– 機能の追加: 既存のクラスに足りない機能を追加する。
– バグ修正: ライブラリ内のバグをアプリケーション側で修正する。
– 振る舞いのカスタマイズ: アプリケーション固有の要件に合わせて、既存のメソッドの振る舞いを変更する。

## モンキーパッチの利点

– 柔軟性: 既存のクラスやメソッドをカスタマイズすることで、特定の要件に合わせて振る舞いを調整できます。
– 迅速な開発: 既存のライブラリやフレームワークに手を加えることで、新しい機能を迅速に実装できます。
– 互換性の維持: 古いコードベースを新しいライブラリやフレームワークのバージョンに合わせて修正する際に役立ちます。

## モンキーパッチのリスク

– 保守性の低下: 元のライブ

RubyのBlock、Proc、Lambdaの違い、分かりやすく解説

Rubyは柔軟性と表現力に富んだプログラミング言語であり、その強力な機能の一つに「クロージャ」があります。クロージャとは、その周囲の環境（スコープ）を「閉じ込める」ことができる関数のことです。Rubyにおけるクロージャには主に3つの形式があります：**Block**、**Proc**、および**Lambda**。これらは似ているようでいて、実は重要な違いがあります。この記事では、これらの違いを明確にし、それぞれの使用例を通じて理解を深めます。

## Blockの基本
BlockはRubyで最もよく使われるクロージャの形式です。Blockは `{}` または `do…end` で定義され、メソッド呼び出しに際して、これを引数として渡すことができます。引数を渡すには、`{}`または`do`の後で引数リストを`|`で囲みます。

**例：**

“`ruby
[1, 2, 3].each { |number| puts number }
“`

この例では、each メソッドにBlockが渡され、配列の各要素が出力されます。

### メソッドにブロックを渡す

ブロックはメソ

【Rails】マイページのURL末尾を「ユーザー名」にする

 

Railsを使ったWebアプリの開発中、「マイページのURL末尾を、ユーザーIDじゃなくて＂ユーザー名＂にできたらかっけぇ…」と思い、実際にその機能をつけました。
 

マイページ（ユーザー詳細ページ：users/show.html.erb）のURL末尾をユーザーIDから「ユーザー名」に変更することは、とてつもなく重要です。なぜなら、ユーザー情報を共有する／されるときに、ユーザーを一瞬で識別できるようになるからです。実際、X（旧Twitter）やInstagram、そしてQiita、といった超人気WebサービスのマイページURLの末尾は、自身で設定したユーザー名になっています。
 

しかし、問題点があります。それは「何の追記もないまま（＝リソースフルにしたがったまま）usersのshowアクションをルーティングに設定すると、マイページのURL末尾がユーザーIDになってしまう」という問題です。
 

そこで、「マイページのURL末尾をユーザーIDから＂ユーザー名＂に変更する」ためのRails実装手順をまとめました。
 
&em

デフォルト動作を理解して使ってますか？

この記事は、株式会社ACCESS Advent Calendar 2023 の19日目の記事です。

私個人としては今年はこれ含めてまだ2個しか記事投稿していないことに気づきましたが、去年一昨年が年1個だったのと比べると2倍に増えたとポジティブに捉えることにします。

# はじめに

多くのツールは、設定やパラメーターでその挙動を制御できるとともに、指定しなかった場合のデフォルト動作が存在します。それを理解せずに使うと、思いもしなかった挙動に直面する危険性があります。

私個人やうちのチームが実際に体験した例を（脚色も交えながら）いくつか挙げることで、デフォルト動作を理解して使うことの大切さをこの年末に改めて再認識する機会にしょうと思います。

# 1) RubyのNFKモジュールで半角カナ変換時に文字化け

## やろうとしたこと: 全角カタカナに変換

Rubyで半角カタカナを全角カタカナに変換したいです。
日本語のコード変換というとNKF、という知識から[ドキュメント](https://docs.ruby-lang.org/ja/latest/class/NKF.html)を見る

【Rails】Helper, Decorator, Presenter

# 1. Rails開発のView周りの実装
## 1.1 共通する悩み
Rails開発において、負債が積み重なり、View周りがしんどくなりがちというのはあるあるかと思います。

– Viewのあちらこちらに似たコードを記載しちゃう問題
– Viewに記載したプレゼンテーションロジックが複雑になりすぎちゃう問題
– Modelにプレゼンテーションロジックを記載しちゃう問題
– 上記により、FatModel、FatViewが発生しちゃう問題
– 結局、ModelとViewのどっちに書けばええねん！と板挟みになっちゃう問題

結果、非DRYで可読性に乏しく、責務の曖昧なコードが出来上がります。私も個人開発でたまにやらかします。以下で具体的なコードを交えて説明していきます。

### 1.1.1 Viewのあちらこちらに似たコードを記載しちゃう問題(非DRY)
いわゆるDRYになっていないコードが存在してしまうケースです。複数人開発で、コードの全容を理解していない、習熟度様々なエンジニアが存在することから、気を抜くとどうしても発生してしまうコードになります。

“`erb