「スクレイピング」を含む日記

2018-07-08

■Python = Web スクレイピング or 機械学習

Pythonって、アフィリエイトで稼いでる系の人たちにとってはスクレイピング用の言語で、エンジニア寄りの人にとっては機械学習用の言語っていう偏ったイメージがついている気がする。

自分は2012年くらいに、みんながrubyだrailsだ言ってるときに「はじめての言語がPythonだとコードをきれいに書く癖がついていい」という話だけで勉強し始めたんだよね。当時は2系と3系が混在してるときでタイミングとしては好ましくなかったかも知れないけど、Python選んでよかったと思ってる。今ほどPython、Python言われるとは思ってなかったけど、純粋に書きやすいし、やりたいことは大抵できるし。

でも、だからこそ、スクレイピングならPythonだよ！みたいなブログとか見るとグッと来るんだよね。なんかもっと色々なことに使えるのに、それに終始しているのはなんかなぁ・・・

自分はエンジニアじゃないし、機械学習なんてノータッチだから、結局のとこと、スクレイピング、文字列操作、エクセル操作、あと種々の自動化くらいなもんだから偉そうなこという気はないんだけど、 https://employment.en-japan.com/engineerhub/entry/2018/05/18/110000 こういうのが3ヶ月に一回くらいはてブの上の方に上がってくるのを見るとげんなりする。もっとなんかないのかね。

Permalink | 記事への反応(0) | 13:24

2018-06-12

■そもそも「引きこもってインターネットをやって賢くなろう」というのが間違い

地道に学んで、他人と意見を付き交わし、人の役に立ったり、傷ついたり、そういった事を繰り返して人は賢くなる。

安全圏に閉じこもってスクレイピングの効率を追い求めては上からマウントを取って気持ちよく射精してばかりいるうちはいつまで経っても馬鹿のままだよ。

Permalink | 記事への反応(3) | 20:27

2018-04-26

■とある 障害の話

これはLAN内で使っているだけの、しょっぱいエントリクラスのサーバ1台障害の話だ、価値のある話ではない。

とある国内最大級の某グループウェア Office(パッケージ版)を使っている。

この某グループウェアは、従業員の「その日のタイムカードの一覧」を見ることができない。

CSVでエクスポートすれば可能だが、営業マンは勤怠をガラケーのメールで報告する運用であるため、

~~スマホ支給しろ~~ 一覧＋タイムカード修正画面へのURL リンク付きで

総務課の人にスクレイピングしてあげていた。

↓大雑把にこんな感じ

#!/usr/bin/env perl
use MY::Cybozu;

my $cb = MY::Cybozu-&gt;new;
$result = $cb-&gt;get_timecard( sprintf("%d.%.d%", $year, $month, $day) );

&amp;amp;send_mail( $result );

数年来やってきていたのだが、突然このスクレイピングでデータが取れなくなった。

僅かに Perlを書けるだけで、他の言語は将棋を指すようにしか書けない低能である、

まず自分のスクリプトを疑った。

ちょうど20日の月替りのタイミングだったので、スクリプトのミスでズレたのか？

或いは、タイムカードのHTMLはtable 構造で「trの何番目が何日目」という原始的な処理の方でズレたか？

しかし、日付に関係なくダメになったのである。

ほぼほぼデータを取れないのだが、たまに正常に取れたりもする。なんだこりゃ。

$mech->statusの結果はいつも200である。

print $mech->contentの結果は、HTMLが途中で途切れていた。

スクレイプ対象の前で途切れたので、値を取得できなくなっていたのだ。

同じ場所で途切れる事が多いが、若干の増減はあった。

手元のWindows マシンに移植したところ、まったく問題ない。

どうやらスクリプトを動かしているLinux側の問題と思われる。

が、Web アクセスしてコンテンツが途中で途切れるって何だ？

どういう現象なのか？

そこまでの知識も経験もなければ、調べ方も分からない。

分からないなりに、とりあえずtcpdumpしてみた。

3WAYハンドシェイクはよく知られた話だが、正常な通信では、サーバから送られてきたパケットに対して

こちらは「ここまでのパケット受け取った」とACKを返し、最終的にサーバからのFINでこちらがRST返すのが見て取れた。

この異常をきたしたスクリプトでは、ある程度を過ぎると、こちらがACKを返す前にサーバからどんどんパケットが送られ、

突如としてこちらがRSTを連打し、切断してしまっていた。

なるほど、ステータスは200だけど、コンテンツは途切れているのだな。

悪いのは、いよいよこちら側である事は間違いない。

でもスクリプトじゃなくて、ネットワーク制御しているOSが悪いっぽい？

