浅野直樹の学習日記

この画面は、簡易表示です

AWSのLightsailでDjango設計図を使いできるだけ簡単にローカルで開発したプロジェクトを公開する

記事タイトルの通りです。

 

AWSのLightsailにはDjangoの設計図(テンプレート)が用意されているので簡単に公開できるのかなと思っていたのですが、意外と苦労しました。

 

そのための手順を説明した記事やドキュメントも不足気味です。

 

そこでこの記事にまとめました。

 

1.前提

ローカル環境でDjangoのプロジェクトの開発をして、GitHubで管理していることを前提とします。

GitHubのリポジトリの中にrequirements.txtファイルやmanage.pyファイルとDjangoのプロジェクトディレクトリがあり、Djangoのプロジェクトディレクトリの中にsettings.pyファイルがあると想定します。

ウェブサーバーはApache、データベースはMariaDB(MySQL)とします。

AWSのアカウントは設定済みとします。

 

2.インスタンスを作成する

インスタンスの作成は簡単です。

Lightsailからインスタンスを作成する画面で、設計図のところからDjangoを選ぶだけで、その他はデフォルトのままでよいです。

必要なら適当に変更してください。

表示言語設定は画面下部の赤丸で囲んだところにあるので、日本語がよければここから日本語に変更してください。

 

3.インスタンスに接続する

ターミナルのようなアイコンをクリックするか、縦に3つの点が並んでいるアイコンをクリックして「接続」を選ぶかして、ブラウザベースのSSHクライアントを立ち上げます。

黒い背景にコマンドを打ち込むターミナル画面が起動すれば成功です。

インスタンスを作成してから数分経過しないとうまく立ち上がらないです。

簡単さのためにこの記事ではブラウザベースのSSHクライアントを利用しますが、お使いのマシンからSSH接続しても構いません。

 

4.GitHubからリポジトリをクローンする

(1) リポジトリをクローンするためのディレクトリを作成する

どこでリポジトリをクローンしてもよいのですが、Bitnamiの公式チュートリアルのGet started with Djangoに従って配置したほうがわかりやすいです。

sudo mkdir /opt/bitnami/projects
sudo chown -R $USER /opt/bitnami/projects

コマンドの貼り付けは、右クリックからするようにしてください。

(2) GitHubのアカウントにSSHキーを追加する

秘密鍵と公開鍵を作成し、公開鍵をGitHubのアカウントに追加します。

秘密鍵と公開鍵を作成するコマンドは以下です。

ssh-keygen

いくつか質問をされますが、デフォルトのままエンターキーを押していけばよいでしょう。

次に、作成した公開鍵を表示します。

cat /home/bitnami/.ssh/id_rsa.pub

ssh-rsaから始まってbitnami@ip-172-26-9-251のような文字列で終わる暗号のような文字が表示されるはずですから、この全体を右クリックからコピーします。

それを以下のようなGitHubのSSHキー追加画面に貼り付けて追加します。

titleの部分は何でもよいです。

(3) GitHubからリポジトリをクローンする

これでGitHubからリポジトリをクローンできるはずです。

cd /opt/bitnami/projects/

git clone git@github.com:GITHUBACCOUNT/GITHUBREPOSITORY.git

GITHUBACCOUNTとGITHUBREPOSITORYの部分は、ご自身のリポジトリに合わせてください。

初回の接続なので接続するかどうかを尋ねられますが、「yes」と入力してエンターキーを押してください。

 

5.pipコマンドでPythonのパッケージをインストールする

GitHubのリポジトリ直下に用意したrequirements.txtファイルを利用して必要なPythonのパッケージをインストールします。

cd /opt/bitnami/projects/GITHUBREPOSITORY

sudo pip install -r requirements.txt

GITHUBREPOSITORYは先ほどクローンしたGitHubのリポジトリ名です。

mysqlclientのインストールに失敗するはずなので、mysqlclient · PyPIに載っている以下のコマンドを実行してから再挑戦します。

sudo apt-get install python3-dev default-libmysqlclient-dev build-essential pkg-config

sudo pip install -r requirements.txt

インストールの確認を求められたら、yと入力してエンターキーを押してください。

Lightsail自体が仮想環境なのですから、Pythonの仮想環境を作成せず、sudoでpipを実行してインストールしています。

これが一番簡単です。

 

6.データベースを作成する

MariaDB(MySQL)が最初からインストールされてはいるのですが、Djangoで使うためのデータベースを自分で作成しなければなりません。

データベースに接続するためのパスワードがわからなくて私はハマりました。

ホームディレクトリのbitnami_application_passwordに書いてあるのですね。

ということでまずそのパスワードを表示します。

cat /home/bitnami/bitnami_application_password

パスワードが表示されたことを確認してから、次のコマンドを実行します。

mariadb -u root -p

パスワードの入力を求められるので、先ほど表示させたパスワードを右クリックからコピーし、右クリックで貼り付け、エンターキーを押します。

MariaDBに入ることができたら、以下のコマンドを実行して、データベースを作成します。

CREATE DATABASE XXXXXXXX;

XXXXXXXXの部分には、Djangoのプロジェクト名など、適当なデータベース名を指定してください。

