Programming ∀

Dasutrchilar ikki turga bo'linadi. 1. Dasturchilar 2. Siz

Agar o'zbek bo'lsa pdocast qiladi. Mavzu: Muvoffaqiyatli dasturchi bo'lish sirlari

Tavakkalning boshqacha tarifi dinamik tipli tillarda ishlash degan bo'lar edim.

Turklarda bir maqol bor: Ikki turk birlashsa davlat quradi. Agar ikki turk haskellist bo'lsa compiler quradi. Agar ikki turk jschi bo'lsa 2ta package.

Ikki jschi ko'risha mavzu jsdan boshqa narsalar haqida bo'ladi. Ikki haskellist ko'rishsa ham shunday jsdan boshqa mavzularda gaplashilinadi.

Bunaqalar ketidan qo’l ostidagilar qiynaladi. Sohada shaxsiy fikri hali rivojlanmagan tajribasi kamlar aynan shunaqa uslub tog’ri ekan degan fikrga keladi. Na o’zi rivojlanadi na qolganlar rivojlanishiga muhit bo’ladi. Shu sabab juniorlar bilan ishlash ham oson emas, agar doyim siz aytgandak bo’lishini istasangiz sizni fikr doyimam tog’ri bo’lmasligi mumkin. Agar doyim uni aytganini qilsangiz junior tajribasizlik qilgan bo’lishi mumkin. Shu sababdan juniorlar bilan ishlashda ular bilan extiyot bo’lish kerak, lekin doyim masuliyatli narsalarga tiqaverish kerak, lekin erkinlik ham berish kerak ohirida esa tanqid qilish kerak. Falon task beramiz o’zi yechadi. Ohirida qabul qilib olamiz review qilib. Shunda skill issuelari ham boshqasi ham ko’rinadi. Agar doyimiy ustida ishlamasa chopamiz agar muammolarini hal etsa ko’taramiz.

Yana qiziq kuzatuvlardan biri ham shunaqa super mega seniorlar paragmatismni abstraksiyaga teskari deb o’ylashadi. Bilmadim ularni miyyasi qanday ishlaydi, lekin paragmatism abstraksiyaga teskari emas balki uni soddalashtirishga urunish, ammo abstraksiya qoidalarini buzmagan holatda. Shu sababdan hamma narsa ham paragmatic bo’lolmaydi chunki complexityga nisbatan abstraksiya qilinadi, complexity bilan ishlolmagan abstraksiya esa juda paragmatic bo’lsayam majrux bo’lib qolaveradi.

Senior laqabli juniorlar deganimni sababi, ular muammoga bo'lgan yechimlarni faqat o'zlari bilgancha qilmoqchi bo'lishadi ammo hammasi nazoratdan chiqganida esa boshlarini qashlab yurishadi. Ularning muammosi ma'lum levelga kelganidan kegin qotib qolishgan va texnik bilimlari ustida ishlamay qoyishgan. Tutoriallarda ko'rsatgandek qilib taskni yopib berishadi va uyog'ini o'ylashmaydi. Hullas bir marotabalik code yozishadi doyim. Ikkinchi eng katta muammolari esa doyim subordinatsiya kabi narsalar bilan o'z g'oyalarini tiqishtirmoqchi bo'lishadi. Qog'ozga o'rab man seniorman mani etganim bo'ladi ! deyishadi. Eng yomoni esa ular bilan consensusga kelish deyarli ilojisiz, chunki ularning contextlari umuman boshqa bo'ladi.

