Wawancara dengan Aaron Patterson, Pembicara Konferensi RubyRusia 2018

Hai Kami melanjutkan serangkaian wawancara dengan pembicara di konferensi RubyRusia . Aaron Patterson (alias tenderlove ) adalah anggota tim inti Ruby dan tim inti Rails, seorang insinyur perangkat lunak terkemuka di sebuah startup kecil bernama GitHub. Pavel Argentov berbicara dengan Harun sebelum perjalanan keduanya ke Rusia.



Mari kita mulai dengan pertanyaan standar. Apa kisah ruby ​​pribadi Anda? Bagaimana Anda menangkap kereta ini? Ceritakan tentang pencapaian Anda? Apakah Anda membuat dunia menjadi tempat yang lebih baik?

Saya menemukan Ruby pada tahun 2006. Saya waktu itu seorang programmer Java. Mari kita mulai lebih awal: Saya adalah seorang programmer Perl, dan kemudian menjadi seorang programmer Java, tetapi saya tidak ingin menjadi seorang javist.

Mengapa

Ketika saya menulis di Perl, kami sudah memiliki kerangka kerja web kami sendiri. Ada banyak yang dimiliki Rails: Anda bisa mengubah kode, memuat ulang halaman, dan memeriksa apa yang terjadi. Semuanya bekerja. Ketika kami beralih ke pengembangan Java, itu menjadi seperti ini: Anda perlu mengkompilasi ulang semuanya - ini akan memakan waktu 10 menit sebelum Anda dapat memeriksa semua perubahan yang baru saja dibuat. Saya suka bahasa dinamis seperti Perl lebih dari Java. Diperkirakan Perl 6. Jadi, ketika saya menunggu Perl 6, saya belajar tentang Ruby. Pikir: “Wow! Inilah yang saya butuhkan! " Jadi saya mulai mengerjakan Ruby - di waktu senggang saya, misalnya, untuk proyek sampingan. Anda tahu, hanya untuk bersenang-senang. Semuanya dimulai dengan itu. Akhirnya, pada 2008, saya sudah mendapat pekerjaan di Ruby.

Apakah itu sudah Rails?

Ya, teman saya memutuskan untuk memulai startup. - Kami akan menggunakan Rails. Apakah Anda ingin bekerja bersama kami di perusahaan yang sama? Saya seperti ini: - Ya, tentu saja, saya akan senang bekerja di "rel"! Begitulah cara saya memulai.

Jujur, saya tidak suka pekerjaan saya di perusahaan ini. Karena itu, di setiap kesempatan, tepat di tempat kerja, saya menulis open source. Ini dilakukan sebagai berikut: - Ok, proyek akan memakan waktu 2 hari. Kemudian saya menyelesaikan masalah ini dalam beberapa jam, dan menggunakan sisa waktu untuk open source.

Apa yang kita sebut: "Jangan pukul polisi tidur!" Aku duduk di sini dengan tenang, memperbaiki primus. Tinggalkan aku sendiri, pliz!

Ya! Jadi, di sini saya mulai banyak bekerja dengan open source. Dalam karya ini, saya mulai menulis Nokogiri dan umumnya mengerjakan open source Ruby saya. Jadi saya biasanya pergi ke open source. Dia hanya "memberikan kontribusi" sampai suatu hari dia bergabung dengan tim Ruby Core dan Rails Core.

Jadi bagaimana Anda berakhir di Tim Inti Rails?

Kami baru saja menemukan bug dan mengembangkan aplikasi Rails. Menemukan bug, saya memperbaikinya dan mengirim patch. Saya baru saja mengirim tambalan. Pada akhirnya, mereka bosan dengan kenyataan bahwa saya hanya mengendarai permintaan tarik.

Seperti, sekarang bawa masalah ke tanganmu sendiri, kan?

Ya tentu saja! Semua dalam semua, itu seperti serangan brute force!

Kedengarannya masuk akal! Jadi, apa kontribusi Anda secara keseluruhan pada Rails?

