Programming ∀

Non offical changelog 1. Toshkent cho'lga aylanishini bilib poytaxtda amma joylar cho'l kabi tasvirlangan. 2. Object detalizationga etibor qilingan 3. Yo'llarga etibor qilingan. Poytaxtda yo'llar tekkis :)

Poytaxt 2.0 is coming...

Uyqudan oldin svejiy info o’qish hammagayam emas. Wikida http2 haqidagi page update qilinibti 😃 https://en.m.wikipedia.org/wiki/HTTP/2 Haa azizlar oramizda http2 haqida endi eshitayotganlar ham bor 🥲

O’ylab qarasam matematikada faqat arifmetik mavzularda stuck bo’lib qolar ekanman. Algebra va abstractionni tushunish esa birmuncha oson negadir :) Oldin umuman mathni tushunmayman deb o’ylar edim bildimki arifmetikani tushunmas ekanman 😅

Endi shu masala yuzasidan refactoring qilamiz:

class UserIO {
  //...
  async find(name: string): Promise<User | null>

  async find(name: string): Promise<User | UserNotFoundError>
}

Burinchi exampleda nullable value qaytadi. Bu esa yomon dedik. Shu sabab birinchi hayolga kelgan uslub exeption qaytarish :) Birmuncha yaxshiroq uslub. Ammo try/catch ko’payadi. Ho’sh qanday refactor qilish mumkin ?

Spoiler…

Endi qiziq savol ? Nima uchun NULL yoki undefined bad practice yoki antipattern ?

Getter setterlarsiz hayot haqida. Ko’pchilik compositionlar haqida bilmaydi yoki murakkablik qiladi… https://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html

12. Paradigmlarga fanatism to’g’ri narsa emas. Bazilar ayan biror narsaga yopishib olishadi oqibatda faqat shu doirada fikrlay boshlashadi. Buning yomon tomoni agar biror fanatga aniq kuchli dalil keltirilsa qabul qilmaydi. Manashu narsa radikalizmga olib keladi. Manashu yana bir absurt masala… 13. Community tajribasiga qattiq ishoniladi… Masalan: Biror narsani tadbiq qilinayotganda aynan community qanday qilgan bo’lsa shuni copy paste qilinadi. Lekin ushbu amaliyot paradigmga teskari bo’lishi mumkin. Bunga misol qilib “OOP” dagi get/set ni misol qilsak bo’ladi :) Ushbu yechim formal OOP ideologyga mos emas. Ammo community tajribasi… Paradigmga nisbatan esa anti pattern.

Paradigmlar haqida qiziq hodisalarni kuzatdim. 1. Bazi paradigmlarga amal qiladiganlar mohiyatni tushunib emas balki shunchaki absurtlarni copy paste qilib ishlashadi. OOP haqida beriladigan ma'lumotlarni ko'plari aynan shu absurtlarga boy. 2. Paradigm paradoxlar mavjud. Ayniqsa traditional software engineeringda shunday. Yuqori bilim tajribali engineerlar jamoada kam yoki umuman yoqligi sababdan paradigmlarni buzishni paradox ko'rinishida amalga oshirishadi. — Business uchun ish tez bitishi kerak... — Biz hamma narsani murakkablashtirsak boshqalar tushunmay qoladi... 3. Paragmatical idealar asosi subyektiv fikrlardan kelib chiqadi. Lekin ma'lum formalism aspectlari orqali ushbu g'oyalar obyektivroq tus oladi. 4. Ko'p paradigmlar asosida Matematika bo'limlari yotadi. To'plamlar nazariyasi, Kategoriya nazariyasi, Lambda calculs, Calculs, Linear algebra. Bu yaxshi yoki yomon ekaniga aniq fikrlarim yo'q. Ammo matematik paradoxlar o'z o'zidan buyoqga ham aralashish extimoli bor. Lekin buyam shunchaki asossiz fikr. 5. Paradigmlar taqdim qiladigan yechimlar tomondan qaralganida juda ham o'xshash bo'ladi. Ammo yondoshuvlar farq qiladi. 6. General va specific paradigmlar mavjud. General paradigmlar o'ta complex va keng qamrovli bo'ladi. Specificlar asosan paradigm bo'limlari yoki kengaytirilgan yoki biror narsaga yo'naltirilgan ko'rinishda bo'ladi. 7. Paradigmlarni mix qilish masalan OOP va FP dagi bazi approachlarni qo'shib ishlatish bazida juda keng tarqalgan. Lekin mix qilish odatda katta prioritetizatsiya qilishga ham sabab bo'lishi mumkin. Sababi mixlardan boshqa side effectlar chiqmasligi uchun. 8. Aynan paragmatism tarafdorlari juda kichik jamiyat. Asosiy engineering jamiyatining taxminan maksimum 5-10% qismini tashkil qilsa kerak. Lekin shu torgina jamiyatlar ham juda ko'plab jamiyatchalarga bo'linib ketishgan. 9. Paradigmlar orasida aynan Functional programming jamiyati ancha active. Shu o'rinda adabiyotlar va resurslar ham juda ko'p xisoblanadi. Ammo mavzular asosan adavanced :) 10. Aynan biror paradigm oriented engineering uchun joblarda junior positionlar deyarli yo'q 😁

