Segera, pada 22-23 November, DotNext Moskow berikutnya akan diadakan. Program ini menjadi lebih spesifik, jadi saya ingin berbagi beberapa pengamatan tentang laporan arsitektur dan hardcore.

Pertama, ada beberapa pembicara “tanpa kategori”. Mereka adalah orang-orang yang dapat mengisi konferensi terpisah. Anda tahu nama mereka: Jeffrey Richter , Pavel Yosifovich dan Greg Young .

Biasanya dalam artikel tentang Habré di sebelah pembicara kami segera memberikan fotonya. Dalam kasus Jeffrey dan Paul, kasus khusus - Anda sebaiknya mengingat orang-orang ini di sampul buku:

Di sebelah kanan adalah buku-buku Pavel Yosifovich . Ia dikenal sebagai penulis Windows Internal, WPF Cookbook, Menguasai Pengembangan Aplikasi Windows C ++, dan lima kursus di Pluralsight. Jika Anda tiba-tiba juga tertarik pada C ++, maka Pavel baru-baru ini memposting video di YouTube tentang model memori C ++. Selain itu, ia adalah pengembang, pelatih, dan pembicara terkenal, tetapi dalam peran ini kami jarang melihatnya - ia hampir tidak pernah terjadi di Rusia. Jadi, Pavel - di DotNext kami. Ini adalah kesuksesan dan kemenangan besar, bahwa semuanya berhasil dan dia benar-benar akan datang. Dalam laporan barunya, "Windows 10 internal untuk pengembang. NET," ia akan berbicara tentang fitur internal yang menarik dari Windows 10, bagaimana fitur-fitur ini mempengaruhi pengembang .NET dan bagaimana Anda dapat dengan bermanfaat menempatkan mereka ke layanan Anda.

Di sebelah kiri adalah buku Jeffrey Richter . Kami sudah melakukan wawancara terperinci dengannya untuk Habr, jika Anda benar-benar ingin tahu apa yang dipikirkan orang yang menentukan arah pengembangan Azure, Anda harus pergi ke sana. Jeffrey adalah pembuat serial buku-buku klasik. Setelah mendapatkan popularitas kembali di awal 90-an berkat buku tentang pemrograman Windows 3.1, ia tidak berhenti. Buku besar berikutnya, "Programming Aplikasi untuk Microsoft Windows", menjadi buku klasik, yang kemudian diterbitkan sebagai "Windows via C / C ++" dan bertahan beberapa edisi. Hal yang sama terjadi dengan "CLR via C #". Orang-orang masih bertanya kapan rilis ulang “CLR via C #” berikutnya (jika Anda juga tertarik, datanglah ke konferensi dan tanyakan pada diri Anda sendiri!). Dia sekarang adalah Rekan Arsitek Perangkat Lunak di Microsoft, bekerja di Aplikasi & Penyimpanan Cloud Terdistribusi, dan menyeret seluruh platform ke masa depan yang lebih cerah. Kami sangat menyarankan Anda mengunjungi "Membangun aplikasi responsif dan terukur" , sebuah laporan tentang penggunaan cloud cloud yang efektif - dari orang yang tahu segalanya tentangnya.

Adapun Greg Young , dia tidak memiliki buku-buku profil tinggi. Dia adalah "satu-satunya" penemu istilah CQRS, salah satu tokoh paling terkenal dan ikon dalam arah ini. Seperti yang mungkin sudah Anda tebak, dalam CQRS semuanya benar-benar tidak sesederhana dan dapat dimengerti seperti yang terlihat pada pandangan pertama, dan Greg adalah orang yang dapat Anda diskusikan dengan semua ini. Jika Anda ingin melihat apa yang dikatakan Greg, ia langsung mencari di YouTube , ia pernah menulis di CodeBetter , dan jika Anda melihat buku-buku tentang CQRS di Amazon, maka ia dipercayakan dengan menulis pengantar buku Exploring CQRS dan Event Sourcing yang ditulis oleh sutradara. Splunk

Hardcore

DotNext telah memantapkan dirinya sebagai konferensi di mana pembicara terkemuka muncul berulang-ulang, mengungkapkan masalah khusus yang paling kompleks. Ada beberapa topik yang mengubah hampir semua laporan menjadi hardcore, misalnya, memastikan kinerja maksimum dan detail implementasi dari teknologi yang kompleks.