Saya banyak bekerja di hampir semua bagian kerangka kerja. Sebagian besar dari Rekaman Aktif. Saya terutama suka melakukan perbaikan bug dan meningkatkan kinerja. Alasan untuk lampiran ini adalah membuat aplikasi seseorang lebih baik. Semua orang senang jika aplikasi menjadi lebih baik, dan Anda tidak perlu melakukan apa pun untuk ini. Itu sebabnya saya suka mengerjakannya.

Anda melakukan beberapa perbaikan "kecil" yang membuat semuanya berfungsi. Tetapi bukankah Anda harus merancang hal-hal "besar"?

Biasanya setiap kali saya melakukan sesuatu arsitektur di Rails, itu adalah sesuatu di dalamnya. Misalnya, arsitektur bekerja dengan URL, asosiasi, gizmos di dalam router - sesuatu seperti itu. Tak satu pun dari hal-hal ini akan terlihat jelas. Mereka dapat dilihat oleh pengguna, tetapi ini tidak dalam bentuk: "Ini dia, Benda asli!" Saya mencoba untuk tetap berpegang pada gaya itu. Saya pikir ini sebenarnya bagus, karena David ( DHH - P.) suka membuat Fitur Baru yang Cemerlang. Alih-alih, saya berkata pada diri sendiri: "Baiklah, mari kita buat ini Fitur Baik Anda. Anda melihat, dan kebenaran akan keluar indah! "

Ya, seseorang harus melakukan semua pekerjaan manual. Misalnya, presentasi Anda di konferensi akan membahas bagian-bagian rekayasa mendalam tertentu dari Ruby pada umumnya dan Rails pada khususnya. Apa sebenarnya presentasi itu?

Bahkan, saya akan berbicara tentang Ruby internal. Saya belum mengarang seluruh pidato sampai akhir.

GC, kinerja, semua itu, kehidupan, alam semesta, 42?

Saya sedang berpikir untuk berbicara tentang pengumpul sampah, proses kompilasi Ruby, dan bytecode. Pada dasarnya, tentang bytecode di mesin virtual dan bagaimana ini berhubungan dengan pengumpul sampah. Tentang beberapa peningkatan kinerja yang saya buat di GC. Saya tidak berharap untuk berbicara banyak tentang Rails.

Konferensi kami dulu bernama Rails Club. Penyelenggara kami berpikir, dan mengganti seluruh gagasan, terutama karena Matz mengatakan bahwa ia tidak pernah menghadiri konferensi dengan kata "Rails" dalam judul. Jadi, sekarang kita adalah "Ruby Russia"!

Jadi, saya akan berbicara tentang Ruby internal!

Menurut Anda, apa yang harus dilakukan programmer Rails untuk mencapai kinerja yang lebih baik dalam kode mereka?

Ada beberapa strategi. Pertama, secara umum, jangan melakukan sesuatu yang istimewa. Cukup tulis aplikasi Anda. Luncurkan, dapatkan pelanggan, umpan balik, dll. Segera menganalisis kemacetan yang terdeteksi. Jangan pernah bekerja dengan hambatan sampai pekerjaan nyata dengan klien mengungkapkannya. Jika Anda berurusan dengan kemacetan yang sebenarnya tidak, itu buang-buang waktu. Waktu ini dapat digunakan untuk fitur baru. Namun, saya pikir banyak yang akan mengatakan hal yang sama, jadi mari kita bicara tentang apa yang benar-benar mempengaruhi kinerja. Pertama, lihat saja query database yang dibuat halaman. Ini adalah garis pertahanan pertama - cobalah untuk mengurangi waktu yang dihabiskan untuk permintaan spesifik. Permintaan sendiri - otomatis dan kurangi. Anda tidak akan percaya seberapa sering kami lupa hanya menambahkan indeks. Ha! Jadi, buat setidaknya indeks di tempat yang tepat.

