欲しくない

数日ぶりにmacでブログのエントリーを書き始めた。やはりBearはなかなかよい。快適なエディタ環境の１つだ。これでBGMにうっすらと静けさを感じるような音楽が流れたらいいな・・・

減少する欲求

これはわたしの老化に起因するものなのかもしれない。ここ数年、どんどんと物欲が減っていっている。もう目に見えるレベルで減っているのだ。いぜんなら、あれが欲しい、これが欲しいと思っていたものが薄れ、どうしても必要なもの以外は購入しなくなってしまった。もっとも購入しているのはおそらくは妻のものか息子たちのものだろう。

ここ最近何を買ったかを思い出してみたが、自分のものとして購入したのは文庫本になった「スタンフォードの自分を変える教室」というものだ。自己啓発というよりは、科学的な雰囲気で書いてあるので読んでみてもいいかな？という程度の動機ではあった。なお、読了していない。

また、同時に所有欲についてもどんどんとなくなっていることがわかっている。先日、自分用につくったsatoyama-editorをGitHubに公開してみたのも、手元にだけ持っていても仕方ないので公開したまでだ。今回のこの記事には使っていないが、それはサーバーを立てていないからmacで起動するのが面倒に感じただけでもある。mac用にElectronパッケージをつくっておくべきだった。

m0t0k1m0t0k1.hatenablog.com

欲しいものはなんなのか

あまりにも物欲や所有欲が減少の一途をたどっているので、欲しいものがないのか考えてみた。もちろん、生活できるだけの現金は欲しいところではあるが、それ以外で。

まず考えたのは、現代的な「他人にシェアしたいものがあるか」ということから考えてみた。３０分ほど自問してみたが、見つかったのは次のものだけだった。

それは、イオントップバリュ製品の無地ノートでA5サイズのもの、それにフリクションボールスリムの組み合わせだ。これがあれば、自分の思ったことを紙に落書きしていくことができる。ここまでくると、メモ取れたらそれでいいのか、おれは、という気持ちになったわけだが。

これらの何がいいかというと、ノートは罫線がなく小さく薄くカバンにも余裕で入る小ささにもかかわらず、書きにくくないサイズだということ。そして１００円切っている価格だったと記憶している。フリクションボールスリムはノック式だけど芯が細く、書きやすいからだ。これで十分。

もはや自問していくだけ時間の無駄だと感じたため、シェアしたいものではなく「よいものとは何か」を自問してみることとした。すると、長く付き合えるものがよいものだという結論に達した。これはモノだけでなく環境や人もそうだと思う。

どういうものが長く付き合うことができるものなのか？とさらに自問したところ、シンプルなものが長く付き合うことができるのではないか？という仮説がでてきた。では、シンプルとはどういうことなのだろうか。それは、「いらないものがついていない」ということだ。いらないもの、たとえば無地のノートには罫線がない。わたしにとって、ノートの罫線ほどいらないものはない。整然と並んでいることはノートにメモをするときに必要とされることではないと考えているためだ。よって無地ノートばかりを優先的に使用するようになった。

いらないものがあるのは、ストレスを感じてしまう。そのため、罫線があるというストレスを無地ノートを使用することで除去しているということだ。フリクションはどうか？わたしは字がヘタだ。それによく間違える。だから書き直したいのだ。しかし鉛筆やシャーペンではダメなのだ。だいたい、黒や赤だけではダメなのだ。わたしはフリクションボールについては黒や赤、青といった事務でよく使われるものを一切買わない。多いのは、緑、紫、ピンク、茶といった事務には使われなそうな色ばかりを使用している。いまは茶がもっとも気に入っている。落ち着いた雰囲気のなかにも硬さが感じられないというところだろう。

いま欲しいものをまとめると、長く付き合えるシンプルなものだけが欲しいということになった。そりゃ物欲も減るよね・・・

惰性のコーヒー、妥協のウェブ

