builderscon 2019に行ってきた(2)〜本編初日〜

シリーズ続編です。前回の内容はこちらをどうぞ。

note103.hateblo.jp

builderscon 2019のサイトはこちら。

builderscon.io

では順に。

朝のランチ券

本編初日の最初のミッションはランチ券をゲットすることでした。

blog.builderscon.io

例年だと、お昼の企画として「ランチセッション」というものがあって、昼休憩になると同時にその会場の前に行列ができ、並んだ順に弁当が配られて、受け取れた人だけがその弁当を食べながらスポンサー企業のトークを聞く・・みたいな感じだったんだけど、この方式だと、1つ前のトークが早く終わるほど有利というか、行列に並び遅れたらもう弁当を受け取れないので、ほとんど運というか賭けというか・・。

それで思い出してみると、ぼくは去年のビルコンではたしか2日ともこの弁当行列に並んで、しかしどちらも受け取れなかったんですよね。😭

なので、この「朝早く行った人ほど弁当をゲットしやすい」というのは非常にありがたくて、これなら弁当が欲しい人は朝に頑張れば確実にゲットできるし、昼前のトークが多少長引いてもソワソワせずに最後まで話を聞けるし、結果的に朝のトークも漏れなく聞けるしでメリットが多く、素晴らしい企画だと思いました。考えてくれた人、実現してくれた人、ありがとうございました。

で、ぼく自身はこの日はイタトマのスパゲティ券を頂きました。というのも、ランチセッションはこれまでにもすでに何度か体験していて、「こういう感じ」というのがわかっていたので、ちょっと違う体験をしたいなと。

10時になると同時に開場して、このタイミングで目論見通りイタトマランチ券をゲット。すると、最初に入ったスペースに朝食・コーヒーコーナーが・・。

f:id:note103:20190830100200j:plain
突然の朝食コーナー。コーヒーはこの左手

なんとスピーカーディナーで食事を提供したチームによる朝食があったのでした。

コーヒーはこちらの方々。(当日聞きそびれたので後日のTwitterより)

久しぶりにちゃんとしたコーヒー飲んだな・・という感じでした。ありがとうございました。

ちなみに1点、これは今回の不備ということではなく、今後に向けた小さな提言という感じですが、この日は最初のセッションが10:50からのオープニングトークだったのでまだ余裕があってよかったのですが、翌日は最初のトークが10時半からで、「10時から朝食コーナーに行って軽く食べてから10時半のトーク」っていう流れはちょっとせわしない感じだったので、教室のオープンよりも少しだけ朝食会場のオープンが早くなっていると、よりゆっくり楽しめるかなと思いました。

*もちろん、そんなことをすればそれだけスタッフさんが早くスタンバイする必要があって大変なわけですが、素朴な実感までに。

午前トーク

そして10時50分、主宰の牧さんによるオープニング。

f:id:note103:20190830105003j:plain

今回はこの写真にあるように、画面右上にスピーカー、右下にタイトルやハッシュタグ等の情報が常時出ている感じで、非常に良かったですね。とくに、右下の諸情報はトークの途中でも知りたくなることが結構あるので、便利でした。

その後、本編最初に見たトークはこちら。

builderscon.io

こちらはスピーカーディナーのときに見て、わー面白そうだな、と思ったので行きましたが、実際かなり面白かったです。

各種の事例を通して「ゲーム」の本質に迫りつつ、その分析を通してまた新たな謎や魅力に出会う、といった感じでしょうか。

最後の質問コーナーでは、簡単な質問をしました(内容は割愛)。初日の最初の発表だったので、なかなか手が挙がりづらいかな・・と。

質問するのって緊張するし、聞いてるときのモードから質問モードに切り替える必要があるので、避けられれば避けたいところですが、効果が見込まれるときにはそれなりに頑張ります。経験的には、スピーカーと近い場所(前列の方とか)にいるとやりやすいですね。あとは、よく緊張するときには人をカボチャと思えみたいに言いますが、ぼくの場合はその会場を自分とその人しかいない親密な空間だと思い込んだりします。

話を戻して、スピーカーの@qsonaさんはnoteで各種記事を書かれていて、builderscon関連だと以下がありました。のちほど見ておきたいと思います。

note.mu

ランチ

前述のイタトマに行きました。パスタは「何を選んでもいい」と言われたのでけっこう迷いましたが、定番っぽいトマトソースとモッツアレラチーズにしました。

f:id:note103:20190830130250j:plain

それなりに量はあるんですが、思ったほどヘビーではなく、サクッと頂きました。

店内には地元の方と思われる多彩な層がいて、でも席が空くのを待ったりする必要もなく、チケット数もちょうどよかったのかな、という感じでした。

午後トーク(1)

午後の最初はこちらを見ました。

builderscon.io

Mathematicaってまったく知らなかったので、雰囲気的に数学の話がメインになるかなと勝手に思っていましたが、思いのほかオブジェクト指向の話が多く出てきて、オブジェクト指向についてはPerlRubyの学習に際してそれなりに時間を割いて触れてきたので、案外理解のきっかけが多い内容でした。

語り口にも推進力があって、動くサンプルが多く用意されていたのも良かったですね。飽きる間もなくあっという間に終わりました。

その後は、同室でこちら。

builderscon.io

「形式手法」とは今回のbuildersconで初めて触れたキーワードでしたが、自分には全然関係なさそうでありながら、なぜか関係ありそう、興味をひかれるなあ・・と思って聞くことにしました。

果たして、内容的には想像以上にわかりやすいというか、出てくるコードは馴染みがないものが多かったですが、構文はそんなに複雑ではなく、かつ1つずつ丁寧に解説してくれたのでけっこう追いついて聞くことができました。

話の筋というか展開も共感・納得感が強いもので、なぜそういうことをするのか、とか、それに対してどういう事を考えて、今後どう展開していこうと思っているのか、みたいなところまで「なるほど」って感じで聞けました。(とくに前半の方)

その後は会場を移動して、こちらへ。

builderscon.io

大会場で60分、ひたすらRailsを中心に話していく感じでしたが、こちらもあっという間という感じでした。

具体的な内容については、知らない要素も多くてコレと言える核心を掴めていませんが、手元のノートにけっこう真面目にメモも取っているので、追って見返しながら勉強したいと思います。

一応、『マルチパラダイムデザイン』による以下。

問題に対して解決となるような構造を与える

これだけは覚えました(笑)。

スライドはこちらです。

speakerdeck.com

休憩部屋

その後のコマはお休み。ずっとトークだけ見ていると、他の人と喋ったり体を休めたりするヒマがなくなるので・・。

ということで、2階に用意された休憩室へ。この部屋はサイボウズさんプレゼンツで、今まで勝手に存じ上げていた同社の風穴さんとようやくご挨拶。

*風穴さんによる当日のツイート。

技術系ジャーナリストとして名高い方ですが、お話しできてよかったです。技術書典、行ったことないと言ったら行ったほうがいいと言われましたので(ただし午後)、行ってみるか・・と考え中です。

techbookfest.org

午後トーク(2)

午後、というかこの日の最後に聞いたのはこちら。

builderscon.io

一冊の本を読み切ったような重厚な発表でした。質疑応答も面白かったです。

なんというか、ある意味では泥臭いんだけど、でもこういうのが結局一番強い、というかそうであってほしい、みたいな感想を持ちました。手本になる本をしっかり読んで、そのエッセンスをつど参照しながら、自分たちの課題に向けてトライ&エラーを重ねていく、という姿勢。

言葉にしてみれば「そりゃそうでしょ」という感じなんだけど、実際に一つひとつそれをやっていくのって本当に胆力が必要というか。
ここで取り上げられている「Kyash Direct」は法人向けのサービスなんだけど、ぼくは個人向けの「Kyash」の方をけっこうヘビーユーズしているので、それとの関連なども想像しながら楽しみました。

ちなみに、これは次の記事に書きますが、翌日最初に聞いたのがクレジットカードのプロトコルの話だったので、図らずもこういった決済を扱う系のサービスの裏側を想像しやすくなって、その辺も想定外でまさにbuildersconのテーマ「知らなかった、を知る」だなあという感じです。

ああ、あともう1個。この発表は基本的に、スライドに書かれている文を読みながら、順に説明していく感じで、ぼくは普段はこういうプレゼンって「スライド上の文言」と「実際に話す言葉」がずれているほど面白いって考えるタイプなんですが、この発表はスライド内容もすごく作り込まれていて、かつ情報量がめちゃ多いので、この読み上げスタイルの方が合ってたかな、という印象を持ちました。一概に、読み上げは駄目、とは言えないなと。この辺の考え方は更新されました。

WEB+DB PRESS』編集長と感想戦

本編終了から懇親会までの空き時間、『WEB+DB PRESS』編集長の稲尾さんと遭遇しまして、しばらく先日の寄稿について感想を述べ合ったりしました。

note103.hateblo.jp

あそこまでやる人、普通いないっす。みたいな話になって、「(やっぱり・・)」と :sweat_smile:。それで余計に思いましたが、たしかにぼくもだいぶんコストをかけたわけですが、やっぱり編集チームにも多大なコストをかけさせてしまったなあ・・とあらためて恐縮。とはいえ、内容としては良いものになった、という点でおおむね意見は一致(たぶん)。

相変わらずお忙しいようでしたが、「この後は懇親会も行かれますか」と聞いたらもちろんそうで、過去の寄稿者さんへの挨拶に加えて、次に原稿を書いてくれそうな新しい書き手も探したいとのこと。さすが・・。こうした普段/不断の活動があの雑誌を支えているんだなあ、とあらためて敬意を抱きました。

懇親会

そのまましばらく知人と喋ったりぼんやりしたりしているうちに、同じ構内で懇親会スタート。

料理はスピーカーディナーや朝食と同じチーム。もりもり料理が出てきて、なくなる端からまた追加。プロフェッショナル!

f:id:note103:20190830185555j:plain

