2025-05-15

【初心者向け】viteで作ったreactアプリをGithub Pagesにデプロイする方法

viteで作ったReactのアプリをデプロイした時、手順が多くて気付かぬうちに忘れたりエラーにハマったのでまとめてみます。

GitHub リポジトリを作る

ホーム　→　New、もしくは右上の「＋」→「New repository」から新しいリポジトリを作成します。

リポジトリ名は任意の名前を入力し、READMEの有無はどちらでもOKです。

この時、公開設定をprivateかpublicか選べますがGithub Pagesで公開するためにpublicを選びましょう。

次にローカルの同名ブランチを作り、 git init で初期化。
この後リモートとローカルのリポジトリを繋げるのですが、長くなってしまうので他のブログを紹介します。

こちらのリンクの記事がわかりやすいです。

qiita.com

node.js npmのインストール

node.js npmが必要なためインストールします。

qiita.com

インストール後、念のためバージョン確認で正しくインストールできているか確認しましょう。

$ node -v
$ npm -v

viteの導入とGitHub Pages用の設定

ターミナルで以下のコマンドを入力します。

npm create vite@latest

確認画面が出たらyを押しましょう。

次にコマンドライン上でreact JavaScriptやTypeScriptなど選べる表示が出たらreactのところにチェックを入れEnterを押す。

以下のコマンドを打つとローカルホストに繋げるようになります。

npm install
npm install gh-pages
npm start
npm run dev

最後のnpm run devのコマンドで表示されるリンクを打ち込むことでローカルでサーバーに繋ぐことができました。

ローカルで新しいブランチを作り何か変更を加えてコミットする、またそれとは別に以下のファイルの記述を変更する必要があります。

package.jsonのスクリプト内に以下の記述を追加

"scripts": {
    "predeploy": "npm run build",
    "deploy": "gh-pages -d dist"
  },

package.json外側の{}内にGitHubのリンクを追加 "homepage": "https://ユーザー名.github.io/リポジトリ名/",

vite.config.jsの記述変更

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

// https://vite.dev/config/
export default defineConfig({
  plugins: [react()],
  base: '/react_todo/',
  build: {
    outDir: 'dist',
    assetsDir: 'assets',
    },
    server: {
    host: true
    }
})

アプリ作成＆デプロイ

reactアプリを作り込み完成したら以下のコマンドをターミナルで打ちます。

npm run build
npm run deploy
git add .
git commit
git push

その後Github Pages用にリポジトリの設定をします。

リポジトリより　Settings → pagesへ移動、Pagesで公開するにはgh-pagesというブランチを指定する(gh-pagesブランチは自動で作成されています)

saveして数分経つと反映し、Settings pages visit siteのリンクよりアクセスできるようになります。

うまくいかないときは？

リンクを押しても真っ白な時はPagesの設定を見直してみたりブラウザの検証機能を使ってみてください。何らかのエラーが出ているはずです。

2025-02-22

JavaScriptPrimer - 迷わないための入門書を読んで

ご無沙汰してます。
最近プログラミングスクールでRuby on Railsの学習が終わり、JavaScriptの学習を始めました。
今回はJavaScriptPrimer - 迷わないための入門書を読んだ感想になります。
こちらの本が気になった方のためにあらかじめ書いておくと、こちらの本はJavaScriptでフロントのスタイル付けというより、バックエンドでの使い方に重きをおいた本になります。

良かったところ

JavaScriptでバックエンドとは？本当にできるの？という状態で読み始めてもNode.js導入からの解説があり、紹介される構文やメソッドがかなり網羅されていて私のような初心者でも一通りざっくりと理解できました。
かなりボリュームあるように感じますがこれだけの内容をこの一冊によく詰め込めたなというのが正直な感想です。

学んだこと

最後には実践の章もあり既に何らかの言語を学んでいる状態ならオブジェクト、クラス、式など大まかに理解できました。
章ごとのまとめや見出しからどのページで何をしていたかがわかりやすいので辞書引きのような使い方で使っていけそうです。

難しかったこと

Rubyを先に学んでいたからなのか書き方に馴染むのに時間がかかりました。
また、関数とECMAScriptモジュールはまだあまり理解できていませんが必要に合わせて何度も読み返したいと思える本です。

最後に

