herokuについて

特徴

・PaaSの一種

そもそもPaaSとは、クラウド(インストールやメンテの手間なくITサービスを享受できる)からインターネットを通してアプリケーションの開発環境を取得できるサービス(Platform as a Servis)。※Platformはアプリケーション実行やデータ保存ができる基盤を、WEB上(クラウド)で展開しているもの。イメージとしてはお菓子を作りたいと思った時、製作キットを買うのではなく、キッチンが用意してある場所に向かう感じ。

・使い勝手の良さ(他のSalesforce社の商品に比べて)

第一にあまりプログラミング言語の垣根がない。Node.jsだろうがDjangoだろうがRailsだろうがアプリケーション開発の土台としてきちんと機能する(もちろん環境自体を弄ることはできないけど)。

第二にコマンドだけでそれなりに運用が可能。ほぼherokuコマンドでなんとかなる。以下例。・アプリケーションの作成・ログの確認(heroku logs。リアルタイムでみたい時は後ろに--tailとつける) ・アプリのステータスの確認(heroku ps)psはprocessの略・環境変数の追加や確認(heroku config) ・設定済みのジョブの起動・動作中のCPUの数の変更・アドオンの追加(heroku addon)

他サービスとの関係

上記から、物を作ることを例にするとherokuは職人、VSCodeは工具、rubocopは工具のメンテ要員、rspecは作った物を知人など近しい人に評価をもらう行動、dockerは物が適当に使えているかを判断する場所、gitがお披露目という感じ。物を作る上で形成する職人の役目を果たすため大事。

よく使う主なコマンド(追追追加していく)

heroku run →基本のコマンド。heroku上で動作を実施したいなら絶対つける。頭に。(heroku run rails consoleとかheroku run rails db:migrateとか) heroku open →アプリケーションがどれだけできてるかブラウザで確認。感覚的にrails sと同じ感じする。 git push heroku master →gitにおけるgit push origin masterとかと一緒。もちろんgit addとgit commitは忘れない(他ブランチからherokuにpushする時はgit push heroku (今の開発ブランチ):(herokuのブランチ)で入力) heroku config:set ENV_VAR_NAME="value" →環境変数を追加できる(確認はheroku config)。多分あんまり使わない。

備考

https://devcenter.heroku.com/ja/articles/heroku-cli-commands

↑コマンドがわからないときはここを見れば大体わかる。

VSCodeについて

特徴

・エディタの一種

そもそもエディタとは、コンピュータ上でソースコードやテキストを編集するソフトウェアのことを指すが内実は色々あり、テキストエディタやプログラミング専用エディタなど様々。VSCodeはテキストエディタの方。ちなみにソースコードを書くこと専用なので、あくまで設計図を作るだけで実際にブラウザで動かせるようにするのはherokuとかの開発に即したアプロケーションの方。

・かなり軽量化されたエディタ

特にいうことはないけど動作しやすい。

できること

・拡張機能

左端の縦メニューバーExtensionsを押すと、vscode内で使えるさまざまな拡張機能が使える。MicroSoft製なので基本が英語だから日本語に変換する機能や、Sassの自動コンパイル(CSSに変換する)、カラーコードを打たなくても視覚的にCSSでの色指定が可能、色々ターミナルでコマンドを打つ必要はあるがエラー箇所をエラーコードではなくファイル内で教えてくれるdebug機能など。またファイルの保存と同時にブラウザを自動更新してくれる拡張機能もある。

・ショートカットキー

例：cmd + s 保存 cmd + f 検索 cmd + o ファイルを開く cmd + n 新規ファイル作成 Shift + cmd + e エクスプローラを開く Shift + cmd + s 名前をつけてファイル保存 cmd + p クイックオープンウインドウ(ファイルを開いたり、指定した行へジャンプできる入力窓。？だけ入れると何やるか促してくれる) Ctrl + Tab 開いているファイルの移動などなど・・・(コーディングについても色々あるけどキリがないし覚えられない)

もしコーディングがすんなりできるようになったら参考にする↓ https://skillhub.jp/blogs/234

Gitについて

GitとGitHub

めちゃくちゃ勘違いしてたけど、GitとGitHubは親と子みたいな関係。 GIt → プログラム開発時のバージョン管理を行うソフトウェア(オープンソースソフトウェア) GitHub → Gitの環境を提供するwebサービスの名前つまりGitHubはgitの機能を提供するアプリケーションに過ぎないので、Gitの使用自体は各エディタで可能(ローカルリポジトリだけ。リモートリポジトリにpushする時はGitHubのようなサービスが必要になる)

