2 - 連続表示

先日、本ページに「管理者のつぶやき」というページを追加しました(画面左のメニューにあります)。内容は私がTwitter(ツイッター)に書き込んだものを、そのまま転載しているだけですが、Twitter APIのサービスを利用すると誰でも簡単にこのようなページが作れます。

PHPプログラムを書いておくので、もし「使ってみたい」という方がいましたら、プログラム最上部の"kunisan_jp"をご自分のユーザー名に変更して、ご自由にお使いください。

■■ Twitterのつぶやきをホームページ上に表示 ■■■
<?php
//Twitter APIに接続
$contents = file_get_contents('http://search.twitter.com/search.atom?q=from:kunisan_jp&rpp=30');

//XMLをオブジェクトに変換
$xml = simplexml_load_string($contents);

for ($i = 0; $i < 30; $i++ ) {

//書き込み人の取得
$author_name = $xml->entry[$i]->author->name;

//書き込み人のユーザー名取得
$author_id = mb_split('\(',$author_name);
$id = mb_ereg_replace(' ','',$author_id[0]);

//本文の取得
$bunsho = $xml->entry[$i]->title;
$bunsho = mb_convert_encoding($bunsho,"SJIS","UTF-8");

//書き込み日の取得
$pdate = $xml->entry[$i]->published;
$pdate = date('Y/m/d H:i:s',strtotime($pdate));

//書き込みの表示
print '<b>'.$id.'</b>: '.$bunsho.' ('.$pdate.')<br>';

}

?>
■■■■■■■■■■■■■■■■■■■■■■■■■■

Twitter APIの利用は誰でもできますが、「1時間あたり150リクエストまで」という制限があります。これを超える利用が見込まれる場合には、下記ページ(英語)から申請を行い承認されれば、「1時間あたり20000リクエストまで」と制限が大幅に緩和されます。

http://twitter.com/help/request_whitelisting

→「Twitter API + PHP + MySQLの連携」の記事



PHP関連記事(リンク一覧): さくらレンタルサーバーのアクセス履歴をPHPで表示 / PHPで画像のアップロード(さくらレンタルサーバーのPHPでImageMagick) / PHP REVERSI(オセロもどき)の続き / PHP REVERSI(リバーシ) - オセロもどきゲームの公開 / PHP版-簡易アクセスブロック(IPアドレス、ホスト名、OS、ブラウザ名で制御) / ...(記事連続表示)

Twitterの本 をAmazon.co.jpでチェック

2013年6月12日以降、Twitter API 1.0が使用できなくなったことにより、上記のプログラムも動作しなくなりました。

設置から3週間ほど経過したアクセス解析プログラムですが、ようやくここに来て、MySQLの動作が落ち着くようになりました。

当初はテーブル1つで全サイトのアクセスデータを取っていましたが、さすがにこれではサイズが大きすぎて、Webサーバーとして稼働しているネットブックが高負荷になってしまいました。

そのため、サイト毎にテーブルを分割する方式を取りました。しかしこれでも一日数万アクセスのあるブログパーツの影響で、改良から10日ほどでCPU使用率が100%に達する現象が頻繁に出るようになりました(平均で30%強)。その後、ブログパーツをアクセス解析の対象から外してみたところ、CPU使用率が平均10%に見たない数字になりました。

ここまでで大分落ち着いてはきたのですが、やはりデータが貯まってくると、「問い合わせ」の際の負荷が大きくなる現象は解消できていません。特にページアクセスの度に行われるデータ追加処理にも、事前に「問い合わせ」の処理が不可欠なので、時間が経ってデータが貯まれば貯まるほどCPUが高負荷になるという状況がそのまま続いていました。

そのため、サイト毎に分割したテーブルを、さらに「アクティブデータ」と、「アーカイブデータ」に分割しました。「アクティブデータ」はページアクセス時などデータの読み書きに頻繁に使用されるデータ、「アーカイブデータ」は分析・参照用などサイト管理者(つまり私)のみが使うデータです。

