Frontendda yarim soat bitta oddiy bugni debug qilib yurdim. Rasmni full viewda ochsam, o'ng tarafdagi arrow bilan "X" icon ko‘rinmay qolayapti.

Kodga qarayman — hammasi to‘g‘ri, ishlashi kerak. Refresh qilaman — ishlamaydi. Boshqa usul bilan yozib ko‘raman — baribir yo‘q. Arrow’ni boshqa joyga ko‘chiraman — ishlayapti. Qaytib o‘z joyiga qo‘yaman — yana yo‘q bo‘lib qolayapti.

Keyin qarasam, browserim macimi ekranida biroz o‘ngroqqa surilib qolgan ekan, shu uchun o‘ng tarafini bir qismi ekrandan tashqariga chiqib qolgan ekan 😅

OpenAI ChatGPTga study & learn mode qo'shdi. Endi AI savollarga birdaniga javob olmasdan, ketma-ketlikda, o'zingiz fikrlab javob olishga yordam beradi. Bunaqa applicationlar juda ko'p, lekin ChatGPT ni o'ziga qo'shishganiyam ancha qulay va yaxsh ibo'ldi.

https://x.com/OpenAI/status/1950240348695072934

Google matndan ma'lumotlarni yaxshiroq va kategoriyalashtirib extract qilish uchun qiziq open source library chiqardi. Ishlatib ko'rish kerak

https://x.com/googledevs/status/1950588788352380978

Real 🥶

GPT-5 allaqachon Cursorda

Hullas, konferensiyada ko'rsatishganidek one-prompt bilan simple application yasamoqchi bo'ldim, resulti 🥴 bop qoldi

Heytermasmanu, yana bitta overhyped modelmi dimanda🙂

Cursoram o'zini CLI yini chiqardi. Endi terminaldan yoki istalgan code editordan turib Cursorni ishlatish mumkin.

So much AI news this week🥱

gpt5 is insane💀

Dasturlashga yangi kirib kelgan dasturchilardan texnik intervyularda eng ko'p so'raladigan savollardan biri: "URL qanday komponentlardan tashkil topgan?"

Shu savolga javob

Backend dasturchi sifatida resurslarni boshqarish va CPU yuklanishini kuzatib borish muhim hisoblanadi. Menimcha, ko‘pchilik o‘z dasturida CPU 100% ga chiqib ketish holatini kuzatgan.

Quyida dasturchilar orasida CPU yuklamasini oshirib yuborishda eng keng tarqalgan xatoliklarni yozib chiqdim:

- Infinite Loops
Ko'pchilik qilib ko'rgan xato bo'lsa kerak. while(true) yoki for loopni ichida qandaydir mantiqiy xato bo'lsa (faulty loop condition deyiladi) kod bloki hech qachon to'xtamaydi. Natijada bitta thread protsessorni to'liq egallab oladi.

- Background Processes yoki Daemons
Siz yozgan kod ichidagi cron job lar yoki message queue worker lar va shunga o'xshash fonda ishlaydigan servislar notog'ri implementatsiya qilingan bo'lsa ko'p hollarda resurslarni ko'p istem qilib yuboradi.

- High Traffic Volume yoki Load Spikes
Bu ham backendchilarni og'riqli nuqtalaridan biri. Kutilmagan trafik oqimi, requestlar sonini keskin ko'payib ketishiga olib keladi. Agar load balancer yoki auto-scaling tog'ri sozlanmagan bo'lsa, serverlarni qulatib qo'yishi mumkin

- Resource-Intensive Applications
Data Science (katta dataset lar tahlil), ML (model training), video encoding/decoding yoki qanaqadir murakkab simulations lar ishlashiyam yaxshigina CPU resurslarini talab qiladi. Bu yerda ko'pincha algoritmik optimizatsiya ham muhim rol o'ynaydi.

- Insufficient Memory (RAM) yoki Thrashing
RAM yetishmaganda OS swapping yoki paging ga o'tadi - ya'ni, ma'lumotlarni RAM va disk o'rtasida almashtirishni boshladi. Bu tufayli I/O operatsiyalari protsessorga haddan tashqari ko'p yuklama beradi va tizim thrashing holatiga tushib qoladi.

