Juda ajoyib fikr bo'ldi. Getter va setterlar encapsulationga emas, aslida objectning kamroq encapsulated bo'lishiga sabab bo'ladi.

ACID haqida gaplashamiz

Ko'p hollarda foydalanuvchi uchun bir butun sifatida qaraladigan o'zgarish ma'lumotlar ba'zasida bir nechta ketma-ket o'zgarishlarni talab qiladi.

Masalan, do'stingizning kartasiga $100 yubormoqchisiz. Bu siz uchun bir butun ish. Lekin ma'lumotlar ba'zasida bu eng kamida mana bu ketma-ket qadamlardan iborat:

1) Sizning balansingizni $100 ga kamaytirish;
2) Do'stingizning hisobini $100 ga oshirish;

Xatoliklarning oldini olish uchun bunday operatsiyalarni ma'lumotlar ba'zasida ham bir butun deb qarashga imkon beruvchi yangi birlikka ehtiyoj tug'iladi. Bu birlik tranzaksiya deb ataladi. Demak, tranzaksiya ma'lumotlar bazasida mantiqiy jihatdan bir butun ish bo'lgan bir nechta query(so'rov)larni birlashtirish imkonini beradigan "quticha".

ACID esa trakzaksiyalar o'zini qanday tutishini belgilaydigan umumiy qoidalar to'plami. Bu qoidalar orqali kutilmagan vaziyatlarda (xatolik chiqqanida, server o'chib qolganida va h.k.) trakzaksiyadagi ma'lumot haqiqiyligini (data validity) saqlab qolish ta'minlanadi.

ACID so'zi 4 ta qoida: Atomicity, Consistency, Isolation va Durability so'zlarining bosh harflaridan olingan. Xo'sh, bu qoidalar nima?

Atomicity – bo'linmaslik

Bu qoidaga ko'ra tranzaksiyalar bo'linmas, bir butun bo'lishi kerak. Yo tranzaksiyadagi hamma operatsiya muvaffaqiyatli bajariladi yoki hech qaysi operatsiya bajarilmaydi. Bir qismi bajarilib, qolgan qismi bajarilmay qolishi mumkin emas. Agar qaysidir operatsiyani bajarish vaqtida xatolik chiqsa butun tranzaksiya muvaffaqiyatsiz bo'ladi va bu tranzaksiyadagi muvaffaqiyatli bajarilgan operatsiyalar ham avvalgi holiga qaytariladi (rollback). Bir kishi hamma uchun, hamma bir kishi uchun deganlaridek...

Tepadagi misolda, deylik, sizning hisobingizdan pul yechildi, lekin do'stingizning hisobini oshirish vaqtida xatolik chiqdi. Natijada siz $100 yo'qotdingiz, lekin do'stingiz qabul qilmadi. $100 "havoga uchdi".
Buning oldini olish uchun xatolik chiqqanida butun tranzaksiya bo'ylab barcha operatsiyalar avvalgi holatiga qaytariladi, ya'ni $100 sizning hisobingizga qaytariladi.

Consistency – moslik

Tranzaksiya natijasi ma'lumotlar bazasida avvaldan belgilab qo'yilgan qoidalar bilan mos bo'lishi kerak. Aks holda tranzaksiya muvaffaqiyatsiz deb belgilanadi va rollback qilinadi. Deylik, qoidaga ko'ra foydalanuvchi balansi manfiy bo'lmasligi kerak. Agar hisobingizda $60 bo'lsa, do'stingizga $100 o'tkazgandan keyin hisobingiz -$40 bo'ladi. Bu esa tepadagi qoidaga to'g'ri kelmaydi. Operatsiyalar muvaffaqiyatli bo'lsa-da natija qoidalar bilan mos bo'lmagani uchun bekor qilinadi.

Isolation – izolyatsiya

Hali tugallanmagan trakzaksiyadagi ma'lumotlar tashqaridan (boshqa tranzaksiyalardan va tranzaksiya tashqarisidagi boshqa operatsiyalardan) izolyatsiyalanishi kerak. Ya'ni tranzaksiya tugamagunicha ichkaridagi ma'lumot tashqariga ko'rinmasligi kerak.

Masalan, tepadagi misolda hisobingizdan pul yechildi, lekin hali do'stingizga tushmadi. Shu vaziyatda, hali tranzaksiya tugamasidan balansingiz tekshirilganida kamaygan qiymat emas, tranzaksiyadan tashqaridagi, oldingi qiymat ko'rinishi kerak.

To'liq izolyatsiya ko'p resurs va vaqt talab qilgani uchun va doim ham to'liq izolyatsiya zarur bo'lmagani uchun tranzaksiya izolyatsiyasining 4 ta standart darajalari bor. Ular tezlik, resurslar sarfi va xavfsizligi jihatidan bir-biridan farq qiladi. Endi bu boshqa kun uchun boshqa mavzu.

Durability – ishonchlilik

Tranzaksiya muvaffaqiyatli yakunlangani haqida xabar berilganida tranzaksiyadagi o'zgarishlar to'liq diskda saqlangan bo'lishi va ma'lumot yo'qotilmasligi kerak.

Masalan, do'stingizga muvaffaqiyatli pul o'tkazganingiz haqidagi xabar olganingiz va shu vaqtda serverda xatolik chiqib, o'chib qoldi. Qayta yoqilgandan keyin balansingizni tekshirganingizda esa pul o'tkazishdan oldingi, eski qiymatni ko'rdingiz. Demak, tranzaksiya muvaffaqiyatli deb belgilangan bo'lsa ham natijalar o'chib ketgan. Xuddi shu holat esa durability qoidasini buzadi.

Qisqasi, mana shu 4 ta qoida ma'lumotlar buzilishi bilan bog'liq ko'p bosh og'rig'idan saqlaydi.

Maqola foydali bo'lgan bo'lsa tanishlarga yuborib qo'ying.

@boboshersnotes

Oramizda backend engineer (preferably, Python stack) position uchun mock technical interview qiladigan engineerlar bormi?
Ko'p skillarim "zanglab" qolayotgandek tuyulayapti.
Biror vakansiyaga topshirib ko'rsam ham bo'ladi, lekin hozircha ish joyimni o'zgartirish niyatim yo'q. Baribir ishga kirmasam, bekorga ularning resursini olish to'g'ri deb hisoblamayman.

Concurrency Control

Zamonaviy ma'lumotlar bazalarida bir vaqtda bir nechta foydalanuvchi tomonidan parallel operatsiyalarni amalga oshirish imkonini beradi. Agar bu operatsiyalar aynan bitta resurs ustida bo'lsa (masalan, 2 ta process bir vaqtda bitta ma'lumotni o'zgartirishga harakat qilsa) ular bir-biriga konkurrent bo'ladi va bu ma'lumot yo'qotilishi bilan bogʻliq bir qancha muammolarga olib keladi.

Konkurrent operatsiyalarni xavfsiz boshqarish uchun Concurrency Control (Konkurrensiya Nazorati) mexanizmlari mavjud bo'lib, ularning asosiy vazifasi konkurrent operatsiyalar natijasida ma'lumot buzilishining oldini olish.

CC mexanizmlari konkurrensiyaga bo'lgan munosabatiga qarab 2 ta kategoriyaga bo'linadi: Optimistic CC va Pessimistic CC.

1) Optimistic CC. Bu yondoshuvga ko'ra konkurrensiya holatlari kamdan-kam sodir bo'ladi va doim alohida tayyorgarlik ko'rishga arzimaydi. Bu usul xuddi bahorda ko'chaga soyabonsiz chiqishga o'xshaydi. Yomg'ir yog'masligiga umid qilasiz, lekin yog'sa jiqqa ho'l bo'lasiz.
Kam resurs talab qiladi, lekin operatsiya muvaffaqiyatsiz tugashi mumkin.