Detail Tingkat Rendah

Kita sudah bicara tentang Jeffrey Richter dan Pavel Yosifovich. Tapi itu belum semuanya! Mari kita lihat apa yang sudah disiapkan Raffaele Rialdi, Chris Bacon dan Yegor Grishechko untuk kita.

Baiklah, mari kita masuk dengan kartu truf, pernahkah Anda ingin menulis .NET runtime Anda? Apakah itu berhasil? Chris Bacon berhasil membuat proyek percontohan, DotNetAnywhere , runtime yang sangat kompatibel dengan dukungan untuk hal-hal seperti multithreading, PInvoke, pengumpulan sampah, dan sebagainya. Ini adalah proyeknya yang digunakan untuk membangun kerangka kerja Blazor , yang memungkinkan Anda untuk menjalankan .NET langsung di browser menggunakan teknologi WebAssembly. (Omong-omong, laporan tentang Blazor dibuat oleh Nikita Tsukanov, videonya ada di YouTube ). Secara umum, DotNext ini akan mengatakan "Jadi, Anda ingin membuat runtime .NET Anda sendiri?" - Laporan yang sangat aneh dan tidak biasa tentang penulisan runtime.

Mari kita beralih ke topik yang lebih praktis. Jika Anda pernah ke DotNext, Anda pasti sudah tidak asing lagi dengan Rafael Rialdi dan topik-topik yang menjadi spesialisasinya. Jika tidak, sekarang saatnya membiasakan diri!



Kali ini, Rafael akan datang dengan laporan baru, "Meningkatkan manajemen memori dalam skenario interoperabilitas" . Anda mungkin telah memperhatikan bahwa Span<T> dan API Span<T> Memory<T> baru telah muncul, dan sekarang Anda dapat mengakses memori yang tidak dikelola tanpa harus melakukan penyalinan yang tidak berarti ke objek yang dikelola. Rafael, dalam perjalanan laporannya, akan menelusuri API ini, menunjukkan rincian tentang contoh-contoh praktis yang menarik seperti IoT, dan bahwa manusia biasa dalam kegiatan sehari-hari dapat melakukan semua ini.

Baru-baru ini, ValueTask, jenis-jenis tugas, dan IValueTaskSource telah muncul di versi bahasa terbaru. Banyak yang bahkan tidak tahu bahwa jenis ini ada, dan sebagian besar dari mereka yang tahu tentang keberadaan mereka tidak mengerti mengapa mereka ada. Egor Grishechko dalam laporannya "ValueTask: apa, mengapa dan mengapa" akan memberi tahu Anda apa alat-alat baru ini, mengapa mereka digunakan dan kapan mereka dibenarkan, dan kapan tidak.

Kinerja maksimal

Hampir semua laporan dalam satu atau lain cara berhubungan dengan kinerja, meskipun secara sepintas. Ini adalah fitur karya pengembang. Tetapi beberapa yang ingin saya soroti secara khusus, ini adalah laporan dari empat pembicara:

• Konrad Kokosa
• Egor Bogatov
• Evgeny Peshkov
• Alexandre Mutel

Kita telah melihat pembicaraan tentang runtime .NET kita sendiri. Bagaimana dengan GC Anda sendiri? Apakah kita perlu menambal file mengerikan dengan ukuran dua megabyte kode C ++ yang dihasilkan? Untungnya tidak. Di .NET Core 2.1, mereka menambahkan fitur baru yang disebut Local GC, yang memungkinkan Anda untuk sepenuhnya mengganti pengumpul sampah standar dengan sesuatu yang umum, atau sebaliknya - menggunakan pengumpul standar di luar lingkungan .NET yang biasa. Dalam laporan “Jadikan kustom Anda .NET GC -“ mengapa ”dan“ bagaimana ”, Konrad Kokosa akan memperkenalkan kepada kami bagaimana hal ini dilakukan. Ini akan menarik dan bermanfaat terutama bagi mereka yang ingin lebih memahami manajemen memori dan perilaku GC. Esensi utama dari laporan ini bukan karena Anda pulang dari konferensi dan segera mentransfer produk ke sesuatu yang ditulis sendiri. Sebaliknya, itu adalah laporan inspirasional keren yang memperluas batas-batas apa yang mungkin. Anda tidak harus melakukan ini, tetapi sekarang ada kesempatan untuk bereksperimen. GC tampaknya semakin tidak bisa dipahami dalam dirinya sendiri dan semakin jatuh ke tangan Anda sebagai alat yang nyaman dan patuh.