そして地味ながら感動したのはこのトレイ。

f:id:note103:20190830190013j:plain
完璧に取りきった様子

ドリンクを挿せるようになってるんですね〜。これがないと、ドリンクと皿を持っただけで両手が埋まってしまって食べることができないので、テーブル必須になっちゃうんですが、これがあるとテーブルがなくても片手に皿&ドリンク、もう片方の手で食べられて、テーブルいらず! すごい発明です。

たぶん、その分少しケータリングの単価も上がるのではとも思いましたが、選べるなら絶対これにしてほしい・・と思うぐらい良かったです。

そのドリンクですが、牧さん行きつけのバーが出張してくれたそうで。

f:id:note103:20190830185103j:plain

ぼくは2番と5番を飲みました。バーの方々、スポンサーの皆さん、ありがとうございました。

初日の雑感

ということで、本編初日をふり返りました。

この日のトークはすべて日本語でしたが、だから余計にというか、なるべく今までに見たことがないような、自分からかけ離れたものを見るように意識しました。
しかしそのわりに、けっこう要素としてはすでに知っていたり、関心が近いものが多かったのが面白かったですね。

風穴さん、稲尾さんといった編集界の諸先輩方に会えたのもよかったです。編集魂(?)が図らずも磨かれました。

朝食・コーヒー・懇親会といった食事系も途中で不足したりすることもなく、食べたいだけ食べれて大変満足でした。

ちなみに、終会後は翌日に向けてサクッと宿へ帰りましたが、川(荒川?)で続きをやっていた人たちもいたようでした。ぼくはもうお酒は十分でしたが、水を持って参加してもよかったな、と後から思いました。とはいえ、それをやったら翌日それなりに大変だったかもしれず、この辺はタイミング次第ですが・・。

最終日についてはまた別記事にまとめます。お楽しみに。

関連記事

builderscon 2019に行ってきた(1)〜スピーカーディナー&前夜祭〜

2019/8/29〜8/31に東京は北千住の東京電機大学千住キャンパスにて開催されたbuilderscon 2019に参加しました。

builderscon.io

感想ブログ、後になるほど書くのが大変になるので、早いうちにワッと書いていきます。
ただし、参加日すべてについて一気に書くのもめちゃ大変そうなので、何回かに分けて書く予定です。

マイスポンサー

先日のRubyKaigiに続き、今回も私が所属するヴェルク(株)の支援により、コンプリートパック・チケットにて参加できました。イベントには全日フルで参加しつつ、このうち会社の営業時間・営業日とかぶる部分は出勤扱いにしてもらいました。心からの感謝と尊敬を捧げます。

DAY0: スピーカーディナー

まずは前々夜祭的なこちらから。

blog.builderscon.io

スピーカーディナーは言ってみればbuildersconの目次のようなイベントで、本編でスピーカーの皆さんがどんな話をするのか、というのを事前にリサーチできる機会になっていてとても良かったです。

主宰の牧さんによれば、本番の2日間ってスピーカーにとっては自分の発表のことで手一杯で、他のトークのことを気にする暇がなかったりするだろうから、その補完的な情報交換とかもできればいいよね、みたいな目的もあるようでした。

ぼくはじつはこのちょっと前に各種事情によりやや疲れていたものの、コンプリートパック・チケットにこれの参加権も入っていたので、「行かないともったいないよなあ・・」と思ってエイヤと参加したのですが、結果的にはそれが大正解で、仮に来年コンプリートパックがなかったとしても、この会があればマストで参加します。そのぐらい本編をより楽しむための材料にあふれていました。

参加者の割合的にはスピーカーの方がずっと多くて、ちょっとびっくりしましたね。非スピーカーの自分、少数派じゃん、と。

とはいえ、だからといって寂しくなるようなヒマもなく、各スピーカーによる1分間ピッチや後述のような要素を終始楽しみました。

健康トーク

本編とはコンセプトが合致しないけど牧さんが聞きたいから、という理由でこの日唯一長めの時間をとって発表されたのが@mogettaさんで、スライドはこちら。

docs.google.com

いやー、素晴らしかったですね。ぼくは全然筋トレその他、こういったことに関心はなかったというか、関係ない世界だと思っていましたが、だいぶ引き込まれました。

スライドも非常に作り込まれていて、参考文献集としても良いものだと思いました。

ちなみに、弊社にも筋トレにけっこう本格的に取り組んでいる人がいるので、このあと社内にシェアしておきます(笑)。

フード

フードもおいしかったですね。とくにおにぎりに生ハムとキュウリが乗ったものと、ゆで鶏にネギソースがかかったもの、あとデザートのチーズケーキがちょっと忘れられないぐらいおいしくて、本編の方の朝食&懇親会で同じチームが料理を提供していたので、そのときに声をかけてその旨伝えたほどでした。ありがとうございました。

f:id:note103:20190828190355j:plain
スポンサーのハートビーツさんによるご挨拶

f:id:note103:20190828191230j:plain
食べてる横でどんどん料理を追加していくスタイル。カッコイイ

f:id:note103:20190901202229j:plain
問題のチーズケーキ。Twitterでもだいぶ好評だった

DAY1: 前夜祭

どこを「DAY1」とするかちょっと迷いましたが、公式サイトではこの日から開催期間としているので、これをDAY1とします。

この日は最初、終日会社を休むつもりだったのですが、時間を確認したら18時スタートということだったので(前夜祭なので当然でしたが)、さすがに1日休むのはどうか・・と思って13時までは自宅でリモートワークをして、それから準備に取り掛かかりました(それまでまったくやってなかった)。

ちなみに、会場は家からそこそこ近かったものの(会社より近い)、それでも片道1時間ぐらいかかる距離だったので、会場と同じ北千住に宿を3泊取っておきました。

なので、この時にはその分の着替えを用意したり、充電器や常備薬などをまとめたりとなんだかんだで用意するものが多くて出発はギリギリに・・。

北千住駅にいきなりハマる

その後、駅すぱあとで調べながら北千住駅に着くまでは余裕でしたが、駅がまさにダンジョン。この駅の複雑さ・問題性については、以下のグレイト記事を事前に読んでいたので一応頭に入っていたはずでしたが・・

blog.builderscon.io

それでもまだちょっと甘く見ていて、何も考えずにホームから一旦「普段どおりに」階段を降りたら、なんか景色が変。「普通だったら」あるはずの方向や場所に『出口』の表示もなければその雰囲気すらない。どこに向かっても別のホームにしか行けない、別の電車にしか乗れない仕組みになって見える・・。

・・オ、俺は外に出たいんだ!出口!出口を教えてくれ!と、軽くパニックになりながら(もう前夜祭の開場時間を過ぎてたので)、「あ、そっか、最初に階段を降りてしまった時点でもう間違っていたんだ・・」とふと気づいた頃、ちょうど『出口』と書かれた中途半端な大きさの看板が目に入って、それが「もう1回ホームに上がっとけ」と道順を示していたので、観念して再び階段を登りながらあっちこっち行きつつようやく出口へ。

件の記事にもちゃんとこのように書いてあったのですが、読めてなかったですね・・。

プラットホームから下り階段・エスカレータを利用すると千代田線方面に向かってしまいます。くれぐれも下らないようにしましょう。

しかし帰りにも思いましたが、北千住駅の道案内って、かなり頑張ってるとは思うんですが、基本的に「すでに駅の構造を知ってる人」がその認識を確かめるために書かれてる感じで、「初めて来た人」にはだいぶ効果が薄い気がしますね。

たとえば東武スカイツリーラインって半蔵門線とつながってるんですが、それを示す解説がほとんどないので、元々そのつながりを知ってる人じゃないとどこに行けばいいのかまずワカランな・・と思いました。

前夜祭トーク

なんとか駅を脱出した後は、荷物が多かったので一旦宿にチェックイン。おそらく会場ではノベルティをもらえるはずなので、必要最小限のものだけ持って会場へ。

会場で受付。コンプリートパックのネームカード&各種ノベルティをもらって場内へ。今回のノベルティ、大ぶりながら軽いリュック付きで、これはナイス!さっそく通勤で使いたい、いや使います(笑)。シンプルな作りでとてもいい。

場内で缶ビールとつまみを取って着席。その後はトークを聞きました。

1つ目のトークはこちら。

builderscon.io

イベント全体を通して1発めだったのでけっこうプレッシャーあったのでは、と思いましたが、すごく力が抜けたイイ感じのトークで楽しみました。技術的にも「うわあ、こんなことできるの」と目が覚める感じで、とくにホロレンズって実際にどういう風に動くのか、テレビとかネットでは見たことがあったものの、目の前で使っている人って見たことがなかったのですごい新鮮でした。早くもbuildersconっぽい。

とくに、笛を吹いたらホロレンズ経由で信号が送られてドローンが飛ぶ、という最後の例。かなりウケました。この突飛な発想はなかなかできない。才能を感じます。

2つ目はこちら。

builderscon.io

MySQLでパウンドケーキ(とクッキー?)を焼くというもので、元になった記事はこちら。

gihyo.jp

あのガムテープでオーブンを常にオンの状態にしておくというハックがウケました。あとはMySQLの2つめのイシューで「MySQLではトーストを焼けない」というのがあったらしくて、その辺の知見も面白かったです。(これも上記記事で解説されています)

3つ目はこちら。

builderscon.io

おそらくこの日一番の「盛り上がったで賞」という感じでしたが。発表の元になった記事はたぶんこちらで、

qiita.com

結果としてはこのような感じでしたが(ビルコン用に用意された動画みたい)。

www.youtube.com

www.youtube.com

もうこの発表はね・・とにかくトークが面白かったですね。圧巻。どうすれば人が笑うのか、という構造をある程度わかってて話を進めている感じがあって、非常にリラックスしながら終始笑いながら聞きました。

そして4本目。

builderscon.io

じつはというか、これはちょっと複雑な問題をはらんだ発表で、後からCoC(行動規範)絡みの議論がしばらく起こりました。

