最近よく使っている自作ブックマークレット

ブックマークレットをよく作っては使っている。こんなのあったら便利では、と思ったらとりあえず作ってみて、使いながらだんだん出てくるさらなる希望に応じて機能を追加したり変更したり、それを延々とやっている。いつまででもできる。

このブログでは以前から時々そういうブックマークレットを紹介しているが、久しぶりに最近よく使っているものを紹介しておく。

選択した英語を日本語に翻訳

使用例はこんな感じ。

コードは以下。

javascript:(function(){var quote = window.getSelection().toString();window.open('https://translate.google.co.jp/?hl=ja&sl=en&tl=ja&text=' + quote + '&op=translate')})()

Google翻訳を使ってるんだけど、翻訳元の文章に応じたURLにアクセスしているのだとふと気づいて、それを使ってみた感じ。

選択した韓国語を日本語に翻訳

使用例。

コードは以下。

javascript:(function(){var quote = window.getSelection().toString();window.open('https://papago.naver.com/?sk=ko&tk=ja&hn=0&st=' + quote)})()

原理は同じだけど、Google翻訳の韓日版は今イチに思われることがあり、それでPapagoを使っている。仕組みが同様で助かった。

選択した部分をググる

使用例。

コードは以下。

javascript:(function(){var quote = window.getSelection().toString();window.open('https://www.google.com/search?q=' + quote)})()

これも原理は同様。ここでは英単語をググっているけど、直訳ではなく用例を知りたいときとか、あるいは人名とか、もちろん日本語を含めてちょっと知りたいフレーズが出てきたら即ググるボタン、みたいな感じ。

いずれもコード自体は何のひねりもないシンプルなものだけど、ワンクリックで翻訳・検索されてくれるので毎日のように使っている。（とくに英語のやつ）

エンジニアでもなければ30代後半までプログラミングにかすりすらしてこなかった自分が何か思いつくたびにこのようなことをできるようになったのは、ひとえにPerl入学式で丁寧にプログラミングを教えてくれた皆さんのおかげなので、本当に感謝しています。

www.perl-entrance.org

ターミナルからScrapboxにメモを投稿するbashの関数

タイトルのとおりですが。

gist.github.com

`***` と書いてある部分にプロジェクト名を入れます。

使い方は、こんな感じ。↓

gyazo.com

パッと思いついたことをサッとどこかにメモしておきたい、というときに使っています。

ちなみに、if文の中の変数（$msg）をダブルクオートで囲ってないと、上記サンプルのような2語以上に分かれるメッセージ（スペース区切りの内容）を入れられない。それで結構ハマった・・。

カレントディレクトリのファイルの中身をざらっとcatする

プログラミングの練習問題的に少し考えてみた。

catを使うのでシェルスクリプトでサラッと書ければよいのだろうけど、大変そうなのでいつものようにPerlのお力を借り・・

＊実行の様子は最後に入れます。

Perlのコードのはこのような感じで。

#!/usr/bin/env perl
use strict;
use warnings;
use feature 'say';

my $arg = $ARGV[0] // '';
my @files;

if ($arg =~ /-[al]/) {
    @files = glob "* .*"; # 不可視ファイルも対象
    if ($arg eq '-l') {
        for (@files) {
            say $_ if -f; # ファイル一覧だけ表示
        }
        exit;
    }
}
else {
    @files = glob "*"; # 不可視ファイル外す
}

my %cats;
for (@files) {
    $cats{$_} = `cat $_` if -f;
}

say for (sort keys %cats);
say "===\n";

for (sort keys %cats) {
    say $_;
    say '---';
    say $cats{$_};
}

しかしこれだけだと、ターミナルに出力するだけで、行数が多いときに不便なのでlessで出すようにしたい。ということでPerlだけでは済まず、.bashrcに以下みたいなのを書く。

# .bashrcに入れる。パスは環境に応じて。
# 当該ファイルは cats.pl とする。

function cats {
    local arg="$1"
    perl path/to/cats.pl $arg | less
}

で、結果はこんな感じ。

gyazo.com

コマンド名catsを入れると、カレントディレクトリ内のファイルを全部対象にしてcatしていく。

最初にファイル名が列記されて、それに各ファイ名＋中身が続いていく感じ。

オプションで -a を入れると不可視ファイルも対象にする。