それでも物欲や所有欲がなくても頻繁に口にするもの、目にするものがある。それがコーヒーとウェブだ。SNSはあまり使っていないが、ウェブの情報はコーヒーと同じくらい日常的に嗜んでいる。

コーヒーは嗜好品だ。さまざまなメリット、デメリットがあるがカフェインを簡単に補充することができる点が特徴だろう。わたしも朝食以外で最低１杯は飲んでいる計算になる。

以前は近所にあるドトールやカルディなどでペーパーフィルター用に豆を挽いてもらって楽しんでいた。楽しむのは色合いや味のほかにも香り、フィルターしてコーヒーを淹れるまでの過程も楽しんでいたわけだ。しかし、いくら良いからといっても時代の流れには負けてしまう。現在はネスレが販売しているバリスタiを利用している。イマイチな公式アプリ、そしてボタン１つでコーヒーを淹れてくれる手軽さ、メンテナンスの簡単さ、放置していてもメチャクチャにはならないところ、１杯あたりのコストを考えると惰性で飲むコーヒーのほうが勝利を収めている。

ネスカフェ ゴールドブレンド バリスタアイ レッド SPM9635-R

シンプルであることを考えると豆を挽いて淹れたコーヒーのほうが妥当だと考えられるのだが、コーヒーをどう捉えるかによってはバリスタマシンのほうがよほどがシンプルなのかもしれない。ペットボトルからカップに注ぐだけのものと考えたら、バリスタマシンのほうが近い。

ウェブを閲覧してしまうのも同じなのかもしれない。もちろん旅行へいって現地を体感するほうがシンプルだ。しかしウェブを使用すれば手続き自体がシンプルになる。このとき、コーヒーも同じだが体験ではなく消費なのだと考えられる。カフェインや眺めをコンテンツとして消費しているのだ。

消費していくのだから、欲求は大きくなりにくい。その体験を所有する欲求も起こりにくい。

消費から体験へ移行したい

マーケティングの書籍で、「体験を提供するからものが売れる」ようなことを読んだ。それもそうだと一旦は思ったわけだが、体験自体を必要としなくなった人もたくさんいるのではないだろうか。出かける、実物をみる、聴く、話を聞くほうもか。書籍を読んだり、友人とスポーツをしたり。だれかにパフォーマンスを見せたり、観たり。そうしたことをしなくなった人も多い。

わたしもきっと、その一人なのだろう。来月には息子の付き添いで倉敷市が主催するウォーキングイベントに参加する。きっと息子の付き添いでなければ体験することはなかったイベントだ。今年で付き添いは３回目になる。たった10kmしか歩かないのだけど、その中でさまざまな景色や人、倉敷の史跡、天候などを体験することができる。３年前は突如としてあられに降られてバタバタと避難したことを覚えている。

瀬戸内倉敷ツーデーマーチ/スポーツ振興課/倉敷市
http://www.city.kurashiki.okayama.jp/2day/

物欲があることは、決して悪いことではない。所有欲もだ。欲求がなくなってしまっては生物としてはかなり危険な状態にあると考えられる。目指すところは欲求はあるが、それをマネジメントすることができている状態だ。そこへたどり着いて、このブログで欲しいものを列挙していきたいものだ。

パイロット フリクションボール スリム LFBS-18UF 0.38mm 10色セット

スタンフォードの自分を変える教室 (だいわ文庫)

ツバメノート A5白無地 3冊パック 白無地 30枚 N2009-3P

satoyama-editorをGithubに公開した

公開したことに悔いはないが、大した意味もない。バックアップ目的ではある。

m0t0k1m0t0k1.hatenablog.com

