Rubyで標準エラー出力に対してwarning吐いてる犯人を探したい!

gemとかが標準エラー出力に対して「deprecatedなメソッド呼んでるよ〜」みたいなwarningを吐いてくれることがあると思うんですが、自分のプロダクトコード側でそのメソッドを呼んでいるわけではなくて依存してる別のgemの気がする、犯人は誰だ!みたいなときの話です。

だいたい./vendor/bundle以下を検索すればまあ犯人見つかるというのはあるんですが、メソッド名を動的に作ってるやつとかがいると引っかかってこなかったり、あとは同じ文字列がたまたま関係ないところで出現してるみたいなときもあるにはあり、「このwarningを出してるところのスタックトレースがほしいよお!」ってなることがある。そのようなときには、

class CustomStdErr < IO
  def write(*args)
    p caller
    STDERR.write(*args)
  end
end

$stderr = CustomStdErr.new(STDERR.fileno)

warn("heyhey")

このようにして標準エラー出力をジャックしてやるとスタックトレースが取れて便利だと思う。

2019年音楽活動振り返り

去年もやりましたが、12月となったので今年関わった音源を順に(記憶があいまいで、多少の前後があるかも)振り返りたいと思います。

夕暮れによせて

曲を作ったのは去年なんだけど、歌詞ができなくて放置していたやつ。歌詞がついたので歌った。この曲はコード進行とメロディがドラマチックなので、「ピアノ〜」「アコギ〜」みたいにやっちゃうと昼メロドラマみたいな腐臭が漂い始めるのだけれど、あえてのシンセベースとクールめなエレピにしたところが自分で気に入っている。リスナーとして信頼している友人が「ドラムの展開が面白い」と言ってくれたことが嬉しかったし、バンドメンバーのタダくんが非常に気に入ってくれたこともうれしかった。一度デュオでやったけれど、うーん、バンドでやるには不向きな曲かなとは思っていて、バンドでやることはなさそう。あと、この音源を聴くと当時はミックスにまだまだ興味を持てていないことがよくわかる。

Sounds Around (My Life)

現在ぼくが最も信頼するボーカルであるところのつるえさんに初めて書いた曲。この曲については一度このブログでも書いた。当時の全力をぶつけたつもりだけど、今になって冷静に聴いてみると、つるえさんの歌に楽曲が負けてしまっていると感じる。ミックスも今聴くと下手くそですね。自分の歌をミックスするぶんには下手くそでも大した問題はない(ある)んだけど、つるえさんの良いボーカルを活かすためにはミックスも重要だと気づいた。「もっときちんとミックスができるようにならないといけない」と感じてミックスを頑張り始めるきっかけになった曲かもしれない。

カレイドスコープ

Sounds Aroundがきっかけ、というわけでもないのだけれど、その後つるえさんと一緒に「錦玉もなか」という名前でユニットをやることになった。そのユニットはEテレソングなどを演奏したりしているのだけれど、オリジナルがほしかったので作った曲。つるさんの声はほんとうにすごくて、どのような楽曲を書くか、あるいはどのようなアレンジをするか、どのような歌詞かによって本当に様々に表情を変える。その様が万華鏡のようだな、と思ったので、万華鏡をモチーフにした曲を書いた。それと、つるえさんにThe SupremesとかThe RonnetesとかThe Emotionsみたいな「かわいい系」かつブラックミュージックな香りのあるシンガー(だれかに怒られそうな表現だなこれ……)みたいな曲を歌ってほしかった、というのが合わさってこのようになった。そんなわけでド頭はThe Supremes「Baby Love」からの引用。

「こうしたい」というイメージだけ先にできてて、メロディと歌詞がずっと出てこなかった時期が2ヶ月くらい続いたあとに、ふと通勤中「きらり さらり しゃらら 万華鏡まわす」のフレーズを思いついて、「勝った!」と思った。実際そこからは一瞬で出来上がったのが良い思い出として残っている。錦玉もなかはふたりユニットなので、この音源のような豪華なバージョンで演奏されることはおそらく今後もないであろう。今聴き直すと最後のドラムなんかは山下達郎「パレード」あたりからの影響を感じる。

ミックスは頑張ったけど頑張りすぎてだめになってるパターン。やりたかったのはフィル・スペクターとかナイアガラみたいなサウンドなんだけど……。こうしてひとは失敗しながら学んでいく。

ラウンドアバウト - EP

これは今年の活動の一番でかいトピックス!

