What's New Qiita

20200919のGitに関する記事は8件です。

  • 投稿日：2020-09-19T21:05:53+09:00

Git メモ【随時更新】

Git に関するメモです。

一度解決したらそのまましばらく Git に関する Tips を忘れがちなので、いったんここにメモしておきます。

直近のコミットの変更

コミットをもう一度やりなおす場合は、--amend オプションをつけてもう一度コミットします。

$ git commit --amend

いったんコミットした後、何かのファイルをステージするのを忘れていたのに気づいた場合はこのようにします。

$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend

複数のコミットメッセージの変更

直近の 3つのコミットメッセージあるいはそのいずれかを変更したくなった場合、変更したい最古のコミットの親を git rebase -i の引数に指定します。

$ git rebase -i HEAD~3

すると、テキストエディタが開き、以下のようにコミットの一覧が表示されます。

pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file

# Rebase 710f0f8..a5f4a0d onto 710f0f8
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

メッセージを変更したいコミットの pick 部分を edit に変更して保存します。
すると、そのリストの最初のコミットまで処理を巻き戻してくれます。

$ git commit --amend

と入力し、コミットメッセージを変更して、次に、

$ git rebase --continue

を実行します。このコマンドは他の 2つのコミットも自動的に適用するので、これで作業は終了です。
複数行で pick を edit に変更した場合は、これらの作業を各コミットについてくりかえしていきます。
それぞれの場面で Git が停止するので、amend でコミットを書き換えて continue で処理を続けることになります。

新しいブランチの作成とチェックアウト

新しいブランチを作ると同時に、そのブランチに切り替えたいという状況に対応するため、Git は ショートカットとして -b new-branch オプションを提供しています。

チェックアウトの完了を妨げる問題が起きない限り、次のコマンドは、

$ git checkout -b <new-branch> [<start-point>]

次の2つのコマンドの順次実行と全く同じです。

git branch <new-branch> [<start-point>]
git checkout <new-branch>

ブランチ名の変更

git branch -m もしくは git branch --move はブランチと対応する reflog (参照ログ) を移動 / 名前変更します。

$ git branch -m <old-branch> <new-branch>

また、git branch の -M オプションは -m -f もしくは -m --force のショートカットです。
<newbranch> が存在する場合でも使えますが、基本的には -m オプションでよさそうです。

機密データをリポジトリから削除する

Git リポジトリへのパスワードや SSH キーといった機密データをコミットしてしまっても、そのデータを履歴から削除することができます。
不要なファイルをリポジトリの履歴から完全に削除するには、git filter-branch コマンドか BFG Repo-Cleaner オープンソースツールのいずれかを使用します。

BFG Repo-Cleaner は、不要なデータを削除する手段として、git filter-branch より高速でシンプルです。 たとえば、機密データを含むファイルを削除して、最新のコミットをそのままにしておくには、次を実行します。

$ bfg --delete-files 機密データを含むファイル

MacOSX の場合、BFG Repo-Cleaner は Homebrew でかんたんにインストールすることが可能です。

$ brew install bfg

git filter-branch コマンドを使用する場合は、参考に上げたリンクを参照するとよいでしょう。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-19T20:54:11+09:00

git commit のコミットメッセージに使える英単語

ファイル追加系

単語 意味
create 新しく作成した
add 追加した

ファイル更新系

単語 意味
update （最新の状態に）更新した
modify （既に正常だったが改良のために）修正した
fix （壊れていたものを正常な状態に）修正した
refactoring （機能は変えずに）構造を整理した

ファイル削除系

単語 意味
remove 削除した（他の場所に残っているかもしれない）
delete 消去した（存在を抹消した）
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-19T20:51:00+09:00

Git基本事項

用語(編集途中)

コミット

ユーザーが任意のタイミングで記録を保存する操作．

リポジトリ

コミットを貯めておく場所．

すでにGitで管理されているプロジェクトの開発に参加する場合はリポジトリをコピー（クローン）して使う．

ワークツリー

変更するファイルを保持する場所．

ステージングエリア

コミットするファイルを登録する場所．

Gitディレクトリ

コミットを格納する場所．

GitHubにあげるまでの手順

今回はGitのインストールやGitHubのアカウント作成などの初期設定の説明は省く．

あらかじめ登録してある人が新しいプロジェクトを始めるという状況を想定．

リモートリポジトリをローカルへ複製する or ローカルで作成したリポジトリをリモートへ反映させる

今回はリモート側のリポジトリとして先にGitHubへリポジトリを作成し，それをローカルへ複製するという方法で進める．

    $ git clone GitHubのリポジトリURL

GitHubのファイルが複製されるので cd コマンドでコピーしたディレクトリに移動する．

作業用ブランチを作成する

Gitではbranchを作成し作業を行い，完成したらmasterにmergeするのが基本なのでここでbranchを作成する．

以下のコマンドで現在いるbranchが確認できる．

    $ git branch
    * master

ブランチの作成には以下のコマンドを使う．

    $ git branch ブランチ名

例）

    $ git branch work