- Concurrent Processes yoki Thread Contention
Ko'p threadli (multithreaded) ilovalarda thread'lar bir xil resurs (shared resource) uchun kurashganda race condition yoki deadlock'lar yuzaga kelishi mumkin. Resursni kutish yoki doimiy context switching CPU yuklamasini oshiradi.

- Busy Waiting / Spinlock
Bu codingdagi anti-patternlardan biri. Thread biror resurs bo'shashini sleep() yoki wait() qilish o'rniga, loop ichida doimiy tekshirib turadi (while (!resource_is_ready) {}). Bu protsessor vaqtini behuda sarflaydi. Yaxshi alternativa: semaphores, mutexes, event listeners.

- RegEx Matching & Catastrophic Backtracking
Yomon yozilgan RegEx pattern'lari (inefficient regex patterns) va greedy quantifiers (*, +) tufayli engine juda ko'p backtracking operatsiyalarini bajarishi mumkin. Bu eksponensial vaqt talab qiladi, shu sababdan CPU ishlashi ortib ketishi mumkin.

- Viruses & Malware (Cryptojacking)
Eng xavflisi. Sizning serveringiz yoki kompyuteringiz resurslaridan ruxsatsiz foydalanib, orqa fonda cryptojacking (mayning) skriptlarini ishga tushirishi mumkin. Bunaqa viruslar ko'p holatlarda npm/pip packagelarini ichida bo'ladi.

Ko'p terminlarni ataylab o'z tilida yozib kettim, mustaqil search qilib o'rganishga oson bo'ladi.

@mabrur_dev

Agar siz Junior Backend dasturchi bo'lsangiz eng kamida mana shu AWS yoki boshqa alternativ Cloud servislarini bilishingiz shart

Menimcha shu top-6 servislar deyarli hamma joyda so'raladiganlari: IAM, EC2, Lambda, S3, RDS, VPC

Ro'yxatga yana nimalarni qo'shgan bo'lardingiz?

@mabrur_dev

Bir so’m puliz bormi, ikki so’m puliz bormi educative dan subscription sotib olib o’rganishni maslahat beraman. Kurslari odatiy videodarslardan farqli, ko’proq mustaqil bo’lishni talab qiladi, ikki martalik obed puliga bir dunyo bilimga access ochiladi

Tasavvur qiling to'lov tizimi uchun system design qilyapsiz.

To'lovlarni amalga oshirishdagi eng jiddiy muammolardan biri - mijozdan ikki marta pul yechib olmaslik.

Bu narsani oldini olish uchun nima yechim qilgan bo'lardingiz?

Xatomi, yo’qmi javob beravering. Xato bo’lsa o’rganasiz, to’g’ri bo’lsa o’rgatasiz.

Uyda ishlashdan ko’ra ofisda ishlash ko’proq yoqadi, nimaga deb o’ylaysiz?

Tepada kimdir boshda yong’oq chaqqandek qilib perforatorini aylantirib o’tirmaydi.
Tinch atmosfera, hamma ishlab o’tirgani ishlashga fokus jamlashga yordam beradi.

Eng muhimi 10 da kelib 6 da ketolasiz va uyga borib ish haqida butunlay unutasiz.

Remote ishlashni eng katta minuslari, huddi siz 24 soat ishlayotgandek tuyulasiz. Ertalab turibam kompyuterni ochib kod yozasiz, kechasi taskimni tugatishim kerak deb bezovta bo’libam kod yozasiz. Hullas, yaxshi manage qilib olmagan bo’sangiz, remote ishlash qiyinlashib ketadi.

Bu hozirgi vaqtdagi, hozirgi vaziyatdan kelib chiqqan fikrlarim, ba’zida remote ishlardayam shunaqa chill paytlar keladi, taskni yopib qo’yib bemalol yuraverasiz.

Katta Loyihalar Siri: Database Middleware

