Web管理関連記事 - 連続表示

2008年のKUNISAN.JPショップを皮切りに、アマゾン、バリューコマース、楽天等のアフィリエイトのページを作成してきました。その多くがAPIサービスを利用して、PHPのプログラムでページを大量に生成するものです。データはキャッシュの場合を除いてリアルタイムにデータベースから取得するため、一度作ってしまえば更新の必要がなく、数十万ページが動的に更新するような形になっていました。一時期はこれでかなりの額の収入があって、2009年の10月に開始した個人事業の中核の事業ともなっていました。

しかし、Amazon Product Advertising APIの度重なる仕様変更に加え、昨年末に実施されたYahoo!サーチのGoogle化によるアクセス数の大幅減があり、毎月の収入は半分程度まで減ってしまいました。これに加えてGoogleの「大量生成型ページ」のペナルティ化があったり、その後も私の手持ちのサイトにとって不利となる検索アルゴリズムの変更が追加されていったものと思われます。結果、KUNISAN.JP全体の1日あたりの閲覧者数はピークの8000人/日から2000人弱/日と1/4以下にまで落ち込んでしまい、アフィリエト収入に至っては、ピークの1/5程度まで下がっていしまいました。

「収入が下がったのはアクセス数が下がったため。アクセス数が下がったのはGoogleの検索結果順位が下がったため」ということは明白なので、先日Googleウェブマスターツールより、サイト再審査のお願いを出してみました。すると、帰ってきた答えがこれです。

「サイトが Google の品質ガイドラインに違反しています」

どのページがどのような違反なのか、具体的には書かれていませんでしたが、「アフィリエイトページの大量生成」は間違いなく品質ガイドラインに反しています。「やはり、これが原因でアクセス数が落ちていたのか…」とはっきりと理解できました。

しかし、「収入を伸ばすためにアクセス数を上げたい」→「アクセス数を上げるために違反ページを削除する必要がある」→「違反ページは収入頭の大量生成されたアフィリエイトページ」→「違反ページを削除するとアクセス数が増えても収入が増えない」ということもあり、「どうしようかな…」ということになってしまいました。ただ、「以前の収入レベルならまだしも、現状の収入レベルなら、ここからさらに半減してもあまり痛くない。アクセス数が増えれば、代わりにクリック報酬型の広告収入が増えるかも知れない。大量生成されたアフィリエイトページは、いずれにしても先が無いのだから、アクセス数を増やすことをベースに、自前コンテンツのホームページやブログを多くの人に見てもらうことを優先して、それ以上のことは後になってから考えよう」という結論に達しました。

そして、本日削除したページは以下のとおりです。

・KUNISAN.JPショップのサーチ機能以外全て
・学び舎サーチ
・駅近君
・KUNISAN.JPサービスモール

先日、別タイプの大量生成型ページである「町の噂DB」と「有名人DB」も削除してるので、全部合せて25万～30万ページ程を短期間に削除した形になります。

現在残っているページは、旅行記や体験記など固定コンテンツのもの、計算機能などのあるツール系のもの、そしてこのKUNISAN.JP(ブログ掲示板)という感じになっています。本サイトトップページの下の方を見ると一覧が出てきます。

今は本職がサラリーマンで、新規ホームページの作成まで手が回りません。ただ、このブログだけはコツコツとコンテンツを積み重ねていきたいと思います。ここでKUNISAN.JPの「コンテンツ重視宣言」を出したいと思います。



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

Googleの脳みそ―変革者たちの思考回路 をAmazon.co.jpでチェック

2010年1月から開始した、「KUNISAN.JP - 新・ブログ掲示板」のRSSフィードですが、本日を持って全文配信を終了しました。今後はタイトルのみの配信となり、今までご利用いただいた方にはご不便をおかけすることになり、大変申し訳無く思っています。

このような決定に至った理由としては、RSSで配信したコンテンツをそのままページに表示し、あたかも「自分のコンテンツである」というような不当なページを発見したためです。このページの管理者から私への連絡は一切無く、またそのページから私のページへのリンクも一切無く、しかも検索条件によっては、私のサイトよりも上にランクされることもありました。加えて、そのページのタイトルとアドレスを変えただけのページが複数存在していることも確認しています(恐らく同じ管理者が所有しているものと思われます)。