先日から開発しているsatoyama-editorだが、ElectronにもしたのでWindowsのタスクバーにピン留めしてある。サーバーをビルトインとはいえ起動しなくてもよい気軽さと、ホスティングのためにサーバーを管理する必要がなくなった解放感からか、GitHubへ公開した。開発のリポジトリ自体は個人的なBacklogプロジェクトに用意していた。そこでつくったものは管理していたわけだ。Backlogにリポジトリを持っていたのは、プライベートリポジトリを容量いっぱいまで使用することができるからだ。数に制限はない。そのため、こうしたしょうもないものや電子書籍のマークダウンなど一式はBacklogへ保管してある。

保管するようになったのは、手元のHDDドライブなどへ保存しておくと息子たちに破壊されるおそれがあるためだ。彼らにとって、こうした電子機器はおもちゃにしか見えていない。そのうえ、昨年の夏には愛用のSurface Pro3がお亡くなりになるなど、バックアップはいくつかあってもよいと考えていた。そこで、せっかくGitHubにアカウントを持っているのだから、そこへバックアップしてもいいのではないかと考えたわけだ。

バックアップの準備

Electronを導入してしまったせいもあって、package.jsonを2種類作成することになった。１つはElectron用のアプリそのもののpackage.jsonだ。こちらに記載の内容でElectron-Packagerは実行形式ファイルにパッケージングしてくれる。もう一つはこのリポジトリでビルドをするためにはElectron-Packagerが必要だということだ。「npm install」だけでそれをリポジトリ内にインストールしてくれるようにpackage.jsonを用意した。

どちらにしても、ビルドするためにはElectron本体が必要になるのではないかとも思ったが、必要ないのかもね…そのあたりはきちんとは学習していないことがはっきりしてよかった。

そのほか、未来の自分にむけてバージョンをきちんとつけたりリリースページを用意してzip圧縮済みのファイルもアップしておいた。これで未来の自分にSurface Pro3が吹き飛んでしまっても、ダウンロードすることができるはずだ。

ライセンスと英語力の問題

ライセンスには知っている限り一番緩そうなMITライセンスを採用してみた。これを複製してくれるような奇特な方は世界的にも少なそうなのだが、それを厳しくする必要はゼロに限りなく近い。はっきりいって無駄だ。でもライセンスを明記してないと奇特な方が困りそうなので入れておいた。

それ以前に困るのが、わたしの英語力だ。READMEファイルを用意するにしても、リリースページを用意するにしても、マークダウンはわかるけど英語でなんと書いておいたらいいかさっぱりだ。「いや、そういう書籍が出てるから読めよ」ということは大いにある。しかし中学生のころまで日本人には英語なんて必要ない！などとほざいていたクソガキだったわたしには、英語のハードルは相当高い。高校で踏ん張って、大学では英語のテキストで暮らせるくらいにはなっていたが、書くのと読むのとでは違うしテキストや論文とふだんの話し言葉って日本語でもメチャクチャちがう。

などと言っていてはバックアップすることすらできないので、つたない英語で書くだけ書いてプッシュしておいた。ひとまずこれで手元のマシンがぶっ壊れてもダウンロードすることでソースコードもバイナリもすべて手元に戻ってくる。はず。GitHubが吹き飛ばない限りは。そのときのためのBacklog…両方同時に吹き飛ぶとなったら、あのくらいのコードだから書き直せよということはある。

今後の課題

もし我が家のマシンが吹き飛んだあと、手元にmacOSしか残らなかったことを想定していなかった。どう考えてもmacでも動作すると考えられるようなコードしか書いていないので、build.jsを少し書き直せばmacにも対応できそう。これはそのうちやろう。

nalulabo/satoyama-editor https://github.com/nalulabo/satoyama-editor

release v0.0.1 https://github.com/nalulabo/satoyama-editor/releases/tag/v0.0.1

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール Web制作者のための教科書シリーズ

「とりあえず」は英語でなんと言う? (だいわ文庫 E 334-1)

ITエンジニアが覚えておきたい英語動詞30

satoyama-editorをElectronでexeにした

