Hirologue

年齢を理由にエンジニアになることを諦めないミドルの成長記録

EP 22: Djangoのクセがスゴイ

Django

はじめに

前回の記事でDjango公式チュートリアル（以下、チュートリアル）を始めるための準備として、Dockerを使って環境構築を行いました。 hirologue.hateblo.jp

チュートリアルでは、Djangoのバージョンを選択することができます。
今回使用するバージョンは4.2です。
チュートリアル開始前に画面右下「ドキュメントのバージョン」が「4.2」であることを確認します。
他のバージョンが選択されている場合は、「ドキュメントのバージョン」をクリックしてバージョンを切り替えましょう。

バージョン選択

あとは、淡々とチュートリアルの内容にしたがって進めるだけです。 ターゲットは「はじめての Django アプリ作成、その 1」から「はじめての Django アプリ作成、その 8」までです。

本記事では、チュートリアルを終えた私の所感を述べたいと思います。

よかったところ

チュートリアルで最初に行うことが、Djangoのバージョンを確認することでした。
バージョンを確認するにはターミナルにコマンドを入力しますが、チュートリアルではLinux/macOSとWindows双方のコマンドが表示されるようになっていました。

「Web開発はLinux/macOSで行うもの」という先入観があった私にとって、これはある意味衝撃でした。

確かにLinux/macOSを使い人もいれば、Windowsを使う人もいる。
しかし、これまで目にしてきたチュートリアルの類で、そのような配慮があっただろうか？・・・記憶を辿っても思い当たるものがありません。

そこで、ふと思いました。

これには、「Webアプリを作るなら、使う人のことを考えましょう」という隠されたメッセージがあるのではないかと。
わたしの考えすぎかもしれませんが、多種多様な人が使用するであろうWebアプリにおいてこの考えは常に優先させるべきことでしょう。

チュートリアル初めの教えは「ユーザーファーストであれ」、わたしはそう捉えました。

単に技術的な解説だけでなく、はじめに思想的な部分に気づかせてくれる構成になっていることが非常に良い点だと感じました。

学んだこと

Udemyで学習したときは、「Djangoとは何かを知る（全体像を把握する）」ことを優先させたため、基本的な流れについてそれほど深く理解していませんでした。
そして今回、チュートリアルを通してDjangoの基本的な流れをしっかり理解できたことが最も大きな収穫です。

Udemyで学習し、イメージは把握できていた「ビュー」、「モデル」、「テンプレート」、そして「ルーティング」の流れや相互の関係性について、実際に手を動かし、学ぶことでDjangoのしくみについて理解をグッと深めることができました。

また、Udemyでは学習していなかったテストについて学ぶこともできました。
これまではpython manage.py runserverコマンドでサーバーを起動し、手動で動作確認を行っていた部分が、テストを用いることで自動化できるという点に驚きました。
しかしながら、これを使いこなすにはかなりの時間を要すると思われるので、現時点での優先度は少し下げざるを得ないのが正直なところです。
ただ、テストとは何か、どのような使い方をするのかを知るキッカケとなったことは確かです。

難しかったこと（悪かったところを含む）

Djangoだけでなく、一般的に公式ドキュメントやチュートリアルは読み解くのが難しいと感じることが多いです。
難易度が高いと感じてしまう理由は人によると思いますが、

  1. 図や写真などがなく、文字情報だけなので内容をイメージしにくい
  2. 翻訳した日本語がわかりにくい

個人的にはこのあたりが原因なのかな？と思っています。

先ほど「学んだこと」の中で「基本的な流れを理解できました」と、サラッと書きましたが、実際にはチュートリアルだけでDjangoのしくみを理解することはかなり難しいです。

Djangoのしくみをしっかり理解するには、良質な参考書の助けが不可欠です。
そこで、わたしが使用したのが、現場で使えるDjangoの教科書《基礎編》［4.2 LTS 対応版］です。
モデルやビューをはじめ、Djangoの基礎を非常に細かく丁寧に解説していて、わたしの理解度を爆上げしてくれました。

きっと、Djangoが「難しい、わけわからん」といった壁を打破してくれる、「会心の一冊」となること間違いなしです。

まとめ

これまでの内容を踏まえ、Djangoを理解するためのステップをまとめました。

まずは、公式チュートリアルを一通り手を動かして、コードを書いて実際に動かしてみます。
次に、書いたコードを確認しながら、参考書を片手に公式チュートリアルをしっかりと読み込みます。
この段階で、Djangoのしくみが頭の中で整理され始めます。
そして、整理が進んだところで、公式チュートリアル内にリンクされているドキュメントにも目を通すと、理解の解像度が一気に高まります。

いかがだったでしょうか？

公式ドキュメントやチュートリアルって、文字だらけで読むのが嫌になるのが本音です。
特に、Djangoは {{ }} や {% %}で括ったりといったように書き方のクセが強いのも事実です。

わたしも初めは、「こんなの理解できるのだろうか？」と不安に思っていましたが、紹介した書籍のお陰で目の前に立ちはだかる壁を乗り越えることができました。
決して万人向けの学習方法ではないのかもしれませんが、Djangoが理解できずに困っている方の一助になれば幸いです。

次は、「Djangoをつかって開発できる」の壁に挑みます！
では、また✋️ 　

EP 21: あ、Djangoチュートリアル その前に

Django Docker Python

はじめに

Python、SQL、RESTと学びましたので、いよいよWebフレームワークのDjangoの学習を開始します。

Djangoの学習は、HappinessChainの学習ロードマップにおける大きな山場の一つと個人的には捉えています。

ここは、「Djangoの概要（全体像）を知る」、「Djangoのしくみを理解する（わかる）」、「Djangoを使ってWebアプリを開発できる」をこれまで以上に強く意識して学習に取り組みます。