lessを使わなければ、bashrcでは関数にしなくてもエイリアスだけで行けるんだけど、自分的にはlessは必須なので・・という感じ。

この機能は以前からたびたび欲しいと思っていたので、今後少しでも快適になればよいのだけど。

＊別環境でも使えるようにGitHubにも上げておきました。
GitHub - note103/cats

EpisoPassを使ってみた

GyazoやScrapboxでお馴染みの増井俊之さんによるEpisoPassの存在は以前から知っていたけど、

episopass.com

基本的な仕組み自体はわかるものの、どうしてこれが安全なのか、数点の疑問がどうしても解けなかった。

ご本人に聞いてしまえば早かったのだと思うけど、そこまで急いでいるわけでもなく、たぶん数年そのままだったのだけど、ようやく理解できた気がするのでメモをかねて書いておく。

EpisoPass全体については、以下のScrapboxをご参照。

scrapbox.io

簡単に言うと、質問＆正答のいわば「なぞなぞ」を作っておいて、それに正解したらパスワードフレーズが出てくる、みたいな感じ。

特徴的なのは、そのパスワードと正答はどこにも保管されておらず、とくに「正答」は自分の頭の中にしかナイので（というかそういうなぞなぞを事前に作っておくので）、仮に運営者のサーバ等からすべてのデータが抜き取られても、パスワードが漏洩することはないということ。

もう少し具体的な仕組みとしては、一意のパスワードを作るには以下の要素が必要になる。

1. ID（URLのこと）
2. Seed（パスワードの長さ等を指定するキーワード）
3. なぞなぞの質問
4. なぞなぞの正答

2番めのSeedというのが少しわかりづらいが、これがたぶんこのシステムのキモで、おそらく質問・回答の選択肢・正答・URLの組み合わせだけでもそれなりに複雑な（他人には破られづらい）仕組みにはなるだろうが、そこにSeedが絡むことでより複雑性が高まるのだと思われる。

その上で、EpisoPassには「編集ページ」と「利用ページ」があり、前者ではなぞなぞやSeedなど各種の設定を行い、後者ではそれによって出来上がったなぞなぞを解く。

で、それらのページはどちらも全世界に公開されている。

たとえば、増井さんが使用例として公開している、ご自身のTwitterのEpisoPass利用ページを見てみると、こんな感じ。

https://episopass.com/Twitter_masui@pitecan.com.html

で、その編集ページを見るとこんな感じ。（最後の「.html」をトルだけ）

https://episopass.com/Twitter_masui@pitecan.com

あれ、Seedもパスワードも見れてしまってる・・というのが、じつはつい最近までまったく意味がわからなかったところ。
パスワード、見えちゃってるんじゃないの？という。

しかし実際には、第一にこの画面内のSeedは利用者が使っているものとは限らず、試しに他のSeedを入れてみると、それに応じてパスワードも変わる。
また、アクセスした時点ではすべての回答候補の最初（左端）の選択肢が選択されているので、どれが正答かは本人以外にはわからない。
つまり、これらの変数が存在することにより、この編集ページを見られても実質的な問題はない。

＊増井さんはご自身の使用例では「Seedを公開している*1」と言っているけど、本当に上記アクセス先のSeedを使っているかはもちろん誰にもわからない。

ぼくは上記後者の、「編集ページにアクセスした時点ではすべて回答候補の左端が選択されている」という前提をわかっていなかったので、編集ページが知られたら自動的にパスワードもバレるのでは・・と思っていた。

もしそうなら、編集ページはなぞなぞページのURLから推測（というか）できるのだから、そもそもなぞなぞの意味ないのでは・・と思っていたのだけど、そうではないことがわかったので、その記念にこうしてブログにメモをしている。

その他、この仕組みに関するよくある質問は以下。想定可能な疑問点はだいたい網羅されているのでは。

scrapbox.io

ちなみに、今回久しぶりにEpisoPassについて調べてみようと思ったのは、増井さんの以下の直近ブログ記事を読んだから。

scrapbox.io

先日仕事でChromebookに触る機会があり、たしかにあのログインは大変！と思っていたので、用途として非常に興味を持ったという。
（まあ実際には、まだ仕事でこれを使うことはできないが・・）

ひとまずは、自分が趣味で使っている＆他への影響が考えづらいサービスで小さく試し始めているところ。