となると深刻である。自動車に乗れても内燃機関の構造など把握していないのだ。

唯一、tcp_abort_on_overflowでそれっぽい挙動をしそうだと分かったが、この機能は使われていない。

詰まった。

お手上げだ。

でも分かった。

端末から NASのディレクトリへ、TAB補完しようとすると突如フリーズしたのだ。

他のスクレイピングは正常に動作してる。

httpdも正常に動作してる。

MySQLも正常に動作してる。

某グループウェアへのスクレイピングとNASへのTAB補完だけが動かない。

故障だ。

単にマシンの故障だ。こういうヘンテコな挙動をするのは。

1.3万円で買って7年目の某ProLiantサーバだから、寿命なのだろう。

オチはないけど、最初から故障を強く疑っても良かったではないのか、と自省する。

そのマシンでのみ失敗し、しかも失敗したりしなかったり(比にして7:3程度)、結果も毎回変わっていたのだから。

うーん無能。

Permalink | 記事への反応(0) | 14:52

2018-04-12

■

増田ってスクレイピングおｋなの？

やっていいの？

Permalink | 記事への反応(1) | 22:03

2018-03-29

■スクレイピング

卑猥な響き

Permalink | 記事への反応(0) | 22:17

2018-03-25

■

ハロワ求人をこの1年ほどスクレイピングしてて

特定できる会社を"常時募集""3ヶ月以内に再募集"でリストアップしてみたけど多すぎてダメだな

もっと的確にブラックを分別できる技術を磨きたい

Permalink | 記事への反応(1) | 20:33

2018-03-13

■Web スクレイピングで全自動 更新のエログ作ったったwwww

概要

よくある「完全放置！」「全自動更新！」「何もしなくても儲かる！」みたいなアフィがあるけど

おそらく、その1つである全自動更新のエログ作って一ヶ月近くたったからその結果を書く。

何かしら作品を作ったらQiitaとかにアウトプット上げるけど、内容が内容なのでここで。

URLは多少内定自慢できるくらいの会社に内定貰っているから伏せますね＞＜@バレなさそうなら晒す

・仕組み

・サイト情報

・お金の話

・技術的な話

・結論

仕組み

仕組みは簡単、いくつかの既存のエロサイトにWeb スクレイピングをかけてウチのエログでも全く同じ情報を配信する。

そんなエログに全く価値が無いと思われるが、既存のエロサイトと比べてウチのエログを使うメリットはいくつかある。

メリット リスト

1. share-videosを使っているので削除されていても案外見れたりする。

2. 広告が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件くらい。

直帰率60%、ユーザー当たりのセッションは4。

こんなものか？正直Web系ではあまり無いから何をいえば良いかわからない。GAで取っているからみたい値があれば追記で。

完全放置のコピペかつ検索からの流入 100%で1ヶ月目にしてはじょうじょうかな？

お金の話。

儲かっているかというとこののままだと大赤字です。

鯖の無料枠で運営しているため向こう1年はタダで運営出来ますが、もっとアクセスを稼がないと厳しいです。（何せshare-videosしか収入がないから）

月極広告のお話が来たら安定するのですが、スクレイピングでこの程度であれば来ないでしよう。

技術的な話

CMSとしてWordpressを採用。理由はSEOとかプラグインで楽そうだから（事実楽）（KUSANAGIの存在を知っていれば使ってたのにと今更後悔）

Web スクレイピングはGolangを採用。理由は速いから。並列処理でもっと速いから。あと書きやすい。てか。。。普通に好き。。。＞＜

速さを求める理由はFunction as a serviceでスクレイピングを実行しているから。Python使おうと思ったけど、実行時間の制限があるためある程度早くスクレイピングを終わらせなければならなかった。

鯖側で常駐かcronを使っても良かったけど、常駐はメモリ食べてパニックだし、cronは設定がめんどくさいから。FaaSだとWeb上で実行間隔を弄れて無料で最高。

こだわった所

Web スクレイピングの抽象化

詳しい内容はウチのサイトの強みだから言えないが、他のエログのURLをリストに貼るだけで勝手に取得し投稿する。神。

結論

Web スクレイピングエログはおすすめしない。手動で毎日更新したほうがアクトレで確実に儲かる。

黒字化するのであれば現行の方法ではなく、全自動で日本中のエログ全てのから記事を取得してshare-videosに張り替えて投稿するサイトかな。

ほんで長期運営でユーザーにブクマしてもらえるような見やすいサイトにでもしなければ収益化は無理。

Permalink | 記事への反応(1) | 23:15

2018-01-06

