Programming ∀

AUF )) @copyright @keilambda

Data model mapping uchun mos keladigan va encode/decoding oson bo'lishi kerak deyilgan. Shunga mos semantics paydo bo'ladi. Lekin bitta neto tomoni bor, log aggregationlar ko'payib ketadi. Mani fikrimcha mapping log create qilishdan oldin bo'lishi kerak. Aggregatorlarga ish qoldirmaslik kerak )) Ammo tushunishimcha standartizatsiya foyda bermaydi bu degani hamma logger driverlarda birxil standart qilish kerak, bu uchun hamma loyihalarda shuni o'zgartirib chiqish kerak. Shu sababdan aggregatorlar ishlatishadi, logstash kabi. Ammo logstashlarda boshqa muammo kelib chiqyabti, log aggregation pipelinelarni deb alertlar kechikadi, ha buniyam birnimalar qilib amallashgan ammo bunaqa holatlarga ko'p duch kelgan edim. Alertlar birnecha daqiqaga ham kechikgan bazida. Yana bir approach esa agentlar o'zida tayyor log model yuborish kerak. Masalan filebeat kabi toolda logni olamiz, parse qilamiz va send qilamiz. Ammo bilamizki bu doyimiy parsing degani. Yani ko'p resource utilization ketadi. Shu sababdan ham loglarni yozishdan oldin aniq formatlashni loggerlar o'zidan boshlash kerak degan firkni ko'pincha oldinga suraman. App layerda bu jarayon unchalik ham katta resurslar yemaydi. Lekin bazi murakkabroq contextlarda muammolar kelib chiqishi mumkin masalan loglarni guruhlash vaxakazolar qilish paytida. Shu sababdan deyarli hamma dummy ammo structured loggerlardan foydalanadi. Agar uzoqni ko'zlasak barbir log aggregatorlar + structured logger driverlar bo'lib qolyabti. Ammo doyimiy log aggregatin uchun content dilivery muammosi bor. Shu o'rinda log collector va log driverlar juda kam resurs utilizatsiya qilishlari shart, ammo bilamizki real hayotda unaqa emas bemalol GB ram ham ishlataverishadi collectorlarimiz )) Driverlarimiz ham uyalmasdan CPUni ichishadi. Qisqasi oddiy loglarni yozishdan ularni saqlanadigan joyga yetkazishgacha manashuncha bosh og'riqlar bor. Siz haliyam AI dasturchilar ishini olib qo'yadi deb ertaklaringizda yuribsiz. Agar semantic log bo'lmasa AI ham tushunolmaydi ))

OTeL log model qilyabman eng prikol joyi deyarli hamma projectlar o'zicha qilib ketgan )) Masalan eng muhim fieldlardan biri time, bazilarda time numeric unix epoch bazilarda esa string yoki datatime )) Requirementlar ham qiziq, yani deyarli to'liq erkinlik huddi yamlga o'xshaydi )) Bitta perfmoance mavzusida birmuncha tayinli narsalar topib oldim. Nu mayli practice uchun shular ham bo'ladi, ammo OTeL modellari man o'ylaganimdan ham bardakroq bo'lib chiqyabti )) To'gri qanaqadir semantic bor RFC ham bor. Ammo hamma RFCga tupurib hamma o'z dunyosini qurigan 😁 https://docs.google.com/document/d/1ix9_4TQO3o-qyeyNhcOmqAc1MTyr-wnXxxsdWgCMn9c/edit?tab=t.0#heading=h.1c8voo540fzy

O’qiganku ammo uqimagan deganlari shunaqa bo’lsa kerak. Mashina oynasiga … qilib ketgan qushlar esimga keldi musichalar.

Ohho 2000 yillar vaybini his etyabman😇 Ammo maqola zor ekan. Manimcha qanaqadir manoda haliyam actual. Ha aytgancha bu maqola ko'pchilikga mos kelsa kerak o'qishga.

Refactoring Functional Programs https://kar.kent.ac.uk/14267/1/notes.pdf

Haskellga turli ekotizimlardan onboarding qilish haqida maqolachalar o'ylayabman. Lekin Haskelldagi hamma narsalarni solishtirib yoki aynan haskell kabi implement qilish mumkinmas. Shu sababdan aynan bazi o'xshashliklar haqida yozaman. O'ylab qarasam bunday content man uchun turli tillar bilan biroz yaqindan tanishgani qiziq bo'lsa o'quvchi uchun haskell bilan tanishish qiziq bo'ladi.

