Programming ∀

Bugun independence day. Mobodoga loyihangizda high coupling bo’lsa shularni to’g’irlashga sabab 😁

Qarshingdagi odam senga ertak aytayotgan mavzusini bilishingini bilmasa va sen gaplari notogri ekanini aytsangu ertakni davom qilsa...

Lekin formal OOP da try/catch mechanism qoralanmaydi. Biror objectda muammo bo'lganda exeption throw qilgani bo'lgani yanayam yaxshi. Ammo bu paradox emas :) Buning yechimi yaxshi error processing mechanism ishlab chiqish. Shunda nullable execptionlar o'rniga xaqiqiy exeptionlar asosida aniq ishlar qilinadi. Bu degani tizimning xatolarsiz ishlash imkoni yoki xatolar chiqganida ularga nisbatan biror amaliyot bajarish imkoniyati oshadi. Lekin har bir layerda yuqoridagi kabi imprative code qilinsa juda boshogriq bo'ladi :)

Throwing problems Exeptionlarni throw qilish va yaxshi error handlingni throwing bilan qilish nisbatan qimmat amaliyot bo'lib qolyabti. 1. Har bir layerda throwing check (try/catch) 2. Yaxshi error processing mechanism qilish murakkablashib ketadi. Errorlar categoriyalanishidan tashqari har birini process qilish kerak. Catch blockda logic yozmaslikni important qilolmaysiz ayniqsa reverting mechanism kerak bo'lsa. 3. Kod hajmi kattalashadi imperotivlashadi. Chunki iflar ko'payishi mumkin :). Declarative conditionlar hohlasangiz 2-punkdagi muammolarga duch kelishingiz mumkin. 4. Error objectlar o'z o'zini process qilish mechanismi ham yaxshi variyant lekin uyoqda yana boshqa muammo paydo bo'ladi. Bunday mechanismni qatiy o'rnatish kerak bo'ladi. Ayniqsa tajribasi kam jamoadoshlar bu mavzularni intuitiv qilolmay qoladi. Har N code reviewlarda error objectlar qolib ketadi. 5. Pattern matching kabi mechanismlar ishlatilinsa ko'p narsa osonroq va yaxshiroq bo'ladi. Ammo juda ko'p code yozishingiz kerak bo'ladi.

Ish joyi kerak: 👨‍💼 Xodim: Muhammadxon Najimov 🕑 Yosh: 28 📚 Texnologiya: Javascript, Webgl, Wasm (Rust) 🇺🇿 Telegram: @Mathammed 🌐 Hudud: Toshkent Shahar 💰 Narxi: $3000 (minimum) 👨🏻‍💻 Kasbi: Computer Graphics Developer (Junior) 🕰 Murojaat qilish vaqti: 11:00 - 02:00 🔎 Maqsad: Pul, juda ko'p pul, commercial experience, networking PS: Saidolim aka rozi bo'ling, UstozShogird botingizni shablonidan foydalandim). Tushunishimcha moderatordan o'tmadi. Shunga shu yerda share qilayapman. PS: post fake emas

Ushbu voqealardan ancha tajriba va hulosalar oldim endi miyya joyiga kelganidan keyin sekin izohlab chiqyabman 😁

Ushbu voqealardan ancha tajriba va hulosalar oldim endi miyya joyiga kelganidan keyin sekin izohlab chiqyabman 😁

