Bagaimana menjadi seorang programmer dari keputusasaan dan naik ke puncak kesuksesan? Hari ini di studio virtual kami Pasha asm0dey Finkelstein menjawab pertanyaan. Pasha adalah salah satu dari sedikit yang tahu cara membuat backend di Kotlin. Selain itu, ia melihat open source, berpartisipasi aktif dalam kehidupan komunitas, dan, sebentar saja, ia telah menghadiri hampir semua konferensi Jawa Moskow kami.

Bagaimana menemukan waktu untuk melakukan

- Ada beberapa topik yang bisa dibahas. Pertama, Anda memberi ceramah di Joker. Kedua, Anda adalah anggota aktif komunitas, terus melakukan sesuatu. Ketiga, Anda terus-menerus menghadiri konferensi kami dan untuk beberapa alasan Anda berpikir bahwa ini baik.

- Mengenai fakta bahwa saya adalah anggota komunitas. Saya, seperti kebanyakan orang, menderita sindrom penipu, saya tidak punya perasaan bahwa saya melakukan banyak hal berguna, terutama untuk masyarakat Jawa, terutama baru-baru ini. Hal terakhir yang saya lakukan bermanfaat bagi komunitas - saya dan orang-orang menulis perpustakaan keren untuk Spring yang disebut spring-flow-state-machine , yang memungkinkan Anda untuk mengontrol keadaan objek dalam aplikasi. Dia kecil dan nyaman.

- Ini adalah perpustakaan yang sekarang mempromosikan di Spring utama?

- Tidak, mungkin Spring Statemachine ada di sana, dan itu sangat menyedihkan: itu ditulis dengan sangat buruk, ia bekerja sangat aneh dan sama sekali tidak melakukan apa pun. Statemachine Musim Semi mengelola keadaan aplikasi ketika aplikasi Anda adalah semacam statemachine terbatas dan bekerja secara berbeda di negara bagian yang berbeda. Kami melakukan hal lain: ketika Anda memiliki semacam entitas, Anda menetapkan siklus hidup untuk itu dan Anda bisa mengendarainya melalui siklus hidup ini. Dan tugas kami adalah memikirkan cara kerja transaksi Anda dan semua itu. Kami hanya memiliki anotasi @Transaksional di satu tempat yang tepat, seperti yang Anda tahu, dan ini cukup bagi kami untuk mengatakan bahwa ia mengontrol keadaan. Yang utama adalah bahwa ada DSL nyaman yang memungkinkan Anda untuk mengatakan di mana Anda dapat dari mana dan apa yang perlu Anda lakukan di sepanjang jalan.

"Dan aku mengerti dengan benar bahwa karena benda ini mengendalikan hal-hal abstrak, dapatkah kau melakukan hal yang sama seperti yang dilakukan Spring Statemachine?"

- Ya benar, ada nuansa. Entitas utama yang dikendalikan hal ini adalah, sepertinya, entitas dengan id atau sesuatu seperti itu. Ini benar-benar perpustakaan yang sangat kecil dari dua antarmuka, dua exception'ov dan empat kelas.

"Dan hal yang dilakukan Spring - mengapa Anda berpikir ini adalah sesuatu yang aneh dan mengapa tidak jelas mengapa?"

"Dapat dimengerti mengapa itu perlu, itu hanya dilakukan dengan sangat buruk. Dinyatakan seolah-olah tahu bagaimana melakukan segalanya. Pertama, contoh yang mereka miliki dalam dokumentasi tidak dikumpulkan, dan kedua, jika Anda mencoba menggali kode sumber (dan Anda selalu menggali kode sumber Spring ketika Anda ingin melakukan sesuatu, karena tidak semuanya tertulis dalam dokumentasi), Anda mengetahui bahwa itu ditulis dengan cara yang lebih baik untuk tidak menulis. Omong-omong, tampaknya Spring Batch biasanya memiliki keluhan yang sama.

"Apakah kamu menggunakan Spring Batch juga?"

- Sepertinya saya menggunakan hampir semua yang ada di ekosistem Spring.

"Dan bagaimana kamu terus menggunakannya?"

- Anda tahu, di tempat kerja berikutnya saya tidak akan memiliki Spring, saya akan memiliki DIA. Itu bukan pilihan saya. Saya mungkin akan menggunakan Spring, tetapi sebenarnya, di podcast kami, saya pernah berkata bahwa sekarang favorit saya adalah mikro- Jooby, yang tahu segalanya. Itu ditulis dalam satu orang oleh beberapa juara Jawa. Ada juga injeksi ketergantungan, yang dibangun di atas Guice. Keren, ia memiliki ekosistem, tidak seperti, omong-omong, dari semua mikroframe lainnya.