これからジャバスクリプトを使って本格的にコーディングするのでまだ何度か辞書のように読み返そうと思います。

2025-01-12

Everyday Rails - RSpecの感想

Ruby on Railsの自動テストについて学ぶ過程でEveryday Rails - RSpecによるRailsテスト入門テスト駆動開発の習得に向けた実践的アプローチを読む機会があったので備忘録として感想を書いておきたいと思います。自動テストを学んで2日目なので、間違いなどありましたらコメントしていただけたら嬉しいです。

https://leanpub.com/everydayrailsrspec-jp

良かったところ

自動テストとは何をするのかもわからないような初心者ですが、Gemの導入からテストコードの見本と、解説、その後テストコードが多くなった時のテストコードの整理方法まで載っているので忘れてしまって読み返した時もスッと理解できました。また、簡単かつしっかり仕事をするテストコードの例が書かれているのでコード一つ一つの意味を理解しやすかったです。

学んだこと

attributes_forなど使ったことがないメソッドが載っていてそのメソッドの働きを調べて理解を深めるきっかけになりました。テストコードはどのファイルに書くのかもわからなかったのでコントローラー、モデルなどファイルごとにテストコードを書く際の注意点が違うということも知ることができました。

難しかったこと

見慣れないメソッド、書き方が多く最初はコード一つとっても理解が難しく、何をしているのか分かるまで何度か読み返しました。見慣れるまでは時間がかかりました。正直まだ理解しきれていないので必要に応じて読み返したいです。

4.最後に

最後までご拝読くださりありがとうございました。引き続きRailsを使いこなせるように勉強を続けていきたいと思います！

2024-12-14

【Ruby on Rails】カラム名を間違えた時、きれいに修正する方法（初心者向け）

これは「Happiness Chain Advent Calendar 2024」の14日目の記事です。 https://adventar.org/calendars/10341

久しぶりの更新です。

今年はほとんどRuby on Railsの勉強をしていました。カリキュラムを進めている中でカラム名を変更する必要があるときに、どのような方法で修正したかでその後の手数が異なると気づいたので書いてみたいと思います。

結論から言いますと、カラム名を変更したいときは個人開発でテーブルにデータを入れる前ならロールバック。チーム開発やデータを入れてしまった後はadd to columnで新しいマイグレーションファイルを作るとその後がスムーズに修正できます。

例えば以下のマイグレーションファイルがあったとします。

class CreateComments < ActiveRecord::Migration[7.0]
  def change
    create_table :comments do |t|
      t.references :user, null: false, foreign_key: true
      t.references :tweet, null: false, foreign_key: true
      t.text :comment, null: false #これを変更したい

      t.timestamps
    end
  end
end

上記のcommentカラムをcontentに変更する必要が出た時、マイグレーション後でもテーブルにデータを入れる前ならrails db:rollbackでロールバックすることでマイグレーション前の状態に戻すことができます。（チーム開発の場合、履歴が変わって他のメンバーのものと整合性がなくなり編集不可能になったりするのでご注意ください。）

データを入れた後にカラム名変更する時はコマンドラインでrails generate migration rename_（変更したいカラム名）_column_to_（変更後のカラム名）でカラム名変更用のマイグレーションファイルを作成します。今回はrails generate migration rename_comment_column_to_contentsと入力します。作成されたファイル内にもカラム名を記入します。

class RenameCommentColumnToContents < ActiveRecord::Migration[7.0]
  def change
    rename_column :comments, :comment, :contents
  end
end

rename_column :commentsはテーブル名で、その後にカラム名が続きます。これをrails db:migrateすると既に登録されたデータもカラム名が変わります。例えば既にコメントを作成していてcommentカラムにデータが入っていたとしても自動的にcontentカラムに改名されています。コントローラーやモデル内の記述は変更されないので、もしcommentカラムを指定するような記述を書いていた場合はcontentに変更してください。

今まではマイグレーションファイルを増やさない方が見やすくていいかと思いこんでいたのと、 renameのやり方がいまいちわからなかったためrails db:migrate:down VERSION=（マイグレーションファイルのID）でカラム名を変更したいテーブルが存在するマイグレーションファイルをupの状態からdownにし、マイグレーションファイルに直接手入力で変更した後にマイグレーションしていました。

