TokyoGirls.rb Meetup vol.1 に行ってきた

TokyoGirls.rb Meetup vol.1 に行ってきました。

techplay.jp

昨年11月にフリーランス編集者からRailsを使うIT企業(のカスタマーサポート)に転職したので、今後はRubyコミュニティとの接点を増やしていきたいな、と思っていました。

その一環として、昨年後半には大江戸Ruby会議07に参加して、今年の春にはRubyKaigi 2019に参加するつもりですが、前者の大江戸の方で見たしなもんさんがこれに参加する、という話をTwitterで見かけて抽選に応募したところ当選。という流れで、同イベントに参加してきました。

現場の雰囲気については、ハッシュタグを追うとある程度わかるかもしれません。

https://twitter.com/search?vertical=default&q=%23tokyogirlsrb&src=typd

以下、簡単に感想を。

かなきゃん(@_kanacan_)さん

元アイドルにして携帯キャリアのエース販売員。中学のときの技術の時間? にHTMLを教わったというぐらいお若い方でウルトラカルチャーショックを受けましたが、それ以上に生き方・考え方みたいなところに刺激を受けました。

speakerdeck.com

たくましいとか強いとかしたたか、みたいなことはいくらでも言えるんだけど、今回この発表から感じたもっと本質的なところを一言で言うと、自分が何を欲しいのか、どうなりたいのか、みたいなことをすごく自覚している、あるいは自覚しようとしている、ということですね。これ、ぼくにはすごく欠けているところです。これがないと、ただフラフラ流されるままというか、本当はもっと欲しいものがあるのに、他人から「君はこれでいいでしょ?」と言われたら「あ、はい・・」みたいになってしまうんですよね。

印象的だったエピソードもいくつかありましたが、とくに残ったのはSmartHRに応募するときの話で、駄目かもしれないけど、失敗したらそれはそれでストーリーになる、というところ。ここで言う「ストーリー」というのは、仮に落ちても、その2年後ぐらいにもっと力を付けてから「一度落ちたけど、また挑戦しに来ました!」って行けばかつての失敗もストーリーとして価値を持つ、みたいなこと。これを考えて実行できるのはスゴイと思いました。

だって、そんな風に考えられるようになったら、すべての失敗は成功の一部になりますよね。

実際には、そんな風に考えたりトライしたりできるっていうことは、そのウラに何十倍もの失敗があるんだろうと想像します。それも全部引き受けながら、トライを続けるその生き方には大いに学ぶところがありました。

*参考記事として紹介された以下のブログ、あとQiitaも読み応えがありました。

しなもん(@sinamon129)さん

前述の大江戸Ruby会議07で一度発表を見ていて、それがものすごい面白かったので、今回の目当ての一つはしなもんさんの発表でした。

speakerdeck.com

果たして、その大江戸のときの話とある意味ワンセットというか、合わせて読むと一段深く楽しめるような、やはり今回も非常に面白い発表でした。

*大江戸Ruby会議07のリポートとしなもんさんのスライドは以下。

障害対応・深夜メンテナンスはすごい人がやってる印象、だからそれに憧れていた、という話。ぼくはプログラマーではないですが、すごいわかる気がしました。たぶん、そのすごい人たちもまた、そういう作業を陰惨な雰囲気で、ではなく、どこか充実した感じでやっていたのかな、という気もします。で、そういう人に自分もなりたいな、みたいなことを感じたのかな・・とか。

印象に残ったのは、できる先輩同士がやってるのを見ながら「その話、どこ見ながら言ってます?」みたいにツッコミながら追いかけていた、という話。たしかに言われてみればめちゃ効率いい方法だけど、自分だったら現場でそんな風に考えたり聞いたりできるかなあ・・と。

単純に、そういう合理的な方法を考えて実際に行動に移す、というのができてスゴイ、と感心しました。自分の今後にも参考になりそうだな、と。

スポンサーLT

スポンサーLTでは万葉の鳥井さんの発表が印象的でした。

speakerdeck.com

というのも、万葉には働き手を支えるいろんな仕組みがそろっているという話が次々出てくるんだけど、これがけっこうどれもヴェルク(昨年ぼくが転職した先)を想起させるんですよね。

ヴェルク株式会社 - board・データ分析・受託開発

*ちなみに、転職したときのぼくのブログは以下です。
http://note103.hatenablog.com/entry/2018/11/10/172527

社員それぞれの都合を最大限生かせる仕組みを用意する感じというか。あるいはぼくなりにもっと原理的なところを言うなら、社員をとことん人間扱いする、みたいな感じでしょうか。

おまけに、どちらもRailsを使ってる・・!

あえて言うと、万葉さんの方は女性の働きやすさという点でより特徴的かなと思いました。
ぼくはプログラマーではないですが(再)プログラミングの本はいくら買ってもOKと言ってもらっているので、万葉さんの以下を読みつつ、新入社員教育用カリキュラムもやってみたいと思っています。

github.com

よう(@youchan)さん

じつは今回のイベント、しなもんさんやかなきゃんさんの発表を見たいというのも大きかったですが、タイムスケジュールを見て一番期待していたのはこちらのようさんの発表で、期待に違わぬとても面白い内容でした。

youchan.org

最初に印象に残ったのは「千葉の人、いますか?」という質問で、なぜなら今は千葉のRubyコミュニティがない(アクティブではない)ので、とのこと。ぼくは千葉の人で、しかもけっこう近いところにお住まいだったので、え、だったらそれ作るの参加したい・・と思いました。(今度また何かの集まりに顔を出したらお声がけします・・)

期待していたというのは、Ruby入門みたいな話だったからですね。それは言語の勉強という意味でも、コミュニティへの入り口という意味でも。

「すべてがオブジェクト」とはRubyを語るときよく語られることですが、今回初めて「あ、なるほど・・」という腑に落ちた感じが少ししました。(まだあまりRuby自体触っていないので、本当に少しですが)

ぼくは今まで5年ほど、Perlを趣味レベルではありますがずっと触ってきたので、その辺も思い出しながら聞いていました。関数型言語と絡めたあたりの話も興味深かったです。

それから後半の、男性中心なのも問題だけど、だからって女性だけなら良いってわけでもない、偏るのが問題。という話、まったく同感でした。

問題は、そういった状況が必ずしも悪意によって生じるのではなくて、むしろ大抵の場合は単に無意識・無自覚のうちに起きてしまう、ということなのかなと。であればこその大人力・思慮・配慮が求められるということなのかなと。

言い換えると、つねに思考停止せず、より良い環境を実現するための方法を想像したり、考え続けたりすることが必要なんだろうな・・と。

そうそう、あと余談ではありますが、ようさんはRabbitを使っていましたね。

Rabbit - A presentation tool for Rubyist

やっぱりつくづく、登壇者だけでなくお客さんにもプレゼンの進捗が可視化されてすごいツールだなあ・・と思いました。少し前に自分でも使おうと思ったものの(YAPC::TokyoのLT)、ちょっとデザインのカスタマイズが難しい・・と思って諦めたことがあったので、あらためてもう少し触ってみようと思いました。

かとりえ(@katorie)さん

最後のかとりえさん、終盤の子育てを絡めた部分は時間の都合もあって概要のみという感じでしたが、具体的なチーム作業のことも多く触れつつ、全般的には女性がどんな働き方をしていけるか、ということについて一番現実的・実感的なイメージを伝える内容だったという印象を持ちました。

speakerdeck.com

Web業界・エンジニア界への惹句としてキラキラした美辞麗句はそこいら中にあって、あたかもこの業界に入りさえすればそれが実現するかのように思ってしまいがちだけど(だから気をつけて、とかなきゃさんも言っていた)、本当に必要なのは誰が具体的にどんなことをして、その結果としてどんな今があるのか、という話で、これからそういう業界に飛び込んでみたいと思っている人たち(とくに女性)にとっては貴重な話だったのではないかな、と思いました。

すべての発表が終わった後、懇親会の方は今回はパスしました。ケータリングのすごい良い匂いがしていましたが、体調が今ひとつだったので。とくに食事の席は外しておいた方が無難かな・・と。

しかし懇親会はボッチ対策でグループ分けの工夫があったようですね。

すげーアイデアだ・・とハッシュタグを見ながら思っていました。(もし残っていたらVimグループでした)

雑感

女性メインでありつつ、男性の参加も一定割合まではOK、というこのシステム、素晴らしいと思いました。

