Happiness Chain Euforia 4ヶ月目の振り返り

8月の学習の振り返りをしていきます！

8 月の学習時間

8 月中の学習時間はトータルで 68.5 時間 でした。

正直、少ないな...って感じましたね。 他のHC生の報告を見てると、みんな100時間 / 月は当たり前に超えててほんとにすごい。 でも急に学習時間を一気に増やすのは大変なので、来月は80時間を目指してみます。

進捗状況

課題の進捗状況についてです。 8 月中に完了したカリキュラムは以下の通りです。

• Django（30%）

良かったところ

Django①（基礎編）

Django学習を始めるにあたって、 まずは、Udemy講座と公式チュートリアルを主に進めました。 特に公式チュートリアルは1周目で内容を理解するのが難しく、2周目でやっとDjangoのルールみたいなものを掴めてきた気がします。（掴めたとは言ってません）

公式チュートリアルに取り組んだ際の感想については、こちらの記事で書いております↓

otaki0413.hatenablog.com

また、同じHC生が紹介されていた下記書籍が初学者にめちゃくちゃ分かりやすいので、興味ある方はぜひ読んでみてください。 個人的には公式チュートリアルやる前にこれを読みたかった...！！

現場で使える Django の教科書《基礎編》［4.2 LTS 対応版］

Django②（ECサイト作成）

基礎固めを終えたあとは、実践編として「ECサイト作成」に取り組みました。 こちらの課題は、現在進行系で進めているのですが、結論むずいです。 はじめはDjangoの基礎をある程度積んだから、意外といけるのでは？と思っていましたが、そもそもの環境構築の部分でめちゃくちゃ詰まりました。 なぜなら、本課題ではDjangoアプリをデプロイするという作業があるので、これまでのローカルの開発環境だけでなく、デプロイ先の本番環境を考慮したコードを書く必要があるからです。 初回デプロイ時には、エラーの嵐でしたが、公式ドキュメントとにらめっこしながら一個ずつエラーを解消したので今では良い思い出ということにしておきます（笑）

改善点

ケガをしない身体づくり

8月の終盤あたりから腰に違和感を感じ始めて、9月は背中の方まで痛むようになりました。 接骨院の先生には、下半身が硬いのでストレッチをやったほうが良いと言われたので、毎日しっかりストレッチするつもりです。

やはり何をするにしても優先すべきは「自分の健康」です。 健康でないと仕事も遊ぶこともできませんから、ちゃんと自分の身体を大切にしようと思います。

9 月の目標

• 80 時間勉強する
• 腰痛を治す
• 毎日タイピング結果を投稿する
• 毎日学習する
• EC課題を完了させる

『Django 公式チュートリアル』をやりました！

本記事では「Django公式チュートリアル」を終えた感想を書いていきます。

docs.djangoproject.com

良かったところ

• Django開発の基礎がざっくり理解できる

  • 正直なところ、チュートリアルの内容は初学者にとって少し難易度が高いように感じました。私の場合、2周くらいやってようやくDjangoというフレームワークの概要をつかめた気がします。 チュートリアルを通して学べることを下記に挙げてみました。Django開発の基礎はしっかり詰まっているのですが、各章に専門用語が多いため、ドキュメント内を参照しながら進める必要があるかと思います。

  • チュートリアルを通して学べること

    • プロジェクト作成
    • アプリ作成
    • ビュー作成
    • モデル作成
    • データベース設定
    • ルーティング設定
    • テンプレート作成
    • 管理サイト設定
    • テスト作成

悪かったところ

• 説明が難解で分かりづらい

  • 初学者には理解しがたい概念が多いので、データの流れを図示したもの（MVTパターンなど）が入ったりした方がより分かりやすくなると思いました。

  • よくも悪くもドキュメントのボリュームが多く充実しているので、全部を理解するのは大変です。参照先のドキュメントのリンクも多いため、すべてを追うのは厳しい気がします。

学んだところ

• Djangoのモデルについて

  • Djangoにおけるモデルは、データベースのテーブルとカラム定義を管理するための専用クラスです。つまり、DDLを直接実行するのではなく、モデルを変更し、それをマイグレーションとして適用することでデータベースを変更できます。

  • 実際にモデルの変更をデータベースに反映するためのフローは、次の通りです。 ①python manage.py makemigrations <アプリ名> → モデルの変更内容をマイグレーションファイルの形で生成する
    ②python manage.py migrate → データベースにマイグレーションを適用する
    

  • また、Ruby on Railsにも同様のモデル機構があるようですが、こちらはモデルにはテーブルのスキーマを直接持たせず、マイグレーションファイルで管理するようです。モデルだけ見てDB構造が直感的にわかるのは、Djangoの強みかもしれませんね。

