Programming ∀

A samurai has no goal, only path 😎

Bu mavzuda quyidagicha uslubni qilaman: Eng birinchi umumiy tizimni analayze qilaman. Layerlar, ulardagi qilingan approachlar va codebase. Nega ? Sababi aynan qaysidir qisimda juda katta resource utilization, long processing time vaxakazolar bo'layotgan bo'lishi mumkin. Shu sababdan tizim componentlari va ularni holatini o'rganish asosiy simptomlarni topishga katta yordam beradi. Lekin hali aniq muammolar chiqmadi.... Keyingisi aniq reasonlar qilib olaman. Masalan 3 second response timeni 300~500ms ga tushirib bo'ladigan bo'lsa. Yoki yana boshqa maqsadlar bularni hammasi aniq talablarga aylanadi. Shunda muammolar aniqlashadi. Bu narsani qanday amalga oshiraman ? Masalan bizda mavjud mongodb va Falon arxitekturada falon serverda turibti. Mongodb o'zidagi default perfomance bo'yicha xozirgi tizim holati qanday ? Default holatda xozirgi QPS qancha bo'lishi kerak vaxakazoalar... Shu asosida har bir layerlarda simpthomlar topiladi 🙂 Hullas yuqoridagi ikki bosqich eng birinchi qiladigan ishim. Bu har qanday holatda qilinadi va bu process uchun loyiha masshtabiga qarab N vaqt olaman. Keyingi masala aniq talablar: Talablarni tuzar ekanman faqatgina texnik emas balki business momentlarni ham xisobga olish kerak. Shu sababdan birinchi homaki yechimlarni ishlab chiqish. Har bir simpthomni aniqlab unga yechim qilish va business capabilityga mos qilish kerak lekin bazilari faqat technical bo'lishi mumkin. Shu sababdan extimoliy simpthomlarni o'rganib chiqaman va shu asosida list qilaman. Kegin o'zim prioritetlar qo'yaman. Masalan quyidagi parametrlar bo'lishi mumkin prioritetda: 1. Time 2. Cost 3. Bariers 4. New problem risks 5. Skill & expirence 6. I don't know I don't know. 7. Impact Yuqoridagi prioritet parametrlari asosida ranking bo'ladi va eng toplarni boshlayman. Aytaylik web server. Mani holatimda nginx. Hosh optimize uchun nima qilishim mumkin ? compressing, caching aytalik man bilganlarim. Darhol implementationga o'tish yo'q. Boshqalar qilganlarini ko'rish kerak )) Shu sababdan communitylarga murojat qilaman, stackoverflowdan qarayman vaxakazo. Bunga juda ko'p vaqt sarflamaslik kerak. Shu sabab researchni ma'lum intervalda qilaman. Research qildim va yangi narsa o'rgandim. Tunning... Endi ushbu implementationi ham alohida sub muammo qilaman. Nega ? Ha shunday yechim bor ammo bu manga qanchaga tushishini bilmayman )) Agar aniq ishonadigan narsalarim bo'lmasa yaxshisi alohida muammocha bo'lsin. App layer, DB hammasi huddi shunday. Birinchi navbatda muammolar -> Hal etish uchun o'zim bilgan yechimlarim -> Boshqalarni yechimlari va man bilmasligimni bilmaydigan yechimlarim. Aynan shunda community va researching katta foyda beradi. Kegin shunga qarab baholash va ranking yana o'zgarishi mumkin. Shu sabab communitylarda qo'rqmasdan axmoqona savollar bo'lsa ham beraverish kerak. Debatlar qilishdan ham qo'rqmaslik kerak... Manda time, cost va yana boshqa parametrlar asosidagi ma'lumotlar bor ekani. Bussiness bilan gaplashishga yordam beradi. Shu sabab ularning rejasini ham o'rganish kerak. Masalan balki business N oydan kegin katta marketing qilgani sabab traffic 10-15x bo'lib ketar... Balki biror texnik yechimda yuridik masalalar bordir... Masalan man active bo'lmagan userlar sessiyasini N vaqtdan kegin o'chirib tashlash kerak desam. Ammo qandaydir qonun sabab barcha sessiyalar M vaqt saqlanishi mumkin... Hullas business bilan sync qilgan holatda eng oson va eng katta impact kutilyotganlaridan boshlayman. Chunki masalan oddiy cache sabab requestlarni kamaytirib 2-3x yutsangiz ham business uchun katta impact bo'lishi mumkin. Bu esa kam impact ammo juda muhim ishlarga nisbatan ko'proq etibor qilishga vaqt ajratishga olib keladi. Hullas manda biror muammoni yechish uchun yechimlar yo'q ! Yagona yechimni qilish uchun qanday yo'llardan borish va umumiy jarayonlar ketma ketligi bor. Optimizationda eng muhim factor bu Research and Development deb o'ylayman. Ha tajriba sababdan bazi narsalarni bilishingiz va oson hal etishiz mumkin. Ammo sizga notanish muammolar bo'las aniq R&D ga extiyoj sezasiz.