Saya melakukan wawancara teknis dan membayangkan bagaimana orang lupa bahkan apa indeks secara umum. Mengapa Anda perlu khawatir tentang ini sama sekali ... Nah, apa yang Anda katakan tentang hal-hal lain yang harus diketahui oleh para penyair? Hal-hal teknis apa yang harus diketahui oleh seorang rubist untuk melakukan pekerjaannya dengan lebih baik?

Ada beberapa bagian seperti itu. Yang pertama, saya pikir, adalah untuk mengetahui bahasa Ruby itu sendiri. Pelajari bahasa dengan sangat hati-hati. Yang kedua adalah memahami UNIX dengan baik.

Anda adalah pembicara "saya" pertama yang mengatakan bahwa Anda perlu tahu UNIX. Jadi saya pribadi datang ke Ruby dari dunia UNIX. Saya bekerja di Linux, FreeBSD, dan banyak kode Perl. Saya datang ke Ruby sebagai Perl lain untuk melakukan urusan sysadmin saya, dan baru kemudian menemukan bahwa itu juga bahasa web. Jadi, Anda mengatakan Anda perlu tahu UNIX. Bagaimana dan mengapa?

Penting untuk mempelajari standar POSIX dan bagaimana mereka berinteraksi dengan sistem operasi, karena Anda akan menjumpai hal ini segera setelah Anda memulai penskalaan. Kamu ...

... harus tahu siapa Jenderal Feiler itu dan mengapa dia membaca file saya?

Haha ya! Anda perlu tahu apa yang mengubah kinerja. Mungkin Anda tidak perlu menghafal ini secara khusus, tetapi Anda harus tahu bahwa mereka (panggilan sistem - P.) ada, dan bagaimana cara google mereka, karena Anda pasti akan menemukan ekonomi ini. Mereka akan penting karena aplikasi ini digunakan pada server UNIX, jadi Anda perlu memahami bagaimana aplikasi akan berinteraksi dengan OS yang akan dijalankannya. Poin penting lainnya adalah bahwa jika Anda memiliki keterampilan ini di UNIX, Anda dapat menerapkannya, misalnya, dalam bahasa lain. Jika Anda mengalami masalah, Anda selalu dapat memulai dari titik ini. Ini mungkin hal utama yang saya sarankan untuk dipelajari oleh programmer.

Apakah menurut Anda berguna bagi rubist untuk mengetahui bahasa lain? Apakah mungkin menjadi programmer yang baik di Ruby tanpa mengetahui apa pun di luar Ruby?

Pertanyaan yang bagus Jujur saja, saya tidak tahu. Semua rubrik yang baik saya tahu bahasa lain. Namun, saya tidak tahu apakah perlu belajar bahasa lain untuk menjadi programmer Ruby yang baik. Saya pikir kebetulan orang belajar bahasa lain.

Pengamatan yang bagus! Dari sudut pandang medis, semakin banyak bahasa yang diketahui seseorang, semakin banyak penundaan timbulnya Alzheimer-nya.

Haha

Setelah 40 Anda harus berpikir tentang hal-hal seperti itu ...

Saya mendekati usia 40 tahun! Itu baik untuk saya ketahui!

Mari kita bicara tentang Ruby itu sendiri. Ruby adalah bahasa dengan masa lalu yang indah. Apakah dia punya masa depan? Belum lama ini saya berada di St. Petersburg di salah satu konferensi IT terbesar yang pernah saya lihat di Rusia. Komunitas ruby ​​lokal tidak diwakili di konferensi ini. Saya terus-menerus harus melakukan apologetika Ruby: Ruby TIDAK BEGITU mati, mereka masih menulis Ruby. Omong-omong, Ruby memiliki kerangka kerja web paling terkenal - dan semua itu. Setiap bahasa besar di pasaran sekarang memiliki beberapa jenis alat pengembangan web. Pergi, Rust, terserahlah. Apa tempat Ruby di ekosistem ini dan apakah "Ruby dengan masa lalu yang hebat" memiliki masa depan?