• Django Adminサイトについて

  • Django固有の機能で、個人的にすごいと思ったのは、Django adminサイトの存在です。Django adminサイトでは、アプリケーションに登録したモデルのデータを簡単に閲覧・編集でき、基本的な管理機能が揃っているため、開発者にとって非常に便利です。他のフレームワークだと管理画面を自前で用意する必要がありますが、Djangoは最初から用意してくれるのはありがたいです。

難しかったところ

• ビューの使い分け

  • Djangoではビュー関数を作る際に、関数ベースドビューとクラスベースドビューの大きく2種類に分かれます。クラスベースドビューはコード量が少なく可読性が高くなる一方、裏側の処理が見えないので慣れるまでは難しく感じました。

  • またチュートリアルで取り上げているIndexViewとDetailViewはテンプレートにわたす各コンテキスト変数が自動で決まるので、その辺りのルールも覚える必要があるのでちゃんと覚える必要がありそうです。

Happiness Chain Euforia 3ヶ月目の振り返り

7月の学習の振り返りをしていきます。

7 月の学習時間

7 月中の学習時間はトータルで 76.5 時間 でした。

課題の進捗状況はそれほど悪くないですが、学習時間100時間を超えたかったです。

進捗状況

さて課題の進捗状況についてです。 7 月中に完了したカリキュラムは以下の通りです。

• SQL（100%）
• DB設計（100%）
• REST（50%）

良かったところ

SQL

SQL学習は指定の書籍を中心に進めており、これまでのHC課題の中ではアウトプット量の面で最も大変だった印象があります。 書籍に付属するドリル問題の量がかなり充実しているおかげで、SQL文を書きまくることでSQLの基礎体力を養うことができたと実感してます！ 以前は素のSQLへの理解がないまま、PrismaやMongooseといったORMを感覚的に使っていましたが、実際のSQL文に置き換えてどんな処理が行われているかを理解できるようになったのは大きな収穫です。

実際に取り組んだ書籍はこちらの記事で感想を書いてます！

otaki0413.hatenablog.com

DB設計

DB設計の課題では、書籍を使ったインプット学習と某SNSのデータモデリングを行いました。これまで、DB設計の分野に手を出したことがなかったため、ER図や正規化という言葉は知っていても具体的に何をするのか分かっていない状態でした。 しかし、書籍や課題を通じて正規化のプロセスを理解し、実際にER図を構築する知識もある程度身につけることができました。 現在の自分に不足しているのは経験値なので、今後たくさんアプリケーション開発を進める中で、DB設計の知見を深めていきたいと考えています。

実際に取り組んだ書籍はこちらの記事で感想を書いてます！

otaki0413.hatenablog.com

改善点

毎日学習する

毎日学習という目標を掲げていましたが、残業疲れ等で全く学習しない日が数日ありました。土日にまとめて学習するより、毎日1時間でもいいから継続学習する方が重要なので、来月こそは達成できるように頑張ります。

8 月の目標

• 100 時間勉強する
• 毎日タイピング結果を投稿する
• 毎日学習する
• ジムに週 3 で通う
• REST の課題を完了する
• Django というフレームワークを理解する

REST について理解する

REST API とはなにか？

REST API とは一言でいうと REST に則って設計された Web API のことです。つまり Web API と REST が何を意味するかがわかれば、REST API の大枠をつかむことができると言えるはずです。 それでは「Web API」と「REST」がなにかを解説していきます。

① Web API とは？

まず前提として API（Application Programming Interface） とは、機能やデータを外部から呼び出して利用する規約のことです。API という言葉の定義自体が広く、種類も沢山あるので一括りにしてまとめるのが難しい概念でもあります。

代表的な API としては、以下が挙げられます。

• ライブラリ API
  • Python をはじめとする特定のプログラミング言語で書かれたライブラリが提供する API
• OS が提供する API
  • Windows、MacOS や Linux をはじめとする各 OS が開発者に提供する API
• ブラウザ API
  • JavaScript の上に乗っかって、より簡単に機能を実装するためにブラウザに組み込まれた API