Refactoring uchun eng yaxshi va oddiy uslublardan biri. Codeni ko'rding, yoqmadimi ? Report qil ! Bug yoki tasklar qayrga yozilsa darxol yozib qo'y ! Kegin feauture/bug ko'rinishida sprint yoki timelinega tasklar olinganida sen qilgan reportlar tasklar orasida bo'ladi qachondir... Kejalakda yana jamoa boshqarib qoladigan bo'lsam manashu madaniyatni singdiraman 🙂

Next week I'm planning to interview Linus Torvalds. What questions do you think I should ask?

Bu yerda javoblar yeg'ilguncha yengilgina Monoidlar haqida o'qisak bo'ladi. https://www.kodeco.com/books/functional-programming-in-kotlin-by-tutorials/v1.0/chapters/12-monoids-semigroups PS: Bundan yaxshiroq resourcelar bo'lsa commentda qoldiring.

Agar o'quv markazlarida o'qisangiz ushbu savolni uztozingizga berib ko'ring 😎

Optimization: Tassavur qiling siz qurgan XmXm nomli App sekin ishlayabti. Va sizda quyidagi componentlar mavjud. 1. Web server. 2. Application. 3. Database. Savol juda abstract va atayin shunday tuzilgan. XmXm application xozirgi potensialidan N barobar tezroq ishlashi uchun nimalar qilgan bo'lardingiz ? Albatta o'z tajribangiz va siz ishlatadigan stackdan foydalanib javob berishingiz mumkin. Hints: 1. Siz hohlaganingizga componentlar qo'shishingiz mumkin. 2. Xozirgi status bo'yicha bizda 100k userlar mavjud va shularning 31% qismi active. 3. Active user deb har kuni kamida 8ta request yuborgan client hisoblanadi. 4. Xozirda faqatgina remove amaliyotlardan boshqa barcha amaliyotlar sekin ishlayabti.

Индусский код — код, который написан слишком длинно и "кудряво". Такое название связано с особенностями оплаты работы программистов в Индии: им платятза каждую строчку кода. Хитрые и прозорливые специалисты пользуются этим и прописывают лишние бесполезные строки #Term | Гайды Программиста | ChatGPT

The principal programming paradigms.

Agar kelajakda adashib davlat hodimi lavozimiga o'tib qolsam. Aynan manashu azoblar uchun alohida jinoyi va ma'muriy jazolar o'ylab topaman.

Yana bir azob: Refactoring: Bu qachon azobli bo'ladi qachonki siz qilgan loyiha hali prodga chiqmasdan turib refactoring boshlansa 🙂 Asablarimni o'ta baland chastotada tebrantirib yuboradi shunday narsalar 😎

Cost optimizationku mayli eng azobli narsa nima aytaymi ? Eng azoblisi perfomance optimization... Chunki nimadan boshlashni bilmaysiz bazida. Shunchalik aralash quralash bo'lib ketganki random sonlar arrayi ham bu randomlik oldida random emas 😅

Kamroq lame content istemol qiling 🙂 https://tontinton.com/posts/database-fundementals/ https://tontinton.com/posts/scheduling-internals/

Hamma caselarga mos kelib turganida milliondan yana bittagina xisobga olinmagan case chiqsa.... Dunyoni to'xtating men tushib qolaman !

Yana bir qiziq holatni kuzatdim. Aynan imperative workflowda namming katta role o'ynaydi. Ochig'i manga yoqmaydi juda ko'p contextlardagi namming. Ayniqsa *Factory Abstract* Base* *Entity *Model *Controller *View _* private declarationlar uchun... Vaxakazolar. Nega yoqmaydi ? 1. Syntax noice ko'p. 2. Tushunarli ko'rinadi ammo cringelashib ketadi. Masalan *FactoryFactory 3. Decomposition va reusability muammoli chunki asosan inheritance shuni tasiri namminga ham katta. FP tillarda ishlar ekanman negadir namingdan muammolarni sezganim yo'q. Aniq responsiblity berilgan pure functionlar va kuchli tipizatsiya umuman boshqa yondoshuvni taklif qilyabti. Ushbu yondoshuv context asosida shakillangan va yuqori reusability va compositioni targ'ib qiladi. Bunaqa holatda alohida terminalogiyalar haqida ham juda qayg'urmasdan bemalol ishlash mumkin. Qisqa aytganda Engineer technical customer ekanini va code yozayotganini his etadi. O'qiyotganida ham biror business solution implementatsiyasini o'qiydi ))

DevOps boyicha part time ishlar bo'lsa ko'rib chiqishim mumkin mobodoga 🙂 Soatiga task bo'yicha narxlarni kelishamiz !

Muhammad akamniyam FP ga o'tkazamiz... Ana kegin Web 3Dda ham FP rivojlanadi 😎