Hech o'ylab ko'rganmisiz, dasturingizga millionlab foydalanuvchilar oqib kirdi, DBingizga so'rovlar soni keskin ko'tarilib ketdi. Natijada dasturingiz sekin ishlayapti. CPU, RAM va diskingizdagi IO juda ko'tarilib ketgan. Bazangiz qulab tushdi, endi butun servisingiz to'xtab qoldi.
Nega Amazon, Netflixlar o'tirib qolmayapti, ularning ham million foydalanuvchisi borku, deyapsiz.

Gap shundaki, ularning barcha so'rovlari bitta joyga yuborilmaydi va bitta baza hamma ishni bajarmaydi. Ular odatda bazaga yuklamani (load) taqsimlashadi.

Asosiy Muammo: Write vs. Read

Baza bilan ishlashda ikki turdagi operatsiya bor:
Write: Yangi ma'lumot qo'shish, mavjud ma'lumotni o'zgartirish yoki o'chirish. Masalan, buyurtma berish, profilni yangilash, nimadirni o'zgartirish. Bu operatsiyalar bazaning ishlashiga kuchliroq ta'sir qiladi.

Read: Ma'lumotlarni shunchaki ko'rish. Masalan, mahsulot ro'yxatini yoki buyurtmalar tarixini ko'rish. Odatda, dasturlarda "Read" so'rovlari "Write" so'rovlaridan ancha ko'p bo'ladi.

Bitta bazaga ham "write", ham "read" so'rovlari kelaversa, baza ikkita vazifani birdan bajarishga qiynaladi va sekinlashadi. Bu xuddi soat 19:00 da Havasga kirsangiz, kassada bitta kassir ham mahsulotlarni skanerdan o'tkazishi, ham borib tovarlarni sortirovka qip kelishi, ham narxlar haqidagi savollarga javob berib o'tirishga ulgurmay qolganiga o'xshaydi.

Yechim: Read Replica Pattern

Bunday muammoni hal qilish uchun odatda Read Replica modelidan foydalaniladi.

Primary DB: Asosiy baza faqatgina "write" operatsiyalari uchun ajratiladi. U "write" ishlari bilan band bo'ladi.

Secondary DB (Replica): Asosiy bazani nusxalarini saqlaydi. Ular faqat "read" operatsiyalari uchun xizmat qiladi.

Replikatsiya (Replication): Primary DBga yozilgan har qanday yangi ma'lumot avtomatik ravishda barcha Secondary DB'larga nusxalanadi.

Bu model loadni taqsimlanishiga moslangan. Write so'rovlari asosiy bazaga, minglab-millionlab bo'lgan Read so'rovlari endi nusxalangan bazalarga borishni boshlaydi.

Kodda, mijoz buyurtma bersa Primary DBga yoz, buyurtma tarixini yoki narxni ko'rmoqchi bo'lsa Secondary DBga to'g'irla deb chiqish juda noqulay va kodni murakkablashtiradi. Aynan shu yerda Database Middleware ishlatiladi.

U huddi agentga o'xshab, dasturingiz va bazalaringiz o'rtasida turadi. Dasturingiz endi faqat Middlewarega murojaat qiladi, u esa so'rov turini tahlil qilib avtomatik tarzda to'g'ri bazaga yo'naltiradi.

Misol uchun, buyurtma berish bu write so'rovi, middleware uni Primary DB ga yo'naltiradi. Buyurtma tarixini ko'rish bu read so'rovi. Middleware uni so'rovlari kam bo'lgan Secondary DBlardan biriga yo'naltiradi. Bu usul dastur kodini soddalashtirib, databaseni boshqarishni soddalashtiradi.

Lekin buni kamchiliklariyam bor:

Database Middlewarening o'zi ham alohida, murakkab tizim. Uni sozlash (configuration) va doimiy monitoring qilish kerak. Noto'g'ri sozlansa, butun tizim ishdan chiqishi mumkin.
Barcha baza so'rovlari middleware orqali o'tganligi sababli, agar u qulasa, barcha DB'ga ulanish to'xtaydi. Shuning uchun, uni high availabilitysini qilishga klaster qilib o'rnatilishi shart. Bu esa o'z-o'zidan qo'shimcha resurs va xarajat degani.

@mabrur_dev

Mayli, ertagacha🥱