• Web API
  • Web サービスが提供する機能やデータを外部から呼び出すために作られた API
  • MDN のこちらが参考になります。

このように API の種類は多岐にわたっており、中でも Web API は HTTP 通信などの Web 技術を使用することが特徴として挙げられます。この一部に REST API が含まれるのです。

② REST とは？

REST（REpresentational State Transfer）とは、日本語で「分散型システムにおける設計原則群」です。

REST API を設計する上では、以下 6 つで構成されるREST 制約をおさえる必要があります。

REST 制約

1. クライアント/サーバー

   • 画面(UI)はクライアント側、データはサーバー側とすることで関心事を分離する。
   • クライアント側がトリガーとして、サーバーは受け身の体制を取る。

2. 階層化システム

   • 多層アーキテクチャ構成において、各サーバーをコンポーネント化することでカプセル化を図る。

3. コードオンデマンド

   • クライアントコードをダウンロードして、実行できる。

4. 統一インターフェース

   • ４つの制約を守った構成になっている
     • URI を用いてサーバーに保存したデータを識別する
     • 断面情報を利用してサーバー
     • 自己記述メッセージの存在（リクエスト/レスポンスデータの内容がヘッダー情報から分かる）
     • HATEOS の存在（レスポンスに現在の状態に関連するハイパーリンクが含まれる）

5. ステートレス

   • サーバーに保存したセッション情報を使わず、状態情報はすべてリクエストに含まれる。

6. キャッシュ制御

   • クライアント側でレスポンスをキャッシュできる。

REST API の成熟度モデル

また、REST API 設計には、どれだけ REST 制約に準拠しているかに応じたレベルがあります。 以下の 4 段階の設計レベルです。

• LEVEL0：HTTP を使用している
• LEVEL1：リソースの概念を導入している（リソースごとに URL 分割）
• LEVEL2：HTTP メソッドを使用している
• LEVEL3：レスポンスに リソース間のつながりが含まれる

③ REST Web API サービス設計

次に REST WebAPI を作成する際にどのようなポイントに気をつける必要があるかを説明します。

③-1：URI の設計

• 短く入力しやすい URI にする（冗長なパスを含まない）
• 人間が理解できる単語を使用する
• すべて小文字で表現する
• 単語はハイフンで結合する
• 単語は複数形を使用する
• エンコードを必要とする文字を使用しない
• サーバー側のアーキテクチャを反映しない
• 改造しやすい
• ルールが統一されている（パスパラメータ or クエリパラメータなど）

③-2：URI と HTTP メソッドの適切な組み合わせ

URI がリソースを示すのに対し、HTTP メソッドはリソースに対する操作を示します。 共通の URI に対して、HTTP メソッドを切り替えることで分かりやすい API になります。

操作	HTTP method	API 実装例
ユーザ一覧の取得	GET	http://sample.com/users
ユーザの新規登録	POST	http://sample.com/users
特定ユーザの取得	GET	http://sample.com/users/123
ユーザの更新	PUT	http://sample.com/users/123
ユーザの削除	DELETE	http://sample.com/users/123

③-3：リソースを特定するパラメータの使い分け

リソースを絞り込む方法には、クエリパラメータとパスパラメータの 2 種類があります。 使い分ける基準は以下の通りです。

• クエリパラメータ：使わないパラメータが省略可能な場合に使用する（検索条件の絞り込みなど）

  • 例：GET http://sample.com/users?name=kei
    

• パスパラメータ：一意なリソースを表現できる場合に使用する

  • 例：GET http://sample.com/users/123

③-4：ステータスコードの使い分け

ステータスコードは大きく 5 つに分類されます。

ステータスコード	役割
100 番台	情報にまつわる
200 番台	成功レスポンス
300 番台	リダイレクトメッセージ
400 番台	クライアントエラーレスポンス
500 番台	サーバーエラーレスポンス

※300 番台はリダイレクト処理に関するため REST API ではあまり利用することはない。

(参考サイト) https://developer.mozilla.org/ja/docs/Web/HTTP/Status

③-5：レスポンスのデータフォーマットと指定方法

REST API で扱うデータフォーマットは以下の3種類です。

• XML
• JSON
• JSONP

仮に JSON で指定する場合、指定方法は下記のようになります。 中でも URI がリソースであることを踏まえると、リクエストヘッダで指定するのが適切です。