Bu usulda ishlaydigan usullardan eng keng tarqalganlari Timestamp-Based Concurrency Control (TBCC) va Multi-Version Concurrency Control (MVCC) mexanizmlari.

TBCC har bir tranzaksiyaga unikal timestamp berish orqali tranzaksiyalarning qat'iy ketma-ketligini ishlab chiqadi va har bir obyektga uni oxirgi marta o'qigan/o'zgartirgan tranzaksiyaning timestampini yozib boradi.

Tranzaksiyadagi har bir operatsiyani bajarishdan oldin o'qilayotgan/o'zgartirilayotgan obyektda ko'rsatilgan timestampga qarab 3 ta variantdan birini tanlaydi: bajarish, kutish yoki bekor qilish. Agar birorta operatsiya muvaffaqiyatsizlikka uchrasa (bekor qilinsa) butun tranzaksiya bekor qilinadi (yomg'ir yog'ib ho'l qiladi).
Ma'lumotlarni yagona versiyada saqlaydigan tezkor, yengil lekin ishonchsiz CC mexanizmi.

MVCC ham xuddi TBCCga o'xshab har bir tranzaksiyaga unikal ID berish orqali ularning tartibini aniqlaydi. Lekin uning ustun jihati bir vaqtning o'zida aynan bitta ma'lumotning asosiy (ishonchli) versiyadan tashqari har bir tranzaksiya uchun alohida versiyalarini saqlay oladi. Natijada muvaffaqiyatsizlikka uchraydigan operatsiyalar nisbati va kutish vaqti kamayadi.

