Programming ∀

Bu mavzuda quyidagicha fikr paydo bo’lgan edi. Abstraksiya va aniqlik bir biriga zid narsalar emas. Qaytangi ikkisi bir birini to’ldiradigan uslublar. Agar aniqlikda biz chuqur detallarga etibor qilsak. Abstraksiya bilan detallarni chetga surib fikrlaymiz.

Interviewga kelgan candidatelarda CV da shunaqa narsalar bo'lsa. Mana sizga N % lik savol... deb gap boshlar edim

we are not friends anymore if you know certain “PERCENTAGE” amount of a language/technology

Eng qizig'i ham shundaki real worlda biz yozadigan code anchagina complexityga ega bo'lishi mumkin. Lekin hamma narsalar eng base narsalar ustiga qurilganiga. Biz functor ko'rinishida strukturalarni transofrm qilishni ko'rib chiqdik. Ammo biz hal etishimiz kerak bo'lgan muammolarning yechimlarida yana boshqacha narsalar ham kerak. Undan tashqari eng katta muammolardan biri bu I/O chunki bu yerda doyim side effects bo'ladi. Nimadir sal notog'ri bo'lsa biz yozgan dastur to'liq crash bo'lishi ham mumkin. Albatta I/O juda ko'pchiligimiz uchun kerak chunki real world I/O dan boshlanadi deyishadi. Ammo masala shunchalik muhim bo'lsa ham ko'pchilik birdan zinadan sakrab boshqa joylarga o'tlab ketadi yoki bunday narsalarni etiborsiz qoldiradi. Masalan yuqoridagi postlarda effect-ts misolidagi birqancha code examplelarni share qildim, etibor qilsangiz o'sha misollardagi o'xshashliklar nestjs yoki expressdagi codebaselarga mos keladi lekin asosiy paradigma effectar bilan ishlash. Effect ts da ham DI qilsangiz, layerlar bilan ishlasangiz bo'ladi, lekin paradigmaga moslab qilingan hammasi, bu esa traditsional nodejs frameworklardan va yechimlardan keskin farqlarga sabab bo'ladi. Shu o'rinda ko'rdingiz paradigmani yaxshi bilmaganlar codeni qanchalik kasha qilishi mumkinligini, albatta idiomatic wayni buzishdan boshlanadi. Lekin nima bo'lganda ham abstraksiya paradigmadan boshlanishi kerak deb o'ylayman va bu narsa tog'ri ekanini amaliyotda ko'rib kelmoqdaman.

Endi implementatsiyani ko'rishingiz mumkin. Yaxshilab etibor qilsangiz albatta savollar paydo bo'ladi. Lekin eng muhim joyi fmap hamma narsaga birxil ishlayotgani. Agar biz qoidani buzmasak abstraksiya bizga manashunaqa go'zalliklar beradi.

Ko'pchilik dasturchilar biror tilni o'rganib olishlari bilanoq arxitekturani o'rganishga yopishadilar. Lekin hammasi bunaqa abstraksiya bilan o'ylashga o'rganmagan odam mavzularni yoki umuman tushunmaydi yoki notog'ri tushunadi. Masalan oddiy CQRS masalasida - Begineerlar Command va Querylarni ajratsa bo'ldi deb o'ylashadi, undan tashqari esa conceptual exeptionlarga duch kelishadi. Masalan login qilish Command yoki Query ? CRUD qilib yurgan odam birdan Event sourcing qilishni boshlashi esa anchagina absurt narsa. Haa albatta "Distrobuted systems engineering" qolib ketmasin, qilgan loyihalarini shunchaki 3-4 qismga bo'lib tashlashadi complexity oshirishga, grpc, kafka va birqancha DBlar ishlatishadi. Kerak bo'lsa har bir servisni alohida tilda yozishsada. Lekin bir narsani tushunishmayabti, ular hali ham CRUD qilishyabti shunchaki o'zlarini qiynab ) Ha albatta bizda enterprays patternlar ham bor masalan DDD. Bu yerda ham bitta Entitiychani yasavolib undagi tiplarga class yasab model devolishadi. "DDD expert" larga anemic vs rich domain model farqini aytib berishini so'rasangiz makillab qoladi. Nega ? Sababi ular yaxshi yechim qilinadigan complexityda emas ekani. Chunki barbir o'sha o'sha crud faqat suniy ravishta o'zlariga qiyinlashtirganlar. Ular o'qiyotgan roadmaplari esa befoyda, chunki foydali resurslarni o'qishsa tushunishmaydi lame contentlarni o'qib esa tushundim deb o'ylab shunaqa masqarabozlik qilishadi )) Yuqoridagi narsalar maniyam boshimdan o'tgan va bu normal holat. Bir narsani yaxshi tushunib olishimiz kerak.

Abstract narsani aniq detallar bilan ifodalab bo'lmaydi. Chunki abstraksiya biror narsa haqida detallariga kirishmay fikr yurutishga qaratilgan.

Murakkab narsani soddalsahtirish doyim ham ish bermaydi. Bu huddi murakakb mexanizmli soatlardan juda ko'p detallarni olib tashlagandak gap. Abstraksiyani o'rganishni kichik abstraksiyalardan boshlash kerak. Masalan A tipga ega data structureni B tipga transform qilish kerak. Ammo strukturani buzmasdan faqat ichidagi tiplarni tansform qilish kerak. Bu nima beradi deysizmi ? Bu ham minimal abstraksiyaning ko'rinishi. Oddiy misol sizda integrers list bor, shuni list of Chars qilish kerak. [1,2,3] -> ['1','2','3'] Manashunda A -> B transform bo'ldi. Endi bunaqa ideyani har qanday ko'rinishdagi strukturaga tadbiq qilishingiz mumkin. Masalan Tree, Vector va yana boshqa tiplar. Endi shu funksiyani hammaga mos keladigan qilib nomlab olamiz masalan fmap deymiz yani flatMap. Endi shuni turli strukturalarga apply qilsak biz tree yoki listni fmap qilganimizda birxil ishlaydi. To'gri detallarda yani implementatsiya farqli bo'lishi mumkin lekin biz strukturani buzmasdan ichidagi tiplarnigina transform qilishni taminlay olamiz.