Tetapi GC hanyalah awal. Baru-baru ini, di banyak runtime telah menjadi populer untuk memberikan pengguna akses untuk menghasilkan instruksi prosesor SIMD, seperti SSE dan AVX. Misalnya, di JS, SIMD.js ditambahkan (dan dihapus), di Jawa, proyek Panama melakukan ini, dan sebagainya. Mod ini juga tidak memotong .NET. Mereka memberi kami kekuatan super, tetapi mereka sedemikian rupa sehingga tidak cukup untuk memilikinya - Anda masih harus dapat menggunakannya, dan ini sulit. Di satu sisi, kontrol pada tingkat seperti itu membutuhkan motivasi dan kualifikasi yang luar biasa: untuk menulis kode vektor yang lebih unggul dalam kinerja daripada skalar, Anda perlu menekan tidak hanya hal-hal seperti penyelarasan, tetapi juga mengikuti serangkaian instruksi spesifik, pikirkan tentang hasil generasi dan hal-hal yang terjadi jika Anda keluar dari jalur cepat. Di sisi lain, jika Anda benar-benar menulis aplikasi kinerja maksimum dan menyimpan setiap ukuran, Anda dapat menghadapi kebodohan bahkan dari kompiler yang paling canggih. Bahkan masalah yang relatif dipelajari, seperti alokasi register, adalah NP-complete ( satu , dua ), membutuhkan intervensi manusia, dan situasi SIMD tampaknya tidak lebih baik.

Tahun ini, Yegor Bogatov datang dengan laporan baru, "Optimasi Di Dalam. NET Core," di mana ia akan memberi tahu Anda cara menghasilkan SIMD dari kode tingkat tinggi. Dengan Yegor, kami akan segera merilis wawancara terperinci tentang Habré. Sekarang saya ingin mengatakan bahwa Egor bekerja di Microsoft, berspesialisasi dalam Mono dan .NET Core, dan ini bukan pertama kalinya ia membuat presentasi tentang DotNext. Simpan beberapa entri sebelumnya:



Egor sangat tertarik dengan pembuatan game komputer dan mobile, di mana semua optimasi ini dapat diterapkan. Sebuah sejarah baru-baru ini dengan Assassin's Creed Odyssey yang baru-baru ini dirilis mengkonfirmasi hal ini: pengembang harus menentukan prosesor dengan dukungan untuk AVX / SSE 4.1 dalam persyaratan sistem minimum, bahkan meskipun ada penurunan pada basis klien (ini adalah prosesor generasi ke-2 Intel: prosesor Intel 2nd gen: Intel Core i5-2400 dan lebih tinggi, yang sebelumnya disebut Sandy Bridge dan yang tidak dimiliki semua orang).