■anond:20180106211107

マクロからだと少し話が飛躍するかもしれないがウェブサイトから記事をテキストで抜き取るスクレイピングっていう技術がある

株価の動向をデータ管理して数字を見るとか，こういったはてなブログの記事を適当な所だけ抜き取って記録していくとか，スクラップできる．

アマゾンのセールとかで買い物かごに速攻で突っ込みまくる巡回ソフトもこういう技術だった気がする．

Permalink | 記事への反応(1) | 21:17

2018-01-05

■増田の機能、ここが足りない俺的トップ1

はてなの数あるサービスの中でもトップクラスにPVがあると予想されるのに、いまだまともな検索機能が実装されないところ。

あれですか、スクレイピングでも定期的に実行して自分で検索してろってことですか？

有用な記事ですらあとで検索しづらくて見つけづらくて辛い。

Permalink | 記事への反応(2) | 18:35

2018-01-02

■うへー

Windows上でPython2系を使ってUnicode扱うのだるすぎつらい

未だにいい感じのIDE見つからんし

ファイル開くときとコンソール上に出すときと書き込む時で

それぞれ文字コードを設定せねばならぬ感あるし

Linux系の環境ができるまでスクレイピングは他の言語にしとこ…

Permalink | 記事への反応(1) | 13:13

2017-12-15

■https://anond.hatelabo.jp/20171214232537

ダウト

☆11、そういえば、アトラクションの待ち時間が分かるアプリがあるからダウンロードしといてね！

アプリストアにあるのはTDR 公式サイトをスクレイピングしている非公式アプリだ。（海外パーク用のは米ディズニーが公式で用意してる）

ディズニー及びオリエンタルランド公式のTDR待ち時間アプリはディズニーモバイル端末向けにしか用意されていない。

「一般的な人」がディズニーモバイルなんて使ってないだろ。公式サイト案内しておけ。

http://info.tokyodisneyresort.jp/s/calendar/tdl/

GPSでリゾート内にいればリアルタイムのスタンバイ時間がわかる。

個人的に、こういうグレーゾーン的な野良アプリの紹介があった場合はその業者の宣伝だと思うことにしてる。

ダメ出しだけでもあれなので

12、トイレの場所は覚えとくとすごく有り難がられるよ！分かんなかったらキャストさんに聞くと教えてもらえるよ！
あと、ディズニーの女性トイレはすごく混む。覚悟してね！

本気でトイレに困ったら、最終手段としてホテルに駆け込むのをおすすめしてる。

ランドならランドホテル、シーならミラコスタ。ランチ終わりの時間帯にぶつかると厄介だが、大抵空いてる。

うんこしてスッキリしたら、ラウンジでお茶でもしていけば良い。

Permalink | 記事への反応(0) | 09:31

2017-12-10

■[エロ]三大プログラマー あるある

"Hello World"の代わりに卑猥な言葉を入れる

エロサイトスクレイピング

あとひとつは？

※男性に限る　むしろ女性なら何をするんだろう

Permalink | 記事への反応(0) | 15:50

2017-10-15

■anond:20171015014103

http://oreero.x.fc2.com/

まず、自分はweb 製作会社に勤めてる身なので、一通りの制作手順は知ってる。

で、なんでこのサイトを作ったかというと、

まあ、副収入がほしかったんだ。

そして、アダルトアフィリエイトサイトなるものを教えてもらった。

ちょうどその頃、仕事以外で勉強しているものがあったが

なんせ金にならん。（※web クリエイターは金など気にせずシコシコ勉強するのが大事）

で、まずはアダルトサイトを作るにはサーバを借りねばならん。

といっても、お金はかけたくない。

できれば無料で。

そして、色々調べた結果、

やはり、アダルトサイト okなFC2が一番しっくりきた。

いい評判はあんまり聞かないが割と普通に動いてる。

まあ、無料なだけあって、色々縛りはつくんだよね。

最初はスクレイピングで、ほぼ自動化したサイト作ればいいんじゃね！

的なことを考えていたけど、FC2の無料サーバだと致命的なことに、DBやサーバサイド言語が使えない。

なんだろ、webも知らない人に伝えやすく言うと、

飛車角抜きで将棋しろとか、コンバイン使わずに田植えしろとか言われてるようなもんかな。

なので、フロントエンドの技術(html / css/ js)だけで、RSSとかの情報取得したりしてねー的なことをしないといけなくなった。

うーん、要はドラクエで言うなら、簡単な呪文は使えるけど、ほぼ素手でたたかえって言われてるようなもんかな。

とりあえず、サイトの体裁を整えるためにまずは、bootstrapのサンプルを改変してベースを作った。