データベースを無事に作成できたら以下のコマンドを実行してMariaDBから抜けます。

quit

 

7.Djangoの設定をする

(1) settings.pyを調整する

Get started with Djangoを参考にしてsettings.pyを調整します。

データベース接続の部分は以下のように設定します。

DATABASES = {
  'default': {
    'ENGINE': 'django.db.backends.mysql',
    'NAME': 'XXXXXXXX',
    'HOST': '/opt/bitnami/mariadb/tmp/mysql.sock',
    'PORT': '3306',
    'USER': 'root',
    'PASSWORD': 'PASSWORD'
  }
}

XXXXXXXXの部分は、先ほど作成したデータベース名にします。

PASSWORDの部分は、bitnami_application_passwordに書いてあるパスワードにします。

ALLOWED_HOSTSの部分は、接続確認を優先して、ひとまず*に設定します。

ALLOWED_HOSTS = ['*']

接続確認できたらドメイン名に設定し直してください。そのときにDEBUGもfalseにしてください。

Lightsailに配置すべきsettings.pyファイル全体をローカル環境のエディタで記載し、それをコピーして貼り付けるようにするのが簡単かなと思います。

まずsettings.pyファイルが存在しているかを確認します。

cat /opt/bitnami/projects/GITHUBREPOSITRY/DJANGOPROJECT/settings.py

GITHUBREPOSITRYは先ほどクローンしたGitHubのリポジトリ名、DJANGOPROJECTはそのリポジトリ直下にあるはずのDjangoのプロジェクト名です。これらは同じ名前にすることが一般的ですが、異なる名前でも構いません。

settings.pyファイルの存在確認ができたら、それをviで開いて、内容をいったん全部削除し、ローカル環境からコピーした内容を貼り付けます。

vi /opt/bitnami/projects/GITHUBREPOSITRY/DJANGOPROJECT/settings.py

viでsettings.pyファイルを開きますので、以下のコマンドを入力してエンターキーを押して内容をいったん全部削除します。

:%d

ローカル環境のエディタで作成したsettings.pyファイルの内容を全部コピーして、右クリックから貼り付けます。

そうするとviの入力モードになっていますから、Ctrl+Cを押してコマンドモードに移行し(Escではコマンドモードに移行できませんでした)、次のコマンドを実行して保存して終了します。

:wq

ここでは簡便さのために直接settings.pyファイルを編集しましたが、できれば.envファイルで設定するほうがよいです。

 

(2) データベースにmigrateする

ここからはLightsail特有の手順ではなくDjangoの標準的な手順です。

python /opt/bitnami/projects/DJANGOPROJECT/manage.py migrate

このようなコマンドでmigrateします。

上記は絶対パスで記載しましたが、DJANGOPROJECTディレクトリの中にいるなら以下のコマンドで実行できます。

python manage.py migrate

 

(3) 静的ファイルをcollectstaticで集める

これもmigrateと同じ要領です。

python /opt/bitnami/projects/DJANGOPROJECT/manage.py collectstatic

または

python manage.py collectstatic

 

8.Apacheの設定をする

本来であれば、ここでmanage.pyのrunserverを実行して確認するとよいのでしょうが、そのためにはファイアウォールの設定を追加するなどの手間が生じますので、いきなりウェブサーバーであるApacheの設定をします。

基本的にはDeploy a Django projectに書いてある手順に従います。

sudo cp /opt/bitnami/apache/conf/vhosts/sample-vhost.conf.disabled /opt/bitnami/apache/conf/vhosts/sample-vhost.conf
sudo cp /opt/bitnami/apache/conf/vhosts/sample-https-vhost.conf.disabled /opt/bitnami/apache/conf/vhosts/sample-https-vhost.conf

コピーしたApacheの設定ファイル中のsampleをGITHUBREPOSITORYとDJANGOPROJECTに置換します。

GITHUBREPOSITORYとDJANGOPROJECTが同じ名前なら、以下のコマンドだけで置換できます。

sed -i s/sample/GITHUBREPOSITORY/g /opt/bitnami/apache/conf/vhosts/sample-vhost.conf

sed -i s/sample/GITHUBREPOSITORY/g /opt/bitnami/apache/conf/vhosts/sample-https-vhost.conf

GITHUBREPOSITORYとDJANGOPROJECTが異なる名前なら、以下のように2段階で置換します。

sed -i s/sample/GITHUBREPOSITORY/g /opt/bitnami/apache/conf/vhosts/sample-vhost.conf

sed -i s@GITHUBREPOSITORY/GITHUBREPOSITORY@GITHUBREPOSITORY/DJANGOPROJECT@g /opt/bitnami/apache/conf/vhosts/sample-vhost.conf

sed -i s/sample/GITHUBREPOSITORY/g /opt/bitnami/apache/conf/vhosts/sample-https-vhost.conf

sed -i s@GITHUBREPOSITORY/GITHUBREPOSITORY@GITHUBREPOSITORY/DJANGOPROJECT@g /opt/bitnami/apache/conf/vhosts/sample-httpsvhost.conf

最後にApacheを再起動します。

sudo /opt/bitnami/ctlscript.sh restart apache

 

9.ネットワークの設定をする

