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

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が渡され、配列の各要素が出力されます。

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

ブロックはメソ

製造メーカーからIT業界を歩いてみて

## イントロダクション
工作機械といった業界をご存知でしょうか？
工作機械とは金属や他の素材を加工して製品を作るための機械装置の総称です。
車のパーツや工具、電化製品などの一部を工作機械によって作られています。

私は前職で工作機械メーカーの電気設計に担当する仕事に携わっていました。
約３年前にITエンジニアとして仕事を変え、Webアプリケーション開発やスマホアプリ開発等の業務に携わっています。

この記事では主に前職の工作機械業界との違いや、生活の変化を私の経験を通して共有していきます。

## 働きやすさ
働きやすさで大きく変化がありました。

今の会社はフルリモートであり、基本的に出社は本人の任意によるところが多いです。
前職は製造メーカーであったので、現場での作業を強いられる為、リモート出社等は出来ませんでした。

リモートワークでは自分の時間をより自由に使えることが嬉しいです。出社時間がないことで、日常生活の様々なことが柔軟に行えるようになりました。また、電話対応や雑務が少ないため、仕事に集中しやすい環境です。

前職の場合、通常の設計作業以外に営業や製造管理、現場、品質保

AlmaLinux9環境にrbenv・ruby3をインストールする

## 環境
* AlmaLinux 9.3
* rbenv 1.2.0-83
* ruby 3.2.2

個人占有の開発環境のため、各アプリのユーザーが共用できるようにシステムワイドにインストールします。rbenv、rubyともにインストール・アップデートなどはrootユーザーで操作する想定です。

## rbenvインストール
“`
# git clone https://github.com/rbenv/rbenv.git /usr/local/rbenv
“`
git cloneで最新のrbenvをインストールします。

“`
# echo ‘export RBENV_ROOT=/usr/local/rbenv
export PATH=”$PATH:$RBENV_ROOT/bin”
eval “$(rbenv init -)”‘ > /etc/profile.d/rbenv.sh
# source /etc/profile
# rbenv –version
> rbenv 1.2.0-83-g325abac
“`
パスを通すなどの必要な処理を記述しますが、全ユーザーに一

【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