O'zi so'radi 🤷‍♂️

Toshmad va Eshmatni topib oldim, tasodiflarga ishonmasam ham tasodifiy holatda chiqib qoldi 🤷

Qaytaraman bizda faqat Life bor ! Work life balance degan tushuncha toza scam ! Toza kapitalistik yuvilgan miyyalar shunaqa o'ylaydi )))

Servant ekotizimiga moslashib olib kegin biroz o'zimga moslashtirsam va relase uchun alohida policylar qilib olsam marra maniki. Bazi avtomatizatsiyalar bilan frontendchilar bilan gaplashis mavzusi anchagina yopilar ekan 😎

To'grisi api contractlar uchun juda ham ko'p yechim o'ylaganman va sinaganman lekin hech o'ylamagan ekanmanki backend frontend uchun API call lib yasaberishi mumkinligi haqida. Bunisi yangilik bo'ldi. Tassavur qiling siz frontendchiga har safar apilar o'zgarganini aytib o'tirmaysiz sizdagi APIdan js code generate qilinadi axios yoki boshqasi uchun. Siz uni huddi alohida library SDK kabi share qilasiz tamam. Genialno ! https://docs.servant.dev/en/stable/tutorial/Javascript.html

HKT ham qilishibti birnimalar qilib 👍 Titkilab ancha narsalarni topib oldim lekin. Hullas FPni effect-tsdan boshlelar deb tavsiya qilolmaymanu ammo nimadirlarga ishlatselar bo'ladi. Boshlanishiga error handling, pattern matching kabi narsalardan projectga tiqishtirsa bo'ladi.

Hayron qolmayman yaqin orada Effect integrated SDKlar ham paydo bo'lsa. Masalan AWS SDK effectga o'raladi. Nestjschilar o'zini axmoqona microservis patternlari bilan maqtanib yurgan bir davrda bunaqa narsalar bo'lsa bormi ))

Lol, effect-ts juda ham ko'plab fichalar qo'shib tashabti. Nodejs ekotizimidagi yagona tayinliroq framework, Tog'risini aytsam bunchalik progress bo'lishini tassavur qilmagan ekanman. Rostan ham ZIOning ukasi bo'lyabti. Nestjslar biz automatic DI containerlar bilan progressive frameworkmiz deb maqtanib yurgan davrda effect aynan developerlar uchun juda foydali va kerakli fichalar qo'shib haqiqiy progressive framework qanaqa bo'lishini ko'rsatyabti. Respect ! 5 yildan ko'p nodejsdagi koryeram davomida man ko'rgan nodejs frameworklar orasida eng yaxshisi, yana biroz vaqt o'tib stabillashsa nestjslar buni oldida tupoy va qasshoq bo'lib qoladi ishonaveringlar. https://effect.website/docs

