Engineering Notes

"Ishlasa bo'ldide" deb kod yozadigan dasturchilarga haqiqiy maslahatlarimni ulashsam. Buyerda test uchun birinchi shunaqa kod yozib, keyin to'g'irlab qo'yadiganlar haqida emas, balki keyinchalik kimdir ishlaydigan loyihalarga to'g'ridan to'g'ri, tikkasiga, uyalmasdan shu kodlarni push qiladiganlar haqida gapiriladi. Maslahatlar: - Kod ishlashi yaxshi. Ammo ... Kodingizni ertaga kimdir o'qiy olishi, o'zgartira olishi ham kerak (Yozganingizni ertaga o'zingiz ham tushunmaysizku, bularga yo'l bo'lsin 😄). O'zingiz kimdir sizga shunday kodli proyektni tashlab ketsa qancha qarg'aysiz ortidan, endi sizni nechtasi qarg'ayotganini tavavvur qilavering 😄 - Dastur sekin ishlashida hissangiz juda katta. Yaxshi yozilmagan kod, ertaga dasturni sekin ishlashiga olib keladi, oqibatda nafaqat dasturchilardan, balki Foydalanuvchilar va Klient tarafdan ham qarg'ishlar yog'iladi. - Sinash uchun yozgan kodingizni to'g'irlab qo'ying. Sinash uchun hammamiz ham yomon kodlar yozib turamiz. Ammo haqiqiy mardlar ularni to'g'irlab, yaxshiroq qilib qo'yadi. Xatto ba'zan console.log("Test") ham main branch'da yotgan bo'ladi. Yaxshimaas 🙂 - O'rganib qolishdan chetlaning. Shunday kodlar yozgan sari, inson shunga o'rganib qoladi. Ertaga jiddiyroq joyga kirganida esa, juda qiynaladi. Chunki unday joylarda "Ishlasa bo'ldi" o'tmaydi. "Eh, o'rganib qolgan 'tryuk'larim endi yo'q 😢" deb yuborasiz. So'nggi gapim shuki, o'zim ham shunday kod yozib turaman. 🙂 Maslahatlarimga amal qilmasangiz ham, share qilib keting guruh va kanallarga. Zora kimdir olar bu gaplarni 😄 @JoshDeveloper

Savoldan oldin javobni yuboribmanku ))

#savol Can anybody explain in simple words to me What does INCLUDE does in CREATE INDEX?

#javob It includes non-index column values to the actual index (b-tree). Let's say you have a table named "users" with id, name and a bunch of other columns. If you include name column in the index on id field: CREATE INDEX idx_user_id_include_name ON users(id) INCLUDE name; Each time you query that uses this index and only asks for the columns on the index:

SELECT id, name 
FROM users
WHERE id = 1;

PostgreSQL doesn't necessarily go to the actual table after finding the required row, since it can find both id and name field on the index. This is called index-only scan. If you query some other columns (let's say age), PostgreSQL first finds the required row id from the index and go to that row on the table to get age value, since it's not presented on the index. Searching on the index and fetching from the actual table. This is called index scan.

Ungacha bir ikkita eski postlarni repost qilib turaman. Yoqsa like bosing, yoqmasa...yam like bosib qo'yavering ))

O'rtog'lar, bu kanalga faqat ilhom kelganida post yoza olaman. Havotir olib, so'raganlarga rahmat. Kimdir keyingi postni kutayotganidan xursandman. Bollar, biz yutamiz 🙂

Nima? Nega? Qanday? O'rganish uchun men biladigan (va qo'llaydigan) eng yaxshi ketma-ketliklardan biri. Top-down approach. Kimgadir yoqmasligi mumkin, lekin menga yoqadi.

Siz ham menga o'xshab bir vaqtda Pythonning bir nechta versiyalari bilan bir vaqtda ishlashingizga to'g'ri kelsa va versiyalar orasida oson almashish yo'lini izlayotgan bo'lsangiz, pyenv ni ishlatib ko'rishni tavsiya qilaman. Yengil va foydalanishga oson. EuroPython 2021 da Sebastian Witowskining shu haqidagi talkini ko'rganimdan beri pyenv ishlataman. Hozircha biror marta pand bermadi.

The feeling of power when you correct someone smarter than you ))

