Honoka v4.0.0 をリリースした

Honoka v4.0.0 をリリースしました。

もうなんやかんや Bootstrap v4.0.0 がリリースされてから久しいんですが、ようやく Honoka の v4.0.0 をリリースしました。大体の作業はG.W.で完了していたんですが、なんかいろいろと準備しているとこんな時期になってしまいました。

このことに関してはただの私の怠慢なので「ごめんなさい」と平謝りするとして、とりあえずこの記事では Honoka v4.0.0 の特徴と変更点を連ねていきます。

フォントウェイトを調整した

Bootstrap v4.0.0 では様々なフォントウェイト（文字の太さ）が登場します。確かに英語圏のフォントだと1つのフォントでもウェイトが最細の Tin から最も太い Ultra bold までそろっているのが多くて、実際 macOS のシステムフォント San Francisco という1つのフォントをとっても多様なウェイトがあります。使うウェイトによって受ける印象も変わるので使い方としては非常に効果的なのですが、日本語のフォントは多様なウェイトをサポートするフォントが多くありません。もちろん多様なウェイトを網羅したものも存在しますが、システムに標準でインストールされているようなフォントでこれをクリアしているものはほとんどなく、またブラウザのバグのような挙動などもあり(後述)、実質使えるのは標準と太字の2種類のみといってもいいでしょう。

Bootstrap v4.0.0 は英語圏の標準として作られているために、フォントウェイトが少なくとも 4種類 ほど登場していることを確認しています。これらの指定は日本語環境でみると、文章中の文字が突如太字になったり、効果的に使えていなかったりとチグハグした状態を作り出していました。

日本語フォントだけが2段階しかない

今回 Honoka ではそういったフォントウェイトに関する指定を再度見直して、見出しレベルでは太字、それ以外の部分では標準の太さを用いるようにしています。また日本語のフォントの文字の太さと英語のフォントの文字の太さに違いが出ないように調整も行いました。

游ゴシックをやめた

かねてから Honoka では標準の日本語フォントとして游ゴシックを使ってきていたのですが、 Windows + Chrome で游ゴシックがうまく扱えない問題があり、これを解決するための @font-face ハックについても自分の環境では効果がなかったので、あまり評判もよくなかったこともあり廃止することにしました。なので .no-thank-yu の効果はありません。

Ruby ライブラリ依存をやめた

SCSS のコンパイルや Lint などを Ruby ライブラリに依存していたのですが、パッチを送ろうとしてくれる方の開発の導入が煩雑になることなどを考えて libsass などをつかった Node.js ライブラリに移行しました。これにより npm i するだけで開発できるようになります。

Grunt.js やめて gulp にした

Honoka ではSCSSのコンパイルなどで使うタスクランナーとして Grunt.js を使ってたんですが、「時代じゃないよねー」という雰囲気を感じ取ったので、 gulp に乗り換えました。もっと言えば Bootstrap では npm scripts だけで全部やってるのでそれに習おうかと思ったのですが、流石にシェルスクリプトワンライナー芸はメンテナンスしづらいだろうということで今回も独自の路線に舵を切っています。

細かいことはこれから調整します！

ここは自分語りになるのですが、最近の自分の悪い癖として完璧を目指そうとしてしまうところがあるので「とりあえずリリースしようぜ」みたいなチャレンジの一歩を踏み出せなくなってしまっていました。今回も完璧を目指したばかりに「あれもこれも」というタスクが積み重なってデッドロック状態になっていたので良くないと思い、まだ細かい不具合はあるかもしれませんが勇気を出してリリースすることにします。

GitHub には要望を書く Issue や、パッチを送りつける Pull Request があるので、もし不具合や要望があれば遠慮せず送っていただければと思います！！！

ぜひ Honoka v4.0.0 をつかって楽しい Bootstrap ライフを！

生ハムに メロンをのせて API puppeteerで スクレイピング

おっと一句詠んでしまった

社会人になってから自由に使えるお金が増えて色々散財しているんですが、最近は薄い本を買い漁っていまして、もっぱら某アイドルアニメの全年齢系のものを買い集めています。

徐々にその量も増えてきていよいよ本棚に入らなくなってきたんですが、量が増えると何を持っていて何を持っていないのかがわからなくなってしまうので、台帳的なもので管理しようということで管理をはじめました。最初は Rails のプロジェクトにして… とか色々考えたんですが、そこまでフットワーク軽くなくて「完成が いつになるやら 法隆寺」とまた一句詠んでしまったところで、一旦 Google スプレッドシート上にまとめることにしました。

本の管理はきちんとできていればリストをみるだけで持ってたか持ってなかったか一目瞭然で便利なのですが、そもそも管理を始める前に懸念していたこととして「そのうち入力が面倒で更新しなくなるんじゃないか」ってことでした。実際1冊あたりの情報項目自体はそんなに多くはないですが、イベントとかがあるとそれをまとめて更新しないといけなくなるので、まあ10冊とかでも結構な重労働だったりするわけです。

でもまあしかしながら幸いにも最近は某果物系の名前がついた委託販売サイトで買うことが多いので、入力したい内容のデータはインターネット上に公開されています。となればやりたくなるのはウェブページ上からそれらの情報を台帳に自動で取ってくることです。

CloudFlareをDDNSで使うためにDDclientのDockerイメージつくった