とくに印象的だったのは、質疑応答でどんどん女性参加者が発言していたことですね。それも、手元のメモを見ながら、というなんだか真面目な感じ・・すごい良いなと。

しかしこんな風なシステムだと、女性ばかりが優遇されるような雰囲気が醸されてしまうのでは? という懸念もありそうですが、この辺のコンセプト的なことについては、個人的には主催の伊藤淳一さんによる以下のブログ記事に大元のことが書かれていると思っています。
blog.jnito.com

とくに、以下2点ですかね。

  • 日本のITエンジニアの世界は、まだまだ比率的に男性の方が圧倒的に多い
  • いろんな勉強会や初心者向けのイベントもあるが、そういった場所でも男性が多いので、(主催者がいくら「女性でもOK」と強調しても)女性にとっては敷居が高い

あとは、少し前に自分の別ブログで抜き書きをしたのですが、作家の森博嗣さんによる以下の言葉も近いことを言っていると思います。

男女平等などの流れで、「女性ばかりを優遇しすぎではないのか? それでは平等ではない」と反発する声もあるのですが、これは、これまでの歴史を知らない発言だと言われてもしかたがないでしょう。つまり、それくらい女性を優遇する仕組みを押し出しても、まだまだ平等ではない、という歴史です。真っ直ぐ走るためには、ハンドルを真っ直ぐにすれば良いわけですが、今まで右に進んでいたら、左にハンドルを切らないと真っ直ぐにはなりませんからね。
森博嗣数奇にして有限の良い終末を』より/太字は原文ママ

今はまだ、ここで言う「ハンドル」を真っ直ぐにしたままでは足りない状況なのかな、と。その意味でも、とても意義深いイベントだったと思います。

あらためまして、スタッフの皆さん、登壇者さん、参加者の皆さん、おつかれさまでした。楽しい時間をありがとうございました。

なぜアウトプットするのか

2013年からPerl入学式(Perlによる無料のプログラミング講座)でお世話になっている id:xtetsuji さんから、ぼくがアウトプットを続ける理由は何か? という質問というか、お題をもらって、しばらく考えていました。

ここで言うアウトプットとは、直近で言うと去る1月終盤に行われたYAPC::TokyoでのこのLTとか。

note103.hateblo.jp

あるいは昨年の今頃に発表したこちらとか?

note103.hateblo.jp

その他にも、このブログをはじめとするネット上での各種意見もそれに含まれると思います。

あとは、いろんなイベントに顔を出してもいますね。去年だけでも、上記以外にbuildersconとか、大江戸Ruby会議07とか、Vimconfとか。

*大江戸Ruby会議については最近公開されたるびまのこの記事がとても良かったです。シェアさせて頂きます。
magazine.rubyist.net

で、そういうイベントでまた、いろんな人に自分から話しかけたり。これもまたアウトプットかなと。

さて、それで最初の質問に戻りますが、なぜそんなことをするのか? という話ですが。

それに対する答えのいくつかは、最初に挙げたYAPCでのLTスライドに書きました。曰く・・

  1. やったことや考えたことを忘れちゃうから、メモがわりに。
  2. 見知らぬ人への手紙。どこの誰かもわからない人に知見の共有。
  3. 自慢したいから。
  4. 恥ずかしさよりも、それをやりたい気持ちの方が強くなるから。

ということ。

とくに、最後のはある意味一番大きいかなと思っていますが、これってじつは「なぜアウトプットしないのか?」という視点から捉えることもできて、ぼく自身のことを考えると、「ああ、あのとき、なんであれをやらなかったんだろう!?」と思ったときの答えは、結局「失敗したくないから」とか「絶対に恥ずかしい思いをしたくないから!」ということだったと思います。

実際には、何かを「やらない」理由なんて100でも1,000でも挙げることは可能で、いくらでもやらない言い訳なんてできるけど、でもやっぱり最後の最後には「失敗したくない」という理由に行き着くはずだと思っています。だって、絶対に失敗しない唯一の方法は、それをしないことですから。試合に出なければ、100%負けません。間違いない。

だから、「なぜアウトプットするのか?」という質問は、単純にそれをひっくり返せばよくて、「失敗してもいい」と思えた時というか、「失敗したくない」と思う以上に「それをやりたい」とか「実現したい!」と思った時があったからですね。

でも、その「実現したい!」っていうのも、そう書くとなんだかポジティブに聞こえますが、実感的にはもっとしょぼい感じというか、ようは「もったいない」って思っちゃうんですよね。たぶん、ぼくがアウトプットする理由の第一ってこれかも、と今思いました。

人生は有限で、チャンスは一度だけではないかもしれないけど、でも生きてる時間が限られてる以上は何度も巡ってくるわけじゃないから、次のチャンスはもう生きてるうちには来ないかもしれない、じゃあ、今やっとくしかないんじゃない? みたいな。

それで、渋々というか、仕方なくというか、「二度とできないぐらいだったら、いま頑張ります・・気乗りはしないけど・・」みたいな感じですね。

その意味では、なんというか、捨て身になっていることも多い気はしますね。それまで丹念に育ててきた何かを一気に全部捨てて次の場所に行く、みたいな。そのことにあまり躊躇がないというか。

ぼくは美大に入って、将来何をしたいとかまったく考えないまま大学4年間を過ごして、卒業してもまだ何も決めず、30を過ぎた頃にようやく継続的な仕事をもらえるようになって、でもそのまま43歳になるまで一度も定職につかずに生きてきて、ようはずっと「なんとかなるっしょ」のままやってきた感じがあるんですよね。

その根無し草感というか、べつにカッコつけるつもりはまったくないですが(とくにカッコよくないですか)、実際本当にそんな感じだったので、あるとき突然どっかに飛び込む、チャレンジする、ということに対して抵抗感が少ないところがあるかなと自己分析します。明日から突然それまでの全部がなくなっても、まあ、わかりました、なんとかします、みたいな。

あるいは別の言い方をすると、「痛くない」という感じ。失敗したり、恥ずかしい思いをしたり、指をさされて笑われたりしてもべつに構わない、いやもちろんめっちゃイヤだし、傷つくし、全然積極的にそんな思いをしたいわけではないけど、それでも「まあそんなに、痛くない」という感じ。ある意味鈍感というか、無感覚ということなのかもしれないですが、でもそのある種の耐性みたいのができてきて、それで前半の方で言った「アウトプットしない理由」の方が、「やりたいこと、味わいたいこと」に比べて相対的に小さくなってくれているのかな・・と。

もうひとつ、これは先日、rubyist.club という数年前にやっていたポッドキャストの以下のエピソードを聞きながらふと思ったことなのですが、

rubyist.club

その中でゲストの@bash0C7さんが言っていたことで、「ロックスターに憧れていても、客席から見ているだけでは届かないから、どんな形でもいいから舞台から客席を見る側でありたい」と言っていて、ああ、それちょっと似てるなと。(実際の文脈とはちょっと違うかもしれないんですが)

上記の捨て身の感覚というのは十代後半ぐらいからあった気がするんですが、それとは別に、ぼくが自分の人生が大きく変わった分岐点として今でも思うのは、たしか28歳のときに菊地成孔さんの音楽私塾に申し込んだときで。その申し込んだ瞬間のことは今でも覚えていますが、雪の日で、古い貸家の暖房をつけてもなかなかあったまらない部屋でブルブル震えながらそれこそ捨て身で「絶対駄目だよなあ」と思いながらエイヤと申し込んだら50分後に入学OKの返事が来て。

その数週間後に第1回の授業があって、初めて目の前に現れた菊地さんを見て、あ、今までスクリーンの向こうにいた人が、現実でつながった。あれ、てことは今ぼくはスクリーンのどっちにいるんだ? こっち側? 向こう側? いやどっちでもないのか? みたいな。その日のその瞬間から、何かその「こっち」と「向こう」を分ける透明なガラス板みたいのが音を立てて砕け散った感じで、こんなふうに言うとあまりに綺麗にまとまってしまうんだけど、それがもしかするとぼくがアウトプットする側に入ったときだったのかな、という気も少ししますね。

実際、その菊地さんとの出会いがきっかけで、ぼくは編集者的な作業をするようになって、それが元になって大谷能生さんと共著で本を出すことになって、その経験を踏まえて後藤繁雄さん、坂本龍一さんとの仕事にも連なっていったわけで。