しかしこちらの方法でカラム名を変更すると既存のデータのカラム名は変わらないのでエラーが出てしまいます。そのため一度手動でテーブル内のデータを全削除する必要があるので修正の手数が多くなってしまいます。

renameの方法を知ってからは、もし間違えてしまっても今までより簡単にカラム名を直せるので学習の速度も落ちづらくなりました。

最後までご拝読くださりありがとうございます！

もっといい方法やご指摘がありましたらぜひコメントください。

参考

qiita.com

zenn.dev

2023-12-19

Ruby on Rails 5 速習実践ガイドを読んで

Ruby on Railsでのアウトプット課題の前にRuby on Rails 5 速習実践ガイドを読みました。
内容を覚えているうちに感想をまとめてみます。

良かったところ

Railsのタスク管理サービスを最初はシンプルに動くように、後半になるにつれ認証機能や他ユーザーが勝手にタスクを消せないような設定など実用的な機能を実装していく流れになっています。実用的な部分は普段自分が使うサイトの裏側の設計の大変さがよくわかりました。
また、Railsでの設計を始める前に必要なRubyの基礎知識、RESTfullな設計の考え方などRailsを使うための前提知識も少し載っているので書いてある通りに作ったらできた、という感じではなく知識を積み上げながら進められます。Railsの頻出コマンド一覧も載っていて分からなくなった時便利です。

学んだこと

Railsを使うとき作られるファイルの役割がよくわかっていなかったのですが一覧で役割が載っていたのでProgateやUdemyでは触れられないファイルの存在理由が分かりました。
また、実用的な部分で学んだこととして個人情報の入力した後に内容確認画面を表示する設定を作る場面があるのですが設計が複雑でありメンテナンスが大変、なお且つユーザー側も確認画面があってもあまり見ないなど必ずしも管理者、ユーザーともにwinwinにならないと知れて勉強時はこう学んだから、参考にしたサイトはこう作られているからという理由で何も考えずに作るのは良くないと知りました。

難しかったこと

書籍のGemfileのバージョンと現在のものが違う関係でGemfileの設定を変えないと動かない部分がありしばらく原因が分からず焦りました。また、RubyやDockerを学びはしたのですが編集するところが多く全ては覚えていません。
10章ではバージョンアップしやすいような書き方とバージョンアップへの対応とについて書かれていたのですが対応したことがないので参考になりましたが全ては理解できてないです。

まだアウトプットを始めるのはこれからなので何度も読み返すことになりそうです。
ここまでご覧くださりありがとうございました！

2023-12-10

RESTについてまとめてみました

RESTの学習を行ったので一度まとめておきたいと思います。

参考にしたUdemy講座はこちらです

RESTとは

アメリカの学者が2000年に定義したもので、REpresentational State Transferの頭文字から取ってRESTといいます。
日本語に訳すと「分散型システムにおける設計原則群」といいます。もう少し分かりやすくすると「設計をする上でのルール」といった意味です。
分散型システムとはクライアントとサーバーのことを指します。クライアントはサーバーにリクエストを送り、サーバーはレスポンスを返すというクライアントがトリガーとなりサーバーは受け身とされていました。
2000年頃にできた概念なので現在はその限りではありません。REST原則という分散型システムを定義するうえでの基準となる原則があり、この原則に則り作られたシステムをREST API(RESTfull API)と呼びます。

階層化システム

web API DBが多数存在する構成のシステムのことです。その中のある一つのサーバーをコンポーネントといいます。
メリットは各システムに役割を持たせることで進化と再利用が促進されます。近年でいうマイクロサービスに近い概念といえます。
デメリットはデータ処理にオーバーヘッドが発生することでユーザー（クライアント）側から見ると動きが遅く反応が悪く感じます。

コードオンデマンド

クライアントコードをダウンロードして実行できることです。
例えば、HTML、Java Scriptなど内容の更新があった時、クライアント側は自動で新しい内容を見ることができます。このようにリリース後にクライアントコードを変更できます。
メリットはリリース済みのクライアントに対して機能が追加できること、クライアント側に処理が移譲できた分、サーバーの処理が軽くなることです。
デメリットは評価環境がChrome,safariなどブラウザアプリがたくさんある分複雑になります。

統一インターフェイス