あまりにもひどいので、何ヶ月か前にGoogleに対して「スパムサイト」報告をしたのですが、全く対応してもらえませんでした。もしかしたら、RSSで取得できる情報をページ上にそのまま表示するのは、法的にもGoogleのガイドライン上も問題無いのかも知れません。そのため、今回のような「配信終了」という措置を取らざるをえないという結論に達しました。

RSSは「Web2.0」と騒がれていた頃に注目を浴びていたサービスの一つですが、最近はRSSリーダーのサービスを止める業者が出てくるなど、少し「過去の物」になりつつあるような気がします。RSSフィードを提供する側にとっても、ホームページのPVが減少することに直結しますし、それに伴って広告収入が減ってしまうという懸念があります。ただ、それよりも上記のような「スパム行為」が横行してしまうと、とてもRSS配信を続ける気にはならなくなってしまいます。

いずれにしても、今回の決定についてご理解いただき、今後も「KUNISAN.JP - 新・ブログ掲示板」を見守っていただけると、管理者としても幸いに思います。



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

米国クラウドビジネス最前線 をAmazon.co.jpでチェック

1年前に本ブログで「Twitterで共有」ボタンの説明を書きましたが、その後Twitterの仕様が変わり、1ヶ月程前から従来の方法ではリンク(URL)やコメントがTwitterのコメント欄に反映されなくなってしまいました。

従来は以下のようなリンクを設置していました。

<a href="http://twitter.com/home?status=XXXX">Twitterで共有</a>
※XXXXのところにURIエンコード(UTF-8)したリンク(URL)＋文章を入れる形。URIエンコードは、 http://kunisan.jp/uri_encode_decode/ を参照。

今ではこのような形のリンクをクリックしてもTwitterのトップページに行くだけで、コメント欄は空の状態になってしまいます。

そのため解決方法を探していたところ、以下のページ(Twitter公式)でちゃんと紹介されていました。

http://dev.twitter.com/pages/tweet_button

このページには公式のリンクボタンを設置する方法も掲載されていますが、私としてはブログやホームページの見た目を変えたくないので、リンク先のURLを変更する形で対応してみました。具体的にはこんな感じの記述になります。
※Twitter上でKUNISAN.JPのホームページを「このページは楽しい！」と紹介する形。

■ HTML
<a href="http://twitter.com/share?url=http://kunisan.jp/kuni/&text=%E3%81%93%E3%81%AE%E3%83%9A%E3%83%BC%E3%82%B8%E3%81%AF%E6%A5%BD%E3%81%97%E3%81%84%EF%BC%81" target="_blank">Twitterで共有</a>

さらにこれをPHP、Perl、JavaScriptで記述すると、こんな感じになります。

■ PHP(SJIS記述の場合)
$tword = 'このページは楽しい！';
$tword = urlencode(mb_convert_encoding($tword,"UTF-8","SJIS"));
$url = 'http://kunisan.jp/kuni/';
print '<a href="http://twitter.com/share?url='.$url.'&text='.$tword.'" target="_blank">Twitterで共有</a>';

■ Perl(SJIS記述の場合※Jcode.pmが必要)
$tword = 'このページは楽しい！';
&Jcode::convert($tword, "utf8", "sjis");
$tword =~ s/([^0-9A-Za-z_ ])/'%'.unpack('H2',$1)/ge;
$url = 'http://kunisan.jp/kuni/';
print '<a href="http://twitter.com/share?url='.$url.'&text='.$tword.'" target="_blank">Twitterで共有</a>';

■ JavaScript
tword = 'このページは楽しい！';
tword = encodeURIComponent(tword);
turl = 'http://kunisan.jp/kuni/';
document.write('<a href="http://twitter.com/share?url='+turl+'&text='+tword+'" target="_blank">Twitterで共有</a>');

変数のところの記述を変更すれば色々と応用できると思うので、興味がある方は試してみてください。

ちなみに今までと違って、リンクをクリックすると確認用のウインドウが出てきます。ここで「ツイート」ボタンを押すとツイートされる形になります。



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

関連カテゴリー: Web管理関連記事, PHP関連記事

できるポケット Twitterをスマートに使いこなす基本＆活用ワザ100 ［できる100ワザ ツイッター 改訂新版］ をAmazon.co.jpでチェック

KUNISAN.JPショップはAmazon Product Advertising API(APAAPI/旧:AWS)を用いた仮想ショッピングサイトで、全部で2万以上のPHPファイル、30万以上のページから構成されています。もちろんページを増やす作業はプログラムの手書きではなく、ある「キーワード」を打ち込むことで、半自動的に生成してくれるようになっています(このプログラムもPHPで自作しました)。画面構成は非常にシンプルですが、大きな商品画像を使っているのが最大の特徴です。

