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

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

どうしても syslog に特定の文字列があったら即時通知したかったので Logstash Output Plugin を自作した

# 概要

SNMP Trap を送信できず、syslog でなら目的のログは送信できるが、緊急性の高い syslog が出た場合、どうしてもなるべくリアルタイムに Slack 通知したい、という稀によくある自体に遭遇したので、ログ収集に使っている Logstash を拡張して、特定の文字列があったら Slack 通知する Output Plugin を自作した。

# 構成の概要

現在、各ネットワーク機器は集約サーバを通すことで SNMP メトリック、syslog を収集している。

![無題のプレゼンテーション.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/88428/243e8e2e-0b9d-da14-5cb1-0af8738a250d.jpeg)

![無題のプレゼンテーション (1).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/88428/8fc29fed-11a8-f6a5-2a16-d046

元記事を表示

モジュール結合度をrubyで理解する

# はじめに
(この記事はProgaku Advent Calendar 2023 17日目の記事です。)

こんにちは!
普段は東京都でバックエンドエンジニアをしているおっちーと言います!
最近、業務でコードレビューをする機会が増えてきました。
そこで、今回はコードレビューの観点として含めると有用な「モジュール結合度」について、rubyによるサンプルコードとともに説明させて頂こうと思います!

# モジュール結合度とは
モジュール結合度とは、モジュール間の関連性の強さを示すもので、一般的にソフトウェアの設計において、モジュール間の結合度が可能な限り低いほうが良いとされています。
結合度は、次の7つの種類があります。上から順番に結合度が強いです。

– [内容結合](#内容結合)
– [共通結合](#共通結合)
– [外部結合](#外部結合)
– [制御結合](#制御結合)
– [スタンプ結合](#スタンプ結合)
– [データ結合](#データ結合)
– [メッセージ結合](#メッセージ結合)

**実務でよく見かけるのは、[内容結合](#内容結合)と[共通結合](#共通結合)以外の結合

元記事を表示

Railsのエラー解消

プログラミングはエラー分との戦いです
ただエラー文はHELP(手助け)してくれるものです。
エラーが出てガッカリしず、成長できるものとして捉えましょう!

### 目的
– デバック方法を理解
– 仮説と検証の習慣

webアプリの開発中は、エラーが頻繁に起きます。
エラー解決を重ねることで、Railsの全体像や仕組みの理解が深まります

「No methodError in Tweets#index」
「定義されていないメソッドが呼び出された」というエラーが、
Tweetsコントローラーのindexアクションが実行されたタイミングで
生じたことを表すエラー内容がわかったので、解決の仮説をたて修正し、検証します。
仮説が建てられない場合は、その他の情報を加味しながら仮説をたて、
検証を行うくり返の作業になります

#### デバック
プログラミングの間違い(バグ)を見つけて、手直しすること
#### pry-rails
Gem
デバックツールに属し、作業の際にバグの有無を確認したり、処理を止めてソースコードを正しいかを確認できるものです。
`binding.pry`という記述をソース

元記事を表示

Rails APIとReactを使用したウェブサイトのXSSとCSPの対策について

### はじめに
Ruby on Rails APIとReactを使用したウェブアプリケーションのセキュリティ設計について、
特にXSS(クロスサイトスクリプティング)とCSP(コンテンツセキュリティポリシー)に焦点を当ててまとめました。

## XSS(クロスサイトスクリプティング)
XSSは、ウェブページに不正なスクリプトが注入され、エンドユーザーのブラウザ上で実行されるセキュリティ攻撃です。
これにより、ユーザーのセッション情報の盗用やマルウェアの配布などが発生するリスクがあります。

### Railsにおける対策
**JSONレスポンスのサニタイズ** :
– JSON形式でデータを返す場合は、適切にエスケープ処理を行います。

**パラメータの検証** :
– 入力されたデータを適切に検証し、不正な入力を防ぎます。
**Strong Parameters** の使用: 不要なパラメータをフィルタリングします。

### Reactでの対策
**データバインディング**:
– ReactはデフォルトでHTMLをエスケープしますが、dangerouslySetInnerH

元記事を表示

投稿機能の検索機能の実装

検索機能は必須機能ではないですがあると便利ですね!
テックキャンプの備忘録です!

### 目的
– ルーティングのcollectionとmemberを理解
– 検索に必要なメソッドを理解

### seachアクションのルーティング設定
#### collectionとmember
ルーティングを設定する際に使用でき、生成されるルーティングのURLと実行されるコントローラを任意でカスタムできる
ルーティングに`:id`がつくかつかないかの違い
config/routes.rb
“`ruby
Rails.application.routes.draw do
devise_for :users
root to: ‘tweets#index’
resources :tweets do
resources :comments, only: :create
collection do
get ‘search’
end
end
resources :users, only: :show
end
“`

### 検索フォーム作成
app

元記事を表示

jbuilderでJSONを生成する

# はじめに

jbuilder は、Ruby on Rails で JSON を生成するための Gem です。
この記事では、jbuilder の基本的な使い方をまとめてみました。

# 環境設定

### Gem のインストール

Gemfile に jbuilder を追加するために、以下の行を追記します。

“`ruby:Gemfile
gem ‘jbuilder’
“`

その後、以下のコマンドを実行して、Gem をインストールします。

“`bash
bundle install
“`

# 使い方

### controller ファイルの設定

コントローラーで、JSON 形式でデータを返すように設定します。
例えば、[respond_to](https://railsdoc.com/page/respond_to)メソッドを使用して、JSON 形式のレスポンスを許可することができます。

“`ruby:app/controllers/UsersController.rb
class UsersController < ApplicationContro

元記事を表示

Ruby on Railsにおける秘匿データの扱い:メリット、デメリット、および管理方法

#### 秘匿データとは?
Railsアプリケーションでは、APIキー、データベースのパスワードなど、外部に漏れるとセキュリティ上のリスクが高まる情報を「秘匿データ」と呼びます。これらは通常、ソースコードとは別に安全に管理する必要があります。

#### 管理方法の選択肢
1. **環境変数 (ENV)**
2. **Rails Credentials**

## 環境変数 (ENV)
– **メリット:**
– 簡単に設定でき、多くのホスティングサービスがサポート。
– ローカルと本番環境で異なる値を設定しやすい。

– **デメリット:**
– 環境によって設定方法が異なる可能性がある。
– アプリケーションが多くなると管理が煩雑に。

## Rails Credentials
– **メリット:**
– ファイル内にすべての秘匿情報を集約できる。
– 暗号化されているため、安全性が高い。

– **デメリット:**
– `master.key` の管理が必要であり、これが漏れるとセキュリティリスクに。
– 初期設定が環境変数よりも複雑。

## ど

元記事を表示

DockerでRails7.1.2×PostgreSQLの環境構築

# はじめに
今回は初めてDockerを使って環境構築してみたので、そのまとめを残していきたいと思います。

https://github.com/docker/awesome-compose/tree/master/official-documentation-samples/rails

こちらのリポジトリを参考に
– Ruby: 3.3.0
– Rails: 7.1.2
– wsl2
– Docker Desktopインストール済み
– composeでsecretsを使う

で環境構築しました。

# 環境構築のステップ
まずはファイルを6つ用意します。
– Dockerfile.dev
– compose.yaml
– Gemfile
– Gemfile.lock
– entrypoint.sh
– db_password

それぞれ中身を見ていきましょう。
まずは`Dockerfile.dev`から、名前はなんでもいいのですが、Rails7.1以降の仕様から.devをつけています。
“`Dockerfile:Dockerfile.dev
# syntax=docker/d

元記事を表示

`gem install middleman` を実行するとエラー 「ERROR: Failed to build gem native extension.」

# TL;DR

`sudo apt install build-essential` で解決した。

# 環境

* Ubuntu 22.04
* Ruby 3.0.2p107 (Ubuntu 22.04 標準)

# 発生した事象

`sudo gem install middleman` を実行したところ、エラーが発生した。

“`console
$ sudo gem install middleman
Fetching backports-3.24.1.gem
Fetching addressable-2.8.6.gem
Fetching activesupport-7.0.8.gem
Building native extensions. This could take a while…
ERROR: Error installing middleman:
ERROR: Failed to build gem native extension.

current directory: /var/lib/gems/3.0.0/gems/ffi-1.16.3/e

元記事を表示

なんでmodelで定義してるUserクラスをcontrollerで使えるの?

動機

Railsチュートリアル7章まで進めて、ふとこの疑問が湧き上がりました。
Rubyの基本的な文法を学習した段階では、

  • 原則同じファイル内で定義したクラスしか使えない
  • 外部のファイルのクラスを使う場合はrequireで読み込む必要がある
  • クラスの継承を使えば、親クラスのメソッドも使用できる

という理解だったのですが、railsチュートリアルのsample_appのusers_controller.rbのコードを見ると

  • ファイル内にUserクラスの定義がない
  • にもかかわらず@user = User.find(params[:id])みたいな感じでUserクラスを使ってる
  • requireで外部ファイルを読み込んでる、もしくはクラスを継承している様子もない

みたいな感じでなぜUserクラスが使えているのか理解できなかったので調べてみました。

<

元記事を表示

Rubyのバージョンが勝手に元に戻る現象を解消する

# はじめに

:::note info
本記事は、下記記事内「バージョンが変わらない場合」を実施しても解消されない方向けです。
:::

https://qiita.com/Ficus/items/bdef5c2b504d7a4008fb

# 現状
mac購入時からデフォルトでインストールされているRubyのバージョンを最新版に更新。
しかし、ターミナルを開き直すとバージョンが更新前に戻る。
“`
Last login: Tue Jan 2 00:14:52 on ttys000
% ruby -v
ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin22]
“`

# 目標
ターミナルを開き直しても、更新後のバージョンが認識されること。

# 対象
mac購入後、初めてローカルのRubyを触る方向け。

# 結論
ターミナルがzshの場合、`.zshrc`ファイルをいじる必要があった。
(上記記事ではターミナルがbashだから成功している)

zshとbash?何それ美味しいの?と

元記事を表示

Rubyの「後置if」をElixirマクロで実装する

この記事は、[Elixir Advent Calendar 2023 シリーズ13](https://qiita.com/advent-calendar/2023/elixir) の13日目です

[piacere](https://twitter.com/piacere_ex) です、ご覧いただいてありがとございます :bow:

Rubyは、下記のように「後置 `if`」が書けます

“`diff_ruby:実行
irb> name = “hoge”
irb> id = :id001
irb> name = “piacere” if id == :id001
irb> name
“piacere”

irb> id = :id002
irb> name = “piacere” if id == :id001
irb> name
nil
“`

これをElixirでも追加してみます

なお、こうしたDSL(Domain Specific Language:ドメイン固有言語)は、マクロを使って実装するのが通例なので、[**書籍「プログラミングElixir」**](http

元記事を表示

Rubyのインストール方法(MacOS編)

# 実際の環境
以下の環境で実際に環境構築をしてインストールができていることを確認しました。
“`shell
macOS Sonoma 14.0
zsh 5.9 (x86_64-apple-darwin23.0)
homebrew 4.2.1
“`

macOSではOS標準のrubyがすでにインストールされていることがほとんどです。これは以下のコマンドで確認できます。

“`shell
ruby -v
“`

しかし、macOS標準のrubyでは以下のような問題が発生してしまいます。

– versionの変更が難しい
– 最新のversionにupdateできない
– 外部ライブラリのインストールでトラブルが起きる

そこで今回はversionのコントロールがしやすいrubyをhomebrew経由でインストールしたいと思います。homebrewはすでにインストールされていることを想定します。

# 1. rbenvのインストール
rbenvとはrubyのversion管理ツールです。これを用いることで、1つのパソコンで複数のrubyのversionを扱うことができます。実際

元記事を表示

ReactとRailsアプリケーションにおける環境変数を無理やり共通化したかった

### 背景
この記事では、Reactをフロントエンドとして、Railsをバックエンドとして使用するアプリケーションの例を取り上げ、両者間での環境変数の共有方法について説明します。

## 問題の概要
ReactとRailsの両方で使用する環境変数がある場合、例えばAPIのエンドポイントやOAuthのクライアントIDなどがある場合に、これらの環境変数の管理が同期的である方が好ましいよな?(個人的な意見)と思いました。

## 考えた解決策
バックエンド(Rails)の .env ファイルから環境変数を読み取り、
それをフロントエンド(React)用の .env ファイルに転送するシェルスクリプトの作成。
この方法により、環境変数の一元管理が可能になりそうだと思った。

スクリプトの実装
“` shell
# バックエンドの .env ファイルのパス
BACKEND_ENV_PATH=”./backend/.env”

# フロントエンドの .env ファイルのパス
FRONTEND_ENV_PATH=”./frontend/.env”

# フロントエンドの .env ファイルをクリ

元記事を表示

public, private, protected

# それぞれの違い
## Public
Publicメソッドは、クラスの外部から自由にアクセス可能です。
これらはクラスのインターフェースを形成し、外部のコードから利用されることを意図しています。
Rubyでは、クラスで定義されたメソッドはデフォルトでpublicです(ただし、initializeメソッドは例外で、常にprivate)。

## Private
Privateメソッドは、そのクラスのインスタンスからのみアクセスできます。
これらのメソッドは、外部のクラスやサブクラスからは直接呼び出すことができません。
Privateメソッドは、レシーバを指定せずに呼び出す必要があります。つまり、selfを明示的に使用してはいけません。
これは、クラスの内部実装の詳細を隠蔽し、外部からの不要な干渉を防ぐために使用されます。

## Protected
Protectedメソッドは、同じクラスまたはサブクラスのインスタンスからアクセスできます。
これらは、外部のクラスからは直接アクセスできませんが、同じクラスまたはサブクラス内の他のインスタンスからはアクセス可能です。
Protectedメ

元記事を表示

依存関係逆転の原則

依存関係逆転の原則(Dependency Inversion Principle、DIP)は、ソフトウェア設計の原則の一つ。高レベルモジュールが低レベルモジュールに直接依存しないように設計することを意味する。代わりに、両方が抽象化に依存する。これにより、モジュール間の結合が緩やかになり、保守性や拡張性が向上する。

“`ruby:依存関係逆転の原則を使用していない
class EmailService
def send_email(user_email)
# 電子メール送信の実装
end
end

class UserAuthentication
def initialize(user_email)
@user_email = user_email
@email_service = EmailService.new
end

def authenticate
# 認証ロジック
email_service.send_email(@user_email)
end
end
“`

“`ruby:依存関係逆転の原則を使用
#

元記事を表示

インターフェイス分離の原則

インターフェイス分離の原則(Interface Segregation Principle, ISP)は、ソフトウェア設計の原則の一つで、SOLID原則の一部である。この原則は、「クライアントは使用しないメソッドに依存するべきではない」という考え方に基づいている。つまり、大きくて汎用的なインターフェイスよりも、小さくて特定のクライアントに特化したインターフェイスを設計するべきであるという原則です。

“`ruby:違反している
class DocumentGenerator
def generate_pdf
# PDFドキュメント生成のロジック
end

def generate_word
# Wordドキュメント生成のロジック
end

# 他のドキュメントタイプの生成メソッドもここに含まれる
end

“`
違反理由
DocumentGeneratorクラスにgenerate_pdfとgenerate_word というメソッドが両方とも含まれている場合、特定のレポート(例えばPDFレポート)にのみ関心があるクライアントが Report クラス

元記事を表示

リスコフの置換原則

# リスコフの置換原則とは?
リスコフの置換原則(Liskov Substitution Principle, LSP)は、オブジェクト指向プログラミングにおける重要な原則の一つで、サブクラスはいつでもそのスーパークラスの代わりとして使用できるべきであるという規範のこと。これは、サブクラスがスーパークラスの契約を変更しないようにすることを意味する。

“`ruby:リスコフの置換原則を使用した例
# 基底クラスの作成
class Payment
# このメソッドはすべての支払い方法で共通です。
# 各支払い方法はこのメソッドを実装する必要があります。
def process
raise NotImplementedError, “process method must be implemented”
end
end

# サブクラスの作成
class CreditCardPayment < Payment def process # クレジットカードでの支払い処理のロジック "Processing credit card payment..

元記事を表示

オープン・クローズドの原則

# 概要
オープン・クローズドの原則の定義は「拡張に対して開かれているべきであり、変更に対しては閉じているべき」と、よくそのように言われます。

しかし、一見すると主語が書いてないので、拡張も変更も同じ主語を持つとした場合、矛盾してしまいます。

これは厳密にいうと、既存のコードの変更に対しては閉じているべき(=変更せずにいられるべき)で、拡張に対して開かれているべき(=新機能の追加をしやすくあるべき)である。つまり、既存のコードを変更せずに、新しい機能を追加できるような設計が望ましいということです。

# つまり、どういうことだってばよ?
## ダックタイピングで実装した例
“`ruby:オープン・クローズドの原則に違反した実装(変更に閉じていない)
class PaymentProcessor
def process_payment(payment_type, amount)
case payment_type
when :credit_card
# クレジットカードでの支払い処理
when :paypal
# PayPalでの

元記事を表示

単一責任の原則

# 1. 序論
## 単一責任の原則とは?
Wikipediaによると
> 単一責任の原則 (たんいつせきにんのげんそく、英: single-responsibility principle) は、プログラミングに関する原則であり、モジュール、クラスまたは関数は、単一の機能について責任を持ち、その機能をカプセル化するべきであるという原則である。モジュール、クラスまたは関数が提供するサービスは、その責任と一致している必要がある。

単一責任の原則の説明としてよく用いられる例が十徳ナイフなので、十徳ナイフを用いて単一責任の原則の説明を行う。

十徳ナイフ
![166003020_2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/270132/298d5f48-d910-20c3-3c7d-2da83d89b37f.jpeg)

十徳ナイフはナイフに缶切り、マイナスドライバーに栓抜きと、多機能に展開されている。これをソフトウェア設計の視点で見ると、十徳ナイフという1つのオブジェクトに対して責任(=役割)が複

元記事を表示

OTHERカテゴリの最新記事