- Saya melihat bahwa ada dua opsi - untuk Jawa dan untuk Kotlin.

"Aku curiga kamu bisa melakukan apa saja." Scala mungkin juga mungkin, tetapi Anda harus meninggalkan Guice, yang mungkin tidak bekerja dengan Scala. Saya, seperti biasa, suka injeksi konstruktor dengan anotasi. Dan ini dilakukan di Guice.

- Dan jika aplikasi seperti itu dapat dirakit secara statis menggunakan GraalVM, itu hanya ruang.

"Saya kira Anda tidak akan menang banyak di sana." Ini seperti Spring - tentu saja, Anda akan memenangkan sesuatu dalam performa.

- Tingkatkan kecepatan startup, misalnya.

- Tentu saja, dalam produksi kami akan menyeret beberapa hal kecil yang ditulis oleh satu juara Java, dan kami akan berjuang untuk kecepatan startup di sana!

- Begitu.

- Mungkin orang-orang yang benar-benar peduli dengan kecepatan startup mengambil beberapa Azul Zing dan menyelaraskannya dengan sesuatu yang tertulis di telanjang SE.

"Apakah saya mengerti benar bahwa perpustakaan yang Anda tulis adalah sumber terbuka dan semua itu?"

- Ya, itu adalah open source dari majikan saya sebelumnya dan entah bagaimana miliknya, seperti yang digunakan dalam draft kerja.

- Begitu. Artinya, Anda menulisnya selama jam kerja.

- Ya, mereka menulis selama jam kerja.

- Dan bagaimana menurut Anda, apakah ada prospek untuk menulis perangkat lunak setelah jam kerja?

- Saya menulis perangkat lunak setelah jam, meskipun sekarang ini bukan perangkat lunak yang nyata. Dan hal terakhir yang saya tulis ... sekarang di Rusia masalah dengan kunci adalah aktual, dan bagi saya masalah yang mendesak adalah untuk memotong kunci ini. Ada server proxy luar biasa bernama 3proxy , jadi saya menulis buku pedoman yang memungkinkan untuk Fedora, Ubuntu, Debian dan Centos, menguji semuanya, dan membagikannya di GitHub. Dan di Ansible Galaxy, juga dibagikan.

"Dan di mana kamu menemukan waktu untuk itu?"

- Saya, seperti semua orang, memiliki masalah dengan waktu, karena saya lelah di tempat kerja, saya punya keluarga, saya harus menghabiskan setidaknya beberapa waktu dengan keluarga saya. Tetapi pada akhir pekan keluarga tidur larut malam, dan saya suka tidur dan bangun lebih awal, kepala saya bekerja dengan baik di pagi hari, dan saya dapat melakukan banyak hal. Terkadang saya menulis sesuatu bahkan sebelum bekerja.

- Apa yang akan Anda sarankan kepada mereka yang ingin mulai menulis sesuatu di sumber terbuka, tetapi tidak berhasil?

- Tanyakan pada diri sendiri mengapa itu tidak berhasil. Dan tergantung pada jawaban untuk pertanyaan itu, cobalah untuk menulis sesuatu.

- Ada jawaban standar: tidak ada waktu, tidak jelas di mana saya membutuhkannya.

- Adapun "tidak ada waktu", itu terjadi bahwa benar-benar tidak ada waktu, tetapi itu terjadi bahwa benar-benar tidak ada waktu. "Tidak ada waktu" adalah cara untuk mengatakan bahwa saya tidak punya motivasi. Ini benar-benar jelas, dan bukan fakta bahwa ini harus diperangi. Tidak semua orang diharuskan berkomitmen untuk open source. Ini adalah cara yang keren untuk melakukan sesuatu untuk diri sendiri dan untuk masyarakat, tetapi tidak ada yang berutang apa pun kepada siapa pun.

Jika tidak jelas siapa yang membutuhkan Anda, pertanyaannya, lagi, mengapa. Ada dua alasan: Anda masih memiliki sedikit waktu untuk melakukan hal seperti ini dalam pemrograman, dan bagi Anda tampaknya ini adalah sesuatu yang sangat membosankan, dan kemudian mungkin benar, pada tahap ini Anda tidak dapat membantu siapa pun. Meskipun saya mengenal orang-orang, misalnya, Slava Semushin - hal pertama yang dia lakukan - dia mulai menyelundupkan di Alt Linux sebelum dia mulai memprogram suatu tempat dalam produksi. Itu jalannya ke pemrograman (ini adalah lelucon, tentu saja). Tapi dia benar-benar tidak mengerti apa-apa, ketika dia mulai, dia mengerti sepanjang jalan. Dan ini bukan lagi lelucon.

