技術的な話題 に関する投稿を表示しています

視認しにくいテキストを探す | その 2 puppeteer を使って任意の web サイト上のテキストに対して色差を計算する

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

前回は色差を計算する方法の簡単な紹介と chroma.js を使った計算について扱いました。
視認しにくいテキストを探す | その 1 chroma.js を使って色差を計算する | ごみばこいん Blog

今回は実践編として、特定の Web ページに対して色差を計算して「視認しにくいテキストを探す」ことをやります。

Web ページに対して色を確認するには、キャプチャしたものから気合で探すか、 CSS の結果を持って確認するか考えられそう。ここでは後者を puppeteer でやってみます。
puppeteer は以前紹介したとおり、 Headless Chrome を Node.js からお手軽に扱うためのものです。
Node.js から Headless Chrome を操作できる puppeteer を試す | ごみばこいん Blog

ページを読み込んで色差を計算するためにこんなコードを書きました。

// ブラウザの起動
const browser = await puppeteer.launch();
const page = await browser.newPage();
page.setViewport({
    width: 1600,
    height: 900,
})

// デバッグ用に console.log を nodejs 側に渡す
page.on('console', msg => console.log(msg.text()));

// サイトにアクセスする
await page.goto('https://gomiba.co.in/test/color_difference.html');

// 色差を計算するために chroma をページ内で読み込む
await page.addScriptTag({
    url: 'https://cdnjs.cloudflare.com/ajax/libs/chroma-js/1.3.6/chroma.min.js',
});

// 色差が一定以上のものを探す
await page.evaluate(() => {
    // 全要素を探索していく
    document.querySelectorAll('*').forEach((element) => {
        // テキストノード、または SVG を子に持っている要素を探す
        let foundChildNode = Array.prototype.filter.call(element.childNodes, (e) => {
            let status = false;
            status = status || (e.nodeType === Node.TEXT_NODE && e.textContent.trim().length > 0);
            status = status || e.nodeName.toLowerCase() === 'svg';
            return status;
        });
        if (foundChildNode.length === 0) {
            return;
        }

        // 計算されたスタイルから色を取得
        let elementStyle = window.getComputedStyle(element);
        let fontColor = elementStyle.color;
        let backgroundColor = elementStyle.backgroundColor;

        // 色差を計算する
        let colorDiff = chroma.deltaE(fontColor, backgroundColor);

        // 計算された色差に透明度の色差を加える(透明度の差分 * 0.5 * 100)
        colorDiff += (Math.abs(chroma(fontColor).alpha() - chroma(backgroundColor).alpha()) * 0.5) * 100;

        // 色差が大きいものは無視
        if (colorDiff > 40) {
            return;
        }

        // 色差が小さいものに色付けをする
        console.log(element.nodeName + " : " + colorDiff)
        element.style.cssText = element.style.cssText + 'border: 5px dashed red !important;';
    });
});


// スクリーンショットを撮ってみる
await page.screenshot({path: 'example.png'});


// ブラウザを終了する
await browser.close();

puppeteer の playground がオンラインで提供されているので、コピペで動作確認できるはず、お試しあれ。
Try Puppeteer

手元に Node.js の環境があるなら、こちらのリポジトリでも。コマンドライン引数で対象 URL とキャプチャの保存するファイル名を受け取って、マーカーが引かれたキャプチャ画像が出力されます。
sters/web-color-difference

たとえば medium でやってみるとこんな感じ。白背景の部分で、薄めグレーの箇所ががマークされている。

たとえば、ランダムに色を設定するページを用意して試してみるとこんな具合。

確かに見にくい!!!なものはマークされているようだけど、ちょっと怪しいライン。もうちょっと基準値を調整したり CIEDE2000 のロジックも試すかなどして詰めたほうがいいかも…?とりあえず、のところはこれでもいいんじゃなかろーか。
元々やりたかった「視認しにくいテキストを探す」は出来たとしておしまい。

…と思ったけど、視認しにくいテキストっていうと話題が広いな、小さすぎる文字とか他の要素と被っているとかそういうのもそうなんだよねきっと、うーん。

視認しにくいテキストを探す | その 1 chroma.js を使って色差を計算する

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

SEO が云々でも色被ってるの良くないよねっていうけど、いや普通にユーザビリティ悪いやん、適当に色選ぶと見にくいこと往々にしてあるやん、って思ったので、そういう何かがあるのかなあって思って調べたら、 Wikipedia 先生にそのまんまの項目が記載されていた。ので、これをまとめつつ、ライブラリがあったのでそれを使ってみる話。

数式、もといロジックをざっくり読んでみる編

前提として Wikipedia のものをガンガン鵜呑みにしていく。
数式とかなんでそうなの?みたいな理解はせず、そういうものがあるんだなーくらいに留める。

色差を計算するには?

Wikiepedia に色差というページがあって、もうこれ。英語版と微妙に内容が違うけど、それは後で触れる。

色差 - Wikipedia

色差を計算するには単純に距離を計算しては、人間の感覚とはだいぶずれてしまってだめ。どうやら CIEDE2000 というものを使うとよいらしい。 CIE は国際照明委員会のことで DE は Delta E だ。2000 は年代。1976 、 1994 と研究され数式が更新されている。で、この CIEDE2000 を計算するには Lab 色空間を使う必要がある。
ただ、ぼくらが普段生きている世界では RGB とか CMYK とか HSV とか HSL とかなので、そこから変換をしてあげないといけない。いや、デザイナーさんとかその手のグラフィック関連に詳しい人なら Lab の世界でも生きているのかもしれない。

(参考)
カラーネーム/RGB/HSL ウェブでのカラー指定いろいろ | アライドアーキテクツのクリエイターブログ

Lab 色空間に生きたい

Lab 色空間も Wikipedia 上にページがある。

Lab色空間 - Wikipedia