で、ここからがまた大事なトピックなんですが、そういう経験をする中でぼくがつくづく思っていたのは、結局そういう才能あるミュージシャン、クリエイターのような人たちとどう関係を結ぶかといったときに、やっぱりお客さんとして付き合うというのは、ぼくにはどうしても不合理というか、もったいなく感じられて、なぜならお客さんとしてアーティストに触れられるのってほんの一瞬だけで、にもかかわらずその「一瞬」を手に入れるためにかなりのコストを支払うことになるんですよね。あくまで個人の感想ですが。

じゃあどうすればいいのよ、と言ったら、その菊地さんの時のように生徒になるとか、あるいは坂本さんの時のように仕事相手になるとか。

まあ後者の方は運や他人の要素も大きいので、やりたいからってそう簡単には実現できないかもしれないですが、ただいずれにしても、ぼくはそういう巨大な才能をお客さんとして味わうのではなくて、もっとその人たちの近くで、もっとダイレクトに体験したいと思っていて、そのためには、彼らと対等な関係になるしかないと思っていました。言い換えると、たくさんいるお客さんの中の一人ではなくて、交換不能な役割を持ってその場に混ざるということなんですけど。

で、それってさらに言い換えると、結局自分もクリエイターになるしかないということなんですよね。自分も作る人になるしかない。なぜなら、お客さんとしてではなく現場に混ざるということは、その才能ある相手から「君には何ができるの? 何を作れるの?」と聞かれるということだから。現場の一員になる以上は、その輝く才能をただ近くで受け取って楽しむだけではなくて、自分からも何らかの才能を燃やした結果を提供しなきゃいけないから。対等な関係というのはそういうことだから。

つまり、リスクを取るということですね。相手にもっと近づきたい、まだ見たことがない巨大な才能の輝きを、生きているうちにもっと見たい、間近で見たい! と思ったら、自分もその人に何かを提供できる人になるしかない、「君には何ができるの?」と聞かれたときに提示できる何かがなきゃいけない。上手くいけば大きなリターンがあるけど、失敗したらもう立ち上がれなくなるほど傷つくかもしれない、というそれがリスクというもので、でもその輝きを本当に体験したいなら、リスクを取るしかない。

上記のポッドキャストでは「客席から舞台を見るのではなく、舞台から客席を見たい」と言っていましたが、ぼくの場合はそれで言うと、「客席からロックスターを見るのではなく、同じ舞台の上からロックスターを見たい」という感じでしょうか。

そう考えると、その後、38歳にしてそれまでまったく馴染みがなかったエンジニア界隈の人たちとつながりを持って、みんな坂本さんのことは知っていてももちろんぼくのことなんて1ミリも知らない人たちに囲まれて、なんのアドバンテージもなく、むしろどちらかといえばマイナスからのスタートみたいなところから、こんなふうに「どうしてアウトプットするの?」なんて質問されるぐらいコミュニティの人たちと親しくなれたりしてきたのは、そういう考え方だったり、経験だったりを重ねてきたからかな、という気もします。

以上、今度 id:xtetsuji さんとそれについて喋るときのためにメモとして書き出してみました。

Scrapboxの当日の日記ページにすぐ移動できるブックマークレットを作った。

小ネタです。

チェック終わりました。

javascript:(function(){ dt = new Date(); dtm = dt.getMonth()+1; dtd = dt.getDate(); if (dtm < 10) { dtm = '0'+dtm; } if (dtd < 10) { dtd = '0'+dtd; } date = dt.getFullYear()+'-'+dtm+'-'+dtd; window.open('https://scrapbox.io/***/'+date,"_self")})()

上記コードの最後の「***」のところをアカウント名に差し替えると、できます。

以下、アカウント名をnote103にした場合。

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

ちなみに、当初はクリックすると target="_blank" 的に新規タブが開くようになっていたのですが、同じタブ内で動いてほしいなあ・・と思ったもののどうしたらいいのかわからず、しばらく粘ってググっていたら以下が見つかり、

stackoverflow.com

window.open()の2つめの引数に "_self" というのを付ければOKでした。ナイス質問者!

以上です。

LT解題 - YAPC::Tokyo 2019

先週土曜に開催されたYAPC::Tokyo 2019でLTをしてきました。

yapcjapan.org

イベント全体の感想は別途まとめる予定ですが、その前に自分の発表について、覚えているうちに書いておきたいと思います。

目次

登壇スライド / 録音

まず発表資料というかスライドはこちら。

speakerdeck.com

手元で録音しておいた音声ファイルもSoundCloudにアップしておきました。

soundcloud.com

声、めっちゃ震えてるんですよね・・(笑)。しかもその震えがなかなか止まらないというか、むしろ後半に行くにしたがって増してくる感じすらあり、軽く絶望を感じながら、でもしょうがないのでそのまま最後までやりました。

たしか沖縄で発表したときも、「うわー、なんか緊張がむしろ増してくるじゃん!」と思ったものですが、つまり「話しているうちに落ち着いてくる」とか、「緊張するのは最初だけ」みたいなことは少なくともぼくの場合はナイようです。

とはいえ、やはりトータル的には、沖縄とどっちが緊張したかと言ったら今回の方が緊張しましたね。

これについてはその後の懇親会でsongmuさんもおっしゃっていましたが、たとえばメイントークって20分とか40分とかあるけど、それを見ているのは「そのトークを見にきている、全体からすれば一部の人たち」に過ぎなくて、でも本編LTってその時点でカンファレンスに残っている人全員が見ているもので、べつにその発表を見たくて集まったというわけじゃない、ある意味予備催眠率ゼロの厳しい目を持った人たちなので、そこで発表する方がよっぽどハードル高い、自分だったらまずメイントーク経験してから本編LTに挑む、みたいな話を聞きました。

いやほんと、心の底から同意です。喩えてみるならメインのトークは自著を書くようなもので、本編LTは雑誌や新聞に寄稿するようなものですね。自著は元々それに関心がある人が買ってくれるけど、雑誌やとくに新聞の場合、自分ではなくその媒体に付いたお客さんなので・・いろいろ厳しい!

プロポーザル / 何を提供できるか

イベント当日は1/26で、LTの締切りは1/22だったのですが、ぼくが申し込んだのはたしか1/21の夜とか、そのぐらいだったと思います。

プロポーザルはこんな感じでした。

# 自走するプログラミング入門者の探し方
 
プログラミングの初心者には、自らモチベーションを高めて学習を進めていける人と、そうではない人がいるようです。その二者を分けるものは何でしょうか?
 
私は長い間、ITとはまったく関係ない仕事をしていましたが、2013年のYAPC::Asiaで行われたPerl入学式に参加したことをきっかけに趣味のプログラミングに没頭するようになり、気がつけばYAPC::Okinawaで登壇を果たし、ついにはIT企業に就職していました。
 
私は冒頭に挙げた二者の中では前者にあたると思いますが、自分にどのような特徴や傾向があったのかと考えると、それは「アウトプットすること」だったように思います。LTでは自分の実体験を軸に、これについて発表したいと思います。

これは手元にあったメモなので、最終的に送った内容そのままではないかもしれないですが、大体こんな感じでした。

なぜこのテーマを選んだのか? と言ったら、一番の理由は、ぼくがYAPCの参加者(おもにエンジニア)に何らかの価値として渡せるものは何かと考えたときに、このネタぐらいしか思い浮かばなかったからでした。

LTで発表する内容は、ぼく一人が満足すればいいカラオケみたいなものではなくて、聞いている人が「ああ、この話を聞いてよかった」と一瞬でも思えるものであるべきでした。でも、ぼくは何か役立つ技術トピックを持っているわけでもありませんし、そもそもそういう知識も経験もありません。

だったら申し込まなければいいのでは、という気もしますが、後述の理由で申し込むこと自体はもう決まっていて、だったらとにかく「自分は持ってるけど他のYAPC参加者が持っていない何か」を探さなきゃ、となって結果的にこの話題に行き着きました。

少なからぬYAPC参加者がこのネタに興味を持つだろうと思った理由は、たとえば id:papix さんのこの記事を読んだからでした。

papix.hatenablog.com

そーだいさんも書かれていました。

soudai.hatenablog.com

こちらの方も時間をかけて考えをまとめてらっしゃいました。

blog.3qe.us

(時系列がバラバラですみません)

