「あなたの図書館は、あなたの子供のように、あなたにとって予期しない方向に進むことができます」：MobXの作成者とのインタビュー

人気のあるオープンソースライブラリの作成者の人生はどうですか？ もちろん、あなたの仕事の結果が世界中の多くの人々を助けることは素晴らしいことです。 しかし、あなたは自分の主な仕事でさえない仕事に圧倒されていると思いますか？ どのように対処しますか？ どれほど大胆に権限を委任できますか？



Michelle Weststrateはこのすべてを十分に認識しています。彼のMobXライブラリには 、githubに17,000以上の星があり、その貢献者の数は100をはるかに超えています。 そしてすぐにミシェルはHolyJSで話すためにロシアに来るので、会議のプログラム委員会のメンバー （Dmitry DmitryMakhnev MakhnevとEvgeny bunopus Kot）は彼に詳細に尋ねました：オープンソース全般、そして特にMobXについて、そして会議について。



ユージーン：あなたのことを知らない人のために、最初に自分自身について少し話してもらえますか？



「はい、もちろん。」 私の名前はミシェルウェストストラット（ほとんどの人にとって発音が難しすぎる）です。私はオランダ出身です。 ほとんどの場合、彼らはMobXまたはimmerでの私の仕事から私を知っています。 私はメンディックスで働いています。 多くのコンサルティング会社が使用するアプリケーション開発プラットフォームであるソフトウェアを作成するソフトウェアを作成しています。 多数の銀行保険会社および同様のシステムを自動化します。 私は技術的な側面をやっています-つまり、私が好きなことです。 そして約2年前、私はオープンソースの世界に参加しました。その瞬間から、ReactコミュニティとJSコミュニティの両方で活動していました。



ユージーン：メンディックスで正確に何をしていますか、テクニカルアドバイザーはいますか？



-はい。 そこにはいくつかの異なる役割があり、主な役割はテリッドです。 本質的に、これは私たちの「部族」の 1つに対する技術的解決策の選択に責任があることを意味します。 したがって、私はモバイルアプリケーションの環境である製品に取り組んでいます。 私たちは4つのチームと連携し、主にアーキテクチャと技術に関する適切な決定を下します。 さらに、私はまだプログラミング中です。 これは私の仕事の一部です。



もう1つは、オープンソースコミュニティへの参加です。 これは「双方向」のアクティビティです。 一方では、会議で共有したいクールな技術的なことを行っており、自分で話すか、同僚に話すことを勧めています。 反対に、会議への頻繁な訪問でも反対のことが言えます。あなたが私たちに役立つかもしれない何かを見つけたら、それを研究してスタックに含めます。



Eugene：「 OSS伝道」はTwitterの説明で言及されています。 それは何であり、なぜあなたにとってそれが重要なのですか？



-これが重要である最初の理由：開発をオープンソースに変換すると、時間をまったく節約できませんが、テストに大いに役立ち、品質が向上することがわかりました。 MobXのようなライブラリは非常に異なる条件で使用されるためです。 そして、この意味で、オープンソースには他の方法で入手するのが非常に難しいという利点があります。



そして2つ目：私たちの「低レベル」開発は会社を定義しないと信じているので、なぜそれらを共有しないのか。 つまり、企業は、技術自体ではなく、その技術に基づいて作られた製品によって、多少なりとも競争力を高められるということです。 そして誰もがコラボレーションの恩恵を受け、これにより開発全体が加速されます。



Eugene：時々、彼らは「非現金」オープンソースは実際には非常に高価な喜びだと言う。 Linuxのようなプロジェクトには、OracleやMicrosoftのような巨人からの莫大な資金が必要です。 そうですか？ 大規模なベンダーやお金がなくてもオープンソースコミュニティは存在できますか？



