Instagramが写真をFB広告素材に転用するというデマについて

元ネタはこれ。

Instagram利用規約変更!退会者続出!Instagramが写真素材サイトに!? – NAVER まとめ 

とりあえず情報を追って、デマであると判断しました。

Instagramの改訂サービス利用規約及び改訂プライバシーポリシーは英語なので読むのは躊躇するかもしれませんが、Facebookのサービス利用規約を見れば一目瞭然です。

10.       Facebookが掲載または増進する広告およびその他の商用コンテンツについて

弊社は、広告主だけでなく、ユーザーにとっても価値のある広告を提供することを目標としています。そのために、ユーザーは以下の点に同意するものとします。

1.            ユーザーは、プライバシー設定を使用して、自分の名前およびプロフィール写真と弊社が掲載または増進する商用またはスポンサー付きもしくは関係するコンテンツ(好きなブランドなど)との関連付けを制限することができます。ユーザーは、自分が設定した制限にもとづき、自分の名前およびプロフィール写真をかかるコンテンツに関連して弊社が使用することを許可するものとします。

2.         弊社がユーザーの同意を得ることなく、ユーザーのコンテンツまたは情報を広告主に提供することはありません。

ちなみに10の1はアレですね。ソーシャル広告に対して「いいね!」等のアクションをしたかを公開するかどうかをユーザー自身が決められる、という事です。このへんはFacebookの『プライバシー設定』→『広告、アプリ、ウェブサイト』→『広告』から設定できます。ちなみにそのページを見ると「Facebookが外部アプリケーションや広告ネットワークにユーザーの名前や写真を使用する許可を与えることはありません」「(ソーシャル広告に)写真が使用される場合、ユーザーのプロフィール写真が使用され、写真アルバムからの写真は表示されません」と明文化されています。

あと、Instagramの利用規約及びプライバシーポリシー(いずれも英語)を読むと、重要と思われる部分では以下のような記述があります。意訳で拙いですのでツッコミがあればご自由に。

  • Instagramは本サービスを通じて貴方が投稿したコンテンツの所有権を主張しません。代わりに、貴方が特定のユーザーへの表示を制御できる(訳者注:ブロックみたいなもの?)ことを除いてInstagramが貴方の投稿したコンテンツを非独占的かつ無料で譲渡又はサブライセンス(訳者注:第三者へのライセンスの付与)を行う権利を付与します。(訳者注:ようするにコンテンツを他のユーザーに表示したりTwitterやFacebookに投稿する権利を言っていると思われ)
  • 貴方はInstagramが貴方の掲示内容に責任を負わないことに同意します。Instagramは貴方の掲示内容を事前にモニタリング・編集・削除する義務を負っていません。貴方のコンテンツがこれらの利用規約に違反している場合は、そのコンテンツに対する法的責任を貴方が負うことがあります。

(以上サービス利用規約から)

  • Instagramは2012年9月にFacebookに買収されました。(中略)貴方は今でもInstagramで誰が貴方の写真を見るか選択することができますし、Facebook上にあなたの写真を投稿するかを選択できます。
  • 私達は貴方のデバイスに設定されたCookieや類似技術に関して、サードパーティーの広告やサービスのパートナーに助言を求めることができます。
  • 私達は、サービスの提供に役立つCookie・ログファイル・デバイス情報・位置データなどをサードパーティーと共有することがあります。守秘義務条項の下でサービスを提供するために合理的に必要である場合に当社は貴方の情報にアクセスする権限が付与されます。

(以上プライバシーポリシーから)

まあ、全部翻訳しようって気にはなりませんが・・・・

実は私もちゃんと情報を確認せずデマの発信源になった事があります。

間違いを犯すのは完璧には避けられないとして、間違えた時にきちんと訂正して情報発信するようにしましょう。

とりあえず信じてInstagramアカウント削除した方はご愁傷さまです^q^

追記

これも参考になるかも。

ニュース – Instagramがプライバシーポリシーと利用規約を変更へ、Facebookと情報共有:ITpro

さらに追記

元ネタの一つであるNYTimesのテクノロジー系記事(英語)。多分これが飛ばしと言うか曲解なんだと思う。利用規約”Rights”の2は「ウチは広告で成り立ってるけどお前らはユーザー名とかいいね!とか写真とか無償で提供してね(つまり儲かってもお前らにはビタ一文やんねーよ!)」って言ってるんであって「お前らの写真を広告に使うよー!」とは言ってないよね。なんでこんな曲解するんだろ。Instagramに親でも殺されたか?

 

またまた追記

英BBCより、Instagramが写真を販売するという噂を公式に否定しました

これにてファイナルアンサー。

広告

Androidアプリのテスターを募集します

 Androidアプリのテスターを募集しております。

開発中のAndroidアプリが使用に耐える出来になったので、テスターとして開発を支援してくださる方を募集します。

アプリはこちら(↓)。

位置的な彼女 

Android携帯からfoursquareを利用するためのクライアントアプリケーションであり、foursquareのアクティビティに応じて進むビジュアルノベル、及びキャラ画像ARやカラーフィルタが使えるARカメラ機能を有しています。

foursquareクライアント部分

 

 

ゲーム部分

 

 

とりあえず手にとって弄っていただくとどんなものか分かりやすいと思います。

アプリやfoursquareに関する説明はホーム画面で端末のmenuボタン→「開発室」で見れます。

とりあえず私の実機では無事動いていますが、端末による機体差が激しいのがAndroid。

なので色んな機種を持っている方に試していただけると助かります。

Android携帯を使っていてfoursquareのユーザーである方、ぜひご一報ください。

テストで確認して頂きたいところ

  •  下位互換性。Android1.6から使えるようにしてありますが、もしかすると低いバージョンでは使用できないAPIが存在するかもしれません。アプリの使用中に強制終了する事があれば、どのページでどんな処理をした時に強制終了したかをお知らせください。
  • ゲーム部分。特に文字サイズ。画面サイズから相対的にサイズ指定していますが、エミュレータで確認したところ、一部の画面解像度でやたら文字サイズが小さくなる現象が見られました。とりあえずホーム画面で端末のmenuボタン→開発室 でご確認ください。
  • ハードウェア制御。主にARカメラ部分。カメラはなんといっても機体差の激しいAndroidの鬼門。挙動がおかしい場合はお知らせください。あと、プレインストールされたカメラやギャラリーとの連携でおかしな部分があれば。
  • 位置情報の取得。東京駅構内で位置情報を取得しようとしたら全く取得できない事がありました。再現性を確かめるために東京駅までは行けないので、そのような現象が起こったらお知らせください。

あと、UIの使い勝手とか、気が付いた事があればお知らせください。

 