なお、Chrome拡張機能を入れてみたけど、これはなぜか上手く動いてくれない。

scrapbox.io

もしかしたら、すでに別のパスワード管理サービスのアドオンを入れているせいかも。

ちなみに、増井さんはご自身でも解説されているように、

解説スライド - EpisoPass

以前にパスワードの使い回しでちょっとした話題になったことがあり、しかしこれは逆に言うと、どんなかたちであれパスワード自体を登録・保存せざるを得ない既存のパスワード管理サービスの欠点を明らかにしたものでもあったと思う。

EpisoPassにはそれはそれで、「なぞなぞを作るのが面倒」等の問題はありそうなものの（人によりそうだが）上記の根本的な問題は含んでいないから、その点からも期待できるところがあるなあ、と思っている。アルゴリズムなど、システムの仕組み部分もシンプルかつ公開されているようだし。（FAQをざっと見た感想）

*1:FAQにて。その上で、通常は公開する必要はないし、安全を期するためにはSeedも非公開にした方が良いだろうと言っている。

ランダムな文字列をパッと出すPerlスクリプトを書いた

ランダムな文字列を何文字分かサクッと出したい、ということが時々あります。
このようなときに使える小さいツールを作りました。

github.com

使い方

たとえば以下のようにターミナルに打ち込むと、

perl randstr.pl 5

5文字のランダムな文字列が出てきます。

+/2ox

文字数を指定しなければ、100文字出力されます。

この際には数字・アルファベット（大小）・記号がミックスされたものが出てきますが、オプションを指定することによって、数字だけ・大文字ないし小文字だけ・数字とアルファベットだけ、などの組み合わせも可能です。

perl randstr.pl -d 5 #=> 91486
perl randstr.pl -w 5 #=> vkDrV
perl randstr.pl -m 5 #=> 4Md8g
perl randstr.pl -l 5 #=> jajnu
perl randstr.pl -u 5 #=> OKKQX

詳しくは以下。

-d --digit           Set digit
-w --word            Set words
-m --mix             Set digit & words
-l --lower           Set lower case
-u --upper           Set upper case
-h --help            Show help

便利な使い方

どういう時にこれが必要になる、という具体的な事例は自分でもよくわからないんですが、案外必要になるケースが多く、その時にいちいちスクリプト名を打ち込むのも面倒なので、.bashrcに以下のようなエイリアスと関数を設定してシュッと出てくるようにしています。

alias pw="perl path/to/randstr.pl"
function pww {
    randstr=$(pw "$@")
    echo $randstr | tr -d "\n" | pbcopy
    echo $randstr
}

ただ表示したいだけなら pw で済みますが、実際の用途としてはそれをクリップボードにコピーするところまでセットなので、 pww の方がよく使います。（要Mac）

Getopt::Long

少し前にGetopt::Longを初めて使って、オプションの取り回しがだいぶラクになったな、と思っていましたが、しばらく使わないうちに忘れかけていたので、今回はそのリハビリもかねてそれ周りをGetopt::Longで書き直しました。

ただ、このツールでは引数の値は受け取らないので、あまり効果は大きくないですが・・。

後の自分の参考用に、Getopt::Longの復習にともない参考にしたブログ記事を掲示しておきます。

• Perlでコマンドラインオプションの解析に Getopt::Long を使う時、絶対に忘れてはいけない引数 - たごもりすメモ
• おそらくはそれさえも平凡な日々: 2013年のGetopt::Long
• 僕のかんがえた最強の Getopt::Long の使い方 - tokuhirom's blog

お蔵出し

このツールはじつは少し前に寄稿した、WEB+DB PRESSの記事で紹介する候補のひとつでした。

note103.hateblo.jp

その記事では自作の小ネタツールを紙芝居コントのように次々紹介していたので、内容的にも規模的にもちょうどいい感じでしたが、紙数が足りなかったのと、最終的な構成からは少し浮く感じもあったので、お蔵になっていました。

展望

これのRuby版も作ってみたいところです。Rubyの練習。

あとはブラウザで動くのも作ってみたいです。JavaScriptの練習・・かな。

WebサービスのヘルプをGitとかで編集する

こちらは『書き手と編み手の Advent Calendar 2019』の2日目の記事です。

adventar.org

昨日はid:mohriさんの以下でした。

mohritaroh.hateblo.jp