会場で聞いていたときの素朴な感想としては、初めのうちはマッチングアプリの概要や課金の仕組みみたいなものを見ながら「そんな風になってるのか〜(知らなかった、を知ったなあ)」と感心して聞いていましたが、途中ぐらいからちょっと説明の中で女性をモノ扱いしているように感じられてしまうくだりがいくつかあって、「ん〜、なんか・・居心地わるいな」と思い始めていました。

なんというか、この話って会場にいる女性、普通に嫌なんじゃないかな・・と。

その後、感想ツイートなどで問題性を指摘するものがいくつか出てきて、「ああ、やっぱりそう思ってた人けっこういたんだ。ですよね・・」という感じになったり。

ただ、上記で「複雑」と書いたとおり、案外現場にいると、サッと動いて「それアウト!」とも断定しづらい事情はいくつかあって、第一にトーク全体の方向としてはあくまで技術にまつわる話をしているので、その「主題は技術」という前提が、ある種反応を「遅らせた」みたいなところがあったように思っています。

それから、これはどこか反フェミニズム的な考え方にもつながりそうなんだけど、結局そのマッチングアプリって「どっちもどっち」感が醸されているというか、「たしかに男性も女性をモノのように見るかもしれないけど、逆も然りじゃん?」という見方を許すサービスでもあるので、「あくまでマッチングアプリに関する話です、出てくる女性も女性全般を想定しているのではなく、このサービスの利用者に限定した話です」みたいな見方もありうることを考えはじめると、「もしかして許容すべきなのか・・?」と思えてしまう部分もあるというか。

まあ後から冷静に考えれば、「聞いてる側が微妙になってる時点で駄目でしょ」とは簡単に言えるわけだけど、現場で即ストップするというのは、よほど事前にそういう状況を強く想定していないかぎり、難しかったんじゃないかな・・というのが現時点でのその現場に対する考えです。

それから、今回の発表者およびその段取りを進めた人たちはおそらくまだ若い人たちで、きっとそういうことに慎重になるだけの知識や経験が少なかったのだろうとも思います。となれば、それはもう各個人だけの問題ではなく、彼らを取り巻く会社・友人・家族などの社会的な不備であり問題でもあるわけで、その意味でも個人を責めるのではなく、関わる人々全体の責任として受け止めるべき部分もあるのかなと。

なお、この問題に対して「何が悪いのかわからん」的な反応もゼロではないようですが、それについて言えることはシンプルで、わかろうとする気がない人には何を言っても無駄です。なぜなら、その人は何を言われても「それじゃわからん、俺を説得してみろ」とさえ言えば常に勝てる無敵の人だからです。

だから大事なのは、そういう不毛な戦いをすることではなく、共に幸せに暮らせる社会を作るために力を合わせていける相手と、議論を積み重ねながら、より豊かな場所を作り続けることだと思います。

次回予告

さて、いつもの私ならこのまま脇目もふらずに翌日(本編初日)の話に入っていくところですが、各日の午前・午後および懇親会などのトピックが待ち構えていることを考えると、記事がかなりの長尺になることが予想され、かつその推敲(というか修正)も大変な量に膨らんでいきそうなので、一旦ここまでにします。

この後の内容的には、たとえばWEB+DB PRESSの寄稿でお世話になった編集長の稲尾さんとお会いしたり、同じく編集系で凄腕技術編集者・執筆家でらっしゃる風穴さんとお会いしたり・・などの話は忘れず書いておきたいところです(忘れないようにメモ)。

あとは朝食、昼食、懇親会・・(食べ物ばっかりですが)とかもたぶん含めます(メモ2)。

お楽しみに!

続編

ふり返る『WEB+DB PRESS Vol.112』寄稿録

少し前にもお知らせしましたとおり、8/24発売の『WEB+DB PRESS Vol.112』のリレー連載「Perl Hackers Hub」に寄稿しました。

note103.hateblo.jp

記事のタイトルは、「自作ツールによる日常業務効率化 〜 初歩的なコードだけで身近な問題を解決!」です。Perlの連載なので、ここで言う「ツール」とか「コード」はPerlのそれですね。

その他、掲載誌の目次など詳細情報については下記をどうぞ。

gihyo.jp

執筆に至る経緯など、大まかな話は前回書いたので、今回はその具体的な内容についてまとめてみたいと思います。

執筆初期の諸問題

なにしろ『WEB+DB PRESS』なんて言ったらもう何年も前から読んでいましたし、ぼくが知っているプログラマーのうち読んだことがない人なんてどれだけいるの? というぐらい知られた雑誌ですから、話をもらってから引き受けるまでは一瞬でしたが、いざ取り組んでみると想定外の問題がいろいろと噴出・・。とくに工程前半のテーマ設定には苦労したので、その辺りから。

テーマ検討

最初に話をもらった時点で大まかなテーマとして提案されたのは、「大掛かりではないけどつど便利に使えるPerl活用法」みたいな、「小道具としてのPerl」みたいな、いずれにしてもまさにぼくがいつもやっているようなことを、そのままちょっと紹介して、という感じだったと思います。

これについてはぼくとしても、自分が書けるとしたらそんなネタだろうな〜と思っていましたから、「ではそれで。」という感じでスムーズにスタートしたのですが、実際に書き始めてみると、いやこれってそんなにシンプルなテーマでもないな・・ということがわかってきました。

というのも、第一にどうしてぼくがそういう「小ネタ的なプログラム」を量産しているのかと考えてみると、それはぼくが「大掛かりなプログラムを書けない(そのための技術がない)」からで、つまりそうした小さいプログラムの背景には、ぼくが「非エンジニア」であることが密接に関わってるんですよね。

だから、対象のコードについて何か書こうとすると、どうしてもその説明の中で自分の非エンジニア的な側面について触れざるを得なくて、でもこれって文章全体を通してみるとけっこう邪魔というか、テーマをボヤけさせるノイズにもなりがちなんですね。

もう一つ、今回は既存ツールの概要やTIPSを紹介するのではなくて、自作のコードを示しながら解説する体を取ることになるので、ということは上記の「小道具としてのPerl」や「非エンジニアである私」といった要素に加えて、「自作ツールのお披露目」という、これはこれでちょっとレイヤーが異なる要素が生じてきます。

で、当初はこの辺りの切り分けをほとんどしないまま、「まあ、とりあえず書いてみましょう、なんとかなるっしょ」みたいな感じでスタートしたので、初稿ではまさにそれらが渾然一体となったものが仕上がってしまったのですが、その問題点をメイン監修者の牧さんからズバッと指摘されまして、それで対象とするテーマをグッと絞り込むことになりました。

それでどうしたかと言うと、ある意味では最初期のテーマ(「小道具としてのPerl」)に立ち戻りつつ、「非エンジニア」の要素は最小限まで減らして、話の軸としては「初心者でも扱えるPerlの基礎構文だけで、便利なツールが作れる!」みたいなことにフォーカスすることにしました。

どうもぼくの性格・指向的には、ついあっちこっちに話題を飛躍・拡散したくなりがちなんですが、とにかく「基礎構文だけで便利なツール」という点に軸足を置いて離さない、ということを考えるようにした、という感じでしょうか。

で、この原稿はたしかアウトライン(見出し案)を3月から書き始めていましたが、このテーマに定まったのは・・結局5月の半ばぐらいでしょうか。その間もけっこう休みなく書いていたので、だいぶ時間がかかりましたね。

懸念と対策

さて、そんなふうに具体的に書き進める中で、テーマとは別に、いくつか新たな問題が出てきました。

と言っても、これはあくまでぼく自身が問題視していただけで、他の人から言われたわけではないんですが、簡単に言うとぼくのコードの正当性というか、妥当性というか、信憑性みたいなものが不安だなと。というのも、ぼくが普段書いてるコードって完全に自分の中に閉じているもので、一応GitHubに公開しているものも少なくはないですが、その内容が間違っていたからって誰が困るものでもないので、ようは他人のレビューというものをほとんどまったく受けてないのですよね。

なので、そんなコードをいきなりWEB+DBに載せるなんてできるわけがないし、直すったってどこから直したらいいのか😇という感じなので、こういう悩みは他のプログラマーの人が執筆する場合に比べて、けっこう独自のものだったのではないかなあ、と思います。

もちろん、そのために監修の皆さんがいらっしゃるというか、掲載にあたっては事前にコードもチェックしてもらえるわけですが、とはいえ対象によってはそれなりに膨大なコードになるので、実際にそれを全部手元で動かして確認してもらうとかはちょっと現実的ではないし、仮にそれをやってもらったところで「直せ」と言われて直せるとも限らないし、さらにはそんなふうにコードを直したら当然文章の方だって影響を受けるはずだし、というのでこれもまたなかなか大きめの懸念に。

で、じゃあどうしたかと言うと、とにかく誌上に出すコードは可能なかぎり初歩的・基礎的なものにとどめて、コード周りの推敲が最小限になるようにしました。

これによって、コードとそれに伴う文章を延々直し続けるような事態は避けられますし、文章もメインテーマの「基礎的なコードだけで便利ツールを作る」を維持しながら仕上げることができます。

デメリットとしては、一部のトピックでは具体的なコードを示せず、「あとはGitHubを見ておいて」みたいになっているので、そこで技術的な物足りなさや違和感を感じさせてしまう可能性もあるなとは思いましたが、それはもう、すみませんがそういうものとしてお受け取りください、という感じで割り切ることにしました。

記事構成

そんな感じで徐々に固まっていった記事の中身は、大きく4つの章で構成されています。

1. 基礎構文でツールを作る
2. シェルコマンドを組み合わせる
3. ほかのツールを組み合わせる
4. 最小限のコードで書く

それぞれひと言で言ってみると、1番では主にPerlだけで書いた超シンプルな初心者的コードを、2番ではそれにシェルコマンドを組み合わせたものを、3番ではpecoなどの他のツールを組み合わせたものを、そして4番では再び超シンプルな小ツールを紹介しています。