毎回開発のときにサーバーを起動するのが徐々に面倒になってきていた。Cloud9にアップロードしておこうかと思ったのだが、まだ開発中の段階ではフリープランの範囲でつかえるのはパブリックなプロジェクトのみのようだった。よって、次の２つを選択肢として検討した。

1. Jettyを利用したwarを作成する
2. Electronを利用する

上記２つを検討してみたところ、JettyだとJavaで書く上にコマンドラインから実行することになると思われた。単にJavaが書きたくないな、と思っただけではある。ただ、GitBucketのような形式をやってみたい気持ちもあるため、いずれはやろうと考えている。今回の用途ではまだまだhtmlやcss、jsは修正を頻繁に加えていくことが想定されるため、コンパイルが待てるかな？という気持ちもあった。

一方でElectronのほうはフォルダを指定して実行という形式になる。以前にもやったことがあるので比較的簡単だったことも記憶にあった。ただ、この場合だとフォルダごと移動するようになって面倒ではある。

２つを比較したところ、サーバーが不要であるという面からElectronを採用してみることにした。なにせ、サーバー機能はまったく不要なのにサーバーが必要なのがダメダメなところで、それは音声ファイルがあるからというだけだ。もうFMシンセをビルトインしてしまったほうがいいんじゃないかとさえ思うのだが、エディタである。つくっているのはエディタなので、シンセサイザーをつくろうとしないように心掛けている。

ということでポート指定をしなくてもいい、コマンドがそれほど長くなくて済む、以前にもやったことがあるという理由でElectron採用！

Electronをつかう

ググるといろんな情報が豊富に出てくるような時代になっているようだ。以前にmacOSでやったときにはここまで多くはなかったと思う。まったく依存関係の薄いただのhtml+css+jsなので、困りそうな予感はまったくしない。そういうわけで、さらりと環境を整える。

まずはelectron-prebuiltをインストールする。node.jsはインストール済み。なぜなら、電子書籍を書いた後、ePubにするところをgulpで自動化しているからだ。PowerShellやVBAの書籍を書くのにnode.jsはないだろう、と思ったりもするが、便利なのだから仕方ない。

インストール自体は困りはしない。他のOSに比較してもWindowsはUnix的なもののインストールに困らない時代になった。

npm install -g electron-prebuilt

これで準備は万端。あとは作成していたプロジェクトフォルダを初期化する。

npm init -y

これで作成者とかもろもろを含んだpackage.jsonができあがる。このコマンドを実行しても、もともとつくっていたhtmlなどが吹き飛ぶわけではないので安心して実行するとよろしい。次はElectronが起動するときのエントリポイントを書いていく。基本的にElectronのウィンドウが起動してそこへhtmlを読み込んで動作させるようなものだったと思うので、ググればいくらでもコピペできるものが出てくる。

そういうわけで、実行することができた。

欲が出る

Electronでsatoyama-editorを表示できるようになったわけだが、こうなってくるとダブルクリックで起動してきてほしいものだ。そこで、exeファイルのようなものにできないか調べてみた。すると、あっさりとelectron-packagerなどという正直な名前のモジュールを発見した。コマンドラインから実行できるのでビルドのような雰囲気で利用できる。

electron-packager [アプリにする対象フォルダ] [アプリ名] --platform=win32 --arch=x64 --version=1.4.3 --icon=[アイコンファイル]

これだけで現在のフォルダへElectronアプリ一式が作成される。アイコンについては指定しなければElectron標準のものになるだけ。platformオプションはWindowsではwin32のみが有効のようだ。逆にWindows以外のプラットフォームでWindows用のアプリを出力するときはWineが必要だそうだ。

なお、nodeモジュールとして「electron-packager」をインストールしておけばnode.jsのスクリプトからrequireすることができて、スクリプトから上記のコマンドのかわりをすることができる。今回は何度も実行しそうであったのでそのようにした。

さらに欲が出る