Saya pikir ada beberapa aspek untuk menjawab pertanyaan ini. Ada banyak bahasa yang berbeda untuk kerangka kerja web, tetapi saya masih berpikir bahwa jika Anda melihatnya dari sudut pandang ergonomi pengembang, Ruby tetap akan berada di atas. Mudah digunakan dan mudah dijual. Masalahnya adalah bahwa Ruby tidak lagi "baru dan brilian." Orang ingin terbawa dengan sesuatu yang baru. Mereka ingin naik kereta berikutnya setelah Rails.

Mereka menginginkan bau mobil baru!

Ya! Tentang masa depan ... Ada banyak perkembangan baru di Ruby, terutama tentang JIT dan apa yang dilakukan Koichi: guild. Saya akan mengatakan bahwa Ruby pasti memiliki masa depan, tetapi semua orang harus bekerja keras untuk itu. Jika kita melakukan upaya yang benar, masa depan pasti akan terjadi.

Apakah Ruby memiliki perspektif di bidang selain pengembangan web? Atau Anda tahu ada contoh di mana Ruby sekarang digunakan di luar pengembangan web?

Pertanyaan bagus! Sulit untuk dijawab, karena saya hanya berurusan dengan masalah pengembangan web.

Saya bertanya karena itu adalah kepentingan pribadi saya. Orang-orang dari komunitas Python, misalnya, suka membual tentang keberhasilan mereka dalam komputasi ilmiah.

Saya tahu ada grup yang mengerjakan alat ilmiah di Ruby. Tapi saya pikir alternatif nyata untuk Ruby adalah administrasi sistem.

Bagaimana kami bisa membawa pengembang dari bahasa lain ke komunitas kami?

Ini pertanyaan yang sangat bagus! Saya pikir kita hanya perlu fokus pada pengembangan ergonomi, pada apa yang membuat pengembangan aplikasi web semudah mungkin. Kita perlu fokus menurunkan ambang entri untuk pengembang baru yang naik dan menulis aplikasi web. Jadi kami akan menarik lebih banyak programmer baru.

Sudah waktunya untuk pertanyaan hollywood tentang JavaScript. Anda tahu, ada pepatah yang mengatakan: "semua yang dapat ditulis ulang dalam JavaScript harus ditulis ulang dalam JavaScript." Apakah Anda pikir Rails juga akan ditulis ulang dalam JavaScript? Kami berbicara tentang ergonomi pengembangan Ruby. Ini adalah hal terbaik tentang Rails. Salah satu programmer Rusia yang sangat terkenal mengatakan bahwa "banyak bahasa bagus, tetapi hanya Ruby yang memiliki Rails." Namun, pengembang JavaScript cenderung mempertanyakan ini. Bagaimana kita bisa bersaing dengan JavaScript? Atau haruskah kita mengatur simbiosis dengannya?

Memang benar bahwa hanya Ruby yang memiliki Rails. Jika Anda melihat kerangka kerja web untuk JavaScript, saya tidak berpikir bahwa mereka cukup sebanding dengan Rails dalam hal ergonomi pengembangan. Faktanya adalah karena kita menulis aplikasi web, kita harus bekerja dengan JavaScript. Kita harus menjadi bagian dari komunitas JavaScript. Berguna bagi kita untuk memiliki simbiosis. Jika Anda dapat menjalankan bahasa apa pun di server, mengapa harus JavaScript? Tapi bahasanya bagus, dan saya pikir kita perlu bekerja secara simbiotik. Kemudahan pengembangan masih di pihak kita, dan ini sangat dihargai di komunitas Rails. Jadi, Anda datang ke konferensi TI, dan Anda harus bekerja sebagai perwakilan Ruby di sana?

Itu sangat informal, karena saya bahkan tidak punya kaus tentang perusahaan atau bahasa saya. Jadi saya baru saja menemukan sekelompok anak muda paling cerdas yang ternyata adalah python, dan kami mulai mengobrol.