ブランチを作成したら以下のコマンドでブランチを切り替える

    $ git checkout ブランチ名

例）

    $ git checkout work

ブランチを切り替えたらファイルの編集を行い，バージョンアップを行う．

コミットをする

書き換えたファイルはリモートリポジトリに保存しておきたいので以下のコマンドを実行する．

    $ git add ファイル名

このコマンドで指定したファイルがコミット対象になる．

今回はフォルダにあるファイルを全てコミットする予定なので以下のコマンドを実行する．

    $ git add .

これでコミットの準備ができたので以下のコマンドでコミットを行う．

    $ git commit -m 'コメント’

これでコミットは完了．（-mを付けなかった場合はvi上でコメントの入力を求められる．）

ブランチをマージする

今回はmasterにworkを取り込む．

まずはmasterブランチに移動する．

    $ git checkout master
    Switched to branch 'master'
    Your branch is up to date with 'origin/master'.

このまま編集したファイルを開いてもブランチを切り替えているので変更が反映されていない．

例）

    $ git merge work
    Updating ac63b89..3eefb35
    Fast-forward
    README.md | 1 +
    1 file changed, 1 insertion(+)

このコマンドでマージが成功すると編集した内容がmasterに反映される．

リモートにpushをする

いよいよ変更内容をGItHubに反映させる．

例）

    $ git push origin work
    Counting objects: 3, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 338 bytes | 338.00 KiB/s, done.
    Total 3 (delta 1), reused 0 (delta 0)
    remote: Resolving deltas: 100% (1/1), completed with 1 local object.
    remote: 
    remote: Create a pull request for 'work' on GitHub by visiting:
    remote:      GitHubのURL
    remote: 
    To GitHubのURL
    * [new branch]      work -> work

これでGitHubにちゃんと反映されていたら成功！

おさらい

大事なのは以下のコマンドでこの流れは絶対である．

    $ git clone URL
    $ git add .
    $ git commit -m 'コメント'
    $ git push origin master

知っていると便利なコマンド

    $ git status

このコマンドで今の状態を確認できる．

慣れるまでは何かを実行するたびにこのコマンドで確認した方がいいかも．

    $ git branch

このコマンドで現在どのブランチにいるのかを確認できる．

不十分な点

  • 開発はGitHub→Gitという流れよりローカル→リモートという流れが自然？
  • ブランチ切ったままファイルの移動をしてしまった場合どうなっちゃう？
  • 後からフォルダに違うディレクトリ にあったファイルを持ってきた場合どうやったらコミット対象になってくれるのか
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-19T18:28:15+09:00

実務経験約6ヶ月のペーペーが実務で使ってない技術だらけでWebアプリを0から開発してみた話

0.はじめに

実務経験だいたい6ヶ月の僕がスキルアップのために現時点では実務で使っていない技術を使ってWebアプリを0から開発してみた話。

未経験からエンジニア転職を目指す方々のWebアプリ（いわゆるポートフォリオ）作成にも結構参考になることはあると思いますのでぜひ。

作成したのは面接情報共有アプリです。

1.使用技術

  • フロント：HTML／MDBootstrap4／Vue.js（2.6.11）
  • バックエンド：Laravel（6.8）
  • DB：開発環境はDockerのMySQLコンテナ、本番環境はRDS（MySQL）
  • 開発環境：Docker（LEMP環境）
  • インフラ：AWS（EC2／S3／Route53／ELB／RDS）
  • CI/CD：CircleCI
  • ソース管理：Git／GitHub

赤太字が2020/9/19時点で実務で使ってない技術

2.簡単に自己紹介

  • 関西のWeb系企業でPHPを使ったWebアプリ開発を行う新米パパエンジニア
  • 2019年10月からプログラミング学習を開始→2020年4月からエンジニアのキャリアスタート
  • Twitterで情報発信
  • 好きな食べ物はホットケーキ

Twitterはこちら↓
https://twitter.com/shimotaroo

3.開発背景

面接情報共有アプリを開発した理由は大きく分けて2つ。

  • Laravel、Docker、AWS、CircleCIの勉強のため（アウトプットしながらが効率的）
  • エンジニアへの転職活動中の方の面接の内容（特に質問）がTwitterで伸びやすいく、需要のある情報だと思ったため
  • 1つのサービスの開発、運用を経験してみたかったら（特に運用）
    ↑開発前はリリース→機能追加→リリースをしてサービスをグロースできたらいいなと思っていました、他にやりたいこと・やるべきことがたくさんあり、今はそこまで考えてない

4.（ひとまず）完成したWebアプリをご紹介

トップページ↓
スクリーンショット 2020-09-13 23.59.34.png

URL↓
https://mensetsu-app.work/

GitHub↓
https://github.com/shimotaroo/laravel-app

README.mdはこちらの記事を見ながら書きました。
【GitHub】シンプルなREADME.mdの書き方 -コピペで使えるテンプレート付き-

トップページに画像だったりとアプリの説明をいれるケースもありますが、Twitter、note、Instagramをイメージしてこんな感じのトップページのUIアプリの説明とか画像が入ってない）にしました。