Har bir ma'lumot bir nechta versiyaga ega va uning biror versiyasi hammaga emas, faqat ma'lum tranzaksiyalargagina ko'rinadi. Buni aniqlash uchun tranzaksiya IDlari va izolyatsiya darajalaridan foydalangan holda bir qancha murakkab qoidalardan iborat visibility check (ko'rinish tekshiruvi) o'tkaziladi. Ma'lumot yozish esa TBCCdagiga o'xshashroq. Umuman olganda, MVCC TBCCning ancha murakkab ko'rinishi.

2) Pessimistic CC. Bu yondoshuvga ko'ra konkurrensiya tez-tez sodir bo'ladigan jarayon va har doim unga tayyor bo'lishi kerak. Ya'ni har ehtimolga qarshi har doim soyabon olib yurish kerak. Biroz og'irroq, lekin sodda va ishonchli usul.

Bu usulning eng keng tarqalgan ko'rinishi Two-Phase-Locking (2PL) bo'lib, ishlashi juda oddiy. Tranzaksiya biror ma'lumotni o'zgartirishidan oldin uni lock(qulf) qiladi va tranzaksiya oxirigacha saqlab turadi. Bu vaqt davomida o'sha ma'lumotdan foydalanmoqchi bo'lgan boshqa tranzaksiyalar lock ochilishini kutib turadi. Natijada bazada yagona versiyali, ishonchli ma'lumot saqlanadi.

Bu CCning turlari haqida qisqacha ma'lumot edi. Aslida bu usullarning har biri haqida diplom ishi yozish mumkin.

@boboshersnotes

Ertaga Yangi O'zbekiston Universitetida DevFest bo'layotganidan xabaringiz bo'lsa kerak. Imkoningiz bo'lsa albatta keling, bir chashka kofe ustida suhbatlashamiz.

Hayotiy tajribamdan:

Kodingizni vaqtida test qilmasangiz vaqt o'tib kodingiz sizni test qiladi.

Oldik ☕

[Meme] I listed the most important HTTP status codes and added some descriptive emojis to them :)
https://redd.it/z7onq2

by @programmer_humor

Funksiyaga kiritilgan argumentlar yo hammasi oddiy bo'lishi yo hammasi keyword argument bo'lishi kerak.
Change my mind.

@Python communityda oddiygina savoldan boshlangan muhokama rosa qiziyapti. Odatda bu yerda muhokamalar uziq-yuliq, qo'pol va tartibsiz bo'lardi.

Pythonchilar olg'a ))

Hi there!)

Do you want to know more about one of the best features of Go?

Here we go!)

https://medium.com/safetycultureengineering/an-overview-of-memory-management-in-go-9a72ec7c76a8

#resources

OOPda static methodlar antipattern degan fikrga qanday qaraysiz va muhimi, nega?

Ba'zi savollar borasida dasturchilarning fikrini o'rganayapman. Tepadagi savolga iloji boricha batafsilroq javoblar qoldirsangiz xursand bo'lardim.

Youtubeda "How to prioritize your goals?" degan video ko'rib qoldim. Qaysidir personal development trainingdan yozib olingan ekan.
E'tibor qilib qarasam oddiy selection sort algoritmini tushuntirib berayapti.
Commentga "Merga sort orqali buni O(n log n)da qilsa bo'ladi" deb yozib qo'ydim🙂.

Hozir ham dasturchi sifatida algoritmlarni o'rganish muhimmi?

Mening fikrimcha juda muhim. Albatta, algoritmlarni yaxshi o'rganmasdan turib ham dasturchi bo'lish mumkin. Hozirgi kundagi dasturga va dasturlashga bo'lgan zamonaviy yondoshuvlar (ayniqsa OOP) ko'pchilikda algoritmlar keraksiz narsa degan tushunchani uyg'otishgacha bordi.

