Andrey Sitnik dari
Evil Martians adalah salah satu nama Rusia paling terkenal di ujung depan: proyek
PostCSS dan
AutoPrefixernya memiliki puluhan ribu bintang GitHub. Tetapi karena Andrei tinggal di New York dan melakukan perjalanan di seluruh planet ini, Anda jarang dapat menemukannya di Rusia.
Pada bulan Mei, ia akan berada di St. Petersburg pada konferensi HolyJS, dan
Dmitry Dmitry Makhnev Makhnev dan
Maxim Yuzva menanyainya secara rinci di komite program HolyJS. Mengapa Andrei berpikir bahwa frontend mandek, dan kode proyek kami terlalu bengkak? Apa perbedaan antara komunitas TI di berbagai negara? Bagaimana belajar bahasa Inggris dan mengapa itu tidak sepenting kelihatannya? Di mana proyek Logux yang dipresentasikan di HolyJS kembali pada tahun 2016?
Tentang proyek saat ini
Dmitry: Pertama, ceritakan secara singkat tentang diri Anda - di mana Anda dan apa yang Anda lakukan.
Andrey: Nama saya Andrey Sitnik, saya tinggal di New York, tetapi saya sering bepergian. Sebagian besar mereka mengenal saya dengan open source dan pertunjukan - seperti sekarang populer untuk mengatakan, "merek media di bidang IT". Saya tidak bisa mengatakan bahwa saya benar-benar layak menerimanya, tetapi keberuntungan berkontribusi pada saya.
Selain open source, saya juga mempromosikan keanekaragaman bahasa di Twitter
@LinguoPunk , Wikipedia di
@LostInWiki dan perjuangan untuk positivisme seks.
Dmitry: Proyek apa yang sedang Anda kerjakan sekarang?
Andrew: Di open source ada beberapa proyek pendukung, yang paling terkenal adalah PostCSS dan Autoprefixer. Mungkin PostCSS sekarang sedikit aktif: Alexey Bondarenko
membuat pembaruan yang sangat besar ke API, jadi mungkin ada rilis besar segera.
Dan Autoprefixer mendukung rilis. Satu-satunya hal yang kami secara aktif menggergaji sekarang adalah dukungan Grid untuk IE 10-11, tetapi itu berjalan buruk karena
penolakan dari Rachel Andrew, yang secara aktif mempromosikan Grid. Dia orang yang sangat terkenal, dan dia tidak suka alat apa pun yang secara otomatis melakukan apa pun dalam CSS - perjuangan keagamaan seperti itu. Dan karena penentangannya, fitur ini, sayangnya, tidak terlalu menyebar.
Dmitry: Bagaimana Rachel dapat menghentikan Anda dari membuat instrumen?
Andrew: Alat ini tidak mengganggu melakukan apa pun, itu berfungsi. Tetapi open source bukan tentang pemrograman, open source adalah tentang masyarakat dan sosialisasi. Jika tidak ada yang menggunakan produk Anda atau berbicara tentangnya media, tidak ada motivasi untuk melakukannya. Sebagai hasilnya, itu menyentuh motivasi pengembang yang melakukannya dan terus melakukannya. Hanya sedikit orang yang berbicara tentang kepahlawanan mereka, tetapi mereka masih merupakan orang-orang hebat dan pahlawan sejati.
Faktanya, kami menyadari semua yang kami inginkan dan dapat, bahkan ada ide gila dengan dukungan grid otomatis, yang umumnya tidak mungkin dilakukan pada spesifikasi ini, tetapi orang-orang menemukan cara untuk melakukan ini dengan kombinasi sihir pemilih yang licik.
Secara umum, PostCSS dan Autoprefixer didukung, jarang ada fitur yang ditambahkan dan sebagian besar kecil, tetapi Logux secara aktif berkembang. Dan tahun ini saya ingin mencurahkan lebih banyak artikel daripada proyek sumber terbuka tertentu.
Dmitry: Anda melakukan banyak pemecatan, tetapi tentang Logux setelah
presentasi di HolyJS pada tahun 2016, Anda tidak benar-benar mendengar apa yang terjadi padanya?
Andrew: Ini pertanyaan yang bagus, karena mengangkat topik yang sangat menarik. Faktanya adalah ada berbagai cara untuk mendistribusikan perangkat lunak.
Menggunakan open source bukanlah semacam pengambilan keputusan yang rasional. Pengembangan perangkat lunak paling baik dijelaskan oleh industri fashion. Pilihan teknisnya adalah, pertama-tama, fashion, hype dan hal-hal serupa.
Oleh karena itu, ada beberapa strategi untuk mempromosikan solusi baru. Misalnya, ketika sesuatu muncul, itu masih tidak berfungsi sebagaimana mestinya, tetapi karena takut kehilangan sesuatu yang besar, orang-orang dengan cepat naik kereta api hype, mulai menggergaji dan membawanya ke kondisi kerja.
Dalam cara yang baik, lebih dari setengah proyek open source populer ditulis dengan menjijikkan. Sebaliknya, hype di sekitar mereka benar-benar tidak konsisten dengan kualitas kode dan tingkat dukungan dari penyelenggara. Tetapi karena banyak orang duduk di kereta sensasi segera, proyek bertahan dan terus ada.
Misalnya, plugin Babel tidak memiliki sinkronisasi. Anda tidak dapat membuat fungsi asinkron di dalam plugin, dan ini adalah masalah yang mengerikan, saya tidak tahu bagaimana itu masuk ke dalam produksi, karena itu sangat membatasi pasar aplikasi Babel yang sangat besar. Tapi begitulah yang ditulisnya, begitulah arsitekturnya. Babel memiliki banyak kesenangan.
Ini adalah salah satu cara penyebaran: untuk mengatakan "semuanya hilang, jika Anda tidak belajar besok - semuanya, pasar akan membutuhkan orang dengan pengalaman tiga tahun dalam teknologi ini." Tapi ada cara lain. Misalnya, dalam React, mereka melakukannya secara berbeda: pertama mereka "memasak" di lingkungan mereka, dan kemudian mereka mempresentasikan proyek yang kurang lebih siap untuk produksi. Tentu saja, pertanyaan terbuka adalah bagaimana tepatnya dia siap untuk produksi, tetapi jelas bahwa kerangka kerja tidak 100% disiapkan.
Logux adalah sistem komunikasi klien / server. Ide pertanyaan, apakah GraphQL atau Ajax, tidak dimaksudkan untuk Internet yang tidak stabil dan bekerja dalam kondisi seperti itu hanya menjijikkan - ini adalah masalah yang diketahui dari sebagian besar situs. Logux adalah pendekatan yang berbeda dan, sebagai hasilnya, secara teknis merupakan solusi yang sangat besar. Idenya bukanlah hal baru, ada banyak solusi seperti itu, dan mereka gagal, dan itu membuat saya khawatir. Bahkan GraphQL dibuat dengan derit yang mengerikan, dan itu seharusnya mengajarkan sesuatu.
Pendapat saya adalah bahwa hype train tidak berfungsi untuk jenis tugas ini. Kita tidak bisa membuat keputusan sehingga semua orang menabraknya dan semuanya berjalan. Ketika kami memberikan solusi segera untuk frontend dan backend, upaya untuk mengeluarkan semuanya dengan hype train mengarah pada konfrontasi antara masyarakat.
Oleh karena itu, saya memutuskan bahwa dengan Logux kami tidak akan melakukan ini, tetapi kami akan pergi dengan hati-hati dan perlahan, mempersiapkannya di dalam proyek. Sepanjang atau dua tahun ini, kami memasak Logux di dalam
Amplifer , menggunakannya pada proyek yang berbeda, dan menyaksikan bagaimana para backders bereaksi. Saya mencoba menjelaskan, menunjukkan, dan sekarang Dima Salakhutdinov akan pergi ke Ruby-confu untuk
berbicara tentang Logux, sehingga kita dapat melihat bagaimana mereka bereaksi, bagaimana kita memberikan PR ke back-end. Karena mengatakan kepada mereka apa yang kita katakan kepada vendor front-end dalam semangat "itu hype" itu salah, itu tidak berhasil di sana.
Dmitry: Mengapa itu tidak berhasil?
Andrew: Backend beralih ke sistem stagnasi atau dukungan: dalam beberapa tahun terakhir praktis tidak ada pengembangan. Dan sebagai hasilnya, mereka memiliki prioritas yang berbeda: ketika Anda tidak memiliki kerangka kerja baru setiap enam bulan, itu memengaruhi Anda. Mereka ada di suatu tempat di Rust atau Go, tetapi Ruby - apa yang baru? Akibatnya, orang fokus pada yang lain. Tentu saja, saya sangat menyederhanakan, dan backend backend berbeda.
Saya ingin mendistribusikan ini dengan benar pada backend dan pada klien, saya ingin datang dengan solusi siap pakai yang benar-benar akan berfungsi, yang kami uji pada produksi. Pada 2017-2018, kami sudah memiliki versi kerja 0,2, tetapi tidak ada skalabilitas. Kami punya ide bagaimana skala, dan untuk PR itu sudah cukup, tetapi sebenarnya itu salah.
Alih-alih, kami menangani masalah skalabilitas yang nyata, bukan teoretis, ketika hal itu tidak dapat dipahami oleh Anda dan Anda tidak tahu pada titik mana. Dan di Logux kami secara serius memompa sistem: misalnya, kami dapat dengan mudah menaikkan server pada beberapa server sekaligus, dan dengan satu perintah untuk menambah jumlahnya.
Tidak ada gunanya melakukan ini sampai Anda memiliki analitik nyata. Karena tanpa itu Anda tidak akan mengerti dari mana Anda mendapatkan colokannya. Anda dapat skala sebanyak yang Anda suka, tetapi ternyata ada beberapa tempat yang tidak skala. Oleh karena itu, kami memiliki kode yang benar-benar siap untuk penskalaan, dan sejumlah besar analitik: bagaimana dan berapa banyak waktu yang dihabiskan, berapa banyak permintaan masuk, Anda dapat melihat di mana steker dimulai. Misalnya, dengan jumlah operasi per detik atau dengan jumlah pengguna, dan semua ini di server diselesaikan secara berbeda.
Dmitry: Kedengarannya cukup menarik. Dan, seperti yang saya mengerti, rencananya cukup besar untuk waktu dekat?
Andrei: Ya, kami telah menyelesaikan rencana untuk aplikasi praktis, sekarang saya akan merilis 0,3 dan menulis dermaga yang tidak cukup untuk aplikasi massal. Dan kodenya bagus.
Tentang Nano ID dan Internet Cepat
Dmitry: Anda telah menyentuh topik koneksi Internet: semua orang terbiasa dengan fakta bahwa internet kita stabil dan bagus, tetapi sebenarnya semuanya benar-benar salah. Dan di sini tidak mungkin untuk tidak memperhatikan ukuran bundel dan hal-hal lain, ingat ID proyek Nano Anda. Mengapa itu sangat mengganggu Anda? Mari kita mulai dengan ukurannya.
Andrei: Apakah menurut saya itu “menghemat pertandingan” ketika semua orang memiliki Internet yang normal? Pertanyaan yang bagus
Nano ID adalah pustaka 141 byte yang menghasilkan ID. Ketika kami menguranginya dari 200 byte, ini tidak masuk akal secara praktis, tetapi merupakan "manifesto politik" yang merupakan waktu untuk memikirkannya.
Ukuran JS adalah masalah yang menarik. Pertama, kompiler tidak menyelesaikannya, tetapi sebaliknya: sebagian besar bundler salah menggabungkan, secara signifikan meningkatkan ukuran atau menggunakannya secara tidak efisien.
Dan fakta bahwa kecepatan koneksi Internet tumbuh adalah benar, dan pada saat yang sama tidak. Begitu Internet berakselerasi, negara-negara menyatakan diri mereka berada di tempat semuanya sangat buruk dengan hal itu - misalnya, di Afrika Tengah. Dan juga muncul pasar baru - misalnya, seluler. Dan ada masalah rumit: kecepatan unduhan meningkat, tetapi situs tidak memuat lebih cepat. Anda dapat memeriksa beberapa LTE, yang akan dengan cepat membuka semuanya, jika Anda membagi ukuran halaman situs dengan kecepatan jaringan.
Masalahnya adalah bahwa kecepatan pemuatan situs yang sebenarnya tergantung pada parameter lainnya. Misalnya,
jumlah perjalanan pulang pergi . Faktanya adalah bahwa antara permintaan dan byte pertama beberapa waktu pasti berlalu ketika sinyal datang dan kembali. Waktu ini sangat lama, hingga
500 ms . Pertama, karena kecepatan cahaya, kedua, peralatannya lambat. Dan jika file Anda memuat satu sama lain pada gilirannya, situs akan melambat.
Untungnya, kami menemukan masalah ini sejak lama dan belajar bagaimana menyelesaikannya. Tapi dia bukan satu-satunya. Baru-baru ini, kami menemukan yang lain: ternyata masalahnya bukan di Internet, tetapi dalam kecepatan kompilasi. Faktanya adalah bahwa 1 megabyte gambar mudah diunduh dan ditampilkan, dan 1 megabyte JavaScript 2-3 kali lebih berat untuk peramban, karena itu harus dikompilasi. Dan jumlah JS meningkat. Dan ini adalah masalah objektif dari situs kecepatan rendah.
Anda dapat dengan cerdik mendekati pertanyaan mempelajari situs menggunakan metode
entropi . Kami memiliki situs web yang beratnya 1 MB. Ada konsep "jumlah informasi." Satu megabyte bukan hanya jumlah baris, tetapi seberapa banyak arti yang terkandung dalam kode ini. Dan seberapa rumit seharusnya sebuah situs membutuhkan 1 MB? Apakah benar-benar ada begitu banyak kasus pengguna di situs sehingga harus ada volume kode untuk menutupinya?
Faktanya, kasus seperti itu sedikit. Ada begitu banyak yang dibutuhkan di kernel Linux, tetapi tidak di situs. Dan karena itu, kami memiliki banyak kode yang berlebihan.
Arti gerakan Nano ID bukan untuk menyimpan setiap byte, tetapi untuk berpikir: "apa yang saya miliki di bundel? Apa yang saya punya di sana 1 MB? Saya tidak dapat memiliki tugas di mana volume seperti itu akan diperlukan. " Di sebagian besar situs, 75% kode tidak digunakan. Nano ID adalah gerakan melawan kami mengirim kode ini kepada pengguna.
Ketika kami mulai berpikir mengapa begitu banyak kode tidak digunakan, kami memahami bahwa jika itu bukan tim yang besar, satu megabyte kode tidak dapat ditulis secara manual. Ini lebih dari "Perang dan Damai" konvensional, yang dapat ditulis selama bertahun-tahun, dan kode ini jauh lebih sulit untuk ditulis karena saling ketergantungan.
Dan paling sering buku ini adalah perpustakaan. Kisah terkenal dengan Moment.js: Anda menghubungkannya, dan karena kekhasan operasi webpack, ia
memuat setiap bahasa di situs web Anda . Dan ada banyak kasus serupa.
Pada suatu waktu, saya perlu membuat ID unik di Logux, saya mengambil perpustakaan, dan kemudian menemukan bahwa itu beratnya 100KB. Mengapa saya sangat membutuhkan untuk menghasilkan ID acak?
Ukuran seperti itu paling sering disebabkan oleh fakta bahwa pengembang perpustakaan mengejanya dengan salah. Oleh karena itu, ide utamanya adalah menggunakan
Batas Ukuran sehingga pengembang perpustakaan mengontrol ukuran proyek mereka. Seperti ESLint, hanya untuk ukuran perpustakaan. Dan kita segera melihat bahwa sejumlah besar perpustakaan dapat dibelah dua.
Dmitry: Apakah menurut Anda pertanyaannya bukan hanya tentang ukuran kode, tetapi juga tentang pendekatan alat pengembangan? Jika saya mengekspor perpustakaan saya sebagai objek alih-alih fungsi individual, dan saya tidak menghubungkan Google Closure Compiler dengan risiko saya sendiri, maka tidak ada yang akan memotong saya apa pun. Mungkinkah masalahnya lebih dalam dari sekedar menulis kode?
Andrew: Saya tidak akan mengatakan bahwa masalah treeshaking benar-benar relevan, karena tidak berfungsi dalam JavaScript. Semua orang berpikir bahwa trichashing akan menyelesaikan masalah, tetapi tidak. Masalah yang paling umum berbeda: apa yang dilakukan paket. Mereka menggunakan beberapa
Rollup , kemas seluruh proyek menjadi satu file, dan ternyata, misalnya, dependensi dikemas di sana. Ini adalah masalah besar, dan dengan bantuan Ukuran Batas kami sangat mengurangi satu perpustakaan, karena kami menghapus dependensi yang kemungkinan akan berulang di setiap proyek.
Masalah kedua adalah mereka secara tidak sengaja menggunakan beberapa API dari Node.js. Misalnya, ada perpustakaan
choo.js - “compact JS-framework”, di mana mereka memeriksa argumen yang masuk menggunakan modul Node.js-modul. Dan itu memuat hampir 4 KB. Dan demi perpustakaan kecil, kami mengirimkan tambahan 4 KB.
Dan masalah seperti itu jauh lebih umum daripada apa yang digunakan untuk treeshaking.
Rekomendasi terbaik untuk trishaking adalah untuk membagi file dalam perakitan, biarkan ada fungsi terpisah di file terpisah. Tetapi seringkali masalahnya berbeda. Jalankan Ukuran Batas dengan opsi --mengapa dan lihat sejumlah besar sampah yang ditanamkan webpack saat menggunakan modul Anda.
Maxim: Lalu ternyata menggunakan webpack untuk perakitan adalah perilaku buruk?
Andrew: Menyaksikan apa yang harus dibicarakan. Jika Anda membuat perpustakaan, kemungkinan besar paket web tidak diperlukan. Anda memiliki kurang dari 1% pengguna yang menginginkan file terpisah, dan pada saat yang sama lebih baik untuk memaksa mereka menggunakan webpack, karena mereka memasukkan pustaka Anda sebagai tautan ke file lain, dan situs akan melambat.
Tetapi dari mana pengguna mengumpulkan perpustakaan Anda, dari mana orang mengumpulkan situs - pada kenyataannya, tidak ada perbedaan. Kami terbiasa di ujung depan bahwa jika Anda menggunakan perpustakaan secara tidak benar, semuanya akan buruk, jika Anda tidak beralih dari webpack ke Parcel hari ini, maka semuanya selamat tinggal, Anda adalah pengembang yang buruk. Tidak, jujur saja, tidak peduli dengan alatnya.
Ada banyak masalah dengan webpack, ini adalah bundler yang buruk, tetapi jika itu bekerja untuk Anda, maka kerjakan. Saya melihat proyek di mana dia membantu menyelesaikan masalah, meskipun faktanya ini adalah salah satu proyek yang paling ditinggalkan. Misalnya, css-loader di sana didukung oleh
satu orang dari Rusia. Ini adalah pahlawan sejati, tetapi jika dia sibuk - itu saja, tidak ada yang akan memperbaiki masalah Anda, tetapi ada banyak masalah.
Jika saya mengatakan bahwa Anda harus berhenti menggunakan webpack, itu hanya karena ada kolektor yang lebih baik. Tapi, sekali lagi, coba proyek baru, dan jangan ubah yang lama. Kami banyak masturbasi di kerangka dan alat, meskipun pada kenyataannya mereka tidak mempengaruhi cara kami membuat kode sama sekali.
Mengapa gembar-gembor kereta api dan bangsawan itu buruk
Maxim: Anda baru saja berbicara tentang menghindari paket web yang mendukung bundler yang lebih keren. Mungkin ada masalah dalam kenyataan bahwa rekomendasi semacam itu dari orang-orang di level Anda membuat hype? Alih-alih merekomendasikan menggunakan sesuatu yang baru, mungkin hanya mengatakan "mari kita dorong dan membuat webpack menjadi hebat lagi"?
Andrew: Pertanyaan bagus. Di satu sisi, benar-benar ada masalah ketika komentar seperti itu dirasakan tanpa memahami konteksnya. Tapi ada masalah lain: Saya takut stagnasi.
Faktanya adalah bahwa frontend mandek. Sampai akhir hidup kita, kita akan hidup di bawah naungan React - tidak ada kerangka kerja baru yang bisa menggantikannya, karena massa kritis diperoleh. Ini seperti dalam bahasa backend: bahasa lama tidak dikalahkan oleh yang baru, karena tidak ada masa kritis, kondisi untuk transisi, kecuali dalam beberapa tugas yang sempit. Sekarang ujung depan telah dimulai.
Stagnasi kerangka kerja dan sistem pembangunan berarti masalah yang sangat besar: stagnasi orang yang akan mengajari kita cara hidup. Kami melihat ini sekarang, karena bintang-bintang di ujung depan masih sama, dan, akibatnya, yang baru tidak akan datang. Dan stagnasi orang juga berarti stagnasi ide. Kami melihat ini sejauh ini oleh parameter tidak langsung, sementara ada cukup kelembaman untuk membawa ide-ide baru. Tetapi Anda datang ke konferensi, dan semuanya sama, dan itu benar-benar membuat saya tertekan. Menurut pendapat saya, sudah waktunya untuk menjatuhkan dunia front-end.
Ini seperti Jawa - pasar besar di mana semuanya baik-baik saja, tetapi tidak ada yang baru. Bagaimana cara mengatasi masalah ini - saya tidak tahu. Tetapi ini adalah salah satu alasan mengapa saya tenggelam dalam proyek-proyek kecil dan terus-menerus menasihati mereka.
Jujur, webpack sangat sulit untuk ditulis ulang, dan penciptanya tidak peduli dengan kualitas DX, ia menulis untuk dirinya sendiri dan berkomunikasi sedikit dengan pengguna. Selain itu, ada masalah arsitektur yang membuatnya sangat sulit untuk ditulis ulang. Ada orang-orang di tim webpack yang jujur mencoba melakukannya dengan baik, tetapi ada kesulitan yang menghalangi kita melakukan ini.
, — — .
, , . , . , «» .
: , , Microsoft Facebook - webpack Babel?
: — . , , -. , -.
, , , - , , - , , , . , - . , . .
, , . , , , , , . , , , Chrome. Chrome , .
— , . , - , : , . , , , , . , , .
: « » - , ?
: . , , — . , ,
[] . ?
: , . - , , - , .
: , . , — , ,
37signals DHH .
, , , . , , , - . , , .
, . , IT .
DHH , , : , , , . , .
: . -, - - , , ?
: Vue.js. , React, , React. , : , .
« , , », , 20–30% . — . , , Google .
Google , , . , - Instagram Facebook, , , , . . , Vue : , React .
, Vue , . , , . — , , win/win. - .
, , , -, - , , , , - .
: , .
: . : , , -.
, — : , , . « ». , , , , .
-, , 99- . , Size Limit,
, , , , Size Limit .
, : - , , , , , , . , , . .
. — « , Google», « , Google, , 99% ».
, , . , , . : , , .
, - pull request Babel, , - . , , — , .
, , - . , , . , .
— - . , PostCSS , , CSS-. Autoprefixer , Compass, , Compass , , , , Opera .
, , , . Accessibility, , URL, , . , — , . , , , Autoprefixer.
, , , , , , , .
: ? , , , JavaScript , , . , ?
: , , — , . — .
: . , , , .
: , , , , , . , . , .
- , … PostCSS , , . , , . - -, , , , , .
: ?
: , , .
: , , , ?
: , , , , - , , , , , . : «
Open Collective , , ».
, . . . , , , . « , , . Open Collective, , . , , , ».
, Babel webpack. : « , . issue,
Open Collective , ». , . , — . , , . , .
, , . -, issue, , maintainer, , , , . , issue, : «, , , . . , , ?» . , «», . , , .
: - , - ?
: . . , JavaScript , . , Ruby , JavaScript. . - , . , , JavaScript.
: , pet project . , , : , , -, , . , , ?
: - . , . , , .
« ». . , . , . — , , maintainer , , - .
, . , , . , , , issue, - , , , .
, ? . , , , . , , .
: , ?
: , .
. . , .
: , , . , . , -, , . , , .
, . , 10, , , , , .
: , , ? , - : « , ».
: , , , . , . , . «» — , , — . , , - PostCSS. .
, - , . - : , , , , , .
— . , , , , , , . , . — , . , .
,
Dmitry: Anda mengatakan bahwa PostCSS membantu bepergian. Berapa banyak Anda bepergian, dan bagaimana Anda menggabungkan ini dengan pekerjaan?
Andrew: Jujur, pekerjaannya bahkan lebih baik. Saya baru saja tiba di New York setelah perjalanan singkat. Ini adalah perjalanan yang sulit, ada internet yang buruk di Maroko, tidak mungkin untuk bekerja, tetapi pada kenyataannya saya melakukan sesuatu yang bermanfaat setiap hari: Saya menulis sebuah artikel, saya membuat dua situs menggunakan teknik yang sama sekali baru.
Tiba di New York, duduk, menonton YouTube. Saya bepergian untuk bekerja secara normal dan efisien. Di satu tempat, saya langsung menjadi wafel, berbaring di sofa. Saya bepergian untuk menjadi lebih produktif, jadi menggabungkan itu mudah.
Satu-satunya aturan: jangan berpikir bahwa Anda akan dapat menontonnya di kota baru, bekerja, dalam sehari. Datang dengan margin yang sangat besar. Jangan berpikir bahwa Anda akan berjalan di mana-mana, Anda akan benar-benar bekerja dengan cara yang sama. Anda akan menjadi pekerja lepas Turki biasa yang bangun dan bekerja, makan di jalan, bekerja, menonton acara TV dan tidur. Jika Anda tidak mengubah kota lebih dari sekali setiap dua minggu, maka semuanya akan baik-baik saja. Tidak ada masalah khusus.
Maxim: Semua orang mengerti bahwa pengetahuan bahasa Inggris diperlukan, tetapi tidak mudah untuk belajar dengan baik. Apakah Anda memiliki latar belakang yang baik? Dari mana Anda mendapatkan bahasa Inggris yang baik?
Andrew: Apakah kamu tertawa? Saya memiliki bahasa Inggris yang menjijikkan. Saya mengangkat topik ini di Lingvopank. Kami terbiasa sekolah bahwa bahasa adalah aturan, terutama dengan budaya Rusia yang beracun, di mana kami terus-menerus mengkritik orang yang berbeda. Kami terbiasa dengan fakta bahwa jika Anda mengatakan dan membuat kesalahan, maka semuanya buruk.
Sebenarnya, bahasa adalah sistem komunikasi, dan selama Anda dipahami, semuanya baik-baik saja. Kami tidak mengerti bagaimana bahasa adalah sistem duplikat. Itu seperti CD atau kode QR. Tahukah Anda bahwa sebagian besar kode QR dapat dimusnahkan, dan masih dapat dibaca? Karena ada algoritma khusus untuk menggandakan informasi. Intinya adalah bahwa Anda tidak perlu tahu bahasa dengan baik, Anda harus bisa berkomunikasi di dalamnya.
Kemajuan utama saya dalam bahasa terjadi ketika saya berhenti takut. Kita semua takut, karena kita terus-menerus diganggu di sekolah dan di Internet - twitter Rusia yang mengerikan, di mana mereka lebih diracuni untuk kesalahan ketik daripada untuk ide anti-reaksi. Faktanya, orang Rusia memiliki bahasa Inggris yang baik. Dimulai dengan fakta bahwa ini adalah bahasa yang terkait erat: bukan bahasa Mandarin, di mana Anda umumnya memiliki sistem bahasa yang berbeda. Kita tidak dapat membayangkan, seperti di seluruh dunia, bahkan lebih buruk di sana.
Rusia berada pada level normal. Tentu saja, lebih buruk daripada Norwegia dan negara-negara kecil serupa yang hanya harus belajar bahasa, karena tidak ada konten. Tetapi orang-orang Rusia lainnya berbicara bahasa Inggris dengan baik, tidak ada masalah. Aturan utama - jangan takut, hanya berkomunikasi, beralih ke bahasa isyarat, minum sebelum diskusi (ini membantu untuk memahami bahwa hal-hal sederhana sangat penting).
Poin kedua - nonton serial dengan subtitle, itu sangat membantu.
Bepergian, hanya belajar bahasa.
Dan yang paling penting - cobalah untuk berbicara.
Kami takut dengan bahasa itu, karena di Rusia ada masalah: kami berkomunikasi sangat sedikit dengan dunia luar. Di satu sisi, ini bagus, karena ada pasar internal yang memungkinkan beberapa orang kecil untuk keluar. Ketika Yandex tumbuh dari monopoli Google karena kendala bahasa, ada juga sejumlah besar lift sosial yang dapat dipanjat oleh seorang programmer, yang tidak akan pernah terjadi di Barat.
Tetapi sebagai imbalannya ada masalah bahwa pasar ditutup, kita tidak melihat ke luar dan semua orang yang telah bangkit, pria yang sangat baik, tidak pergi ke Barat, karena mereka takut bahasa Inggris. Rekomendasi saya adalah memiliki dua akun Twitter, menulis dalam bahasa Rusia dalam satu untuk membantu budaya Anda (ini juga penting), dan bahasa Inggris untuk latihan. Ketika Anda menulis dalam bahasa Inggris, Anda akan mengerti bahwa itu tidak sulit. Satu-satunya hal adalah bahwa sedikit orang akan membaca Anda, karena di Barat ada cukup banyak dari mereka sendiri, tetapi massa yang kritis dengan demikian mendapatkan pula, Anda akan mendapatkan 150-300 pembaca Anda.
Berpartisipasi dalam pertemuan berbahasa Inggris di Rusia, tidak menakutkan, tidak ada yang akan menyinggung Anda, semuanya baik-baik saja.
Dmitry: Apakah Anda merekomendasikan mencoba pindah ke suatu tempat untuk sementara waktu untuk belajar bahasa, jika demikian, di mana?
Andrew: Untuk menghilangkan rasa takut, perjalanan apa pun sudah cukup. Tetapi bagaimana belajar lebih jauh adalah pertanyaan yang bagus. Sejujurnya, saya tidak tahu, saya tidak tahu bahasanya dengan baik. Tetapi saya dapat mengatakan bahwa ketika Anda berbicara di sebuah rapat umum di New York, bahkan jika penonton hampir tidak merasakan aksen Anda, maka semuanya tetap sama, karena setengah dari penonton dari India, setengah dari Cina.
Dan saya bisa mengatakan sesuatu yang lain. Di Rusia, ada narasi populer yang perlu disalahkan, dan di mana-mana baik: "Di Rusia, semuanya buruk, saya akan membuang dan saya akan bahagia." Jujur - ini adalah motivasi yang lebih baik untuk tidak dibimbing. Karena narasinya sudah sangat tua, dan secara historis kita tahu bahwa narasinya tidak berfungsi sejak abad ke-18 dan ke-19. Di negara lain, secara fundamental tidak lebih baik. Ada masalah manajemen mendasar, tetapi cepat atau lambat masalah itu muncul di negara mana pun.
Ada masalah pilihan ketika Anda memiliki tugas, dan diselesaikan dengan cara yang berbeda. Sebagai contoh, kami ingin jalan dibersihkan, dan untuk ini, sebenarnya, kami membutuhkan masyarakat yang terpusat. Untuk melakukan ini, perlu untuk menindas semua orang yang berpikir salah, seperti di Amerika Serikat. Ada sistem aturan dan keseimbangan internal yang sangat ketat tentang siapa yang harus memikirkan bagaimana dan, pada kenyataannya, Amerika Serikat dalam hal ini mirip dengan Cina. Hanya saja aturannya tidak diucapkan, dan negara tidak melakukan ini - masyarakat sendiri yang melakukannya.
Saya tidak akan mengatakan bahwa ada solusi yang pasti di mana lebih baik - di mana jalan rusak, atau di mana masyarakat mengatakan bagaimana Anda harus berpikir. Tetapi ini bukan solusi biner, dan ini adalah masalah politik dan sosiologi. Dan garis besarnya secara umum: seringkali negara lain dalam beberapa hal lebih baik, karena di tempat lain lebih buruk.
Lebih baik untuk tidak segera pindah, tetapi untuk melakukan perjalanan keliling dunia, dan kemudian Anda akan menyadari bahwa pada umumnya hal-hal apa yang siap Anda berikan untuk mendapatkan hal-hal lain sebagai balasannya. Dan dengan pemahaman ini, Anda dapat memilih negara tempat Anda dapat pindah. Dan kemudian bergerak secara normal.
Tapi jujur saja, Anda tidak akan bahagia, karena gelombang pertama emigrasi selalu mengalami penderitaan yang mengerikan, menjadi depresi, setelah bergerak Anda akan kehilangan seluruh lingkaran sosial Anda.
Dmitry: Saya ingin tahu apa perbedaan komunitas pengembang Rusia di negara lain.
Andrei: Berbicara tentang Amerika, ini adalah situasi yang menarik. Pertama, benar-benar ada sistem kaku dalam memaksakan filsafat. Dia selalu begitu, mereka memiliki sistem hukuman yang ketat, misalnya pelecehan publik. Tetapi sistem ini sudah cukup tua dan, secara umum, berfungsi. Jujur, di sisi lain, dia paling sering menggunakan ide-ide yang tepat untuk disebarkan, dan yang salah, yah, berlebihan di tanah.
Gagasan utama adalah bahwa ada pemikiran yang sangat stereotip dalam budaya untuk dengan cepat menyebarkan praktik-praktik yang baik. Di sana sejumlah besar programmer tidak melakukan kesalahan bodoh, karena semua orang disuruh menulis seperti ini, semua orang menulis seperti itu. Sebaliknya, cukup sulit untuk mempromosikan ide-ide Anda.
Dan ada budaya khusus obrolan ringan - menggertak untuk ide-ide yang salah menciptakan ketegangan sosial, dan di AS ada sejumlah besar negara, dan mereka tidak tahu bagaimana melakukan topik-topik komunikasi yang saling bertentangan tanpa mengintimidasi, sehingga mereka memiliki daftar tema berhenti.
Ini adalah perbedaan sosial yang paling penting di masyarakat. Dari kelebihannya - mereka mudah didaki, dan sangat berhati-hati agar orang tidak menderita. Anda datang, semua orang ramah, semuanya baik-baik saja, selama Anda adalah orang biasa yang bermain sesuai aturan.
Fitur menarik kedua adalah bahwa mereka sering membayar mitaps, harga simbolis 5-10 dolar untuk makanan. Lagi-lagi karena kapitalisme.
Dmitry: Dan kalau bukan AS, tapi negara lain?
Andrew: Di tempat kedua, omong-omong saya mempelajari komunitas, ini adalah Cina. Ada fitur yang menarik di sejumlah besar pengembang, dan di sisi lain, mereka memiliki format yang menarik - jaringan yang sangat sedikit. Biasanya ditutup, Anda diundang ke "sarapan khusus", yang berlangsung dengan para tokoh masyarakat. Di sisi lain, orang-orang di pertemuan benar-benar datang untuk membicarakan topik yang rumit dan menyerap pengetahuan baru. Jujur saja, semua fitur ini bukan kerangka kerja. Komunitasnya beragam, dan ada cukup banyak anarkis di Cina, di Amerika, sejumlah besar orang juga diludahi larangan. Nah, di Rusia ada yang ramah, sopan dan baik, bukan kritikus kecil-kecilan.
Fitur lain yang menarik dari Cina adalah bahwa mereka tertutup, dengan dunia yang terpisah, ini adalah plus dan minus. Mereka memiliki sejumlah besar prestasi mereka, karena ada tempat di mana mereka dapat berkembang. Dan di sisi lain, mereka sangat menderita dari kenyataan bahwa mereka tidak dapat melakukan perkembangan mereka, seperti di Rusia. Semua penutur bahasa Mandarin teratas takut berbicara bahasa Inggris dari kata "umum", walaupun mereka biasanya berbicara bahasa Inggris.
Berikutnya adalah Jepang. Terlepas dari kenyataan bahwa ini adalah negara komputer, negara adidaya dengan teknologi canggih, pemrograman dianggap lebih buruk daripada manajemen. Dipercayai bahwa, tidak seperti manajer, pemrograman adalah kerja yang rendah: mereka memberi tahu orang tersebut dan dia menulis kode. Akibatnya, tidak ada komunitas, dan TI berkembang sangat buruk, startup dikembangkan jauh lebih buruk daripada kemampuan negara. Tidak ada Valley, "geniuses-programmer," itu saja. Dan ada jauh lebih sedikit wanita di IT daripada di China, karena masyarakat tradisional. Di Cina, semuanya baik-baik saja dengan ini - ada banyak wanita Cina dengan pandangan dan pengalaman yang menarik, meskipun ada juga ruang untuk tumbuh.
Ada komunitas Brasil yang baik. Negara-negara Hispanik tidak memilikinya, karena semua orang berorientasi ke Amerika. Prancis juga memiliki komunitas internal yang baik.
Tetapi di Sri Lanka, semuanya sangat buruk dengan komunitas TI, karena ketika mereka menikahi seorang gadis, paling sering melalui keluarganya, ayahnya bertanya: "Kamu bekerja dengan apa?" Dan ada daftar putih profesi "benar", dan programmer belum masuk ke dalamnya. Oleh karena itu, ada sangat sedikit programmer, walaupun ada banyak keuntungan potensial: uang, kemungkinan imigrasi. Seorang ayah yang baik akan menghargai bahwa ia memberikan putrinya di tangan yang baik, tetapi ini tidak terjadi, karena daftarnya belum diperbarui.
Saya menyarankan Anda untuk berbicara di konferensi Cina dan India: mudah untuk sampai ke sana (mereka dengan senang hati menerima seseorang dari luar), dan Anda berlatih dalam bahasa Inggris di lingkungan di mana Anda tidak akan takut, karena tidak ada yang benar-benar tahu bahasa Inggris dan semua orang berbicara dengan kesalahan.
Konferensi Ideal
Dmitry: Jika kita berbicara tentang konferensi, apa faktor penentu untuk berpartisipasi sebagai pembicara?
Andrew: Bagi saya, faktor penentu adalah ketersediaan konferensi. Meskipun kadang-kadang, jika jalur saya melewati beberapa negara, saya setuju untuk konferensi yang tidak mudah diakses orang, hanya untuk memompa laporan.
Saya pikir ada masalah besar bahwa harga konferensi sangat tinggi. Saya mengerti bahwa konferensi perlu menghasilkan uang, tidak ada masalah dengan ini, tetapi ada beberapa JSConf yang menghabiskan $ 500 dan, terus terang, mereka menghabiskannya untuk hal-hal yang dapat diselamatkan. Misalnya, untuk makan malam, afterparty yang paling kuat, meskipun saya, sejujurnya, lebih suka minum bir yang tidak enak, tetapi supaya ada orang yang menarik.
Dan harga yang besar menyebabkan fakta bahwa pembicara tidak tertarik untuk berkomunikasi dengan audiens, kadang-kadang sulit untuk mendukung topik, karena pada konferensi ini hanya karyawan perusahaan besar, pencipta yang sama dari implementasi JS CRDT terbaik,
Viktor Grishchenko tidak bisa datang, karena tiketnya sangat mahal. Ada banyak cara untuk menghemat, dan mereka perlu diterapkan, tiket mahal salah. Konferensi harus dapat diakses.
Saya sering setuju untuk pergi ke pertemuan kecil, supaya semua orang memiliki akses normal ke jaringan. Dan pada banyak pertemuan, dialog lebih baik daripada di konferensi dengan harga tiket tinggi. Ini pendekatan saya.
Dmitry: Tanpa konferensi apa yang tidak baik? Sudah jelas tentang jaringan, aksesibilitas, dan apa lagi?
Andrei: Ya, sebagai pembicara, saya sangat menghargai ketika ada timer di depan panggung. Dalam hal ini, di HolyJS semuanya sangat profesional, saya suka organisasi pertunjukan. Secara umum, jaringan adalah hal utama, orang pergi ke konferensi bukan untuk pengetahuan, lebih mudah untuk membaca artikel daripada laporan, tetapi untuk perasaan memiliki komunitas.
Komunitas adalah hal terpenting yang terjadi di konferensi. Perasaan bahwa Anda sedang berbicara, dan sesuatu telah berubah dalam diri Anda, Anda tahu sesuatu. Ada ide bagus bahwa masyarakat kita kurang memahami "mengapa". Kami pergi ke konferensi untuk memahami mengapa kami melakukan semua ini. Dan konferensi yang baik mungkin akan menyelesaikan masalah ini.
Dmitry: Anda mengatakan "bukan untuk pengetahuan", ini adalah masalah yang sangat kontroversial. Apakah Anda akan pergi ke sebuah konferensi di mana kumpulan orang-orang dengan topik yang sangat mendasar, tetapi dari komunitas yang sangat berbeda, berkumpul?
Andrei: Ya, tentu saja, itu akan sangat menyenangkan.
Dmitry: Dan itu akan lebih menarik daripada konferensi di mana ada laporan yang serius dan kuat?
Andrei: Saya pikir kedua pendekatan itu bagus, dan tidak ada masalah di sini.
Dmitry: Mungkin pertanyaan terakhir. Apa yang Anda harapkan dari HolyJS?
Andrew: Pesta yang bagus! Pada 2016, itu langsung dikreditkan, salah satu yang terbaik dalam hidup saya, dan kemudian semuanya terorganisasi dengan sangat baik.
Dmitry: Apa yang akan Anda rekomendasikan saat ini untuk menjadikannya lebih baik? Ingin pesta?
Andrew: Saya akan mencoba mengatur dengan mitaps lokal. Kami memiliki banyak pertemuan lokal, dan ternyata cukup keren ketika mereka memiliki kesempatan untuk melakukan sesuatu sendiri - ada banyak orang yang berinisiatif, Anda perlu memberi mereka kesempatan. Dan itu akan keren jika penyelenggara dari semua aksi unjuk rasa lokal atau pembicara utama mereka diberi tiket gratis atau semacam bantuan, itu akan bagus.
Di HolyJS terdekat (St. Petersburg, 24-25 Mei), Andrei akan berbicara lebih banyak tentang mempromosikan proyek sumber terbuka. Dan selain dia, akan ada banyak tokoh penting dari open-source JS: dari Ryan Dahl (Node.js, Deno) ke Michel Weststrate (MobX, Immer). Semua rincian tentang topik laporan mereka ada di situs web , tiket dapat dibeli di sana, dan secara bertahap harganya menjadi lebih mahal.