ブラウザでインスタンスを作成したページに戻り、「Django-1」のようなインスタンスの名前をクリックして、「ネットワーキング」というタブから、静的IPをアタッチします。

そこに表示されているパブリックIPV4アドレスの数字をブラウザのURL欄に打ち込むと、ページが表示されるはずです。

httpsではないためにブラウザが警告を発することがありますが、危険性を承知の上で続行するとページが表示されます。

 

10.HTTPSの設定をする

独自ドメインのAレコードに先ほど接続確認をしたパブリックIPV4アドレスの数字を設定してからの作業になります。

Auto-configure a Let’s Encrypt certificateに書いてある手順そのままです。

sudo /opt/bitnami/bncert-tool

リダイレクトの設定やメールアドレスなどを質問されるので、適当に答えてください。

 

11.ハマりやすいポイント

(1) ブラウザベースのSSHクライアント

ブラウザベースのSSHクライアントのコピーアンドペーストに少しハマりました。

結論としては、すべて右クリックで操作することです。

SSH接続のための公開鍵のコピーをコマンドでしようとしたら失敗しました。

また、viもEscキーでコマンドモードに戻れないなど、いつもの操作と挙動が異なり戸惑いました。

日本語が表示されず文字化けすることにも苦しめられました。

環境変数の変更などを試してみてもうまくいきませんでした。

文字化けしている部分をコピーしてSSHクライアント以外の場所に貼り付けると読めるようになるので、それで一時しのぎはできます。

 

(2) Pythonのパッケージ管理

結論としては、上記に記載したように、/opt/bitnami/projects/以下にDjangoのファイルを配置して、sudo pipでパッケージをインストールすることになります。

最初はホームディレクトリにDjangoのファイルを配置したせいで、wsgi.pyファイルで no module named DJANGOPROJECT(DJANGOPROJECTは具体的なプロジェクトの名前)エラーが発生してハマりました。

/opt/bitnami/apache/logs/error_logのApacheのエラーログを見てこのエラーに気づきました。

そのときはwsgi.pyファイルに以下の記述を追加して一時的に切り抜けました。

import sys
sys.path.append(os.path.dirname(os.path.abspath(__file__)))
sys.path.append(os.path.dirname(os.path.abspath(__file__)) + '/..')

この記事の上の部分で説明したように公式ドキュメントに準拠した場所に配置すれば、このような一時しのぎは不要です。

 

(3) mysqlclientのインストールエラー

これも記事中に記載した通りです。

公式ドキュメントをきちんと読まなければなりませんね。

 

 



プログラミング学習にまつわる雑感(コーディング原則本等の自分なりのまとめ)

私は、この数年で、プログラミングスクールの講師や実際の現場でコードを書くなどのエンジニア関係の仕事の比重が高まり、プログラミング学習について考えることが多くなってきました。(それ以前の経験についてはWebサイト制作の個人史Webサイト制作の個人史2をご参照ください。)

仕事での実践とともに、趣味的に雑多なコードを書いたり学習をしたりしつつ、コーディング原則本なども読み漁りました。

そこで考えたことをこの記事にまとめます。本記事の末尾に掲げた10冊の本の内容を極度に圧縮した記事だと言えます。

私はエンジニアとしての経験が決して豊富ではありませんが、様々な分野での学びと教える経験は豊富なので、これからプログラミング学習を始めようとしている人だけでなく、経験豊富なエンジニアに対しても新しい視点を提供できればと思って執筆しました。

 

1.プログラミングの特徴

天下り的な記述をさせてもらうなら、プログラミングの特徴は次の2点だと私は考えるに至りました。

(1) プログラムは製作物であるとともにドキュメントである→動作だけでなくわかりやすさも重要

(2) 結果の正しさを容易に観測できる→素早い変化や修正に開かれていることが重要

(1)は、車やテレビなどほとんどすべての製作物はドキュメント(設計図や説明書)とは別個なのだけれども、プログラムは製作物がドキュメントでもあるということです。ですので、求める動作をすることはもちろん、わかりやすさも重要になります。

(2)は、例えば宇宙物理学や心理学や政治学は、(装置や倫理などの理由から)仮説を立ててもその正しさを観測するのが極めて困難であるのに対し、プログラミングでは意図した動作をするかどうかという正しさを容易に観測できるということです。農業は収穫物という形で結果の正しさが目に見えやすいですが、結果を得るまでに数か月から年単位の時間がかかる場合が多いので、分単位や秒単位でPDCAサイクルを回すことのできるプログラミングほどには結果の正しさを観測するのが容易ではありません。この特徴は、プログラミングでは、作って、確かめて、変更して…というプロセスを何度も繰り返すということにつながります。

ChatGPTをはじめとした生成AIでプログラミング関係の精度が高く利用価値があるというのも、この点に関わっているのではないかと私はにらんでいます。生成されたコードが正しく動作すればそれでよいと言えるからです。政治学に関する質問をして生成された回答の正しさをすぐに確かめる術はないこととは対照的です。

 

2.コーディング共通原則のまとめ

いくつかの本に書かれていて、概ね受け容れられているであろうコーディングの共通原則を、上記の2つの特徴を軸にまとめることができます。以下では、その観点から、私が重要だと捉えているコーディングの共通原則を取り上げてコメントします。