「アクティブデータ」は24時間に1回、自動的に1週間以上前に追加されたデータを「アーカイブデータ」に移動する処理を行っています。これにより、データの読み書きに使うテーブルの大きさを制限できるため、ネットブックの負荷がある一定のレベルを超えることがなくなりました。

なお、データを分析する際には、MySQLの「UNION ALL」コマンドで「アクティブデータ」「アーカイブデータ」を縦に連結してまとめるようにしています。

表には出てこないアクセス解析プログラムを、ここまで詳細に語るのも何なのですが、近い将来プログラムをセットで公開する予定です。使う人がいるかどうかはわかりませんが、PHP+MySQLが使える環境であれば、どこでも動くような形に改良しておこうと思います。



Web管理関連記事(リンク一覧): SPF、DKIM、DMARCの設定とネームサーバー(DNS)設定のトラブル / さくらレンタルサーバーのアクセス履歴をPHPで表示 / PHPで画像のアップロード(さくらレンタルサーバーのPHPでImageMagick) / KUNISAN.JPサイトのメンテナンス(2018) / Webサーバー引っ越し(さくらインターネット スタンダード)とHTTPS(常時SSL)化 / ...(記事連続表示)

MySQL全機能バイブル ~現場で役立つAtoZ~ をAmazon.co.jpでチェック

e-Taxでの確定申告(青色申告)が完了したのが、先月17日。そして昨日、税務署より「国税還付金振込通知書」が届きました。手続日が3月3日となっており、e-Tax完了からちょうど2週間で還付金が振り込まれた形になっています。

以前は還付金を得るのに、申告から1ヶ月以上かかっていましたが、e-Taxはこの点では大変便利になったと思います。ただ、青色申告で還付金を得られるのは恐らく今回だけで、今後は納税が続くものと思われます。というより、納税が続くくらい収支が長年安定していると嬉しいものなのですが、この先どうなるかは誰にもわかりませんね…。



個人事業開業関連記事(リンク一覧): 2度目の30kmラン / 2016年(平成28年)確定申告準備完了 - マイナンバーカード/個人事業終了/ふるさと納税 / やよいの青色申告14 / e-Taxソフトで平成23年分(2011年分)の確定申告を完了 / やよいの青色申告＋e-Taxソフトでの確定申告まとめ / ...(記事連続表示)

やよいの青色申告 10をAmazon.co.jpでチェック

ネットブック(FRONTIER FRNU305)を自宅サーバー化して、PHP+MySQLのアクセス解析プログラムを乗せたのが約10日前。当初はデータ量が少ないことから動きが軽く、ネットブックのファンも静かだったのですが、最近になって管理画面が時折フリーズしたり、ファンがうなるようにもなってきました。

タスクマネージャーでリソースの観察をしてみると、メモリの方はそれなりに余裕があるものの、CPUの使用率が100%に達することがあり、これがフリーズやファンがうなる原因になっていたようです。

アクセス解析プログラム中、頻繁に行われる処理の中で、「2時間以内にIPアドレスとユーザーエージェントの両方が同じデータが記録されているか確認を取る」というものがあり、これが1日4万回もあることから、大きな負荷がかかっているものと思われます。そのうち、「IPデカ(ブログパーツ)」だけで1日2万回に達しており、混み合う時には1秒に数回の処理があります。IPデカのアクセスデータ数は既に27万件に達していて、このテーブルから1秒に何回もクエリーでデータを抽出するのは、大変な負荷になるということは容易に想像できます。

Windows付属のパフォーマンスモニターで、さらに詳しく動向を見てみると、1～2時間に1度、3～5分の長さでCPU使用率が100%に達して、この間に動きが非常に重くなってしまうことがわかりました。

「どうにかならないかな…」と思い、MySQLの本を流し読みしていたところ、MySQLのデフォルトの状態では「クエリーキャッシュ」の設定がされていないことがわかりました。早速phpMyAdminから、下記のコマンドを入力してクエリーキャッシュをセットしました。

SET GLOBAL query_cache_size = 1048576;

キャッシュサイズは約1MBです。当初はこれで「軽くなったかも」と思いましたが、やはり1～2時間に1度、CPU使用率が100%になってしまう現象は変わりませんでした。キャッシュ容量をチェックしても「全て食い尽くす」ようなことは無かったので、クエリーキャッシュの設定だけではCPU使用率が高くなる現象は防げないようです。

