1週間前ぐらいまで毎日いろいろと資料を読んでコード書きまくったりしていたけど、例によって急激にやる気が失われてほとんど何もしていない。

  1. ハードウェア周りのコード書くやる気が急激に失われる
  2. サイトの最適化まわりにやる気を出す
  3. 全てのやる気が失われる (だいたいやったから)

という感じで進行した。やる気があるときは「ゲームとかやってる暇全くないし、ゲームとか完全に無駄な時間を過ごすだけ。酒飲んで頭回らない時間をつくるのも無駄」みたいな意識の高さがあるが、そうでないときはとにかく頭を一切使いたくないという感じになる。

ハードウェアまわりは明確にやりたいことはあるけど、途中でやる気がなくなったのでそれ以来全くすすめていない。

ディアブロ3を久しぶりにちょっとやってるけど、目が疲れる。

どっか散歩したいけれど、忌中なので神社には行けない。つつじヶ丘あたりを地図なしで歩いたりしてみたりしたけど気分は晴れず。ストレスは溜まるがやはり解消方法がない。

二重の意味で(出勤も保育園も)はぁ嫌だなあと思いながら保育園に行ったら、保育園が開いていなかった。意味がわからなかったけどとにかく開いていなくて、どうしようもないので帰ってきた。

自分はこういう予期していないトラブルに滅法弱くて、普段に数倍に嫌な気持ちが増幅されるんだけど、そうはいっても現実として「誰が子供の面倒見るの?」という問題を解決しないといけないので、会社を休んだ。

結局なんだったかといえば保育園は諸事情 (特に複雑な事情ではなくて、年間行事表には書いてあった) によって休みだった。昨年は土曜日にあたっていたようで意識しなかったし、休みになるという認識がなかった 。そして今年は直前に子供の発熱があったせいか特別休みの予告がなかったので、誰も休みを認識してなかった。

来年同じことがないようにカレンダーにリピートを入れた。

別に保育園が悪いわけではないけど、ほんと保育園関係は嫌な気持ちになることが多い。暦通りじゃない休みがこんなにアナウンスされないものなのか。

準備して、子供が寝てるとこを起こして(朝食をとったあと、たまに寝ることがある)、だっこして、門まで連れていって、開いてない。平日だから当然出勤するつもりでいる。出勤する人の流れが見えるから平日なのは間違いない。寝ボケていて時間を間違えたのか。開いてないから帰るしかない。おやつやら昼食やらをどうするか考えないといけない。夕方までの間のすごしかたを考えないといけない。スワップアウトされてるもろもろを頭の中のワーキングメモリにロードしなおさないといけない。

自分のイライラするシチュエーションを考えみると「ワーキングメモリに大きなデータをロードする必要がある」ことと「予期してない」ことが大きく関係しているような気がしている。

自分は頭の中のワーキングメモリに、何らかの仕事(プログラム全体の設計とか)をロードするのにとても時間がかかる。このロードされたイメージが何らかの出来事(外部割込み由来)で無駄になるときにイライラする。

生活全般で

保育園なんかで、1円にもならない仕事をやらされたりする。全体としてたいしたことじゃなくても、その仕事をロードするたびに、趣味にしろ仕事にしろ、頭の中のイメージにリセットがかかる。そして再度元の仕事をロードする必要がある。

予期できることもあるけど、そもそもストレスかかる仕事が多いのでコンテキストスイッチが発生するだけで不愉快。

仕事において

しばしばあるのが、些細な仕様変更・追加で、これにより根本的に直す必要がありそうだというケース。

そういうことが起こらないように、将来的にどんな仕様の追加がありそうかということをエスパーして、予期されるそれらへの変更耐性を設計に組み込んだりするする。そういうのも含めて、ピースをうまく噛み合せて全体的に「これでうまくいきそうだな」というイメージを構築するまで、まずとても時間がかかる。

しかしいろいろ考えたとしても、考慮外の仕様が出現したりする。この「考慮外の追加仕様」はイライラする。というのも

  1. 頭の中にロードされたイメージの中にどのように割り込ませるかを考えたうえで
  2. 場合によって全体のイメージを再構築する必要がある