RDBMS, umuman DBMSlar haqida 20 ta savol. Qolganlaridan qiyinroq savollar * bilan belgilangan. 1. ACID xususiyatlaridan biri bo'lgan atomicity nimani bildiradi? 2. RDBMSlarda qaysi holatlarda denormalizatsiya qilish foydali hisoblanadi? 3. Database cursor nima? Server-side cursorning client-side cursordan ustun tomoni qaysi? 4. Database engine nima? 5. Read committed va repeatable read izolyatsiya darajalarining orasidagi asosiy farq nimada? 6. Pessimistic Concurrency control nima? Uning qanday kamchiliklari bor? 7*. Transaction snapshot nima? 8*. Serialization anomaliyalaridan biri bo'lgan rw-conflict qachon sodir bo'ladi? 9. Connection pool haqida ma'lumot bering. 10. Clustered index bilan non-clustered indexning farqi nimada? 11*. B-tree va B+tree orasidagi farq nimada? 12. Master va slave replicalar orasida to'liq consistencyni qanday ta'minlash mumkin? 13. Database sharding nima? 14*. Row-based storage nima? U nima uchun OLAP operatsiyalari uchun yaxshi tanlov emas? 15*. WAL nima? 16. PostgreSQLda vacuuming nima? 17. PostgreSQLda index scan va index-only scan bir-biridan qanday farq qiladi? 18. PostreSQLda view nima? 19. PostgreSQLda ANALYZE buyrug'i nima vazifani bajaradi? 20*. PostgreSQLda SELECT FOR UPDATE komandasi nima vazifani bajaradi? P.S. Bu savollardan ba'zilari backend developer uchun texnik intervyularda tushishi mumkin. P.S.2. Agar to'g'ri javoblaringiz soni 20 dan kam bo'lsa tabriklayman, o'rganish uchun sizga yangi mavzu topildi.

Mostly asked tech books and their prices: Clean Code: 45$ Grokking algorithmms: 45$ Cracking coding interview: 55$ System design interview: 47$ Contact: @booktrain_bot to order these books

Postdan 2 ta xulosa: 1. Taksistlar siyosat tugul dasturlashni ham "qoyillatib" qo'yadi. 2. Talabalar pul tejash uchun har baloni o'ylab topadi.

Rostini aytganda, bu hazil edi (faqat biroz intellektual). "😁" emoji bosganlarning hammasi hazilni tushungan deb umid qilaman. JR aytganidek, endi postlarimga bunisi hazil, bunisi rost deb qo'shib ketaman. ******* Endi postning o'zi haqida. Nagle's algorithm, TCP delayed ACK, bir-biridan vahimali nomlar juda murakkab tuyulayaptimi? Keling odam tushunadigan tilda gaplashamiz. Tasavvur qiling 25 ta kursdosh Samarqandga taksida bormoqchisizlar. 6 ta taksiga 4 kishidan 24 kishi yo'lga chiqib ketdi, lekin yana bir kishi qoldi. U o'zi bitta taksiga chiqdi, lekin taksist hali haydamaydi. Nega? Sababi, u hali "to'lmadi". Yana 3 ta odam olsa, keyin yuradi. Faqat 1 kishi bilan haydash o'ziga qimmatga tushadi (metan qimmat). Oddiy mantiq. Xuddi shu narsaning network engineeringdagi nomi Nagle's algorithm deyiladi. Taksi bu TCP segment, talabalar - yuborilayotgan ma'lumot. Oxirgi, to'lmay qolgan segmentga yana data kelmagunicha yoki oldinroq yuborilgan segmentlar uchun ACK kelmagunicha (sheriklari biz Samarqandga yetib keldik demagunicha). Foydali tomoni - resurslar tejaladi. Zararli tomoni - "kimdir" kech qoladi. Delayed ACK esa xuddi shu voqeaning davomi, faqat Samarqandda. Studentlar yetib borganidan keyin yetib keldim deb qolganlarga xabar berishi kerak, lekin xabar berish juda qimmat turadi, studentlar esa tejamkor. Shunda bittasining aqli ishlab qoladi: hamma alohida-alohida telefon qilmaydi, bir kishi telefon qilib hamma kelganlarni aytib chiqadi (Garry, bizning studentlar tejash uchun nimalarni o'ylab topmagan). Lekin u qachon telefon qiladi? Endi telefonni o'chirganida yana bir kishi yetib kelsa u uchun yana alohida telefon qilish kerakku? Oddiy, yana yarim soat (bu bir misol uchun) kutamiz, hech kim kelmasa telefon qilamiz. Xuddi shu narsa networkingda TCP delayed ACK deyiladi. Studentlar segmentda yetib kelgan ma'lumot, telefon esa server tomonidan segment yetib kelgani haqida yuboriladigan ACK signali. Foydali tomoni - resurslarni tejaydi. Zararli tomoni - "narigi taraf" segment yetib kelganini kechroq biladi. Xo'sh, endi qiziq joyi: agar tepadagi ikkita holat bir vaqtda bo'lsa nima bo'ladi. 1 ta student haliyam taksida kutib o'tiribdi. Ketish uchun yo taksi to'lishi kerak, yo yetib borgan sheriklari telefon qilishi kerak. Aksiga olib, boshqa ketadigan odam yo'q, endi sheriklarni kutish kerak. Lekin sheriklar nega telefon qilmayapti? Qizig'i, Samarqandda sheriklari telefon qilmay, hozir sherigimiz kelsa hammamiz bittada telefon qilamiz deb buni kutib o'tiribdi. Bu taksida qolganlarni kutib o'tiribdi, qolganlar Samarqandda buni kutib o'tiribdi, bu nimanidir eslatmayaptimi? DEAD LOCK! Faqat farqi, Samarqanddagilar oxiri sabri tugab, "shuncha kutdik, kelmasang ayb bizdamas" deb telefon qiladi. Taksida o'tirgan talaba buni ko'rib, "4 kishiga to'layman, haydang" deb bir o'zi bitta taksida ketadi. Muammo hal bo'ldi, lekin juda ko'p vaqt bekorchi o'tib ketdi. Xuddi shu narsa network engineeringda ham bo'lib turadi. Bu tarafda sender segment to'lishini kutadi, narigi tarafda reciever ACK yubormasdan qolgan segment kelishini kutadi, natijada connection UZOQ VAQT "qotib" qoladi. P.S. Tepadagi postning ma'nosini tushungan bo'lsangiz, endi kulavering ))