Kebetulan orang-orang terlibat dalam usaha untuk waktu yang lama dan tidak mengerti apa yang bisa mereka lakukan. Saya telah berada dalam situasi ini untuk waktu yang sangat lama. Sekitar 4 tahun yang lalu pasti. Saya telah di perusahaan selama 6 tahun dan tidak mengerti apa yang bisa saya lakukan. Namun seiring berjalannya waktu, saya melihat bahwa komponen yang satu ini dari sistem yang ingin saya tulis ulang, pada prinsipnya, dapat dipisahkan menjadi modul yang terpisah dan terlalu terasa. Ini harus disetujui oleh majikan. Yang utama adalah mengambil langkah pertama.

Terkadang majikan tidak ingin berkoordinasi, ini adalah topik yang cukup hidup. Sebagai contoh, Tinkoff tidak ingin membuka beberapa komponen backendnya, meskipun secara teoritis bisa.

Anda mulai melihat peluang dengan waktu. Yang utama adalah mengisolasi ini menjadi komponen yang terpisah. Jika majikan tidak mengizinkannya, Anda akan menggunakannya di dalam majikan, akan ada sumber terbuka internal, seperti yang mereka lakukan di beberapa Zalando. Kemudian pada proyek selanjutnya Anda akan melihat bahwa hal ini dapat dibedakan juga.

- Wow. Atau tulis lagi, misalnya.

- Tentang "tulis lagi." Salah satu masalah yang akhirnya kami selesaikan adalah pencatatan. Jelas bahwa semua krupnyaki bingung dengan penebangan terpusat, tanpa kehidupan ini sama sekali. Solusi standar untuk ini adalah tumpukan ELK, ElasticSearch, Logstash, Kibana. Hanya ada masalah kecil - ini adalah Logstash. ElasticSearch, Kibana berfungsi dengan baik, tetapi Logstash tidak. Entah itu tidak bekerja terus-menerus, atau sangat lambat. Jika tidak bekerja terus-menerus, maka ukuran antrian untuk itu adalah 5.000 pesan. Lebih dijejalkan - pesan mulai turun. Singkatnya, fitur yang tidak menyenangkan. Karena itu, kami memiliki Kafka, bukan dia. Di Sberbank, kami menulis append Kafka logback kami sendiri, yang juga open source dan bekerja dengan baik untuk dirinya sendiri.

- Jadi, siapa itu!

- Sudah ada tiga, saya tidak yakin apa yang Anda lihat.

- Oke. Kembali ke topik open source dan logging. Dan mengapa orang menggunakan penebang terpusat di perusahaan terus-menerus, coba menulis sendiri, jika ada Linux dan cara-cara yang diciptakan oleh kakek - mengunggah semuanya ke file, misalnya?

- Saya tidak tahu di Linux normal logging terpusat. Ada rsyslog, yang merupakan format yang baik, tetapi, dengan kata lain, itu tidak diadaptasi, misalnya, ke Jawa, karena jika Anda melihat beberapa jenis stack track, tiba-tiba ternyata stack track itu banyak baris, bukan hanya satu. Jadi di rsyslog ini akan menjadi entri log yang terpisah. Jika semua ini tercampur dalam satu tumpukan besar, menurut saya itu akan melukai semua orang.

- Ya, mungkin.

- Dan saya jujur ​​tidak tahu jaminan apa yang disediakan rsyslog. Saya biasanya macet ketika saya memiliki beberapa solusi, saya mencoba mencari tempatnya di teorema CAP. Dan saya tidak menemukan informasi ini di rsyslog, mungkin saya terlihat buruk. Tetapi dengan cepat saya tidak bisa menentukannya. Dia umumnya menjamin pengiriman kepada kami dan untuk berapa lama? Stempel waktu apa yang akan ada ketika dia ada di suatu tempat? Jika dia menjamin, ini sudah baik, jika Anda biasanya log dengan semua jenis bentang dan jejak, maka Anda masih akan mengetahuinya, tidak peduli apa yang dia lakukan di sana. Jika tidak menjamin pengiriman, ini benar-benar bencana. Dalam hal ini, saya lebih mempercayai kafka, tetapi memiliki lebih banyak bandwidth. Ini terlepas dari kenyataan bahwa saya tidak mengenal Kafka dengan baik, jujur ​​saja.

- Di sana Anda perlu entah bagaimana membagi, mungkin, log menjadi kritis / tidak kritis, karena jika server logging macet, Anda tidak akan pernah tahu apa yang terjadi.

Sementara kita berbicara tentang Jawa, semuanya sangat sederhana. Kami menjalankan di beberapa Docker dan kami memiliki log di stdout dimasukkan dari tingkat ERROR. Dan semuanya mulai mengalir ke Kafka, mulai dari debug atau dari trek. Saya adalah tipe orang yang log debitnya biasanya tidak pernah dimatikan. Saya tidak pernah hidup untuk melihat saat yang cerah ini, ketika saya menyadari bahwa itu semua, saya tidak menggunakan logging lagi untuk menganalisis masalah.

