Matematiklarga savol.
Ko'pburchak(polygon)da maksimal nechta tomon bo'lishi mumkin?

Xo'sh, demak tomonlar soni 2 dan katta ixtiyoriy natural son bo'lishi mumkin ekan. Demak tomonlar sonining yuqori chegarasi yo'q ekan.

Xo'sh, endi ikkinchi savol.
Tepadagi xulosadan foydalansak, aylana(circle) ham ko'pburchak (polygon)mi?

Bir boshidan analiz qilaylik.

Polygon tomonlardan tashkil topgan. Tomonlar esa kesmalar, ya'ni to'g'ri chiziqning bir bo'lagidan iborat. To'g'ri chiziq esa cheksiz nuqtalar to'plami.
Aylana ham cheksiz nuqtalar to'plami.
Demak, aylanadagi barcha ketma-ket ikki nuqtani kesma (ya'ni to'g'ri chiziqning bir qismi) sifatida qarasak, aylanani ham kesmalardan iborat yopiq shakl – ko'pburchak deb qarash mumkin.

Lekin matematik jihatdan aylana ko'pburchak deb qaralmaydi. Unda biz qayerda xato qildik? Aynan nima bu sofizmni keltirib chiqarayapti?

Javob: Cheksizlik (infinity).

Tepadagi sofizmda biz cheksizlikka son sifatida qaradik. Bu esa noto'g'ri. Cheksizlik son emas, chegarasi yo'q bo'lgan kattalikni matematik jihatdan ifodalash uchun kiritilgan tushuncha. To'plamlar jihatidan olib qaralganda cheksizlik bu oxiri yo'q to'plamdagi elementlar soni, lekin elementlardan biri emas. Masalan, natural sonlar to'plamidagi har bir element chekli, lekin bu to'plamning kattaligi cheksiz.
Sonlar ustida bajariladigan amallar cheksizlik bilan ishlamaydi.

Biz aynan xato qilgan joy esa aylanadagi ikkita ketma-ket nuqtani kesma sifatida qarash edi. Aslida aylanada ham, chiziqda ham ikkita ketma-ket nuqtaning o'zi yo'q. Istalgan ikki nuqta orasida cheksiz sondagi nuqtalar bor.

Biz aylanani ko'pburchak deb hisoblashimiz uchun undagi har bir nuqta ko'pburchakdagi qaysidir kesmaga tegishli bo'lishi kerak. Buning uchun esa eng kamida ketma-ket ikki nuqtani kesma sifatida qaray olishimiz kerak (kesma boshi va oxiri). Lekin tepada aytganimiz bo'yicha ketma-ket nuqtalarning orasida ham cheksiz sondagi boshqa nuqtalar bor. Biz esa ularni kesmaning bir qismi sifatida qaray olmaymiz. Sababi, aylanadagi hech qaysi 3 ta nuqta 1 to'g'ri chiziqda yota olmaydi.

Qo'ldan kelganicha tushuntirishga harakat qildim. Cheksizlik fandagi eng sirli va tushunarsiz tushunchalardan biri.

@boboshersnotes

JavaScriptning chiroyidan bahra oling.

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

Code review, hamma testlar va staging serverda QAdan ham eson-omon o'tkazib production serverda bug chiqarish ham aslida bir san'at, sizga aytsam.

One LeetCode a day
Keeps unemployment away.

Credit: @JR_TwitGram

Array

RAMda ordered collection saqlashning eng sodda usuli array.
Ko'p hollarda bu collection ustida bajariladigan ma'lum operatsiyalar tezligi boshqalaridan ko'ra muhimroq bo'ladi. Natijada faqatgina ma'lum operatsiyalarga ixtisoslashgan yangi data structurelar ishlab chiqishga ehtiyoj tug'iladi. Dynamic array, stack, queue, heap, va h.k. lar mana shu sabab paydo bo'lgan. Lekin asosida oddiy array yotadi. Masalan:

— Oddiy array razmerini band va bo'sh joylar nisbatiga qarab dinamik tarzda o'zgartirish (aniqrog'i, hamma ma'lumotni boshqa razmerli arrayga ko'chirish) orqali dynamic array hosil bo'ldi. Bu orqali oxiriga element qo'shish va oxirgi elementni o'chirish operatsiyalari O(n) dan amortized O(1) ga tushdi.

— Dynamic arrayning oxirgi elementini o'chirish va oxiriga element qo'shish O(1) bo'lgani uchun undan first-in last-out (oldin kelgan keyin ketadi) tartibini ta'minlaydigan collection – stack sifatida foydalanish mumkin.

— Ikkita stackni bir-biriga teskari qilib ulash va biroz matematikadan foydalanib ulangan joyni nazorat qilish orqali first-in first-out (oldin kelgan oldin ketadi) tartibini amortized O(1) vaqtda ta'minlaydigan collection – queue paydo bo'ldi.

Bu ro'yxatni hali uzoq davom ettirish mumkin...
Arrays, arrays everywhere ))

@boboshersnotes

OOP dasturlashdagi eng chiroyli paradigm deb hisoblayman.
Lekin afsuski, bu go'zallik hozir ko'plab dasturchilarning ko'zini ko'r qilib qo'ygan.

@boboshersnotes

Yaxshi savol ekan:

https://leetcode.com/problems/bulb-switcher/

How to create a good mobile application with Python:

Step 1. Don't do that.

Step 2. Jump to the step 1.

Asosiy servislarimizdan biri bilan bitta third-party service o'rtasida ma'lumot almashish uchun pollingdan foydalanamiz (nega webhook emas deb so'ramang). O'tgan juma kuni productionga bugi bor featureni release qilish sabab serverdagi ba'zi configurationlar o'zgarib ketibdi. Natijada dam olish kunlari bizning serverimiz ularning serveriga yaxshigina RPS bilan to'xtovsiz request yuboribdi. 2+ kun davomida, to'xtovsiz.

Ularning ham DDoSga qarshi himoyasi yo'q shekilli, blok qilishmabdi. Yaxshi-ki, dam olish kunlari sabab ularning serverida boshqa load kam bo'lgan. Bo'lmasa serveri o'chib qolib boshimiz baloga qolishi mumkin edi 😅.

Behavioural interviewda "Qovun tushirgan vaqtingni gapirib ber" deb so'rab qolishsa aytib beradigan story bo'ldi.

O'rgangan darslarim:
1. Third-party toollar ixtiyoriy vaqtda kutilmagan natija berishi mumkin. Hatto eng ishonchlilari ham.
2. Serverni monitoring qilish uchun ketgan resurslar o'zini oqlaydi.
3. Testlar hech qachon yetarli emas.
4. Juma kuni kechki vaqt deploy qilish yaxshi fikr emas.

If you know what I mean

Meme explained

Instance methodlar boshqa tillarda qanday implement qilingan?
Biladiganlar commentda qisqacha ma'lumot bersangiz xursand bo'lardim.