VimConf 2018と私

2018/11/24(土)、VimConf 2018に行ってきました。

VimConf 2018

最初に2行で自己紹介をしておくと、ぼくは先月まではこういうことをやっていて、
note103.hatenablog.com

今月からはこういうことをしています。
note103.hatenablog.com

1行で言い換えると、非エンジニアの元・フリー編集者&現・IT企業のカスタマーサポートです。

では本題です。

本編

会場は秋葉原アキバホールというところで、スタートは10時だったので家を出たのは8時半ぐらい。秋葉原駅には予定どおり9時半過ぎに着いて、事前に地図で確認したところでは5分程度で会場に着く予定だったものの、普段あまり使わない駅なのとiPhone6sのGoogleマップが重くてかえって道に迷うことに・・。

その後、なんとか会場付近まで来てからも似たようなビルが多くて、どこを向いても「アキバホール」の文字が見つからず、また土曜のオフィス街ということもあってか全然人影がなく、普通ならそのあたりにフラフラしていそうな参加者っぽい人たちも見当たらないので、「もしかして、まったく別の場所にいるのかも・・?」とかなり不安になりましたが、あんまり時間もなかったのでGoogleマップはもう無視してカンでそれっぽいビルに入ったら正解でようやく受付を発見。

ノベルティ&Tシャツを受け取って開演10分前ぐらいに会場に入ったら階段状の客席にはワーッと人がいて、さっきまでの外の静けさとは好対照。皆さんもっと早い時間からいらしてたんですね・・30分早く来ていれば迷わなかったのかも。遅刻した人も少ない印象でした。

客席脇の廊下スペースにはタリーズのコーヒー&紅茶が完備されていて、そんなの想像もしていなかったのでサプライズ&堪能しました。

そしてオープニング、いきなり全編英語でまたびっくり。この英語主体の進行は最後まで続いて、すごく新鮮であるとともに嬉しい感じもしましたね。ああ、世界につながった場所にいるんだな、しかも当たり前にそうなんだな、と。日本のカンファレンスに海外ゲストを呼んでいるのではなくて、国際カンファレンスを日本でやってるんだな、と。

キーノート

mattnさん

最初のキーノートはmattnさんで、vim-jpの紹介を中心にVimの前提的・全般的なことから将来的・技術的なことまで。ある意味で、この後のBramさんとこのmattnさんのトークが全編を通して一番ビギナー向けというか、どのレベルのユーザーにとっても身近に感じられるバランスの良い内容だったように思いました。

vim-jpがどういう歩みを辿っていて、今はどういう働きをしていて、それに対してぼくらユーザーはどう関わっていけるのか、ということは今までも「調べればわかる」状態だったかもしれないですが、この発表を見てスイスイ理解できたようで、ぼくにとってはこちらと午後イチのdaisuzuさんの発表が今回のカンファレンスで自分にぴったりフィットしたなという印象でした。

Bramさん

続いてBramさんのキーノート。Bramさんは以前にYouTubeで見た講演の動画で、聞きやすい英語を喋っている印象があったので、

www.youtube.com

そのまま聞くか、翻訳レシーバーを使うか一瞬迷いましたが、きちんと意味を拾うことを優先してレシーバーで聞きました。通訳さん、とてもいい感じでしたね。正直、専門的な部分については把握しきれなかったですが、とはいえまったく追いきれないというほどでもなく、長さ的にも聞いていて全然疲れないぐらいですっきり終わって、質疑応答も含めて楽しみました。

その質疑応答、これまでに参加したITカンファレンスだと挙手した人の席までスタッフがマイクを持って走る、みたいな運用が多かったですが、このVimConfでは会場前方まで質問者が来て、列状に並んで順に質問する、みたいになっていてこれも新鮮でした。

この方式なら、質問者は登壇者と近い場所で話せるし、周りとしても質問者があと何人いるのか、とかがわかりやすくていいなと思いました。2階席まであるような大ホールだと難しいかもしれないですが、スタッフのリソースを最小限にできるという意味でもけっこう良いなと。

昼食

その後の昼食では、今半のすき焼き弁当とベジタリアン向けの野菜弁当の2種類が用意されていました。野菜弁当にもかなり惹かれましたが、今半のすき焼き弁当なんて次にいつ食べられるかわからないので、そちらに。もしかしたらチケット代の大半はこれに行ったのではと思うほど贅沢な内容でしたね。ぼくは普段は少食なので、お弁当ってけっこう残すことが多いのですが*1、今回は完食しました。

午後

daisuzuさん

午後イチは上にもちらっと書いたdaisuzuさんの "Migrating plugins to standard features."

https://vimconf.org/2018/sessions/#link-daisuzu

膨大なプラグインとともにあったVim環境から、最小限のプラグインと最大限の標準機能を活かした新たなVim環境への移行の試み、といった感じでしょうか。これはすごく共感できる指向というか、結局プラグインって増やすのも減らすのも効率化を追求するという意味では同じというか、しかし減らす方ではさらにそこに「標準機能縛り」みたいなある種のゲーム性が加わって面白そうだなあ、と思いました。とくに、Ctrl+xを用いたキー操作はあまり(というかタイプミスのとき以外は)使ったことがなかったので、そっちの世界にも足を踏み入れてみたい気持ちが高まりました。

Alisueさん

他に個人的にヒットしたものとしては、Alisueさんの "Effective Modern Vim scripting" がありました。

https://vimconf.org/2018/sessions/#link-lambdalisue

わかりやすく3ステップに分けて、ごく初歩的なVim scriptの書き方から非同期で動く本格的なものまでひと息に解説するという内容でしたが、ぼくもVim scriptで自作プラグインを作ることにはすごく興味があって、実際以前にちょっとしたものを作ったことはあったのですが(それはまだブログに書いてなかったのでいずれ・・)、でも普段から実際にVim scriptを書いている人がそういう方法についてまとめてくれることってなかなかナイので(書籍はすごいのがありますが)、これはあらためてじっくり見直しながら、手を動かして試してみたいなと思っています。

とくに、今までvital.vimというプラグインがあること自体は知っていたものの、それが何をやるのか、というのはどうしてもイメージできなかったのですが、この発表を通して「なるほど」という感じでうっすらイメージできた気がするので、次にプラグインを書くときが来たら、vital.vimを使うことがひとつの目標になりそうです。

ちなみに、同じAlisueさんが懇親会で紹介していたfila.vimにもすごく興味を持ちました。

github.com

ぼくは今やっている編集仕事でも趣味のプログラミングでも、Shougoさんのvimfiler.vimを頻用していて、こういったものが無くなるのは本当に困るので、こちらの動向も注視したいなと。

ついでに言うと、今年の3月にYAPC::Okinawaで発表した中の以下のスクリーンショット

f:id:note103:20181125231912p:plain
https://speakerdeck.com/note103/the-non-programmers-programming-techniques?slide=12

この左のサイドバーになっているのがvimfiler.vimですね。さらに付け加えると、そのIDE風の構成はmattnさんの以下のSoftware Design誌の記事を見て真似したものです。(という話もそのスライドの中で触れています)

軽い話

本編最後の発表は、Linda_ppさんでした。導入のところで「もう皆さんお疲れでしょうから、最後は軽い話をしますので。ゆったり聞いてください」みたいなことを言っていたので一瞬気を抜きましたが、それからものすごい速さで深遠かつ先端的な話をなさっていたようで、ふんわり聞いてしまいました。とはいえ、WebAssemblyについては少し前にbuildersconで見た以下の発表で興味の下地はできていたので、

https://builderscon.io/tokyo/2018/session/5212a273-a1b8-4458-9ce6-621d136b24f1builderscon.io

まったくワケわからん、というほどでもなく。図説なども丁寧に重ねてあったので、こちらもあらためて資料など出たら見直してみたいと思っています。

幸運

会の終了後、じつはというか幸運にもというか、mattnさんがすごく近いところに座っていたので、自作の英語練習ツールでmattnさんのchoを使っていることについて、実際にターミナルで動いているところを見てもらいながら、少しだけ話すことができました。

choはこういったもので、

github.com

それを使ったぼくのはこういったものです。

github.com

このうち、以下の動画の7秒目以降で出てくるセレクタのところでchoを使っています。

www.youtube.com

そして上の方で挙げたIDE風の画面分割についても、mattnさんの記事がすごく参考になった旨を伝えることができました。たぶん懇親会の時間だけだったらここまでいろいろ話すことはできなかったと思うので、座った場所が近かったというのは本当にラッキーだったな〜・・と思っています。

