Programming ∀

Dasturlashda funksiya kattalashsa 2ga ajratish kerak. Matematikada esa ikki funksiyani qo’shish kerak ekan 🥹 Albatta xazil. Matematika nima uchun dasturlashni asosi ekaniga tushunib yetdim ))) Shu kungacha matematikani kaslargacha bilgan edim. Shunchaki algebradan boshlang’ich lecture qo’limga tushib qoldi. Mavzuda ikki funksiyani qo’shish bor ekan 😀 Algebrik syntax manga yoqdi )) Biz ko’p gapiradigan abstractioni asosi shu yerda ekan )) 2-3 ta masla ham ishlab kordim faqat yozishni unutib qo’yibman (( Umuman olganda birinchi marotaba algebrik funksiyalar haqida o’qidim va misollarni ishladim (kop boshog’riqlar bilan). Man o’ylaganimdan ancha oson va tushunarli ekan )) Matematikani universitetga kirish uchun emas zerikanda challenge uchun o’qisa ham bo’lar ekan. Xamkasblardan ko’pchilikda math background zor edi hademay yetib olaman 1-2 yilda 😎

Bu yerga ham yuborib qo'yvoman. Umuman olganda ajoyib suxbat bo'ldi. Qatnashgan barcha insonlarga kotta Rahmat.

Partial list of “-ilities” ))

Bugun Nodejs guruhda audiochat qilamiz Hudoholasa. Mavzular birmuncha umumiyroq. Kimgadur qiziq bo'lsa bemalol qo'shilishingiz mumkin. https://t.me/nodejs_uz

Arxitektura va unga talablar. Har qanday tizimni loyihalashda yoki uni ishlab chiqishda eng muhimi talablar. Aytaylik siz kontaktlar ro'yxati (contact list) bilan ishlaydigan dastur qurmoqchisiz. Siz ushbu dastur arxitekturasini qurishdan oldin birqancha turdagi talablarni qo'yasiz masalan: 1. Funksional talablar - Dasturdagi mavjud imkoniyatlar. Umiyroq aytganda siz qurayotgan dastur yoki tizim nima qiladi ? Qanday imkoniyatlari mavjud ? Shu kabi to'g'ridan to'g'ri imkoniyatlarga yo'naltirilgan savollar qo'yiladi va ushbu savollar asosida talablar hosil bo'ladi. 2. Sifatga qo'yiladigan talablar. Ushbu masala birmuncha keng qamrovli ushbu talablar umumiy funksionalning qanday ko'rsatkichlarga ega bo'lishi yoki biror qismning bir qancha kvalifikatsiyalangan sifat darajalariga nisbatan qo'yilgan talablar xisoblanadi. Masalan kontaktlarni qidirishda eng maksimum vaqt oralig'i 200ms bo'lishi kerak. Agar ushbu vaqtdan oshadigan bo'lsa qo'yilgan talab qondirilmaydi. Yoki bo'lmasam barcha domain layerlar immutable bo'lishi kerak. Yoki umumiy loyihaga aloqador bo'lishi mumkin masalan yangi versiyani chiqarish (relase) vaqt oralig'i N dan oshmasligi kerak. Yoki bo'lmasam relase uchun kamida 85% test coverage bo'lishi shart. 3. Cheklovlar. Bu masala talablarga javob berilishi kerak bo'gan barcha ko'rsatkichlarning vaqtga nisbatan o'lchashning eng muhim qismi. Qisqaroq aytganda cheklovlar qanchalik qa'tiy va aniq qilingan bo'lsa loyihaga qancha va qanday resurslar safrlanishi ham shuncha aniqlashadi. Ammo cheklovlar masalasi birmuncha kengroq tushuncha. Chunki ushbu cheklovlar faqat arxitektorning subyektiv fikri bo'lib qoladigan bo'lsa boshqa jiddiy va qimmatli yoqotishlarga sabab bo'ladi. Misol uchun arxitektor falon loyihani falon texnalogiya yoki dasturlash tillari yordamida qurishni belgilagan va qolganlarini cheklagan bo'lsayu ammo jamoadagi injinerlar ushbu texnalogiyadan tajribalari mavjud bo'lmasa. Ushbu holat jiddiy nomutonosibliklar va noxushliklarga sabab bo'lishi mumkin. Shu sababdan loyiha arxitekturasini qurish paytida boshqa tashqi omillar va umumiy texnik potensialni ham xisobga olish kerak (Falon dastur qilmoqchiman shunga Mongodb ishlaganim yaxshimi yoki PostgreSQL ? Kabi savollar turli xamjamiyatlarda berilganda ko'pchilik o'zingiz yaxshi bilganingizdan foydalanganingiz yaxshi kabi javob berishadi bunday holat ham yuqoridagi tarifga va potensial masalasiga taqaladi). Undan tashqari biror muammoga yechimni va shu turdagi boshqa muammolarga ham yechim sifatida aynan bitta yagona patternni arxitektor belgilab berishi mumkin. Software designda barcha N turdagi amaliyotlar falon pattern yordamida define qilinadi. Bunday cheklov yordamida barcha bir kategoriyaga mansub muammolarga qolipli yechimni taqdim qilinadi va barcha shu qoliplardan foydalanishga majbur bo'ladi. Yanayam real misolda keltiradigan bo'lsak. Bizda aynan Databaselar bilan ishlash masalasi mavjud. Biz data acess layerni repository pattern yordamida amalga oshiramiz. Barcha Databasega aloqador qilinadigan ishlar hammasi repository pattern yordamida amalga oshiriladi )). Biz repository patternni data access masalasi uchun qolip sifatida taqdim qildik va bu birmuncha abstrat yani aniq shakl shamoyili deyarli mavjud emas balki umumiy xususiyatlari mavjud. Bu degani biz ushbu abstract qolip yordamida aniq biror narsaga yo'naltirilgan yechimni tadbiq qilishiiz kerak. Chegaralarni esa repository pattern xususiyatlari va talablari belgilab beradi ))). #software_architecture #architecture #software_design #requirements