バンドでスタジオ盤を作った。宅録音源とは異なりきちんとしたレコスタできちんとしたエンジニアさんにきちんとお金を支払って。クロスフェードデモを聴いてすこしでも良かったらぜひ!https://triothecmyk.bandcamp.com/album/epからご購入ください! bandcampからじゃなくても、spotify, AppleMusic, Amazon Music, Google Play Musicなどでも配信中です。このレコーディングの経験はその後の宅録にもだいぶ生かされていて、「ははーんなるほど〜、そうやるのか!」みたいな学びがすごかった。

ツイストドーナツ

これはこのブログでもたまに登場するtmrrさん案件。tmrrさんが高校生の頃に御学友と一緒に書いた曲とのこと。ぼくはアレンジとギターの演奏とその他の楽器の打ち込みをやっている。歌っているのもそのtmrrさんの御学友です。アレンジに関して、「きゃるんきゃるんにしてほしい」というオーダーだったので、思いっきり90年代J-POPサウンドできゃるんきゃるんにしたった。これはボーカルはiPhone録音(ボイスメモ)で送ってもらったのだけれど、せっかく歌がうまいひとが歌っているのだから、もう少しよいアプリあるいは良い環境で録音してもらえばよかったという点を後悔している。録れ音がiPhoneボイスメモだとだいぶ限界がある……。アレンジは気に入っている。ミックスについてもすこしずつ勘所がわかってきて、「なにがわからないのかわからない」から「なにがわからないのかわかる」になってきた頃のように思う。

パーシモン

友人の島林深雪くん(以後みゆきくん)が曲を書いて、そこにtmrrさんが詞をつけたもの。本来はみゆきくんが歌っている曲なのだけれど、あまりに良い曲だったので錦玉もなかで勝手にアレンジして勝手につるさんに歌ってもらった。出来が良かったので、事後承諾で公開させてもらった。ミックスもだいぶうまくなってきて、音源の完成度としては多分今年一番の出来なのではないかと思っている(つるさんの歌のうまさにおんぶにだっこではある)。自分が書いた曲よりもこちらのほうがつるえさんの歌の良さが出ていて、かなり悔しい思いをした音源でもある。

ピクニック

ぼくがお世話になっているお店アルカフェの店主だんさんと友人のみゆきくんとが、つるえさん宛に合作された「ピクニック」という曲。つるえさんが出産を控えて里帰りされるということで、プレゼントとして制作されたとのこと。なのでボーカルもつるえさん。わたしはアレンジ(エレピ及びコーラスはだんさんの手によるアレンジ)とベースを担当。そのほかにも趣味レコーディング・エンジニアとして、みなさんの演奏のレコーディング(ボーカルがつるえさん、ギターと男声コーラスはみゆきくん、エレピと女声コーラスはだんさん)をして、ミックス、マスタリングをもぼくがやった。ミックスはトラックについてはだいぶよくなってきたが、ボーカルの処理がまだまだ甘い。というかつるえさんの歌すごい。Sounds Around、カレイドスコープ、パーシモン、ピクニックのすべてで、声がまったく違う表情を見せている。本当にすごいボーカリストだと思う。あと「好きな時間〜」という部分で「ん〜」をハイトーンで出させる作曲者は鬼だと思う。

台風のせい

またしてもtmrrさん案件。tmrrさん作詞作曲、歌。残りのパートのアレンジと演奏と打ち込みはぜんぶぼくがやっててすごい(自画自賛)。じつはいま聴くとエレピのアレンジちょっと直したいところがある……。 ミックスに関して、このあたりから「ステレオ感がどうしても足りない」「PANの問題ではなさそうだ」「ボーカルのミックスなにもわからん」ということに悩み始めている。この音源はtmrrさんがすごく喜んでくださったので、やってよかったと思う。自分のスキルがだれかに喜んでもらえるのって人間の根源的な喜びですよね……。

ノイジーペンギン

「最近ぜんぜん自分が歌う、しかもバンドでできそうな新曲作ってないな〜」という思いから作った曲。そういう半端な思いから作ったせいで、手癖で作ってしまった。そのせいかあんまりぴんとこなくて、結果自分の心の「イマイチ」フォルダに突っ込んである。けど好きって言ってくれるひとも結構いるのでそれは素直に嬉しいです。歌がちょっとうまくなってきたかもしれない。

図鑑を買いに

