Hari ini set baru telah dibuka di
Yandex School of Interface Development di Moskow. Dari 7 September hingga 25 Oktober, tahap pertama pelatihan akan berlangsung. Siswa dari kota lain akan dapat berpartisipasi di dalamnya dari jarak jauh atau secara langsung - perusahaan akan membayar untuk jalan dan akomodasi di asrama. Kedua, ini tahap terakhir akan berlangsung hingga 3 Desember, hanya bisa diselesaikan sendiri.
Nama saya Julia Seredich, kami menulis posting ini bersama dengan Sergey Kazakov. Kami berdua pengembang antarmuka di kantor Yinsk Minsk dan lulusan SRI beberapa tahun terakhir.
Pada kesempatan pembukaan pendaftaran di Moskow, kami menerbitkan analisis tugas masuk ke Sekolah sebelumnya - di sini di Minsk.
Jika kita menelusuri sejarah tugas SRI, maka dari tahun ke tahun kami menguji tiga keterampilan penting untuk seorang programmer:
- Tata letak Setiap pengembang harus bisa mengeset. Itu tidak terjadi bahwa Anda memiliki Paman Seryozha yang mengeset untuk seluruh tim, dan Anda hanya menulis skrip. Oleh karena itu, setiap siswa harus menunjukkan bagaimana dia tahu cara mengeset.
- Javascript Jika masalah ini terbatas pada pengaturan huruf, maka kita tidak akan memiliki sekolah pengembangan antarmuka, tetapi sekolah tata letak. Antarmuka terlipat yang indah perlu dihidupkan kembali. Oleh karena itu, selalu ada tugas di JS, tetapi kadang-kadang juga tugas tentang algoritma - kami sangat menyukainya.
- Pemecahan masalah mungkin merupakan keterampilan utama pengembang. Semuanya berubah sangat cepat dalam menciptakan antarmuka. Seperti halnya Lewis Carroll: "Anda harus berlari secepat hanya untuk tinggal di tempat yang sama, tetapi untuk sampai ke tempat lain Anda harus berlari dua kali lebih cepat." Setiap hari kita dihadapkan dengan teknologi baru - perlu diperhitungkan dan dapat memahaminya. Oleh karena itu, dalam tugas ketiga, kami mengusulkan untuk memahami teknologi yang biasanya tidak dikenal oleh pengembang pemula.
Dalam analisis setiap tugas, kami akan memberi tahu tidak hanya tentang prosedur yang benar, tetapi juga tentang kesalahan umum.
Tugas 1: Portofolio
Tugas pertama dikerjakan oleh perancang Yandex. Koleksi Alexei Cherenkevich, yang tahu cara mengeset, dan rekannya dalam layanan, perancang antarmuka, Sergey Samsonov.
Ketentuan
Buat situs portofolio: beri tahu kami tentang diri Anda, pekerjaan Anda, dan harapan dari Sekolah. Situs harus mencocokkan tata letak yang diusulkan sebanyak mungkin (tautan ke tata letak: 1000px , 600px , 320px , spesifikasi ). Kami hanya tertarik pada tata letak, jadi jangan gunakan JavaScript.
Saat memeriksa, kami akan mempertimbangkan:
- ukuran padding, akurasi warna, gaya font, ukuran ukuran;
- tata letak semantik;
- kehadiran berbagai status elemen: tampilan tombol dan tautan saat Anda mengarahkan kursor, menyorot bidang input aktif, dll.;
- kompatibilitas lintas-browser (diperiksa dalam versi terbaru dari browser populer).
Nilai tambahnya adalah:
- penggunaan solusi-CSS modern: flexbox, grid, dll.
- tata letak adaptif;
- penggunaan pra-dan (atau) post-prosesor, perakitan, minifikasi, optimalisasi kode output;
- Validasi formulir HTML, tombol unggah bergaya file.
Tugas ini cukup banyak, sehingga Anda dapat melewati apa yang tidak akan berhasil. Ini akan sedikit menurunkan skor, tetapi Anda masih bisa menunjukkan pengetahuan Anda. Setelah selesai, kirim kami dua tautan - ke portofolio dan kode sumber di GitHub.
Tata letak yang diusulkan dalam penugasan tidak hanya dengan layar untuk perangkat seluler, tablet, dan desktop, tetapi juga dengan spesifikasi yang sebenarnya.
Untuk menambahkan sebanyak mungkin objektivitas pada hasil tes tugas pertama, ada banyak kriteria untuk tes ini.
Kriteria
Situs yang selesai . Ini kelihatannya jelas, tetapi beberapa orang melewatkan beberapa blok sepenuhnya - entah mereka ingin menghemat waktu, atau mereka tidak bisa membuatnya. Tata letak dapat dibagi secara kondisional menjadi empat layar utama: layar utama dengan avatar, blok dengan daftar harapan dari SRI, blok dengan portofolio dan blok dengan informasi kontak. Mereka dapat dibuat dalam bagian atau hanya menggunakan div, yang utama adalah bahwa keempat blok tersedia.
Tata letak pencocokan . Perancang membuat spesifikasi terpisah (termasuk warna, tipografi, tombol, dll.) Untuk memudahkan calon. Di bawah ini adalah tip pada lekukan dan fitur layar pertama. Sangat senang dengan orang-orang yang memperhitungkan semua keinginan perancang: misalnya, layar pertama seharusnya tidak kurang dari ketinggian viewport.
Tata letak adaptif - ini adalah saat antarmuka tidak hanya dibuat sehingga pada tiga resolusi semuanya pixel demi pixel sesuai dengan tata letak. Dalam kondisi perantara, tata letak juga tidak boleh berantakan. Seseorang lupa untuk membatasi lebar maksimum wadah dan menarik semuanya ke 1920 piksel, seseorang mengacaukan latar belakang, tetapi secara keseluruhan para kandidat melakukan pekerjaan ini dengan baik.
Tata letak semantik . “Berapa kali mereka memberi tahu dunia” bahwa tautan harus dibingkai sebagai <a>, tombol harus dibingkai sebagai <button>. Untungnya, sebagian besar kandidat telah memenuhi persyaratan ini. Tidak semua orang mengenali daftar yang bersembunyi dalam harapan dari SRI dengan membuatnya menggunakan tag div, tetapi tidak terlalu menakutkan. Ada seorang kandidat yang menyisipkan semua tag semantik yang hanya dia tahu - di mana itu perlu dan di mana itu tidak perlu. Misalnya, alih-alih daftar, <section> dan <article>. Namun, semantik - ini adalah tentang memahami komposisi halaman Anda dan tujuan setiap blok (mayoritas melakukannya di sini), serta tentang penggunaan pra dan / atau post-prosesor (beberapa melakukannya di sini, meskipun ini juga dalam poin - kurang dan scss paling sering terhubung) .
Penggeser yang berfungsi . Dalam penugasan, kami menulis bahwa JS tidak dapat digunakan. Di sini kemampuan untuk memecahkan masalah diuji - slider dapat dibuat dengan menggunakan penghubung <input> dan <label untuk = "# id">. Semua keajaiban terjadi pada level selektor # tombol-N: dicentang ~ .slider-inner .slider-slide. Ketika kami mengklik salah satu kotak centang input, itu masuk ke kondisi diperiksa. Kita dapat menggunakan ini dan menetapkan terjemahan yang diinginkan ke wadah kami dengan slide: transform: translate (-33%). Lihat penerapan slider di
sini .
Daftar drop-down . Semuanya berujung pada <input name = "accordion" type = "radio"> dan pemilih yang serupa: .accordion-item input: checked ~ .accordion-item__content. Lihat implementasinya di
sini .
Kehadiran status: hover ,: aktif, dan: focu * . Poin yang sangat penting. Kenyamanan tergantung padanya selama interaksi dengan antarmuka. Pengguna harus selalu menerima umpan balik atas tindakan mereka. Item ini diperiksa selama interaksi dengan kuesioner. Jika saya mengklik tombol "Panggil Saya" dan secara visual tidak ada yang terjadi (meskipun permintaan telah dikirim) - ini buruk, karena saya akan mengkliknya lagi dan lagi. Akibatnya, sepuluh permintaan akan dikirim dan saya akan dipanggil kembali sepuluh kali. Jangan lupa bahwa tidak ada mouse di perangkat seluler - yang berarti tidak boleh ada kursor. Dan satu hal lagi yang tidak menjadi perhatian mereka yang mematuhi poin tentang semantik. Jika kontrol Anda bukan elemen interaktif, maka ketika Anda mengarahkan kursor, kursor akan tetap standar. Itu terlihat sangat berantakan, bahkan jika Anda meresepkan respons untuk melayang. Jangan meremehkan kursor: pointer.
Animasi Adalah penting bahwa segala sesuatu yang terjadi dengan elemen reaksi lancar. Tidak ada yang instan dalam hidup, sehingga kehadiran transisi pada hover dan aktif sudah cukup untuk membuat antarmuka lebih menyenangkan. Nah, mereka yang membuat slider dan daftar umumnya dilakukan dengan baik.
Menggunakan teknologi terbaru . Banyak yang menggunakan flex, tetapi tidak ada yang menyelesaikan tugas menggunakan grid. Item dihitung jika flex digunakan dengan benar. Jika di suatu tempat, karena kelenturan yang sama, tata letak terbelah - sayangnya, Anda tidak menerima poin tambahan.
Validasi formulir . Semua yang diperlukan adalah menambahkan atribut yang diperlukan untuk setiap formulir input. Kami menambahkan poin kepada mereka yang memvalidasi bidang email sebagai email.
Stylization dari tombol unggah file . Kami berharap melihat banyak formulir: <input type = ”file” id = ”file” name = ”file” class = ”inputfile” /> dan <label untuk = ”file”> Pilih file </label>. Lebih lanjut itu diperlukan untuk menyembunyikan input dan label gaya. Ada cara umum lainnya - untuk membuat input transparan dan meletakkannya di atas tombol. Tetapi tidak semua browser mengizinkan styling <input type = ”file”>, dan solusi seperti itu tidak dapat disebut sepenuhnya cross-browser. Dan secara semantik lebih tepat untuk membuat label.
Kompatibilitas lintas browser . Kami memeriksa bahwa semuanya baik-baik saja, di dua versi browser modern terakhir (tanpa IE, para peserta beruntung), serta di Safari di iPhone dan di Chrome di Android.
Kami, sebaliknya, mencetak poin jika seseorang menggunakan JS atau Bootstrap: keduanya membuat seluruh tugas menjadi tidak berarti. Selain itu, peserta dengan Bootstrap tidak hanya menerima minus, tetapi juga kehilangan banyak poin untuk semantik dan elemen yang diimplementasikan.
Mereka yang menandai situs mereka di suatu tempat di Internet tidak mendapatkan keuntungan tertentu - tetapi para inspektur sangat senang ketika mereka tidak harus mengunduh repositori dan menjalankannya secara lokal di komputer mereka. Jadi ini berfungsi sebagai nilai tambah dalam karma.
Tugas pertama sangat bermanfaat terutama bagi siswa. Mereka yang belum kami terima sekarang memiliki ringkasan yang disusun - Anda dapat dengan bangga melampirkannya ke semua respons atau meletakkannya di halaman-halaman gh Anda.
Tugas 2: Rute Transportasi
Penulis tugasnya adalah Denis Balyko, kepala kelompok antarmuka pencarian.
Ketentuan
Anda memiliki peta langit berbintang. Ini menunjukkan nama masing-masing bintang, serta jarak dari itu ke bintang lain dalam detik cahaya. Menerapkan fungsi solusi, yang harus mengambil tiga argumen: objek di mana kunci adalah nama bintang-bintang, dan nilainya adalah jarak ke bintang-bintang (dalam ruang lalu lintas satu arah), serta nama-nama titik awal dan akhir jalur - masing-masing mulai dan selesai. Fungsi harus mengembalikan jarak terpendek dari mulai bintang ke finish bintang dan jalur yang harus dilalui.
Tanda tangan fungsi:
const solution = function(graph, start, finish) {
Input sampel:
const graph = { start: { A: 50, B: 20 }, A: { C: 40, D: 20 }, B: { A: 90, D: 90 }, C: { D: 160, finish: 50 }, D: { finish: 20 }, finish: {} }; const start = 'start'; const finish = 'finish';
Output sampel:
{ distance: 90, path: ['start', 'A', 'D', 'finish'] }
Catatan: kerangka solusi ada di folder src /, masukkan solusi Anda di solution.js.
Verifikasi tugas kedua adalah yang paling otomatis dan objektif. Sebagian besar orang menduga bahwa itu perlu untuk mengimplementasikan algoritma Dijkstra. Mereka yang menemukan deskripsinya dan mengimplementasikan algoritma pada JS sangat bagus. Namun, ketika memeriksa tugas, kami bertemu banyak pekerjaan dengan kesalahan yang sama. Kami mencari potongan-potongan kode di internet dan menemukan sebuah artikel dari mana para peserta menghapus algoritma. Sangat lucu bahwa banyak orang menyalin kode dari artikel bersama dengan komentar penulis. Pekerjaan semacam itu mendapat skor rendah. Kami tidak melarang penggunaan sumber apa pun, tetapi kami ingin orang tersebut menyelidiki apa yang ia tulis.
Kriteria
Poin utama diberikan untuk tes. Kadang-kadang terbukti bahwa orang-orang salah mengira repositori dengan mengganti nama folder, dan tes jatuh hanya karena mereka tidak dapat menemukan file yang mereka butuhkan. Tahun ini kami mencoba membantu orang-orang seperti itu dan mengembalikan semuanya ke tempat mereka untuk mereka. Tapi tahun depan kami berencana untuk beralih ke sistem kontes, dan ini tidak akan dimaafkan.
Ada juga "manusia", kriteria manual. Misalnya - keberadaan gaya kode tunggal. Tidak ada yang mengurangi poin untuk menggunakan tab alih-alih spasi atau sebaliknya. Ini masalah lain jika Anda mengganti tanda kutip tunggal dengan tanda kutip ganda sesuai dengan satu aturan yang diketahui, dan menempatkan tanda koma secara terpisah.
Kejelasan dan keterbacaan solusi diperhitungkan secara terpisah. Di semua konferensi di seluruh dunia mereka mengatakan bahwa pekerjaan programmer terdiri dari 80% membaca kode orang lain. Bahkan anak sekolah melalui ulasan kode - dengan kurator dan satu sama lain. Jadi kriteria ini memiliki bobot yang signifikan. Ada karya di mana tidak ada variabel lebih dari satu karakter - tolong jangan lakukan itu. Komentar para peserta sangat senang - dengan pengecualian yang identik dengan komentar Stella Chang.
Kriteria terakhir adalah ketersediaan autotes. Mereka ditambahkan oleh hanya beberapa orang, tetapi bagi semua orang ini telah menjadi nilai tambah besar dalam karma.
Keputusan yang benar:
const solution = function(graph, START, FINISH) {
Tugas 3: Kalender Acara
Itu disiapkan oleh pengembang antarmuka Sergey Kazakov dan Alexander Podskrebkin.
Ketentuan
Tulis kalender mini untuk menampilkan jadwal. Anda dapat mengambil jadwal apa pun yang Anda suka. Misalnya, jadwal konferensi front-end pada 2019.
Kalender akan terlihat seperti daftar. Tidak ada persyaratan desain lainnya. Memungkinkan pengingat acara diatur selama 3, 7 dan 14 hari. Setelah unduhan pertama dengan Internet, kalender harus terbuka dan berfungsi offline.
Sumber daya yang bermanfaat
Jadwal konferensi front-end:
confs.tech/javascript?topics=javascript%2Bcss%2Bux
Pekerja layanan:
developer.mozilla.org/en/docs/Web/API/Service_Worker_API/Using_Service_Workers
developers.google.com/web/fundamentals/primers/service-workers
API Pemberitahuan:
developer.mozilla.org/en/docs/Web/API/Notifications_API
Tugas ketiga adalah yang paling menarik untuk diuji, karena ada begitu banyak solusi, masing-masing dengan sendiri. Kami memeriksa bagaimana kandidat menangani teknologi yang tidak dikenal - apakah dia tahu cara menyelidiki, apakah dia menguji solusinya.
Kriteria
Kalender yang dibuat . Ya, dia masih perlu berbaikan. Ada orang-orang yang memahami kondisi ini secara harfiah dan tidak memasukkan satu baris kode CSS. Itu tidak terlihat sangat pribadi, tetapi jika semuanya bekerja, poinnya tidak berkurang.
Mengambil daftar acara dari sumber . Ini bukan tugas untuk mengatur huruf, jadi daftar acara yang dijahitkan ke dalamnya tidak dihitung. Anda selalu dapat membatalkan konferensi, menjadwalkan ulang konferensi, menambahkan yang baru. Jadi itu diperlukan untuk menerima data dari luar dan membuat tata letak yang sudah didasarkan pada JSON yang diterima. Itu penting dengan cara apa pun (menggunakan metode ambil atau menggunakan XMLHttpRequest) untuk mendapatkan data. Jika seseorang menambahkan polyfill untuk diambil dan menandai pilihannya di readme, ini dihitung sebagai nilai tambah.
Mendaftarkan pekerja layanan tanpa kesalahan dan bekerja offline setelah boot pertama.
Berikut adalah contoh pekerja layanan dengan caching jadwal saat boot pertama. Detail tentang pekerja layanan, kemampuan dan cara mereka bekerja dengan mereka (strategi untuk bekerja dengan cache, bekerja offline) dapat ditemukan di
sini .
Kemampuan untuk mengatur pengingat sehingga benar-benar berfungsi setelah 3, 7, 14 hari. Itu perlu untuk memahami API Pemberitahuan,
tautan yang langsung dalam tugas. Kami tidak menunggu implementasi spesifik untuk memverifikasi apakah sudah tiba saatnya untuk mendorong. Semua opsi kerja diterima: penyimpanan di Penyimpanan lokal, IndexDB atau jajak pendapat berkala oleh pekerja layanan. Anda bahkan bisa membuat server push (ini
contohnya ), tetapi itu tidak akan berfungsi secara offline. Sama pentingnya untuk mendapatkan dorongan setelah halaman ditutup - dan dibuka setelah beberapa waktu. Jika pengingat "mati" pada saat yang sama dengan halaman ditutup, keputusan tidak dihitung. Itu keren ketika orang-orang memikirkan inspektur dan membuat kesempatan untuk mendapatkan dorongan sekarang - agar tidak menunggu 3 hari.
Kemampuan untuk membuat ikon di desktop (PWA). Kami memeriksa file
manifest.json dengan ikon yang benar. Beberapa orang membuat file ini (atau meninggalkan yang dihasilkan di CreateReactApp) - tetapi tidak menambahkan ikon yang benar. Kemudian, ketika mencoba untuk menginstal, kesalahan seperti "perlu ikon lain" terjadi.
Gaya kode dan struktur proyek . Seperti dalam tugas kedua, kami melihat gaya kode tunggal (bahkan jika itu tidak cocok dengan kami). Beberapa orang mengacaukan linter - itu bagus.
Kesalahan di konsol . Jika ada indikator langsung di konsol bahwa ada sesuatu yang salah, dan peserta tidak memperhatikannya, maka kami mengambil poin.
Ringkasan
Lucu dalam keputusan para peserta:
- Satu kuesioner berisi teks berikut: “Seorang programmer teman membantu untuk merakit aplikasi reaksi. Saya mengajukan pertanyaan kepadanya tentang apa, bagaimana dan mengapa, katanya. Saya sangat menyukainya, saya ingin tahu lebih banyak tentangnya. ” Kami dengan sepenuh hati mendukung kuesioner ini, tetapi sayangnya, teman kandidat tidak benar-benar membantunya membuat aplikasi yang berfungsi.
- Satu kandidat mengirim tautan ke GitHub, tempat arsip RAR berada - sulit mengomentari hal ini. :)
- Kandidat lain dalam komentar di baris pertama file solution.js dengan jujur mengakui bahwa ia menyalin algoritme.
Kami menerima kuesioner dari 76 kandidat dan memilih 23 di antaranya. Kuisioner dikirimkan kepada kami tidak hanya dari Minsk, tetapi juga dari Moskow, St. Petersburg, dan bahkan Tatarstan. Beberapa orang terkejut dengan profesi mereka saat ini: salah satunya adalah seorang pemeriksa medis, dan yang lainnya adalah seorang mahasiswa di sebuah universitas kedokteran.
Ternyata distribusi keberhasilan yang menarik dalam menyelesaikan tugas. Para peserta menyelesaikan tugas pertama rata-rata 60%, yang kedua - 50%, dan yang ketiga ternyata yang paling sulit dan diselesaikan rata-rata sebesar 40%.
Sekilas, tugasnya terlihat rumit dan memakan waktu. Alasannya bukan karena kami ingin menyingkirkan kandidat sebanyak mungkin. Selama pelatihan, siswa dihadapkan dengan tugas nyata - untuk mengobrol, Yandex.Music untuk anak-anak atau Yandex. Kulit untuk orang-orang yang bergantung pada cuaca. Untuk melakukan ini, Anda memerlukan basis awal.
Saya ingat bagaimana saya melihat perkenalan saya dengan SRI dua tahun lalu dan berpikir bahwa saya tidak akan pernah bisa menyelesaikannya. Hal utama saat ini adalah duduk, baca dengan cermat kondisinya dan mulailah melakukannya. Ternyata kondisinya mengandung hampir 80% dari solusi. Misalnya, dalam kondisi tugas ketiga (yang paling sulit), kami menambahkan tautan ke pekerja layanan dan Pemberitahuan API di MDN. Siswa yang mempelajari isi tautan diatasi tanpa kesulitan.
Saya benar-benar ingin artikel ini dibaca oleh kandidat yang berencana untuk memasuki SRI di masa depan, tidak dapat memasuki Sekolah Minsk, atau mulai melakukan tugas tes lainnya. Seperti yang Anda lihat, sangat mungkin untuk bertindak. Anda hanya perlu percaya pada diri sendiri dan mendengarkan semua tips dari penulis.