Deylik, siz do'stingizning hisobiga $100 o'tkazmoqchisiz. Database levelda bu taxminan mana bunday bo'ladi:
1. Hisobingizda $100 dan ko'p mablag' borligini tekshirish.
2. Sizning hisobingizdan $100 kamaytirish.
3. Do'stingizning hisobiga $100 qo'shish.

Deylik, 1 va 2-bosqichlar bajarilgandan keyin hali 3-bosqich tugatilmasdan biror sababga ko'ra xatolik chiqdi yoki server vaqtincha o'chib qoldi. Bunda nima bo'ladi?
Siz $100 yo'qotdingiz, lekin do'stingiz qabul qilmadi.

Mana shunday holatlarning oldini olish uchun database transaction o'ylab topilgan. Bu xuddi qutiga o'xshaydi. Ichiga querylar solasiz va execute qilasiz. Agar hammasi yaxshi bo'lsa unda commit qilinadi, ya'ni natijalar actual tablega o'tkaziladi. Agar bitta transactiondagi birorta queryda xatolik chiqsa qolgan querylarning ham natijalari bekor qilinadi(rollback).

Bir kishi hamma uchun, hamma bir kishi uchun deganlaridek ...

#savol
topSkills = profile.skill_set.exclude(descriptionexact="") shu kodda "exact" ni vazifasi nima ?

exact lookup oddiy tenglik bilan bir xil vazifani bajaradi.
Siz User.objects.get(id=10) deb yozsangiz bu User.objects.get(id__exact=10) bilan bir xil bo'ladi.

Unda exact nega kerak degan savol tug'ilishi mumkin. Gap shundaki, django ORM SQL query tayyorlayotganda SELECT statement uchun mana shu lookuplardan WHERE clauseda foydalanadi.

Batafsil:
https://docs.djangoproject.com/en/3.2/ref/models/querysets/#field-lookups

#savol GIL O'zi nima kim qanday malumotga ega tushuncha berib yuboringlar menda internet tezligi 13 B/s Google ning ochaolmayabman iltimos😢🧐😊

#javob

GIL nima va nega kerakligini tushunish uchun concurrency nima, lock nima, nega kerak, dead lock nima, qanday oldini olish mumkin va h.k. lar haqida ozgina ma'lumot olish kerak.