実際、つくってみるといろいろできそうな感じがしてくるので欲が出てきてしまう。しかしいまのところはこの段階でストップ。これ以上Electronとしての作りこみは行わないこととした。理由は２つ。1つ目はElectronアプリをつくりたいわけではないということ。本当に必要なものは快適な執筆環境なので、つくりこみは趣味の世界で他でやろうと思う。2つ目はそぎ落とした機能を復活させてしまうことになりかねないということ。これでは本末転倒だ。

ということで、今回はここまでとしてElectronアプリとして執筆を快適に行いつつ、今後の改善を検討していく。しかし、Electronにすると100MB近い大きさになるのはどうなんだろう。仕方ないとはいえ。Windowsアプリとして書き直してみてもいいかな、とすら思うほどだ。実行環境を抱き込んでいるかどうか、という違いではあるので2017年現在では「スモールだぜ」ということかもしれない。

それにしても快適だ。localStorageも問題なくつかうことができて、この投稿記事も昨日の夕方書き始めたものだがアプリを落としても保存されたままだ。Electronはほんとにブラウザなんだなと今更思ったりした。鐘の音も鳴るしね。

WEB+DB PRESS Vol.94

プログラミングGROOVY

YAMAHA シンセサイザー REFACE-DX

雑記 慣れないJavaScriptとやりあうおっさん、そしてマークダウンとGroovyのこと

ふだん行わないような、慣れないことをするとさまざまな学びがあるものだ。わたしは基本的にPowerShellを書いて暮らしていた。もちろんhtml+css+jsもつかってはいたけど。しかし、主にやっているものでもないので、思いのほかいろんなことを知ることができている。これもsatoyama-editorを開発しはじめたからだ。

無知

ほんとうに無知なものである。スマホのブラウザでも同じようにできるものと考えていたのだけど、そうはいかなかった。たとえば、10分後に鳴らす予定の鐘の音なのだが、これがiOSやAndroidでは鳴らすことができなかった。厳密にはiOSでは鳴らすことができるのだが、クロージャスコープにある変数が参照できず動作していないことがわかった。しかし本当にそうなのかな、ということはあるので、さらに調査する必要がある。Androidのほうは厳密にはKindle FireのOperaでのことだ。こちらはどうやらAudioBufferSourceNodeが未サポートのようだ。そのため音を鳴らすことができなかった。

AudioBufferSourceNode - Web API インターフェイス | MDN https://developer.mozilla.org/ja/docs/Web/API/AudioBufferSourceNode

いずれにしても、10分以上の執筆をスマホで行うことは考えにくいという考えに至ったため、無理に対応する必要はなさそうだ。それに、開いたままだと音が鳴ってしまうというのはいかがなものか、とも思う。 よって、先に実装すべきは音を鳴らすことよりミュートなのではないかという気持ちにもなった。

その他にも、いまの方式ではテーマを選択するようなことは難しそうだ。UIとして設定を行うためのスペースをほとんど確保していないうえ、スマホではその場所すら惜しい。いまは80%程度をエディタ領域にあてており、スマホではさらに100%にできるだけ近づけたいと考えている。そのため、ボタンのようなものを配置するスペースすらなくしていきたいところだ。

では、メニューかのごとく画面上部に文字数などを表示させている箇所があるから、ここをそれにあてては？ということはある。これらも画面幅が小さくなれば非表示にしてしまう。最後はsatoyama-editorのアイコンのみが画面上部に表示されるのみとなるくらいに徹底的に部品を排除している。ほんとうを言えば、フッターもなくてもよいくらいだ。

いつかサイドバーを表示できるようにして設定をするように変更するまでは、この形で落ち着きそうである。

慣れないことをすること

慣れないことをすると、ふだん使わない何かを使っているようだ。筋肉でもそうだが、やたらと疲れるものだ。JavaScriptとの付き合いは非常に長く、大学生のころからなので15年近いのではないだろうか。しかし、一度も得意だと感じたこともないし理解できた！と思ったこともない。あいつはほんとうに難しいやつだと思っている。