-特定の状況に依存すると思います。 そのように存在する可能性のある小さなライブラリがあります。 しかし、上記のLinuxカーネルやReact Nativeなどのプロジェクトは非常に複雑であり、非常に多くの人々がそれらに依存しているため、信頼できる財務モデルが必要です。 この場合、大きなスポンサーがいなければ非常に難しいでしょう。 しかし、私はこれが問題だとは思わない。 企業が責任を負うことを学ぶことは、企業なしで行うことを学ぶことよりも重要だと思います。



Eugene：たとえば、Facebookがあなたのところに来て「MobXを購入するか、MobXを後援して、開発が私たちのブランドの下に行くようにしましょう」と言ったら？



-まあ、実際、彼らはすでにスポンサーです！ 面白いですが、FacebookはOpen CollectiveでのMobXのスポンサーの1つです。 ある意味で、これはすでに起こっています。 私の意見では、オープンコレクティブはオープンソースの財政状態を改善する方法の良い例です。 請求書などの財政的に深刻なアプローチがあるため、企業は自分に合った方法で開発を後援することができます。



Mendixでは、実際、私はすでにMobXで作業するための報酬をほとんど受け取っているので、Facebookに完全に切り替えることに興味はありません。 他の人の興味を引く可能性があることは理解していますが、これには問題はありません。 私の意見では、ライセンスがオープンソースのままであれば、その製品がメインスポンサーのブランド下にあるという事実には何の問題もありません。 テレビでサッカーを見ているようなものです。誰もが試合を見ることができれば、Tシャツにどんなロゴが付いていてもそれほど違いはありません。



ユージーン：大企業が図書館を後援している場合、「私たちはそんなにお金を払っているので、それで私たちにこれをしてください」と言うことはできませんか？



「少なくともこれに遭遇したことがないので、問題になります。」 私が間違っていなければ、webpackはそのようなモデルを使用します。そこで機能の代金を支払うことは可能です。 そのため、多少のリスクはありますが、プロジェクトがその哲学に忠実であることを保証するのは、メンテナーの責任だと思います。 しかし、この哲学の範囲内では、十分な操作の余地がありそうです。 さらに、オープンソースでは、突然何かが完全にうまくいかない場合、少なくともフォークの可能性が残ります。



Eugene：オープンソースソフトウェアの開発は曲線のようなものです。最初に、誰も必要としないライブラリを作成し、次にそれを使い始め、それからgithubで何千もの星を獲得します。 オープンソースプロジェクトが一般的になると、多くの時間がかかり始めます。 MobXにいくら費やしますか？



-最近はあまりありません。 MobXは現在非常に安定しています。 もちろん、過去に多くを費やしました。 それは非常に異なっていました。 最初の数年間は週に数夜で、Twitterで小さな問題や質問に答えるだけの小さな瞬間があったと思います。 これらのささいなことは、時間の大きな投資としては感じられませんが、合計すると著しく増加すると思います。 ただし、測定するのは非常に困難です。 これが仕事用メールの確認方法です。問題を確認し、すぐに応答を送信します。



Eugene：あなたが開発者であり、ライブラリを作成し、人気が出てきて、ますます時間がかかる状況で生産性を上げるにはどうすればいいですか？ あなたは幸運です、あなたは勤務時間中にそれをする機会があります。 しかし、あなたがすでに仕事と趣味を持っていて、プロジェクトがより人気になったら？



-さて、私がMobXの仕事を始めたとき、それは私の自由な時間でもありました。プロジェクトが人気を博したとき、仕事の時間は追加されました。 しかし、いくつかのヒントがあります。 私が助けてくれたいくつかのルールがあることに気づきました。



最初：ドキュメントの関連性を監視します。 同じ質問を3、4回受け取った場合は、ドキュメントに回答を記録してください。 最終的に時間を節約できるからです。