まずはDjangoの概要（全体像）を知るために、Udemyの講座で学習を行いました。
講座の内容にしたがって講師と同じ環境を構築するので、環境構築でつまづくこともなくスムーズに進みます。
動画を視聴しながら実際に手を動かして学習を進め、Djangoの概要（全体像）を知ることができました。

何度かエラーも出ましたが、原因はほぼ100%でタイポでした。

と、順調にDjangoの概要（全体像）を知ることができましたので、次はDjangoのしくみを理解するための学習をはじめます。
しくみを理解するには、その大本である公式ドキュメントを読む必要があります。
しかしながら、用意されているDjangoのドキュメントは膨大な量で、そのすべてを読み込むことはナンセンスです。

そんなときは、公式チュートリアルの出番です。
この公式チュートリアルには、Djangoにおいて必要とされるエッセンスがギュッと凝縮されています。
ならば、この公式チュートリアルをつかってDjangoのしくみをしっかり理解するのがベストプラクティスです。

では、公式ドキュメントにしたがって環境構築をしてスタート！

といきたいところですが、ちょっと待った！

私はWebエンジニアになりたい。
ということは、チームで開発することを意識しなければならない。
つまり、みんな同じ開発環境である必要がある。
そんなときどうするか？
そう、Dockerの出番ですね。

前置きが長くなりましたが、本記事ではDjango公式チュートリアルで学習するための開発環境を構築します。

開発環境をどうするか

Djangoを使うにはPythonが必要なわけですが、今回使用するバージョンは3.12.5とします。
Djangoのバージョンは2024年9月時点の最新版ではなく、LTS（Long Term Support）版の4.2.16とし、データベースはPostgreSQLのlatestバージョンを使用することにしました。

Djangoをインストールするには、requirements.txtに記述する必要があります。
requirements.txtにパッケージを記述すると一括でインストールできるので、他にも必要なパッケージがあれば追記します。
ここで必要な追加パッケージは、django-environとpsycopgです。
詳細な説明は省略しますが、django-environは、Djangoで環境変数を扱う際に便利なパッケージで、psyocopgはデータベースとして使用するPostgreSQLのためのパッケージです。

Dockerファイルを作る

では、以前の記事を参考にDockerファイルを作成します。

FROM python:3.12.5-slim
ENV PYTHONUNBUFFERED=1

WORKDIR /django_tutorial
COPY requirements.txt /django_tutorial
RUN pip install --upgrade pip && \
    pip install -r requirements.txt

COPY . /django_tutorial/


続いて、パッケージをインストールするためのrequirements.txtを作成します。

Django==4.2.16
django-environ==0.11.2
psycopg[binary]==3.2.1

これでdockerfileとrequirements.txtの準備は完了です。

docker-compose.ymlファイルを作る

続いて、以前の記事を参考に docker-compose.ymlファイルを作成します。

# version: '3'  # 私の環境では不要なのでコメントアウトしています

services:
  web:
    build: .
    ports:
      - '8000:8000'
    volumes:
      - '.:/django_tutorial'
    depends_on:
      - db
    tty: true
    stdin_open: true

  db:
    image: postgres
    platform: linux/amd64
    volumes:
      - db-data:/var/lib/postgresql/data
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_DB=django_develop
      - POSTGRES_PASSWORD=postgres

volumes:
  db-data:

細かい部分の説明は割愛しますが、とりあえずこの状態でコンテナを立ち上げます。

$ docker compose up -d



環境変数を設定する

さて、無事にコンテナが立ち上がりましたが、Djangoを起動させたい気分をグッとこらえましょう。

次にやるのは、環境変数の設定です。
requirements.txtに記述したパッケージ「django-environ」の出番です。

django-environを使うには、manage.pyと同じ階層に.envファイルを作る必要があるので作成します。

なお、gitでバージョン管理を行っている場合は、この.envファイルを管理対象から外すことを忘れないでください。

作成した.envファイルに必要な環境変数を書き込んでいきましょう。
データベース周りの環境変数を記述します。

DATABASE_URL="postgres://postgres:postgres@db:5432/django_develop"

ちなみに、この環境変数は次のような作りとなっています。

DATABASE_URL=[データベースエンジン]://[ユーザー名]:[パスワード]@[ホスト名]:[ポート番号]/[データベース名]

（参考: https://freemas.stepupkaraoke.com/python/django/about-django-environ）

環境変数の設定は一旦ここまでとして、次に進みます。

プロジェクトの作成

ターミナルで作業ディレクトリにいることを確認して、次のコマンドを入力します。

$ django admin-startproject config .

コマンドの最後のピリオドを忘れずに入れて実行するとconfigと言う名のディレクトリが作成されます。

settigns.pyに追加の設定を記述　その１

次にconfig/settings.pyファイルを開いて、いくつか追加の設定を行います。
まずは、django-environをインポートして使うための設定です。

from pathlib import Path

import environ  # この行を追記

BASE_DIR = Path(__file__).resolve().parent.parent

env = environ.Env()  # この行を追記
environ.Env.read_env(env_file=str(BASE_DIR) + '/.env')  # この行を追記

これで、先程作成した.envファイルを読み込めるようになりました。
しかし、少し下の行に目をやると・・・

SECRET_KEY = 'django<ランダムな文字列>'

といった具合に、本来秘密であるはずのSECRET_KEYがハードコーディングされています。
これはあまりよろしくないことなので、何とかしなければなりません。

SECRET_KEYの再生成

DjangoにはSECRET_KEYを生成するためのしくみが用意されています。
早速、キーを再生成しましょう。
そのために適当な名前の.pyファイル（ここではregenerate.pyとします）を作成します。
そして、次のコード書いて実行します。

from django.core.management.utils import get_random_secret_key

secret_key = get_random_secret_key()
text = f'SECRET_KEY={secret_key}'
print(text)

コードを実行すると、文字列が出力されますので.envファイルに出力結果をコピペします。
こうして.envファイルは次のようになります。

DATABASE_URL="postgres://postgres:postgres@db:5432/django_develop"
SECRET_KEY='<再生成されたランダムな文字列>'