さて、続く私はWebサービスのヘルプを編集することについて書きます。

といっても、あんまり汎用的・抽象的な話ではなく（そうしたかったんですが、ならず）、やや特殊な事例かもしれません。あらかじめご承知おきのほど・・。

ぼくは昨年の11月にそれまでのフリーランス編集者（兼たまにライター）からIT企業の会社員に転職しまして、現在はその会社が開発・運営しているWebサービスのカスタマーサポート、兼編集者みたいなことをしています。

＊転職時のブログ記事はこちら。

note103.hatenablog.com

ここで言うWebサービスとは以下で、

the-board.jp

こちらは見積書や請求書などの取引で使う書類をクラウドで作成・管理したり、そこで登録した金額を使って売上分析・経営管理できるよ、みたいなものですが、これのチャットサポートをしながら、そのサービスに関わるヘルプ記事の校正・テキスト表現の監修みたいなことをしています。*1

このヘルプ、現在400本ぐらいありますが、

boardヘルプセンター - board

そのすべてを同サービスのメイン開発者であり弊社代表でもある田向さん（id:fw_tx76129）が書いていまして、何しろこのサービスは元々田向さんが自分が欲しくて作った（理想に合致するものがあれば使ったけど、なかったので作った）もので、コードも最初のプロトタイプから今に至るまでずっと中心になって書いているので、その仕様については誰よりも彼がよく知っていて、だからそういうこともできるわけですが、とはいえ同サービスがスタートしてからぼくが入社するまでの4年ちょっとの間、ヘルプの文章は他の誰も触っていない状態だったので、いわば「外部の目」によるチェックというのはほとんどされていない状態だったのですよね。

で、そこにぼくが入ってきたということで、じゃあ編集、やりましょうかやりましょうよ、ということで、まずは校正的な視点で表記を揃えたり、ちょっと内容が伝わりづらそうなところを適当に書き換えたり、ということからスタートしてできたのが以下のようなシステムでした。

tamukai.blog.velc.jp

tamukai.blog.velc.jp

詳しくは上記の田向さんによる記事をご覧頂きたいですが、簡単に解説すると特徴は2点で、

• Git/GitHubを使ってヘルプ記事をバージョン管理する
• textlintを使って表記揺れを自動的にチェックする

という感じです。

とくに大きいのは前者のバージョン管理で、以前はその1本目の記事にも解説されているとおり、HTMLエディタ形式の管理画面で編集してそのまま保存するような仕組みだったので、もし修正してもその差分（どこをどう修正したのか）はわからず、とくに複数人で編集する場合には困難が生じそうな状況でしたが、ここにGitをかませることで、第一に複数人による作業が非常にしやすくなり、また普段づかいのエディタ（Vim）でローカルのテキストファイルを気軽に編集できるようになり、感覚的には「コードを書くようにヘルプを書く（編集する）」みたいな感じになりました。

さらには、これによって上記2点目の特徴であるリントツールも経由できるようになり、事前に登録しておいた「辞書」と異なる表記をしていたらエラーが出るようになっています。

textlint.github.io

その作業の流れについて、もう少し具体的に書いてみると、こんな感じ。

1. まず修正前のブランチを元に修正用のブランチをチェックアウト。
2. その中でどんどん修正＆コミット。
3. 時間がかかりそうだったら一旦途中でプッシュして、Draft Pull Request（WIPみたいなやつ）を作成。
4. 1本の記事につき頭から終わりまでを2〜3周ぐらい読み直しながらつど修正。
5. 終わったら、DPRからPRに切り替え。田向さんにアサインを移す。

ちなみに、Git操作はSourceTreeを使っています。

www.sourcetreeapp.com

ぼくは以前は、Git操作なんて黒い画面でやってナンボでしょ、GUIなんて邪道！と思っていましたが、入社してみるとエンジニアで黒い画面を使っている人はいなくて（笑）むしろSourceTreeの割合が多かったので、あっさり改宗。

普段それを本業で使ってるエンジニアさんにGitやSourceTreeの使い方を教われるなんてありがたすぎるので大人しく教わった次第でしたが、なんやこれ、めっちゃ便利やん！という感じで今では手放せないものになっています。*2

上記を踏まえて、あらためてそれらツールに着目しながら手順を追うと、こんな感じ。