自分がテスト投稿したデータが本番環境に残ってますが悪しからずww

5.完成までにかかった日数

スクリーンショット 2020-09-14 0.06.34.png

毎日このアプリ開発に時間を費やしていたわけではないので明確にわかりませんが草は上の画像の感じです。
（育児と本業、その他諸々の傍らコツコツやってました）

まあフルコミットすれば1ヶ月くらいでできたのかな、って感じです。（多分）

6.実装した機能

  • CRUD機能
  • ユーザー登録
  • ログイン／ログアウト
  • Googleアカウントでユーザー登録／ログイン
  • Twitterアカウントでユーザー登録／ログイン
  • プロフィール編集
  • パスワード変更（現在のパスワードをチェックする仕様）
  • プロフィール画像のデフォルト設定／変更
  • いいね（お気に入り）
  • ページネーション
  • 並び替え＋ページネーション保持
  • 絞り込み検索＋ページネーション保持

特別難しい機能はないかと思います。レベルの高い初学者の方ならポートフォリオとして盛り込んでいたりするかもです。
（と言っても僕はいくつかは手こずりました）

7.その他にやったこと

  • ER図書いてDB設計
  • 開発環境DockerでLEMP環境構築（もちろんLaradockじゃないです）
  • PHPPUnitで単体テスト
  • AWSにデプロイ
  • Circle CIで自動テスト／自動デプロイ

1つ前に書いた機能実装よりこっちの方が未知の分野だったので大変でした。そして頑張った。
（上手くいかず何度PCをぶん投げようと思ったか...）

8.DB設計

DB設計というかER図作成はDraw.ioというツールを使いました。
VSCode用のプラグインがありエディター上ででER図を作成できるスグレもの。

作成したER図はこちら↓
スクリーンショット 2020-09-14 0.49.36.png

作成したテーブルはこちら↓

テーブル名 説明
users 登録ユーザーの管理
articles 投稿された面接情報の管理
prefectures articlesに紐づける都道府県
company_types articlesに紐づける企業の事業形態
phases articlesに紐づける選考フェーズ
likes いいねの管理

ポイントとしてはarticlesテーブルにprefecturesやcompany_types、phaseの情報をベタでINSERTせずにそれぞれのテーブルで値を保持しておき、articlesテーブルではそのidを参照するように外部キー制約を設定しました。（正規化っていうらしい）

詳しいことは上のER図をみていただければわかるかなと思います。

僕はこれまでER図を書いたことがなかったので1から勉強しました。
初めはリレーションあたりが「？」でしたが、めっちゃググって理解できました。ググった中でも特にわかりやすかった記事を下にピックアップします↓

9.ソース管理

ソース管理は皆さんお馴染みのGit/GitHubです。

個人開発なのでGitHub Flowでソース管理しました。（masterとfeatureブランチ）

GitHub Flowがよくわからない人はこちらから↓
GitHub Flow 図解

※Gitに関して、僕の記事にもまとめていますので特に初学者の方はこちらも併せて読んでいただくとお役に立てると思います↓

Gitでやりたいこと、ここで見つかる

※僕のQiitaの記事は約800LGTMなので結構オススメです（笑）

10.環境構築

環境構築はDockerでLEMP環境を構築しました。

LEMP環境は以下の通りです。

  • L：Linux（OS）
  • E：Nginx（Webサーバー）
  • M：MySQL（DBサーバー）
  • P：PHP（アプリケーション）

Dockerを使ったLaravel+Vue.jsの実行環境の構築方法については以下にまとめております。今回作成したアプリもこの記事通りに環境構築しました。

絶対失敗しないのでDockerでLaravelの実行環境を構築をしたい方はぜひ併せて読んでいただければと思います。

11.インフラ

インフラはAWSを使いました。
僕は独学期間にAWSはノータッチ＆実務でもまだAWSを使ったことがないので、この開発を通して初めて触りました。最初は意味不明ながらもUdemyの動画教材（後ほどご紹介します）を見ながら必死でインフラ構築しました。

構築したインフラはこちらです。

image.png

上図の通りですが簡単に。

  • Webサーバー：EC2
  • DB：RDS
  • DNS：Route53
  • 画像用ストレージ：S3
  • ロードバランサー：ALB

せっかくローカルの環境をDockerで構築したのでECSを使ってデプロイできればよかったのですが、いかんせんAWSを初めて触ったレベルだったので諦めました...（一応チャレンジはしました）
なお、"EC2内でDockerコンテナを立ち上げる"方法も検討しましたが、こちらも全然上手くいかず諦めました...
良い勉強になりましたが、今後は↑このあたりも勉強＆挑戦していきたい。

あと、先ほど掲載したインフラの図を見て、「あれ...」って思われた方がいらっしゃると思うのでここで簡単に反省点をあげます（笑）

  • ロードバランサー使っているのにアクセスを振り分けるEC2が1つしかない
  • てかそもそもEC2もRDSも1つしかなくて全然冗長化できてない
  • 画像を扱うのにCloudFront使ってない