単に Lab というと Hunter と CIE の 2 種類があるが CIE の方を最近では指すらしいので、これを使ったらいいみたい。これまた国際照明委員会が決めたもので、明度( L )と、いい感じの色 a と b を使って示し、人間の目で見える全ての色を記述できて機器固有の基準として使えるようにしたものだそうだ。

RGB からどうやって Lab に変換するんだろうねっていうと、 RGB は機器固有の部分があるので、一発変換!とはできず、 RGB を XYZ 色空間 に変換する必要がある。

RGB の世界から XYZ の世界へ移動する

これまた Wikipedia 上にページがある。

CIE 1931 色空間 - Wikipedia

すげーざっくりの理解では「研究成果の結果、 RGB に対する人の感覚を重み付けしたもの」。

ここまでをまとめると?

RGB → XYZ → Lab → 色差が計算できる!

後に回した英語との差分って?

色差の英語版のページを見てみる。
Color difference - Wikipedia

すると「 CMC l:c (1984) 」という日本語にはない数式が出ている。なんか良いやつなんじゃないかな、きっと。色っぽい単語で調べてたらその手の調査したよって論文もでてきた。

DDCPにおける色域外特色近似再現のための色差式評価

優位性とか書いてあるので気になった時に読むとよさそうな気がする。

ライブラリの出番です chroma.js

こう研究された成果があるわけなので、まあきっと便利に使えるようにライブラリ作っている人とかいるんだろうなあ~~とか思っているとやっぱりある。

chroma.js api docs!

色関係の話題をいい感じに取り扱ってくれるライブラリだそうで、各種色空間の変換も任せろ、グラデーションも任せろ、な強いライブラリ。

chroma.js を使って色差を計算する

単純な距離、ユークリッド距離の計算をするには chroma.distance を使う。 mode パラメータで色空間の指定が出来るので、2つの色の間の位相をみたりなんかにもできそうだ。
色差を計算するには chroma.deltaE を使う。ご丁寧に deltaE という命名になっててわかりやすいぞ~。内部的には CMC を使っているらしい。 CIEDE じゃないんだ。

それを実際に試してみようってわけで、こんな HTML + JS を書いて様子を見てみる。

<script src="https://cdnjs.cloudflare.com/ajax/libs/chroma-js/1.3.6/chroma.min.js"></script>

<style>
.color-difference td {
    min-width: 15px;
    min-height: 15px;
    padding: 3px;
}
</style>

<table class="color-difference">
    <tr>
        <td></td>
        <td></td>
        <td>distance(RGB)</td>
        <td>deltaE</td>
    </tr>
</table>

<script>
let colors = [
    ['rgb(255,0,0)', 'rgb(0,255,0)'],
    ['rgb(255,0,0)', 'rgb(0,0,255)'],
    ['rgb(255,0,0)', 'rgb(255,255,0)'],
    ['rgb(255,0,0)', 'rgb(255,0,255)'],
    ['rgb(255,0,0)', 'rgb(0,255,255)'],
    ['rgb(255,0,0)', 'rgb(255,128,0)'],
    ['rgb(255,0,0)', 'rgb(255,0,128)'],
    ['rgb(255,0,0)', 'rgb(255,255,255)'],
    ['rgb(255,255,0)', 'rgb(255,0,255)'],
    ['rgb(255,255,0)', 'rgb(0,255,255)'],
    ['rgb(255,255,0)', 'rgb(255,255,255)'],
];

let table = document.querySelector('.color-difference');

colors.forEach((color) => {
    let tr = document.createElement('tr');
    tr.innerHTML = `
        <td style="background-color:${color[0]}"></td>
        <td style="background-color:${color[1]}"></td>
        <td>${chroma.distance(color[0], color[1], 'rgb')}</td>
        <td>${chroma.deltaE(color[0], color[1])}</td>
    `;
    table.appendChild(tr);
});
</script>

こんな出力が得られる。

  • 赤と緑、青よりは、黄ピンクのほうが気持ち近い。水色、距離は遠いんだけど色差はあまり変わらず
  • 赤とオレンジ、マゼンダな色はやっぱり色差が少ない
  • 赤と緑や青を比べるより、赤と白を比べたほうが色差がすくない(!)
  • 黄とマゼンダよりも、黄と水、黄と白のほうが色差がすくない(!)
  • 距離 = 色差 に直結せず、色によって微妙に重み付けがされているのを感じる

わりと見た感覚と近い気がするのと、数字として出るとさらに面白い。

その 2 を書いた。

https://gomiba.co.in/blog/archives/1841

Carbon を使って 開始日と終了日を指定した // 単位の日付データ列を生成する

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

日単位のデータがわっとあって、週とか月とかの単位で集計してーなー!みたいな、そういう事をやりたいときってあると思うんですよ。
そのための日付の範囲を一覧にしてくれるやつ、というイメージで。作ったらあとは SQL とかそれに準ずる何かにポイポイしたらいいと思う。