（参考: https://noauto-nolife.com/post/django-secret-key-regenerate/）

settigns.pyに追加の設定を記述　その２

これで必要な環境変数が用意できたので、.envファイルの内容をsettings.pyファイルに反映させます。
ついでにALLOWED_HOSTSの設定も追記します。

（略）
SECRET_KEY = env('SECRET_KEY') 
（略）
ALLOWED_HOSTS = ['0.0.0.0']  # 追記
（略）
DATABASES = {
    'default': env.db(),  # 辞書の値を変更
}



hello django!

これで準備万端整いましたので、まずはコンテナを立ち上げて、bashを起動させます。

$ docker compose up -d

$ docker compose exec web bash

では、待望のロケットを飛ばしましょう！
次のコマンドを入力します。

$ python manage.py runserver 0.0.0.0:8000

見事に飛びました！あー長かった。

これで、ようやく公式チュートリアルで学習を開始する準備が整いました。

いかがだったでしょうか？
この記事がDockerでDjangoの環境構築をしようとしている方のお役に立てたら幸いです。

次回は、公式チュートリアルからDjangoを理解する過程で感じたことや気づきを初心者目線でリアルに伝えたいと思います！

ぜひお楽しみに！では、また✋️

EP 20: 49歳の挑戦（６ヶ月目を振り返る）

月報

2024年3月1日にHappiness Chain（以下、HC） Euforia ２期生として入会してから早いもので6ヶ月が経過しようとしています。
本記事では、この1ヶ月間で学んだことをダイジェストで振り返りたいと思います。

50歳目前の私が入会を決意するまでの経緯を書いたポエムは👇こちら hirologue.hateblo.jp

８月の学習時間（期間：7/31 - 8/30）

８月の学習時間は 130 時間 / 31日 でした。
学習日数が31日ですので、一日あたりの学習時間は 251分（4時間11分）となりますね。

今月も学習時間の目安として、休日は8時間、平日は3時間を基本としました。
会社の夏季休業（お盆休み）がありましたので、目標学習時間はいつもの月よりも多くなり、153時間の設定です。

目標学習時間には 23時間足りませんでした。

先月は、肘の激痛のため学習時間の確保が困難でしたので、今月はその遅れを取り戻すべくガンガンやろうと心に誓っていました。
ましてや今年のお盆休みは祝日と有給休暇をあわせて９日間の大型連休でしたので、涼しい場所で学習しまくる予定でした。
起床後に朝食をとり、中学英語の勉強をし、タイピング練習をして学習開始と普段の休日と同じルーティンのはずなのに集中できない日々が続きました。

「せっかくの休みだし、ゲームしようかな」とか、台風が来そうだから帰省を諦めたせいか「故郷の味」が恋しくなったり、両親・兄は元気だろうか？と色々な思いが頭の中を駆けめぐります。

集中して学習に取り組むなら、そういった思いを取り除くべくしっかり休むべきでした。

とはいえ、平均４時間の学習を毎日継続できたことは、日常生活にプログラミング学習が当たり前のように組み込まれている証だと思っています。

今後の課題は、学習と休みのバランスを良好に保って、学習時間に対して学習内容を濃くする、濃度を意識していこうと思います。

８月の学習内容

７月はロードマップのSQLの途中まででしたので、８月はその続きからになります。



SQL

先月は肘の激痛もあり、思うように進めなかったSQLですが、痛みが収まったのでガンガン進める予定でした。 しかしまぁ、１冊目の書籍（スッキリわかるSQL入門）のボリュームの凄いこと。 書籍の内容については、読めばある程度理解できる内容でしたが、演習に取り組むと「できない」の壁にぶつかりました。 わかる、知っている、できるの違いを思い知りました。

👇学習に使用した書籍についてレビュー記事を作成しました。 hirologue.hateblo.jp

SQLの２冊目の書籍は、エンジニアなら必携と言われる１冊「達人に学ぶDB設計　徹底指南書」ですね。
タイトルの通り、DB設計に特化した１冊です。
先のレビュー記事でも述べましたが、「スッキリわかるSQL入門」では、DB設計についてスッキリすることができませんでしたが、この書籍を読み込むことによってスッキリすることができました。
初学者がSQLを学習する２冊目としては素晴らしい書籍だと思いました。

👇学習に使用した書籍についてレビュー記事を作成しました。 hirologue.hateblo.jp

SQLの仕上げとしてHCの課題に取り組みました。 内容は、某SNSのデータテーブルを設計するというものです。
どのように設計するべきなのか試行錯誤し完成したER図を提出したところ、修正の指摘をいただきました。
修正内容について詳細は書けませんが、指摘の内容について「なぜ？」を調べることで書籍を読むだけでは得られない知見を得る機会をいただけました。
以前の月報でも書きましたが、指摘をいただけるのが本当にありがたいと思うレビューでした。



REST

さて、SQLの次はRESTです。
学習前の私は、「REST？なにそれ？おいしいの？」といった具合にRESTが何たるかを全く知りませんでした。

動画教材を視聴する→異世界の言葉かと思うほど難解なワードの出現→理解が追いつかず眠くなる→ハッと目が覚める→難解なワードを調べる　のループです。

まるで檻の中でじっと座っている犬が、外で駆け回ることを夢見ているように、コードも書かずただただ座って難解な内容を理解する日々は正直つらかったです。

つらい日々でしたが、HC入会前の説明会でゆうだいさんが言ったこの言葉を思い出しました。
「我々の言うことに素直にしたがってください。」
そうだ。つよいエンジニアになりたくてここに入会したのだから、師の言うことを素直に聞いて実践しなければ。
高校時代の監督・先輩の言うことは絶対だったころのマインドはどこに行った？
コードも書かずに抽象的な内容の座学だけで逃げたくなりましたが、Djangoの前に学習しているということはDjangoを学習するために必要なステップなのだから、頑張るしかない！
コードも書けずに檻に閉じ込められたかのような状況であっても、広大なフィールドを自由に駆け巡るための準備期間なのだから、と自分を奮い立たせこのセクションを乗り切りました。

