あるデータが更新されたかどうかajaxで打診して、されてたら全体をリロードするみたいな処理を自作CGIサイトに入れようとしてるんだけど、サーバの負荷が心配。打診はいくらなんでも10秒毎ぐらいにはしないと用をなさない。現在ユニークIP2千くらいだからまだ大丈夫だと思うけど、利便性が上がるとそれはそれで人が増える可能性がある。
意図的に中途半端な導入の仕方をするかもしれない。
サイト管理のブログ記事
いまどきアフィリエイトに幻想を持っている人もいないかもしれないけど、いかに厳しいかの実例というか、私のCGIサイトの5月の収益グラフを出してみる。
5月全体で50万回以上広告を表示してあがりは約2千円(暫定)。いやぁ...。
日別グラフは青がインプレッション(表示回数)で、緑が収益です。5日と6日が極端に落ち込んでいるのは、バナー表示があまりに遅いために自ら大半の広告を切ったからで(重かったのはたぶん広告サーバの不具合かなんかだった)、人為的な原因です。28日の落ち込みは広告会社側で表示する広告が無くなったようで、広告会社自身の広告が表示されていました。それは当然表示カウントとして有効ではないようです。
私が利用している広告プログラムは表示とクリックの両方で収益になるというたてまえなのですが、5月は、表示のレートは500回表示で1円くらい(但しスマホ用広告は幾分これよりわりがいい)。クリックはまちまちなのだけど1クリック5円~10円くらいのレートが多いと思います。
クリック率が低めですが、ググると同じプログラム利用者でも0.02%とか平気でいるみたいなので、他と比較してとんでもなく低いわけではありません。
私はちゃんと(?)バナー広告を貼るようになってからあんまり期間が過ぎていないのでそう確かなことは言えないんだけど、以前と比べるとかなり広告料のレートが下がっているらしく、今後さらに下がるかもという流れらしい。Amazonなども今月からの紹介料引き下げを公式に発表している。Amazonは1年位前まではたいていなんでも紹介料5%位(販売価格の)だったような曖昧な記憶だけど、今は品目によっても2%~3%くらいが大半という感じで、フィギュアとかは0.5%(!)になったらしい。私はフィギュア1個の値段とかに詳しくないけど、たぶんかなりな惨状になると思われる。
私のCGIサイトのクリック率はたぶんあがりようがないかもしれない。無機質過ぎて、なんかキャラクターとか貼ったとしても逆に奇異なだけだろうし。PVそのものは上のグラフからでも推測できるかもしれないけれど、一貫して漸増していることはいる。しかしほんとにゆっくりで急激な変化はとても望めそうもない。ほったらかしにできるってとこだけが強みかな。
今日さくらインターネットから下記メールが来ていて古いMovable Typeが危ないとの注意喚起が書かれていた。このブログはまさに古いMovable Typeに該当すると思うのだが、なんか外部からエントリーそのものが書き換えられるのだそうだ。
で、最新のMTが入らないのは分かっているので、移行を念頭に国産のbasercmsていうのの最新ブログプラットフォームを入れてみたのだが、サーバにエラーが出てたので諦めた(ネット情報では入るはずだったのだが、バージョンが違ったのか、インストールの過程で失敗したのか)。
しかたがないので、ググりながら頭をひねりMT4のエントリー書き込みをつかさどる(見る側は関係ないです)cgiファイルにベーシック認証をかけることにした。かなり簡易な認証なんだけど、それでもあるとないじゃ大違いらしく、該当cgiファイルにアクセスするのに一応パスワードが要求されることになる。暗号の設定に少し手間取ったものの、うまく投入できたみたいなのでよかった。
しかしアクセスログを見ると、我が過疎ブログには今のとこそんなに怪しげなのはない感じというか、以前ロシア語のアダルト広告がコメント欄に連投されてコメント欄を認証制にしたんだけど、それ以降はきわめて平穏。まあ、あとは臨機応変に構えとこう。
追記(2014/05/24):
.htaccessで特定cgiファイルに対して自分のIP以外を弾くような設定を付加してしまった。ちょっと厳重すぎるというか、公衆LANとかネカフェから更新するのがやや面倒になってはしまうけど、そんな機会はたぶんあんまりない。これでIP制限に二重認証(ベーシック認証とMT本来の認証)てことで過疎ブログにしてはやや滑稽なほどの多重防御なわけだが、しばらくやってみるけど、飽きたらさすがに緩和していくかもしれない。サーバそのものをクラックされたらもちろんダメだがそれはサーバ会社側の範疇。
----------------------------------------------------------------------
【重要】Movable Type の利用に関する注意喚起
----------------------------------------------------------------------2014年5月20日
お客様各位
さくらインターネット株式会社平素よりさくらインターネットに格別のご愛顧を賜り、誠にありがとうござい
ます。この度、CMS「Movable Type」の古いバージョンにおいて、Webサイトの改ざん
が行われるケースが多数報告されているとして、コンピュータセキュリティ
関連の情報発信などを行うJPCERTコーディネーションセンターから注意喚起が
発表されています。▼JPCERTコーディネーションセンター
旧バージョンの Movable Type の利用に関する注意喚起
https://www.jpcert.or.jp/at/2014/at140024.html「Movable Type」ご利用のお客様におかれましては、下記ご参照の上、最新
バージョンへのアップデートをお願いいたします。さくらインターネットでは、今後もよりよいサービスの提供が行えますよう、
精一杯努めて参ります。引き続き変わらぬご愛顧を賜りますようお願い申し上
げます。
単なるメモ。
ほとんどよく分かってないが、だいたいは揃っている感じなんだろうか。前はLWP::UserAgent使えなかったのに使えるようになっている。ただ公式の一覧には載ってないような。非公式サポート?
LWP系 | |
LWP::Authen::Wsse | 利用可能(Ver. 0.05) |
LWP::Debug | 利用できません |
LWP::MediaTypes | 利用可能(Ver. 6.02) |
LWP::MemberMixin | 利用できません |
LWP::Protocol | 利用可能(Ver. 6.00) |
LWP::Protocol::https | 利用可能(Ver. 6.04) |
LWP::RobotUA | 利用可能(Ver. 6.03) |
LWP::Simple | 利用可能(Ver. 6.00) |
LWP::UserAgent | 利用可能(Ver. 6.05) |
HTTP系 | |
HTTP::Cookies | 利用可能(Ver. 6.01) |
HTTP::Daemon | 利用可能(Ver. 6.01) |
HTTP::Date | 利用可能(Ver. 6.02) |
HTTP::Headers | 利用可能(Ver. 6.05) |
HTTP::Message | 利用可能(Ver. 6.06) |
HTTP::Negotiate | 利用可能(Ver. 6.01) |
HTTP::Response | 利用可能(Ver. 6.04) |
HTTP::Status | 利用可能(Ver. 6.03) |
HTTP::Headers::Util | 利用可能(Ver. 6.03) |
HTTP::Request | 利用可能(Ver. 6.04) |
HTTP::Request::Common | 利用可能(Ver. 6.00) |
URI系 | |
URI::data | 利用できません |
URI::Escape | 利用可能(Ver. 3.31) |
URI::file | 利用可能(Ver. 4.21) |
URI::Heuristic | 利用可能(Ver. 4.20) |
URI::ldap | 利用可能(Ver. 1.12) |
URI::URL | 利用可能(Ver. 5.04) |
URI::WithBase | 利用可能(Ver. 2.20) |
サーバ会社からおそらく負荷の問題でCGI落とされた。アクセス過多だったという話ではなく、むしろ私のスクリプトに脆弱性があったというべき事案。その後変な復元のされ方をして、いちおうメインの(脆弱性のあった)CGIは再動作したのにあんまり関係ないCGIをまだ止められてる。きわめて不思議な対応。
なんかメールしなきゃいけないんだろうか。
上図は例によってこのブログの分も含んでるけど、このブログは無視して良い規模なので、2月と比較しても、いくらか底上げしてるのがわかると思う。が、大したことないといえば大したことないのである、このくらいでは。ある程度人が増えてやりがいがある部分も全くないわけではないが、1割~2割くらいもうぜんぶ辞めたい気もしてきている。
桁がもう一つ上ならということもあるが、やはりそれはそれで責任が増すわけで、どっちに進むにしても、あるいは現状のままでもあんま気が晴れない。どうなるんだろ。
追記(2014/04/19):
人が増えてきて排他処理系のエラーがよく出るようになったかもしれない。同時読み込みとかそういうので出るエラー。エラーが出るとリロードしまくる人がいて、さらに悪循環。軽くできそうなとこはあるんだけど、書き直すの大変そう。
追記2(2014/04/20):
なんだかんだで書きなおしてしまった。思ったほどは大変じゃなかったけど、ほんとにちゃんとなってるのか様子見。とりあえずやや軽くなった感あり。しかし問題は平常時じゃないんだなぁ...。
わーい、バグだらけだった。ひとりでテストしてる時と挙動が全然違った。お昼ごろに気付いて元のバージョンに戻す。軽量化とりあえず失敗。
午後8時過ぎ。紆余曲折あったが、再投入で、いちおうまともに動作してるかもしれない。バグは大小3箇所だったと思われる(少なくとも!)。しっかし、まだまだわからない。楽観は禁物。依然「ほったらかし」を目指しているのだが、むしろそれのほうがよっぽど高度な目標かもしれないと思い始めてきました。
追記3(2014/04/23):
全自動化はとても無理だけど、現段階で維持のための労力を自分なりに最小限にはできたかも。バグ潰しもそこそこしたし。しばらく経ってみないと分からないけども、これでまあまあ「ほったらかし」にできるかな。ホントにプログラミングは際限ないけど、ようやく解放される。アクセス数はその後ほとんど横ばいで特に変化なし。もうちょっと他のことをしたい。
WEB作成関連です。
下はまったく同じスタイル指定のtableタグ(<table style="width:20%;border:1px solid purple;word-break: break-all;word-wrap: break-word;">~</table>)の中に別種の文字を入れているだけなのですが、IEだと全角記号の連続を含むテーブル②は自動改行されません。同じブロック要素でもdivタグならIEであっても全角記号の連続に対しword-wrapの指定が効くようですが※1、なぜかIEとtableタグおよび全角記号の組み合わせでは効かないようです。
tdタグ内に絶対幅指定したdivタグを入れ子にして何とかするということもできるのかもしれないけど、私が本来やりたいのは特に幅の指定をしない柔軟なtable内で、ブラウザの横スクロールバーが出ないよう、(全角記号の連続を含む)長い行だけを折り曲げることなわけです。これは、HTMLとCSSの範囲内では、見るブラウザを変える以外、救済の方法が存在しないような気がします。こういうの、たいてい何らかの代替策があるもんだけどなぁ...。
ネット上にこの組み合わせでの情報があんまり見当たらず、他にも躓いている人がいるかもしれないと思ったので、とりあえずメモとして書いておきます。
テーブル①
あいうえおかきくけこさしすせそたちつてとなにぬねのはひふへほまみむめもやゆよらりるれろわをんABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!"#$%&'()/-+`{+*}<>?_ |
テーブル②
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
※1:【HTML・CSS】 文章の一部、文字が領域を突き抜けてしまうのを検証してみた
CGIサイトの方のレイアウトをスマホに合わせるために試行錯誤。
User-Agent Switcher for Chromeというプラグインで、Chrome上に複数のスマホをエミュレートできるのが便利だった。これで確認しながらデザイン変更していった。
翌日(昨日:棒グラフ右端)急激にアクセスが増えてPVが9千近くまで行ったが、サイト全体を更新したからロボット巡回が激しくなっているだけかもしれない。詳細見ていない(見る気がしない)。今日以降のアクセスがどうなるかでおのずと分かってくるだろう。転送量は余裕ある。
WEBデザインは気にしだすとホント難しい。「正しいデザイン」とは何かと考えるより、「より良いデザイン」は何かと考えるべきなんだろうけど。それでも簡単じゃない。たとえば、眼が疲れないデザインは?
なんやかやしている内に、このブログの上部広告を元に戻してしまった。日付表示の方をサイドバーに移動。
追記(2014/03/04):
その後アクセス数乱高下。スマホ対応は必ずしもうまく行っていなかったようだ。さらに修正した。一旦様子見したい。
追記2(2014/03/05):
アクセス履歴採って詳細見てみた。google bot のiphone版が来ていた。そんなの初めて見た。反応を軽くするためにCGI側のアクセス記録機能を切っていたのだが、今回forkによりバックグラウンドで処理できてるみたいで、そんなに重くなってない気がした。アンドロイドを強制的に大フォントページに飛ばすと、アンドロイドの大型タブレットでも大フォントで読むことになってしまうわけだが、もとに戻すわけにも行かない。あちらを押せばこちらが...。今回の対応は簡易で、本格的なスマホ対応ページはちょっと無理目か。
追記3(2014/04/08):
新機能をつけたためかじりじりPVが上がってきていて、検索サイトのロボット巡回を除いても1万近く行くようになってきた。眠い時に手直ししていてひどい間違い。こんなことをしてるとサイトの信用を失うなぁ。PVが10万くらい行ってしまえば事態がはっきりするんだろうけど、今はまだゆらゆらあわいのような段階が続く。
PV増加に加えて、新機能が常に特定のファイルを呼び出すこともあってか、転送量が跳ね上がっていて、1日1ギガバイト行くこともあるようになった(つい先月までずっと1日400メガバイトくらいだったのに)。特定ファイルは予めgzip圧縮してありその上での数字。サーバの方の転送量上限は1日40ギガだからまだまだだが、一度ためしにhtml送出に伴うgzip圧縮を切ってみたら1日3ギガも行った。その他の状況を勘案しても、gzipはtxt系のデータならだいたい1/3くらいには圧縮してくれているという感じであろうか。やはりgzip圧縮は重要。
アクセスログ見ると検索エンジンからの巡回を制御するrobots.txtが効いてない感じが強くする。マニュアル通りにしてるつもりだが...??
追記4(2014/04/10):
改良の方向として、むしろシステムをより「ほったらかし」にできるようにすることを目指した方がいいように思えてきた。すでにある程度自動化されてるけども。自動処理が盤石なら、余程じゃなければ人の増減も気にならないし、当然労力的にも負担ではない。そこまで急激に人が増えるということもないだろう。あってもたまにチェックしていれば気づくだろう。作っていてなんだけど、自分自身でよく見るサイトではないということも大きいというか、あるいはネット広告が一定の収益を上げているならまた別なのだろうが(サーバ代くらいは出てるけども...)、距離感がしっくり行ってないのが一番の問題かもしれない。元々perlのSocket接続で遊んでいて妙に発展してきてしまったけど、なんか持て余してる感がないではない。
このブログ上部に設置していたAMAZONの広告バナーをやめ、自作のCGI(作成時間45分)をインラインフレームで呼び出すことで、今日の日付を表示するようにした。
曜日、月、日、年の順番で表示されます(日本時間です)。
うまくいくかな?
追記(2013/12/21)
なんかシンプルすぎて寂しいので、サイドバーにAMAZONの検索ボックス追加した。ほとんど広告効果ないけども。気分だけ。
このサーバの別ドメインのCGIを久方ぶりにバージョンアップしようとしたら、なかなか思ったように動作せず、試行錯誤を繰り返していたのだけど、ようやくうまく行った感じ。
Javascriptによるカウントダウン処理を実装した複数のページで、ページ自体をリロードしてもそのままカウントダウンを引き継げるようにしたかったのだが、Javascript側からCookieを利用するやり方しか思いつかなかったので(他にやり方あるのかな?)なんとかそれでやってみた。しかしきわめて動作が不安定。普通Cookieには幾種類か簡単な情報が記録できるわけだが、その内のPath指定で、ブラウザが、例えば「/abc」と「/abcd」の区別がつかないらしいことが分かった。これはCookieの「仕様上」そうらしい。なんじゃそらだが、要はこれにハマっていたようだ。
上の階層にPathを指定し内容の記述で対象を仕分けることでたぶん解決。分かればあとは簡単?しばらく様子見ないと自信が持てないけれど、今日はここまで。続きは未定。
あとIEだけCookie処理が他のブラウザと違うような気もしたが、深追いしなかった。
【追記】2013/12/02
結局、様子見たあと本格投入見送った。元に戻した。やっぱり本来Javascriptで全部(特にソート処理自体)書くのが正しいのか。Perl+Cookieでやるとカウントの遷移はできてもあれこれ派生的な問題が起こる。プログラミングはやりはじめると際限なくなって怖い。向こう岸まで泳ぎ切ったような人はなんでも出来て楽しいんだろうなぁ。
【追記2】2013/12/03
ページリロード時にデータ取得の空振りがないように、せめてもの改良した。まだ気に食わないところがあるが、ブラウザを閉じないとタブを閉じただけでは一時cookieが消えないのは一般的な仕様なので、タブ消しから再びページに復帰してカウンターがリセットされないのは今のやり方では仕方ない。
際限ないのでこれで一旦収めたい。バグ出ないでくれぇ。
覚え書きとして書いておきたくなったので、このブログ自体について少し書いておく。
この極弱小ブログへのアクセス(1日100件弱、RSSは別で30件前後)は、もうずっと、1/3強がyoutube字幕をダウンロードしに来る人、1/3弱が英文拙訳のどれかの読者で、その他1/3がひっくるめて残り全部という感じ。その他で最近多いのは、IE10のインストールをローカルで行いたい人がリンクを求めて来るもの。
今年に入ってからの英文拙訳でアクセスが比較的多いのがWikipedia「離人症」英語版の和訳で、それ関連だけで10件近くある日もあるのだが、離人症関連のサイトは多々あるので悩んでいる人の全体が多いのかなと思ったりもする。そのうち『離人症 克服』とかのフレーズで検索してくる人を見ると、多少なりとも何か感懐を持たないでもない。去年離人症関連の『Feeling Unreal』を読んだ影響でWikipediaの記事を訳したのだが、書籍には結局古典的なカタルシス法が紹介されているだけだったりして、正直そう決定的な治療法があるわけではないようだった。ただ、治さなくてもしばらくすれば勝手に治ったり、またずっと治らなくてもそれなりには生きてゆけるみたいではある。ただ言を換えれば、なまごろし的ともいえるかもしれないが。
あと英文拙訳で以前からずっとコンスタントにアクセスがあるのは『スプリッティング』と『投影性同一視』で、これはBPD方面の人なのだろう。『投影性同一視』はそうでもなかったかもしれないが、『スプリッティング』の方は、私が訳したときはネット上の日本語の解説ページがほぼ皆無といった状況だったと思う。しかし今はちらほら国内専門家の人が説明していたりしているようで隔世の感。もはやそちらの方を読んだほうがいいかもしれません。
先月末訳した『自己愛憤怒』で検索してくる人は今のところ皆無であり、これからもほとんど存在しないに違いないわけだが、一年を通して数人くらいは居てほしいものだ。
エントリーに組み込んでいるyoutube字幕ダウンロード等のCGIは、整理して別ドメインの方に移動させたい気もしている。
ブログのプラットフォームがそろそろ旧式の部類に入ってきている問題。MT4不調?
調べるとあんまり選択肢がなく、MT4で行けるところまで行くしかないか?多少コツは要るがWordPressはインストールできるみたい。さくらのブログに戻る手も。試したのは少し前だが、Chromeならば最新版でもMT4が問題なく使えた気はする。
前回のナルシシストのエントリーで、「(今の自分は)世を忍ぶ仮の姿だ」が口癖だった特定人物等が頭をよぎって、書きながらやや血が上ってしまった。みっともないので、われながら気をつけよう。
今年も折り返し。あったかくなってきたからかなんなのか知らないが、今年前半ずっと微妙だった体調が(今度こそ)よくなった気がする。このまま持続するかどうかだけど。
最近のコメント
purplebaby≫MOさん Youtubeは、自動生成系の字幕の場合、複数の… (240325)
MO≫いつもありがたく使用させていただいています。 不具合なのか1… (240324)
purplebaby≫2023/10/16 15:49 コメント投稿者: 山田 隆… (231016)
MO≫はじめまして、便利で毎回使用させていただいていますが、1点リ… (230515)
wakamin≫もう何年も利用させていただいております。 srtだけでなく、… (230127)
sennapeng≫YouTubeの英語字幕を、ゆっくり翻訳できないかとググって… (220519)
tab≫初めて利用させて頂きました。 無料で公開してくださり本当にあ… (220507)
purplebaby≫イナチャン55さん、yosiさん、動作報告ありがとうございま… (211205)
イナチャン55≫早速の対応ありがとうございます。 数年前から秘密の宝ツールと… (211205)
yosi≫早速のご対応ありがとうございます。無事に srtファイルをダ… (211205)