この章立てもかなり終盤の方まで編集さんと議論しながら詰めていったのですが、原則的には、「単純なものから複雑なものへ」とか、「昔のコードから最新のコードへ」みたいな時間の流れを意識して組みました。

記事解題

といった前段を踏まえつつ、以下ではその各章で取り上げたトピックや関連リンクなどを記していきます。

1. 基礎構文でツールを作る

ここでは上記のとおり、Perlだけで書かれた単純な、しかし自分の実作業を飛躍的に効率化してくれたツール群を紹介しました。

まあ、あまりにもシンプル過ぎて、これを「ツール」と呼んで良いのか、という問題もありそうですが・・とはいえ、ここで紹介しているコードは、ぼくが実際の仕事の作業をする中で「これプログラミング使わずに全部手作業でやっていたらめっちゃ大変だったろうなあ」と実感していたものばかりで、なおかつぼくのプログラミング初期の頃から使っていたものなので、記事の最初はとにかくこれを取り上げなきゃ、と思って紹介しました。

ちなみに、ここで取り上げた各ツールの利用シーンとしては、ぼくがフリーランス時代に手がけていた音楽全集の編集作業がかなりの割合を占めると思います。

commmons.com

それもあって、記事中では当時の詳しい素材データなどもわずかながら例として出していますので、クラシック音楽好きの人には面白がってもらえるのでは・・と少し思っています。

2. シェルコマンドを組み合わせる

ここではMacのopenコマンドをはじめとするシェルコマンドを、Perlと組み合わせる事例を紹介しています。

しかし考えてみると、ぼくが普段書いてるコードって、だいたいここまでに扱ってる技術ばっかりで、それより複雑なものってほとんどないのですよね。

ほんとにプログラミング始めて1〜2ヶ月ぐらいの人でも十分に書けるものだと思うので、そういう意味では(とくに非エンジニアの人には)参考にしてもらえるかもしれません。

具体的なところだと、「複数ファイルの行数や文字数をカウントする」で紹介しているツールは上記の編集者時代に頻用しましたし、あるいは「複数のWebサイトを一斉に開く」とかは我ながら単純すぎてちょっとバカっぽいなとも思いますが、でも地味に便利なんですよね。今でも時々使います。

3. ほかのツールを組み合わせる

メインはこの章だと思っています。ぼくが普段めっちゃ使ってる自作ツールを次々紹介していますので。

とくに、このブログでも何度か紹介しているchocoというツールがありますが、

GitHub - note103/choco

今回扱ったツールの中で何かひとつだけ選べと言われたらこれを選ぶぐらい、ぼくにとっては必須のものなので、これを紹介できたのは良かったなと。

プラス、このツールではその主要な機能を提供するものとしてpecoが使われているんですが、

GitHub - peco/peco: Simplistic interactive filtering tool

そのpecoを開発している牧さんが今回のメイン監修者だったので、なんというか・・今にも逃げ出したいような😱でも非常にありがたいような、得がたい経験をさせてもらいました。

あとは、ぼくがプログラミングを始めた初期の頃から公開しているcarvoというゲーム?みたいのがあるんですが、

GitHub - note103/carvo

これは冷静に考えると便利ツールでもなんでもないんですが(笑)、しれっと含めることができてよかったかなと*1

あとはAgっていう文字検索ツールを手軽に使うためのツールとか。

finds/find-word.pl at master · note103/finds · GitHub

これもかなり使用頻度が高くて、作り始めたときよりも今の方が使ってるかも、というぐらいよく利用してます。

4. 最小限のコードで書く

最後の章はこちらですが、ここでは今まさに会社で自分の業務のために使ってるツールを紹介しています。

少し前にTwitterでこんなことをツイートしましたが、

そこで言ってるのがこのツールです。

GitHubだとここに公開してありますが、

finds/find-file-open.pl at master · note103/finds · GitHub

あまりにも短いので誌上でもほぼ全部載っけています。

詳しい用途については記事で解説しているので、そちらをご覧頂きたいですが、とにかく出社して編集仕事をしているときは必ず使っているので、そのつど「ああ、作ってよかった」と思っています。

実工程のふり返り

ここからは、現在の目で工程全般のふり返りを。

執筆・編集工程

ええと、曲がりなりにも過去10年にわたって編集の仕事をしてきて、その間にはプロの執筆家の方々と毎日のようにやり取りしたり、その原稿を読んだり、時には自分でもテキストを書いたりしてお金をもらってきたわけなので、最初はどちらかと言うと、同誌に寄稿する他のプログラマーの人たちよりも自分の方が「本業の人」として取り組んでいる自負があったのですけど、いやあ・・やってみるとめちゃめちゃ大変で、「本当にみんな、こんな大変なことをいつもやってるの??」という思いが何度も湧き上がりました。

上記のとおり、この作業はたしか今年の3月からスタートしていて、まあ仕事をしながらではありますけど、でも土日はかなり使っていたし、平日も仕事から帰宅後に深夜まで及んで対応したりして、それでも入稿*2の数日前まで修正してましたからね・・。

普通に本業で編集・執筆やっていたときと同じぐらいの労力および時間を費やしてようやく間に合いました・・みたいな感じだったので、ほんとに他の執筆者も編集さんもみんなすげ〜な〜・・というリスペクトの気持ちでいっぱいです。これで税別1480円、めちゃめちゃ安いですよ(笑)。180ページほどの中にとてつもない価値と手間が詰まっています。

GitHub

以下はどこまで詳しいことを公開していいのかわからないので概要までですが、今回の記事はGitHub上で進行しました。これもありがたかったですね。

ぼくは基本的に、日本語テキストの編集もじゃんじゃんGit管理(というかGitHub管理)できたほうが良いと思っているので、環境的には申し分なかったです。

ちなみに、WEB+DB編集部がGitHubを使っている、という話は以前に「GitHub Kaigi」というイベントに参加したときに、編集長の稲尾さんが登壇しているのを見てざっくりは知っていたんですけど、

gihyo.jp

まさかそのフローを自分も体験できるとは(笑)5年前の同会場では想像もできなかったですね。(細かいフローはだいぶアップデートされてると思いますが)

GitHubの良いところは、とにかく前のバージョンを残せる、見返せる、というところだと思います。もちろん、消したい過去も残るわけですが、基本的には同じ目標に向かって進むひとつのチームですから、仮に恥ずかしい間違いや操作ミスがあっても、それはそれでべつにいいや、という感じで遠慮なく使わせてもらいました。

Issueなどの機能もけっこう初めの方からバリバリ使って、思ったことはなるべくそのつどオープンに伝えるようにしました。この辺は生来の空気読まない気質が良い方に作用したかなと思っていますが、まあ同時に、その意見言い過ぎなところがいつまでも執筆・編集が終わらない遠因になったのかも・・という気も今してきましたが。

話を戻すと、GitHubを使うとテキストベースで正の情報をアップデートしていけるので、それがありがたかったです。最終的には、本番デザインに組んだデータの方が正(最終版)になるわけですが、それでも簡易的なレイアウトや文字数はギリギリ最後の方までGitHub上のプレーンテキストでチェックできるようになっていたので、この辺はやっぱり技評さんならではの技術力と言いますか、助かりましたね。

コミュニケーション

編集チームとのコミュニケーションも円滑で良かったです。編集長の稲尾さん、この1コーナーにここまでコミットしてくるのか(笑)と驚くぐらいすごいスピードで動いてくださって、これがプロの仕事・・という感想でした。硬軟のバランスというか、アメとムチの出し方というか(笑)あれよあれよという間に執筆モードに誘導され、必要な環境がセットされ、気がついたら集中して取り組んでる、みたいな感じでした。

工程の後半は同編集部の渡邉さんに担当してもらいまして、こちらも毎回迅速なレスポンス、かつぼくのめんどくさい相談にも深いレベルで検討&回答してくれて、ありがたかったです。

とくに良かったのは、お二人ともレス(返信)が確実に来るんですよね。というのも、個人的にはレスって、べつに「早ければいい」というものではなくて、一番良いのは「想定どおりのタイミングで来る」のが良いレスだと思っていて、その意味で最悪なのは「めっちゃ早いときもあればまったく来なくなるときもある」というやつで、逆にその日のうちに返事が来なくても、毎回「午前の問い合わせには翌日午前、午後の問い合わせには翌日午後に返事が来る」みたいにパターンが一定なのがありがたいというか。あるいは事前に予告されていて、そのとおりに返ってくるとか。
そういう、ある意味基本みたいなところがきちんとされていてありがたかったな、と。

監修の牧さんにも、pecoの使い方でどれだけ怒られるかと戦戦恐恐としていましたが(←大げさに言いました)、改善点の提案なども論理的・丁寧に示してもらって、とてもやりやすかったです。

終わりに

ということで、丸々4ヶ月ほどにわたって取り組みました執筆もようやく終わりまして、またこの解題をもって本件全体についてもひと区切りかなと思います。

あらためて、今回の機会を与えてくれた id:papix さん、編集部・監修者の皆さん、ありがとうございました。
そしてまだ見ぬ読者の皆さん、どうぞお楽しみください。『ノルウェイの森』で小林緑が言った、以下の言葉を捧げます。

そのだしまきよ。心して食べてね。

WEB+DB PRESS Vol.112

WEB+DB PRESS Vol.112

  • 作者: 樋口剛,篠田典良,谷口慶一郎,大沼由弥,豊島正規,三村益隆,笹田耕一,牧大輔,大原壯太,門松宏明,鈴木恭介,新倉涼太,末永恭正,久保田祐史,池田拓司,竹馬光太郎,はまちや2,竹原,粕谷大輔,泉征冶
  • 出版社/メーカー: 技術評論社
  • 発売日: 2019/08/24
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

*1:一応、「初歩的なコードを組み合わせて自分に必要なものを作った」という意味ではテーマの範疇だと思っていますが。