Concurrency bu bir nechta thread(oqim)larning bitta processorda ishlashi. Umuman olganda, threadlar processorda juda kichik instructionlarga ajratilib(Assemblyga o'xshash), navbatma-navbat bajariladi. Bu instruksiyalar juda kichkina bo'lgani va processor bir soniyada bunaqa instruksiyalardan milliardlab bajargani uchun bizga xuddi bir vaqtda ishlayotgandek taassurot qoldiradi.

Concurrency paytida ba'zi o'zgaruvchilarni ikkita thread bir vaqtda o'zgartirishi, buning orqasidan noto'g'ri natijalar kelib chiqishi mumkin(masalan, a=0 o'zgaruvchiga 2 marta 1 qo'shib, natija 1 chiqishi mumkin). Mana bu race condition deyiladi.

Race conditionning oldini olishning bir usuli sifatida lock o'ylab topilgan. Lockning ishlashi quyidagicha: biror thread biror o'zgaruvchining qiymatini o'zgartirmoqchi bo'lgan paytda uni "qulflab" qo'yadi. Shunda o'zgaruvchini bir vaqtda faqat bitta thread o'zgartira oladi. Bu qiymatni olmoqchi bo'lgan boshqa thread qulf ochilishini kutib, ochilgandan keyin yangi qiymatni olib ishlataveradi.

Lock juda yaxshi yechim, lekin bitta jiddiy muammosi bor. Deylik, bitta thread a o'zgaruvchini "lock" qilgan va b ning qiymatini olmoqchi. Ikkinchi thread b ni "lock" qilgan va a ning qiymatini olmoqchi. Shunda ikkita thread yopiq sikl hosil qilib bir-birini qulflab qo'yadi. Bu esa dastur o'sha joyda "tiqilib qolishi"ga olib keladi. Mana bu holat "dead lock" deyiladi.

Pythonda xotira boshqaruvi avtomatik bajariladi. Ya'ni qaysidir qiymat ishlatilmasa, python uni avtomatik aniqlab, xotiradan bo'shatadi. Buni amalga oshirish uchun python reference count degan narsadan foydalanadi. Sodda qilib aytganda, o'sha qiymatdan necha kishi foydalanayotganini sanab turadi. O'sha raqam 0 ga tushganda(demak, hech kim ishlatmayapti) garbage collector o'sha qiymatni xotiradan o'chiradi.

Race condition hamma joyda sodir bo'lishi mumkin. Shu jumladan reference countda ham. Lekin bu yerda sodir bo'lsa kerakli ma'lumotlar o'chib ketishi yoki keraksiz ma'lumot xotirada qolib ketishi kabi muammolar kelib chiqadi. Buning oldini olish uchun Python reference count uchun ham lock ishlatadi. Lekin yuqorida aytilganidek, dead lock muammosini ham hisobga olish kerak. Shuning uchun Python hamma uchun bitta GIL(Global Interpreter Lock) ishlatadi. Bu ham oddiy lock kabi ishlaydi, lekin u interpreterda saqlanadi. Qaysidir thread biror o'zgaruvchini o'zgartirmoqchi bo'lsa interpreter GILni o'sha threadga vaqtinchalik berib turadi. Thread esa undan o'zgaruvchini emas, uning qiymatidagi reference countni qulflashda foydalanadi. Ishini tugatib bo'lgach, u GILni yana interpreterga qaytaradi va interpreter GILni boshqa threadga beradi...
Butun interpreterda bitta GIL bo'lgani uchun dead lock sodir bo'lmaydi. Sababi, qulf bitta, hech kim bir-birini qulflab qo'ymaydi.

Demak, GIL bizning dasturimizdagi o'zgaruvchilar bilan bo'ladigan race conditionning oldini olish uchun emas, Pythonning ichki, xotira boshqaruv tizimi to'g'ri ishlashi uchun xizmat qiladi.

Nima topib olganimni ko'ring 🙂
https://www.cs.usfca.edu/~galles/visualization/Algorithms.html

#savol
Assalomu alaykum, hammaga!

Postgresqlda replikatsiya bo'yicha savol:

replikatsiyani maqsadi performance'ni oshirish ya'ni yagona serverga yuklama ortib ketib, uni ishlashi sekinlashmasligi uchun ishlab chiqilgan desak, master-slave o'rtasida sinxronizatsiya paytidagi jarayon(masterdan slave'ga yozuv yozish) performance'ga qanchalik ta'sir qiladi?

Assalomu alaykum, database replicationdan asosiy maqsad read(SELECT)larni tezlashtirish. Masalan, 1 ta slave 10 k QPSga (faqat read) aktiv javob bera olsa, 3 ta follower slave qo'shish orqali bu tezlikni 3 marta tezlashtirish mumkin.
Xuddi API leveldagi load balancerga o'xshab.

Replication write(INSERT, UPDATE, DELETE)larni yaxshilamaydi. Shu bilan birga deyarli sekinlashtirmaydi ham. Sababi, master slavega yangi record yozilganda boshqa slavelar ham copy qilishini kutib(sinxronlash), master slavedagi asosiy threadni block qilmasdan, bu haqida qolganlarga xabar berib, ishini davom etadi. Follower slavelar esa bu recorddan xabar topib, o'zlariga yozib qo'yadi.
Bu qaysidir taraflama EDAga o'xshab ketadi.