Muhammad Oka bir ajoyib kinoni tavsiya qilgan edilar. Kino nomi: A Beautiful Mind John Forbesh Nash islmi matematik haqida. Nash Game theory va yana matematikaning birqancha bo'limlarida researchalr qilgan. Nash qilgan ishlarning natijalari xozirda. Video games, economics, Cryptography va yan birqancha sohalarda amaliyotda qo'llanib kelyabti. Agar film ko'rish uchun yaxshi film topa olmayotgan bo'lsangiz albatta ko'ring.

Texnikani qimmatga sotib olamiz. Ammo tekinga datasetlar beramiz :) Linux ishlatish kerak desam ishonmaysizlar... Bugun Telefonimda olingan rasmlarni wallpaperga suggest qildi :) Bu hechnima emas deyishingiz mumkin ammo bu katta narsa...

Yaralangan Disk hamon ishlamoqda... Uyda bo'sh yotgan disklarim ichida alohida backuped-ubuntu degan diskni topib olgan edim. Birinchi laptopimdagi :) Kegin ichiga kirib qarasam 2 yil oldin ishga tushurgan containerim turibti 😁 Eng qiziq tomoni diskga hechnima bo'lmabti. OS va kernelni upgrade qilib yuborgan edim barcha configlarim bilan yangiday bo'ldi :) Qaytadan OS setup qilishga birnecha kun ketar edi vaqtdan ancha yutib qo'ydim :) O'sha davrlarda OSni backup qilib yurar edim. Sababi birnecha marotaba expirementlarda barcha narsamdan ayrilganman. Ayniqsa birqancha disklarni bag'ridan kechgan edim. Laptop esa pensiyaga chiqgan lekin disk haligacha navqiron shu joyi hayratga soldi 😁