「ノイジーペンギン」の出来がいまいちだったことが心のどっかでひっかかってたんでしょう。すぐに次の曲を作った。「ノイジーペンギン」を「手癖」で作ってしまったことへの反省として、「いつもと全く違うアプローチで、違う曲想のものを作りたい」という気持ちで、かなり新鮮な心持ちで作った。Aメロ-Bメロ-サビ-Cメロ構成といい、アレンジといい、思いっきりJ-POPマナーをやりつつも、ちょっとヒネたポップス、というのがテーマ。アレンジもミックスも今の所だいぶ気に入っていて、良い出来になったと思う。おそらく音源の出来としては「パーシモン」につぐ出来なのではないかと思う。はやくこれが「この頃はレベルが低かった」といえるくらいにレベルアップしたい。

グラデーションスライダー

これもtmrrさん案件やんけ!!!! tmrrさんが自分の誕生日に向けてみゆきくんと合作したもののアレンジをした。楽曲があまり自分にない語彙のものだったので、そういうものを編曲するのは非常に勉強になった。ただこれは結構ミックスがたいへんだった思い出がある。というのも、全員遠隔で作業をしていたのが原因で、tmrrさんのボーカルの音とみゆきくんのボーカルの音が録れ音の段階で全然違う状態の録音だったんですよね。そのあたりをどうカバーするかという工夫をして、そこもたいへん勉強になる案件だった。

総括

こうして見ると、今年は10曲に関わっておきながら、純粋に自分の曲、自分が歌う曲というのは3曲しかやってないことがわかる。だいぶ「ひとのサポートをする」というのがメインの年になったと思う。しかし自分にとっては今年はDTMを始めてから一番音楽的に充実していたと言える一年だったように思う。バンドのレコードも作れたしね!

自分がメインの表現よりも、「だれかの表現を形にするお手伝い」のほうがぼくは好きなのだということに改めて気付かされたし(バンドでもどちらかというとそういう役回りだしね!)、そういうサポートを通じて自分のできることのレベルがぐんぐん上がっていくことが実感できる年だった。来年はこれをすこしでいいから収入に結びつけていくことを大きな目標としている。twitterのbioも「編曲家でプログラマ。弾き語りミュージシャンの編曲やレコーディング格安で請け負います。まずはDMか shinpeim@gmail.com にご連絡ください。相談は無料で乗ります」に改定しました。まだごらんのレベルだけど、「本物のプロに頼む余裕はないしそこまでガチではない、けど自分の弾き語りをバンドサウンドにしたい」とか「弾き語りを自分で録るよりもいい音で撮りたい」というようなニーズにお応えしたいと思っていますので、まずはご相談ください。

「ラウンドアバウト - EP」をリリースしました

ぼくは趣味としてずっとバンド活動をしているのですが、そのバンドのきちんとしたレコードを本日リリースしました(いままでは宅録音源とかライブ音源しかなかった)。特設サイトも作りましたので、そちらからぜひ購入ください。3曲入り600円からです。iTunesMusicStoreやGoogle Play MusicSpotifyなど、各種ダウンロード・ストリーミング配信サービスでも順次リリースされます。

round-about-ep.netlify.com

ところで、600円「から」というのは、bandcamp経由でお買い上げいただく場合、投げ銭としてそれ以上を支払っていただくことも可能だからです。売り上げは次回作の制作費としてありがたく使わせていただくので、「応援してやらんこともないぞ」という方はぜひ、ぜひですね、1000円くらいで購入していただけると、メンバー一同めちゃめちゃに喜ぶ、という仕組みになっております。

アートワークおよびグッズの話もしましょう。今回のアートワークは、知人のイラストレーターの佐藤おどりさんに描いていただきました。ぼくらの音楽は「オールドスクールなポピュラー音楽をリファレンスにしながら、現代的な感性で再構築する日常ポップス」みたいな感じで言いあらわせると思うんですけど、おどりさんの描いてくださったイラストは、まさにレトロ感と現代的な感性で音楽とともにある日常の一コマを描いてくださって、めちゃめちゃに素敵なアートワークを描いてくださったなあ、と感動しています。

で、グッズ展開です。メンバー自身が欲しくなるようなグッズが作りたい!というわけで、おどりさんの描いてくださったイラストをあしらったグッズもSUZURIで販売しています。こちらの売り上げも次回作の予算になりますので、おどりさんの素晴らしいイラストに心奪われた方はもちろん、バンドを応援してくださる方はぜひぜひ購入を検討していただければと思います!

suzuri.jp

肝心の音の方はどうなのかって?なんの言い訳もしないしする必要ない出来だと信じてるので、こちらのデモを聴いてすこしでもピンと来たらぜひ特設サイトからご購入ください!!

