Weekly R-style Magazine 「読む・書く・考えるの探求」 2018/10/29 第420号
はじめに
はじめましての方、はじめまして。毎度おなじみの方、ありがとうございます。
先日、Evernote for Macのver.7.6 Beta 1 のアップデート通知がきていました。
内容を見てみると、ダークモードに対応したとあります。私は最近ダークモードでMacOSを使っているので、これ幸いとすぐさまアップデートしてみました。
で、クライアントのダウンロードが終わり、お馴染みの「ローカルのデータベースを更新しています」のプログレスバーが表示されます。
が、それが半分を過ぎたあたりで、まったく動かなくなりました。何かややこしい処理をしているのかなと思い、30分ほど放置していましたが、バーは1ピクセルも伸びていません（まあ、1ピクセル伸びていても気がつかないと思いますが）。
仕方なく、一度Evernoteを強制終了して、もう一度立ち上げました。すると真っ先に「ローカルのデータベースを更新しています」が出るのですが、今度はスタートラインから伸びません。ああ、やってしまったやつです。何かが壊れてしまったのでしょう。
一応OS自体を再起動してもう一度チャレンジしてみるものの結果は変わらず。
仕方なく、アップデート前のバージョンをダウンロードして起動してみるも、「データベースが古すぎて起動できません。最新版をお使いください」のアラートが。それができないから困っとるんやないかい、とツッコミながら、ver.7.6 Beta 1 にアクセスしようにも、アプリケーションそのものが起動していないので、「アップデートを確認する」が実行できません。oh my god。
というわけで、Evernoteの英語のforumで、ver.7.6 Beta 1 のダウンロードリンクを探すことにしました。これが結構見つかりにくいところにあったのですが、何とか発見でき、その後Evernoteのアプリケーションフォルダを丸ごと消して（実際は別の場所に移動させました）、ver.7.6 Beta 1を起動させたところで、Evernoteのサーバーから「私のノートたち」のダウンロードが開始されました。
Evernoteを10年ほど使っているので、似たようなことは何度も体験しています。当然、後になればなるほど、ダウンロードしなければならないノートの総数も増えます。今は7万2000ノートほど。いったいどれくらいの時間がかかるのかと覚悟していましたが、実際は数時間で2018年10月までの全ノートが閲覧できるようになりました。ただし、ノートのサムネイルなどは表示されていません。
たぶん、ノートリストで表示される最低限のフレームだけを最優先で構成し、その後中身やらサムネイルなどを随時追加していく、という構成になっているのでしょう。昔は、だいぶ待たされないと使い始められなかったので、その点は進化しているとは言えそうです。
ただ、気がついてしまいました。その最低限のフレームが構成されている数時間の間、Evernoteを一切触らなくても、ほとんど問題なく仕事ができてしまった、という事実に。
この一件で、ますます自分にとってのEvernoteの存在意義が曖昧になってしまいました。まあ、アーカイブとしては便利なのですが。
ちなみに、MacのEvernoteのデータベースが保存されているフォルダは「ライブラリ」の中の、「Application Support」の中の、「com.evernote.Evernote」です。これをすっかり消してしまえば、Evernoeが起動されたときにデータベースの再構築がスタートします。もし、エラーが出てお困りなら参考にしてください。
〜〜〜サイズとスクロール〜〜〜
あまり目に負荷を掛けないように、Scrivenerでは少し大きめのフォントサイズを指定しています。16px くらい。
で、それが当たり前になっていたのですが、先日たまたま別のところからコピペした際に、操作を誤ってフォントサイズ13pxくらいで貼り付けてしまったのですが、面倒だったので、まあいいかとそのままにしていたら、意外なことに気がつきました。
文字サイズが小さいと、スクロール量も小さくて済むのです。
まあ、当たり前の話です。文字サイズが大きくなれば、行の高さも増え、行数も増える。だから上下移動するときのスクロール量も大きくなってしまう。逆に文字サイズが小さくなれば、その量は減少する。何の変哲もありません。
とは言えわかったのは、原稿を「編集」しているときは、文字サイズは小さい方がいい、ということです。その方が、俯瞰的な視点が取れますし、項目移動などの作業も（多少ならがら）時短化されます。
お前は何を当たり前なことを力説しているのかと思われるかもしれませんが、作業によってビュースタイルやUIが違った方が良く、そのスタイルの中にはフォントサイズも含まれるのだ、というのは私の中では発見でした。それができるツールは、案外少ないかもしれません。
というわけで、今はScrivenerの設定は、通常のエディタはfont-size:13pxで、「フルスクリーン作成モード」では、テキストスケール150%としています。編集は通常画面、執筆はフルスクリーンモード、という使い分けです。
〜〜〜ブログ・リファクタリング〜〜〜
最近アイデアメモを、Scrapboxの公開プロジェクトで公開していて、少し書いては、たまに昔のものを編集する、ということをコツコツやっています。これはもう「コツコツ」という表現がぴったりくる行為です。
で、同じようなことをR-styleでもできないかな、とちょっと考えています。というのも、基本的にR-styleの記事は書きっぱなしだからです。
R-styleにおいて記事の投稿ボタンを押すことは、その原稿の完成を意味し、後から手を加えるようなことはありません。もちろん、更新したあとに誤字脱字に気がついたら修正しますが、それすらも「更新した直後」にしか発生しません。なぜなら、更新した直後は、自分でも読み返すことが多いのですが、時間が経つとそれすらなくなるからです。
つまり、情報カードの言い方に引きつければ、私はR-styleの記事をあまり「くれて」いません。
一応、ブログ記事をまとめた本をセルフパブリッシングすることは、その「くる」ことに相当しますし、有用な再生産を行っているとは思うのですが、その再生産の結果がR-styleに反映されておらず、他者からみたときの情報的価値があまり上がっていないのではないかと危惧しているわけです。
たまに読み返して、表現を変えたり、別の記事とリンクをつけたり、新しくタグを打ったり。
そういうリファクタリングをすれば、「ほとんど読まれていない大量の過去記事」の有用性も向上するのではないかと思うのですが、どのようにしてそれを仕組み化すればいいのかはまだ見えていません。
でも、長くブログを続けていると考えなければいけない問題だとも思います。
〜〜〜JavaScriptクイズ〜〜〜
突然ですが、ここでJavaScriptクイズです、JavaScriptを知らない方はスルーしてください。
先日、ブックマークレットを改良していました。Amazonから書影つきで本のデータをScrapboxに取り込むためのブックマークレットの改良です。
やりたいことは簡単でした。すでにあるブックマークレットの機能は変えずに、取り込む要素として「内容説明」を追加する、というもの。幸いなことに、「内容説明」のHTML要素にはidが割り振ってあったので、そう難しくはありません。難点は、Amazonは紙の本とKindle本で、HTMLの構造が（かなり大きく）違うことくらいです。
よって、その点で場合分けすれば問題なく進むはず、だったのですがそうは問屋が卸しませんでした。
まず、商品紹介を含むHTML要素は"productDescription"のidが付与されていたので、最初にやることは、
var d = document.getElementById("productDescription")です。これは問題ないでしょう。
あとはこのdから内容紹介の本文を取り出すことなのですが、紙版は素直にPタグ（classなし）に、Kindle版はややこしいDivの入れ子構造（固有classあり）に入っています。でも、これは切り分ければOKですね。
var d1 = d.getElementsByTagName("p")[0];
if (!d1) var d1 = d.getElementsByClassName("productDescriptionWrapper")[0];これであとは、d1.innerTextを処理すれば問題ないはずなのですが、どうもうまくいきません。Kindle版ページだと、dが取得されていないようなのです。
ブラウザのインスペクターで、Amazonページのソースを確認しても、やっぱり<div id="productDescription">がソース内に存在しています。でも、それがdocument.getElementByIdで取得できません。
？
さて、その理由とは一体なんだったのでしょうか、というのがクイズです。答えは、空改行後。
【解答編】
まったくエラーが解決しないので、紙版のページとKindle版のページのソースを何度も行き来して確認していました。もしかして入れ子の状態に何か問題があるかもしれないと思って、細かく見ていきました。「内容紹介」全体を包括するDIvがある。そのDivは複数の<div>が入れ子になっていてClassが当てられている。で、その全体のDivは、きちんと<body>に入っている。
ん？
<body>？
なんでページの下半分くらいの「内容紹介」のdivの直上に<body>がある？
というか、あれ、<body>が二つないか？ というか<HTML>も二つなくね？
………
……
…
iframe
oh iframe!
なぜかAmazonのKindle版の「内容紹介」はiframeによって別ページから取り込まれています。たぶん、KindleアプリとかKindle端末とかで本を閲覧したときに、内容紹介が表示されるので、それとデータを共用するためなのでしょう。そんなことになっているなんて、まったく想像もしていませんでした。
別ページにあるのですから、 document.getElementByIdで取得できるはずがありません。そもそも無理な話だったのです。
結局、以下のようなコードで解決しました。
var d = document.getElementById("productDescription");
if (!d) {
var subdoc = document.getElementById("product-description-iframe").contentWindow.document;
var d = subdoc.getElementById("productDescription");
}できあがったブックマークレットはこんな感じです。
最初に全体象をきちんと確認しておくことは大切ですね。id部分しか見ていなかったので、フレーム構造を完璧に見落としていました。やれやれ。
〜〜〜Q〜〜〜
さて、今週のQです。いよいよ10月も最終週。
Q. 残り二ヶ月で何かやっておきたいことはありますか。
では、メルマガ本編をスタートしましょう。
今週もお楽しみくださいませ。
――――――――――――――――
2018/10/29 第420号の目次
――――――――――――――――
○「リストへの要請」#BizArts3rd
ネットワーク型の整理について考えることで、改めてリストを作ることの意味を考えます。
○「Evernoteはメメックスではなかった」#新しい知的生産の技術
来るべき情報整理ツールとはどのようなものなのか。
○「『ホモ・デウス』を読む 第六回」 #今週の一冊
『ホモ・デウス』を読み込んでいく連載です。
○「縦に並べる、横に並べる」 #物書きエッセイ
物を書くことや考えることについてのエッセイです。
○「自分らしさという虚構」 #エッセイ
「自分らしく生きる」ってそんなに素晴らしいことなのでしょうか。
※質問、ツッコミ、要望、etc.お待ちしております。
――――――――――――――――――――――――
○「リストへの要請」 #BizArts3rd
前回は、非ツリー型（ネットワーク型）でのタスク管理の問題点を考えてみました。
そこで出てきたのが、以下の転回的問いです。
「ネットワーク型でタスクを「管理」しても支障ない状況とはどのようなものか」
今回は、ここからスタートしましょう。
■
ネットワーク型でタスクを「管理」しても、支障が発生しない状況とは、おそらく以下のような状況でしょう。
・明確な締切がなく、先方から指定される優先順位もなく、自分が「気になったこと」から取りかかることで生まれる成果だけで評価される状況
これは素晴らしい世界に思えます。何しろ、人は自主的に何かに取り組むとき、一番力を発揮します。「やらされる」仕事が皆無なら、すべての人は意欲的に仕事に取り組み、その能力は存分に発揮され、生まれる成果も素晴らしいものになるでしょう。
ただし、いくつかの点は受け入れなければいけません。
たとえば、私が新しい車を注文したとして、その車がいつ私の手に届くかはまったくわからなくなります。それを作る人たちが、「私の車を作る」というタスクに取りかかる気持ちになってくれないと、実行されないのですから仕方ないでしょう。
しかも実際は、車は多数の部品でできているので、関係する人の数は膨大となります。その人たちすべてが、やる気になって初めて車は完成に向かって進み始めるのです。ということは、とんでもなく時間がかかるか、悪くすれば私の寿命を超えることすらありえます。
もちろん、車だけに留まりません。交通機関もそうですし、料理店でもそうです。ゴミ回収や、葬式のお経や、水道管のメンテナンス・交通整理・幼稚園児の見守りなど、すべての仕事が「やる気が出たら、とりかかる」というスタンスなので、いつ結果が得られるかはまったく不明になります。
単純に考えれば、そのような状態では社会は成り立たないでしょう。
つまり、私たちがリスト的な（ツリー的な）ものを使い、自らの「やること」を管理するのは、（ツール的な要請や、人間の認知的な要請ばかりでなく）、社会的な要請がそこにあるから、ということになります。言い換えれば、タスク管理において「強制力」が必要になるのは、裏側に社会からの要請があるからです。
■
命令する上司がいて、その上司の指示に従って「やること」を実施していく、というのも、形を変えた「リスト」ではあるでしょう。その場合でも、結局私たちはリストに書かれたことを実行していくのと同じように「経路」を選ぶことはできません。言われたことを、その通りに実行するしかないのです。
実行者側が選べる経路が増えれば増えるほど、成果が生まれるタイミングは制御できなくなり、一定の製品やサービスを安定的に供給することはできなくなります。そして、「それでは困る」という社会が現実的にあるわけです。
もちろん、そのようなものばかりでは、あまりに息苦しすぎるでしょう。そこで、そうしたものからの解放としての非ツリー構造があります。あるいは、ツリーであっても、その中においてのみ経路を選択できる「自由」を担保することもできます（「今日中にこれだけを終わらせろ。どれから手をつけるかは任せる」）。
ツリー構造の制約下にいるとき、そうした非ツリー的なものはたいへん魅力的に思えますが、かといってすべての人が非ツリー構造にエグゾダスしてしまえば、先ほど書いたように安定的な社会生活は望むべくもありません。特に、これほど高度な製品とサービスが出回っている社会を維持するのは不可能でしょう。
■
おそらく、ツリー構造が上記のような息苦しさを持つからこそ、「生産的」という言葉が、ときに批判的・侮蔑的に使われるのだと思います。かといって、その「生産的」なものを完全に排した世界が、ユートピアなのかと言えば、それはいささか怪しいでしょう。
すべての対象ではないにせよ、私たちはどこかの時点で「リスト」を作らなければなりません。リストを作るとは、ある属性に沿って情報を選り分け（≒排他的に情報を集め）、それらの順番を決定する、ということです。
この両方の行為において、人間の「意志」というものと、その意志に影響を与える環境からのさまざまな要因が関わってきます。言い換えれば、人が持つ「したい」と「しなければならない」の複雑な組み合わせにおいて、タスクリストというのはできあがっていきます。
別の言い方をしましょう。
私たちがリストを作るとき、私たちは世界とつながっています。否応なしにつながってしまいます。
大げさな話に思えるかもしれません。しかし、制約はなければないほどいい、というのはやっぱりイノセントすぎるユートピア像なのだと思います。
―――――――――――――――――――――――――
ここから先は
¥ 180
この記事が気に入ったらサポートをしてみませんか？