なんか、一方的にお願いするばかりで申し訳ありません。

こんなショウジョウバエも嫌がって寄り付かないような低俗な人間である私の開発にご協力してくださるお優しい方は、ぜひTwitterのDMかfacebookのメッセージでお知らせください。その際はお使いになっているAndroid携帯のキャリア・端末メーカー・機種・Androidのバージョン等をお知らせ下さい。

何卒よろしくお願い申し上げます>ω<

ブックマーク棚卸しをして選んだおすすめ記事20選

ふと『ブックマーク棚卸し』という言葉を聞いて、自分もちょっとやってみようと思いました。

私は元々、繰り返し読みたいと思った記事には『*読み返す』ってタグを付けるんですが、その中からもうちょっと厳選して「これは人様にもおすすめできる」というものをまとめたいと思います。

まあ、あくまで個人的基準です。IT関連にものがどうしても多くなっちゃうので、興味ない人はスルーで。

あと、順番はブクマした時系列です。

 

プロフェッショナルに学ぶ「アイデア発想法」「プレッシャー克服法」「やる気を出す方法」 – Attribute=51

アイデアを出したり、プレッシャーを克服したりモチベーションを上げる方法です。

 

 らばQ : それでもあきらめなかった24人の偉人

いま逆境にある人はとりあえず読みましょう。ちょっと前向きな気持になれるかも。

 

スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ – Masatomo Nakano Blog 

システム開発における反省点からチームビルディングまで。

 

僕がWebディレクターの肩書がついてから勉強した15のこと

web系にかかわる人は職種は何であれこのへんは勉強したほうがいいのかも。

 

人生をより楽しくさせる100の方法 | Webクリエイターボックス 

自己啓発系はあんまり好きじゃないけど、なんとなく共感するものもあったので。

100個のうち、気に入ったものだけを心掛けてもいいと思います。

 

1年間の技術的負債を返すために読んだ3冊の本 

コーディングして時間が経つと自分で書いたコードなのに読んでも意味わかんないって事がありますよね。