それらを読みながら共通して思ったのは、どれもが当然のことながら、プログラミングを「教える側」からの考えであって、「教わる側」が何を考えているのか、とくには、自走する初心者が何を考えているのか、感じているのか、何に突き動かされているのか、という点については、その立場の違いから原理的に(構造的に)触れられないのだな、ということでした。

であれば、プログラミングを「教わる側」のぼくがその欠けたパズルのピースを埋めることには一定の意義があるはずで、それをすれば多少はコミュニティの役に立てるのではないか、喜んでもらえる可能性があるのではないか、と思ったのでした。

応募するまで

少し時間を遡りますが、じつのところ、今回のYAPCでLTをするなんていう気持ちはまったくありませんでした。前夜祭のLTソンで発表する気すらなかったです。

(だって、忙しかったので・・)

でも、YAPCのチケットを買ったとTwitterでつぶやいたその日ぐらいから、 id:magnoliak さんから「LT募集してますよ」という煽り・・ではなくご案内を何度か頂いて、反射的には「ムリです!」という気持ちでいっぱいでしたが、ただお腹の底の底のところで、「んーしかし、magnoliaさんやスタッフの皆さんがこれだけ全力を投じているこのイベントに対して、しかもそのmagnoliaさん本人から応募を勧められているのに、やらないって選択肢があるのかなあ・・いや無理だけど、無理なんだけど、でもなあ・・」という逡巡が、何度押さえつけても戻ってきて、なかなか「やる」とも「やらない」とも決められないまま、とりあえずネタを考えてみておく、という日々を過ごしました。

そして最終的には、上述のとおり締切りの前日になって、「とりあえず」というつもりで一旦プロポーザルを書き始めてみたら思いのほかサラサラ内容がまとまって、それを見ながら「まあ、よく考えたらそもそも一択か」と思って応募に至りました。

この際には、せっかくやるなら前夜祭の方ではなくて、「毒を食らわば皿まで」という言葉もありますように、ぜったい怖すぎてマジやばいとは思いながら、応募するだけなら何も損はしないのだから、と思って本編の方に申し込み、その際に「駄目だったら前夜祭の方で」というオプションを付けておきました。

しかしこの、「応募するだけなら何も損はしないのだから」というのは、「タダより高い物はない」という言葉もありますように、恐ろしい誘い文句でして、それから発表までの間は何度も「あれ、これ万一選ばれたらかなり大変では? え、なんで応募したん? なんで??」という後悔にそれはもうさいなまれたものでした。

なんというか、プロポーザルは持ち前の調子の良さであたかも崇高なネタがすでに用意されているかのように悠然と書いてしまったものの、実際には具体的な内容はまったく固まってなくて、もし選ばれたらその場に見合うだけのガッツリしたものをその瞬間から一気に作らなければならず、いやいや、会社に通いながらそれは無理じゃん、って無責任じゃん、ってかなりマズイ、かなり・・とかなんとか、ただひたすらエネルギーが落ちていく感じでした。

果たして、LTの選考結果が発表されるのはイベント本番の2日前、1/24のお昼すぎでしたが、「LT採択が云々」という件名のメール通知が目に入ると同時に頭の頂点からこめかみに向けてイヤ〜な汗がズワッと降り出してきて、「今は見たくない・・というか落ちていてほしい・・」などと思いながらエイヤと開いたら採択されていて、ひえ〜マズイ! けど嬉しい! けど絶対失敗する! などの恐怖と混乱に包まれながら、でも同時にぼくのプロポーザルを見て期待を感じてくれた運営の人たちの顔も浮かんで、ああそうだ、その人たちの期待に応えなければいけないんだ。と、あちこちぶつかりながらなんとか覚悟を決めました。

構成の練り方

すでにプロポーザルを書いた段階で大きめの方針は決まっていて、どんなトピックを入れるかということも思っていたよりはスムーズにリストアップできたのですが、大変だったのはその筋道を整理することで、いくら考えても話がうまくつながりません。

それもそのはずで、これは上記のpapixさんたちのブログとは逆方向の性質ゆえというか、ぼく自身はプログラミング初心者の視点からものを感じたり言ったりすることはできるけど、テーマはそういう初心者を外側から見るような(すでに技術を習得した側からの)視点で立てられているので、一体どちらの視点を軸にしたらいいのか、またどうすれば双方の視点から語られるトピックを自然に構成できるのか、といったことが難しく、なかなかこれを整理できませんでした。

それでとにかく、言いたいトピックを一回全部入れた上で、それだとまったく時間に収まらなかったのでネタを足し引きしながら本の編集のように構成をまとめて、その「語りの軸足をどちらに置くか」とか、「どうやって自然につなげるか」とかは最後の最後まで後回しにする作戦を取りました。

視点や方針を定めないまま構成なんてできるの? とぼくも今これを書きながら思いましたが、ん〜、でもなんか、できましたね。言っておきたいネタはあって、それをどう見せるかまでは出来てしまうというか。

具体的には、こんな感じでした。

  • タイトル
  • 目次
    • その1
    • その2
    • その3
  • 結論
  • その1
    • 話の前提
      • 勝手に水を飲む馬
    • 自己紹介
      • commmons: schola
      • YAPC::Asia 2013 & Perl入学式
      • MOONGIFT
      • ブログ
  • その2
  • その3
    • アウトプット
    • なぜ?
      • 忘れちゃう
      • 見知らぬ人への手紙
        • メッセージ・イン・ア・ボトル
      • 自慢
      • 恥ずかしさが薄れていく
        • 相対的に
  • 引用
  • 結論(再)

ここでやっているのは、ただひたすら見出し文言の洗練とその入れ替えです。結論を最初の方に持っていったのも、結局最後の1行をコピーして初めの方にペーストする、という作業を見出しだけなら簡単にできるところから思いつきました。

ちなみに、今回の一連の作業はもちろん(というか)Vimでやっていました。沖縄での発表でも紹介しましたが、tagbarというプラグインを使って、こんな感じで左に本文、右に見出しを出しながら内容を詰めていきました。

f:id:note103:20190202210801p:plain

*いま気づきましたが、レイアウト調整の都合もあって本来見出しではないものが右に行ってますね・・文字を大きくしたいものを見出しにしていたので。まあ、暖かく見守って頂ければと・・。

そしてまた、このようにMarkdownファイル1本でスライド資料を作りきれたのは、ゆーすけべーさんによるPerlモジュール App::revealup のおかげでした。

metacpan.org

これがなかったらまず間に合いませんでしたし、このモジュールのおかげでKeynoteを地道にポチポチ調整することもなく、本質的な内容の洗練に集中できました。ゆーすけべーさん、ありがとうございます!

筋を通す / 引用

上で何度か書きました「筋道の通し方」ですが、最終的に思ったのは、「結局ぼくにわかるのは初心者側の話なのだから、初心者としての実感をメインにするしかない」ということ、そしてその上で、「アウトプットしてる人を探せ、なんて何も言ってないのと同じだから、そうではなくて、そのアウトプットからそれを支えるモチベーションを逆算的に見出して、もしそのモチベーションが自走型のそれだったら、その元にいる人は自走するプログラミング入門者だっていう論理なら行けるのでは」ということでした。

やや強引にも思える論理ですが、この準備期間でこれらのトピックを入れるにはその方向しかなかったのですよね・・。

ただ実際には、そこまで込み入った論理を説明するヒマはなかったですし、聞いてくれた人たちもそこまで論理のつながりみたいなものは気にしていなかったかな、とも思っています。

それとは別に、もうひとつ論理のつながりとして気になっていたのは、終盤の森博嗣さんの引用でした。

ぼくが今回絶対入れたいと思っていたのは、2本出した引用のうちとくに最初の方、「才能は決して埋もれない」というもので、これは本当にぼくを支える言葉になっています。といっても、それは何も「ぼくの才能が埋もれるはずがない」とおまじないのように思っているということではなくて、ただ「アピールの仕方にリソースを費やすぐらいなら納得行くまで物を作ろう」という気分を後押しするものとして支えにしている、ということです。

なのですが、この引用も結局、なんの支えになるのかと言ったら「教わる側」であるところのぼくを支えているもので、それを外から見る「教える側」とか、自走するプログラミング入門者を「探す側」の実感とは、ある意味では逆なんですね。なので、ん〜、この超終盤の決め手になるようなところで、教わる側視点の引用を出すのって正直意味わからん・・どうしよう・・と、これはかなり悩みました。