今のところ、動きが重くなるタイミングがあるとは言え、全く動きが取れなくなるような状況ではありませんが、今後事態がさらに悪くなるようであれば、プログパーツをアクセス解析の対象から外そうと思います。ブログパーツ以外のテーブルのサイズはいずれもブログパーツのものより大幅に小さいものばかりで、これだけでも負荷が半分以下に減少することが見込まれます。

それにしても、ブログパーツはサーバーのリソースを食うし(本サーバーの方も最近たまにエラーが出ます)お金にはならないし、運営していてあまりいいことがありません…。「IPデカ」のように人気が出るのもいいことなのですが、今後アクセスがありすぎて他のサービスにまで影響してしまうようなことがあると、ブログパーツの公開を中止せざるをえないかも知れません。苦渋の選択になりますね…。



Web管理関連記事(リンク一覧): SPF、DKIM、DMARCの設定とネームサーバー(DNS)設定のトラブル / さくらレンタルサーバーのアクセス履歴をPHPで表示 / PHPで画像のアップロード(さくらレンタルサーバーのPHPでImageMagick) / KUNISAN.JPサイトのメンテナンス(2018) / Webサーバー引っ越し(さくらインターネット スタンダード)とHTTPS(常時SSL)化 / ...(記事連続表示)

MySQL全機能バイブル ~現場で役立つAtoZ~ をAmazon.co.jpでチェック

その後、負荷の原因と思われる処理の「2時間以内に…」というのを「同日内に…」という条件に変更してみました。クエリーキャッシュはWHERE条件が一文字でも変わると有効にならないので、時間と共にパラメーターが変化する「2時間以内(今から2時間前のタイムスタンプを指定し、それ以降)に…」よりは、その日のうちはパラメーターが変化しない「同日内に…」の方が、システムの負荷が小さくなると考えたからです。

結果はほとんど変わらず、やはりCPU使用率が100%に達する現象は発生してしまいました。残念…。

最後の手段として、ブログパーツをアクセス解析から外してみました。当初はCPU使用率の平均値が30%強(普段は20%台後半で、たまに100%に達してしまうため)だったのですが、ブログパーツを対象から外したところ、「7%」と大きく減少しました。12時間稼働させて100%に達することは一度もありませんでした。やはりブログパーツのリソース食いはかなりのものです…。

QRコードが簡単＆無料で作成できるツールサイト「QRコード作成君」を公開しました。

QRコード作成君
http://kunisan.jp/qrcode/

入力欄にホームページURLやEメールアドレスを入れて「作成」ボタンを押すだけの簡単操作です。

技術的には「Google Chart API」というサービスを使っているだけで、特別なことは何もしていません。PHPで作ってみましたが、PerlでもJavaScriptでも簡単に作れるサービスです。



Web管理関連記事(リンク一覧): SPF、DKIM、DMARCの設定とネームサーバー(DNS)設定のトラブル / さくらレンタルサーバーのアクセス履歴をPHPで表示 / PHPで画像のアップロード(さくらレンタルサーバーのPHPでImageMagick) / KUNISAN.JPサイトのメンテナンス(2018) / Webサーバー引っ越し(さくらインターネット スタンダード)とHTTPS(常時SSL)化 / ...(記事連続表示)

エーワン マルチプリンタラベルA4判QRコード用70面 31555をAmazon.co.jpでチェック

マクドナルドのBig Americaシリーズ第3段は、ハワイアンバーガーです。ハワイの名物料理「ロコモコ」風に、タマゴとハンバーグとグレイビーソースの組み合わせです。ソースの香りとピリ辛感が特徴的と言えます。

とは言うものの、今までのBig Americaシリーズの中では、インパクトが少々弱く感じます。テキサスバーガーのバーベキューソースやニューヨークバーガーのマスタードソースは、マクドナルドの万人受けの味から少々はみ出た感がありましたが、ハワイアンバーガーのグレイビーソースは「想定内」と言えると思います。バンズにトッピングしてある粉チーズも、それほど強い主張はしていません。