Arxitektura va unga talablar. Har qanday tizimni loyihalashda yoki uni ishlab chiqishda eng muhimi talablar. Aytaylik siz kontaktlar ro'yxati (contact list) bilan ishlaydigan dastur qurmoqchisiz. Siz ushbu dastur arxitekturasini qurishdan oldin birqancha turdagi talablarni qo'yasiz masalan: 1. Funksional talablar - Dasturdagi mavjud imkoniyatlar. Umiyroq aytganda siz qurayotgan dastur yoki tizim nima qiladi ? Qanday imkoniyatlari mavjud ? Shu kabi to'g'ridan to'g'ri imkoniyatlarga yo'naltirilgan savollar qo'yiladi va ushbu savollar asosida talablar hosil bo'ladi. 2. Sifatga qo'yiladigan talablar. Ushbu masala birmuncha keng qamrovli ushbu talablar umumiy funksionalning qanday ko'rsatkichlarga ega bo'lishi yoki biror qismning bir qancha kvalifikatsiyalangan sifat darajalariga nisbatan qo'yilgan talablar xisoblanadi. Masalan kontaktlarni qidirishda eng maksimum vaqt oralig'i 200ms bo'lishi kerak. Agar ushbu vaqtdan oshadigan bo'lsa qo'yilgan talab qondirilmaydi. Yoki bo'lmasam barcha domain layerlar immutable bo'lishi kerak. Yoki umumiy loyihaga aloqador bo'lishi mumkin masalan yangi versiyani chiqarish (relase) vaqt oralig'i N dan oshmasligi kerak. Yoki bo'lmasam relase uchun kamida 85% test coverage bo'lishi shart. 3. Cheklovlar. Bu masala talablarga javob berilishi kerak bo'gan barcha ko'rsatkichlarning vaqtga nisbatan o'lchashning eng muhim qismi. Qisqaroq aytganda cheklovlar qanchalik qa'tiy va aniq qilingan bo'lsa loyihaga qancha va qanday resurslar safrlanishi ham shuncha aniqlashadi. Ammo cheklovlar masalasi birmuncha kengroq tushuncha. Chunki ushbu cheklovlar faqat arxitektorning subyektiv fikri bo'lib qoladigan bo'lsa boshqa jiddiy va qimmatli yoqotishlarga sabab bo'ladi. Misol uchun arxitektor falon loyihani falon texnalogiya yoki dasturlash tillari yordamida qurishni belgilagan va qolganlarini cheklagan bo'lsayu ammo jamoadagi injinerlar ushbu texnalogiyadan tajribalari mavjud bo'lmasa. Ushbu holat jiddiy nomutonosibliklar va noxushliklarga sabab bo'lishi mumkin. Shu sababdan loyiha arxitekturasini qurish paytida boshqa tashqi omillar va umumiy texnik potensialni ham xisobga olish kerak (Falon dastur qilmoqchiman shunga Mongodb ishlaganim yaxshimi yoki PostgreSQL ? Kabi savollar turli xamjamiyatlarda berilganda ko'pchilik o'zingiz yaxshi bilganingizdan foydalanganingiz yaxshi kabi javob berishadi bunday holat ham yuqoridagi tarifga va potensial masalasiga taqaladi). Undan tashqari biror muammoga yechimni va shu turdagi boshqa muammolarga ham yechim sifatida aynan bitta yagona patternni arxitektor belgilab berishi mumkin. Software designda barcha N turdagi amaliyotlar falon pattern yordamida define qilinadi. Bunday cheklov yordamida barcha bir kategoriyaga mansub muammolarga qolipli yechimni taqdim qilinadi va barcha shu qoliplardan foydalanishga majbur bo'ladi. Yanayam real misolda keltiradigan bo'lsak. Bizda aynan Databaselar bilan ishlash masalasi mavjud. Biz data acess layerni repository pattern yordamida amalga oshiramiz. Barcha Databasega aloqador qilinadigan ishlar hammasi repository pattern yordamida amalga oshiriladi )). Biz repository patternni data access masalasi uchun qolip sifatida taqdim qildik va bu birmuncha abstrat yani aniq shakl shamoyili deyarli mavjud emas balki umumiy xususiyatlari mavjud. Bu degani biz ushbu abstract qolip yordamida aniq biror narsaga yo'naltirilgan yechimni tadbiq qilishiiz kerak. Chegaralarni esa repository pattern xususiyatlari va talablari belgilab beradi ))).