bootstrap便利。http://getbootstrap.com/

あとは、幾つかのアフィリエイトのサイトに登録してパーツを配置。

動画も著作権やアダルト動画を載せる際の調査をして、一通りの知識を得る。

あとは、どんなサイトにするか。

ぱっと思いついたのは、普通のエロサイトよりもページ遷移を無くして、

どんどん動画を見やすいようにすれば、いろんなページから探し出す手間を省けるのではと思った。

なので、構成としては、クリックしてモーダルウィンドウの中で、動画が再生する形に統一。

動画の採取場所はDMMの無料サンプルとXVIDEOSでおｋ。

サイトのベースは一通り完成した。

で、１ヶ月運用してみると、シングルページの弱点を身を持って体験した。

SEOにクソ弱すぎる。

どうしよう流行りのシングルページ（なんちゃって）にしたのに・・・どんどん検索順位が下る。

そこで起用したのがpushState。

jsでURLを書き換える技術。ただ書き換えるだけじゃなく、履歴そのものを作成してくれる。

これをすると、グーグルさんのクローラがシングルページのサイトでもうまいこと動いて順位があがった。

（若干iframeとの挙動で問題はあるが、ないよりまし。まあいける・・・。うん。）

てな感じです。

収益化はまだ全然できてないけど、仕事でサイト作るよりも自由だし、

変更もその場で思いついたこと試せるから面白い。

後半眠くて、技術よりの話になった・・・。

Web エンジニアはだまって、アフィリエイトしてみるのも面白いかもね。

という感じでした。。おそまつおそまつ。

最近は収益どうこうより、自分が作ったサイトに人が訪問してくれるだけで嬉しくて、

淡々と息を潜めるように更新してやす。

↓まあ抜いていってくだせえ。

http://oreero.x.fc2.com/

Permalink | 記事への反応(0) | 02:18

2017-10-12

■Googleにデコイを食わせろ！

「よろしい、ならば戦争だ」

Google検索と戦う方法を紹介します。

デコイ

デコイ - Wikipedia https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B3%E3%82%A4

デコイ（英: decoy）は、狩猟で囮に使う鳥の模型。これが元来の意味である。

デコイ (兵器) - Wikipedia https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B3%E3%82%A4_(%E5%85%B5%E5%99%A8)

デコイ（英語: decoy、Military dummy、囮とも）は、敵を欺瞞して本物の目標と誤認させる目的で展開する装備の総称。

ネガティブ SEO

逆SEOとは？ネガティブ情報対策に効果的な「悪用禁止…｜Udemy メディア https://udemy.benesse.co.jp/marketing/negative-seo.html

「リバース SEO」や「ネガティブ SEO」とも呼ばれる逆SEO
逆SEOとは、特定サイトの検索順位を下落させること

ネガティブ SEOはうまくいかない、Googleマット・カッツがあらためて否定 | 海外 SEO 情報ブログ https://www.suzukikenichi.com/blog/matt-cutts-says-negative-seo-will-now-work/

Matt Cutts氏が指摘するように、順位を下げるために付けたリンクが、期待とは正反対に順位を上げる手助けをしてしまうこともあり得なくはありませんね。

【2017年】検索アルゴリズムリスト200：Google検索順位要因 https://moukegaku.com/google-ranking-algorithm/

リンクされているサイトではなく、リンク元のサイトがスパムかどうか判断していることをGoogleのゲイリー・イリェーシュ氏がMarketing Land のポッドキャストで明らかにしています。
この説明にもネガティブ SEOの具体例をあげて解説していることから、ペンギンアップデートがネガティブ SEO 対策に力を入れていることがうかがえます。

方針

ネガティブ SEOではなく、ポジティブ SEOを採用する。
ポジティブ SEOでデコイを大量に投下する。

あなたがプログラマーではない場合（手動）

あなたの名前を付けたブログやTwitterアカウントを作る。（例：はてな次郎のダイエット日記）
質の良い情報が必要なので、趣味や特技を活かしたテーマで記事を書く。（例：スムージーのオリジナルレシピを紹介）
業界の有名人へ積極的にメッセージを送る。（例：料理家・平野レミさんのちくわストローで飲むティースムージーのレシピに感想を送る） https://twitter.com/Remi_Hirano/status/759208574694359044

目的は「はてな次郎」の文字列を自分で管理して、インターネット上に増やすこと。

ブログの記事を動画にして、YouTubeにアップする。（YouTuber、ビデオブログ）
ブログの記事を書籍にする。（例：Amazon Kindle、Amazon オンデマンド印刷本）
書籍をオーディオブックにする。（例：Amazon Audible）