"Apakah Anda tidak takut bahwa throughput, misalnya, dari jaringan Kafka hanya akan mengambil dan berakhir jika semua terabyte log ini terbang ke sana?"

- Kami selalu terlalu kecil, kami memiliki 100 GB log per hari, dan 100 GB - berapa volume ini? Masalah utama adalah bagaimana menyimpannya, bukan bagaimana mentransfernya. Apakah Anda benar-benar memiliki log terabyte?

- Saya tidak tahu berapa banyak dalam hal penyimpanan pada disk, tetapi saya tahu bahwa kadang-kadang sistem mulai sangat lambat sehingga kami tidak menunggu untuk memulai. Seseorang secara tidak sengaja melakukan debug, atau melacak, dan itu saja.

- Tunggu. Sepertinya saya, atau apakah Anda salah jalan ketika Anda membuat log sinkron, melalui jaringan?

- Tidak, mereka baru saja menuangkan ke dalam Kafka.

- Tapi serentak? Tidak mungkin Anda memiliki opsi untuk melakukannya secara tidak sinkron, Anda harus menunggu ACK dari Kafka dari setidaknya satu node, bahkan jika Anda benar-benar keras kepala dan Anda tidak ingin jaminan pada log. Setidaknya satu ACK Anda masih menunggu.

- Mungkin iya.

- Saya katakan itu karena kami menulis append logback, saya mengerti apa yang kami pandu. Tapi kami membungkus append ini dalam AsyncAppender, dan kemudian secara eksperimental menghitung berapa banyak pesan yang kita miliki di puncak, dan buffer dalam AsyncAppender ini diputar sedikit lebih, seperti ada puncak ditambah 10%. Ternyata aplikasi kami tidak diblokir.

"Cerita-cerita mengerikan yang kau miliki." Dan mengapa ini bukan standar di Jawa, mengapa Anda harus menulis dengan tangan Anda?

- Karena Anda harus menulis dengan tangan dalam semua bahasa, hanya di Jawa, paling tidak harus jelas di mana harus menulis. Dan jika Anda mengambil plus, saya tidak tahu harus mulai dari mana.

- Jadi menurut Anda tidak ada perpustakaan yang dapat ditambahkan ke Maven, dan semuanya akan diinstal dengan sendirinya?

- Mari kita mulai dengan fakta bahwa mereka tidak memiliki Maven normal, karena mereka memiliki Ninja, Make, CMake, qmake dan semuanya sedikit berat dengan Maven. Tentu saja, mereka memiliki perpustakaan untuk dicatat, mereka berada di Jawa, dan sudah jelas bagaimana cara melampirkan lampiran ke mereka. Selain itu, di Jawa mereka indah, fleksibel, biasanya bekerja dengan fasad dan semua itu. Dan jika Anda melihat beberapa Karat, ada sesuatu yang sangat menyedihkan. Saya tidak tahu di mana harus meletakkan dan mencatat penebang saya. Saya hampir tidak menguasai cara mengkonfigurasi mereka.

"Jadi, kamu benar-benar menyukai Jawa?"

- Saya suka ekosistemnya. Saya suka Kotlin sebagai bahasa dan Jawa sebagai ekosistem. Ngomong-ngomong, tidak ada satu bahasa pun yang lebih baik dari Kotlin, saya tidak tahu sama sekali sekarang. Begitu saya terjebak di Groovy, saya bahkan punya T-shirt dari Baruch dengan tulisan Groovy.

Kenapa Kotlin?

- Memilih antara Java, Scala, Groovy dan Kotlin - mengapa tepatnya Kotlin?

- Kombinasi sempurna sintaksis yang baik dan kompleksitas untuk menembak diri sendiri di kaki. Saya tidak suka batu, karena sangat mudah menembak di kaki, dan kadang-kadang bukan untuk diri sendiri, tetapi untuk tetangga Anda. Anda menambahkan variabel implisit, semuanya bekerja secara ajaib untuk Anda, dan neraka ada di debug-nya. Anda bisa, tentu saja, setuju untuk tidak menggunakannya, maka Anda kehilangan sebagian dari pesona Rock. Tentu saja, jika Anda benar-benar pintar, Anda menggunakan makro di Rock dan tidak seorang pun kecuali Anda mengerti cara kerjanya.

- Di Batu menyelesaikan makro, ternyata?

