Akhmad’s DB

Taxminan 6-7 yildan ko'proq muddat faqat Gnomedan foydalanibman 🙂 Endi esa KDE, hayotni yorqin tarafida bo'lay dedim )) NixOs bilan bo'lgan 2 kunlik jangu jadallardan so'ng, yaxshilab ujen qilib o'zimni xursand qilib piyoda yurib mana endi mazza qilib o'tiribman. Asosiy configlarim tugadi endi multi devicega moslashim kerak. Linuxga qaytish huddi vatanga qaytish kabi hissiyotlar bedi yuqori efariya 😁 Endi dasturlashdagi afsonalar rubrikasini davom qilsak bo'ladi.

China, mashina...

Kimdir boyidi kimdir o’sha o’sha holatda…

Хакеры массово взламывают аккаунты X и рекламируют токен $HACKED ИБ-специалисты заметили, что в социальной сети X (бывший Twitter) произошла волна взлома аккаунтов. Через скомпрометированные учетные записи хакеры рекламируют токен $HACKED на блокчейне Solana, который в итоге начал пользоваться популярностью. Читать полностью #xakep @linux_potok

Yana qanday shunaqa mifologik masalalar bor 🤔

FP uchun matematikani yaxshi bilish kerak

Ammo savol tug'uladi, matematika juda katta ocean. Aynan nimani bilish kerak ? Arifmetika ham matematika va buni bilish ham qandaydir matamatik bilim. Matematikaning sohalari va fieldlari biz tassavur qilgandan ham katta ekanini bilganmizda aniqroq gaplar aytishni o'rganamiz )) Sababi matematika hamma yerda bor va hamma joyga aralashgan. Hamma sohaning matematika qismi bor desak bo'ladi(Istesnolar bo'lishi mumkin). Qisqasi bizni oddiy hayotimizdagi ishlarda ham matamatik bilimlardan foydalanamiz. Demak matematikani yashab qolish uchun ham bilish kerak )) Endi mavzuga qaytamiz, lekin undan oldin JS/TS da birnecha yillik backend va ozgina muddatli frontend tajribamga ko'ra bemalol ayta olamanki, matematikaga shundoq ham ko'p ishim tushgan. Masalan frontenda custom turli componentlarni qilishimda ularni responsive qilishimda ham math kerak bo'lgan. Backenda esa yoki biror matematik conceptni bilmasdan shunchaki tadbiq qilganman yoki yo'l yo'lakay o'rganib ketganman. Qisqasi hayotim davomida matematikaga ichidagi fanlarga murojat qilganman bilib yoki bilmasdan. Aynan webgl da ishlaydigan leph0 oka ham matematikani bazi bo'limlarini o'rganganlar va haligacha o'rganadilar. Sizga xozir yuqorida aytib o'tilgan hamma domainda ham matematika bor ekanini tushuntirmoqchiman. Bazilarida asosan arifmetika yetsa yana bazilarida biroz ko'proq bilimlar kerak. FPga qaytamiz, yuqoridagilardan hulosa qilsak, agar Toshmat Haskellda backendchi bo'lmoqchi bo'lsa. Nima qilishi kerak. A. Agar Toshmat JS/TSni bilgan bo'lsa va shunda backend tajribasi bo'lsa. Haskell o'rganishi kerak. B. Agar Toshmatning birinchi o'rganayotgan tili Haskell bo'lsa, backend uchun keraki matematikani o'rganadi yo'l yo'lakay. Boshqacharoq aytaman, Toshmat uje backendchi faqat nodejs da backend yozadi. Ammo u Network, Database, OS bilimlarini ham o'zlashtirgan, chunki bularsiz normal backenchi bo'lish ham ertak )). Endi shu holatda Toshmat Haskellda backendchi bo'lish uchun yana qayta boshlaydimi hammasini ? Albatta yo'q, lekin Toshmat backendchi bo'lmoqchi bo'lsa unga faqat Nodejs, yoki Haskell yetarli deb hechkim ayta olmaydiku ! Qo'shib DB, OS, Networkni ham o'rganadi. Hulosa: Biz qaysi domainda ishlasak shunga tegishli matematikani o'rganamiz ! Kerak bo'lsa fizikani ham o'rganamiz, biologyni ham o'rganamiz. Chunki biz ishlaydigan domainda bular fundament ! Demak kimdir FPda backend yozmoqchi bo'lsa FP o'rganadi va backend uchun kerakli matematikani o'rganadi. Masalan dbdangi table ichidagi aynan biror qatorni olib kelish uchun yozilgan SQL query FP da ham OOP da ham boshqasida ham birixilku )) Hulosa pro max: Biz backendchi bo'lmoqchimiz, ammo eng mininmal holatda shu embedded DB SQLite ishlatib ko'ramiz. HTTP apilarimiz semantic bo'lishi uchun aynan shu protocolni o'rganamiz. Qaysi vakansiyada ko'rgansiz: Bizga faqat nodejs yoki Java yoki yana boshqasini biladigan engineer kerak deganini )) Shu sabab soha ma'lum sub sohalarga bo'lingan va shu subsohalar esa ma'lum domain va subdomainlarda farq qiladi. Masalan qanaqadir CRM uchun backend yozish bilan biror chat application uchun backend yozish umuman farqli ekani bizga ma'lum. Shunday ekan biz agar backendchi bo'lmoqchi bo'lsak, Databases, OS, Network kabi fundamental bilimlarga qo'shim matematik bilimlarni ham o'rganamiz. Endi savol, biz biror dasturlash tili yasamoqchimiz yoki aynan shu Compiler engineering domainda ketmoqchimiz. Matematika kerakmi ? Topdingiz albatta kerak, sababi hamma sohaning matematikasi bor ekanini yuqorida isbotladik. Unda nima qilamiz ? Qo'rqib tashlab ketamizmi ? Albatta yo'q ! yo'l yo'lakay davom qilaveramiz. Bilmaganimizni o'rganamiz. Agar biz ML engineer bo'lmoqchi bo'lsak ham aynan ML uchun kerakli narsalarni o'rganamiz !