Bagi kami, ada baiknya jika kami bekerja sama dengan bahasa lain, dan tidak bersaing dengan mereka. Secara pribadi, saya pikir pemrograman di Ruby jauh lebih mudah dan lebih menyenangkan daripada dalam bahasa lain. Kenapa tidak Kita berbicara tentang bahasa pemrograman lain dan apakah kita harus mengetahuinya. Saya percaya adalah penting bahwa para Ruby mempelajari bahasa lain. Sesuatu seperti Java, Haskell, atau sesuatu yang fungsional seperti Elixir atau Lisp, sesuatu seperti itu. Saya pikir berguna untuk mempelajari berbagai paradigma, karena ketika Anda mempelajari hal-hal baru, Anda dapat mengambilnya dan menggunakannya dalam bahasa Anda. Fitur yang baik dari Ruby adalah kita dapat menggunakan teknik dari berbagai bahasa di program kita.

Ya, kami memiliki, misalnya, alat untuk pemrograman fungsional atau melakukan peta / pengurangan atau sesuatu yang lain.

Ya, kita bisa menggunakan semua ini. Jika Anda menggunakan bahasa yang mendorong teknik ini, Anda mungkin menemukan cara yang lebih baik untuk menyelesaikan masalah. Saya tidak yakin bahwa perlu mempelajari bahasa lain untuk menjadi seorang rubis yang baik, tetapi penelitian ini pasti membantu saya. Jujur, saya menghabiskan 50% dari waktu saya pemrograman di C.

C membuat jari lebih kuat!

Saya pemrograman dalam C sehingga orang lain dapat memprogram di Ruby.

Apakah Ruby internal ditulis dalam C murni, bukan ++?

Di bersihkan. Akan lebih baik jika lebih banyak kode ini ditulis dalam Ruby, tetapi jujur, beberapa hal utama untuk alasan kinerja harus ditulis dalam C. Salah satu hal yang saya lakukan ... Kita perlu meningkatkan profil memori. Oleh karena itu, saya bekerja pada alat profil memori di Ruby. Karena semua bagian dalam ditulis dalam C, saya harus menulis alat dalam C. Di tempat kerja, saya menulis banyak kode.

Bagaimana kabar Ruby dengan FFI dan sejenisnya?

FFI bekerja dengan cukup baik jika Anda memiliki pustaka C dalam pekerjaan Anda yang membutuhkan satu atau dua fungsi. Jika ada sesuatu yang lebih rumit ... Maka semuanya lebih rumit. Ketika Anda bekerja dengan FFI, pada dasarnya Anda menulis kode C yang mirip dengan Ruby. Namun, Anda masih harus melakukan hal-hal misterius seperti manajemen memori. Saya pribadi merasa lebih mudah untuk beralih di antara dunia-dunia ini jika Anda menggunakan C untuk mengelola memori, dll. Dan dalam kasus lain, saya beralih ke Ruby.

Di Ruby, apakah kita memiliki antarmuka ke bahasa lain?

Beberapa antarmuka dengan JavaScript. Saya melihat seorang pria yang terlibat dalam tugas-tugas ilmiah, jadi dia berinteraksi dengan Python.

Apakah itu berinteraksi langsung dengan runtime bahasa?

Ya persis. Tidak seperti penembakan atau semacamnya ... Proyek ini masih sangat eksperimental. Ketika dia memberikan demo, dia mengatakan bahwa “semuanya bekerja, tetapi mungkin jatuh!”

Saya tahu banyak rubrik terkenal yang pergi untuk menciptakan Rust. Menurut Anda mengapa orang melakukan ini, dan bagaimana keadaan mereka?

Saya suka Rust, saya pikir itu bahasa yang sangat bagus. Alasan orang pergi ke Rust ... mereka menginginkan bahasa yang memiliki lebih banyak fitur keamanan daripada yang disediakan C. Akan sangat luar biasa untuk menulis ulang Ruby di Rust. Saya pribadi penggemar berat Rust, saya mencintainya.

Bagaimana ini bisa bermanfaat? Apakah lebih aman, lebih cepat atau apa?