mattnさんはスタッフ業もあってお忙しかったと思いますが、同じモニターを見ながら丁寧に話を聞いてくださって、嬉しかったです。

懇親会

懇親会は同じフロア(5階)の、ホールから少し歩いた別会場で行われました。料理も飲み物もサービスも適度な具合で心地よかったです。これまでにもこうした懇親会には何度か参加してきましたが、この過小でも過大でもないバランスってなかなか実現しづらいというか、どうしても料理が足りなくなったり、逆に多すぎて余ってしまったり、あるいは給仕さんが雑な人だったり・・とコントロールが難しいところが多々あると思うのですが、そういうストレスを全然感じなかったです。

初めの方でスポンサーセッションなどの発表があったのもよかったですね。終始歓談タイムだけだと、ちょっとアイスブレイクしづらかったりすると思いますが、同じものを皆でじーっと見る時間があったことで、イベントが柔らかく始まった印象を持ちました。

しかし今回の懇親会、これはいつもそうと言えばそうなのですが、ぼくには知り合いと言える人が見事にまったくいなくて、ぼくはこれまでもYAPCPerl入学式Perlおよびプログラミング自体の入門者を対象にした無料のプログラミング講座)に何度も参加したり、今年はそれに加えてbuilderscon大江戸Ruby会議にも行ったり、それなりにいろんなコミュニティに顔を出してきたと思うのですが、それでも結局まだまだ知らない人ばっかりなんだな・・と思い知らされました。

daisuzuさん

でも、そこでふと気がついたのは、向こうは知らなくてもこっちは知ってる、と言える相手がけっして少なくないということで、だったらそういう相手に話しかけて、面識を持てばいいじゃないかと思って、さっそく前述のdaisuzuさんを見つけて感想を伝えました。お話ししてみると、思いがけず共通の知人や話題があったり(daisuzuさんの発表ではPerlのコードが出てきたのでその話とか)、ちょうどそのときに一緒にいらっしゃった人たちも交えて楽しく話せたりして、この積極方針は思っていた以上に有益なものでした。

松田明さん

その後、Asakusa.rbの松田明さんを見かけたので、先日の大江戸、超面白かったです!と伝えました。あとはぼくが今月入社した会社ではRailsを使っているので、そういう話も。ちょっとだけ挨拶、のつもりがこちらも思いがけず話題がいくつも浮かんできて、いろいろお話しすることができました。そして来年のRubyKaigi熱も高まりました・・なんとか参加したい!!

rubykaigi.org

Bramさん

それからしばらくの間は、食事やドリンクを頂いてまったりしていましたが、ふと会場の端の方を見ると、Bramさんの周りには思ったより人がいないことがわかりました。何人かと話してはいるものの、とても辿りつけない、というほどではないな・・と。

じつは今回は、Bramさんと話さなきゃ!みたいな気持ちはあまり持っていませんでした。なぜなら、ぼくよりずっとそれに相応しい人が他にたくさんいると思っていましたし、ぼく程度のVim歴で対面したところで、とくにBramさんに提供できる価値もないだろう、と思ったからです。でも、考えてみたら本人と直接話せる機会なんてもう二度とないかもしれないし、一応ぼくも毎日Vimを使って仕事も趣味もやっているし(このブログももちろんVimで書いています)、こうなったら当たって砕けろ、邪魔と思われてもいいから行ってみよう!と勢いをつけて話しかけました。

英語は普段のとおりまったく出てこなかったですが、名前を言ってから「ぼくは編集者で、プログラマーではないですがいつもVimを使っています。日本語の編集という仕事でもVimはとてもヘルプフルです。ぼくはVimでddと打つのが好きです。Vimは行単位や段落単位での作業に向いていて、編集という仕事ではまさにそれが役立つのです。ぼくはあなたにとにかく感謝を伝えたいと思っていました。どうもありがとう」みたいなことを言いました。

このうち、とくに「行単位」とか「段落で作業する」みたいなことはまったく英語の表現が浮かばなかったのですが、すぐそばにいたスピーカーの大倉雅史さんがササッと通訳をしてくれて、Bramさんも「ああ、そうなんだね」とか、「ああ、ddね」みたいな感じでリラックスして聞いてくれたようでした。大倉さんには本当に感謝しています。

暗黒美無王(Shougo)さん

その後、こちらもいつも勝手にお世話になっている暗黒美無王ことShougoさんに話しかけました。Shougoさんの周りにはそれこそ人が途切れなくて、その話も常に盛り上がっているようだったので、どうしようかけっこう迷いましたが、しかしこれもやっぱりなかなか無い機会だから、とその話をちょっと割るような感じで「少しだけ今話してもいいですか」と言うと「もちろん、どうぞどうぞ」という感じでShougoさんもお相手の方も一旦それまでの話を止めてくれて、それからしばらくShougoさんのプラグインをいかに使っているか、助けられているかみたいなことを伝えました。

ぼくはあまりShougoさんのプロダクトの良いユーザーとは言えなくて、というのは最近のものよりも以前に作っていた(現在はアクティブな開発はストップしている)プラグインの方をまだ使っているので、その点についてはご本人の前でアピールしづらい気もしましたが、それでもそうした作品の恩恵を大いに受けていることは確かで、そのことを直接伝えられたのは嬉しいことでした。

kaoriyaさん

懇親会もそろそろ終わりかな、という雰囲気になってきたとき、会場の出口付近にkaoriyaさんがいらっしゃることに気づきました。kaoriyaさんは今回のイベント中、どの段階でもつねにあちらへ、こちらへと走り回っていて、とても話しかけるタイミングはないな・・と思っていましたが、そのときはしん、とした場所で知り合いの方と和やかに喋っていて、今だったら話しやすいかなと思って、声をかけました。

じつはkaoriyaさんとは数ヶ月前のbuildersconの終演直後、フォトブースのコーナーで初めてお会いして、そのときは本当に一瞬でしたが、5年前に書籍『実践Vim』のプレゼント企画で本を送ってもらったことの御礼を伝えていました。

2013年という年は、ぼくにとって「プログラミング元年」みたいな年でした。ぼくはその数年前から「あ〜、プログラミングやりたい、できるようになりたい!」と思いながら、でもどうしても中途半端というか、RubyJavaScriptの入門書を何冊も買ったり、有料のちょっとしたオンライン講座を受けてみたりしたものの長続きしなくて、毎回よくわからないまま自然消滅、ハローワールドってなんなん?何が嬉しいのん?みたいな、やっぱり向いてないわ自分、挫折・・みたいなことの連続だったのが、この年の後半になっていきなりスイッチが入ったというか、継続する方向にモチベーションが切り替わったのでした。

具体的には、この年の9月初旬、前述のPerl入学式に通い始め、同月後半には神奈川で行われたYAPC::Asiaにそれこそ知り合いゼロの状態で飛び込みました。

このPerl入学式およびYAPCへの参加はぼくにとって非常に大きな出来事で、その後にぼくがプログラミングを続けてこられたのは、これらのイベントやコミュニティの人たちがいてくれたおかげだと思っています。

では、なぜそのような勉強会やイベントに、まったく畑違いのぼくが無謀にも飛び込む気になったのかと言えば、その一番のきっかけは上記の『実践Vim』にあったと思います。ぼくはそれまでもVimを何度も試しては「ダメだ、難しすぎる!」と思っていつものように挫折しかけていましたが、なぜかノーマルモードの不思議な魅力には取り憑かれたままで、Vimを諦めることもできず、かといって使うこともできない、という半端な状態を漂っていました。

そんなときにkaoriyaさんの以下のブログを読んで*2

www.kaoriya.net

本当に「何を思って」という感じなのですが、応募したのですよね、プレゼントに。どう考えても想定読者には入っていなかったと思うのですが・・。

しかし結果はなんと、当選。倍率は25%。kaoriyaさんからは、

異業種からの参入であることを重視。どういう視点で見るのかに興味があった。*3

とのこと。いやあ、異業種でよかった・・(笑)。

そして書いたレビューがこちら。

note103.hatenablog.com

この記事は、その後のぼくのプログラミングへの関わり方を大きく左右する分岐点になったと思います。というのは、第一にはこのレビューを書くために同書を必死になって全部読んだこと。どれだけわからない内容が並んでいたとしても、さすがに全ページに目を通せばそれなりに知識は定着するもので、しかもレビューを書かなくてはならないのでとにかく何でも良いから吸収しなければ!という姿勢で読むことになって、もう一旦そういうことをやると不可逆というか、だからこのレビューを書き終えた頃には、それまでの

