JSなしのソーシャルボタンというのを作ってみました。このサイトの各エントリ下部に実装されているものです。

動機

各サービス、JS を読みこんでボタンを表示するタイプのものをメインに提供していますが、ソーシャルサービスへのシェアという機能で外部リソースの読み込みとJSの実行が発生するのは、提供される機能に対して割に合わないのではないかと思っていました。

実際ウェブサイトのパフォーマンスチューニングをしていると、細かいボタンのJSのダウンロード・パース・実行・表示後のリフローが結構多くて気になります。

実装

サービス

  • Facebook
  • Twitter
  • Google+
  • LINE
  • はてなブックマーク

HTML+CSS+各サービスのアイコン画像(5つ)です。

各サービスのアイコンをSVGにしたかったのですが、各サービスのブランドガイドラインを読んでいると面倒になったのでオフィシャルなものを使っています。オフィシャルにSVG版が提供されていれば悩まないんですが、はてなブックマークしか提供していないようでした。

使っている画像はオフィシャルのものですが、さらに optipng や svgo をかけてあります (一部の画像にしか効きませんでしたが)。

LINE it! はスマフォかつアプリが入ってないと機能しません。JS版のボタンはスマフォの場合だけ出すような判定も入っているようです。テストページでは出しわけをしていませんが、このサイト内では画面サイズが小さいときだけ出るようにしています。

  1. トップ
  2. tech
  3. JavaScript の必要ないソーシャルボタン

国産原料、国内生産のグリシン1kg 【3gぴったり計量スプーン付き】 -

4.0 / 5.0

毎日寝る前に飲んでみてる。そんな期待してなかったけど、寝起きは確かに多少良くなった。元々ものすごく寝起きが悪いので少しマシになった程度だと思う。

ただし、短い睡眠時間を補うようなものではないので、睡眠時間が短いとあまり変わらずただただ眠い。どうしようもない。

https://buffer.com

buffer というのをちょっと使ってみようとしています。予め Facebook / Twtter などを接続して、スケジュールを設定しておくと、buffer 経由で投稿したときにいい感じにマルチポストするというツールです。

スケジュールの設定がおもしろくて「このサービスはこの時間帯に投稿すると効果がたかいぞ!」みたいなことをサジェストしてくれて、それを時刻に設定できます。

buffer への投稿自体は chrome 拡張経由で手動でやってみています。

使い続けるかはよくわかりませんが、現在 Twitter とか Facebook を見ないようにしているので、buffer のような別サービスを挟んでおけば、うっかり見ることも減って良さそうです。

  1. トップ
  2. tech
  3. ソーシャルサービスに一括でして予約投稿してくれる buffer

そういえば なんとなく思いたったので Twitter 使うのをやめてみ… | Mon, Feb 15. 2016 - 氾濫原 というエントリを書いてから2ヶ月ぐらい経ってました。意外と見ないと決めてしまえば見ないものです。

最初の一ヶ月ぐらい twitter.com, www.facebook.com, b.hatena.ne.jp を /etc/hosts を使ってブロックしていましたが、twitter.com と www.facebook.com はそんなことしなくても案外見ないのでブロックするのをやめました。b.hatena.ne.jp はうっかり見たい欲求にかられることがあるので、PCによってはブロックしたままにしてあります。

あたり前ですが Twitter や Facebook 由来のストレス(けまらしい感・バカにされている感)と時間の浪費はなくなったので、その点はいい感じです。代わりにそれらよりは多少生産的なこと (日記とか) に時間を消費している気がします。


精神の安定のため、内在的かつアウトプットを増やそうというのが自然にできるようになるといいなと思っています。

  • モチベーションは内在し、無限に沸いてくる
    • 必要なのは沸いてくるものを守ることだけ
  • 幸福感は内在する
  • 「アウトプットした」という事実が幸福感を生むはずだ
  • 昨日より少しだけでも進歩することを繰替えすことが、のちに振り替えったときに幸福感を生むはずだ

誰かに褒められれば嬉しいのは確かだけれども、それは直接次のモチベーションには繋がらないし、「誰かに褒められる」ことよりも「誰かに貶される」という期待値のほうが圧倒的に高いので、そういう場は精神を不安定にするだけで割に合わないという判断にまとめています。