soundcloud.com

builderscon2019振り返り(not技術編)

builderscon2019に参加してきました。以下技術的ではない部分の振り返りです。技術的な部分の振り返りはまたあとで書きます。


今年はすごく自分のメンタルが乱高下する、とてもヘヴィなbuildersconとなった。というのも、まさに前回の記事に書いたことが起こったのがbuildersconの前夜祭だったからだ。前回の記事は自分もまだ混乱のさなかにあるときに書いたものなので、だいぶ落ち着いた今、再度そのあたりの話をするところからはじめたい。

前回の記事にも書いたけれど、「マッチングアプリのいいね自動化」という内容そのものが悪である、という立場にぼくは立たない。マッチングアプリというのは、そもそも男女ともに「性的に選別」しあうものである。そうである以上、「マッチングアプリ上での性的な選別の自動化」は問題ないはずだ、という立場ではある。「どんな文脈であれ人間を性的に選別するような発表はそもそも悪である」という立場もあるとは思うけど、それはそのまま「マッチングアプリは悪である」という立場になるとぼくは思っているし、何度も言うけれど、ぼくはそういう立場は今のところ取らない(もちろん、そういう立場に立つひともいると思うし、それは一つの意見として検討に値するものだと思う)。

ところで、「発表が悪くないんならなにが問題なのかわからない」という反応がいくつかあったのだけれど、今となって考えたらそりゃあの書き方で何が問題なのかわからないのは当然だよな、となったので、そのあたりの話をしたいと思う。まず、ぼくは「すでに参加者に多様性がある状態であるときにはOKなものも、著しく多様性が損なわれている状況ではさらに多様性を損なうことになりうる」という前提を持っている。今回はまさにそういう例だと思っている。

逆の立場になって、女性が大半であるようなコミュニティで、男性を容姿によって選別する技術の発表がされていて、それに笑っている女性がたくさんいるようなところに自分が参加したと想像したら、おそらくぼくは「ああ、このカンファレンスは男性である自分は対象外なんだな」と感じると思う。このように感じること自体が間違えているだろうか? 「そのとおり、そのように感じることが間違いだ」と言うひともおそらくいるだろう。ただ、「男性が参加者のほとんどで、しかも普段からプロフェッショナルとしてではなく女性として扱われがちで、なおかつ女性を容姿によって選別する技術が発表されて、たくさんの男性が笑っている」という状況を見てある女性が「ああ、このカンファレンスは女性である自分は対象外なんだな」と感じることを、ぼくは間違えたことだとは思わないし、思えない(もちろん、そう感じない女性だってたくさんいるだろうとは思うし、これを「悪い忖度」という人もいるだろう。そこはぼくとは異なる意見として、もうすこし検討したい部分ではある)。

べつの方向から見てみると、「マッチングアプリという文脈においては女性を選別することはなんら問題はない」とぼくは思っているが、その文脈を「プロフェッショナルとしてではなく女性として扱われがちでしんどい思いをしているひとたちがすでに何度も報告されており、なおかつCoCで"すべての参加者がこのイベント・コミュニティから歓迎され、楽しんでいただくくことをめざして"いると明言されている場」に持ち込むことは、不適切だと思う。おそらくここは違う意見を持つひともいて、「いや、マッチングアプリの文脈と、カンファレンスの文脈を分けられないのはむしろ受け手の問題でしょ」という話をすることも可能だとは思うし、それはひとつの正義だと思う。ただ、なんども言うようだけれど、ぼく自身はその立場には立たない。これは「どちらが絶対的に正しい」と主張しているわけではなく、「ぼくはこちらの立場だ」という話だ。

と、ここまでが前回の記事について、言葉を変えてもう一度書いた内容。ここからさきは当日の振り返りです。


ぼくは前夜祭の翌日、つまりbuildescon初日に登壇を控えていたのだけれど、当日の朝、「このままでは登壇できない」と考えていた。というのも、上述のような点について、運営側がどう考えているか、わからなかったからだ。それどころか、じつは前夜祭でのトークは公募ではなく、運営がオファー、ブッキングしたトークだということで、「むしろ運営としては上述のような点は"好ましいもの"、"推奨されるべきもの"ですらあるのだな」と感じていたからだ。ぼくは自分が絶対正義の側に立っているとは思っていないし、上述の通り「これで排除されたと思うのはむしろ排除されたと思う側の問題」という考え方にも一定の理があるとは思っている。しかし、もしも運営が、CoCですべての参加者が歓迎されることを謳っているこのカンファレンスにおいて (あらゆるカンファレンスで件のトークが排除されるべきだとは思わないから、このような限定をしている)件のトークが歓迎され、推奨されると思っているのであれば、そのようなカンファレンスには自分は賛同できない(それに賛同するひとがいても当然いいと思う)。そして、自分が賛同できない立場を取るカンファレンスに登壇するということは、どうしても自分にはできない、となったわけだ。

