Bugun olx.uz da tozalash(uborka) kunimi deyman, sayti ertalabdan ishlamayapti. CloudFront ni noto’g’ri sozlab qo’yganga o’xshaydi

P.S. Oxirgi vaqtlar olx da juda ko’p shunga o’xshash muammolar bo’lyapti.
Bu xatolik nimadan bo’lishi mumkin?

Pyramid nomli Python frameworki bor, O’zbekistonda unchalik ham mashhurlikka erisholmagan bo’lsada, aslida ancha qulay va ko’p imkoniyatli freymvork hisoblanadi.

Django battery-included (hammasi ichida) freymvork bo’lsa, Pyramid minimalistik freymvork hisoblanadi. Kerakli komponentlar ehtiyojga qarab tanlanadi. Django shunday freymvorkki siz unga moslashishingiz kerak, Pyramid esa sizga moslashadi.

Misol uchun django da ma’lumotlar bazasi bilan ishlash uchun o’zini tayyor ORM bilan ishlashga majbursiz (istisnolar bor), Pyramidda istasangiz SqlAlchemy, istasangiz Pony ORM yoki boshqasini ishlataverasiz.

Python uchun veb freymvorklar juda ko’p, hammasini tagida bitta maqsad yotadi, u ham bo’lsa dasturchiga qulaylik yaratish. Barcha freymvorklarda requestlarni boshqarish, URL routing, database bilan ishlash(CRUD) kabi asosiy vazifalarni o’z ichiga olgan.

Siz ham xuddi shu vazifalarni o’z ichiga olgan freymvorkni o’zingiz Python yordamida yozishingiz mumkin. Mustaqil freymvork yozmoqchi bo’lsangiz Jakhongir Rakhmonov ni “Pythonda veb framework yozish” kursini tavsiya qilaman.

Pyramid code example

Pyramid freymvorkida GET va POST metodlarini ishlatishga misol

Bu odam nima xohlayotganini asl maqsadi nima ekanligini kimdir tushuntirib bera oladimi?

Yuborgan bot linkini hali start qilmadim, qilaveraymi 😅

P.S. Chat egasini ismi ko’rinmasin deb uchirib qo’ydim

Connection Pooling Pgbouncer nima?

Assalamu Aleykum azizlar!. Men Mukhammad Irmatov postlaridan kelib chiqib Pgbouncer haqida qisqacha ma'lumot berib o'tmoqchi edim.

Yuqoridagi postda aytib o'tilganidak Postrgesql har bir kiruvchi client request uchun connection yaratadi. Har bir connection uchun serverdan joy ajratiladi. Qarabsizki 100ta request va 100ta connection, bundan kelib chiqadiki resource to'ladi va PostgreSQL resourlar to'lguncha request larga connection ochib klientlarga javob bera oladi. Bu model Client-Server arxitekturasi deb nomlanadi, albatta sekin, effektivniy hisoblanmaydi. Shuning uchun Connection pool bizga yordam beradi. Bunga bitta misol PostgreSQL uchun albatta PgBouncer.

Pgbouncer bu Connection pool ga javob beruvchi, klient va DB o'rtasida turuvchi middleware protses hisoblanadi. Mijoz Pgbouncerga ulanadi va bir vaqtda pgbouncer DBga ulanadi. Pgbouncer o'ziga katta miqdorda connection so'rovlarni qabul qiladi va pooling yordamida bazaga bo'lgan haqiqiy connectionlarni kamaytiradi. Bunda http requestlarimiz tez ishlashni ham boshlaydi. Sababi har bir kiruvchi http request uchun yangi haqiqy connection ochilmaydi va yopilmaydi, CPU va Memorydan joy ajratilmaydi, bundan kelib chiqadiki baza requestlarni avvalgi holatiga qaraganda tezroq handling qiladi.

PgBouncerni 3 turdagi pool_mode mavjud.
Bular:
1. Session - mijoz sessiyani uzgandan so'ng connection poolga qaytarib beriladi.
2. Transaction - har bir tugatilgan transactiondan so'ng connection poolga qaytadi.
3. Statement - har bir sql so'rovdan so'ng connection poolga qaytadi.

