Programming ∀

Nodejs 18-20 versiyalarida yuqoridagi masalalarni anchasi hal etildi. Ammo shaxsan manda concurrency bilan juda ko'plab yechimlar qilish kerak bo'ldi. Bu yechimlar uchun community emas balki asosan o'zimni tajribamga tayandim. Sababi bunday mavzularga doir yechimlar juda kam edi, Temur akani resurslari bor edi bazida shular yordam bergan. Lekin load ko'paygani va perfomance juda muhim point bo'lgani tufayli juda ko'p parametrlar muhimlashib ketti. Masalan avability. Boshida oddiy kubernetes yoki dockerda hal qivormoqchi bo'lgan narsamda state bilan muammo bo'ldi. Uni hal etganimda esa perfomanceda juda negative yechim berdi. Kegin processlar bilan qildim, biroz yaxshilandiku ammo katta foyda bermadi, kegin threadlarga o'tkazdim va threadpool bilan hal etdim. Biroz qoniqarli natija berdi. Ammo bazida resurslar yetishmasligi threadlar esa lock bo'lib qolishi kabi boshqa muammolar chiqdi. Ammo bu etibor qilishga juda muhim muammo emasdi shu sabab yechim jiddiy o'zgarishlarga uchraamdi. Oradan vaqt o'tib shuni tushundim "DevOps tools aynan ko'plab dasturchilarni skill issuelarini yopish uchun" Vaqt o'tib bir loyihaga qo'shildim, u yerda asosiy qiladigan ishim devopslik loyiha esa asosan nodejsda. Barcha infratuzulma kubernetesda bo'ldi docker containerlar bilan. Kerakli monitoring va boshqa yechimlarni ham tayin qildim. Oradan vaqt o'tib qiziq narsani kuzatdim, docker containerlarda negadir memory boshqaruvida issuelar bo'lyabti. Bazida birgina container load kam bo'lsa ham 4-5GB ramdan bo'shamayabti. Kegin bilsam aynan o'sha applarda memoryga katta ma'lumotlar yuklanyabti, ammo kube schedulerda ham shunchaki OSda tekshirsam ham memory managementda juda ko'p overheadlar b'lyabti. Nega ? Sababi containerlar bilmaydi chegarasi qanday bo'lishini. Dockerdagi memory overheadlar haqida alohida o'qishingiz mumkin. Bu narsani atayin cloud funksiyalar bilan ham tekshirgan edim ularda birmuncha boshqacharoq ishladi lekin loyiha cloudga o'tishga budjedi kam edi va arxitekturial ancha o'zgarishlar kerak bo'lgan. O'tgan yili esa manashu muammoni juda zo'r hal etishga mos bo'lgan yechim sifatida fiberlar bilan tanishdim va yaqinda huddi shunaqa mavzudagi muammoga fiberlar bilan yechim qildim. Juda oddiy misol, ko'pchilik containerlar bilan appni ko'plab instancelarda ko'taradi, ammo kegin statefull app qilishda muammolarga duch kelishadi. Oradan ancha vaqt o'tib, nodejs persmissionlarni ham typescript supportni ham tog'irladi. Ammo ungacha bun, deno kabi alternativlarda bunday narsalar ancha oldindan bor edi. Expressjs o'rniga nestjs trend bo'ldi ungacha odamlar fayllarni qanaqa sturkturalash haqida baxslashib yuravergandi. Lekin bu narsalar ancha oldin javada bor edi. pnpm kabi paket managerlar paydo bo'ldi. Lekin nega ? nega oradan shuncha vaqt o'tib bu narsalar endi qilindi ? Mani javobim asosiy masalalar raqobat bilan bog'liq. Eslayman biz ham qanaqadir file permissionlar uchun kutbxonalar qilganimizni. Eslayman openapi uchun o'zim testlardan api generatsiya qiladigan kutbxona yozganimni. Eslayman nodejs bor ediku ammo o'rganishga tayinli resurslar yo'qligini. Xozir bilmayman nodejs va community qayerga qarab ketyabti. Ammo bilamanki ekotizimdagi ko'plab boshqa fundamental muammolarni hali aytmadim. Ularni turli uslubda, ko'rinishda hal etib yopishga xarakat qildik va xozirgacha shunday. Lekin yuqorida takidlaganim kabi bularning hammasi qandaydir boilerplatelar yoki bo'lmasa kostillar bilan bo'lyabti. Bu esa o'z o'zidan yana boshqa muammolarni keltirib chiqaryabti. Manga yoqmaydigan yagona narsa shu biz yangi texnalogiyalarni juda eski g'oyalar va tajribalar bilan quryotganimiz. Yuqoridagi va undan ko'plab boshqa muammolar, ko'ngilsizliklarning hammasi aynan hammasi ishlayabtiku degan fikrlar bilan sodir bo'lgan. Muammolar qiyinchiligi xozir oshib boryabti eski yechimlar esa bularga mos kelyotgandak ko'rinadi ammo shu fundamentlarga taqayveradi.