悩みましたが、でもこの引用は(くり返しになりますが)絶対必要で、確かにこれがなければ流れはスッキリして、誰からも突っ込まれないウェルメイドなスライドができたかもしれないんだけど、それって言いかえると「小さくまとまる」みたいなことで、せっかくここまで地獄の釜の蓋を開けるようなことをしてきたのに、最後に日和るんかい、というツッコミの方が勝ちまして、「もう論理とかどうでもいいからとりあえず入れとけ、説明は本番でしろ」みたいに自分に説得される感じで結局入れました。

結果的には、発表では「この言葉はぼくの支えになっていて、関係ないって思われるかもしれないけど今回の発表とめちゃ関係してます」みたいな、説明になってるんだかなってないんだかわからないようなことを言って終わってしまいましたが、その数分後に思ったのは、「自走するプログラミング入門者を何が支えているのかと言ったらたとえばこういう信念だから、知っておいて損はないですよ」みたいな観点から見れば筋はちゃんと通ってたな、ということでした。

ようは、瞬間的な反応とか、評価とか、そういうのはもういらないんだと。「いいね」とか、はてブとか、そういうのはもういいんだと。もちろんそういうのを求めたっていいし、その欲求は自然なものなんだけど、でも逆に、すぐには全く反応が得られなかったとしても、それは作品の価値とは全然関係ないし、気にするに値することじゃないんだと。それが本当に面白いものだったら、必ずいずれ評価されるから、作る人が本当に全力で気にすべきことは、それが本当に面白いものなのかどうかなんだってこと。それだけ。作る人はそのことだけに集中してればいいんだと。めっちゃ頑張ったけど全然評価されませんでした、見向きもされませんでした、なんていうのはまったく気にすることじゃなくて、めっちゃ頑張ったけど全然面白くなりませんでした、ってそっちの方がダメなんだと。そっちを気にしろと。それだけを集中して考えろと。・・そういうことをこの引用を通して伝えられたら良かったのかなと思いましたが、ぼく自身今これを書きながら「ああ、そういうことだったんですね」と思ったので、その時点で言えるはずはなかったですね。

いろいろスッ飛ばしながら、最後のまとめに触れ終わった瞬間の手元のiPhoneのストップウォッチは4分57秒で、あ、間に合った・・と思って「ピッタリ」と思わず言いました。実際はどうだったかわからないですが・・ぼくが締めの御礼を言ったあとにpapixさんのドラが鳴り響いて、ああなんか、すみませんありがとうございました、という感じでした。

練習、練習、練習!

しかしステージに上がる数分前まではけっこう正気だったんですけど、階段を上がる瞬間にはなんだか、真っ白な天国の光の中に入っていくような、意識が薄れていく感じがあって不思議な感覚でした。M-1グランプリの決勝に出る人たちとかってこんな感じなのかな・・とふと思ったり。ステージで何を喋っていたのか、ほとんど覚えていないですね。降りてから、「あれ、坂本さんの話ちゃんとしたっけ?」と本気で不安になったりしました(一応してました)。

ステージではもう、だから体が勝手に動くのに任せていた感じでした。そこで生きてくるのが練習なんでしょうね。スポーツとか楽器とかと同じで。普段練習した分がそのまま本番に影響するのかなと。今回、ぼくはスライドがなんとか形になるまでだいぶ時間がかかって、当日の昼前ぐらいまで浅草橋のホテルでスライドを作っていたので、その後にできた練習は正味3〜4周ぐらいでしたか・・もう少しできると良かったのですけど。

ぼくはパフォーマンスの出来/不出来として目に見えるのは山の頂上みたいなほんのわずかな部分でしかなくて、それを高めるにはひたすら山の裾野を広く盤石にしていくしかないと思っていて、つまりパフォーマンスの完成度を高めたかったらひたすら地味な練習をくり返すしかないと思っていました。それがまあ、結局は足りなかったがゆえのあの結果かな・・とも思っています。いやあ、口が乾いて仕方なかったですね。舌が口の中にひっついて喋れない! なんて経験、初めてだったかもしれません。ああ緊張しました。

緊張といえば、ちょっと聴いている人全員を意識しすぎたかなとも後から思いました。もう少し「こういう人に向けて喋る」という対象を絞って想像しても良かったのかなと。今回のYAPC参加者数は384人とのことですから、本編LTに残っていたのは300人ぐらいでしょうか(わからないですが)。なので、その全員に向けて喋っても大半には伝わらないはずで、だからそうではなく、その中のほんの3〜4人だけを相手に喋る感じだったらもう少しリラックスできたかな・・とも。いやまあ、次にそんな機会があってもそう上手くいくとは到底思えないですが・・でも理想としてはそういうことだったのかなあ、と。

また接続にハマる / バックアップ

前回のYAPC::Okinawaの前夜祭LTでもそうだったのですが、ぼくはいまだにMacとプロジェクターとの接続方法がよくわかっていなくて、今回もLT前の接続確認でかなり手間取ってしまったのですが、ぼくの後ろで次のチェックを待っていた id:moznion さんが「ミラーリングじゃないですか」と不調の理由をさっと指摘してくれた上に「それ、そこをチェックして」などと具体的に教えてくれて、沖縄のときには id:karupanerura さんに近い感じで救ってもらったことを思い出しましたが、本当に助かりました・・ありがとうございます。

ただじつは、その後にもまだ結構深刻なトラブルが待っていて、というのも事前に書き出しておいたスライドのPDFを投映しても一部が消えてしまうんですよね。で、こんなこともあろうかと思って、これまた事前にスライドを上げておいたSpeaker Deckのページにアクセスして颯爽と自分のスライドを開いたのですが、それもダメ!🙅‍♂️

え、ええ〜〜〜・・マジやばい、やっぱりプロジェクター意味わからん、苦手すぎる! と逃げ出したい気持ちになりましたが、じつはもう一つだけバックアップとして用意しておいたのが前述のApp::revealupのローカルサーバ機能で、念のためにこれをターミナルから開きっぱなしにして、ブラウザのタブもそれに合わせてあったのですよね。で、そっちに移動したら何とかまともに見れるようになって、これほんとに半ば無意識のうちにやっていた準備でしたが、もしやってなかったらスタートラインにすら立てなかったわ・・という感じでした。

そんな風にフルタイム・パニックみたいな状況でしたが、周りのスタッフの皆さんは常にスムーズかつ間違いなく発表できるようにすごく丁寧に段取ってくれていて、最後までストレスなく場に臨むことができました。ありがとうございました。

ベストLT賞

ぜんぶ終わって、もう何も残ってません・・灰になりました・・という感じで同じくLTに登壇された id:xtetsuji さんと並んで会場最前列に座ってしばらくしてから、ベストLT賞なるものがあることを初めて知りました。で、あ、これもしかしたら獲るかもな・・と思いましたね。自信があったわけでもなければ、誰かからそう言われたわけでもなくて、むしろやってるときは「会場、反応ないな!」と思っていたぐらいでしたが、なにか音もなく届いた手応え。みたいなものを感じていたんですよね。その何というか、一瞬の淡い期待感みたいなのが心地よかったです。もし事前にそういう賞があるとわかっていたら、狙って登壇していたかもしれないので、狙わずに発表しきって、かつそういう手応えを感じられたのが良かったなと。

(結果的にはそれはmoznionさんが受賞されて、その発表内容としても、またその後のsongmuさんのベストトーク賞への流れという意味でも、まさにベストなLT賞だったと思いました)

ご感想

終わってから、いくつか嬉しい反応を頂きました。

tomcha.hatenablog.jp

blog.3qe.us

sorehaedamame.hatenablog.com

nayuta-1999.hatenablog.com

morichan.qrunch.io

*他にもあったかもしれないですが、もし見つけたら追加します。

ありがとうございました。やって良かったです。

ちなみに、スライド上の文字と口頭の内容をずらすというのは意識的にやっていました。紙芝居じゃないのだから読み上げるのはやめよう、と。昔大学で「なんて退屈な講義なんだ」と思ったものは大抵、教科書をただ読み上げるだけのものでした。

でもそれに気づいてもらえるなんて! 伝わるものですね・・。

それからsongmuさん、これは以下の記事にも書きましたが、

note103.hateblo.jp

