2019/04/29
今回は、2019年のGW期間(10日間)を全て費やして取り組むポートフォリオの製作過程
を取りまとめた内容を投稿させて頂きます。(投稿は毎日行う予定)
全体通した取り組みの詳細については、前回までの記事をご参照ください。
【10日間でポートフォリオ作成に挑戦】1日目:要件定義〜記事投稿のCRUD
【10日間でポートフォリオ作成に挑戦】2日目:アクセス制限〜コメントのCRUD機能
ここからは、今日1日で取り組んだ作業内容をご説明します。
前回作成したER図ですが、かなり見辛いのと、userとpostの中間テーブルが1対多の方向が誤って逆になっていた為、修正を行いました。
↓変更前個人開発かつ、そこまで規模大きく無い為、別に綺麗する必要は無かったかもしれませんが、こちらの方が気持ち良いので、モチベーション的にやって良かったと思ってます!!
続いて記事一覧のページネーションを実装します。
実装にはgemのkaminari
を利用しています。
gem 'kaminari'
kaminari
では、下記の様にコードを一部変更するだけで、ページネーションを実装することが可能です。
↓変更前
def index
@posts = Post.all
end
= render @posts
↓変更後
PER = 10
def index
@posts = Post.page(params[:page]).per(PER)
end
= render @posts
= paginate @posts
Materializeのデフォルト設定で、レイアウトがお洒落になっていますが、これでページネーションのサーバーサイドは完成です。
続いてCKEditorを導入します。
CKEditorとは、WYSIWYGエディタと呼ばれるユーザーにリッチな編集フォームを提供するツールです。
CKEditor 5
今回は記事の詳細をリッチに編集できる様にすべく導入しました。
導入には、フロントサイドのパッケージマネージャーであるyarn
を利用しています。
yarn init
yarn add ckeditor
ここからは今日の失敗を紹介します。
CKEditorを導入すると、それまでの動作が大きく変化して修正が面倒になると考え、CKEditorでの記事作成/編集機能が完成するまでは、テストコードは書かないと行こうと考えていました。
しかし、実際に実装を行って見ると、機能を追加する度にブラウザでチェックする手間が発生し、また、どの機能が動作不全に陥っているか直ぐに特定出来ず、そこで時間を割かれてしまいました。
また、CKEditorの導入で動作が変わると言っても、根幹の部分は変わらないので、少しの修正だけで済んだと思われるので、テストを書かなかったのは、タイムロスだったと感じています。
せめて単体テスト・統合テストのどちらかだけでも、事前に書いておけば良かったと考えています。
現在の職場ではテストコードを必ず書く運用になっていますが、改めてテストコードの有用性を実感しました。
ER図にある通り、記事の詳細については、Postテーブルと分けて管理する構成にしています。
しかし、実際に分けるのは、CKEditorを導入してからで良いと考えて、記事のCRUDを実装する際には、同じPostテーブル上で管理していました。
これが、後々の修正を面倒にしてしまいました。
例えば下記のコードです。
= post.title
= post.description
description
を別テーブルに分けると、この部分の修正が必要になります。
また、viewファイルにdescription
の情報を渡すために、コントローラーの修正も必要です。
そもそも、分けた状態で記事のCRUDを実装する事も出来たので、二度手間な判断をしてしまったと反省しています。
この一件で、下記の一文を思い出しました。
早くできるからと手を抜いてコードを書くと、機能追加やコードのリファクタリングが難しくなります。
プログラマが知るべき97のこと(分別のある行動)にも
以下の様に書かれています。
今後は拙速に走り過ぎず、先を見越した実装を行って行きたいと考えています。
かなり無茶な計画を立ててしまったと、今になって思い出したので、工数の見積もりを修正して行きたいと思います。
とりあえず下記を目標とする。
そしてテストコードを早く書こう・・・テストが無いと駄目だ・・・やってられん・・・テスト・・・
※追記:四日目の記事を投稿しました
【10日間でポートフォリオ作成に挑戦】4日目:テーブル分割〜CKEditorのフォームへの反映