私はあります( ー`дー´)キリッ

思い当たることがあれば読んでみましょう。

 

 ネガティブな人が「成功する」ための5つの名言 : earth in us.

非リアな自分を肯定してもらえます^q^

 

僕が社長になってはじめてわかったいくつかの大切なこと。または川上さんから学んだこと – Keep Crazy;shi3zの日記 

起業に関する生々しい話。

『どれだけ求人広告を打っても、まともな応募が来ない』とか生々しすぎる。

 

Webサービスを作ったそのあとに、「自分でもできる低コストなWeb PR方法」 « モノづくりブログ 株式会社8bitのスタッフブログです

自分でアプリ作りたい人は読んでおくといいかも。

いいものを作れば当たるってのも必ずしも真じゃないので。

 

才能の枯渇について (内田樹の研究室) 

才能の正しい使い方について。

 

 簡単にモチベーションを上げる方法 | 情報蔵たつが教えるアフィリエイトで稼ぐノウハウ

ブログタイトルがアフィリエイト云々で「ん?」ってなるけど書いてあることは結構まとも。

『ベランダに出てちょっと深呼吸』っていうのが意外と出来なかったりするんですよね。

 

今年はWebサービスを作りたいと思っている人にお勧めのエントリーまとめ | ロプログ 

まとめのまとめ。

結構量が多いので全部読むには時間がかかるかも。

 

 ポール・グレアム「自然発生的な起業のアイデア」 – らいおんの隠れ家

この人のブログはポール・グレアムの翻訳が多い。結構ためになるのでフィード購読してもいいかも。

 

今年こそWebサービスを作りたい人に伝えたい5つのこと(+番外編) – パパパパ 

個人開発者がいかにサービスを企画運営するか、という話。

『企画段階でプロモーションの仕掛けを組み込む』とか結構重要だと思う。

 

デザインの力で新聞を復活させた男。ジャチェック・ウツコ

目からウロコ。

『私のように貧しい国に住み、小さな会社のつまらない部署で働きながら、予算も何も無い所でも、それでも「自分の仕事を最高レベル」に持って行くことが出来ます。』とか素晴らしい箴言ですね。金の板に掘って飾りたい。

著者の大元さんはfacebookでも購読させてもらってますが非常に素晴らしい視点を持ってます。

 

登 大遊@筑波大学大学院コンピュータサイエンス専攻の SoftEther VPN 日記 

このくらいのレベルになれるならなりたい^q^

 

時間を奪うコンテンツと時間を与えるサービス « nia.note 

なんとなくソーシャルなんちゃら系サービスに食傷気味で、これからはベンダーがユーザーにコンテンツを提供する、もしくはユーザーの手間を省くようなサービスが流行るんじゃないかと 思っていた矢先に読んだエントリ。

企画の参考になるかも。

 

面倒な仕事 – naoyaの寿司ブログ

面倒な仕事その2 – naoyaの寿司ブログ 

二つに分けたエントリ。

自己流に解釈すると『プログラミングに出来る範囲のモノ作りに固執すんな』ってことかな?

 

120131_52_フリーランスとか大手とか言ってないで「ソニーの開発18か条」を今こそ振り返ってみよう! – Onigiri.blog 

これはつい先日のやつ。

 

以上、20選でした。

個人的には、『デザインの力で新聞を復活させた男。ジャチェック・ウツコ 』がお気に入り。

ところでもうすぐバレンタインデーですが、チョコもらえそうですか?

google+は日本では150%流行らないと断定した

おはようごじますっヾ(☼ⒾωⒾ)

 

のっけから釣りっぽいタイトルですみません。

 

今朝、ちょっと調べものしようと思ってぐぐる検索さんを使ってみたんですが、最近出来たトップの黒いバーの左端に見慣れないリンクを発見しました。

 

「これは….もしやgoogle+のっ!?」

 

日曜の甘ったるい午前、招待制のおこぼれに預かれなかった私の心はときめき、意気揚々とリンクをクリックしました。

 

これがgoogle+….

 

相変わらず素っ気ない白い背景、洗練されたオーラ醸し出すUI、私の心は益々踊った。

 

しかし、その画面をじっくり見るうちに、次第に私はなんかこれ 自分は使えないなー….っていう考えに変わってきました。

 

そこで、google+に対して感じた違和感を纏めたいと思います。

 

【ここがヘンだよgoogle+】

①gmailのメインアカウントに問答無用で紐付けされる

つまり、gmail は複数作成して利用できるにも関わらず、メインで利用しているアカウントでの人間関係に問答無用で紐付けされてしまう。メールの用途、例えば、オフィシャルとプライベートを使い分けるような使い方をしてる人がいたとしても、利用できるのはメインアカウントのみ。

 

②メールのやり取りした相手が問答無用でサークルのメンバー候補に表示される

メールのやり取りした相手が必ずしも友達になり得る相手かというとそうではない。むしろ真逆の場合もある。会社の上司だったり、取引先だったり、クレーム入れてきた相手だったり….google+を利用するということは、そういう相手に対して自分のプライベートを丸裸にしてしまう可能性がある。

 

上記二つの理由から、私はgoogle+の利用をとりあえず断念しました。

だって、「つながりたくない相手」にまで問答無用でつながっちゃう可能性があるし。

twitterで私をフォローしてる方は、私がおっぱいだのおセッ○スだの放送禁止用語を日常的に発していることはご存知だと思うので大体私の事情は分かっていただけると思います。

 

閑話休題。

 

facebookの実名制や偽名アカウント排除について一時期ネットが賑わってましたが、google+はその比じゃありません。

利用することで問答無用でプライベートが丸裸にされる可能性があります。

 

まあ、抜け道はあるんだろうけど。gmail以外のメアド使って新たにgoogleアカウント作ってうんたらかんたら….とか。

そこまでして使う人がいるかって言うと疑問だけど。

 

匿名か実名かっていうのが議論されまくって、mixiにfacebookの真似すんなって言われまくってる日本で、google+が流行るかって言うと、150%流行らないだろうな….って思った次第です。

 

なんというか、UIとか洗練されまくっててさすがgoogle….って感じなのに惜しい気がしますね。

 

まあ、まだローンチしたばかりで結論付けるのもアレなので、今後の推移を見守りたいと思います。

 

おっぱいもみたい。

PHPer必見の文書『A HOWTO on Optimizing PHP』を和訳してみたよ!

正式名称は『A HOWTO on Optimizing PHP with tips and methodologies』ですね。

PHPの最適化に関する文書です。

PHP4の時代に書かれたものですが、今でも通用する内容だと思います。

この週末を使ってコレを読んでたので、ついでに和訳しました。

かなり意訳&拙い翻訳ですが、何かしらのお役に立てればと思って載せます。
情報古かったり個人的に縁のない部分は省略したりしました。
ポロリもあるよ!

—–ココから和訳—–

やあ!

こいつの最終更新日は2009年9月30日だよ!
ベンチマークはちょっと古いかもしれないけど、一般的なアドバイスとしてはまだまだイケるんじゃないかな!
8年間やってきた中でいちばん需要なのはキャッシングだって気付いたからそこんとこは修正したよ。
まあ、squidとmemcacheについて付け加えたんだけどね。
変更事項について知りたきゃ原文のログを探すことだね。
こいつが気に入ってくれたら、僕のブログ『どこでもPHP!』(http://phplens.com/phpeverywhere/)を読んでよ。

【PHPを最適化する方法】
PHPはすっげー早いプログラム言語なんだけどさ、そいつを最適化することでもっと早くなるんだぜ。
『スピードは俺の方が上だったな』ってくらいに。

ここじゃあさ、PHPに関係あるなしじゃなく、PHPがサーバー上で他のサブシステムにどう影響するのかとか、
PHPを最適化するべき要因とかさ、そのへんについて説明しつつボトルネックを確認していくよ。

【高性能ってやつを実現しよう】

パフォーマンスがどのくらい良いかって話するときにさ、PHPがいかに早いかっていう話はしたことないよね。

そもそもパフォーマンスってのはさ、

『速度&正確な動作&スケーラビリティ』

ってのを一緒くたに考えなくちゃいけないんだ。

例えば速度と正確さって話だと、キャッシングして動作が早くなっても参照してるのが古いデータだと

「こんなの絶対おかしいよ!」

って話になるじゃん?
もしくはさ、速度とスケーラビリティを重視して正確さを損なうようなことだってあるわけじゃん?

つまりさ、PHPはすっげー早く走る短距離ランナーであると同時にタフな長距離ランナーでなくちゃいけないんだよ。

問題をハッキリさせなくちゃいけないから、リアリティのある例を出そう。

僕が250Kのファイルを読み込んでさ、そいつについてHTMLでのサマリーを出力するとしよう。
僕は同じ挙動をする2つのスプリクトを書くよ。

ファイル全部を一度に読み込むhare.phpと、一行ずつ読み込むtortoise.php。
読み込むのはtortoise.phpのほうが遅いし、より多くのシステムコールを必要とするんだ。

hare.phpは0.04秒かけて10MBのメモリを消費し、tortoise.php は0.06 秒かけて5MBのメモリを喰う。
サーバーのメモリは100MB、CPUは99%アイドルタイム、話を単純化するためにメモリの断片化は
起こらないとしよう。

並列で10のスプリクトが動いてるとすると、hare.phpはメモリ(10のx 10 = 100)が尽きちゃう。
ところがね、tortoise.php は50MBのメモリが自由なままなんだ。
hare.phpが11個目のスプリクトを動かしたら、最初の半分で減速しちまう。
トータルで0.08秒かかる。
ところがどっこい、tortoise.phpは0.06秒で終わっちゃうんだ。

つまり、良いパフォーマンス=早いPHP、ってわけじゃないんだ。

ハイパフォーマンスなPHPは、
下にあるハードウェア、OSと支えるソフトウェア(例えばウェブサーバとデータベース)
の十分な知識を必要とするんだ。

【ボトルネック】

ウサギとカメの例が分かりやすいよね、ボトルネックについて話すとき。
無限のメモリはで、hare.phpは常にtortoise.phpより速いよ。
でも残念なことに、この二つの例えは単純すぎるし、メモリ以外のボトルネックだってあるんだ。

(a) ネットワーク
君が使ってるサーバーのネットワークが多分最大のボトルネックだよね。
秒当たり1MBの転送速度なら、30kのウェブページが33個あれば溢れちまう。
さらに細かく言うと、DNSだのなんだのってのもある。

(b) CPU
質素なHTMLを送るだけならCPUはネットワーク以上のボトルネックにならない。
でもリッチなやつを送るとそうでもないんだ。
対策としては、サーバーを冗長化することだね。

(c) 共有メモリ
共有メモリの使いすぎもあんまりよくないよね。

(d) ファイルシステム
メモリからデータを読むより、ハードディスクにアクセスすることは、50~100倍遅かったりするんだ。
メモリを使っているファイル・キャッシュはこいつを軽減できる。
でもメモリが低い場合はそうじゃない。
Unixのシンボリックリンクの重い使用は、ディスク・アクセスも遅くすることがあるんだ。

(e) プロセス管理
マルチスレッドでPHP動かすのもかなり遅いよ
(メモ: PHPの古いバージョンは、マルチスレッドのモードで安定ではありません)。
(訳者注:今のバージョンでもworkerで動かして平気かどうかは試したことがない)。
webサーバーにあんまり多くのことをさせないでほしい。
サーバーとしてしか使わないなら、X Windowとかまじカンベン。

使ってないプロセスは極力止めよう。

/etc/init.dとかetc/rc.d/init.dとかで。
もしくは、cronを使ってオフピーク時にやるとかね。

(f) 他のサーバーに接続すること
君のwebサーバが他のサーバーで動いているサービスを必要とするなら、それらのサーバーがボトルネックになるかもね。
例えば、複数のwebサーバーからリクエスト受けまくってるDBサーバーとか。

【いつチューニングを始める?】

コーディングが終了するまでチューニングを延ばしたほうがいいって言う人もいるけど、
それはプログラミング・チームが最高のコーディングができて既に良好なパフォーマンスが得られてる場合だけだよね。
そうでないなら、テスト後に相当量のコードを書き直さなきゃいけなくなるかもよ。

アドバイスするとすれば、アプリを設計する前にハードとソフトで若干の初歩的なベンチマークをしておこう。
それからアプリを設計して、パフォーマンスやらセキュリティと柔軟性をキープするようにしよう。

テストデータもいいものを選ばないといけない。
100,000のデータがあるのに100だけ選んでテストしちゃいけない。

これらは僕の同僚がやらかして、後から大部分のコードを書き直す羽目になったんだ。

【PHP最適化のためにサーバーを調整すること】

今日、Apache 1.3とIISの二つで最高のパフォーマンスを得る方法を教えるよ。こいつはHTMLについてもカバーできる。
マルチスレッド(worker)じゃあApache 1.3についてApache 2.0でもパフォーマンスに優位性はないってとあるPHPerが言ってたんだ。
preforkについてはまた今度。

(a) Apache 1.3/2.0
ApacheはUnixとWindowsで利用可能な世界で一番人気のwebサーバーだ。
Apache 1.3は基本preforkを使う。
Apacheが起動すると、HTTPリクエストを扱うための子プロセスを作成する。
親プロセスはさ、『円環の理』みたいなもんだ。子プロセスがきちんと機能/調整してることを確認してる。
HTTPリクエストが増えると、子プロセスも増えるんだ。
HTTPリクエストが減ると、親プロセスはアイドルタイムになってる子プロセスを殺す。
一連のそれらの動作がApacheをより強力にしてる。
たとえ子プロセスがクラッシュしても、親プロセスがそいつを放棄しちゃうからね。

preforkはそれ以外のものほど早くないけど、それが顕在化する前にApacheの他のボトルネックが出てくるから、それはそんなに問題じゃない。
Apacheが頑丈で信頼できるってのが重要なんだ。

Apache 2.0 は、マルチスレッドモードで動作するけど、僕がベンチマークするかぎりそれにはあまり利点はないし、
PHPの互換性(GDとかIMAPとか)で問題が出てくる(Apache 2.0.47 の話だよ)。

Apache は、httpd.confで設定するんだけど、特に以下の項目は重要だ。

MaxClients:
(default)256
作成する子プロセスの最大数。デフォルトは、最高256のHTTPリクエストが並行して取り扱われる。
それ以上は処理待ちになっちゃうよ。

StartServers:
(default)5
起動時にいくつ子プロセスを作っておくか、だよ。

MinSpareServers:
(default)5
アイドルタイムの子プロセスをいくつ作っておくか。
この数値より減少すると、まず1つ子プロセスを作り、一秒後に2つ、次の一秒で32、それ以降は1秒につき4つ子プロセスが作られる。

MaxSpareServers:
(default)10
子プロセスがこれ以上の数になると、そいつは殺されちゃうんだ。

MaxRequestsPerChild:
(default)0
HTTPリクエストの数に対してどれだけ子プロセスを作るか、の設定。
0だと無制限になる。
メモリリークが起こったり、サーバーリソースが遊んでると思ったら、100~10000の間で調整してほしい。

以下の設定は広い範囲で有効だよ。

MinSpareServers 32
MaxSpareServers 64

(訳者注:このへんの数値は同じにしたほうが必要以上にプロセスをforkしないのでいい、っていう意見もある。
参考:http://bit.ly/iody6T いろいろ試してみたほうがいいかも)

windowsのApacheはちょっと違って、子プロセスを作るかわりにスレッドを作る。
なので上記パラメータの代わりに50がデフォルトのThreadsPerChild ってパラメータを使う。
これはApacheで作り出すスレッド数を意味していて、デフォルトだと50のHTTPリクエストが並列して扱われる。
忙しいサーバーなら256~1024の間で調整するといい。

他の役立つパラメータは以下の通り。

KeepAlive:
(default)on
HTTPリクエストは個別にサーバーとの接続をしなくちゃいけないので、
コネクションを維持してオーバーヘッドを減らすためのパラメータとして作られたのがコレ。
同一のソケット接続を複数のHTTPリクエストで再利用するんだ。
画像とかは別の専用webサーバーに入れてる場合は無効にすることもできるよ。
これを設定すれば利用するリソースを大幅に削減できるよ。

KeepAliveTimeout:
(default)15
ソケット接続を生かしておく秒数だよ。
応答が完了したのに接続が生きたままだとネットワークが遊んじゃうから、この値は低くしておくべきだね。
(訳者注:応答時間+αくらいの設定で。長すぎるとwebサーバーがリクエスト送っているDBサーバー等にも負荷をかけます)

MaxKeepAliveRequests:
(default)100
リクエスト数がこの値に達すると接続を終了するよ。
MaxClientsまたはThreadsPerChild以下のなるべく高い値に設定したほうがいいね。

TimeOut:
(default)300
処理待ち何秒で接続を切るか。
クライアント数が少ないなら、低く設定してもいいよ。

DNSルックアップ(IPからホストの逆引き)を必要としていなくて個々のディレクトリでhtaccseeファイルを読み込まない場合、
以下のように値を設定するといい。

# disable DNS lookups: PHP scripts only get the IP address

HostnameLookups off

# disable htaccess checks

AllowOverride none

シンボリックリンクにアクセスしてもセキュリティ上問題ないなら以下のようにしよう。

Options FollowSymLinks

#Options SymLinksIfOwnerMatch

(訳者注:FollowSymLinksだと、指定したディレクトリ内でシンボリックリンクにアクセスできる。
SymLinksIfOwnerMatchだと、シンボリック先のユーザー一致を確認するので結構な負荷。)

(b) IISチューニング
(訳者注:省略します^q^読みたい方は原文を読んでね。)

【PHP’s Zend Engine】

Zend EngineってのはPHPでの内部コンパイラかつ実行エンジンだよ。
Zeev SuraskiとAndi Gutmansが開発したものの省略形さ。
PHP4初期だと、以下のように動作してた。

Zend EngineでロードされたPHPスプリクトはZend opcodeでコンパイルされ、それが実行されるとHTMLとしてクライアントに送信される。
opcodeはその後メモリから排除されて停止される。
今ではこれらのプロセスをより早くするプロダクトや技術のオプションがいっぱいある。
下の画像がソレ。影のついてるのがオプションだよ。

PHPスプリクトはメモリにロードされて、Zend opcodesでコンパイルされる。
現在では、Zend Optimizerを使ってこれを最適化できる。
スプリクトによっては0~50%スピードを上げることができるだろう。

opcodesはそれを停止した後は廃棄されてたんだけど、現在ではオープンソース・プロダクトや商用の
Zend Acceleratorによってそれらをキャッシュすることもできるんだ。
Zend Optimizerと互換性を持つ唯一のものはZend Acceleratorだ。
これはスプリクトのロードとコンパイルを不要にすることで、実行時間を10~200%早くできるよ。

このへんの詳細はウィキペディアを見てよ。
あとZendのサイト(http://zend.com)。こいつはマジですごいから。
ちなみに僕は大人気のeAcceleratorを使ってるよ。
あとAPC。
僕はPHP6が出来るころにはAPCが組み込まれてるんじゃないかと思ってる。
(訳者注:ちなみにeAcceleratorとZend Optimizerは併用が可能です。)

【キャッシュは最高の加速装置】

高性能の秘密の一つはさ、早いPHPコードを書かなくても、メモリにPHPコードやHTMLを
キャッシュしてそれ自体を実行しないことにあるんだ。
PHPは一度動くだけでHTMLをキャプチャしてロードする。
データを定期的に更新したいならば、expiresを出力すればいい。
そういうクラスやライブラリは沢山ある。PEAR CacheとかSmartyテンプレートとかね。

ついでにさ、クライアントに送信されるHTMLは圧縮することもできるんだ。
PHPスプリクトの最初にこいつを入れてごらん。


ob_start("ob_gzhandler");

これで多い時には50%~80%もHTMLを圧縮できる。
ネットワークの負荷がだいぶ下がるよ。
もっとも、CPUの負荷は増えちゃうけどね。

【PEAR CacheでHTMLをキャッシュする】

PEAR Cacheは、HTMLや画像といった複数のファイルをキャッシュできるクラスだよ。
一般的な使い方はHTMLのキャッシュだろうね。
以下のコードは、start()からend()の間のテキストを出力するかキャッシュに保存する
Output bufferingクラスだよ。

require_once("Cache/Output.php");

$cache = new Cache_Output("file", array("cache_dir" => "cache/") );

if ($contents = $cache->start(md5("this is a unique key!"))) {

#
# aha, cached data returned
#

print $contents;
print "Cache Hit";

} else {

#
# no cached data, or cache expired
#

print "Don't leave home without it…";
# place in cache
print "Stand and deliver";
# place in cache
print $cache->end(10);

僕がこれを書いてから、さらに優れたPEARのキャッシュクラスであるCache Liteも作られた。

このCacheコンストラクタは、最初のパラメータにストレージドライバを取得する。
これにはファイルやデータベース、共有メモリを利用できる。
pear/Cache/Containerディレクトリを見てごらん。
ちなみにUlf Wendelのベンチマークによると、ファイルを指定するのが最高のパフォーマンスらしい。
2番目のパラメータはストレージドライバのオプション。
キャッシングディレクトリの位置を指定するcache_dirと、ファイルの接頭語として設定するfilename_prefixだ。
不思議なんだけど、キャッシュの保存期間はオプションではセットされない。

データをキャッシュするために、キャッシュのキーとなるユニークなIDを作成するんだ。
僕達はmd5()を使ってるけどね。

start()でこのキーを使ってキャッシュを探す。キャッシュが存在しない場合は空の文字列を返す。
そしてend()が呼ばれるまで、echoやprintは全てキャッシュで出力される。
end()でバッファの内容を返すんだけど、end()は最初のパラメータにキャッシュの満了期間を使う。

PEAR Cacheを使うもうひとつの方法は、変数または他のデータを保存することだね。


require_once("Cache.php");
$cache = new Cache("file", array("cache_dir" =< "cache/") );
$id = $cache->generateID("this is a unique key");

if ($data = $cache->get($id)) {

print "Cache hit.
Data: $data";

} else {

$data = "The quality of mercy is not strained...";
$cache->save($id, $data, $expires = 60);
print "Cache miss.";

}

データを保存するにはget()を使うよ。
ユニークなキーがすでにファイル名にあるなら、generateID()を省略することができる。

save()はデータをシリアライズするので、オブジェクトや配列も保存することができる。
最後のパラメータでキャッシュの保存期間を設定するんだ。
こいつは秒単位とかUnixスタンプ、または0に指定すると無期限になる。

キャッシュしたデータを検索するにはget()を使ってね。

$cache->delete($id)でデータ項目を削除できるし、
$cache->flush()ですべてのキャッシュを破棄できる。

【SquidとHTTP Accelerators】

(訳者注:Squidつかおうぜ!ってことなので省略^q^)

【Distributed Caches】

(訳者注:memcacheつかおうぜ!ってことなので省略^q^)

【ベンチマークを使って】

今まではパフォーマンスの問題をカバーしてたけど、次はいよいよ骨格となるベンチマークの話をするよ。
webサーバーで現実的なベンチマークをしたければ、HTTPリクエストを送信するツールが必要だ。
Unix上でのベンチマークツールといえば、Apacheがリリースしてるabが一般的だね。
windows上では、マイクロソフトが提供してる無料の分析ツールを使うことができる。

これらによって複数のHTTPリクエストを並列に処理でき、詳細なデータを得ることができる。
Unixサーバー上では、ベンチマーク中に『vmstat 1』コマンドでモニタリングできる。
こいつは毎秒ごとにディスクI/Oやメモリ使用量、CPU負荷を教えてくれるんだ。
あるいは『top d 1』コマンドでプロセスごとのCPU負荷を監視することもできる。
1秒毎だとちょっと変動が激しいから、僕は『vmstat 5』を推奨してる。

windows2000以降だと、パフォーマンス・モニタまたはタスクマネージャーで確認できる。
もしオーバーヘッドについて心配することはないけど特定のコードが・・・って時には
microtime()を仕込んでベンチマークすることもできるよ。

$time = microtime(true);

#
# code to be benchmarked here
#

echo "Time elapsed: ",microtime(true) - $time, " seconds";

あるいは、プロファイリング ・ツール(例えばAPDまたはXDebug)を使用することもできるよ。

【ベンチマーク・ケーススタディ】
(訳者注:ここからしばらく長いので要約すると、
『PHPの最適化にはネットワーク、メモリ、CPU、Apacheの子プロセスの動作、PHPスプリクトとデータベース構成を含む
複数のソフトウェア・サブシステムの理解を必要とするよ!』
っていう話です。

【コードの最適化】

なんでこんなにPHP以外の問題について語るのかって疑問を持ってる読者もいるよね。
思い出してごらん、PHPはすっげー早い言語だって。
それを遅くしてるボトルネックは、多くはPHPの外側にあるんだ。

大部分のPHPスプリクトは単純なんだ。
それは若干のセッションを読んで、コンテンツの管理システムまたはデータベースからデータをロードして、
適切なHTMLに変換してクライアントに返す。
スプリクトが0.1秒で完了してレイテンシが0.3秒だと仮定すると、PHPの演算時間はわずが33%だ。
スプリクトの速度を20%改善したところで、応答速度は0.28秒早くなるだけ。
取るに足らない改善だよね。
もちろんそれでも、サーバーは20%分他の処理ができるからスケーラビリティは改善されるけど。

上の例はさ、僕達がやるべきことじゃなくて、やめるべきことを意味してる。
僕達はコードの最後の1%まで改善してそれを誇ってちゃいけない、
しかしより高いリターンを得られる、コードの価値ある領域を最適化することに時間をかけなきゃいけない。

【ハイリターンなコード最適化】

そういう高いリターンを得られる場所は存在する、
僕達のコードを散らかすループは存在して、そいつを繰り返すごとにスピードは落ちる。
いくつかの例を使って、何を最適化できるかを理解しようか。

例1:
配列を出力する単純な例がここにある。


for ($j=0; $j<sizeof($arr); $j++)
echo $arr[$j]."<br>";

こいつはこうすればもっと早いよね。


for ($j=0, $max = sizeof($arr), $s = ''; $j<$max; $j++)
$s .= $arr[$j]."<br>";
echo $s;

最初のやつは、評価式$jでもsizeof($arr)は不変だから、変数$maxにキャッシュすればいい。
専門用語だと、こいつは「ループ不変の最適化」っていうんだ。

第二の問題は、PHP4では、全部を文字列に保存して一度だけコールするより、複数回echoで出力するほうが遅いってことだ。
なぜなら、echoはそれをTCP/IPパケットでクライアントに送信することが必要なハイコストな処理だからだ。
もちろん、変数に文字列を足していくことはメモリも使うし、複雑なトレードオフではある。

上記のコードは、output bufferingを使用することでもスピードアップできる。
これは内部的に出力する文字列を集めて、スプリクトの終わりにそいつを出力するんだ。
これによって、メモリとレイテンシを犠牲にしながらも大幅にネットワークのオーバーヘッドを減らすことができる。
echo文だけで作った僕のコードの一部では、15%もの改善がなされた。


ob_start();
for ($j=0, $max = sizeof($arr), $s = ''; $j<$max; $j++)
echo $arr[$j]."<br>";

ob_start()による出力バッファリングは全てのPHPスプリクトの最適化に使用できる。
ランニングタイムが長いスプリクトでは、いくらかのフィードバックを返すために定期的に出力したい場合もあるよね。
これはob_end_flush()で実現できる。
この関数もoutput bufferingをオフにするから、flushした後にもう一回ob_start()をコールしたくなるかもね。

要約すると、ループ不変量を最適化することとoutput bufferingを使うことでコードを
スピードアップさせることが出来るってのをこの例は示してる。

例2:
以下の例では、取得した列をフォーマットしてechoするPEAR DBをループしてみるよ。
この実行時間をベンチマークすると、SQL接続やクエリの実行時間を除いて、10.2msだった。


function FormatRow(&$recordSet)
{
$arr = $recordSet->fetchRow();
return $arr[0].'/'.$arr[1];
}

for ($j = 0; $j numRows(); $j++) {
print FormatRow($rs);
}

例1のとおりコードを最適化したら8.7msになった。

function FormatRow(&$recordSet)
{
$arr = $recordSet->fetchRow();
return ‘<strong>’.$arr[0].'</strong><em>’.$arr[1].'</em>’;
}

ob_start();

for ($j = 0, $max = $rs->numRows(); $j < $max; $j++) {
print FormatRow($rs);
}

$maxの使用で0.5ms、ob_start()の使用で1msから1.5msのスピードアップを達成した。
さらにループの最適化により、コードの単純化とスピードアップを達成できる。
以下の例だと8.5msになったよ。


function FormatRow($arr)
{
return '<strong>.$arr[0].'</strong><em>'.$arr[1].</em>';
}

ob_start();

while ($arr = $rs->fetchRow()) {
print FormatRow($arr);
}

さらにもう一つの最適化により、0.1ms減らした8.4msになった。


ob_start();

while ($arr = $rs->fetchRow()) {
print $arr[0].'/'.$arr[1];
}

これをPEAR Cacheに変えて、キャッシュを使うことにより実行時間は3.5msにまで下がった。


require_once("Cache/Output.php");

ob_start();

$cache = new Cache_Output("file", array("cache_dir" => "cache/") );

$t = getmicrotime();

if ($contents = $cache->start(md5("this is a unique kexy!"))) {
print "Cache Hit";
print $contents;
} else {
print "Cache Miss";

##
## Code to connect and query database omitted
##

while ($arr = $rs->fetchRow()) {
print '<strong>'.$arr[0].'</strong><em>'.$arr[1].'</em>';
}

print $cache->end(100);
}

print (getmicrotime()-$t);

上の例からも、コードの微調整はob_start()のような最適化もしくはHTMLキャッシュのように大幅に速度を向上させないことが分かる。

【オブジェクト指向プログラミングの最適化】

2001年3月にPHP4でベンチマークした結果から僕は若干のアドバイスを得た。
要点は以下の三つだよ。

1.使用前にすべての変数を初期化しよう。
2.値に二度以上アクセスするなら、全てのグローバル変数やプロパティをローカル変数にキャッシュしよう。
3.頻繁に使われるメソッドは派生クラスに置いてみよう。

ただし、PHPは継続して改善されてるから、将来的にこのへんは変わるかもしれないね。

【さらに詳しく】
クラス内で定義してるメソッドをコールするのは、通常のメソッドをコールするより2倍遅いことに僕は気付いたんだ。
以下はメソッド内での話。

a.メソッド内でローカル変数の使用をインクリメントするのが一番早い。

b.グローバル変数を使うことはローカル変数より2倍遅い。

c.オブジェクトのプロパティをインクリメントするのはローカル変数よりも3倍遅い。

d.未定義のローカル変数をインクリメントするのは初期化されたものより9~10倍遅い。

e.関数内で使用しないグローバル変数を宣言するのはローカル変数の宣言にくらべて遅い。
PHPはグローバル変数が存在しないかいちいちチェックするからね。

f.クラス内のメソッドを増やしてもパフォーマンスにそれほど影響はない。

g.派生クラス内のメソッドは親クラス内のものより早い。

【調整のサマリー】

a.使用しているソフトウェア、そしてOS(ネットワークやサーバー・ハードウェア)の知識を深めることで
コードとシステムの最適化が可能になる。

b.できるだけ多くのキャッシングを使おう。僕はSquidとmemcacheを使ってるよ。

c.PHPスクリプトについて、最もハイコストなボトルネックは通常CPUだろうね。

d.PHPをインストールする時に”configure — enable-inline-optimization ” オプションをつけると一番早いPHPになる。

e.データベースを調整して、WHERE句に用いられるフィールドにインデックスをつけよう。

f.めったに更新されないデータがあるならHTMLキャッシュを使おう。毎分更新されるとしても、キャッシュと同期すればいい。
10倍くらいパフォーマンスが上がるよ。

g.複雑なコードは早目にベンチマークしておこう。xdebugか、有料だけどZend Studioとかで。

h.opcode cacheを使うことを考えよう。10~200%くらいスピードアップするよ。

i.コードの最初にob_start()を使おう。5~15%スピードアップする。ob_gzhandler()でgzip圧縮することもできるよ。

j.Zend Optimizerのインストールを検討しよう。ただし一部のコードは逆に減速するかもしれない。
君のコードに多くのループが含まれている場合、Zend Optimizerは非常に有効だよ。

k.ループの外に不変の定数を動かして最適化しよう。

l.可能な限り配列または文字列にデータを入れてからechoしよう。

m.一つの大きな文字列に小さな文字列を複数付け足していくなら、ob_start()を使うのが最速だよ。
終了時にはob_get_contents()を使って内容を取得しよう。

n.可能な限りオブジェクトや配列は関数として参照しよう。短いコードやコード・メンテナンスが問題でないなら
グローバル変数にしてもいいと思うよ。

o.セッション変数を多く使うPHPスプリクトがあるなら、共有メモリにセッションをストックするモジュールを使うよう
PHPの再コンパイルを検討しよう。

p.文字列検索はstrpos() > preg_match () > ereg()の順に早い。
文字列の置き換えはstr_replace() > preg_replace() > ereg_replace()の順に早い。

q.switch文の一番最初に最もよくあるケースを持ってこよう。

r.正規表現によるXMLパースは、DOMまたはSAXを使うよりかなり早い。

s.メモリ使用量を減らすために、大きな配列などは用が済んだらunset()しよう。

t.派生クラス内のメソッドは親クラスで定義されるものより早いので、頻繁に使われるメソッドは派生クラス内に複製しよう。

【役に立たない最適化】

いくつかの最適化は役に立つけど、それ以外はそうでもない。
でもって、PHPは内部的に変わっていくから、それらは時代遅れになるだろうね。

以下に挙げるのはそういったものだよ。

a.echoはprintより早い
echoは返り値がない分printより早いと言われてる。でも僕がPHP4.3でベンチマークすると、
一部のスプリクトではprintのほうが早かった。

b.コメントを止めるとスピードアップする
PHP3時代の神話だね。

c.’var=’.$var は “var=$var” より早い
PHP4.2以前ではそうだけど、4.3以降で修正されたよ。若干オーバーヘッドが減る部分もあるけど、取るに足らないものだよ。

【参照渡しってスピードってどうよ?】

参照渡しにしたからスピードアップするってことはない。
以下のコードを見てみよう。


function TestRef(&$a)
{
$b = $a;
$c = $a;
}
$one = 1;
ProcessArrayRef($one);

以下は参照渡しをしない同様のコード。


function TestNoRef($a)
{
$b = $a;
$c = $a;
}
$one = 1;
ProcessArrayNoRef($one);

PHPは値を見落とした時に変数を複製したりはしないんだけど、内部的にカウントされる高速参照を行っている。
TestRef()では参照元を追跡しなきゃいけないので$bと$cは代入されるまでそれだけ時間がかかる。
この場合はTestNoRef()のほうが早い。

対照的に、配列やオブジェクトをパラメータとして持っている時は、参照渡しはパフォーマンスを向上させる。
これは、配列やオブジェクトはカウントされるような参照を行わないからなんだ。

次のコードを見てみよう。


function ObjRef(&$o)
{
$a =$o->name;
}

is faster than:

$function ObjRef($o)
{
$a = $o->name;
}

注:PHP5では、オブジェクトのパラメータは自動的に参照渡しになる。
パフォーマンスはかなり良くなってるはずだよ。

—–ココまで和訳—–

誤訳があってもかんべんしてにゅる。

実際に運用して遭遇した、Amazon EC2を使う上で極力避けるべきこと

春ですね。
そろそろ暖かくなってきたので、おっぱい出して外歩いてくれる美少女とか現れませんでしょうか。

さて、先月末の話ですが、人生三万日しかない[30thou]というwebサービスを公開しました。

一日が有意義だったかどうかを記録していくだけの単純な自己管理ツールですが、おかげさまで公開3週間で登録ユーザーは3000人を超え、現在も一日100人単位でユーザー数が増えています。

このサービスはAmazon EC2でホスティングしていますが、深夜12時以降にtwitterで自分宛にリプライして自己管理を促します。日中の稼動状況は穏やかなものですが、12時以降のピーク時に激しくアクセスが増加します。Microインスタンス1台のケチケチ設定で始めましたが、現在5台まで増やしてようやく安定稼動するようになりました。

サーバー構成としてはプロキシサーバ1台、webサーバ2台、DBサーバ2台(マスターとスレーブ、それぞれキャッシュサーバとcron処理も兼任)ですが、ピーク時の稼動状況を見るかぎりプロキシが次のボトルネックになりそうです。

ところで、Amazon EC2といえば独自の優れたオプションがありますね。
稼動状況を監視するAmazon CloudWatch、ロードバランサのElastic Load Balancing、負荷状況に応じて仮想サーバーを増減させるAuto Scalingなど。
私も当初は、負荷が増えてきたらこれらのオプションを使おうと思っていましたが、いざ使おうとした時に困ったことが起こりました。

事前の計画では、CloudWatchで稼動状況を監視、ピークタイムに負荷が増えたらサーバーがビジーになる前にAuto Scalingで仮想サーバーを増やし、Elastic Load Balancingでトラフィックを振り分ける・・・・という事を考えていましたが、

webサービスのurlにドメインそのもの(http://www.hoge.comのようなサブドメイン付きではなく、http://hoge.com)を使っていると、Elastic Load Balancingが利用できない

という事が判明しました。

しまったな・・・・と思いつつぐぐってみたら、モバツイが同じような事態に過去遭遇してましたね。アウアウ^q^

どういうことか具体的に説明しますと、

Elastic Load Balancingを使ってロードバランサを作成すると、Amazonからロードバランサのurlを割り当てられます。ロードバランサ自体は固定IPを持っていません。
このurlをDNSのCNAMEに登録するのですが、ドメインそのものにはIPしか登録できないので、現状のhttp://30thou.comというurlではElastic Load Balancingが使えません。

なんたるチーヤ。

CNAMEとかbind立てたことがある人はピンとくるでしょうが、簡単に説明すると、

DNSサーバーでホストとIPを紐付けする方法にはAレコードとCNAMEレコードがあり、AレコードにはIPアドレスを登録、CNAMEレコードにはホスト名やurlを登録できます。

Elastic Load Balancerでは固定IPではなくurlを割り振られるので、AレコードではなくCNAMEレコードにこれを登録するのですが、前述のとおりドメインそのものにはIPしか割り当てることができません(AレコードでIP指定したホストを割り当てることはできるのかな?)。

まあ、Amazon EC2の関連図書を見れば『Elastic Load BalancingはCNAMEにurlを割り当てて使う』旨が書いてありますし、頭のいい人はそれだけ読めば気付くんでしょうが、残念ながら私は気付きませんでした。くぎゅううううううううううううう。

www付きのurlに変更すれば利用できますが今更なのでこのまま行こうと思います。

EC2にTokyo Regionが出来たことや安価なMicroインスタンスがある事で今後Amazon EC2を使い始める人が増えるでしょうが、どうぞ私と同じ轍を踏まないようご注意ください。

【今日の教訓】
Amazon EC2の機能をフルで使いたければ、サービスのurlは必ずwww.等のホスト名をつけましょう。

『非モテタイムズ』の配信停止要望を大手メディアに送った報告とその全文

掲題の通り。
事の発端は、多くの方が知っているかと思います。

主婦兼ライターをされている@francesco3さんに対し、非モテタイムズ編集長である@meganeou氏が侮蔑発言を行いました。

一連の流れはコチラ 『Togetter – 「「francesco3氏」と「めがねおう氏」の炎上ツイートまとめ」』

なんというか、ひどい出来事ですね。

そしてこれら一連の出来事は、非モテタイムズ運営元である株式会社ホットココアが新サービスcloudnoteを公開するにあたり、注目を集めるため行った事柄だと私は考えています。
こちらの増田でも同じ意見が見られます。なおかつホットココア社長である@egachan自身が、『炎上マーケティングの第一人者』を自称しています

一連の事柄が、話題集めのために全く関係のない一般人に噛み付き、誹謗中傷を行ったとすればどう思いますか?

僕は素直に怖いと思いました。

何の脈絡もなく、ある日突然話題集めの為に罵詈雑言を投げかけられる、インターネットをそういう空間にしたくない、と思いました。

なので、非モテタイムズの配信先である大手メディアに、配信停止の要望を送りました。

まあ、私個人がメディアに要望送る程度の事ならわざわざブログに書かなくても良いんだけどさ。

twitterを見ていると、該当する加害者(ここでは@meganeouその他)に罵詈雑言を投げかけてる人が多かったので。
それはちょっとやり方が賢くないんじゃないかと。

twitterで直リプして文句を言っても問題は解決しません。
文句言ったらある程度気は晴れるかもしれないけど、その対象は相変わらず存在し続け誰かを傷付けて注目を集めようとするかもしれないのだから。

なので、ちょっと提案。

直リプで文句を言うのは辞めましょう。

代わりに、彼等が記事を配信しているメディアに自分の気持ちを正直に伝えたらどうでしょうか。

メディアの暴走、例えば人権を侵害したり法律を無視したりして人を傷付ける行為に対して、我々は抵抗する手段があります。

テレビにそのような行為があればBPOに訴える。新聞であれば買わない。
そしてネットメディアであれば、配信先に対して自分の考えを述べることです。

私はそう考えたので、配信先に配信停止の要望を送りました。

YahooとExciteとLivedoorに送ろうと思ったんだけど、Yahooはどうも個人からの要望等を受付けてないみたいなので後の二社に送りました。

Exciteお問い合わせフォーム
Livedoorご要望フォーム

Livedoorは文字数制限があったのでいろいろ削りました。

以下に全文を載せます。

『非モテタイムズ』配信停止のお願い

拝啓

いつもお世話になっております。
本日は、貴社にニュース記事を配信している株式会社ホットココア『非モテタイムズ』の配信停止要望をさせて頂きます。

株式会社ホットココア(以下『H社』とします)の編集長を務める@meganeou氏(http://twitter.com/meganeou)がライターをされている@francesco3氏(http://twitter.com/francesco3)に侮辱発言を投げかける事案がありました(参考:http://togetter.com/li/107425)。
前述の件を見る限り、H社が配信する『非モテタイムズ』は、ジャーナリスムが持つべき「責務ある取材姿勢」に著しく欠けるメディアであると考えます。
また、H社はニュースサイト以外のサービスも運営しており、サービス公開に先立って注目を集めるために無関係な方に罵詈雑言を投げかけ故意に炎上させている節もあります(参考:http://anond.hatelabo.jp/20110304162935)。
上記いずれの陳述も私個人の推測の域を出ませんが、H社の配信する『非モテタイムズ』は貴社の提供するコンテンツに相応しくないと私は考えます。
よって私は貴社に、H社の配信する『非モテタイムズ』の配信停止を要望いたします。

貴社の益々のご発展と皆様のご健勝をお祈りいたします。

敬具

参考URL:
http://togetter.com/li/107425
http://anond.hatelabo.jp/20110304170215
http://anond.hatelabo.jp/20110304162935

全文載せたけど、要望送る方はまるっきりコピペはやめてね。

それだとただのチェーンメールだし、一連の事柄を見て自分がどう感じたか、という事を率直に伝える事が重要だと思うので。

彼等にどういう意図があってこのような行為を行ったのか、実際のところ彼等自身にしか分からないものなので。

いずれにせよ、今後同様の事案が起こらないこと、かつこのような行為を行うメディアに対しては受け手がはっきり『No』を突きつける世の中になることを望みます。

「インターネットはけしからん」って言うおじさま達が多いけど、僕は「インターネットの自浄作用」というものも信じていますので。良い方向に進むといいなあ。

あー・・・・

まじめな文章書いてると疲れるね。

おっぱいもみたい。