Odatda turli texnalogiyalar yoki platformalar hate qilinganda turlicha ko'rinishda suxbatlar shakillanadi. Shu o'rinda man agar biror narsani hate qilsam nega ekani bazida ko'pchilik hamkasblarimizga tushunarsiz bo'ladi. Bu esa o'z o'zidan radikalism va evangilizm bilan izohlanadi. Ho'sh manda eng ko'p tajriba nodejsda va shu ekotizim asosida backendni o'rgandim va shu muhitda professional koryerani boshladim. Endi sizlarga manashu ko'rganlarimni aytib bermoqchiman. Man nodejsning 8 versiyasidan boshladim. Bir loyihamda aynan CPU intensive muammo bor edi. Xisoblashga doir. Manda bunday mavzulardan umuman tajriba yo'q va hechnima bilmayman. Juda ko'plab resurslardan qidirganman huddi shu narsaga yechimni C++da topgan edim. Hamma bilan kelishib manashu vazifani C++da qilib Nodejsga addon qilishga qaror qilganmiz. Bunday tanlovga eng asosiy sabab u payitlar tjribali nodejslar kamligi va boshqa communitylar tomonidan shunday tavsiya berilgani edi. Ammo addon yozish oson bo'lmagan, chunki u payitlar nodejsda FFI yaxshi emas edi. Lekin masalani hal etish shart nega sababi aynan xozirgi yechim talabga javob bermaydi. Hullas ushbu muammoni hal etishda nafaqat skill issuelar balki platform issuelarga ham juda ko'p duch kelganmiz, Oradan ko'p o'tmay nodejsda bu narsalar yaxshilandi ammo aynan o'sha payitda nodejs versiyasini yangilay olmaganimiz ham addon qilishga juda katta sabab bo'lgan edi. Nodejs 12 threadlar chiqdi, aynan o'sha muammoni threadlar bilan qilib ko'rdik, natijalar esa qoniqarli bo'ldi va ohiri loyihani 12-versiyaga o'tkaza oldik, ammo ungacha bo'lgan vaqtda anchagina muammolarga duch kelgan edik. Kegin boshqa loyihada huddi shunga o'xshagan narsalarni child process bilan qilishganini ham ko'rdim. Ammo uyoqda anchagina uzoq processing edi shu sababdan uncha zarari yo'q edi. Bilamizki nestjsdan oldin nodejs ekotizimida eng mashxur narsa bu expressjs bo'lgan aynan backend uchun. Community tajribasi va boshqa resurslar sababdan o'zim ishlagan loyihalarda juda ko'plab middlewarelar ishlatar edim. Foydalanishga qulay va oson. Oradan vaqtlar o'tib bizda chain componentlar ko'payib ketdi va debug juda ham qiyinlashib ketti. Chunki hamma joyda context mutatsiyaga uchrar edi. Afsuski community tajribasi ham bu borada deyarli yordam bermadi. Ekotizim va community bilan bog'liq undan yomonroq muammolar keginroq boshlandi yani bizdagi dependencylar bilan. Ko'p loyihalarda typeorm ishlatar edik, ammo keskin o'zgarishlar tufayli juda ko'p muammolar chiqib kelaverdi. To'g'ri bu yerda asosiy muammo mendagi skill issuelarda bo'lishi mumkin. Ammo communityda bu normal practice bo'lsa nima qilish kerak ? Nodejs 16-versiyalardan biroz stabillashdi, ammo boshqa platformalardan ancha orqada qolayotgan edi, masalan permissionlar yo'qligi sababdan bizda ham turli issuelar bo'lgandi. Undan yomoni 14-16 versiyalargacha nodejs va typescriptni kelishtirish edi. Buning uchun juda ham ko'p uslublar bor ediku ammo hammasining o'ziga yarasha qiyinchiligi bor edi, yani doyim ham siz kutganday bo'lmaydi.