Kompaniya bu insonlar ! Shunday fikrlar prosto ko'ngilni aynitadi :) Ko'pincha kompaniya madaniyati, qadiryatlari haqidagi safsatalar shunaqa absurtlardan boshlanadi :) Shu orqali emotsiyalaringizni jlovlashadi va qulog'ingizga yaxshilab tepishadi... Activitylar... Juda ko'plab kompaniyalar turli ko'rinishda g'alati activitylar va eventlar o'tkazishadi. Bundaylar orasida foydali yaxshilari ham bor albatta. Ammo bunday strategiya asosan tashqariga marketing bo'lib xizmat qiladi. Bu anchagina universal piar instrument hayiryadan torib qandaydir birnasa firendlylargacha... 1. Ishchilarni hunting qilish oson bo'ladi. Chunki odamning ko'ziga hamma narsa ideal va chiroyli ko'rinadi tashqaridan. 2. Investitsiya jalb qilishga katta foyda beradi :) Bu amaliyotning absurtligi shundaki ichkaridagi molhona tashqariga megopolis qilib ko'rsatiladi. Tili bor qo'li yo'q management. Bunday holatda barcha ishlar shunchaki hojako'rsinga qilinadi. Ozgina qilingan ishham bo'rttirib ko'rastilinadi. Managerlar esa faqat meetinglarda aralashib yuraveradi. Ularning ishlarini ham quyirodagi roledagilar yoki undan ham quyiroqdagilar qilishadi. Absurtligi shundaki managerlar umuman contextni tushunmaydi. Texnik bilimga ega bo'lgan managerlarga o'z ishlarni qildiradilar :) Meetingbozliklar - Ko'pchilik conversationlar olib borish ko'niklmalariga ega bo'lmaydilar. Insonlar bilan suxbatlashishni ham eplay olmaydilar. Shu sababdan biror context yuzasidan kerak bo'lsa soatlab yoki birnecha marotaba meetingbozlik qilishadi. Absurtlik shundaki ularning qanadydur yetishmayotgan skillarini deb boshqalar jabr ko'radi bekorga vaqt o'tadi. Top managment. Ha doyimgiday baliq boshidan sasiydi. Huddi shu gapga mos top managerlar tufayli juda absurt org structure quriladi. Juda sodda misoli grading tizimining umuman yo'q ekanini keltirsak bo'ladi. Masalan hodim growup qilmoqchi. Hosh bunga qanday yechimlar bor ? Nazarimda eng minimal holatda biror hodimni promote qilishga aloqador reglamentlar bo'lishi kerak. Masalan: Salom Mening ismim Toshmad, Xozirda X positionda ishlayman fa Y positionga levelup qilmoqchiman ! Shunday holatda eng minimal holatda. Y position descriptioni bo'lishi shart shu asosida aniq requirementlar qilinadi. Hodim loyiq bo'lsa promotion qilinadi bo'lmasa feedback. Masalan siz bu yilda N ta muammoni hal etibsiz. Ammo requiremetdagi asosiy punkt M muammoni hal etgan bo'lishlik sababi ushbu roleda muammolar ko'lami P ta bo'ladi. Shu o'rinda sizdagi Z ko'rsatkichlari pastroq chiqyabti. Ushbu kriteriyalargai muammolaringizni hal etib falon vaqtdan kegin qayta urinishingiz mumkin. Etibor qiling bu yerda complex ideal levleuplar haqida emas balki aniq talablar asosidagi oddiy leveluplarga etibor qaratildi. Kegin hodimni o'qitish o'qitmaslik haqida ham gapirmadim. Eng minimal ko'rinishni aytdim :) Davomi bor...

AT != Axborot texnalogiyalari AT == Anti Trash

Bugun so’ngi 1 yilda ko’rgan barcha absurtlarimni yozib chiqishni reja qildim 🙂

Officega hayvon olib keladiganlarni tushunmayman. Coworkinglarga ham olib kelishayotgan emish… Kompaniya madadaniyati… degan so’zni aytadiganlarni juda ko’plari o’z idishlarini yuvib qo’yishni eplay olmaydigan darajada befarosatligini ham ko’rdim. https://t.me/programming_everyone/1772

Puzzle bo'laklarini birma bir topayotganga o'xshayman... Type driven development degan ideani ko'rib huddi oltin topib olganday hursand bo'ldim :) https://idris2.readthedocs.io/en/latest/typedd/typedd.html#chapter-1 https://corecursive.com/006-type-driven-development-and-idris-with-edwin-brady/