あんまりスター付かないので気付いてなかったのですが、Chrome 拡張の「はてなのお知らせ」とかに通知がこなくなっていることに気付きました。

おそらく「HTTPS にしたこと」というより、http: から https: に URL が代わったことにより Hatena.Star.Token の更新が必要なんだと思います。が、s.hatena.ne.jp/cho45/blogs にログイン状態でアクセスすると現状タイムアウトしてしまうので、詰んでいます。

HatenaStar.js を読んでて気付いたのですが、

Hatena.Star.Token = null;

がベタに書いてあるため、async と併用するとそもそも Token が初期化されてしまうようでした……

HTTPS とか関係なかったです。HTTP ではてなスターに登録していても、リダイレクトしているなら、リダイレクト先の Token を読んで判断するようです。

しかしHTTPSにしたことによって過去のスターが消えてそうなことに気付いたので、どうしようか考えています。

結局にっちもさっちも行かないことがわかったので、HatenaStar.js のコピーを編集して使うようにしました。

はてなスターに渡すURLは http: に戻しました。HTTPS になってからついたスターが表示されなくなってしまいますが (申し分けないのですが)、HTTP のときについたスターは復活するはずです……

まぁそもそも、そろそろはてなスター止めてもいいかもしれないんですが、もうちょっと頑張ってみようという感じです。

--- HatenaStar.orig.js	2016-04-15 23:11:20.355944766 +0900
+++ HatenaStar.js	2016-04-15 23:11:34.687944255 +0900
@@ -4655,7 +4655,39 @@
 
 
 /* start */
-new Hatena.Star.WindowObserver();
+// new Hatena.Star.WindowObserver();
+
+Hatena.Star.Token = '7743b0e60f0e3b267f9723d3a5cf96981a59e4f3';
+Hatena.Star.EntryLoader.loadEntries = function (node) {
+    console.log('custom EntryLoader');
+    var entries = [];
+    var entryNodes = node.getElementsByTagName('article');
+    for (var i = 0, entryNode; (entryNode = entryNodes[i]); i++) {
+        var uri = entryNode.querySelector('a.bookmark').href || '';
+        var title = entryNode.querySelector('h1').innerText;
+        var container = entryNode.querySelector('.social .hatena-star');
+
+        var sc = Hatena.Star.EntryLoader.createStarContainer();
+        container.appendChild(sc);
+        var cc = Hatena.Star.EntryLoader.createCommentContainer();
+        container.appendChild(cc);
+
+        entries.push({
+            uri: uri.replace(/^https:/, 'http:'),
+            title: title,
+            star_container: sc,
+            comment_container: cc
+        });
+    }
+
+    console.log('custom EntryLoader loaded', entries);
+
+    return entries;
+};
+
+window.addEventListener('load', function () {
+    new Hatena.Star.EntryLoader();
+});
 
 /* Hatena.Star.SiteConfig */
 /* sample configuration for Hatena Diary */

[tech] JavaScript の必要ないソーシャルボタン | Fri, Apr 15. 2016 - 氾濫原 これを作るとき、最初のうちは全てSVGにするぞと意気込んでいて、Ligature Symbols に含まれるものをSVGに変換したらいいのではないかと、いろいろ試していました。

結局その方法はやめたのですが、SVG フォントから、個別の SVG ファイルに変換するスクリプトを雑に書いたので残しておきます。SVG フォント全体だとファイルサイズが大きすぎるので、必要なファイルだけ普通の SVG 画像として抽出するということです。

以下のように perl + XML::LibXML で書きました。グリフ名を引数に与えると、該当するグリフを個別の .svg に書き出します。LigatureSymbols でしか試していませんが、SVG フォントなら他のでもいけるかもしれません。

#!/usr/bin/env perl

use utf8;
use strict;
use warnings;
use v5.10.0;
use lib lib => glob 'modules/*/lib';

use XML::LibXML;

open(my $fh, "<", "LigatureSymbols-2.11.svg") or die "cannot open < input.txt: $!";
my $font = do { local $/; scalar <$fh> };
close $fh;

my $doc = XML::LibXML->load_xml( string => $font, load_ext_dtd => 0 );
my $xpc = XML::LibXML::XPathContext->new($doc);