特徴

・分散バージョン管理

Gitを使うと共有フォルダ内(リポジトリ)にある一つのファイルを、複数の開発者がそれぞれコピーを使い手元で作業することができる。作業が終われば共有フォルダにpushしてそれぞれの変更を反映したファイルをマージすることで完成させる。

ちなみにこれの反対は「集中バージョン管理」で同じネットワーク内の同じ環境で作業するため共有は早いが、作業分担がしにくい(ってか多分パソコン使って制作物を販売する会社の仕組みは大体これな気がする)。そのため、それぞれが目標物を作り各々のタイミングで共有できる分散型の方がソーシャルコーディング大好きなエンジニアには好まれるらしい。また、上記の分散型で必要な共有ファイルを保管する役目を担っているのがGitHubなどのホスティングサービス。

・オープンソースソフトウェア

誰でも自由に改変できるソフトウェアなので、中身をプラベートにしてると突然「rm *」とかされて詰む。 ※内容の修正ができるという点でフリーウェアとは違う。

用語解説

追跡(fetch・merge)

ローカルリポジトリの中にリモート追跡ブランチというものがあり、リモートリポジトリの中にあるリモートブランチ(大体master)とローカルリポジトリの中にあるローカルブランチ(自分の開発環境(俺は大体develop))の間を取り持っている。役割としては読み取り専用でリモートリポジトリからローカルリポジトリへ情報を受け取る受け皿であるため編集機能などはない。後述のgit pullはリモートブランチから情報を引き出すfetchとそれをローカルブランチへ提供するmergeで成り立っているので相互作用ではなく三角関係で覚えておくといいかも。

重要なコマンド

git init ←リポジトリを新規作成(この場合ローカル) git add ←ステージング(コミット可能な状態にしておく) git commit ←ローカルリポジトリに作ったリポジトリ(というかファイル)を移動し保管。基本何をどう編集したかコメントを入れるため「commit」の後に「-m」をつけて””で囲みコメントを挿入する。 git push ←ローカルリポジトリに保存していたファイルの中でcommitしたファイルをリモートリポジトリに移す。アップロードと言い換えるとわかりやすい。またpushの後直接GitHubに移すか(origin (pushするリモートリポジトリ))、herokuなど別の開発環境を通す場合(heroku (pushするリモートリ...etc))でコマンドが異なる。 git log ←コミットしたファイルの記録を見る git checkout ←ポテパンの課題では主にブランチを切り替えるときに使ったが基本的には過去にコミットしたファイルをリポジトリから引き出すコマンド。(引き出す場合：git checkout (SHA1ハッシュ値かタグ)、ブランチ切り替え：git checkout -b (切り替え先のブランチ名を入力して同時に生成する)) git clone ←リモートリポジトリの中にある特定のリポジトリをコピーして自分のエディタにそのままペーストする。クラウドから焼き増ししたリポジトリを輸入する感覚なので、きちんと開発用ブランチで作業していれば元のリポジトリに影響を与えない(masterとかmainブランチで作業してたら詰む) git pull ←意味合いがcloneと似てるけど、自分がcloneやcommit・pushしていない内容が他の人からpushされてた時に抜粋して自身のローカルリポジトリに挿入するコマンド。pull(引く)の対義語であるpush(押す)がアップロードのイメージなので、こちらはダウンロードのイメージ。fetchとmergeを合わせたコマンド。

リカバリー

git pushをリモートリポジトリの本番環境でやった場合前回コミットしたものと整合性が取れなかったり、前にコミットしていたものをオミットしかねないので、やったら命かけて方々に土下座しに行った方がいい。俺はできる。ただ一応リカバリーはできるので、下記コマンドを入力 1.git branch misster (新しいブランチを作る) 2.git checkout master (マスターブランチを切る) 3.get fetch (リモート追跡ブランチを最新状態に更新しておく) 4.git reset --hard origin master (ローカルブランチのmasterを書き換えるため、先ほどfetchしたリモート追跡ブランチのmasterの内容に強制的に上書きする) 5.git checkout misster (プルリクを作る場合)(masterブランチにコミットする場合はそのまま下へ) 6.git merge master(プルリク作る場合)、git merge misster(masterブランチにコミットする場合) 7.git push origin misster(プルリク作る場合)、git push origin master(masterブランチにコミットする場合)