なお、リファクタリングにつきましては、以下の共通原則に従うように適宜コードを見直すことであって、水準が異なりますから、独立した項目にはしませんでした。

わかりやすい名前をつける

これがコーディング原則の第一歩かなと思います。(予約語などの不適切な名前は当然除外するとして)変数や関数などにどのような名前をつけても同じように動作しますが、ドキュメントとしての読みやすさは全然違ってきます。わかりやすい名前をつけると、脳の認知負荷が顕著に減ります。

読みやすいコードを書いてコメントで補う

プログラミングコードは製作物であるとともにドキュメントでもありますから、コード本体が読みやすいのが理想です。読みやすいコードを書けない場合は、コメントで補うべきです。その手の本によく書かれていることですが、数か月後の自分は他人も同然であり、数か月後に変更や修正をすることもよくありますから、わかりやすいコードとコメントはとても大切です。

DRY、KISS、YAGNI

それぞれ、Don’t repeat yourself(繰り返しを避ける)、Keep it simple stupid(シンプルで愚鈍にする)、You ain’t gonna need it(それはきっと必要にならない)の頭文字を取った原則です。繰り返しがなければコードが読みやすくなるとともに変更も1箇所で済み、シンプルであればわかりやすくて機能の追加もやりやすく、プログラムは変更が容易なので先回りしすぎず必要になったときに機能を付け加えると割り切って考えやすいです。

 

3.議論のあるコーディング原則

以下では議論のあるコーディング原則を取り上げます。混乱を招く可能性があるので、自信のない人は読み飛ばしてください。

オブジェクト指向か関数型か

要はわかりやすいほうを採用すればよいのではないでしょうか。オブジェクト指向にすると、コードのわかりづらい部分を設計図に相当するクラスの部分に書いてインスタンス化して使う部分の記述が簡潔になります。大規模なライブラリはオブジェクト指向で設計されていることが多いので、それを使う際には必然的にオブジェクト指向の記述になります。私は、大規模な仕組みを一から作ることはまずないので、自分で定義する場合には関数型にします。

テスト駆動開発

テスト駆動開発も、効率が上がりわかりやすくなるなら採用すればよいですし、そうでなければ無理に採用する必要はないと考えます。テストは結果の正しさの観測をさらに容易にする仕組みだと捉えることができます。ですので、結果の正しさを観測して変更することを何度も繰り返すことが予想される場合にはテストを書いたほうが効率的ですし、何が正しい動作であるのかがテストによりわかりやすくなります。他方で、テストを書くにも労力がかかり、テストコード自体は読みづらいことも多く、そのデメリットを上回りメリットがなければテストを書かなくてもよいのではないかと私は考えます。

疎結合と密結合

疎結合がもてはやされる風潮がありますが、今後必要とされるであろう変化や修正に開かれていることが重要だということに行き着くと私は考えます。例えば、(WP REST APIを駆使して意識的に疎結合にしようとしなければ)WordPressは簡単に始められることの裏返しとして密結合になりやすいですが、それが問題になるかどうかは状況次第です。小さな団体の外部告知用ホームページなら今後機能面の変更が必要になる可能性は低いのでWordPressで問題ないことがほとんどでしょうけれども、いろいろな機能の追加が予定されているウェブアプリをWordPressで作ろうとすると将来的に苦労する姿が目に浮かびます。仮想化やクラウドについても同様で、変化が見込まれそれらを使ったほうが合理的なら使えばよいし、必要なさそうなら使わなければよいです。

そもそも、何が一つの結合かということにも議論の余地があります。単純化をするべきか過度の単純化を避けるべきかという問題も、結局のところ中庸と言いますか、適度なバランスということになるのかなと思います。

 

4.「わかりやすさ」と「正しさ」の深堀り

ここまでは「わかりやすさ」と「正しさ」を自明で一つに定まるものと想定してきました。しかし、前節の議論からも垣間見えますように、「わかりやすさ」と「正しさ」は自明でもなければ一つに定まるとも限りません。

「わかりやすさ」は人によって大きく異なります。これは私の学び教える経験から自信を持って言えることです。同じ説明をしても、とてもわかりやすいと感じる人もいれば、まったくわからないと感じる人もいます。その人の前提知識や好みによって大きく左右されます。

コードにコメントを書くときも、未来の自分に向けるなら自分にとって難しく感じたことのメモを書きますし、非エンジニア向けならそうと意識して書きますし、プログラミングスクールの受講生向けなら教育的配慮をしますし、野球の好きな人が読むなら野球のたとえを使います。

使用しているプログラミング言語やフレームワークの慣習に従うと、その慣習を共有している人にとってはわかりやすくなります。ですので、私は、LaravelやDjangoを使うときに、標準的な構成にして、そのビジネスドメイン固有のロジックはUseCasesとして別のディレクトリに切り出すようにしています(5年間 Laravel を使って辿り着いた,全然頑張らない「なんちゃってクリーンアーキテクチャ」という落としどころが提示しているこの方法がわかりやすさの絶妙のバランスを保っていると私は感じています)。