1. SourceTreeでブランチ作成・チェックアウト。
2. エディタでひたすら編集。コミット。
3. 途中でプッシュ。GitHub上でDraft Pull Request。
4. エディタで編集の続き。コミット。プッシュ。その繰り返し。
5. GitHub上でPull Requestに切り替え。

実際は上記に加えて、Ruby製のMiddlemanを使ってプレビューを確認したり、

Middleman: 作業を効率化するフロントエンド開発ツール

Perl製の自作ツールを使って対象ファイルをシュッと開いたりしていますが*3、そこまで説明していると細かすぎて伝わらないアドベントカレンダーになってしまいそうなので*4、ここまでにしたいと思います。

本当はこの後、Webサービスのヘルプを編集するとはどういうことか、その時にはどんなことに気をつけて、何を考えているのか、みたいなことも書きたかったのですが、ここまでの話でちょうどキリが良い感じがするので、その辺はまた日にちが空いていたら書くかも、という感じにしておきます。

本日の記事は以上です。ひき続き、『書き手と編み手の Advent Calendar 2019』をお楽しみください！

adventar.org

*1:チャットサポートをどんなふうにしているのか、という話はたまたま先月初頭に行われたテキストエディタVimの国際カンファレンス VimConf 2019 にて簡単なLT（登壇）をしましたので、ご興味おありの方はぜひどうぞ。 docs.google.com www.youtube.com

*2:まあ、黒い画面と格闘した日々があったからこその感動なのだとは思いたいですが。

*3:これについてはコレの最後の方で紹介しています。 note103.hateblo.jp

*4:もう遅いかも。

VimConf 2019でLTをしてきた

以下のスピンオフ、というか続編です。

note103.hateblo.jp

まさかの1人目

レギュラーセッションの最後、Shougoさんの発表を見ていたら、それが終わるたぶん5〜10分前ぐらいにLT登壇者がステージ脇に呼ばれて、お、ついに・・と緊張を高めながら、そういえば今日って、何番目に発表するんだろう？タイムテーブルにも結局出てなかったよなあ・・なんてぼんやり考えながら登壇者が集まるそちらに向かったら、じつは発表順はすでに別ページに公開済みで、1人目でした。

＊ココの下方にあるLightning Talksの項。

一応というか、最初だったらどうしよう〜ぐらいのことは思ってましたが、その確率自体は高くないはず、とも思っていたので、それを聞いたときには思わず声に出して「まじですかー」みたいな反応をしてしまいましたが、今回イベント全般の進行をされていたmoppさんが「大丈夫です」と落ち着いて言ってくれたので、「そっか、大丈夫か」と思って覚悟を決めました。

そんな発表スライドは以下です。
bit.ly

スライドの作成に際しては、最初はPerl製のApp::revealupを使っていましたが、やっぱりというかさすがにというか、Markdownだけだとどうしても細かい表現がしづらいというか、かえってしょうもない調整の手間が余計にかかるなと思って、これまで何度か使っていたKeynote.appで最後まで作って、でも最終的には上記リンク先のGoogleスライドに全部移し替えました。

一度はKeynoteで完成させたものをわざわざGoogleスライドに持っていくっていうのは、べつにそういうインポート機能もないし、実質イチから作り直すようなものなので（Googleスライドの使い方から調べたりして）めちゃめちゃ大変でしたが、でもKeynoteだとGIF動画を載せた状態で簡便に共有する、という方法がちょっとわからず、一方のGoogleスライドはURL1本で動画ごと共有できたので、しばらく逡巡しつつも「これを使うしかないか・・」と諦めて移植した感じでした。

今回のぼくの発表では、実際にVimを操作している＆画面が動いている様子を見てもらわないと話にならないというか、PDFだけでは伝えたいことの半分も伝わらない感じだったので、発表中にデモをやるか、スライドに動画を混ぜるかのいずれかが必要だったんですが、この5分という限られた時間でデモもやるというのはちょっと怖すぎて、GIF動画をバリバリ挿し込んだ次第でした。

ちなみに、GIF動画の作成に使ったソフトは以下のLICEcapで、

• Cockos Incorporated | LICEcap

またスライドの中盤で使った、キー入力をリアルタイムで表示するためのソフトは以下のKeyCastを使いました。

• GitHub - cho45/KeyCast: Record keystroke for screencast