目的は「はてな次郎」の文字列を爆発的に増やすこと。

セルフプロデュースでセルフブランディングするのがポジティブ SEOの王道です。

現在、「はてな次郎」をGoogle検索したら1万件ヒットする場合、セルフブランディングした情報が3万件ヒットするぐらいを目指してください。

「はてな次郎」に関する誤情報が、検索結果の10ページ以下に沈めばとりあえず成功です。

あなたがプログラマーの場合（自動）

「はてな次郎」という文字列をインターネット上で増殖させる作業を、手動ではなく自動で行うことも可能です。

「クローラー」を作り、Web上のデータを収集する。
AI、自然言語処理でデータを加工する。
加工したデータをもとにポータルサイトを作る。

（例）有名人を応援するファンサイトを作り、各ページのタイトルやヘッダーに「はてな次郎」の文字列を入れる。

Amazonの商品データをスクレイピングして、本＝著者、CD＝歌手、DVD＝監督・俳優の人物データベースを作成する。
その人に関する情報をスクレイピングする。（DBペディアのAPI、あのひと検索スパイシーを参考にする）
日本語→英語→日本語の往復翻訳をするなどして、オリジナルのデータを少し改変する。
人物に関するデータから、その人物の三行紹介を作成する。（マルコフ連鎖で圧縮新聞のような記事を生成する） http://pha.hateblo.jp/entry/20071124/1195904502
自分が好きな歌手や女優なら、自分で紹介記事を書いても良いです。（手動の作業も加えてOK）

このような方法で、100万ページ程度のWebサイトは自動的に作れます。

元データや加工方法を変えて、さらにWebサイトを作れば「はてな次郎」の文字列をインターネット上に1億個以上投下することも可能です。

いいね 工場

アメリカ大統領選挙でロシアが情報操作を行っていたと言われている「ロシアゲート事件」を参考にして、SNSにデコイをばらまくことも可能です。

安いスマートフォンとSIMカードを大量に用意する。
SNSを操作する専用アプリを作る。（DeployGateやTranspoterPadのようなデプロイツールを利用）
「はてな次郎」の情報（自分で作ったブログ、Webサイト、SNS アカウントなど）を拡散したり、いいねを送る。

ユーザーの陳情を受付けないGoogleは傲慢ですね？

やりたい放題のGoogleをブッ飛ばすには、プログラミングが有効です。

頑張ってください。

追記

元記事の仮名が変更されたので本記事の仮名も変更しました。（はてな次郎）

補足：

「はてな次郎」の文字列を自分で管理

＝自分が書いた投稿なら、必要に応じて（自分の権限で）表示／非表示を切り替えられるので管理上都合が良い、という意味です。

Permalink | 記事への反応(1) | 16:28

2017-09-19

■増田でテキストマイニングして投稿者のパターンを判別

https://anond.hatelabo.jp/20170918004847

続き

テキストマイニング勉強して増田に頻出する人間の種類をパターン化しようとしてるんだけど、方法が思いつかない

スクレイピングでデータを取る→mecabで形態素解析して頻出名詞をデータ化する→頻出名詞によって元増田がどのカテゴリーの属するのか判定する

の最後のカテゴリーを作るのがむずい。カテゴリーに名前を人力でつけようとするから難しいのか。ある程度頻出名詞が似通ったら(閾値を作って似てるの基準を作る)適当に振った名前group1,group2等に放り込むか。頻出名詞が似てるかどうかを判定するのは何の理論を使うのか、もしくは何のライブラリを使ったらどれだけ似てるかの判定を簡単にできるのか

最後のどれだけ似てるかの判定が自分は分からないってことが分かった

こういうのはどこで質問したら良い回答が得られるかな

Permalink | 記事への反応(1) | 00:39

2017-08-30

■https://anond.hatelabo.jp/20170830155706

自慢にもならんけど

1997年からネットとPC使っててHTTPを人並に読めてgithubのスクレイピングライブラリにプルリクエスト出すようなエロシコ二次裏ユーザーだがあのへんの魚拓の取り方は知らんぞ

とった後どうなるのかも知らん

とった後のページは何度か見たことがあるが

個々のWebサービスの利用知識というのは単にその特定のWebサービスの利用の経験によるものであって、汎用の経験やリテラシでは代替できない

できんもんはできんしそこまで手間かけたくないものの手間はかけたくはない

Permalink | 記事への反応(1) | 18:57

2017-08-22

■はてブ 検索で特定 キーワードの特定のユーザーのコメントを取得する(スクレイピング)