# get copyright metadata
my $original_metadata = $xpc->findvalue('/svg/metadata');
my $units_per_em = $xpc->findvalue('/svg/defs/font/font-face/@units-per-em');
my $ascent = $xpc->findvalue('/svg/defs/font/font-face/@ascent');
my $bbox = $xpc->findvalue('/svg/defs/font/font-face/@bbox');

for my $glyph_name (@ARGV) {
	my $glyph = $xpc->findnodes(sprintf('/svg/defs/font/glyph[@glyph-name="%s"]', $glyph_name))->[0];
	my $horiz_adv_x = $xpc->findvalue('./@horiz-adv-x', $glyph);

	my $document = XML::LibXML::Document->new('1.0', 'UTF-8');
	my $svg = $document->createElement('svg');
	$svg->setAttribute('width',  $horiz_adv_x);
	$svg->setAttribute('height', $units_per_em);
	# $svg->setAttribute('viewBox', $bbox);
	$svg->setAttribute('xmlns', 'http://www.w3.org/2000/svg');
	$document->setDocumentElement($svg);

	my $metadata = $document->createElement('metadata');
	$metadata->appendChild($document->createTextNode($original_metadata));
	$svg->appendChild($metadata);

	my $path = $document->createElement('path');
	$path->setAttribute('transform', sprintf("scale(1, -1) translate(0,%s)", -$ascent));
	$path->setAttribute('fill', '#fff');
	$path->setAttribute('d', $xpc->findvalue('./@d', $glyph));
	$svg->appendChild($path);

	warn "write to $glyph_name.svg";
	say $document->toString(1) ;

	open(my $fh, ">", "$glyph_name.svg");
	print $fh $document->toString;
	close $fh;
}
  1. トップ
  2. tech
  3. SVGフォントのグリフを個別のSVG画像に変換する

ずっと中途半端なデザインだなと思っていたので、改めて全体を見直しました。

大きい画像は devicePixelRatio に基いて大きい画像をロードするようなスクリプトを書いていたのですが、面倒なので最近になって常に 2048px の画像を読みこむように変えました。

しかし画面の表示は 960px 程度を最大にしており、Retina でも若干の無駄があるのが気になってきました。ということで、まず 1024px を最大幅にできるようにしました。

しかし、意外ともう少し狭い幅で見ることも多い気がするので (特に開発ツールを横に開いていると結構画面が狭い)、その場合幅だけ変えたバージョンをメディアクエリでだしわけしています。

スマートフォン向けにはさらに狭い幅向けのバージョンをメディアクエリでだしわけていますが、これはほぼ今まで通りです。

また、大きい画面の場合、photo タグが設定されているエントリと、それ以外のエントリで画像の幅を変えるようにしました。tech カテゴリでも無駄に横幅が大きい画像になっていて一画面の情報量が少なかったので、これで見易くなった気がします。

しかし、テキストの幅を制限しつつ画像は大きく表示したいと思うと、自分のデザイン能力だと綺麗にいかず難しく感じます。

  1. トップ
  2. tech
  3. デザインの調整

STM32F103 C8 T6 の安いボードが ebay で売っているので買ってみました。水晶が実装済み基板が 300円程度。届いたボードに実装済みの外部水晶は8MHz (内蔵RCと周波数は一緒) のようです。また 32.768k の水晶もついています。他に実装されているのはLDOやUSBコネクタぐらいです。

なお USB デバイスを作りたい場合 RC オシレータだとクロック精度が足りないので外部水晶は必須です。

買ったのはこれです: http://www.ebay.com/itm/201529768817

型番について

STM32F103 C8 T6 という型番の読みかた

  • C: 48pins
  • 8: 64kbytes Flash
  • T: LQFP パッケージ
  • 6: -40〜85°C

をあらわしています。STM32F103x8 (64k) や STM32F103xB (128k) はスペックシート共通になっています。 (ピン数とFlashのサイズの違いのみなので)

特徴

以下個人的に良さそうと思った点です。

  • STM32F103 は USB 1.1 FS (フルスピード=12Mbps) に対応している
  • ADC が2つある (チャンネル数は10)
    • 同時サンプリングができそう

Cortex-M3 なので M0 よりはパフォーマンスが良さそうです。一方 FPU や DSP 関係の命令 (SIMDとか) は M0 同様ありません。

クロック