👇RESTのRも知らなかった私がRESTについて記事を書きました。 hirologue.hateblo.jp



Django

ようやくRESTが終わり念願のDjangoの学習を開始しました。
Djangoも独学時に少しだけ取り組んだ経験があったので、序盤はスイスイ行けるだろうと高を括っていたら、思いっきり足元をすくわれました。

・・・完全に忘れとる。

ある意味頭の中がリセットされて良いのかもしれませんが、再びゼロからのスタートです。
Djangoの学習を開始したところで、月末を迎えましたのでこの続きは来月ということで。



今月の感想

中学から大学を出て働き始めるまで愛読書は「ジャンプ、マガジン、サンデー、エ◯本」で、読書が本当に嫌いな私にとってSQL、RESTのセクションは本当にしんどかったのが嘘偽りのない正直な感想です。

それだけしんどい時期でも乗り越えることができたのは、高校時代のまるで軍隊のような部活動で精神の鍛錬をしたからだけではありません。
それプラスでRESTのように抽象的な内容を、YouTubeのように身近で具体的なものに置き換えて考えることができたからに違いありません。
きっと、この先も抽象的な考えを理解しなければ行けない場面は多く出現することと思いますが、そんなときは、この時期に身につけた何かに置換する手法を使いたいと思います。



９月のターゲット


いよいよ待望のDjangoの学習が始まり、思いっきりコードを書く時間が増えます。

冒頭で述べたように、集中して学習に取り組むために「故郷の味」を求め、この記事は実家に帰省しながら書いています！
生まれ育った故郷で旬のものを食べ、両親とお酒を酌み交わす幸せな時間がこのあとに控えています。

生まれ故郷の庄内の枝豆（だだちゃ豆）はマジで美味い。

この世に生を享けてから、当たり前のように食していたこれが食べたくてお盆休みの間にモヤモヤしていたのかもしれませんね。

きっと来月の学習の濃度は濃くなることでしょう！
では、また来月！

晩夏の故郷

EP 19: RESTは抽象的だが役に立つ

プログラミング

はじめに

これまでLinuxに始まり、Git、HTML/CSS、Docker、Python、SQLと学習してきました。
ここでWebフレームワーク（Django）について学習する前にもう一つ知っておくべきことがあります。

それは、アプリケーションと人とを繋ぐインターフェース、つまりAPI（Application Programming Interface）と呼ばれるものです。

身近なWebアプリケーションとして、YouTubeを思い浮かべてみましょう。

YouTubeで観たい動画を検索して再生するには、検索窓にキーワード（例えば、「Python 入門」）を入力するだけでたくさんの動画が検索結果として表示されて、観たい動画をクリックすれば再生できます。

普段何気に使用しているこの一連の流れの中で、私たちとYouTubeの橋渡しをしているのがAPIです。
APIにはいくつか種類がありますが、本記事ではWebアプリケーションで広く使われる REST APIについて学習した内容を紹介します。

そもそもRESTってなんだ？

REST APIについて学習する際に「RESTとは、なんだろうか？」という疑問が真っ先に思い浮かびます。
REST（Representational State Transferの略）とは、Webサービスを設計するためのルールとして2000年にロイ・フィールディング氏によって提唱されたものです。

つまり、Webサービスを設計するためのルールに則ったAPIのことをREST APIといいます。

RESTのルールには次の６つが挙げられます。

  • クライアント/サーバー
  • ステートレス
  • キャッシュ制御
  • 統一インターフェース
  • 階層化システム
  • コードオンデマンド

RESTの6つのルール

クライアント/サーバー

１つ目のルールは、「クライアントとサーバーは分離されていなければならない」ということです。
クライアントは、サーバーが提供するリソース（データやサービス）を要求し、サーバーはその要求に応じてリソースを提供します。

YouTubeを利用する場面を想像しましょう。
クライアントは私たちが使っているブラウザやスマホアプリで、サーバーはYouTubeのデータベースやストリーミングサーバーです。
例えば「Python 入門」と検索すると、クライアントはその検索ワードをYouTubeのサーバーに送ります。
サーバーは、そのリクエストに対応する動画データをクライアントに返すことで、ブラウザやアプリで表示・再生されます。

ステートレス

２つ目のルールは、「サーバーはクライアントの状態を保持しない」ということです。
クライアントの状態を保持しないということは、以前のリクエストがどうであったかは関係なく、１度きりのやり取りでリクエストとレスポンスが成り立つということになります。
例えるなら、１話完結型のドラマです。

では、仮にステートフルだった場合を想像してみましょう。
多くのユーザーが多種多様なリクエストをサーバーに投げてきます。
その一つ一つをサーバー側に保持していたらどうでしょうか？
あっという間にパンクする気がしませんか？
だから、リクエストを独立して処理するステートレスである必要があるのです。

キャッシュ制御

３つ目のルールは、「クライアント側でレスポンスをキャッシュできるようにする」ということです。
レスポンスがキャッシュ可能かどうか指定します。
クライアントはキャッシュされたデータを利用することで、サーバーへのリクエストを減らすことができます。これによりユーザー体験の向上やリソースの効率化が見込まれます。

例えば、YouTubeの動画のサムネイル画像を考えてみましょう。
サムネイル画像は変更されることが少ないため、YouTubeはその画像をクライアントのブラウザにキャッシュさせます（キャッシュ制御）。
次に同じサムネイルが必要な場合、ブラウザはキャッシュに保存されている画像を再利用します。
これにより、サーバーへのリクエストが不要となり、ページの読み込み速度が速くなります。

統一インターフェース

４つ目のルールは、「リソースにアクセスするためのインターフェースは統一されている必要がある」ということです。
このルールは、REST APIの中心的な役割を果たすと言っても過言ではありません。
統一インターフェースには、クライアントとサーバー間のやり取りをシンプルにし、互換性を高めるための４つの制約があります。