htmlもそうだ。cssも。ウェブブラウザの発展とともに姿形を変えていき、わたしの知らない領域へどんどんと進んでいく。その結果、わたしはいつも追いかける立場になっている。追いつかないので、ここ数年は追いかけることすらやめていた。そうすると最近はReactうんぬんが登場していて、少しだけ触ってみたが今回は採用しなかった。ユーザー入力に応じて画面を再描画するほどの必要性が感じられなかったためだ。そのためjQueryさえ使っていない。

一方でCSS3は非常に便利だ。いままでJavaScriptなしには実現しえなかったことをブラウザのレベルでやってくれるため、見た目は見た目、という切り分けがしやすくて非常にうれしい限りだ。html5は…いまいちどこに恩恵を受けているのか感じないレベルであるため、きっとよくできているということなんだと思う。

マークダウンとApache Groovy

唐突に何を言い出すのかと思いきや、マークダウンとGroovyは似たようなところがあるなと思い立ったので書き始めてみた。どちらも最終的には別のものになる。マークダウンはブログサービスなどではhtmlに変換される。Apache GroovyもJavaにコンパイルされる。そしていずれもマークダウン中のhtmlタグはそのままアリとして生き残る。Groovyもスクリプト中のJavaコードは妥当なGroovyコードになる。非常に面白い。

satoyama-editorではhtmlタグは除去してから文字数カウントを行うようにしてある。それは、書籍を書いているときにAtomやVSCodeだと文字数はそうしたタグも含めての数になってしまうからだ。つねづね、そこは違うんだけどなーと思っていたので除去することにしてある。

いずれにしてもマークダウンもGroovyもどちらも好きなものである。マークダウンを超える表現手法が必要なときはhtmlを内部に記述していく。GroovyではなくJavaを書くべきところではJavaを記述する。結果的には１つのアウトプットになるというところが素晴らしいところだ。PowerShellでもC#やVB.Netをスクリプト内部に記述することができるのだけど、そのままとはいかない。ヒアストリングという形式の文字列に埋め込んで、Add-Typeコマンドレットで一時的にコンパイルして利用することになる。これがなければPowerShellも素晴らしいのになぁと、時々Groovyのような.Netプログラミング言語がないものかと考えてしまうことがある。

とりとめもない話になってきたので、そろそろここらで終わりとしたい。

追記：2017/02/23 15:04

Kindle Fireでは何もとくに変更していないが、音を鳴らすことができた。なんなんだこれは…謎が深まるばかり

確かな力が身につくJavaScript「超」入門 (確かな力が身につく「超」入門シリーズ)

プログラミングGROOVY

【改訂新版】 Windows PowerShell ポケットリファレンス

名前をsatoyama-editorに決めた（変えてしまいそうだけど）

m0t0k1m0t0k1.hatenablog.com

昨日から開発をはじめた、快適な何もしない執筆環境を「satoyama-editor」と命名した。ああ？なぜ里山なんだよ。なぜかって？それは、静かな場所をイメージしながら開発しているからだ。虫の声。風の音。小川に流れる水の音。鳥の声。そうしたものを想像しながら開発している。

いまわたしは里山という環境にはいない。実際は地方都市の2番目に大きな街にある町に暮らしている。だから、里山には程遠い。近所には交通量の多い幹線道路があって、窓を開ければ日々昼夜を問わず自動車の音や緊急車両のサイレンも聞こえている。さらに線路も走っているので、踏切や電車の走行音も聞こえてくる。ある意味で交通の便がよく、快適な町だ。