Nagle's algorithm + delayed acknowledgment = ❤️

Xususiy bankdan $1.5M o'g'irlandi va bu katta ehtimol bilan bizning sohamizdagilarning xatosi bilan sodir bo'ldi. Bu qolganlarga dars bo'lishi kerak. Biz esa hamma kanalda anavi .NETchi yigitni muhokama qilayapmiz.

Multithreading is just async implemented on a lower level. Change my mind. P.S. Discussion ochiq deb e'lon qilaman ))

"A Philosophy of Software Design" kitobi muallifi, Stanford universiteti professori John Ousterhout TCP datacenterlarda ishlatish uchun ancha noqulay, Homa protocolga o'tish kerak deb hisoblayapti. E'tiborimni tortgan jihati, paperda TCPning faqat negativ tomonlari, Homaning faqat pozitiv tomonlariga urg'u berilgan. Balki menga shunday tuyuldi. Qiziq, kompaniyalar rostdan ham datacenterlardagi communicationni Homaga o'tkazishga qaror qilsa kim birinchi bo'larkin?

DB haqidagi postga comment: — Backend engineer databaseni yaxshi bilishi qanchalik muhim? Networking haqidagi postga comment: — Bularni backend developer bilishi shartmi? Languagening ichki komponentlari haqidagi postdan keyin: — Bu ancha chuqur narsalar, bu backendchilarga kerakmi? System design haqidagi postdan keyin: — Bu savollar intervyularda so'raladimi? ... O'rtog'lar, bular kerak bo'lmasa backend engineerning vazifasi nima o'zi?😅

oklanib turadi. Bu narsa OSIda 4-qavatda, HTTP esa 7-qavatda. Demak, biz yuborgan 10 ta HTTP request TCP uchun shunchaki bir butun data, u request nimaligini ham bilmaydi. Natijada o'sha 10 ta requestdan birortasi qisman yetib kelmasa ham TCP hamma requestlarni bloklaydi. Bu HOL blocking deyiladi. Bu muammoni hal qilish uchun h3 TCPdan voz kechib, UDP ustiga qurilgan QUIC protocolidan foydalanadi. UDPning o'zida retransmission yo'q. QUIC bu narsani o'zi ishlab chiqdi va buning TCPdagi retransmissiondan farqli jihati, QUIC bitta connection ichidagi HTTP requestlarni bir-biridan ajrata oladi. Natijada request to'liq yetib kelmasa butun boshli connection emas, faqat o'sha request bloklanadi. Xo'sh, shu bilan muammolar tugadimi? Albatta yo'q. Muammolarni yechishda davom etamiz... Bu maqolani yozishdan maqsad HTTPning evolutsiyasi haqida qisqacha ma'lumot berish va sizni bu borada yana izlanishga undash. Xato va kamchiliklarni aytib, feedback qoldirsangiz, xursand bo'laman. Foydalanilgan manbaalar: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP https://en.m.wikipedia.org/wiki/Hypertext_Transfer_Protocol https://datatracker.ietf.org