ぼくは勝手にsongmuさんに煽られ・・じゃなくて導かれるように情報処理の勉強をしてみたり、そうやって一歩一歩進んできた感覚を持っていたので、うわ、直接評価された! って思ってすごい嬉しかったです。

終わりに

本当はYAPC::Tokyo全体の感想の中にこのLT解題を入れるつもりでしたが、ご覧のとおり、だいぶ長くなったので分けました。会全体については、また時間を見つけてアップしたいと思っています。

(ドラフトはほぼできてるので、何ヶ月も先とかにはならないと思います・・)

今回のLTに採択されたときはこんなツイートをしましたが、

果たしてスタッフの皆さん、どうでしたでしょうか・・あまりみっともいい感じではなかったですが、自分的にはやり切りました。スライドにも書きましたが、ぼくは本当は恥ずかしい思いをするのも失敗するのもみっともないのも超!イヤだし、おそらく今後もずっとイヤですが、それを上回る「やるしかない」とか「これをやったら今まで見たことない風景を見られるはず」みたいなモチベーションでやらせて頂きました。恥ずかしさや不安をゼロにすることは決してできませんが、小さくすることはできるな、と今回の発表で自分に教えられました。やりたいことが大きくなるほど、それらは相対的に小さくなります。これをステップに、またこういうことに挑戦したいと思っています。ありがとうございました。

PHPで書いたWebページをVagrant+Ubuntu+Nginxで複数デバイスから閲覧する

PHPとは相性が悪い、というのがプログラミング入門初期からの実感で、これまで「おー、やった!いいじゃんPHP!!」みたいに思ったことは一度もありませんでした。

しかし昨年の後半、いろんな成り行きからもう頑張るしかない・・みたいな状況に追い込まれまして(たぶんそれについては別記事で)、少し本腰を入れてというか、時間をかけて対応しましたら、ようやく「はあ〜、できた」みたいになったので、ここにメモしておきたいと思います。

ちなみに、この現象と解消、以前から何度かくり返してはいたのですが、そのつど「あれって、一回できたはずだけど、どうやるんだっけ? もう忘れちゃったよ・・」というくり返しでもあったので、今度こそちゃんと記録しておく、というのもあります。

あとは、その以前に辿りついた解決法というのも、結局いろいろイジっているうちになんか知らんけど出来てしまった、みたいな感じだったりして、その意味でも再現しづらかったので今度こそ(略)という感じでもあります。

やりたいこと

記事タイトルにもバリッと書きましたが、今回の目標は

PHPで書いたWebページをローカルネットワーク内で複数ブラウザから閲覧する!

というものです。

これはメインのPCのブラウザから見るのはもちろんですが、スマホでも見れるとか、離れた部屋の別マシンでも見れるとか、そういう状態を指しています。

で、今回はそのWebページ自体は重要ではないので、以下のコードだけを記した hello.php というファイルを作成し、

<?php echo '<p>Hello, PHP!</p>'; ?>

これを Vagrant の共有フォルダに置いて閲覧できるようにする、としたいと思います。

その閲覧時の手順としては、最初にローカルサーバ上のトップページである index.html に入って、そこから張られている hello.php のリンクをクリックしたらそのページに移動して「Hello, PHP!」を見る。という感じで行ってみます。

先にその結論というか、成功した状態を見てみましょう。

https://i.gyazo.com/7b3a99735f887250aa85cb21f9263b0d.gif

はい、左上に控えめに「Hello, PHP!」と表示されました。これができればOKです。

環境の前提

記事タイトルにも書きましたが、今回はVagrantUbuntuを起動して、その中に入れたNginxでサーバを立てます。

Nginxを起動してHTMLのトップページを見られるようにするまでの段取りは、少し前に書いた以下の記事のママですので、今回は割愛します。ご興味おありの方は、そちらをどうぞ。

note103.hateblo.jp

余談ですが、今回のUbuntuは12.04ですが、このバージョン番号を調べるのに何気に時間がかかりました。どうやったら正確なバージョンを調べられるのだろう? と。

もちろん、ちょっとググればいろんな方法が出てくるのですが、どれも不要な情報があれこれと一緒に表示されてしまって、読み解きにそれなりにコストがかかるなあ、と。

しかしこれ、単にUbuntuに最初にログインしたとき、つまり「vagrant ssh」で入ったときに、このように出てくるんですね。

Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic x86_64)

完全に見落としていて、たぶんトータル20〜30分ぐらい費やしました。いやほんとに余談ですが・・。

さらにちなみに、今この手順でこのUbuntuを立ち上げると、14.04にせよ、と以下のように出てくるのですが、

 * Documentation:  https://help.ubuntu.com/
New release '14.04.5 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

今回は無視しています。

PHPファイルが無限にダウンロードされる問題

では、ここから本題です。ひとまずトップページが見えるところまで設定して、目的の hello.php を開こうとすると、こんな感じで・・

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

ページ移動すらせず、とりあえずファイルがダウンロードされてしまいます。何回クリックしても、何回でもダウンロードされます。(当然ですが)

これは今回の最初の難関ですが、同時にこの後どれだけいろんなことを試してもなかなか解消されない最大の難関でもありました。実際、ぼくのダウンロードフォルダはこの hello.php が大量に溜まってしまい、ひどい時はファイル名が hello.php(17) とかになってましたね・・。

PHPをインストールする

さて、この時点では何が何やら、原因のゲの字もわかりません。

ということで、とりあえずググりまくって最初に役立った記事はこちらでした。

freefielder.jp

とくに、ここで書かれているこのコマンド。

$ dpkg -l |grep php | awk '{print $2}'

リンク先では、これによってインストール済みのPHP関連パッケージを見つける、みたいな感じでこのコマンドが紹介されていましたが、ぼくがこれを打ってどうなったかというと、

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

はい。何も出ないですね。なんだろう、コマンド自体間違ってるのかな? と思ってPHPのところをPerlにしてみると、

https://i.gyazo.com/8183caae7b75e6a7a360357394f9397b.gif

ちゃんと出てきます。つまり、PHP自体まったく入ってなかったんですね。これには驚きました。なんだ、そもそもPHP入ってないんかい! という。いやあ、PHPってめっちゃメジャーな言語なので、当然どこにでも入っているものだという思い込みがありました。

さて、じゃあPHP入れようよ、簡単でしょ? という感じなんですが、これはこれで逆にあちこちに情報があふれすぎていて、今回ぼくが求める最小限のインストール方法ってどうしたらいいのか、精査するのがきわめて大変でした。

結論的には、以下のブログ記事の冒頭で紹介されていた、

thr3a.hatenablog.com

最低限のラインナップ。

$ sudo apt-get install -y php5 php5-fpm

これだけにしておきました。実際にちゃんと使おう、PHP書こう、という時はこれでは足りないのかもしれないですが、今回はオプション的な情報が入るとかえって煩雑になるので。

設定ファイルを編集

さてしかし、PHPのインストールが完了してもまだファイルのダウンロードは止まりません。クリックすればしただけPHPファイルがダウンロードされてきます。

そこで、次にどうしたかというと、上記の同記事で紹介されていた以下の設定ファイルを書き換えます。

$ sudo vi /etc/nginx/sites-available/default

ファイルを開いたら、以下の箇所で5行分コメントアウトを解除します。(オフだったのをオンにする)

location ~ \.php$ {  #← 解除
#       fastcgi_split_path_info ^(.+\.php)(/.+)$;
#       # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
#
#       # With php5-cgi alone:
#       fastcgi_pass 127.0.0.1:9000;
#       # With php5-fpm:
#
#       ↓ 以下4行解除
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
}

なお、この際、リンク先の解説では最初の行の拡張子部分にもう少し手を入れるように教えてくれていますが、前述の通り、これも今回の目的とは少しずれるのでその点は反映していません。

ここまでやってからNginxを再起動すると、

$ sudo service nginx restart

https://i.gyazo.com/4395f66a48b31f58a39e2fa3656f5126.gif

はい、やりました。ついに hello.php に移動してくれました。なんか、違うのが出ていますが・・。

502 Bad Gateway から逃れる

ファイルをダウンロードしなくなったのは大きな前進です。このまま記事を終えても良いぐらいですが、それで納得するのはぼくぐらいでしょうから、もう少し頑張ります。

現在画面に出ている「502 Bad Gateway」を消す方法については、ここまでの参考記事ではとくに言及がありませんでした。

