Programming ∀

Yana bazi narsalarni yetkazib qo'ymoqchiman. Ko’p qiziq narsalarni tanishlar turli qiziq community va resurslardan olaman yoki olganman. Kanalni maqsadi ham aynan shunaqa narsalarni boshqalarga ham ulashish. Darslik, maqola yana ko’p narsalarni sinab ko’rganman. Ammo xozircha ikki tomonga foydali narsa aynan shu uslub deb bilaman. Uslub va trolling masalasida ham masalan manga doyim ham yoqmaydi doyimiy formallik yoki ideallik. Bazida o'ta formal qilingan contentlar zerikarli ko'rinadi, shu sababdan bunga doyim ham amal qilgim kelmaydi. Fikrlaganimdak bayon qilishga xarakat qilaman. Tog'ri content saviyasi kabi narsalar ham bor, lekin masalaga biroz real qarasak ITda saviyamiz yaxshigina past shunga qanaqadir chiroyli qadoqlangan trashdan ko'ra boricha ulashish afzal deb bilaman. Bazida fikrlarimga qarshi fikrlar ham shunaqa narsalar tufayli, chunki xayotda ham qarama qarshi nuqtadan qaraydigan odatim bor, bazida bu foydali bazida esa chalg'itadi. Bilaman kanaldagi sanoqli odam gap nima haqida ketayotganini tushunadi yoki feedback beradi. Bazilar umuman tushunmagan narsasiga boshqacha fikr bildirishadi. Maqsad hechkim tushunmaydigan narsalarni ulashib o'tirish emas. Bilmaganlarni ulashish, masalan manga zerikarli bo'ladi biror kanalda doyim man bilgan narsani ulashilsa yoki oldin ham bo'lgan mavzular qaytalanaversa shu sababdan juda ko'plab kanal yoki communitylardan chiqib ketganman chunki o'sish bo'lmaydi. O'zim yozgan hamma mavzuda ham katta bilimga ham ega emasman. Masalan FP yoki Haskell mavzularida ham mandan ko'proq narsa biladigan hamkasblar, uztozlar ko'p. Biror mavzuda aslida ular content qilsa juda zo'r, lekin ularda ham boshqacha maqsad, piroritetlar va uslublar. Hamma turli uslubda ma'lumot yetkazadi, muhimi ular shuni qilishi va qila olishi, qilishyabtimi ? ha qilishyabti Rahmat! Biror narsaga ularni majburlash masalsi ham xato sababi har kimning o'z rejasi va maqsadlari mavjud va bu normal holat, shu o'rinda ular ham jim turishmaydi va hechnimani berkitishmaydi. Hamma biror nima qilishidan o'ziga yarasha maqsad va motivi bor. Manda ham shunday, kanalning g'oyasi o'z nomi bilan "Dasturlash hamma uchun" lekin bilamizki hamma ham dasturchi bo'la olmaydi bu esa normal holat. Kanaldan maqsad esa manashu yaxshiroq dasturchilikga targ'ib, chunki ko'p general narsalar deyarli hamma dasturchilar uchun muhim. Ammo mani o'zim hamma dasturlash sohalarini bilmayman bu ham dilema kabi albatta. Lekin turli uslublar, texnalogiyalar, sohalarda doyimo o'xshashliklar mavjud. Aytaylik kanaldagi odamlarni 4/1 qismi postlarni o'qiydi. Masalan ~300ta shu odamlarning 100/1 qismiga aniq yordam bersa ham man maqsadimga yetdim. Shunda qiziq savol keladi: Dasturlash hamma uchun, lekin ~1300 kishidan bor yog'i 3-4 kishi uchunmi content ? Javob: Yo'q content hamma uchun. Lekin hechkimni o'zgartirishga qaratilmagan va shunaqangi statistikaga rozi bo'lgan holatda kanal ishlab turibti va bunday ko'rsatkich xozircha mani qoniqtiradi. Lekin bilamanki bu narsalar ham qachondir aktualligini yoqotadi, lekin xozir aktual ! - Bular bunaqa natijaga arziydimi? - Ha arziydi, yo'q narsadan ko'ra arziydi va mani vaqt sariflashimga ham mos keladi.

Kanalni maqsadi pul topish emas, bloggerlik ham emas. Shunchaki fikr va tajribalarimni ulashish va tekinga. Bu masala biror kimdan pul yoki boshqa narsa so’ramganman. So’rashga extiyojim ham yo’q. Lekin telegram o’zi reklama tiqyabti, man o’zim ham bu reklamalarga qarshiman. Kanal public va ma’lum darajada obunachilar bor ekani esa vaziyatni yana o’zgartiradi. Hammasini ochirib tashlasam ham manga farqi bo’lmaydi. Lekin kimgadir kanal orqali foydam tegsa, ayniqsa shu ta’lim masalasida foydali bo’lsa doyim hursand bo’laman. Telegram reklamalari esa tradeoff, manga bulardan keladigan pul kerak ham emas lekin ochira olmayabman. Manimcha hammaga mos yechim shu reklamalarga etibor qilmaslik. Man o’zim bilib reklama qo’yayotganim yo’q ahir telegram o’zi chiqaryabti. Boost sotib olishga ham urinib ko’rdim ammo bizni auditoriya soniga nisbatan qimmatroq keldi, yomon tomoni esa buni doyimiy yangilash. Agar bu masalani to’laqonli hal eta oladigan odamlar bo’lsa marhamat bilganlarizni ulashing. Lekin manimcha hammamizga mos yechim reklamalarni ignore qilish. Commentsda reklamani report qilyabsizlar va manam bilaman shunga nisbatan aytdim yuqoridagi gaplarni. Umuman olganda telegramdan boshqa narsalarga ko’chib ketish masalasi ancha oldin ko’tarilgan va biz bazi communitylarda sinab ham ko’rdik. Ammo adaptatsiya masalasida bizni regionlardagi insonlar juda konservativ qarashadi va bu masalalarda ko’p narsa standart bo’lib qolgan. Bu esa o’z o’zidan rivojlanishga tasir qiladi.