Bo'lsa chain bo'lsin :) Bobosherning maqolasi chiqganida refactoring va testinga aloqador mavzularda yaxshigina tajribaviy hulosalar yeg'ilib qolgan edi :) Shularni endi sal miyya bo'shaganida yozishga qaror qildim. Qisqa qilib aytganda bazi masalalar sabab bizda requirementlar o'zgardi va ikki amaliyot yuqori prioritetdagi vazifa qilib berildi. 1. Mavjud servisni boshqa servisga migration qilish. Yani o'rtada turadigan bir servis bor uni boshqa external servisga wrapper sifatida ishlab beradi va event based ishlaydi shu o'rinda external servisga boradigan barcha tasklarni nazorati bilan shug'ullanadi. Shu holatda external servis o'zgargani uchun ushbu mavjud wrapper servisdagi asosiy logicni o'zgartirish kerak. Bu migration amaliyoti 2. Servisdagi business logic tubdan o'zgargani uchun nazorat mexanizmlari o'zgarishi kerak. Refactoring amaliyoti. Man qilgan servisda queue mexanizmi ham ishlaydi barcha tasklarni queuega saqlash kerak va persistance bo'lishi kerak. Shu o'rinda bir vaqtning o'zida qancha taskni process qilish kerak. Asosiy texnik masalalar shu edi. Shu sababdan oldin umumiy powerni bilib olishga turli benchmark analizlardan boshladim. Bizda barcha narsa oldindan umuman mavhum edi. Texnik va business tomonlama barcha narsalar migration va refactoring bo'layotgani sabab raqamlarda ko'rsatilgan natijalar yoq. Ammo eski tizimdan hulosalar olishtirib solistirish mumkin. Shu sabab yangi candidate servisni benchmark qilish kerak bo'ldi. Undan keyin man qilgan wrapperni benchmark qilish kerak edi. 1. Bir vaqting o'zida qancha taskni process qilyabti. 2. Agar task meyordan ko'payib ketsa processing time qanday bo'lyabti ? 3. N vaqtda N ta task berganda natijalar qanday chiqyabti ? 4. Hightload va stresslarda qanday natijalar chiqyabti (Benchmark emas automation test asosan) Hullas yuqoridagi kabi savollar tuzib olindi va shu savolalrga raqamlarda javob topish uchun turli benchmarklar yozishga yoki tayyorlarini ishlatishga to'g'ri keldi. Benchmark hulosalari ijobiy bo'ldi. Ammo wrapper mechanismi va business logic o'zgarishi aniq bo'ldi sababi yangi servisda processing ancha boshqacha holatda. Ammo yuqoridagi hulosalar va docsni yaxshilab o'qib chiqganimdan keyin refactoring(Alohida mavzu) ancha oson bo'ldi. Umuman olganda refactoring tugadi. Servis ancha stabil holatga keldi(Ammo isboti yo'q). Hammasidan oldin yana bir benchmarking qilish kerak bo'ldi. Sababi servisga alqador barcha requirementlarga javob berayotganini tekshirish kerak edi. Ayniqsa bazi critical aspectlardagi natijalarni(perfomance). Uning uchun ham huddi integration testlarga o'xshaganroq ko'rinishda benchmark yozdim. Natijalarni esa eski LTS versiya bilan solishtirish kerak edi. Bu orqali qo'yilgan requirements bo'yicha barcha aspectlarni cover qilgan raqamlarga isbotlangan javoblar olindi :) - Cost - CPU/Memory Resources - Traffic - Yana boshqa aspectlarga qaratilgan natijalar Huddi shunday ozgina hightload va stress testing ham qilib ko'rdim. Ammo to'liq infra bilan qildim bog'liqliklar ko'pligi sabab. - Anchadan buyon kuzatilayotgan critical bugni tog'iladim :) Uni deb service block bo'lib qolayotgan edi. Keyin restart qilishga to'g'ri kelar edi. - Queue persistanceda muammo topdim. - Filemanagerda muammo topdim. Mechanism aniq ishlayotganiga ishonchim komil edi. Ammo turli holatlarda ayniqsa katta loadda qanday ishlashiga shubxam bor edi. Yuqoridagi kabi birqancha amaliyotlardan keyin Availability va Perfomancega aloqador barcha aspectlarda aniq javoblarni oldim. Normal hightloaddan birnecha barobar ko'p loadni simulation qilganim uchun esa ushbu servisdan ancha ko'nglim to'q bo'ldi. Umumiy jarayon esa manga ancha stressfull bo'ldi sababi deadline konstanta qilib berilgandi :)

N-API Rustga ham bor ekan :) https://napi.rs/ Nodejs borgan sari jiddiy rivojlanyabti. Asosiy muammolar JS/TS da bo'lyabtgani yoqmayabti lekin bu paradox buyoqda tilning aybiyoq :) Oldin hamma noligan CPU intensive tasklarda ham xozir anchagina o'sish bo'lgan. Concurrency va asynchronus paralell asyncronus computinglarni support qiladi :) 20.x versiondan permissionlar qo'shilgan. Asosiy muammo texnologik maktabda. Java kabi ekotizimlarda katta tajriba va maktab mavjud. Shu sababdan ular gegemon :) Bizda ham sekin sekin maktab yaxshilanyabti. To'g'ri haliyam trash markazlarda express vs koa deb yurishgandur 😁. Lekin bilimli xamkasblar soni ko'p. Versuschilar ham 4-5 yildan keyin ancha tajriba orittirishadi agar ustilarida ishlashsa. Mani firkimcha JS/TS ni biroz modification qilib chiqish kerak formal languages va paradigms bo'yicha. Ha bu juda katta mashaqqatli yoki bo'lmasa umuman ilojisiz darajadagi ish bo'lishi mumkin. Nodejs code browserda ishlamaydi :) Alohida ekotizimga aylanib bo'lganiga ancha bo'ldi. Nodejsda yaxshi yozilgan code ancha hight perofmanceda ishlaydi umuman olganda ekotizimda ma'lum jiddiy o'zgarishlar qilib yanada powerfull tool ko'rinishiga olib kelishga imkon katta :)