第二に、どの問題を受け入れるかについて非常に気を配ること。 最初は、エラーが通知されるとすぐに、利用可能な説明に基づいて問題を再現しようとしています。 また、場合によってはこれが不可能であり、すでに時間がかかっていることがわかります。 そのため、サンドボックス内のコードであろうと、単体テストを伴うプルリクエストであろうと、問題から直接実行できるものを要求しています。 問題がどこにあるかを判断できるようにするもの-ライブラリ内またはユーザー側。 これは非常に重要です。時間を節約し、問題の作成者が時間を費やす準備ができていることを確認できるからです。 「バグを再現する時間がない」と言う人もいますが、「それなら、問題を解決する時間がない」と感じます。 結局のところ、人はおそらく自分のライブラリを使用する仕事に対して支払われているでしょう。それでは、なぜ自分の自由時間を彼の問題に投資すべきなのでしょうか？ 一般に、このような選択性は役立ちますが、すべての人を助けたいので、やや責任感が減ります。 しかし、「みんなを助ける」ことは単に非現実的であることがわかりました。



それでも、いくつかのライブラリを扱っているため、すべての問題に即座に対応するのではなく、あるライブラリから別のライブラリに「ジャンプ」します。各ライブラリで一度に数日間作業し、次のライブラリに進みます。 そして、私が今していることについて書いていただければ数分で答えることができますが、あなたの番がまだ届いていない場合は何日も答えられません。 これにより、コンテキストを切り替える頻度が少なくなります。



これらのヒントはすべて、ライブラリが人気を博し始めたときに役立ちます。



ユージーン：人気のあるライブラリの作成者が「再現できない、単体テストを書く」と答えたとき、これは人々に「彼はうぬぼれていて、助けたくない」と感じさせませんか？



-私はそのような効果に出くわしましたが、めったにありません。 通常、ユーザーは、メンテナーが非常に忙しく、高い確率で問題が彼の側にあることを理解していると思います。 Lodashフィルターを使用していて問題がある場合は、「誰もがLodashを使用しているため、おそらく何か間違っている可能性があります」という無意識の気持ちになるでしょう。 そのため、ほとんどの人は問題に注意する必要があることを理解しています。



Eugene：ライブラリが人気を博し、より多くの時間を必要とするとき、貢献者としてあなたの役割を共有し、コミュニティの他のメンバーに権利を与える価値はいくらですか？



-これは素晴らしいアイデアです。通常、1人からの複数の良いプルリクエスト（または大きい場合は1つのプルリクエスト）を見つけたらすぐに貢献者の権利を与えます。 私の意見では、これはうまく機能します。 たとえば、MobX状態ツリーでは、ほとんどの作業が私ではなく他の人によって行われています。 また、コードベースには、私よりも理解しやすい部分が他にもあります。すべてがその状態になったことは素晴らしいことです。 「コア」MobXの場合、これは必須ではありません。すべてがすでに落ち着いており、アルゴリズムは過去数年にわたって変更されていないため、サポート作業はわずかです。 しかし、MobX状態ツリーの場合、多くのユーザーライブラリを作成する人々を意図的に選択し、メンテナーの権利を付与しました。 結局のところ、日常業務でライブラリを積極的に使用すると、見逃したパターンや一般的な問題に出くわすことになります。 また、開発者のモチベーションと信頼感を与えてくれると思います。なぜなら、彼らは図書館が直面しているものを扱うのを助けることができるからです。



ユージーン：同時に、図書館が子供の頃に打ちのめされているという感覚はありませんか？ おそらく、他の人がどのようにそれを開発するかについてあなたは同意しないのでしょうか？



-時々それは少し起こります。 しかし、私はそれが正常だと思います。 あなたは子供たちと大きな類推をしました。彼らは時間とともに成長し、18歳になり、そしてあなたは彼らが自分の道を見つける時が来たので、彼らを手放す必要があります。 ある程度、オープンソースのライブラリも同様だと思います。 それらが成功すれば、より困難な状況に直面し始めます。 あなたは私が一般的に対処したくないケースに対処し始めます。 コードは、当初私が欲しかった美しく、クリーンでミニマルなコードではなくなります。 これは避けられません。