Laravel の気持ちだったので Carbon だけど Chronos でも同じようにいけると思う。 startOfMonth とかで、自身の日付変わるところは結構驚いた、さすが Carbon やりますねぇ!(

<?php
require_once('vendor/autoload.php');

use Carbon\Carbon;

// 週の最初を日曜日、最後を土曜日に設定
Carbon::setWeekStartsAt(Carbon::SUNDAY); 
Carbon::setWeekEndsAt(Carbon::SATURDAY);

// $type = 1, 2, 3 // day, week, month
function dateRangeIterator($startDate, $endDate, $type=2) {
	$startDate = Carbon::parse($startDate)->startOfDay();
	$endDate = Carbon::parse($endDate)->endOfDay();

	while ($endDate > $startDate) {
		// "この" 始まりと終わりを取得する
		if ($type === 1) {
			$thisStartDay = $startDate->copy();
			$thisEndDay = $thisStartDay->copy()->endOfDay();
		} elseif ($type === 2) {
			$thisStartDay = $startDate->copy();
			$thisEndDay = $thisStartDay->copy()->endOfWeek();
		} elseif ($type === 3) {
			$thisStartDay = $startDate->copy();
			$thisEndDay = $thisStartDay->copy()->endOfMonth();
		}

		// 終わりが指定値を超えないように調整
		if ($thisEndDay > $endDate) {
			$thisEndDay = $endDate;
		}

		// ジェネレーター生成
		yield [$thisStartDay, $thisEndDay];

		// 次の日/週/月にいく
		if ($type === 1) {
			$startDate->startOfDay();
			$startDate->addDays(1);
		} elseif ($type === 2) {
			$startDate->startOfWeek();
			$startDate->addWeeks(1);
		} elseif ($type === 3) {
			$startDate->startOfMonth();
			$startDate->addMonths(1);
		}
	}
}


// 月単位 2/2 ~ 3/2 まで
foreach(dateRangeIterator('2018-02-02', '2018-03-02', 3) as $x) {
	echo "$x[0] - $x[1]\n";
}

echo "------\n";

// 週単位 2/3 ~ 2/18 まで
foreach(dateRangeIterator('2018-02-03', '2018-02-18') as $x) {
	echo "$x[0] - $x[1]\n";
}

echo "------\n";

// 月単位 2/2 ~ 10/12 まで
foreach(dateRangeIterator('2018-02-02', '2018-10-12', 3) as $x) {
	echo "$x[0] - $x[1]\n";
}

/**
$ php hoge.php
2018-02-02 00:00:00 - 2018-02-28 23:59:59
2018-03-01 00:00:00 - 2018-03-02 23:59:59
------
2018-02-03 00:00:00 - 2018-02-03 23:59:59
2018-02-04 00:00:00 - 2018-02-10 23:59:59
2018-02-11 00:00:00 - 2018-02-17 23:59:59
2018-02-18 00:00:00 - 2018-02-18 23:59:59
------
2018-02-02 00:00:00 - 2018-02-28 23:59:59
2018-03-01 00:00:00 - 2018-03-31 23:59:59
2018-04-01 00:00:00 - 2018-04-30 23:59:59
2018-05-01 00:00:00 - 2018-05-31 23:59:59
2018-06-01 00:00:00 - 2018-06-30 23:59:59
2018-07-01 00:00:00 - 2018-07-31 23:59:59
2018-08-01 00:00:00 - 2018-08-31 23:59:59
2018-09-01 00:00:00 - 2018-09-30 23:59:59
2018-10-01 00:00:00 - 2018-10-12 23:59:59
*/

時間とか分とか、単位をもっと細かくしたいんだよね~~ってなっても、同様にして細かい単位のものを実装したらいいと思う。

いじよ。

(翻訳)Chrome の広告ブロックが何をしているか

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

元記事はこちら。
Chromium Blog: Under the hood: How Chrome's ad filtering works

自分の理解のため読んだ記録に。
※翻訳者は中の人でもなければ、ガバガバ翻訳なの※


web 上の多くの広告はユーザエクスペリエンスを尊重している。が、ここのところ邪魔なんだけど!と聞いていて、昨年 6 月に発表した( Chromium Blog: Improving advertising on the web )けど Chrome で Better Ads Standards ( The Initial Better Ads Standards - Coalition for Better Ads )に従ってない広告を消すようにしたよ。

Chrome が守っている詳細は前に説明した( Building a better web for everyone )けど、このアプローチがリリースされる 2 月 15 日が近くなってきているので、今日はどうやって動いているかを説明するよ。

Better Ads Standards って何?

オンライン広告のユーザーエクスペリエンスを向上させるための、業界団体が定めるもの。4 万人以上の北米・ヨーロッパのユーザにアンケートを取って、様々な広告について評価をしたよ。
一番迷惑だと評価されたのは全画面広告( Ad Experience: Prestitial Ads [Mobile] - Coalition for Better Ads )とフラッシュアニメーション広告( Ad Experience: Flashing Animated Ads [Mobile] - Coalition for Better Ads )だったよ。

詳しくはこっち( The Research - Coalition for Better Ads )をみてね。

そんな Better Ads Standards に違反する広告のいくつかは、そもそも広告自体に問題があるけれど、ほとんどはサイトの所有者が制御しているよ。思うに、広告が密集していたり、カウントダウンするような広告だったり。

この Better Ads Standards の結果を受けて、多くの迷惑な広告からユーザを守るアプローチを Chrome でやるよ。Better Ads Standards に準拠しているか評価して、発生した問題をサイトに報告、問題に対処する機会を提供し、それでも継続していたら広告の削除を行なうよ。

違反サイトの評価

サイト上のページのサンプルを調査して評価するよ。見つかった Better Ads Standards の問題に応じて、サイトが合格、警告、失敗のステータスに評価するよ。

サイトの評価ステータスは Ad Experience Report API ( Introduction | Ad Experience Report API | Google Developers )を通してアクセスできるよ。

サイト所有者は詳細な結果を見るために、 Google Search Console の Ad Experience Report ( Web Tools - Web Tools )の中で確認できるよ。ここで、再審査をしたりもできるね。

ネットワークレベルでのサイトのフィルタリング

Chrome ユーザがページに移動すると、 Chrome の広告フィルタが、ページが Better Ads Standards に違反してないかを確認するよ。このとき、ネットワークリクエスト(JavaScript や 画像たち)は広告関連 URL と一致しているかチェックするんだ。マッチした場合、 Chrome はそのリクエストをブロックして、広告を表示されないようにするよ。

この広告関連 URL は EasyList フィルタルール( EasyList - Overview )に基づいていて、 Google プラットフォームの AdSense や DoubleClick も含まれるんだ。

Chrome でこれがどのように見えるのか?

ここまで紹介したアプローチで Chrome は広告を自動的にブロックするんだ。少なくとも 1 つの広告がブロックされると、 Chrome はユーザにブロックした旨を伝えるよ。広告を許可するオプションもあるよ。

デスクトップユーザなら Chrome のアドレスバーにでるポップアップブロッカーと似たような通知を出すよ。Android ユーザの場合は画面下の小さなインフォバーで表示されるね。

初期の結果ではユーザのために良い進歩

この操作の結果で Chrome ユーザは Better Ads Standards に準拠していない広告は見えないことになるが、私達のゴールは全ての広告を見せないことではなく web ユーザのエクスペリエンスを向上させることだよ。( The browser for a web worth protecting

2 月 12 日時点では Better Ads Standards に違反していたサイトのうち 42% は既に合格しているよ。これは私達の望んていることで、迷惑な広告体験を修正し、全ての web ユーザに恩恵をもたらすんだ。

違反に関する通知を受けてから 30 日たってもサイトが修正されなければ Chrome は広告をブロックするよ。

私達は迷惑な広告体験から以降する早期な結果を持って、業界と継続的にやり取りし、 Chrome の広告フィルタ機能が不要になる未来を目指しているんだ!

エンジニアリングマネージャーの Chris Bentzel さんが書きました。

docker の出すログファイルでディスクが 100% になった

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

まとめると?

  • タイトル通り。 docker の出すログファイルでディスクが 100% になった。
  • ログファイルの削除と daemon.json の設定をして完。

起きたこと

環境依存的に難しいので docker を使っているバッチスクリプトがあるのだが、このスクリプトがモリモリと標準出力に出している。や、本来は捨てられる前提のものなので、問題はあるけどない、みたいな状態。
docker は docker 内で動いているメインプロセスの標準出力のログを取っているっぽく、そのログが溜まりに溜まって、ホストマシンのディスクを埋め尽くしてしまった。

それをたまたま、同じホストマシン上の、まったく違う docker コンテナで動いている web アプリケーション上で、セッションがうまく動いていないっぽいという事象が発生したところから、調べてみると、ホストマシンのディスクがいっぱいだった、ということが判明した。

やったこと

何が容量を食っているのか確認した

du コマンドでチマチマ確認したのだが、もうちょっと効率のいい方法がしりたい。一発でバチコーンとわかるような何か。

# du -sh /* | sort -nr
...

# du -sh /var/lib/docker/* | sort -nr
436K    /var/lib/docker/containerd
104K    /var/lib/docker/network
72K     /var/lib/docker/volumes
37G     /var/lib/docker/containers
22M     /var/lib/docker/image
20K     /var/lib/docker/plugins
20K     /var/lib/docker/builder
8.1G    /var/lib/docker/overlay
4.0K    /var/lib/docker/trust
4.0K    /var/lib/docker/tmp
4.0K    /var/lib/docker/swarm
4.0K    /var/lib/docker/runtimes

# du -sh /var/lib/docker/containers/* | sort -nr
372K    /var/lib/docker/containers/df16f7083353204424150c80cb7c87dc9dda19627c7f09632e797a48d3bea2cf
372K    /var/lib/docker/containers/0d9b9a46c096f977921b682b40d7aa9de5dee443ea01a8d0b157f8f366bce764
288K    /var/lib/docker/containers/8d813f2238daa78186881017d1d6b675715f7602549cfb8285cbb08f5832f88d
252K    /var/lib/docker/containers/ce637310ed46de127cfc78813df94b1a269370a07a0f8ab24dc11f2c87bbadc8
228K    /var/lib/docker/containers/fd837df4343e6c54f5c145385bd93e23e8705114243f8a3d856458bf89c454a0
64K     /var/lib/docker/containers/bc4cdc66666f835980147bbc8105741a45db5018777ca883e35fdd3a072a7970
37G     /var/lib/docker/containers/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80
36K     /var/lib/docker/containers/8d9bb861db601facac528d60ee855fd5b38a05dcdc2949fee72e9c3dcb4dd177

# du -sh /var/lib/docker/containers/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80/* | sort -nr
37G     /var/lib/docker/containers/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80-json.log
4.0K    /var/lib/docker/containers/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80/resolv.conf.hash
4.0K    /var/lib/docker/containers/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80/resolv.conf
4.0K    /var/lib/docker/containers/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80/hosts
4.0K    /var/lib/docker/containers/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80/hostname
4.0K    /var/lib/docker/containers/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80/hostconfig.json
4.0K    /var/lib/docker/containers/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80/config.v2.json
4.0K    /var/lib/docker/containers/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80/checkpoints
0       /var/lib/docker/containers/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80/shm

# tail /var/lib/docker/containers/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80-json.log
....
// このログしってる!ぼくが標準出力に出すようにしたやつだ!

ログファイルの削除をした

中身を確認した上で、完全に不要なものだったので削除した。お手軽 echo 。

# echo > /var/lib/docker/containers/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80/4d81d71c1ea8eaea101cab745f2c16a2bcb096a2bba78f9aecd385f560e62e80-json.log

/etc/docker/daemon.json の設定をした

実際には次のような設定を書いている。これで docker 自体が勝手にログファイルの容量制限とローテートをしてくれるっぽい。べんりちゃん。

# cat /etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {"max-size": "10m", "max-file": "3"}
}

容量制限とローテートされた様子。上で出したものと別コンテナだけど。

# du -sh /var/lib/docker/containers/61ffb4d88381cd2556a91f6944a2b2d2b57bb7837d8ad9a21ed772748f490b66/* | grep json.log
4.6M    /var/lib/docker/containers/61ffb4d88381cd2556a91f6944a2b2d2b57bb7837d8ad9a21ed772748f490b66/61ffb4d88381cd2556a91f6944a2b2d2b57bb7837d8ad9a21ed772748f490b66-json.log
9.6M    /var/lib/docker/containers/61ffb4d88381cd2556a91f6944a2b2d2b57bb7837d8ad9a21ed772748f490b66/61ffb4d88381cd2556a91f6944a2b2d2b57bb7837d8ad9a21ed772748f490b66-json.log.1
9.6M    /var/lib/docker/containers/61ffb4d88381cd2556a91f6944a2b2d2b57bb7837d8ad9a21ed772748f490b66/61ffb4d88381cd2556a91f6944a2b2d2b57bb7837d8ad9a21ed772748f490b66-json.log.2

公式ドキュメントを見ると他にも設定項目がいろいろあって、デーモン自体の設定なので、どんな権限で動かすか、とか、そういう…。あまり変更するような出番はないかも。
daemon — Docker-docs-ja 17.06.Beta ドキュメント

log-driver として json-file 以外にも fluentd や AWS CloudWatch なども指定できるので、もしかしたら何か活用できる…?具体的にどういう活用方法があるんだろう
Fluentd logging driver | Docker Documentation


docker 入れてる環境、事故防止のためにもログローテート系の設定はとりあえず入れると良いとおもった一件

DELL XPS 13 の Windows 10 を使っているが無線 LAN の電源管理オプションが表示されなくてちょっとこまった

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

会社では Windows 10 のノート PC 、というか DELL XPS 13 を使っている。
無線 LAN の親機の設定が変わったのか、こっちが変わったのかよくわからないが、ここ最近で無線 LAN がよく切れるようになってしまった。

特に電源ケーブルにつないでいない状態で、一部の SSID にまったく接続できなくなったのはかなり謎。元々は問題なく利用できていたので完全に親機の問題だと思う(設定かえたとか言ってたし…)
一向に対応される気配がないので、諦めて子機側でできることをやってみようと思った。

 

「無線 LAN 切れる Windows」とか「無線 LAN 不安定 Windows」などで調べると、おおむね「電源管理の設定を開いて最大パフォーマンスにしよう!」という内容が出てくる。たとえば…
Windows10のLAVIEでWi-Fiがすぐにつながらなくなるので省電力設定を直したぞ! | むねさだブログ

 

が!!!

「電源オプション」の中の「ワイヤレスアダプターの設定」が表示されていない。 DELL ありがてえ(ありがたくない)
「表示されない」、とかで調べるとてもドンピシャな内容がヒットせず。。

 

DELL サポートに連絡するのもアレなので、レジストリエディタからほげほげできないかなあと思いながら調べていると、まさしくな記事が見つかった。

Windowsの電源オプションで設定可能な項目を増やす - らどこの消費生活 続き

 

ワイヤレスアダプターの件について書かれてはいないのだが、同じようなあたりに設定値おるやろってことで順番に見ていくと wlansvc.dll と指定されているものいて、無線 LAN っぽい名前だしこれだろうな~~と。
ここの Attributes の値を、上記のブログに書かれていたように 2 にしたら設定項目がでてきましたとさ。

環境によって違うかもだけど、レジストリキーはこれ。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\19cbb8fa-5279-450e-9fac-8a3d5fedd0c1\12bbebe6-58d6-4636-95bb-3217ef867c1a

 

本題に戻ると、この設定で接続不安定なところは改善された。たまに瞬断も起きているっぽいが、まあまあ問題ない。というか親機…

 

OEM 的な目線(?)で考えれば、これって不用意にいじられてぶっ壊されたり、メーカーが想定している適切なパフォーマンスが発揮できない、みたいな減少を回避するために、意図的に項目を隠しているんじゃなかろーか、と思った。コンパネ的な設定項目だったら「エコにしよう!!!」とかですぐ弄れるけれど、レジストリなら弄れるには弄れるが、たまたまたどり着くことは難しいと思うので、それでいいんだと思う。

Apache 2.4 で WebSocket もリバースプロキシする

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

Apache 2.4 で WebSocket をプロキシしたい。以前書いた docker-compose のフロントとして Apache を立てると、バックエンドで WebSocket を使う場合にすこしの設定を足す必要がある。

docker-compose で LDAP 認証のリバースプロキシを設定する | ごみばこいん Blog

nginx 使えよって話、めっちゃわかる。そのうちやる…たぶん…

ちなみに Apache 2.2 だとパッチがいたりするそうなので、がんばって!って感じっぽい。

 

httpd.conf あるいはその手の Apache 設定ファイルで以下のような設定を足すと良い。

# ...略...

# WebSocket をプロキシするモジュールを読み込み
LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so


# ...略...


# 例えば Jupyter の場合はこんなパスをプロキシしてあげる

# websocket
ProxyPass /api/kernels/ ws://${REVERSE_PROXY}/api/kernels/
ProxyPassReverse /api/kernels/ ws://${REVERSE_PROXY}/api/kernels/

ProxyPass /terminals/websocket/ ws://${REVERSE_PROXY}/terminals/websocket/
ProxyPassReverse /terminals/websocket/ ws://${REVERSE_PROXY}/terminals/websocket/

# http
ProxyPass / http://${REVERSE_PROXY}/
ProxyPassReverse / http://${REVERSE_PROXY}/

 

REVERSE_PROXY は環境変数で、バックエンド( Jupyter )のホスト(とポート)を指定する。ぼくの手元のやつは docker-compose を使ってるのでこんな感じに書いている。

version: "3"

services:
  jupyter:
    container_name: "${APP_NAME}_jupyter"
    build: ./docker-jupyter
    command: start-notebook.sh --NotebookApp.token=''
    volumes:
      - ./notebooks:/home/jovyan/work
    environment:
      GRANT_SUDO: 1
      NB_UID: ${NB_UID}
      NB_GID: ${NB_GID}
  proxy:
    container_name: "${APP_NAME}_proxy"
    build: ./docker-proxy
    ports:
      - "${HTTP_PORT}:80"
    links:
      - jupyter:jupyter
    environment:
      REVERSE_PROXY: jupyter:8888

httpd:alpine の Docker イメージを利用しても WebSocket のプロキシが出来るので、そんな感じ。
いじょ

docker-compose 自体を更新する

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

Github にリリースされていっているので、そこを見て、コマンドを実行したらよいといえば良い。

Releases · docker/compose

が、毎回見るのもあれなので、思い立ったときに動かせるようにしたいなあと思ったので更新するやつを作った。

sters/docker-compose-updater: Semi automatic docker-compose updater

原理はめっちゃそのままで、こんな処理をしている。

  • インストールされている docker-compose を which で探す
  • インストールされていなければ終了
  • curl と cut で Github のリリースページから最新版のバージョンを探す
  • OSとアーキテクチャを uname で識別(ドキュメントのまま)
  • Github のリリースページから最新版をダウンロードし、インストールされているものを置き換える(ドキュメントのまま)
  • chmod で実行権限を渡しておわり

Makefile がいいよ!って言われたので試しに見よう見まねで Makefile でやった。 Makefile のお試したかっただけ、みたいなところはある。なるほどなあ~~

 

どうやるのがいちばん良さそうかわからないけれど、docker-compose を扱う docker イメージがあってそっちを使うほうが楽そう…?

とはいえコンテナ内から docker-compose な操作をほにゃほにゃするとなると /var/run/docker.sock とか docker-compose.yml もといアプリケーションディレクトリをマウントしないと行けないので、記述がめんどうになりそうな気がする… というかちょっと試した程度ではできなかったのでうーん。
docker-compose って名前でエイリアスして、実態は docker/compose イメージを docker run してますよ~~みたいなものが出来ると、 docker-compose の準備する手間が無くてちょっとだけ便利になりそうなのだけど…

 

ちなみに作ったものと同じように、手元へと docker-compose バイナリを取り出すのはこんな感じ。

$ docker run --rm --entrypoint "" -v $(pwd):/tmp/bin docker/compose:1.18.0 cp /usr/local/bin/docker-compose /tmp/bin/

$ ls -l docker-compose
-rwxr-xr-x 1 root root 8479184 Jan 18 12:10 docker-compose

※ root が所有者になってるので移動させたりするときは sudo しないとだめ

docker-compose で LDAP 認証のリバースプロキシを設定する

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

色々が色々あって、社内限定ツールに Active Directory を参照した LDAP 認証を掛けることがある。
それ自体は別にいいのだが Docker を使ってペペッと作って展開するといったときがやや面倒になった。

ので、それを docker-compose を使ってリバースプロキシを作ったら解決できたよ、というメモ。

 

こんな感じで docker-compose.yml を作って。

version: "2"

services:
  application:
    container_name: "${APP_NAME}_application"
    build: ./docker-app
    volumes:
      - ./src:/var/www/html
  proxy:
    container_name: "${APP_NAME}_proxy"
    build: ./docker-proxy
    ports:
      - "${HTTP_PORT}:80"
    links:
      - application:application

docker-compose をやったことがある人はご存知と思うが、このときの ${APP_NAME} や ${HTTP_PORT} は環境変数を指していて .env ファイルなどを作り APP_NAME=hogehoge みたいなことをしたらいい。

余談なのだけど、ドキュメントみたら version 3 のフォーマットがいつの間にかリリースされていて(しらなかった!!)、そっちに移行していく流れのほうがいいよねって思った。
Compose file version 3 reference | Docker Documentation

 

こんな感じで ./docker-proxy/Dockerfile を作って。

FROM httpd:alpine
COPY ./httpd.conf /usr/local/apache2/conf/httpd.conf

 

こんな感じで ./docker-proxy/httpd.conf を作って。

# default configures
ServerRoot "/usr/local/apache2"
Listen 80
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_core_module modules/mod_authn_core.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule access_compat_module modules/mod_access_compat.so
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule reqtimeout_module modules/mod_reqtimeout.so
LoadModule filter_module modules/mod_filter.so
LoadModule mime_module modules/mod_mime.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule env_module modules/mod_env.so
LoadModule headers_module modules/mod_headers.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule version_module modules/mod_version.so
LoadModule unixd_module modules/mod_unixd.so
LoadModule status_module modules/mod_status.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so

<IfModule unixd_module>
    User daemon
    Group daemon
</IfModule>

ServerAdmin you@example.com
ServerName localhost:80

<Directory />
    AllowOverride none
    Require all denied
</Directory>

DocumentRoot "/usr/local/apache2/htdocs"

<Files ".ht*">
    Require all denied
</Files>

ErrorLog /proc/self/fd/2
LogLevel warn

<IfModule log_config_module>
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    LogFormat "%h %l %u %t \"%r\" %>s %b" common
    <IfModule logio_module>
      LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
    </IfModule>
    CustomLog /proc/self/fd/1 common
</IfModule>

<IfModule mime_module>
    TypesConfig conf/mime.types
    AddType application/x-compress .Z
    AddType application/x-gzip .gz .tgz
</IfModule>

<IfModule ssl_module>
    SSLRandomSeed startup builtin
    SSLRandomSeed connect builtin
</IfModule>



# Load modules
LoadModule authn_core_module modules/mod_authn_core.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule auth_basic_module modules/mod_auth_basic.so

LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
LoadModule ldap_module modules/mod_ldap.so

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so


# LDAP
LDAPTrustedMode SSL
LDAPVerifyServerCert off


# Proxy
<VirtualHost *:80>
    ProxyRequests Off
    ProxyPreserveHost Off
    AllowEncodedSlashes On
    KeepAlive Off

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    <Location />
        AuthName "Basic Auth"
        AuthType Basic
        AuthBasicProvider ldap
        AuthLDAPURL [ここにLDAPを参照するのURI]
        Require valid-user
    </Location>

    RequestHeader unset Authorization

    ProxyPass / http://application/
    ProxyPassReverse / http://application/
</VirtualHost>

 

あとは docker-compose up -d --build などと実行したら出来上がる。

$ docker-compose up -d --build

 

Apache をつかっている理由としては nginx の場合は公式イメージの中で LDAP のモジュールが提供されていないこと、組み込む場合にビルドが必要なことがあげられる。 Apache のイメージであればデフォルトで LDAP のモジュールが提供されている。さらに言えば
alpine イメージでも提供されているので debian ベースなイメージなどと比べて、軽量で高速上げ下げ出来たりしてめっちゃ良いよねってところもあった。調べると debian ベースにビルドしてるものもあって、良いんだけどう~~ん。

まあ「docker nginx ldap proxy」とか普通のワードで調べたらイメージだったり Dockerfile だったりが出てくるので、そのあたりを使ってもよかったのかもしれない。

debian ベースで nginx 1.11.13 をビルドする。 PR したらマージされる感あるのでバージョンアップもやっていけそう。
h3nrik/nginx-ldap - Docker Hub

debian ベースで nginx 1.9.9 をビルドする。2 年前から更新されていないので今後も更新されなさそう感
confirm/docker-nginx-ldap: nginx Docker image with ldap support

nginx 公式なのだけど nginx で LDAP ではなく、横にいる LDAP してくれるやつがよろしくやる、というものでちょっと違うかも。
nginxinc/nginx-ldap-auth: Example of LDAP authentication using ngx_http_auth_request_module

あるいは nginx-proxy っていうめっちゃ便利なリバースプロキシできる君があるので、これをベースに LDAP 認証のモジュールを追加するっていうのが、お手軽楽ちんで一番いいかもしれない。
jwilder/nginx-proxy: Automated nginx proxy for Docker containers using docker-gen

 

とりあえず一旦のところは Apache でやったよっていう話と、 nginx でも調べたら出てくるよ、ってまとめでおわり。

phpcs の自作ルールを作ってみた

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

phpcs を使って、他のルールセットにはない、独自のルールを設定する方法を調べた。

存在するルールセットを組み合わせる

そもそも、存在しているルールセットを組み合わせたり、無効にしたりするには、 composer を使ってパッケージを入れるなどして xml ファイルに記載をしていけば OK 。
これは Github の Wiki にもやり方が記載されている。

Coding Standard Tutorial · squizlabs/PHP_CodeSniffer Wiki

xml ファイルの例

<?xml version="1.0"?>
<ruleset name="oreore_ruleset">
    <description>名前空間は無くてもいいよ</description>
    <rule ref="PSR2">
        <exclude name="PSR1.Classes.ClassDeclaration.MissingNamespace" />
    </rule>
</ruleset>

コマンドの例

$ phpcs -n --colors --standard="oreore_ruleset.xml" src/

調べたのはこれではじゃないよ

自分で 1 からルールを定義する

こちらも Github の Wiki 、同じページ(Coding Standard Tutorial)にも書いてある。 Creating the Sniff の項目。

が、ちょっとトラップがあって、 Creating the Sniff の項目だけ読んで進めると、足りないものがいろいろあって NG 。1からルールを定義するときにも xml ファイルは必要だった。

それを読みながら試しに作ってみたのがこれ。

sters/phpcs-myruleset-test: Create phpcs sniffer test repo.

実際に触ってみて、いくつかの制約があるっぽい(というか書いてある)

  • ルールを格納するサブディレクトリを作らないといけない
  • ファイル名の末尾が Sniff.php でないといけない
  • PHP_CodeSniffer\Sniffs\Sniff インタフェースを利用する
  • register と process メソッドを実装する

個別にもう少し詳しく深掘りする。

ルールを格納するサブディレクトリを作らないといけない

こんな感じで掘ると良さそう。
ルールセット名の下に Sniffs という名前にすると、自分で設定しているルールセットだよ~的な意味になるっぽい。

MyRule/Sniffs/HogeSniff.php

phpcs の実装としてはこのあたりにそう書いてあるように見える。
PHP_CodeSniffer/Ruleset.php at master · squizlabs/PHP_CodeSniffer

で、作ったディレクトリと同じ階層に xml ファイルを置く。中身は説明書き程度で、もし他のルールを継承したものを作っていく場合にはここに書き足していくと良いっぽい。

MyRule/rule.xml

<?xml version="1.0"?>
<ruleset name="MyRule">
	<description>MyRule Coding Standards</description>
</ruleset>

アプリケーションと同じところに Sniffer は入れないと思うので(関心の分離的にも別で管理しよう!)、別管理する気持ちで作っていくと良いと思う。

ファイル名の末尾が Sniff.php でないといけない

phpcs が Sniff.php でファイルを探している。実装はこのあたり。

PHP_CodeSniffer/Ruleset.php at master · squizlabs/PHP_CodeSniffer

なので、ルールを書いていくファイルは HogeSniff.php のようなファイル名でないといけない。

MyRule/Sniffs/HogeSniff.php

PHP_CodeSniffer\Sniffs\Sniff インタフェースを利用する

このあたりからは、ぼくの試した実装とにらめっこしてみたほうがいいかもしれない。

これは phpcs の Wiki にも書いてあるものと同じ、ハッシュコメントを警告するための Sniff 。

phpcs-myruleset-test/DisallowHashCommentsSniff.php at master · sters/phpcs-myruleset-test

インタフェースの利用については特にいうこともないので、はい。

register と process メソッドを実装する

引き続き、ハッシュコメントを警告するための Sniff を見ながら。

phpcs では対象となった php ファイル(あるいは他のファイルも指定できる)に対して、トークナイザを実行し、指定されたトークンに対してのみ process メソッドが動くように作られている。
その指定されたトークンを register メソッドで指定する。こういう感じで。

public function register()
{
    return [
        T_COMMENT
    ];
}

トークンの一覧は php.net の方にある。

PHP: パーサトークンの一覧 - Manual

php.net のリストを見ると T_COMMENT は 「 // or #, and /* */ 」にあたると書いてある。
これでコメントのトークンに限定して process メソッドを実行できる。

process メソッドはこんな感じで書いている。

public function process(File $phpcsFile, $stackPtr)
{
    $tokens = $phpcsFile->getTokens();

    if ($tokens[$stackPtr]['content']{0} === '#') {
        $error = 'Hash comments are prohibited; found %s';
        $data  = [trim($tokens[$stackPtr]['content'])];
        $phpcsFile->addError($error, $stackPtr, 'Found', $data);
    }
}

$phpcsFile は PHP_CodeSniffer\Files\File クラスのインスタンスで、今はどのファイルを対象にしているか、そのファイルのトークンは、といった情報が入っている。

$stackPtr はトークンスタックのうち現在の位置を示す int 。 register で指定したトークンが見つかった位置になる。当然のことながら 1 ファイルで複数見つかることもあるので、そのときは毎回 process メソッドが呼ばれるようだ。

$phpcsFile->getTokens() でトークンの一覧を取ることができ、これはトークンの二次元配列になっている。なので $stackPtr で参照することで、現在の位置のトークンが分かる。

トークンは以下のような形式で表現されている。

array(8) {
  ["type"]=>
  string(9) "T_COMMENT"
  ["code"]=>
  int(377)
  ["content"]=>
  string(8) "# echo
"
  ["line"]=>
  int(3)
  ["column"]=>
  int(1)
  ["length"]=>
  int(6)
  ["level"]=>
  int(0)
  ["conditions"]=>
  array(0) {
  }
}

そのトークンが、コード中の何行目にあって~、どのネストレベルで~、とかとか。このうち content に着目すると、そのトークンが持っている中身が見られる。

コメントの場合はコメント自体がまるっとトークンになるので、そのうちの先頭 1 文字をみて # だったらエラーを出すことで、ハッシュコメントを警告する Sniff の出来上がり。

自作のルールも phpcbf で自動でなおるようにしたい

お試したリポジトリには入れていなかったのだが addFixableError と fixer->replaceToken を使うことで出来るっぽい。

PHP_CodeSniffer/ClassDeclarationSniff.php at master · squizlabs/PHP_CodeSniffer

$fix = $phpcsFile->addFixableError($error, $stackPtr, 'SpaceBeforeKeyword', $data);
if ($fix === true) {
    $phpcsFile->fixer->replaceToken(($stackPtr - 1), ' ');
}

複雑なルールを作っていきたい

もしかしたら場合によって、もっと複雑なルールを設定していきたいような場合もあるのでは…?
そんなときどうするんだろうなあと思ったけれど、結局のところは気合で処理を書いていかないといけない(そりゃそうだ)

それは phpcs に含まれる PSR のルールを見てもそうだし Packagist にあるルールセットを見てもみんながんばってるのが分かる。

例えば PSR-2 のクラス定義に関する Sniff 。
PHP_CodeSniffer/ClassDeclarationSniff.php at master · squizlabs/PHP_CodeSniffer

「 1 つ前のトークンが空白で、改行で、その前が abstract か final だったらエラー!」とかそういう。

 

例えば… とおもって Packagist みていたら phpcs でセキュリティチェックしてくれる君があった。
FloeDesignTechnologies/phpcs-security-audit

その中に簡易的に XSS のチェックをしてくれるのがあるが、やっぱり頑張る
phpcs-security-audit/EasyXSSSniff.php at master · FloeDesignTechnologies/phpcs-security-audit

とはいえ、全部書くのもあれなので、 phpcs 側で用意されているユーティリティメソッドだったり、自分で便利に使うものを用意すると Sniff 本体が簡潔に書けて良さそうだ。

 

例えば処理の中や後ろにコメントを書くようなあれを警告する Sniff を作ってみたのがこんな感じ。

phpcs-myruleset-test/DisallowInlineCommentsSniff.php at master · sters/phpcs-myruleset-test

public function process(File $phpcsFile, $stackPtr)
{
    $this->tokens = $phpcsFile->getTokens();
    
    $tokenPrev = $this->findSomethingFirstOnLine($phpcsFile, $stackPtr);
    $tokenNext = $this->findSomethingLastOnLine($phpcsFile, $stackPtr);

    if ($tokenPrev !== false || $tokenNext !== false) {
        $message = "Disallow Inline comments.";
        $errorCode = 'inline_comments';
        $placeholder = [];
        $phpcsFile->addError($message, $stackPtr, $errorCode, $placeholder);
    }
}

findSomething.. は同じ行の前後に、自分以外の別トークンがいるかを探すメソッド。
findFirstOnLine というのが File クラスのメソッドにはあるが、微妙にそういう意図じゃないんだよ!というところだったので、参考にしつつ作ったのがコレ。行の情報があるので、ぐるぐるして、同じ行で別トークンがあるかな?を探しているだけで、特別難しいことは何もしていないとは思う。

おわり

特定のキーワード、特定の処理方法を警告するようなものは簡単に作れそうなので、余力があれば、チーム独自ルールみたいなものを phpcs に掛けられるようにすると、レビューコストが下がったり(?)、変な記述が生まれにくくて、いいなあと思ったとさ。

命名規則のようなちょっとむずかしそうなルールも、頑張ったら実装していくことは出来るので、そういうのを統一していきたいんだよね、みたいな事象のときに活用できそうだ。

1 2 3 4 5 6 7 8 9 10 11 12 13