わかっています。わかってるんです...
お、お金の面を考慮してリーズナブルにしました...（お許しを...）

12.使った教材

僕がこのWebアプリを作成するために活用した教材をご紹介します。

Laravel、Vue.js：【Techpit】Laravel(+Vue.js)でSNS風Webサービスを作ろう！

PHPUnit、Circle CI、AWS：【 Techpit】Laravel × CircleCI × AWSで学ぶCI/CD

AWS：【Udemy】AWS：ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得

Docker：【Udemy】米国AI開発者がゼロから教えるDocker講座

ここで紹介している教材は本当にわかりやすかったです。もちろん上記プラスで公式ドキュメントやQiitaを見ながらしました。

当たり前と思いますがLaravelならこちらは必ず見た方が良いですね。
ReadDouble

13.大変だったこと

大変だったこと、苦労したことはやはり初めて触る技術・実務で使っていないですね。
具体的にはこちら↓

  • Laravel
  • PHPUnit
  • Circle CI
  • AWS

Laravelで大変だったこと

Laravelに関しては現職に入社する前に基礎は学習していたのでそこまで躓かなかったのですが、

  • 並び替え・絞り込み検索時のページネーション保持
  • プロフィール画像のデフォルト設定／変更

は結構手こずりました。

画像の取り扱いに関しては

  • 開発環境ではローカルに保存
  • 本番環境ではS3に保存

にするように変更したので、初めからS3に保存していてもよかったですね。

PHPUnitで大変だったこと

  • テストコードの書き方全般
  • DBを使ったユニットテスト（単体テスト）

結合テストだったり統合テストは今後勉強していきたいです。

Circle CIで大変だったこと

  • config.yml（設定ファイル）の書き方全般

だいぶ苦労しました。4日くらいひたすら自動テストの段階で格闘してましたw
めっちゃググって実際に書いて大まかな書き方は理解できたのでこれは今後別の記事にできたら良いなと。

※ちなみに、自動テストと自動デプロイが無事に通った瞬間は最高の気分で昇天するかと思いました。

AWSで大変だったこと

  • AWSの概念の理解
  • ALB（ELB）を使ってクライアントとの通信をHTTPS化

HTTPS化に関しては結局Laravel側にも設定が必要ということに気づいて解決したんですが、ここも結構時間を使いました。

14.実装したかったけどできなかったこと・まだしていないこと