フォーマット	例
クエリパラメータ	http://sample.com/users?format=json
拡張子	http://sample.com/users.json
リクエストヘッダー	GET http://sample.com/users?format=json Host: sample.com Accept: application/json

④ 実際に REST API を設計してみる

最後にmovie をリソースとして CRUD 操作の URI、HTTP メソッドを定義してみます。 共通の URI を使用することで、REST API の設計が簡単になってますね。

URI	HTTP method	操作
/movies	GET	映画の一覧取得
/movies	POST	映画の新規登録
/movies/:id	GET	特定の映画取得
/movies/:id	PUT	特定の映画更新
/movies/:id	DELETE	特定の映画削除

『達人に学ぶ DB 設計徹底指南書』を読み終えました！

本記事では「達人に学ぶ DB 設計徹底指南書」を読み終えた感想を書いていきます。 DB 設計初心者の私にとって非常に難しい内容でした学びも多かったです。

www.shoeisha.co.jp

良かったところ

• 『学習のポイント』と『勘どころ』が役立つ
  • 本書籍は 第 1〜9 章で構成されており、各章の冒頭には『学習のポイント』が記載されています。 ただでさえ内容が難しい書籍なので、最初に目を通しておくだけで各章の内容理解が進みやすかった印象があります。また各ページには『勘どころ』という形で、「一言でまとめるとこうなるよね」的なコメントが散りばめられています。これを要約として捉えることで、難しい内容のページであっても頭の中で整理することができました。

• 演習問題の解説が充実している
  • 各章の最後には演習問題が付属しています。答えが 1 つに決まっている問題だけでなく、「性能の悪い SQL の改善策」や「ビジネスロジックをアプリケーション側で実装することの是非」といった色んな視点から考えさせるような問題も書かれていて面白かったです。また、筆者なりの解答ロジックも詳しく書かれているので、プロの考えを知ることができてとても勉強になりました。

学んだところ

• 正規化の欠点と非正規化について

  • 前提として、著者は『原則として非正規化は許さない』など正規化を強く支持する立場を取っています。最初はパワーワードのように聞こえましたが、正規化は高次にすればするほど、データ整合性が高まる一方、検索パフォーマンスが低下します。これへの対処として『非正規化』が候補として挙げられますが、これは DB 設計に対してある意味冗長性を持たせる行為なので、非正規化ありきの論理設計は考慮すべきことが多く、初心者には難しい印象を受けました。だからこそ、まずは正規化を行うと念頭に置き、SQL パフォーマンスチューニングで対処しつつ、最終手段として非正規化を試みるくらいが有効な方針であると認識を持つことができました。今後の DB 設計ではこの方針で進めてみようと思います。

• 論理設計のバッドノウハウ

  • 本書第 7 章にて、論理設計におけるバッドノウハウとして以下が挙げられています。
    • 非スカラ値
    • ダブルミーニング
    • 単一参照テーブル
    • テーブル分割
    • 不適切なキー
    • ダブルマスタ
  • 内容を読む限り、現場でこんなことが普通に起こりうるのかと驚くものばかりでした。 バッドノウハウが採用されたデータ設計でもシステムは動くかもしれませんが、設計変更が入った場合には、開発や運用にかかるコストが肥大化することは理解できました。私自身、論理設計を行う際には絶対に避けるよう心がけようと思います。

難しかったところ

• 物理設計まわり
  • 本書第 2 章にて、物理設計について書かれていますが、個人的に理解が難しい章でした。物理設計とは、論理設計の結果からデータ格納用の物理的領域や格納方法を決める工程になります。そのため、ストレージやリソース管理（CPU、メモリ、ディスク I/O など）、各 DBMS 製品に関する幅広い知識が必要になります。正直、この部分は書籍を読んだだけではイメージがほぼできず、実際に開発現場でハードウェア周りを触って経験しないと中々身につかないのではと感じました。

『スッキリわかる SQL 入門』を読み終えました！

本記事では「スッキリわかる SQL 入門」を読み終えた感想を書いていきます。
全体を通して、SQL 初心者にとって間違いなく推せる書籍でした。

book.impress.co.jp

良かったところ