Bazilarda odat bor, tildan tilga texnalogiyadan texnalogiyaga sakrab yuraveradigan. Lekin hech birini tayinli bilmaydi. Ularning eng katta xatolari o'zlarini aldashadi: 1. Masalan default pitonchi va rustni boshladi, aytaylik ownershiplardan ham amallab o'tib oldi. Lekin biror loyihalarad qatnashmasdan CVga rust qo'shib oladi. 2. O'sha pitonchi rustda ham pitonda yozgandaka code yozadi. Optioni ifda tekshirish masalan. Hullas rust idiomaticsni umuman bilmaydi yoki tushunmaydi. 3. Study project tanlashda ham adashgan. Rustni ham CRUD qilib o'rgangan. Yana boshqa qalashib ketgan xatolar bor. Shu sababdan aniq maqsad bilan o'rganish va maqsad o'zgarmasligi kerak. Shunda o'sha narsani issig'iga ham sovug'iga ham sabr qilib natijaga chiqiladi. Bo'lmasa yarim yo'lga kelmasdan tashlab ketiladi. Haskellni juda intuzyazm bilan boshlab, monadlarga bormasdan tashlab ketadiganlarning asosiy muammosi shu maqsadsizlik. Kegin yurishadi, haskell akademik til o'rganishga qiyin yana birnimalar deb. Lekin aka ketingiz chidamabtiku desangiz xafa bo'lishadi. Hulosa: 1. Maqsad bilan o'rganing 2. Idiomaticsga amal qiling va buni ham o'rganing. Huddi chet tilini o'rganish bilan ularning madaniyatini o'rgangan kabi, dasturlash tillari bilan ularning madaniyatini ham o'rganing. 3. Ko'proq code yozing.

Bunaqa narsalarga extiyoj sezmasangiz o'rganishdan manfat bo'lmaydi. Extiyoj sezish uchun esa yuqoridagi postlarda takidlaganimdan kichik abstraksiyalarni o'rganishdan boshlash kerak. Shu bilan birga testlar ko'p yozish kerak. Kegin tushuna boshlaysiz testlaringiz qayerdadir befoyda, aqli yetmayabti. Formal software design uchun oldin software designi bilish yoki tushunish kerak, SD esa yuqoridagi postlarda aytilganidak abstraksiyalardan iborat.

Practical Alloy A hands-on guide to formal software design https://practicalalloy.github.io/

Nega ekanini tushunmaganlar uchun shu threada yozilgan. https://stackoverflow.com/questions/1653340/differences-between-fork-and-exec

Manashu https://linux.die.net/man/3/execvp

Biz bilgan va sevgan nohubni prosto execvp() ga o’rab qo’yishgan ekan errorlarni handle qilib. Shu payitgacha daje nohubni notog’ri ishlatgan ekanman blyaaa alam qilyabti. https://github.com/coreutils/coreutils/blob/master/src/nohup.c#L217

Undan ko'ra docsga chiqmagan liblarni yozish kerak. API docsdan titkilab o'tirmasdan docsdan o'qib olinaveradi shunda begineerlarga ham oson. Expiremental apilarni to'g'irlash kerak. Stabilizatsiya qiliinsa yaxshi fichalar va osonlik bo'ladi ayniqsa platform wrapperlarda. Yo'q guys biz api liblar qo'shamiz ! Tipichniy js ekotizimi 😏

Wth maynavozchilik blyat, ai ga balo bormi. Shunga aytamanda jschilar odam bo'lmaydi deb.

Haskellistlarni elita deydiganlarni o’zi senior software engineer yozib olgan. Bu huddi qora tanlilar tomonidan oshirib yuborilgan anti natsizmga o’xshaydi.

Objectlarni cast qilib yoki bo'lmasa override qilib o'tirishni istamaganim uchun map funksiyalarni alohida nomladim. Bunaqa strukturani bemalol o'zingiz o'zgartirib olishingiz mumkin lekin transformation buzulmasa bo'lgani. Man adashib Listni array qivoribman (( Aslida linked list bo'lishi kerak edi. Arraydagi map ham juda yaxshi misol masalan 10 ta elementlik array oladi ichidagi itemlarni hohlaganicha trasnform qiladi lekin mapdan 10ta elementlik array qytadi )) Ideya juda sodda lekin usefull yani ko'p ishlatamiz ayniqsa container strukturalarda.

Yanayam tushunarli bo'lishi uchun TS misolida. Lekin noiselar bilan )) Lekin bir narsa qolib ketgan )). O'sha qolib ketgan narsani o'zingiz implement qilib ko'rsangiz ajoyib bo'ladi.

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.