Shigeki SUGAI teckl

この記事はWebスクレイピング Advent Calendar 2017の17日目の記事です。puppeteerでクローリングします。

Google Chrome（Chromium）でクローリングをやる

SPAみたいなちょっと凝ったWebサイトをクローリングするときは一昔前はSelenium + PhantomJSあたりが鉄板でしたが、今後はSelenium + Headless ChromeもしくはPuppeteer + Headless Chromeが主流となっていく見通しです。（HeadlessとはGUIアプリケーションのGUIを介さないモードのことです。）

前者についてはWeb上に情報も多いですが、Puppeteerでクローリングする話をそんなに見ない気がするのでクローリングの歴史を踏まえてやってみます。

一昔前のクローリング

gitにおけるコミットログ/メッセージ例文集100の転載

例文を組み込んだAlfred Workflowを作りました: Alfred Git Commit Message Example

以下転載:

3つのリダイレクトの違い

実はGET(とHEAD)でリクエストされた時の動作は変わりません。違いはPOST(やPUT/DELETE/OPTIONS)でリクエストされた時の動作です。

**"307 Temporary Redirect(一時的リダイレクト)"**は最初のURLでは実際の処理は行わず、リダイレクト先に改めてリクエストを出し直して欲しい時に使います。したがって、最初のリクエストがPOSTであれば、ブラウザはリダイレクト先にもPOSTを使います。 "301 Moved Permanently(恒久的リダイレクト)"の「一時的」版であると思えばよいでしょう。

いまどきのガラケーと Flash Lite 開発事情

いまどきのガラケーコーディングがどうなっているか確認してみました。

ガラケーを取り巻く環境の変化

停波による古い端末の一掃
- docomo
  - 2006春モデル以前の端末が mova の停波により 2012/03/31 から利用不能に
au

	module github.com/mackee/sandbox/goperlfallblock

	go 1.16

	require (
	github.com/JoelOtter/termloop v0.0.0-20210806173944-5f7c38744afb // indirect
	github.com/Songmu/strrand v0.0.0-20181014100012-5195340ba52c // indirect
	github.com/nsf/termbox-go v1.1.1 // indirect
	)

	#! /usr/bin/perl
	#
	# Written in 2017 by Kazuho Oku
	#
	# To the extent possible under law, the author(s) have dedicated all copyright and related and neighboring rights to this software to the public domain worldwide. This software is distributed without any warranty.
	# You should have received a copy of the CC0 Public Domain Dedication along with this software. If not, see <http://creativecommons.org/publicdomain/zero/1.0/>.
	#
	use strict;
	use warnings;

	-- www.lua: Hammerspoon snippet that takes a snapshot and uploads it to imagebin every time you hit "www".
	--
	-- Requirements:
	-- * ffmpeg
	-- * imagebin API key
	--
	-- This script is directly inspired by: http://portal.nifty.com/kiji/170321199097_1.htm
	--
	-- License: BSD-2-Clause (c) Akinori MUSHA
	do

	# filter by request host header
	varnishlog -q 'ReqHeader ~ "Host: example.com"'

	# filter by request url
	varnishlog -q 'ReqURL ~ "^/some/path/"'

	# filter by client ip (behind reverse proxy)
	varnishlog -q 'ReqHeader ~ "X-Real-IP: .*123.123.123.123"'

	# filter by request host header and show request url and referrer header

	// ==UserScript==
	// @id iitc-plugin-ingressdualmap-exporter@OllieTerrance
	// @name IITC plugin: Ingress Dual Map Exporter
	// @category Keys
	// @version 0.0.0.1
	// @namespace https://github.com/jonatkins/ingress-intel-total-conversion
	// @description Exports portals currently in view as a CSV list for use with Ingress Dual Map.
	// @include https://www.ingress.com/intel*
	// @include http://www.ingress.com/intel*
	// @match https://www.ingress.com/intel*

	ip_conntrack: table full, dropping packet.

	この一行のログに悩まされた方は多いのではないでしょうか。
	自分もその一人です。

	多くのブログには echo '500000' > /proc/sys/net/ipv4/netfilter/ip_conntrack_max で解決。みたいなことが書いてあると思います。
	では、この数字について根拠はなんでしょうか。そもそも何のためにconntrack tableというものがあるのか考えたことはありますか？
	闇雲に最大値をあげることにたいして抵抗がある方もいると思います。

	このテキストは、転職後2日目にGWとして使っているLinux NAT BOXが爆発したことを起因とした、netfilterのチューニングについてまとめようと思います。