Connection poolga qaytadi va boshqa kirib keluvchi requestlarga javob berishi mumkun bo'ladi. Ko'pgina hollarda Tranction pool_mode ishlatilish tavsiya beriladi.

A friend of mine is hiring a Chief Operating Officer (COO) for their AI-based micro SaaS startup. It’s a rare chance to lead and scale a cutting-edge company – with equity included! 🤩

Key requirements:
✅ Equity is shared!
✅ Full-time commitment
✅ Fluent in English & Russian
✅ Strong sales and leadership skills
✅ Experience with AI and SaaS is a big plus

Saas - Software as a Service.

If you or someone you know is interested, DM me for more details! 🚀

DM 👉 @muhammadali_salohiddinov

Bir do’stimiz AI asosidagi mikro SaaS startupiga Bosh operatsion direktor (COO) qidiryapti. Bu juda ham zo'r imkoniyat.🔥 Eng muhimi ulush (equity) taqdim etiladi! 🤩

Talablar:
✅ Ulush (equity) taqsimlanadi!
✅ To'liq ish vaqti
✅ Ingliz va rus tillarini yaxshi bilish
✅ Kuchli sotuv va rahbarlik ko'nikmalari
✅ AI va SaaS sohalarida tajriba afzallik hisoblanadi

Saas - Software as a Service.

Agar siz yoki tanishlaringiz qiziqsa, DM orqali murojaat qiling! 🚀

DM 👉 @muhammadali_salohiddinov

Help me help you

Dasturchilikda, va umuman boshqa sohalarda ham, tez o‘rganishning eng yaxshi usullaridan biri bu savollar so‘rash orqali. Ishxonadagi dasturchilardan, chat jipidi akadan, claude opadan, stockoverflowdan, mendan va boshqalardan savol so‘rash orqali tez va to‘g‘ri yo‘nalishda harakatlanish mumkin.

Shaxsan o‘zim va men bilgan ko‘pchilik yordam berishni chin dildan xohlaydi. Juda xursand ham bo‘ladi, agar yordam bera olsa. Lekin hech kim, qaytaraman hech kim, sizning ishingizni siz uchun qilib berishni xohlamaydi.

- Menga rezyume yozib bera olasizmi?

- Mana-bu ishni qila olmayapman, yordam bera olasizmi?

- Shu loyihaning arxitekturasini chizib bera olasizmi?

kabi savollar ochiqsachiga odamga yoqmaydi. Sababi bu va shunga o‘xshash savollarga to‘g‘ri va to‘liq javob berish uchun ancha bosh qotirish va vaqt sarflash talab qilinadi. Undan ham yomoni - savol berayotgan odam shu ishni qilishga yoki savolni to‘g‘ri yozishga erinayotganida.

Men ishda biror kishidan savol so‘rasam, odatda taxminan quyidagicha shaklda ifodalayman:

Salom Alexandro. Men loyihaning shu qismida bir muammoga duch kelyapman. Sen shu qismda juda ko‘p ishlar qilgan ekansan. Bilsang va yordam bera olsang zo‘r bo‘lar edi. Lekin agar boshqa odam yaxshiroq biladi deb o‘ylasang, iltimos o‘sha odamga meni jo‘natvor. Savolim: ‘Shu ishni qilmoqchiman. Uning uchun 3 ta yo‘ldan ketishim mumkin. 1 chisi bunaqa, 2 chisi shunaqa, 3 chisi esa munaqa. Menimcha 2 chi yo‘l eng zo‘ri, chunki shunday qilsam bunday bo‘ladi. Uni qilish mana bu yerda shunday o‘zgarish qilmoqchiman, lekin mana bunday xato chiqyapti. Bilasanmi, qayerda xato qilayotgan bo‘lishim mumkin?’

Mening maqsadim Alexandroga iloji boricha tez va to‘g‘ri javob bera olishi uchun sharoit yaratib berish. Butun contextni tushuntirib berish.

