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

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

### 目的
– ルーティングの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` の管理が必要であり、これが漏れるとセキュリティリスクに。
– 初期設定が環境変数よりも複雑。

## ど

Rails: JavaScript からコントローラの POST メソッドに対して非同期でリクエストを送信する

一定の時間が経過したら強制的に投稿するフォームを作成する。
questionsコントローラのsubmitメソッドに対し、選択した`choice_id`を送信する。

“`html
<%= form_with(url: submit_questions_path, method: :post) do |form| %>

<%= form.radio_button :choice_id, 1 %>
<%= form.radio_button :choice_id, 2 %>
<%= form.radio_button :choice_id, 3 %>

<%= form.submit '投稿' %>
“`

もちろん、上記のフォームで選択をして投稿ボタンを押せば投稿ができる。
しかし今回は、一定の時間が経ったらjavascriptで強制的に投稿させる。
それをしてくれるjavascriptは以下。
viewにベタ打ちなどして記述する。

“`javascript

var postAfterSeconds = 5;
setTimeout(function()

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

Docker + MySQL + Rails5環境でRailsコンテナが起動できない問題

# 環境
Ruby:2.4.6
Rails:5.2.8
MySQL:5.7

# 対処法
タイトルの通り、以下のコマンドを実行後にRailsコンテナが起動しない(Exit1)事態に陥りました。

“`
docker-compose up -d
“`
ログは次のようになります。
“`
web_1 | /usr/local/bundle/gems/loofah-2.21.1/lib/loofah/html4/document.rb:10:in `‘: uninitialized constant Nokogiri::HTML4 (NameError)
web_1 | Did you mean? Nokogiri::HTML
web_1 | from /usr/local/bundle/gems/loofah-2.21.1/lib/loofah/html4/document.rb:4:in `‘
web_1 | from /usr/local/bundle/gems/loofah-2.21.

【3日目】フロントエンジニアがRailsを習得するまで

# 3章 ほぼ静的なページの作成

—

## railsの省略コマンド

“`
rails server -> rails s
rails console -> rails c
rails generate -> rails g
rails test -> rails t
bundle install -> bundle
“`

—

## `rails g` で作成したものをまとめて削除

`rails g` でmodelやcontrollerの命名を変更したい。
でも `rails g` は複数のファイルに変更を加えるので、修正が面倒。。

そういう時に使うのが `rails destroy` 。
このコマンドによって `rails g` で作成した各種変更を取り消してくれる。

### 1. Controllerを取り消す場合
`rails destroy` コントローラー名`

### 2. Modelを取り消す場合
`rails destroy モデル名`

### 3. migrateしたDBを戻す場合
`rails db:rollback`

#### ~

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

動機

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

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

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

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

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

<

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) は、プログラミングに関する原則であり、モジュール、クラスまたは関数は、単一の機能について責任を持ち、その機能をカプセル化するべきであるという原則である。モジュール、クラスまたは関数が提供するサービスは、その責任と一致している必要がある。

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

十徳ナイフ

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

docker-compose build はやりたくない　rails

## はじめに
今回、ruby on rails を勉強のためdocker上で環境構築して学習しているのですが、

章が変わるごとにgemを追加して、docker-compose buildで2時間近くかかって、全然学習にならなかったので改善できないか調べて取り組んでみました

## 結論
docker-compose のvolumesを使えばできた。

“`diff_yaml
version: ‘3’
services:
web:
volumes:
– .:/app
+ – bundle:/usr/local/bundle
volumes:
+ bundle:
“`

## 概要
* PC : M1 Macbook
m1 Macbookは通常と違う点が多いのでご注意を。

ファイル構造
“`:現在のディレクトリ

rails
├─ Dockerfile
├─ Gemfile
└─ docker-compose.yml

“`

* Dockerfile
* Gemfile
* docker-compose.yml

“`:

Rails環境でRakeタスク作成~テストまで

## モチベーション
Rakeタスクを作成に伴い、どのように利用するかを知ること！

## Rakeタスクって？

> Rake ファイルにおける基本単位です。タスクは名前と、事前タスクと、実行するアクションのリストを持ちます。
>

https://docs.ruby-lang.org/ja/latest/library/rake.html

RakeというRubyで書かれたビルドツール利用される基本単位のことらしいです。

`***.rake` というファイル名でRubyスクリプトを実装し、Rakeタスクとして実行することができます。

## ユースケース

下記のユースケースが考えられます。

– Railsのアプリケーションコードを利用した、一回だけ実施したい処理
– バッチなどの定期実行処理

## 利用方法

`namespace:task_name` の形式で呼び出すことができます。

“`zsh
# 引数なしの呼び出し方
bin/rake ‘test:argument_parse’

# 引数ありの呼び出し方
bin/rake ‘test:argument_pars

CarrierwaveとMiniMagickを使った画像アップロード機能

# Carrierwaveとは

ファイルアップロード用のgem

# MiniMagickとは

画像加工をしてくれるgem
・画像サイズ変更
・画像反転
・画像回転
・画像フォーマット変換
・色調整
・グラデーション

# 導入方法
## 1.gem導入
“`terminal:Gemfile
gem ‘carrierwave’
gem ‘mini_magick’
“`
## 2.アップローダークラス作成
“`terminal
rails g uploader image(アップローダー名)
“`
## 3.マイグレーションファイル作成とカラム追加
もし紐づけるマイグレーションファイルを作成していない場合、作成する
“`terminal
rails g migration add_image_to_posts image:string
rails db:migrate
“`

## 4.モデル編集
画像を保存するmodelにアップローダーを紐づける
postのdbにはファイル名だけが保存される。
“`ruby:post.rb
# 追記
class Post < App

CarrierWaveでアップロードした画像を絶対パスで返す設定

CarrierWaveで画像アップロード機能を実装していたのですが、
レポジトリをバックエンドとフロントエンドで分離していて、バックエンド側に仮で画像を保存したかった際、
バックエンドから返ってくるpathがデフォルトだと相対パスで少しつまづいたので
相対パスの絶対パスにする方法を残しておきます。

# image_uploader.rbの設定
デフォルトだと以下のようになっているかと思います。
これだけだと相対パスが返されます。
“`ruby:image_uploader
def store_dir
“uploads/#{model.class.to_s.underscore}/#{mounted_as}/#{model.id}”
end
“`
絶対パスにするには、image_uploaderにhostのpathの設定を追加します。
“`ruby:image_uploader
def store_dir
“uploads/#{model.class.to_s.underscore}/#{mounted_as}/#{model.id}”
end

【個人開発】健康的に太りたい人をサポートするサービス「Fat Recipe」をリリースしました!

# はじめに
こんにちは！@hamusan44と申します。
この度、プログラミングスクール「RUNTEQ」を卒業し、健康的に太りたいが何を食べればいいか悩む人向けにサポートするAI×レシピ提供サービス「Fat Recipe」をリリースいたしました！

:::note warn
まだまだ初学者のため、間違った情報があればコメントなどで教えていただけると幸いです。
:::

# サービス名：「Fat Recipe」
▼サービスURL(独自ドメイン対応中です):https://fat-recipe-af94f33f2e6f.herokuapp.com

▼Github:https://github.com/sakamoto-kohei-44/Fat-Recipe

▼告知ツイート:https://twitter.com/ha