もふのアウトプットブログ

Webエンジニアへの転職を目指すもふのプログラミング学習アウトプットブログ

【月報】2023年6月の振り返り

5月に引き続き月報第二弾です。
前回の月報はこちら↓ mof-51.hatenablog.com

やったこと・実績など

  • Linuxの学習
  • GitとGitHubの学習
  • 技術記事のアウトプット
  • 学習時間:67h

とにかくGitとGitHubの学習にのめり込んだ一ヶ月でした。
コマンドを打った時にGitやGitHubではどういう動きをしているのかをきちんと理解することに重点を置いて学習できました。

また、Git学習中に引っかかったところをQiitaへ投稿しました。 qiita.com 言葉で説明することで自身の理解度の向上につながることを実感したので、アウトプットする機会は増やしていこうと思います。

先月の目標達成度

目標1:学習時間を増やす

先月の学習時間82.5hに対し、6月は67hでした。
学習時間を増やす目標を立てていたにもかかわらず減ってしまいました…こちらは反省点です。

原因は2つです。

  • 1日のスケジュールの中での学習時間を定めなかった
  • 朝活が思うようにいかずモチベーションが一時下がってしまった

来月から職場が変わり7月中は全日出社なので、朝の学習時間の確保が必須です。
多少無理にでも早起きして学習時間を作ります。

目標2:集中力を上げる

こちらは比較的うまくいきました。
細かいことですが

  • 学習している間はスマホの通知を切る
  • デスクと椅子の高さなど環境を整える
  • 学習する時は「勉強するぞ!」という意気込みで全力投球する

特にスマホは集中力の大敵でした。
通知が来て画面が表示されるだけで一瞬集中が途切れてしまう。
通知オフは大成功でした。

来月の目標と学習の進め方

  • 平日5時起床を定着させる
  • 朝学習を継続する
  • 金曜日は学習休暇日にする
  • アウトプット記事を1つ以上書く

すべてマストです。
メリハリをつけて学習を継続するのが目標です。

感想と意気込み

Gitの学習に入ってから「いよいよ本格的になってきたぞ…!」という感じです。笑
職場が変わり思い通りに学習できないこともあると思いますが、凹まず「どうすれば立て直せるか」をすぐに考えて対処しながら進めたいと思います。

【月報】2023年5月の振り返り

4月11日にHappiness Chainというモダン技術が学べるスクールに入会し、プログラミングの学習を始めました。
5月に学んだことと言いつつも月報を書くのは初めてなので、学習開始時からの振り返りをしたいと思います。

学習内容

  • Progate
  • マークダウン記法
  • Web技術の基礎
  • Vimの基礎
  • Linuxの基礎

学習内容を振り返って

コーダーをしているためHTMLとCSSに関してはすんなり進めることができました。
JavaScriptに関しては先入観で苦手意識がありましたが、Progateでの進め方のおかげで理解しやすかったなという印象です。

その他、SQLVIMLinuxに関しては完全に初めて触るものでした。
本やUdemyを活用しながら学習を進めましたが途中理解しにくいところも多々あり、納得がいくまでググりブラウザのタブ数が大変なことになるのは日常茶飯事でした。笑
ただ、もともと物事の仕組みや理屈を知ったり考えたりするのが好きなので、楽しみながら学習を進めています。

Linucの最強問題集を全問正解するという課題は結構ハードでした、、何日格闘していたかわかりません。
Linux自体はまだまだ奥が深く実務で使うとなるともっと難しいんだと思いますが、おかげでLinuxに関する抵抗は今のところゼロになりました。

「もうちょっと勉強したい…!」という気持ちが勝って夜更かし気味なので、ここは今後調整が必要かなと感じています。

改善点と6月の課題

学習時間について

学習を始めてからの総学習時間が129時間でした。5月だけだと82.5時間。
正直もうちょっとできたなと感じます。
学習時間が多ければ良いというわけではないと思っていますが、もともと時間の使い方が下手なので、学習を習慣化するよう平日用と休日用で学習時間を組み込んだスケジュールを作って固定化してみようと思います。

集中力について