Database replication aslida real-time emas. Sababi, record master slavega yozilgandan keyin hamma followerlar sinxronlangunicha millisekundlar vaqt ketadi. Shuning hisobiga data inconsistency kelib chiqishi ehtimoli yo'q emas(o'sha millisekundda follower slaveda read query execute bo'lsa). Lekin buning ehtimoli juda kam.

Bu yerda bir narsani aytish esimdan chiqibdi.
Master nodega yangi record yozilganda followes nodelarni kutib o'tirmasdan, ishida davom etishini yozdim. Bu asinxron yozish usuli. Lekin bundan boshqa usullari ham bor.

Sinxron usulda yozilganda client follower slavelar yozib bo'lgunicha bloklanib turadi. Bu asosan, data consistencyni ta'minlash uchun. Yana boshqa sabablar ham bor.
Sinxron yozishni ham turlicha configure qilsa bo'ladi.
Masalan, ixtiyoriy 1 ta, 2 ta n ta replica yozib bo'lishi bilan blokni ochish, aynan a, b replicalar yozib bo'lgandan keyin bo'shatish va h.k.

Writelarni scale qilish uchun multi-master replication bor. Lekin rostini aytsam, bu implement qilish uchun biroz qiyin va conflictlar kelib chiqishi ehtimoli ancha yuqori.

#savol
Webhook nima va qanday qulayliklar yaratib beradi?

Telegram botlar qanday ishlashini tushunish uchun polling, webhook nima,
ular nega kerak kabi savollarga javob topsak.

User telegramda botga biror buyruq yuborganda, unga javob qaytishi uchun bu buyruq biz yozgan kodimiz turgan servergacha yetib kelishi kerak va server unga javob qaytarishi kerak. User yuborgan buyruqlar telegramning serveriga borib tushadi. Endi o'sha serverga kelgan buyruqlarni bizning serverimizga yetkazish kerak. Lekin telegram aynan o'sha bot uchun yozilgan bizning kodimiz qayerda turganini qanday biladi?

Telegram botlar uchun HTTP protocolidan foydalanadi. Muammo shundaki, HTTP bir tomonlama ishlaydi(push/promisedan tashqari). Ya'ni faqat bir tomon(client) request yuboradi, ikkinchi taraf(server) uni qabul qilib, response qaytaradi.
Bu degani, server xohlagan paytida clientga response yubora olmaydi. Faqatgina client request yuborgandan keyingina response yuborish mumkin.

Bizning server bilan telegram server orasida ma'lumot almashishning ikki yo'li bor:
1. Bizning server HTTP client, telegram serveri esa HTTP server vazifasini bajaradi.
2. Telegram serveri HTTP client, bizning server esa HTTP server vazifasini bajaradi.


1. Deylik, user telegram botga biror buyruq yubordi. Telegram serveri bu buyruqni to'g'ridan to'g'ri bizning serverga yubora olmaydi. Sababi, yuqorida kelishganimizdek, faqat client birinchi bo'lib ma'lumot yubora oladi. Telegram server esa hozir HTTP server rolini o'ynayapti. Plus, telegram biz qaysi bot haqida so'rayotganimizni ham bilmaydi. Demak, avval client so'rov yuborishi kerak.
Lekin client qachon so'rov yuborish kerakligini(telegramga yangi buyruq kelganini) qanday biladi?
Javob — hech qanday. Shunchaki ma'lum vaqt oraligi bilan telegram serveriga to'xtovsiz request yuborib turadi. Botga yangi buyruq kelsa, telegram keyingi safar bizning serverdan request kelganda uni response qilib yuboradi. Bu taxminan mana bunday bo'ladi:

Client: Falonchi bot uchun yangi buyruq bormi?
Telegram: Yo'q
*ozgina vaqt o'tgach*
C: Bormi?
T: Yo'q
C: Bormi?
T: Ha, mana, ol. *Buyruqni yuboradi*
C: *Buyruqqa javob qaytarib, request shaklida yuboradi*
T: Oldim.
C: Bormi?
T: Yo'q
...