それほど複雑ではない場合は部分的な再構築ですむのでそれほど最悪な気分にはならないが、全体を再構築する必要がありそうな場合は、頭の中を全部一旦空にするので再度全体の設計をロードしなおすまで時間がかかる。その間ずっとイライラしている。

どうすればいいのか

頭の中にロードする時間自体を短縮するのは難しそうなので、イメージのサイズを小さくするとか、予期できそうなことは予期しておくしかない? しかし予期できそうなことを予期しておくというのをやるとイメージのサイズが大きくなる。

そもそも何故頭の中のイメージが初期化されることでイライラするのか。

前提知識:レスポンシブ広告といっても、既定の広告サイズからコンテナサイズによって選ばれて表示されるだけで、広告そのもののサイズは固定です。

そのまま使うと、広告がロードされた時にページの高さの再計算が入って、コンテンツがガタガタと動いて大層鬱陶しいです。とりあえず便利そうだから貼ってみると、この挙動でギョギョっとします。

しかし、レスポンシブ広告はCSSで設定する width/height によって正確に対応する広告サイズを入れることができ、この場合は高さが固定になるのでガタガタしません。CSSなのでメディアクエリでサイズを変えられ、レスポンシブサイトと大変相性が良いです。

公式のドキュメントに詳細な設定方法が書いてあります。といっても width/height をコンテナに設定しているだけです。

既にサイトがメディアクエリによってレスポンシブになっているなら、レスポンシブ広告にした場合、広告サイズもCSSで指定するだけでよくなってます。

余談:Adsense の広告コードの修正・改変

「広告コードには一切の変更が認められない」みたいなことが過去に書いてあったような記憶があるんですが (記憶違いかも)、現状では上記の通り、改変が認められるケースがあり、悪意をもってやるようなことじゃなければだいたい大丈夫そうな雰囲気があります。

  1. トップ
  2. tech
  3. Adsense のレスポンシブ広告の正しい使いかた

ティファール 電気ケトル 「ジャスティン プラス」 シンプルモデル サーブル 1.2L KO340177 -

3.0 / 5.0

これの古いモデルをずっと(7年ぐらい)つかっていたが、底のステンレス部分が緑色に錆びのようなものができていて、さすがにどうかと思ったので買い替えた。

緑色の何かの正体はよくわからず。こすっても落ちないし使用頻度が高いのでカビではないと思うが、クエン酸を入れて沸かしてもとれなかった。

ティファール 電気ケトル 「アプレシア プラス」 コンパクトモデル メタリックノワール 0.8L BI805D70 -

3.0 / 5.0

これにした。沸かせる量が減ったが、1.2L 沸かすことがまずなかったように思えるので小さいモデルに。外装がプラスチックのものは嫌だったのでステンレスのものにした。燃費を上げるためか全体を金属にしたものはないみたいだった。

電気ケトルの電気料金

メーカーのページを見てみると、同じメーカーのほぼ同じモデルでも微妙に電気料金が違く書かれている。

例えば、アプレシアプラス(プラスチックモデル)では約0.44円/カップ1杯と書いてあるが、アプレシアプラスメタリックでは約0.50円/カップ1杯となっている。といっても、この差だと365回沸かしてようやく約22円程度の差なので誤差ではありそう。

なお、このメーカーの場合だとスペック上で最も燃費が悪いもので約0.56円/カップ1杯、最も良いもので約0.44円/カップ1杯と、0.12円の差がある。

ES2015 の iterable/iterator/generator による無限 FizzBuzz | tech - 氾濫原 に続いて、オブジェクト指向っぽく書けるようにしてみました。

ポイントはジェネレータ的なものをラップして常に It というクラスのインスタンスにするところです。

"use strict";