次回(最終回)はカリフォルニアバーガーですが、「赤ワインを使用した特製ソース」というのが気になります。



マクドナルド関連記事(リンク一覧): ドイツのマクドナルド(7年ぶり) / ギガビッグマック / トリプルチーズバーガー / 1年ぶりのマクドナルドでカマンベールてりたま / ハワイアン バーベキューポーク / ...(記事連続表示)

おしごとチャレンジコンパクト マクドナルドレストランをAmazon.co.jpでチェック

Perlを使い始めたのが１９９９年３月。その年の間にPerlでアクセスカウンター、掲示板、チャットを制作し、それから数年後にはImageMagickを応用した「画像編集君」や、パズルゲーム「タイルdeパズル」を作ったりもしました。

それから時が流れて２００７年１０月からPHPを使い始めるようになりました。当初の目的は某Web広告がPerlでの記述に対応しておらず、PHPを使わざるを得ないということからでした。仕方なくPHPを学習した、というのが正直なところです。

しかし、その後PHPのプログラミングの容易さに魅力を感じるようになりました。Perlでは数行記述する必要のあるファイル関連の処理やメール送信処理など、PHPではたったの一行でできてしまいます。

結局ブログパーツのような小さいプログラムから、ショッピング系サイトやMySQLと連携したものまで、新しいプログラムはPerlは一切使わず、全てPHPで作成するようになってしまいました。先日完成したアクセス解析プログラムもPHPでできています。

現状では細かいメンテでPerlを使うことがありますが、その際にPHPとの記述の違いに若干戸惑うこともあります。また、Perlで中規模以上の改良を行う気力が起きてこなくなってしまいました。「Perlで改良する位なら、PHPでゼロから作り直した方が楽」ということも多々あります(先日のアクセス解析プログラムもそうです)。

現在、「直さなければいけないな」と思っているのが、本ブログ掲示板です。書き込みデータはサーバー上にテキストファイルとして保存してあるのですが、ある条件での抽出や並び替えの機能を付けたりするなど、Perlで機能を追加していくのは容易ではありません。

近いうちに書き込みデータをMySQLに移して、このホームページ全体をPHP化しようと思っています。現状ではブログのカテゴリー追加や左メニューの編集など、全てコードを手打ち入力していますが、これをある程度自動化したいと思っています。今現在、このホームページはメインとなるPerlのプログラム数本に、後付けした別の小さなPerlのプログラムとPHPプログラム数本で構成されています。これもPHPのプログラムだけで構成するシンプルな形にしようと思っています。

この先Webの世界がどうなるかわかりませんし、私自身もどのようになっていくかわかりませんが、今までに築き上げたコンテンツだけは大事に扱っていきたいと思います。あと、本ページのPHP化は、今後の自分のためにもなるのかな…、と。まあ、あまりお金に繋がるような話ではないと思いますが。



Web管理関連記事(リンク一覧): SPF、DKIM、DMARCの設定とネームサーバー(DNS)設定のトラブル / さくらレンタルサーバーのアクセス履歴をPHPで表示 / PHPで画像のアップロード(さくらレンタルサーバーのPHPでImageMagick) / KUNISAN.JPサイトのメンテナンス(2018) / Webサーバー引っ越し(さくらインターネット スタンダード)とHTTPS(常時SSL)化 / ...(記事連続表示)

PHP 逆引きレシピ (PROGRAMMER’S RECiPE) をAmazon.co.jpでチェック

先ほどe-Taxソフトを使って、平成21年度分(2009年度分)の確定申告を済ませました。今回は初の青色申告でしたが、昨年「雑所得」分でe-Taxソフトでの申告を経験していたので、「右も左も分からない」ということはありませんでした。

ただ、昨年購入した日立製の公的個人認証対応カードリーダーライターが、Windows7の64ビット版に対応しておらず、新たに64ビット対応のソニーのカードリーダーライター(RC-S330)を購入する羽目になってしまいました。おかげで「電子証明書等特別控除」の5,000円よりも、カードリーダー2台＋区役所までの往復電車賃＋住民基本台帳カード発行費用を全て足した額の方が上回ってしまいました。金銭面だけを考えるなら、昨年のうちから電子申告など一切考えず、自転車で近所の税務署まで行って申告した方が安上がりでした…。