Jika contoh game terlaris tidak meyakinkan Anda, maka Alexandre Mutel pasti akan meyakinkan Anda. Ini adalah pembicara kedua yang dengannya kami akan melakukan wawancara terperinci untuk Habr. Dia bekerja untuk Unity Technologies, perusahaan yang menciptakan salah satu mesin permainan paling populer, Unity . (Omong-omong, mereka baru saja membuka kode C # untuk membaca). Alexandre tahu pasti bahwa ada kode kritis yang biasa tidak bisa ditangani oleh C # biasa. Oleh karena itu, mereka menemukan kompiler "burst" khusus: itu mengubah subset terbatas C # menjadi kode asli dioptimalkan menggunakan LLVM, yang memungkinkan Anda untuk mencapai kinerja yang sebanding dengan C ++, dan kadang-kadang bahkan lebih cepat. Bagaimana cara menghasilkan kode yang lebih baik daripada RyuJIT? Subset C # manakah yang masuk akal untuk menulis kode ultrafast? Pertanyaan-pertanyaan ini dan lainnya akan dibahas dalam laporan "Di balik burst compiler, mengonversi .NET IL ke kode asli yang sangat dioptimalkan dengan menggunakan LLVM" - Anda pasti tidak akan mau ketinggalan ini!

Saya ingin mengakhiri deskripsi kategori ini dengan sesuatu yang dapat langsung diuntungkan. Rupanya, "Metrik Sistem: mengumpulkan jebakan" sangat cocok untuk peran ini. Evgeny Peshkov dari Kontur akan memberi tahu Anda cara mengatasi metrik: bagaimana mereka berbeda di antara mereka sendiri, apa yang harus dilakukan dengan masalah kinerja dalam Process dan PerformanceCounter , bagaimana Penghitung Kinerja diatur di dalam, dan apa yang mengikuti dari ini dan seterusnya.

Laporan Evgeny sebelumnya, "Pengecualian Khusus dalam .NET," mengambil tempat kedua di konferensi DotNext Piter 2018. Ini membahas fitur masing-masing jenis pengecualian, misalnya, StackOverflowException , ThreadAbortException , AccessViolationException dan OutOfMemoryException yang terjadi ketika kesalahan terjadi pada sistem operasi atau tingkat runtime.

Praktik dan arsitektur terbaik

Setelah pengumuman kami, kadang-kadang sepertinya DotNext adalah semacam hardcore yang kuat untuk pengembang tingkat rendah. Padahal, program tersebut memiliki cukup kategori lain. Perhatikan program ini - ada tanda di sebelah sebagian besar laporan. Saat memilih laporan mana yang akan dituju, perhatikan mereka. Hardcore adalah tag tentang kinerja dan detail kompilator, di sebelahnya ada ikon bicara dengan "kambing". Tetapi lihatlah berapa banyak tema universal yang dapat Anda terapkan sekarang!



Sementara itu, menemukan laporan hebat tentang "praktik yang baik" dan "arsitektur" adalah hal yang sangat sulit. Fakta bahwa seseorang tampaknya merupakan ide yang brilian, bagi yang lain itu terdengar seperti omong kosong dan sebaliknya. Apakah pembicara di perusahaan memiliki arsitektur tertentu untuk sistem, tetapi bagi kita dengan cara yang berbeda? Dan apa artinya itu? Untungnya, ada serangkaian topik yang bisa dibahas tidak hanya karena alasan selera.

Praktik terbaik

Pertama, ini adalah area di mana masalah jelas terjadi. Setiap kali Anda terbang dengan pesawat terbang, Anda ingin mendengarkan koleksi musik, dan satu layanan cloud Rusia yang terkenal mengatakan bahwa baik Anda mengunduh koleksi Anda ke disk bawaan dan offline, tetapi dapatkah Anda memeriksa lisensi? Sebelum verifikasi lisensi, sepuluh kilometer secara vertikal. Lain kali Anda mengunduh semuanya dalam Hi-Res ke disk bawaan dan akan mendengarkan aplikasi pemutar. Dan di suatu tempat di tengah penerbangan, seorang pemain yang dibeli dengan jujur ​​bertanya - semuanya baik-baik saja, tetapi saya lupa memeriksa lisensi dan mengunduh sesuatu. Anda melompati sepuluh kilometer secara vertikal. Dari sudut pandang pengembang, ini terlihat lebih seperti neraka, karena banyak kerangka kerja yang akrab sama sekali tidak menyiratkan tidak adanya koneksi jaringan. Dalam beberapa kasus, Anda harus menulis banyak hal buruk seperti kode duplikat untuk membaca langsung dan cache. Sekarang kita mengalikan semua ini di cross-platform dan tetap di palung. Atau sepertinya begitu di awal? Tulis di komentar. Pada DotNext akan ada laporan yang luar biasa tentang hal ini, "Membuat aplikasi Xamarin proof mode pesawat" dari Gerald Versluis, yang dapat Anda ketahui dari berbagai pidato dan posting blog dan beberapa buku. Terlepas dari namanya, laporan ini akan menarik bahkan bagi orang-orang yang tidak terbiasa dengan Xamarin.



Ada topik-topik abadi, jawaban pasti yang belum ditemukan, tetapi setiap tahun pemahamannya berkembang pesat. Salah satu pertempuran yang tidak pernah berakhir adalah TDD vs TestLast. Untuk memulainya, banyak orang memiliki masalah dengan pengujian secara umum, pada tingkat proses - di dunia pembangunan yang didorong oleh tenggat waktu Anda tidak akan dikembangkan secara khusus. Kami bahkan melakukan konferensi pengujian khusus, Heisenbug . Pemrogram masih lebih rumit - TDD diciptakan sekitar tahun 99 sebagai bagian dari Pemrograman Ekstrim. Terlepas dari semua kejeniusannya, ia tidak pernah menguasai dunia, yang difasilitasi oleh sejumlah faktor. Dalam kehidupan biasa, ternyata bukan Test-First, tetapi Test-Last yang sebenarnya. Pendekatan ini juga memiliki kelebihan (sesuai dengan tenggat waktu lebih mudah) dan sejumlah kerugian yang jelas. Ingat artikel hyped tanpa ampun "TDD is Dead" dari pencipta Ruby on Rails? Itu ditulis pada tahun 2014. 4 tahun berlalu, dan pendulum tidak tetap di tempatnya. Bagaimana perasaan Anda tentang masalah ini? Di DotNext akan ada "Test Last, Test First, TDD: Kapan Menggunakan Satu atau Pendekatan Lain" - sebuah laporan dengan judul pembicaraan dari Alexander Kugushev. Alexander akan membahas secara terperinci semua pendekatan ini dan mempertimbangkan penerapannya pada contoh-contoh spesifik yang agak rumit.

Laporan lain menggemakan laporan ini - “Pengujian unit pragmatis” oleh Vladimir Khorikov, seorang spesialis dari jenis yang berbeda, seorang ahli dalam menyelamatkan proyek-proyek warisan perusahaan besar. Ya, kami tidak suka membicarakannya, tapi kadang-kadang hal paling bodoh menyebabkan kehancuran bahkan proyek yang paling tahan lama yang dibangun selamanya . Salah satu faktor teknis untuk kesuksesan jangka panjang perusahaan teknologi adalah tes unit yang tepat. Kita semua tahu banyak praktik, tetapi dalam jangka panjang, tidak semua praktik sama-sama bermanfaat. Laporan ini bukan untuk pemula - itu untuk mereka yang dapat menulis tes dan ingin membawa pemahaman mereka ke tingkat yang baru. Omong-omong, Vladimir memiliki blog yang sangat bagus di mana dia menganalisis masalah arsitektur yang paling menarik. Fiksi sangat dianjurkan untuk junior pemula untuk pencerahan, dan senior yang berpengalaman untuk sistematisasi.

Pada bagian praktik yang baik, saya ingin menyebutkan laporan lain - “Bagaimana cara bertahan di bawah beban: server yang toleran terhadap kesalahan, klien cerdas” oleh Igor Lukanin. Igor adalah orang yang, sebagai perwakilan Kontur, telah menghadiri hampir semua konferensi terakhir kami. Phillennium dan saya berulang kali mewawancarainya dan dengan cepat menyadari bahwa ia mampu memberikan jawaban yang mendalam dan akurat untuk sejumlah besar pertanyaan praktis. Tidak perlu mempersiapkan secara khusus untuk wawancara dengan Igor - kami mengajukan pertanyaan kepadanya, dan dia menjawab hampir semuanya. Selain pertanyaan yang paling penting: kapan Anda akan datang ke konferensi kami sebagai pembicara? Dan begitulah yang terjadi. Deskripsi laporan hanya mengatakan: "Anda akan belajar dari laporan cara membuat layanan microser tersebut dan melakukan pengujian stres untuk memastikan bahwa mereka menahan beban." Tidak ada keraguan bahwa itu akan terjadi, dan itu sangat berharga. Pada akhirnya, infrastruktur Contour mungkin merupakan produksi .NET terbesar di Rusia. Dalam hal apa pun, Anda selalu dapat mengajukan pertanyaan tambahan kepada Igor di area diskusi.

Arsitektur

Dan akhirnya, kategori terakhir kami untuk hari ini adalah arsitektur. Banyak dari kita yang ingat artikel Joel Spolsky "Jangan Biarkan Arsitektur Astronot Membuatmu Takut" . Jika Anda belum membacanya, lihat, tidak ada yang berubah banyak sejak itu. “Ingat bahwa penggemar arsitektur biasanya memecahkan masalah yang mereka pikir dapat diselesaikan. Sama sekali tidak yang bermanfaat untuk dipecahkan, ”Spolsky mengingatkan kita. Laporan “arsitektural” kami dipilih berdasarkan kesamaan: mereka harus memiliki manfaat praktis yang konkret, target audiens yang spesifik, mengkomunikasikan pemikiran dengan jelas hanya dalam empat puluh menit yang diberikan untuk laporan. Terlepas dari kesederhanaan luar dari persyaratan tersebut, tidak semua aplikasi lulus.

Jadi, siapa yang kita punya waktu ini? Kami sudah membahas Greg Young di awal artikel. Ini adalah pembicara "di luar kategori", yang layak dikunjungi hanya karena itu adalah Greg.

Vagif Abilov ( VagifAbilov ) akan datang dengan laporan "Kehidupan aktor dalam klaster: mengapa, kapan dan bagaimana . " Wagif adalah pembicara terkenal dan anggota komite program DotNext. Ngomong-ngomong, permintaan sangat tinggi ditempatkan pada laporan peserta PC - ini harus menjadi contoh bagaimana cara memberitahu laporan arsitektur yang baik. Kali ini akan ada laporan yang kuat tentang model aktor, Akka dan batas-batas penerapannya. Kami akan membahas penskalaan dan templat keputusan dasar cluster. Jelas bahwa lebih banyak yang bisa dikatakan, tetapi sulit dilakukan tanpa spoiler. Datang saja ke laporan dan cari tahu sendiri semua ini. Semua keputusan bukanlah penerbangan pemikiran astronot, tetapi diuji berdasarkan pengalaman Norwegian Broadcasting Corporation (NRK).

Vagif tidak langsung menjadi anggota PC, tetapi mulai sebagai pembicara pada DotNext sebelumnya.

Orang belajar arsitektur dari buku-buku lama yang ditulis untuk Jawa. Buku-buku itu bagus, tetapi mereka memberikan solusi untuk masalah waktu itu dengan instrumen waktu itu. Waktu telah berubah, C # lebih mirip dengan Scala cahaya dari Jawa, dan ada beberapa buku bagus yang baru.

Dalam laporan "Desain Instan" Maxim Arshinov akan berbicara tentang kriteria untuk kode yang baik dan kode yang buruk, bagaimana dan bagaimana mengukurnya. Dia akan membuat ikhtisar tentang tugas dan pendekatan yang khas, dia akan menganalisis pro dan kontra. Pada akhirnya, ia akan memberikan rekomendasi dan praktik terbaik untuk merancang aplikasi web. Maxim - seperti yang mungkin sudah Anda duga, penulis terkenal @marshinov . Dia adalah salah satu pendiri perusahaan outsourcing teknologi tinggi Grup Teknologi Tinggi, dan di samping melakukan bisnis, dia mengajar di Sekolah Tinggi Teknologi Informasi. Artinya, ini adalah laporan seseorang yang telah berada dalam masalah "di kedua sisi barikade": baik dari sisi mempelajari teknologi baru dan dari sisi penggunaan dalam bisnis nyata.

Dan akhirnya, laporan terakhir dalam ulasan hari ini. Alexey Merson dengan laporan "Desain berbasis domain: resep untuk pragmatis" akan mengungkapkan kepada kita esensi dari DDD. Lebih tepatnya, dia yang tidak tahu akan mencari tahu. Siapa tahu - tahu lebih baik. Pengalaman pribadi yang kaya memungkinkan menceritakan hal-hal kompleks kepada Alexei dalam bahasa yang sederhana dan mudah dimengerti.

Kami mengingatkan Anda bahwa DotNext 2018 Moskow akan segera diadakan - pada 22-23 November di Radisson Royal Moscow Congress Park. Tiket masih dapat dibeli di situs web konferensi .

Dan juga, teman-teman kami DevZen Podcast baru-baru ini merilis rilis PC DotNext, Anda dapat mendengarkan sesuka hati.