とうぜん、いろいろと悩んだ。そもそもぼくはbuildersconにはものすごい思い入れを持っていて、毎回登壇させてもらっているし、自分のエンジニアとしてのキャリアはbuildersconの周りに存在するコミュニティにかなり助けられているのだ。そういうカンファレンスに(自分のわがままで登壇しないと決めるとはいえ)登壇しないという選択をするのは、すごくすごく辛いことだ。それに、buildersconは登壇者が決まったあとにチケットを購入できる(これってじつは運営側からするとけっこう大変なんですよ)ので、自分の発表を楽しみにしてチケットを購入してくださった方だっているかもしれない。個人としての登壇だけど、会社にもサポートしてもらっていて、ある意味会社の看板も背負っている。そういう中で、自分のわがままで登壇をキャンセルする、ということが許されるのか。それはよくないことなのではないか。けれど、どうしても、このままでは登壇できる気持ちにならない。

そういう中で、会社に「最悪の場合登壇しない、という判断をしたい」と相談した上で、builderscon主催に「登壇について相談したい」という話をしに行った。ここもすごく悩んだ。さっきも書いたけど、そもそもぼくはbuildersconのことがめちゃめちゃ好きなのだ。それに、以前自分もカンファレンススタッフをやったことがあるから、主催やコアスタッフが当日どれだけ忙しい修羅場を迎えているか、知っている。そういう中で、自分のわがままをどれだけぶつけていいのか。けれど、信頼しているコアスタッフや主催に半ば甘えるような形で、「自分はこのように感じていて、そうである以上このままでは登壇できない、本当なら前向きな気持ちできちんと登壇できたほうがうれしいに決まっているし、どうしたらいいか自分でも混乱している」と主催の方に対して相談させてもらった。その結果、主催の方は嫌な顔ひとつせず、「なぜ今このようになっていて、自分たちが今どのような対応を考えているのか」をすごく誠実に伝えてくれた。その上で「今できるのはここまでで、そのうえでしんぺいさんが"やはり登壇できない"と思うのであれば、その判断は尊重する」と言ってくれた。内容を詳しく書くことはできないのだけれど、今これを書いている途中でも涙が出そうになるくらいだ。改めてお礼を申し上げたい。会社も、「しんぺいさんの判断を尊重する」「なにかあったら全力でちゃんと守るから」と言ってくださって、「この会社を選んで本当によかった」と思った。

その後、運営からは会期中にも関わらず公式な声明が発表され、ぼくは安心して「このカンファレンスの立場には賛同できるから自分も登壇できる」と思うことができた。何度も言うけれど、「これが正義だ」というつもりはない。様々な正義があると思うけれど、ぼくは こういう立場を取っていて、カンファレンス側もそういう立場を取っている、ということを確認できた、ということだ。当然、ぼくの相談あったから声明が出されたわけではないと思うし、おそらくぼくの相談がなかったとしてもなにかしらのアクションは取ってくださっただろうけれど、ぼくの一方的な立場だけから見ると、相談にしっかり乗っていただいたからこそ安心して登壇する気持ちを固めることができたという出来事だった。

ただ、この相談をしたことについては、いまでもそれでよかったのかどうか判断がつきかねている。ぼくにとっては本当にありがたい対応を各位がしてくださって、そのおかげでぼくは登壇する意思を固めることができたし、そのあとの懇親会なども楽しく参加することができた。しかし、実際に対応してくださった各位に対してはともすると「かけなくていいはずのコスト」をかけさせてしまっただろうし、まるで自分が「不寛容なSJW」のように感じられたり(というか、ぼくのことを「自由なテック・コミュニティの敵」だと思っているひとは実際にたくさんいるだろうと思う……そう思うとほんとうにつらい)している。仮に「カンファレンスの立場に賛同できないので登壇はキャンセルしました」としていれば、全てを自分の責任においてかぶる形になっていただろう。それはあくまで「ぼくの考えをぼくの責任において発信している」ということだろうし。そのほうが誠実であったかもしれないという気持ちも持っている。もちろんそうしたらぼくはいろんな角度から批判にさらされることになっただろう(チケットを購入したひとに対する責任はどうなるんだ、とかね)し、そういう批判を自分が受けたくないから、自分の登壇をある種「人質」に取って運営にに対して責任を負わせる形にしただけだろう、と言われたら、自信を持って「違う」と言うことはできない。そう考えるとすごく落ち込む。