リソースの識別

リソースは一意に識別できる必要があり、これにはURI（Uniform Resource Identifier）を使用します。
URIはリソースを特定するためのアドレスであり、リソースにアクセスするための手段となります。

YouTubeでBon Joviの"It's My Life"のOfficial Music Videoを例にすると、

https://www.youtube.com/watch?v=vx2u5uUu3DEのwatch?v=vx2u5uUu3DEでリソースが一意に識別されています。

もちろんアクセスすればお目当てのMVが再生されます。

リソースの表現を用いた操作

リソースの表現とは、JSONまたはXMLのことを指します。
クライアントは、リソースの表現を取得し、そのデータを使ってリソースを操作することができます。
サーバーは、リソースの状態をクライアントに返す際にこれらの表現を使います。

自己記述メッセージ

この「自己記述メッセージ」とは、サーバーへのリクエストやクライアントへのレスポンスに含まれるデータのことを指します。
具体的には、メッセージのヘッダーに、ボディー部分の内容がどの形式であるかを示す情報（Content-Type）が記述されています。

HATEOAS

Hypermedia As The Engine Of Application Stateの略で、レスポンスに現在の状態を踏まえて関連するハイパーリンクを含めるということを示しています。
例えば、検索結果の表示における「次ページ」のようなリンクを含めるということです（ただし、最近のREST APIでは見かけることは少なくなったようです）。

階層化システム

5つ目のルールは階層化システムで、システムが複数の階層（レイヤー）に分かれていることを指します。 各階層は独立して機能し、他の階層とのやり取りを通じてシステム全体が動作します。

このように階層化システムとすることで、システムの柔軟性とスケーラビリティが向上しますが、処理の中でオーバーヘッド（階層化したことによる負荷）が発生し、レスポンスが悪く感じるといったデメリットもあります。

コードオンデマンド

6つ目のルールは、「クライアントにコードを送信し、クライアント側で実行することができる」です。
これによって、リリース済みのクライアントに対して機能追加といった拡張や、クライアントに処理を移譲できるので、サーバーの負荷を下げることが可能になります。
その一方で、クライアント側の実行環境（SafariやChromeなど）が増えるので、評価が複雑になるというデメリットもあります。

URI設計のポイント

URIを設計するポイントはいくつかありますが、代表的なものは以下の通りです。

  • 冗長なパスを含まず、短く入力しやすいものであること
  • 読むだけで理解できるものであること（省略した表記を使わない）
  • すべて小文字であること
  • 単語はハイフン（ - ）で連結すること
  • 単語は複数形とすること（リソースの集合であるため）

これを踏まえ、movieをリソースとしてURIを設計してみます。
CRUD（Create / Read / Update / Delete）操作を行う場合のHTTPメソッドとURIの関係は、以下のようになります。

URI HTTP method 操作
/movies/ GET リソースの一覧取得
/movies/ POST リソースの新規作成
/movies/{id} GET 任意のリソースの取得
/movies/{id} PUT 任意のリソースの更新（存在しない場合は新規作成）
/movies/{id} DELETE 任意のリソースの削除




いかがだったでしょうか？
RESTは設計思想であるため、どこか抽象的で、私も含め初学者には理解しにくい部分が多いのも事実です。

ただ、現段階で100％理解できなくとも「RESTとはこんなものだったよな」といった感じを掴めるだけでもこの先の学習の役に立つと思います。

個人的には、Djangoなどのフレームワークを学習していく過程で、RESTについて疑問に思うことがあれば、また調べればいいと思っています。
なぜなら、プログラミング学習をして何か試験を受ける訳ではないのですから。

この記事がお役に立てれば幸いです。

EP 18: 達人の下でDB設計を学びスッキリしたい

SQL

はじめに

前回の記事では、SQLの学習に使用した書籍「スッキリわかるSQL入門 第４版」についてレビューを行いました。

その中でも述べましたが、テーブルそのものの作成方法は理解できました。
しかしながら、書籍の中ではどのようにしてその設計を行うべきか、セオリーや考え方には、あまり踏み込んでいない印象を受けました。
豊富な演習問題が特徴の書籍ではあったのですが、せっかくの演習問題に解説がないため、どのような考え方をしているのかは自分で考える必要がありました。
特に考え方が重要となる設計の部分については、この解説がないという点が致命的でした。
問題を解きながら理解を深めるスタイルの私にとっては、考えを巡らせる時間だけが過ぎてゆくだけで、理解度が一向に上がりません。

そして、設計に関する理解度が低いままの状態で書籍を読み終えたので、タイトルのように「スッキリ」はしなかったですね。

ここはスッキリするためにも、他の書籍で理解が足りていない部分をガッツリ補う必要があります。

👇ということで、こちらの書籍で設計について学習しました。
www.shoeisha.co.jp

本記事では「達人に学ぶDB設計徹底指南書（第１版）」の内容について、率直な感想を初心者目線で述べたいと思います。

良かったところ

学習内容の全体像を把握しやすい

この書籍は全９章で構成され、各章の冒頭には学習内容の概要とポイントが明確に示されています。
そのため、学習内容の全体像を掴みやすくなっています。

過去の学習経験から私自身、プログラミング学習を進める際には、はじめに全体像を把握するようにしています。
なぜなら、全体像を把握できると、何がキーワードなのか、どの点を注意深く読むべきなのかについても把握することができるからです。

内容的には少し難しいと言われている書籍ではありましたが、冒頭で全体像を把握できて学習の道筋をハッキリさせている点が優れていると感じました。

理由をきっちり説明している

この書籍ではDB設計に際し、やってはいけない「バッドノウハウ」と使い方次第ではOKな「グレーノウハウ」について扱っています。

この章に進んだとき、私はこう思いました。
「これこれ、こういう事を知りたかったんだよ。」 ほんと、私の心をガッチリ鷲掴みしてくれます。