- Saya ingin mengatakan bahwa mereka berfungsi, tetapi saya tidak ingin mengatakan bahwa mereka dapat digunakan. Dan jika Anda bahkan lebih pintar, maka Anda menggunakan perpustakaan seperti Kucing. Tapi ini mungkin pada tingkat yang sama ketika Anda menjadi sedikit lebih pintar dan Anda sudah bosan menggunakan scalaz, dan Anda menggunakan Kucing. Tetapi tidak ada yang bisa membaca kode ini kecuali Anda.

- Dan penganut Kucing lainnya.

"Kamu mengatakan itu seperti itu benar, tapi itu tidak benar, karena penganut Kucing lainnya menggunakannya secara berbeda."

- Ini adalah bagian dari kekuatan sistem ini.

- Sangat kuat, mengingatkan pada BFG .

- Yang Anda tembak di kaki Anda.

"Terkadang untuk dirimu sendiri, terkadang untuk orang lain, betapa beruntungnya." Ngomong-ngomong, saya perhatikan bahwa orang-orang yang menulis di Batu terkadang lupa untuk berpikir. Mereka memiliki konsep yang begitu indah sehingga mereka dapat membuat 2 sisipan berturut-turut di tempat yang berbeda dan tidak memikirkan fakta bahwa semua ini perlu dibungkus dalam suatu transaksi. Tetapi mereka memiliki panggilan indah ke database dengan beberapa licin (atau apa pun yang sekarang modis untuk bekerja dengan SQL di Scala).

- Tapi Anda bisa melakukannya di dua tempat di Jawa ...

- Tetapi di Jawa, saya memiliki Spring, dan saya meletakkan anotasi @Transaksional. Di Jawa tidak lazim melakukan hal-hal rumit. Di Kotlin, tampaknya, omong-omong juga. Tapi di Batu diterima. Adapun Groove, ini adalah bahasa yang keren, tentu saja, sampai Anda masuk ke bytecode di satu sisi atau menemukan fakta bahwa Anda tidak mengerti apa jenis objek yang Anda miliki. Mereka juga kadang-kadang suka berteriak bahwa kode Java yang valid adalah kode alur yang valid, tetapi ini tidak benar karena kelas-kelas dalam anonim tidak berfungsi di sana. Anda tidak dapat mengambil dan membuat instantiate. Anda harus membuat lambda dan kemudian melemparkannya. Jadi saya memilih Kotlin, ini memiliki sintaks yang sedikit berbeda dari di Jawa, tetapi ada konverter di sana jika Anda benar-benar ingin. Di sisi lain, tidak ada kompleksitas baru. Tidak ada yang bisa Anda klik ctrl pada sesuatu dan tidak pergi. Anda ctrl-klik pada double sama dengan dan beralih ke metode sama dengan.

- Momen licin: apakah Anda mempercayai JetBrains? Sekarang banyak yang tidak terlalu mempercayai Java, karena itu adalah Oracle, tetapi apa yang harus dilakukan dengan JetBrains? Apakah orang normal duduk di sana, mengembangkan bahasa?

- Saya tidak ingin merusak sepotong laporan, tetapi secara keseluruhan saya suka cara mereka berkata, dan saya suka apa yang saya lihat. Saya tidak punya opsi "tidak percaya". Oke, well, saya tidak percaya JetBrains, maka semuanya menjadi sangat sedih, karena bahasa apa yang kita kembangkan oleh beberapa orang yang relatif waras? Mungkin Rust (dikembangkan oleh Mozilla), Golang dikembangkan oleh Google. Plus, mereka semua dikembangkan oleh komunitas, termasuk bahkan Jawa. Tidak jelas siapa dan mengapa Anda bisa percaya. Saya memiliki masalah dengan paranoia, saya tidak tahu bagaimana melakukannya.

Pada hari pertama konferensi Joker (19-20 Oktober 2018), Pasha akan berbicara tentang backend di Kotlin dalam laporan "Kotlin - 2 tahun dalam produksi dan tidak ada celah" . Joker adalah salah satu konferensi utama kami, dan kami terus-menerus menulis tentang hal itu di Habré. Jika memungkinkan, pastikan untuk datang.

- Baru-baru ini, Baruch dan saya menemukan studi tertentu pada topik Kotlin, yang menunjukkan bahwa program di Kotlin dengan 40 burung beo mereka (beo studi) lebih baik daripada program di Jawa.

- Tidak lebih baik, tetapi singkatnya, jika ingatanku benar.

- Ada keduanya lebih pendek dan lebih baik. Mereka mengukur semuanya dalam bau kode. Saya tidak tahu bagaimana mengatakannya. Mungkin, dalam arti tertentu, ini bisa digantikan dengan kata "lebih baik."

