投稿

4月, 2021の投稿を表示しています

Perl (Mojolicious) を使って web アプリ開発に挑戦 (第7回)

イメージ
 第7章 保守と拡張性が高い構造体に変更する準備 前回まででとりあえず動くものとテストコードの実装まですすみました、今の状態でも開発はすすめることはできますがアプリの機能がおおくなると今のままではコードのメンテナンスは難しくなるかもしれません。 今回はアプリをコードを書くのは一旦やめて、アプリ開発をするときにどういうディレクトリ構造をつくるのがよいのかみていきましょう。 7.1 ディレクトリとファイルの作り方 ディレクトリ構造をつくるまにUNIX的にはディレクトリとはディレクトリファイルのことであり、ファイル名というのは任意の文字でよいことになっています。 とはいえ何も考えず場当たり的に名前をつけていくと一貫性がなく何が何だかわからなくなってしまうので慣例的にこういう名前もしくはディレクトリ構造にする方が無難という考え方があります。 ファイル名について下記のまとめてみました。 ファイル名について UNIX 的にいうところのファイルとは 取り扱う情報の単位、ファイルタイプの意味で使われることがある パソコンの「フォルダ」は「ディレクトリファイル」と言われことが多い 現在は日本語のファイル名も使えるがあまり推奨はしない 正確にファイル名はディレクトリファイル名と組み合わせて表現されるので日本語をファイル名にすると使いにくくなる ファイルディレクトリの構造体について 慣例的な構造体がある Filesystem_Hierarchy_Standard Perl のスクリプトについては名前空間の規則が存在する キャメルケースとスネークケースを使い分ける アプリケーションの実行ファイルはあえて拡張子をつけないことがある 上記の点など考慮すると下記のようなディレクトリ構造になるとおもいます。 完成系のディレクトリ構造のイメージ dir # Application directory |- bin # docker-compose の中で実行するコマンド |- db

Perl (Mojolicious) を使って web アプリ開発に挑戦 (第6回)

イメージ
 第6章 テストコードと機能追加実装を同時にすすめる 今回は機能を実装しながらテストコードを実装してみますが、テストコードというのは一度作ると削除するのが難しくなり、最終的に実装のコードより大掛かりなことになってしまい、テストコード自体のメンテナンスが負担になることがあったりします。実装コードもそうですが、小さい単位で作るというのはとても大事なことです。 ここではテストコードの小さい単位での実装方法を紹介してみたいと思います。 6.1 テストコード拡張の準備 投稿記事の削除機能とそのテストコードを実装したいと思います。アクセスURLと画面遷移は下記のようなイメージになります。 URL: POST - `/remove` - remove 掲示板の削除実行 画面遷移 一覧`/list`の表示記事ヨコの「削除」ボタンクリック `/remove`アクション実行 削除実行後、一覧画面に遷移、削除完了のメッセージ表示 実際のソースコードはこちらの github からみれます。 https://github.com/Becom-Developer/beginning-mojo/tree/master/chapter6/section1 6.1.1 テストファイルを追加 % touch t/remove.t t/remove.t の中身は下記のようにしておきます。 # 暫定的にトップページのリクエストテストを書いておく use Mojo::Base -strict; # ... 省略 subtest '/' => sub { $t->get_ok('/')->status_is(200); }; done_testing(); 6.1.2 既存のテストファイルと共通化の仕組みをつくる % mkdir -p lib/Test/Mojo/Role % touch lib/Test/Mojo/Role/Basic.pm lib/Test/M

Perl (Mojolicious) を使って web アプリ開発に挑戦 (第5回)

イメージ
 第5章 完成品に対してテストコードを実装 今回はテストコードを実装してみますが、ここでいうテストコードとはどういうものなのか、説明を始めると長くなりますのでまずは手を動かしながら実際にテストコードを実行できる状態にしてから最後にテストコードとはなにかについて考えるようにしてみます。 5.1 テストコードファイルの設置 Perl の場合、テストコードのファイルは慣例的に `t/` ディレクトリのなかに `sample.t` のように `.t` 拡張子を付けて保存することになっています。Perl がインストールされている環境ならば `prove` というコマンドを実行することでテストコードを実行できる仕組みがあり、Mojo のテストコードにおいても prove コマンドで実行することができます。 実際のソースコードはこちらの github からみれます。 https://github.com/Becom-Developer/beginning-mojo/tree/master/chapter5/section1 5.1.1 ファイルを用意して実行 % mkdir t % touch t/bulletin.t bulletin.t の中身は下記のようにしておきます。 use Mojo::Base -strict; use Test::More; use Mojo::File qw(curfile); use Test::Mojo; use Mojo::Util qw{dumper}; # web アプリの実行スクリプトを指定 my $script = curfile->dirname->sibling('bulletin.pl'); # ルーティングテスト my $t = Test::Mojo->new($script); $t->get_ok('/')->status_is(200); done_testing(); 今回は docker を利用してアプリを起動しているのでもう一つターミナルのウインドウを開いて下記のように docker 経由でテストコードを起動します。 (ファイルを個別に指定)

Perl (Mojolicious) を使って web アプリ開発に挑戦 (第4回)

イメージ
 第4章 完成品に対しての課題をまとめる 前回までの作業でとりあえず動くものはできましたが、本当に最低限のものです。今後何をすればいいのか客観的に自分の作ったものを見直す時間はとても大事になります。 4.1 レビューをする時間をもうける ちなみに私が開発をしている部署では月に一回はレビュー会を実施しています。このレビュー会では開発のリーダーとなるひとや、開発の経験が浅い方も一緒になって現在開発作業をしている案件の進捗や問題点などを洗い出していくということをしています。 もし一人で開発をしていた場合は客観的に自分の作ったものを見てくれる人がいなかったりしますから、一人レビューというは難しいわけですが、それでも定期的にそういう時間を作ったほうが結果的に洗練されたものができると思います。 4.2 課題管理の手法 最近ではGithubサービスを活用してアプリ開発をするのが定番となっています。Github のイシューやプロジェクトの仕組みは大変よくできていますので、今はそれらをうまく活用するのがいいと思います。 今回ここでは、ちょっと古臭いやり方かもしれませんが、README.md に今後の課題を追記していく方法をとってみます。 4.3 課題をある程度分類しておく 課題をある程度分類しておくと優先順なども付けやすくなると思います。また、あえてこの問題はやらないという、やらない選択をする判断基準もつくりやすいでしょう。何でもかんでもやろうとすると開発というものはあっという間に破綻してしまうことがあります。 今回は下記のような分類にしておきます。 バグ - 思っていた仕様と違う挙動をしているので修正する 機能改善 - いまある機能をより洗練させる 機能追加 - 新しい機能を追加してアプリを充実させる 作業効率 - メンテナンスのしやすさやバグが発生しにくくなるような修正 4.4 まとめ 今回課題をまとめた TODO は下記の github 参考資料でみれます https://github.com/Becom-Developer/beginning-mojo/tree/master/chapter4 4.5 次回