N-API Rustga ham bor ekan :) https://napi.rs/ Nodejs borgan sari jiddiy rivojlanyabti. Asosiy muammolar JS/TS da bo'lyabtgani yoqmayabti lekin bu paradox buyoqda tilning aybiyoq :) Oldin hamma noligan CPU intensive tasklarda ham xozir anchagina o'sish bo'lgan. Concurrency va asynchronus paralell asyncronus computinglarni support qiladi :) 20.x versiondan permissionlar qo'shilgan. Asosiy muammo texnologik maktabda. Java kabi ekotizimlarda katta tajriba va maktab mavjud. Shu sababdan ular gegemon :) Bizda ham sekin sekin maktab yaxshilanyabti. To'g'ri haliyam trash markazlarda express vs koa deb yurishgandur 😁. Lekin bilimli xamkasblar soni ko'p. Versuschilar ham 4-5 yildan keyin ancha tajriba orittirishadi agar ustilarida ishlashsa. Mani firkimcha JS/TS ni biroz modification qilib chiqish kerak formal languages va paradigms bo'yicha. Ha bu juda katta mashaqqatli yoki bo'lmasa umuman ilojisiz darajadagi ish bo'lishi mumkin. Nodejs code browserda ishlamaydi :) Alohida ekotizimga aylanib bo'lganiga ancha bo'ldi. Nodejsda yaxshi yozilgan code ancha hight perofmanceda ishlaydi umuman olganda ekotizimda ma'lum jiddiy o'zgarishlar qilib yanada powerfull tool ko'rinishiga olib kelishga imkon katta :)

O'zim bilmagan holatda SEO qilib qo'yibmanku kanalni 😁

Bu opencv deganlari linux kerneldan ham sekin build bo'lar ekan :) Compiler languagedan foydalanadiganlar build qilayotganda nimalar bilan shug'ullanasizlar 😁

Officeni yoqtiradiganlar uchun maxsus 🫠 80DB shovqin darajasi normadan ko’p 🙂

1 oyda 1ta kitobni yakunlay olsa ham kam ekan :) 1 yilda 12 ta kitob bo'ladi. Degan g'oyalar bilan kunlik o'qishga yuqoriroq prioritet bergan edim ~2 yilcha oldin. O'qigan birinchi kitobimni o'zidanoq juda katta dunyoqarash berib yuborgan edi. Ungacha aynan biror mavzudagi ma'lumotlarni kitoblardan izlar edim. Aytaylik manga HTTPS qanday ishlashi qiziq bo'lib qoldimi. Birinchi soddaroq ma'qolalar o'qib ko'raman. Keyin sekin "Computer Networks" kitobini ochib ko'raman :) Bunga aloqador nima mavzular bo'lsa sekin o'qib chiqman. Bunday amaliyot mavzularning muhimlik darajasi belgilangan vaqt va unga propartsional energiya va yana qiziqishga bog'liq edi. Keyin qarashlar o'zgardi. Biror mavzuni olib o'qib ko'raman. Contextga tushunsam davom qilaman bo'lmasa keyinroq qaytib kelaman :) Endi yana o'zgarish arafasida. Shunchaki random mavzuni olib o'qiyman. Ularning amaliyotini esa yuqoridagi kabi muhimlik darajasiga qarab qilaman :) PS: Aynan kitobdan nimadur o'rganish va kitob o'qish mavzularidagi savollarga umumiy javob :). Bazi kitoblarni shunchaki o'qilganini o'zi katta narsa beradi amaliyot qilish esa muhimlik darajasiga qarab. Umuman olganda mavzu bo'yicha kam kitoblar o'qiganman. Masalan xozir traditional software engineeringa aloqador mavzularda ko'p kitob o'qishim kerak aslida. Lekin man umuman offtopic mavzularni o'qib yuribman 😁 Bu mavzuda useful tavsiya berolmayman qiziqganingizni o'qing :)

1 oyda 1ta kitobni yakunlay olsa ham kam ekan :) 1 yilda 12 ta kitob bo'ladi. Degan g'oyalar bilan kunlik o'qishga yuqoriroq prioritet bergan edim. O'qigan birinchi kitobimni o'zidanoq juda katta dunyoqarash berib yuborgan edi. Ungacha aynan biror mavzudagi ma'lumotlarni kitoblardan izlar edim. Aytaylik manga HTTPS qanday ishlashi qiziq bo'lib qoldimi. Birinchi soddaroq ma'qolalar o'qib ko'raman. Keyin sekin "Computer Networks" kitobini ochib ko'raman :) Bunga aloqador nima mavzular bo'lsa sekin o'qib chiqman. Bunday amaliyot mavzularning muhimlik darajasi belgilangan vaqt va unga propartsional energiya va yana qiziqishga bog'liq edi. Keyin qarashlar o'zgardi. Biror mavzuni olib o'qib ko'raman. Contextga tushunsam davom qilaman bo'lmasa keyinroq qaytib kelaman :) Endi yana o'zgarish arafasida. Shunchaki

