asyncioを用いたpythonの高速なスクレイピング - HackerNews翻訳してみた
「HackerNews翻訳してみた」が POSTD (ポスト・ディー) としてリニューアルしました！この記事はここでも公開されています。 Original article: Fast scraping in python with asyncio by Georges Dubus ウェブスクレイピングについては、pythonのディスカッションボードなどでもよく話題になっていますよね。いろいろなやり方があるのですが、これが最善という方法がないように思います。本格的なscrapyのようなフレームワークもあるし、mechanizeのように軽いライブラリもあります。自作もポピュラーですね。requestsやbeautifulsoup、またpyqueryなどを使えばうまくできるでしょう。 どうしてこんなに様々な方法があるかというと、そもそも「スクレイピング」が複数の問題解決をカバーしている総合技術だ
You don't need API version 2 - yohei's diary
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) rest - Best practices for API versioning? - Stack Overflow RESTfulなサービスのバージョンングから得られた知見 RESTとバージョニング 基本的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい（というか実用的）かど
拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
Fast scraping in python with asyncio
Web scraping is one of those subjects that often appears in python discussions. There are many ways to do this, and there doesn't seem to be one best way. There are fully fledged frameworks like scrapy and more lightweight libraries like mechanize. Do-it-yourself solutions are also popular: one can go a long way by using requests and beautifulsoup or pyquery. The reason for this diversity is that
Google、モバイル向けサイトのリダイレクトには301よりも302を使うように推奨を変更
[対象: 上級] PC向けページとモバイル向けページを別URLで提供する環境では、HTTPヘッダーに含まれるUser-Agent（ユーザーエージェント）に基いて、デバイスに応じた適切なページへ自動でリダイレクトする構成が幅広く使われています。 リダイレクトには、301リダイレクトでも302リダイレクトのどちらを利用しても構わないとこれまでGoogleは説明してきました。 しかしその指針を変更し、301よりも302の利用を推奨するようになりました。 公式ドキュメントで302リダイレクトを推奨 12月に公開されたモバイル向けサイトのチェックリストのドキュメント、「Checklist for mobile website improvement」には以下のように書かれています。 Try to use 302 for device-related redirects (not 301s). デバイ
Google先生の検索結果リンクが予想以上に作り込まれていた件 - Y's note
Index 検索結果のリンクは単なるRedirectorでは無かった 検索結果のhttps化 httpsからhttpページへの遷移ではブラウザはRefererを送らない Google先生はRerererを送る仕組みを実装してくれた Refererが送信される処理の流れを追う httpsからhttpsページへの遷移はどうなるか Google Analyticsで検索Queryが「not provided」となる本当の理由 まとめ 検索結果のリンクは単なるRedirectorでは無かった 知らなかったのが僕だけだったら凄い恥ずかしい内容なんですが、今までGoogle先生の検索結果として表示されるリンクのURLはGoogle内部でClick集計するためのRedirector機能だと思っていました。カウントアップの集計を記録したら本来のURLに遷移させるような。当然そのClick数を集計する機能も
POST をリダイレクトすると GET になる件について調べた - 理系学生日記
とある事情により、POST リクエストをリダイレクトさせる必要が生じました。単純にリダイレクトさせてみたところ、リダイレクトはされるものの、POST リクエストに付与していた HTTP_BODY が取得できません。どうも、リダイレクト時に GET に変更されているみたいです。 ぼくは怒りに震えたものの、RFC 的にはどう振る舞うべきなんだ、各種ブラウザの振舞いはどうなっているんだ、ということが気になったのでまとめてみました。内容としては、 -POSTリクエストをリダイレクトするとGETされる？POSTされる? - はこべにっき ♨ の二番煎じになります。 先に結果を示しておくと、以下のとおりでした。 Status Code 期待動作 Firefox (25.0.1) Safari(7.0) Chrome (31.0) 301 POST GET GET GET 302 POST GET GE
今夜つける HTTPレスポンスヘッダー （セキュリティ編） - うさぎ文学日記
Webサーバーがレスポンスを発行する際に、HTTPレスポンスヘッダーに付けるとセキュリティレベルの向上につながるヘッダーフィールドを紹介します。 囲み内は推奨する設定の一例です。ブラウザによっては対応していないヘッダーフィールドやオプションなどもありますので、クライアントの環境によっては機能しないこともあります。 X-Frame-Options ブラウザが frame または iframe で指定したフレーム内にページを表示することを制御するためのヘッダーフィールドです。主にクリックジャッキングという攻撃を防ぐために用いられます。 X-Frame-Options: SAMEORIGIN DENY フレーム内にページを表示することを禁止（同じサイト内であっても禁止です） SAMEORIGIN 自分自身と生成元が同じフレームの場合にページを表示することを許可（他のサイトに禁止したい場合は主にこ
YappoLogs: 2014年に向けた JSON API の実装の方向性と X-JSON-Status 改め X-API-Status header のご提案
2014年に向けた JSON API の実装の方向性と X-JSON-Status 改め X-API-Status header のご提案 追記 2014/11/20 14:00:00 わりと JSON やら XML やら各種フォーマットで API を運用している環境がある場合に JSON API の時だけ X-JSON-Status にすると XML とかの時と整合性取れないし、 X-XML-Status みたいのを量産するのは困る的なレビューを頂いたので X-JSON-Status をやめて X-API-Status にしました。 へたに JSON に限定するから REST とか JSON-RPC とかいわれるんや！ X-API-Status にしたら全部解決したし MessagePack な API でも使い回せるって songmu さん言ってた！ XML とかからどうやって引っこ抜
ブラウザが消滅して： APIベースのWeb - 檜山正幸のキマイラ飼育記 (はてなBlog)
「僕らが大好きだったWebはなくなるのかもしれない」において、「Webページ／Webサイトから構成される従来型のWebはなくなるのではないか」と述べました。 ここで、極端な想定として「Webブラウザが消滅してしまった」としましょう。これは、あくまで想定であって、未来予測をしているわけではありません。 汎用のブラウザに代わるのは、個別の機能を持ったアプリ群です。これらのアプリ（の多く）は、通信のインフラとしてインターネットを利用するので、インターネットはやはり必須で重要な存在です。 ブラウザがなければ、Webページから構成されるWebサイトは意味を持ちません。Webサイトはアプリのリモートバックエンドに置き換えられ、Webページはアプリの状態に取って代わられます。 アプリとそのリモートバックエンドは通信をするのでプロトコルが必要です。そのプロトコルは、HTTP（の発展形）がやはり主流でしょう
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Referrer を制御する - Qiita
Web ブラウザーは通常 HTTP 要求の Referer: ヘッダーに参照元ページの URL を入れますが (あるいは document.referrer で参照元ページの URL を取得できますが)、 Web サイト側でこれを制御したいことがあります。 例えば、次のような場面が想定されます。 URL にユーザー名や秘密の ID などを含めざるを得ない時は、プライバシーやセキュリティーの観点から、この URL を外部に漏らしたくありません。 社内システムに URL を貼りたいことがありますが、社内システムの URL を外部に漏らしたくありません。 Web アプリケーションの開発用サーバーは、その所在を外部に漏らしたくありません。 投稿者と友達のみに公開される SNS の投稿にリンクが含まれる時、その個別 URL を漏らしたくありません。 (SNS 全体の URL が漏れることは問題ありま
HTTPでHashやArrayを送る手法に仕様は存在しない……の? - ただのにっき(2013-09-15)
■ HTTPでHashやArrayを送る手法に仕様は存在しない……の? jQueryでこんなふうに書くと: $.post('/', { hash: { foo: 'hoge', bar: 'fuga'}, array: ['baz', 'piyo'] }); サーバ側でこんなふうに受け取れて(これはSinatra): post '/' do params.each do |key, val| puts "#{key}: #{val} as #{val.class}" end end ちゃんとHashやArrayとしてアクセスできる: hash: {"foo"=>"hoge", "bar"=>"fuga"} as Hash array: ["baz", "piyo"] as Array ああこりゃ便利だね、で済ましてもいいんだけど、HTTP POSTの中身なんてただのバイト列なんだから型の情
SSL/SPDYを攻撃するCRIMEはBEASTの正統な後継者だ
はじめに 以前のエントリでSSLに対する新しい攻撃手法「BEAST」を紹介しましたが、今回はBEASTをさらに発展させた「CRIME」という攻撃について簡単に紹介したいと思います。一次情報源としてこちらのスライド（英語）が閲覧できますので、時間がある方はぜひ目を通してみてください。 CRIMEの意味 CRIMEは "Compression Ratio Info-Leak Made Easy" あるいは "Compression Ratio Info-Leak Mass Exploitation" の頭文字で、SSLやSPDY（あるいはHTTPボディ部のgzip圧縮）で使われる圧縮アルゴリズムに注目した攻撃手法です。あまり知られていませんがSSLには圧縮機能が存在しており、サーバ側・クライアント側双方が圧縮機能をONにしている場合に、データが圧縮されます。 BEASTとの関係 CRIMEはB
Hatena-Textbook/ios-app-development-with-web-api.md at master · hatena/Hatena-Textbook · GitHub
Web API を利用する iOS アプリ作成 iOS 開発 Bootcamp Introduction スマートフォン全盛期のいま、Web サービスもスマートフォンから利用される割合がどんどん高まっています。ユーザーはより便利で快適なアプリを求め、Web サービス事業者はそういったユーザーを少しでも満足させるため、日々努力しています。またスマートフォンアプリ開発を専業としていても、Web との関わりのないアプリではできることが非常に少なく、その様なアプリはいまやごくまれです。今日、Web アプリケーションとスマートフォンアプリは非常に密接な関係にあります。 Web アプリケーションとスマートフォンアプリ開発の両方を学ぶことは、そういった現在の Web をより広く見通すためには最適な課題であると言えます。どちらも学ぶことでその連関を知るだけでなく、開発の類似性や違いからより多くを学べるはず
Webに関わる人のための『HTTPの教科書』を発売 - うさぎ文学日記
ひさびさの単著となる『HTTPの教科書』が2013年5月24日に発売になります。 内容はタイトルの通り、Webに関わる全ての人に捧げるHTTPを学ぶための教科書です。基礎を学びたい初心者の方から、机の上に置いてリファレンス的に使いたい方までを対象としています。 HTTPの教科書発売元: 翔泳社価格: ￥ 2,730発売日: 2013/05/25posted with Socialtunes at 2013/05/21 HTTP関連の書籍は『今夜わかるHTTP (Network)』というタイトルの本を2004年に出しています。その頃からHTTP/1.1が主流であるというのは、今でも変わりませんがそれを取り巻く環境というのは変わりつつあります。 HTTPを学ぶ上での要点がわかりやすく、そして読みやすくなっております。前作のリニューアルっぽく感じるかと思いますが、9割以上は書き直しや追記しており
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
httpsだからというだけで安全？調べたら怖くなってきたSSLの話!？ - Qiita
Interactive Reading Community (Ver.6)
404 Not Found