Node Internals Keling bir boshidan boshlaymiz. Node cross-platform bo‘lgan runtime environment hisoblanadi. Sodda qilib tushuntirganda JavaScript kodni browserdan tashqarida ishlatishga yordam beradi. Nodening asosiy dependencylari V8 engine hamda Libuv hisoblanadi. V8 engine parser, garbage collector, interpreter, hamda JIT compiler kabi komponentlarni o‘z ichiga oladi. Biz uchun qiziq bo‘lgan asosiy komponentlari heap hamda stack hisoblanadi. Libuv nodedagi asynchronous I/Oga oid muammolarni hal etish uchun ishlab chiqilgan. O‘z ichiga event loop, tcp va udp socket, dns resolution, file system events, va thread pool kabi komponentlarni oladi. Nodening qolgan til va platformalardan farqi single thread, even-driven modeldan foydalanadi. Keling birinchi navbatda nima uchun ko‘p tillar multi-thread modelidan foydalanadi. Sababi process qandaydir I/O call qilganida, masalan bu network yoki hard drivega bo‘lishi mumkin, ma’lumot mavjud bo‘lgunga qadar bloklanish hosil bo‘ladi va buni alohida threadga yuklagan holatda qolgan ishlar boshqa threadlarda bajariladi. Odatda I/O bloklovchi bo‘ladi va bu data mavjud bo‘lmagunga qadar davom etadi. Lekin zamonaviy operatsion tizimlar non-blocking I/O mexanizmini qo‘llab quvvatlaydi. Bu usulda system callga ma’lumot o‘qishga tayyor bo‘lmasidan darrov javob qaytariladi. Masalan odatda Unix operatsion tizimlar fcntl() funksiyasini taqdim etadi. Bu funksiyani vazifasi network socketga access oluvchi file descriptorni non-blocking uslubga o‘tkazadi. Bu usulda agar o‘qish uchun ma’lumot mavjud bo‘lmasa read operatsiyalar EAGAIN bilan fail bo‘ladi. Bu narsani hal qilish uchun ba’zi patternlar bor. Masalan birinchi pattern, busy-waiting. Bunda resourceda ma’lumot mavjud bo‘lmagunga qadar loop orqali resource tekshirib turiladi. Bu methodni kamchiligi ma’lumot mavjud bo‘lmaguncha CPUni isrof qilib turadi. Keyingi usul Event Demultiplexing, zamonaviy operatsion tizimlar non-blocking resurslarni samarali boshqarish uslubini beradi. Bu narsa Synchronous Event Demultiplexer yoki Event Notification Interface deb ataladi. Bunda Synchronous Event Demultiplexer resourcelarni kuzatadi va execute bo‘lgan read yoki write operatsiyalar tugaganda yangi eventlar yaratadi. Keyin shu eventlar protsess qilinadi va aynan shu narsa Event Loop deb ataladi. Endi keling bu narsa qanday qilib single threadda ishlashini ko‘rib chiqamiz. Reactor pattern. Bu patterni qo‘llash orqali har bir I/O operatsiyasi o‘z handleriga (callback) ega bo‘lishiga erishish mumkin. Misol uchun 1 ta I/O requestini olaylik. Birinchi navbatda bu narsa Event Demultiplexerga resource, operation, handler ko‘rinishida topshiriladi. Qachonki Event Demultiplexerdagi biror bir operatsiya yakunlansa, Event Demultiplexer Event Queuega eventlarni yuboradi. Bu vaqtda Event Loop Event Queueni iteratsiya qiladi hamda biriktirilgan handlerni ishlatib yuboradi va yakunlangach handler kontrolni yana Event Loopga qaytaradi. Event Queuedagi hamma eventlar process qilingandan so‘ng bloklanadi va yangi event kelishi bilan keyingi cycle boshlanadi. Har bir operatsion tizim o‘zining Event Demultiplexer Inferfacega ega. Misol uchun linuxda epoll, macOSda kqueue. Bu inconsistencylarni oldini olish uchun NodeJS core team Libuvni ishlab chiqqan. Aynan Libvu yuqorida aytib o‘tilgan ishlarni o‘z zimmasiga oladi. Node single theadedmi yoki multi-threaded. Aslida node multi-thread hisoblanadi. Sababi Libuv main threaddan tashqari default 4 ta thead yaratadi. Buning sababi operatsion tizimlarida ba’zi I/O operatsiyalar non-blocking xususiyatinini qo‘llab quvvatlamaydi va buni simulate qilish uchun boshqa threadlardan foydalanadi. Bundan tashqari multi-threading va multi-process modellari ham taqdim etilgan. Misol uchun child_process module orqali child protsesslar yaratishimiz mumkin. Yoki child_processdan lightweight bo‘lgan worker_threads moduledan multi threading uchun foydalanishimiz mumkin.