Wie ist das Leben der Schöpfer populärer Open-Source-Bibliotheken? Natürlich ist es schön, wenn das Ergebnis Ihrer Arbeit vielen Menschen auf der ganzen Welt hilft. Aber sind Sie mit Aufgaben überfordert, die nicht einmal Ihre Hauptaufgabe sind? Wie gehe ich damit um? Wie mutig kann man Autorität delegieren?
Michelle Weststrate ist sich dessen bewusst: Seine
MobX- Bibliothek
hat mehr als 17.000 Sterne auf dem Github, die Anzahl ihrer Mitwirkenden hat längst einhundert überschritten. Und bald wird Michelle nach Russland kommen, um bei HolyJS zu sprechen, also fragten ihn die Leute vom Programmkomitee der Konferenz (Dmitry
DmitryMakhnev Makhnev und Evgeny
bunopus Kot) ausführlich: über Open Source im Allgemeinen und speziell über MobX und über die Konferenzen.
Eugene: Kannst du zuerst ein wenig über dich erzählen für diejenigen, die dich nicht kennen?- Ja natürlich. Mein Name ist Michelle Weststrate (was für die meisten Leute zu schwer auszusprechen ist), ich komme aus Holland. Meistens kennen sie mich aus meiner Arbeit an MobX oder an
immer . Ich arbeite für Mendix. Wir machen Software, die Software macht: eine Anwendungsentwicklungsplattform, die viele Beratungsunternehmen nutzen. Wir automatisieren eine Vielzahl von Bankenversicherungsunternehmen und ähnlichen Systemen. Ich mache die technische Seite - das ist es, was ich mag. Und vor ungefähr zwei Jahren habe ich mich in der Open-Source-Welt engagiert. Von diesem Moment an war ich sowohl in der React-Community als auch in der JS-Community im Allgemeinen aktiv.
Eugene: Was genau machen Sie in Mendix, gibt es technische Berater?- Ja. Ich habe dort verschiedene Rollen, und die Hauptrolle ist Tehlid. Im Wesentlichen bedeutet dies, dass ich für die Auswahl technischer Lösungen für einen unserer
„Stämme“ verantwortlich bin. Daher arbeite ich an einem Produkt, das eine Umgebung für mobile Anwendungen darstellt. Wir arbeiten mit vier Teams daran, und hauptsächlich treffe ich die richtigen architektonischen und technologischen Entscheidungen. Außerdem programmiere ich noch. Dies ist ein Teil meiner Arbeit.
Und das andere ist die Teilnahme an der Open Source Community. Dies ist eine Zwei-Wege-Aktivität. Einerseits machen wir coole technische Dinge, die ich auf Konferenzen teilen möchte, und ich spreche alleine oder ermutige Kollegen zum Sprechen. Auf der anderen Seite ist das Gegenteil bei häufigen Besuchen von Konferenzen gut: Sie finden etwas, das für uns nützlich sein kann, dann studieren wir es und nehmen es in unseren Stapel auf.
Eugene: OSS Evangelism wird in Ihrer Twitter-Beschreibung erwähnt. Was ist das und warum ist es dir wichtig?- Der erste Grund, warum dies wichtig ist: Ich habe festgestellt, dass Sie bei der Übersetzung Ihrer Entwicklung in Open Source keine Zeit sparen, aber beim Testen viel helfen und die Qualität verbessern. Weil eine Bibliothek wie MobX unter sehr unterschiedlichen Bedingungen verwendet wird. Und ich denke, dass Open Source in diesem Sinne einen solchen Vorteil bietet, dass es sehr schwierig ist, auf andere Weise zu erhalten.
Und zweitens: Ich glaube, dass unsere „Low-Level“ -Entwicklungen das Unternehmen nicht definieren. Warum also nicht teilen? Ich meine, ein Unternehmen wird durch ein Produkt, das auf der Grundlage seiner Technologien hergestellt wird, mehr oder weniger wettbewerbsfähig - und nicht durch diese Technologien selbst. Und jeder profitiert von der Zusammenarbeit, wodurch sich die Entwicklung insgesamt beschleunigen kann.
Eugene: Manchmal sagen sie, dass Open Source „bargeldlos“ tatsächlich ein sehr teures Vergnügen ist. Projekte wie Linux erfordern eine Menge Geld von Giganten wie Oracle und Microsoft. Ist das so? Kann eine Open Source Community ohne große Anbieter und Geld existieren?- Ich denke, es hängt von der spezifischen Situation ab. Es gibt kleine Bibliotheken, die so existieren könnten. Projekte wie der oben erwähnte Linux-Kernel oder React Native sind jedoch so komplex und so viele Menschen sind von ihnen abhängig, dass sie ein zuverlässiges Finanzmodell benötigen. In diesem Fall wäre es ohne große Sponsoren sehr schwierig. Aber ich denke nicht, dass dies ein Problem ist. Ich denke, es ist wichtiger, dass Unternehmen lernen, Verantwortung zu übernehmen, als dass wir lernen, ohne sie auszukommen.
Eugene: Wenn zum Beispiel Facebook zu Ihnen kommt und sagt: "Kaufen wir MobX oder sponsern wir es, damit die Entwicklung unter unsere Marke fällt."- Eigentlich sponsern sie schon! Es ist lustig, aber Facebook ist einer der Sponsoren von MobX
bei Open Collective . In gewisser Weise ist dies also bereits geschehen. Meiner Meinung nach ist Open Collective ein gutes Beispiel dafür, wie wir die Finanzlage von Open Source verbessern können. Es ermöglicht Unternehmen, die Entwicklung auf eine Weise zu fördern, die zu ihnen passt, da es einen finanziell seriösen Ansatz mit Rechnungen und dergleichen gibt.
Bei Mendix werde ich im Wesentlichen viel für die Arbeit an MobX bezahlt, daher bin ich nicht daran interessiert, vollständig auf Facebook umzusteigen. Ich verstehe, dass dies möglicherweise jemand anderen interessiert, aber ich sehe darin kein Problem. Wenn die Lizenz Open Source bleibt, ist meiner Meinung nach nichts falsch daran, dass das Produkt unter die Marke des Hauptsponsors fällt. Es ist wie Fußball im Fernsehen: Wenn jeder das Spiel sehen kann, gibt es keinen großen Unterschied, welches Logo auf T-Shirts abgebildet ist.
Eugene: Wenn eine große Firma die Bibliothek sponsert, kann sie dann nicht sagen "Da wir so viel bezahlen, dann tun Sie uns das bitte darin"?"Ich bin zumindest nicht darauf gestoßen, so dass es zu einem Problem wird." Wenn ich mich nicht irre, verwendet Webpack ein solches Modell, ist es möglich, für Funktionen dort zu bezahlen. Es besteht also ein gewisses Risiko, aber ich denke, es liegt in der Verantwortung der Betreuer, sicherzustellen, dass das Projekt seiner Philosophie treu bleibt. Innerhalb dieser Philosophie gibt es jedoch wahrscheinlich viel Handlungsspielraum. Und außerdem bleibt in Open Source, wenn plötzlich etwas völlig schief geht, zumindest die Möglichkeit einer Gabelung bestehen.
Eugene: Die Entwicklung von Open-Source-Software ist wie eine Kurve: Zuerst erstellen Sie eine Bibliothek, die niemand sonst benötigt, dann beginnen die Leute damit, dann erhält sie Tausende von Sternen auf einem Github und so weiter. Wenn ein Open Source-Projekt populär wird, kann es viel Zeit in Anspruch nehmen. Wie viel gibst du für MobX aus?- In letzter Zeit nicht sehr viel. MobX ist momentan ziemlich stabil. Ich habe natürlich viel in der Vergangenheit verbracht. Es war ganz anders. Ich denke, in den ersten Jahren waren es ein paar Nächte in der Woche, und es gab viele weitere kleine Momente, in denen Sie einfach kleinere Probleme oder Fragen auf Twitter beantworteten. Diese kleinen Dinge werden nicht als bedeutende Zeitinvestition empfunden, aber ich denke, dass sie insgesamt erheblich dazu beitragen. Es ist jedoch sehr schwer zu messen. So überprüfen Sie die Arbeitspost - Sie überprüfen das Problem und senden schnell eine Antwort.
Eugene: Wie kann man in einer Situation produktiv sein, in der man Entwickler ist, eine Bibliothek erstellt hat, diese populär geworden ist und immer mehr Zeit benötigt? Sie haben Glück, Sie haben die Möglichkeit, dies während der Arbeitszeit zu tun. Aber wenn Sie bereits einen Job und ein Hobby haben und das Projekt immer beliebter wird?- Nun, als ich anfing an MobX zu arbeiten, war es auch nur in meiner Freizeit, die Arbeit wurde hinzugefügt, als das Projekt Popularität erlangte. Aber ich habe ein paar Tipps. Mir ist aufgefallen, dass es mehrere Regeln gibt, die mir geholfen haben.
Erstens: Verfolgen Sie die Relevanz der Dokumentation. Wenn Sie drei- oder viermal dieselbe Frage erhalten haben, notieren Sie die Antwort in der Dokumentation. Weil es Ihnen letztendlich Zeit spart.
Zweitens: Seien Sie sehr wählerisch, welches Problem Sie akzeptieren. Sobald Sie über einen Fehler informiert werden, versuchen Sie zu Beginn, das Problem anhand der verfügbaren Beschreibung zu reproduzieren. In einigen Fällen stellen Sie fest, dass dies unmöglich ist und die Zeit bereits aufgewendet wurde. Daher fordere ich jetzt etwas an, das ich direkt aus dem Problem ausführen kann, sei es ein Code in der Sandbox oder eine Pull-Anfrage mit Unit-Tests. So kann ich feststellen, wo das Problem liegt - in der Bibliothek oder auf der Benutzerseite. Dies ist sehr wichtig, da ich so Zeit sparen und sicherstellen kann, dass die Autorin der Ausgabe bereit ist, ihre Zeit zu investieren. Einige sagen: "Ich habe keine Zeit, um den Fehler zu reproduzieren", und ich habe das Gefühl: "Nun, dann habe ich keine Zeit, um Ihr Problem zu lösen." Schließlich wird eine Person wahrscheinlich für die Arbeit bezahlt, in der sie meine Bibliothek nutzt - warum sollte ich dann meine Freizeit in sein Problem investieren? Im Allgemeinen hilft eine solche Selektivität, obwohl Sie sich dadurch etwas weniger verantwortlich fühlen, weil Sie allen überhaupt helfen möchten. Aber ich fand, dass es einfach unrealistisch ist, „allen zu helfen“.
Da ich mich jedoch mit mehreren Bibliotheken befasse, reagiere ich nicht sofort auf alle Probleme, sondern „springe“ von einer Bibliothek zur nächsten: Ich arbeite mehrere Tage am Stück daran und gehe dann zur nächsten über. Und ich kann Ihnen in wenigen Minuten antworten, wenn Sie über das geschrieben haben, was ich gerade mache, aber ich kann tagelang nicht antworten, wenn Sie noch nicht an der Reihe sind. Dies hilft mir, die Kontexte seltener zu wechseln.
All diese Tipps helfen, wenn Ihre Bibliothek an Popularität gewinnt.
Eugene: Wenn der Schöpfer der beliebten Bibliothek antwortet "Ich kann nicht reproduzieren, schreibe einen Komponententest", fühlen sich die Leute dann nicht "eingebildet und wollen nicht helfen"?- Ich bin auf einen solchen Effekt gestoßen, aber sehr selten. Ich denke, dass der Benutzer normalerweise versteht, dass die Betreuer ziemlich beschäftigt sind und dass das Problem mit hoher Wahrscheinlichkeit auf seiner Seite liegt. Ich denke, wenn Sie den Lodash-Filter verwenden und ein Problem haben, entsteht das unwillkürliche Gefühl, dass "wahrscheinlich etwas mit mir nicht stimmt, weil jeder Lodash verwendet". Daher verstehen die meisten Menschen, dass sie in Angelegenheiten vorsichtig sein sollten.
Eugene: Wenn die Bibliothek populär wird und mehr Zeit benötigt, wie viel lohnt es sich, Ihre Rolle als Mitwirkender zu teilen und anderen Mitgliedern der Community Rechte zu gewähren?- Dies ist eine großartige Idee. Ich gebe normalerweise die Rechte eines Mitwirkenden, sobald ich mehrere gute Pull-Anfragen von einer Person sehe (oder sogar eine Pull-Anfrage, wenn sie groß ist). Meiner Meinung nach funktioniert das super. Zum Beispiel wird im MobX-Statusbaum der größte Teil der Arbeit jetzt von anderen Personen erledigt, nicht von mir. Und es gibt andere Teile der Codebasis, die die Leute besser verstehen als ich, und es ist großartig, dass alles in diesen Zustand gekommen ist. Für den „Kern“ MobX ist dies nicht erforderlich, da sich dort bereits alles eingelebt hat und sich die Algorithmen in den letzten Jahren nicht geändert haben, sodass der Supportaufwand gering ist. Aber im Fall von MobX-state-tree habe ich bewusst diejenigen Personen ausgewählt, die viele Benutzerbibliotheken erstellen, und ihnen die Rechte des Betreuers eingeräumt. Wenn Sie die Bibliothek in Ihrer täglichen Arbeit aktiv nutzen, werden Sie schließlich auf Muster oder häufige Probleme stoßen, die ich übersehen habe. Und ich denke, es gibt Entwicklern Motivation und ein Gefühl der Zuverlässigkeit - weil sie der Bibliothek helfen können, mit dem zu arbeiten, mit dem sie konfrontiert sind.
Eugene: Gleichzeitig gibt es kein Gefühl, dass die Bibliothek als Kind abgeschlagen wird? Vielleicht sind Sie sich nicht einig, wie genau andere Leute es entwickeln?- Manchmal passiert es ein bisschen. Aber ich denke das ist normal. Sie haben eine großartige Analogie mit Kindern gemacht: Mit der Zeit werden sie erwachsen, sie werden 18, und dann müssen Sie sie gehen lassen, weil es Zeit für sie ist, ihren eigenen Weg zu finden. Ich denke zum Teil auch an Open-Source-Bibliotheken. Wenn sie erfolgreich sind, werden Sie mit schwierigeren Situationen konfrontiert. Sie beginnen sich mit Fällen zu befassen, mit denen ich mich im Allgemeinen nicht befassen möchte. Der Code wird nicht mehr der schöne, saubere und minimalistische Code sein, den ich ursprünglich wollte. Das ist unvermeidlich.
MobX hat ein großartiges Beispiel dafür: Ich habe ursprünglich für TypeScript geschrieben, wo Dekorateure sehr einfach sind, und dann haben die Leute angefangen, es mit Babel zu verwenden, wo es eine völlig andere Implementierung gibt. Und am Ende sind einige Teile der Codebasis sehr unansehnlich, weil sie versuchen festzustellen, ob Sie TypeScript oder Babel verwenden. Es klingt schrecklich und es sieht schrecklich aus. Aber das gehört zum Job. Es ist nicht notwendig, es zu lieben, aber es ist notwendig sicherzustellen, dass überall alles gut funktioniert. In diesem Sinne kann Ihr Kind in eine Richtung gehen, an die Sie nicht gedacht haben, aber das ist normal, denn letztendlich ist es wichtig, dass die Menschen das Projekt erfolgreich nutzen können.
Eugene: Die Entwicklung ändert sich, vieles wird einfacher als vor 10 bis 20 Jahren. Was halten Sie von der aktuellen Open Source-Situation im Zusammenhang mit diesen Änderungen und was erwarten Sie von der Zukunft? Werden große Unternehmen alle oder umgekehrt Enthusiasten befeuern?- Schwere Frage. Ich bin mir nicht sicher, ob es große Veränderungen geben wird. Und es gibt Änderungen in beide Richtungen gleichzeitig. Ich bin besonders beeindruckt von Facebook und Microsoft - wie viel sie jetzt öffnen und inwieweit sie es Drittentwicklern ermöglichen, einen Beitrag zu leisten. React Native ist ein besonders eindrucksvolles Beispiel, bei dem ein großer Teil der Arbeit nicht von Facebook stammt. Andererseits war es für einen Einzelgänger wahrscheinlich noch nie so einfach, an einem Open-Source-Projekt teilzunehmen oder ein eigenes zu erstellen, wie es jetzt ist. Die Tools werden immer standardisierter. Wir haben großartige Online-IDEs wie
CodeSandbox und
Gitpod . Ich habe in den letzten Wochen mit Gitpod gearbeitet, und das ist großartig: Ich kann Pull-Anfragen überprüfen, ohne etwas vor Ort zu tun. Sie können Docker einfach in einem Browser ausführen und dort entwickeln. Ich weiß also nicht, wie sich das ändern wird.
Eugene: Vor acht Jahren, als ich C ++ - Entwickler war, gab es keine Open Source-Community wie heute. Und jetzt in der Welt des Web und von JavaScript sehe ich, dass sich Open Source immer schneller entwickelt. Wird sich dieses Wachstum fortsetzen?- Ich denke, die Bewegung wird fortgesetzt. Einer der Gründe ist meiner Meinung nach folgender: Sowohl Unternehmen als auch Entwickler verstehen zunehmend, dass Open Source nicht nur für diejenigen nützlich ist, die es entwickeln oder nutzen, sondern auch dazu beiträgt, Mitarbeiter zu finden. Wenn Sie sich die Teilnahme einer Person an Open Source ansehen, können Sie mehr über sie verstehen, als wenn Sie sie den ganzen Tag interviewen. Die Art und Weise, wie er das Problem beantwortet oder startet, zeigt viel. Ich denke, Entwickler und Unternehmen werden sich zunehmend der Bedeutung bewusst.
Eugene: Sie denken also, dass die Entwicklung einer Open Source-Bibliothek bei einem Interview helfen kann?- Genau. Wenn Sie ein Unternehmen sind und über solche Bibliotheken verfügen, die nicht eng mit Ihrer API verbunden sind, ist dies großartig, da die Teilnehmer teilnehmen werden - und sich möglicherweise als genau das herausstellen, was Sie benötigen. Wenn Sie einen Ihrer Mitarbeiter einstellen, können diese leichter beitreten und Sie verstehen besser, was Sie erwartet. Ich denke, allein aus diesem Grund wurden viele interessante Dinge eröffnet.
Dmitry: Wir haben allgemein über Open Source gesprochen. Gehen wir speziell zu MobX über. Wie und warum hast du damit angefangen?- Gute Frage. Wir bei Mendix haben schon lange eine Windows-Anwendung in C # geschrieben. Vor einigen Jahren haben wir beschlossen, es ins Web zu portieren und herauszufinden, welcher Stack verwendet werden soll. Die Reaktion hatte gerade erst begonnen, Angular war schon eine Weile da, Ember war ziemlich beliebt. Und ziemlich schnell haben wir uns aufgrund seines Komponentenmodells und der vorgeschlagenen Abstraktionsebene in React verliebt.
Aber dann stellten wir fest, dass wir ein Leistungsproblem hatten. Es stellte sich heraus, dass die vollständige Aktualisierung des DOM selbst im Fall von React ziemlich teuer war. In C # haben wir das Modell ständig aktualisiert und die gesamte Leinwand neu gezeichnet, und niemand hat etwas optimiert, da ohnehin alles sehr schnell funktionierte, sodass es nicht erforderlich war, „das Rendering auf intelligente Weise anzugehen“. Hier haben wir jedoch festgestellt, dass Sie im Fall des DOM nicht einfach alles 60 Mal pro Sekunde neu zeichnen können. Also haben wir darüber nachgedacht, wie wir es effektiv machen können. Wir haben über den unveränderlichen Ansatz nachgedacht, aber in unserem Fall passte er aus mehreren Gründen nicht. Eine davon ist, mit welchen Daten wir gearbeitet haben und wie sie gerendert wurden. Die gleichen Informationen wurden an verschiedenen Stellen wiedergegeben. Unsere Daten sind sehr schwer zu normalisieren. Und zweitens schien es, dass Sie sich immer noch mit zu vielen Details befassen mussten. Beispielsweise müssten Sie Selektoren für die Daten schreiben, die Sie rendern.
Aber was ist, wenn Sie denselben einfachen Code wie unseren C # -Code schreiben, vorher "etwas rendern" und sich nicht darum kümmern möchten, wie sich dies in Zukunft ändern wird? Wenn Sie den Komponenten nicht sagen möchten: "Nehmen Sie also diesen Teil der Daten von hier, aber diesen von dort, und dann können Sie etwas rendern." Wir begannen zu untersuchen, welche Technologien derzeit verfügbar sind, und kamen schnell zu dem Paradigma, das in Knockout, Meteor und (zumindest konzeptionell) sogar in Angular verwendet wurde. Wo Sie weder die Beziehung zwischen Datenabhängigkeiten und Komponenten meinen, noch was wann gerendert werden soll.
Ich begann zu verstehen, warum Menschen solche Ansätze oft hassen, besonders wenn die Anwendung wächst. Und es stellte sich heraus, dass die Menschen häufig über die mangelnde Vorhersehbarkeit und das „Debuggen“ besorgt sind, dass etwas zu oft oder zu selten oder in der falschen Reihenfolge getan werden kann. Und ich habe beschlossen, dass wir es besser machen können. Wir können das gleiche Ziel anstreben, aber einen intelligenteren Ansatz für die Umsetzung. Und so erschien MobX. Es erfasst nicht nur die Beziehung zwischen Observaten und Observablen, sondern erstellt ein vollständiges Abhängigkeitsdiagramm, sodass Sie sicher sein können, dass alle Beobachter in der effizientesten Reihenfolge ausgeführt werden. In der reaktiven Programmierung gibt es das Konzept der „Panne“ - und so kann dies hier nicht auftreten. Im Allgemeinen wurde hier eine vorhandene aufgenommen, jedoch mit dem Versuch, sie vorhersehbarer zu machen.
Dmitry: Das heißt, wenn ich einen Ansatz mag, aber die vorhandenen Bibliotheken nicht gut genug sind, können Sie es einfach besser machen, und das kann populär werden?- Ja genau! Also schrieb ich es zunächst für unsere internen Zwecke und ging dann zu ReactEurope. Es scheint 2015 zu sein, und es wurde viel über Flussmuster gesprochen. Dann tobten die Flux Wars. Und ich hatte das Gefühl, dass die Leute viel Energie in ein Problem stecken, das wir bereits gelöst haben. « ». . , « 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. ?— , , — . , . — . , , , … . . , . . , . , , . , , , , - . , . , (, , ) — . , , . .
Eugene: Großartiger Rat. Sie werden zum ersten Mal in Russland sein - was erwarten Sie von Moskau und von der Konferenz?- Ich möchte auf jeden Fall Moskau anschauen und ich werde definitiv schockiert sein. Und mir ist auch aufgefallen, dass es in Russland viele MobX-Benutzer gibt. Ich sehe das auf dem Tracker, auf Commits. Daher hoffe ich, viele MobX-Benutzer auf der Konferenz zu treffen.Sie können Michelle sehen und ihm Fragen auf der HolyJS 2018 in Moskau stellen , die vom 24. bis 25. November stattfinden wird . Dort wird er mehr über Staatsmanagement sprechen. Eine Beschreibung der Konferenzberichte finden Sie auf der Website .