1990-yillar, internetni faqat ma'lum tashkilotlar orasidagina emas, butun dunyo bo'ylab ishlatish g'oyasi bilan chiqqan WWW endi tug'ilgan vaqtlar. IP, TCP, OSI kabi internetning "building block"lari allaqachon ishlab chiqilgan, lekin WWW uchun standartlar kerak edi. Ma'lumotni foydalanuvchiga yetkazish tili sifatida HTML ishlab chiqildi (va bu tildagi ma'lumotni render qilib, UIda ko'rsatish uchun browser ishlab chiqildi). Networking uchun TCP va UDP kabi transport layer protocollar ishlab chiqilgan bo'lsa ham, tez, yengil, ishonchli va asosiysi, application layerda ishlaydigan protocol ishlab chiqishga ehtiyoj tug'ildi. Shunday qilib HTTP ishlab chiqildi. Dastlabki versiya o'ta sodda va imkoniyatlari kam edi. Path orqali murojaat qilib, serverda turgan faylni yuklab olish mumkin edi xolos (faqatgina GET methodi bor edi). Keyinchalik bu versiyani boshqalardan farqlash uchun HTTP/0.9 deb nomlandi. Keyingi versiyalarga to'xtishdan oldin HTTPning o'zi haqida biroz: HTTP application layerda ishlaydigan, TCP protocoli ustiga qurilgan (h3 gacha), client-server modelini support qiladigan stateless protocol. Nega stateless? Sababi protocol yengil va tez bo'lishi kerak edi. Qiziq, unda nega stateful network protocol (TCP)ning ustiga qurildi? Sababi, protocol ishonchli bo'lishi kerak edi. Davom etamiz. Tim Berners-Lee va uning jamoasining ko'p mehnatlaridan so'ng va nihoyat 1996-yil HTTP/1.0 rasman standart bo'ldi va RFC 1945 sifatida kiritildi. Xo'sh bu versiyaga asosan nimalar kiritildi? 1. Status kodlari. Bu orqali browser request success bo'lgan yoki bo'lmaganini aniqlash imkoni tug'ildi. 2. POST va HEAD methodlari. 3. Request headerlar. Bu juda ko'plab yangi imkoniyatlar eshigini ochdi, masalan, hypertextdan boshqa content typelar bilan ishlash). Jamoa esa tajriba qilishda davom etdi. 1 yildan keyinoq HTTP/1.1 ishlab chiqildi va RFC 2068 sifatida taqdim etildi. O'zgarishlar: 1. Bitta TCP connectionni keyingi request uchun qayta ishlatish imkoniyati. Sababi, TCP connection ochish ancha "qimmat"ha tushadi va bitta connectionni uzoqroq ishlatish kerak. 2. Yangi request methodlari. 3. Content haqida ko'proq metadata. 4. Katta hajmli responseni bo'laklab yuborish imkoniyati. Keyingi yillar davomida WWW ancha takomillashdi, protocolga qo'yilgan talablar oshdi va natijada HTTPga yana ko'plab o'zgarishlar qo'shib borildi. Bir muammo borgan sari jiddiylashib bordi: bir nechta request yuborish uchun avvalgi requestga response kelishini kutib, undan keyingina keyingi requestni yuborish mumkin edi. Natijada client resurslarni olish uchun juda ko'p vaqt sarflashga majbur edi. Buni hal qilish uchun bir vaqtning o'zida 6 tagacha parallel connection ochib, request yuborish imkoniyati qo'shildi. Bu HTTP/1.1 ning 1.0 ga qaraganda eng ustun jihatlaridan biri bo'ldi. TLSni support qilish orqali protocol HTTPS deb atala boshlandi va shunga o'xshash bir nechta juda muhim yangilanishlar bo'ldi. 1.1 juda omadli chiqdi: tez, yengil va muhimi, moslashuvchan. Lekin shu bilan birga ba'zi jiddiy muammolari ham bor edi... 2015-yil, 1.1 versiya yaratilganidan 18 yil o'tib avvalgisidan ancha farq qiladigan zamonaviy protocol – HTTP/2 ishlab chiqildi (RFC 7540). 1.1 ko'plab requestlarni 6 ta parallel connection orqali hal qilgandi, lekin bu endi ancha samarasiz bo'lib qoldi. H2 da bu juda chiroyli usulda yechildi: bitta TCP connectionda bir vaqtda ko'plab request yuborish imkoniyati (bu narsa multiplexing deyiladi) bor va muhimi avvalgi requestga response kelishini kutib o'tirish shart emas! Shunchaki o'nlab request yuborasiz va server birin-ketin javob beraveradi. Responselar aralashib ketmasligi uchun har bir requestga ma'lum ID beriladi va server shu ID bilan response qaytaradi. Ha, bu "game changer" feature bo'ldi. Bundan tashqari juda ko'plab o'zgarishlar bor, qolganini o'zingiz topib o'qiysiz. HTTP/3 yoki xayr, TCP. Request multiplexing juda ajoyib yechim edi, faqat bitta jiddiy muammosi bor ekan. TCP stateful protocol va uni agar dataning bir qismi yetib kelmasa, ma'lum vaqtdan keyin qayta uzatiladi va bu oraliqda yetib kelgan ma'lumot ham