Saya pikir ini lebih aman. Saya tidak yakin apakah ini lebih dioptimalkan daripada C, tetapi jelas lebih aman. Inilah yang saya sukai dari dia. Ketika saya menulis kode C, saya hampir yakin itu bukan SEGV, tetapi tidak 100% yakin. Tetapi ketika saya menulis di Rust, saya yakin lebih banyak. Ketika saya menulis dalam C, saya cukup yakin bahwa tidak akan ada kebocoran memori. Dengan Rust, jelas seperti hari putih bahwa tidak akan ada kebocoran memori. Itu sebabnya saya pribadi lebih suka Rust daripada C. Saya juga mulai belajar Rust, karena saya ingin menulis ekstensi untuk Ruby. Ada seluruh proyek yang disebut "Helix" - khusus untuk ini. Seringkali, ketika saya menulis dalam bahasa C, rasanya seperti: "Oke, saya punya perpustakaan C, dan saya harus mengaksesnya dari Ruby dengan menulis beberapa kruk." Menggunakan Rust untuk ini adalah meriam burung gereja. Dalam dunia ideal saya, semuanya, seluruh sistem suatu hari nanti akan ditulis ulang di Rust. Karat akan menjadi C. baru kami Jika Anda perlu menyelesaikan masalah dengan cepat, Anda menulis dalam Ruby. Dan sistem operasinya akan dibuat pada Rust. Dan semua orang akan bahagia.

Apakah Rust cukup dewasa untuk ini?

Ya saya tidak tahu. Saya pikir cukup. Di Mozilla, mereka menggunakannya - dan puas.

Apa peluang untuk "melihat register" dengan menjalankan program di Rust?

Haha, saya tidak tahu! Harapan rendah! Melihat ini sama sekali tidak lucu.

Terutama ketika Anda meluncurkan sesuatu di browser.

Ya Pesan tentang kerusakan muncul, dan Anda seperti ini: "OK." Ha! Di tempat kerja, kami memiliki beberapa hal dalam C ++, dan kadang-kadang ketika saya crash, saya hanya seperti ini: "Hmm ..."

Saya ingin memprogram dalam bahasa, bukan dalam assembler makro! - itu adalah lelucon favorit saya ketika saya beralih dari C ke Ruby ...

Anda sebenarnya benar. Setiap kali saya menulis dalam C, pertanyaannya adalah apa yang harus saya pikirkan. Saya benar-benar tidak memikirkan masalah yang sedang dipecahkan. Dengan Ruby, saya tidak perlu memikirkan semua ini (ekonomi tingkat rendah - P.). Saya hanya fokus pada logika program, dan saya melakukan bisnis. Ini adalah salah satu alasan saya sangat mencintai Ruby! Ketika saya adalah seorang javist selama Java 1.3, itu sebelum generik muncul di sana. Setiap kali saya harus menulis sesuatu seperti peta - misalnya, koleksi atau iterator, saya harus melakukan "iterator.next ()", dan kemudian memberikan nilai yang dihasilkan ... Hanya kemudian melakukan operasi yang diperlukan. Kemudian saya mulai belajar Ruby, di mana peta sudah di Perl ...

... Oh, keajaiban! Tepat di tangan saya, saya memiliki objek dengan tipe yang tepat yang saya butuhkan!

Ya persis. Di Jawa, saya harus menulis 15 baris kode untuk mencapai apa yang dapat saya lakukan sebagai satu baris di Ruby. Saya akan menulis di Ruby, saya akan menyelesaikan pekerjaan lebih cepat! Alih-alih menulis semua sampah ini! Memahami hal ini sangat membuat saya kesal pada pekerjaan itu. Saya menghabiskan waktu berjam-jam untuk lalu lintas tambahan!

Horor Eksistensial!

Tepat! Itu adalah titik balik. Saya perlu mencari pekerjaan di Ruby. Saya tidak bisa memotong java sampai akhir hidup saya!

Apakah bisa dikatakan bahwa Ruby meningkatkan pikiran programmer?

