Apa kehidupan pencipta perpustakaan open source populer? Tentu saja, itu menyenangkan ketika hasil pekerjaan Anda membantu banyak orang di seluruh dunia. Tetapi apakah Anda menemukan diri Anda kewalahan dengan tugas-tugas yang bahkan bukan pekerjaan utama Anda? Bagaimana cara mengatasinya? Bagaimana berani seseorang dapat mendelegasikan wewenang?
Michelle Weststrate sangat menyadari semua ini: perpustakaan
MobX- nya
memiliki lebih dari 17.000 bintang di github, jumlah kontributornya telah lama melebihi seratus. Dan segera Michelle akan datang ke Rusia untuk berbicara di HolyJS, jadi orang-orang dari komite program konferensi (Dmitry
DmitryMakhnev Makhnev dan Evgeny
bunopus Kot) bertanya kepadanya secara terperinci: tentang sumber terbuka secara umum, dan khususnya tentang MobX, dan tentang konferensi.
Eugene: Bisakah Anda ceritakan sedikit tentang diri Anda untuk mereka yang tidak mengenal Anda?"Ya, tentu saja." Nama saya Michelle Weststrate (yang terlalu sulit untuk diucapkan oleh kebanyakan orang), saya dari Holland. Paling sering mereka mengenal saya dari pekerjaan saya di MobX atau di
immer . Saya bekerja untuk Mendix. Kami membuat perangkat lunak yang menghasilkan perangkat lunak: platform pengembangan aplikasi yang digunakan oleh banyak perusahaan konsultan. Kami mengotomatisasi sejumlah besar perusahaan asuransi perbankan dan sistem serupa. Saya melakukan sisi teknis - yaitu, apa yang saya suka. Dan sekitar dua tahun yang lalu, saya terlibat dalam dunia open source, sejak saat itu saya aktif di komunitas React dan di komunitas JS pada umumnya.
Eugene: Apa yang sebenarnya Anda lakukan di Mendix, apakah Anda ada penasihat teknis?- Ya. Saya memiliki beberapa peran berbeda di sana, dan yang utama adalah Tehlid. Intinya, ini berarti saya bertanggung jawab atas pemilihan solusi teknis untuk salah satu
“suku” kami . Jadi, saya sedang mengerjakan produk yang merupakan lingkungan untuk aplikasi seluler. Kami mengerjakannya dengan empat tim, dan terutama saya membuat keputusan arsitektur dan teknologi yang tepat. Selain itu, saya masih pemrograman. Ini adalah salah satu bagian dari pekerjaan saya.
Dan yang lainnya adalah partisipasi dalam komunitas open source. Ini adalah aktivitas "dua arah". Di satu sisi, kami melakukan hal-hal teknis keren yang ingin saya bagikan di konferensi, dan saya berbicara sendiri atau mendorong kolega untuk berbicara. Dan di sisi lain, yang sebaliknya adalah baik dalam kunjungan yang sering ke konferensi: Anda menemukan sesuatu yang dapat berguna bagi kami, kemudian kami mempelajarinya dan memasukkannya ke dalam tumpukan kami.
Eugene: OSS Evangelism disebutkan dalam deskripsi Twitter Anda. Apa itu dan mengapa itu penting bagi Anda?- Alasan pertama ini penting: Saya menemukan bahwa jika Anda menerjemahkan pengembangan Anda menjadi open source, itu sama sekali tidak menghemat waktu Anda, tetapi sangat membantu dalam menguji dan meningkatkan kualitas. Karena perpustakaan seperti MobX digunakan dalam kondisi yang sangat berbeda. Dan saya pikir dalam hal ini open source memberikan keuntungan sehingga sangat sulit diperoleh dengan cara lain.
Dan yang kedua: Saya percaya bahwa perkembangan "tingkat rendah" kami tidak mendefinisikan perusahaan, jadi mengapa tidak membagikannya. Maksud saya, sebuah perusahaan dibuat lebih atau kurang kompetitif dengan produk yang dibuat berdasarkan teknologinya - dan bukan teknologi ini sendiri. Dan semua orang mendapat manfaat dari kolaborasi, ini memungkinkan pengembangan secara keseluruhan untuk dipercepat.
Eugene: Terkadang mereka mengatakan bahwa open source "non tunai" sebenarnya adalah kesenangan yang sangat mahal. Proyek seperti Linux membutuhkan banyak uang dari raksasa seperti Oracle dan Microsoft. Benarkah begitu? Bisakah komunitas open source ada tanpa vendor besar dan uang?- Saya pikir itu tergantung pada situasi spesifik. Ada perpustakaan kecil yang bisa eksis seperti itu. Tetapi proyek-proyek seperti kernel Linux atau React Native yang disebutkan di atas begitu rumit dan begitu banyak orang bergantung padanya sehingga mereka membutuhkan model keuangan yang andal. Dalam hal ini, tanpa sponsor besar akan sangat sulit. Tapi saya rasa ini bukan masalah. Saya pikir itu lebih penting bahwa perusahaan belajar untuk mengambil tanggung jawab daripada kita belajar untuk melakukannya tanpa mereka.
Eugene: Misalnya, jika Facebook mendatangi Anda dan mengatakan "Ayo beli MobX atau sponsorkan sehingga pengembangannya berada di bawah merek kami"?- Yah, sebenarnya, mereka sudah mensponsori! Ini lucu, tetapi Facebook adalah salah satu sponsor MobX
di Open Collective . Jadi dalam beberapa hal ini sudah terjadi. Menurut pendapat saya, Open Collective adalah contoh yang bagus tentang bagaimana kita dapat meningkatkan posisi keuangan open source. Ini memungkinkan perusahaan untuk mensponsori pengembangan dengan cara yang sesuai untuk mereka, karena ada pendekatan yang serius secara finansial, dengan faktur dan sejenisnya.
Di Mendix, saya pada dasarnya membayar banyak untuk bekerja di MobX, jadi saya tidak tertarik untuk beralih ke Facebook sepenuhnya. Saya mengerti bahwa ini mungkin menarik minat orang lain, tetapi saya tidak melihat masalah dalam hal ini. Menurut pendapat saya, jika lisensi tetap open source, tidak ada yang salah dengan fakta bahwa produk tersebut berada di bawah merek sponsor utama. Ini seperti menonton sepak bola di TV: jika semua orang bisa melihat permainan, maka tidak ada perbedaan apa logo di T-shirt.
Eugene: Jika sebuah perusahaan besar mensponsori perpustakaan, tidak bisakah dikatakan "Karena kita membayar begitu banyak, maka tolong, lakukan ini untuk kita di dalamnya"?"Setidaknya aku belum menemukan ini, sehingga itu menjadi masalah." Jika saya tidak salah, webpack menggunakan model seperti itu, adalah mungkin untuk membayar fitur di sana. Jadi ada beberapa risiko, tetapi saya pikir itu adalah tanggung jawab pengelola untuk memastikan bahwa proyek tetap setia pada filosofinya. Namun dalam filosofi ini, kemungkinan ada banyak ruang untuk bermanuver. Dan selain itu, dalam open source, jika tiba-tiba ada yang salah, setidaknya kemungkinan garpu tetap ada.
Eugene: Pengembangan perangkat lunak open source seperti kurva: pertama Anda membuat perpustakaan yang tidak dibutuhkan orang lain, lalu orang-orang mulai menggunakannya, lalu memperoleh ribuan bintang di github dan sebagainya. Ketika sebuah proyek open source menjadi populer, itu bisa mulai memakan banyak waktu. Berapa banyak yang Anda belanjakan untuk MobX?- Baru-baru ini, tidak terlalu banyak. MobX cukup stabil saat ini. Menghabiskan banyak di masa lalu, tentu saja. Itu sangat berbeda. Saya pikir selama beberapa tahun pertama itu beberapa malam dalam seminggu, dan ada banyak momen kecil ketika Anda hanya menjawab masalah kecil atau pertanyaan di Twitter. Hal-hal kecil ini tidak dirasakan sebagai investasi waktu yang signifikan, tetapi saya pikir secara total mereka menambah secara signifikan. Namun, sangat sulit untuk diukur. Ini adalah cara memeriksa surat kantor - Anda memeriksa masalah dan mengirim respons dengan cepat.
Eugene: Bagaimana menjadi produktif dalam situasi di mana Anda adalah seorang pengembang, membuat perpustakaan, telah menjadi populer dan membutuhkan lebih banyak waktu? Anda beruntung, Anda memiliki kesempatan untuk melakukannya selama jam kerja. Tetapi jika Anda sudah memiliki pekerjaan dan hobi, dan proyek menjadi lebih populer?- Nah, ketika saya mulai bekerja di MobX, itu juga hanya di waktu luang saya, yang bekerja ditambahkan ketika proyek mencapai popularitas. Tapi saya punya beberapa tips. Saya perhatikan ada beberapa aturan yang membantu saya.
Pertama: melacak relevansi dokumentasi. Jika Anda menerima pertanyaan yang sama tiga atau empat kali, pastikan untuk mencatat jawabannya dalam dokumentasi. Karena pada akhirnya menghemat waktu Anda.
Kedua: sangat pilih-pilih tentang masalah yang Anda terima. Pada awalnya, segera setelah Anda diberitahu tentang kesalahan, Anda mencoba mereproduksi masalah berdasarkan deskripsi yang tersedia. Dan dalam beberapa kasus Anda menemukan bahwa ini tidak mungkin, dan waktu telah dihabiskan. Oleh karena itu, sekarang saya menuntut sesuatu yang bisa saya jalankan langsung dari masalah, apakah itu kode di kotak pasir atau permintaan tarik dengan unit test. Sesuatu yang memungkinkan saya untuk menentukan di mana masalahnya - di perpustakaan atau di sisi pengguna. Ini sangat penting, karena memungkinkan saya menghemat waktu dan memastikan bahwa pembuat masalah siap untuk menginvestasikan waktunya. Beberapa mengatakan, "Saya tidak punya waktu untuk membantu mereproduksi bug," dan saya merasa, "Baiklah, maka saya tidak punya waktu untuk membantu menyelesaikan masalah Anda." Bagaimanapun, seseorang mungkin dibayar untuk pekerjaan di mana dia menggunakan perpustakaan saya - mengapa saya harus menginvestasikan waktu luang saya dalam masalahnya? Secara umum, selektivitas seperti itu membantu, walaupun itu membuat Anda merasa agak kurang bertanggung jawab, karena Anda ingin membantu semua orang sama sekali. Tetapi saya menemukan bahwa "membantu semua orang" sama sekali tidak realistis.
Namun, karena saya bekerja dengan beberapa perpustakaan, saya tidak menanggapi semua masalah secara instan, tetapi “melompat” dari satu perpustakaan ke perpustakaan lain: Saya mengerjakannya beberapa hari dalam satu waktu, dan kemudian pindah ke yang berikutnya. Dan saya dapat menjawab Anda dalam beberapa menit jika Anda menulis tentang yang saya lakukan sekarang, tetapi saya tidak bisa menjawab selama berhari-hari jika giliran Anda belum tercapai. Ini membantu saya mengubah konteks lebih jarang.
Semua tips ini membantu ketika perpustakaan Anda mulai mendapatkan popularitas.
Eugene: Ketika pencipta perpustakaan populer menjawab "Saya tidak bisa mereproduksi, tulis tes unit", apakah ini tidak menyebabkan orang merasa "dia sombong dan tidak mau membantu"?- Saya menemukan efek seperti itu, tetapi sangat jarang. Saya berpikir bahwa biasanya pengguna mengerti bahwa pengelola cukup sibuk, dan bahwa masalah dengan probabilitas tinggi ada di pihaknya. Saya pikir jika Anda menggunakan filter Lodash dan Anda memiliki masalah, maka akan ada perasaan tidak disengaja "mungkin, ada yang salah dengan saya, karena semua orang menggunakan Lodash." Jadi kebanyakan orang mengerti bahwa mereka harus berhati-hati dalam masalah ini.
Eugene: Ketika perpustakaan menjadi populer dan membutuhkan lebih banyak waktu, berapa nilainya berbagi peran Anda sebagai kontributor, memberikan hak kepada anggota komunitas lainnya?- Ini adalah ide bagus, saya biasanya memberikan hak kontributor segera setelah saya melihat beberapa permintaan tarikan yang baik dari satu orang (atau bahkan satu permintaan tarikan, jika itu besar). Menurut pendapat saya, ini sangat bagus. Sebagai contoh, di pohon-pohon MobX, sebagian besar pekerjaan sekarang dilakukan oleh orang lain, bukan saya. Dan ada bagian lain dari basis kode yang orang-orang mengerti lebih baik daripada saya, dan itu bagus bahwa semuanya datang ke keadaan itu. Untuk MobX "inti", ini tidak diperlukan, karena semuanya telah menetap di sana, algoritme tidak berubah selama beberapa tahun terakhir, sehingga pekerjaan dukungannya kecil. Tetapi dalam kasus MobX-state-tree, saya sengaja memilih orang-orang yang membuat banyak perpustakaan pengguna, dan memberi mereka hak pengelola. Lagi pula, jika Anda secara aktif menggunakan perpustakaan dalam pekerjaan sehari-hari Anda, Anda akan menemukan pola atau masalah umum yang saya lewatkan. Dan juga, saya pikir, itu memberi motivasi pengembang dan rasa keandalan - karena mereka dapat membantu perpustakaan bekerja dengan apa yang mereka hadapi.
Eugene: Pada saat yang sama, apakah tidak ada perasaan bahwa perpustakaan, sebagai seorang anak, sedang dikalahkan? Mungkin Anda tidak setuju bagaimana tepatnya orang lain mengembangkannya?- Terkadang itu terjadi sedikit. Tapi saya pikir itu normal. Anda telah membuat analogi yang hebat dengan anak-anak: seiring waktu, mereka tumbuh, mereka menjadi 18, dan kemudian Anda perlu membiarkan mereka pergi, karena sudah waktunya bagi mereka untuk menemukan jalan mereka sendiri. Saya pikir, sampai batas tertentu, dengan perpustakaan open source juga. Jika mereka berhasil, maka Anda mulai menghadapi situasi yang lebih sulit. Anda mulai berurusan dengan kasus-kasus yang secara umum tidak ingin saya tangani. Kode tidak akan lagi menjadi kode cantik, bersih, dan minimalis yang saya inginkan. Ini tidak bisa dihindari.
MobX memiliki contoh yang bagus tentang ini: Saya awalnya menulis untuk TypeScript, di mana dekorator sangat sederhana, dan kemudian orang-orang mulai menggunakannya dengan Babel, di mana ada implementasi yang sama sekali berbeda. Dan pada akhirnya, beberapa bagian dari basis kode sangat tidak sedap dipandang karena mereka mencoba menentukan apakah Anda menggunakan TypeScript atau Babel. Kedengarannya mengerikan dan terlihat mengerikan. Tapi itu bagian dari pekerjaan. Tidak perlu untuk menyukainya, tetapi perlu untuk memastikan bahwa semuanya bekerja dengan baik di mana-mana. Dan dalam hal ini, anak Anda dapat pergi ke arah yang tidak Anda pikirkan, tetapi ini normal, karena pada akhirnya penting bahwa orang dapat berhasil menggunakan proyek.
Eugene: Pembangunan sedang berubah, jauh lebih mudah daripada 10-20 tahun yang lalu. Apa yang Anda pikirkan tentang situasi saat ini di open source sehubungan dengan perubahan ini, dan apa yang Anda harapkan dari masa depan? Akankah perusahaan besar menjadi bahan bakar semua orang, atau, sebaliknya, penggemar?- Ini pertanyaan yang sulit. Tidak yakin akan ada perubahan besar. Dan ada perubahan di kedua arah sekaligus. Saya sangat terkesan dengan Facebook dan Microsoft - seberapa banyak yang mereka buka sekarang dan sejauh mana mereka memungkinkan pengembang pihak ketiga untuk berkontribusi. React Native adalah contoh yang sangat mencolok di mana sebagian besar pekerjaan tidak berasal dari Facebook. Di sisi lain, bagi penyendiri, mungkin tidak pernah begitu mudah untuk berpartisipasi dalam proyek open source atau membuat sendiri, seperti sekarang. Alat menjadi lebih terstandarisasi, kami memiliki IDE daring yang hebat seperti
CodeSandbox dan
Gitpod . Saya telah bekerja dengan Gitpod dalam beberapa minggu terakhir, dan ini bagus: Saya dapat memeriksa permintaan tarik tanpa melakukan apa pun secara lokal. Anda cukup menjalankan di Docker di peramban dan berkembang di sana. Jadi saya tidak tahu perubahan apa yang akan terjadi.
Eugene: Delapan tahun yang lalu, ketika saya adalah seorang pengembang C ++, tidak ada komunitas open source seperti sekarang. Dan sekarang di dunia web dan JavaScript, saya melihat bahwa open source berkembang lebih cepat dan lebih cepat. Akankah pertumbuhan ini berlanjut?- Saya pikir gerakan akan berlanjut. Salah satu alasannya, menurut saya, adalah sebagai berikut: baik perusahaan maupun pengembang semakin memahami bahwa open source tidak hanya berguna bagi mereka yang mengembangkan atau menggunakannya, tetapi juga membantu menemukan karyawan. Melihat partisipasi seseorang dalam sumber terbuka, Anda dapat memahami lebih banyak tentang dia daripada jika Anda mewawancarainya sepanjang hari. Cara dia menjawab masalah atau memulainya menunjukkan banyak hal. Saya pikir pengembang dan perusahaan menjadi semakin sadar akan pentingnya hal ini.
Eugene: Jadi Anda berpikir bahwa mengembangkan perpustakaan sumber terbuka dapat membantu wawancara?- Tepat. Jika Anda adalah perusahaan dan Anda memiliki perpustakaan seperti itu yang tidak terikat erat dengan API Anda, ini bagus, karena orang-orang akan datang untuk berpartisipasi - dan mereka mungkin berubah menjadi apa yang Anda butuhkan. Dan jika Anda menyewa salah satu kontributor Anda, akan lebih mudah bagi mereka untuk bergabung, dan Anda akan lebih memahami apa yang diharapkan. Saya pikir, untuk alasan ini saja, banyak hal menarik dibuka.
Dmitry: Kami berbicara tentang open source secara umum, mari kita beralih secara khusus ke MobX. Bagaimana dan mengapa Anda awalnya mulai melakukannya?- Pertanyaan bagus. Kami di Mendix telah lama memiliki aplikasi Windows yang ditulis dalam C #. Beberapa tahun yang lalu, kami memutuskan untuk mem-port-nya ke web dan mulai mencari tahu tumpukan mana yang akan digunakan. React baru saja dimulai, Angular telah ada untuk sementara waktu, Ember cukup populer. Dan cukup cepat, kami jatuh cinta dengan React karena model komponennya dan lapisan abstraksi yang diusulkannya.
Tetapi kemudian kami menemukan bahwa kami memiliki masalah kinerja, ternyata memperbarui DOM sepenuhnya cukup mahal, bahkan dalam kasus React. Di C #, kami terus-menerus memperbarui model dan menggambar ulang seluruh kanvas, dan tidak ada yang mengoptimalkan apa pun, karena semuanya bekerja dengan sangat cepat, jadi tidak perlu "mendekati rendering dengan cara yang cerdas". Tapi di sini kami menemukan bahwa dalam kasus DOM, Anda tidak bisa hanya menggambar semuanya 60 kali per detik. Jadi kami memikirkan cara melakukannya secara efektif. Kami berpikir tentang pendekatan abadi, tetapi dalam kasus kami itu tidak cocok karena beberapa alasan. Salah satunya adalah data apa yang kami kerjakan dan bagaimana data itu diberikan. Informasi yang sama diberikan di berbagai tempat. Data kami sangat sulit untuk dinormalisasi. Dan kedua, sepertinya Anda masih harus berurusan dengan terlalu banyak detail. Misalnya, Anda harus menulis penyeleksi untuk data yang Anda render.
Tetapi bagaimana jika Anda ingin menulis kode sederhana yang sama dengan kode C # kami, "render sesuatu" sebelumnya, dan tidak ingin repot dengan bagaimana ini akan berubah di masa depan? Jika Anda tidak ingin mengatakan kepada komponen "Jadi, ambil bagian data ini dari sini, tetapi yang ini dari sana, lalu Anda bisa membuat sesuatu"? Kami mulai mempelajari teknologi apa yang saat ini tersedia, dan dengan cepat tiba pada paradigma yang digunakan dalam Knockout, Meteor, dan (setidaknya secara konseptual) bahkan di Angular. Di mana Anda tidak berarti hubungan antara dependensi data dan komponen, atau apa yang harus diberikan saat.
Saya mulai mengerti mengapa orang sering membenci pendekatan seperti itu, terutama ketika aplikasi tumbuh. Dan ternyata lebih sering orang khawatir tentang kurangnya prediktabilitas dan "debugging", bahwa sesuatu dapat dilakukan terlalu sering, atau terlalu jarang, atau dalam urutan yang salah. Dan saya memutuskan bahwa kita bisa melakukan yang lebih baik. Kita bisa berusaha untuk tujuan yang sama, tetapi pendekatan yang lebih cerdas untuk implementasi. Dan MobX muncul. Itu tidak hanya menangkap hubungan antara mengamati dan diamati, tetapi membangun grafik ketergantungan seluruh, sehingga Anda dapat yakin bahwa semua pengamat dieksekusi dalam urutan yang paling efisien. Dalam pemrograman reaktif, ada konsep "kesalahan" - dan, di sini ini tidak dapat terjadi. Secara umum, yang sudah ada diambil di sini, tetapi dengan upaya untuk membuatnya lebih mudah diprediksi.
Dmitry: Yaitu, jika saya suka semacam pendekatan, tetapi perpustakaan yang ada tidak cukup baik, Anda bisa mengambil dan berbuat lebih baik, dan ini bisa menjadi populer?- Ya persis! Jadi saya menulisnya awalnya untuk keperluan internal kami, dan kemudian pergi ke ReactEurope. Tampaknya tahun 2015, dan ada banyak pembicaraan tentang pola Flux. Kemudian Perang Fluks mengamuk. Dan saya merasa bahwa orang menaruh banyak energi ke dalam masalah yang sudah kita selesaikan. « ». . , « 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: Nasihat yang bagus. Anda akan berada di Rusia untuk pertama kalinya - apa yang Anda harapkan dari Moskow dan dari konferensi?- Saya pasti ingin melihat Moskow dan saya pasti akan terkejut karenanya. Dan saya juga memperhatikan bahwa ada banyak pengguna MobX di Rusia. Saya melihat ini di pelacak, saat melakukan. Jadi saya berharap dapat bertemu dengan banyak pengguna MobX di konferensi.Anda dapat melihat Michelle dan bertanya kepadanya di HolyJS 2018 Moscow , yang akan diadakan pada 24-25 November . Di sana dia akan berbicara lebih banyak tentang manajemen negara. Lihat deskripsi laporan konferensi di situs webnya .