昨年、確定申告書の電子申告控除欄への記入を忘れてしまったため、今年中に電子申告を再びやらないと5,000円の控除が得られない状況でもあり、「新たにカードリーダーライターを買わずに、今年は電子申告無しで済ませる」という選択肢が無かったことも痛いです。控除なしの3,000円強の損よりは、「出費-控除」の1,000円程度の損で済ませた方が得策という結論でした。

どちらにしても出してしまったお金は戻ってこないので、e-Taxソフトを使って申告することになります。せっかくなので署名の手続きを書いておきますが、これの前提としてe-Tax上で書類の作成が全て終わっていることが条件です。
※e-Taxソフト上での書類の作成についてはこちらを、書類作成の前提となる記帳ソフトについてはこちらを、住民基本台帳カードの取得についてはこちらを参考にどうぞ。

1)カードリーダーライターのドライバインストール
2)カードリーダーライターをパソコンに繋いで認識
3)JPKI(公的個人認証サービス)ソフトをインストール
4)e-Taxソフトを起動、画面左から「電子署名」を押し、申告する書類を選択して、画面右下の「署名」ボタンを押す
5)ポップアップでカード選択(ICカード)、カード種選択(公的認証カード)、カードのパスワードを入力
6)2～3分ほどで「承認内容」が画面に出て署名完了

あとは画面左の「送信」から書類を送信して申告完了です。

昨年前半の会社在職時に多めに源泉徴収を取られていたこと、昨年10月の個人事業開業以降の所得が青色申告控除額を下回ったこと、それと住宅ローン控除などもあって、今回は「納税」ではなく、いくらか「還付」されることになりました。

昨年納税した際には、納付情報登録をして、銀行から指定の所に振り込んで…、という手順を踏みましたが、それが無かった分、申告の処理自体は今年の方が若干楽でした(書類作成は昨年より大変でしたが)。

それにしても、e-Taxの手続きや処理は総じて面倒で、青色申告者の1割程度しか利用していないということも頷けます。もっと金銭的なメリットが大きければいいのですが、私のようにe-Taxを利用することで損を出してしまうことがあるようなシステムでは、納税者の大半に普及することはほとんど不可能でしょうね。



個人事業開業関連記事(リンク一覧): 2度目の30kmラン / 2016年(平成28年)確定申告準備完了 - マイナンバーカード/個人事業終了/ふるさと納税 / やよいの青色申告14 / e-Taxソフトで平成23年分(2011年分)の確定申告を完了 / やよいの青色申告＋e-Taxソフトでの確定申告まとめ / ...(記事連続表示)

SONY 非接触 ICカードリーダ/ライタ USB 対応 パソリ RC-S330をAmazon.co.jpでチェック

PHPでWhois検索ができるようになりました。ただし、Pearをインストールできる環境に限ります。逆にPearをインストールできる環境であれば本当に簡単です。

KUNISAN.JPサーバーは共有ホスティングサーバーのため、Pearのインストールはできませんが、代わりにネットブックのXAMPP1.7.3で試してみることにしました。コマンドプロンプトでカレントディレクトリを移動して、下記の通りコマンドを打ちます。

C:\xampp\php>pear.bat install Net_Whois

これでPHPにNet_Whoisモジュールがインストールされます。続いて、PHPで下記のようなプログラムを書けば完成です。

require_once 'Net/Whois.php';
$whois = new Net_Whois();
$data = $whois->query('IPアドレスまたはドメイン名');
print $data;

早速これを応用して試験的なサイトを作ってみました。

http://kunisan.jp/whois/

インラインフレームにNet_Whoisモジュールをインストールしたサーバーの応答が表示されます。



PHP関連記事(リンク一覧): さくらレンタルサーバーのアクセス履歴をPHPで表示 / PHPで画像のアップロード(さくらレンタルサーバーのPHPでImageMagick) / PHP REVERSI(オセロもどき)の続き / PHP REVERSI(リバーシ) - オセロもどきゲームの公開 / PHP版-簡易アクセスブロック(IPアドレス、ホスト名、OS、ブラウザ名で制御) / ...(記事連続表示)

