Semantic HTML

Web dasturlarning strukturasini yasayotganda muhim qadamlardan biri to’gri elementlarni tanlash hisoblanadi.
Bazi saytlarga kirib devtoolsni ochib qaralsa asosan div va span elementlardan tashkil topgan bo’ladi. Balki muallifi HTML semantikasini yaxshi bilmas, balki unga bunday talab ham qoyilmagandir(o’zi bunaqa talab qoyilishiga ehtiyoj bormikin?), lekin bu tashlab o’tib ketiladigan mavzu emas, menimcha.

Semantic HTML deb “content parcha”si bilan birga faqat funksionalning ozi emas balki unga tegishli mano/mohiyat (bu yerda osha “content parcha”sining mazkur documentga nisbatan munosabati nazar tutilgan) ham birga kelishiga aytiladi. Aytaylik documentga “Hello World” degan matn bor, agar uni h1 elementga o’rasak u content bu document uchun birlamchi heading vazifasini bajaradi (Headinglarga tegishli qoidalar bor). Agar bu contentni div elementga o’rasak, bu shunchaki manosiz content bo’ladi.

Shu o’rinda aytib o’tishimiz kerak, tag elementlar hech qachon browser ularga bergan default “style”lar bilan tanlanmaydi, chunki “style”lar istalgan vaqtda istalgan shaklda “override” qilinishi mumkin.

Semantic elementlar ishlatishning quyidagi afzalliklari bor:
- Functionality. Togri element bilan togri funksional keladi. Masalan div yoki spandan to’laqonli button yoki a yasashning imkoni yoq.
- Accessibility. Bazi elementlarda imkoniyatlari cheklangan foydalanuvchilar uchun qulayliklar bor. O’rniga div va span ishlatish ularning sayt bilan muloqotini qiyinlashtiradi.
- SEO. Search enginelar togri semantika bilan tuzilgan saytlarni yuqoriroq baholaydi(divlar o’rniga main, section, aside, nav, header, footer…)
- Easy testing. Semantic elementlarni ishlatish elementlarni testlarda togri topib olishni osonlashtiradi va test id (darvoqe, test idlarni ishlatish antipatternligini bilarmidingiz?) larga ehtiyojlarni keskin kamaytiradi.

Savol: ohirgi marta ul (unordered list) o'rniga qachon ol (ordered list) elementini ishlatgansiz va ularning qanday farqi bor?

@dev_thinking_loud

Utilise it as much as it does not hurt you!

Bugun bitta postga ko’zim tushib qoldi. TypeScriptni qanchalik chuqur va murakkab ishlatish haqida. Muallif hammaga ma’lum Evan You. Yuqoridagi maslahatni bergan.

Men odatda bu maslahatni testing uchun berardim. Chunki “qancha test yozish kerak?” (qanchasi sizni qoniqtirsa), “code coverage threshold qancha bo’lishi kerak?” (o’zi kim o’ylab topgan bunaqa talab bo’lishi kerakligini?) yoki “qaysi tur testlarni ko’proq yozish foydali?” (uzun mavzu, umumiy qilib aytganda hammasini yozib koring, qaysi kamroq resurs olsa oshani ko’proq) kabi ko’p tabiiy savollar uchrab turadi. Men odatda bitta implementation uchun eng kamida bitta case (happy path) ko’rilishi kerak deb aytardim.
Masalan React component implement qilinsa oshani hech bolmasa render test yozish kerak. Bu narsani odat qilgandan keyin bir muddat o’tib sal murakkabroq holatni test qilish ishtiyoqi paydo bo’ladi. Nega deysiz mi? Chunki bu muddat ichida basic component render testlar qanaqadir natija berishga ulgurgan bo’ladi, bazi regressionlarni oldini olganiga dasturchi guvoh bo’lgan bo’ladi. Keyin qiziqish paydo bo’ladi, sal murakkabroqroq va hosroq holatlarni ham test qila olaman mi degan savol paydo bo’ladi. Orqasidan izlanish, o’rganish, eksperiment, tatbiq qilish, odatga aylantirish, tdd va hk… Undan keyin esa test yozmasdan commit qila olmaslik “kasalligi” paydo bo’ladi, peerlar review request qilishganda ozgargan filelar ichidan birinchi test filelarni qidirish odati chiqadi.

Hammasi esa eng birinchi qadamdan boshlangan edi: utilise it as much as it does not hurt you…

@dev_thinking_loud

Frontend dasturlash ish o'rni uchun mock intervyu

Mock intervyu va umumiy frontendga oid savollar muhokamasi suhbati

JavaScript boyicha interview savol va javoblar ro'yhati. Foydali bo'ladi degan umiddamiz

https://github.com/sudheerj/javascript-interview-questions

React boyicha interview savol va javoblar ro'yhati:

https://github.com/sudheerj/reactjs-interview-questions

ES6(ES2015) va undan keyin qoshilgan ES "proposal"larni yillik "specification"lar tasnifida qayta ko'rib chiqamiz (balki esimizdan ko'tarilganlari bordir)

https://github.com/sudheerj/ECMAScript-features

Haqiqatdan, shu mavzular ko'pincha jiddiyga olinmaydi

Mana nima sababdan JavaScriptda hamma o'zgaruvchilar heapda saqlanadi: chunki stackdagi joy function tugashi bilan tozalanadi (function ozi stackdan "pop" bo'ladi), closuredagi functionga esa u joy keyin ham kerak.

Manba:
https://exploringjs.com/deep-js/ch_environments.html#recursion-via-environments

MongoDB aggregationlar haqida yaxshi manba ekan:

https://www.practical-mongodb-aggregations.com

Ingliz tilini bilmasangiz siz yaxshi dasturchi emassiz.

@jakhonrakhmonov

Bazan object propertylarining kalit yoki qiymatlari ustida amal bajarishimizga to'gri keladi.

Object.entries/Object.fromEntries APIlari bunaqa holatda qo'l keladi

Sizningcha qanday natija olamiz va nega?