いずれも無料で、大変安定感のあるツールで、本当に助かりました。本当に・・。

解題メモ

その他、発表内容に関する具体的なあれこれは、真面目に書いてると時間かかりそうなので、以下箇条書きで。

• 全体的な構成については、発表前の月曜か火曜（10/28-29ぐらい）に1回大筋の流れができて、あとはスライドを完成させるだけ、というところまで来ていた。
• ただ、その時点での内容は、前置きの部分と、最終版のMotionsの項で扱ったバッファ内移動の話でほぼ占められていて、その他の細かい話は一切ナシ。この時はとにかく5分以内に収めることを最重視していたので、少ないネタを丁寧に解説、という感じだった。
• しかしこれ、時間内に収まるのはよいとしても、何度見直してもあんまり面白くない。カスタマーサポートがVimを使うっていう意義みたいのは伝わるかもしれないけど、たぶんぼくのプロポーザルを見て採択してくれた人はもっと「面白い」ものを期待しているはずで、そんな場所にこれを持っていくというのはちょっと違うというか、小さくまとまりすぎでは・・と思って、結局全部最初から書き直すことに。
• で、今度は逆に振り切って、とにかく話題盛り沢山の長尺版を作って、そこから削っていく作戦に。たとえば、画面分割のワザとしては下記ブログに書いた「一時的なゴミ箱ファイルをすぐに出す」というトピックも入っていて、これはかなり終盤の推敲時点まで残っていた。
  • Vim の地味だけどよく使う設定 - the code to rock
• じつは今回の発表はそのVimの小ネタ一覧的なブログ記事と、少し前に沖縄で登壇したときのVimネタ（→コレ）の流れにあって、初めはそれらの内とくによく使うものをグレイテスト・ヒッツ的に紹介しようかと思っていたんだけど、途中でもっとローカルにというか、ニッチにというか、リアルなカスタマーサポートの現場の雰囲気・臨場感がわかるような感じの方が価値を提供できるのではないか・・と思って、なるべくそうなるように調整した。
• このスライド作成、かなり時間がかかることは容易に予想できたので、このために会社の半休を取ったぐらいだったが、それでも発表の1週間前ぐらいは毎日仕事が終わった後に深夜までやっていて、ほんとに大変だった・・。
• プラス、今回は業務上のお客さんにも多少なり関わってくる話題でもあるので、念のため発表の数日前に社長にもスライドを見てもらって、コメントをもらい、いくつか修正。
• 会社にはチケット代も出してもらった上に、こうして事前レビューまでしてもらう万全のサポート体制でほんとにありがたかった。
• ちなみにうちの社長はテキサスの大学出身で英語ができるので、内容チェックに加えてスライド上の英語表現も見てもらって、これも心強かった・・。
• 英語といえば、今回の英語表現は最初にカンでわーっと書いてから、Google日本語入力で差分を確認して、その後にGrammalyに突っ込んでチェックを受けて・・という工程を何度も繰り返しながら作った。結果はまあ、上々では・・？

周辺的な話

発表内容については以上ですが、イベントの進行的な部分について、もう少し。

とにかく発表前後の流れについては、前述のmoppさん他、スタッフの皆さんの準備が本当に完璧で、最良の環境で発表できたと思います。ありがとうございました。

事前の接続チェックも早い段階（LTの2つ前ぐらいの休憩時間？）でやらせてもらえて、なにしろこの接続チェックって本当にいつも鬼門というか、ぼくはこれまでもカンファレンスの登壇経験って多少はあるんですが、一回ですんなりOKっていうことがほとんどなくて、なおかつチェックできるとしてもごく短時間しかない、というケースが多いので、今回は納得行くまでできてよかったです。

ちなみに、ぼくは今回Googleスライドを使っていたので、できればスピーカーノートの機能を使いたかったんですが、事前に自宅でApple TVのミラーリングで試したときにはうまく行かず、んー、これって会場ならできるのかなあ・・と思って会場でつなげてもやっぱり駄目で（現在も原因不明）、結局普通にスライド流しながら喋ったんですが、その会場での検証にはujihisaさんがとことん付き合ってくれて、本当にありがたかったです。

あとはステージで喋ってる間、すごく見やすいところに専用のPCモニターで残り時間を出してもらっていて、めちゃくちゃ助かりました。