※同じmasterブランチの内容はリモートが親、ローカルが子供と相互関係になっているので、一つ書き直すと親子関係にあったファイルが赤の他人になる危険性がある。そのため違うローカルブランチで作業している人がリモートリポジトリに内容をpushしようとするとこの内容は地続きになっていないとエラーが出ることになるので、迷惑をかけるという話らしい。

大事なこと

複数の人が参加しているリポジトリで本番環境(master,main)で作業してはいけない。必ずの他に開発用branchを作る。

CircleCiについて

特徴

SaaSの一種

SaaSはクラウドからサービスを利用者が受け取るということはherokuのPaaSと一緒だが、SaaSは元々形が出来上がっているアプリケーションを取得することができる。そのため開発などはできない。(Software as a Service)。ちなみにWordやpower pointなんかもSaaS。なんならスマホでインストールするもの大体SaaS。

CI/CDサービスのクラウド型

・概要(名前だけだとよくわからんし内容がわからないことだらけなので)

Continuous Integration／Continuous Deliveryの略で日本語にすると継続的インティグレーション/継続的デリバリー(これでもよくわからんがとりま用語だけ)。高度なコーディングが求められた時になるべく時短でアプリケーションを完成させるため自動化テストの重要度が上がったことと、アジャイル開発のプラクティスの浸透(アジャイル開発：『計画→設計→実装→テスト』といった開発工程を機能単位の小さいサイクルで繰り返す開発手法)(プラクティス：アジャイルを円滑に行うためにチームでまとまるための話し合いや取り組み姿勢を明確にする開発のための手段の一つ)したことによって必要性が高まった。クラウド型は文字通りクラウドからアプリケーションを取得するが、メリットはコストがかからない(一部)、自前のサーバーが必要ないなどがある。デメリットは拡張性がないためアップデートなど環境の変化は管理者に一任されること。

・内容

１テストコードを書いた際、任意のタイミングを設定すれば自動でテストを行なってくれる。２テストをパスしたコードの変更を自動でリリースし、バグがあればロールバッグを行なってくれる。３流としては、開発環境で書いたコードをpushした後CI/CDで解析、build、テスト、デプロイまでほぼ自動で行い、各環境(開発へのリターン、本番でマージ、ステージング、テスト環境など)に移動する。簡単にいうと、いちいちコードを書いてテストした後間違ってたらそれを目視で確認して手動で直すことまでやるとアホほど時間かかるから自動でやっちゃえというのを請け負ってくれるアプリケーション。

備考

CI/CDについては下記のサイトが概要がわかりやすかった。 https://www.sbbit.jp/article/cont1/81640#head3

CircleCIの基本についてわかりやすい(やっぱQiitaだわ) https://qiita.com/gold-kou/items/4c7e62434af455e977c2

rubocopについて

特徴

・リンター

多分Rubyのロボコップでrubocop。Rubyの静的コード解析(コードの違和感やインデントの位置の修正などを教えてくれる)を行うツール。なくても開発をする上では問題ないがあった方が絶対いい。しかし、railsのファイルでrubocopを使うと徹頭徹尾.rbのファイルしか参照しないので、HTML,CSS,JavaScript、左記ファイルの中のrubyコードは読み取ってくれない上に違和感を警告してくれるだけなのでそれが合っているかどうかはプロジェクトの方針次第なところもあるらしく、便利ではあるが万能ではない。

使い方

1.Gemfile group :development do gem 'rubocop', require: false ←これを入力する(CircleCi導入するとややこしくなるのでエラーとか出たらちゃんと見る) end $gem install rubocopとターミナルに入力 2.コードを書いた後、ターミナルに入力 $ rubocop ←解析して結果をターミナルに吐き出す。 $ rubocop --help ←ヘルプを参照できます。 $ rubocop --lint( または rubocop --rails ) チェック規則は以下の4つに分類されますが --lint がLintのみチェック、 --rails がRailsのみチェック 1 Style (スタイルについて) 2 Lint (誤りである可能性が高い部分やbad practiceを指摘する) 3 Metrics (クラスの行数や1行の文字数などに関して) 4 Rails (Rails特有のcop) $ rubocop --auto-gen-config ←.rubocop_todo.ymlに警告を一旦退避する。.rubocop.ymlに "inherit_from:.rubocop_todo.yml" と書くのを忘れないでください。 $ rubocop --auto-correct ←直せる箇所を自動で修正してくれます(最初は使わないで警告されたコードを眺めてみることをお勧めします)。

Potepan-sgtom / rails_kadai4_hotel_service

メモ #6