そういう輩にはどう対処すればいいか？

とても簡単なことですが、あっさり削除するのが一番です。
もう一歩進んだ処理をするなら、相手のサイトやIPアドレスを拒否設定してあげるとベターです。こういうことしてる人たちに遠慮は無用です。

今日届いたスパムコメント。

うわぁぁぁぁ何これぇぇぇぇぇ！！？

トシオに教えてもらったサイトでおねーさんとイチャイチャエチィーしたら
なんか知らんが９万円もらったぁぁぁぁ！！！！

とりあえずブルーレイ買ってくるｗｗｗｗｗヽ(*´ー`*)ﾉ

http://mao.acmahsjfms.com/5kolu2b/

間違ってもリンク先を見ようとしないでください。このURLは見せかけだけで、最終的な飛び先はアダルトサイトへ転送されることになっています。

ようするに、アダルト・アフィリエイトの類でしょう。
ノリスケ君というIPアドレス210.146.180.59からのコメントです。

調べてみたら迷惑コメントの常習者らしく、すでにこのIPアドレスは汚染アドレスとして登録されていました。堂々の全国１８位ですから大したものです。この順位までなっているからには、そろそろプロバイダのヴェクタントから警告がいってるかもしれませんね。

こういうスパムコメント（迷惑コメント）は遠慮なく削除してあげるのが礼儀です。
同じようにスパムトラックバック（迷惑トラックバック）も同じように削除してあげるのが礼儀です。

礼儀というと変でしょうか？

いえ、ブログを訪問してくださる普通の方への礼儀です。

検索エンジンからとか、誰かのブログを経由して訪問してくさる方たちに、こういう目障りなコメントやトラックバックを見せないよう削除する。これはブログ管理者としての礼儀だと考えたほうがいいです。

また、自分のブログをキレイにしておくことは、訪問してくれた人たちへ安心感も与えます。スパムコメント（迷惑コメント）やスパムトラックバック（迷惑トラックバック）を放置しているブログを、あなたは信用できるでしょうか？

ブログを訪問してくる人たちも同じように考えます。

ですから、こういうモノは即刻削除するのが礼儀なのです。

ただ、いかんせんデザインに制約があるため、バナーはローテーション表示させるしかない状況。
幸い、XOOPSにはバナーローテーションできる仕組みが標準にあるので、簡単な話だとヒョイヒョイと設定して終わりだと思っていた。

ところが、１つのＡＳＰさんからローテーションしてないと指摘され、よく見てみたらたしかにローテーションしていない。

考えてみたらそりゃそうだよ。
トップページの表示を速くするため、強制的に静的なHTMLページを作り出しているから、バナーローテーションするのはページを再作成する１時間ごと。それをローテーションしていると言っていいものかどうか。

FLASHなどを使えばキレイにバナーローテーションするのだろうが、あいにくそのようなスキルは持ち合わせていない。

ということで、少しネット探索して見つけたJavaScriptでのやり方を、JavaScriptをヘッダーに書くのではなく外部ファイルにする方法で試してみることにした。

参考にさせていただいたのはこちらのサイト。
バナーのローテーション表示を JavaScript で！

普通こういうローテーションを考えるとき、JavaScriptの中に表示させるバナーなども書いておいて、それをランダムや順番に表示させるのですが、このやり方は逆転の発想で、全部表示させてからJavaScriptで消すという方法になっていたのでちょっと面白い。

もし、JavaScriptをオフにされていても、ローテーションするバナーが全部表示されるだけなので、デザインとしては崩れるかもしれないが、何も表示されないよりはいいんじゃないかなぁ。

わたしとしては、こういう発想は好きです。

テキストも一緒にローテーションできるので、一瞬バナー全部が表示されてしまうことに目をつぶれば、これほど簡単で間違いない方法はないと思う。

あまり多く掲載できるスペースを確保していないので、一度に掲載できる数は限られますが、中央と右サイドのエリアを使い分けながらご紹介していこうと思います。

今掲載しているのはリンクシェア(Linkshare)さんの新しいモニタープログラムVOICEになります。

今日7月1日から、リサーチラボが会員制のモニター＆レビュープログラムとして進化しました。
アンケート回答、サンプル試供、商品モニター、レビュー記事掲載など、様々な特別プロモーションに会員だけが参加できるプログラムです。

リサーチラボと大きく異なるのは、モニターやレビューの選出に、事前アンケートへの回答が必要になったことです。つまり、アンケート回答で対象者を人選しますので、その時点でウェブリテラシーなどを問われる可能性があります。

以前より狭き門になった感じですが、良質なモニター記事やレビューを書いてもらうためには仕方がないと言えます。

ただ、逆に考えれば、モニターに選出されたら力量を認められたことにもなるので、そういうチャレンジとしてはありではないかなと思います。
個人的にはPPP(Pay Per Post)でなければいいなと願っています。

登録キャンペーンが7月末まで期間延長されましたので、まだ登録されていない方は登録してみてはいかがでしょうか。

すでにリサーチラボへ登録していた人でも、アンケート回答で特典をもらうことができます。

XOOPSの構造上これは仕方がないことなのですが、これをどうにかする方法はないものか。
ものすごくシンプルな発想をしてみました。

キャッシュを強制的に作ってしまえれば問題ないのですが、探してみたところそのようなモジュールの類はない。

それなら、定期的にトップページにアクセスさせればキャッシュを作るだろうと、CRONを使って何かできないかと考えてみたところ、ついでなのでトップページも静的に作ってしまえばいいという結論に達した。

これは簡単な方法で解決できることで、CRONで定期的にトップページをWGETすればいい。そうすればその時点のindex.htmlが作成できるので、トップのURLへアクセスされたらindex.htmlが表示されることになる。XOOPS本来のindex.phpはそのままにしてできることだし、非力なサーバーでもトップページの表示を改善できる方法だ。

具体的にはこんなシェルをCRONで毎時０分に実行しています。

#!/bin/sh
cd /virtual/xxxxxx/public_html/example.com
rm index.html
/usr/bin/wget http://example.com
exit

例はCORESERVERなので、試すときは自分の環境に合わせてください。

何をしているかといえば、
１．ドメインのトップディレクトリへ移動
２．index.htmlを削除
３．WGETでindex.htmlを作成

これだけです。

通常なら、indexページが表示される順番はindex.html→index.htm→index.cgi→index.phpとなるはずなので、先にindex.htmlを削除しておけばWGETがアクセスするのはXOOPS本来のindex.phpになり、その結果WGETで静的なindex.htmlを作成できます。

通常のURLでアクセスされたときに表示するのはindex.htmlになるので、よほど間が悪く０分にアクセスしない限り表示は速くなります。

XOOPS本来の機能で表示速度を改善しているわけではないので、あくまで表面的な表示速度の改善でしかありません。

しかし、利用者にしてみればindex.htmlだろうがindex.phpだろうが関係ないわけで、ページの表示にストレスを感じないことが一番でしょう。

そう考えればこういう方法もありかなと思います。

ちなみに、サイドバーへ表示しているブロックがトップページと共通なら、このタイミングでブロックキャッシュも作られるのでそこそこ恩恵は受けると思います。

とりあえず、標準キャッシュモジュールの機能を使っているけれど、これがいいらしいのだが悪さしている気がする。６０分ごとにキャッシュをクリアするので、そういう点ではキャッシュによるページアクセス速度の向上とページ最新性のバランスをとっている。

それはそれでいい機能だと思うのだけれど、ほかにブロックキャッシュやモジュールキャッシュという機能があるからわかりにくい。

違いがわからない男の・・・何ブレンドだろ？

それはそれとして、標準キャッシュモジュールは、ページにアクセスされたときの時刻とキャッシュが生成されたときの時刻を比較して、６０分経過していればキャッシュをクリア（削除）する仕組みのようだ。

ということは、６０分ごとにページ表示が遅い不幸な人がでることになる。これをなんとか改善できないかといろいろ調べているが見つからない。キャッシュする時間が短いなら何も問題ないけれど、不幸にしてキャッシュクリアのタイミングに訪問すると、かなりページ表示を待たされることになる。

運営していながら言うのも変だけれどわたしなら待てない。さっさと右上のバッテンをクリックするか再読み込みをクリックするだろう。

レンタルしているサーバーの性能は悪くない。廉価なレンタルサーバーの中ではサーバー単体の性能はピカ一だと思う。それを考えると、外部から読み込んでいる情報が多すぎるのだろうか。

もう少し調べてみよう。

これは、東北アフィリエイツの皆様や東北サポーターズの皆様のおかげですし、このサイトが有益なサイトだと検索エンジンのGoogleから認められたことになります。本当にありがとうございます。

ページランクに一喜一憂するつもりはありませんが、ブログやサイトを運営する側にしてみれば１つの励みになるところです。それも東北アフィリエイトマーケティング研究会のウェブサイトにですから、個人的には自分のアフィリエイトサイトで獲得したページランクより意味があると考えています。

ページランクそのものが大きな意味を持つものではありませんし、ページランクが３になったところで検索エンジンの扱いは何も変わらないと思います。
また、ページランクを見ている人は少ないと思います。

ただ、このサイトがページランク３という評価を受けたことは、大きな意味を持つと考えています。

東北アフィリエイツのウェブサイトが検索エンジンに評価された。
これはとても大切なことで、これからもっと役立つサイトとして認められるよう、コンテンツを充実していきたいと思います。

ようやく2009年の１Ｑが終わったところですので、残り３Ｑかけてもっともっと見に来てもらえるようにしていきます。

Googleの１位は『東北アフィリエイトマーケティング研究会』で、MSNの１位は『東北アフィリエイターネットワーク』になっていますが、これは検索エンジンのクセとわたしのミスが重なった結果です。あまりにも恥ずかしいので理由は書かないでおきます。分かる人が検索結果を見れば一目で理解するでしょう。

Yahooは・・・ダメですね。ここは瞬発力だけでは制覇できないのが辛いところです。じっくり時間が過ぎるのを待つしかありません。

中国期待の百度(Baido)はといえば、GoogleともYahooとも傾向が違っているようです。ただ、ドメインの年令（取得してからの年数）を強く反映している気がします。
あくまで感覚的な私見なので、『そうなのか？』くらいに受け取ってください。

それに、日本国内での百度(Baido)利用者は無視できる数字ですから、そういう意味ではまだ深く検証する必要はないと思います。

と、ここまで書きながら、１位になったことでアクセスは増えてるのかと聞かれたら、口笛を吹きながらムーンウォークでフェイドアウトします。
アドワーズ(Adwords)でデータ不足と表示される程度しか検索されてませんから。

そういう点で、今はアフィリエイトで検索する人は少なくなったのかもしれません。それだけインターネットにあるアフィリエイト関係の情報が信頼されていない。そういうことなのかもしれませんね。

まぁ、こういういサイトは口コミに近い形で広がると思いますので、地道にコツコツ広がるようにしていきたいと思います。

基本方針による登録審査はさせていただきますが、それに触れないウェブサイトやブログであれば登録承認させていただきます。

このリンク集には次のような特徴があります。

１．左サイドバーへランダム表示されますので、ウェブサイトやブログの露出機会が増えることになります。

２．リンク集からクリックされた数などにより人気サイトＴＯＰ１０に表示されます。

３．相互リンクしていただけると相互リンクサイトという独自カテゴリへも表示されます。

４．管理スタッフの独断になりますがおすすめサイトに登録されるかもしれません。

５．現在試行中の高評価サイトへ表示される可能性があります。

６．施設や企業のウェブサイトなどは、管理スタッフの判断でGoogleMapsによる地図表示をさせていただきます。
また、GoogleMaps対応サイトというカテゴリへも表示されます。

７．自動的にトップページのスクリーンショットが取得されますので、テキストリンク集より訴求性が高くなっています。

８．登録時に取得したGoogleページランクが表示されますので、ウェブサイトやブログのアピ－ルポイントになります。

これからもいろいろ考えて機能アップしていこうと考えています。

ここからはお願いになりますが、ぜひ１つは各県のアフィリエイツというカテゴリへ登録してください。東北６県でアフィリエイトをしている人がどれだけいるのか、ＡＳＰやＥコマースへのアピールポイントになります。

ここに登録されている数により、これから東北へイベントやセミナーを誘致できるかどうかがかかってきます。現在複数の企業と交渉していますが、最終的には見込み人数がどれくらいになるのかがポイントになります。

そういう意味で、各県アフィリエイツのカテゴリにウェブサイトやブログを１つは登録していただきたいと思います。

ただ、どちらかといえば『CORESERVER』のほうがサーバー単体性能はいいので、すでに別サイトで使っていた『CORESERVER』をマルチドメインで使うことにしました。

XOOPSやMovableTypeなどサーバー側に負荷をかけやすいCMSのばあいは、サーバー性能を優先したほうが良い結果になることがあります。回線性能とサーバー性能の両方を求めるなら、何ランクか上のサーバーを検討したほうがいいと思いますが、この辺に微妙な費用の分かれ目が存在するものです。

移転した日中は快適だと感じたのですが、一番混雑する時間帯になるとあまり変わらない感じがします。

感じとして、『ロリポップ』のばあいは定常的に遅くて『CORESERVER』は時間帯に左右される。この時間帯になると回線負荷に左右されるのかなと感じます。

なんらかの形でサーバー維持費が捻出できるなら、月額1000円以上のサーバーを検討してもいいと思いますが、そうでなければ月額500円というのは魅力です。

これからまた、しばらくチューニングを楽しめそうなので少しゲンナリしてますが、まぁ、それも嫌いではないのでいいかなと考えてます。

キャッシュにはモジュールキャッシュとブロックキャッシュがあり、これをうまく使ってあげることで表示速度が大幅に改善されるようだ。
参考までに今回やったことを記録しておきたい。

サイトのコンポーネントは次のとおり。
・XOOPS Cube Legacy 2.1.6
・d3pipes 0.66c
・altsys 0.71a

(d3pipesを使うためにインストール)
・xupage 0.93
(個人的にpicoが使いにくいのでこっちにした)
・logcounterx 2.72
・sitemap 1.31

この中でモジュールキャッシュを指定したもの。
・d3pipes 0.66c
・xupage 0.93
・sitemap 1.31

また、d3pipesを使ったブロックのうち同期表示しているところはブロックキャッシュを指定した。
加えて、カスタムブロックはほとんどテキストやリンクしかないので、これらは全部ブロックキャッシュを指定した。
d3pipesを使って非同期表示しているところは、JavaScript呼び出しがキャッシュされるだけだと思うので指定しなかった。

ここまでで少しいい感じの表示速度になったと思う。

XOOPS_TRUST_PATH配下のblock_sync.htmlとmain_jsbackend.htmlを変更した。

１．<ol～>・・・</ol>を<div～>・・・</div>に変更
２．<li>・・・</li>を<div style=”clear:both;”>・・・</div>に変更
３．日付表示をdiv要素にしてクラスを指定
４．表示するリンクをdiv要素にしてクラスを指定
ついでに外部リンクの時は外部リンクの画像を表示する
５．style.cssに３と４のクラスを追加
（どこに追加すべきかわからんかったので）

あとはレイアウトに合わせてCSSを書き直すだけ。

ものはついでだったので、使っている無料テーマも少し変更。
ヘッダ部分へメールアドレスの表示をやめた。InternetExplorerを少しお利巧にするIE8.jsを使うことにした。これで少しはレイアウトの微調整が減る。

も１つついでにフォントにメイリオを追加してみた。
こうやってみるとSafariのレンダリングって優秀だなぁ。ものすごくキレイに表示される。これからSafari派になろうかな。

いやぁ、ここまで見事な場違い感ははじめてかもしれないな。

まぁ、それはそれとして淡々と講義を受け続けましたけどね。

全体的な感想を言えば、やはりビギナーズということで基本の再確認という感じでした。XHTMLとCSSの基本的な使い方や現場に即した使い方。半日で９セッションやるのだから時間は足りなかったとは思うけど、個人的にはもう少し詳しく知りたいとこもあった。

ただ、鷹野さんのセミナーは良かった。ものすごくいい！
説明にメリハリがあるし、参加者のレベルに合わせて言い回しを変えてくる。この辺の臨機応変な対応は場慣れだと思うけど、それだけじゃないようにも思う。

なんていうんだろう。大袈裟な言い方をすれば熱意と愛を感じた。自分が話すことを、より多くの人に理解してもらえるように気持ちが参加者のほうを向いている。自分が話していないときでも会場の雰囲気を感じ取り、そこで不足していると思ったことは他のスピーカーへ自分の疑問として投げかける。

これを当たり前にできるってすごいことだと思う。
今回のセミナーで最大の収穫はこれかな。
自分がプレゼンするときには注意していきたいし、そういう気持ちを後輩なんかにも伝えていかなければと感じた。

ちなみに、鷹野さんの会社のサイトはMovableTypeのようです。
株式会社スイッチ

しかし、どうやらD3Pipesのほうが自分の好みに合ってるようなので、昨夜一気に切り替えることにした。

それに、よく調べたらD3Pipesを使うほうが最近の流れのようだ。

ということで、D3Pipesを使った感想。

これまでパースエラーを起こしていたサイトのフィードが問題なく取得できる。
同期表示と非同期表示が選べるので、最初に見える範囲はページレンダリングと同期表示にして、スクロールしないと見えない範囲は非同期表示にした。
これでページの表示開始が少し早くなった気がする。

ただ、気に入らないので何点かカスタマイズした。

１．日付表示がフルだったものを月日だけにした。
/xoops_trust_path/modules/d3pipes/templates/の
block_sync.html
と
main_jsbackend.html
２．同じように日付表示を年月日だけにした。
/xoops_trust_path/modules/d3pipes/templates/の
inc_entries.html
３．外部リンクの場合別ウィンドウで表示するようにした。
１と２のテンプレートで外部リンクへ「target=”_blank”」追加
４．他のブログのフィードから全文表示しないようにした。
/xoops_trust_path/modules/d3pipes/templates/の
inc_entries.html
で表示部分を削除

残った課題。

・表示の折り返しが左端までくるからとても見づらい。
これをなんとかしたい。

試みた最適化の中には、一部ロリポップ(LOLIPOP)だからできる手法が含まれているので、その点は注意して読んでいただきたいと思う。

まずサーバー環境の最適化だが、これはロリポップ(LOLIPOP)だからできると考えていただいていいと思う。わたしがレンタルしているさくらとコアサーバーでは指定できなかった。指定の仕方があるのかもしれないが、今のところ改善の必要がないのでそれ以上調べていない。

サーバーチューニングといっても大した内容ではなく、ようするに再読み込みされる時にローカルパソコン側のキャッシュを使う指定と、FileETagの比較を行わないようにするだけだ。
ExpiresActive on
ExpiresByType image/gif  “access plus 7 days”
ExpiresByType image/jpeg “access plus 7 days”
ExpiresByType image/png “access plus 7 days”
ExpiresByType application/x-javascript “access plus 7 days”
ExpiresByType text/css “access plus 3 day”
FileETag none

これで画像ファイルとJavaScriptは１週間、CSSは３日間キャッシュを使うことになるので、再読み込み時の表示を高速化することができる。
とはいえ、ローカルパソコン側のインターネットキャッシュ（インターネット一時ファイル）を毎回クリアされれば、これらの設定は何も意味を持たないことになる。そういう点では見せかけの高速化策といえなくもない。

本当の意味での最適化はここからの手法であり、これはどこのサーバでも同じような効果を得ることができる。また、XOOPSだろうがWordPressだろうがMovableTypeだろうが、同じことがいえる手法なので覚えておいて損はないと思う。

・画像はできる限りGIFを使う
・CSSとJavaScriptを圧縮する

画像に関しては個人の好みもあるし、サイトの表現になるのでGIFだけで構成できないかもしれない。
しかし、できる限りGIFを使ったほうが画像サイズは小さくできるメリットがある。GIFに置き換えることができるなら、積極的にGIFを使うほうが表示速度向上には役立つ。

次にCSSとJavaScriptの圧縮だが、頻繁にメンテナンスしないものならば圧縮するほうがいい。
圧縮といってもGUNZIPなどを使った圧縮ではなく、テキストの余計な制御文字を取り去るだけの方法で、次のサイトなどを使えば簡単に圧縮することができる。
Compress javascript and css.

上のサイトでは数回のコピー＆ペーストが必要になる。
他にローカルパソコンのファイルをアップロードして圧縮してくれるサイトもあるようなので、コピー＆ペーストが面倒な場合はそちらを探すといいでしょう。

サイト表示のどこに問題がありそうか調べるにはここが便利です。
Pagetest web page performance test

初期読み込みと再読み込みにかかる時間を細かく分析してくれます。

それにしても、ある程度最適化しても表示開始まで約３秒かかるとは、ロリポップ(LOLIPOP)でXOOPSを動かすのは厳しいかもしれない。おそらくMySQLの処理時間に取られていると思われます。WordPressの場合はここまで性能が悪くなかったので、データベースのテーブル数の違いだと思われます。

なんでいまさらEUCなんだよと思いつつ、面倒なのでそのままインストールしていた自分が悪いわけで、いつかサーバー移転する際には全部UTF-8に切り替えたいと思います。

とりあえずサイトオープンを優先したために、手持ちでテスト用に使っていたロリポップをサーバーに使いました。PHP5になったことだし、データベースサーバーの性能不足を補えるかなと思ったのですが、どうやらそれは期待できないものだと実感しました。ことMySQLに関して、ロリポップはいまだに性能不足が顕著なようです。

いくつかサーバー性能を軽く確認したうえで、負荷が少なそうなデータベースサーバーへ移転したので、サイトの表示でストレスを感じることはなくなったと思います。ついでにカウンターもゼロクリアして、あとは１月１日０時をまつばかりです。

１月１日に急にこだわるようになったのは、やはり１年の計は元旦にありということで、サイトオープンを記念すべき日にふさわしいだろうと考えたことが一番です。
また、普段はあまり気にしませんが大安吉日ということも１つの理由です。

まぁ、そんなこんなでなんとかサーバー移転も終了して、あと３時間少々を待ちたいと思います。