これもmoppさんが用意してくれたんですが、大体自分の中でも「このスライドが来たらあと何分」とか決めていたので、それとの組み合わせで非常に時間をコントロールしやすくて、実際ほぼぴったりで終わりました。

aomoriringoさんのドラも発表終了と同時に鳴って、綺麗に終わりましたね。あんまり早く喋り終わってドラが鳴らない、というのも寂しいので、ちゃんとドラで締めてもらえてよかったなあ、と。

発表が終わってから、そのまま席に戻るか、それともステージ脇の方に戻るか、一瞬迷いましたが、余韻を味わいたかったので脇に戻って、そのままコーヒーのコーナーでタリーズコーヒーをポットから入れて飲みました。まだコーヒーが残ってて良かった〜・・と心から思いましたが、ほんとに、このコーヒーがおいしかった！体中の力がフワ〜って溶けながら抜けていくような感じで、「ああ〜、終わった！もう練習しなくていいんだ！しかも、そんなに失敗しなかった！そこそこ良かった！」みたいな達成感と充実感と脱力感が一気にコーヒーと一緒に体の中を駆けめぐっていく感じで、タリーズコーヒーさんには感謝しかありません。

登壇することについて

今回のVimConfをこれだけ楽しめたのは、間違いなく、自分で発表したからだと思います。

じつのところ、今年の10月後半にはなかなか大変なことが立て続けにあって、また今までの登壇経験を振り返っても、もしプロポーザルが採択されたらもの凄い時間と労力が一気に奪われることは明らかだったので、「今回はプロポーザルはやめておこう、お客さんとして楽しもう」とずっと思っていました。

で、締切り前日までは少なくともそう思っていたのですが、一方で今回のネタ（カスタマーサポートがVimを使うという話）はずっと頭にあって、この内容はどう考えても世界で自分しか発表しないだろうし、もしそれができたらVimConfへの貢献にもなるんじゃないかなあ〜・・と思い始めてしまい、貢献・・それはVimConfのスタッフ、コミュニティ、参加者、登壇者といった関係者全体への貢献ということでもあって、そんなことができたら本当に素晴らしいことだし、その素晴らしいことをやらないだけの理由があるのか？ある？本当に？・・とか考え始めてしまい、んー、ない・・ないなあ・・と思ってしまい、というか応募するだけでもカンファレンスにとってはプラスのはずだし、とか思い始めて結局、締切りのほんと1時間前ぐらいにワッとプロポーザルを書いて提出しまして、幸い選んでもらった次第でした。

こういうイベントがその人にとって楽しいのか、楽しくないのかって、最終的には自分次第で、自分側に楽しめる土台がなかったらどんな優れたエンターテイメントでも退屈だし、逆に自分の中に楽しむ下地ができていたら他人がどれだけ退屈だと言っても楽しめるものだと思います。

その意味で、こうやって登壇者になる、発表する側になるっていうのは、その「楽しむ土台」を作るある意味一番手っ取り早い方法というか、「その瞬間を他の何にも代替できない唯一の経験にする」ための確実な方法なので、散々迷ったものの応募したというその経緯も含めて、ナイス判断だったじゃん、頑張ったじゃん自分、と思ってます。

あらためて、このような場を作ってくれたスタッフの皆さん、登壇者、参加者の皆さん、ありがとうございました。この経験をステップに、より楽しみと刺激に満ちたVimライフを送っていきたいと思います。

付録 - 再現スクリーンキャスト

今回のカンファレンスの模様については、いずれ以下で公式動画を見られるようになると思いますが、

www.youtube.com

それまでのつなぎというか、上記の付録みたいな感じで、今回の発表内容の再現スクリーンキャストを作ってみました。

本来5分の発表のための資料を使って、結局15分ぐらい喋っているのでけっこう冗長かもしれないですが、ともあれ今回喋りたかった内容は基本的に詰め込めたと思いますので、ディレクターズカット版みたいな感じで楽しんでもらえたら嬉しいです。

www.youtube.com

付録2 - 公式動画

公式動画が公開されました。以下の1分40秒過ぎからです。
www.youtube.com

すごく綺麗に撮られていて、びっくりです。音も映像も。このように記録してもらえる前提で申し込んだわけではないですが、これを目的に申し込んでもいいぐらいの仕上がり。本当にスタッフの皆さん、ありがとうございました。