リソースの識別、表現を用いたリソース操作、自己記述メッセージ、アプリケーション状態エンジンとしてのハイパーメディア(HATEOAS)の4つの制約で成り立っています。
メリットはシステムアーキテクチャが簡素化されてわかりやすい、提供するサービスに集中でき、独自の進化ができる、HTMLという取り決めが共通なので異なるブラウザでも同じような表示ができることです。
デメリットは標準化によって効率が犠牲になり、冗長になることです。それぞれの詳細を以下に紹介します。

リソースの識別

URIを用いてサーバーに保存されたドキュメント、画像などのデータを識別できることです。URIのリソースを識別しますが、動作は含みません。

表現を用いたリソース操作

断面情報を利用してサーバー上のデータを操作することです。認証情報のようなメタデータも含みます。
リクエストを送る際に表現（認証情報などの追加情報）を付与してサーバー側にリソースの編集をお願いすること

自己記述メッセージ

データ自身がサーバーにリクエストするデータ、クライアントへのレスポンスデータのように自らのメッセージ内容をヘッダーに記述して説明しています。

アプリケーション状態エンジンとしてのハイパーメディア(HATEOAS)

レスポンスに現在の状態を踏まえたハーパーリンクが含まれていることです。2000年頃はよく見られましたが近年は減少しています。

ステートレス

リクエストが保持されず、一つ一つの会話（コンテキスト）が独立していることを指します。
メリットは単一のリクエストを見ていればよいので監視が容易なこと、障害発生したリクエストだけ回復すればよいので障害復旧が容易、リクエスト全体でサーバーのリソースを共有する必要がないのでスケールがコンパクトであることです。
デメリットは単一リクエストで完結させるためにリクエストデータに重複ができてしまい冗長であること、アプリを複数バージョン提供し、状態をクライアント側に置いておく場合はアプリ制御が複雑になってしまいます。

キャッシュ制御

クライアント側でレスポンスをキャッシュします。
メリットとしてユーザー体験、リソース効率、拡張性が向上します。
デメリットとしては古いデータを戻してしまうとそれがユーザーに表示されてしまうことがありシステムの信頼性低下につながる恐れがあります。

REST API成熟モデル

2010年に紹介されたRESTAPI設計レベルにどれだけ準拠しているかを4段階に分類したモデルのことです。

Level0はHTTPを使ったAPIである
Level1はリソースの概念が導入されている
Level2はHTTPの動詞が導入されている
Level3はHATEOASの概念が導入されていること
以上の4段階が基準となっています。

URI設計で考慮すること

URI設計では以下のことを考慮して設計します

短く入力しやすいこと
人が読んで理解できること
他の人に伝わらないのでversionをvのように省略しない
小文字で統一されていること
単語はハイフンでつなげて書くこと
リソースの集合を表すので単語は複数形で書くこと
日本語のようなエンコードが必要な文字を使わない
サーバー側のアーキテクチャを記入しない
何を指しているのかわかる単語のみを使い改造しやすくすること
設計はクエリパラメータ指定のみ使用するというようにルールが統一されていること

CRUD操作のURI、HTTPメソッド

URIはリソースを表しますが、HTTPメソッドは操作を表します。
メソッドの種類は

method	説明
GET	リソースの取得
POST	名前が決まっていないリソースの新規登録
PUT	既存リソースの更新、名前が特定できている場合のリソースの新規登録
DELETE	リソースの削除

これを実際に当てはめてみます。
今回は例としてmovie（映画）をリソースとして CRUD操作のURI、HTTPメソッドを定義してみます

URI	HTTPS method	説明
/v1/api/movies	GET	登録されている映画を全て取得
/v1/api/movies	POST	映画の新規登録
/v1/movies/{id}	PUT	既に登録されている映画情報の更新、名前が決まっている映画の新規登録
/v1/movies/{id}	DELETE	登録されている映画の削除

URI設計で考慮することにも書いたようにmovie（映画）はたくさん種類があるのでリソースの集合を表すのでmoviesと複数形で書きます。
また、映画は名前が決まっているはずなので新規登録は基本的にPUTを使うことになると思います。

終わりに

RESTという言葉を聞くのも初めてでしたが、サーバーの設計上必要なものでありこの設計がうまくいってないと利用するユーザーはとても使いにくくなるというだけではなく、設計後の更新作業をする上でも意味が分からないURIの意味を推測する無駄な工程ができてしまうということが分かりました。まだ設計はしたことがないですがこれからの勉強で必ず必要となる土台の部分であると思うので今後初めて設計する時は間違えて修正が大変にならないよう参考Udemy講座を含め見返して書いていきます。

