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コマンドによるパッチを検討してみるのも、ありなのではないか、というお話でした。逆にいうと、対象ライブラリのバージョンが上がっていってもこのパッチは当て続けたいんや!!みたいな場合はモンキーパッチのほうが有利かもしれません(が、それってかなり地獄への道を歩んでいる感じがする)。

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

webフロントエンドからwebAPIを呼び出すのをwrapするアレの名前

twitterに書いたやつ再掲+加筆。

Webフロントエンド、というかSPAの設計で、単なるwebAPIラッパーに対して「Repository」と名付けるケースが散見されるけど、ぼくはあれあまり好きではないです。というのも、Repositoryという名前がついてると、集約的なもの、それが言い過ぎならいわゆるEntity、それも言い過ぎならひとかたまりのデータを保存、取得するだけの責務のように思えるからです。けど、実際の「Repository」を見てみると、取得されるのは画面の仕様にベッタリなJSONだったり、更新系としてもなんちゃらidとパラメータを渡すようなIFになってることが多いですよね。画面の仕様にベッタリなJSONが返ってくるようになってたり、idとパラメータ渡すだけだったりするのは、多くの場合考えることが少なくて済むし通信量も減る良いプラクティスだと思うので、それ自体は問題ではないと思っています。ただ、Repository な責務でないものにRepositoryという名前をつけるのがあまり好きではない、という話です。

とはいえ、これは「好き嫌い」の問題なので、「このプロジェクトではそういう名前なんだよ」というのがチーム内で合意が取れてればそれはそれで、とも思います。ただ誤解は産みやすいからそこんとこコミュニケーションしっかりとりたいですね。

ちなみに、じゃあぼくがそれをなんて名前にするかですが、ぼくはよく「Gateway」という名前を使います。サーバーはフロントのSPAと異なるシステムなので、その境界をまたいだ処理を行う窓口だよ、という意味でのGateway

以上がtwitterでしゃべったことです。以下は補足です。

いま扱ってるものが(たとえば)SessionStorageに保存しているものなのかネットワーク越しにあるシステムに保存されているものなのかを意識したくない、だからRepositoryという名前を使うんだ、という話もあると思うのですが、多くの場合APIサーバーは「たんにデータの出し入れ」じゃなくて、たとえば参照系のAPIなら集計をしたり、更新系のAPIなら複雑なロジックを実行したあとになにかを保存したり、それどころか別のシステムを呼び出して結果として誰かに通知が飛んだりなどが行われるかと思います。それと同等のことをローカルでできるでしょうか?もしできないとしたら、ネットワーク越しにあるシステムの呼び出しとローカルのストレージの読み書きを意識しない、なんてこと意味があるのでしょうか?また、仮にローカルでもおなじこと(集計やら複雑なロジックを伴ったデータの更新)ができるとして、その場合それって「Repository」なのでしょうか。Repositoryと言うには賢すぎる気がしますね。

もちろん、APIが完全にリソース志向で、ロジックはほとんどローカルにあります、みたいなアプリケーションなのであれば、そのAPIのwrapperをRepositoryとして扱うことが可能でしょう。たとえばあまりユーザー同士のインタラクションがなくて、クラウドは単なるデータ置き場である、みたいなアプリケーションの場合とかは、そういうやり方が適するかもしれません。また、ユーザごとの設定値のようなものについては、たしかにローカルに保存しているのかネットワーク越しのシステムに保存しているのかは意識したくないかもしれませんね。こういったものについては、自信をもってRepositoryとすればいいと思います。

そう考えると、もしかするとひとつのSPAの中で、このAPI呼び出しはGatewayという名前、あのAPI呼び出しはRepositoryという名前、ということが起こるかもしれません。これは良いことでしょうか悪いことでしょうか。ぼくは「良いこと」だと思います。一貫性がない? けどそもそも、実装(それがローカル保存なのかネットワーク越しのシステム保存なのか)を意識したくないから、意識しなくていい名前をつけよう、という話だったはずです。そう考えると、「別のシステムに対する処理の移譲(その別のシステムがどこにあるかは意識しない)」についてはGateway、「データの保存と読み込み」についてはRepositoryを使う、というのはかなり筋が良いようにぼくには思えます。

