Kami melanjutkan serangkaian artikel tentang mereka yang membuat proyek dengan tangan mereka sendiri. Dengan
Stepan Goncharov, kami berbicara tentang bagaimana mengubah secara organik arah kegiatan profesional, dan pada saat yang sama, mengubah keterampilan kami dari pengembang Android menjadi DevOps. Mereka bertanya tentang
siklus rilis dan proses di Grab , sebuah perusahaan di mana 40 orang hanya mengembangkan untuk Android. Mereka berbicara tentang di mana mendapatkan ide untuk game, bertanya Stepan
Archetype dan kOptional tentang proyek OpenSource.
Tentang tamu : Stepan Goncharov (
stepango ) telah mengembangkan aplikasi dan game untuk Android sejak 2008, sejak jaman dahulu, ketika Android SDK tidak keluar. Selama karirnya, ia berhasil berperan sebagai QA, manajer, pemasar, blogger, analis, penasihat, dan banyak lainnya. Dia berpartisipasi dalam pengembangan aplikasi dan aplikasi yang tidak dikenal dengan jutaan pengguna di seluruh dunia. Dia saat ini bekerja di Grab, menggunakan Kotlin dan Rx secara ekstensif, dan mencurahkan lebih banyak waktu untuk OSS.
Ini adalah decoding teks dari podcast
Run Loop . Penyaji: Ilya Tsarev, Alexey Milyaev dan Roman Busygin.
Ilya: Katakan padaku apa yang Grab terlibat langsung dan apa peranmu. Apakah Anda hanya menulis kode atau lebih?
Stepan: Awalnya, Grab adalah layanan persembunyian tumpangan. Anda dapat memesan taksi, mereka akan mendatangi Anda, menjemput Anda, dan menjemput Anda. Namun baru-baru ini, perusahaan semakin mendapatkan akses ke layanan tambahan seperti pengiriman makanan dan sistem pembayarannya. Ketika saya datang ke Grab, saya memimpin tim pengembangan aplikasi pengemudi. Kemudian dia beralih ke aplikasi penumpang. Salah satu proyek terakhir saya adalah
desain ulang lengkap aplikasi penumpang . Sekarang saya melakukan lebih banyak DevOps - mengatur CI, mengoptimalkan waktu pembuatan dan semua itu.
Devops
Alexei: Stepan, dan jika itu bukan rahasia, mengapa kamu memutuskan untuk beralih ke DevOps dan CI? Saya sering mendengar cerita ketika pengembang seluler datang ke platform, antusias, dipompa ke ketinggian yang luar biasa, dan kemudian memutuskan untuk tiba-tiba pergi untuk beberapa tugas yang tidak produktif.
Stepan: Faktanya, semuanya berubah, menurut saya,
secara organik . Ketika saya sedang dalam proses mendesain ulang aplikasi, kami mengalami migrasi darurat ke GitLab karena fakta bahwa instance CircleCI tidak lagi dapat membangun proyek kami. Ternyata terlalu besar dan memakan banyak memori, tetapi tidak ada contoh CI yang cocok. Entah bagaimana, saya macet selama beberapa minggu mencoba untuk memigrasi proses kami dan, secara umum, segala sesuatu yang berkaitan dengan CI ke GitLab. Kemudian, setelah proyek berakhir, kami membentuk tim platform baru. Sementara saya menghabiskan 3 minggu berlibur, semua tugas lain diambil, jadi ketika saya kembali, mereka mengatakan kepada saya: "
Itu saja, Anda mengoptimalkan kecepatan build dan CI."Peran dan kegiatan berbeda
Ilya: Kami juga memiliki burung - bukan burung yang memiliki mikrofon yang dililitkan, tetapi masih di ekor mereka memberi tahu Anda bahwa Anda mengunjungi QA, sebagai manajer, dan
pemasar, dan blogger , dan analis - secara umum, saya menjalani banyak kegiatan berbeda . Tolong beri tahu kami secara lebih terperinci bagaimana Anda memasukkan Anda ke dalam semua peran ini, sudah berapa lama Anda di dalamnya, apa yang Anda sukai di masing-masing, mungkin, tidak suka? Mungkin Anda ingin kembali ke blogger sekarang?
Stepan: Pada prinsipnya, dalam masing-masing peran ini entah bagaimana entah bagaimana organik berubah mengalir dengan lancar dari satu ke yang lain. Semuanya berawal dari fakta bahwa saya menjadi tertarik pada pengembangan Android
sebelum merilis perangkat pertama di Android . Saya tertarik pada ide itu sendiri - sistem operasi di Jawa - entah bagaimana tidak biasa. Akibatnya, saat belajar di universitas, alih-alih melakukan pekerjaan laboratorium di C atau masalah universitas yang membosankan lainnya, saya secara bertahap mengurangi segalanya menjadi Android. Guru itu tidak menentang, dia juga tertarik untuk mempelajari sesuatu yang baru, dan saya menulis aplikasi Android.
Pada saat saya lulus, saya sudah memiliki beberapa pengalaman. Saya menulis aplikasi pertama saya, merilisnya ke Market, dan ini
memulai hasrat saya untuk pemasaran . Saya memiliki aplikasi saya sendiri, dan saya harus mempromosikannya. Saya mulai bermain-main sedikit dan menulis blog.
Pada tahun 2010 saya menemukan karya seorang pengembang Android, maka itu hampir mustahil - tidak ada pasar, tidak ada yang tahu tentang Android. Saya masuk ke perusahaan outsourcing, dan
saya harus merekrut tim dengan hanya enam bulan pengalaman dan 2 aplikasi yang diterbitkan.
Jadi, dari pemasaran dan blogging, saya kembali ke pengembangan. Kemudian ia lulus dari magistrasi, pindah ke St. Petersburg - juga untuk melakukan outsourcing. Di sana, saya mulai terlibat dalam pengujian otomatis, dan ternyata saya mengembangkan
arahan Robotium di perusahaan dan mengajar QA
cara menulis tes otomatis hingga saya
berangkat ke Singapura , tempat saya kembali merekrut tim saya untuk salah satu startup di Singapura. Setelah itu, ia mulai mengembangkan lebih lanjut dalam pengembangan Android. Sekarang saya masuk ke Grab - pertama ke manajer, lalu ke DevOps.
Roman: Stepan, tolong beri tahu saya, apakah Anda melewatkan saat ini ketika tugas Anda telah berubah cukup dramatis? Sekarang, secara kasar, setiap hari Anda minum DevOps - dan hanya itu?
Stepan: Sebenarnya, belum. Saya baru saja menyelesaikan proyek besar, dan pada prinsipnya, masih ada cukup banyak tugas. Mereka mungkin terlihat, tentu saja, sama - yaitu, tujuannya adalah satu, tetapi apa yang saya lakukan adalah
banyak, banyak hal yang berbeda , termasuk, misalnya, memori-profiling, bekerja dengan CI. Sekarang saya melihat analisis Amazon di S3.
Ini semua baru bagi saya sejauh ini . Saya tidak berpikir bahwa saya akan terlibat dalam CI dan optimisasi waktu perakitan untuk waktu yang lama. Kemungkinan besar, misalnya, pada kuartal berikutnya saya akan beralih ke hal lain.
Roman: Misalnya, saya memiliki
siklus transisi dari satu arah ke arah lain selama sekitar 2-2,5 tahun . Saya mulai dengan pengujian, lalu beralih ke memuat pengujian, lalu saya menjadi pengembang. Seberapa sering Anda mengubah minat dan bidang pekerjaan?
Stepan: Di suatu tempat di wilayah 1,5-2 tahun. Namun baru-baru ini, ternyata selama enam bulan.
Permainan
Alexei: apa yang paling ingin kamu lakukan? Idealnya, mungkin Anda ingin meninggalkan pengembangan, tidak menyentuh apa pun dengan tangan Anda? Atau mungkin Anda, sebaliknya, ingin menggali beberapa hal asli yang mendalam? Apa yang paling Anda inginkan secara spesifik?
Stepan: Itu pertanyaan yang bagus! Saya sebenarnya tidak memutuskan.
Saya masih tertarik pada beberapa hal . Salah satu yang paling menarik bagi saya, di mana saya tidak bisa mendapatkan, adalah pengembangan game. Saat belajar di universitas, saya gemar menulis semua jenis permainan. Saya punya proyek di Flash. Aplikasi Android kedua saya juga merupakan permainan. Saya bahkan bekerja selama sebulan di perusahaan game, tetapi entah bagaimana itu tidak berhasil untuk saya.
Pada prinsipnya,
saya ingin mencoba desain game , tetapi ini masih sulit. Semakin lama saya menghabiskan waktu dan berkembang di Android, semakin sulit transisi ini, jika itu terjadi sama sekali.
Ilya: Styopa, jika kita menyentuh pada topik permainan, maka pertanyaannya adalah - apa pertandingan pertama kamu?
Stepan: Itu tahun 2010, jadi itu sangat sederhana. Itu adalah teka-teki logis dengan laser dan cermin yang harus diputar sehingga laser mencapai target. Sayangnya, game ini di-host di akun atasan saya saat itu. Akun ini telah lama dihapus dan permainannya tidak ada. Tapi aku sangat menyukainya. Itu sepenuhnya ditulis di Android View, yang, tentu saja, saya menyesal, tetapi pengalaman itu sangat baik.
Ilya: Sekarang, apakah Anda meluangkan waktu untuk mengembangkan game?
Stepan: Tidak. Sama sekali tidak ada waktu untuk permainan sekarang. Selain fakta bahwa saya bekerja di perusahaan, saya juga
mengatur pertemuan Kotlin di Singapura dan berbicara di konferensi. Artinya, waktu senggang sepenuhnya penuh. Mungkin suatu hari nanti saya akan kembali ke ini. Baru-baru ini saya membeli Google VR untuk mencoba Unity ketika ada waktu, tetapi sejauh ini belum memungkinkan.
Roman: Dan tolong beri tahu saya, dari mana Anda mendapatkan ide untuk game? Bagaimana mereka datang ke pikiran Anda?
Stepan: Gagasan untuk permainan biasanya datang kepada saya dari inovasi teknis. Saya biasanya menonton beberapa demo teknologi, atau, misalnya, pada 2008-2010 ada mode untuk mesin fisik. Anda melihat beberapa teknologi keren atau shader modis baru, dan
ide -
ide itu sendiri muncul berdasarkan apa yang Anda lihat.
Roman: Apakah hobi Anda membuat game terkait dengan fakta bahwa Anda sendiri seorang gamer - Anda bermain di PlayStation, di Switch, di PC - apakah ada korelasi?
Stepan: Ya, saya pikir ada. Sebagai seorang anak, saya punya Sega, lalu PC, saya menghabiskan banyak waktu bermain game. Sekarang saya memiliki PlayStation dan Switch, tetapi sekarang
saya menghabiskan lebih sedikit waktu untuk permainan , saya bahkan tidak harus memainkannya.
Roman: Dan game mana yang paling Anda ingat? Atau genre game mana yang paling Anda sukai? Sebagai contoh, saya lebih suka penembak atau semacam Survivor-horor.
Stepan: Saya entah bagaimana tidak berhasil dengan penembak. Saya bermain Counter-Strike sebagai seorang anak, tetapi ternyata tidak.
Salah satu game favorit saya adalah Space Rangers-2 , dan bagian pertama tentu saja epik. Kemudian dari mengesankan itu adalah
Freelancer .
Alex: Freelancer adalah game? Ini adalah gaya hidup!
Stepan: Sebenarnya, ini adalah simulator ruang, secara kasar, sangat dekat dengan Space Rangers, tetapi dari perspektif pihak ketiga. The Witcher, Arcanum, dan Fallout seperti itu.
Ilya: Bagi saya,
mengembangkan game adalah impian kebanyakan programmer . Seperti yang selalu tampak bagi saya, orang umumnya pergi ke pengembangan hanya untuk membuat game. Ini sangat keren! Proyek iOS pertama saya - omong-omong, itu juga permainan. Apa yang Anda pikirkan tentang ini?
Alexei: Saya mendengar bahwa bagi banyak orang jalan menuju pemrograman benar-benar dimulai dengan fakta bahwa mereka ingin membuat semacam permainan, mereka suka bermain game, mereka ingin mengerti bagaimana melakukannya. Untuk beberapa alasan saya tidak memiliki ini.
Saya lebih tertarik pada bagaimana program bekerja - apa yang terjadi ketika Anda mengklik windows di Windows. Tetapi pada titik tertentu saya menyadari bahwa saya tidak tahu cara membuat game. Saya mengerti bagaimana mungkin menulis aplikasi ini atau itu di ponsel, program ini atau itu di PC - saya tidak membayangkan bagaimana cara membuat game. Entah bagaimana saya begitu ditempatkan di saluran YouTube. Di sana, seorang pria di Jawa dan Kanvas menulis mainannya dari awal - klon dari beberapa game RPG dengan sesuatu yang mirip dengan campuran Diablo dan Final Fantasy. Ini sangat menarik.
Saya akan menyarankan semua orang untuk mencoba bermain dengannya di waktu luang mereka , untuk memahami bagaimana umumnya ditulis, cara kerjanya. Itu adalah pengalaman yang sangat keren. Lalu aku entah bagaimana masuk ke pelajaran yang sama, di mana pria itu melihat beberapa permainan sederhana di Unity. Sangat menarik untuk membandingkan pendekatan ketika Anda mulai menulis mesin Anda, dan ketika Anda sudah memiliki sesuatu yang siap seperti Unity, dan Anda entah bagaimana menyesuaikannya untuk membuat mesin Anda sendiri. Saya akan sangat menyarankan mencoba sesuatu seperti ini, karena itu, bagaimanapun, sangat menarik.
Roman: Saya punya pengalaman serupa. Saya suka bermain, tapi saya bukan gamer yang rajin, tetapi pada saat yang sama saya terutama tertarik untuk memahami bagaimana program dibuat. Kemudian saya sampai pada kesimpulan bahwa apa yang saya sukai, apa yang saya sukai, saya ingin mencoba melakukannya dengan tangan saya sendiri. Namun dalam hal permainan
, semuanya dimulai dengan sebuah ide . Saya menunggu ide yang dapat diterapkan di waktu luang, atau untuk membersihkan waktu saya dan membuat game ini.
Stepan: Mengenai gagasan, salah satu yang terakhir muncul di benak saya terkait dengan
pembuatan peta secara otomatis . Sekarang ini bisa dikatakan tren, dan beberapa game menggunakan generasi dunia besar untuk membuatnya sangat mirip dengan yang nyata.
Ada seluruh kelas algoritma yang memungkinkan Anda menghasilkan medan. Bentang alam dapat dibangun sehingga akan ada gunung dan laut. Pada prinsipnya, jika seseorang ditampilkan tampilan atas peta Google dan lanskap yang dihasilkan, hanya sedikit yang bisa membedakannya. Ini sangat menarik, karena Anda dapat membuat konten untuk gim Anda sendiri, tanpa memiliki sumber daya yang besar, karena itu adalah salah satu bagian yang paling sulit. Setidaknya saya pikir begitu.
Hari kerja
Alexei: Stepan, bagaimana biasanya hari kerjamu? Anda bangun, pergi ke kantor, atau tidak mendapatkan - apa yang Anda lakukan, apa yang Anda lakukan?
Roman: Saya masih tertarik dengan apa yang terjadi sebelum Anda sampai di kantor. Mungkin Anda memiliki beberapa kedai kopi favorit atau tradisi favorit Anda: misalnya, apakah Anda suka berjalan di sepanjang taman umum di depan kantor? Apa yang sebenarnya mengawali harimu?
Stepan: Baru-baru ini, hari saya dimulai dengan 50 push-up.
Alexey: Hormat!
Stepan: Pada titik tertentu saya menyadari bahwa
saya perlu mencurahkan lebih banyak waktu untuk aktivitas fisik , dan sekarang saya mencoba untuk memaksa diri saya untuk melakukannya di waktu luang saya. Pada prinsipnya, tidak ada yang istimewa.
Karena bisnis utama perusahaan adalah naik sembunyi, yaitu memesan taksi, perusahaan membayar saya taksi. Karena itu, hal pertama yang saya lakukan di pagi hari setelah sarapan adalah memesan taksi dan pergi bekerja.
Saya bekerja di kantor yang lumayan dengan pemandangan teluk yang indah. Seperti kebanyakan dari kita,
hal pertama, tentu saja, secangkir kopi . Lebih sering daripada tidak, kami hanya turun dengan rekan kerja ke ruang bawah tanah gedung yang sama, pergi ke salah satu kedai kopi, mengambil kopi dan
membahas beberapa berita, rencana . Sangat menarik jika terjadi sesuatu pada malam ini, yaitu hari di AS: sesuatu yang baru telah dirilis, beberapa berita menarik, kerangka kerja baru. Kami membahas semua ini, dan setelah itu kami bisa mulai bekerja.
Kemudian semuanya hampir sama dengan orang lain: Anda pergi ke
Jira , menonton tiket. Selama beberapa minggu terakhir saya telah on-call. Ini adalah pengembang seperti itu, yang menjadi penyebab semua masalah produksi, dan Anda harus entah bagaimana menyelesaikan, atau mendelegasikan, atau mengatakan - ini bukan masalah dan lupakan saja.
Karena timnya sangat besar (
lebih dari 40 orang sudah mengerjakan aplikasi penumpang - ini adalah tim yang berbeda yang bertanggung jawab untuk area yang berbeda), kadang-kadang cukup sulit untuk menemukan orang yang tepat yang perlu menyelesaikan masalah ini. Kami memiliki rotasi seperti itu -
setiap minggu salah satu pengembang terlibat dalam menyapu masalah produksi . Secara khusus, minggu ini saya sedang mempersiapkan rilis, ini adalah perbaikan masalah dari pengujian, dan sekali lagi menemukan orang yang tepat untuk menyelesaikan ini dengan tercepat.
Roman: 40 orang hanya Android, atau apakah seluruh tim yang membuat aplikasi seluler?
Stepan: Ini hanya Android.
Roman: Wow! Ketika saya
mendengar berapa banyak pengembang seluler di Uber, saya merasa tidak nyaman. Tetapi tim Anda mengkonfirmasi tren ini. Anda menyebutkan bahwa Anda, secara kasar, bertugas pada laporan bug. Katakan padaku, bagaimana siklus rilis Anda?
Siklus rilis aplikasi
Stepan: Pada prinsipnya, saya pikir ini adalah proses yang kurang lebih biasa yang coba dipatuhi oleh aplikasi besar.
Kami memiliki kereta rilis tetap . Ini adalah minggu saat ini. Artinya, setiap minggu pada hari Selasa kami memiliki rilis. Insinyur rilis dipilih untuk minggu ini, dan pada awal minggu, semua fitur yang termasuk dalam rilis harus siap.
Jika beberapa fitur tidak siap, mereka membuangnya, tutup dengan bendera - lakukan apa pun untuk mencegah kemundurannya. Segera setelah bangunan ini, di mana semua fitur siap, diberikan kepada QA, proses pelepasan-rekayasa dimulai. Artinya,
setiap bug terbuka harus diperbaiki secepat mungkin , mereka diberi prioritas tertinggi. Sekalipun pengembang sedang mengerjakan fitur berikutnya, yang akan dirilis pada rilis berikutnya, tetapi ada bug atau masalah yang ia tahu paling baik dan ia memiliki waktu paling sedikit untuk menyelesaikannya, itu diberikan kepadanya.
Ini terjadi pada kami sampai hari Jumat.
Pada hari Jumat, kami mencoba untuk mengakhiri regresi , menutup semua bug regresi, dan pergi dengan jiwa yang tenang untuk akhir pekan. Jika sesuatu tiba-tiba terjadi, pada hari Senin Anda dapat dengan cepat memperbaikinya, dan sudah pada Senin malam atau Selasa pagi menerbitkan dan meluncurkan dengan diam-diam - 10% pertama, kemudian lebih, lebih, lebih, lebih. Selama seminggu, kami mencoba mendekati seratus, dan merilis rilis berikutnya.
Pengujian dan Pembaruan
Roman: Cepat menyusun dan mengeluarkan - tetapi bagaimana dengan proses pengujian? Penguji orang khusus yang memeriksa pada titik apa mereka melakukannya?
Stepan: Ada banyak penguji, mereka tepat waktu. Saya tidak tahu berapa banyak dari mereka yang pasti. Alasannya adalah bahwa sebagian besar tim tidak di Singapura. Saya tidak ingat berapa banyak kantor yang kami miliki, tetapi ada setidaknya 5 kantor lagi di mana ada tim pengembangan bersama dengan QA. Selama pengembangan fitur, tim-tim ini, bersama dengan QA, men-debug fitur-fitur ini sendiri dan mengujinya.
Pada saat siklus rilis dimulai, fitur seharusnya tidak memiliki bug terbuka . Regresi terjadi sebagai berikut: satu, mungkin dua QA dari semua tim menonjol, dan mereka menjalankan regresi sesuai dengan fitur mereka. Baru minggu ini, saat mencari bug, regresi diperbaiki.
Ilya: Ternyata Anda memiliki siklus pembaruan mingguan, dan pengguna punya waktu untuk memperbarui dalam waktu seperti itu? Misalnya, kami dihadapkan pada situasi di mana pengguna iOS punya waktu untuk memperbarui, dan Android - tidak juga. Versi kami berbeda secara langsung selama beberapa minggu.
Alexei: Ya, bagi saya sepertinya minggu itu terasa cepat.
Stepan: Ya, benar. Seminggu sangat cepat, tetapi
kami tidak memiliki tujuan untuk memperbarui semua pengguna . Kami beralih dari siklus rilis dua minggu ke siklus mingguan untuk mengurangi beban QA selama regresi, karena sejumlah besar fitur terakumulasi selama 2 minggu.
40 orang dapat melakukan bisnis! Kemudian, pada akhir minggu kedua, kami menggunakan bug yang cukup serius yang diperoleh karena penerapan fitur-fitur ini, dan itu cukup sulit untuk menyelesaikannya. Ternyata kami mogok setiap minggu dan mendistribusikan beban pengujian ini lebih merata.
Ilya: Berapa kira-kira persen dari basis pengguna Anda menggunakan versi terbaru?
Stepan: Itu tergantung pada periode waktu yang kita bicarakan.
Ilya: Saat ini.
Stepan: Anda dapat menggunakan versi terbaru hanya jika Anda masuk ke paket muat ulang ini selama seminggu. Artinya, 100% isi ulang akan sekitar Jumat, atau pada hari Senin, karena sudah pada hari Selasa versi baru akan keluar. Itu sudah tergantung pada keberuntungan. Tapi kami tidak memiliki tujuan sehingga pengguna selalu duduk di versi terbaru. Satu-satunya hal yang masih perlu kita pikirkan adalah versi minimum yang didukung. Kami secara berkala memaksa pengguna untuk memperbarui secara paksa ketika setidaknya 90% pengguna berada pada versi minimum yang didukung, yaitu sekitar 3-4 bulan.
Organisasi Kerja Tim
Alexey: Styopa, saya punya pertanyaan seperti itu. Anda mengatakan 40 orang melakukan Android - kan? Benarkah 40 pengembang sedang melakukan sesuatu?
Stepan: Ya.
Alexei: Ada momen seperti itu dengan meningkatnya jumlah karyawan, terutama di satu area perusahaan, yaitu, khususnya dalam pengembangan Android,
biaya komunikasi meningkat secara eksponensial . Semua proses bisnis berkomitmen untuk menyelesaikan fenomena ini. Dan bagaimana ini diselesaikan dalam diri Anda? Bagaimana struktur organisasi mesin 40 pengembang ini?
Stepan: Sebenarnya, solusi kami cukup sederhana.
Ke-40 pengembang ini tidak melakukan hal yang sama , dan mereka pada dasarnya tidak perlu berkomunikasi dengan kuat satu sama lain. Ternyata tim di berbagai negara terlibat dalam fitur yang berbeda. Pada dasarnya, Anda tidak perlu berkomunikasi dengan tim lain. Anda berkomunikasi terutama dengan manajer Anda. Akibatnya, biaya komunikasi tidak begitu besar, karena
timnya 5-6 orang . Ada tim dari 1-2: misalnya, hanya beberapa bisnis vertikal baru muncul, ada satu pengembang, dan dia hanya memiliki kepala teknik, yang bertanggung jawab untuk semuanya, termasuk backend, iOS dan hal-hal lainnya.
, , , .
OpenSource- Archetype kOptional
: . , OpenSource -. , OpenSource, .. , , โ
Archetype kOptional . Apa ini
: kOptional . ,
Optional . - Null, . . , Java8 .
, . , , โ , , . , -.
Archetype โ . - , 90
Seconds . - : , , , . , : , โ .
, - .
. . , , : "
". Kenapa tidak
โ , - , . , 90 Seconds , NDA . , , 90 Seconds: , - , - .
,
- , 90 Seconds. , , , , . , , , Rx. , , Kotlin, legacy.
, , , โฆ .
: ,
OpenSource- . , , , , , . , !
.
AppsConf . , , ?
AppsConf
: , AppsConf.
, , : ยซ ยป. , , , .
, , . , , . , , , , .
. , , . , . โ , .
, . , , -, , -, , .
, . , , , . Mobius, . .
-, , ,
- , , - WorkManager, .
,
Kotlin ,
,
, - .
: , ?
: , . -, , , , . , , , .
, , โ , , , subscribe. - , , . .
: , - OpenSource , ?
: . production-ready, , , GitHub.
:, ! , , , AppsConf 8โ9 .
AppsConf , , , .