0-0mfuji

私は緩やかにプログラミングを始めてから5~6年が経ちました。最初はコマンドラインすら知らず、使ってみて「誰が使うんだ？」と不思議に思いましたが今はbashを常に立ち上げてないと気が済みません。そんな中ふと思いました。最近のWebサイトは重すぎるし、目的を絞ればどこまで短くできるのかと。日記を兼ねたブログを現代で作る際にどこまで小さくできるか再考し、最終的に約14KBに圧縮しました。また考えたことと必要な機能と書き方のルールをかこうと思います。明確な動機の発端は書くことです。書くことは間違いなく人間のもっとも強力な通信手段の1つです。そして近い将来、ポールグレアムのいうように文章を書ける人がほとんどいなくなるなら、自分がどれくらい機械に負けてるのか記録するのは悪いことではありません。

静的サイトのパラドックス

「LESS IS MORE」建築の巨人は少ないことは豊かであると言いました。Unixの思想の哲学にも同じような考えがあります。どの世界でも少ないことは悪いことでは決してありません。ミクロコスモスであればいいのです。しかし、近年のウェブサイトは複雑化しています。急速な進化や幅広い対応を目指してのことですが、重たくなり必要ないものが多く含まれてしまっています。実際はほとんどのWebサイトは静的HTMLファイルと1つまたは2つのCSSファイルのコレクションで十分です。あとJSも少々。専門家は大きな複雑なサイトを作ると思われがちですが、小さくみじかいナプキンの上に描ける程度のサイトが不要な計算量もデータの輸送もお金も払わなくてすみます。なぜこのような複雑性が存在するのか。それはウェブを複雑にすればするほど、通常のユーザーをSNSやブログサービスに押し込めることが可能なためです。

複雑性の堂々巡り

複雑性の堂々巡りは各所で見られ、ほぼすべての業界でマクロレベルで存在してます。しかし、どの業界も意図して陥っているわけではありません。急速な業界の進化と知識の探究の結果、最初に必要な技量を補うための存在がいない場合がほとんどです。その場合は正しい情報を正しくいち早く届けるシステムを導入するだけで済みます。しかし、ごく稀に故意に用意された複雑性があります。意図した複雑性と意図してない複雑性を見分ける方法はシンプルです。 簡単なシンプルなことを簡単にできないとき それは明らかな妨害と業界の衰退を意味しています。なので私は非常にシンプルに妨害が生まれる前の知識から勉強することで表面的な理解を回避します。少し遠回りですが、大抵の場合古い現存する知識は大量の屍の上に成り立っているので少々の地殻変動で消滅することはありません。しかし学ぶことは膨大になりがちなので、何かものを作る際はとくに仕様書を作成することをオススメします。

仕様書が全体の9割

行いたいことために指針を見失う場合が多々あります。なので仕様書は厳格に書くべきです。というのは過去の話で私は現代は常に情報を共有更新できる状況です。そのため仕様書は常に書き直し常に見返せるような、なんでも誰でも書ける自由帳のようなものであるべきと考えています。今回、自身のブログではAuthoringとしてGoogle keepを使用し思いついたことを大量に書きました。ある種のポモドーロタイマーに近いです。そして電車でも家でも書いたものを少し時間が経ったら見返します。書いている最中に停滞するのはよくあり、仕様書の難しい点です。しかし時間は自然と解決してくれます。とりあえず書き始めて、時間と共に反復します。満足のいく仕様書ができたら、コードを書き始めます、妥協は不可欠ですが、譲れない点だけは決めておきます。私の場合は最小化とレスポンシブデザインだけは譲れませんでした。

デザインと最小化の両立

最小化のためにはHTMLとCSSを削ります。その上でレスポンシブデザインを最低限実装しようと考えました。最低限というからにはCSSテンプレートといったものは使えません。直書きが必須です。そして悩んだ結果、以下のように定めました

@media (max-width: 42em) {
  /* 制限するコード */
}

大きさごとにCSSを上書きするシンプルな方法です。しかし、細かいミスで破綻する可能性があるのでできる限りCSSをシンプルに保つ必要があります。そして最初はRustのParserを使いシンプルなSSGを作成しようとしました。しかしZolaに途中から移行しました。理由は非常に多くありますが、HPだけでなくランディングページや、ナレッジベースとして使えること。 RSSや検索といった機能を実装しやすこと。そして多言語対応を行いやすいことにあります。

愛すべきミクロな機能

多言語対応は、サイトの作成初期段階から計画する必要がある機能の1つです。しかし、事前に計画が必要な機能はそれほど多くありません。多言語対応のほかに検索、RSS、画像圧縮、Tagが該当します。その他の機能は後からサイトに付け加えることが可能です。ミクロな機能はWebサイト優劣をつけるものではありませんが、読者のQOLを向上させます。以下に実装したもの、したいものを羅列します。

ミニリンク