本記事における「正しさ」は「依頼主が求める動作」という意味ですが、これにしても自明で一つに定まるとは限りません。求める動作を事前に依頼主が正確に見極めていることのほうが珍しいです。「顧客が本当に必要だったもの」という標題の下にで示されるブランコの絵は有名ですよね。

顧客が本当に必要だったものから学ぶこと | Casley Deep Innovations株式会社 技術ブログ

ここまでの記述からお気づきの方も多いかと存じますが、私は圧倒的にアジャイル派です。結果の正しさを容易に観測できるというプログラミングの特徴を最大限に活かせるからです。金融や人命に関わるようなミッションクリティカルで大規模なプロジェクトではなく、ウェブや業務効率化などの小規模プロジェクトに従事してきたという背景もアジャイルを推す理由になっています。

 

5.プログラミング学習のコツ

正しさ=求める動作をはっきりさせる

この流れからプログラミング学習のコツを考えるなら、正しさ=求める動作をはっきりさせるところからスタートすべきです。

現状に不満がなければわざわざプログラミングを学ぶ必要はありませんし、ZoomやkintoneなどのSaaSで解決できるならそのほうが早いです。車輪の再発明をする必要はありませんからね。怠惰は美徳という言葉もあります。どれほど美しいコードも、その仕事が必要ではなくコードがいらないことには劣ります。

自分では特に作りたいものはないけれどもプログラミング関係の仕事ができるようになりたいということでしたら、将来の顧客の立場で何を作りたいか考えてください。

正しさ=求める動作がはっきりしてきて、そのためにプログラミングが必要だということになりましたら、臆せず取り組んでください。自分は専門家ではないからと遠慮しなくてもよいです。何らかの動作を求めるその領域では自分が専門家です。正しさを決めるのはエンジニアではなく依頼主です。自分が作りたいものがあってプログラミングを学ぶということで依頼主とエンジニアが同一人物なら、自分が作りたいものが作れればそれでよいのです。

プロトタイプを早く形にする

その際には、欲張りすぎず、最小の労力で最大の効果が得られる部分を早く形にすることを目指すとよいです。リーンスタートアップで言うところのMVP(Minimum Viable Product、実用最小限の製品)です。80-10-10の法則と80:20の法則に共通して、少しの労力で大部分の仕事は片付けられるという含意があるということもあります。

スモールステップで少しずつ進むのがコツです。入試問題でも小問に沿って進んでいくと大きな問題も解けるということに似ています。余談ですが、私が入試科目とプログラミングを問わず教える仕事をするときには、いかに小問を刻んでいくかということを大切にしています。適切に小問を刻んで区切ることができれば、それだけで解決することも多いです。

最初はとにかく動けばよいという感覚で試行錯誤することになりますが、動くことを確認できたらきれいなコードにリファクタリングするようにすると、実は近道になります。

私の個人的な経験の紹介

私自身の実例をいくつかお伝えします。

まず、2000年から2010年頃にかけて、ホームページ(ウェブサイト)を作りたいと思いました。正しさ=求める動作は、インターネット上で内容を見ることができるということです。現在なら各種SNSやWordPressを使うでしょうが、当時はHTMLとCSSを新たに学びました。

次に、動的なサイトを作りたくなって、Perlを学ぶとともに、開発環境としてLinux(Ubuntu)を使い始めました。Linuxを使うことには、比較的古いPCでも無料のOSで快適にウェブブラウズや文書作成をしたいという目的もありました。それまで使っていたWindowsからLinuxにいきなり全面的に切り替えるのは困難だったため、併用しながら少しずつ置き換えていきました。最初はLinuxの世界に圧倒されましたが、ウェブブラウズさえできればいいのだと目的をはっきりさせると、案外簡単にできました。当時よりも現在のほうが環境が整っていますし、Linuxに挑戦してみることをみなさまにもお勧めします。

それから、数学の教材を作るためにTeXを使い始めました。それまではWordのフィールドコードで数式を入力していたのですが、特に分数などを表示するのが面倒だったので、分数が登場する計算問題のプリントをTeXで作ることを当面の目標に据えました。最終的にはTeXとemathでグラフや図形も自由に描けるようになりました。

比較的最近のこととしては、Pythonで給与計算などの業務効率化をしました。これもExcel等でやっていた業務を少しずつPythonに置き換えていきました。

何をどのように学ぶかを計画する

正しさ=求める動作をはっきりさせたとしても、何をどのように学んでいくかは迷います。次々と新しい技術が登場することもあって全部を学ぶことは到底できませんが、古い技術にしがみついて非効率になるのも避けたいです。損得で考えるなら学習コストを固定費と見立てて損益分岐点を考えることになるでしょうが、将来的な投資という意味合いや好みや楽しさも考慮します。個人的には、LinuxやSQLあたりは長年の検証を経て安心感があるとともに陳腐化しにくいので将来を見据えた学習の投資をする価値があり、好みにも合致していて楽しいと感じます。

専門分野を持っている人がプログラミング学習をすることに意義がありますし、逆にエンジニアが特定のビジネス領域のことを知るのも同じように意義があります。この記事の最初のほうで述べたプログラミングの2つの特徴からそう言えます。わかりやすさも正しさも特定のビジネス領域の知識と大いに関係しますので。