スクールの朝活に何度か参加してみたのですが、頭が冴えきらず効率的に学習できませんでした。
5時起床→ラジオ体操→朝学習6時起床→軽食→朝学習など模索してみましたがいまいちだったので
6月中に朝の学習時間を集中力を上げて有効的に使える方法を探し出します。 また、集中力とモチベーションを持続させるため、一週間の中でリフレッシュ日を設けるなどの対策もとっていこうと思います。

まとめ

頭を悩ませたり調べたり理解すべきところはたくさんありますが、今のところは楽しく学習できています。
知れば知るほど楽しくなっていっていて、プログラミングに関する理解が進んでいる実感もあります。
この気持ちは6月も引き続き持ちつつ、課題を改善していきたいと思います。

Vimの基本操作まとめ

Vimはコマンドを覚えることで爆速操作ができますが、用意されているコマンドはかなり多いです。 ここではよく使うコマンドを用途に分けて紹介します。

はじめに

Vimには4つのモードがあります。

インサートモードはテキストを入力するモードなので、使用するのは他のモードへ切り替えるコマンドのみです。
コマンドは主にノーマルモード・コマンドモード・ビジュアルモードで使用します。

モードの切り替え

ノーマルモード→インサートモード

キー 動き
i インサートモードに切り替え、カーソルの左から挿入
a インサートモードに切り替え、カーソルの右から挿入
o インサートモードに切り替え、カーソルの下に空白行を挿入
O インサートモードに切り替え、カーソルがある行に空白行を挿入

インサートモード→ノーマルモード

キー 動き
esc ノーマルモードに切り替え

ノーマルモード→コマンドモード

キー 動き
: コマンドモードに切り替え

ノーマルモード→ビジュアルモード

ビジュアルモードではカーソルの移動ができないので、あらかじめカーソルを操作したい位置に移動させてから切り替えます。

キー 動き
v ビジュアルモードに切り替え

各モードでのコマンド

コマンドは入力後Enterで実行します。

ノーマルモード

画面表示系

キー 動き
:set number 行番号を表示

移動系

キー 動き
k 上の行に移動
j 下の行に移動
h 左に移動
l 右に移動
:10 10行目に移動(数字を変えると移動先の行も変わる)
$ 行末に移動
0 行頭に移動
^ インデントの先頭に移動
{ 上の段落に移動
} 下の段落に移動
[[ 上のセクションに移動
]] 下のセクションに移動
G 最終行に移動
:1 または gg 先頭行に移動
Control + o 移動前の場所に戻る

ファイル保存・終了

キー 動き
:w ファイル名.拡張子 名前をつけて保存
:w 上書き保存
:q 編集終了
:wq 保存して編集終了
:q! 保存せずに編集終了

編集系

キー 動き
x カーソルがある位置の文字を一文字削除
X カーソル位置の左の文字を一文字削除
dd 一行削除
2dd 2行削除(数字を変えると消える行数も変わる)
dw 単語の削除(単語の先頭にカーソルがある状態で。スペースで区切られているところを「単語」と認識する)
u 前回の操作を取り消す(undo)
Control + r undoを取り消す
yy 一行コピー
2yy 二行コピー(数字を変えるとコピーする行数も変わる)
p 下の行にペースト
P 現在の行にペースト
. 前回のコマンドを再実行
J 二行を一行に連結(一行目にカーソルがある状態で)

検索と置換

キー 動き
/テキスト テキストを検索
n 次の検索結果に移動
N 前の検索結果に移動
R カーソルのある位置から一文字ずつ置換
:%s/検索するテキスト/置換するテキスト/g 一括置換
:%s/検索するテキスト/置換するテキスト/gc 検索結果をひとつずつ確認しながら置換

コマンドモード

キー 動き
:! コマンド コマンドを実行
:!! 前回のコマンドを再実行

ビジュアルモード

キー 動き
> インデントを右に移動
< インデントを左に移動
y コピー
j 選択範囲を下の行に拡大
k 選択範囲を上の行に拡大
:norm I テキスト 行頭に挿入
:norm A テキスト 行末に挿入

さいごに

よく使うコマンドだけでもこれだけの数があります。
丸暗記はできないと思うので、使って慣れて手で覚えるのが一番良さそうですね!

Web技術の基礎について

書籍「プロになるためのWeb技術入門」を読了しました。
ここではWebの基礎となる部分のルールや仕組みに関するアウトプットです。

はじめに

