はてなキーワード: スクレイピングとは
Pythonって、アフィリエイトで稼いでる系の人たちにとってはスクレイピング用の言語で、エンジニア寄りの人にとっては機械学習用の言語っていう偏ったイメージがついている気がする。
自分は2012年くらいに、みんながrubyだrailsだ言ってるときに「はじめての言語がPythonだとコードをきれいに書く癖がついていい」という話だけで勉強し始めたんだよね。当時は2系と3系が混在してるときでタイミングとしては好ましくなかったかも知れないけど、Python選んでよかったと思ってる。今ほどPython、Python言われるとは思ってなかったけど、純粋に書きやすいし、やりたいことは大抵できるし。
でも、だからこそ、スクレイピングならPythonだよ!みたいなブログとか見るとグッと来るんだよね。なんかもっと色々なことに使えるのに、それに終始しているのはなんかなぁ・・・
自分はエンジニアじゃないし、機械学習なんてノータッチだから、結局のとこと、スクレイピング、文字列操作、エクセル操作、あと種々の自動化くらいなもんだから偉そうなこという気はないんだけど、 https://employment.en-japan.com/engineerhub/entry/2018/05/18/110000 こういうのが3ヶ月に一回くらいはてブの上の方に上がってくるのを見るとげんなりする。もっとなんかないのかね。
これはLAN内で使っているだけの、しょっぱいエントリクラスのサーバ1台障害の話だ、価値のある話ではない。
とある国内最大級の某グループウェア Office(パッケージ版)を使っている。
この某グループウェアは、従業員の「その日のタイムカードの一覧」を見ることができない。
CSVでエクスポートすれば可能だが、営業マンは勤怠をガラケーのメールで報告する運用であるため、
スマホ支給しろ 一覧+タイムカード修正画面へのURLリンク付きで
総務課の人にスクレイピングしてあげていた。
↓大雑把にこんな感じ
#!/usr/bin/env perl use MY::Cybozu; my $cb = MY::Cybozu->new; $result = $cb->get_timecard( sprintf("%d.%.d%", $year, $month, $day) ); &send_mail( $result );
数年来やってきていたのだが、突然このスクレイピングでデータが取れなくなった。
僅かにPerlを書けるだけで、他の言語は将棋を指すようにしか書けない低能である、
ちょうど20日の月替りのタイミングだったので、スクリプトのミスでズレたのか?
或いは、タイムカードのHTMLはtable構造で「trの何番目が何日目」という原始的な処理の方でズレたか?
ほぼほぼデータを取れないのだが、たまに正常に取れたりもする。なんだこりゃ。
$mech->statusの結果はいつも200である。
print $mech->contentの結果は、HTMLが途中で途切れていた。
スクレイプ対象の前で途切れたので、値を取得できなくなっていたのだ。
同じ場所で途切れる事が多いが、若干の増減はあった。
手元のWindowsマシンに移植したところ、まったく問題ない。
どうやらスクリプトを動かしているLinux側の問題と思われる。
どういう現象なのか?
3WAYハンドシェイクはよく知られた話だが、正常な通信では、サーバから送られてきたパケットに対して
こちらは「ここまでのパケット受け取った」とACKを返し、最終的にサーバからのFINでこちらがRST返すのが見て取れた。
この異常をきたしたスクリプトでは、ある程度を過ぎると、こちらがACKを返す前にサーバからどんどんパケットが送られ、
なるほど、ステータスは200だけど、コンテンツは途切れているのだな。
でもスクリプトじゃなくて、ネットワーク制御しているOSが悪いっぽい?
となると深刻である。自動車に乗れても内燃機関の構造など把握していないのだ。
唯一、tcp_abort_on_overflowでそれっぽい挙動をしそうだと分かったが、この機能は使われていない。
詰まった。
お手上げだ。
でも分かった。
端末からNASのディレクトリへ、TAB補完しようとすると突如フリーズしたのだ。
某グループウェアへのスクレイピングとNASへのTAB補完だけが動かない。
故障だ。
1.3万円で買って7年目の某ProLiantサーバだから、寿命なのだろう。
オチはないけど、最初から故障を強く疑っても良かったではないのか、と自省する。
そのマシンでのみ失敗し、しかも失敗したりしなかったり(比にして7:3程度)、結果も毎回変わっていたのだから。
うーん無能。
よくある「完全放置!」「全自動更新!」「何もしなくても儲かる!」みたいなアフィがあるけど
おそらく、その1つである全自動更新のエログ作って一ヶ月近くたったからその結果を書く。
何かしら作品を作ったらQiitaとかにアウトプット上げるけど、内容が内容なのでここで。
URLは多少内定自慢できるくらいの会社に内定貰っているから伏せますね><@バレなさそうなら晒す
・仕組み
・お金の話
・技術的な話
・結論
仕組みは簡単、いくつかの既存のエロサイトにWebスクレイピングをかけてウチのエログでも全く同じ情報を配信する。
そんなエログに全く価値が無いと思われるが、既存のエロサイトと比べてウチのエログを使うメリットはいくつかある。
1. share-videosを使っているので削除されていても案外見れたりする。
3. エログ特有のアクセストレードを行っていない(コピペなのでそもそもアクトレサイトに申請出来ない)ため、色んなサイトを行き来せずにめっちゃ見やすい!
4. 「PageSpeed Insights スマホ 82 PC 93」「【GTmetrix】 PageSpeed Score 99 YSlow Score 87(CDN入れたら94)」平均読み込み4秒のエログの割に読み込みが早い
5. スクレイピングするエログは動画のクオリティが高いサイトに厳選しているため良いネタがすぐに見つかってずく抜ける。(自分でも毎日使ってる)
事実、友達に悪い点とかのフィードバックを頂戴とお願いしたが「特に悪い点は無い、、、むしろ使いやすい」と好評。セッション継続時間は平均4分でみんな動画をちゃんと見てるみたい^^
自慢はここら辺にして、アクセス結果とかサイト情報はざっくりを晒す。
2月の総アクセスはざっと2400くらいで、1日大体70〜100くらい。流入は検索からのアクセスが100%。
検索ワードはjk 個人撮影みたいなワードからが割と多い。記事の数は10000件くらい。
こんなものか?正直Web系ではあまり無いから何をいえば良いかわからない。GAで取っているからみたい値があれば追記で。
完全放置のコピペかつ検索からの流入100%で1ヶ月目にしてはじょうじょうかな?
鯖の無料枠で運営しているため向こう1年はタダで運営出来ますが、もっとアクセスを稼がないと厳しいです。(何せshare-videosしか収入がないから)
月極広告のお話が来たら安定するのですが、スクレイピングでこの程度であれば来ないでしよう。
CMSとしてWordpressを採用。理由はSEOとかプラグインで楽そうだから(事実楽)(KUSANAGIの存在を知っていれば使ってたのにと今更後悔)
WebスクレイピングはGolangを採用。理由は速いから。並列処理でもっと速いから。あと書きやすい。てか。。。普通に好き。。。><
速さを求める理由はFunction as a serviceでスクレイピングを実行しているから。Python使おうと思ったけど、実行時間の制限があるためある程度早くスクレイピングを終わらせなければならなかった。
鯖側で常駐かcronを使っても良かったけど、常駐はメモリ食べてパニックだし、cronは設定がめんどくさいから。FaaSだとWeb上で実行間隔を弄れて無料で最高。
詳しい内容はウチのサイトの強みだから言えないが、他のエログのURLをリストに貼るだけで勝手に取得し投稿する。神。
Webスクレイピングエログはおすすめしない。手動で毎日更新したほうがアクトレで確実に儲かる。
黒字化するのであれば現行の方法ではなく、全自動で日本中のエログ全てのから記事を取得してshare-videosに張り替えて投稿するサイトかな。
アプリストアにあるのはTDR公式サイトをスクレイピングしている非公式アプリだ。(海外パーク用のは米ディズニーが公式で用意してる)
ディズニー及びオリエンタルランド公式のTDR待ち時間アプリはディズニーモバイル端末向けにしか用意されていない。
「一般的な人」がディズニーモバイルなんて使ってないだろ。公式サイト案内しておけ。
http://info.tokyodisneyresort.jp/s/calendar/tdl/
GPSでリゾート内にいればリアルタイムのスタンバイ時間がわかる。
個人的に、こういうグレーゾーン的な野良アプリの紹介があった場合はその業者の宣伝だと思うことにしてる。
ダメ出しだけでもあれなので
本気でトイレに困ったら、最終手段としてホテルに駆け込むのをおすすめしてる。
まず、自分はweb製作会社に勤めてる身なので、一通りの制作手順は知ってる。
そして、アダルトアフィリエイトサイトなるものを教えてもらった。
なんせ金にならん。(※webクリエイターは金など気にせずシコシコ勉強するのが大事)
といっても、お金はかけたくない。
できれば無料で。
そして、色々調べた結果、
まあ、無料なだけあって、色々縛りはつくんだよね。
最初はスクレイピングで、ほぼ自動化したサイト作ればいいんじゃね!
的なことを考えていたけど、FC2の無料サーバだと致命的なことに、DBやサーバサイド言語が使えない。
飛車角抜きで将棋しろとか、コンバイン使わずに田植えしろとか言われてるようなもんかな。
なので、フロントエンドの技術(html / css/ js)だけで、RSSとかの情報取得したりしてねー的なことをしないといけなくなった。
うーん、要はドラクエで言うなら、簡単な呪文は使えるけど、ほぼ素手でたたかえって言われてるようなもんかな。
とりあえず、サイトの体裁を整えるためにまずは、bootstrapのサンプルを改変してベースを作った。
bootstrap便利。http://getbootstrap.com/
あとは、幾つかのアフィリエイトのサイトに登録してパーツを配置。
動画も著作権やアダルト動画を載せる際の調査をして、一通りの知識を得る。
あとは、どんなサイトにするか。
ぱっと思いついたのは、普通のエロサイトよりもページ遷移を無くして、
どんどん動画を見やすいようにすれば、いろんなページから探し出す手間を省けるのではと思った。
なので、構成としては、クリックしてモーダルウィンドウの中で、動画が再生する形に統一。
動画の採取場所はDMMの無料サンプルとXVIDEOSでおk。
で、1ヶ月運用してみると、シングルページの弱点を身を持って体験した。
SEOにクソ弱すぎる。
どうしよう流行りのシングルページ(なんちゃって)にしたのに・・・どんどん検索順位が下る。
そこで起用したのがpushState。
jsでURLを書き換える技術。ただ書き換えるだけじゃなく、履歴そのものを作成してくれる。
これをすると、グーグルさんのクローラがシングルページのサイトでもうまいこと動いて順位があがった。
(若干iframeとの挙動で問題はあるが、ないよりまし。まあいける・・・。うん。)
てな感じです。
収益化はまだ全然できてないけど、仕事でサイト作るよりも自由だし、
Webエンジニアはだまって、アフィリエイトしてみるのも面白いかもね。
最近は収益どうこうより、自分が作ったサイトに人が訪問してくれるだけで嬉しくて、
↓まあ抜いていってくだせえ。
「よろしい、ならば戦争だ」
デコイ(英語: decoy、Military dummy、囮とも)は、敵を欺瞞して本物の目標と誤認させる目的で展開する装備の総称。
Matt Cutts氏が指摘するように、順位を下げるために付けたリンクが、期待とは正反対に順位を上げる手助けをしてしまうこともあり得なくはありませんね。
リンクされているサイトではなく、リンク元のサイトがスパムかどうか判断していることをGoogleのゲイリー・イリェーシュ氏がMarketing Land のポッドキャストで明らかにしています。
この説明にもネガティブSEOの具体例をあげて解説していることから、ペンギンアップデートがネガティブSEO対策に力を入れていることがうかがえます。
目的は「はてな次郎」の文字列を自分で管理して、インターネット上に増やすこと。
セルフプロデュースでセルフブランディングするのがポジティブSEOの王道です。
現在、「はてな次郎」をGoogle検索したら1万件ヒットする場合、セルフブランディングした情報が3万件ヒットするぐらいを目指してください。
「はてな次郎」に関する誤情報が、検索結果の10ページ以下に沈めばとりあえず成功です。
「はてな次郎」という文字列をインターネット上で増殖させる作業を、手動ではなく自動で行うことも可能です。
(例)有名人を応援するファンサイトを作り、各ページのタイトルやヘッダーに「はてな次郎」の文字列を入れる。
このような方法で、100万ページ程度のWebサイトは自動的に作れます。
元データや加工方法を変えて、さらにWebサイトを作れば「はてな次郎」の文字列をインターネット上に1億個以上投下することも可能です。
アメリカ大統領選挙でロシアが情報操作を行っていたと言われている「ロシアゲート事件」を参考にして、SNSにデコイをばらまくことも可能です。
やりたい放題のGoogleをブッ飛ばすには、プログラミングが有効です。
頑張ってください。
元記事の仮名が変更されたので本記事の仮名も変更しました。(はてな次郎)
補足:
https://anond.hatelabo.jp/20170918004847
続き
テキストマイニング勉強して増田に頻出する人間の種類をパターン化しようとしてるんだけど、方法が思いつかない
スクレイピングでデータを取る→mecabで形態素解析して頻出名詞をデータ化する→頻出名詞によって元増田がどのカテゴリーの属するのか判定する
の最後のカテゴリーを作るのがむずい。カテゴリーに名前を人力でつけようとするから難しいのか。ある程度頻出名詞が似通ったら(閾値を作って似てるの基準を作る)適当に振った名前group1,group2等に放り込むか。頻出名詞が似てるかどうかを判定するのは何の理論を使うのか、もしくは何のライブラリを使ったらどれだけ似てるかの判定を簡単にできるのか
最後のどれだけ似てるかの判定が自分は分からないってことが分かった
こういうのはどこで質問したら良い回答が得られるかな
勉強がてら作った〜
はてブ検索で特定キーワードの特定のユーザーのコメントを取得する(スクレイピング)
http://qiita.com/t-katsura/items/d015ecd683255a87cf80
でも今のところ/entryの一個前のところに/を入れると旧ブックマークページに飛ぶという変なハックにより、機能してる
新UI:http://b.hatena.ne.jp/entry/www.itmedia.co.jp/news/articles/1708/22/news008.html
旧UI:http://b.hatena.ne.jp//entry/www.itmedia.co.jp/news/articles/1708/22/news008.html
でもまぁ使い方は難しいかも
言論や表現の自由には愚行の自由も含まれるだろうから、こういうダメな研究も守るべきとなるのはわかる(私はシャルリーってやつね)。
が、学問研究としてみた場合は、特に倫理面でダメな研究はむしろ排除していかないとかえって学問の自由が阻害される状況もある。研究の質を保つ問題もあるし。
例えば小保方さんの問題になった論文は、それを著作物表現物としてみれば当然表現の自由として法に守られるべきだが、学問研究としてみた場合は研究手法や事実関係や研究倫理等が厳しく糾弾されたり学会や論文誌等から排除されるのはしょうがないよね、といえる。かつてのオボちゃん擁護勢もそうだったが、この両者を混同して前者の論理で後者まで擁護しようとしてる人が大勢いて混乱に輪をかけている。
大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。
悪く言えば自分の能力に絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。
相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。
本来の業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。
せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。
プログラミングの経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドでVBAから、Rやら自社製品の解析用環境の割と珍しいタイプのスクリプト言語など(特定されそうだからぼかすけど。)
とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手に作ってみたりして提案していた。
物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。
この辺で気付いたことだが、製造業のITリテラシーは驚くほど低い。製造業と一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。
なんせまともにプログラムを書いたことが無い新人が半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。
ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。
(そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。)
2年目に気付いたのは、弊社エンジニアのITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。
製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。
無骨だが使いやすいイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。
だから逆に言えば下々の人間はコピペでなんとか恰好を整えられるのだった。
彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。
私はそれに感動した。なんせWebスクレイピングみたいな方法で他人が社内プラットフォームや社内WIKIに上げた報告をまとめたり、製造時データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。
それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。
何にせよそういったものを一気通貫、自動化できるポテンシャルがあると感じられた。
SQLもjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しかも管理はIT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。
ところがその「ビッグデータ」プロジェクトは人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。(あとで聞いた話、外部コンサルで外れを引いたらしい)
自分もドメインの知識からの助言とか想定される使い方についての意見を伝えていったし(有難迷惑だった可能性は否定できないが)、もう少し待てばモノになると信じていたし、実際そうなった。
具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果の確認の為に数十億行のデータが活用された。彼らの力が無ければ常識的な時間では終わらなかった仕事だった。
残念だったのは彼らの優秀さの割に一般のエンジニアのスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。
そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。
もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社(厳密にはその親会社に)に買われることになった。
そういう時に起ることは不要な冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署が相手側にも存在するということだ。
つまりどちらにもある部署は統合するか一方を無くすかという戦争が始まるのだ。ITも例外ではない。(ITインフラ部署の無い会社はさすがに無いはずだ)
一方で製造業の本懐である「製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存の顧客への説明が必要だからだ。
そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか。
(ここで簡単のために旧弊社を(旧)A社、買収した側の競合他社を(旧)B社と呼ぶことにする。)
今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である。
旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフが簡単に表示され、A社側のお偉いさんからも好評を得ていた。
だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。
そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉だ
「増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ?」
もちろんhtmlもjavascriptもphpもRoRも一行も書いたことが無いのが当時の私である。
果たして旧A社のプラットフォームはB社のプラットフォームのデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。
そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。
クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベルで筆舌に尽くしがたいものがあるが、
反面教師だと思って耐える日々だ。
最近分かったことは旧B社のバックエンドスクリプトがデータを引っ張るついでに意図的に旧A社のプラットフォームを攻撃しているということだ。DDoSとまでは言わないが、悪意100%である。
いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。(つまり旧A社プラットフォームが不安定かつ重くなることを意図しているらしい)
旧A社から継続されてる業務はまだそこ使ってるんですけど・・・
それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。
旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える(私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングのレベルが二回りぐらい違うように見える)