人月の神話やブルックスの法則はコミュニケーションコストの大きさを示唆しています。自由な文章から判例を検索できる判例探索サービスを作りましたのように一人で全部完結させるとコミュニケーションコストはゼロです。

もっとも、一人でできることなどたかが知れているので、何らかの形での協力関係を築くことは必須です。フリーソフトウェアやOSSがそのための一つの形かもしれません。

具体的な学習法

何のために何を学ぶかをおよそ決めた後は実践あるのみです。定まったカリキュラムがあるわけではなく自分の実現したいことを中心に学ぶことになりますが、あまりにも断片的な事柄をインターネットで検索しても道に迷って時間を浪費しがちです。

そこで、どこかの時点で公式ドキュメントをざっと一通り読むことを私はお勧めします。わからないことがあっても深く気にせず、公式ドキュメントのどのあたりにどのような内容が書いてあったのかをだいたい把握しておくと、後が楽になります。私は、割と早い段階でLaravelの公式ドキュメントInstallation – Laravel 10.x – The PHP Framework For Web Artisansを一読したことが、そのときにはすっきり理解できなくても、後で大いに役立ったと感じております。

網羅的にまんべんなく学習するという意味では、資格試験を活用するのも吉です。資格試験は自分の知識に抜け落ちがないかの確認にもってこいです。日時を決めて受験を申し込むと勉強する気分が高まります。

本を読むことも、情報が古いかもしれないという欠点はありますが、安定的な知識を網羅できるという点で有効です。PCの画面にばかり向かっていると目が疲れるので、休憩を兼ねて本を読むこともできます。

もちろん、わからないことや気になったことをインターネットで調べることも日常的に行っています。日々新しい技術や概念が登場しますから、それを調べて学習できる生活の余裕があるということが一番大切かもしれません。

 

6.落ち穂拾い

UNIX哲学の一つに、設定やフィルタにテキストを用いるという原則があります。バイナリではなくテキストを扱うということは、わかりやすさの点から極めて重大な点です。

それに比べると、CUIかGUIかという点は、ケースバイケースかなと思います。テキストを扱うCUIのほうがわかりやすい場面もあれば、見た目で直感的に操作できるGUIのほうがわかりやすい場面もあります。一定の知識や技術のある人が繰り返し作業をするときはCUIが適しているとは言えそうです。

AWSの操作をするとして、慣れないうちはGUIで操作するのが簡単だけれども、慣れてきたらIaC(Infrastructure as Code)という点からもCUIベースに移行したほうがよいでしょう。

WordPressのブロックエディタは、従前の手法と比べるとGUI的な要素が強くなっており、わかりやすいと感じるかわかりにくいと感じるかは人それぞれでしょう。DRY原則に準拠していて素早い変化や修正に開かれていますから、フロントエンドから入った人がブロックエディタを極めるというのは一つの道なのかなと思います。

最後に大事なこととして、透明性が挙げられます。透明性はわかりやすさの前提条件ですし、透明性を高めて多様な観点から結果の正しさを観測することも頑健性につながります。

 

7.参考文献

本記事ではページ数を示して直接引用することはしませんでしたが、以下の文献で提示されていたアイデアを咀嚼して再構成しました。興味のある人はぜひ直接読んでみてください。

総合的なコーディング原則本


リーダブルコード : より良いコードを書くためのシンプルで実践的なテクニック


作 者: 

出版社: オライリー・ジャパン

発売日: 2012年10月05日

コーディング原則本として真っ先に挙げられるのが『リーダブルコード』でしょう。おもしろい絵と具体例が豊富で読みやすいので、最初に読む本としてお勧めします。


プリンシプルオブプログラミング : 3年目までに身につけたい一生役立つ101の原理原則


作 者: 

出版社: 秀和システム

発売日: 2016年06月08日

こちらの『プリンシプルオブプログラミング』も有名ですね。興味深い原則や法則を紹介してくれる本です。


プログラマが知るべき97のこと


作 者: 

出版社: オライリー・ジャパン

発売日: 2011年03月04日

『プログラマが知るべき97のこと』は、いろいろな人の意見や考えが寄せ集められており、インターネット上で全文を無料で読めますから、気軽に読めます。


ルールズ・オブ・プログラミング : より良いコードを書くための21のルール


作 者: 

出版社: オライリー・ジャパン

発売日: 2023年09月15日


『ルールズ・オブ・プログラミング』は新しめの本です。C++で書かれているゲームのコードが例に取られているので、読みやすいと感じる人もいれば読みにくいと感じる人もいるでしょう。

古典


人月の神話


作 者: 

出版社: 丸善出版

発売日: 2017年08月16日

『人月の神話』は古典的な部類ですね。歴史的な読み物と思っていただいてもよいかもしれません。プロジェクトマネジメント寄りです。


UNIXという考え方 : その設計思想と哲学


作 者: 

出版社: オーム社

発売日: 2001年07月30日

『UNIXという考え方』も古典的です。技術寄りです。


フリーソフトウェアと自由な社会 : Richard M.Stallmanエッセイ集


作 者: 

出版社: アスキー

発売日: 2003年09月04日

『フリーソフトウェアと自由な社会』は、フリーソフトウェアやオープンソースを考える書です。