Saya pikir jika Anda dapat mencurahkan lebih banyak waktu untuk tugas-tugas tingkat tinggi, untuk tujuan-tujuan program ini, ini akan membantu meningkatkan pemikiran abstrak. Anda berlatih semakin memikirkan sistem secara keseluruhan, dan bukan tentang roda kecil program. Biarkan saya mengingatkan Anda bahwa dalam C saya harus terus-menerus memikirkan semua hal-hal sepele ini, dan bukan tentang masalah yang saya pecahkan. Bahkan, Anda mempelajari persis Pemecahan Masalah, yaitu tugas tingkat atas. Saya pikir itu dapat meningkatkan Anda sebagai seorang programmer.

Saya ingat kesan saya sendiri ketika saya mulai di tahun 90-an. Saya mencoba menguasai OOP. Saya mencoba melakukan C ++. Saya membaca buku, mempelajari "trinitas suci PLO." Dan kemudian saya kembali menemukan diri saya dalam proses menguasai semua trik "macroassembler" yang sama. Kemudian saya mencoba bekerja di Jawa, saya menghasilkan uang di Perl. Dan hanya di Ruby akhirnya saya mengerti cara kerja OOP.

Anda mengatakan hal itu. Jika Anda berpikir tentang bahasa OOP lainnya, seperti C ++ atau Java, maka tidak semuanya memiliki objek. Misalnya, masih ada ints saja. Masih ada primitif, dan mereka harus ditangani secara berbeda daripada dengan objek. Di Ruby, sebenarnya, semuanya adalah objek. Hanya OOP yang harus ditangani. Lebih banyak olahraga, lebih banyak makna. Saya benar-benar tidak banyak memikirkannya sampai Anda bertanya.

Bahasa dirancang sedemikian hati-hati sehingga membuat Anda berpikir ke arah yang benar. Itu membentuk pikiran. Sintaks itu sendiri menjelaskan apa yang Anda lakukan.

Saya bekerja dengan OOP di Perl. Ini umumnya hanya peretasan untuk hal-hal seperti OOP. Java, tentu saja, mengimplementasikan OOP. Tetapi dia, di antara hal-hal lain, memiliki benda-benda yang tidak ada. Ruby di daftar kami adalah bahasa pertama di mana semuanya benar-benar objek.

Dengan kata-kata apa Anda akan menginspirasi programmer muda dan yang lama?

Pertanyaan bagus! Saya pikir inilah yang bekerja untuk para penyair muda dan tua: Secara pribadi, saya pikir Ruby adalah satu-satunya bahasa yang ketika digunakan memberi penggemar. Pemrogram muda yang sudah menguasai bahasa lain, coba Ruby, karena itu sangat menyenangkan. Pemrogram lama dengan pengalaman yang solid dalam bahasa lain, Anda dapat membandingkan semuanya dan memahami betapa baiknya Ruby. Ketika Anda mulai menggunakan sesuatu yang lain, Anda akan berkata pada diri sendiri: wow, tetapi Ruby bukan apa-apa!

Pada akhir pekan, saya melakukan beberapa latihan kecil dalam bahasa lain. Setelah akhir pekan, saya kembali bekerja, membuka Emacs saya dengan Ruby, dan berkata pada diri sendiri: "Ya Tuhan, betapa indahnya kembali ke tanah air Anda!"

Ya, saya pikir itu baik untuk beralih ke bahasa lain, bekerja di sana, mengumpulkan beberapa pengamatan. Saya selalu senang untuk kembali. Saya merasa seperti di rumah di Ruby.

Dimungkinkan untuk secara pribadi mengajukan pertanyaan kepada Harun pada tanggal 6 Oktober. Sampai jumpa di konferensi! Semua detail di situs .

Anda dapat membaca aslinya dalam bahasa Inggris di hype.codes .

Dan banyak terima kasih kepada perusahaan yang mendukung acara Ruby utama di Rusia:

Mitra Umum - Toptal
Mitra Emas - Gett dan Cookpad
Mitra perak - Instamart , UCHi.ru , JetBrains , dan Qlean
Mitra setelah pesta - Teachbase
Mitra Perunggu - Bookmate dan InSales