転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分で行い、実装も原則自分で書いています。AIには手順書・レビュー・調査を任せています。
自作アプリの入力チェックを書いています。
カードのタイトルに文字数の上限をつける場面で、エディタの補完が.max(255) を出してきました。
そのまま受け取らずに、なぜ255なのかを考えてみました。
255には根拠がありませんでした
255はvarchar(255)という古い型の慣習から来ている数字です。
でも自分のデータベースはこのカラムをtextにしています。
上限のない型です。
つまり255は、このアプリのどこから出てきた数字でもありませんでした。
補完が「よく見る数字」を置いただけです。
じゃあ何文字なら大丈夫なのか
保存できる長さではなく、崩れない長さで決めるべきだと思いました。
そこで、タイトルを実際に表示している場所を見に行きました。
誰も切っていませんでした
管理画面の一覧にはtruncate（はみ出した文字を「…」で省略する指定）が
入っていました。1行に収める必要がある場所なので当然です。
公開ページのカードには、入っていませんでした。
タイトルも説明文も、長ければそのまま折り返して伸びます。
これは間違いではありません。説明文を読ませる場所なので、
折り返すのが正しい作りです。
でもそうすると、長さを止める役をどこかが引き受けないといけません。
崩れるのは1枚では済まなかった
カードはグリッドで並べていて、高さを揃えるために伸ばす指定を入れています。
グリッドは行の高さを、その行でいちばん高いものに合わせます。
1枚のタイトルが長いと、同じ行のカードが全部一緒に高くなります。
高さが揃うのは意図した動きです。ただ、揃う先の高さを決めているのが
タイトルの文字数だと気づいていませんでした。
止める場所がひとつだけだった
- データベースは
textなので、無制限 - 表示側は折り返す作りなので、切らない
- 残るのは入力チェックだけ
手順書には「この数字だけが唯一の歯止め」と自分で書いていました。
バリデーションの話として書いたつもりでした。
実際に見たら、見た目の崩れ方まで含めて、書いたとおりでした。
上限は60文字にしました。
前に書いたのと同じ形をしていました
このシリーズで前に、生成された型が手書きより弱くなっていた話を書きました。
型をデータベースに合わせた結果、間違った値を止める関門が
一緒に外れていた、という内容です。
今回のこれも同じ形でした。
- 前回：型を合わせたら、値の範囲を守る場所がなくなった
- 今回：表示を伸ばす作りにしたら、長さを守る場所がなくなった
どちらも、正しい判断がべつの場所の保証を外していたというものです。
覚えておきたいこと
層を1つ薄くしたら、その仕事を引き受ける層を決める。
薄くした判断そのものは、たぶんどちらも正しかったです。textにしたのも、折り返す作りにしたのも、理由があります。
抜けていたのは、外した分を誰が持つかを決めるところでした。
あと、補完が出す数字は疑ってみるとおもしろいです。
255には255の背景がありますが、それは自分のアプリの背景ではありませんでした。