2023-12-07

プログラミングの勉強を始めてから11か月

はじめに

Happiness Chain Advent Calendar 2023、7日目の記事です。今年の1月20日にHappiness Chain(以下HC)に入って11ヶ月ほど経ちました。
入会時に初めて触ったプログラミングの勉強時間も12月7日現在600時間以上となりました。今まで書いていませんでしたがアドベントカレンダーの企画をきっかけにHCに入会してから思ったことを紹介していきたいと思います。気づいたら長文になってしまいましたのでご注意ください。

勉強内容

私はRuby on Railsコースなのですがプログラミング言語はもちろん、DockerやGitHubなどWeb開発に必要な知識を幅広く深く学べます。内容自体は難しいですが必ずクリアできます。勉強で間違えてもどうしても分からなくて質問しても実務でそれをするより苦労は少ないはずなので今のうちにたくさん壁にぶつかろうという精神で進めてます。
コードレビューでは、ただ動くだけではなくメンテナンス性を考えること、コードが複数の人の目に触れることを意識したアドバイスをしてくれます。便利なツールやショートカットも教えていただけます。slackやDiscordで質問ができるのですが先生だけでなく生徒の方も優しく答えてくれることがあり、その日の内に大体解決します。

良かったこと

LGTMをもらい勉強が進む度に達成感があります。できることが増えてきてからできないことがあっても勉強の落ち込みを引きずることが減り、気持ちの切り替えに数日かかっていたのが今では数十分～1時間とかなり楽になりました。振り返ると昼寝のしすぎやスマホで時間の使い方を無駄にしていたと気づき家事の手伝いもありますが趣味の時間はあまり減ってないです。
また、せっかくプログラミング特化で勉強しているので特に好きな趣味を極めてみようと思い、月1回通っていた苔テラリウムの教室はお休みし、代わりにハオルチアという見た目が好みな植物をお手入れし、きれいさの維持向上に力を入れるようになりました。
実は女子大出身で男性と話すとかなり緊張するのですがミートアップや雑談でお話したら少し慣れてきました。以前は緊張するだけでしたが生徒同士の雰囲気が良くコミュニケーションが楽しくなってきたところなので今後もっと顔を見せる機会を増やしていく予定です。

悪かったこと

現行ですとさぼったりペースが落ちても先生から最近どう？など聞かれないので自分で自分を管理する必要があります。ただ、こちらは2024年からは体制が変わり以降入会する人から対応が変わるようです。
また、少しずれますが付き合いの長い友達から誘われた旅行を勉強に集中したいので宿泊有りは1年ほど厳しいと断ったら疎遠になってしまいました。1ヶ月くらい落ち込みましたがHCで新しい仲間、友達が出来ていくので過去のことは引きずらず今を生きるのが吉だと思ってます。最近回復してきて勉強すると落ち着くようになりました（笑）

終わりに

PCをフリーズさせるのが得意で英語もテスト前に詰め込む、受験勉強も推薦のためほとんどせず勉強は不得手な私が1年以内でここまで頑張れるとは正直入会時点では想像もつきませんでした。HC生、卒業生と先生方が作ってくださった環境のおかげでここまでこれました。来年は私も他の人に貢献できるくらい知識と実力をつけたいです。これからも卒業目指して地道に積み上げていきます！

最後まで読んでくださりありがとうございます！

GitHubリポジトリを作る

node.js npmのインストール

viteの導入とGitHub Pages用の設定

アプリ作成＆デプロイ

うまくいかないときは？

良かったところ

学んだこと

難しかったこと

最後に

良かったところ

学んだこと

難しかったこと

RESTとは

階層化システム

コードオンデマンド

統一インターフェイス

リソースの識別

表現を用いたリソース操作

自己記述メッセージ

アプリケーション状態エンジンとしてのハイパーメディア(HATEOAS)

ステートレス

キャッシュ制御

REST API成熟モデル

URI設計で考慮すること

CRUD操作のURI、HTTPメソッド

終わりに

はじめに

勉強内容

良かったこと

悪かったこと

終わりに

GitHub リポジトリを作る