どうでもいい個人的な話から入ると、私がDDNSサービスというものに出会ったのは中学生の頃にDynDNSを使用した頃が最初出会ったと思う。いまでこそ有料会員にならないとまともに使えないサービスになってしまっているが、その頃は無料会員でもいろんなサブドメインを使用することができたので、ドメインを複数持っていなかった私はサブ垢までつくって色々取得していたように思う。

まあその辺の話はさておき、 CloudFlare というDNSサービスがある。無料でも込み入ったことさえしなければその辺のドメインレジストリが提供している無料DNSよりは高機能なので、私が所持しているドメインのほとんどのプライマリ DNS を CloudFlare にしている。しかも CloudFlare は API も充実していて大体の設定は RESTful な感じで設定することができる。つまりその API を使えば、実質的な DDNS を行うことができるので、いくつかのDDNSクライアントが CloudFlare に対応しており、 DDclient というソフトウェアもそのうちのひとつである。

DDclient は結構昔からある DDNS 用のクライアントソフトウェアで、もっぱら Linux のサービスとして動かすことを想定した解説記事などを見るのだが、時代は「cgroups だ！」「Docker だ！」という感じなので、どうせ Docker 化されたイメージが Docker Hub にあるんじゃないかとおもって探したのだがちょうどいいのがなかった。

• linuxserver/ddclient
  • 設定ファイルを吐き出す Volume の持ち方があんまりイケてない
  • DDclient 側の問題だが起動するとマウントした設定ファイルのファイル所有者とパーミッションを変更する
• outcoldman/docker-ddclient
  • 環境変数から設定できるのは Good だが CloudFlare で必要なパラメータの設定(zone)ができない
  • あとベースイメージが Ubuntu で無駄にイメージサイズが重い

これ以外にもいくつかあったのだが、面倒なので自分で作った。

ベースイメージはめちゃくちゃ軽い library/alpine で、DDclient が依存する Perl 関連のパッケージをいれるのに結構四苦八苦している。

DDclient の設定は環境変数からも設定ファイルマウントでも行うことができる。設定ファイルマウントを Read only にすることで、パーミッションの変更をむりやり抑制することができることに気づいた。

docker run -d \
  -e DDCLIENT_ZONE=example.com \
  -e DDCLIENT_PROTOCOL=cloudflare \
  -e DDCLIENT_SERVER=www.cloudflare.com \
  -e DDCLIENT_LOGIN=login-email-address@example.com \
  -e DDCLIENT_PASSWORD=your_api_key \
  -e DDCLIENT_HOST=ddns-host.example.com \
  windyakin/docker-ddclient

docker run -d \
  -v /path/to/ddclient.conf:/etc/ddclient/ddclient.conf:ro \
  --entrypoint ddclient \
  windyakin/docker-ddclient

実際に自分のサーバーでつかっているがいまのところ困ったことはなくて良い感じ。

社会を生き抜くためには「ラブライブ！ Dash Button」が必要だ

これは ラブライブ！ Advent Calendar 2017 25日目の記事です。

前回のラブライブ！

ネットサーフィンをしているとよくみかける Amazon Dash Button と Raspberry Pi の組み合わせをやってみたくなった私は、Amazon Dash Button (PANTENE) と Raspberry Pi 3 Model B を買いました(これが1年ぐらい前)。買った当時はてきとーに Node.js をつかって「ボタンを押したらイベントが発動する」だけの実装をしたんですが、それで満足してしまったのともともと特に計画もないまま買ったものなのでそのまま部屋の片隅に放置されていました。

ところで私は家で酔っ払うと、しょっちゅう μ’s Live Collection を引っ張り出してきてはひとり鑑賞会を始める癖があります。μ'sのライブ演出は何度見ても見飽きない面白さがあると思います。

ラブライブ! μ's Live Collection [Blu-ray]

ある日、その日も飲み会帰りで酔っ払っていたため、ひとり鑑賞会をしていたのですが、そのときふと部屋の片隅に放置された RasPi が目に入ったわけです。

「ボタンひとつでライブ映像が見れる環境が欲しい！」

というわけで、Raspberry Pi と Amazon Dash Button を連携させて「ラブライブ！ Dash Button」を作ることにしました。

ここ数年のらりょすの雑コラ界、または雑コラが与える一般世間への影響について

この記事は らりょす Advent Calendar 2017 の1日目の記事です。

私はらりょす雑コラ界の端くれとしてよくらりょすの雑コラを作っています。はじめたきっかけは特にありません。Twitter を見ていて流れてきた会話とかから「このシチュエーションを画像にしたら面白いんじゃないか」みたいな思いつきではじめたようにおもいます。

さて、話は変わりますが、2年ほど前に Tumblr 上にらりょすの雑コラを集積するページを作ってたんですが、らりょす本人がアカウント更新を休止していた（とはいっても時たま動いていたが）時期もあったりしたため、2年前を最後に更新が止まっていました。しかしながらこの度 らりょす Advent Calendar があるということで、せっかくの機会なので更新をさぼっていた2年ほどの雑コラ画像をまとめなおしてみました。

raryosu-zatsucolla.tumblr.com

それぞれの画像については各記事のDescriptionをみてもらうことにして、改めてこの2年を振り返ってみると、らりょす雑コラ界のターニングポイントも多かったなと思いました。

というわけで今回はここ2年の間にらりょすの雑コラ界で起きた大きなできごとを振り返ってみたいなと思います。