function It(iterable) { if (typeof this === 'undefined') return new It(iterable); this.iterable = iterable; }
It.countup = function* (n) {
	for (;;) yield n++;
};
It.prototype = {
	zip : function* () {
		const iterators = [];
		for (let it of this) {
			iterators.push(it[Symbol.iterator]());
		}
		for (;;) {
			const nexts = [];
			for (let it of iterators) {
				nexts.push(it.next());
			}
			yield nexts.map( (i) => i.value);
			if (nexts.some( (i) => i.done) ) break;
		}
	},
	map : function* (func) {
		for (let value of this) {
			yield func(value);
		}
	},
	cycle : function* () {
		for (;;) {
			for (let value of this) {
				yield value;
			}
		}
	},
	take : function (n) {
		const ret = [];
		for (let value of this) {
			ret.push(value);
			if (!(ret.length < n)) break;
		}
		return ret;
	}
};
It.prototype[Symbol.iterator] = function () { return this.iterable[Symbol.iterator]() };
{
	let wrapGenerator = function (generator) {
		return function () {
			const self = this;
			const args = arguments;
			const iterable = {};
			iterable[Symbol.iterator] = function () {
				return generator.apply(self, args);
			}
			return new It(iterable);
		}
	};
	let generatorConstructor = Object.getPrototypeOf(function*(){}).constructor;
	for (let key of Object.keys(It.prototype)) {
		if (It.prototype[key] instanceof generatorConstructor) {
			It.prototype[key] = wrapGenerator(It.prototype[key]);
		}
	}
}


console.log(Array.from(
	It([
		It.countup(1),
		It(["", "", "Fizz"]).cycle(),
		It(["", "", "", "", "Buzz"]).cycle()
	]).
		zip().
		map( (_) => _[1] + _[2] || _[0] ).
		take(30)
));
  1. トップ
  2. tech
  3. ES2015 の iterable/iterator/generator による無限 FizzBuzz (オブジェクト指向編)

表題の通りですが、Generator にはいずれの protocol も実装されています。気になるのは iterable の挙動ですが、どうやらレシーバーの Generator 自身を返すようです。

function* count (n) {
	for (;;) yield n++;
}

var c = count(1);
console.log(c.next, c[Symbol.iterator]);
//=> [Function: next] [Function: [Symbol.iterator]]

// iterator protocol
console.log(c.next()); //=> { value: 1, done: false }
console.log(c.next()); //=> { value: 2, done: false }
console.log(c.next()); //=> { value: 3, done: false }

// iterable protocol
console.log(c[Symbol.iterator]().next()); //=> { value: 4, done: false }

console.log(c[Symbol.iterator]() === c); //=> true

iterator protocol (next) で状態をすすめたあとに iterable protocol (Symbol.iterator) で iterator を取得すると、状態は継続されています。

  1. トップ
  2. tech
  3. Generator は iterator であり、iterable でもある

最近になって「関連コンテンツ」と「ページ単位の広告」というのが beta になって登場した。サイト最適化と同時にこれらも有効にしてみたりしていた。

関連コンテンツ

広告ユニットではあるが、サイト内の関連コンテンツを表示してくれるので普通に便利。先頭に2つぐらい広告が入る感じ。便利になるだけで収益にならないユニットなのかと思ったけど、ちゃんと収益にもなる模様。

パフォーマンスレポートを見てみても、他のユニットと比較してかなり収益性が高そう (このサイトの場合そもそも微々たるものだけど)

ページ単位の広告

「ページ単位の広告」という名前の中にさらに2種類ある。

「アンカー広告」はよくあるスマフォ向けの広告で、画面下を常時占領するタイプ。ただ、position: fixed で固定しているようで、JS の scroll イベントを奪っている系のウザさはないのが救い。

「モバイル全面広告」はときどきあるだいぶうざい全面広告に似ているが、ページを開いたときではなくて、次ページに遷移しようとするときに次のページをロードしながら表示される広告、ということになっているらしい。

ページのパフォーマンスと広告

明かなことだけど、Adsense を貼るだけで、おそろしくページのロードは遅くなる。非同期コードを使おうがページ全体の onload までの時間が伸びるのはどうしようもない。

たいして儲かるわけでもない Adsense を貼って遅くするのもどうかとは思うけど、Adsense なくしたらロード早いのは当たり前すぎるので、かえって意固地になって広告を貼りまくっている。遅くなっても儲かってくれるならいいんだけど

  1. トップ
  2. tech
  3. Adsense の新しい広告ユニット