というわけで、「webフロントエンドからwebAPIを呼び出すのをwrapするアレの名前」について考えてみました。みなさんのご意見もぜひ聞かせてください。

知識問題と思考問題

最近、高校の先生が「知識問題」「思考問題」という言葉を使ってらっしゃるのを聞いて、「なるほど、面白い分類だな」と思った。それ以来「知識問題と思考問題」という視点で物事を眺めるのが自分の中でブームとなっている。

もちろん、知識問題と思考問題というのはきれいにスパッとわかれるものではなく、グラデーション状になっていると思う。この問題はやや思考問題よりだね、とか、かなり知識問題に振れてるね、とか、かなり思考問題寄りだね、とか。

ソフトウェアの設計について考えてみると、じつは、ソフトウェアをどのようなレイヤーに分割するか、というような話はかなり知識問題寄りに見える。この問題には先人の知恵がたくさんあって、それらが「傾向と対策」として未知の問題にも流用しやすい。

一方で、レイヤーの内部をどのような責務でどのようクラス、コンポーネントに分割していくのかというのは、かなり思考問題よりに見える。このとき、設計原則などは役にたつが、それは「検算」的な部分で役に立つ感じで、問題とがっぷり四つに組んで頭に汗をかいて設計しなければならないように感じる。

これがマイクロサービシーズになってくると、どのようなマイクロサービスにどのような責務を負わせ、どのように分割するのかがかなり思考問題寄りで、サービス間の連携についてはけっこう知識問題に寄っているように思えるのがおもしろいところだ。

そんな視点で眺めてみると、去年ぼくがbuildersconで話した開発現場で役立たせるための設計原則とパターンという発表は、設計原則やパターンは、このように活用すると思考問題を解く際の武器にできるよ、という話をしているというように理解ができそうだ。一方、今年のbuilderscon に応募している(たのむ!採択されてくれ!)、Ruby (off|with) the Railsという発表は、かなり知識問題よりの領域を扱っていると思う。まあこの記事で言いたかったのはそういう予告です……。

ところで、知識問題を解くための武器とも思考問題を解くための武器だったら、なんだか思考問題を解くための武器のほうが「ありがたがられ」そうな気がするけど、これらに優劣はない、とぼくは思っている。思考問題を解くための武器は錆びつくのが遅いけど、一方で「すぐに役立てる」のが難しい。知識問題を解くための武器はすぐに陳腐化するけど、明日からすぐに役立てやすい。これらは優劣ではなく、性質の違いだ。

自分が問題に向き合ってる時に、いま知識問題に向かい合っているのか思考問題に向き合っているのかは少し意識してみると、自分がいま向き合うべき問題なのかを考えられたりとか、「知識問題だけど知識が足りないから、すぐ使えるやつを仕入れてこよーっと」みたいなムーブができたりとかできて良いかもしれない。いや、しかしこれは「知識問題だとわかるためには知識が必要」という問題があるか?

あー、でも、少なくとも、ジュニアエンジニアが知識問題に戸惑ってたらシュッと知識をインストールしてあげる、思考問題に戸惑ってたら本人の気づきをナビゲートしてあげる、みたいなことはできそうですよね。知識問題と思考問題という視点はけっこう便利であるなあと思います。

なんかとりとめない話になっちゃったけどブログだからいいよね。

rubyのString#splitのおもしろ挙動

RubyのString#splitは、下記のようなおもしろ挙動を持っている

"  a\nb \t c   \rd  ".split(' ') # => ["a", "b", "c", "d"]

これは(とうぜんのことながら)ちゃんとDocumentedである

docs.ruby-lang.org

1 バイトの空白文字 ' '
先頭と末尾の空白を除いたうえで、空白文字列で分割する。

便利なんだけど知らないでいると意図せぬバグを埋め込んでしまうかもしれないので、知っておいて損はないかもしれない(ぼくは今日知った)