ダメだ、Vim難しすぎる!もうやめた!

という感じだったのが、

ダメだ、Vim難しすぎる!・・けど、もう少しやってみるか

みたいになっていたと思います。

そして「分岐点」という意味はもうひとつあって、それはその記事に付いたはてなスターが示しています。見て頂けたらおわかりになると思いますが、thincaさんやh_eastさんをはじめとするVim界の人たちがスターを付けてくれて、ブックマークの方にも好意的なコメントをもらいました。

これがもう、すごーーーーく嬉しかったのです。そんなこと、それまで一度もなかったですから。それまでのぼくのブログと言ったら、知り合いか、編集の仕事絡みで見てくれる人はいても、プログラマーの人たちから反応をもらうことなんてまずないし、ましてや好評価をもらうなんてありえないことでした。

それが、このレビュー記事ではそういうプログラマーの人たちから「ウェルカム!」と言われたような感じがして、実際にはその後も技術コミュニティに関わる過程ではそれなりの苦労をするわけですが*4、でもそれにしても、やはりこの記事をきっかけに、本格的なチャレンジを始めたからこそ体験できたことなのだと思います。

この記事を公開した数日後、ぼくは上記のPerl入学式に初めて参加して、

note103.hatenablog.com

その2週間後に初めてYAPCに参加して、

note103.hatenablog.com

気がつけば、今年の春のYAPCにスピーカーとして登壇していました。

yapcjapan.org
30d.jp
note103.hateblo.jp

そして今月からは、これまで続けてきたフリーランスの編集者の活動を収束して、ITの会社に勤めはじめています。

www.velc.co.jp

会社の事業は受託開発と自社サービスが半々ぐらいで、ぼくはその自社サービスのカスタマーサポート*5を担当することになっています(今は絶賛トレーニング中)。プログラミングを生業とするわけではないですが、それでもプログラミングをやってきたからわかること、想像できることは多くて、そういうことに関心がなかったらちょっと対応できなかったな、と思えることがすでにたくさんあります。

今までやってきた編集の仕事もすごくクリエイティブで、とくに世界的に活躍するクリエイターさんたちとの仕事は自分がどこまでも高く引っ張り上げられていくような、ロケットで見知らぬ場所まで飛ばされてしまうような面白みに満ちていましたが、でも一方で、ぼくが理想とするような仕事や生活の環境をそこで作っていくのはなかなか大変で、その意味で今の会社に入れたことは、理想の人生に大きく近づいたということだと思っています。

だいぶ話が広がってしまいましたが(そして一気に戻しますが)、VimConfの懇親会の最後に、会場の出口近くでkaoriyaさんと握手をしながら、あの『実践Vim』がなかったらまだ挫折をくり返していたかもしれないこと、そしてあのレビュー記事が最初の成功体験になって今があるのだということを伝えられて、本当に嬉しかったです。

その後、kaoriyaさんからは以下のようなツイートをしてもらいました。

ありがとうございます!!!

終わりに

帰り道、まだ御礼を言えていないVimmerがたくさんいるな、と思いました。たとえば、会場にはいたはずの(必ずどこかですれ違っていたはずの)thincaさん、それから今回はいらしてなかったかもしれないですが、open-browser.vimやcaw.vimで毎日のようにお世話になっているtyruさん、そしてこちらも毎日めちゃくちゃ使っているVim-EasyMotionのhaya14busaさん、あるいはprevim*6の作者であり、現在は書店向けの先進的なサービス 「リトルスタッフ」の事業に邁進してらっしゃるkannokannoさん。他にもまだまだ、そうやってぼくの方で勝手に知っている人たちがいると思います。

でも、また来年VimConfが開催されたら、そういった方々に会えるチャンスもあるかもしれないですね。そのときまでに、ぼくも何か貢献できるよう、自分なりに準備をしておきたいと思います。

VimConf 2018を実現してくださったスタッフの皆さん、登壇者の皆さん、参加者の皆さん、スポンサーの皆さん、ありがとうございました。これからもよろしくお願いします!

*1:家や職場のように取っておける場合は後で残りを食べます。

*2:どうしてその記事に行き着いたのかと言うと、たぶん2011年の同ブログで書かれていた「Vim昔話」シリーズがすごく面白くて、それを読み漁るかたわら新着記事も読んでいたのだと思います。同シリーズは本当に名文!

*3:「実践Vim」レビュワー選考結果発表 — KaoriYa

*4:受け入れられなかった、とかではなくて自分自身の固定観念やカルチャーショックを乗り越える大変さ、みたいなものだと思います。

*5:電話や対面によるものではなく、Intercomを利用したチャットサポート。

*6:直近の編集仕事でもめちゃめちゃ使いました。

Scrapboxの日記にWebページをブックマークするためのブックマークレット

ネットで気に入った記事を見つけたり、部分的にコピーしておいて後で読み直したいと思ったときに、そのURLや選択範囲を手軽にブックマークして、読み返しやすい場所に整理しておきたいとは思うものの、既存のブックマークサービスではなかなか難しそうだなと思って、Scrapbox公式ブックマークレットをアレンジして使っています。

javascript:(function(){var title=window.prompt('Bookmark to Scrapbox','['+document.title+' '+window.location.href+']'); if (title==null) return; var lines=['['+document.title+' '+window.location.href+']']; var quote=window.getSelection().toString(); if (quote.trim()) lines=lines.concat(quote.split(/\n/g).map(function(line){ if (line !== '') { return ' > '+line } })); var lines2 = []; for (var i = 0; i < lines.length; ++i) { if (lines[i] !== undefined) { lines2.push(lines[i]); } } lines2.push(''); var body=encodeURIComponent(lines2.join('\n ')); dt = new Date(); dtm = dt.getMonth()+1; dtd = dt.getDate(); dh = dt.getHours(); dm = dt.getMinutes(); ds = dt.getSeconds(); if (dh < 10) {dh = '0' + dh}; if (dm < 10) {dm = '0' + dm}; if (ds < 10) {ds = '0' + ds}; time = dh + ':' + dm + ':' + ds; if (dtm < 10) { dtm = '0'+dtm; } if (dtd < 10) { dtd = '0'+dtd; } date = dt.getFullYear()+'-'+dtm+'-'+dtd; if (title == '['+document.title+' '+window.location.href+']') { title = ''; }; if (title == '' && quote == '') { body=encodeURIComponent(lines2.join(' ')); body = body+' '+time } else if (title == '') { body = body+' '+time } else { body = body+' '+title+' '+time }; window.open('https://scrapbox.io/***/'+date+'?body= '+body)})()

最後の「***」としているところを自分のプロジェクトIDに変えて使います。ぼくの場合、以下が公開プロジェクトなので

https://scrapbox.io/note103/

IDは「note103」です。ちょっとやってみましょう。

まずは、単にブックマークレットをクリックして、そのままOKボタンを押した場合。

f:id:note103:20181122233637g:plain

次、なにかコメントを入れた場合。

f:id:note103:20181122233705g:plain

次、コメントは入れずに、部分選択した場合。

f:id:note103:20181122233733g:plain

最後に、選択しつつコメントも入れた場合。

f:id:note103:20181122233809g:plain

最小限の仕様は、

ブックマークした日の日付をタイトルにしたScrapboxページを生成し、そこに時刻付きで [ブックマークしたWebページ名 URL] を投稿する

です。もしすでに日記ページがあった場合は、下に追記していきます。

その上で、もし元のページでテキストを選択している場合は、インデントしつつその部分を引用コピー。

確認ダイアログでコメントを入れた場合は、こちらもインデントしつつ下行に(引用がある場合はその下に)反映。

で、時刻は最後の行に(引用もコメントもなければ[ページ名 URL]の後に)くっつける。

という感じですね。

ちなみに、少し前のバージョンでは、選択範囲が空行を含んでいた場合、空行も引用に含めていましたが、可読性が悪いので空行は詰めるようにしました。たとえば、上の最後の動画の場合、前のバージョンだったら「二」の前後に空行が入っていたのですが、今は詰まっています。

ぼくは個人の仕事で使っているものも含めて、非公開のScrapboxのプロジェクトをいくつか持っているので、それぞれに関連するWebページや文章を分けて保存しておきたい時は、プロジェクトごとに設置したブックマークレットでサクサクっとブックマーク&コメント(または引用)を入れています。