MobXにはこれの素晴らしい例があります。元々は、デコレータが非常にシンプルなTypeScriptのために書いたもので、その後、人々は完全に異なる実装があるBabelでそれを使い始めました。 そして、最終的に、コードベースの一部は、TypeScriptまたはBabelのどちらを使用しているかを判断しようとしているため、非常に見苦しくなります。 それはひどく聞こえ、ひどく見えます。 しかし、それは仕事の一部です。 それを愛する必要はありませんが、すべてがどこでもうまく機能することを確認する必要があります。 そして、この意味で、あなたの子供はあなたが考えていなかった方向に進むことができますが、最終的には人々がプロジェクトをうまく利用できることが重要であるため、これは正常です。



Eugene：開発は変化しており、10〜20年前よりもずっと簡単になっています。 これらの変更に関連してオープンソースの現在の状況についてどう思いますか、また将来に何を期待しますか？ 大企業はすべての熱狂的なファンになりますか？



-これは難しい質問です。 大きな変更があるかどうかはわかりません。 そして、一度に両方向に変化があります。 FacebookとMicrosoftには特に感銘を受けています。現在どのくらい開いているのか、サードパーティの開発者がどの程度貢献できるのか。 React Nativeは、作品の大部分がFacebookからのものではない、特に印象的な例です。 一方、孤独な人にとっては、オープンソースプロジェクトに参加したり、自分のプロジェクトを作成したりすることは、今のように簡単ではないでしょう。 ツールはより標準化されており、 CodeSandboxやGitpodなどの優れたオンラインIDEがあります 。 私はここ数週間Gitpodで仕事をしてきましたが、それは素晴らしいことです。ローカルで何もしなくてもプルリクエストをチェックできます。 ブラウザでDockerを実行するだけで開発できます。 そのため、変更が何になるかわかりません。



Eugene：8年前、私がC ++開発者だったとき、現在のようなオープンソースコミュニティはありませんでした。 そして今、WebとJavaScriptの世界では、オープンソースの開発がどんどん速くなっていることがわかります。 この成長は続くのでしょうか？



-運動は続くと思います。 私の意見では、理由の1つは次のとおりです。企業と開発者の両方が、オープンソースが開発または使用する人にとって有用であるだけでなく、従業員を見つけるのにも役立つことをますます理解しています。 その人のオープンソースへの参加を見ると、一日中インタビューするよりも、彼についてもっと理解できます。 彼が問題に答えるか、それらを開始する方法は多くを示しています。 開発者や企業は、この重要性をますます認識し始めていると思います。



ユージーン：それでは、オープンソースライブラリの開発がインタビューに役立つと思いますか？



-まさに。 あなたが会社であり、あなたのAPIに密接に結び付けられていないそのようなライブラリを持っているなら、人々が参加するようになるので、これは素晴らしいです-そして彼らはまさにあなたが必要なものかもしれません。 そして、寄稿者の1人を雇うと、参加しやすくなり、何が期待できるかをよりよく理解できます。 この理由だけで、多くの興味深いことが開かれたと思います。



Dmitry：オープンソース全般について話しましたが、具体的にはMobXに進みましょう。 最初にどのように、なぜ始めたのですか？



-いい質問です。 Mendixには、C＃で記述されたWindowsアプリケーションがあります。 数年前、私たちはそれをウェブに移植することを決め、使用するスタックを見つけ始めました。 Reactはまだ始まったばかりで、Angularはしばらく前から存在していましたが、Emberはかなり人気がありました。 そして、かなり早く、コンポーネントモデルと提案された抽象化レイヤーのために、Reactに恋をしました。