419 status codeni You sent Trash Qo'yish kerak. Eng qizigi 419-status hali bo'sh )))

Alex Xu birat ham Diagrams as Code haqida yozibtilar. Diagram chizishga erinib huddi shu mavzuga kirib qolgan edim o’tgan yili 😅 PS: Architectlar codingdan chiqib yana codingga qaytishyabti ))) https://blog.bytebytego.com/p/diagram-as-code

Songi qatnashgan va qatnashayotgan 4ta loyilarimda deyarli etibor qaratilmagan ikki narsa bor. Ushbu ikki aspectlar eng kam etibor qaratilganlar ichida yuqori o’rinlarda. 1. Loglar va xatoliklarni boshqarish (Logging, Error handling and Error tracking) 2. Ko’rsatkichlar tahlili (metrics) Birinchi masalaga etibor qilinmagani sababdan juda ham ko’p xatoliklarni bartaraf etish qiyin bo’lyabti. Umumiy tizimdagi muammolarni qayta ishlash va aniqlash ancha ko’p resurs talab qilyabti. Ikkinchi masalaga etiborsizlik. Umumiy tizim yoki uning biror componenti qanday holatda ishlayotganini mavhumlashtiryabti. Oqibatda keyingi qadamlarni taxlil qilish va software evolution sekin va kutilmagan xolatli voqealiklarga boy bo’lib kelyabti. Loyiha holati va uning ko’rsatkichlarining mavhum ekanligi to’g’ridan to’g’ri stabil bo’lmagan juda ko’p qismlarni birlashtirmoqda oqibatda keyingi qadamlar ham mavhum va intuitiv bo’lmoqda. Yani bu hafta yoki sprintda yoki N vaqt oralig’ida biz nima qilsak loyiha stabillashadi ? Degan savollarning katta qismi ochiq qolmoqda. Ushbu masalalar esa biznes va management uchun qiziq bo’lmasligi mumkin lekin kasallik jiddiy simptomlarni oshkor qilganida kasal inson axvoli og’irlashgani kabi loyihada ham vaziyat o’g’irlashishiga ko’z yumish ham og’ir ekan ))) PS: Yuqoridagi gaplar mani umumiy tahliliy hulosalarim. Shu sababdan bu aynan shu loyiha yoki kompaniyada ekan degan hulosa qilmasligingizni so’rab qolar edim.

O’zbek tili aynan manga nima uchun muhim ekani haqida aniq javob topdim vanihoyat )). Asosiy masala qandaydur orlanishga o’xshagan his tuygu’ular sabab ekan. Sohamizga aloqador mavzulardagi terminlarni kulgili yoki noqulay bo’lsa ham tarjima qilish va ishlatish kerak ekan )) PS: Xatolar bo’lsa to’girlab qo’yasizlar. Ushbu masalada tanqidlar o’rinli va jiddiy qarash kerak. Endi biror termin yoziladigan bo’lsa avval O’zbekcha keyin qavs ichida inglizchasini qo’yaman. PSS: Trashni tresh deyman lekin 🥲 O’zbekchasi juda ham qo’pol ayniqsa contextda to’ridan to’g’ri ma’no bersa… Balki boshqa alternativ so’z o’ylab toparmiz bunga ham ))