2008年初頭に作成したKUNISAN.JPショップですが、ページ追加を重ねていった結果、2009年の夏ごろには手持ちのサイトの中で稼ぎ頭にまで成長しました。その後も収益の高い状態が続いていましたが、2010年秋になりAPAAPIから「ユーザーレビューを取得できなくなる」というサービス変更がありました。さらにYahoo!サーチのGoogle化が追い打ちをかけ、一日あたり2000～3000UVあったアクセス数が、昨年12月には1000UV以下にまで落ち込んでしまいました。収益もアクセ数減に応じて、激しい落ち込みです。今までKUNISAN.JPショップはYahoo!サーチからのアクセスが大多数であったこともあり、Googleへの対応を考える必要が出てきました(対応が後手に回ってしまいましたが…)。

ところで、昨年夏にKUNISAN.JPショップの「別館」という形で作成した「有名な靴屋への近道」というサイトがあります。これはKUNISAN.JPショップのプログラムを基本としていますが、APAAPIにリクエストするデータをMySQLに格納する形にプログラムを変更しており、KUNISAN.JPショップのように各PHPファイルにデータを格納する形よりも管理やページ追加が楽になりました。このサイトについては、KUNISAN.JPショップと異なり、Yahoo!サーチのGoogle化後もアクセス数が減ることはありませんでした。

Googleについてはサイト全体があるテーマに絞られたものほど、検索ランクが高めに出る傾向があると聞いたことがあります。「有名な靴屋への近道」は靴とバッグを専門にしているので、テーマが絞られた形になっているという解釈になるかと思います。反対にアクセス数の激減したKUNISAN.JPショップは、「何でも屋」的な内容になっており、またページ構成も体系的になっていません。これをヒントにして、KUNISAN.JPショップの別館専門店として、新たに4サイトを立ち上げてみました。

・パソコンショップ
・アウトドアショップ
・赤ちゃん用品ショップ
・オーディオショップ

先に作ったパソコンショップ、アウトドアショップについては、今のところ好調なアクセス数を記録しています。赤ちゃん用品ショップ、オーディオショップについてはこれからどうなるか見極めた上で、今後の展開を考えていきたいと思います。

ただ、2009年夏～2010年夏に記録したような収益に戻るかどうかは、現状では不透明です。また、戻るとしてもかなりの時間がかかることが予想されます。サラリーマンをやりながらの週末プログラマーなので、昨年のように一気にページを増やすようなことができませんが、何とか再び軌道に載せられたら嬉しいです。

Webの世界は技術的な変化が早いですが、首の皮一枚でも何とか付いて行きたいところです。



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

PHP×WebサービスAPIコネクションズ をAmazon.co.jpでチェック

新しく作成したサイトを公開します。

学び舎サーチ
http://kunisan.jp/learning/

内容は沿線別(今のところ首都圏のみ)、都道府県別で、語学やITなどの学校、講座、レッスンなどが検索できるというものです。フリーワードでの検索も対応しています。基本部分はPHPで作成し、MySQLで各種データを連動させつつ、バリューコマース経由で「ケイコとマナブ」のデータを引っ張って表示させています。見た目は100ページ以上ありますが、トップページ以外はコアとなるプログラムは1本のみです。

このページは製作開始から本日の「ほぼ完成」まで、約一ヶ月かかりました。今年3月までの個人事業専業なら3日足らずで仕上がったと思いますが、週末の限られた時間だけでの製作となると、やはり期間が長くなってしまいます。プログラム自体はシンプルなので、これからも少しずつ拡張して行きたいと思います。



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

公開API活用ガイド (I・O BOOKS) をAmazon.co.jpでチェック

先月27日にGoogleよりAdSense広告の配信を停止する内容のメールが来ました。手持ちのショッピングサイトが、Googleのポリシーに引っかかったようです。翌日には実際に広告の配信が停止されて、広告のあった部分が空白になってしまいました。

昨年6月には違うサイトが「Googleサービスの抜け道を利用する(YouTube著作物配信の助長)」という理由で、広告配信停止になりました。それ以来、2度目の広告配信停止の措置です。この時にはその後ページ上に「Google広告配信停止になったため、本サービスの継続を中止する」等、Googleの名前を連呼するような形の説明文を掲載したことが、「Googleブランドの(不正)利用」ということになってしまい、広告配信停止が延長されたという経緯があります。

