  |
はてなキーワード: クローラとは
元増田だよ。
昨晩はまったく反応がなくて自演しようかヒヤヒヤした。けど寝た。
サイバーメガネさん拡散ありがとうございます。もっと頑張ってくれ。
Twitterでmentionが発生した瞬間に該当アカウントに鍵が掛かったのでおふとんの上でニヤニヤしてる。
もう片方のアカウントはそれでも元気に活動してるのでええ根性しとるな。
というサイトを使ってるよ。
先日「Web魚拓」が過去のアーカイブを検索する機能を「忘れられる権利」のために無効化するって言ってたけど増田は微妙だと思う。
増田は特定個人の悪行を未来永劫残すことを目的としてないので、各魚拓のURLを直接書いてクローラに教える気はない。
知りたい人が調べればいいだけの話なので。
調べたい人が調べられるが普通には気付かないまま残っている、というのが正しい姿なんじゃないかなー、と思った。
いろんな意見があると思うけど。
---------------------------------------------------------------------------
---------------------------------------------------------------------------
前回の続き
苦労の甲斐があってエロサイトのおおまかな枠組みはできてきた。
ここまできて僕は、どうやったらwebサイトとして機能するのだろう（ヤフーとかグーグルとかに載るんだろう）？
という疑問を持った。とゆうか最初にその疑問を持てという話でもあるが、とにかく僕は急にそう思い始めた。
とりあえず、キーワードはサイト名の「動画エロサイト」でお願いしまつっ！！！！
（期待に胸をふくらます僕）
「分からん」
先生またご冗談を。全知全能の先生がそんなはずないじゃないですか。
何百位でもかまわないですよ。まだ始めたばっかりですから。
それでは、先生、改めて僕のサイトの順位のご発表をお願いします！！
ドゥン！ドゥルルルルルルルルルルルルルルルルルルルルルルルルルゥ！！
「載っとらん」
Σ(っﾟДﾟ；)っ
検索エンジンは「クローラー」とか「スパイダー」と呼ばれるプログラムを使って、web上に存在するページの情報を集めるらしい。クローラーがウェブ上を自動的に巡回して集めたデータをデータベースといういわばデータの貯蔵庫のような所に登録する。
この事をインデックスする（される）などと呼ぶらしい。
なんだか僕の知らないところで、とんでもない事が起きている気がしてきた。
とにかく、サイトはこのインデックスというのをされていないと、Googleやヤフー（のちにヤフーはGoogleの検索エンジンを使っている事が判明）Bing、infoseekなどから検索する事ができない。
クローラが巡回にくるタイミングはまちまちで、すぐインデックスされる事もあれば、何カ月もされない場合があるらしい。
どうしてもインデックスされないのなら下記の原因を疑ってみた方がいい。
クローラーに発見されやすいサイト構成や、Googleウェブマスターツールへのサイト登録をして、
クロールされやすい記事、サイトから、クロールしてもらいたい記事へのリンクを張っていくことも重要です。
Googleウェブマスターツールへのサイト登録＆サイトマップ送信
などの改善を行なってください。
このガイドラインを見ると、Googleはどのような行為に対して不正とみなすのかを確認することができます。
Googleが提供するガイドラインに違反することで、ペナルティを受けてしまった場合には、最悪インデックス削除の可能性もあります。
インデックス削除はかなり重いペナルティであり、それが解除されるまでには時間がかかります。最悪の場合、悪質なサイトであると認定されてしまい、インデックスされないドメインとなる可能性もあります。ですから、Googleのガイドラインはしっかりと読み込んで、気をつけてサイト運営を行ないましょう。
この原因に関しては、かなりSEOの知識のある人でないと、そもそもクローラー制御タグや記述を利用する事がないので調べる必要はないと思いますが、一応書いておきます。
インデックスさせたい記事のmetaタグに以下の設定が入っていてはインデックスされなくなる。
noindex このページはクロールしても、インデックスはしない
nofollow このページはクロールしても、ページ内リンク先はクロールしない
インデックスさせたい記事へ外部からリンクを送る場合において、nofollowをmetaタグ内に記述しているとインデックスされにくくなる。
以上の点について、改善していきましょう。
インデックスはクローラーにクロールされやすいサイトを作成し、
リンクを用いて露出を増やし、Googleのガイドラインに違反しないよう気を付ける
う～ん。なるほど。ここら辺はかなり重要だなあ
htmlを勉強したときにメタタグの事は調べたので、もう一度確認したらすんなり頭に入った。
あとは、ウェブマスターツールなるものに登録して、「サイトマップ」ていう単語も出てきたから
これも後で調べよう。
よしもう一度僕のサイトを確認してみよう(^-^)p
つづく
Rails3 と jQuery で、真面目にオシャレなエロサイトをつくってみました。 - h300
http://d.hatena.ne.jp/inouetakuya/20120331/1333192327
に触発されて、オシャレエロサイトを作ってみました。
オシャレエロサイトを作ろうと思ったのはいいのですが、デザインは苦手なので途方に暮れていました。
h300の方はペパボのソフトウェアエンジニアらしいのですが、こっちはただの素人プログラマー。
そこで何か裏ワザみたいなものはないかとググっていると、Twitter Bootstrapという文字が目にとまりました。
Bootstrapの名前は知っていましたが、深い内容までは知りませんでした。
ですが、紹介記事を読んでみると自分の理想に近かったので早速使ってみることにしました。
Twitter Bootstrapはある程度有名だと思うんですが知らない方のために説明すると、
CSSフレームワークの一つで、ウェブデザインの作成を手助けしてくれるものです。
色々なCSSフレームワークを見ましたがTwitter Bootstrapが一番完成度が高いと感じました。
ウィキを見ると最初のリリースが2011年8月なので比較的最近のものですね。
普段、みなさんがウェブサイトを作る時、HTML + CSSで作られるかなと思うんですよね。
この時、CSSが事前に用意されているとすごく楽じゃないですか？
CSSフレームワークはCSSの大部分を前もって用意してくれているんですよ。（フレームワークによりますが）
ですので基本的にCSSに合わせてHTMLを記述するだけでウェブサイトが出来てしまいます。
CSSに合わせてHTMLを記述するとはどういうことでしょうか？
この文章は薄い青色でハイライトされていますよね？ Bootstrapで似たようなことをする場合 ＜div class="well"＞ ハイライトしたい文章 ＜/div＞ という感じになります。
classにwellと指定しているだけですね。
なぜそうするだけで文章がハイライトされるかというと、
divのclassにwellが付いていたら、いい感じでハイライトしてねっていう指示が
Twitter BootstrapのCSSに書いてあるからです。
BootstrapのCSSには、divのclassにalert alert-errorっていうのがあったら警告文だしてねとか、
button class="btn"ってあったらボタン表示させてねとか色んなことが最初から書いてくれています。
もちろん見栄えがよくなるように記述されていますので、classを指定するだけでモダンなデザインになるわけですよ。
CSSに合わせてHTMLを記述するだけでウェブサイトが出来るというのはこういうことです。
でも、最近のウェブサイトは HTML + CSS + JQueryという場合も多いですよね。
安心してください。Twitter Bootstrapの場合はJQueryの基本的な部分も用意してくれています。
ですのでドロップダウンメニューやタブ、スライドショーなどの実装も簡単にできます。
それに加えてBootstrapはよく使うアイコン数百種類まで用意してくれています。
至れり尽くせりですよ。
神様ですね。
CSSが固定化されていると、HTMLも自動的に固定化されます。
CSSに合わせて記述するので当たり前といえば当たり前ですね。
CSSの記述は一定、HTMLもある程度一定なので、メンテナンスが格段にやりやすくなります。
個人プログラマーの方だと、サイトごとにHTMLもCSSもグチャグチャという方も多いのではないでしょうか？
フレームワークを使えばそういうこともなくなるということです。
Twitter Bootstrapの凄さはそれだけではありません。
現在、ユーザーがどんなデバイスでウェブサイトにアクセスしてくるか分かりません。
PC、スマートフォン、iPad、TV、3dsなど全てのデバイスに合わせてデザインを作るのは時間がかかりすぎます。
でもTwitter Bootstrapならbootstrap-responsive.cssというCSSを選ぶだけで、
デバイスの横幅に合わせてデザインが変わるレスポンシブなウェブサイトができます。
もちろんデメリットもありまして、サイトのデザインが似てしまうというのが難点です。
ですが基本はBootstrapを使って、ちょっと自分でカスタマイズしてオリジナルっぽくすることもできますので、
一度Twitter Bootstrapを使ってみる価値はあると思います。
http://twitter.github.com/bootstrap/
Bootstrapの説明が長くなってしまいましたね…。
1.エロいサイトを巡って、XVIDEOSやFC2動画などのリンク、embedされたものがあれば取得。
3.データベースに登録。
一連の作業をクローラーにやらせるプログラムをRubyで書く。
RailsでBootstrapを使うにはtwitter bootstrap railsというgemを使うらしいです。
しかし、使おうと思ったのですが、windowsでは上手くインストールできませんでした。
仕方なく、代わりにsass-rails-bootstrapというものを使いました。
違いはcssにLESSをつかっているかsass（scss）を使用しているかだと思います。
http://d.hatena.ne.jp/tkawa/20120219/p1
の記事が参考になりました。
ちなみにLESSとかSassってのはcssを効率的に書けるすぐれたものです。
最近、webクリエイターボックスさんでも紹介されていました。
http://www.webcreatorbox.com/tech/css-sass/
railsでは3.1からcoffee scriptと共にsassがデフォルトで使えます。
このあたりがRailsの素晴らしさですね。
Bootstrapは画像を綺麗に並べて表示することにも向いているので、
アダルトサイトと相性がいいなと感じました。
AV女優名とか女子校生、人妻などのジャンルのタグがあれば便利ですよね。
Railsではacts-as-taggable-onというgemを使い実装しました。
動画のタイトルが事前に用意したAV女優名リスト、ジャンルリストと合致すればタグ付けするという感じです。
AV女優リストはDMMから、ジャンルリストは大手アダルトサイトから作成しました。
タグ付けするときに あおいそら-蒼井そら みたいな感じでタグ付けするようにしました。
もっとスマートな方法があるはずですが思いつかなかったので仕方ないです。
ア行、カ行…のように行別にわけて、なおかつアイウエオ順で表記してますので
クッキーを使ってログイン不要のブックマーク機能を作りました。
jquery.cookie.jsを使って、cookieを配列に直してごにょごにょしてという感じで実装しました。
削除ボタンを押すと非同期で通信して…などいろいろ面倒でした。
でも、動画の数はかなり増やしていこうと思っていましたので頑張って実装しました。
動画の下のブックマークするボタンを押していただければブックマークできます。
ブックマークするボタンの表示などにBootstrapの便利さを感じました。
実はこれが一番やりたいことでした。
多くのアダルトサイトは広告だらけで、肝心の動画がポツンと小さくあるだけというのが多いです。
戦場で疲れた兵士たちに、そんなせせこましい画面でアダルト動画見ろって？
そんな野暮なこと言いませんよ。
PCスクリーンの画面いっぱいに、大画面で、ドカーンとエロ動画を楽しんで下さいよ。
動画はできるだけ大きく表示しています。もちろんレスポンシブです。
全画面表示にすりゃいいじゃん…っていうのは違うんですよ。
全画面表示だと逃げれないじゃないですか！
不意に誰かが部屋に入ってきたらどうするんですか？
そう考えております。
Bootstrapでデザイン面はスマホ対応にはなっているのですが、
加えてjpmobileというh300で紹介されていたgemを使って、
CPU 2.66GHz、メモリ 2.2GB HDD200GBです。
Railsは遅いので少しでも速くするためにApacheの代わりにNginx使おうと思ったのですが、
PC用のキャッシュとスマホ用のキャッシュを別々に保存して使う
ということがどうしてもできませんでした。
PC用のキャッシュがある場合、スマホ用のキャッシュがなくてもキャッシュがあると認識されるなど、
もともとNginxとrailsのページキャッシュは相性が悪いようです。
Nginx側でキャッシュする、もしくはスマホ用のアドレスを別にすればできるかもしれないですが、
http://m.サイト名 みたいにするのが嫌だったので最終的にNginxを使うことをやめました。
Nginxに関するネット上の記述も少ないので運用するのは危険かな、ということもあります。
Nginxを少しだけ使ってみた感触はかなり速いというものだったので残念でした。
バージョンが変われば、また挑戦したいですね。
【追記】
やっぱNginxでもいけるかもしれないですね。
紹介しないと終わらないということで紹介します。
http://nukisen.com （エロ注意）
サイト名はオシャレに横文字でNukisenにしました。読み方はヌキセンです。
http://bootswatch.com でダウンロードできるBootstrapのテーマそのままですが、
Bootstrapを使うと自動的に細部まで凝ったデザインになるので最高ですね。
下にスクロールしていくと背景のグラデーションが変化したりとか、とても一人ではできないですよね。
長々と説明してきましたが、
ぜひNukisenで大画面のアダルト動画を体感してほしいです。
しばらくは一日30本ぐらいの更新でいく予定です。
アダルトサイト同士の相互リンクでアクセス増やしてなどはしない方向です。
新しいことに挑戦すると得られるものが多いなと感じました。
ウェブサイトを作る際、無意識のうちに自分のできる範囲の技術で構築しがちだと思うんですが、
そうすると成長はないですね。
長文失礼しました。
http://d.hatena.ne.jp/nishiohirokazu/20120323/1332504404
最近、Webクローラクライアントを作るお仕事が増えた。WebクローラクライアントというのはHTTP(S)を介して様々なファイルをダウンロードして解析し、結果を溜め込むだけのプログラムである。ボットともいう。
クローリングの規模が大きくなると、クロール処理部と結果貯蓄部を分離する必要がある。クローラには様々なものがあるが、ものによっては特定のサーバに集中的にクローリングを行うこともある。このとき、1つのIPを使って集中的にクローリングを行うと、攻撃とみなされ一瞬でbanされてしまう。そこで、一見するとまったく関係なさそうなIPを複数確保し、それぞれにクローラーを仕掛けて走らせるのである。
結果貯蓄部は、要するにデータベースサーバであり、何を使用しても良い。クロール処理部とのやりとりに使用するプロトコルはRDB依存プロトコル(MySQL Socketとか)でもHTTPでもなんでもいいが、とにかくクロール処理部が解析した結果を随時溜め込めるようにしなければいけない。逆に言うと、まぁ、口さえできるのであれば何を使用しても良い。
問題は、クロール処理部に何を使用するかである。おおまかな要件は次の通りである。
これらの要件を満たそうとすると、ぶっちゃけJavaかPythonくらいしか選択肢が無い。
| Java | Python | |
|---|---|---|
| HTTP(S) | HttpURLConnectionかApache HTTP Client | urllibかurllib2 |
| 環境依存性 | Write once, run anywhere (VMが最初からインストールされてるのはSolarisくらいのものだが、どんなOSでも大体はすぐインストールできる) | UNIXであればほぼ標準で入ってる、Windows用インストーラも用意されている |
| キャッシュ機能 | JDK6にDerby標準搭載 | Python 2.5からsqlite3標準搭載 |
JavaとPythonの違いは山ほどあるが、簡単なことをやらせるだけならPythonはJavaよりも使用メモリが少なくなりがちなので、そういう場面であればPythonは(現時点においては)最強の座に君臨すると考えられる。
「ステログ」って、今回問題になったＰＲ会社による火消しステマなんじゃないだろうか。
というのは、ステログは、「レビュー数が少なくて、高得点をつけてる人」をあぶり出してるんだけど、食べログもさすがにそんな作戦にはとっくに対処していて、そういう場合は点数が上がらないように、もともと作られてるんだよね。つまり「ステログ」であぶりだせるのは、素人による「自作自演」だけなんだ。プロモーション会社が有料で引き受けて、巧妙に点数を上げてるような事例、つまりレビューを数多く投稿していて点数に大きな影響を持つユーザを事前にじっくり作っておいて、そのユーザに高得点をつけさせるような作戦は、華麗にスルーされてしまうんだ。
もちろん、そこまで悪意なくておもしろ半分にやってるだけかもしれないけど、一番注意した方がいいのは「ガチヤラセ？？」って赤文字だけ見て喜んでる人ね。それ、ステマに騙されてる可能性は高いと思います。
そもそも。
「食べログ」って、レビューを書き込んだユーザーの「レビュー書き込み数」とかを単純に返すAPIとかないので、「ステログ」の会社は、自社製のクローラでデータ収集してるんだろう。ま、それは別に悪いことじゃないんだけど、そんなクローラまで作ってる会社が、食べログの採点の仕組みの基本を知らないってのは腑に落ちない。
Webシステムとは縁遠い事務職のリーマンが、ある日思い立って、ニッチな用途の検索エンジンサービスを作ってみたので、ちょっと書いてみようと思います。
ちなみに、検索エンジンといっても、googleカスタム検索とかのお茶濁し系じゃなくて、apache Solrというオープンソース検索エンジンを、VPS上で動かしているという、それなりに本
気度の高いものです。
なんで素人がそんな物騒なものを動かす羽目になったかは、後述。
やりたい構想みたいなことを思いついたのは、もう6、7年前ほど前のこと。初めて独り暮らしを始めたときに、ひどく不便を感じたことがあり、こんなサービスがあったら便利だなあ、
ちなみにその妄想をふと高校の同期に話したとき、そのサービスはどこにあるのか？！と、えらくがっつかれたのを、覚えてます。まあ、俺と同じく偏執狂の奴だったからだと思います
が。
ただ、しがない事務職リーマンということもあり、当然、技術も無く、そのときは、やるならこんな名前のサービス名だろうなあ、とか、そんな妄想レベルで、話は終わっていました。
そんな感じで、5年ほど月日は経ち、なんとなくリーマン人生の流れも見えてきたところで、以前、妄想していたことを、ふと思い出しました。
5年も経ったら、さすがに自分が考えたようなこと、誰かがやっているだろうと調べてみたところ、意外なことに、競合になるようなサービスは存在せず。ちょうど異動があって、少し時
間が出来たこともあり、じゃあ、着手してみようかと思い立ちました。
やりたいことは、大手サイトの情報検索。ただ、商品ページ内の特定情報、それも、商品ごとに正規化されていない表記を、正規化して抽出する必要があったので、大手サイトの既設API
だけではとても実現不可能でした。
まあ、だからこそ、5年間、誰もやろうとしなかったんでしょうが。
ということで、とても一発では解決できなさそうな内容だったので、自分でなんとか実現できそうな機能に細分化して、各個撃破していくことにしました。
随分と考えた結果、
以上に区分できると考えて、これらを各個撃破していくこととしました。
また、技術もなく、プログラミングも出来ず、ましてやlinuxサーバのお守りをしたことなんて当然ないので、インターネット上に置くサーバですべての処理を完結させるのではなく、イ
ンターネット上に置くリソースは最小限に留め、できる限り、勝手がわかる自宅のwindowsパソコンで処理を行うことにしました。
ちなみにさらっと結論だけ書いてますが、ここまで至るまでに、いろいろと調べ続たり、考え込んだりしていたので、思い立ってから3ヵ月は掛かってます。。。
さて、やる方針を決めたあと、はじめに着手したのは、要の検索エンジンサーバです。
いろいろとググって調べて、mySQLというやつか、apache Solrというやつかに絞りましたが、結局、Solrを使うことにしました。
MySQLのほうが実績は多そうだったのですが、Solrのほうが検索専門で、滅茶苦茶動作が速いらしいということ、MySQLでも出来るが特に速度が遅いらしい全文検索機能も使いたかったこ
と、あとファセット機能がジャンル絞りこみに便利に使えそうだったので、というのが理由です。
ちょうどSolr本が発売されていたこともあり、それを参考に、自分が使うように設定ファイルを変更していきました。
しかし、初めは設定ファイルの内容も意味不明な上に、私の書き方も雑なのか、少しいじっただけでまったく動かなくなる。結局、設定ファイルを一文字ずつ変更しては動作検証、とい
った始末で、進捗は地を這うよう。ある程度思い通りにSolrを扱えるようになるまで、3ヵ月以上掛かったでしょうか。。。
さらに、検索エンジンのフロントエンド（Solrの検索結果を、htmlに変換するプログラム）も書かなければならない。プログラミングが出来ない人間には、これが本当に辛かった。
Solr本に、いろんなプログラミング言語でサンプルがあったのですが、迷った末に、わずか数行なら書いた（≒コピペした）経験があるという理由で、javascriptを苦渋の選択。
しかし、選択はしてみたが、基礎が本当に無いから内容がサッパリ頭に入ってこない。こちらも、わかるところから本当に1文字ずつ変えていくといった手探り状態。
プログラミングについては、今回のためだけだから、といった理由で、一切基礎をやらずに着手したのが裏目に出たのか、サンプルのソースをモノにして、書き上げるのに、ゆうに半年
以上。本当に時間が掛かりました。
さらに、Solr周りで計9ヶ月間ハマっていた頃、忘れもしない、kanzen21のおっさんが彗星のように現れて、衝撃を受けることになります。
大手サイトのページをクロールして検索エンジンを作る手法は、私と考えていた構想の枠組みとまさに「完全に一致」な訳で。。。
図書館事件に注目していたのも同じで、あまりの一致具合に衝撃を受けっぱなしでした。
その後の成り行き等も含めて、興味深く観察させて頂き、本当に参考になりました。
そんな感じで紆余曲折もありましたが、ようやく難題だった、プログラミング関連に目処が立ってきたので、あとはクローラと肝心のデータ処理です。ここからは、勝手知ったるwindows
まず、クローラですが、専用のクローラをwindows用に探してきたり、それを設定するのも大変なので、今回はテレホーダイ時代に使っていたような、フリーのweb巡回ソフトを利用する
こととしました。指定のhtmlをダウンロードしてくるだけなので、別に変に新しいものに手を出す必要もないので。
また、ダウンロードしてきたhtmlファイルについては、これまたフリーの日本語処理ツールでcsv方式に加工することにして、処理ルール部分を相当に作り込みました。
このあたりは、全体を通して見てもキモの部分なんですが、ある意味、ちょっとしたパズル感覚だったので、プログラミング言語の部分と違って、かなり楽しかったです。
あとは、msdosのバッチファイル（これは前から知っていた）で、これらの処理を繋ぎ、cygwinのcurlとかいうツールで、連続して検索エンジンサーバにcsvファイルをアップロードする
仕組みを作りました。
検索エンジンサーバには、容量は少ないが、安くて高性能という、今回の用途にピッタリだった、さくらのVPSを借りて設定。CentOSのサーバ構築ホームページを見ながら、サーバとか
Solr管理URLとかにセキュリティを掛けて、こちらも素人ながら、意外とすんなり設定。
ホームページは、vpsサーバに相乗りさせるのではなく、別にさくらのレンタルサーバを借りました。apacheの設定方法等を習得する必要がありませんし、vpsのリソースをapacheと分け
合う必要が無くなるので。ホームページのhtmlファイル、cssファイル等も調べながら設定し、画像も準備しました。
あと、構想を思いついたときに妄想していたサービス名の.comドメインは、すでに他者に取得されていたのですが、どうも使っている風にも見えなかったので、whoisで出てきたメールア
ドレスに連絡して交渉し、幾ばくか払って買い取りました。
結局、足かけ18か月。ようやく完成。
楽天市場の家具を、幅x奥行x高さ(家具サイズ)で検索できる、楽天市場・家具カテゴリ専門の検索エンジン
この商品数規模（データ収録約30万アイテム）で、1センチ単位で家具のサイズ指定検索が可能な手段は、商用サービスも含めて、ほかには存在しないと思います。
kanzen21と違って、エロじゃないから華はないけどね。。。
ちなみに冒頭で少し書いたきっかけですが、就職して独り暮らしを開始したときに、新しい家にピッタリサイズの家具が欲しかったのですが、これが楽天で探すのは至難の技でして。
楽天で家具を探してみようと思った人には判っていただけると思うのですが、楽天では、価格では範囲指定やソートができても、サイズでは検索出来ないんです。
これは、楽天では、商品のサイズ情報は商品の自由記述欄に記載することになっているためで、商品ごとにサイズの記載方法がバラバラのため、検索が事実上、不能となっています。
家電製品とかに関しては、種類が少ないこともあり、メーカーのホームページとかでサイズを確認した上で、商品型番で検索すればいいので、それほど問題にはならないのですが、家具
って、種類が非常に多く、型番もあったり無かったりで、家電のようにサイズを調べることができません。
・・・ということで、カグサイズでは、楽天の商品ページにいろいろな書式で書かれているサイズ情報を拾って解析して正規化し、範囲指定やソートして検索ができるようにしています
。
また、単に寸法サイズを拾うだけでは、梱包サイズとか引き出し内寸とかも引っ掛かってしまうので、それらは出来るだけ排除して、商品の外寸が優先して引っ掛かるよう、アルゴリズ
ムを調整しています。
単位（センチとミリ）に関しても、商品ごとにバラバラ（単に単位だけでなく、商品説明のどこに"センチ"とか"ミリ"と記載しているかについてもバラバラです。）なので、サイズ表記
の前後の状況をみて、正しいと思われる単位で拾うようにしています。
あと、変わった使い方としては、欲しい家具の価格比較みたいなこともできます。
家具は、同じ商品でも、店ごとに型番が違ったりすることがよくあり、簡単には価格の比較が行いづらいジャンルの商品です。
しかし、型番は違っても、同じ商品なら原則、サイズは同じですから、欲しい商品とまったく同じサイズで検索をかけると、同等商品があるのかどうか比較しやすい・・・といった使い
方もできます。
と、そんな感じで、しがない事務職リーマンが作ってみた、ニッチな用途の検索webサービスを、サービスインさせて頂きました。
一般に公開されていて、誰でもアクセスできる情報でも、ニーズが有りそうな切り口の条件で検索性を高めれば、新しい価値を創造できるんじゃないかという実験です。
もしよろしければ、ぜひ、使ってみてくださいー。それでは！
----------
Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります。
ブコメには「Googleが勝手に盗んだのにこっちがオプトアウトしなきゃいかんとは何事だ」というものが多いが、それらは問題を根本的に誤解している。
(もしかすると総務省、ストリートビュー車の無線LAN傍受でGoogleに指導。再発防止策と日本語で周知を要求 -- Engadget Japaneseの件と混同している人がいるのかもしれない。これはビーコン信号ではなく通信内容そのものを傍受していたという話で、基本的には別件である――但し、法解釈によっては同じ問題ともなり得るし、根底に共通している部分はある。これは論点がズレるので、ここでは完全に別件として扱う)
そもそもの問題は、Wi-Fiの仕様において、Wi-Fi機器のMACアドレスが強制タレ流しになっていることにある。これは例えばSSIDステルスの設定でも止めることはできない。
つまり、あくまでGoogleは垂れ流されている情報を集めたに過ぎないということである。垂れ流されているものなら勝手に集めてもいいのかという論点はあり得るが、その点についてはGoogleだけを責めても全く意味がない。誰であれ収集は可能だからだ。「しかし、他の誰がそんなことをするのか？」との反駁には「はい、PlaceEngineがしています」が答えになる。仕組みは全く同じだ。PlaceEngineは、Googleのような巨大企業でなくてもこの技術を商用レベルにまで持って行けるということを既に証明している。
つまり、この問題は「GoogleのDBから削除してもらう」だけでは全く解決しない。
(追記: どうもこの節の表現は誤解を招いたようだ。「できるからやってもいい、Googleは悪くない」という意味ではない。その議論があること、今後も必要なことは承知の上で、そもそも「できる」こと自体が根本的な問題であり、しかも各国の現行法において確実に違法な行為ではないということが重要だ。何度でも言うが、Googleを憎んでも問題は全く解決しない。あくまでここでは問題の本質を理解することと、現実的で効果的な解決方法について考えたい――もちろん、GoogleやAppleやMSなどを相手取って世界中で訴訟を起こす、というのも一つの手だろう。今のところ強制力を持ちたいなら勝訴の判例を作るしかないし、勝訴すれば抑止力を備えた最強の解決手段になる。どうぞ。)
(a) 「申し出のあったMACアドレスは削除し、今後も登録しないようにする」という対応
技術的にはすぐにでも対応可能。ただし、本人以外の手によって無差別に大量のアクセスポイントを削除するという妨害行為を防止できないかもしれない。
PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して、そのような手段が用意されていることを周知しなくては問題は解決したといえず、十分な周知は困難と思われる。
新たなアクセスポイントを購入するごとに削除手続きをする必要があることについて納得しない者が、「私のものは登録するな」という主張で争ってきたら対応できない。
(b) 「SSIDステルス設定にしているアクセスポイントは、登録拒否の意思があるとみなして、登録しない仕組みとし、また、既に登録されているものは次回検出時に自動的に削除されるようにする」という対応
技術的には容易に可能。しかし、そのような仕様であることを周知しなくてはならない。PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して周知しなくては問題は解決したといえない。
(c) 「暗号化設定されているアクセスポイントは登録せず、他は削除する」という対応
暗号化していないアクセスポイントは特定の相手方に対してのものではないとみなすことで、電波法59条の問題をクリアできるかもしれない。
しかし、これを採用すると登録アクセスポイント数が減ってしまい、位置の測定制度が低下する。
(d) 所有者の同意を得たアクセスポイントしか登録せず、他は削除する」という対応
まず、ブコメで要求されているような「オプトイン」の仕組みは(d)だが、これは実現性に乏しいと考えられる。どうやってオプトインするんだという問題もあるわけだが、そもそも「誰でも収集できる」のだから、個別にオプトインなど根本的に不可能であるし、無意味でもある。例えGoogleが独自にオプトイン方法を用意したとしても本質的な問題は全く解決しないばかりか、ユーザに「Googleでオプトインしなければ安心」という誤解を与えかねないという懸念もある。
(b)や(c)についてはサービスプロバイダ側の設計の問題であり、ユーザは関与することができない。
今回Googleが提案した方法は、(a)の改良型(あるいは(a)～(c)のハイブリッド)というべきものである。再掲。
Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります。
オプトアウトという意味では、(b)のSSIDステルス法も同様である。それよりも_nomapが優れているのは、これが「うちのAPをマッピングしないでくれ」という明確な意思表示となるからだ。
SSIDステルスや暗号化をオプトアウトフラグとして扱うかどうかは単に実装に期待するしかないが、_nomapがデファクトになれば、万一オプトアウトが実装されずにマッピングされた際「俺は一般的に合意されている方法でマッピング拒否の意思表示をしていたぞ！」と法的に主張できる可能性がある。Wi-Fiの規格に変更を加えるものでもなく、この用途以外に意味を持たないことから、デファクトとして広まりやすいだろう。確かにSSID変更が困難なケースは考え得るが、しかしこれ以上に簡単な代案は私には考えられない。
解決しない。
ここに挙げたどの方法を採ろうとも、原理的に「サービスプロバイダのマナー」程度にしかなりようがないからだ。オプトインですら、である。robots.txtを無視するクローラを根絶することができないことにも似ている。そしてそれは、Googleの責任ではないし、Googleに責を負わせても全く意味がない。
最初に述べた通り、そもそもの問題は「Wi-Fi機器がMACアドレスをタレ流しにしている」ことであり、これはWi-Fiの仕様改訂で対応しないとどうしようもない。また、対応したとして、新方式へ完全に置き換わるまでには気が遠くなるほどの長い時間が必要だろう。WEPすら未だに根絶できないというのに。
また、Wi-FiはMACアドレスをタレ流しているぞ、これは防げないぞ、という啓蒙ももっと必要だろう。一般ユーザには何のことやらさっぱりわからないと思うが、それでも啓蒙しないよりはマシである。
一つ付け加えるなら、個人的には、デファクトとなり得るオプトアウト方法を提示したGoogleさんはもうちょっと褒められてもいいと思う。これはAppleやPlaceEngineが今までしてこなかったことだ。
ちなみに、Google Location Serverでは既に「2つ以上のMACアドレスがDBとマッチしないと位置情報を返さない」などの様々な対策を実施済のようである。これにより、もしMACアドレスやSSIDが漏れたとしても、その所在地をこんな方法で正確に掴むことは困難になっている。PlaceEngineは知らない。
もう一つ。この問題は、Wi-Fiだけに起こりうる問題ではない。ひろみちゅ先生は本来この問題をRFIDの普及によって起こりうる問題として予測していたそうである。この辺りもっと知りたい方はgoogle:高木浩光 PlaceEngineとかして勝手に読んでください。
PlaceEngineより、Googleの提唱する_nomap方式のオプトアウトに準拠する旨のリリースが出た。
PlaceEngineデータベースにおける無線LANアクセスポイント(AP)情報の取り扱いについて
Google社から、Google Location Service のWi-Fi位置情報データベースから無線LANアクセスポイント情報を削除するためのオプトアウト方法（SSIDに"_nomap"文字列を追記する方法）が公開されました。
PlaceEngine サービスにおいても、Google社のオプトアウト方法に準拠する形でPlaceEngine位置推定データベースから該当するAP情報を削除する運用を実施する予定です。具体的な実施時期や運用方法については、別途お知らせします。
また、PlaceEngineサービスにおいては、以前より、主にモバイルルーターなどに対応するため、オプトアウト(削除)したいMACアドレスをサポート窓口へ送付して頂く方法などをとっておりましたが、こちらについても引き続き運用していきます。（「位置推定の改善」をご参照ください）
これこそがまさにGoogleの狙った効果だ。素早くデファクトになり得る。すると次の段階として、Wi-Fi機器の製造者が設定画面に「☑位置情報サービスからオプトアウトする(SSID末尾に_nomapを付加する)」のような項目を用意することが標準化する、などといった流れに進むことも期待できそうだ。これには一層の啓蒙活動が必要になるが、十分に現実的な範囲だ。
そして、「Wi-Fiだけの問題ではない」と書いた通り、あっさり同種の別問題が持ち上がってきた。今後、この手の問題はゴロゴロ出てくるだろう。そもそもどこまでが許される範囲でどこからが許されないのかといった大枠の議論も含め、どんどん問題にして世界中で合意やルールを形成してゆく必要がある。先は長い。
http://dso.2ch.net/test/read.cgi/sakhalin/1319173391/
2 ： ◆G3E3Ee8IMBFg-隠居♪ (WiMAX)：2011/10/21(金) 14:26:26.78 発信元:49.134.166.55 0
まずは、こんなのを作ってみようと思う。
1. スレ立てる。 スレタイに #abcd と入れると、 「 #abcd を暖かく見守る」
2. Twitter をリッスンして、#abcd がなんかつぶやいたら、自動的にそのスレに書き込む。
3. あとは普通のスレ。(スレに書き込むだけで#abcdへのtwitになんてできる?)
40 ： ◆G3E3Ee8IMBFg-隠居♪ (WiMAX)：2011/10/21(金) 17:48:05.69 発信元:49.134.166.55 0
できた
これで nida_run をフォローした。
そしたら nida_run が何かつぶやくと
ehenfoxにnida_runのつぶやきがでてくるようになった。
と同時に 私の geteew.cgi にも流れてくるようになった。
ここまで大成功。ﾉﾊｽﾞ
55 ： ◆G3E3Ee8IMBFg-隠居♪ (WiMAX)：2011/10/21(金) 19:21:29.22 発信元:49.134.166.55 0
こんなのを作るらしい。
#abcdってあるけどハッシュタグを追跡するんじゃなくて、@abcdというユーザーのツイートを転載するようにするらしい。
今の段階ではとりあえず@ehenfoxをブロックしておけば転載されないと思う。
Twitterはバカ発見機として活躍中だけど、発見後はせいぜいRTやTogetterやはてブで弄られるくらいで大して盛り上がらなかった。2chのネットウォッチ板にもTwitterヲチ総合スレはあるけど、あまりに対象が多すぎて拡散気味になり盛り上がることはあんまない。注目案件で個別スレが立つこともあるけどたまにだし、大物（大馬鹿？）案件だとニュー速→まとめブログで料理してもらえることもあるけど。
これからはTwitterで発見されたバカが、2chで個別にカジュアルに祭られるようになるのかなぁと思います。
ところでこれわざわざ対象をフォローしてhome timelineを取得してるみたいだけど、リスト使えばいいのにね。フォローだと上限とか制限きついし。
クローラのアカウント書いちゃってるけど隠して作り直してプライベートアカウントにして、リストも鍵かけておけば、ステルス転載システムが作れるなんて入れ知恵しちゃ駄目だよ。
馬渕教室、新生ホームサービス株式会社、日本eリモデルなどのSEOを担当していると思われる株式会社マイスタンダード（代表取締役 武智建樹）は、ブラックな企業らしいです。
日本のブラックハットSEO会社一覧に株式会社マイスタンダードが掲載されています。
インデックス削除URL タイトル サービス名称 会社名 代表者名 住所 備考 http://www.seo-rankup.com/otameshi.html 業界最安値！関連検索ワード削除１キーワード１万円 関連検索ワード削除 お試しプラン 株式会社マイスタンダード 武智建樹 大阪府大阪市淀川区西中島7-7-3-702
ブラックハットSEOとは、SEO（検索エンジン最適化）における用語で、悪質な（非倫理的な）手法を駆使して検索結果ページ（SERP）の上位に表示させる技術または施策のことである。
ブラックハットSEOの典型的な手法としては、ユーザーに気づかれないようにWebページ内にSEO目的のキーワードを大量に埋め込んだり、ユーザーがアクセスしてきた際にWebクローラが巡回したWebページとは異なるWebページを表示させるような仕組みを埋め込んだり、コメントスパムなどの強引な手法で大量のバックリンクを獲得しようとしたりする方法がある。検索エンジンの多くはこうした手法はポリシーに反するものとしており、通常は何らかのペナルティが課されるが、悪質なWebサイトと判断されず検索結果ページの上位に表示される場合がある。
http://www.sophia-it.com/content/%E3%83%96%E3%83%A9%E3%83%83%E3%82%AF%E3%83%8F%E3%83%83%E3%83%88SEO
疑問の一つ目、「MDISは不具合を認めるかどうかが大問題である」。これの根拠となっている点はいくつかあったかと思うのだけれども、
たしかに、MDIS自身「不具合」という表現で（できれば図書館も、多分無理だけど警察・検察も）認めてくれた方が社会への説明は楽だと思うけど、どの程度そうなのか？
（まともな技術者からは）「こんな実装は異常である」というのはいい。しかし…カーリルとNECの間でも類似の問題が起きている。そっちの実装は不明だが、今回の観点でいえばそれも「不具合」であった可能性が十分ある。MDISだけが「不具合」であることの表明を要求されてNECは問われない、というのはそれで本当に解決するのだろうか。NECでも見つかったのではという疑いがある、というのは、言い換えれば「実装のバリエーションはともかく、技術的に貧弱なサーバがある程度権威のある機関でも平気で公開されているような世の中である（他にもあるんじゃね？）」という話になりかねず、議論として「MELIL方式は例外中の例外だからそんなのを基準にクローラを考えるのはおかしい」という議論にたいして、少なくともその説得力を減じている気はするのだが。なぜNEC批判はこうも目立たないのか。いや、NECを批判したところで、「一定数貧弱サーバの存在する（と仮定すると）」現実は変わらない。この現実を肯定すると、技術者なら影響がわかるはずだ、未必の故意云々という理屈の後押しをしてしまわないのか（その理屈が正しい、と言う意味ではなく、少なくともそういう意見の説得力がまして支持者増えるのでは、と）、この点は「クローラ技術の萎縮」と関係ないのか、それに対してどうアクションすべきなのか、どうも向かう方向性が見えない。
疑問の二つ目、「警察はなぜサーバの不具合を調べなかったのか」。不具合という表現はともあれ、「（未必の故意なのではなく）本当にlibrahack氏がサーバの異常に気づいていたかどうか」を本人談を鵜呑みにせず（技術者なら今まで流れてきている情報だけで多分気づいていなかったのだろうと推測がつくが、警察としてはそれだけでは不十分という議論は成り立つ）、検証するためには、「サーバで何が起きていたのか」を調べてそのメカニズムを理解－－理解することが必須だったとは言わないまでも、理解していれば「やっぱりlibrahack氏が気づいていなかったのでは」という一定の状況証拠になるであろうことは理解できる。
しかし、「クローラのアクセスが非常識ならサーバに不具合がなくても業務妨害」なのだから、（本音か建前かは別として）未必の故意も含めて主張している相手（警察・検察）に「なぜサーバの異常を調べなかったのか」と質問しても「必要ない」と言われるのは当然だ（圧力として質問する意味がないと断言はしない）。それも含めて、警察に「なぜサーバの異常を調べなかったか」と質問して失敗した人は、そもそもそれを聞くことの意味を理解していたのだろうか、という疑問がそもそもあって、単に聞き方が悪かったという問題という風には思われないのだが。
どうも「警察はなぜサーバの不具合を調べなかったのか」と問うことにどのような意味があるのかについて、第三者を説得する目的という意味で十分な説明がなされていると思えるものを見かけないのだが、皆は疑問を感じないのだろうか？
私の疑問について分かりやすい説明をしてくれる人がいるなら、それは意味があるとおもうのだがどうだろう（お前が馬鹿だ、と批判するのは勝手だが、この問題の解決にはそんな煽りは多分役に立たない）。
これ、Twitterの話題の多さに対して触れてる人の少なさが際だってるよな。何か陰謀めいたものすら感じる。この件に触れた奴は何者かによって密かに抹殺されているんじゃないかとすら。
http://d.hatena.ne.jp/kazuhooku/20101012/1286901973
[メモ]TwitterやFacebookのURLには、なぜ#!が含まれるのか (SEOとAjaxのおいしい関係)
- Ajaxを使うためにはページ内リンク (hash fragment=URLの#以降) を使うのが一般的*1
- hash fragmentはサーバに送信されないから、JavaScript非対応のブラウザだと動作しない
そこで Google は、#! が含まれる URL を hash を含まないものに読み替える仕組みを提唱している。例えば「www.example.com/ajax.html#!key=value」のサーチエンジン用URLは「www.example.com/ajax.html?_escaped_fragment_=key=value」になる。
TwitterやFacebookはこの仕様に従うことで、Ajax な UI と SEO を同時に実現している、というわけ。ということを調べたなう。
参照: Getting Started - Making AJAX Applications Crawlable - Google Code
「アドレスの変更」という最も目に見えるポイントなのに、上記以外にまともにその理由を考察しているサイトが全然見あたらないってのが、情けないというかむかつくというか。
高木氏が「異常」と言っているのは、一番目の選択肢が変なURLだけになっていること。
でも決して「検索サイトが変な結果を意図的に表示させた」わけではない。
技術的にはやろうと思えばrobots.txtの記述を無視して収集できるし、
でもしない。robots.txtで「しないでください」と書いてあるから。
（昔は無視して収集する検索サイトはたまにあった。今は知らないけど）
http://takagi-hiromitsu.jp/diary/20101024.html#p01
高木氏はrobots.txtが修正されることにより、「検索サイトで正常に閲覧できる」ようになった、
と書いています。また、「/robots.txt によってすべてのクローラを排除していたため、図1の「ビフォー」のように異常な検索結果になっていた。 」とも。
検索サイトってそんなに偉いんでしょうかねぇ、と思っただけ。
※性的内容を含んでるのでお嫌いな方は読まないでください
アダルトサイトを巡回するのはまぁ一般的な成人男性なら経験はするだろうとは思うが、中にはプログラマ？なんだろうけど、岡崎図書館の時みたいに自分でクローラ作って
DBに登録して、あろうことかWeb上に公開、みたいなことをしちゃう人って結構いるんだな、と思う。
○気になったサイト
○多分パクられてるサイト
http://shane01.blog80.fc2.com/
後者はいわずと知れた「えろつべ」さん。キングコングの西野さんも御用達なんだっけ？で、気になったサイト。見てみると、なんというか・・・動画のURLはもちろんのこと、「掲載日付」「サムネイル画像」「ジャンルタグ」全部一緒。
リスク回避のためなのか自分用とか書いちゃってるけど、サイトの一番上に輝くソーシャルブックマークのロゴ。。。
そりゃさ、確かに広告が多いと見づらいさ？まとめて一気に片付けりゃ楽だろうさ？けど、ブログ運営してる人はそれなりに努力をして毎日更新してるんじゃねぇの？
そういう人達の努力を、どんくらい時間かけて作ったプログラムかわかんないけどさ、広告取っ払っちゃうんじゃゼロにしちゃうでしょうよ。
「これからも対応ブログ増やしていきまっす！」なんてゆっちゃってるこの人、早速2chでも宣伝してるし・・・
ま、もっと悪質なブログだのなんだのもいっぱい居ることはわかってるんだけどさー・・・