*2:印刷所にデータを渡すこと。

RubyKaigi 2019に行ってきた

すでに4ヶ月過ぎてしまいましたが、2019/4/17(水)から4/21(日)まで、RubyKaigi 2019に参加するため福岡に行ってきました。

rubykaigi.org

大事なことなので初めに書きますと、今回の交通・宿泊費および参加費は会社に出してもらいました。またそのうち営業日は業務扱いで、有給も消化せずに参加できました。

そんなヴェルク(株)はRubyを使って受託開発および自社サービス「board(ボード)」の開発・運営を行っています。現在はQAエンジニアを募集中ですので、ご興味おありの方はぜひどうぞ。

RECRUIT | ヴェルク株式会社

・・と、そんなことを言ってる私は本来開発もRubyもまったく関係ないカスタマーサポート兼社内外ドキュメントの編集者ですが、6年ほど前から趣味でプログラミングをやっていまして(Perlで入門)、当時はフリーランスの編集者でしたが、その頃からYAPCには毎年参加していたので、昨年末にヴェルクに入ったことをきっかけに「次のRubyKaigiには行っておきたい、Rubyコミュニティ・デビューしたい」と思いまして、エイヤと参加した次第でした。

前置きは以上です。以下、開催期間中に毎日取っていたメモを元に記録をまとめます。

目次

DAY 0

往復の飛行機はスターフライヤーを使いました。以前に山口へ取材に行ったときにも一度使いましたが、その時の印象がとても良かったので。今回も最高でした。また機会があれば使いたいと思います。

イベント前日に到着したものの、時間はすでに夕刻過ぎで、クルーズ等の懇親会にも申し込んでおらず、かつ朝から何も食べていなかったことにようやく気づきながら福岡の夜を彷徨しかけたところ、当地で働くPerl Mongerの@itokenさんから声をかけてもらって、知る人ぞ知る天神の「屋台屋ぴょんきち」で初日からディープな屋台飯を頂くことに。いきなりの豚骨ラーメン@屋台を堪能しました。

f:id:note103:20190417211249j:plain
ドリンクは終始サワーと芋焼酎。食べ物はこの他に焼き鳥・餃子・干物など。

DAY 1

前夜は想定外の屋台飯にテンションが上がって飲み過ぎてしまい、初日の朝は久しぶりの二日酔い*1。しかしMatzさんのキーノートを見逃すわけにはいかないので、なんとか支度を済ませてホテル近くから会場に向けて路線バスでいざ移動!*2 と思ったら、Googleマップで示されているバス停にいつまでもバスが来ない。*3

え、どうしよう・・と焦るもそのまま待っているわけにもいかないので、少し歩き出してからちょうど通りかかったタクシーにスイッチ。さらに大渋滞に阻まれながら、たしか10:00ジャストぐらいに会場着。料金は1,200円ぐらい?(おぼろげ)

いきなり遅刻かい・・とヘコむもとにかく前進、3階のメインホールへ行くまでにノベルティをいろいろ取れるようになっていたので、パーカー*4、Tシャツ*5その他主要なものをゲットしてからMatzさんが待つメインホールへ。

ホールに到着するとまだスポンサーセッションをやっていて、GMOペパボさん、Raksulさんの発表ののちに初日最初の目的だったMatzさんのキーノートを聞くことができました。幸運・・。

出張屋台

ほどなくお昼。なんと会場下の広場に数台の屋台が登場し、しかもすべて無料で食べられる! ・・こりゃすごい(笑)。

f:id:note103:20190418120352j:plain
このときは時間も早かったので人はまばら。この後大変な行列になる

f:id:note103:20190418120724j:plain

ぼくはまだ二日酔いが抜けきっていなかったので、胃に優しいものを・・と思ってふぐ天うどんを頂きました。

f:id:note103:20190418121537j:plain

この時、屋台の中で食べることもできましたが、近くに設置されたテントで食べることもできたので、そこまでテイクアウトで運んでズルズル。すると、「ここ、いいですか(英語)」という感じで海外からの参加者さんがやってきたので「Yes!」と元気に返事をして少しおしゃべり。なんでもロンドンのBBCから来たとのこと。ぼくは英語ほとんどできないですが、たまたまその脇に座っていた方が話を進めてくれて、なるほどBBCでもRuby使ってるんですね、なんて話をしばらく。

午後のメニュー

午後に入ってからはまずこちらを見て、
Terminal Editors For Ruby Core Toolchain - RubyKaigi 2019

こちらを聴いて、
Determining Ruby Process Counts: Theory and Practice - RubyKaigi 2019

それから話題のコーヒー店「猫廼舎 (ねこのや)」さんへ。
荒木町(四谷三丁目) 珈琲専門 猫廼舎

猫廼舎さんの出張店を企画・実現してくれたのはSpeeeさん。なんというセンスの良さ!ありがとうございました。
speee.jp

おいしく頂きました。

f:id:note103:20190418141217j:plain

その後は、先日のOSS Gateで大変お世話になりましたようさんの発表を最前列で見て、
Ruby for NLP - RubyKaigi 2019

この日の発表チェックはここまで。全部見ていると疲れるし・・ブースも見て回りたかったので。

スタンプラリーでスポンサーブース巡り

そんなスポンサーブースはとにかく盛りだくさん。見るべきところばっかりでそれも楽しかったですね。

ぼくがこれまでに参加してきたカンファレンスだと、スポンサーさんからのノベルティって入場時にトートバッグに詰めてどさっと渡される、というスタイルが普通でしたが、今回はスタンプラリー形式というか、自分が話を聞きに行った(スタンプをもらいに行った)ブースでノベルティを受け取る、という方式。これだといろんな企業とのコミュニケーションが自然に発生するので、ナイスアイデアだなあと思いました。

ぼくはひとまず、いつもその取り組みを敬意を持って眺めているメドレーさんで絆創膏をもらったり、サムライズムさんのところでヨーヨーをもらったりしました。


igaigaさんにサインを頂く

今回はRuby関連の書籍を2冊持ってきました。

ゼロからわかる Ruby 超入門 (かんたんIT基礎講座)

ゼロからわかる Ruby 超入門 (かんたんIT基礎講座)

初めてのRuby

初めてのRuby

この日はそのうち前者を宿から持参して、タイミングが合えば著者の五十嵐さん(@igaiga)にサインをもらいたいなと思っていましたが、ちょうどこのブース巡りの際に出張版の技術書典みたいなコーナーがあって、そこをぶらぶらしていたら五十嵐さんにお会いしたのでそのままお願いしました。五十嵐さん、快く応じて頂きありがとうございました。

ちなみに、ぼくはとくにサイン集めの趣味があるわけではなくて、自分が愛着を感じた本の著者さんに直接会える可能性があるときに限り、感想や意見を伝えるきっかけとしてその本を持っていって、もしたまたまタイミングが合ったら話しかけて書いてもらう、という賭けみたいなスタイルで頂いています。

これ以前だと、昨年の大江戸Ruby会議07のときにMatzさんに以下の本にサインを頂きました。

オブジェクト指向スクリプト言語 Ruby (ASCII SOFTWARE SCIENCE Language)

オブジェクト指向スクリプト言語 Ruby (ASCII SOFTWARE SCIENCE Language)

こういうのって少し勇気がいりますし、空振り(=会えない)もあるので積極的にはしないのですが、RubyKaigiというお祭り感もあって踏み出しやすかったですね。

ハックスペース

そのブース巡りに前後して、5階に用意されていた畳のハックスペースにも行きました。

blog.notainc.com

充電可能なテーブル付き、そして玉露を無料で頂けるという満たされすぎなシステム。朝からずっとバタバタしていたので、ここでようやくリラックスできました。

ちなみに、ここで当日に見たトークややったことをプライベートなScrapboxにメモしたことで、翌日と翌々日も同じぐらいの時間帯にメモを取る習慣ができて、そのおかげで今この記事を非常に書きやすくなっています。

イベントレポートはすぐ書くに越したことはないですが、それができなくてもとりあえずメモだけでもきちんと取っていれば、4ヶ月後経ってもなんとか思い出しながら書けることを実感中です・・。

有賀さん(@chezou)に挨拶

ハックスペースからそろそろ移動しようかな、と思った頃に、ふと後ろを見ると@chezouさんこと有賀さんがいらっしゃったので、声をかけて少しだけおしゃべりしました。というのも、ぼくは今までYAPCやVimConfへの参加経験はあったものの、RubyKaigiは初めてだったので、その準備というかRuby対策として、以前に有賀さんがホストしていた「rubyist.club」をすべて聴いていたのですよね(真面目〜)。

それが面白かったので、直接「面白かったです」と伝えました。ちなみに、有賀さんは以前にこの記事を読んでいたので顔もすぐわかって、声をかけやすかったです。やっぱりどこかしらで顔を出しておくの、重要だなと思ったり。

blog.team-ai.com

DAY 2

初日の教訓を生かして、福岡の2夜目は早めに休み、連日の二日酔いは回避しました。・・が、この日の朝もオープニングには間に合わず。

というのも、この日は前日の教訓を生かすべく、正しいバス停に時間どおりに着いたつもりでしたが(前日はバス停を間違ってたので)、その途中ですれ違ったバスがなんだか目的のバスだったような? まさか時間より早く発車することはないよな〜・・と思っていましたがそのまさかで、少なくとも3分ほど早く出てしまったようでした。

え、でも、どうせすぐに次が来るんですよね? と思いましたが次は17分後ぐらいで、いや普通に遅刻じゃんということで方針変更。しかしさすがに連日タクシーはつらい・・と思ってGoogleマップで検索を重ねて、博多駅近くから出るBRTという2両編成の快速的なバスをなんとかゲット。結局到着したのは前日より遅い10時10分ぐらいでした。