SYSCLK (システムクロック) は

  • HSI
    • High Speed Internal ?
  • HSE
    • High Speed External ?
  • PLL

の3種類のクロックソースがあります。

HSE はさらに HSE バイパスと HSE クリスタルとに別れています。バイパスは発振器のクロックを直接入れるモードです。

PLL のクロックソースにはHSIとHSEがどちらも使えるようになっています。

このボードの場合

8MHz の外部水晶がついてるので、8MHz の HSE を PLL のクロックソースとして 72MHz にします。USB 用のクロックもここから作ることになっています。

  • PLL 入力クロックソースは HSE、分周なし
  • PLL逓倍を9倍に (8 * 9 = 72MHz)
  • USBプリスケーラは1.5に (72MHz / 1.5 = 48MHz)
  • APB1 は2分周 (72MHz / 2 = 36MHz)

みたいになりそうです。が、とりあえず mbed 環境で動かしてみるためクロック設定は無視します (mbed 側で 72MHz に適当に設定されます)

書きこみ (Lチカ)

例によって環境を整える部分は platformio でやります。

platformio.ini は以下のようにします。nucleo_f103rb は型番違いですが、ほぼほぼ互換性があります。nucleo_f103rb の外部水晶も 8MHz のようで、この場合 mbed の初期化コードは一切変更なしでいけそうです。

本来 boards の追加をもっと簡単にできたらいいのですが、現状の platfromio だとそういうことはできなそうです。

# platformio.ini
# nucleo_f103rb は f103c8t6 とフラッシュサイズとピン数以外は互換
# 外部クロックも 8MHz で同じのためそのまま使える
[env:stm32f103c8t6]
platform = ststm32
framework = mbed
board = nucleo_f103rb

Lチカはこのようにしました

#include "mbed.h"


DigitalOut led(PC_13);
// Serial serial(USBTX, USBRX);


int main() {
	for (;;) {
		led = 1;
		wait(0.5);
		led = 0;
		wait(0.5);
	}
}

PC_13 はボード上のLEDに繋がっています。nucleo_f103rb だと LED1 は PA_5 のようなので、ジェネリック名ではなくピン名で直接指定しています。

書きこみはこれまた ebay で購入した st-link2 を使いました (約400円)。Mac の USB ポートに繋ぐと特に何もしなくても認識するようでした。

ボードと st-link を接続して、USB 接続すると、基板上にも電源供給されます (別途電源供給はいらないようです)

書きこむためまず st-util を起動します。platformio で ststm32 環境をセットアップしておくと st-util もインストール済みのため楽です。

$ ~/.platformio/packages/tool-stlink/st-util
2016-04-14T00:48:41 INFO src/stlink-common.c: Loading device parameters....
2016-04-14T00:48:41 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
2016-04-14T00:48:41 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2016-04-14T00:48:41 INFO gdbserver/gdb-server.c: Chip ID is 00000410, Core ID is  1ba01477.
2016-04-14T00:48:41 INFO gdbserver/gdb-server.c: Target voltage is 3254 mV.
2016-04-14T00:48:41 INFO gdbserver/gdb-server.c: Listening at *:4242...

こんな感じで gdb server として立ちあがります。

別のターミナルから gdb server に接続してバイナリを送りこみます。

$  ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-gdb .pioenvs/stm32f103c8t6/firmware.elf 
> target extended-remote localhost:4242
> load
> cont

これでLチカできました。

ref

  1. トップ
  2. tech
  3. STM32F103 C8 T6 の安いボードでLチカ (platformio + mbed)

あいかわらず断続的に体調不良。一日会社を休んで寝てたら回復した気がしたが、また腹痛になった。吐き気はしないのでまだマシ。

ここ最近、夜中に子供がうんちしていることがあって、いざ寝ようと思うと寝室がめっちゃ臭い。子供もおそらく胃腸炎を完治してない気がする。食欲はかなりあるみたいだけど、本調子ではないのだろう。


基本的にストレスが多いのだけど、ストレスが多くなると些細なことにイライラしてさらにストレスを増やしてしまう。一方で捌け口が自分の場合ほとんどないので、どうしようもない。

直近で気が重かった仕事が一旦出て、それは良かったのだけど、出たは出たで次は何をするのかと考えると気が重いので、無限に気が重い。