PEAR―PHPライブラリ をAmazon.co.jpでチェック

先週の金曜日にアクセス解析用のMySQLデータ追加プログラムを公開しましたが、その後蓄積されたデータを分析・表示するプログラムを作り始めました。土曜日の朝から食事、風呂、トイレ、睡眠以外はずっとプログラムを組み続け、ようやく昨晩遅くにほぼ完成しました。トータルで50時間位はかかったと思います。

管理用のページなので残念ながらアドレスの公開はできませんが、ざっと内容を紹介するとこんな感じです。

■トップページ
・各ページの最近一週間のアクセス数(UV、PV)表示
・各ページの開設時からのアクセス数(UV、PV)表示
・ドメイン全体のアクセス数合計(UV、PV)表示
・データ詳細画面へのリンク
・掲示板、ブログの「コメントあり」アラーム
・掲示板、ブログのブロック解除、編集画面へのリンク

■詳細画面の機能
・アクセス履歴一覧表示(UV、PV、アクセス日時、アクセス元サイトなど)
・各項目(フィールド)の昇順、降順切替
・日付でのフィルタリング
・キーワードでのフィルタリング
・グラフ表示(日別、時間別、アクセス元IPランキング、アクセス元ドメインランキング、閲覧ページランキングなど)
・IPアドレスのWhois検索


今までのアクセス解析プログラムは、サーバーのCGI処理での負荷限界があったため、1サイトあたりのデータが最大2500件を超えると、日付に関わらず古いデータから自動的に削除するようにしていました。しかし、今回製作したものは200GB超のスペースにMySQL+PHPという組み合わせで、基本的に古いデータもそのまま保持し続けます。現在のアクセス数でデータが蓄積されていくとして、軽く数十年の単位は持つ計算になるので、恐らくサーバーとして使用しているネットブックの方が先に寿命が来てしまうのではないかと思います(万が一に備えて、1日1回自動でデータのバックアップを取っています)。

当初、データベースにはテーブルを1つだけ置いて、各サイトにID(サイト名)を振り分けてデータを蓄積していきました。サイト別になっているPVやUVのカウントには、一度データベースから該当サイトのPVとUVの最大値を読み込んで、PHP上で1つ数字を加えて、アクセス履歴と共にレコードに追加するという形を取っていました。しかし、「数十万件のデータをサイト名でフィルタリング＆グループ化して1つ取り出す」というのを、平均2秒に1回のペースでこなさなければならず、アクセスが少しでも集中すると、フリーズしたような状態になってしまい、正常にカウントされなくなる現象が出ることが分かりました。MySQLのバッファ設定をいじったりもしましたが、全く改善しません。ネットブックを調べてみると、CPU使用率が時折100%の状態になってしまうようです。Atom N280(1.66GHz)搭載程度のスペックでは、少々無理のある処理でした。

そのため、テーブルをサイト毎に分割して管理するよう変更し、さらにPVについてはフィールドの自動カウント機能(Auto Increment)を使うようにして、クエリー処理の負荷を減らすようにしてみました。するとCPU使用率が平均10%前後と大幅に下がり、比較的負荷の高い状態でも50%程度で収まるようになりました。

分析ツールはひとまず完成しましたが、後はこのデータを活用した「ニーズのあるサイト」を作れるようになれば、と思うところです。



Web管理関連記事(リンク一覧): SPF、DKIM、DMARCの設定とネームサーバー(DNS)設定のトラブル / さくらレンタルサーバーのアクセス履歴をPHPで表示 / PHPで画像のアップロード(さくらレンタルサーバーのPHPでImageMagick) / KUNISAN.JPサイトのメンテナンス(2018) / Webサーバー引っ越し(さくらインターネット スタンダード)とHTTPS(常時SSL)化 / ...(記事連続表示)

MySQL全機能バイブル ~現場で役立つAtoZ~ をAmazon.co.jpでチェック