と、今まで書いてきたようなことを考えながらbuilderscon本編2日間を過ごしていて、だけどやっぱりカンファレンス自体はすごく技術的に興奮する発表が多くて、懇親会などでもとても実りのある議論ができたりして、けどほんとうならぼくはそんな楽しみ方をする資格はないのかもしれなくて、というようなことを考えて、ほんとうに感情のキャパシティがもういっぱいいっぱいで、そういう点で、振り返ると今年はものすごくしんどいbuildersconだった。もちろん、この「しんどい」というのは誰かを責めるための発言ではなくて、単純に振り返りとして。

エンジニア・コミュニティにはオープンであってほしい

エンジニアの集まるカンファレンス(参加者の多くはソフトウェア・エンジニアだが、ものづくりするひとすべてを対象としたカンファレンスなので、暫定的に「エンジニア」という括りで話します)において、マッチングアプリ上で女性の外見を判別して自動でいいねを押すという発表がなされている現場に居合わせた。このエントリの目的は特定の発表自体の是非を判断することではないので、リンクしない。「リンクしなければそもそもその発表の是非の判断ができないじゃないか」という向きもあると思うけれど、少し調べればわかることだし、その発表自体の是非を議論したいなら、調べるくらいのコストをかけて別のところでやってくれたら嬉しいと思っている。

さて。少なくとも今回参加しているカンファレンスのジェンダーバランスは、めちゃめちゃ偏っている。おそらく、多くの技術系のカンファレンスにおいても、そうなのではないかと思う。これ自体がいびつであるのか、それともそれは「生得的な性差によるもので自然なこと」なのかということについては、ここでは踏み込まない。ただ、事実として、現状のジェンダーバランスはめちゃめちゃ偏っている。そういう中で、女性エンジニアは、エンジニアとして参加したはずのカンファレンスで人事のひとだと思われたり、あるいは自分の専門分野に対してなぜか「教えてあげるね」という態度で話しかけられたりするという報告がいままでもなされている。エンジニアとして参加したはずのカンファレンスで、エンジニアとしてではなく、「女性」として扱われるという体験をする女性は、どうやら多いらしい(ここで「どうやら」ということばを使っているのは、ぼく自身が男性であり、すべて伝聞情報でしかないからだ。だけど、周りを見ていて「そういうこともあるだろうな」と思ってしまうのも、また事実だ)。そういう経験をしている女性がいる、という前提の中で、「女性の外見を判別して自動でいいねを押す」という発表がなされて、それが受け入れられている、というのは、どういうメッセージになるのだろうか。ぼくはやっぱりそれって「やっぱりここでは女性はエンジニアとしてではなく"女性"としてしか扱われないものなんだな」と思われてもしょうがないのではないか、と思うのだ(もちろん、そう考えないひともいるだろう)。

勘違いしてほしくないのは、ぼくは「女性の外見を判別して自動でいいねを押す」という発表が「悪いものだ」と言っているわけではない。というか、ぼく自身けっこう女性の外見の好みにすごく偏りがあるし、好み抜きにしても類型化した外見について語ることだってあるし、そういう話を、すでに友人関係で信頼関係も築けている男性、あるいは女性とすることを楽しく感じるような感性の持ち主だ。ただ、「エンジニアとしてではなく女性として扱われがちで、なおかつ周りが男性だらけ」というとても特殊な状況でそういう話がある種公的になされる、というのは、すごく排他的なメッセージになってしまうのではないかなあ、という話をしているのだ(もちろん、どんな場であろうと「別に排他的じゃないと思うけど」という意見もあるだろうけど)。

件の発表について、技術的にはすごく興味深い話だったし、もちろんその技術的な面白さは一切毀損されるものではない。「エンジニアとしてではなく女性として扱われがちで、なおかつ周りが男性だらけ」という特殊な状況が前提になければ、「これは面白い話だね!」で済む話だとぼくは思う(これまた、そう思わないひともいるだろうけれど)。だからこそ、この特殊な状況が変化してほしい、とぼくは思っている。自由に、のびのびと、技術を語りたいからこそ、エンジニア・コミュニティには女性が「ここでは男女関係なく"エンジニア"として扱わるんだ」と思えるジェンダーバランスであってほしい。そのためにも、ぼくたち「マジョリティ」がどういうメッセージを発するかということは、とても重要なことだと、ぼくは思っています(という、メッセージです)。エンジニア・コミュニティがオープンであってほしい、ぼくはそう考えています。