今回問題になったショッピングサイトですが、Amazon Product Advertising API(APAAPI、旧AWS)のデータをもとにしたコンテンツを掲載していました。これにAdSense広告を掲載し始めたのは2年以上前です。その後は特に問題なくサイトを運営していたのですが、APAAPIの仕様が変わることになり、ユーザーレビューをコンテンツに埋め込む形でなく、iframaeで表示するように変更しなければなりませんでした。広告配信停止の連絡はページ変更から2週間後なので、恐らくページ内に突然増えたiframeを自動的に検知するなどした上、APAAPI側の不具合でエラーが多発してたことなども影響して、広告配信停止の措置が取られたものと思います。

加えて「コンテンツがアフィリエイトのみ」というのも、ポリシー違反となってしまいます。アフィリエイト広告だけでなく、APAAPIからユーザーレビューなども引っ張ってきていたので、問題ないと思っていましたが、どうやらこのような形態のものもポリシー違反になってしまうようです。

そのため、このショッピングサイトに加えて、他のアフィリエイト系APIからデータを引っ張っているサイトについても、AdSense広告を全て外した上で、Googleに「広告配信復活」のお願いを出しました。

その後Googleからメールが来たのですが、今度は別のページについて「見出しの直下に広告が配置されていて、広告が見出しに関連した内容と誤解される」ということで、広告配信停止が解除されませんでした。そのページは見出しの部分の背景色は緑で、広告とその周りの背景は白だったので、見間違えるようなことは無いと思っていましたが、どちらにしてもポリシー違反ということだったので、このページからも広告を外しておきました(元々広告を掲載できるようなコンテンツではなかったので)。加えて他にも見出し直下に広告を掲載しているページがあったので(一応見出しと広告には、一行分以上の隙間がありましたが)、そのようなページについては全て見出しと広告の間に罫線を入れた上で、広告の上に「スポンサードリンク」の表記を入れておきました。

改めてGoogleに「広告配信復活」のメールを出したところ、今度は問題がなかったようで、無事に広告掲載復活となりました。

AdSenseのポリシーはよく読んでいたつもりではあったのですが、解釈の違いでポリシー違反となってしまいました。上記の例が他の方の参考になればと思います。



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

グーグル・アドセンスの歩き方―収益が飛躍的にアップする最適化の必須テクニック をAmazon.co.jpでチェック

今年の2月、ネットブック(FRONTIER FRNU305)にXAMPPを入れて、Webサーバーとして稼働させていました。主にKUNISAN.JPサイトのアクセス解析用として使っていて、24時間電源を入れっぱなしだったのですが、5月までは大きなトラブルも無く、順調に動き続けていました。

しかし、6月になってから、Apacheが突然停止してしまったり、Windowsが勝手に再起動したりするなどの現象が出るようになりました。特に昼間の室温の高い時にだけトラブルが発生するため、恐らく暑さが原因であったものと思われます。7月～8月のもっと暑い時期になると、さらにトラブルの確率が上がることが予想されました。かと言って、クーラーを24時間付けっぱなしにすると、電気代だけで月7,000円以上の出費になってしまいます。

そのため、自宅でのネットブックWebサーバーの運用は「これ以上続けられない」と判断し、代わりにWebARENA SuiteXの「高機能データベース(DB)」を利用してみることにしました。月額2,100円(税込)ですが、自宅Webサーバー＋クーラーの電気代のことを考えると、それほど高いとも思いませんでした。

「高機能DB」は申し込み直後から利用可能になりました。早速ネットブックのデータベースから一部データをエクスポートし、高機能DBにインポートします。日本語データの文字化けが発生しましたが、その他の部分は問題ありませんでした。アクセス解析用のプログラムについては、DB接続パラメーターの変更とエンコードの設定変更(SJIS→UTF-8)で普通に動いてくれました。さらに、動作速度もネットブックに比べて3～5倍程度速いようです(正確には測定していませんが)。

そして本日、データの完全移行作業と文字化け修正、それと各ホームページのアクセス解析用コードの変更作業を行い、無事切り替え作業が終了しました。ネットブックの電源を落とし、ルーターの設定で80番ポートも閉じて、自宅Webサーバー稼動前の状態に戻りました。