Artifacts(Artifaktlar) Biz uchun odatiy ish kunidagi va shunchaki default engineering uchun kerakli bilimlar bu standart artifaktlar. Buni huddi moba games kabi herolar misolida tassavur qilsak bo'ladi. Ammo real hayotda salgina boshqacha ishlaydi, masalan o'yinda sizda qanaqadir juda katta kuchga ega artifact bo'lsa siz maqsadingizga tezroq yetasiz. Ammo o'yin va real hayotdagi farq bu real hayotdagi maqsadlar, orzular primitiv bo'lmasligida. Yani biz parallel holatda birqancha maqsadlar ustida ishlaymiz. Bir dasturchi hechqachon faqatinga dasturlashni o'rganmaydi unga qo'shib yana ko'plab boshqa narsalarga ega bo'ladi. Ho'sh bizda Legendary artifact bor deylik, yani birmuncha noyob va qimmatli bilim. Ho'sh, u bilan nimalar qila olamiz ? Toshmad oddiy JSchi uning iqsodiy ko'rsatkichlari va sotsial statusi Eshmatnikidan ancha yuqori. Ammo Eshmat computer sciencedan katta backgroundga ega va unda o'sha legendary artifactlar mavjud. Ammo Eshmatning sotsial statusi juda tor doirada, iqsodiy holati ham Toshmatchalik emas. Ammo ikkisi ham baxtli )) Ammo Toshmatning hayoti birmuncha qiziq va ma'noli korinadi. Sababi ko'p sayohatlar qiladi, turli eventlarga ko'p qatnashadi tinmaydi. Eshmat esa ertalabdan kechkacha qanaqadir kichkina kurugchalarda nimadirlar qilib yuradi. O'zicha nimadirlarni o'rganadi va birbalolar bilan doyim ovora va doyim vaqti yo'q. Hammaga ham qo'shilgisi kelmaydi, atrofdagilar uni kibrli deb o'ylaydi. To'g'rida, ahir Eshmatda legendary artifact mavjudku. Shu sabab unga o'zini levelidagilar qiziq. Yana Eshmat qanaqadir fantasik ko'rinadi, g'alati narsalar haqida o'ylab yuradi va juda g'alati narsalar qiladi. Lekin ikkisining ham xatolari mavjud. Toshmad: 1. Toshmada legendary artifactlar yo'q, shu sababdam kattaroq qiyinchiliklar bilan ishlash og'irlik qilishi mumkin. Va statistik jixatdan qaraganda xatolar kofitesenti juda yuqori. 2. Agar Toshmadda artifactlar tanqisligi yuzaga kelsa bu katta muammolarga sabab bo'lishi mumkin. Shu sababdan Toshmad ko'p narsalarni stabillashtirishni istaydi doyim. 3. Toshmad qimmatli artifaclarga erisha olmasligiga aynan statistic tomondan qaraladigan bo'lsa uning eng katta muammosi yangiliklar bilan ishlashni bilmasligida. Eshmat: 1. Eshmatda sotsial muammolar bor lekin faqat Eshmat shunaqa deb o'ylaydi. Yani menda juda ko'p sotsial muammolar bor ! Deb xisoblaydi. Shu sabab o'zini jamiyatdan izolyatsiya qilmoqchi bo'laveradi. 2. Eshmat doyim ham o'z potensialini to'laqonli namoyish qilolmaydi. Yani muhitga nisbatan adaptatsiya qilolmasligi tufayli boshqa muammolar bilan ovora bo'lib qolaveradi. O'z uslubini turli muhitlarga adaptatsiya qilolmaydi, shu sababdan qiyinchiliklar bilan ishlashda uning legendary artifactlari ham bazida yordam bermaydi. 3. Eshmatning eng katta xatosi artifactlarini umumiy deb o'ylashida. Shu sababdan Eshmat, yanayam ko'proq artifactlarga ega chiqishga intilaveradi bazida bu esa uni potensialini hayotga tadbiq qila olmaslikga olib kelishi mumkin. PS: Yana qanaqa fikrlar bor ?

Bu faqat ghcida ishlashini aytmabman. Agar fayl ichiga yozsangiz duplicateion error beradi. O'zi yetkazmoqchi bo'lganim biroz boshqacharoq edi va context biroz neto ketibti bu postda. Tog'rirogi exampleda asosiy muammo ) Shu sababdan sal boshqacharoq ko'rinishda qayta post qilaman qachondir. Bundan keyingi post comentida yaxshi suxbat bo'lgani uchun o'chirib tashalamadim. Report qilganlarga Rahmat ! Contextni yaxshi define qilolmaganim uchun esa uzr! )

Haskellda umuman boshqa narsa bo'ladi. Muammo esa quyidagicha. Bizda one degan funksiya bor deylik. function one() {} Endi huddi shu funksiya ichida o'z o'ziga call qilyabmiz

function one() {
  return one()
}

Juda ko'p strict tillarda bu callstack exeption bilan tugaydi. Haskellda esa infinity loopga aylanib qoladi. Lazy evanulation tufayli one ichidagi oziga bo'lgan call yani one = one to'liq execute bo'lishini kutib turaveradi. Haskellda variablelar ham immutable bu degani qayta qiymat assign qilolmaysiz. Ammo buyoqda laziness sabab one ohirigacha evanulation bo'lishini kutyabti. Bu degani cheksiz marotaba

one(one(one(one(one(....)))))

Haskell tabiati boshida ko'pchilikni confuse qilishi mumkin. Ammo biroz etiborli bo'lsangiz bu narsani tushunish juda oson.