思いつくだけでもこちらです↓

  • 要件定義
  • 基本設計
  • 詳細設計
  • ユーザー登録時のバリデーション強化
  • セキュリティ面の確認
  • コメント機能
  • DM機能
  • フォロー機能
  • Vue.jsの活用
  • ファビコン設定
  • Twitterへのシェア機能
  • Webサーバー、DBサーバーの冗長化
  • ECS(Elastic Container Service）でデプロイ
  • Cloud Frontでの画像のキャッシュ配信
  • Docker環境の最適化
  • 結合テスト／統合テスト

見てもらうとわかると思いますが、できてないこと・してないことはたっぷりです（笑）
少しずつできたらいいなと思います。

15.開発してみた感想

プライベートでWebアプリを開発したのは転職活動前ぶりでしたが、当時は

  • フレームワークなしでネイティブPHPのみ
  • ローカルはMAMP
  • Xserverに手動デプロイ
  • テストコード0

というなかなか笑えない感じだったので、今回色々な技術を使って開発した感想としては

  • アウトプットしながらのインプットがまじで最強
  • FW超便利
  • Docker超便利
  • AWSはむずい
  • CI/CDパイプラインは構築はむずいけどできたら超便利
  • 公式ドキュメントをちゃんと読むようになった
  • ググればある程度の問題は解決できた

とかですかね。

赤字で強調しましたが、アウトプットありきのインプットはまじで効率がオバケです。
どういうことかと言うと、勉強（インプット）してから「どんな機能を実装しようかな」（アウトプット）じゃなくて、まず実装する機能をまず決めて（アウトプット）それに必要な知識を勉強（インプット）するということです。

アウトプット駆動開発とでも言いいますか。

超オススメです。

（あとは実務未経験でポートフォリオにDocker、Circle CI、AWSを盛り込んでいる方がいますがマジですげえなと思いましたね）

16.さいごに

かなり長くなってしまいましたが、最後までご覧いただき本当にありがとうございますm(__)m

今後はもっと上流工程（要件定義、基本設計、詳細設計）にチャレンジしたいなと思っています。

初学者の方々も僕と同じくエンジニア1年生の方もアウトプット駆動開発でゴリゴリスキルアップしていきましょう(^^)

（あ...最後に...LGTMをポチッと押していただけると...昇天しま...あ、嬉しいです）

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-19T18:28:15+09:00

実務経験約6ヶ月の僕が実務で使ってない技術だらけでWebアプリを0から開発してみた話

0.はじめに

実務経験だいたい6ヶ月の僕がスキルアップのために現時点では実務で使っていない技術を使ってWebアプリを0から開発してみた話。

未経験からエンジニア転職を目指す方々のWebアプリ（いわゆるポートフォリオ）作成にも結構参考になることはあると思いますのでぜひ。

作成したのは面接情報共有アプリです。

1.使用技術

  • フロント：HTML／MDBootstrap4／Vue.js（2.6.11）
  • バックエンド：Laravel（6.8）
  • DB：開発環境はDockerのMySQLコンテナ、本番環境はRDS（MySQL）
  • 開発環境：Docker（LEMP環境）
  • インフラ：AWS（EC2／S3／Route53／ELB／RDS）
  • CI/CD：CircleCI
  • ソース管理：Git／GitHub

赤太字が2020/9/19時点で実務で使ってない技術

2.簡単に自己紹介

  • 関西のWeb系企業でPHPを使ったWebアプリ開発を行う新米パパエンジニア
  • 2019年10月からプログラミング学習を開始→2020年4月からエンジニアのキャリアスタート
  • Twitterで情報発信
  • 好きな食べ物はホットケーキ

Twitterはこちら↓
https://twitter.com/shimotaroo

3.開発背景

面接情報共有アプリを開発した理由は大きく分けて2つ。

  • Laravel、Docker、AWS、CircleCIの勉強のため（アウトプットしながらが効率的）
  • エンジニアへの転職活動中の方の面接の内容（特に質問）がTwitterで伸びやすいく、需要のある情報だと思ったため
  • 1つのサービスの開発、運用を経験してみたかったら（特に運用）
    ↑開発前はリリース→機能追加→リリースをしてサービスをグロースできたらいいなと思っていました、他にやりたいこと・やるべきことがたくさんあり、今はそこまで考えてない

4.（ひとまず）完成したWebアプリをご紹介

トップページ↓
スクリーンショット 2020-09-13 23.59.34.png

URL↓
https://mensetsu-app.work/

GitHub↓
https://github.com/shimotaroo/laravel-app

README.mdはこちらの記事を見ながら書きました。
【GitHub】シンプルなREADME.mdの書き方 -コピペで使えるテンプレート付き-

トップページに画像だったりとアプリの説明をいれるケースもありますが、Twitter、note、Instagramをイメージしてこんな感じのトップページのUIアプリの説明とか画像が入ってない）にしました。

自分がテスト投稿したデータが本番環境に残ってますが悪しからずww

5.完成までにかかった日数

スクリーンショット 2020-09-14 0.06.34.png

毎日このアプリ開発に時間を費やしていたわけではないので明確にわかりませんが草は上の画像の感じです。
（育児と本業、その他諸々の傍らコツコツやってました）

まあフルコミットすれば1ヶ月くらいでできたのかな、って感じです。（多分）

6.実装した機能

  • CRUD機能
  • ユーザー登録
  • ログイン／ログアウト
  • Googleアカウントでユーザー登録／ログイン
  • Twitterアカウントでユーザー登録／ログイン
  • プロフィール編集
  • パスワード変更（現在のパスワードをチェックする仕様）
  • プロフィール画像のデフォルト設定／変更
  • いいね（お気に入り）
  • ページネーション
  • 並び替え＋ページネーション保持
  • 絞り込み検索＋ページネーション保持

特別難しい機能はないかと思います。レベルの高い初学者の方ならポートフォリオとして盛り込んでいたりするかもです。
（と言っても僕はいくつかは手こずりました）

7.その他にやったこと

  • ER図書いてDB設計
  • 開発環境DockerでLEMP環境構築（もちろんLaradockじゃないです）
  • PHPUnitで単体テスト
  • AWSにデプロイ
  • Circle CIで自動テスト／自動デプロイ

1つ前に書いた機能実装よりこっちの方が未知の分野だったので大変でした。そして頑張った。
（上手くいかず何度PCをぶん投げようと思ったか...）

8.DB設計

DB設計というかER図作成はDraw.ioというツールを使いました。
VSCode用のプラグインがありエディター上ででER図を作成できるスグレもの。

作成したER図はこちら↓
スクリーンショット 2020-09-14 0.49.36.png

作成したテーブルはこちら↓

テーブル名 説明
users 登録ユーザーの管理
articles 投稿された面接情報の管理
prefectures articlesに紐づける都道府県
company_types articlesに紐づける企業の事業形態
phases articlesに紐づける選考フェーズ
likes いいねの管理

ポイントとしてはarticlesテーブルにprefecturesやcompany_types、phaseの情報をベタでINSERTせずにそれぞれのテーブルで値を保持しておき、articlesテーブルではそのidを参照するように外部キー制約を設定しました。（正規化っていうらしい）

詳しいことは上のER図をみていただければわかるかなと思います。

僕はこれまでER図を書いたことがなかったので1から勉強しました。
初めはリレーションあたりが「？」でしたが、めっちゃググって理解できました。ググった中でも特にわかりやすかった記事を下にピックアップします↓

9.ソース管理

ソース管理は皆さんお馴染みのGit/GitHubです。

個人開発なのでGitHub Flowでソース管理しました。（masterとfeatureブランチ）

GitHub Flowがよくわからない人はこちらから↓
GitHub Flow 図解

※Gitに関して、僕の記事にもまとめていますので特に初学者の方はこちらも併せて読んでいただくとお役に立てると思います↓

Gitでやりたいこと、ここで見つかる

※僕のQiitaの記事は約800LGTMなので結構オススメです（笑）

10.環境構築

環境構築はDockerでLEMP環境を構築しました。

LEMP環境は以下の通りです。

  • L：Linux（OS）
  • E：Nginx（Webサーバー）
  • M：MySQL（DBサーバー）
  • P：PHP（アプリケーション）

Dockerを使ったLaravel+Vue.jsの実行環境の構築方法については以下にまとめております。今回作成したアプリもこの記事通りに環境構築しました。

絶対失敗しないのでDockerでLaravelの実行環境を構築をしたい方はぜひ併せて読んでいただければと思います。

11.インフラ

インフラはAWSを使いました。
僕は独学期間にAWSはノータッチ＆実務でもまだAWSを使ったことがないので、この開発を通して初めて触りました。最初は意味不明ながらもUdemyの動画教材（後ほどご紹介します）を見ながら必死でインフラ構築しました。

構築したインフラはこちらです。

image.png

上図の通りですが簡単に。

  • Webサーバー：EC2
  • DB：RDS
  • DNS：Route53
  • 画像用ストレージ：S3
  • ロードバランサー：ALB

せっかくローカルの環境をDockerで構築したのでECSを使ってデプロイできればよかったのですが、いかんせんAWSを初めて触ったレベルだったので諦めました...（一応チャレンジはしました）
なお、"EC2内でDockerコンテナを立ち上げる"方法も検討しましたが、こちらも全然上手くいかず諦めました...
良い勉強になりましたが、今後は↑このあたりも勉強＆挑戦していきたい。

あと、先ほど掲載したインフラの図を見て、「あれ...」って思われた方がいらっしゃると思うのでここで簡単に反省点をあげます（笑）

  • ロードバランサー使っているのにアクセスを振り分けるEC2が1つしかない
  • てかそもそもEC2もRDSも1つしかなくて全然冗長化できてない
  • 画像を扱うのにCloudFront使ってない

わかっています。わかってるんです...
お、お金の面を考慮してリーズナブルにしました...（お許しを...）

12.使った教材

僕がこのWebアプリを作成するために活用した教材をご紹介します。

Laravel、Vue.js：【Techpit】Laravel(+Vue.js)でSNS風Webサービスを作ろう！

PHPUnit、Circle CI、AWS：【 Techpit】Laravel × CircleCI × AWSで学ぶCI/CD

AWS：【Udemy】AWS：ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得

Docker：【Udemy】米国AI開発者がゼロから教えるDocker講座

ここで紹介している教材は本当にわかりやすかったです。もちろん上記プラスで公式ドキュメントやQiitaを見ながらしました。

当たり前と思いますがLaravelならこちらは必ず見た方が良いですね。
ReadDouble

13.大変だったこと

大変だったこと、苦労したことはやはり初めて触る技術・実務で使っていないですね。
具体的にはこちら↓

  • Laravel
  • PHPUnit
  • Circle CI
  • AWS

Laravelで大変だったこと

Laravelに関しては現職に入社する前に基礎は学習していたのでそこまで躓かなかったのですが、

  • 並び替え・絞り込み検索時のページネーション保持
  • プロフィール画像のデフォルト設定／変更

は結構手こずりました。

画像の取り扱いに関しては

  • 開発環境ではローカルに保存
  • 本番環境ではS3に保存

にするように変更したので、初めからS3に保存していてもよかったですね。

PHPUnitで大変だったこと

  • テストコードの書き方全般
  • DBを使ったユニットテスト（単体テスト）

結合テストだったり統合テストは今後勉強していきたいです。

Circle CIで大変だったこと

  • config.yml（設定ファイル）の書き方全般

だいぶ苦労しました。4日くらいひたすら自動テストの段階で格闘してましたw
めっちゃググって実際に書いて大まかな書き方は理解できたのでこれは今後別の記事にできたら良いなと。

※ちなみに、自動テストと自動デプロイが無事に通った瞬間は最高の気分で昇天するかと思いました。

AWSで大変だったこと

  • AWSの概念の理解
  • ALB（ELB）を使ってクライアントとの通信をHTTPS化

HTTPS化に関しては結局Laravel側にも設定が必要ということに気づいて解決したんですが、ここも結構時間を使いました。

14.実装したかったけどできなかったこと・まだしていないこと

思いつくだけでもこちらです↓

  • 要件定義
  • 基本設計
  • 詳細設計
  • ユーザー登録時のバリデーション強化
  • セキュリティ面の確認
  • コメント機能
  • DM機能
  • フォロー機能
  • Vue.jsの活用
  • ファビコン設定
  • Twitterへのシェア機能
  • Webサーバー、DBサーバーの冗長化
  • ECS(Elastic Container Service）でデプロイ
  • Cloud Frontでの画像のキャッシュ配信
  • Docker環境の最適化
  • 結合テスト／統合テスト

見てもらうとわかると思いますが、できてないこと・してないことはたっぷりです（笑）
少しずつできたらいいなと思います。

15.開発してみた感想

プライベートでWebアプリを開発したのは転職活動前ぶりでしたが、当時は

  • フレームワークなしでネイティブPHPのみ
  • ローカルはMAMP
  • Xserverに手動デプロイ
  • テストコード0

というなかなか笑えない感じだったので、今回色々な技術を使って開発した感想としては

  • アウトプットしながらのインプットがまじで最強
  • FW超便利
  • Docker超便利
  • AWSはむずい
  • CI/CDパイプラインは構築はむずいけどできたら超便利
  • 公式ドキュメントをちゃんと読むようになった
  • ググればある程度の問題は解決できた

とかですかね。

赤字で強調しましたが、アウトプットありきのインプットはまじで効率がオバケです。
どういうことかと言うと、勉強（インプット）してから「どんな機能を実装しようかな」（アウトプット）じゃなくて、まず実装する機能をまず決めて（アウトプット）それに必要な知識を勉強（インプット）するということです。

アウトプット駆動開発とでも言いいますか。

超オススメです。

（あとは実務未経験でポートフォリオにDocker、Circle CI、AWSを盛り込んでいる方がいますがマジですげえなと思いましたね）

16.さいごに

かなり長くなってしまいましたが、最後までご覧いただき本当にありがとうございますm(__)m

今後はもっと上流工程（要件定義、基本設計、詳細設計）にチャレンジしたいなと思っています。

初学者の方々も僕と同じくエンジニア1年生の方もアウトプット駆動開発でゴリゴリスキルアップしていきましょう(^^)

（あ...最後に...LGTMをポチッと押していただけると...昇天しま...あ、嬉しいです）

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-19T17:10:36+09:00

GitHubで"Initial Commit"をすぐにする方法

はじめに

GitHub Codespaceは､ブランチがないと作れないので

やり方

最初だけローカルかGitpodを用いります｡

1, まず､GitHubにusername/initialという名前のRepoを作ります｡
2, github.com/username/initial/settings を開いて､Template Repositoryに✅を入れます｡
3, クローンします｡

git clone https://github.com/username/initial.git
gitpod.io/#github.com/username/initial

4, git commit --allow-empty -m 'Initial Commit' をしてPushします｡

コミットメッセージはご自由に

これで､Repoを作るときにTemplateからinitialを選択することで､Initial Commit済みのRepoを作れます｡
これならすぐにCodespaceに行けますね!

俺って天才かも

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-19T09:47:21+09:00

Windows10 HomeにDokerをベースとした開発環境を構築する 2020 ver. その2　VSCodeでDocker開発環境を快適にできるはず

はじめに

前回はWindows10Homeにまともに動きそうなDockerを構築しました。今回は統合開発環境として十分に使えそうなVSCodeの設定を実施していきます。

快適な開発環境を定義してみる

（その１ で書くべきだと反省していますが）
そもそもWindowsベースで快適じゃない開発がなぜ発生するか考えてみると、WindowsがLinuxやUnix（Mac）と同等に動かないことが一番の原因だと思いました。
改善ポイントと改善方法を考えてみました。

  1. ruby、python, MySQLなどの開発に必要なモジュールがまともに動かない（きがする）→ WSL2ベースのDockerならまともにうごく（はず）
  2. 開発に必要なモジュールのバージョン管理がもうカオス（こればMacでも一緒） →　Docker適切な環境をコンテナとして用意。ただしその環境にすぐ切り替え可能なこと
  3. コマンドプロンプトやPowerShellなどのターミナルの操作が慣れない。bashがいい　→　Windowsで動くbash導入

1はDocker Desktopを導入しましたのであとは触ってみるだけですが一応解決とします。残りは2と3です。

開発に必要なモジュールのバージョン管理

コンテナ環境を用意するのはDockerに任せるとしまして、問題はその開発環境にすぐに切り替えられること。もっと言いますとコンテナの環境を開発環境として
まともに動かせるのか調査しました。VSCode の Remote Developmentがよさそうなので構築してみました。
「Visual Studio Code Remote Development allows you to use a container」
https://code.visualstudio.com/docs/remote/remote-overview

VSCode & Remote Containers

VSCodeをインストールします。
https://azure.microsoft.com/ja-jp/products/visual-studio-code/

拡張機能のRemote Containersをインストールします
https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers
image.png

そうするとVSCodeの左下に緑色の新しいステータスバーが追加されました。クリックしてみるとRemote Containersのコマンドが出てきます。
image.png

今のところ開発環境はありませんのでPythonのSample開発環境を導入してみます。
Remote-Containers: Try a Sample...　を選択し、その中のPythonをクリックします
image.png
コンテナがインストールされ始めました。
image.png

これでサンプルのPython開発環境の準備ができました。ものの数分でできてしまいました。快適です。
image.png

Docker Desktopの画面でも新しいコンテナが認識されています。
image.png

VSCodeにもどってF5キーを押しすと、サンプルのFlaskを使ったWebアプリケーションが立ち上がります。Running on の後に続くURLにマウスフォーカスし、Follow Linkをクリックします。
image.png

Webブラウザが立ち上がり以下のような画面がみえたら成功です。
image.png

最後に開発ができること≒コードの編集をVSCode上で実施してみます。
index.htmlを開いて日本語の「もちろんできるよ！」を追記し保存します。
image.png

Webブラウザをリロードすると・・・
image.png

意図通りのコードが反映されました。あとはgitですがWindowsにはまだ導入していませんが、コンテナには導入されているのでVSCodeから実行できます。しかしコンテナ側でのgitの設定は必要になります。今後もコンテナ側のgitの設定は都度実施するのは快適ではありません。VSCode RemoteContainersではローカル側のgitの情報をシェアすることが可能となっています。ローカルにgitをインストールしておきましょう。

Git for Windows のインストール

インストーラーを公式サイトからダウンロードします。
https://git-scm.com/download/win

基本的にウィザードに従っていけば問題ありませんが、いくつか変更を考えた方がよい部部分があります。

デフォルトエディターの選択でVSCodeにしておく

（Vimでもよいと思います））
image.png

改行コードの変換は「Checkout as-is, commit Unix-style line ending」にしておく

開発環境がWindows、実行環境がLinuxの場合はこれにしておくことを推奨します。
（Checkout Windows-styleですとチェックアウトの時に改行コードをCRLFに変更します。
以前のnotepadなどWindowsの改行コードのみ対応しているエディターを利用する場合はこちらを選びますが、そのような人は今はほとんどいないと思っています）

インストールが終わったらGit Bashを立ち上げて以下のコマンドでuser.nameとuser.emailを設定します

> git config --global user.name "TakaK"
> git config --global user.email "sample@sample.sample"

gitの設定はとりあえずこれでOKです。

既存のコンテナへgitの設定を反映させる

コンテナのビルド時にgitの設定が自動でコピーされ反映されますので、既存のコンテナに反映させるにはReBuildする必要があります。

image.png

あとは通常のgitコマンドもしくはVSCode上のgitUIでもお好きなほうで作業OKです。

今後はリモートレポジトリの設定なども必要ですがローカルでコンテナを使った開発自体は以上でできると思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-09-19T01:01:31+09:00

なるべくgitを理解させず他人にgitを使わせたい

gitを運用する上の問題

俺はgitを完全に理解している。だが俺以外のメンバーはgitを理解していない。
理由は単純、gitは難解だからだ。
そういうときに「勉強しろ！」というのはプロとしての「怠慢」なのである。

どうするか

gitは諦めて前時代的な管理方法 (RCSやSVN) を使うか？それはあり得ない。1
極めて単純化した運用を練っておくことでgitという難解なツールを使ってもらうのである。
運用としてはGitHub-Flowに近いものを使います。git-flowなぞ高度なことさせられません。

ブランチの種類

  • featureやfix: トピックブランチ
  • develop: デプロイ可能な開発用ブランチ
  • master: 製品となったコードの格納先

各ブランチは複数持つことを許容します。feature/new-buttonやdevelop/開発1、master/お客さんA みたいな。

開発中の作業として頼むサイクル

  1. ソースコードの修正作業が発生する（機能追加やバグ修正）
  2. git checkout develop
  3. git pull
  4. git checkout -b feature/hoge または git switch -c feature/hoge
  5. いろいろソースをいじってもらう
  6. git add .
  7. git commit -m "hogehoge"
  8. git push -u origin feature/hoge または事前にgit config push.default currentを仕込んでおいてgit push
  9. GitLabやGitHubとかでMR、PRしてもらう。
  10. MRやPRを承認してもらう。

改めて見ると長いですね。大変だ。これを無意識にやっている方々は偉大ですね。

あきらめたこと

  • 作業単位にコミットを分けること
    • やるに越したことはないが分けるために頭や時間を使うくらいなら分けなくてよい。

問題

もし、自分の作業中に他人の変更がdevelopに発生した場合、適宜リベースするか？
それともdevelopを作業ブランチにmergeしてもらうか？という問題がある。
作業内容を見た感じほぼ同じじゃね？となるが、作業者が何をどこにマージするのかによって難易度が変わる。

developへリベースする場合

作業のフローとしてはこんな感じ。
この場合、developの最新版に対して自分の差分をマージすることになる。

  • git pull origin develop
  • git rebase origin/develop
  • 「自分の変更に対して」コンフリクトがあったら解決し、 git rebase --continue
  • git push -f

developを作業ブランチにmergeしてもらう場合

developのmergeは他人の変更を取り込む必要が発生する。他人の作業は理解し難い（したくない）。
この場合、古いバージョンのdevelopに対して自分の変更がある状態に加え、developの最新版をマージすることになる。
作業者の負担が多くなると思われる。

  • git pull origin develop
  • git merge origin/develop
  • 「他人の変更に対して」コンフリクトがあったら解決し、 git merge --continue
  • git push

つまり

手順書を書いて、rebaseさせよう！ということ。おわり。

  1. SVN派の皆さんすいません。 ↩

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