「スケジュール」について考えると気がとても重くなるのだけど、実際に全体のスケジュールを決めてる人は不思議と前工程のスケジュールをさっぱり守らないので、自分が気を揉むようなことではないはずだと思う。一方スケジュールのことを無視して言われたベースでやってると「やってないんですか」みたいなことになって鬱陶しいし、なんかとにかく何をどうしても嫌な気持ちになるしかない感じがする。


保育園のナニカみたいなのが一年たってだいたい終わったんだけど、自分の役職だけまだ仕事があって、とてもだるい。なんか数秒喋るだけのために1時間か2時間拘束されるハメになる。これが終われば終わりだから我慢しよう。それにしても保育園関係のナニカは本当に不愉快だった…… これは本来「無償ボランティア」の範疇にあることだが、それは名ばかりで強制力がある。責任()というやつです。直接子供のためになるならまだしも、クソどうでもいいこと (進級時に先生にお礼をしましょう、みたいなの。個人的には心底どうでもいい) が実際殆どであった。「無償ボランティア」なうえ特にモチベーションもないので、必然的に優先順位は最下位なのだが、やたらごちゃごちゃ言われて本当に辛かった。得るものがほぼないのに時間がとられる、死にたくなるほど割に合わない。保育園のナニカと比べれば普段の仕事は大変良くて、周りの人は会話が通じるし、効率的なやりかたをしようという前提が共有されている。

JS しか書いてないんだなって人は筋悪いものをありがたがっていたりする印象はある。しかし筋悪いものをありがたがるみたいなのはどこにでもいるので、JSがどうとかは直接は関係がないはずではあると思う。JSしか書いてない人とPHPしか書いてない人は似たようなもんで、単に広範囲の知識に興味がないだけな気がする。

それはともかく「これは筋悪そうだな」っていう感覚がどこからくるのかよくわかってないので、現時点で思いつく限り雑にメモしておく。

割の合わなさ

「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。

フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。

将来性のなさ

「あ、これはただの流行だな」みたいな、5年後には消滅してるなというものは筋が悪い。

標準にそういう機能入るよ、みたいなのを全然違うインターフェイスで実装してたりするのとかがあてはまる。標準で議論されている機能なら、ポリフィルにするのが最も将来無駄にならない。

HTTP2 に向けてキャッシュフレンドリーなリソース構成にしていこうな、という昨今で、何でもかんでもパックや!みたいなのも、今はぎりぎりいいかもしれないけど、既に筋悪い感じがする。

プログラムの見方を変えないラッパー

たとえば Promise はコールバックのちょっとしたラッパーぐらいの機能しかないが、プログラムの見方を変えるという重要な役割を持っているので、意味がある。

しかし単にシンタックスシュガー的なものしか提供していないとかで、何もプログラムの見方が変わっていないのにラッパーがかぶさっているのは、ライブラリとしての意味がない。

「プログラムの理解を助ける」という役割はとても重要だけど、そういう視点で作られているライブラリかどうか、それが割に合うかは難しい。

しかし最悪なのは書き手にとってしかメリットがないというもの。特に実装を全て読まないと使えない系は要注意で、そういう書き手のオナニーで変なラッパーが挟まってるみたいなのは読み手がとても苦労する。これはメリットがないというよりも明確に将来にわたって害となる。

ただし実装を全て読まないといけないものが全てだめかというとそういうわけでもない。実装は読まないと危険だけど可読性はあがるので割に合うこともある。

フルスタック

フレームワークのレールから外れた瞬間アホみたいなマジカルコードを書くことになる。レールから脱線すると必ずハマる。そしてフレームワークの枠組み内で収まるようなアプリケーションはない 。

もし使う場合コピペで実装できる以外のことをしないことがポイントで、「ここはこう書きたいんだ!」という自我を捨ててコピペする機械として生きなければならない。

実際のフルスタックというのは検索して出てきたstackoverflowのコピペで全部やりますよという意味で、なんでもできるという意味ではない。

  1. トップ
  2. tech
  3. 筋の悪さ

意外と何をプッシュすべきか悩んだのでひとまず現時点での自分の結論をまとめました。

CSS は必ずプッシュ・JSは場合による

サイトの構成によりますが、ページの表示に必要なものは全てプッシュするべきのようです。

  • CSS の全て
  • ページの根幹に関わるJSの全て