初学者である私にとって、「やっていいこと」や「ダメなこと」と言うのは現場に入らない限り知り得ないものと思っていましたから、非常に興味深く読みました。

初学者が知り得ないノウハウが書かれていること自体が非常に優れている点であると思います。

しかし、それよりも特筆すべき点があります。
それは、バッドノウハウがもたらす影響などについて、まるで、親が我が子を躾けるかの如く「〇〇だから〇〇してはいけません」といったように丁寧に説明している点です。

その説明に不明点はなく、その理由には、なるほど！と納得することばかりでした。

初学者である私は、言い換えるなら「子ども」ですから、「親」である著者にやってはいけないことを丁寧に説明されれば納得するわけです。

演習問題の解説がある

私がSQLを学習した１冊目の書籍「スッキリわかるSQL入門 第４版」では、「演習問題に解説がないこと」が不満でした。
そのような不満もあり、考え方が重要である設計について理解を深めることができなかったというのは、冒頭で述べた通りです。

この書籍にも章末に演習問題が付属していますが、これでもかと言うほどしっかりとした解説が巻末についています。
本文に加え演習問題の解説が、解答する上で直面した様々な「なぜ？」を明らかにしてくれたことが特に良かった点です。
演習問題に付属する解説の重要性を知ることができ、今後の書籍選びにも活かせると思いました。



学んだこと

この書籍を通じて、特に理解が浅かった正規化とER図について深く理解することができました。

正規化について

正規化については、テーブルとは何であるかの説明から始まりました。
「テーブルとは、ある共通点を持ったレコードを集めたものであり、テーブル名はすべて複数形または複数名詞で書ける」という非常に明快な説明に驚きました。
単純に「第１正規形とは、これこれこういうもの」といった説明から始めるのではなく、前提となる部分をしっかり理解してもらいたいという著者の思いがヒシヒシと伝わるものでした。
そのため、正規化の内容はスラスラと頭の中に入ってきます。

また、「スッキリわかるSQL入門」では第３正規形までの学習で、第４、第５正規形といった高次正規形についての説明は割愛されていました。 その理由は、第３正規形まで理解していれば事足りるからといったものでした。 この書籍では第3.5正規形とも呼ばれる「ボイス－コッド正規形」も含め高次正規形についても知ることができました。

ER図について

設計において正規化を進めると、テーブル（エンティティ）の数が増えていき、テーブル同士の関係性がわかりにくくなる問題が起きます。
そのため、テーブル同士の関係を明らかにするためのER図が必要であるということは、理解していました。

しかし、この書籍を読む前は、ER図を自分で作成するときに何をもって「１、あるいは多」と判断するかよく理解できていませんでした。
私が抱えていたこの悩みについても、演習問題と丁寧な解説を通じてより深く理解することができました。



難しかったこと

これまで、著者の説明がわかりやすいと述べてきましたが、すべてがわかりやすかったわけではありません。

正規形に関して、第３正規形まで理解すれば十分という先入観もあり、高次正規形についてはあまり深く理解できず、単なる読み物として「そういうものがある」で済ませました。
高次正規形が必要となるときに再度読み返すつもりです。

また、第９章「一歩進んだ論理設計〜SQLで木構造を扱う〜」の内容は、イメージが上手く沸きませんでした。
リレーショナルデータベースで木構造を扱うのが不得意であるという事実を知った程度で、正直なところ、これも読み物として読み終えました。



悪かったところ

最後にこの書籍の悪かったところです。
特筆すべき点はないのですが、敢えて挙げるなら、
2024年8月時点で第１版の発行から10年以上経過していて内容が古いかもしれないという点です。

IT系の技術は日進月歩なので、書いてある内容が今でも通用するのかどうか、少し不安を感じました。
情報は鮮度が命ですからね。

敢えて挙げるならと前置きした理由は、内容をアップデートした第２版が2024年8月28日に発売されるからです。

www.shoeisha.co.jp

第２版が発売されることを知っていましたが、早くスッキリしたいという思いから発売日まで待てませんでした。
この書籍は常に手元に置いておきたい１冊なので、読み始めて間もなく第２版も予約しました。

この書籍に限らず技術書を購入する際には、発行年も重要なポイントであると感じました。




初心者目線で率直な感想を述べてきましたが、いかがだったでしょうか。

私はこの書籍を読み終え、１冊目の学習後に抱えていたモヤモヤが「スッキリ」しました。

完全初心者が読むにはハードルが高い書籍ですが、他の書籍でデータベース設計を学んだあとの２冊目として、ベストな選択であると思います。

また、第２版では、内容を最新化しクラウドに関する内容もあるようで、非常に楽しみです。
機会があれば、第２版との比較レビューをしてみたいと思います。

本記事がデータベース設計について書籍を探している方の一助となれば幸いです。

EP 17: SQLはじめました

SQL

はじめに

Pythonの学習を一通り終えたので、次はSQLについて学習します。
Webアプリケーションとは切っても切れない関係のSQLですので、ここは書籍を使ってしっかり学びたいと思います。

SQLに関する書籍は巷に多く存在していますが、選択肢が多すぎるというのも悩みの種です。 売上ランキングや、通販サイト等のレビューを参考にしたりと、選び方は人それぞれです。
初心者向けと謳っていても内容が中級者向けだったりすることもありますので、書籍選びは慎重に行わなければいけません。

私自身、SQLについては独学時にUdemyで少しだけ学んだことがあります。
とは言っても、動画を視聴して、少しだけ手を動かして何となくの雰囲気だけ掴んだ程度です。
今となっては当時の学習内容の記憶は殆どリセットされているので、結局のところ全くの初心者と言ってもいいレベルです。

ただ、そのときに思ったことがあります。

それは、
「データの抽出の仕方は教わるけど、このデータ（テーブル）はどうやって作るんだ？」
という疑問です。
学習内容が記憶から消し去られていても、この疑問は今なお鮮明に記憶しています。