追記

ある種の無自覚な傲慢さについて

ぼくはもう35歳で、どうあがいても中年のおじさんであるし、子供もいる「いい大人」のくせに、毎朝きちんと起きることができない。こうやって雑文を書いたり音楽をやったりすることでなんとか自分を保ってるような「現実不適合者」だ。だからいい歳してバンド活動もやめられない。たまたまプログラミングが好きでやってるおかげでなんとか社会との接点を保って経済的にやっていくことが可能になってる。プログラミングのおかげで社会と接点を持つことができて、文章と音楽のおかげでなんとか自己と世界のチューニングを合わせることができている。そんな感覚がある。

で、 まあ、話を戻して(?)バンド活動をずっと続けているわけだけれど、そのバンドメンバーのひとりにタダくんという男がいる。ぼくは彼のことをバンドメンバーとしてもとても信頼してるんだけど、それ以上に文学部の友人としても信頼している。というのも、彼はぼくと同じくらい、ともするとぼく以上に、「ある種の無自覚な傲慢さ」を撒き散らかす人間に対する激しい憎悪を持っているようにぼくの目からは見えるからだ。彼の「ある種の無自覚な傲慢さ」に対するアンテナはぼくにはとても高性能に見える。それは、ぼくにとっては、とても信頼すべき部分なのだ。もちろん、それはあくまでぼくが捉えた彼の姿であって、実際には彼はそんなに激しい憎悪をもってなんかいないのかもしれない。それはわからない。だってぼくは彼じゃないから。それでも、すくなくとも「ぼくにとっての」彼はそういう人物だし、それはぼくにとってはとても好ましいことに感じる。ぼくにとってはそれで彼を好きになるのに十分だ。

ところでさきほどぼくは「ある種の無自覚な傲慢さ」と言ったけれど、その内実について話したい。ほんとうならばもっと解像度の高い言葉をつかうべきだと思う。けれど、それをうまくぼくは説明できない。だからその代わりに例を挙げたいと思う。

たとえば「自分は自己表現が好きで」と言えてしまう「シンガーソングライター」。たとえば「感動を届けたい」と言ってしまえる「詩人」。ぼくはこういう人たちをほんとうに醜悪だと感じてしまう。いや、おまえだってバンド活動やめられない「シンガーソングライター」じゃねえか、と言われればその通りなのだけれど、言い訳をさせてください。ぼくはあまり「自己」を表現したいとか「感動をを届けたい」みたいなことはなくて、「表現そのもの」のほうにむしろ興味があったりして、あの、その、えーと、たいへんにめんどくさくなってきたので強い汚い言葉を使ってしまいますね。

要するに、「自己表現」な人を見ると、てめーには(というかふつう人間には)「表現に値する自己」なんてたいそうなもんはないし、てめーは「感動を届けたい」とか言ってるけど、感動するかどうかはこっちが決めるんだよ黙ってろこのタコすけ、みたいな気持ちになるわけです。で、こういう罵詈雑言が、もちろん歌ってる自分にも向かう。けど、すごい欠陥と欠損を抱えたまま生きてるせいで、音楽とか文章を書くことがやめられないんです、ごめんなさい、みたいな逡巡が自分にはある……。

あるいは、別の例。「どうして自分のことを理解してくれないんだ」という怒りを他人にぶつけてしまうようなひとにも、ぼくはとても醜悪な傲慢さを感じてしまう。というか、どうして自分のことを理解してくれるのが当然だと思っているのですか?そこに「自分には表現に値する価値のある自己がある!!」っていう自己表現さんと同じ傲慢さを感じ取ってしまうのだ、ぼくは。

もちろん、じゃあおまえがいま書いてるその自分語りはなんなんだよ、それは「自己表現」さんとなにが違うんだよ、と言われると「すみません…….」となってしまうのだけれど、冒頭にも言ったようにぼくはどうしても文章を書くことと音楽がやめられなくて、それはどちらかというとぼくの欠陥や欠落であって、そんなに褒められたものではない、とも思っているわけだ。一方で、たまになんかの偶然で、ぼくの欠落や欠陥を埋めるためのものが誰かの欠陥や欠落と深いところでひょいとつながっちゃうことがあって、もし偶然にそういうことがあるなら、こういう行為にも積極的な意味を見出せるかもしれない、という気持ちはあるにはある。いつもその点ですごく気持ちが引き裂かれている