WebサイトやWebアプリなどブラウザからURLでアクセスするものは、すべてHTTP(Hypertext Transfer Protocol)に則って行われています。 HTTPにはさまざまなルールや仕組みがあります。今回はその中の基礎部分と関連知識についてです。

プロトコル

プロトコルは通信を行う際の約束事です。現実の世界でいうと法律のようなものですね。
WebサイトやWebでブラウザとWebサーバが通信する際に使われるプロトコルが、先述したHTTPです。

ひとえに「通信」といっても、Web以外にもさまざまなものがあります。
プロトコルは通信するアプリによって異なり、Webブラウザ通信にはWebブラウザ通信用の、メール通信にはメール通信用のプロトコルがあります。
メールの場合は、送信にはSMTP(Simple Mail Transfer Protocol)、受信にはPOP(Post Office Protocol)またはIMAP(Internet Message Access Protocol)というプロトコルが使われます。
法律でも、人の権利を守るための民法や、労働に関する労働基準法などがあるのと同じですね。

他にも、ファイル転送をするためのFTP(File Transfer Protocol)なども存在し用途によってさまざまなものがありますが、これらをまとめてプロトコルまたは通信プロトコルといいます。

ポート番号

上記で紹介したHTTPの中に「Webブラウザでの通信は80番のポートを使ってね」という約束事があります。
ポートとはインターネットとコンピュータをつなぐ通信の出入口です。
Webブラウザやメールなど主要アプリで使われる出入口は番号が決まっています。

たとえば、友人にメールを送るとしましょう。
送信したメールは自分のコンピュータからまずインターネットに出ていきます。この時は25番の出口を使います。

次にメールを受け取る友人の場合です。
インターネットで運ばれてきたメールが友人のコンピュータに入る時は110番の入口を使います。
Webブラウザでの通信の場合は80番でしたね。

このように、ブラウザやメールなど主要アプリで使われるポート番号は世界共通で決められており、受け取るアプリケーションによって異なります。

リクエストとレスポンス

Webアプリにアクセスすると目的のアプリが表示されます。
当たり前のように感じますが、これはリクエスレスポンスという2つの動作で成り立っています。

リクエスはWebサイトにアクセスした人の操作に起因するものです。

たとえば、Amazonにアクセスしたとしましょう。
AmazonのURLにアクセスしたとき、ブラウザはWebサーバーに「Amazonのサイトを見せてください」と要望を出しています。これがリクエスです。
これに対してサーバーは「Amazonのサイトですね!どうぞこちらです!」とAmazonのサイトのデータを返してくれます。これがレスポンスです。
このやりとりはAmazonのトップページにアクセスした時だけではなく、別のページに移動したり商品をカートに追加した時など、サイトを利用している人が通信を含む操作を行なった時に毎回発生します。

ステートレスとステートフル

HTTPの特性としてステートレスというのがあります。
ステート(state)は「状態」を意味しますが、Webサーバが状態を保持しないというのがステートレスです。

Amazonで実際に商品を購入するとしましょう。Amazonでの買い物はログインが必須ですね。
ログインすれば、Webサーバは「田中さんがアクセスしている」とわかります。

次に、カートに移動するとしましょう。
ブラウザは「カートを見せてください」とリクエストを送信しますが、Webサーバは状態を保持できません。
「あなたは誰ですか?カートの情報はログインしていない人には見せられません」と言われてしまいます。
Webサーバはあなたの名前も、ログインしたという事実も覚えていません。

現実にはこんなことは起きませんが、それは後述するクッキーという仕組みによってカバーされているためです。
本来HTTPでのWebサーバは「リクエストに一度レスポンスを返したら、リクエストの内容は覚えていない」のです。

ステートレスに対して、前回までの情報を覚えているのがステートフルです。FTP通信などがこれにあたります。
ステートフルの場合は前回までの情報を記憶しているため、先ほどのAmazonを例に例えると

ブラウザ「商品一覧を見せてください」
Webサーバ「どうぞ、商品一覧ページです」
ブラウザ「カートを見せてください」
Webサーバ「田中さん!カートですね、ログインしてるのでOKですよ。田中さんのカートです、どうぞ!」

…という感じになります。
こちらが実際の動きですよね。

では、HTTPはステートレスなのになぜ情報を記憶しているのでしょうか?
そこで登場するのがクッキーです。