- Luar biasa. Sekadar tahu, dalam perbandingan kedua bahasa itu, ada satu masalah kecil. Apakah mereka menyadari tugas yang sama dan apakah ada alat pengukur yang sama? Benarkah kode tebal mengukur kualitas yang sama di Jawa dan Kotlin? Atau apakah mereka menulis 20 tahun terakhir di Jawa dan belajar bagaimana menemukan kode pasangan 800, dan di Kotlin mereka menulis 2 tahun dan belajar menemukan 20?

- Wow, ini pertanyaan yang sangat bagus. Tapi di sana, bukan angka yang mereka simpulkan yang menarik, tapi pertanyaan apa yang mereka hadapi. Hanya ada 5 dari mereka, saya juga ingin bertanya. Apa tingkat adaptasi Kotlin di area mana saja? Itu tergantung pada berapa banyak orang yang bekerja dengan Anda, berapa banyak proyek, berapa banyak contoh.

- Jelas bahwa semua Android hampir pindah ke Kotlin (perkembangan modern), dan backend bergerak sangat lambat. Salah satu tujuan laporan saya adalah mempercepat proses ini. Ketika saya datang ke HH untuk wawancara dan mengatakan bahwa selama dua tahun terakhir saya telah menulis backend di Kotlin, mereka mengatakan kepada saya, apakah mungkin? Ini hanya untuk ponsel! Pengusaha benar-benar tidak tahu bahwa ini mungkin. Mungkin, karyawannya juga tidak tahu. Sulit untuk berbicara tentang jumlah adaptasi, saya pikir di Android 80-90%, dan di backend - maksimum 10 persen, mungkin. Ya, benar-benar 10! Jika Anda menghitung semua sistem lawas, tidak akan ada dua persen. Tetapi jika Anda hanya menghitung proyek baru, maka mungkin 10 persen.

- Artinya, setidaknya hal seperti Kotlin di backend sudah ada?

- Ya, saya menulis di Pusat Real Estat dari Sberbank. Dan sebelum itu, dia juga menulis.

- Bagus Sederhananya, banyak yang mengatakan bahwa ini adalah pemasaran JetBrains, dan orang yang masih hidup akan bereaksi secara berbeda terhadap hal ini.

- Bagian dari laporan saya dikhususkan untuk fakta bahwa sebagai hasilnya, seluruh bagian Jawa perusahaan mulai beralih ke Kotlin setelah proyek kami berhasil terbang.

- Jadi, pertanyaan selanjutnya muncul lebih lanjut: berapa persen kode pada Kotlin adalah aplikasinya? Pertama, Anda bisa mencampur Jawa dan Kotlin sebagai basis. Kedua, Kotlin dapat digunakan sebagai DSL dan mulai menulis ulang semuanya secara berurutan.

- Dari sudut pandang saya, ada beberapa situasi di mana Anda perlu dengan sengaja mengganggu Jawa dan Kotlin. Masuk akal untuk menulis seluruh proyek di Kotlin. Mungkin jika Anda merasa bahwa Anda akan menerjemahkan seluruh aplikasi ke Kotlin, Anda dapat mulai menulis kelas-kelas baru di Kotlin dan kemudian di beberapa titik mulai mengubah kelas-kelas lama dari Jawa ke Kotlin dan memotongnya dengan pena. Tetapi saya harus mengatakan bahwa "Java2Kotlin" adalah alat yang begitu-begitu, tidak sempurna.

- Dengan "Java2Kotlin" maksud Anda Ctrl C - Ctrl V dalam Ide antar file?

- Ya, tapi masih ada semacam jalan pintas, mungkin.

- Ngomong-ngomong, saya pernah mencoba untuk Scala menggunakan persis Ctrl C - Ctrl V di Idea, tapi ternyata ada sampah langka sebagai hasilnya.

"Saya juga tidak suka apa yang dilakukan Java2Kotlin." Saya menulis lebih baik. Terkadang Anda bisa mulai dengan ini, tentu saja. Anda memiliki dua cara: Anda mengonversi seluruh proyek, terutama jika tidak terlalu besar, dan kemudian Anda memperbaiki semua tempat yang salah. Atau Anda melakukannya menurut salah satu klasik: menulis ulang dengan tangan Anda untuk waktu yang sangat lama, banyak pekerjaan mekanis. Tetapi Anda mungkin ingin memulai suatu tempat.

- Apakah ada jenis komplikasi di sana, terhubung bukan dengan sintaks yang bodoh, tetapi dengan bagian semantik?

- Tampaknya saya akan membicarakan hal ini dalam laporan.

- Bagus Ketika Kotlin ditambahkan ke proyek, apakah jumlahnya meningkat atau turun? Berapa banyak Kotlin baginya untuk mulai melahap segalanya?

"Aku tidak punya pengalaman seperti itu." Kami segera menulis aplikasi di Kotlin, kecuali satu kasus. Apakah Anda dibimbing oleh ekosistem plugin untuk Ide?

