Di antara pengembang Android,
Artyom Zinnatullin sangat disegani sehingga Anda dapat membuat analogi "fakta tentang Chuck Norris" tentangnya - kira-kira seperti ini:
- Artyom begitu keras sehingga ketika dia melihatnya, github itu sendiri berubah menjadi hijau (siapa di antara kita yang bisa membanggakan jadwal kontribusi seperti itu?)
- Artyom begitu keras sehingga baginya git adalah seorang pembawa pesan .
- Artyom sangat keras sehingga dalam konteks aplikasinya adalah podcast .
Ketika kami mewawancarainya di konferensi Mobius kami, itu dimaksudkan untuk siaran online. Tetapi setelah melihat bagaimana mereka merujuknya di obrolan Android, kami memutuskan bahwa itu juga menarik bagi banyak orang di Habré, dan membuat versi teks untuk Anda (kami juga melampirkan rekaman video).
Bagaimana cara hidup dengan proyek pada sejuta baris kode? Apa kerugian corotin Kotlin? Apa yang salah dengan Google? Apa perbedaan pembangunan di San Francisco dengan Rusia? Apa yang dibicarakan Mobius? Di bawah potongan - tentang semua ini.
Evgeny Trifonov : Di Mobius ini, saya melewatkan pembicaraan Anda “Android builds at Lyft”, tetapi setelah itu saya melihat kerumunan orang yang ingin mengajukan pertanyaan di area diskusi. Dan saya ingin mengklarifikasi: tetapi bagaimanapun, sebagian besar pemirsa tidak bekerja di proyek raksasa seperti Lyft, apakah pengalaman ini relevan bagi mereka?
Artyom : Ini hal yang menarik. Garis besar asli laporan di kepala saya, dan bagaimana saya akhirnya mengimplementasikannya, sangat berbeda berkat komite program Anda yang berkelas.
Awalnya, saya akan memberi tahu Anda bagaimana semuanya dimulai di Lyft, mengapa kami sampai pada solusi teknis tertentu. Dia berbicara dengan Sergey Boishtyan dari komite program selama dua jam, dia mendengarkan dan berkata, "Keren, tentu saja, tetapi Anda memang suka berbicara." Dan pada akhirnya, saya menyadari bahwa laporan seperti itu, tentu saja, menarik untuk didengarkan, tetapi itu benar-benar tidak relevan bagi siapa pun.
Dan kemudian saya ulang, menggeser penekanan pada pendekatan teknik dasar ke pilihan sistem perakitan, sistem lain. Saya tidak memiliki tujuan untuk memberi tahu alat apa yang kami gunakan secara khusus. Saya tidak ingin seseorang mengambil dan membabi buta mulai menggunakannya, dan kemudian menulis kepada saya surat-surat hebat yang tidak semuanya bekerja seperti yang saya katakan. Saya ingin menyampaikan praktik rekayasa yang tepat tentang bagaimana membuat pilihan, dan apa yang penting menurut pendapat saya (alami, subyektif). Oleh karena itu, saya berharap bahwa pada akhirnya pengalaman itu relevan bagi lebih banyak orang, dan bukan hanya "pria dari Lyft keluar dan mengatakan sesuatu."
Oleg olegchir Chirukhin : Apakah ada pilihan Lyft yang tidak biasa yang sulit dilakukan orang lain?
Artyom : Ya, tentu saja. Kami memiliki dua sistem pembangunan di proyek pada saat yang sama, saya tidak merekomendasikan siapa pun
(tertawa) .
Sangat menyakitkan untuk mempertahankan: Anda terus mengejar dua burung dengan satu batu, di keduanya, ada sesuatu yang tidak berhasil sampai akhir. Tetapi ini adalah keadaan kita saat ini, secara historis, karena satu sistem bangun mulai tutup pada sebagian tugas, kita harus memulai yang kedua. Saya berbicara tentang cara menghindari ini dan bermigrasi dengan benar ke salah satu dari mereka.
Oleg : Dan sistem pembangunan seperti apa?
Artyom : Kami menggunakan Gradle dan Buck, dan saya berbicara tentang cara datang ke Bazel dari Google.
Oleg : Ini semacam gerakan menuju kejahatan: dari Gradle yang cantik ke Bazel, di mana bahkan tidak ada ketergantungan normal.
Artyom : Sekarang ada lebih atau kurang. Ya, tentu saja, ada pertukaran, dan, tentu saja, Gradle memiliki kelebihannya. Itu semua tergantung pada jenis proyek. Beberapa Gradle akan lebih cocok daripada Buck dan Bazel, karena mereka memiliki beberapa poin mendasar yang tidak akan mereka kumpulkan secara bertahap dalam modul yang sama, tetapi Gradle akan, dan bagi banyak orang ini sangat penting. Dan kerennya, Gradle bisa melakukan itu.
Hal lain adalah ketika Anda menambahkan modul - lebih banyak, lebih banyak modul, delapan ratus, seribu - Gradle didesain ulang sehingga akan memperlambat perakitan secara linier di beberapa tempat. Tetapi bagi saya kelihatannya Gradle dapat memperbaiki semua ini jika komunitas menekan mereka - yang mungkin saya lakukan. Ayo lihat.
(catatan: beberapa hari setelah wawancara ini, Artyom menulis posting panjang tentang masalah Gradle)Oleg: Ya , Bazel hanya karena saya ingin mendukung banyak modul?
Artyom : Anggap saja dalam kasus kami, kami tidak "merasa menyukainya," tetapi membagi proyek menjadi modul memungkinkan bisnis kami untuk bergerak lebih cepat. Pada dasarnya, seperti yang saya mengerti, ini adalah isolasi sehingga tidak berhasil spageti, yang kemudian sulit untuk dipertahankan. Modul memberikan kontrol lebih besar atas bagian mana dari kode yang berinteraksi. Kami memiliki hampir satu juta baris kode. Jika ada dalam satu modul, saya harus spageti. Karena di atas bahasa - Jawa, Kotlin - akan perlu untuk membuat sesuatu untuk melarang panggilan antar paket, di antaranya tidak ada yang mengharapkannya. Ditambah lagi, akan muncul pertanyaan bahwa Gradle tidak akan mengeluarkan begitu banyak kode dalam satu modul. Itu tidak akan mengumpulkannya secara paralel, secara bertahap merakitnya di dalam modul.
Setiap solusi memiliki trade off. Dalam kasus kami, menurut saya ini adalah solusi yang tepat, tetapi ada masalah - saat ini kami mendukung dua sistem build.
Oleg : Dan apa yang lebih baik untuk ratusan modul: monorepo atau banyak repositori?
Artyom : Ini poin yang sangat menyakitkan. Mungkin satu repositori lebih baik dari sudut pandang bahwa Anda tidak harus berpikir tentang versi dan tidak ada ketergantungan ini ketika Anda pergi dan mengkloning selusin repositori untuk membuat satu perubahan, dan kemudian buka satu permintaan tarik dan selusin setelahnya. "Gesekan" dihapus dari sistem, dan orang tidak takut untuk mengubah kode. Bagi mereka, atomicity perubahan muncul: semuanya diubah menjadi satu proyek, dan perubahan dari satu modul secara otomatis ditransfer ke modul lain tanpa persetujuan eksplisit dari mereka. Pada saat yang sama, semua pemeriksaan yang Anda tulis secara otomatis dalam CI akan dieksekusi dan memverifikasi bahwa kode tersebut dikompilasi, diuji, dan semua ini.
Oleg : Dan jika Anda tidak sampai pada kenyataan bahwa Anda, seperti di beberapa Chrome, cabang akan berubah selama dua menit, saat Anda minum teh?
Artyom : Ya, tentu saja, ada kemungkinan. Tapi di sini, mungkin, pertanyaannya sudah pada ukuran produk: apakah Chrome perlu mengandung begitu banyak kode? Mungkin perlu menyoroti beberapa bagian dalam instrumen yang terpisah, yang akan dikencangkan secara berkala ketika terjadi perubahan besar di dalamnya? Ini mungkin pertanyaan untuk organisasi proyek. Contoh keren, omong-omong. Saya memiliki yang serupa: korespondensi dengan dudes dari Yandex.Browser, di mana mereka juga memiliki colokan besar.
Chrome dapat dibagi menjadi beberapa komponen, dan jika Anda mengambil beberapa V8 - Saya bukan spesialis besar, tetapi sejauh yang saya mengerti, itu bisa menjadi proyek terpisah secara umum, bukan? Dan mengapa, kalau begitu, GUI harus tahu tentang mesin, pasang kembali setiap kali dan pikirkan tentang kode sumber berbaring di suatu tempat di dekatnya? Bazel, omong-omong, juga mendukung ini.
Secara umum, sekarang semua sistem pembangunan besar - Gradle itu, Buck itu, Bazel itu - mendukung hal seperti komposit yang dibangun ketika Anda merujuk, misalnya, ke perakitan Bazel lain. Ini adalah situasi yang sulit, tetapi, bagaimanapun, ini berhasil, ini memungkinkan Anda untuk menghapus sebagian file dari repositori, mengurangi ukurannya. IDE, misalnya, akan menjadi gila untuk mengindeks semua file ini, jadi saya ingin memisahkannya dari komponen umum proyek.
Tapi kami jauh dari itu. Sepertinya saya bahwa kita dapat dengan tenang mencari lima tahun lagi. Kami tidak mungkin mengalami checkout dua menit. Kami tidak memiliki banyak orang.
Eugene : Apakah Lyft masih memiliki spesifikasi sendiri, di samping dua sistem pembangunan?
Artyom : Ya, ada beberapa kisah yang tidak biasa di sana. Kebetulan orang yang datang ke perusahaan (dari Google, Facebook, di mana-mana) membenci mono-repositori. Sebagai hasilnya, kami di Lyft memiliki tiga mono-repositori: Android, iOS dan L5 (ini adalah
mobil otonom kami).
Dan yang lainnya lebih dari 1.500 repositori git: untuk semua layanan microser, untuk semua perpustakaan secara terpisah. Ini adalah kasusnya secara historis. Ini memiliki harga sangat tinggi yang harus kami bayar: mendorong perubahan melaluinya sangat sulit. Di sisi lain, ketika bekerja dengan masing-masing dari mereka, Anda memiliki klon git instan, push git instan, semuanya sangat cepat, indeks IDE per detik. Saya dapat mengatakan bahwa ini adalah bagian yang sangat menarik. Dari dudes dari San Francisco, saya harapkan repositori tunggal.
Oleg : Dan ketika salah satu dari repositori terpisah ini diperbarui - API berubah, misalnya - bagaimana perubahan ini berlaku untuk seluruh perusahaan?
Artyom: Rasanya sakit.
(tertawa) Yah, saya bukan pengembang backend karena saya tidak menulis backend fitur, saya menulis backend infrastruktur - mereka biasanya cukup mandiri dalam hal ini.
Sebagai aturan, ini hanya sekelompok aksi unjuk rasa, interaksi silang, dan kemudian perencanaan.
Oleg: Jadi demonstrasi adalah bagian dari sistem perakitan? (tertawa)
Artyom : Ya, pertama-tama kita harus mengumpulkan sebuah reli, lalu merakit repositori. Plus, sayangnya, secara historis, kami memiliki banyak layanan microser ini - ini adalah Python, yang juga memiliki lelucon sendiri.
Oleg : Beberapa tidak suka untuk Python menyelinap.
Artyom : Agak tidak suka mengetik dinamis. Python, bukan Python - tidak ada bedanya, tetapi pengetikan dinamis adalah hal yang menyakitkan.
Eugene : Dan itu tergelincir "untuk sebuah perusahaan dari San Francisco", dan ingin tahu menanyakan hal ini: tetapi dalam hal pengembangan, perusahaan dari San Francisco berbeda dari perusahaan dari Rusia, apakah ada perbedaan yang nyata?
Artyom : Perbedaan yang sangat besar. Saya bukan penggemar berat mengklasifikasikannya seperti itu, tetapi bagi saya sepertinya ada sekolah teknik yang lebih tepat.
Oleg : Ini - dimana itu?
Artyom : Di Rusia, di negara-negara bekas Uni Soviet. Orang-orang lebih memperhatikan aspek teknis tentang cara kerja komponen sistem mereka. Dan di Amerika sering terjadi bahwa beberapa perpustakaan memecahkan masalah, dan orang-orang bahkan tidak melihat bagaimana penerapannya. Mereka, sebagai suatu peraturan, sama sekali tidak peduli bahwa itu melambat atau bahwa mereka menggunakannya secara salah.
Saya akan mewawancarai banyak orang di sana, karena ini adalah bagian dari pekerjaan, dan tingkat pengetahuan umum, mungkin, masih lebih rendah. Ada sesuatu untuk diubah. Setiap kali seseorang datang dari Eropa Timur, itu menjadi lebih menarik selama wawancara, karena orang tidak takut untuk menolak, untuk berdebat di suatu tempat. Sementara kandidat AS sangat sering mungkin tidak menjawab pertanyaan sama sekali atau menjawab "Saya tidak ingat kapan terakhir kali menggunakannya." Untuk pertanyaan seperti "Bagaimana cara kerja permintaan HTTP?" atau "Format data apa yang akan Anda pilih?" mereka tidak dapat memberikan jawaban teknik normal, tetapi mengatakan: "Yah, saya telah menggunakan ini selama lima tahun terakhir." Keren, tentu saja, tetapi tuannya tidak menarik.
Di sisi lain, ada proyek yang membutuhkan waktu bertahun-tahun untuk dibandingkan dengan apa yang kami lakukan di sini. Orang-orang membuat lebih banyak produk massal, dan hanya ada lebih banyak skala. Misalnya, Chrome atau Uber - mereka sudah memiliki lebih dari seribu modul di sana. Ini hanya skala masalah. Katakanlah di Uber di bawah tiga ratus pengembang Android. Muncul pertanyaan: mengapa?
(tertawa) Tapi, bagaimanapun, mereka berhasil membuat raksasa ini bekerja, terus-menerus dibebaskan. Saya akan mengatakan masalah seperti itu kurang sering diselesaikan di sini.
Di sini Yandex adalah contoh yang bagus. Saya punya teman di Yandex.Maps: sepuluh orang membuat aplikasi Android. Di Google, kemungkinan besar seratus sedang duduk. Dan pada saat yang sama, Yandex.Mart memiliki lebih banyak fungsi. Itulah bedanya, menurut saya.
Eugene : Selain itu, Lembah juga dikaitkan dengan start-up, dan mereka memiliki pendekatan "bergerak cepat dan memecahkan hal-hal", dan tampaknya ini juga harus mempengaruhi perkembangan: hidup di tepi pendarahan, gunakan yang terbaru. Apakah itu benar
Artyom : Saya tidak bekerja di startup, Lyft sulit untuk menyebut itu: sudah ada tiga ribu tiga orang, di suatu tempat lebih dari seribu dari mereka adalah insinyur. Artinya, itu adalah perusahaan yang sudah terbentuk.
Ini adalah teknologi canggih yang jarang digunakan. Jika teknologinya hyped, maka ya. Jika teknologinya niche, tapi keren, sangat sering tidak. Sampai semua konferensi membicarakannya, sangat sedikit orang yang akan menggunakannya.
Tetapi pada saat yang sama saya benar-benar mencintai (di San Francisco dan sebagian di Lembah) - banyak masalah diselesaikan karena fakta bahwa perusahaan secara fisik dekat. Sangat sering Anda menulis kepada seseorang di ruang obrolan: “Mari makan siang bersama di tempat kami atau di kantor Anda dan memutuskan, kami akan mengajukan beberapa pertanyaan”, dan kemudian satu kali - proyek sumber terbuka atau permintaan tarik muncul di proyek lain, sesuatu diperbaiki.
Yang menarik: orang sering mendiskusikan hal-hal yang sebenarnya tidak boleh dibicarakan di NDA. Tapi inilah bagaimana seluruh Lembah bergerak, pada akhirnya semua orang mengerti ke mana sisanya bergerak, dan seluruh industri berjalan bersama. Katakanlah, mobilis Lyft dan Uber terus-menerus berbicara tentang hal-hal teknis, karena kami menggunakan open-source dari Uber. Dan, tentu saja, ada ahli langsung hardcore dalam beberapa teknologi. Ini juga keren: Anda bisa menyeberang dengan mereka.
Saya suka ini, dan ini tidak cukup bagi saya di beberapa kota tempat saya tinggal. Di sini, di St. Petersburg ada Kelompok Pengguna Java yang sangat keren (saya belum tahu bagaimana keadaannya sekarang): Anda datang setelah bekerja, dan Shipilev mengeluarkan otak Anda, dan ada sesuatu yang baik!
Dan di sana muncul lagi: misalnya, ia juga memiliki Java User Group sendiri, dan sering ada dudes, katakanlah, dari Oracle, yang memfilmkan beberapa JDBC Reaktif baru. Dan Anda duduk, berdebat, karena beberapa pemimpin Reaktor Proyek atau pemimpin Reaktif di Spring duduk di tempat yang sama, diskusi panas sedang berlangsung, dan ini keren.
Oleg : Saya akan bertanya tentang sesuatu yang lain: Saya melihat
repositori Mainframer, dan Rust digunakan di sana. Mengapa semua ini ditulis bukan pada Javka yang diberkati, tetapi pada beberapa jenis Karat?
Artyom : Baru-baru ini, saya telah pergi ke sisi bahwa program harus memiliki sumber daya yang minimal. Yaitu, saya ingin menjadi sangat dekat dengan bagaimana besi mencerna byte. Dan di Jawa, banyak hal yang terjadi di sekitar (saya bahkan tidak berbicara tentang pengumpulan sampah), yaitu, JIT dan semua ini. Saya sangat suka bahwa Jawa sekarang bergerak ke arah kenyataan bahwa akan ada juga kompilasi sebelumnya. Tampaknya bagi saya itu akan sangat keren, misalnya, untuk memulai peluncuran layanan microser dengan mengunduh dari cache kompilasi di muka, yang awalnya terjadi pada beberapa mesin lain, dan memulainya dengan sangat cepat, tanpa pemanasan. Ini keren, tetapi Java memiliki harga. Saya tidak bisa hanya meminta orang yang sedang membangun proyek iOS untuk memiliki Java di sistem mereka.
Mainframer awalnya ditulis dalam dialek Bash. Tapi saya ingin menulis ulang dalam bahasa sistem untuk mendapatkan multithreading yang normal, kemampuan untuk menulis tes unit normal, dan bukan hanya tes integrasi di atas utilitas ...
Oleg : Dan seseorang dapat mengambil, misalnya, Python.
Artyom : Ya. Tapi kemudian pertanyaan akan muncul dengan fakta bahwa, pertama, ini adalah pengetikan dinamis, dan kedua ...
Oleg : Jadi dalam Bash, juga, pengetikan dinamis.
Artyom : Jadi saya ingin menulis ulang. Dan selain itu, ada masalah dengan fakta bahwa Python sekarang dua: di MacOS, secara default yang kedua, dan hampir semua di Linux sekarang yang ketiga. Ada banyak jenis lelucon seperti itu. Jika saya perlu semacam kecanduan untuk mengikat saya akan meminta orang untuk menjalankan pip? Atau apakah saya harus memukulnya?
Saya ingin mengambil bahasa sistem yang tidak memerlukan dependensi nol, sehingga saya bisa meletakkan biner yang akan menimbang, secara kondisional, kurang dari satu megabyte, dan bekerja dengan overhead yang minimal.
Oleg : Kamu bisa mengambil Golang, setidaknya ada pengumpul sampah.
Artyom : Itulah mengapa saya ingin mencoba Rust. Dan itu berhasil. Plus, Golang agak sedih dengan obat generik.
Eugene : Karena mereka mulai membahas bahasa ... Dalam konteks pengembangan Android, pertanyaan "Kotlin atau Java" sudah lelah, tetapi saya masih akan menanyakannya untuk melanjutkan ke pertanyaan berikutnya.
Artyom : Ya, Kotlin, tentu saja.
Eugene : Sekarang pertanyaan yang sangat menarik. Baru-baru ini, di Kotlin, coroutine menjadi stabil, dan suara-suara "Hore, ayo menjauh dari RxJava" terdengar. Karena itu, ketika saya melihat seseorang di depan saya yang sangat dekat dengan RxJava, saya langsung ingin menanyakan pendapatnya tentang coroutine.
Artyom : Saya sangat negatif terhadap coroutine. Pada prinsipnya, sebagian besar masih negatif, tetapi ini telah sebagian mengubah pembicaraan yang sangat panjang dengan
Roma Elizarov , yang sedang mengerjakannya.
Sebagai pengguna program, saya ingin mereka menjadi non-blocking mungkin, menggunakan sumber daya seakurat mungkin. Maksud saya paralelisme dan fakta bahwa mereka menggunakan API sistem operasi yang benar untuk akses non-pemblokiran ke jaringan atau file - ada banyak masalah dengan ini dalam sistem operasi, tetapi, bagaimanapun, ada API semacam itu. Apa sebenarnya yang dipecahkan ini? Sebagai pengguna, itu tidak masalah bagi saya - jika hanya pengembang yang akan memecahkan masalah ini dengan cara yang membuat mereka nyaman. Saya tidak punya masalah besar dengan ini. Dan ini adalah visi Roma Elizarov. Setelah percakapan ini, saya entah bagaimana melepaskannya.
Sebelum ini, seperti teman saya
Arthur Dremov , sepertinya
saya mundur setelah beberapa tahun menggunakan Java dalam produksi: kode kembali menjadi keharusan, tidak bersih, kehilangan pemahaman tentang pipa, lagi-lagi menjadi berantakan, yang membuat kompiler berubah menjadi kekacauan asinkron untuk Anda.
Saya tidak menggunakan coroutine, tetapi semua contoh yang sekarang saya amati telah beralih ke pendekatan terstruktur, ketika Anda bahkan tidak melihat kode mana dari ini yang coroutine. Sejujurnya, saya sangat takut melihatnya. Karena saya membuka permintaan tarikan di GitHub, beberapa metode dipanggil untuk mengunggah gambar dan profil, salah satunya masuk ke jaringan, dan yang lain pergi ke SQLite lokal, dan di sini SQLite lokal dapat dengan mudah diblokir. Saya tidak melihat ini dalam kode, karena coroutine dibuat sehingga Anda tidak melihatnya. Mungkin bagus, tapi bagi saya ini masih minus desainnya, karena dalam pendekatan Rx sangat jelas: apakah Anda mengerti apakah ini bagian dari pipa sinkron atau tidak.
Mungkin ini satu-satunya keluhan saya terhadap coroutine: Saya ingin melihat kapan asynchrony saya terjadi, dan ketika tidak. Idealnya, saya ingin orang-orang menulis kode yang lebih fungsional ketika ada potongan-potongan kecil yang dapat digunakan kembali, atau setidaknya potongan-potongan yang dapat diuji yang menggabungkan dengan yang lain. Dan kita kembali ke fakta bahwa inline semuanya ke dalam logika, dan kemudian kompiler kemudian membaliknya.
Oleg : Biarkan saya memberi Anda sedikit oposisi. Kode lama lebih dari sekadar kode baru. Dan jika kita mengambil beberapa hal seperti bekerja dengan jaringan, bekerja dengan file, dan sebagainya, maka tidak ada yang akan dengan cepat menulis ulang semua ini, misalnya, menggunakan RxJava. Dan jika kita memiliki autocoroutine, maka kita dapat, misalnya, melacak semua syscalls, secara otomatis membungkusnya dan mengirimkannya ke kunci untuk parkir.
Artyom : Benar, dalam hal apa pun, Anda harus memanggil fungsi dari konteks corutin. Tapi ini pemikiran yang menarik, ya.
Oleg : Mungkin keduanya harus dikombinasikan? API tingkat atas akan berada di RxJava, dan API tingkat rendah di coroutine.
Artyom : Ya, sekarang ada pergeseran seperti itu. Tetapi kemudian muncul pertanyaan, karena saat ini, RxJava dapat melakukan semua yang dilakukan coroutine, dan coroutine tidak dapat melakukan semua yang dilakukan RxJava. , — . , , , - Rx Kotlin. . forEach - map, . , , Java- , . .
, Kotlin — . , Go , , API, , : . , , , , legacy, , . , Java Kotlin — legacy, , . , . - , .
, , . , , , — . .
: , . , , : Android-? , .
: … . , Android- . , . , : , . RxJava , : - . , , .
, iOS. , Lyft iOS- dependency injection RxSwift. 2019-. iOS-, , , clean, . , Android — .
, , — Google. « opinionated, , : , , ». — , , .
, «RxJava — , ...» : «, LiveData». , — RxJava, , . , , Google , .
: «, Google MVVM». , MVVM , , , MVVM . , Google.
, , scope . .
: , Room . - Architecture Components — , . Google , ? .
: , . , . !
: .
Mobius berikutnya akan diadakan di St. Petersburg pada 22-23 Mei . Sekarang programnya belum diumumkan, tetapi ini adalah momen paling menguntungkan untuk membeli tiket: pada 1 Februari, harga tiket akan naik. Dan juga, karena programnya belum selesai, momen ini juga cocok untuk masuk ke dalamnya sendiri: kami siap menerima aplikasi untuk laporan. Semua informasi tentang konferensi dan tiket ada di situs .