それにしても、自宅サーバーの安定稼働は本当に難しいものです。温度管理、停電対策、セキュリティ設定、OSアップデート、トラブルシューティングなど、時折手をかける必要が出てくるものがあります。うちでは、ネットブックを利用した簡易的なものでしたが、24時間稼働にあたっては「何もしなくていい」という状態に持って行くことができませんでした。

そういった経緯で、私としての落ち着きどころは、「手のかからない有料サービス」ということになりました。



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

関連カテゴリー: Web管理関連記事, WindowsPC関連記事

XAMPPではじめる全部無料のかんたん+最新自宅サーバーfor Windows をAmazon.co.jpでチェック

ご無沙汰しております。
DB入れ替えお疲れ様でした。自宅でのサーバー運用はやっぱり難しいみたいですね。気になることを１つ減らせたことを考えると￥2,100は安いかも知れないですね。

関係ないですが、ついにウチの会社もWindows7への入れ替えをすことになりました。今年度中に全てのPCを切り替える予定で、忙しくなるんだろーなー・・・

ネットブックの簡易サーバーとは言え、時間の面でもコストの面(ネットブック本体価格やクーラー電気代なども含めて)でも、ホスティングサーバーのサービスの方が「楽」という結論に達しました。

Windows 7はXPやVistaに比べて便利にできてますが、総入れ替えとは大変ですね…。私はSE職から足を洗ったので、現在そういった作業は他人にお任せしてます。自宅の趣味(というか週末の個人事業?)としては色々とやってますけど。

※(2010/4/11追記)PHPプログラムはページ下部のコメント欄をご参照ください。

先日、本サイトに「管理者のつぶやき」というページを設置して、私のTwitter(ツイッター)の書き込みをリアルタイムで表示するようにしてみました。ただ、Twtter APIを用いた簡易的なブログラムなので、「管理者のつぶやき」を見るより、直接Twitterの私のページを見た方が早いという話もありました。

しかし、本家Twitterについても、検索機能はあまり充実していると言えません。基本的に日本語検索が不完全なことに加え、「何日から何日までのつぶやき」というような、書き込み日時による抽出も不可能です。過去のつぶやきを見るには、画面下にある「もっと読む」ボタンを何回か押さないといけません。せっかく自分で書き込んだ内容なので、日記やブログのように読み返せると便利なのに、と思うことも多々ありました。

そのようなことから、Twitterの書き込みを日付とワードの両方で検索できるシステムを自前で作ることにしました。本ページ左の「管理者のつぶやき」をクリックすると、最新のつぶやきに加えて、新たに設置した抽出機能もチェックできます。

原理としては、KUNISAN.JP内のあるページを開くことで、Twitterに書き込んだ内容をMySQLに書き込むプログラム(PHPで作成)が動作するようになっています。検索機能はTwitter APIではなく、このMySQLの方からデータを抽出する形になっているため、より柔軟なデータ抽出が可能となっています。

とは言うものの、ブログに比べて各書き込みの情報量が少ないので、どれだけ利用価値があるのかは定かではありません。ただ、私としては過去の書き込みにアクセスしやすくなったということで、Twitterの利用価値がますます上がったように感じています。



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

関連カテゴリー: Web管理関連記事, PHP関連記事

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

Twitter APIのデータをMySQLに渡すプログラムとMySQLのデータを抽出・表示するプログラムを公開します(どちらもPHP)。

予め「TWITTER」テーブルを作成し、「NAME(text)」「COMMENT(text)」「TIME(int)」の3つのフィールドを用意しておきます。その後、下記プログラムのデータベース接続用の変数と、Twitter APIリクエスト部分の"kunihisa_ogawa"を変更すれば、そのまま使えると思います。

※プログラムは個人使用に限り自由にご利用いただいて結構ですが、動作確認等すべて自己責任でお願いします。当方では一切のサポートを行っていません。
※プログラムの無断配布、転載等はご遠慮ください。当ページへのリンクはご自由にどうぞ。
※当サイトで動作しているものと、一部中身が異なります。

■■■■ Twitter APIからMySQLへデータ追加 ■■■■
//エンコード設定
mb_language("ja");
mb_internal_encoding("SJIS");
mb_regex_encoding("SJIS");

//データベースオープン
//変数設定
$dbserver = 'localhost';
$dbuser = 'XXXXXXXX';
$dbpassword = 'XXXXXXXX';
$dbname = 'XXXXXXXX';

//MySQLに接続する
$con = mysql_connect($dbserver,$dbuser,$dbpassword);

//データベースを選択
$selectdb = mysql_select_db($dbname);