- Sedikit.

— , , , - . - , , , , , .

— Community Edition , , .

— Community Edition , Ultimate.

— Ultimate , Spring-.

— , , Spring-, .

— -, , endpoints, , .

— . endpoint', ?

— , . , , .

— , , Shift-Shift-Shift, - , Shift-Shift-Shift , , endpoint' , . , - .

— , Search Anywhere, .

- Jadi , , . . , , , . , , , , , , , , .

— , ?

— , . , , , .

— . , , , . . , , , , .

— , , , , , , , , , . . , -. . , , . Java-, . generic , , invariants, in. . . , , . , . , Haskell, ? : map, fmap, .

— .

— : , , . , — sequence. — , .

, , , - . GraalVM , , . , @graalvm_ru.

— ?

— . 2, 2 2 . .

— , . , .

— - . : for- , for-, ( baseline), . 2 6 . , — : sequence' sequence'. , , - . . . , . , , , baseline.

— , ?

— , - .

— , , GraalVM .

— . JDK10 JVMCI , GraalVM EE, , C2.

— - , Community Edition -Community Edition, , .

- Tidak. , , . . , , , .

— ! :-)

— , .

« »

— . : . , . : ?

- Tidak. . « ». , , , , : , , , . 2008 , , , . , . , , . .

— ?

— 4 C++ Builder, Java, , -, , . Java , C++ Builder, , , C++ Builder, . . , . , , , .

— — VCL, .

— , . , - , - . - , SQL, . , , .

— C++.

— , Java, . C++ - , , , , , . MVC. , NetBeans, , . , , . GroupLayout BorderLayout. , , , , . , , -.

— , IDE-?

— . , , - Electron.

— . , Java.

— , . - - : JavaScript. .

— GraalVM , Electron JavaScript -.

— . , , , . Nashorn . Truffle- JavaScript? , .

— , , Nashorn, . Electron, .

— , ?

— , Electron.

— ?

— Node.js, Graal Node.js, . .

— ?

— . - .

— . — Node.js, Electron Builder, SQLite ORM . , , — SQLite — 10 . -, , . .

— , , , .

— . . , Java FX, , , , 10- . , JRE, . , — , . , -. , - , .

— , .

— - , - , . -, .

— - desktop environment , , -. , - to do list, - . , , , , . , , , . — F1, .

— , , . - – CLI-. , Task Warrior, . , .

— « ». , , , - . ?

— , ?

— .

— , .

— -. , ?

— , : «, , ?» : «». , - . - , - , . : « ?» , . : «, . , ?» «». « , ».

— : , , . ? , - ?

— , , , : . (5 , ), , - , , , , . , , , - , , , , .

— , , — , , ? , , ?

— , - . , . , . . , . . .

— : - , , - — SQL , . .

— ? — . , . — . - , , . .

- Ngomong-ngomong! Anda tahu banyak hal menarik dan Anda bisa mengetahuinya. Mengapa Anda tidak di konferensi kami setiap tahun dengan beberapa laporan baru?

"Kurasa aku tidak tahu cukup banyak untuk diceritakan banyak."

"Tapi kamu masih datang!"

- Kebetulan saya memiliki keahlian yang kurang lebih unik untuk industri ini. Sangat sedikit yang benar-benar menulis backend di Kotlin. Tampaknya tidak ada dari mereka yang ingin membicarakannya. Dan mereka mungkin tidak memiliki aliran penginjilan ini. Saya selalu memiliki keinginan untuk mengajar orang lain cara hidup (atau setidaknya mencoba). Karena itu, tentu saja, saya tertarik. Selain itu, saya sendiri agak tertarik pada laporan ini, karena majikan berikutnya, kepada siapa saya akan datang dan meminta untuk menulis di Kotlin, akan berkata: "Mengapa?", Saya akan mengatakan bahwa sekarang, saya membuat laporan di Joker ayo kita lihat.

- Bagaimana merumuskan momen ketika Anda memahami bahwa Anda memiliki keahlian yang cukup untuk membuat laporan?

- Tidak mungkin. Laporan dibuat bukan karena Anda memiliki keahlian, tetapi karena Anda memiliki pengalaman dan keinginan untuk membicarakannya. Saya memiliki keinginan untuk memberi tahu sejak pertama kali saya tiba di JPoint. Tetapi topik yang disengaja "untuk menceritakan" saya belum begitu lama. Topik yang sedemikian rupa sehingga Anda dapat berbicara sekitar 45 menit.

Mengapa pergi ke konferensi?

- Mengapa mengadakan konferensi? Mengapa mereka dibutuhkan? Dari fakta bahwa Anda biasanya mendatangi mereka, ternyata Anda membutuhkannya.