Performance - implementationdan kelib chiqilib aytiladigan narsa. @keilambda

Odatda bir muammoga yechim izlab A. Boshqa muammolarga duch kelasiz. B. Boshqa muammolarga ham yechim topasiz. Manda aynan ikkinchisi, o'rganish davrida oldin bo'lgan juda ko'p muammolar yechimlariga duch kelyabman. Kegin ko'p narsani o'tirib analiz qila boshladim ya'ni man uchun nima ko'proq muhimligi va FP nimalarni taklif qilishi. Keyingisi esa umuman hamma uchun desak ham bo'ladi. Ammo bu aynan mani nazarimda shunday bu degani man xisobga olmagan narsalar ham bo'lishi mumkin. Perfomance - OO mavzularida izlanishlar davrida bir narsani tushungan edim. Hamma perfomance haqida gapiradi, ammo hechkim bunday code yozmaydi toki majbur bo'lmagunicha. Lekin perfomance qilish kerak ekan deb hechkim tech stackni o'zgartirib yuboravermaydi, buning uchun biror critical sabablar kerak. Shu o'rinda juda ko'p projectlar ham aynan codebase perfomance qilinmagan holatda ham ishlab kelyabti. Shunday ekan FPda perfomance neto deyish kabi izohlarni asossiz deb bilaman. Huddi shu gapni Immutable object oriented approach misolida ham aytgan edim. Simplicity - Soddalik man uchun eng muhim aspectlardan biri edi. Soddalik uchun man yozgan codeni boshqa hamkasbim tushunishi, o'zgartira olishi, feedback bera olishi kabi aspectlar ham muhim. Bunga bo'lgan urinishlarda juda ko'p qaramaqarshi fikrlar va hollywar chiqishi manga yoqmas edi. Yani yozilgan code hamma uchun intuitiv darajada bo'lishi ham aynan hollywarni kamaytiradi ammo bunga bo'lgan urinishlar complexity oshib ketishiga saba bo'lavergan. FP bu borada man hohlagan narsani bera oldi, chunki biror begona code bilan ishlar ekanman manga ham ancha tushunarli va man qilgan ish ham boshqalarga tushunarli. Xozircha kattaroq hajmda code yozib ko'rmadim ammo bunaqa fikrga kelishimga githubdagi turli repolarni titkilab chiqishim va o'zimcha o'zgartirib ko'rishlarim sabab bo'ldi. Yani projectda complexity bo'lsa ham codebaseda kamroq. Perfectionism - Perfectionismni hamma tanqid qilinsa ham bu hammada mavjud. Man programmingda ham perfectionis sifatida topa olganan compromise aynan FPda mavjud deb bilaman. Boshida qanchalik perfectionsmni ignore qilmay shunchalik talab oshib ketaverar edi. Xozir esa perfectionismdan kelib chiqgan etirozlar va tanqidlarim deyarli yo'q. Qayerdan ham bo'lsin ? Ahir oddiy conceptlardan tortib boshqasigacha hammasida boshqalar yetarlidan ko'p narsalarni tadbiq qilganku ayniqsa Haskellda. Paradigms and patterns - OO, imperativ programmingda aynan shu mavzuda doyim kuzatganlarim asosida shuni ayta olamanki doyim nimadir nimadirni inkor qiladi. OO programmerlar o'ylab topgan patternlari faqatgina qog'ozlarda deb aniq ayta olaman. GOF patternlarni o'rganamiz ammo miyanning qayeridarir chang bosib yotadi, huddi sarpo uchun yeg'ib qo'yilgan narsalarga o'xshaydi, undan olib foydalansa esa foydasidan zarari ko'p.

X singleton object ekan, threadlarga olib o'tsam singletoni o'zgartirish kerak bo'lyabti.

FPdagi conceptlar doyimiy ishlatilinadi. Siz biror asosiy conceptlardan birini o'rgandingizmi demak aniq siz ishlatasiz ! Yani siz qilmoqchi bo'lgan ishlarning yechimini topishga yoki yanayam yaxshiroq qilishga ham muhim concepltarni o'rganishiz kerak bo'ladi. FPdagi terminalogy bilan ham gaplashish juda oson. Mansalan man functor nima ekanini scalachidan ham haskellistdan ham so'rasam birxil javob beradi. Lekin bir oilaga mansub turli OO tillarda patternlarni implement qilishdagi farqlar bor ekani sabab til foydalanuvchilari boshqacha fikrga kelib qolganini eshitganmiz.

Qauality - Soddaroq aytsak FP da katta funksional o'z o'zidan scopelarga ajralib ketadi inuitiv darajada. Masalan tail recursion uchun helper function qilaman deysiz va heper alohida scope bo'ladi. Sizdagi logic esa ikkiga bo'linib qoladi. Bilasizki sizga loopdan ko'ra foydaliroq narsa bu recursion chunki hammasi bir biriga mos keladi. Strong va static typing kuchi bilan code o'z o'zini documentated qila oladi. Hamma joyga ham yana alohida context berib ketish shart emas. Biror joyda nima bo'layotganini ham type levelda ancha informationlar bo'ladi. Debugging masalasiga kelsak sizda oldin bo'lishi mumkin bo'lgan null pointer exeptionlar va yana boshqa bazi gemaroylar avvalidan oldi olingan. Hullas codebase ancha sifatli va ergonomik bo'lishi kafolatlangan ))

Miyyamdagi omborda SQL yotibti chang bosib…