• 圧倒的な演習問題の量
  • 本書籍には SQL と正規化を始めとしたドリル問題 256 問が付録として付いてきます。 このボリュームは非常に大きく、コツコツやっても 最低でも 1 週間はかかると思います。僕の場合は 2 週間以上かかりました（笑）。ただプログラミング学習において『質より量』だと信じているので、このドリルをやり終えることで SQL 初学者にとって基本的な知識が身につき、エンジニアを目指す上でのスタートラインには立てる自信が湧くはずです！

• 説明やイラストがとにかくわかりやすい
  • 登場人物を交えたストーリー仕立ての会話で飽きることなく読み進められました。タイトル通り「スッキリわかる」を体現しているなと感じました。
  • SQL の 4 大命令、集計とグループ化、複数テーブルの結合、テーブルの作成といった基本知識はもちろん、初学者にはとっつきづらいテーブル設計などのパートも、イラストや表などを多用して解説してくれるので、内容が理解できない場面に遭遇することは一度もありませんでした。

悪かったところ

• 正規化ドリルの解説がちょっと薄い
  • 書籍内の正規化のパートは分かりやすいですが、その分ドリル問題の解説がもっと欲しかったなという印象です。非正規形から第 3 正規形にかけて正規化を進める中で、なぜそういう正規化を行うかまで深く掘り下げてほしかったです。

• docoQL の使い勝手が若干悪い
  • 『docoQL』とは環境構築不要で SQL 文を実行できる便利なサービスです。しかし、書籍内の練習問題の環境が存在していない、SQL 文の実行回数に制限がある、サインインしないと SQL 文実行時に文字数制限をくらう等、モヤッとする箇所がいくつか散見されました。

学んだところ

• 正規化の手順
  • 正規化とは、DB 設計の論理設計で行う作業です。システム開発を行うにあたり「第 3 正規形」まで理解すれば問題ないと言われ、本書では第 3 正規形までの変形方法を学びました。段階的に正規化を進める中で、排除すべき項目が理解できて良かったです！（下記参考）
    • 第 1 正規形の場合 ・・・ 繰り返し列
    • 第 2 正規形の場合 ・・・ 部分関数従属（複合主キーの一部への関数従属）
    • 第 3 正規形の場合 ・・・ 推移関数従属

難しかったところ

• ユーザービューからテーブル設計を行うこと
  • 本書籍の正規化ドリルには、ユーザービューからテーブル設計を行う問題が 6 問ほどあり、題材として「職務経歴書」「不動産物件」「時刻表」といった日常的なものが挙げられます。 それらのイメージから読取れる情報を非正規なデータに落とし込むのが結構難しかったです。イメージ上では記載のない列も想像して考える必要がありました。

Happiness Chain Euforia 2ヶ月目の振り返り

6月の学習の振り返りをしていきます。

6 月の学習時間

6 月中の学習時間はトータルで 62 時間 でした。
月後半の残業が多かったこともあり、時間があまり取れない日がありましたが、思い返すともっと学習時間を確保できたなと反省しています。

進捗状況

課題の進捗状況についてです。 6 月中に進めたカリキュラムは以下の通りです。

• Python（100%）
• SQL（30%くらい？）

良かったところ

Python

Python は今まで触れたことのない言語でしたが、指定の Udemy 講座を クリアするだけで、基本的な知識を効率よく身につけることができました！ボリュームはかなり大きかったですが、簡単なロジックなら Python で組めるようになったと思います。
また、スクールが提供する Python のアウトプット課題も無事合格できました。 こちらは実装要件が決まっていたので、要件を満たすロジックを自力で書く力は付いたと思います。 ただ冗長なコードで妥協する箇所がいくつか見られたので、可読性なども意識してレビュアーが「読みやすい」コードを書くことを心がけたいです。

SQL

こちらは現在進行中の課題です。 「スッキリわかる SQL 入門」という書籍を中心に SQL の基本を学んでいるところです。 本書籍は非常に読みやすく、SQL 初心者の自分にとってはこれ 1 冊で、沢山のことを学べました。 また巻末の大量のドリル問題を通じて、SQL 文を書く力はだいぶ付いていると実感しています。 まだ残り 40%ほどあるので、引き続き頑張ります！

改善点

全体的に学習時間が少なかったです。 残業があったとしても、最低 1 時間は捻出できるはずなので、もっとストイックに学習に励みたいと思います。

7 月の目標

• 100 時間勉強する
• 毎日タイピング結果を投稿する
• 毎日学習する
• ジムに週 3 で通う
• SQL・DB の課題を完了する
• REST の課題を完了する
• Django の課題に着手する