//Twitter APIに接続
$contents = file_get_contents('http://search.twitter.com/search.atom?q=from:kunihisa_ogawa&rpp=100');

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

//ループ処理
for ($i = 0; $i < 100; $i++ ) {

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

//書き込み人のユーザー名のみ取得
//$author_link = $xml->entry[$i]->author->uri;
$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");

//本文をUTF-8に変換
$utf8_comment = mb_convert_encoding($bunsho,"UTF-8","SJIS");

//ダブルクオーテーションを参照文字に変換
$utf8_comment = mb_eregi_replace("\"",'"',$utf8_comment);

//時間をUNIX形式に変更
$unixtime = strtotime($pdate);

//DBデータを抽出(ダブりの有無）
$sql = 'SELECT * FROM TWITTER WHERE TIME = '.$unixtime;

//DB結果を取得
$data = mysql_query($sql);

//ダブり用変数のリセット
$dub = '';

//DB結果セットの表示
while ($sd = mysql_fetch_array ($data)) {

//COMMENTがあれば取得(つまりダブり)
$dub = $sd[COMMENT];

}

//ダブりがなく、かつ$unixtimeが0より大きければレコード追加の処理
if (($dub == '')&&($unixtime > 0)){

//テーブルにレコードを追加する
$sql = 'INSERT INTO TWITTER
(NAME,COMMENT,TIME)
VALUES
("'.$id.'","'.$utf8_comment.'","'.$unixtime.'")';
if (mysql_query($sql)) {
//print 'レコード追加成功<br>';
} else {
//print 'レコード追加失敗<br>';
}

}
■■■■■■■■■■■■■■■■■■■■■■■■■■

■■■■■ MySQLのデータを抽出して表示する ■■■■■
//エンコード設定
mb_language("ja");
mb_internal_encoding("SJIS");
mb_regex_encoding("SJIS");

//データベースオープン
//変数設定
$dbserver = 'localhost';
$dbuser = 'XXXXXXXX';
$dbpassword = 'XXXXXXXX';
$dbname = 'XXXXXXXX';

//MySQLに接続する
$con = mysql_connect($dbserver,$dbuser,$dbpassword);

//データベースを選択
$selectdb = mysql_select_db($dbname);

//何日前からのデータを取得するか？（デフォルト値）
$term = 30;

//日付1の取得(いつから)
$date1 = $_GET[DATE1];
if ($date1 == '') {
$date1 = date('Y/m/d',(time() - (86400 * $term))); //デフォルト値設定
}

//日付2の取得(いつまで)
$date2 = $_GET[DATE2];
if ($date2 == '') {
$date2 = date('Y/m/d',time()); //デフォルトは今に設定
}

//サーチワードの取得
$searchword = $_GET[WORD];
$hyojiword = mb_convert_encoding($searchword,'SJIS','UTF-8');

//表示件数の取得
$hyoji = $_GET[HYOJI];
if ($hyoji == '') {
$hyoji = 30;
}

//最大1000件まで表示
if ($hyoji > 1000) {
$hyoji = 1000;
}

//フォーム表示
print '
<form method="get" action="twitter_kunisan_jp.php">
<b>日付:</b> <input type="text" name="DATE1" value="'.$date1.'" style="width: 85px;">～<input type="text" name="DATE2" value="'.$date2.'" style="width: 85px;">　
<b>検索ワード:</b> <input type="text" name="WORD" value="'.$hyojiword.'">　
<b>表示件数:</b> <input type="text" name="HYOJI" value="'.$hyoji.'" style="width: 45px;"><br>
<button type="submit" value="">つぶやき抽出</button>
</form>
';

//サーチワード指定があれば、サーチワードでも抽出をかける
if ($searchword != '') {
$filtersql = 'AND COMMENT LIKE \'%'.$searchword.'%\'';
}

//SQL指定
$sql = 'SELECT * FROM TWITTER WHERE TIME >= '.strtotime($date1).' AND TIME <= '.(strtotime($date2) + 86399).' '.$filtersql.' ORDER BY TIME DESC LIMIT '.$hyoji;

//DB結果を取得
$data = mysql_query($sql);

//データ件数リセット
$ndata = 0;

//DB結果セットの表示
while ($sd = mysql_fetch_array ($data)) {

//書き込み人のユーザー名取得
$id = $sd[NAME];

//本文の取得
$bunsho = $sd[COMMENT];
$bunsho = mb_convert_encoding($bunsho,"SJIS","UTF-8");

//URLをリンクに変換
$bunsho = mb_eregi_replace("(https?:\/\/[-_.!~*'()a-zA-Z0-9;/?:@&=+$,%#]+)",'<a href="\\1"'.$target.'>\\1</a>',$bunsho);

//書き込み日の取得
$pdate2 = date('Y/m/d H:i:s',$sd[TIME]);

//コメント表示
print '<p><b>'.$id.'</b>: '.$bunsho.' ('.$pdate2.')</p>';

//データ件数カウント
$ndata = $ndata + 1;

}

//検索結果がない場合
if ($ndata == 0) {
print '<p>指定された検索ワードのつぶやきはありませんでした。</p>';
}
■■■■■■■■■■■■■■■■■■■■■■■■■■

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

昨年末に購入した「Google AdSense For Dummies」という洋書を読み終えました。洋書一冊を最初から最後まで読み通したのは、5～6年ぶりになると思います。私自身、Google AdSenseを始めてから数年が経ちますが、何らかの知識の足しになれば、という期待と、英語の勉強にもなるということも併せて、時間をかけてじっくりと読みました。

内容としては、AdSenseの広告の種類や管理画面の操作方法など基本的事項についての説明や、広告の配置、色使い、アクセス数増加対策など、運用面での実践的なことも書かれています。「裏技」のようなものは書かれておらず、自己クリックなどの違反行為はもちろんですが、グレーゾーンにあたるようなことも「絶対にやってはいけない」としており、長期的に稼ぐ基本は「コンテンツを充実させること」と強調しています。

ただ、コンテンツの充実→リピーターが増える→広告クリックが増える、という図式は必ずしも当てはまらないような気がします。AdSenseに限らず、一般的にリピーターは広告のクリック率が低いと言われています。それよりも、コンテンツの充実→被リンクの増加→検索結果ランキングが上がる、という効果の方がメリットが大きいです。

この本にはおまけでUS$25のAdWordsギフト券が付いてきます。ただし、このギフト券を使えるのは今までにAdWordsのアカウントを取得していない人のみで、私は既にAdWordsの使用経験もあるので、残念ながら使うことができませんでした。私はこの本を2,000円弱で購入しましたが、もしこれからAdSenseもAdWordsも両方やってみたいという人がいたら、かなりお得ということになります(場合によっては元以上？)。

ちなみにこの「Dummies」シリーズですが、私は今までにWindows 2000、Networking、Lotus Notes 6と購入していて、今回のAdSenseが4冊目になります。文章が口語調で書かれており、「英語はそこそこできるけど読解は苦手」という人でも、あまりストレスを感じずに読み切ることができると思います。



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

関連カテゴリー: Web管理関連記事, 英語学習関連記事

Google AdSense For Dummies (For Dummies (Computer/Tech)) (ペーパーバック)をAmazon.co.jpでチェック

Lotus Notes for dummies（頂いた本）家にありますよー。たまに読んでましたが、会社のメールソフトがNotesからOutlookになったので、あまり読まなくなってしまいましたが・・。

そういえばLotus Notes for dummiesは会社のお金で買ったので、会社に置いておきましたね。Windows 2000は行方不明で(もういらないですが)、Networkingは今でも手元にありますよ。あっ、もちろんどちらも個人のお金で買ったものですよ。

※(2010/4/1追記)本件はBIGLOBEより状況改善の連絡がありました。詳しくはページ下部のコメント欄を見てください。

先々週のことですが、BIGLOBE担当者より「アンケート」という形で、「ひかりTV」サービスの勧誘がありました。しかし、我が家ではテレビをあまり見ない上に、自宅サーバーやルーター設定などへの影響を最小限に抑えたいこともあり、インターネットをコンピュータ以外の用途に使うことをできるだけ避けたいということで断りました。「最初の2ヶ月間は無料なので」と、もう一押しありましたが、解約を前提とした契約になることは明白なので、「お互いに手続きが面倒になるだけ」ということで丁重に断りました。

その翌週、私が留守の間に、BIGLOBEの別の担当者から妻に電話がありました。やはり「ひかりTV」の勧誘でした。しかし私から妻に上記の事を伝えていなかったこともあり、「2ヶ月無料」ということで、そのまま申し込みをしてしまいました。翌日、私が既に「ひかりTV」を断った事と、断った理由についても既にBIGLOBEに説明済みということを妻に伝え、妻より電話でキャンセル依頼を出しました。

その2日後、今度はBIGLOBEよりメールで「お申し込み受付」の連絡がありました。キャンセルを受け付けたはずなのに一体どうなっているんだろうと思い、「キャンセルしたはずですが」とメールを返信したところ、「キャンセル手続きの確認が取れない」との回答が来ました。BIGLOBE社内の情報体系の悪さにびっくりしましたが、妻のキャンセルの電話に対応した担当者の名前を伝えつつ、改めて「キャンセル」ということで連絡を出しました。

しかし、今週になって妻宛にNTTから「ひかりTV」のガイドブックが届き、さらに今日になってやはり妻宛にBIGLOBEから郵便で「ひかりTVforBIGLOBE契約内容確認書」が届きました。さすがに頭に来て、確認書に書いてあった電話番号にクレームの電話を入れたところ、「すでにキャンセル済みです。破棄してください」との回答がありました。加えて先週メールで連絡した別のBIGLOBE担当者にもクレームのメールを入れておきました。

それにしても、BIGLOBE契約者本人である私の確認なく、妻の一言で契約を進めてしまい、しかもキャンセル処理に関して社内で横の連絡が全くできておらず、加えて万が一私が感知していなければ(もしくは「もうキャンセル済みだから」とそのまま流していたら)、さらに勝手に事が進んでしまうという状況には参りました。IT系の会社なのに、キャンセル情報を社内で共有できていないというのも不思議な話です。

例えば、という話になりますが、BIGLOBE契約者本人が家に長期不在で、機器設置の事実等が知らされないままの状況も考えられます。「契約者本人が知らないうちに請求が来る」という可能性もあり、世間に広く知られた会社のやり方としては、非常にまずいのではないかと思います。

BIGLOBEを利用しはじめたのは、インターネットをやり始めた1997年からで、利用期間は実に13年もの長期に渡ります。しかし、ここまで手間のかかる体験をしたのは初めてです。一瞬、他のプロバイダーへの変更を考えましたが、とりあえずは今後のBIGLOBEの対応を見てからにしたいと思います。



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

改正法対応 すぐに役立つ 消費者契約法 特定商取引法 割賦販売法の法律知識 をAmazon.co.jpでチェック

BIGLOBEもの会社が情報共有化されていないというのは驚きですが、たとえ会社がIT系だろうと非IT系だろうと、営業現場ではそんなものかも知れないですね。

大企業ではありがちですが、IT担当者が「これを使えば情報共有化がもっとうまくいく」と思って導入したツールも現場では全く使われていなかったりしますからね（苦笑）

ネットで検索してみると、BIGLOBEに限らず、他のプロバイダーでも「ひかり電話」の勧誘に困っている人が多いようです。しかも、プロバイダーとは別の会社がプロバイダー名を名乗って勧誘することもあるようです。そうだとすると、プロバイダーの契約情報が契約者の承認を取らずに第三者に渡されているということになり、個人情報保護法など別の問題が出てくることになります。この「プロバイダーとは別の会社」がいくつも存在することから、短期間にいくつも勧誘の電話がかかってくることもあるようです(もちろん「別の会社」同士では情報のやりとりは無いでしょうから)。

ただ、上記の件についてはBIGLOBEからの回答が来ていないので、現時点では「BIGLOBEの営業担当者が直接電話したもの」と解釈しています(こちらにはそれを否定する客観的な証拠が無いので)。まあ、このあたりはBIGLOBEサイドで調査すればすぐにわかることだと思いますが。

先ほどBIGLOBEの部長さんから謝罪の電話がありました。

キャンセル処理がうまく進まなかった件については、やはりデータベース間や部門間の連携など、社内の情報の流れがうまく行っていなかったということでした。また、「BIGLOBE契約者の確認無しに契約が進んでしまう可能性」については、営業活動を一時的に中止してまで改善に当たっているとのことでした。私からも「契約確認書類や機器を送る前に、BIGLOBE契約者に確認メールを出して、了承の連絡を受けるようにする」というアイデアを出しました。

私自身、「また忘れた頃に勧誘があって、勝手に契約が進む可能性も…」という不安感が無くなったことも大きいですが、他のBIGLOBE契約者やBIGLOBE自身も、これで無用なトラブルの可能性が無くなったのではないかと思っています。

一応BIGLOBEの部長さんにもお話しましたが、私としては基本的にBIGLOBEのサービスには満足していて、今回のようなトラブルは非常にレアなケースだと信じています。