Programming ∀
Open in Telegram
Ushbu kanalda IT va Dasturlashga aloqador mavzularda subyektiv fikrlarimni bayon qilaman.
Show more1 217
Subscribers
No data24 hours
-87 days
-3530 days
Posts Archive
1 217
Engineer sifatida nima motivate beradi ?
Taxminan 4-5 yilcha oldin ushbu savol actual edi. Asosiy javobim bu process edi. Learning process work process. Shu jarayondagi turli challengelar. Keyingisi esa monetization turli aspectlardagi narsalarni monetization qilish.
Turli jarayonlar, kompaniyalar ichidagi boshqaruv tizimi vaxakazo masalalar ayniqsa juda bilimsiz management sabab ko'p ustimda ishlashimga to'g'ri keldi. Junior sifatida koryeram juda success boshlanmagan bazida juda oddiy narsalarni ham eplay olmas edim yoki fail qilar edim.
O'zimdagi minimal narsalarni ham maksimal darajda monetization qilish qiziq edi. Masalan qandaydur kichik loyihani ham ustida ishlab sotsam.
Challengelardan bazida katta potensial bilan chiqsam yana bazida looser bo'lar edim.
Boshida hamma narsa qandaydur uzoq muddatli o'yin kabi edi. Man personajman turli aspectlardan rivojlantiraman rivjlanganim sari levelim oshib boradi. Ko'zimga barcha narsa shunday ko'ringan huddi Witcher3 yoki Cyberpunkga o'xshagan ammo ancha real va juda katta o'yin ichidagi main personajga o'xshar edim 😁 O'zimni faqat manaviy tomondan modify qilishim cheklanmagan qolgan narsalar cheklangan. Yaqin 1-2 yilgacha asosan shunday tassavur edi. Negaki har bir challenge yoki problem yoki vazifa manga tajriba berayotganini va bu tajriba level o'sishiga sabab bo'lishini his etar edim. Shu sabab bu process juda qiziq edi.
Oradan vaqt o'tib bu amaliyotlar biror game sujetlaridan ancha murakkab ekanini tushungan edim :) Ammo bu challengelar tugamaydi toki biz o'lmagunimizcha...
Keyin yana shu savol ko'tarildi. Sen engineer sifatida nimadan motivate olasan ?
Bu savolning javobi topilmaganday tuyulgan edi. Keyin javobni qidirish uchun analiz qilishni boshladim :) Bazida juda ko'p o'qib dars qilib ko'rdim. Bu huddi bir taraflama hayotga o'xshab qoldi. Uy o'qish ish. Keyin yana o'zgarish qildim. 2-3 ta ishda ishlab ko'rdim 4 oycha muddatda katta daromat ham qildim katta tajriba ham oldim ammo umrim ishda o'tib ketganday tuyuldi. Keyin o'z loyihalarimni qilib ko'rdim. Turli g'oyalar fikrlar manda juda ko'p keladi sekin sekin realizatsiya qilib ko'rdim. Bular katta tajriba berdi. Ammo dunyoni ko'rmay ketti sababi o'zim distiplina qilmadim.
Hullas turli parametrlarni rivojlantirib ko'rdim turli nuqtalardan qarab ko'rdim. Ammo eng katta boom bo'lgan narsa professionalism bo'ldi. Hobby vs Kasb masalasi bo'ldi. Bu ikkisni o'rtasidagi farqni tushunganim sari nima uchun bu sohada yurganimdan tortib nima uchu shu sohada qolishim kerak ekanigacha bo'lgan barcha asosli javoblar topila boshladi. Hobby uchun code yozilganida sizdan asosan ijodkorlik talab qilinadi. Dasturlash bilan shug'ullanib dam olish mumkin(Buni hamma ham eplay olmaydi).
Professional Engineer esa har bir qilayotgan ishiga nisbatan distiplina bilan qarashi kerak.
Motivationga aloqador fikrlarim ancha o'zgarib ratsionallashib boryabti.
Hosh, Sizga engineer sifatida nima motivate beradi ? Hurmatli Qo'chqor aka
1 217
Bugun independence day. Mobodoga loyihangizda high coupling bo’lsa shularni to’g’irlashga sabab 😁
1 217
Qarshingdagi odam senga ertak aytayotgan mavzusini bilishingini bilmasa va sen gaplari notogri ekanini aytsangu ertakni davom qilsa...
1 217
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 :)
1 217
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.
1 217
Repost from Aleph Nought
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
1 217
Ushbu voqealardan ancha tajriba va hulosalar oldim endi miyya joyiga kelganidan keyin sekin izohlab chiqyabman 😁
1 217
Ushbu voqealardan ancha tajriba va hulosalar oldim endi miyya joyiga kelganidan keyin sekin izohlab chiqyabman 😁
1 217
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 :)
1 217
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 :)
1 217
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 :)
1 217
Bu opencv deganlari linux kerneldan ham sekin build bo'lar ekan :) Compiler languagedan foydalanadiganlar build qilayotganda nimalar bilan shug'ullanasizlar 😁
1 217
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 217
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
1 217
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).