クッキー

クッキーはブラウザがテキスト情報を保存する機能です。
ステートレスでお伝えした通り、Webサーバは情報を保持しません。その代わり、IDを発行してくれます。

ログインに成功すると、Webサーバは「田中さんですね!認証OKです!これIDです。僕情報覚えられないので、次回からこれ見せてください!」という感じでセッションIDというものを発行してくれます。
このセッションIDはブラウザのクッキーに保存され、同じWebサイトである限りリクエストのたびにWebサーバに送信されます。
そのため、実際のAmazonのサイトのように一度ログインしたらログイン情報が保たれるというわけです。

クッキーが保存するのはログイン情報だけではありません。
ログインしていないECサイトなどでも、過去にアクセスして商品情報を見ていた場合「閲覧履歴」として表示されることがあります。
これも、ブラウザが前回の情報をクッキーで保存しており、リクエスト時に送信することによって表示されています。

さいごに

Web技術の基礎中の基礎ですが、普段Webを使っている裏側でどんなことが行われているか少しでも想像できたら幸いです。
また、書籍「プロになるためのWeb技術入門」はWebを体系的に学べる上、インターネットの始まりから進化の歴史を中心にWebの本質が理解できる良書です。
図解や噛み砕いた説明が多く初学者にも読みやすいので、気になった方はぜひ読んでみてください!

HTTPのステートレス性に基いたログイン状態の管理について

はじめに

「一度ログインしたらログアウトするまではログイン状態のまま」
サービスを利用する側として当たり前だと思っていましたが、プログラミングの学習を行う中でルールや仕組みを知ったので
アウトプットのための記事を作成します。

ログイン機能の仕組みについて

ログイン状態の管理の前に、予備知識として簡単にログイン機能の仕組みについて触れたいと思います。

たとえば、メールアドレスとパスワードでログインできるサービスがあったとします。
ログイン画面でのユーザーの動作としては以下の流れです。

  1. メールアドレスを入力
  2. パスワードを入力
  3. ログインボタンをクリック

この動作に関してプログラム側では以下のような処理が行われています。

  1. ユーザーが入力したメールアドレスとパスワードを取得しサーバーに送信
  2. データベースにあらかじめ登録されているユーザーのログイン情報と一致するかを照合
  3. 一致した場合はログインが成功し、サーバーがセッションID(後述)を発行

これで問題なくログインはできるのですが、ひとつ問題があります。 それがHTTPのステートレス性です。

HTTPのステートレス性について

HTTPはHypertext Transfer Protocol(ハイパーテキストトランスファープロトコル)の略で、インターネット上に公開されたWebサイトやWebアプリで通信を行うためのルールのことです。
HTTPにはステートレス性というのがあり「サーバー側は状態を保持しない」という特性があります。
ログイン機能における状態とは「ユーザーがログインしている状態」のこと。
つまりユーザーがログインをしてもサーバーはログインした情報を保持しないので、ユーザーがリクエストを送る度にログインした情報が消えてしまうということです。

しかし、冒頭で述べたとおりWebアプリは「一度ログインしたらログアウトするまではログイン状態のまま」というのが一般的です。

ではこの仕組みはどのように構成されているのでしょうか。

ここで登場するのがセッションIDCookie(クッキー)です。

セッションIDCookieとは

セッションIDは、入館証のようなものです。
入館証は、ログインした際にサーバーが発行してくれます。
この入館証の情報はブラウザのCookieが保存していて、ユーザーが何かリクエストをする度にこの入館証を見せる必要があります。
Cookieはブラウザの機能の一部で「ブラウザで情報を保持する機能」です。

実際のWebアプリだと以下の動きをしています。

  1. ログインするとサーバーがセッションIDを発行する
  2. セッションIDをブラウザのCookieが保持する
  3. ユーザーが別ページへのリンクをクリック(リクエスト)したとする
  4. リクエストと同時にブラウザが保持しているセッションIDが送信され、ログイン状態を保持したまま別のページへ移行できる

まとめ

  • ログイン情報はサーバーが発行したセッションIDで管理される
  • ログイン情報はサーバー側では保持できない
  • セッションIDの情報はブラウザのCookieが保持している
  • セッションIDはユーザーがリクエストする度に送信される