各記事の一枚目の画像をカバー画像とみなすようにして、関連記事にサムネイルを表示するようにしてみた。画像があるだけで記事をクリックしてみたい感が高まると思う（残念ながら Google Analytics で見る限り直帰率は改善してない）。人間は、文字だけを読むよりもイラストや画像など視覚的な情報を一緒に見ることで物事の理解度が高まると本で読んだ。自分で過去記事を読み直していても画像があると関連記事をクリックしてみたくなるし、満足感のある改修だった。
なおカバー画像の判定処理は記事本文を読み込んだ上で正規表現で調べているので多分重い（ベンチマークを取ったらタイトルを表示する処理に比べて二倍くらい遅かった）のだけど、関連記事表示部分はキャッシュしてるのでそんなに体感速度は悪化してないはず。
2018 年から 2019 年にかけてよく挽肉料理を作って食べた。最初はキーマカレーから入って餃子になり、最終的にはラザニアに落ち着いた。ラザニアを作るようになってからはラザニアしか作ってなかったが、餃子アドベントカレンダーというものを発見して久々に餃子を作ってみたくなったので餃子を焼いた。低所得ゆえ餃子の名店食べ歩記などではありません。一般人の普通の餃子に関する考察です。
続きを読む
会社の飲み会とかであれば参加するけど、基本的に外で酒を飲むのをやめた。厳密には 3 ヶ月に一度くらいは行ってるかもしれないけど、以前月 2 回くらいのペースで飲みに行ってたのをやめた。主に理由は二つあって、金がもったいないと感じるようになったのと、はちゃめちゃに飲んで二日酔いになり、翌日半日くらい使い物にならないのがもったいないと思うようになった。おっさんになると酒の飲み方が尋常じゃなくなって、自分はそんなに飲まなくても一緒に飲みに行くおっさんたちがめちゃくちゃ酒飲みだとこちらもつられて飲んでしまって、二日酔いにはなるし金はなくなるしで全くいいことなかった。飲んでるときは楽しくてわーわー騒いだり愚痴を言ったりしてすごく生産的な時間を過ごしているような気がするんだけどそれは全て幻想で、翌日は寝不足でズキズキと頭が痛み、仕事の日だろうが休みの日だろうが半日くらいは頭が使い物にならず無為に時間を過ごしてしまう。老い先短いのだから時間は有効活用しなければならないと思って、飲みに行くのをやめた。
とは言っても家では普通に缶ビール一本程度を飲むし、何なら仕事の帰りに缶ビールを買って電車待つ間に飲んだり、仕事帰りに海岸に行って飲んだりしてる（クズっぽい）。ただ一晩で何千円も飲み代に使うような酒の飲み方をやめた。
かわりといってはなんだけど、最近は昼ご飯を会社の人たちと食べに行くようになった。毎日外に食べに行くと飲みに行くのと同じくらいお金がかかってしまうけれど、一回 600 円とか 700 円くらいの外食を週に一、二度やるくらいだったら一月で 5000 円くらいにしかならないし、それで親交を深められたら安いものだと思う。二日酔いにもならないし。
というわけで今年やってよかったのはむやみやたらに酒を飲みに行くのをやめたことでした。
この記事は 今年やってよかったこと Advent Calendar 2019 2 日目の記事でした。
2018 年末に NIKON Z6 を買った。その前は NIKON D90 を 10 年近く使ってた。 NIKON D90 で撮れる写真にあまり不満はなかったが、フルサイズへの憧れと動画性能のしょぼさ（静止画は D90 の方がよいものが撮れるが、動画は明らかに iPhone の方がよいものが撮れた）に困っていて買い換えを決意した。人生で初めて新発売のカメラを発売前から予約して購入した。 48 回分割払い。
NIKON Z6 の良さは色々ある。通し F4 で撮れる 24-70m レンズ（レンズキットを買った）、 ISO 感度の高さ、チルト液晶、奥行きにも対応したデジタル水準器、 SnapBridge 対応（スマートフォンの GPS を利用した位置情報埋め込み、撮った写真をすぐに Bluetooth でスマートフォンに送れる）などなど。スマートフォン時代に対応するための正統進化という趣がある。 NIKON は真っ当ないい製品を作ったなと思う。
というわけでまずは NIKON Z6 で撮った写真からご覧下さい。そのあとに iPhone 7 で撮った写真で今年を振り返ります。
続きを読む
Day One が Markdown をやめて WYSIWYG に移行した話は前書いた。
自分が知っている範囲でアンチ Markdown 勢は Scrapbox くらいしか思い浮かばず、 GitHub や Trello などのグローバル勢に加え、 Qiita やはてなブログなど日本国内向けのサービスでも当然のように Markdown が共通言語として使われているのに、その Markdown を捨てて WYSIWYG 化する1という戦略は疑問だった。
ひとむかし前の WYSIWYG は最悪で、Word での文書作成や Google Docs にも良い思い出がない。とにかく文章が書きにくい不自由なツールだった。
一方で、お洒落な UI で話題になった Notion を使ってみると Markdown の要素を残した WYSIWYG だった。 Dropbox Paper も Markdown 風 WYSIWYG 、 Slack も最近段階的に WYSIWYG 化しつつある。
どうやら WYSIWYG の波が到来しつつあるようだ。
エンジニアやデザイナーなど、 HTML を理解している人からしたら Markdown は簡単だが、そうでない人には難しい。組織内に非エンジニア・非デザイナー（ HTML を書けない人）が増えてくると、途端に社内ドキュメント管理ツールがカオス（ ・ や全角空白 で装飾された文書が氾濫）になる。
プレーンな Markdown では、リストの概念や文書を構造化するということに対する理解がないと読みやすい文書は書けない。プレーンテキストベースの Markdown には読みやすく構造化された文書を書けるようになることを助ける仕組みが欠落している。
Slack は DAU が 1200 万を超えたらしい。もはやエンジニアだけのツールだけではなくなってきているようだ。
チャット、 Wiki 、社内ブログ、タスク管理ツールなど、文章を入力させる系の SaaS が徐々に IT 産業以外の職場でも普及しつつあり、そのような環境でも受け入れられやすいようにプレーンテキストの Markdown ではなく、 Markdown 風の WYSIWYG を入れてきているのだと推察する。
普通の人でもぐちゃぐちゃにならないように文書を書くための仕組みとして WYSIWYG が注目され直しているのだろう。
MS Word や Google Docs など昔ながらの WYSIWYG はボタンが多く、出来ることが多すぎて逆に不自由だと感じる場面が多かった。一方で Dropbox Paper や Notion の WYSIWYG には悪い印象がない。Paper や Notion の WYSIWYG はできることが限定されていて、制限されているがゆえの使いやすさがある。 MS Word のような大小の文字が入り乱れ、文字が七色に輝いているような文書は書けない。
Paper や Notion はアウトライナーを WYSIWYG 化したような感じで、文章を並べ替えたり入れ子にしたりできる。
文章を構造化することに慣れていない人でも、まぁまぁ読みやすい構造化された文章を書ける、あるいは構造化された文章の書き方を学べるようになっている。
WYSIWYG の前提として、下書きする場所と最終的な出力をする場所が同じだということが挙げられる。でないと独自の装飾フォーマットが使えない。
Notion で書いた文書は Notion でしか読めないし、 Dropbox Paper で書いた文書は Dropbox Paper でしか読めない。 Markdown で書いたテーブルならほかのツールに取り込めるが、 Notion で書いたテーブルは Notion でしか使えない。入れ子にしたり装飾したりする便利な機能も Notion で使うからこそ約束されているものだ。その場所でしかその書き方はできない。
だから、ローカルのお気に入りのテキストエディター（ Vim など）で書いたあとにクリップボードにコピーしてブラウザーに貼り付ける、という使い方が出来なくなってしまう。
いまこの文書は Notion を使って書いているが、プレーンテキストでコピーできない2のでブログにこの記事を投稿するときは一旦 Markdown フォーマットで書き出して Vim で開き、コピーしてブラウザーのブログ記事入力欄にペーストする必要がある。
冒頭に挙げた Day One も Markdown で文章をコピーすることができなくなった。文書作成・管理プラットフォームとして考えたときにはこれは正しい戦略で、 Markdown ではない独自のフォーマットで文書を書かせることでユーザーをロックインできる。ひとたび Notion や Dropbox Paper に文章を書きため、その独自フォーマットに慣れてしまえば、データと記法の両方によってロックインされてしまうわけだ。
Notion や Dropbox Paper はよくできていると思う。特に Notion は WorkFlowy のようなアウトライナー的な側面を持ち、いわゆる「ファイルの壁」問題を解決しつつ Markdown のサポート、画像の埋め込みや表の挿入などにも対応している。良いなと思う反面、一人のインターネットユーザーとしては、オープンかつ自由なフォーマットで書くことができる Markdown がやっぱり好きだとも思う。
このサイトのデザインは黒地に白文字でダークモードという概念が出てくる前からダークモードだった。家のパソコンで見るときには見づらいと思うことはなかったが、外出先で日中にスマートフォンでサイトを見ると黒地に濃い赤色のリンクは見づらいなぁと思うことがあった。最近、 Mac や iPhone でダークモードの概念が浸透してきたので、自分のサイトの場合は昼間用のライトモード対応を行うことにした。こういう感じのメディアクエリを書けばよい。
@media (prefers-color-scheme: light) {
...
}ただ、元々の CSS が結構ぐちゃぐちゃな書き方で難儀した。ダークモードとライトモードの切り替えが行えるサイトは必然的に CSS のメンテナンス性が高い状態だと思う。明暗を反転したときにこの色はこうなる、という対応関係が綺麗に提示できるような状態は、利用するカラーをシステマティックに整理できているということだと思う。 Sass で書いてあるなら利用する色はきちんと変数化されていて適切な命名がなされているとかそういう状態だと思う。 CSS の設計健康診断としてダークモード・ライトモード切り替え対応をやってみるのは結構いいと思う。