サーバプッシュの目的

まずサーバプッシュの目的を改めて確認しておくと、これはクリティカルレンダリングパスを削減するためです。

クリティカルレンダリングパスについては クリティカル レンダリング パスのパフォーマンスを分析する | Web Fundamentals - Google Developers がわかりやすいです。

サーバープッシュなしの場合 HTML+CSS 構成のページはクリティカルレンダリングパスが必ず2以上になります。つまり最低でもRTTの2倍の時間がページ表示に加算されます。

これをサーバプッシュで行う場合、HTML+CSSを一度に送り返すので、クリティカルレンダリングパスは1になります。

イメージとしてはHTML内の外部CSSが全てインライン style 要素にしてある場合に似ています。ただしサーバプッシュの場合、適切なキャッシュを効かせることができるケースがあるので、インライン style 要素よりも効率的です。

JSをプッシュすべきか

これは場合によると思っています。JSがないとページの表示に致命的な不具合がある場合、サーバープッシュしないと意味がありません。

一方、JS がページのインターフェイスの向上のために使わていて、とりあえずの表示に関係がない場合、JS をプッシュした分、ファーストペイントが遅れます。

そういうわけでなので、JS をプッシュすべきかどうかは場合によるので簡単に決められない気がしています。

理想のサーバープッシュ

理想のサーバープッシュを考えるにあたって、ロードされるリソースの分類をしてみます。

クリティカルリソース (ブロッキングアセッツ)

ファーストペイントのために必要なリソース

  • CSS
  • ブロックする JS (async/defer のない script 要素)
  • HTML

DOMContentLoaded リソース

DOMContentLoaded までに必要なリソース

  • defer された script

onload リソース

onload までに必要なリソース

  • 画像
  • async された script

どうプッシュするか

最終的に必ずロードされるリソースなら、プッシュしてしまっていいはずです (初回ロードの場合)。

  1. クリティカルリソース
  2. DOMContentLoaded リソース
  3. onload リソース

の順に全てプッシュするのが理想そうです。ただ、現時点で任意の順番に優先順位を明確に決めて送信することはできないような気がしてます。

  1. トップ
  2. tech
  3. HTTP2 で何をサーバープッシュすべきか

たとえ明かなバグ修正、すなわちマージされる公算が大きくても、些細なことでケチがついたりする。これがさらに機能追加みたいな「マージしてもしなくても本流には関係ないね」みたいなのは、マージされる公算がさらに低くてさらに気が重い。

まずプルリクエストを送るケースってのは、別にプルリクエストを送りたくてやってるわけではなく、そのプルリクエストに含まれるコードが自分に必要だからやってるに過ぎない。つまり最悪自分のレポジトリに置いておけばいいのだが、本流に取り込まれていれば今後のバージョンアップで機能が壊れることが減る (ついでに他に困ってる人がいたら助かるかもしれないね)。そういう保守的なモチベーションで動いていることであって、元気良くプルリクを送っているわけではない。

そういうわけで、大抵の場合プルリクエストを投げた時点で「XX だ! とか言われてDISられそうだ」とか「コードスタイルがあってない!!とか言われてリジェクトされないか」とか「オレのところだとテストが通らん!とか言われないか」とか気が滅入る妄想に支配され、燃えつきており、あとはもう勝手にしてくれ (コミュニケーションはしたくないぞ) という気分になっている。


最近良くあるのが、プルリクエスト送る前にコミュニケーションしろ!みたいなルールを強いているプロジェクトで、こういうのはほんとどうしようもない。死ぬほど困っているとか、仕事でやるとかじゃないならプルリク送る気がしない。コミュニケーションしたくないからコード書いてプルリクしてんのに、コミュニケーションを強要してくるのはどういうことなのか。かつて github に感じた居心地の良さはここにはない。

  1. トップ
  2. tech
  3. プルリクエストを送るときは大抵気が重い。

サボさんいい

「ワンワンパッコロ!キャラともワールド」でワンワンとサボさんが共演する夢の回があって、サボさんがダンソン(バンビーノ)をやっていた。この番組、全体的に子供には難しいネタが多い。改めて見るとお笑いって常識(お約束)を裏切る形のパターンがよくあって、そもそも常識のない子供はいつから笑えるようになるのだろうと思った。