勉強がてら作った〜

はてブ検索で特定キーワードの特定のユーザーのコメントを取得する(スクレイピング)

http://qiita.com/t-katsura/items/d015ecd683255a87cf80

作ってる途中でUI切り替わってワロタ

でも今のところ/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

でもまぁ使い方は難しいかも

Permalink | 記事への反応(0) | 15:17

2017-05-29

■http://anond.hatelabo.jp/20170528113521

んー、研究倫理の項にだいぶ漏れが目立つな。

こういう研究の進め方が摩擦を生んで規約が変えられたり鍵付きアカウントが増えればそれだけ以降の研究は困難になる
そうなると同じ分野ないし近い分野の研究まで悪影響を被り、その迷惑は自分だけでなく他の研究者にまで及ぶ
- 例えばpixivの画像データを使った研究は多数あるだろうが、今回の騒動で鍵垢が増えたりpixivの規約が変更されればスクレイピング等が困難になり影響を受けるだろう
アイデンティティに強くひもづくIDのリストの公表は大きな問題になりうる
- ネット上で公表されているメールアドレスをかき集めてリストを作り、それを公表したり売買したりすればいくらでも悪用可能だろうが
- それを「もともとネット上に公表する連中がバカなだけ、それを利用するおれの行為にはなんらの罪もない」で済むのか
- (公開データを収集や編集することによって生ずる別の価値への責任や、同意を得ずに行ったそれへの責任とか)

言論や表現の自由には愚行の自由も含まれるだろうから、こういうダメな研究も守るべきとなるのはわかる（私はシャルリーってやつね）。

が、学問研究としてみた場合は、特に倫理面でダメな研究はむしろ排除していかないとかえって学問の自由が阻害される状況もある。研究の質を保つ問題もあるし。

例えば小保方さんの問題になった論文は、それを著作物表現物としてみれば当然表現の自由として法に守られるべきだが、学問研究としてみた場合は研究手法や事実関係や研究倫理等が厳しく糾弾されたり学会や論文誌等から排除されるのはしょうがないよね、といえる。かつてのオボちゃん擁護勢もそうだったが、この両者を混同して前者の論理で後者まで擁護しようとしてる人が大勢いて混乱に輪をかけている。

Permalink | 記事への反応(0) | 10:22

2017-05-12

■製造業に新卒で入って数年経過したけどもうダメかもしれない

新卒で製造業に入った。

大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。

悪く言えば自分の能力に絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。

相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。

無駄が多いという感想は本配属後も変わらなかった。

本来の業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。

せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。

プログラミングの経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドで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持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。

ところがその「ビッグデータ」プロジェクトは人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。（あとで聞いた話、外部コンサルで外れを引いたらしい）

自分もドメインの知識からの助言とか想定される使い方についての意見を伝えていったし（有難迷惑だった可能性は否定できないが）、もう少し待てばモノになると信じていたし、実際そうなった。

具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果の確認の為に数十億行のデータが活用された。彼らの力が無ければ常識的な時間では終わらなかった仕事だった。

残念だったのは彼らの優秀さの割に一般のエンジニアのスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。

そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。

このころ私は入社3年目に突入していたが、

もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社（厳密にはその親会社に）に買われることになった。

そういう時に起ることは不要な冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署が相手側にも存在するということだ。

つまりどちらにもある部署は統合するか一方を無くすかという戦争が始まるのだ。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はその優秀さでそれらの攻撃をいなしつつあるようにも見える（私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングのレベルが二回りぐらい違うように見える）

この不毛な戦いはいつ終わるのだろう・・・つらい・・・

そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。

そもそも私はエンジニアなのだろうか・・・少なくとも職位にはそう書いてあるけど・・・

Permalink | 記事への反応(4) | 18:00

2017-04-24

■http://anond.hatelabo.jp/20170424200836

昔は「エロサイトの違法動画をスクレイピングして表示するサイトつくりました」って増田にURL貼ってアクセス稼ぐ犯罪者が多かったけどそれの亜種だな。

Permalink | 記事への反応(0) | 21:39

2017-04-21

■Orarioとスクレイピングと大学側の対応について

すでに学生でもないのになぜこの件について書いているか自分でも分からないが、例の穏便でない大学教授の発言にブーストされた感がある。