あとは小ネタですが、現状ではダイアログの段階で[ページ名 URL]というScrapbox記法を使ったリンク情報が出ていますが、この部分をMarkdownのURL記法に変えて、以下のようにしておくと、

javascript:(function(){var title=window.prompt('Markdown','['+document.title+']('+window.location.href+')'); // 以下同じ

f:id:note103:20181122235924g:plain

このように、ダイアログの部分でMarkdown記法のURLをパパっと取れてけっこう便利です。(それ以外の挙動はすべて最初に挙げたものと同じ)

肝心のコードの中身については・・例のごとく(というか)泥縄で継ぎ接ぎしながら作ったものなので、とくにコメントはありません。😇

じつはScrapboxへの投稿&連携ツールとしては、これとは別に、もう少し手の込んだ&PHPやGAEなども巻き込んだ&これもほとんど毎日使っているものがありますが、それについて書き始めるとけっこうな大作になってしまいそうなので、また時間ができたら・・と思っています。

ブックマークレットの設置の仕方

プログラマーの人にはとくに説明不要だと思いますが、Scrapboxユーザーの中には非プログラマーも多いでしょうから、念のため上記のブックマークレットを自分のブックマークバーに設置する手順を書いておきます。

1. 何でも良い何かのWebページをブックマークバーにブックマークしておく。(たとえばこの記事ページなど)

f:id:note103:20181123093614p:plain

2. そのブックマークを右クリックして「編集」をクリック。

f:id:note103:20181123093657p:plain

3. そして「URL」の部分を・・

f:id:note103:20181123094341p:plain

4. 上記のコードをまるっと入れ替え。このときにプロジェクトIDも自分のものに変更。

f:id:note103:20181123093727p:plain

5. 「名前」の部分はご自由に。

f:id:note103:20181123093744p:plain

6. 保存して出来上がり。

f:id:note103:20181123093800p:plain

以上です。

VimとRubyでScrapboxの日記に追記する

前回書いたTipsに近い話ですが。

note103.hateblo.jp

もっと手軽にVimから投稿できないかなあ、と思って作った物をご紹介します。このとき、投稿対象はその日の日記ページとします。個別のScrapboxページを作成する場合には、前回の記事後半に示した「Vimから新規ページを作ってコピペする」を使います。

目次

VimコマンドラインモードからScrapboxに投稿する

まずはVimコマンドラインモードからサクッと投稿するやつ。

https://i.gyazo.com/455a334df1d3ee3a738cda41f74a6b2a.gif

.vimrcに設定した任意のマッピングを打つと、コマンドラインに以下が表示され、テキストの待機状態になります。

:!ruby ~/scrapbox/sb-post.rb note103 (ここにテキストを入れていく)

上記のデモでは、テキスト部分に「Vimから投稿テスト」と入れています。このとき、行頭に全角スペースを入れていますが、それは投稿時に1字下げするためです。この字下げを半角スペースでやると自動的に詰められてしまうので、全角にしています。

コードを見てみましょう。まず .vimrcの方ではこのように書いています。

nnoremap <Leader><Leader>i :<C-u>!ruby ~/scrapbox/sb-post.rb note103 

1行ですね。ここではリーダーキー(ぼくはスペースにしていますが)を2回叩いてから、iを1回打つとこの待機状態に入るようにしています。

後半の「note103」とある部分は、Scrapboxのプロジェクト名です。複数の投稿先候補がある場合には、一番使うプロジェクト名をここに書いておいて、それ以外のプロジェクトに投稿したい場合には、コマンドラインに出てきてからさらっと書き換えるようにしています。

コードが1行で済んでいるのは、大半の(というかすべての)処理をRubyスクリプト(sb-post.rb)に任せているからですね。

では、そのRubyのコードを見てみましょう・・とするつもりでしたが、じつはこのスクリプトは後述の機能も兼ねているので、そこまで紹介してからあらためて掲示します。

Vimで書いている任意の内容をそのまま投稿する

コマンドラインモードから投稿できるのはお手軽ですが、上記のとおり、半角スペースを含む投稿はできなかったり、けっこう制約があります。

そこで、バッファに書いている内容の一部をサクッと投稿(日記に追記)できないか、と考えて作ったのが以下です。

まずは使ってる様子を見てみましょう。

カーソルが乗っている行を投稿

https://i.gyazo.com/a426037e4f782604e22ec86bd70414a0.gif

選択範囲を投稿

https://i.gyazo.com/73ee490c9f98e2c6bbcc2b55cf3c3bcf.gif

前回の記事で紹介した、バッファの内容をScrapboxにコピペするものはバッファ全体を対象としていていましたが、今回は「カーソルが乗っている行」、または「選択した部分」だけを飛ばしてくれます。またこの際には、最初に書いたとおり、投稿先は当日の日記を対象にしています。

コード

では、それを実現しているコードを示します。まずは .vimrcに記載している関数&マッピングがこちら。
gist.github.com

その中から呼び出しているRubyのコードはこちら。
gist.github.com

どちらもエスケープの置換が泥縄な気がしますが・・とりあえずこれである程度は機能してくれます。

近況

最近はPerlの次に勉強する言語として、なるべくRubyを使ってみるようにしています。まだまだRuby本来のパワーとか独自性などの魅力には触れられていない自覚ですが、それでもいろいろ直感的に使える*1感じがして、面白いです。使い方がわからないときも、ちょっと検索すればたくさんの情報に出会うことができます。

余談ですが、Rubyの方の22行目にある & の置換について、他と同様にバックスラッシュでエスケープしようとしても効いてくれなくて、しばらくハマりました。検索を繰り返してもなかなか解決策に出会えず・・諦めかけましたが、以下でようやく解決しました。
stackoverflow.com

先日のbuilderscon 2018では最終日のスピーカーだったAmyさんが、その発表の中で「大抵の疑問はStack Overflowで解決する」と言っていましたが、まったくその通りだなと思いました。

さらにちなみに、そのQ&Aの中ではビシッと解答が示された後にも質問者が「これじゃ動かないよ」と言っていて、解答者がそれに対して「そりゃエスケープの問題じゃなくて君のコードの問題だよ」と言っているのを見て、ああ、いかにも初心者のハマり方・・わかります・・という感じでした。

初心者は2重、3重に少しずつ間違えているので、そのうち一つの問題を解消しても不具合は直らず、正しい修正の正しさがわからない、何をどう間違えているのかもわからない、そして混沌に至る・・というよくあるパターン。でもそれも、結局はひとつずつ地道に解消していくしかないんですね。それが一番の近道というか、舗装された安全な道。

そうした地道な一歩一歩をくり返す中で、徐々にスピードが上がったり、効率的な進み方を思いついたりするのかなあ、と思っています。

*1:構文をちゃんと覚えてなくても、「こんな感じかな?」とかカンでやってみるとそれで動いたり。

最近のScrapboxの使い方

Scrapbox、最近はほとんど毎日使っています。日記的に使うことが多いですが、メールやブログの下書きに使うことも多いです。

いろんなことがScrapbox周りで効率化している気がするので、現在の使い方について記録しておきたいと思います。

目次

家族との情報共有

他人と使うケースとしては、最近では家族との情報共有で利用することが多いです。家族とは基本的にはチャットでやり取りしていますが、たとえば買物リストとか、旅行の持ち物リストや旅券に関わる各種の情報(予約番号とか)のように、何度も見直したり、チャットで流れないでほしかったりするデータはWikiのような静的な場所を使った方が良いので、そういう用途で使います。

ちなみに、以前はこれをサイボウズLiveでやっていました(が、すでに同サービスは終了)。最近Kibelaを使ってみたところ、フイフイ動くしかわいいし、家族との用途ならKibelaもいい気がしましたが(たしか5人ぐらいまでは無料だし)、非営利でプライベート用途のための料金プランをより切実に想定しているのは、Scrapboxの方かなという気もします。それに、家族はMarkdown記法にこだわったりもしないですからね・・。

仕事関連でも時々使いますが(フリーランス・ユーザーなので無料プラン)、これはたぶん本来の用途に比べてちょっと特殊で、ほとんど更新しているのはぼくだけ、というパターンが多いですね。自分が頭の中だけで覚えておくのはちょっと大変だな、というネタを入れておいたりします。ただいずれにしても、現時点では仕事での使用頻度はそれほど多くありません。

メールやブログの下書き

個人用途で言うと、最初にも書いたようにメールやブログの下書きでよく使います。と言っても、ちょっとした内容なら、そもそも下書きなんてしないわけですが、けっこう大事なメールとか、込み入った内容の場合には、ぼくは3段階ぐらいに分けてそれを書くので、そういうときに役立ちます。

第1段階では一気にラフを書き切ります。この時はサクッと手元で起動できるVimを使うことが多いですが、いずれにせよディテールや整合性などは気にせず、とにかく頭にある情報を出し切ることが優先です。

それが終わったらScrapboxにコピペして、一旦そこから離れます。いわゆる「寝かせる」状態。

しばらくしたら、その第1段階で作ったものをScrapbox上で直していきます。これが文章を作る上では一番大事な工程です。
もし分量が多く、PCを使えるならVimに持っていくこともありますが、「修正」という点に重きを置くならばやはりScrapboxが有効です。

なぜなら、Scrapboxには「編集画面」がないからですね。編集するための画面が、すなわちそのまま「閲覧画面」になっています。
これ、本当に革命的にすごいことです。Googleドキュメントもそうじゃないか、と思われるかもしれないですが、Googleドキュメントをモバイルから操作しようとすると、編集画面に移動するためにエンピツアイコンをクリックしなければいけません。そして、Scrapboxにはそれがありません。

その話からもわかるとおり、この第2工程の修正作業では、ぼくはPCとモバイルを行ったり来たりします。文章を書く際、というより直す際に、「この表現、変だな」とか「ここタイポじゃん」とか気づきやすいのはどういう時かというと、それは「無責任な人」になったときです。よくTwitterで的外れなリプライをしている人がいますが、そのぐらい無責任な態度で文章を読むと、見方がものすごく厳しく、かつシンプルになり、「こんな言い方じゃわからないでしょ(このオレ様が)」といった具合に様々な指摘が頭の中に浮かんできます。

このような「無責任な人」になるスイッチというか、トリガーになるのが、たとえば上記のような「時間を置く(寝かせる)こと」だったり、あるいは「環境を変えること」だったりします。
そして、その「環境を変える」方法の中でもとくに手っ取り早いのが、「PCとモバイルを行ったり来たりする」ことです。

ぼくの場合、あまり寝かせてる時間がないようなときは、PCで書いた文章をすぐに手元のiPhoneで読んだり、iPhoneで書いた内容をPCで見直したりします。そうすると、だいぶ見え方が新鮮になって、変な言い回しやわかりづらい表現に気づきやすくなります。別人のような目で読み返すことができます。

見つけた間違いを修正するときも、Scrapboxに文章を入れておくと、たとえば今までPCで書いたり読んだりしていた文章を、iPhoneSafariから、新鮮な目のまま(間違いに気づいたときのイメージを保持したまま)修正していくことができます。Scrapboxでは閲覧画面から編集画面に移動する時間が存在しないので、画面遷移の際に微妙なニュアンスを忘れてしまうようなこともなく、感覚的にサッサと直していくことができます。

このような感じで、ちょっと込み入った文章を直すときにはScrapboxをよく使っています。

ターミナルやVimからページを生成

Scrapboxでは、URLにあたる文字列を操作することで、任意のページを自在に生成することができます。

詳しくは以下で説明されていますが、

scrapbox.io

この機能を利用して、当日または任意の日付の日記ページをターミナルからさくっと生成したり、Vimで書いた文章を少ない手数で新規ページにコピペしたりできるようにしています。

ターミナルから日記ページを作る

まず、ターミナルからどのような操作をしているか紹介します。

ぼくは.bashrcに以下のような関数を入れています。

gist.github.com

おそらくプロの人から見れば冗長で、恥ずかしい気もしますが、やりたいことは充分に実現してくれます。

論より証拠ということで、この最後にあるエイリアス「sddn」を使って、ぼくの公開Scrapboxであるところの「https://scrapbox.io/note103/」に本日付(2018/08/31)の日記ページを作ってみましょう。

gyazo.com

できましたね。個人的には、前後の日付(8/30と9/1)が入るようにしているところがポイントです。

コードの中で、言語設定を英語にしたり日本語にしたりしていますが(L7, 33)、これは曜日を英語にするための処理なので、ターミナルの設定によっては不要かもしれません。
(ぼくの環境では、これがないと「#Friday」のところが「#金曜日」になります)

また、openコマンドを使っているので、Mac以外のOSだとそのままは使えないと思います。

if文の中の処理は、当日の日記ではない、任意の日付のページを作りたいときのためのものです。
例として、「2016/01/01」の日記を作ってみましょう。

gyazo.com

できました。ちなみに、この本文の内容は、上記のヘルプにもありますが、中身を全部URLに入れ込むことにより生成しています。

また、エイリアスの設定からもわかりますが、「sddn」というコマンドの実体は「sbdd」という関数にプロジェクト名の「note103」という引数を渡しているだけです。よって、その引数を変えればどのようなプロジェクトにも応用できます。

なお、このようにいろいろデフォルト情報(前後の日付や各種タグなど)が詰まった新規ページではなく、当日または任意の日付の日記にアクセスしたいだけ、というときには、以下の関数を利用しています。

function sbd {
    local site="$1"
    if [ -z "$site" ]; then return; fi

    local ymd=$(date +%Y-%m-%d)
    if [ ! -z "$2" ]; then
        ymd="$2"
    fi
    open "https://scrapbox.io/$site/$ymd"
}

alias sdn="sbd note103"

たとえば、すでにその日の日記を作成済みの状態で、さっきの日記ページ作成コマンドを使うと、初期設定用のタグや前後の日付がまた入ってしまうので、単にその日記を閲覧したいだけであれば、これを使うのがシンプルです。

Vimから新規ページを作ってコピペする

もう一つ、時々使うのが「いまVimで書いてる文章をそのままScrapboxにコピペする」というワザです。前半で触れた、Vimで書いたメールのドラフトをScrapboxに持っていくときなどによく使います。

先にコードを示しておくと、.vimrcに以下の関数およびマッピングを書いておきます。

gist.github.com

では、動かしてみましょう。

gyazo.com

はい。GIF動画だと順番がわかりづらいですが、

1)最初に2行だけ文が入ったVimがあって、
2)ファイル下部のコマンドラインで対話型の操作をすると、
3)一意の日時から生成されたScrapboxの新規ページが現れて(この時点では新規ページはカラ)、
4)そこにクリップボード上にコピーされていたテキスト情報をペースト。
5)で、最後に少し内容が変わった最初のVimが出てきています。