そこでまたいろいろググりまして、以下の記事を見つけました。

qiita.com

これはこれで何というか、膨大な情報があふれていて、詳しい人にとっては有用なリファレンスかもしれないのですが、ぼくにとっては「こん中のどれを参考にすればええんや!」という感じで途方に暮れましたが、とにかく一つひとつそれらしいのを試して、結論的には以下の設定ファイルを編集すれば良いことがわかりました。

$ sudo vi /etc/php5/fpm/pool.d/www.conf

これを開いて、まず以下の2行のコメントアウトを解除します。

listen.owner = www-data
listen.group = www-data

そして、その近くに(じゃなくてもいいとは思いますが)以下を追加。

listen = /var/run/php5-fpm.sock

はい。で、php5-fpm を再起動。

$ sudo service php5-fpm restart

で、どうなるかと言うと・・

https://i.gyazo.com/7b3a99735f887250aa85cb21f9263b0d.gif

や、やりました!

iPhoneのブラウザからも見れます。(9秒の動画)

youtu.be

雑感

ということで、長きにわたるPHPとの戦いにも終止符が打たれ、ぼくも晴れてPHPerの仲間入り・・ができたかはわかりませんが、個人的にはひとつの大きな達成でした。

とくにあの、何回試してもとりあえずファイルがダウンロードされるタイムリープ世界から解放されたのは、本当になんというか、よかったです。

ちなみに、ちょっとしたローカルサーバ利用だったらべつにそんなことしなくても、ビルトインサーバ使えばいいんだよ、と言われてしまうかもしれないのですが、それは大丈夫です、わかっています、ということで。

PHP: ビルトインウェブサーバー - Manual

何しろぼくは以下のムックで、うずらさんのPHP記事、付箋ペタペタ張りながらそれなりに読み込みましたから。

Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus)

Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus)

ビルトインサーバについては、その中でもちゃんと取り上げられているのです。

なので問題は、どちらかと言うと「同ネットワーク内にいる他のデバイスからも見れるようにしたい」という方ですね。その欲求に応えようとすると、なかなか茨の道だったな・・と。

また正直なところ、お読み頂いてわかったかもしれないですが、設定ファイルを書き換えた辺りについては、自分で何をやっているのかまったくわかっていません。この辺、どういう部分をどのように、なぜ書き換えるのか、ということを解読していけると、もっと面白くなるかなあとも思っています。

ともあれ、この記事によって、少なくとも未来の自分はもうPHPの同件で時間を浪費することがない(あるいはその時間を最小化できる)だろうと思っています。おつかれさまでした。

追記

本文でも勝手に登場させて頂いてしまいましたうずらさんから、大変勉強になるコメントを次々と頂いたので、以下にまとめさせて頂きます。

Twitter、あとから掘り起こすのメチャ大変なのが目に見えていたのでとにかく今のうちに・・と。
*togetter使う手も考えましたが、あれってあまり相性が良くないというか、今まで満足に使えた試しがないのでこちらで。
*途中でかたついさんがしれっと入っていますが、うずらさんが一連のツイートの間にRTされていたものです。










うずらさん、最高です。

追記2

Twitterにて、こちらのご意見も頂きました。

な、なるほど・・まったく知らなかったのですが、であれば7を入れる前提で考えた方がより汎用的な方法・情報になりそうですね。

今回の場合、一応ローカル利用特化&最低限のセットで、ということだったので5.6でも大きな問題はないと思いますが、サポートが終わってしまうなら個人的にも新しい方を入れられるようにしておきたいな、と。

ということで、次に同じようなことをやるときには、PHPインストールのくだりで7系(というかなるべく最新の)を入れる方向で調べ直し&トライし直してみたいと思います。

Markdownファイル1本で著者校正とデザイナー連携を済ませる一石二鳥の編集術

こちらは『ライティングや編集にまつわるあれこれ Advent Calendar 2018』の23日目の記事です。

adventar.org

さっそくですが、こちらをお読みの皆さんはMarkdownをお使いでしょうか?

いや、もう「ご存知でしょうか?」なんて聞く必要はないと思ってとりあえず使ってるかどうかを聞いてしまいましたが、このMarkdown、使いやすいような、使いにくいような、なかなか評価が安定しない記法(マークアップ言語)です。

しかし個人的には、Markdownは使う場所さえ適切なら、あるいは複雑なことさえしなければ、十分に我々を助けてくれるものだと思っています。

今日はぼくが直近の編集仕事でどのようにMarkdownを活用したか、という話を書いてみたいと思います。

目次

取り組みの舞台・背景

若干唐突ながら、ぼくは今年の11月から都内のIT企業に就職したのですが、

note103.hatenablog.com

その前に請けていた編集仕事が最大で年度末まで続くことになっていて、この秋からはかけ持ちで仕事をしています。

で、その編集仕事というのが、数年前から時々お仕事をしているYCAMさん(山口情報芸術センター)が今年の10月に開催した以下のイベントのうち、メインのトークセッション3本の採録記事を作成するというものです。

special.ycam.jp

この採録記事は同サイトに来年公開予定ですが、じつはというか、ぼくが今年の春まで10年にわたって携わってきた坂本龍一さんの音楽全集企画『commmons: schola』でも、坂本さんがゲストの方々と行った座談会の原稿を毎回作っていたので、作業的には勝手知ったるというか、馴染みのある分野ということもあって、今回のその仕事もリラックスしながら楽しくやらせてもらっています。

この種の作業に複雑な処理は必要ありません。もしこれが書籍の組版で、InDesignへの流し込みなども視野に入れてやるものであれば、いろいろと気にすべき細かい要素が出てくるのかなと思いますが、今回はとりあえず最低限の構造化や、リンク・画像等の挿入ができれば十分というか、そもそもWebサイトへの反映という時点で様々な制約が生じるので、やりたくてもさほど複雑なことはできないとも言えます。

具体的に、この作業に関する記法として必要なのは、せいぜい2〜3層の見出しの階層化と、リンク、太字、画像および動画の埋め込み、といったところでしょうか。

ということで、上記の採録記事は迷わずMarkdown記法で作ることにしました。

作戦

トークセッションの採録ですから、仕上がり次第、その内容を登壇者の皆さんに確認してもらう必要があります。「こんなこと言ってないよ」とか、「たしかにそう言ったけど、本来の意図と違うからちょっと直したい」みたいなことは普通にあるので、登壇者にはそれら下原稿を確認してもらって、必要に応じて直してもらいます。

これは書き原稿で言うところの著者校正みたいなものですね。「登壇者による原稿チェック&修正」だとちょっと長いので、今回の記事タイトルではこの作業を「著者校正」と表現しています。

話を戻すと、この作業を進める上で少し悩んだのは、その確認用の原稿をどういうファイル形式で渡すべきか、またどういう方法で修正してもらうのか、ということでした。

相手は各界の専門家ではありますが、必ずしもライティングに馴染んでいる人ばかりではありません。普段使っているコンピュータやツールも様々でしょう。

一方で、上記のリンクからイベントの概要を見て頂けたらわかると思いますが、今回の登壇者は皆さんテクノロジーに明るい人たちでもあったので、その辺りも考慮して、渡すデータのフォーマットや修正方法については以下のように考えました。

  • 確認用の原稿フォーマットは以下の複数種類で用意する。
    1. Markdown形式のテキストファイル(.md)
    2. 1をWordにコピペしたもの(.docx)
    3. 1をもとにPDF化したもの(.pdf)
    4. 1をGoogleドキュメントにコピペしたもの
  • 登壇者には上記1〜3が入ったDropboxフォルダか、1〜4が入ったGoogleドライブのフォルダへの限定公開リンクを渡す。*1
  • その中から登壇者自身が一番確認&修正しやすいフォーマットのファイルを使って対応してもらう。
    • 1〜3のいずれかを選んだ場合は、手元にファイルをダウンロードしてもらって、修正後はメール添付で返送、またはリネームしたファイルを同じフォルダにアップしてもらう。
    • 4の場合はそのまま上書き修正してもらう。

まだすべての原稿が返ってきたわけではないのですが、今のところ登壇者からの戻り原稿で一番多いのは2番のWordです。やはりある種のデファクト・スタンダードというか、超使いやすいわけでもないですが(※個人の感想です)、積極的に拒否するほど使いづらいわけでもないですし、校閲機能も付いていますから、「まあそうだろうな」という気はします。

