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/14(日)リソース状況 その3

リソース状況 その3

アクセス・リソース状況
日付ページビューグラフCPU使用時間グラフウェブ転送量グラフ
2014/12/1360255
2時間38分56秒
4.96GB
2014/12/1246571
2時間13分13秒
4.15GB
2014/12/1124631
1時間47分 9秒
4.32GB
2014/12/1024959
2時間 5分46秒
4.32GB
2014/12/0927210
1時間51分48秒
4.80GB
2014/12/0825372
1時間56分48秒
4.25GB
2014/12/0734138
2時間39分52秒
6.19GB
2014/12/0632728
2時間25分14秒
5.57GB
2014/12/0529505
2時間17分 2秒
5.06GB
2014/12/0425888
2時間21分15秒
5.01GB
2014/12/0324984
1時間44分50秒
4.17GB
2014/12/0222825
1時間42分57秒
3.95GB
2014/12/0124100
1時間43分 2秒
3.66GB
2014/11/3029206
2時間 2分 3秒
4.88GB
2014/11/2925177
1時間48分32秒
4.13GB
2014/11/2818354
1時間27分12秒
3.06GB
2014/11/2718493
--
2014/11/2619682
1時間27分52秒
3.35GB
2014/11/2518971
1時間27分52秒
3.29GB
2014/11/2423916
1時間45分41秒
4.07GB
2014/11/2320239
1時間30分58秒
3.36GB
2014/11/2219867
1時間29分49秒
3.37GB
2014/11/2116170
1時間16分 7秒
2.75GB
2014/11/2015450
1時間19分22秒
2.49GB
2014/11/1912708
1時間10分52秒
1.77GB
2014/11/1812545
1時間 39秒
1.86GB
2014/11/1713939
1時間 6分 2秒
1.84GB
2014/11/1614340
1時間 9分48秒
1.89GB

日曜前後に山があって、大局的にはアクセスはだんだん増えてる傾向でしょうか。とはいえ、今のところは問題になるような感じでもないですね。

時間ができたら、bodycache patchを #include を使っているページにも適用できるように改造したいところ。

2014/12/04(木)ECO-Wiki (acronia) スパム状況

ECO-Wiki (acronia) スパム状況

日付種別内容アクセス元
2014/11/24pcommentQuest/Waterlayer台湾
2014/11/25pcomment香港
2014/11/29pcomment(URLの羅列)ウクライナ
2014/12/01pcommentアニバーサリーBOXタイ
2014/12/02newpage(宣伝スパムっぽい)U.S.
2014/12/03newpage(宣伝スパムっぽい)U.S.

頻度はそれほどではないですが、今までの所上記のようなスパム投稿がありました。

なんだか、無意味な単語投稿と、宣伝スパムの2種類があるような感じです。

香港の人はECO関係の掲示板*1から来ていたようですし、コメント欄があったので何か書いてみたくなったのかな?


今のところ、スパムっぽいのは全部国外アクセスのようなので、国外からのコメント投稿とページ編集を禁止して様子を見ようかと思います。

*1 : 日本のECOをプレイする際の注意点とかが載ってました。オープンチャットで中国語しゃべらないようにとか、うっかりしゃべっちゃったら「誤爆ごめん」って謝るようにとか。