題名の横にミニリンクを置きます。

サイドノートの表示

PCの画面でサイドが空いているのは勿体ないのでサイドノートを表示します。スマホでサイドノートを作成する方法に日々悩んでいます。

投稿のグループ化

Tagを実装している場合、非常に簡便に実装できます。ブログを言語ごとや内容ごとにグループ化することが可能です。

コードブロック

コードブロックで色をつけるのは理解に繋がります。クリック可能なコード付きリンクブロックはコードと記事を紐付ける便利ですが、非常にめんどうな実装です。

外部リンクのマーカー

外部リンクには外部だとわかるようにマーカーをつけます。

切り返し

日本語は単語の間にスペースがなく、通常の場合は音韻で折り返してしまします。そのため日本語はGoogleのbudouxで改善しました。接続詞や固有名詞の途中で折り返さないようになっているはずです。

PWA

Webサイトをアプリのように利用できる仕組みです。プッシュ通知を作成できるためブログの新規投稿を通知できます。

Togのパラドックス

なぜ大規模な機能をつけようと思わないかについて少し触れようと思います。機能を考える上でTogのパラドックスを私は常に意識しています。このパラドックスでのユーザーはタスクを完了するまでには特定の時間が設定されており、作業をより早く終了できる場合は利用可能な時間を埋めるためにより多くの作業を行おうとします。結果として、特定のタスクでユーザーが経験する複雑さを軽減すると、ユーザーはより困難なタスクに取り組むようになり機能はより複雑化していきます。実際、このようなユーザーがほとんどです。 Appleの優れた点の1つはこのことを理解し、機能を制限しつつ利便性を高めていることにあります。逆に手に負えなくないほど複雑化し修正も難しいデザインも多くあります。そのようなデザインの二の舞にならないように、このWebサイトはできる限り機能を使用することを少なくするように設計しています。

書き方の標準化

私の書き方の標準化の話よりもThe Craft of Writing Effectively はもっとも指針とする書き方の動画なのでまずコチラを見てください。

自分がコードを書く際に、コーディングルールを作ることに非常に重きを置いています。そのためブログを書く際もルールを決めたくなります。実際、書き方は標準化を行うことが可能です。優れた書き手は聴衆と目的に合わせて独自の執筆アプローチを持ち、体験を常に楽しくします。例を挙げるなら、製品マニュアルは使用方法のみを漏れなく伝えることが。学術的なレポートは文章の整合性と目的から結論までを明確に間違いなく伝えることが求められます。 SNSの戯言はスピードとシンプルな共感性です。そして今回の場合、開発者のブログは明確さと性格が求められます。

明確さ

明確さはすべてに注意を払います。文法、適切な単語の使い方から 1文の構造から段落の分け方、文章全体の構成に気をつけます。日本語の場合は漢字をひらがなで表記するべきかも考慮します。

おもしろいテクニックとして文章を「省くこと」は残された文章と同じくらい意味を持ちます。文章は理論的には包括的であるべきです。しかし、ブログの場合は読者が知識を持ち、早く要点に達し背景資料はリンクで参照することを望む場合が多いです。私は手のつけようのない複雑性はサイドノートに押し込みます。

性格

自分の意見をどこに表明するかは、自分の好み、対象者、一般的な分野や専門分野によって決まります。それぞれに独自の派閥や習慣があり、出版された文章で著者の意見が反映される範囲もさまざまです。利害関係者へのプロジェクトレポートや製品ドキュメントなどの文書作成媒体では、中立的な意見が求められます。また、複数人で書く場合それぞれがページに自分の個性を刻み込もうとすると、認知的な不協和が生じてしまいます。これには「ちょうどよい」領域があります。つまり、その問題に実際に興味を持ち、知識の少しある人が書いたものを読んでいると読者に確信させるだけの個性と本物の声が伝わり、内容の邪魔になるほどではない領域です。

構成

構成は非常にシンプルにします。

伝える予定の内容を実際に伝える。
実際に内容を伝える。
伝えた内容を振り返る。

予測、理解、復習は物事の最もバランスのよい認知です。最後の要約では他者が引用する可能性を考慮し的確に要約します。

ツール

ツールは人それぞれなので性格にあったものを使います。文法はミスをするのは避けられないのでlintを入れると便利です。

情報収集とAuthoring　Googlekeep
日本語の文法添削ツール　テキスト公正くん
バージョン管理　Github

なにを書きたいか

一番重要ですが私は非常にシンプルです。

やりたいか
やるべきか
できるか

この三原則でできたものを書きます。

要約

この記事はシンプルな動機とブログの設計思想、書き方のルールについて書きました。纏めると

ブログを設計する際は複雑なブログを作らず、ちょっとした機能を少しずつ実装し、書き方のルールを決めるのがおすすめです。

ブログは最初の読者は私自身であることを肝に据えて書いていこうと思います。