会場ではこの日から無料の朝食があったはずなんだけど、パッと見ではちょっとわからず。遅れて着いたから終わってしまったか・・とそのまま上階に上がりましたが、後から聞いたところでは朝食用のレストランが別にあったのですね。RubyKaigiではそういった細かなおトク情報が満ち満ちているので、宝探し的にそれらをゲットしておくスキルが求められるな・・と実感しました。

オープニング・キーノート

メインホールに到着すると、2日目のオープニングである@nagachikaさんのキーノートが始まったところで、前の方の空いている席に収まって拝聴。

All bugfixes are incompatibilities - RubyKaigi 2019

このお話、これといった専門的な知識がなくても追っていける内容で、すごく面白かったです。stable versionのメンテナとしてどんなことに気をつけているのか、どんな失敗をしてきたのか、みたいな話をユーモラスかつ誠実に語っていて、最後まで夢中になって聞きました。

キーノートが終わってふと横を見ると、なんと先日のOSS Gateでお世話になったばかりの@swamp09さんがいらっしゃって、しばし歓談。

いやー、朝遅れちゃって・・バスがそのあの・・なんて言っていたら、会場と各地を結ぶシャトルバスのことを教えてもらいました*6。なるほど。もしRubyKaigiを256倍楽しむ方法というものがあるとしたら、事前にRubyKaigi経験者であるところのRubyistにいろいろ教えてもらえ、ということになるでしょうか。なお、swampさんからは「RubyKaigi直前のRejectKaigiに行くとRubyKaigiの見所も教えてもらえるから、出れるならそれに出ておくだけでも違う」とも教えてもらいましたので、合わせてシェアしておきます。

早めのお昼

前日の屋台ではけっこう行列が激しくて、もう並ぶのは嫌だなと思っていたので、2本目の発表はパスして早めに屋台に行って「豚骨Rubyラーメン」を頂きました。豚骨Ruby? はい。この「Ruby」にあたる部分はなんとミートソース。ミートソースmeetsトンコツ。なかなか味わいがたい味わいを得ました。

f:id:note103:20190419115155j:plain

その後、スポンサーブースに戻って未読ブースをひとしきり巡りました。しかしつくづく思いましたが、ぼくは今回エンジニアとしてではなくカスタマーサポート兼編集者という立場(?)での参加だったので、各ブースが想定するお客さんとはちょっとズレていて、それがわずかながらも残念ではありましたね。

といっても、もちろんそれはブースの人たちの問題ということではなく、参加者であるぼくに起因する問題なのですが。つまりエンジニアではないとしても、それに近いぐらいの技術的な知識や素養があれば、ブースの人たちが言うことに対してもっと「なるほど」とか「そりゃ面白い試みだ」みたいなことがわかったのかな、と。

午後のメニュー

その後は、Fromロシアのアンドレイさんの発表を見て、
Yabeda: Monitoring monogatari - RubyKaigi 2019

それからこちらの複合セッションを見て、
RubyData Workshop - RubyKaigi 2019

一旦発表巡りは終了。前日同様にハックスペースへ移動して、その日の記録をScrapboxに取ったり、体を休めたりしました。

さてこの時、ふと同じフロアで開催中の猫廼舎さんの方を見ると、いつもなら常時10人近く行列しているお客さんが3人ぐらいしか並んでない! と気づいて慌ててダッシュ。しかし、目の前のそれに辿り着くまでの数十秒のうちにあっという間に数人並ばれて、結局普通に6〜7人待つことに。

しばらく頭をカラッポにして待っていたら、ちょうど自分の前でそれまでに淹れていたコーヒーが終わったようで、店主の@ogijunさんから「濃さはどうしますか?」と意外な質問が。聞けば、新たにコーヒーを淹れるときに先頭だった人に濃さの希望を聞いて、その後の7〜8人は(つまりその分が終わるまで)その味で提供されるというめちゃ重大な責任が課せられたようでした。

で、僕の回答はこちら。

ちなみに、先頭で待つ特権として、しばらくogijunさんとお話しすることもできました。ぼくは以前からogijunさんの存在は知っていたのでその話とか、自分はエンジニアではないけどYAPCは何度も行っていて〜、とか。その辺りを起点にogijunさんからもYAPCとRubyKaigiの関係とか、へえ〜と思うようなことをお聞きできて、とても印象深い時間になりました。

Lightning Talks

LTにはプロポーザルを出していましたが、あえなく落選。でも、一連の発表を見て納得感がありましたね。この中に混ざったらとても太刀打ちできなかったなと(笑)*7

知識的・技術的にまったくついていけない部分も含めて、どれも楽しく見ましたが、令和ネタが続いたあたりが個人的には盛り上がりました。

After show

RubyKaigiから少し離れますが、この日の夜にはかつて新宿&池袋のジュンク堂で働いていて現在福岡のジュンク堂で文芸書を担当している友人M氏の元を訪れて、どこに行っても変わらない同氏ならではのイカレた棚を堪能しました。

f:id:note103:20190417194110j:plain

f:id:note103:20190417195212j:plain
ものすごい手作り感。上の方に柴崎友香さんの名前がありますが、勝手に使ってるのではなくてご本人と連絡取った上で飾ってるらしい。
f:id:note103:20190417195057j:plain
こういう手書きポップも著者さんに来店時に書いてもらってるらしい。さすがとしか。

その後、同地が誇る個性派出版社「書肆侃侃房(しょしかんかんぼう)」が運営するブックカフェ「ajiro」に連れて行かれ、店主のFさんを紹介するから、と言われたものの、何だか外から店を見る限り貸し切り? みたいになっていて、なおかつ何かテレビ取材? みたいのが入っている・・「(私)これ今日ダメじゃないの?」「(M氏)いやあ、おかしいですね・・とりあえず出直しますか・・」とか言って退散しようとしていたら、中の方でF氏がぼくらに気づいたみたいで、「どうぞどうぞ!」とか言われて中に入ると、ちょうどその時間帯にいつもajiroで開催されている『短歌の会』みたいな集まりをNHK福岡の取材班が取材していたところらしく、にもかかわらず「あの、じゃあほら、二人も参加して!」とかいきなり無茶に誘われて、そのまま『短歌の会』に合流&お題の歌に感想を述べたりテレビ取材も受けたりすることに・・。

終わってから、ディレクターさんに「名前と年齢教えてください」と言われたので名刺交換したりしましたが、あれは本当に放送されるんでしょうか・・? 4ヶ月経ってもとくに音沙汰ナイですが。 🤔

その後はF氏が「前から行ってみたいと思ってた」という「戦国焼鳥 家康 5号店」へ。

謎の「ルビーサワー」で怒濤の1日を打ち上げました。

f:id:note103:20190419234701j:plain

DAY 3

いよいよ最終日。

前夜の「戦国焼鳥」は深夜に及び、終電も逃したので徒歩で天神から博多のホテルまで帰りましたが、目覚めはスッキリ。二日酔いもありません。

路線バスチャレンジは2度にわたり失敗しているので、この3日目はSmartHRさんのスポンサードによるシャトルバスで会場へ。助かる〜〜!

f:id:note103:20190420093136j:plain

最終便だったので時間的にはギリギリでしたが、前日のように時間前に出発されるとか、前々日のようにバス停を間違えるとかのミスは回避できるのでとにかく安心。参加者さんのオレンジパーカーも良い目印になりました。

午前のメニュー

到着して1発目は「Ruby Committers vs the World」。
Ruby Committers vs the World - RubyKaigi 2019

内容的にはわかったり、わかんなかったり、という感じでしたが、全体を通して楽しみました。笹田さんの進行ぶりも良かったですね。

その後は、こちらを聞きました。
The Selfish Programmer - RubyKaigi 2019

英語トークということもあって少し難しく感じるところもありましたが、イラストも多用されていて、おおむね把握できたと思います。共感するところが多い印象でした。

で、お昼。この日も少し早めです。前日、ふと見ると屋台ではなくお弁当を持って歩いている人も多くて、「どこでゲットできるんですか?」と聞いたら「中にあるよ」と教えてもらっていたので、最終日はこれをゲットしようと思っていました。

果たして、望みどおりのイイ感じのお弁当をゲット。じっくりゆっくり頂きました。

f:id:note103:20190420123004j:plain

幕間

この後はしばらくまたブース巡り。最終日ということもあって、これまで見れていなかったブースを駆け足で。

印象的だったのは、前年のbuildersconで少しだけお話ししたStripeのエイミーさんと会えたことですね。

builderscon.io

あれ、もしかしてエイミーさんですか、と聞いたら思い出してくれて、しばし歓談。このときにもらったStripeのノベルティのノート、軽くてカッコよくて、気に入ってます。

それで思い出しましたが、この会場は空間自体は広々しているものの、それなりに動線が限られているので、なにかと人に出会う、すれ違う機会が多くて、ことあるごとに「あ、どうも」みたいに対面してはそのまま少ししゃべる、みたいなことができて良かったです。

上記のロシアから参加していたアンドレイさんも、発表のときにオリジナルキャラクターのステッカーがあるよ、と言っていたので、廊下ですれ違ったときに「まだステッカーありますか」と聞いたら、「下のロビーに置いてあるけど、一緒に見に行こう」と言ってそのまま数フロア同行してゲットしたり。

あとは少し前に宣伝しましたが、その頃からちょうど『WEB+DB PRESS』のための原稿を書き始めていて、そのコーナーを担当されている同誌編集長の稲尾さんにお会いできたり。「なにか問題ないですか?」と不意に執筆状況について聞かれたので、「まあ、とりあえず書いてみます、たぶん大丈夫です」とやや自信ありげに返事をしましたが、全然大丈夫じゃなかったことがわかるのはその2ヶ月ほど後のことです。これについてはまた別の記事で・・。

午後のメニュー

そんなこんなを挟みつつ、午後の最初は柴田さんのこちらを聞きました。
The future of the Bundled Bundler with RubyGems - RubyKaigi 2019

こちらもそんなに専門的な知識がなくても最後まで楽しめる内容でした。すごい! えらい! 尊敬する! と思うことしきりでした。