しかし、その後、パフォーマンスの問題があることがわかりました。Reactの場合でも、DOMを完全に更新するのは非常に高価であることがわかりました。 C＃では、モデルを絶えず更新してキャンバス全体を再描画しましたが、いずれも非常に高速に動作するため、誰も最適化を行いませんでした。したがって、「スマートな方法でレンダリングを行う」必要はありませんでした。 しかし、ここでDOMの場合、毎秒60回すべてを再描画することはできないことがわかりました。 そこで、効果的にそれを行う方法を考えました。 不変のアプローチについて考えましたが、この場合、いくつかの理由で適合しませんでした。 それらの1つは、使用したデータとそのレンダリング方法です。 同じ情報がさまざまな場所でレンダリングされました。 データを正規化することは非常に困難です。 そして第二に、あなたはまだあまりにも多くの詳細に対処しなければならなかったようです。 たとえば、レンダリングするデータのセレクターを作成する必要があります。



しかし、C＃コードと同じ単純なコードを記述し、前に「何かをレンダリング」し、これが将来どのように変化するかを気にしたくない場合はどうでしょうか。 コンポーネントに「それでは、データのこの部分をここから取得しますが、この部分をそこから取得して、何かをレンダリングできます」と言いたくない場合は、 現在どのテクノロジーが利用可能かを調査し始め、Knockout、Meteor、そして（少なくとも概念的には）Angularでも使用されているパラダイムにすぐに到達しました。 データの依存関係とコンポーネントの関係、またはいつレンダリングするかを意味しない場合。



特にアプリケーションが大きくなると、なぜ人々がそのようなアプローチを嫌うのかを理解し始めました。 そして、多くの場合、予測可能性と「デバッグ」の欠如について人々が懸念していることが多く、何かがあまりにも頻繁に、またはあまりにもまれに、または間違った順序で行われる可能性があることが判明しました。 そして、私たちはもっと良くできると決めました。 私たちは同じ目標を目指して努力することができますが、よりスマートな実装へのアプローチです。 そして、MobXが登場しました。 オブザーブとオブザーバブルの関係をキャプチャするだけでなく、依存関係グラフ全体を構築するため、すべてのオブザーバーが最も効率的な順序で実行されることを確認できます。 リアクティブプログラミングには、「グリッチ」という概念があります。したがって、ここではこれを行うことはできません。 一般的に、ここでは既存のものを取り上げましたが、より予測しやすいものにしようと試みました。



Dmitry：つまり、何らかのアプローチが好きなのに、既存のライブラリーでは十分でない場合、あなたはそれを受け入れてより良くすることができ、これは人気になりますか？



-はい、まさに！ それで私は最初に内部目的のためにそれを書き、それからReactEuropeに行きました。 2015年のようで、Fluxパターンについて多くの話がありました。 その後、フラックス戦争が激化した。 そして、私たちはすでに解決した問題に多くのエネルギーを注いでいると感じました。 « ». . , « Flux», - . .



: MobX , . , ?



— ! « MobX Lite». , MobX, 200 . , . . , . MobX. , — API, . , , API . , MobX 5 MobX 4 , Proxy .



: Proxy. - , . ?



— , , Proxy - , . . Chrome 8, , .



: . , jQuery -, , - . Redux MobX. ?



— , . , jQuery- . , JQuery , . - . jQuery React , , , . . , state definitions .

, , React UI. . , - UI .



: ? , ?



— , . , immutable values. , , immer — , immutable states JS. , state management. , , , . , , , GraphQL, , . …



: -, MobX?



— , , , . . : , to-do list . , , todo. , - , todo- , . . , .



: . . , - . , ?



— , . : , . — , , . , . Docker, . , , , . — « ». -, — , , . , , . — , , - . - -, , . , , . : -, , . .



: ( , ) , , Medium YouTube. ?



— , , — . , . — . , , , … . . , . . , . , , . , , , , - . , . , (, , ) — . , , . .



: . — ?



— . , MobX. , . MobX.

HolyJS 2018 Moscow , 24-25 . state management. .