Programming ∀

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.

Dasturlashga doir contentlar ham ikkiga bo'linadi. 1. Biror mavzu haqida ulashilgan birilm tajriba, fikrlar va ma'lumotlar. 2. Adavanced, practical, paragmatic copy paste qilingan ammo notog'ri ma'lumotlar ham bo'lishi mumkin bo'lgan narsalar.

Conferencelardan maqsad ikkita. 1. Bir mavzuda bilim tajribalarini almashish, yangiliklarni ulashish. 2. 40 daqiqa aljirash va networking qilish.

1. Programmers who write software. 2. Programmers who write CV.

Dasturchilar ikkiga bo'linadi. 1. Programmers who write software. 2. Senior sofware engineer | Solution architect | Lead | 2x certified | Mentor | Author of books | Tech writer |

FPchilar ikkiga bo’linadi. 1. Functional programmingdan foydalanadiganlar. 2. React componentlarni funksiyalar bilan yozadiganlar.

enum Bool  
{  
    True,  
    False,  
    FileNotFound  
};

90 yillardan sovg'a.

Management bilan shug’ullanish inson miyyasining kichrayishiga sabab bo’lar emish.