各論


リファクタリング : 既存のコードを安全に改善する


作 者: 

出版社: オーム社

発売日: 2019年12月20日

『リファクタリング』というタイトルの通り、リファクタリングについて第一に読むべき本です。


テスト駆動開発


作 者: 

出版社: オーム社

発売日: 2017年11月10日

『テスト駆動開発』という書名にもなっている概念が斬新です。


エリック・エヴァンスのドメイン駆動設計 : ソフトウェア開発の実践 : ソフトウェアの核心にある複雑さに立ち向かう


作 者: 

出版社: 翔泳社

発売日: 2019年12月16日

『エリック・エヴァンスのドメイン駆動設計』はかなり読みにくいのですが、大事なことが書かれているような気がします。

 

 

 



自由な文章から判例を検索できる判例探索サービスを作りました

司法試験短答式過去問演習サイトの解説を作り始めましたでお伝えしましたように、司法試験短答式過去問演習サイトの解説を少しずつ作っています。

 

その過程で、短答式試験の選択肢となっているような自由な文章から判例を検索したいというニーズを強く感じました。

 

裁判例検索 | 裁判所 – Courts in Japanではキーワードから検索できても自由な文章に対応していませんし、Google等でその文章に「判例」というキーワードを加えて検索しても思うようにヒットしなかったからです。

 

それなら自分で作ってしまおうと思って作りました。

 

司法試験過去問題集

 

2023年11月中旬頃までの最高裁判例を対象としています。

 

技術的な詳細は追ってお伝えするとして、概要を紹介します。

 

以下のデモ動画の50秒あたりからが判例探索の部分です。

 

 

 

比較的うまく表示されたものを、2023年司法試験短答式試験からいくつか紹介します。

・憲法第9問

求める判例がトップに表示されています。

 

・民法第23問

この1ページ目の左から3番目の判例がここでは最適かなと思いました。

他の判例も読むと勉強になります。

この4ページ目の4番目の近時の判例は、民事訴訟法の論点とも大きく関わっています。

 

・刑法第20問

3番目の判例にこの問題の着想を得たのでしょうね。

 

検索する文章が長いほうがうまく表示される傾向にあります。

Legalscape、大規模言語モデルを活用した次世代型リーガルリサーチAIを開発——森・濱田松本法律事務所との協働により高い精度を達成し、今後の実用化を目指す (2023-06-12) | 株式会社Legalscape | リーガルスケープに対抗意識を燃やして試してみた結果も載せます。

この1ページ目の結果は、近いですが、ズバリの判例はありませんね。

この6ページ目の4番目にようやくズバリの判例がありました。

 

一人で趣味的に作ったにしては悪くありませんし、最近の司法試験では論文式試験でも判例の比重が高くなってきているような気もしますので、学習者としてはいろいろな判例に寄り道するのもしっかりとした力を涵養するのに役立つと思います。

 

 

 



令和5年司法試験成績通知(論文)

令和5年司法試験の成績通知を公開します。

試験科目 順位ランク
憲法 B
行政法 C
民法 B
商法 A
民事訴訟法 A
刑法 C
刑事訴訟法 D
選択科目 35.71
合計点 395.84
順位 1397

再現答案も過去の記事にありますので、ご参考になれば幸いです。

出来のよくない科目もありますが、どうにか合格できたという感じですね。



司法試験短答式過去問演習サイトの解説を作り始めました

司法試験短答式過去問演習サイトを作りましたで紹介した司法試験短答式過去問演習サイトの解説を作り始めました。

 

実質的な内容である法律面と、形式的な枠組みのコード面の両面において、試行錯誤を繰り返しながら悪戦苦闘しています。

 

一人で両方をやるとどうしても時間がかかりますが、連携に齟齬が生じるということはありませんし、作りたいものを作ることができます。

 

例えば、法律を学習する際には記憶への定着のしやすさから判例には事件名を必ずつけるようにしたいと思いました。一人二役ですから、コードを書くエンジニアとして「事件名が空白のこともありますか?」といった質問をせずにすみます。

 

1.解説の内容

最初は自分の言葉で解説を書こうとしましたが、あまりにも労力がかかりますし、その割には得るところが少ない(下手な解説よりも判例や条文をたくさん読みたい)ので、すぐにやめました。

 

次に、その問題を解くために必要な判例や条文をピンポイントで切り取って示そうと考えましたが、それも思ったより大変でしたし、その問題とは直接関係なくても判例や条文の周辺事項が知りたいこともあるので、単純に判例と条文をそのまま示そうと決めました。

 

基本的には判例と条文をそのまま示す、それができないときに限り自分の言葉で簡潔な説明をするという方針が定まりました。

 

2.解説の表示方法

解説をどのように表示するかも悩みました。

 

判例はPDFをそのまま見せ、条文はその法律の条文全体を見せる方向に決めたので、それなりに大きな表示領域が必要です。

 

そのような用途ならモーダルかなと思ってしばらく調べました。

 