Mana shu usul, ya'ni bizning server ma'lum vaqt oralig'i bilan to'xtovsiz telegramdan so'rab turishi polling deyiladi.


2. Endi bizning server HTTP server vazifasini bajarib, Telegram serveri HTTP client rolini o'ynab beradi. Endi telegram client sifatida buyruqlarni to'g'ridan-to'g'ri bizga yubora oladi. Lekin buning uchun ikkita shart bajarilishi kerak:
1. Telegram bizning serverning manzilini bilishi.
2. Bizning server web server sifatida ishlashi, ya'ni requestlarni qabul qilishi kerak.

Buning uchun boshda Pashka akaning serverlariga "Falonchi botga kelgan buyruqlarning hammasini falonchi adressdagi serverga request qilib yubor" degan ma'noda xabar berib qo'yamiz. O'zimizning serverimizni esa web serverga aylantiramiz.

Endi faqat yangi buyruq kelgandagina telegram bizning serverimizga request yuboradi:

Telegram: Uka, botingga yangi buyruq keldi. Ma, ol.
Bizning server: *qayta ishlab, natijani yuboradi*.
*keyingi safar buyruq kelganda*
Telegram: Yangi buyruq. Ma, ol.
...

Mana bu usul, yani telegram bizning serverga request yuborishi esa webhook deyiladi.

JR:
Mikroservislar yomon. Ular boshqa yaxshiroq variant yo'qligi uchun ishlatilayapti.

Men:
Shu "boshqa yaxshiroq variant yo'qligi sabab" degan joyini "an'anaviy variantlar (ba'zi vaziyatlarda) ish bermagani sabab" ga o'zgartirsak, qiziq narsalar chiqadi:

Mikroservislar nega yaratildi?
An'anaviy variantlar(monolith) ish bermay qolgani sabab.

O'zi komputerlar nega yaratildi?
An'anaviy hisoblash usullari ish bermay qolgani sabab.

Miltiq nega yaratildi?
An'anaviy usullar(qilich) ish bermay qolgani sabab.

G'ildirak nega yaratildi?
An'anaviy usullar(sudrash) ish bermay qolgani sabab.

Ana shunaqa gaplar...

P.S. Bunaqa faylasufona gaplar qayerdan keldi, bilmayman😁

Toshkentda ish izlayotgan tanishlar bo'lsa, "fisht" deb qo'yinglar.

Newmax Technologies - это холдинг продуктовых IT компаний с такими проектами как My Taxi, Express 24, Workly, Max Track в поисках Junior Back-end разработчика на проект My Taxi.

Мы ищем специалиста, желающего развиваться в направлении Back-end разработки. Если вам интересно создавать программное обеспечение, работая с базой данных, архитектурой, программной логикой — смело откликайтесь на вакансию.

Обязанности:
- Создание нового функционала и оптимизация работы уже имеющегося;
- Повышение надежности и качества системы на всех уровнях.

Требования:
- Знание Python (Django);
- Понимание принципов RESTful API/gRPC, Microservices;
- БД MySQL, миграции;
- Опыт работы с git;
- Свободное владение русским языком, английским на уровне чтения технической документации;
- Большим плюсом будут DevOps навыки, опыт работы с API платёжных систем.

Условия:
- Официальное трудоустройство по ТК РУз;
- График работы 5/2, 09:00-18:00;
- Офис в центре города (парк Бобура, Ракат махаля, ТРЦ Next);
- Заработная плата от 2 000 000 в зависимости от квалификации
- Контактное лицо: @alishermusurmonov

👉 @uzpythonjobs

Ba'zi kanal kuzatuvchilari nimaga postlar kamayib qolgani haqida so'rashayapti.
Sababi oddiy. Ko'p post bo'lishi uchun ko'p qiziqarli savol kerak. Savollar esa asosan communitydan keladi. Communityda faol bo'lish uchun esa yetarlicha bo'sh vaqt kerak. Ana shu vaqt hozir menda muammo. Lekin shaxsiyda berilayotgan savollarga maksimal javob berishga harakat qilayapman.