- Tidak, dari kenyataan bahwa saya pergi ke mereka, ternyata hanya saya yang mendatangi mereka.

"Tapi apakah kamu membutuhkannya karena suatu alasan?"

- Saya tidak tahu seberapa jujur ​​saya siap menjawab pertanyaan ini. Saya tidak yakin saya pergi ke konferensi untuk mendapatkan informasi. Di satu sisi, saya pergi ke konferensi sehingga Anda mengenal saya.

- Ini adalah ide yang normal.

- Ketika saya mengatakan "kamu", maksud saya banyak orang yang mengingat saya. Secara umum, berguna bagi saya bahwa pasar mengenal saya hanya dari segi nilai saya, terutama jika saya membuat kesan yang baik. Dan saya mencoba melakukan ini, karena saya sepertinya tidak tahu banyak, dan saya selalu kekurangan pekerjaan yang menarik. Saya terus mencari pekerjaan yang lebih menarik. Jarang sekali sesuatu muncul yang tampaknya lebih menarik daripada yang saya miliki sekarang.

Di sisi lain, saya pergi ke sebuah konferensi untuk naik ke usus. Tidak ada peluang seperti itu di mana pun. Saya pergi untuk mendengar tentang bagaimana Azul Zing bekerja, karena itu menarik. Ya, saya hampir tidak bisa menggunakan pengetahuan ini, tapi itu menarik. Ini sulit dibaca dalam buku. Saya punya masalah lain: Saya sedikit membaca buku. Saya lebih suka membaca fiksi. Saya mungkin salah satu dari sedikit di antara beberapa teknisi serius yang hidup seperti ini. Saya membaca referensi, kertas putih, tetapi hampir tidak pernah membaca buku. Dan dalam referensi dan papan tulis informasi seperti itu jarang mungkin.

- Ya, dan dalam buku tidak begitu sering informasi ini terjadi.

- Buku langsung sulit bagi saya, jujur ​​saja. Buku penting terakhir yang saya baca di Jawa adalah "Java Concurrency in Practice", dan pada ekosistem Java adalah "Java Persistence Kinerja Tinggi", Vlad Mihalcea (ini adalah buku yang sangat bagus). Tapi biasanya itu bacaan yang sangat sulit, dan itu tidak diberikan kepada saya.

- Apakah layak untuk membaca dok Jawa?

- Tergantung cara belajar Anda. Orang-orang dibagi menjadi dua jenis sesuai dengan cara mereka belajar: beberapa lebih suka menulis terlebih dahulu, kemudian memahami cara kerjanya, dan beberapa pertama membaca cara menulis, dan kemudian menulis. Saya termasuk tipe pertama. Saya selalu memulai dengan eksperimen dan tidak menyelam terlalu dalam. Saya menyelam jauh kemudian. Seorang gadis yang luar biasa bekerja dengan saya, yang, sebelum menulis baris pertama di Kotlin, pergi dan membaca dok di Kotlin.

- Mungkin, saya akan melakukan itu, omong-omong.

- Ini adalah cara yang luar biasa, saya tidak menentangnya.

"Saya juga sangat tertarik pada bagaimana orang-orang seperti Anda melakukannya yang dapat segera menulis secara normal."

- Tidak ada tugas untuk menulis secara normal, tidak ada tugas untuk menulis. Ini sangat penting. Secara umum, tugas menulis biasanya tidak selalu muncul, terutama ketika Anda sedang belajar. Ketika saya mempelajari sesuatu, saya tidak bisa hanya memahami banyak informasi dan kemudian menulis. Saya selalu memulai dengan eksperimen. Mungkin Anda tahu bahwa saya terkadang menulis podcast. Dalam edisi pertama, yang kami rekam dan terbitkan, saya berbicara tentang fakta bahwa saya dapat mempelajari semuanya hanya karena saya tidak pernah menunda untuk nanti. Saya tidak punya tugas untuk membaca sesuatu dan, oleh karena itu, saya menghemat banyak waktu, karena saya segera duduk dan mulai menggunakan beberapa jenis teknologi, baik dalam proyek kerja, atau dalam beberapa jenis proyek rumah. Lalu, jika perlu, saya akan masuk lebih dalam. Tetapi sebagai permulaan, saya dapat memberitahu Anda bahwa saya mengerti bagaimana menggunakannya. Pada langkah selanjutnya, saya bisa memberi tahu Anda bahwa saya tahu cara kerjanya. Saya mulai menggunakan pegas sebelum saya menyadari cara kerjanya. Mungkin sekitar 6 tahun.

- Sepertinya kita harus menyingsing :-) Terima kasih banyak! Sampai jumpa di Joker, saya pasti akan datang untuk mendengarkan laporan Anda.