Mandat chiqibti. Quyidagi linkar o’qoshga kirolmaganlar va mamdat platformasini qurgan engineerlar uchun foydali. Faqat shu ikki turdagi insonlar o’qishsin ! https://blog.bytebytego.com/p/ep47-common-load-balancing-algorithms https://www.section.io/blog/scaling-horizontally-vs-vertically/#:~:text=Horizontal%20scaling%20means%20scaling%20by,as%20%E2%80%9Cscaling%20up%E2%80%9D).

Eng asabimni buzadigan narsa manual testlar 🫠

Yana sarlavha topolmadim 3 sekundga ko'zingizni yuming va 50 ga 50 santimetrli qog'ozni tasavvur qilib unga 1 metr uzoqlikdagi masofadan qarang. Agar qo'goz huddi stolda turgandek va siz unga tepadan qaragan bo'lsangiz, demak sizda matematik iqtidor bor! Biroq siz qo'gozni huddi devorda ko'rdingiz ya'ni tepadan emas to'gridan qaradingiz (Yer yuzasiga nisbatan). U holda siz fiziksiz! Bu gaplar sizga shunchaki motivation uchun aytilmayapti. Bu sizning biror ilmiy masalaga, tug'ma yondoshuv usulingizni bildiradi. Veb-saytlarga kirgan paytimiz scroll qilsak nima bo'ladi. Sahifa yo tepaga yo pastga harakatlanadi. Albatta! Chunki u 2 o'lchamli va bizga yaqinlashmaydi va bizdan uzoqlashmaydi ham. Agar u 3 o'lchamli bo'lganda yaqinlashtirishimiz yoki uzoqlashtirishimiz mumkin edi (Bu yeda browser lardagi zoom nazarda tutilmagan). Demak 3 o'lchamli fazoda deb bilishimiz uchun faqat yaqinlashtirish (musbat qiymat) va uzoqlashtirish (manfiy qiymat) argumentlari kifoya qiladi. Chunki qolgan 2 o'lcham shundoq ham ma'lum! Agar siz matematik ekanman desangiz, o'sha qo'gozdan quti yasash uchun uning har tomonidan boshqa devor qog'ozlarni siz uchun ko'taramiz. Nima uchun ko'taramiz? Chunki siz tepadan qarayapsiz. Ya'ni sizga nisbatan yaqinlashtirishimiz 3-argument (3-o'q) sifatida musbat qiymat berayotganimizni bildiradi. Aksincha fizik ekanman desangiz huddi shu harakat siz uchun ko'tarilish emas sizga nisbatan yaqinlashish hisoblanadi (Huddi uzoqdagi avtobus sizga yaqinlashgani kabi). Albatta tasavvur qilish tasodifiy. Qog'oz deganimda tepadan, quti deganimda esa yonidan tasavvur qilishingiz mumkin. Ammo fanda biror tasodiflar fundament ya'ni asos qilib olinmaydida! Fundament har doim bitta va faqat yondoshuv har xil bo'lishi mumkin. Masalan matematik uchun shakl ko'tarildi degani ham, aslida unga yaqinlashganini bildiradi huddi fizik uchun yaqinlashganidek. Shundan kelib chiqib 3 o'lchamli fazoda tog'ning cho'qqisini, matematiklar Z o'qi deb bilishsa, fiziklar Y o'qi deb bilishadi. Chunki Fizikada tortishish kuchi (gravitatsiya) har doim -Y yo'nalishida bo'ladi. Ikkala yondoshuvda ham yaqinlashish va uzoqlashish masalasi bir xil. Ya'ni bu yerda fundamental hisob-kitob yoqolib qolmayapti. Lekin ikkisi 2 xil tasavvur qilar ekanku desangiz, unday emas. Bu yerda faqat nisbiylik nazariyasi bor. Demak fizik jihatdan tepa bu Y, matematik jihatdan esa Z dir. Bu tushunchalarning ham ilmiy nomlari mavjud. Y-UP va Z-UP. Tajribamdan kelib chiqib bir narsani aytishim mumkin. Xaritalashda Z-UP dan o'yin dasturlashda Y-UP dan foydalanaman. Fundamentdan chetlashmagan holda ishlash, Applied Science jarayonlarini osonroq qilar ekan. Applied Science ga oddiyroq tushuntirish beraman. Hayotdagi muammoning qandaydir ilmiy yechimi bor, dasturchi bo'lsangiz siz uni kodga o'girib amaliyotga tatbiq qilasiz. Bu Kimyo, Matematika, Fizika, Biologiya va boshqalar bo'lishi mumkin. Xulosa: Fundamental bilimlarni o'rganing! Aytgancha siz matematikmisiz yo fizik? Izohda qoldiring. Aleph Nought