Shunaqa savollar bo'ladi-ki, u savollarga javob topish orqali ko'p narsa o'rganmasligingiz mumkin, lekin hali o'rganishingiz kerak bo'lgan ko'p narsani bilib olasiz.
Hozir bir fikr kelib qoldi. Vaqti-vaqti bilan kanalda #yaxshi_savol tagi bilan savollar joylab turaman. Lekin javob bermayman.
Hamma commentda o'z javobini qoldirishi mumkin (batafsil va hammaga tushunarli formatda bo'lsa juda yaxshi).
Kuzatuvchilar (hozircha) ko'p bo'lmasa ham orangizda kattagina xalqaro kompaniyalarda ishlaydigan dasturchilar bor.
Sizlardan o'z bilimingizni commentlarda ulashishingizni so'rab qolardim. Bu endi boshlaganlar uchun foydali bo'ladi deb o'ylayman.

Boshladik, inshaalloh.

#yaxshi_savol

Avval web development yaxlit bitta soha edi. Keyin ikki asosiy qism: frontend va backendga ajraldi. Qizig'i, aslida bu qismlar abstrakt emas, nisbiy. Biz biladigan frontend va backend butun boshli web applicationga nisbatan olingan.
Web applicationning bir qismi uchun ham frontend va backend qismlari bor. Masalan, backend web serverning frontend qismi bu API.

Endi savol.
Biz biladigan web backendning o'zi uchun ham backend qismi bor. Bu nimaligini ko'pchilik biladi. Qizig'i, o'sha qismning ham frontend va backend qismlari bor.
Siz kommentlarda shu backend, ya'ni web backendning backend qismining backend qismi nimaligini ayting.
Iloji bo'lsa, batafsilroq javob qoldiring. U nima, nega kerak, qanday ishlaydi, qanday turlari bor va hokazo.

P.S. Tanishlarga ham share qilsangiz xursand bo'lardim.

#yaxshi_savol

PostgreSQL bilan ishlaganda, deylik siz bir ma'lumotni UPDATE yoki DELETE qildingiz.
Lekin shu vaqtning o'zida eski qiymat ham tabledan o'chib ketmaydi.

Masalan, sizda
id INT, name VARCHAR
columnlaridan iborat persons table bor.
Deylik, unda 1 ta row: (1, 'John') bor.
Keyin siz uni yangiladingiz:
UPDATE persons
SET name = 'Doe'
WHERE id = 1;

Yoki o'chirib yubordingiz:
DELETE FROM persons
WHERE id = 1;

Lekin ikki holda ham eski qiymat, ya'ni (1, 'John') xotiradan o'sha vaqtning o'zida o'chib ketmaydi.

Savol: Eski qiymatlarni xotirada vaqtinchalik saqlab qolish nima uchun kerak va buning qanday negativ natijalari bo'lishi mumkin?

Javoblarni iloji boricha batafsil yozib, discussionda qoldirishingiz mumkin.

#yaxshi_savol

Serverga kelayotgan requestlarni bitta web application instance ko'tara olmay qolganda load balancingga ehtiyoj tug'iladi.
Oddiy tushuntirganda, hamma requestni bitta instancega yuborish o'rniga, bir qancha instancelar ishga tushirib, requestlarni ularning orasida taqsimlab berish.

Load balancingning ham turlari bor.
Backend developmentda eng keng tarqalganlari layer 7 va layer 4 load balancing. Ya'ni, OSI modelining yettinchi (application) va to'rtinchi (transport) qavatida turib taqsimlash.

Savol: L7 va L4 load balancerlarning har birining qanday yaxshi va yomon taraflari bor?

Javoblarni iloji boricha batafsil yozib, discussionda qoldirishingiz mumkin.