必要だろうと思った機能を最低限つけて、バグをひとつずつ潰して、まず最初の完成形となった。

とりあえずのメモ。

データベースは、mysqlではなくてsqlite。

どうして？lolipopのmysqlは重いので、ページ表示がもっさりしてしまう。レスポンスが早い、というのがwebの絶対正義。

sqliteは複数の同時アクセスに弱いという評判だけど？確かにその通りらしいけど、ウチぐらいのアクセスなら十分。むしろファイルひとつがそのままDBなので、バックアップなどのメンテがらくちん。そっちのメリットのほうが大きい。

mysqlとかpostgresqlのようなRDBが必要になったら、そのときそのままSQLなどは移せる。

データ構成は。

基本的に、一意に決まる本の情報以外の付属情報はすべてタグとして処理。著者やカテゴリなど。でも、イベント情報関係は別テーブルで管理（同人誌の場合、イベント参加情報は重要なので）

詳細ページを閲覧された回数や立ち読みされた回数はまた別管理で。モチベーションのため。

ページ表示に使うためのマスターテーブルは特になくて、idではなくて、ユーザー入力によるテキストのタイトル部分をキーにしている、というのが後々禍根を残しそうな予感。でもたぶん、そのおかげでおそらく内部SEO対策となる、はず。urlとページタイトルとコンテンツのh1の関連が強くなるし、そこで使われるキーワードがアンカーテキストとしてページ上部に出現する、いわゆるSEOとしては理想的な構造。

サイトの目的とか。

立ち読みをしてもらう。

面白かったら作者やサークル、カテゴリで芋づる式に次の立ち読みをしてもらう。

動線はそのために作る。それによって結果として内部SEO対策となる。

表示側。

一覧ページと詳細ページだけ。あとは、利用規約など。

サイトのトップページは必要ない？意図を持ってなにかをおすすめするとか企画するようなサイトではない。なので、単純にひらたく、なんらかの一覧ページをトップにすればいい。

ページの目的は立ち読みのテキストを読んでもらうことなので、一覧も詳細もワンクリックで立ち読みが開くように。

サークル名や著者名など本に付属するデータはすべてリンクとする。面白かったら芋づる式に次を読んでもらいたいから。

登録側。

テーブル構造のまんま。必須項目などはjavascriptでUIを作る。必須入力項目が多いので、少しでも便利にしておきたいところだけど、まだまだ検討材料が多い。

同人誌に限った話ではなくて。デザフェスなんかを見て感じることで。

世間とか時代とかに、もし閉塞感があるとすれば、これからは組織に頼らない個人こそが勝負できるんじゃないかと思う。