Haskell va FP bilan qilgan tajribalarim asosida tushunib yetgan narsam asosida bazi fikrlar shakillandi. Umuman olganda bazi narsalar o'rganishga halal bergan bo'lsa bazilari dunyo qarashimni ancha oshirdi. Bular sizda ham bo'ladi deyishdan yiroqman shunchaki o'zimda kuzatganlarim. Tillar oilasi - FP ga kirib kelganimdan buyon turli oilaga mansub tillar bilan tanishdim va nimadirlar qilib kelyabman. Bu narsalar dasturlash tillariga va umuman dasturlashga bo'lgan qarashlarimni o'zgartirib yubordi. Turlicha yondoshuv - Shu payitgacha man code yozganimda oldin logicni yozib kegin unga tiplar yozganman. Bazida biror logicni chiroyli dekompozitsiya qilish o'rniga tiplarni o'zgartirish osonroq edi. Buni ortidan abstraksiyani buzib qo'yish holatlari juda ko'p bo'lgan. Xozir esa asosiy focus tiplarga qaratilgan. Yani tiplar bilan o'qiyman va tiplar bilan tushunaman manashu narsaga ko'proq harakat qilyabman. FP conceptlari donolar so'zi emas - Boshida monadlarga ham boshqasigayam woow bu yerda yana qanaqadir sirli narsalar bor degan ko'z bilan qarar edim. Xozir hammasiga tiplar bilan qarayman va sekin sekin tushib yetyabmanki nega oddiy stringlarni qo'shishda ham "++" emas balki "<>" semigroup ishlatilinganini. Yoki bo'lmasam nega buncha ko'p conceptlar borligini. Umuman olganda doyim ham tehoryga zadror bo'lish shart emas. Sotsial masalalar - Umuman olganda boshida hayron qolgan edim, chunki juda ko'plab oliy nasab dasturchilar ham oddiy communitylarda o'tirishlari va ularni oddiy odamlardan ajratib bo'lmasligini ko'rib. Ha, hammaning o'ziga yarasha xarakteri, nafsi bor va hamma inson. Community va sotsial mavzularda FP tomonlardan o'rganadigan narsamiz ko'p va shu bilan birga aynan o'sha engineering culture saqlanib qolgan. Rivojlanish - FP turli tomonlarga qarab rivojlangan va shunday bo'lib kelyabti ham. Xozirgi mashxur tillarning deyarli hammasida FPchilar hissasi katta. Bunga birinchi marotaba rust bilan tanishganimda guvoh bo'lgan edim. Kegin sekin sekin bildimki bizga mashxur tillardagi bazi narsalarni ham aynan shu yo'nalishdagi olimlar qo'shishganini, generics, pattern matching, Option, Result types etc... Shu o'rinda Vitaliy amaki yaqinda bo'lgan podcastdagi aytgan gaplarni ham eslab o'tish kerak. Iltimos podcasni ohirigacha ko'rmasdan quyidagi quotedan fikr shakillantirmang !

FP dasturlashdagi labaratoriya bo'lib ham xizmat qiladi!

FP juda ko'p eshiklarni ochib berdi. Masalan qanday qilib dasturlash tillari qurish, compiler, interpreterlardan tortib qanday qilib dastur TZsini proof qilishgacha. Bundan tashqari yana ko'plab turli mavzularga olib kirdi parserlar, parallel va concurrent programming, async programming, error handling vaxakazolar. Yil boshida FP uchun matematika kerak, akademik bilim kerak deb yurgan edim. Ammo boshlaganimdan kegin hech qanday matematikaga va akademiyaga ishim tushgani yo'q. Bu shuni anglatadiki bunday gaplar shunchaki bahona yoki bo'lmasa qorquvdan boshqa narsa emas. Aslida indamay o'tirib boshlaganimda xozir yanayam ko'proq narsalarni bilgan bo'lardim, mayli qadar ekan hali hammasi oldinda )) Sciencega qarashlarim o'zgara boshladi - Boshida juda katta tayyorgarlik va tonnalab narsalar kerak deb yurgan edim. Aslida unday emas bir chekkadan boshlash kerak tamam. Matematika ham qiyin emas o'rganish uchun kuniga 10ta masala ishlash ham kerak emas. Mavzularni o'rganish va tushinish yetarli. Man boshida hamma narsa ideal bo'lishi kerak deb yurgan edim aslida inson qilgan hechnima ideal bo'lolmasligini amaliy isbotlarini ko'rdim. Borgan sari ko'p tillarni tushunish va o'rganish oson bo'lib borayotganini sezdim. Buning sababi esa turli tillar oilasidagi fundamental narsalar bilan bog'liq. Man bunday hissiyotni algorithmlarni o'rganib emas Haskellni o'rganib seza boshladim. Ammo yagona qilayotgan xatoyim bazida kam code yozyotganim, bu masalani imkon qadar tezroq tog'irlashim kerakligini tushunib yetyabman. PS: Ohiri tushungan narsam shuki perfectionism bor narsa ammo uning o'zi perfect emas 🙂