他にも、データの追加や削除はどうするんだろう？といった疑問もありました。

そのような背景もあり、書籍選びでは、いわゆるCRUD（Create/Read/Update/Delete）を網羅している初心者向けのものを使って学習したいと思っていました。

ということで、初心者向けで定評のある
👇こちらの書籍を使ってSQLを学習しました。
book.impress.co.jp

本記事では「スッキリわかるSQL入門 第４版」の内容について、率直な感想を初心者目線で述べたいと思います。

良かったところ

身近なデータである”家計簿”を題材にしていること

家計簿を題材としたストーリー仕立ての内容となっているため、学習する内容のイメージが掴みやすいです。
具体的なイメージを持ちやすかったこともあり、学習途中で理解が追いつかず躓くといったことが非常に少なく感じました。

各章に練習問題があること

章末に学習内容の理解を深めるための練習問題が用意されている点も非常に良かったです。
私は内容をサラッと読んで、概要をある程度把握してから練習問題に取り組むようにしていました。
練習問題は、一度自分で考えはしますが、わからなければ答えを見て、実際に手を動かし、理解することを優先しました。

学習した内容の練習問題なのに、答えを見るの？と思った方もいるではないでしょうか。

確かに独学でプログラミングを学び始めた頃は、何とか覚えなきゃいけないと思い、必死にノートに書いて覚えようとしていた時期もありました。
現代の日本が抱える詰め込み教育の弊害とも言える考え方ですね。
しかし、よく考えてみてください。
プロの方々もわからなければ、ググって解決している訳ですし、何かの試験を受ける訳ではないのですから、カンニングOKなのです。

ガッチガチに覚えるのではなく、内容を理解する。これにつきます。

私が尊敬するエンジニアの一人、はやたすさんもこう仰っています。


練習問題とは別に演習（ドリル）が用意されていること

巻末には章末の練習問題とは別にドリルが256問も用意されています。
前述の練習問題で、学習内容を理解するようにしましたが、学習の仕上げとしてドリルに取り組むことで知識の定着化が図れるようになっている点も非常に良かったです。
誰しも幼き頃にひたすら漢字ドリルや計算ドリルをやったことはあると思いますが、この演習問題は正しくそれです。
最初のうちは答えを見ながら解いていきますが、数をこなすことによって解答を見ずに解くことができました。


このように、身近なデータで学習内容のイメージを湧きやすくし、練習問題で理解を深め、多くの演習問題で知識を定着させるという流れになっている点が、この本の特筆すべき長所であると私は考えます。

学んだこと

この書籍で、SELECT, UPDATE, DELETE, INSERTの４大命令を学び、独学時に抱いていた疑問の一つである「データの追加と削除はどうやってやるのか？」を真っ先に解決できました。
命令によって書き方が異なるため、はじめのうちは戸惑いましたが、前述の練習問題やドリルを通じてしっかりと理解し、基本的な内容を身につけることができました。

また、現職では様々なデータを扱っており、会社の基幹システムにデータを入力しているときにいつも思っていた疑問があります。

それは、「データ入力している人が他にもいるのにデータに矛盾が生じないのはなぜ？」です。 この疑問については、トランザクション制御について学んだことで解決できました。

トランザクション制御は、複数のデータ操作を一つのまとまりとして扱い、すべての操作が成功したときのみデータベースに反映される仕組みです。
Webアプリケーション開発においては、複数のユーザーが同時にデータ操作することもあるため、この仕組みを理解するのは非常に重要であると感じました。

難しかったこと

冒頭で述べたように、テーブルの作り方を知りたいと以前から思っていました。
この書籍にはテーブルの作り方（CREATE)についての説明も含まれているので、基本的な作り方は理解できました。

しかし、そのテーブルの設計方法については少し難しく感じました。
要件から概念設計をし、それを基に論理設計、物理設計と進めることは理解できるのですが、それらの理解度はかなり低いと自覚しています。

書籍の中ではテーブル設計について、内容が薄く、どこかサラッと済ませているような印象さえも受けました。
ですので、ここは大枠だけ学んで、本質的な内容についてはテーブル設計を扱う別の書籍でしっかり学習する必要があると思い、深追いするのを止めました。

テーブル設計に関する理解度が低い理由については、次の「悪かったこと」で述べたいと思います。

悪かったこと

演習（ドリル）の解説がない

前述の通り、この書籍の良いところは、章末の練習問題と大量のドリルが用意されていることです。
解答例も用意されていますが、ドリルについてはPDFをダウンロードしないと見れないようになっています。

しかも用意された解答例に解説の類がないことが非常にもったいなく感じました。

私の学習スタイルは、練習問題やドリルをこなして理解を深め定着させるというものです。
解説がなくても大丈夫な内容であれば不満ではないのですが、テーブル設計のように考え方が重要な内容について解説が用意されていないのは致命的かなと、個人的には思います。
例えば、ER図を書いてくださいという問題でも解答例のER図だけを載せて、解説がないのでどのような手順や考え方でER図を作成するべきなのかわからないわけです。

このようなことを書くと他責思考のようで、嫌なのですが、解説がないことがこの書籍を読み終えた時点でテーブル設計の理解度が低い原因の一つなのかなと思います。
ただ、非常に重要なテーブル設計についてこのまま放って置くわけにもいきません。
テーブル設計については他の書籍等で学習してから、再度この書籍に戻って理解度を高めていきたいと思います。

dokoQLの使い勝手が少し残念

この書籍では、環境構築の手間をなくし、ブラウザ経由でSQLを実行できるdokoQLという仕組みが用意されています。

多くのプログラミング初心者が環境構築が上手くいかず挫折することを考えれば、環境構築が不要である点は大いに評価すべきことなのですが、使ってみて残念な点がありました。
それは、入力画面で全角スペースと半角スペースの見分けが付きにくい点です。