Effect-tsdan example projectlar ko'plarida turli xatoliklar bor, boshqacha aytganda bilinadi avtorlar skill issuelari, bir qasasa api interfeyslar notog'ri bo'lsa bir qarasa yana C like procedurelarga o'tib ketishgani, hullas ko'p qo'rqinchili narsalarga duch kelyabman. Effect-ts docsda ko'p narsa zo'r yozilgan tushuntirilgan, lekin examplelar doyim ham yaxshi emas. Boshqacha aytganda instrument takoy bo'lsa ham trash code yozish mumkin. Shu sababdan skill issuelaringizni yopish haqida qattiq qayg'uring.

Ikkisi ham legal )) Lekin shu syntax noise uje jonga tegib ketdi birpasta. Option tipgani ko'pchilik if bilan qiladi, shunaqa narsani doyim ko'rganman, rustda ham beginnerlar if yozib o'tirishadi. Lekin match ancha qulay ishonavering, faqat jsda pattern matching yo'q shunga match degan funksiya qilingan. Lekin shunda ham ancha qulayliklar ko'p lekin limitlar ham ko'p tiplarda va yana boshqa narsalarda. Lekin kodni birinchi ko'rgan odam biroz chalg'ib tushunmay qoladi sababi esa shu syntax noise ko'pligi va hamma narsa effect-ts idiomaticsda qilingani. Xozir aynan bir kishiga tushuntirib o'tiribman.

Bunisi kulgili lekin 🌚 Boshida servantga o'xshagan ideyani qilishibti deb o'ylabman kegin bilsam prosto enum ekan. Ikkinchi rasmda esa servantdagi misol.

Bu yerdagi ideya ham qiziq ekan, aynan routing o'zida o'rab aniq qilib qo'ygan qanaqa responselar qaytishini. Masalan expresschilar buni tushunishi ancha oson ))

Kelajakda taksis akalar oldin dasturchi bo’lgani haqida aytib berishsa bu haqiqat bo’lishi mumkin.

Bonusga flake qivorilsa shakalat bo’ladi. Faqat past so’rtli shakalat. Oliy navlisi kerak bo’lsa ZIOda qilish kerak edi🥹

Perfomance deysizmi ? Common nigga ! Script tilda backend yozishga uyalmagan odam perfomancedan uyalmaydi 🐎🛁 bosing

Hullas FP yozyotganizniyam farqiga bormaysiz. Nimani qayerga yozay nima qilay nimani o'rganay qanaqasi tog'ri degan savollarsiz Doc o'qib bosaverasiz. Nestjs kabi hoosh DIni qanaqa qilsam kean deb siqilmasdan Layerlarni yopishtirib tashlaysiz tamam. Nima qilasizlar o'zingizni qiynab, tiplar bor biroz xatla bo'lsa ham yomon emas. Nodejsdagi molxonalar uncha sezilmaydi chunki hammasi effectga o'ralgan yoki o'zingiz o'raysiz. Focus asosiy logicda bo'ladi, bir joyga promis qilib hamma call chaini async qilib kegin big refactoring deb commitlar qilmasdan bemalol coffechani qo'yvolib erkakchasiga kod yozasiz.

Mana default setupcha. Fifftillion biblatekalardagi bitta funksiyani ishlataman demasiz. Realworldni effectga o'raymizda yashayveramiz. AI generatorlarda yozsangiz ham bo'louradi yana bilmadim. Lekin nestjs daka krinj DIlar qilib o'timasdan bosaverasiz.

choq, choq hammasi tayyor 30 minutda.

Man bera oladigan yagona по-братски maslxat: Do your own research NIGGA !

Mazzami ? Nodejs builtin sqlite bilan maqtaniyotgan bir davirda. Effect-ts ichiga kuberni tiqvoryabti. Nestjslarni esa bilmadim manimcha yangi decorator yozishyabti IOC uchun. Effect contributorlariga hurmatim shuki ular rostdan ham ZIOni js ekotizimiga olib kirishga qattiq harakat qilishyabti. 1 yil ichida akalar ancha narsalarda progress qivorishdi. Lekin jschi sifatida ayta olamanki js ekotizimida sanoqli bo'lgan tayinli narsalardan biri bu effect-ts. Promislardan qutilishni eplashdi ! Real world bilan ishlashni esa ancha oson va default js approachlardan ancha aqilli qilishdi. Nima bo'lsa ham respect. Eslayman daje o'tgan yili ham ancha narsalar stabil emas edi, platform issuelar bor edi, anchasini eplashdi. Hullas effect-tsga yetib olish uchun undan yaxshiroq effect system qilmasa hali beri ancha bor. Oddiy loggerdan fibergacha shardingacha yozib chiqishgan uje katta extimol bilan actor-model patternga xarakat boshlashganov. Pm2 kabi molxonalardan ham qutilishadi hali.

Effect-ts 2049 yilda yashayabti. https://effect-ts.github.io/effect/docs/cluster

Anonimlik imkonsiz bo'lib borgani sari ko'p shaxsiyatlilik rivojlanyabti.