Vanixoyat odambashara setup boshlandi 🥲 Uninstalldan kegin /nix volume o'chmayotudi. Hamma nix folderlarni bittalab tozalab chiqish kerak ekan.

O'ylaganimdan tez bo'ldi hamma narsa. MacOs ham chakki emas ekan benchmark qilib o'tirmayman sababi linuxda qurilmalar umuman boshqacha.

MacOS da battareydan tashqari yoqgan yana bir narsa bu File system. Oddiy file I/O operatsiyalarda linux ext4 bilan ko'incha OS qiynalishni boshlaydi, ayniqsa desktopda. Nega ekanini xozircha topa olmadim chunki bugun sezib qoldim. MacOS bu masalada ancha yaxshi ya'ni foydalanuvchiga sezilmaydi. Balki linux devaysimda raid qilmaganimga shundaydir xozircha aniq firklar yo'q. Macosda esa swap ham bor o'zinki shunga qaramay diskga load bo'lsa ham hechnima sezilamayabit rasmda esa birnecha kunlik I/O metrikasi.

ghostyni ishlaytabsilarmi ?

Maqola yaxshi ekan, VMlar haqida bir kitob bor edi nomini eslolmadim haliyam juda ko’p naraalar detailed yoziludi runC haqida ham bor edi.

Write your Own Virtual Machine Comments via jmeiners.com via sam_ezeh

Yanayam o’zim parser yozganim yo’q hali !

Masalan kecha duch kelgan masalam, default parserlar ham synchronus ishlaydi, oqibatda kattaroq faylni parse qilsangiz oldin hammasini memoryga yuklaydi, tassavur qiling 4-5gb file bor va siz uni pare qilishiz kerak. Doyimgidak paket qidirasiz, ammo afsuslar bo'lsinki tayinli paketlar yo'q, borlari bazi versiyalar bilan chiqishmaydi. Stream trasformerlar bilan o'zingiz pipeline qurishiz mumkin, bunaqa holatda katta faylni parse qilishga o'zingiz own pipeline based parser yozasiz, bu yana alohida mavzu chunki pagelarga ajratib chiqib parse qilasiz. Buyoqda esa aniq surprizlar kutib turibti, paggingdan o'tib olganiz bilan pipeline o'zini debug qilish ancha bosh og'riq va hamma narsani bir biriga yopishtirish uchun objectlarizda inheritance hell boshlanadi. Agar hammasini norm qurib chiqishni istasangiz ancha narsani 0dan yozasiz. Bu esa ko'p vaqt oladi. Threadlarni debug qilishni gapirmasa ham bo'ladi, umuman user friendly emas masalan manda Interrupt bo'lgan threadlarni terminate qilolmay qovoti. Nima sizlar bunaqa narsalarni containerlar bilan hal etamiz deb o'ylisilarmi haliyam ?

Buffer allocationdan tortib memory managementgacha tushunarsiz, bordak platforma 😏 Shunga platform trash bo'lsa hammasi trash bo'ladi deymanda. Effect-ts zo'r narsa, ammo runtime rasvo, shu sababdan ham doyimam siz kutgandak bo'laveramaydi. Fiberlar bilan ishlash mazza, lekin platform tupoyligi fiberlar imkoniyatlarini cheklab qo'yadi.

hehehe trash

Manashu narsani deb anchagina I/O tasklarda perfomance oshdi. Oldinlari databaselar bilan bo'ladigan I/O latency problemalarni bazilari hal bo'ldi. https://kernel.dk/io_uring.pdf

Manabu foydali marketing deyiladi, chiroyli abstraksiyaga o’raymizda sotamiz😎

O’rta statistik qomat parametrlar asosida maniken yasalganida.