Keling, sizga bir haqiqatni aytaman: siz va biz OOP bilan erkin ishlay olishimiz uchun ham ancha-muncha algoritmlar o'ylab topilib, implement qilingan. OOP esa biz – dasturchilar uchun ishlab chiqilgan juda chiroyli abstraksiya. Shunchalik chiroyli-ki, ko'pchilik OOPning o'zini dasturlashdagi elementar, atomic tushuncha deb o'ylashni boshladi. Komputerlar esa haliyam objectlar bilan emas, instruksiyalar ketma-ketligi bilan ishlaydi.

Siz bilan biz kundalik dasturlashda duch keladigan business-related (ya'ni to'g'ridan-to'g'ri loyihaning biznes tomoni bilan bog'liq) muammolar texnologik tomondan allaqachon hal qilib qo'yilgani uchungina algoritmlar bizga kundalik ishimizda kerak bo'lmayapti. O'zingiz o'ylab ko'ring, siz ishingizda foydalanadigan til, tarmoq, protokollar, tayyor software toollar (OS, database, proxy, MQ, ...) va hokazolar hammasi texnologik muammolarni hal qilish uchun ishlab chiqilgan va biz uchun abstraktlashib ulgurdi. Biz esa deyarli hech qanday murakkab texnologik muammoni hal qilmayapmiz.

Muammo shundaki, atrofimizdaki ko'pchilik dasturchilar asosan biznes muammolarni hal qiladi (oxirgi marta ishingizda qachon yangi protokol ishlab chiqishga ehtiyoj tug'ilgan?). Lekin hozir ham minglab dasturchilar sohadagi muhim texnologik muammolarni hal qilish ustida ishlayapti va bir-ikki yildan keyin biz ularning natijasidan shunchaki tekinga foydalanamiz.

Dasturlashdagi texnologik, ya'ni dasturlash sohasining o'zi bilan bog'liq muammolar doim algoritmlarga muhtoj bo'lgan va shunday bo'ladi. Siz saytingizni yaratish uchun qo'lda algoritm yozmayotgan bo'lsangiz bu algoritmlar kerak emas degani emas.

Xo'sh, algoritmlar qanchalik kerak? Bu ko'proq sizga bog'liq deb o'ylayman. Siz dasturchi sifatida nima ish qilasiz? Texnologik muammolarni yechasizmi yoki biznesdagi muammolarnimi?

@boboshersnotes

Universitetda semestr davomida "Introduction to Computer Science" kursida logic gatesdan foydalanib butun boshli sodda komputer qurish va shu komputer uchun sodda high-level dasturlash tili ishlab chiqishni ko'rib chiqdik (High-level language code -> VM code -> Assembly code -> Machine code, CPU instructions).

1 yilcha oldin "Inside the Python virtual machine" kitobini o'qib ko'rish hech narsani tushunmagandim. Bugun bir qismini yana qayta o'qib chiqdim. Hammasi men o'ylaganchalik murakkab emas ekan.

Oldik ☕

Offset haqida

SQL databaselar bilan ishlaganda pagination uchun iloji boricha offset ishlatmaslikka harakat qiling. Sababi, limit va offset query processingda eng oxirgi bajariladigan operatsiyalar. Demak siz offset qilsangiz ham, qilmasangiz ham database baribir og'ir operatsiyalarni bajaradi. Ya'ni birinchi 100 mingta natijani olish bilan 99 minginchi natijadan boshlab mingta natijani olish tezlik jihatdan bir-biridan unchalik farq qilmaydi.

Xo'sh, unda qanday pagination qilish kerak? Iloji boricha index qilsa bo'ladigan biror narsa orqali. Nega? Sababi ularni index orqali filter qilish mumkin. Masalan, har bir pageda 1 kunlik postlar. Shunda offset qilmasdan date bo'yicha filter qilib kunlik postlarni olish mumkin.

Lekin buning bir yomon tomoni pagedagi resultlar soni aniq bo'lmaydi. Masalan, bugun 2 ta, kecha 100 ta post chiqqan bo'lsa bu usul UIda juda xunuk ko'rinadi.

Agar har bir pageda aynan ma'lum sondagi result kerak bo'lsa unda filter + limit ishlatish mumkin. Keyingi pagening boshlanish joyini olish uchun esa oldingi pagening oxirgi elementidan foydalaniladi. Masalan, page size 50 va hozirgi pagedagi oxirgi postning IDsi 150. Keyingi page uchun IDsi 150 dan katta bo'lgan birinchi 50 ta postni olish yetarli bo'ladi. Muhimi, bu usul offset talab qilmaydi.

Offsetdan qochishning bulardan tashqari ham bir nechta usullari bor. Qisqasi, offsetni doim oxirgi variant sifatida qoldiring.