まず前提として、ID/パスワードを用いてスクレイピングを行うサービスそのものは、特殊というほどではない。そのようなサービスはすでにいくつも存在するし、最も有名なところでは口座アグリゲーションサービス（MoneyForward等）だ。彼らは業としてそのようなサービスをおこなっている。セキュリティのこと少しでもわかる人間ならそんなサービスやらない、というほどでもない。ただし、セキュリティが分かる人間であればあるほど慎重になる、というのは確かではある。通常ID/パスワードを渡すということは、全権委任とおなじだ。また、ログイン後の行動について、自分がやったか第三者がやったか、全く判別できない状況になる。さらに通常のWeb セッションと同等だとすると、パスワードリセットから完全なアカウント乗っ取りまであり得る。つまり、サービス事業者に対してよほど強い信頼関係がなければ厳しい、ということになる。

クラウド上で動いているかスマホ上で動いているか、という話は、それほどは重要ではない。クラウドにしろスマホアプリにしろ、すべてサービス事業者側の組んだプログラムの意図に従って動くものであることは確かだからだ。

ただしクラウド上ではユーザが想定していない動作を行っているのかどうかという検証しにくいという問題があるとはいえる。とはいえユーザが予め意図した行動から外れることをしてないのであれば、クラウドからのアクセスでも別にそれは問題ないわけで、その点で、Orario側の主張である「スマホで動かしているのだから」という主張は、ちょっと見当はずれではある。

なお、ユーザインタラクションを介さない自動的なアクセス自体がサービス要件に含まれる場合、スマホでは厳しいためクラウドにアクセス主体が置かれる、というのは、まああり得る。口座アグリゲーションはその典型的なものだろう。Orarioの場合は、たぶんその必要はないのだと思う。

正規の手段として学認があるのになぜしない？という主張は、マジでひどいと思う。普通に考えて、ぼっと出の１ベンチャーがトラストサークルに加えてもらえると思っているのか。このような主張は、Google/Facebook レベルに自由にAPI クライアントの登録ができるようになっていて、初めて言えるものだろう。通常は、世に受け入れられるサービスが出て初めて実行力を認めてもらえる、にわとりたまごの話ではないのか。そもそも、学認のShibboleth 仕様で、そのような履修情報のやりとりがそもそもできるようになっているのか疑わしい。ホントはSSOできるだけではないのか？

大学側にお伺いを立てるべき、という筋論は、そりゃそうかもしれないけど、やっぱりにわとりたまごだと思う。ビジネスの筋論っていうやつは、内輪だけの論理になっている場合が多いし、正直ステークホルダーは既得権益側だったりするわけで、話が通じるとは思えない。そのようなものを破壊していくのは常に外部からだろうし、それを単なる破壊行為ではなくDisruptionにできるのは唯一ユーザからの支持であるわけだけど、Orarioは最低限そこはできていたようにもみえる。例の教授はどうも内側のメンバーの感じがひしひしと出ており、傍目から見ると、そりゃそのポジションじゃあね感が強い。

事業モデルがわからないから怪しい、事業が成り立つとしたら収集したデータの第三者への販売ぐらいしかないはずだ、という主張は、気持ちはわかるものの論理として弱い。怪しいサービスに預けるな、というのは、意見の表明ではあるかもしれないが、普遍的に怪しさを証明するには根拠が足りていない。利用規約レベルではまだなんとでもいえる。逆に言うと、Orario側は、そういう色が少しでもあったのでは？と思わせるような内容を否定してさえいけば、その点では勝てるが、やっぱりそこは何らかの形で検討して行きたかったのでは、とも思えるので、そういう将来の自分たちを制限することはことはあまりやりたくないだろうなとは思う。

結論を言うと、とりあえず大学側はもうすこしトーンを落としてほしい。このままではFUDだといわれても仕方ない。単位云々の脅しは傲慢以外の何物でもない。少なくとも卒業生にとってそのような大学にいたことを恥じるレベルである。嫌なのは分かるが、銀行とかだってそうだったはずだ。もうすこし長い目で見てあげられないのか。ID/パスワードを預けることのユーザへの注意喚起は、もちろん正当だが、それを認識して預けていることについてとやかく言うことは得策でない。

そして、Orario側は、自分たちがやっているサービスの説明に少し時間を割いてもいいと思う。特に何をどのように取得しているのか、明確にすることは重要だ。大半のユーザたちはそういうこと気にしないとしても、自分たち自身が自分たちのサービスを定義するのに役に立つし、今はEvilでなかったとしてもいつかEvilになってしまうのを防ぐという意味合いもある。面倒かもしれないが、取得範囲を明確にすることは信頼を得るということであり、最終的にユーザの獲得に寄与するだろう。

Permalink | 記事への反応(0) | 13:25

2017-04-20

■http://anond.hatelabo.jp/20170419213734

中の人なの？