VuetifyのDialogを試してみて、問題文と同時に解説の判例や条文を見たいからモーダルをドラッグできるようにしたくてvue-js-modalをインストールしようとしてバージョン不適合に遭遇し、もう一度VuetifyのDialogに戻ってドラッグできるように改造している人のコードを借用させてもらって(vue.js – how to make vuetify dialog draggable – Stack Overflow)思うように動かせるようになりました。しかし問題文が見づらくこれじゃないと感じたのでやり直しです。

 

私はPCで司法試験短答式過去問演習サイトを使いますから、右サイドバーに解説を表示すればよいと思い直しました。

 

PDFファイルの埋め込みにはvue-pdfを使ってもよかったのですが、特にこだわりはないのでobjectタグにしました。

 

3.解説で表示する判例と条文の取得

解説で表示する判例と条文の取得でもいろいろ悩みました。

 

(1)判例

判例は、APIが公開されているわけではなさそうだったので、自力でURLを解析して理解しました。

 

結果詳細ページは「https://www.courts.go.jp/app/hanrei_jp/detail2?id=判例ID」のようなURLで、全文PDFは「https://www.courts.go.jp/app/files/hanrei_jp/判例ID下3桁/判例IDゼロパディング6桁_hanrei.pdf」というURLです。判例IDさえわかれば両方のURLを構築できます。

 

ただ、その全文PDFをそのまま右サイドバーに埋め込むことはちょっと試してみた限りできなかったので、ダウンロードして自前で準備することにしました。著作権法13条3号があるので著作権的にも問題ないはずですし、後々判例検索機能を作ったりするときにもそのほうが便利だろうと思いました。

 

(2)法律の条文

法律の条文については法令APIがあるのでこれを使うものだという思い込みがありました。

 

最初はその問題に関係する条文の部分だけをマウスカーソルを合わせたらツールチップとして表示するのがカッコいいのではないかと考えました。元データのcsvファイルでは「joubun ken 63」のような必要最低限の情報だけ盛り込み、そこから法令APIで必要な情報を取得するという方向です。

 

必要最低限の情報から表示用に変換するreplaceの関数内では非同期処理が使えなかったのであえて同期処理でAPIに問い合わせるなど、苦労しました。実際にツールチップとして表示してみると、それほどカッコよくもなく、前後の条文を読みたいこともよくあるので、シンプルに法律全体を表示する方向に舵を切りました。

 

法令APIでは法律全体を取得することもできます。ただ、XML形式での取得になります。そこで、XMLからHTMLに変換するにはどうしたらよいかをかなり調べました。Vue.js内で自分で一つずつ置換することやfast-xml-parserを使って解析することなども考えましたが、XSLTスタイルシートがXMLからHTMLに変換する専用のツールのようだとわかったので、これに取り組みました。

 

かなりの程度思い通りに変換することができたのですが、e-Gov法令検索で項が丸数字で表現されているのを再現するところで嫌になりました。

 

そこでふと、わざわざXMLからHTMLに変換しなくても、e-Gov法令検索からhtmlファイルを取得して保存してそれを読み込めばよいのではないかと思いつきました。著作権法13条1号から著作権的に問題ないはずですし、毎回APIに問い合わせるよりも効率的です。司法試験の短答式試験で関係する法律は限られていますし、それほど改正もされないでしょうから、毎回APIに問い合わせる必要なんてないです。むしろ、法改正に敏感になって、差し替える際に改正点のチェックをするほうがよいとも言えます。

 

昔読んだ深沢千尋『すぐわかるPerl』の「美しいプログラミングの費用対効果」というコラムを思い出しました。

 

 さて、費用対効果的に効率のいい解を出すのは、プログラミングの技術だけとは限りません。
 一度、スケジュール管理ソフトで、春分秋分の日(天文学上の要請でその年その年で変わる)をカレンダーに入れる必要が生じました。総理府を出発点に電話で情報の検索を始め(当時はこんなにインターネットが一般的でなかった)結局とある有名な科学機関に到達しました。電話に出たほうは年配の天文学者らしかったですが、実に機嫌良く話してくれました。「地球だけが太陽の回りを回っているならよいが、実際には月と地球からなる系(けい)が回っており…」から始まる堂々たる講義で、ぼくは必死にメモを取りました。
 電話を切ってからちょっとがんばってプログラミングしようとしましたが、1分ほどぼうっと考えて、急に思いついたことがあって、また同じ方に電話しました。「あのー、これから30年間の春秋分の日、わかりますでしょうか」。幸いにもリストがあって、教えてもらうことができました。そのとき作業していたプログラムは、どんなプログラムもたいていそうですが、30年も現役で動くとは思えません。そこで聞いた値を定数で埋め込みました。これで十分だったわけです。ぼくはあまりいいプログラマーではありませんが、このとき出した解はニートな解だったと思います。プログラミングにはパソコンだけでなく、電話も使えるという話です。

深沢千尋『すぐわかるPerl』(技術評論社、1999)224ページ

この本が出版されてからもうすぐ30年ですが、確かにこのPerlのスケジュール管理ソフトが現役で動いているという可能性は低そうです。仮に動いていたとしても、またこれから30年分の春秋分の日を問い合わせて定数で埋め込めばよいだけですしね。

 

4.現在の完成形

このような感じです。

作りたいものが作れました。

ソースコードや動作するサイトはAsano-Naoki/shihoushikenからどうぞ。

 

 

 




top