Senior laqabli juniorlarga salomlar! Bazi holatlarda tajribasi katta bo'lsa ham bilimlari o'smay qolgan hamkasblarni kuzataman. Ularning ikki turi mavjud. 1. O'ziga haddan oshiq ishonib yuborib kibrlanib ketgan. O'zini juda aqlilli tutadi lekin skill issuelari ochib qo'yadi ko'p narsalarni. 2. O'z xatolarini tushunadigan va tog'irlashga harakat qiladigan. Ammo o'z ustida ishlashga muhit bo'lmasligi va boshqa faktorlar sababdan yangi narsa o'rganmaydi. Bugun aynan birinchi guruhga kiradiganlar haqida gaplashamiz. Odatda bunday odamlar qachondir nimadirlarni o'rgangan, ammo bilimlari ma'lum joyga kelib qotib qolgan. Lekin amaldagi lavozimi kattaroq bilimlarni talab qiladi. Ular odatda abstraksiyani yomon ko'radilar asosiy vaqtlarini esa oldin o'xshamagan yechimlardagi xatolarni yana o'xshamagan boshqa xato yechimlar bilan yopishga xarakat qiladilar. Biror yechimning sifati odatda kritikal darajadagi holatlar va force majorlarda, anomaliyalarda o'lchalinadi, shu sababdan ham turli uslubdagi testlar, benchmarklar qilinadi. Hamma narsa limited, shu sababdan ham yechim sifati List of system quality attributes ichidan talabga nisbatan moslarini tanlab olish bilan o'lchalinadi. Bu perfectionism emas, unga xarakat emas balki complexityga mos keladigan qualityni ishlab chiqish. Aniqroq misolda aytadigan bo'lsak, bizda oddiy message getway mavjud. Ho'sh buni qanday uslubda qursak bo'ladi ? Aynan bunaqa turdagi getwaylar uchun odatda EDD approachlar taklif qilishadi. Lekin nega ? Sababi xabarlar birnecha uslubda yuborilishi mumkin. Xabarlarda retry degan imkoniyat bo'lishi mumkin. Undan tashqari bir vaqtning o'zida ko'plab xabarlar yuborilishi mumkin. Detallarga kirishadigan bo'lsak yechim uchun juda ko'p narsalr kerak bo'ladi, concurrency, brokers. Demak yechimdan oldin tanlanishi kerak bo'lgan sifat parametrlari yechimga o'z o'zidan tasir qiladi. Keling endi ikki yechimni ko'ramiz. 1. Messagelar http ustiga qurilgan biror interfacedan olinadi masalan JSON-rpc, Grpc. Bular esa ma'lum queuega tiqiladi, sababi bir vaqtning o'zida hamma messagelarni process qilishga limitlar halal berishi mumkin, shu sababdan queuelar yaxshi practice. Ammo endi queuedagi tasklarni process qilish kerak. Yana variantlar masalan: - Schedulerlar - Webhooklar Scaling masalasiga kelganimizda esa ikkisida ham race conditionlar uchun locking qilishimiz kerak, bu degani queuega ham locking tiqish kerak degani. Keyingi masala esa, bizni msg-getway down bo'ldi va requestlarni qabul qilolmaydi, ho'sh nima bo'ladi ? Bizni servisga ulangan servislarda ham muammo bo'ladi, ular o'z o'zidan bizni servisga sinxron bog'liq, bu esa zanjir reaksiyasiga sabab bo'lish extimoli ham bor. Masalan msg ketmagani tufayli qanaqadir process o'rtada qolib ketdi. Bunga esa zanjirdagi servislar rollbacking qilishni qoshishlari kerak. Bu o'z o'zidan servislar o'rtasidagi bog'liqliklarni oshiradi. 2. Msg-getway uchun kafka ishlatamiz, kontraktlarni esa avro yani kafka schema registryga tiqamiz. Yoki boshqa brokerlarni ishlatsak bo'ladi, ho'sh brokerlar o'zida bemalol concurrent tasklarni configini qilsak bo'ladi bu bilan scaling oson bo'ldi. Messagelarni ham broker o'zidagi queue hal etib qo'ydi, muhimi persistance bo'lsa yetarli. Shu bilan biznii servisga bog'likliklar kamayadi. Bizga bog'likliklarni bartaraf etganimizdan kegin esa ichkaridagi o'zimizni ishlarni qilishimiz kerak, masalan scaling, avability, durability vaxakazolar. Faqat EDD o'zini tog'ri tadbiq qilish kerak, lekin fundamentni yaxshi boshladik, qolgani research masalasi.

Reactchilar State monadlarni o’rganishsa yaxshi bo’lardi. 732991836ta state manager bo’lib ketibti va hammasi birxil ishlaydi va hammasi birxil trash. Aynan reactchilar deganim sababi https://t.me/programming_everyone/3589

CPU o'zining intensiv ekanini eshitsa.

Continuations, Feautures va tresh promislar kabi. Hammasi nomlanishi farqli ammo conceptual birxil narsalar ko'p. Shunga doyim aytaman conceptlar muhimroq deb. Har qanaqa loopni ko'rib bu CPU intensiv deganingizdan kegin sizni AI replace qilishi ham tabiy holatku hurmatli hamkasb.

Aytgancha threadlarga o'xshagan yengilroq objectlar tiqilib yotibti, sparks, fibers, gorutines, corutines, virtual threads. Albatta concurrencyda ham Haskell super pozitsiyada !

Yuqoridagi stream misolida ham biz streamdan kelgan chunklarni concurrencyga tiqib yuborishimiz mumkin. Ammo chunklarni process qilishda bir biriga bog'liq bo'lmagan holatlar bo'lsa uni parallel qilsak bo'ladi. Lekin bu yerda eng gemaroy narsa streamning parallelism bilan ishlay olishi. Chunki stream vaqt o'tishi bilan foydalanish mumkin bo'lgan cheksiz ma'lumotlar elementlari ketma-ketligi. Bu yerda sequence juda muhim, parallelism uchun esa buni ham tog'irlashimiz kerak bo'ladi.

CPU intensivlik masalasiga kelsak. Eng basic misollardan biri Matrix Multiplication Ho'sh bu qaysi modelga mos keladi ? Concurrency or prallelism. To'gri, kallangiz ishlaydi bu parallelismga mos keladi. Chunki row va column producti natijasi bir biriga bog'liq emas. Nimani concurrent qila olamiz ? Masalan oddiy webserver, har bir requestni alohida contextda qabul qilamiz va exeution uchun callback beramiz, callbackdan kegin esa natijani qaytaramiz. Shu orqali biz bir vaqtni o'zida ko'plab requestlar bilan shug'ullanamiz.

Thread yoki Process - Bu shunchaki abstract object. Muammoning yechimi uchun oldin conceptual narsa kerak. Concept esa Concurrency or Parallelism. Concurrency vs Parallelismni farlay olmaganlar threadlar haqida maqola yozishi va intensivlik deganda loopni nazarda tutishi juda absurt. Masalan manda stream bor deylik va unga pipeline qilyabman, albatta iteratorga o'rab loop qilishim mumkin. Shunda bu CPU intensivmi ? Concurrency - bir vaqtning o'zida ko'p narsalar bilan shug'ullanish Parallelism - bir vaqtning o'zida ko'p narsalarni qilish Rob Pike qilgan talkda tushuntirgan. Abstract objectlarni ovolib o'zini aldab yurmanglar !

Stand up meetings be like. https://www.youtube.com/watch?v=IBZtTW0pXLE

Haskell is a general-purpose programming language.

Community qilishdan ikki maqsad bo’lari. 1. Community doirasida rivojlanish. 2. Infosiganlik.

Ko'pchilik beginnerlar uchun deb content tayyoraydi ? Hechkimga tosh otilmadi.