Zip格納されたCSVファイルをHTTPレスポンスから直接取り出す

## TL;DR　

オープンデータを提供しているサイトから、ZIPファイルに格納されたCSVファイルをダウンロードし、データを取り出す際、ダウンロードしたファイルを一旦保存して処理するアプローチを取りたくなかったので、HTTPレスポンスからストリーム経由で直接データ抽出するアプローチを採用してみました。

HTTPクライアントにはfaradayを採用していますが、通信周りの処理見直しは必要なものの、他のライブラリでも大丈夫だと思います。

他の方の参考になれば幸いです。

### 留意点

HTTPレスポンスが分割されるケース（チャンク形式）に耐えられるか確認してません。

“` ruby

require ‘faraday’
require ‘stringio’
require ‘zip’

class FetchCsvService

BASE_URL = ‘https://www.opendata.metro.tokyo.lg.jp/’

def initialize
@conn = Faraday.new(BASE_URL) do |builder|

Railsのエラー解消

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

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

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

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

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

原因不明だったRDS負荷のスパイクを改善できた話

# 概要
当時数ヶ月間誰も原因がわからなかった一時的にRDSの負荷（CPU使用率）がスパイクする現象の原因を調査できる環境を整えて、原因分析〜改善まで実施したときの話です。

1つ1つの取り組み自体は大きなことはやっていませんが、一連の動きで得られたものも多かったのでアウトプットしようと思い記事にまとめました。

# 取り組んだ課題
## 原因を特定するためのツールがない
そもそも何が原因でRDSのCPU負荷が高まっているのかを調べるための情報がCPU使用率以外に全くない状況でした。
そこでRDSの負荷原因を探る方法を調べると、Performance InsightsやCloudWatch Logsへのスロークエリログ出力を使う記事をいくつか見つけたのでこの2つについて調べることにしました。

– ### [Performance Insights](https://aws.amazon.com/jp/rds/performance-insights/)
データベース負荷をSQLなどの単位で時系列で可視化したり、トップSQLやDBのヘルスメトリクスを見れる機能です。アプリのパフォーマ

Ruby On Rails Development Company | RoR Web App Development Services

In the dynamic landscape of web development, selecting the right technology and the right team can make all the difference. Ruby on Rails, a powerful and versatile web application development framework, has gained significant popularity for its efficiency and effectiveness. If you’re in the USA and considering harnessing the power of Ruby on Rails for your project, it’s crucial to partner with the right development company to ensure success.

Ruby on Rails, an MIT-licensed full-stack web develop

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

## ど

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つのオブジェクトに対して責任(=役割)が複