Umuman olganda birovdan nimanidir xohlasangiz, sizga u o‘sha narsani berishi uchun ishini osonlashtirishingiz kerak. Yana bitta misol. Odatda ishxonalarda promotion olishingiz uchun sizning manageringiz siz haqingizda report yozishi kerak va boshliqlarga siz promotionga arzishingizni isbotlab berishi kerak. Bu oson ish emas. Manageringiz siz qilgan ishlarni eslashi, aniq misollar berishi talab qilinadi. Siz manageringizga shu reportni yozib berish orqali katta yordam qilishingiz va promotion jarayonini ancha tezlashtirib berishingiz mumkin. Siz o‘zingiz nima ishlar qilganingizni manageringizdan yaxshiroq bilasiz har holda.

@jakhonrakhmonov

O’zbekistonda Python dasturchilarga ish yo’q, amaliyotga ham hech kim olmayapti degan gaplarni eshitib qolaman. O’tgan bir yil ichida, 5 dan ortiq junior dasturchilarga amaliyot o’tash imkoniyatini bergan bo’lsak, deyarli hammasi turli IT kompaniyalarda ishlab yurishibdi. Amaliyot davomida o’zimiz qanday loyihalarda ishlayotgan bo’lsak (pulseev.uz, mockexam.uz, mohirlar.uz, mohirpool), ular ham biz bilan birga o’sha loyihalarda ishlashdi, tajriba orttirishdi.

Amaliyotchi olish, ularga mentorlik qilish va ular bilan loyihalarda birga ishlash shaxsiy tashabbus bo’lib, kimgadir ozgina bo’lsa ham dasturchi sifatida o’sish uchun yordam berish xolos. Amaliyotchilardan ba’zi kompaniyalarga o’xshab 2-3 mln so’m amaliyot o’tash xarajatlari uchun deb pul olmaymiz yoki o’zimizdagi taniqli xalqaro kompaniyalarga o’xshab 3-4 mln so’m pul ham berolmaymiz, to’g’ri tushunish kerak. Ularga maosh taklif qiladigan vaqtlarga ham yetamiz, nasib.

Har doim amaliyotchi olish e’lonini qo’yganimda, doim kimlardir norozi, nimadirlar deb ichidagi alamlarini chiqarib olgisi keladi. To’g’ri tushunish kerak, bitta amaliyotchiga katta loyiha topshirib, tugattirib olish uyoqda tursin, bir o’ziga loyihalar topshirib qo’yilmaydi, doimo u bilan birga darajasi yuqori dasturchi ishlashi, mentorlik qilish talab qilinadi, busiz iloji yo’q. Odamlar o’ylagani kabi, loyihalarni ularga qildirib olib, ketkazib yubormaymiz. Deyarli hamma amaliyotchilarga, amaliyot tugagach ish taklifi berilgan.

O’ylantirayotgan jihati, biz amaliyotchilarga imkoniyat berib xato ish qilyapmizmi, buni to’xtatishimiz kerakmi shunda?

Backendchi Deploymentni Bilishi Kerakmi?

Yaqin-yaqingacha backendchi uchun deploymentni bilish shart emas deb o‘ylardim. Chunki oldingi ish joylarimda kamida 2-3 ta DevOps dasturchi bo‘lar edi va bu ishlarni ular bajarardi. Backendchi sifatida kod yozaman, API larni tayyorlayman, qolgani esa DevOps'ning ishi – CI/CD, serverlarni sozlash, security va deployment kabi ishlar ularga tegishli deb hisoblar edim. Bu fikrim 1-1.5 yildan beri teskarisiga o’zgargan.

Oxirgi 2-3 kun ichida Digital Ocean serveriga React ilovasini o‘zim deploy qilib ko‘rdim. Oldin faqat backend applicationlarni deploy qilib, frontend deployment bilan umuman shug‘ullanmaganim uchun bu tajriba men uchun qiziq bo‘ldi. Dastlab Docker bilan build qilib, container'ni Digital Ocean Container registry'ga saqladim, keyin serverda uni pull qilib ishga tushirdim. Natijada deployment vaqti 8-10 daqiqagacha cho‘zildi.