その後、小休憩を挟んで行ったのがこちら。
Play with local vars - RubyKaigi 2019

とにかくグレイトワーク、グレイト発表! すーごく面白かったですね。ujihisaさんは前年に行われたVimConf 2018でもスペシャルな発表をされていましたが、その印象をさらに塗り変えるような素晴らしい発表でした。

ちなみに、ujihisaさんはそのVimConfの発表後にこんなことをツイートしていて

もうまさに、まさにそれだなあ、と思いました。楽しかったです。

その後はクロージングのキーノートをホールで聞いて、来年の予告。

f:id:note103:20190420184244j:plain

行きます!

アフターパーティー

終演後は、トレジャーデータさんご提供のアフターパーティーへ。お店がちょっと見つけづらい場所にあり、かつそれなりに本会場から離れていたのですが、自分的にはけっこう頑張って早めに到着したつもりが、すでにだいぶ人がいてびっくり。

毎度のことながら、こういった場では知り合いがいない方がデフォルトなので、飲み物を取ってその辺の空いてるスペースに収まってぼんやりしているうちに、いつものようにちょうどその辺りにいる方々とおしゃべり。とくに目的もオチもなく、ただ思いつくまま喋って時間を過ごすこの感じ、ぼくは好きです。単なる世間話というのでもなく、共通の話題があるというのがいいのかも。

とにかく英語率が高いので、否応なく英語をしゃべる機会にもなります。上記のアンドレイさんがいたので少し話したり、その場にいた人に彼をまた紹介したり。

あとは、たしかデンマーク? から来たという海外テック企業のチームと喋ったり。ぼくらはこれこれこういうサービスを作っていて、ニーズはあると思うんだけど、こういう問題があるから日本では展開できないな、みたいな話とか(たしか「日本進出すればいいじゃん!」と誰かが冗談で言って、それに対して「いや無理だよ、なぜなら・・」とマジレスしたのだったか)。

あとは「今日見た中で一番良かったのは何?」という、ある意味定番だけど鉄板でもあるような話題を振られて、「ujihisaさんのが良かったよ」と言ったら「俺も見たよ・・あれは良かった!」と盛り上がったり。いやあ、しかしこんな会を月イチでもやっていたら、さすがにもう少し英語うまくなるのでは・・と思うぐらい最大限に英語喋りました。ありがたい機会です。

Yuguiさんにサインを頂く

アフターパーティーのハイライトは、今回持っていったRuby本のもう1冊、『初めてのRuby』にその著者であるYuguiさんのサインをもらったことでした。

この日は最終日だったので、お願いするなら今日がラストチャンス〜・・と思って朝から本を持ち歩いていたものの、会場では全然お見かけしなかったので「ハイ空振り〜・・まあ、それもご縁だから」と諦めつつ、そのパーティーに行ったらYuguiさんもいらっしゃったので、「終わってなかったラストチャンス」と思ってタイミングを見て声をかけてサインを頂きました。

ちなみに、ちょうどこのときにYuguiさんとお話ししていた@kwappaさんがこのやり取りの一部始終を見て、記念に写真を撮ってあげますよと言ってくれて思いがけず記念写真も撮ってもらいました。Yuguiさん、kwappaさん、ありがとうございました。

中洲、そして川

Rubyistの皆さんと「川」に行くチャンスは去年の大江戸Ruby会議07のときにもあったのですが、その日は用事があって行けなかったので今回は初「川」でした。

「川」というのは、つまりそこで缶ビールなどを飲んで語らうみたいなことですが(たぶん)、上記のアフターパーティーの後、次はどうするかという流れで「じゃあ、川で」と川へ向かうみんなに付いていって、そのまま川でビールを飲みました。

このとき、移動前に撤収モードのパーティー会場で声をかけてくれたのがJobin(ジョバン)さんで、日本語もすごい流暢なんだけど半分英語で何だか英語のレッスンみたいになりながら一緒に次の会場(というか川)に向かいました。しかしこの後の道中がまた一人ではまず体験するはずがないような不可思議なもので、気がつくとぼくとJobinさんの周りには日本人の同行者が1人もいなくなっていて、逆に海外勢の5〜6人が英語でひっきりなしに喋っている中に加わっていて、「もうよくわからんがとりあえずこのまま一緒に行くしかない・・」ってなりながら付いていったらその中の誰かが「面白いからあっちから行ってみようぜ」とか言ってわざわざ中洲のめちゃディープな狭い路地に入り込んで、まるでデヴィッド・リンチmeetsロスト・イン・トランスレーションみたいな幻惑的な光景のなか次から次へと行く先を阻む客引きの人たちとワイワイ言いながら練り歩いて(めっちゃ怖かった)、ようやくそれを抜け出したときには本当にホッとしましたね。いやあ・・何やってんだみんなも自分も。

そんなふうに辿りついた川はさっきまでの閉塞的時空間とは打って変わって広く開けたところで、そのまましばらくJobinさんと英日まぜこぜの会話をしながら、すでにだいぶ飲んで別世界に飛んでいるような若い人たちとも適度に話したり。

このときにぼくがもう一人、この日のうちに喋っておきたいと思っていたのがJonanさんで、なぜならぼくは上記の大江戸Ruby会議07でのJonanさんの発表に非常に感銘を受けたからで、詳しくはこのレポートのJonanさんの部分を見て頂きたいですが、

magazine.rubyist.net

この中でもとくに彼が示した4番目のトピック「You’re Awesome」という話がじつに素晴らしく、ここで彼を捕まえて「あれは本当によい発表だった、ぼくはあなたの "You’re Awesome" の話を聞いて物の考え方が本当に変わった、まるで別人になったようだ、サンキュー」と伝えたら、彼は「その話を自分にしてくれたのは君が初めてだ、こちらこそありがとう、その体験についてぜひ他の人にも広めてほしい」と言ってくれました。

そんなどこにでもありそうな、でも非日常でしかないような儚い時間を過ごして、ついに最終日も終わりました。

終わりに

初めてのRubyKaigiは海外旅行に行ったかのようなフルコース的充足、詰め込まれた多様さに翻弄された日々でした。純粋に「行ってよかった」と思える部分もあれば、じんわり落ち込みながら「まだまだ至らない自分・・」みたいに思えることもあり、さまざまな印象を清濁あわせて受け取りました。

今後の展望的には、途中でも書きましたがもっと技術的な面、つまり具体的な一つひとつのトピックをより実感的に把握できるように、プログラミングの技術や知識・経験などを身につけたいなあ、という感覚が強いですね。実際、どこまでやれるかわからないですが、次回のRubyKaigiまでの宿題として地道に取り組みたいところです。

あらためて、今回のイベントを作ってくれたスタッフ&スポンサー&地元の皆さん、福岡でお会いした皆さん、その他関係各位、ありがとうございました。

*1:たぶん1年以上ぶりぐらい。

*2:この時はシャトルバスの存在を知らなかった。

*3:同じ名前の逆向きの停留所で待っていたことに後から気づきました。

*4:とにかくオレンジが目立つので、街にいてもすぐ「RubyKaigiの参加者だ」と気づけて良かったです。

*5:後から気づきましたが、Tシャツのロゴ部分がエンボスのようになっていてそのオリジナリティが良かったです。

*6:公式サイトでも紹介されていて、自分でも見たはずだったんだけどまったく認識できていなかった。

*7:応募した内容は「LT応募当日からRubyKaigi当日までの30日間のRuby入門学習記録」というドキュメンタリー的なものでした。そこそこ面白くできる自信はありましたが、万一採用されていたら1〜2日目はほとんどその練習とスライド仕上げでつぶれていたと思うので、結果的には外れて良かったと思います。

Asakusa.rb 第527回 に行ってきた

2度めの参加です。

asakusarb.esa.io

初めて行ったのはいつだっけ・・Twitterでなにか言ってるはず、と思って検索したら、

と言っているので3月半ばですね。たぶん、翌月に控えたRubyKaigiの前にコミュニティの雰囲気を知っておきたかった、という感じだったかなと。

ちなみにその後、RubyKaigiの前にOSS Gateにも参加して、

oss-gate.doorkeeper.jp

こちらもかなり充実の内容でしたが、また時間のあるときに・・。

今回の私的テーマは、以前に7〜8割方書いていてそのままストップしてしまったRubyKaigiの参加レポートを仕上げたい! ということだったのですが、じつはこんなことがありまして↓大半の時間はぜんぜん違うことをしていました。

いやあ・・大変でしたね。久しぶりにかなり焦りましたが。一応、復旧したので良かったですが。

その後、残りの20分ぐらいで普段使いの自作ツール*1の改良に取り組んで、タイムアップ数分前にギリギリ手離れ。充実しました。(ブログどこ行った)

それから、この日はフロム台湾の@Stanさんがいらっしゃっていて、しばらくお話ししたり、お土産の太陽餅を頂いたりして楽しかったです。

www.instagram.com

太陽餅、初めて食べましたが初めての食感で、でもとくに抵抗もなく食べやすく、「Tasty!」と感想をお伝えしました。

会場の永和システムマネジメントさんは、ぼくが勤めるヴェルクから都営新宿線で数駅離れているだけのご近所さんで、というかぼくの帰り道に永和さんがあるので、ここでAsakusa.rbがある時は非常に行きやすいんですよね。
と言いつつ、最近はそもそも会社自体行かなくて自宅作業のことも多いので(とくに猛暑日)なかなか頻繁には行けないのですが。

ともあれ、非常にリラックスしながら、自分のやりたいことをやれて、なおかつ現役のRubyistの皆さんと時空間を共有する中でいろいろ高まったりするので、またぜひ行きたい所存です。

*1:これもまだどこにも紹介できてないので、いずれブログに書いておきたいところ。

『WEB+DB PRESS Vol.112』に寄稿しました(2019年8月24日発売)

掲題のとおりです。

gihyo.jp