そうした環境はプログラミングするには非常に向いている。集中してさえしまえば、何も気にはならない。没頭することができるのでね。だけど、書籍のときは慣れていないせいか集中できない。あれこれ目に入るとまったくもって集中できない。たとえば構文ハイライト。マークダウンの構文に沿って書くことができているか？それがハイライトされると「よっしゃ」となってしまって本来書くべき内容は薄くなってしまっていることに気が付いた。メール文章を書くときにも、はじめのうちはテキストエディタを使用していたのだけど、結局最後はプレーンテキストにはほとんど何もしないTeraPadを使用するようになっていた。

リッチなエディタは非常に便利なのだけど、不便なほうがより集中できるということもあるのだと考えたのだ。では、里山にたとえた形になっているわけだけど、里山に何もないか？というとそうではない。たくさんのものがある。ある、というか生きている。生きているものがたくさんある。もちろん、街の中でも生き物はたくさんいるし、足元を見つめるだけでいろんなことに気が付くだろう。だけど、街の中にはないものを求めているという「ないものねだり」というところだと思う。

使い心地

いまのところ、なにもしないのはとても快適だ。見出しになっているかどうか、リストになっているかどうか、いちいち気にならないし、それほど目につらいものでもない。開発自体はhtml+css+jsでいまのところ外部ライブラリも一切使っていないので、振り回されることもない。ひどい話、自分の使用している環境で動作すればよいので無理なハックを使わなくてよいのもすこぶるよい。なぜ、いままでこういうものをつくってこなかったのか。不思議でならない。

そういうわけで、違う意味で快適なのではあるが少々バグも目に付くようになってきた。一日中つかっていれば、バグにも気が付く。昨日のブログ投稿のあとに追加した修正でバグっているようだ。自分でつかいつづければバグもとれてくるのだろうか。最大のユーザーが自分というのはある意味でよいことだ。なんだ、ドッグフーディングとかいうやつかな。

昨日追加した機能のなかでもっとも気に入っているのは、この文章を読むためにどのくらいの時間がかかるものなのかを計算して表示するようにしたものだ。適当にググると人間はだいたい400から600文字くらいを1分間で読むことができるらしい。どう考えても普段のブログ記事を読むスピードより遅い気がしなくはないが、600文字にしておけば目安にはなるだろうということで600文字で計算するようにしてある。いまこの時点で1400文字強なので、およそ2分と4秒くらいで読み終わることができる。ブログ記事であれば2000文字くらい書いてあることが多いので、3分前後というところかな。

プレビュー機能について

昨夜も寝る前に考えていたのだけど、プレビュー機能はブログサービスなりにあるのでやはりつくらなくてよさそうな気がしている。書籍だと実際にePubやmobiファイルにしてビューアで読んでみないとわからない。エミュレータもあるのでそういうもので読んでみると、初期のころに出版したもののコード部分が死ぬほど読みづらい箇所がたくさん見つかる。なかなか簡単にはいかないものだな、と思っている。今後出版するものは白黒のビューアでも快適に読むことができるようにハイライトはやめようと決心している。思い返せば、ハイライトしている紙の書籍ってほとんどないはず。だって、ブログじゃないから読みづらいんだもの。

いまウェブサーバーはPHPをつかっているので、PHPでサーバー側の機能をつくればプレビューはおろかサーバーサイドでのドキュメント保存もできそうだなーと思うことは思うのだけど、個人的にはあまりエディタの同期機能をつかうメリットを感じていないので他の方法があるんではないかと思っている。わたしはDropBoxにファイルとしてアップしたほうが便利なのでそうしている。ファイルは開くことができなくてもいいし。貼り付ければいいのだから。

類似としてクリップボードの制御もいまのところ考えていない。全選択してコピーは別にブラウザの機能を使わなくてもOS標準のものでよいと思っている。なぜなら、このエディタはあくまでも単なるtextareaで、データはプレーンテキストなのだから。

そういうわけで、とりあえずゴミみたいなレベルのバグを修正することにする。

NHK ニッポンの里山―ふるさとの絶景100

カレンダー2017 今森光彦が見つめるニッポンの里山 (ヤマケイカレンダー2017)