Bundan samaraliroq usul kerak edi. Keyin React’ni shunchaki github actions yordamida build qilib, tayyor fayllarni /var/www/ katalogiga yuklab, Nginx konfiguratsiyasida root va index ni to‘g‘ri ko‘rsatdim. Natija ajoyib bo‘ldi – deployment vaqti 30-40 soniyagacha tushdi!

Biroq bu usulda bitta muammo bor edi: yangi build yuklanayotgan vaqtda eski fayllar ustiga yoziladi va shu orada server ishlamay qolishi mumkin. Zero-downtime qilish uchun CI/CD pipeline yozdim:
✅ Oxirgi 3 ta build saqlanadi – agar yangi buildda xatolik bo‘lsa, avtomatik rollback ishlaydi.
✅ Deployment muvaffaqiyatli o‘tsa, Telegram bot yordamida guruhga bildirishnoma boradi.

Agar sizga CI/CD qismi qiziq bo’lsa, bu linkka kirib jarayonni ko’rishingiz mumkin

Xulosa:
— Backendchi deploymentni bilishi kerak. DevOps mutaxassislaringiz bo‘lsa ham, real hayotda backend dasturchining ham deployment jarayonlarini tushunishi va ba’zan o‘zi bajarishi kerak bo‘lib qoladi
— Backend dasturchi har doim professional DevOps darajasida bilimga ega bo‘lishi shart emas, lekin hech bo‘lmasa basic deployment, Docker, CI/CD, server konfiguratsiyasi, loglarni ko‘rish va tahlil qilish kabilarni bilsa, ishi ancha osonlashadi.
— Har doim eng samarali usulni izlash kerak. Oddiy statik fayllarni container ichiga joylash o‘rniga, to‘g‘ridan-to‘g‘ri Nginx orqali serve qilish bir necha barobar tezroq ishlaydi.

Siz qanday deployment usullaridan foydalanasiz?

Ko‘pchiligimiz Django va Python backend'da "best practices" izlaymiz, lekin aslida, yomon amaliyotlar (anti-patternlar) dan qochish hammasidan ko’ra muhimroq. Masalan, CI pipeline umuman bo‘lmasligi, yoki aksincha, 30+ daqiqada test o‘tishi, PR merge qilish uchun butun jamoaning approve berishini kutish — bular jamoaning tezligini pasaytiradi. Gitflow branch strategiyasi esa Django monolit yoki microservice ishlatilayotgan loyihalarda ko‘p hollarda ortiqcha murakkablik olib keladi.

Kod yozishda ham ko‘p xatolar uchraydi. Hamma logikani bitta view ichida yozish – klassik anti-pattern. Django'da 10 ming qatorlik views.py yoki models.py yozish esa loyiha murakkabligini oshirib, kodni tushunib bo‘lmas holatga keltiradi. Keraksiz abstraksiya qilish – har doim AbstractBaseClassPatternFactoryReactor kabi classlar yozish, lekin u faqat bitta joyda ishlatilishi – bularning hammasi kodni keraksiz darajada murakkab qiladi.

Database bilan ishlashda esa eng katta muammo – Django ORM optimizatsiyasiga e’tibor bermaslik. Ba’zilar har bir request uchun 1000 ta .filter(), .all(), .values() chaqirib, N+1 query muammosini yaratadi. Cache ishlatmaslik – har safar bir xil ma’lumotni qayta-qayta DB’dan olish esa server resurslarini behuda sarflaydi. Har bir mayda o‘zgarish uchun ERD chizish yoki aksincha, katta feature uchun umuman database dizayn qilmaslik ham katta muammolardan biri.

Deployment va loggingda ham xatolar ko‘p. Log yozmaslik – production’da muammo chiqqanda hech qanday dalil topilmasligi, yoki aksincha, kerakmas hamma narsani logga yozib, haqiqiy muammoni topishni qiyinlashtirish – backend'ning asosiy muammolaridan biri. Bundan tashqari, frontend va backend deploy qilish uchun 30 daqiqa kutish, yoki har bir deploy’da eski faylni ustiga overwrite qilib, downtime yaratish, keyin esa rollback imkoniyati bo‘lmaganidan pushaymon bo‘lish – deploymentdagi asosiy xatolar.