発売は8/24とのことなので、あと3週間ぐらいでしょうか。余力があれば、またその頃に何か書きたいですが・・(無理かも)

初めに本件のお話を頂いたのはたぶん3月頃で、Perl入学式の名誉校長であります id:papix さんから、こういうのやりませんか、とお声がけ頂きまして。

具体的には、Perlハッカープログラマーの方々が連綿と受け継いでこられたリレー連載「Perl Hackers Hub」の第57回を担当しました。

タイトルは『自作ツールによる日常業務効率化 ―― 初歩的なコードだけで身近な問題を解決!』ということで。

まあ、これしかない、というか、こういうテーマでしか書けることがないのですけど、どうなんでしょうね、書き始める前には、第一にこんな話でいいのかどうか、第二にそれでいいのだとしても、現実世界でこれ、最後まで書き切れるのか体力的に・・などなど、いろいろ不安もありましたが。

結果的には、編集長&担当編集氏のスーパーご活躍と、メイン監修を務めて頂きました牧大輔さんのおかげで、「へ〜、思った以上に、思ったとおりの感じになったじゃん!」という感じになりました。
関係各位、本当にありがとうございました。

ぼくは今現在に至るまで、プログラマーとして仕事をしたことは一度もないんですが、この連載って基本的にプロ・プログラマーの方が記事を書いてらっしゃるので、硬軟の違いはあれど専門的な技術のことを扱うのが普通なところ、今回はやっぱり、異色といえば異色なものになったんじゃないかな・・と思います。

ただ同時に、ゆってもPerlの連載ですから、Perl成分はそれなりに濃いとも思います。何しろ、これまで5年ほどにわたり書いてきたPerlのコードをばりばり載っけましたので。

内容的には、そのノンプログラマーであるぼくが普段、自給自足的に作っては使っているプログラムについてあれこれ紹介している感じです。とはいえ、プロではないので、ねえ、まあ、難しいじゃないですか、どの辺をどの辺まで出すかっていうのは・・わかりますかね、結局、普段ぼくは自分だけが使う目的のプログラムを、自分だけが読む前提で書いているので、人様に、ましてやプログラマーである読者さんに(それもお金を払って読むような人たちに)見せるようなコードなんて書いてないんですよ(笑)。誰からもレビューとかされてないんですから。

なので、その辺のバランスというか、出すところと引っ込めるところのバランスを取りつつ、でも読み物としてはある程度、「貴重な時間を使って目を通してもそれなりには満足できる」ようなものを書ければ・・という感じで頑張りました。

しかしどうなんでしょうか、面白いんでしょうかね・・編集長氏は面白かったと言ってくれましたが・・ぼく自身はもう時間かけすぎてよくわかっておりません。

とはいえ本誌、ぼくはもう趣味のプログラミングを初めた頃からなので、2013年とか、2014年ぐらいには読み始めていたはずで、その頃から触れていた連載でしたから、まさかそのリレーの一員に加われるとは〜・・という感じでしたね。

編集チームもザ・プロの仕事。という感じで。ぼくも一応、編集の仕事をしていたはずだったんですが、この本物のプロを目の当たりにしますと、自分がやってたのは編集ではない編集的な何か、というか。讃岐うどんじゃないうどん、というか。そんな感じだったのかなと思いましたね。べつにどっちが上という話ではなくて、別物だったなあ、と。

しかしこんなブログをまだ続けているように、ずっと普通に、誰にやれと言われるまでもなくやってきたがゆえのコトだよなあ、と思います。ぼくはプログラミングを仕事にこそしていませんが、でも結局、向いてるのかなという気はしますね。ある種の才能というのか。やめない才能、苦もなく続けられる才能、疲れない才能、みたいな。まあ環境要因だったり、たまたまだったり、という要素も含めてのことですが。自分ではとくに努力と思ってやってるわけではないですからね・・はたから見れば頑張ってるように見えているかもしれないことも、べつに頑張ってるわけじゃなくて気がつけば普通にやっているだけで。それが向いてるということなのかなと。

ともあれ(まとめ)、いろんな貴重な経験をできた忘れがたい機会でありました。冒頭にも書きましたが、また発売前後でもう少し内容に踏み込んだことも書ければ〜・・とも思っていますが、それはその、ほんとに機会があればということで。

あらためまして、関係各位、ありがとうございました。読者の皆さん、発売をお楽しみにお待ちください。

WEB+DB PRESS Vol.112

WEB+DB PRESS Vol.112

  • 作者: 樋口剛,篠田典良,谷口慶一郎,大沼由弥,豊島正規,三村益隆,笹田耕一,牧大輔,大原壯太,門松宏明,鈴木恭介,新倉涼太,末永恭正,久保田祐史,池田拓司,竹馬光太郎,はまちや2,竹原,粕谷大輔,泉征冶
  • 出版社/メーカー: 技術評論社
  • 発売日: 2019/08/24
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

プログラミング入門者向けのサンプルコードで異なる名前を付けられるはずの複数の変数に同じ変数名を付けてしまう問題

Perl入学式の受講生だった5年前にも同じようなことを言っていたので変わってないな自分・・と思うとともに、この問題じたいがある種普遍的なのかな、という気も。

以下、掲題の件について簡単にまとめてみたいと思います。

Rubyで言うと、たとえばこんなサンプルコード。

class Foo
  def initialize(name:, price:)
    @name = name
    @price = price
  end

  def show
    return "#{@name}: #{@price}"
  end
end

bar = Foo.new(name: "apple", price: 100)
puts bar.show

結果は以下。

apple: 100円

引数としてクラスの外部から内部へ値を受け渡すためのname, priceと、クラスの内部でその値を操作するインスタンス変数のname, priceがそれぞれ別の変数であるにもかかわらず同名で記載・使用されています。

こういったことはPerlの入門者向けサンプルコードでも起こりがちで、なにしろPerlではスカラー変数でも配列変数でもハッシュ変数でも、それぞれ別の変数なのに同じ単語を使えるので、たとえばこんなことになります。

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

my $apple = 100;
my @apple = (101, 201);
my %apple = (foo => 102, bar => 201);

say $apple;
say $apple[0];
say $apple{foo};

結果は以下ですが、

100
101
102

問題は、この中の

say $apple;
say $apple[0];
say $apple{foo};

と並んでる3つの「$apple」は全部別物だということですね。まったく相互の関係はありません。

これ、混乱しませんか??

ぼくは初心者のときにこう思いました。「なんでわざわざ同じ名前付けるの!?」

上記の例で関係がある(同じ変数名でなければいけない)のは、以下の組み合わせです。

# 配列とその要素

@apple
$apple[0];
# ハッシュとその要素

%apple
$apple{foo};

同じ変数名を使うなら、こうした「同じ変数名でなければいけない組み合わせ」に限るべきで、なぜわざわざ配列とハッシュを同じ変数名にするのだ・・とただ苦しむばかりでした。

まあ実際には、ぼくもやがて初心者を卒業というか、初心者であることに飽き始めた頃、「なるほど、コードを書くときはこんな風にいろいろ揃えてしまった方がラクに感じることもあるのだな」と理解するようになりましたが、とはいえ、初心者にこれは酷だろうという気持ちには今も変わりはありません。

では、そのPerlのコード、どう直したら読みやすくなるでしょうか?
一例ですが、こんな風にすればどうかと思います。

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

my $apple = 100;
my @orange = (101, 201);
my %lemon = (foo => 102, bar => 201);

say $apple;
say $orange[0];
say $lemon{foo};

これだったら、どの変数がどこに動いているのか。それぞれの代入した値がその後にどこで使われているのか、追いやすくなります。

ようは、「同じ変数名でなければいけないものだけ」を同じ変数名にするということです。

コードには色が付いていません*1。そのようなとき、色分けをする代わりに適切な変数名*2を付ける必要があるのではないか、と思うわけです。

上記を踏まえて、あらためて最初のRubyの例に戻りますが(再掲)

class Foo
  def initialize(name:, price:)
    @name = name
    @price = price
  end

  def show
    return "#{@name}: #{@price}"
  end
end

bar = Foo.new(name: "apple", price: 100)
puts bar.show

これ、たとえば以下のようにすると、どの値がどの変数を通してどこへ動いているのか、わかりやすくなると思います。

class Foo
  def initialize(name_arg:, price_arg:)
    @name_var = name_arg
    @price_var = price_arg
  end

  def show
    return "#{@name_var}: #{@price_var}"
  end
end

bar = Foo.new(name_arg: "apple", price_arg: 100)
puts bar.show

この問題、ようは読み手のトレースする力の程度に合わせる、ということなのだと思います。コードを書いているプログラマー自身は、どの変数がどの値を抱えているのか、頭の中ですでに追えている状態なので、変数名によって値の経路を示す必要はもうなくて、むしろ別の理由、たとえば異なる中身を持った変数同士が同種の属性や役割を背負っていることを示すために、同じ変数名を付けてカテゴライズしておきたい、みたいな考えがあるのかもしれません。

しかし入門段階の人は、普通はそういったトレースをする力が十分にはないがゆえに、変数の名前からその中身の値を想像しようとしますから、異なる値・異なる変数であるにもかかわらず同じ名前がついていると、混乱が生じやすいということではないかなと。

このあたりの問題を認識した上で、その状況に応じてどうするべきなのか(異なる中身を持つ変数同士に同じ名前を付けるのか、それをしないのか)を考えられると、より良いかたちで書き手と読み手のコミュニケーションが成立しやすくなるのではないか、と思っています。

*1:エディタ等のシンタクスハイライトで色を付けることはできますが、それは個々の設定によるので、結局書き手が見ているのと同じ色付けを別の読み手が見ることはできません。

*2:ここで言う「適切さ」とはそのコードが読み書きされる背景によって変わるものだと思います。プログラマーの間だけで読まれる前提ならば、上記のような配慮は不要かもしれません。ここではあくまで「入門者にとって適切な」変数名について書いています。