ブラウザでの画面表示と印刷の描画差異に関する実践的考察
会社が新しくなったので、本格的にホームページを作ることにしました。
前からちょぼちょぼ作ってはいたのですが、コンテンツ自体が前の会社の丸パクみたいな感じでいろいろみっともないので、気合いを入れて直そうと思い立ちました。
前の会社のブログはいつまでかは未定ですが、とりあえずそのまま遺しておくことにしたのと、もう更新することはありえないのでデータベースは凍結ということにしました。
そんなわけで、新しい環境でCMSを設定しようと思ったのですが、久しぶりにCMSのコードを見てみることとしました。
そうしたら、太古のコンテンツエディタはRailsで書かれていましたが、それをNode.jsにした時に色々やった痕跡とか出て来たので、この辺何とかした方がいいかなと思いました。あの時はDBをそのまま移行させることに意味があったのでフィールド名とかマッピングさせる必要があったのですが、今回は全く新規にやるのでその辺は考えなくて済みます。
その他、後付けで増やした機能とかあまり練られてないものがあったりするので、この際なので直してしまうことにしました。
と同時に、他のアプリのコードを大幅にリファクタリングしたので、それと同じようなリファクタリングをしたいなという気持ちもあります。まぁ要するに「過去との決別」をして行こうということです。
とりあえず、
- DBスキーマの見直し
- コードの構造の見直し
- プラットフォームの更新
- 機能の見直し
あたりをやって行こうと思います。割と大幅な改修に見えるのですが、大した規模のソフトウェアではないのでそんなに工数はいらないと思ってます。まぁ1週間もいらないかな。
DBスキーマの見直し
Railsとの互換のためにやっていたことを全部消してしまって、Sequelize nativeのDB設計にしてしまいます。
Sequelizeを未だに使うのは、Prismaの日付処理があまりに残念でバグの温床になりそうだったので避けたかったからです。慣れてしまえばPrismaの方が綺麗な気もするのですが、時期尚早だなと。逆にSequelizeは色々古臭いのではありますが。
Railsと言うかRubyなものは命名がsnake caseになっていて、Javascriptはcamel caseが普通という違いがあって、この辺を調整するためのマッピングをしていたのですが、今回はcamel case主体でやることにしました。まぁ実のところsnake caseの方がpsqlを使う時に楽ではあるのですけど。
他にはActiveRecordではリレーションはActiveRecord内での処理にしていたのを、Sequelizeの流儀に合わせてDBのリレーションで処理するようにします。
また、ついでなので、migrationを繰り返して定義されていたテーブルについては、現在の最終形に合わせてcreateするようにしました。何しろ元のCMSのDBを最初から作ろうと思うと、Railsのインストールから始めなきゃいけませんからね。
この辺をすっきりさせると、Sequelizeの欠点でもある「スキーマの最終形がよくわからない」という問題も解消します。
コード構造の見直し
現在のCMS(V3)は
- コンテンツエンジンとAPI
- オーサリング用フロントエンド
という構成になっています。これを、
- コンテンツエンジン
- APIとオーサリング用フロントエンド
に構成しなおそうと思っています。元々、コンテンツエンジンとオーサリング用フロントエンドとに分かれていたのですが、ヘッドレス化をした時にAPIをコンテンツエンジン側にしてしまったからこうなってしまったわけです。
まぁこの辺は趣味みたいなところがあって、mayumiと私の好みは違うってだけなんですが。
プラットフォームの更新
とりあえずwebpackはやめたいなと思ってます。最近のライブラリはwebpackだと妙なことになるものが結構あって面倒臭いので。
あとは、できれば完全ESM化してしまっておきたいところです。現状だと、バックエンドはCommonJSでフロントエンドがESMということで、ライブラリの観点からすると別の言語で書かれているのも同然ですから。
機能の見直し
ちょっと前にセカンダリのカテゴリを付けられるようにしたのですが、これが微妙に使い辛いので「タグ」を使うようにしようと思ってます。タグのライブラリは現在開発中の他のアプリで作ったものがあるので、それを流用すればすぐでしょう。
と同時にカテゴリそのものを廃止しようと考えています。結局コンテンツを「カテゴリ」なんて概念で分類するなんて無理なんじゃないかと。