だからたぶんぼくが激しく憎むのは、むしろ「無自覚さ」の部分なのだろう。その無邪気さがとても許せないのだ。こうして言語化してみるとなおのことこれはぼく側の欠陥であって、「自己表現」さんが悪いわけではない。けど、良い悪いと好き嫌いはまったく独立な軸として存在するわけで、そういう理由により、やはり「自己表現」さんは悪くないけどぼくはその無自覚さ(すくなくともぼくにそのように映る部分)に激しく嫌悪感を感じるのだ。

というわけで、ぼくの好き嫌いの話、ぼくの価値観の表明でした。とてもいい大人とは思えませんね。まあしかし、こればかりはしょうがない……

モンキーパッチよりも古式ゆかしいpatchのほうが良いシーンがあるという話

労働の現場においては、gemにオレオレパッチを当てたい、ということがまれにあります(あ、いい忘れてましたがこれからRubyの話をします)。もちろん、オレオレパッチは基本的には避けるべきものですが、そうも言っていられない深遠なる事情というのが、労働においてはある……。労働にはいろいろあります……。

さて、オレオレパッチの是非については一旦おいておいて、gemにオレオレパッチを当てたいとき、オープンクラスを利用してモンキーパッチを当てることが一般的には多いのではないでしょうか(繰り返しになりますがここではオレオレパッチの是非は問いません)。Railsを利用している場合、config/initializers以下にモンキーパッチのためのファイルを入れて、Rails起動時にgemの挙動を拡張、あるいは変更する、というような手段が多くの場合取られるのではないかと思います。

しかし、Railsを利用している労働の現場において、先日、Railsのbootstrap前、というかRackサーバーの読み込み前にgemにパッチを当てたい、という状況が発生しました。当然、Railsのbootstrap前なので、config/initializersの読み込みを待つわけにはいきません。

苦肉の策として、モンキーパッチを諦め、bundle install のあとに古式ゆかしいpatchコマンドを利用してライブラリ自体を実際に書き換えてしまうという暴力スクリプトを書いて物事を解決したのですが、その暴力の中で気づいたことがあります。それが、タイトルにもある、「モンキーパッチよりも古式ゆかしいpatchのほうが良いシーンがある」ということでした。

モンキーパッチの場合、パッチ対象のライブラリのバージョンが上がった場合などに、モンキーパッチの作者の意図しない挙動を引き起こすことがあります。別の言い方をすると、パッチ対象ライブラリのバージョンが上がった場合は内部が変わっていることがありうるため、本来はモンキーパッチ側も新しいバージョンに追従してメンテナンスしていく必要がある(たまたまモンキーパッチ側は書き換えなくてもうまく動く、という可能性は充分にある)わけですが、実際にライブラリの更新とモンキーパッチの更新の足並みを揃えるのは結構たいへんです。

一方、patchを当てるスクリプトの場合、パッチ対象となるライブラリのファイルパスをなんらかの形で埋め込んでおく必要があります。bundlerによってインストールされたgemは、バージョンごとに一意なファイルパスを持つし、仮に同じパスにインストールされたライブラリであっても、バージョンが代わりパッチ対象のファイルが書き換わっていたらpatchコマンドでのパッチに失敗します。これがなにを意味するかというと、patchコマンドによるパッチは、モンキーパッチと異なり、特定のバージョンのライブラリのみに対するパッチとして機能する、ということです。これは、そもそも危険なオレオレパッチの影響範囲を絞るという点でモンキーパッチよりも優れている部分があると言えるのではないでしょうか。

常にモンキーパッチよりもpatchコマンドによるパッチのほうが優れている、と主張する気はありませんが、「このversionのときだけパッチを当てたいなあ」みたいなときには、古式ゆかしいpatchコマンドによるパッチを検討してみるのも、ありなのではないか、というお話でした。逆にいうと、対象ライブラリのバージョンが上がっていってもこのパッチは当て続けたいんや!!みたいな場合はモンキーパッチのほうが有利かもしれません(が、それってかなり地獄への道を歩んでいる感じがする)。

危険なオレオレパッチは捨てやすい方法を選んだほうがいい場合がある、という話だと言い換えてもよいかもしれませんね。