この最後の段階でわかりますが、上記2)と3)の間で元ファイルの1行目に目的地のURLが追加されています。それを使って、Vimプラグインの「open-browser.vim」でジャンプすると自動的にページが生成される、という仕組みです。

github.com

なお、Vimでヤンク(コピー)したテキストは、デフォルトではMacクリップボードには入らないので、これについては別途設定が必要になります。

ぼくの場合は、以下のような設定が.vimrcに入っていました。(これを書きながら久しぶりに思い出しました)*1

" Use clipboard register.
if has('clipboard')
  if has('unnamedplus')
     set clipboard& clipboard+=unnamedplus
  else
     set clipboard& clipboard+=unnamed
  endif
endif

この方法の良いところは、新規ページを作成しても、中身が自動的にリンク先にペーストされないことです。

え、自動で反映されたほうが便利じゃないの? と思われるかもしれませんが、Vimで書いている内容ってけっこうセンシティブなものが多いので、万が一ペースト先のプロジェクトが間違っていたら大変なことになります。(いわゆる誤爆

その点、この方法だとまずは新規ページが作成されるだけで、それまでVimで書いていた中身は、まだクリップボードに保持している状態なので、行き先のプロジェクトが目当てのものであることをきちんと確認してから、安心してペーストすることができます。

・・といっても、じつはそれはあくまで結果論で、初めは自動的にペーストできるものを作ろうとしていたのですが、URLに中身を持たせる方法だと文章量に制限があるようで、長文には向かなそうだったので、結果的にこの方法に落ち着いています。

まとめ

ということで、最近のScrapboxの使い方を簡単にまとめてみました。

Scrapboxはウラではいろいろ複雑な処理やコードが動いているのだろうと思いますが、ユーザーからすればシンプル極まりない構造になっているので、そのぶん使い方も無限大というか、自由度が高くて面白いです。

また、前半にも書いたように、編集画面と閲覧画面の切り替えがないことの優位性はいくら強調してもしすぎることはないでしょう。

今後どのような新たな使い方が出てくるのか、思いつくのか、ということも楽しみです。

*1:ヤンクとクリップボードの設定についてはこれだけでは解消できない場合もあるかもしれません。もしハマったら検索で最新情報にあたってください。

YAPC::Okinawa 2018 の思い出

もう半年前になってしまいますが、3月に行われたYAPC::Okinawa 2018 ONNASONについて。

yapcjapan.org

本イベントについては、すでに2本の記事を書きましたが、

YAPC::Okinawa 2018 ONNASONの記録 - the code to rock
ノンプログラマーのプログラミング活用法 - the code to rock

まだもう1本分、これも書いておかないと・・と思っていたトピックがいくつかあったので、少し時間ができたこのタイミングで一気に書いておきたいと思います。

目次

前夜祭

まずは本番前日の前夜祭。国際通りに面したビルの5階、結婚式の2次会などもできそうなステキ・スペースで開催されました。

当日の様子はこの辺りから。
30d.jp

この前夜祭、リジェクトコン*1とその後のLTから構成されていて、ぼくは翌日の本編で発表する予定だったので、この日はただボーッと見ているだけのお客さんとして参加するつもりだったのですが、会場に着いてみると思っていた以上に知らない人が多い・・時々、Perl入学式つながりで知っている人や、過去のYAPCでお会いした人とは挨拶できましたが、でもやっぱり基本、知らない人ばかり。

んー、これ、このままじー・・っと2時間ぐらいチビチビお酒を飲みながらここで過ごすの、ちょっとつらいかも・・? と思い、急遽ホテルまでMacを取りに戻って、LTに参加させてもらうことにしました。
LTに参加することで、自分が誰なのか、少なからぬ人に周知できると思ったし、時間を持て余すこともなくなるし、と。

しかし、この中途半端な野心がその後のスタッフの皆さんの仕事を増やすことになってしまい・・。というのも、いざLTとなって接続を始めたらなかなかモニターにスライドが反映されない。押しても引いてもまったく駄目。それも、順番が最後から2番めぐらいだったので会場の皆さんは注目しているし、うわー、ミスった、すみません! もうやめます! ゴメンナサイ、じゃあ次の方! とか泣きそうになりながらその場で撤退宣言をくり返していたのですが、現場を仕切っていた id:codehex さんをはじめスタッフの皆さんが「いや、大丈夫ですよ」と優しく&粘り強くセッティングを手伝ってくれて、最後には id:karupanerura さんが「これでどうだ」とセットしてくれたのが届いてようやくスタート。

いやあ・・本当に皆さんの胆力というか、タフさ、落ち着き、頼りがい、どれを取っても見習いたいです・・ありがとうございました。とくに codehex さんの「大丈夫ですっ」には救われました。

後から思いましたが、ぼくが翌日の本編で、そこそこリラックスして、緊張しすぎずに発表できたのは、この前夜祭でもうこれ以上ないぐらいのテンパりを体験したからだと思っています。いくら何が起きるかわからない本編だとしても、上記以上の失敗というか、焦った雰囲気はもうナイだろう、と思ったので。実際、本編の方でもスタッフの皆さんにたくさん助けて頂いて、まったく滞りなく進めることができました。

さて、そんな経緯で行ったLTですが、ぼくがその会場で何かしら見るに足る、価値と言えるものを提供できるとしたら、とりあえず自動文字起こしの実演ぐらいかな・・と思ってそれをやりました*2。実際には、そのようにして起こした文字をVimからtextlintを呼び出して自動校正する、というところまでやりたかったのですが、これはtextlintが動かない・・というのを2〜3回繰り返したところで時間切れ。

まあ、文字起こしの方ではけっこう良い反応を頂いて、最後の時間切れのところでも「ああ〜、残念〜!」という雰囲気を会場で一体になって醸せた感じもするので、自分としてはOKというか、充分な成果だったかなと思っています。

ちなみに、そのときにtextlintでやりたかったのはこんな感じのことでした。(当日使う予定だったテキストで再現)

youtu.be

このワーッと滝のように流れていくのが、純粋に面白いなって。それを最後に見てもらったら最初のドタバタもチャラにできるかな・・と思っていましたが、そうも行かなかったのが自分らしいなと思っております。*3

あらためまして、当日サポートしてくださったスタッフの皆さん、そして声を上げて反応してくれた会場の皆さん、ありがとうございました。

当日(私信)

その翌日、本編の出来事に関しては上記2本のブログでだいぶ書いていますが、これまでに書きそびれたことをひとつだけ。というのは、じつはぼくの発表会場では、以前にPerl入学式のサポーターとしてご活躍&サポーターチャットの方でも時々やり取りしていた id:gomayumax さんが部屋付きのスタッフ業をされていて、でもぼくは初対面だったのでそれがgomaさんだとは結局最後まで気づかなかったんですよね〜・・。まったくまともな挨拶もせず、失礼しました・・😅また次の機会に。

ハッカソン

そのさらに翌日、3/4にはPerlハッカーの@skajiさんの呼びかけで、以下のハッカソンが催されました。
connpass.com

ぼくはもちろん(というか)こういった会にはこれまで縁がなかったのですが、今回はスピーカーでしたし、エイヤという感じで申し込みまして、参加してきました。

前日の本編後の懇親会(というか飲み会)にけっこう遅くまで出ていたので、この日は二日酔いがけっこうキツかったですね・・。

しかしその懇親会で、「いやー、明日ハッカンソン行くんですけど、やることなくて・・とりあえず雰囲気だけ味わいに行きます」みたいなことを言っていたら、 @charsbarさんから「そんなこと言わないで〜。何かできることあるんじゃないの?」とニコニコしながら突っ込まれてしまい、んー、たしかに。何かあるかなあ・・できること・・と考えていましたが、とりあえず編集者を名乗ってはいるので、じゃあPerl関連のドキュメントでも何かしら見て回って、直せそうなところがあれば手を入れてみるか・・と。

それで、会場に着いてからさっそくperldoc.jpを見に行って、何かできることはあるかな・・とひとしきり周遊。
japan.perlassociation.org

ハッカソン会場にもいらしていた @charsbar さんから、修正依頼を送るならどうするのか、などもその場で教えてもらって*4、しかしこれ、実際に何かやるとなると、ただ頭から見ていくより自分の使っているモジュールなどから見た方がいいか・・とか、けっこう砂漠に水をまくような大変さを実感。

ということで、これはこれとして見るとして、他に何かないものか・・と思っているところで、ふと、少し前に目にしたJPAさん(Japan Perl Association)のWebサイトで、部分的に情報が古かったりリンク切れになったりしているところがあったのを思い出したので、そちらの修正作業をやることに。

幸い、ハッカソン会場にはJPA理事の@karupaneruraさんもいらしていたので、さっそくその旨相談。数秒で「じゃあ、この時間だけ編集権限を渡しますよ」と決定、すぐにアカウント手続き、1分後にはもうページの編集ができる状態になっていました。すご・・。

あまりのスピード感に眩暈を覚えつつ、ざくざく作業。まずは修正対象になりそうなページや箇所をリストアップ。
要修正の箇所と、要検討につき修正案を提案するまでにする項目に分けていきます。

その後は要修正のところからどんどん修正。終わったら修正内容を簡単にGistにまとめて @karupanerura さんに共有。というあたりまで行ったところで、終了30分前ぐらい。あっという間!&なにこの充実感!

タイポやリンク切れの箇所についてはここで示してもあまり意味がないので、わかりやすい成果をひとつだけ。

以下の、Perlの参考文献を示したページで『初めてのPerl』と『続・初めてのPerl』のリンク先が古い版だったので、最新版に差し替え。
japan.perlassociation.org

初めてのPerl 第7版

初めてのPerl 第7版

続・初めてのPerl 改訂第2版

続・初めてのPerl 改訂第2版

その他、参考書籍として深沢千尋さんの『かんたんPerl』と木本裕紀さんの『業務に役立つPerl』も追加してはどうか? と提案しておきました。

かんたん Perl (プログラミングの教科書)

かんたん Perl (プログラミングの教科書)

もっと自在にサーバを使い倒す 業務に役立つPerl (Software Design plus)

もっと自在にサーバを使い倒す 業務に役立つPerl (Software Design plus)

ゆるくて鋭い突っ込みと具体的なレクチャーで作業を促してくださった@charsbarさん、前夜祭に続き圧倒的なパフォーマンスで段取りを組んでくださった@karupaneruraさん、そしてこのような機会を作ってくださった@skajiさん、ありがとうございました。

焼肉

エンジニアといえば焼肉ですが、この日の打ち上げ(?)も焼肉でした。たしか会場は以下。

焼肉酒場 牛恋 那覇松山店(那覇/焼肉) - ぐるなび

入ってすぐ、店員さんから「牛恋(うしこい)は初めてですか!?」と前のめりに聞かれて(たぶん決まり文句)、「あ、はい・・」という感じになったのが記憶に深く残っています。

参加者は錚々たる面々。上記の方々に加え、本編の最後にキーノートを務められた@yappoさん、同じくPerl Mongerとして著名な@xaicronさん、そしてもう何年も前、YAPC::Asiaのリジェクトコンのときに「malaさんですか?」と話しかけて以来のmalaさん等々。

とにかくハイレベルなプログラマーが集まっているので何を話しているのか理解できない時間の方が長かった気がしますが、まさにそういった時間を体験することこそがこのハッカソンに参加した目的でもあったわけで、考えてみるとその念願はこの焼肉会でようやく達成されたのかもしれません。

個人的には、@xaicronさんに以下の記事およびそれを含むテスト系のアドベントカレンダーがすごい参考になって何度も見直している、という話をできたこと、そしてそれを書いた頃にはどういう動機でどんな感じで書いていたのか、みたいなことをお聞きできたのは嬉しかったですね。
perl-users.jp

ちなみに、Perlアドベントカレンダーのテストの話といえば、@myfinderさんの以下もそれはもう何度も読んでいます。

Test::Moreでテスト事始め - JPerl Advent Calendar 2009

お土産屋めぐり

最終日。3/3が本編だったので、翌3/4に沖縄を発った人も多かったようですが、ぼくは上記のハッカソンに参加したので帰りはこの日、3/5でした。

結果的には、このスケジュールがYAPC恒例の飛行機ガチャにつながって、出発時刻は延期につぐ延期、もう今日はダメか・・? という頃になってようやく&突然飛んで、しかし羽田に着いた頃にはもう終電が自宅まで届いてなくて、たしか蒲田あたりに一泊するはめになったりしましたね・・。

しかしそこから少しだけ時計を巻き戻して、飛行機の予定は夕方だったので、ひとまず午前および昼過ぎまではようやくの&今回初の沖縄観光。

といっても、それほど時間があるわけでもないので、とりあえず那覇の公設市場で本場の沖縄そばを食べて、残った時間でお土産を買って帰ろう、という算段でした。

沖縄そばをどこで食べるか? については、さとなおさんこと佐藤尚之さんの以下を参考にしました。

沖縄の行った店リスト(170店)|さとなおのおいしいスペシャル

さとなおさんはぼくがかつて震災ボランティアを手伝っているときに、団体は違ったもののそのご活躍を見ながら、「ああ、すごい人だな」と思っていた方。信頼のおける、尊敬できる人。その人が沖縄のあちこちを食べ歩いて、ちょうどぼくが今回歩き回れる範囲も上のページでいろいろレポート(&レート付け)してくれています。ありがたい!

ということで、まずは目当てにしていた公設市場から。1階には生鮮食品のお店がすごい勢いで営業を繰り広げていますが、その2階には飲食店街が広がっています。そこをぐるりと一周した後、さとなおさんのレポートを読みながら「ここがいいかな」と思ったところに入店・・したつもりが、いきなり失敗。じつはこの飲食店街、店同士がびっしり並んでいるのですが、その店の境界が非常にわかりづらい。それで、目当てにしていた店に入ったつもりが、隣の店の席に着いて注文してしまいました。

f:id:note103:20180305120535j:plain:w300
(絵に描いたような普通の沖縄そば

いや、普通に全然おいしそうだし、実際「こんな感じだと思ってた」という味だったし、値段も量もほとんど隣と変わらないので、不満ということではないものの、それでもいきなりつまづいた〜・・という感じ。

幸い、このときには半量で頼んでいました。かなりレアな機会ということもあり、そば一杯で終わるつもりはなかったので・・。それで、ふたたびさとなおさんのレポートを見ながらあちこち歩いてみたところ・・出会ったお店がこちら、「牧志そば」。

f:id:note103:20180305134319j:plain:w300

ちょっと見づらいですが、ドアに「ソーキそば専門店」と謳っています(肉筆で)。そしてさっきの店よりずっと安い。さらには(たしか)100円追加で沖縄名物の炊き込みご飯「じゅーしー」も食べられる。ということでそれらを注文。

f:id:note103:20180305132328j:plain:w300
(目が覚めるほどシンプルなソーキそば)

f:id:note103:20180305132713j:plain:w300
(じゅーしー。普通にボリュームある)

んー、おいしい!(ガッツポーズ)
やっぱりさっきの市場のお店、悪くはなかったけど、いわゆる観光客向けの感じだったのかな・・と思ってしまうほどこちらの店は大満足。諦めなくてよかった・・。

気を良くして、しばらく散歩。

f:id:note103:20180305122010j:plain:w300
(パラソル通り、と言うらしい)

f:id:note103:20180305123323j:plain:w300
(でかい)

f:id:note103:20180305124525j:plain:w300
(ぐっと来る)

f:id:note103:20180305124558j:plain:w300
(猫)

f:id:note103:20180305145634j:plain:w300
(ちんすこうはここで。@国際通り

こんな感じでグルグル回ってから、ふたたび公設市場に戻ってきたところでなんだか気になるお店を発見。たぶんこちら。
www.satoukibikotobuki.com

さとうきびジュース・・。ここで飲まなかったら後悔しそう、と思っておそるおそる注文。すると、いきなりナタみたいなものでバシン、バシン、とご主人がさとうきびをタテに割り始めて、おもむろに鉛筆削りみたいなジューサーに投入。これ、すごいな・・と思って許可を取って撮らせて頂きました。

youtu.be
(マシンの下の方にコップがセットされていて、そこにジュースが入る感じみたい)

できあがり。

f:id:note103:20180305153326j:plain:w300

そのまま店内の小机を借りて飲み干しました(持ち歩いたらゴミの処分に悩みそうだったので)。けっこうスッキリした甘さでおいしかったです。

そろそろこの辺で疲れてきたので、お土産探しモードに切り替え。先ほど、公設市場の食堂階で1枚のチラシを見かけて、「ゆっくる」という観光案内所が紹介されていたので、とりあえずそこへ向かいます。

machigwa.info

アーケード街の並びにある小さなスペースですが、スタッフさんたちがいろいろ優しく教えてくれました。この辺でお土産屋は・・? と聞くと、すぐ近くにある「てんぶす那覇」というビルの1階に、この案内所の姉妹店のような感じで「ショップなは」という店が入ってるので、そこに行ってみたら、とのこと。

ショップなは

このてんぶす那覇、ものすごい穴場スポット。1階には休憩できるスペースもあるし、トイレも観光案内所もある。国際通り近辺というのは、なにげに「ちょっと休める場所」というのがないので、これはすごい助かりました。ということで、お土産を探す前にしばらく休憩・・。

の後、お土産物色。店員さんにあれこれと相談。「こういうのありますか?」「こういうのは?」と。家族へのお土産はもちろん、個人的にはなんと言っても古酒。「古酒ってあまり馴染みがないんですが、どういうのがオススメでしょう?」と聞いて、教えてもらったのがこちら。

www.koosugura.jp

たしか30度で720cc。1800円前後。初めてだったらこれがオススメ、と。折しもキャンペーン的なタイミングで、寝かせる前のそれ(いわゆる泡盛)も小瓶でついてくるという。嬉しい!&即決。

トータルでたぶん20分ぐらい、あーでもないこーでもない、とじっくり選んで、ようやく会計。そして自宅への郵送もお願いしました。

とにかく先ほどのまちぐゎー案内所「ゆっくる」にしても、この「ショップなは」にしても、まったく何も知らない状態で那覇情報を知りたかったら最適の場所だと思いました。

とくに「ゆっくる」の方では「沖縄そばめぐり」のマップなどももらって、うわー、今さら! 最初にここに来ればよかった・・と激しく後悔しましたね・・。まずはこちらの案内所を訪ねて、全体を把握してから各所をめぐれば効率が良かったなあ、と思いました。というか、次行くことがあったらそうします。

飛行機ガチャ

上にも少し書きましたが、YAPC名物の飛行機ガチャも体験できました。この日は夕方ぐらいから雨が降り出して、一気に豪雨になり、しかし東京はさらにすごかったらしくて「羽田に着陸できないから」という理由でなかなか飛べなかったようです。

個人的には、その那覇の豪雨が地味にキツくて、靴も靴下もビショ濡れ・・替えの靴下は預けた荷物に入れてしまっていて、売店で靴下、いやせめてビーチサンダルでもないかと探しましたがそういうのも無く・・。けっこう心身ともにダメージを受けました。

そんな中、ヤケになって買った紅いもソフト。少しはストレスも軽減された気がします。

f:id:note103:20180305192207j:plain:w300

結局、飛行機は21時過ぎぐらいに那覇を飛び発ち、しかし自宅までは間に合わなかったので都内で一泊して、3/6に帰り着きました。
おつかれ!!

終わりに

ということで、記録しそびれていたあれこれをまとめて書いてみました。これで思い残すこともなく、ぼくのYAPC::Okinawaを終わらせることができます。(おそい)

三度、精神的にも肉体的にもタフなスタッフの皆さん、そして誰も彼もめっちゃ優しくてすぐに友達みたいになってしまった沖縄の皆さん、楽しい旅をありがとうございました! また行きたい!!

*1:本編に届かなかった方による発表イベント。

*2:これについては他の記事で詳しくやっているので割愛。以右などご参照のほど。21世紀の文字起こし(2) - the code to rock

*3:しかしこれ、自覚的には当日とまったく同じ環境で再現したら成功したんだけど・・どうして現場で駄目だったのかいまだにわからず。

*4:管理されている@argrathさんは前日のうちに、これまた @charsbar さんからご紹介頂いていました。

bashでコマンドライン引数を複数取得する方法を間違えて認識していた

これまで気づかなかった方が不思議なのだけど、ハマって解決したのでメモ。

.bashrcに自作関数fooを作って、ターミナルから呼び出す際に、引数としてbar1, bar2, bar3を入れるという場合。

受け取り側では、今までこんな感じで関数を書いていた。

function foo {
    local arg="$@"
    echo $arg
}

これでこのように呼び出すと、

$ foo bar1 bar2 bar3

このように出る。

bar1 bar2 bar3

だから当然、この中のbar2を取り出したいと思ったら、関数にはこのように書けばいいのだと思っていたけど、

function foo {
    local arg="$@"
    echo ${arg[1]}
}

実行しても何も出てこない。

おかしい・・と思ってこのようにプリントデバッグしてみると、

function foo {
    local arg="$@"
    echo all: ${arg[@]}
    echo arg0: ${arg[0]}
    echo arg1: ${arg[1]}
}

こんな感じ。

all: bar1 bar2 bar3
arg0: bar1 bar2 bar3
arg1:

ひとつ目の要素に全部入ってるんですね〜・・😇

で、しばらくハマっていましたが、関数内での引数の受取り時に、配列として受け取ればよかったようです。

function foo {
    local arg=("$@") # <= New!
    echo all: ${arg[@]}
    echo arg0: ${arg[0]}
    echo arg1: ${arg[1]}
}

実行。

all: bar1 bar2 bar3
arg0: bar1
arg1: bar2

OK!

んーむ、引数を用いた.bashrc内の関数、少なくとも3年は使ってきた(書いてきた)と思うんだけど、全然気づいてなかった・・。

同じ変数名でなくてもいい部分を同じ変数名にして初心者を混乱させてしまう現象

最近はProgateでRubyを中心にいろいろ未知の言語に触れている。

prog-8.com

Progate、控えめに言ってグレイトすぎるサービス。勉強法についてこれほど意識的なプログラミング学習サービスを他に知らない。「回転」や「定着」や「インセンティブ(ごほうび)」みたいなものが学習者にもたらす効果について、これ以上なくストイックに追求していると思う。リスペクト。

さてしかし、そのProgateのRuby学習コースIVの中で、ありがちな不備というか、これはまったくProgateに限ったことではないのだけど、すでにプログラミングをよく理解している人が初心者に教えたり入門書を書いたりするときにやりがちな悪例(というか推奨できない教え方)を目にしたので、記しておきたい。

具体的には、上記コースの「インスタンスメソッド」の項をやっているときに、こんなサンプルコードに出会った。(部分的に編集して抜粋)

class Menu
  attr_accessor :name
  attr_accessor :price
  
  def initialize(name:, price:)
    self.name = name
    self.price = price
  end
  
  def info
    return "#{self.name} #{self.price}"
  end
end

menu1 = Menu.new(name:"すし", price:1000)

puts menu1.info

実行すると、こんな。

すし 1000円

なんの変哲もない、シンプルなサンプルコードのように見えるけど、じつはここには初心者を混乱に陥れる問題が潜んでいる。

それはどこか? たとえば、ここ。

  def initialize(name:, price:)
    self.name = name
    self.price = price
  end

「name」と「price」という変数名が、本来必要な数に比べて多すぎる。

その言い方でわかりづらければ、以下の修正例を見てほしい。

  def initialize(name_foo:, price_bar:)
    self.name = name_foo
    self.price = price_bar
  end

先ほどはnameとpriceが3個ずつ出てきたが、ここでは1個ずつあるだけで、あとはname_fooとprice_barに置き換えられている。

さて、ここでは一体、何を直したのだろうか? それは、

  • 同じ変数名じゃなくてもいい部分にも同じ変数名を使っている

という状況を、

  • 同じ変数名じゃなきゃいけないところだけを同じ変数名にしている

という状況に変えた、ということになる。

最初のサンプルコードでは、「本来なら別の変数名でも構わないところ」が、なぜか(たぶん何となく)「同じ変数名」になっている。そして、初心者がそれを見てどう思うのかというと、それらの変数名が「同じでなければいけない」と思ってしまう。

だから教える人は、自分たち経験者にとっての「同じ変数名でなくてもいい場所」が、初心者にとっては「同じ変数名であってはいけない場所」なのだということを理解しながら教えてあげなければいけない。

もちろん、ある程度習熟してくれば、これらの箇所で同じ変数名を使いたくなるのは自然なことだと思う。

だけど、「同じ変数名にしてもいい(場合によってはその方が便利)」ということと、「同じ変数名にしなければならない」ということはやはりまったく別のことだ。

そして初心者にとっては、「なぜ同じ変数名にしたのか」を説明されなければ、それは「同じ変数名にしなければならない」という意味になる。

どうもこのたぐいのズレがプログラミングの入門書では散見される。そしてそのつど、「ああ、わかってないな・・」と思ってしまう。*1

変数名というのは、その中身がどんな値であるのか、外側から(中身を見なくても)大体判断できるように付ける目印というか、外装みたいなものだろう。

プログラミング経験者は、コード全体の文脈を踏まえて変数を見ているから、その中身をすぐに想像できるだろうけど、初心者はそうではない。初心者は同じ変数名を見たら、中身も同じなのだろうと思ってしまう。あるいは、「中身は違うかもしれない・・けど、確証はない・・」という状態。言い換えると、変数の中身を頭の中でトレースできていない。

中身も役割も異なるのに、同じ変数名が付いているというのは、人間で言ったら「別人なのに全身同じ服」みたいなもので、だからプログラミング初心者にとっての「値が異なるのに同じ変数名」という状況は、欧米人にとっての「背格好がほぼ同じでまったく同じ服を着ている日本人」みたいなもので、見た目から中身が異なることを判断するのは難しい。というか単純にまぎらわしい。

変数名は中身を想像させるために付けているのだから、経験者ほどにはその中身を想像できない初心者に対して、そういうまぎらわしいことをしてはいけないと思う。外から見ただけで、「ああ、あそこで使った変数をここでも使い回せるのか」と直感的にわかった方が、より効率的に、本質的な構文を学びやすくなるのではないだろうか。

話を戻して、上記の修正はメソッドの呼び出し部分にも影響を及ぼすから、一応全体に修正を行き渡らせたサンプルも示しておく。

class Menu
  attr_accessor :name
  attr_accessor :price
  
  def initialize(name_foo:, price_bar:)
    self.name = name_foo
    self.price = price_bar
  end
  
  def info
    return "#{self.name} #{self.price}"
  end
end

menu1 = Menu.new(name_foo:"すし", price_bar:1000)

puts menu1.info

https://i.gyazo.com/b61dff70f93446898a9fa85426e0e0e8.gif

しかしこの、「同じ変数名でなくてもいい部分」をつい普段のクセで「同じ変数名」にしてそのまま入門書などに書いてしまう現象、なにか名前をつけたい。そしてこうした問題がくり返されないための目印みたいなものにしたい。

*1:とはいえ、本の場合はこういうズレは編集者さんが見つけるべきだと思うけど。執筆者はプログラミングのプロではあっても、入門書のプロであるとは限らないわけだから。