SQL文を入力して実行すると、構文的にも間違っていないはずなのにエラーが発生することがしばしばありました。
その場合のエラーの原因の大半は、半角スペースではなく、全角スペースを入力していたことでした。 この手のエラーが発生すると、何度も入力内容を見返し、一文字ずつ確認してやっと気づくといった感じで、エラーの解消に多くの時間を費やしました。
せめて、全角スペースをハイライト表示などで強調してくれたらいいのになと、何回思ったかわかりません。

環境構築不要ですぐに使えるというのが長所であるだけに、この点が少し残念に感じました。


SQL初心者目線で率直な感想を述べてきましたが、いかがだったでしょうか。

良い点もあれば悪い点もありますが、総合的に判断するなら、SQLのはじめの一冊としてふさわしい書籍の一つであると思います。

本記事がSQLの初心者向け書籍を探している方の一助となれば幸いです。

EP 16: 49歳の挑戦（５ヶ月目を振り返る）

月報

2024年3月1日にHappiness Chain（以下、HC） Euforia ２期生として入会してから早いもので5ヶ月が経過しようとしています。
本記事では、この1ヶ月間で学んだことをダイジェストで振り返りたいと思います。

50歳目前の私が入会を決意するまでの経緯を書いたポエムは👇こちら hirologue.hateblo.jp

７月の学習時間（期間：6/30 - 7/30）

７月の学習時間は 118 時間 / 31日 でした。

今月も学習時間の目安として、休日は8時間、平日は3時間を基本としました。
これをカレンダーに当てはめると、今月の目標学習時間は143時間ということになります。

学習日数が31日ですので、一日あたりの学習時間は 228分（3時間48分）となりますね。

目標学習時間には 25時間足りませんでした。

ここで、これまでの学習時間の推移をグラフで表してみます。

2024年3月入会からの累計学習時間の推移

グラフの赤色で囲った部分に注目してください。
累計学習時間が600時間を突破した直後に右肩上がりだったグラフが横ばいになっています。

実はこのとき、私の左手に異変が起きました。
左肘に急に激痛が走り、腕を伸ばすことも曲げることもできなくなったのです。

左手を少しでも動かそうものなら激痛に襲われ、眠ることもままならぬ日が数日続き医者に診てもらうことに。

診察の結果、肘にでっかい石灰の塊ができていました。
こいつか・・・こりゃあデカいわ。
素人の私がレントゲンを見てもわかるくらいのサイズでした。

注射を打って、薬を飲んで安静にとのことでしたので、大人しく安静にしていました。

これが目標学習時間に25時間も足りなかった主要因です。

兎にも角にも健康第一っていうことですね。

７月の学習内容

６月はロードマップのPythonのオブジェクト指向の課題の途中まででしたので、7月はその続きからになります。



Python（オブジェクト指向）

６月中にクリアできなかった課題はオブジェクト指向に関する2題です。
入会したての頃、他のHC生の日報を見て、かなりハードな課題という印象が強かった記憶があります。

引き続き、この強敵に挑みますが納得できるものができません。
本当に手強い課題でしたが、毎日少しずつ前に進んでいることは実感できました。

毎日挑み続け、7月7日ついに課題を提出することができました。

結果は、１発クリアでした！

LGTMの４文字を見たときは本当に嬉しかった。
仕事中でしたが、スマホの通知を見て一人でニヤニヤしてました（笑）

その翌日には、最後の課題も提出することができました。
この課題もオブジェクト指向に関する課題でしたが、前段の課題でしっかり学習したおかげで思っていたよりもすんなりクリアできました。

こうして、オール１本勝ちで優勝したような清々しい気分で、ロードマップのPythonの学習内容を終えることができました。



SQL

さて、Pythonの次はSQLです。

こちらも独学時に少しだけUdemyで学習したことがあります。
なので、ここもサクッと終わるのではないかと勝手に予想していました。

ちょうどこのSQLの学習を開始したあたりから、前述の左肘の症状が出始め、日に日に悪化していきました。
インプット教材のボリュームが多いこともあり、中々前には進めません。

そして、激痛で左手が全く動かせなくなり、タイピングができない状態になりました。
治療を受け、注射と薬を服用して腕もギプスシーネで固定されました。
（実は人生で6度目のギプス固定です）
しばらく安静にして、書籍を読むことにしましたが、物凄く眠くなる（笑）

書籍を読むだけだと、わかった気になって身につかないので、PC覚えたてのおじさんのように右手だけのタイピングで学習を進めることにしました。

もちろん片手でのタイピングは効率が悪いのですが、手を動かしたことでかなり身につきました。

この記事を書いている時点で、SQLの内容の半分終わったかどうかといった進み具合です。

まだまだ道は長い。

8月中には終わらせたいですね。

今月の感想

HCに入会してから休むことなく毎日コツコツと学習を積み重ねてきましたが、7月19日に初めての休息日を設けました。
連続学習日数は140日間でストップすることになりました。

それと言うのも、2度に渡るステロイド注射でやっと痛みが収まり、体を休めることができるようになったからです。

ここまで、本当に辛かった。
横になって安静にしても痛い、寝返りも打てない、痛くて眠れないと散々でした。

大人なのに痛み止めの注射を打ったときに泣いてしまうとは・・・

毎日当たり前のように体を動かせていることに感謝しなければいけないと思ったのは、人生で初めてでした。

不本意な休息日ではありましたが、今後も学習を継続するなら定期的に休息日を設けてリフレッシュするようにしたいですね。



８月のターゲット


うちには、高校2年の娘がいます。
幼い頃の私と同様にいわゆる「お父ちゃん子」です。
その娘が高校卒業後の進路を真面目に考えたいと相談してきました。
どうやらPCを使った稼げる女性になりたいのだそうです。

え？エンジニア一択じゃね？

ということで、うちの娘も夏休みの間にプログラミング学習しています。

親子でエンジニア目指す・・・素敵やん

では、また来月！