Xulosam shuki, best practice degan narsa yo‘q, lekin yomon amaliyotlar juda ko‘p. Django va Python backend'da keraksiz murakkablik, noto‘g‘ri database optimizatsiyasi va yomon deployment jarayonlari eng katta xatolardan hisoblanadi.

Overengineering — Katta muammolarga kichik yechim, kichik muammolarga katta yechim

Dasturchilar loyiha boshlaganda yoki kod yozishda mukammallikni maqsad qilishadi. Har bir funksiya maksimal darajada reusable(qayta ishlatib bo’ladigan) bo‘lishi kerak, har bir mikroservis mustaqil ishlashi kerak, har bir metod kengaytiriladigan bo‘lishi kerak... Va oxir-oqibat, oddiy muammoni hal qilish uchun murakkab, boshqarish qiyin va ortiqcha resurs talab qiladigan arxitektura paydo bo‘ladi.

Bu – Overengineering (ortiqcha muhandislik).

Nega Overengineering muammo?

1️⃣ Tuzilishi qiyin va vaqtni oladi
Tanishlaringizdan biri mehmonlar uchun oddiy choy tayyorlashi kerak. Unga bitta choynak va gaz plitasi yetarli. Lekin u "choy eng optimal haroratda damlansin" deb, termometr, suv filtri, avtomatik choy damlovchi apparat, maxsus vaqt o‘lchagich va qayerdandir IoT bilan boshqariladigan elektr choynak olib keladi. Mehmonlar esa choy kelguncha allaqachon uyiga ketib qolishadi.
Dasturiy ta’minotda ham shunday: oddiy CRUD API uchun event-driven arxitektura, mikroservislar va Kubernetes klaster kerak emas. Eng kerakli narsani tez va samarali qilish muhim.

2️⃣ Texnik qarz yuki
Tasavvur qiling, ofisingizda oddiy bitta eshik bor. Uni ochish uchun oddiy kalit yetarli. Lekin kimdir "bu eshik xavfsiz bo‘lishi kerak" deb, 4 ta qo‘shimcha kod, Face ID, karta skaneri va 2 bosqichli autentifikatsiya qo‘shadi. Boshida bu zo‘r ko‘rinishi mumkin, lekin keyinchalik kalit yo‘qoladi, Face ID ishlamaydi, yangi odamlar kirishi uchun soatlab ruxsat kutishadi va oxir-oqibat eshikni buzib ochishga to‘g‘ri keladi.
Dasturda ham shunday: agar boshlang‘ich darajadagi loyiha uchun ortiqcha murakkab arxitektura yaratsangiz, u kelajakda texnik qarzga aylanadi va uni refaktor qilishga majbur bo‘lasiz.

3️⃣ Resurslar ortiqcha sarflanadi
Sizga kvartira kerak. Lekin "mukammal yashash joyi bo‘lishi kerak" deb, shahar markazida katta villa qurishni rejalashtirasiz. Kredit olasiz, byurokratiya bilan shug‘ullanasiz, qurilish 5 yil davom etadi... oxirida esa kvartira narxi 2 baravar oshib ketadi va siz hali ham ijara to‘layapsiz.
Xuddi shunday, oddiy monolit xizmat qilish mumkin bo‘lgan joyda murakkab mikroservis arxitekturasi, kutilmagan xatolar va ortiqcha operatsion xarajatlar muammoga aylanadi.

4️⃣ Haqiqiy biznes muammolar chetda qoladi
Do‘konda oddiy savdo tizimi kerak bo‘lsa, sotuvchi faqat "Sotish" tugmasini bosishi yetarli. Lekin siz "UI zo‘r chiqsin, AI bilan tahlil qilsin, blockchain bilan ma’lumotlar xavfsiz bo‘lsin" deb murakkab tizim qurib qo‘yasiz. Natijada sotuvchi tugmani bosish o‘rniga, 5 daqiqa shaxsiy kabinetga kirib, API ishlashi kutishiga to‘g‘ri keladi.
Haqiqiy biznesda foydalanuvchi uchun eng sodda va samarali yechim muhim, ortiqcha murakkablik esa faqat vaqt va pul yo‘qotilishiga sabab bo‘ladi.