GitHub Pagesの使い方
最近、GitHub Pagesを学習の一環として利用させていただきまして、結構色々引っかかって数日停滞してしまったので、備忘録としてブログに残したいと思います。
GitHub Pages とは
GitHub Pagesは静的サイト(HTML, CSS, JavaScript等で作成)のホスティングサービスです。自分でサーバを用意したりすることなく、従来より非常に簡単にWebページを公開することができる点でとても初学者に優しい魅力的なサービスとなっています。
記事の公開方法
記事の公開方法は以下のProgateのサイトが本当にわかりやすかったのでまずはこちらを参照ください。
基本的にGitHubへPushした後、該当リポジトリのSetting→PagesにてBranchの項目で公開したいブランチを選択し、Saveするというのが基本的な流れになります。
「Branch」の項目が「None」となっていると思いますので、これをデフォルトブランチ(リポジトリが作成された時期に応じて、「master」または「main」)に変更して
「Save」ボタンを押すことでURLが表示されます。
Saveを押しても私の場合はURLが表示されませんでした。URLが表示されるのには少しタイムラグがあるようなので焦って何度もやらなくてもOKです!!!私はここで何度もやり直しましたが…
公開してみたサイト
上記がGitHub Pagesを用いて私が公開した静的サイトです。まだまだ作成途中ですが、適宜更新して完成させていきたいと思います。
引っかかった部分
最も躓いたのは、TOPページ以外の表示の仕方がわからなかった点です。READMEが表示されたため、間違ったページをアップロードしてしまったのだと勘違いして何度もデプロイを試みたり、時間を空けてみたりしましたが、間違っているわけではないためエラーメッセージすら出ず、途方に暮れていました。
https://yrdwsn.github.io/resume/startbootstrap-resume-gh-pages/index.html
結果として、URLをディレクトリ構成そのままに入力したところ、目的のindex.htmlを表示することができました。上記のURLが表示したかったページのURLなんですが、これに辿り着くまでに微妙に時間がかかりました。 本当に単純な問題だったのですが、初学者にとってはこんな簡単な問題を解決するのにも意外と時間を浪費してしまうんですよね…
間違っている情報
- ファイル名がindex.htmlでないと公開できない
簡単な問題が解決できなかった理由として、間違った情報を見つけてしまったからという問題もありました。 最初ファイル名を別の名称にしていたので、どこかのWebサイトでこれが書かれていたときはこれだ!と思ってファイル名を変更したのですが、ファイル名、リポジトリ名等はなんでも大丈夫みたいです。
まとめ
GitHub Pagesは無料で始めることが出来て、とてもシンプルな操作のみで自分の作ったサイトを公開できるので本当におすすめです。焦ってたくさん失敗もしましたが、すごく勉強になりました。
HappinessChainに入会して1ヶ月経過しました
HappinessChainを5/27に入会して1ヶ月が経過したのでこの1ヶ月を振り返ってみようと思います!
ちなみに1ヶ月間のGitHubはこんな感じです。
毎日勉強しないと草が途切れてしまうのが嫌で、どんな時でも1日1時間は勉強するようになりました。この時は綺麗な芝生が生え揃っていたのに数日後勉強中に寝落ちしてから寝落ちスパイラルに入ってしまい、せっかくの芝生に穴を開けてしまって大ショックです🥺
6月の振り返り
5/27から6/30までの勉強時間は84hでした!正直もうちょっと勉強して100時間を目標にしてみたい気持ちはありますが、疲れて挫折してしまうよりは全然いいですね。コツコツ頑張ります!
1週目
以前プログラミングスクールでProgateをまるまるやったのと、それ以前にも何度もやったことがあったのでNode.js以外は飛ばしましたが、後半HTML/CSSのアウトプット課題でかなり時間を費やすことになったので、やっておいても良かったかなとは思いました…
そして日報見ると1週目にVimやらLinuxやらもやってて謎に爆速で自分にびっくりです…
2週目
2週目は主にGitをやりつつやり残したLinuxの勉強もやってました。Gitはあまり理解してなかったのですが、理解してないことの恐ろしさは理解できた
というか、今までよくあやふやな知識でやってたな…と怖くなりました。
3週目
3週目はHTML/CSSの動画の視聴がメインでした。夜に動画学習をするとあまりに眠くて動画を見終わるまで1週間くらいかけてしかも終わらなかった記憶があります。1週目の爆速具合はなんだったんでしょうか…。
4週目
最終週からは動画の残りと、いよいよHTML/CSSのアウトプット課題に入ります。最初はすぐ終わるだろと思っていましたが未だに提出したものを修正中という亀の歩みです。
でも、一つ一つ実装していくうちに理解が深まったり、色んなことが出来るようになったり、最初よりは格段に早くなったりと良いこと尽くし
で本当に楽しいです。早く完成して次のカリキュラムに進みたいですね〜
まとめ
6月の勉強具合はまぁまぁというところですかね?この調子で今月もゆるく勉強を継続して着実に成長していきたいです。
プロになるためのWeb技術入門を読了しました
初めに
1週間ほどかけてプロになるためのWeb技術入門を読みました。
まだまだ完全に理解したとは言い難いですが、少しでも理解を深めるために気になった用語をまとめてみようと思います!
ステートフル(stateful)
ステートフルを一言で言えば、「以前の状態を保持していること」
です。
サーバがクライアントの状態を保存しており、前回までのやり取りに応じてレスポンスを返してくれるためやり取りがスムーズ
というメリットがあります。しかしクライアントの状態をその都度把握する必要があるため、クライアントの数と比例して負荷も増えるというデメリットがあります。
ステートフルなプロトコル
ステートレス(stateless)
状態を保持するステートフルに対し、「状態を保持しないこと」
を指します。サーバが以前の状態を保持する必要がないためシンプルで実装も簡単
である反面、処理に必要なデータを全て送信しなければならないのでデータ量が多くなる
というデメリットがあります。
ステートレスなプロトコル
- HTTP
- DNS
- IP
そもそもプロトコルって?
コンピュータ同士で通信をするための約束事
のこと。
クライアントとサーバについて
クライアントとサーバとはそれぞれコンピュータ上で動作するソフトウェア
であり、サービスを提供する側をサーバ、サービスを利用する側のことをクライアントと言います。ちなみにSafariやGoogle Chromeなどのブラウザ
はWebクライアントにあたります。
リクエストとレスポンス
クライアントからサーバに対して要求することがリクエスト
にあたり、その要求に対する応答がレスポンス
になります。
Cookie
ステートレスなHTTPで状態を保持できるようにするための拡張機能
。
クライアントが最初にアクセスした際に、サーバがHTTPレスポンスのヘッダを利用して情報を送ります。そしてクライアントが同じサーバにアクセスする度に受け取ったCookieをサーバへ送ることでユーザの識別が可能となります。
IPアドレス
簡単に言えばインターネット上の住所のようなもので、インターネットを利用する全ての機器に割り当てられ、通信相手のコンピュータを識別する
のに使われます。
DNS
人間にとってわかりにくい数字の羅列であるIPアドレスとそれを文字列にしたドメイン名を対応づけて変換してくれる仕組みです。
TCP/IP
TCPとIPの2つを組み合わせたプロトコル。クライアントから受け取ったHTTPリクエスト等の情報をパケットに分割して送信し、再度組み立ててからサーバへ送る役割を持っています。
ポート番号
IPアドレスによってコンピュータを識別した後、該当のコンピュータのどのアプリケーションにパケットを渡すかを識別してくれるものです。
IPアドレスは番地まで、ポート番号は部屋番号という例えが一番わかりやすいなと感じました。
また、代表的なプロトコルで使用されるポート番号は「ウェル・ノウン・ポート」
と呼ばれており、HTTPは80番ポートなどあらかじめ決められています。
参考文献
GitHubの草の色について
初めに
最近GitHubのアカウントを新規で作成して少しずつ利用しているのですが、1日1コミットでも草の色が濃い緑色になっていて不思議に思い、GitHubの草の色
について調べてみることにしました。
GitHubの草とは
まずGitHubの草
とは、GitHubのコントリビューション
のことを指します。
コントリビューションがカウントされると、プロフィールページのコントリビューションカレンダーに色がつく仕組みになっています。
学習を始めてまだ一週間も経ってませんが、ご覧の通り深い緑色になっています。
草の色は活動量に比例して濃くなる
ので、私のまだ少ない活動量では濃いはずがないのでは…という疑問が湧きます。
草を生やすには
そもそも何をすれば草が生えるのか、GitHubドキュメントを確認したところ、以下のように記載されています。
(GitHubより引用)
プロフィールページでは、特定のアクションがコントリビューションとしてカウントされます:
リポジトリの既定のブランチまたは gh-pages ブランチへのコミット
- ブランチの作成
- イシューのオープン
- ディスカッションをオープンすること
- ディスカッションに回答すること
- プルリクエストを提案すること
- pull request レビューの送信
とりあえず初学者が草を生やす手段として一番手軽なのが一つ目にあるリポジトリの規定のブランチまたはgh-pagesへのコミット
であり、こまめにコミットをする
ことで簡単に草を生やすことが出来るようです。
※ちなみにリポジトリを削除してしまうと草が消えてしまうので注意が必要です
草の色は何で決まるのか
では、結局草の色は何で決まるのでしょうか。
こちらにそのまま答えが書いてありました。要するに、草の色は1年間の活動量で相対的に決まる仕組み
になっており、普段活動量が少ない人は少ない活動量でも濃い緑となり、逆に普段から活動量の多い人はたくさん貢献しないと色が濃くならないという仕組みになっているようです。
結論
したがって、私のGitHubに生えている草の色が濃いのは正常で、活動量が増えることで一定の基準を超えると薄く変化する
ようです。
せっかく濃い草が生えているのでなんだか少し残念な気もしますが、学習し始め頃に生えた草が薄くなるよう毎日学習を続けていきたいと思います。