PostgreSQL'da «Transaction» ishlatmaslik qachon muammo bo'ladi?

Tasavvur qiling, pul o'tkazish uchun 2 ta query bor:

UPDATE accounts
SET balance = balance - 100000
WHERE id = 1;

UPDATE accounts
SET balance = balance + 100000
WHERE id = 2;

Birinchi query ishladi, ikkinchisi esa xato berdi. Natijada:
❌ Pul 1-account'dan ketdi
❌ 2-account'ga tushmadi

Shuning uchun bog‘liq bir nechta operation'larni transaction ichida bajarish kerak:

BEGIN;

-- queries

COMMIT;

Xato bo‘lsa:

ROLLBACK;

Qoidasi: bir nechta query bir-birisiz ma'nosiz bo‘lsa — transaction ishlating.

👨‍💻 @MKhan404Lab

😣 Qachon kodni optimizatsiya qilish kerak?

Ba'zida kod yozishimiz bilan uni optimizatsiya qilishga tushamiz.
Lekin har doim ham bu kerak emas.

Optimallashtirish kerak bo‘ladigan holatlar:
— Kod real sekin ishlayotgan bo‘lsa
— Database query'lar ko‘p vaqt olayotgan bo‘lsa
— Server resurslari ortiqcha sarflanayotgan bo‘lsa
— Memory yoki CPU muammosi paydo bo‘lsa
— Performance monitoring muammo borligini ko‘rsatsa

Muhimi:

Avval ishlaydigan kod yozing, keyin kuzating, undan keyin optimizatsiya qilsak boladi.

Chunki taxminan optimizatsiya qilish — ba'zida muammoni hal qilmasdan, kodni faqat murakkablashtiradi.

👨‍💻 @MKhan404Lab

Clean Code haqida noto‘g‘ri tushunchalar

☹️ Kod qancha kam bo‘lsa, shuncha clean.
Kam kod har doim ham yaxshi kod emas.

☹️ Har bir funksiya 5-10 qatordan oshmasligi kerak.
Muhimi — funksiya tushunarli va bitta aniq vazifani bajarishi.

☹️ Har narsaga abstraction kerak.
Keraksiz abstraction kodni yanada murakkablashtiradi.

☹️ Clean Code = ko‘p design pattern.
Pattern maqsad emas. Muammoni hal qilish — maqsad.

☹️ Clean Code faqat naming.
Naming muhim, lekin architecture, coupling, complexity va maintainability ham muhim.

Maqsad — kodni boshqa dasturchi ham oson tushunishi, o‘zgartirishi va qo‘llab-quvvatlashi.

👨‍💻 @MKhan404Lab

🖥 SQL Injection haqida

SQL Injection — firibgar foydalanuvchi kiritadigan ma’lumot orqali SQL Queryning ishlash mantig‘ini o‘zgartirishga urinadigan hujum.

Masalan, foydalanuvchi bergan qiymat SQL Queryga to‘g‘ridan-to‘g‘ri qo‘shilsa, hujumchi undan foydalanishi mumkin.

Bu orqali:
— Ruxsatsiz ma’lumotlarni olish
— Ma’lumotlarni o‘zgartirish yoki o‘chirish
— Databasega zarar yetkazish
mumkin.

🛡 Qanday himoyalanish kerak?

User inputni SQL Queryga string sifatida qo‘shmang.

Buning o‘rniga:
— Prepared statements
— Parameterized queries
— ORM/query builder
— Input validation
ishlatiladi.

👨‍💻 @MKhan404Lab

Assalamu alaykum hammaga 👋

▶️ Youtube'ga 1-video tayyor bo'ldi

Tez orada linkini yuboraman 🔥

😣 Yangi loyihaga kirganizda, Kod yozishga shoshilmang...👇👇

https://youtube.com/shorts/QlhNwGNOU88?si=WZu_5eNycHyDgc1h

🤖 AI'ga kompyuteringizni to‘liq boshqarish huquqini bersangiz nima bo'ladi?

U sichqonchani harakatlantiradi, fayllarni ochadi, browserdan foydalanadi, terminalda command ishga tushiradi — xuddi sizdek.

Bu allaqachon AI agentlar rivojlanayotgan yo‘nalishlardan biri.

Masalan, “GitHub'dan projectni clone qil, ishga tushir, xatolarni top va tuzat.” deysiz.
Agent esa buni o‘zi bajarishga harakat qiladi.

Lekin, agentga juda katta permission bersangiz, u xato qilib faylni o‘chirishi, noto‘g‘ri command ishlatishi yoki maxfiy ma'lumotlarga kirishi mumkin.

AI agentlar kuchaygani sari permission, sandbox va security ham shunchalik muhim bo‘ladi.

Savol:
❓ AI'ga nimalar qilishga ruxsat berish kerak?

👨‍💻 @MKhan404Lab

🤖 Kompaniya o‘z mahsulotidan qo‘rqib ketishi mumkinmi?

3-sentabr kuni OpenAI Astra'ni chiqardi — 100,000+ GPU bilan o‘qitilgan yangi model.

Eng qizig‘i:
Astra OpenAI'ning “Critical” cybersecurity threshold'idan o‘tgan birinchi model. Ya’ni u nazariy jihatdan murakkab tizimlarga mustaqil cyberattack uyushtira oladi.

Ammo 3 kundan keyin OpenAI bosh olimi Jakub Pachocki:
“Hech qanday lab alignment va monitoringni hal qilmagan.” deb yozdi.

Ironiyasi?
Modelni yaratishdi. Kuchaytirishdi. Lekin uni to‘liq nazorat qilish hali ham muammo.

❓AI poygasi endi faqat “kim kuchliroq model yaratadi?” emas.
“Kim uni nazorat qila oladi?” — demoqda.

👨‍💻 @MKhan404Lab