報われてほしい人たちと万人のための Web
ちょっと前からぼんやり考えてることがあるので、そのモヤモヤを整理しようと思ったものの、まだ整理できてないのでモヤモヤしたまま一度書き出してみる。
TL; DR
チラ裏
気になっているもの
最近、note というサービスが気になっている。
description によると、
note（ノート）は、文章、写真、イラスト、音楽、映像などを手軽に投稿できるクリエイターと読者をつなぐサービスです。ブログのように使うことも、SNSのように使うことも、コンテンツを販売することも自在に活用いただけます。
とのことらしい。
自分がよく目にするのは主にブログとしての使われ方なんだけど、作者に対して投げ銭的な支援をできたり有料記事を販売したりという使い方ができる。
そして、有料記事というものに対して少し前からモヤりを感じている。 つまり、誤解を恐れずに言ってしまうと、記事が有料であるというところにひっかかりを感じているのだと思う。
「お金を払いたくない」わけではないはず
なお、自分はコンテンツだったり情報にお金を払うことには比較的抵抗がない人間だと思っている。
物理書籍には昔から課金しまくっているし、Kindle も1600冊以上買っている。 App Store でソフトウェアに課金するのに抵抗はないし、某デジタル配信商品を扱っているサイトでもそこそこお金を使っている。
何かをつくっている人や価値を提供している人は尊重されるべきだと思っているし然るべき対価が支払われてほしいとも思っている。
なのに、note の有料記事に対してはなぜかひっかかりを感じていて、その感覚と上記のスタンスの間に矛盾を感じていた。
「無料の Web」という呪い
そこでいろいろと考えてみると、なんだかんだ言いつつも「Web は無料」という呪縛から逃れられていないのではないかという気がしてくる。
Web を日常的に使うようになったのは中学生のころだったが、その頃 Web に転がっていたものはだいたい無料だった気がする。 Web には楽しい無料コンテンツがいっぱいあったし、無料でいろいろなことを学ぶことができた。
一方、電子書籍は生まれたときから有料だった物理書籍の延長線上にあるし、ソフトウェアはパッケージの、映像はディスクメディアあるいはビデオテープの延長線上にある。 だから、心理的に課金への抵抗感が少ないのではないか。
課金は対価にすぎないのか
じゃあ、課金するいう行為が単に何かを得るためだけの行為かというと、そういうわけでもないのがコトを複雑にする。
たとえば、自分は Mozilla Foundation や Wikimedia Foundation などいくつかの団体に課金してるんだけど、これらの団体に課金したところで自分が得る直接的な利益はたぶんほとんどない。
「無料の Web」という願い
とまあ、いろいろ考えてみると、自分は「誰でもアクセスできる Web」が欲しいだけなんじゃないかという説が浮上してくる。
幸い、今は労働者として日々を過ごしているため収入があり、note にある大半の有料記事くらいならまあ払える。
でも、みんながそうかというとそうじゃないと思っていて、自分も数年前までは学生でそんなに余裕がなかったし、もしかすると数カ月後には失職するなどしてまた余裕がなくなっているかもしれない。
自分が学生だった頃には Web にめちゃくちゃ楽しませてもらったし、いろいろなことを学ばせてもらった。 Web に無料で転がっていた情報のおかげで、今の職業に就けているという自信がある。
だから、情報は可能な限り誰でもアクセスできるようになっていてほしい。
そんな気持ちが note へのモヤモヤの原因なんじゃないかなーというのを、現時点での暫定的な答えとしている。
まあ、こんなエラソーなことを言っておきながら、「やっぱり無料がいい」みたいな気持ちもたぶん存在している気はしていて、それも否定しない。
さいごに
最後になったが、note の有料記事が悪いとか嫌いとかいうつもりは一切ない。
ニッチな領域だったり分量がそれほどでもなかったりして、書籍にするのは難しい知見などが有料記事という仕組みで吸い上げられてくると良いなとも思っている。 それに、note に上がってるのも大半は無料記事だし、他のサービスでは今も無料で情報が提供され続けている。
今回、「何かを生み出している人たちが報われてほしい」という気持ちと「誰でも情報に到達できてほしい」という気持ちがあることに気づいたが、それらのバランスの取り方についてはほとんど何も考えられていないし特にスタンスも持てていない、というのが現在の状況。
むずかしいなー。
URLs are (not) alone
少し前にこんなエントリを書いた。
要約するとこんな感じ。
- URL はリソースを一意に特定するのがプライマリな役割だが、可読性が高くて指し示すリソースの内容がわかると嬉しい
/articles/2018/03/16より/articles/great-articleのほうが良いよねという話
- 一方で、リソースの内容がわかるようにするとキーが意味を持つことになり、変更される可能性がある
/articles/great-articleが/articles/awesome-articleに変更される可能性
リソースの管理が運営主体によって為されている場合はキーの変更リスクもある程度抑えられると思うが、UGC になると表記ゆれなどもあって変更頻度が結構高くなることが考える。
Cool URIs don't change なので URL は変わってほしくない。Web ってのはリンクなんだ。
このあたり、Wikipedia, Weblio, ニコニコ大百科, ピクシブ百科事典なんかは UGC だけど（マルチバイト文字の）タイトルを path に含めていてそれがベストプラクティス感がある。
ただ、やっぱり表記ゆれとかが怖いなーと思っていたら可読性について別の考え方が浮かんだ。
OGP に頼るという選択肢はどうだろう？
現代において、URL が貼られる場所（Twitter, Slack, Facebook, LINE, etc...）ではだいたい OGP を読み込んでタイトルや画像を展開してくれる。
URL が不変性を持ったままリソースの内容を表現できればそれに越したことはないが、内容を表現するために不変性が失われるのであれば URL に意味を乗せることはスパッと諦めて、OGP に意味を乗せれば良いのではないか。
一度この考え方でアプリケーションを作ってみようと思っている。
キー、その名状しがたきもの
URL とキーについて考えていたら、URL に含むキーについていろいろ思うところがあったので雑に dump しておく。
暗黙のうちに REST を前提にしてしまっているところはあるが、意識的に REST とは文脈を切り離して素朴に書いてみる。
重複する部分もあるが、URL 側とキー側、それぞれの観点から書いてみる。
URL に求めること
自分が URL に求めることはいくつかあるが主に以下のようなことを求めている
- URL だけで目的のページにたどり着けること
- ページの簡易的な説明になっていること
- ASCII で構成されていること
それぞれの意図するところと重要度について簡単に書く。
[MUST] URL だけで目的のページにたどり着けること
あるページにたどり着くために「URL が指し示すページに行って、次に◯◯というボタンをクリックして……」みたいなことはやりたくない。
URL を入力したら一発で目的のページにたどり着いて欲しい。
（Addressable & Stateless であってほしい）
[SHOULD] ページの簡易的な説明になっていること
例としてブログの URL に含まれる path を考えてみる。
このとき、path が /articles/1234 となっているよりは /articles/introduction-to-key とかのほうが実際にページを見る前に内容が予測できて嬉しい。
[MAY] ASCII で構成されていること
状況によるが、可能であれば ASCII だけで構成されていると嬉しい。
ASCII 以外を URL に含めるとエンコードされて URL が長くなりがちだし、可読性も下がってしまう。
とはいえ、ASCII 以外を含めるメリットが大きいときもあるので、そういうときは無理に ASCII にはしない。
キーに求めること
URL の中で path に含まれるキーにあたる部分以外について上の条件を満たすのはわりと難しくない。キーをどうするかが悩ましい。
キーに求めることは以下のようなもの。
- リソースを一意に特定できること
- リソースを一意に特定する以外の意味を持たないこと
[MUST] リソースを一意に特定できること
これはキーの定義上必須。
ただし、path に含まれる文字列がそのまま物理的に保存されている必要性は必ずしもない。
[SHOULD] リソースを一意に特定する以外の意味を持たないこと
キーとはリソースなりレコードなりを一意に特定するものであり、それ未満でもそれ超過でもない。
仮に auto increment な primary key を作成順の判別に使っているとしたら、それはキーの目的外利用になる。そもそも、作成順は作成日時から導出できるので整数列にしてしまうということは情報を損失している。
人間は整数を見るとどうしても比較したりソートしたりしてしまうので、この観点からはキーは乱数（UUID v4 やランダム文字列）だと嬉しい。*1
対立とバランス
上に書いたものの中で真っ向から対立するものがある。
- URLはページの簡易的な説明になっていること
- キーはリソースを一意に特定する以外の意味を持たないこと
URL はページの簡易的な説明になっていてほしいけど、URL に含まれるキーはリソースを一意に特定する以外の意味を持ってほしくない。
このふたつの間でどういう風にバランスを取るかというのが良い URL/キーをつくる上で重要だと思っている。
いくつかの例を考えてみる。
例1：商品管理アプリケーション
小売店の商品を管理するアプリケーションを考えてみる。
この店舗が扱う商品すべてに JAN コード（バーコード）が付与されているなら JAN コードは商品を代表する属性として妥当なように思われる。
そこで JAN コードを path に含むキーとして採用して /products/4569951116179 のような path にするのが良いかもしれない。
例2：石コレクターのための石管理アプリケーション
そのへんで拾ってきた石を管理するアプリケーションを考えてみる。
石はこの上なく自然のものだが、石に自然キーはない。
そこで何かしらのサロゲートキーを用意してやる必要があるが、ここで auto increment な整数を使うとキーに必要以上の意味を持たせてしまうことになるため、この場合は /stones/5f498e23 のようなランダムな文字列をキーとして含む path が良いかもしれない。
例3：薄い本管理アプリケーション
薄い本を管理するアプリケーションを考える。
薄い本には ISBN のようなものはないのでこれをキーにすることはできない。*2
とはいえ、本にはタイトルというその本を代表する属性がある。ただし、タイトルは重複する可能性があるのでそのままキーにすることはできないし、多くの場合、エンコーディングが必要な文字を含んでいるのでそのままだと path に含めて扱いにくい。そこで、本を代表する属性であるタイトルを元に新たにキーを考える。
たとえば /books/sekaiichi-kawaii-boku のような感じ。
キーの選び方
例1で触れたように、リソースを代表する属性がありそれがキーである場合、代表する属性を path に含めるキーにするのが良い気がする。
例2で触れたように、リソースを代表する属性がない場合、人工的で意味を見出しにくいキーを path に含めるのが良い気がする。
例3で触れたように、リソースを代表する属性はあるがそれがキーではない場合、代表する属性を元に人工的で意味のあるキーを path に含めるのが良い気がする。
例1は自然キーを使った path、例2は意味のない人工キーを使った path になっていて対照的。
例3はそれらの中間でリソースを代表する属性から意味のある人工キーを作り出している。いわば、半自然キーとでも言うべきものになっている。
おわりに
URL を考えるだけでもこんなに苦労するのでプログラミングはむずかしい。
書きながらキーについて思うところが増えてきたので、近いうちにまた何か書くかもしれない。