Yaqin oylar oralig'ida bo'lgan 3-4 hodisalar juda qimmatli tajriba olib keldi. Engineer ham business va boshqa mavzularda ham. Bu mavzularni qandaydur ko'rinishda yoritish kerak. So'ngi oylarda man umuman xisobga olmagan holatlarda umuman tassavurimga sig'magan masalalarni deb faillar bo'ldi 😁 Undan tashqari juda chiroyli qadoqlangan trashlarga ham govoh bo'ldim )) Weekenda ushbu holatlarni birortasi ko'rib chiqaman InshaAllah. Yana bir narsani eslatib ketmoqchi edim. Man pozitive fikrlash yoki tolerantlik tarafdori emasman. Shu sababdan ko'p yozgan narsalarim sizlarga yoqmasligi yoki asabingizda tegishi mumkin. Agar shunday bo'lsa sizga ikki yo'lni tavsiya qilaman. 1. Keling ratsional muhokama qilamiz )). Biroz miyyani qizdirib ko'raylik balki yechim topilar. Fikrlarimiz mos kelmasligi mumkin ammo muammo hal bo'lsin )) 2. You left the channel (with trash)...

Onlayn formatdagi hackaton )). Cosmos mavzusida game ishlab chiqish kerak )). Sinab ko'rishni tavsiya qilaman juda bo'lmaganda networking uchun. O'zbeklardan ham shunday hackatonlarda yutadiganlar chiqsin ! Bizdan ham yaxshi gameplay va sujetga ega video o'yinlar chiqsin vaxakazolar kabi osmon opar gaplarga tupurib qo'ygan holatda. Qiziqmi ? Minimal talablarga javob beramanmi ? Ha, Demak sinab ko'rish kerak PROSTO PS: Man shunchaki ko'rib qolgan informatsiyam o'zimga qiziq bo'lgani uchun kanalga ham ulashdim. Aynan game development mavzusi birmuncha qiziq ammo xozir bunga proiritetlarim pastroq. Qolgan informationlar: https://datsteam.dev/datspace/

Хакатон DatsArt Space от DatsTeam! Space X запускает космические корабли, а DatsTeam – новый хакатон! Приглашаем отметить День космонавтики на крутой игре! 🚀🪐🌟 Вы пишете свой «геймпад» к нашей «игровой консоли» и сразу играете в игру. Задача каждой команды создать свой шедевр, максимально приближенный к оригиналу. >>> Регистрация до 20.04.2023 >>> 🏆 кто покажет лучший результат по итогам двух этапов – Apple Macbook pro на каждого участника 🙌🏻 в команде от 1 до 3 участников 💸 бесплатно 👽 от 18 и старше Хакатон пройдет в два этапа: 1 этап: 21 апреля 17:00 - 22 апреля 16:00* 2 этап: 22 апреля 17:00-20:00* - финал в прямом эфире! *время Московское Использовать можно любые технологии - никакая из выбранных не даст дополнительного преимущества перед другими участниками. Вопросы info@datsteam.dev >>> Регистрация до 20.04.2023 >>>

The Table of Nines :)

Kinolar va o'yinlarda etibor qilgan bo'lsangiz sniperlarda barcha otilgan o'qlarni xisob kitoblari va eski otilganlar tarixi bo'ladi. Ushbu ma'lumotllar yordamida merganlar yangi o'q uzishda avvalgi tajribalariga murojat qiladilar va o'sha ma'lumotlar asosida nishonni belgilaydilar. Shu bilan birga ularga ham ushbu notes todo bo'lib ham xizmat qiladi yani xatolardan hulosa uchun. Aynan bizni sohada ham shunga o'xshagan narsaga extiyoj seza boshladim. 1.Qog'ozga bugun qilinadigan ishlarimni yozib boraman. 2. Qog'ozda tassavurimdagi narsani shakillantirish oson shu sababdan kerakli narsalarni chizib yanada aniqlash juda yaxshi. 3. Classic development uslubini to'laqonli qo'llash mumkin )). Oldinlari engineerlar ham biror narsalarni qurishdan oldin chizmasini chizib chiqishgan hamma narsani izohlab keyin haqiqiy ishlab chiqishni boshlashgan. Bunday tajribani software engineeringa tadbiq qilish manga anchagina qiziq )) Man ko'rgan yagona minus buni odat qilish yaxshi lekin ortiqcha buyum olib yurasiz doyimo ))

Manam bir maqtanay 😎 Nodejs stackda oylik boshqalardan balandroq ekan ))) bu albatta djinni co datasi faqat )) Sardor og’aga ham nodejsga otishlarini taklif qilamiz 😁 PS: O’zilar uchun bilpoyurasila 🙂