ユーザのスマホからのスクレイピングじゃなくて、ユーザのスマホ外からのアクセスによるスクレイピング（と情報の蓄積）が問題とかじゃなかったっけ？

なんで開発中だけちょろっとアクセスしただけなんて言えるんだ？

Permalink | 記事への反応(0) | 17:20

2017-04-19

■今流行ってるOrarioと大学側について思うこと

Orarioについて思うこと

Orarioについて

現在大学の中でOrarioのアクセスがどうこうという問題が起きているようだが、

ひとまずこの記事については、下記URLにある、京都大学の専門家であらせられる記事について、一人歩きしてる感があるので、

もう少し彼のような上流側（という表現で良いかどうかは不明だが）の専門家ではなく、

下流でプログラムをガッツリ書いているほうの専門家として私(匿名で失礼)が纏めたいと思う。

https://srad.jp/~yasuoka/journal/611343/

不正アクセスという言葉の曖昧性

Orarioの芳本大樹が書いた『時間割アプリの「Orario」の特性と安全性について』(2017年 4月17日)という文書を読んだ。このOrarioは、京都大学のKULASISにずっと不正アクセスを繰り返していて、正直なところ私(安岡孝一)としてはアタマに来ていたのだ。

Orarioの特性と安全性について、本当にスクレイピング技術をクライアント端末側で行っているのであれば、

この部分は間違いではないと私(匿名で失礼)は考えている。

この部分の書き方、実に大学教授らしい逃げ道を多く用意していて。

KULASISにずっと不正アクセスを繰り返していて

上記発言、これは本来「開発時の検証段階」の話をしているのであれば「正解」、である。

逆に今のOrarioの通信についてを不正アクセスとしているのであれば「正解ではない」、である。

何せ、開発者が勝手にアカウントを使って入り込んで様々な検証を行う必要があるため、

学生から IDとパスワードを借りたはずだ。

借りてログインするのが不正かというと微妙なラインだと思う。

この辺りにもやっぱり大学教授のいやらしさがあって

KULASISサーバに対してクラッキング/ハッキングを行って根こそぎどうこうしたなどという大がかりな不正アクセスではなく、

あくまで大学側が定める規約規則から若干外れた使われ方がされているという意味の不正アクセスである。

法律的には、正直不正かどうか微妙なラインになる。

（そもそもスクレイピングなんて技術を使う連中はID/PASSWORDがない状態でのサーバへの不正アクセスなどできない

開発時は「京大のKULASISアカウントをもったユーザが開発に携わっていないのであれば」押し出してきている京大の規約によれば、不正アクセスにあたるのかもしれない。

個人的には当たらないと感じるが。

現在動いているアプリは不正アクセスと断言できない

現在動いているものは不正アクセスではなく、

京大の規定に定められたユーザが「特定のブラウジングツール（Orario）」により、

KULASISにアクセスしているのだからアクセスとしては不正ではない。

本当にスマートなWeb スクレイピングで行われているのであれば、Web ブラウザと全く同じ動きをするはずで、

それを不正アクセスと断罪してOrarioは不正というのは表現が汚いと考える。

これはコメント欄にもあるが、

https://srad.jp/comment/3196554

また、ChromeやSafari（及びその他マイナーなWeb ブラウザ）なども御校のWebサーバーよりコンテンツデータを取得し、HTMLを構文解析し画面表示を行っていますが、これらはセキュリティポリシーには適合しているのでしょうか？

ご大層にはっておられるリンクを流し読みをする限り、そんな厳格に何かを定めているわけではないように思われる。

それ故、実際にOrarioがスマートフォンによるスクレイピングを行っているのであれば、

Web ブラウザの一種とも言えなくはない為、これを不正と断ずるのは、「正しくない」だろう

京大のユーザが開発に携わったかを証明できない以上、彼にとっては不正なのかもしれないが、

ここでそれをOrarioは不正アクセスと断ずる論理性が私(匿名で失礼)にはわからない。

アクセス パターンを公開できない理由とは？

他にもこの部分

Orarioアプリでは「Web オートメーション(Web スクレイピング)」と呼ばれる技術を用いています。この技術により、利用者様のスマートフォン（にインストールされているOrarioアプリ）に学生アカウント（大学 ID・パスワード）を入力すると、自動で当該利用者様の教務用ページから時間割の生成に必要な情報のみを取得し、Orarioアプリの時間割テーブルに当該利用者様の時間割を生成・表示することができるという仕組みとなっています。
全く信用できない。少なくとも先月以前、OrarioからKULASISへのアクセスパターンを解析した限りでは、そんな風なアクセスパターンには見えなかった。嘘を書くのもいい加減にしろ。