それから、今回のイベントではYCAMのスタッフさんたちも登壇していたので、同スタッフにも確認&修正をお願いしましたが、YCAMでは普段からチーム内でGoogleドキュメント上でやり取りすることが多いそうで、スタッフさんは皆4のGoogleドキュメントを使ってチェック&修正をしてくれました。

さて、上ではさらっと書きましたが、今回のやり取りのポイントは、PDFを除くテキスト系のデータがすべてMarkdown記法のままだということです。

Markdown記法は非常に簡素であるとはいえ、太字は「**」で囲みますし、リンクは「[文字列](URL)」、画像に至ってはその行頭に「!」を付けたりする謎表記にも満ちているので、普段からMarkdownに親しんでいる人でもなければ「なにこれ」という感じだと思うのですが、その辺はあえて説明せずにデータを渡しました。

というのも、ここでチェック&修正をしてほしい部分というのはただ日本語の文章が並んでいるところだけで、その部分にはMarkdown記法を混ぜ込まないようにしておいたので(後述)、よほど奇妙な見栄えになっていなければとくに混乱は生じないだろうという見込みがあり、実際今のところ大きな問題は出ていません。

上記の「Markdown記法を混ぜ込まないようにしておいた」という点について、これは今回の進行を考える上で一番工夫したところで、初めての試みでもありました。

というのも、今回の最終形はWebページなので、文中の特定の語句から外部サイトへのリンクを張りたいところがいくつかあったのですが、これを原稿の状態で、たとえばこんなふうに*2

私は[Google検索](https://www.google.co.jp/)だけは使いたくなかった。

文中にリンク記法を用いてしまうとさすがに邪魔というか、原稿チェックに集中できないので、こういうところはこんなふうに表記しました。

私はGoogle検索だけは使いたくなかった。

Inline-link 'Google検索': https://www.google.co.jp/

やや冗長にはなりますが、これによって肝心の日本語文章の部分は読み書きしやすくなりますし、どの語句にどのURLをあてるかという情報を記録しておくこともできます。また、登壇者的にも関心があれば「へえ、〈Google検索〉というところにリンクを埋めるのね」みたいに解釈することが可能になります。

画像の入り方をどう伝えるか

もう一つ、今回の仕上がりページでは登壇者がセッション時に使用したスライド画像なども挿入したかったので、これを原稿チェックのタイミングでどう示すか、少し頭を使いました。

単に文中に

私はGoogle検索だけは使いたくなかった。

*ここでGoogleの画像を入れます。

みたいにメモを入れておくだけでも良いといえば良いのですが、いずれにせよその後にWebデザイナーさんやオペレーションをする人(以下「Webデザイナー*3)にデータを渡すときには画像の挿入位置と対象の画像情報を紐づけて知らせなければならないので、できればこの原稿作成の時点で対象画像の情報も入れておきたいと思い、結局ここもMarkdown記法のまま、

私はGoogle検索だけは使いたくなかった。

Slide: ![Googleの画像](img/google.jpg)

みたいに表記しました。

こうした部分も当然、普段Markdownを書かない登壇者にとっては「?」という感じだったと思いますが、ここまで作っておくことによって、これをHTML化した段階で以下のレベルまでイメージを表現できるので、

f:id:note103:20181223120508p:plain

あとはこれをブラウザからPDFとして保存して、前述の3番の資料として同封しておくことで、登壇者にとっても仕上がりがイメージしやすくなったのではないかと思っています。

*ちなみに、この方法を取る都合上、実際には資料フォルダの中には「img」という子フォルダが作られていて、登壇者は見ようと思えばその中の画像群も見ることができました。わざわざ見た人はほとんどいなかったと思いますが・・。

Previm

そのHTML化の手段ですが、ぼくがもう何年も前から使い続けているMarkdownプレビュー用のVimプラグイン「Previm」を使いました。

github.com

この際、デフォルト設定のままだとヘッダー(ファイル名や更新日時の情報)が表示されるのですが、今回は登壇者のチェック用ということで、その辺の情報は不要なので設定値をゼロにして、

let g:previm_show_header = 0

また今回のPDF(HTML)ではどうしてもフォントにこだわりたくて、あとは画像サイズもできるだけ細かく調整したかったので、PrevimのカスタムCSS機能を使って、CSSの追加要素を以下の感じで設定しておきました。

let g:previm_custom_css_path = '/path/to/additional.css'

" パスとファイル名は説明用のダミー

CSSはデフォルトを無効にすることも可能ですが、ぼくはデフォルトは生かしつつ、必要な要素を追加する形で対応しました。
*フォントはいろいろ試行錯誤した結果、Rictyに落ち着きました。

意図と各種の効果

これを書いている12/23現在、登壇者とのやり取りはまだ少し残っていますが、今のところはこれという混乱もなく進んでいます。前述のとおり、Wordの校閲機能を使って詳細に直してくれた方もいれば、内容的にはほぼノータッチで "Wonderful documentation" と評してくれた海外の登壇者さんもいました。(嬉しい!)

*じつは今回初めて英文の原稿を作成して、これはこれで個人的にはかなりドラマチックな進行でしたが、長くなるのでその話は別の機会に・・。

今回のぼくのテーマは、「いかにして最小の手間で、最大の効果を生み出すか」ということで、それは仕事をかけ持ちしていたからということもありますが、それよりも「ほとんど同じはずの登壇者宛のデータとデザイナー宛のデータをわざわざ手作業で別個に作る」という思考停止的な作業をしたくなかったから、という理由が大きかったです。

実際には、デザイナーさんの方ではぼくが渡したMarkdownファイル(あるいはそこから生成したHTMLファイル)をそのまま使うわけではないのですが、それでも必要なリンク情報や画像、太字にしたい箇所などをすべてMarkdown記法で原稿内に指示しておくことで、登壇者のための原稿がそのままデザイナーさん用のデータにもなるという、ひとつの達成があったかなと思っています。

加えて言うと、それら関係者との連絡も結果的にだいぶシンプルになったと思います。

これまでだったら、すべての登壇者(今回だとゲスト登壇者6者、スタッフ登壇者7人)に、3種類あるセッションの原稿を振り分けて、個別メールまたはCcで必要なファイル群を添付して送っていたと思いますが、今回は3つのセッションそれぞれのフォルダを前述のDropboxまたはGoogleドライブに作っておいて、メールでは各フォルダへの限定リンクを送るだけで済みました。

ちなみにこの時、原稿チェックに際しての各種の留意点も伝える必要があるのですが、従来なら各メールに列記していた内容を上記の3フォルダそれぞれに「はじめにお読みください.txt」*4として置いておくことで、長文メールを読み書きせずに済ませるとともに、その記述もだいぶ余裕をもって行うことができました。*5

また、上記のとおり同フォルダには必要な画像もすべて入っているので、原稿が完成したあかつきには最終原稿と画像群だけをフォルダに残した上でデザイナーさんもフォルダにアクセスできるようにすれば、連携作業はすべてそのフォルダだけで完結することになります。

その意味でも、今までならやっていたはずの細かい手作業をだいぶ削減できたのではないか、と思っています。

同記事に関しては、今後大きなトラブルなどなければ、春頃までには以下のサイト内に掲載されることになると思います。(再掲)

special.ycam.jp

どうぞお楽しみに。

本日の記事は以上です。『ライティングや編集にまつわるあれこれ Advent Calendar 2018』は昨年の狂騒に比べると幾分しずかな印象ですが、その分芯の通ったスッキリした記事が揃っているようですので、他の記事も合わせてお楽しみください。

adventar.org

*1:機密性が高いセッションはDropboxでパスワード付きのものを作り、そこまでではないものはGoogleドライブの限定公開フォルダ(パスワード不要)を作る。

*2:これを書いているときにリアルタイムで考えた例文で、文自体にはなんの意味もありません。あえて言えばGoogleのURLを使うのが無難かなと思ったぐらい。

*3:実際の作業ではデザイナーとオペレーター(テキストを流し込んだり仕上げたりする人)は別になるケースもあると思いますが、ここでは便宜的に「Webデザイナー」で統一しました。タイトル部分も同様。

*4:海外勢に対しては「README.txt」というファイル名にしました。というか元々READMEがネタ元だったので。

*5:メール送信後にも書き直すとか。

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:直近の編集仕事でもめちゃめちゃ使いました。