2015/01/20(火)ECO-Wiki画像リサイズ

ECO-Wiki画像リサイズ

こちらの記事(ECO-Wikiでの画像縮小・拡大)でふれていた、ブラウザ側でリサイズされていた画像について、一部*1をリサイズ済みの画像と差し替えました。元画像は、サフィックス _big を付けたファイル名にリネームして残してあります。

ECO-Wiki上の画像サイズ指定について

画像差し替えの際に、画像の実サイズと表示サイズを一通りチェックしたのですが、想像していた以上にいい加減でした^^;

例としては、

  • 実サイズ:177x111 → 表示サイズ:100x100
    • 縦横比が合っていない
  • 実サイズ:128x128 → 表示サイズ:127x127
    • 周りの画像は表示サイズ128x128に統一しているのに何故か1ピクセルだけ縮小
  • 実サイズ:128x123 → 表示サイズ:123x128
    • 縦と横が逆

単純ミスのものもあるでしょうし、既存の記述をコピーして修正したときに画像サイズ指定をそのままにしてしまったという可能性もありそうです。不特定の人が編集する場合は、画像サイズ指定は省略した方が無難なのかもしれないですね*2

画像アップローダーは実サイズを指定した&ref記述を生成するので、これをそのまま使ってくれる分には問題はなさそうですが。

*1 : 全部は数が多かったので気になったところを中心に。

*2 : サイズ指定しておくと、画像読み込み前にページレイアウトを確定できるという利点もあるので、サイズ指定自体は悪いことではないのですが。

「アンケートページ:今後の ECO wiki について」のコメント

最近、「アンケートページ:今後の ECO wiki について」をチェックしていなかったので気づくのが遅れましたが、

装備品データベース等を面倒ではあるが独立したWikiとしての公開をするべきと思う
acroniaでは別のサイトに飛ぶが検索する閲覧者に酔ってみれば使い勝手が良い物とは言えない

というコメントが付いてますね。

ただ、このコメントの意図がよく分からないです。

  • 「検索」がWikiの検索機能を指す場合
    • 独立したWikiでは検索は結局別々なので解決にならない。
    • 今のECO-Wikiに含めるなら検索はできますが、ECO-Wikiが肥大化しかねない。
  • 「検索」がGoogle等の検索を指す場合
    • データベースが検索にかかるようにすることを考えるべき。*3

あと、データベースにしておかないと、細かな条件を付けた検索や、データの機械的な再利用が困難になるので、よほどの事が無ければデータベース化が望ましいと思います。

・・・というか、Wiki管理だと数が多すぎて破綻しそう^^;*4

*3 : 今のデータベースは検索エンジンに非常に優しくない実装です。まあこれは割切ってやっているのですが・・・。

*4 : イリスカードの索引とかWiki上に作ったのは凄いと思う。私は手間かけるのが嫌でイリスカード一覧を作りました。

2015/01/08(木)圧縮転送による読込時間改善、他

圧縮転送による読込時間改善

以前、ECO-Wiki (acronia) でページ生成時間を表示するようにしましたが、内容が多いページではかなり時間がかかっているのが気になりました。

例えば、Iris/Explanationでは

HTML convert time: 0.007 sec. (total: 2.447 sec.)

と数秒かかり、実際に体感できるロード時間も同程度です。

これは、Iris/Explanationだとページ(HTML)サイズが約700kBとちょっとした画像並みに大きいため、単純に転送に時間がかかっていると思われます。

そこで、転送データをgzip圧縮して転送量を削減してみることにしました。さくらのレンタルサーバーは半年くらい前からmod_deflateが使えるようになったらしいので、以下の記述*1を .htaccess に追記します。

<FilesMatch "\.php$">
	SetOutputFilter DEFLATE

	BrowserMatch ^Mozilla/4\.0[678] no-gzip
	BrowserMatch ^Mozilla/4 gzip-only-text/html
	BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

	AddOutputFilterByType DEFLATE text/html
</FilesMatch>

続きを読む

2014/12/31(水)アイテムデータベース更新

アイテムデータベース更新

データベース間の連携に関連して、アイテムデータベースを何度か更新しました。データベース連携の方針についてはちょっと悩んだのですが、アイテムデータベースに連携機能を集中させる方針にしました。最終的にアイテムデータベースで以下のことができるようになっています。

  • 装備品データベースの登録データもアイテム一覧に表示
  • モンスターデータベースのドロップアイテムを参照し、入手方法として表示
  • 製法データベースを参照し、入手方法・用途として表示
    • 「No.」クリックで製法データの詳細を表示

これらの機能は基本的にブラウザ側で実装している*1ため、ブラウザ側の処理がどうしても重くなってしまい、特にページを開いたときの読み込み時間は長めになっています。ただ、読み込み完了後の操作感については従来とほとんど同じなので、実用上はそれほど問題ないと思います。

*1 : ブラウザでデータベースを4つ読み込んで処理しています。サーバー側は連携に関して本当に何もしないという実装。

2014/12/20(土)モンスターデータベース更新

モンスターデータベース更新

久しぶりに、モンスターデータベースを更新しました。

データベースシリーズは、

  1. モンスターデータベース
  2. 装備品データベース
  3. アイテムデータベース
  4. 製法データベース

の順に、以前のソースコードを流用しながら作っていたのですが、新しい方にいろいろ修正・改善をしていく内に、一番古いモンスターデータベースも直したくなったので、今回いろいろモンスターデータベースにフィードバックしました。

普通に使う分には機能面で特に変わったところはないのですが、以下のような変更がされています。

  • デザインを他のデータベースに合わせた
  • データの受け渡しをgzip圧縮したJSON形式に変更した*1
    • 閲覧だけならサーバー側プログラムは動作しない
    • ブラウザキャッシュも効くようになったはず
  • JavaScriptライブラリは他のデータベースと共通のファイルを参照(ブラウザキャッシュが参照されやすくなる)
  • データベース処理で、バリデートなどのデータ項目依存の処理を分離*2
  • Unicodeで普通は使わない文字をはじくようにした
  • 管理用の機能をいくつか追加

圧縮とキャッシュのおかげでロードは早くなったように感じるはず・・・。

*1 : 以前は、圧縮していないJavaScript。また、データ構造もオブジェクトから配列に変更しています。配列にするとkeyが不要な分若干データ量が減少。

*2 : 項目数がかなり多い装備品データベースで必要になった措置