— Lampochkani almashtirish uchun nechta Apple user kerak?
— Kerak emas. Ular yaxshisi yangi uy sotib olaqolishadi.

© Redditdan

— Lampochkani almashtirish uchun nechta dasturchi kerak?
— Kerak emas. OOP prinsiplariga ko'ra lampochka o'zini-o'zi boshqara olishi kerak.

— Lampochkani almashtirish uchun nechta Uztelekom Operatori kerak?
— 1 ta. Sizning tartib raqamingiz to'qson sakkiz.

© Kommentdan

— Lampochkani almashtirish uchun nechta C developer kerak?
— Esing joyidami, ular sham yoqishadi-ku

— Lampochkani almashtirish uchun nechta outsourcedagi developer kerak?
— 2 ta developer olsangiz bo'lsa 1 yilda almashtirib bo'lishadi, 5 ta bo'lsa 4 oyda tugatishadi. Lekin baribir 1 haftadan keyin buziladi.

— Lampochkani almashtirish uchun nechta JS developer kerak?
— 1 ta React developer, 1 ta NodeJS developer. Jami 11 ta.

— Lampochkani aylantirish uchun nechta dasturchi kerak?
— 2 ta. Bittasi lampochkani ushlab turadi, ikkinchisi dunyoni aylantiradi😎

— Lampochkani almashtirish uchun nechta dasturchi kerak?
— Open-close prinsipiga ko'ra lampochkani almashtirish mumkin emas. Yaxshisi, yoniga yana bitta lampochka qo'sh.

Qaysi manbaalardan ma'lumot olishni, qanday qilib o'rganishni, qanday qilib "zo'r" dasturchi bo'lishni so'rab tez-tez yozib turishadi. Odatda, faqat resurs beraman. Qanday qilib o'rganish, qanday qilib dasturlashni "his qilish" haqida esa iloji boricha maslahatlar (tips) bermaslikka harakat qilaman. Nega?

Well, men sizga bera olishim mumkin bo'lgan maslahatlar albatta, o'z tajribamdan o'tgan va qaysidir darajada foyda (yoki zarar) bergan caselardan chiqarilgan xulosalar to'plami. Ularni shartli ravishda 2 ta turga bo'la olaman:
1. Hamma uchun ishlaydigan "universal" tavsiyalar.
2. Menga bog'liq faktorlari mavjud bo'lgan tavsiyalar.

Keling, bu ikkalasini biroz analiz qilib ko'ramiz.
1. Hamma uchun ishlaydigan tavsiyalar. Masalan, ko'proq kitob o'qing, dissipliniya bilan o'rganing, dunyoqarashingizni kengaytiring yoki shunga o'xshash. Gap shundaki, bu gaplarning deyarli barchasi hamma (shu jumladan siz ham) biladigan, lekin ko'pchilik amal qilmaydigan gaplar. Siz allaqachon biladigan, lekin amal qilmaydigan gaplarni yana bir marta aytishdan nima foyda? Shuning uchun bunday tavsiyalarni bermayman (agarda kitob o'qish foydali ekanini bilmaysiz deb o'ylamasam).

2. Mening vaziyatimga bog'liq bo'lgan tavsiyalar. Masalan, men bilan bo'lganidek self-study qiling, top-down approachda o'rganing yoki PHPni emas Pythonni tanlang degan gaplarni aytishim mumkin. Sababi, men aynan shunday qilayapman. Lekin gap shundaki, bu tavsiyalar menda "ishlashi"ga ta'sir qilgan intellektual, iqtisodiy, diniy va hatto geografik faktorlar ham bor. Menga foyda bergan usullar sizga foyda bermasligi yoki umuman teskari natija berishi ham mumkin. Shu sababdan ham muvaffaqiyatga erishishning yagona qoidalar to'plami yo'q (aks holda hamma muvaffaqiyatli bo'lgan bo'lardi). Bu degani, agar siz butun hayotingiz davomida xuddi Elon Musk, Einstein yoki Al Xorazmiyga o'xshab yashasangiz ham ular kabi muvaffaqiyatli bo'lmasligingiz mumkin.

Xo'sh, "sizga maslahat bera olmayman" deyish uchun shuncha gapni yozdimmi? Albatta yo'q. Balki boshqalar yurgan yo'lni roadmap qilib olgandan ko'ra ulardan va o'zingizning shu vaqtgacha yurgan yo'lingizdan xulosalar chiqarib, o'zingiz uchun roadmap tuzing. "Muvaffaqiyat siri"ni izlagandan ko'ra bu yo'ldagi muammolaringizni analiz qilib, yechim toping. Masalan, ko'pchilik 10 minutdan ko'proq kitob yoki article o'qiy olmasligini aytib shikoyat qiladi. Lekin bu muammoning sababi boshqa muammo(lar). Masalan, attention span kamligi bo'lishi mumkin. Lekin nimani boshqa narsalarga chalg'imasdan 2-3 soat qila olasiz? Social media? Tabriklayman, siz ko'pchilik (men ham) chalingan, allaqachon bir nechta yechimlar topilgan, lekin juda kamchilik qutula oladigan "kasallik"ka chalinibsiz. Masalan, social media addictionga qarshi dopamine detox qilishingiz mumkin. Dopamine detox esa discipline talab qiladi. Sizda discipline yo'q bo'lsa avval bu muammoni hal qilishingiz kerak bo'ladi. Xullas, muammo/sabablardan iborat bu linked list hali ancha cho'zilishi mumkin. Muammolarni hal qilishni qancha chuqurroqdan boshlasangiz shuncha "solid" yechim qilgan bo'lasiz, faqat asosiy maqsaddan chalg'ib qolmang.

Xullas, "muvaffaqiyat formulasi"ni boshqalardan qidirmang. Izlaning, xato qiling, analiz qiling va davom eting. Bollar, biz yutamiz.

Bugun Pythonda bir narsani test qilayotganda qiziq holatga duch keldim.
Men bilishimcha Python thread bu OS thread ustiga qurilgan instance va bitta CPU coreda ishlaydi.
Lekin AYNAN bitta coreda turib, faqat shu coreda ishlaydimi yoki bir vaqtda QAYSIDIR bir coreda ishlab, birozdan keyin boshqa coreda ishlashi mumkinmi shuni topa olmadim.

Buni tekshirish uchun sistemadagi loadni minimallashtirib, CPU-intensive threadlar va processlarni bir nechta kombinatsiyada run qilgan holda CPU loadni kuzatdim. Natijalar meni hayron qoldirdi:

a) Single thread, single process. Bir vaqtda 1 ta CPU corega load tushdi, lekin o’sha load tushgan core almashib turdi. Masalan, hozir 1-coreda load bo’lsa birozdan keyin 2-corega load tushdi. Demak, OS thread ishlash davomida u ishlayotgan CPU coreni almashtirdi deb xulosa qilish mumkin.

b) Multiple thread, single process. (2, 3 va 4 ta threadda sinab ko’rdim). Bir vaqtda 1 ta corega load tushdi, lekin qizig’i load tushgan core o’zgarmadi. Ya’ni process boshidan oxirigacha aynan bitta coreda ishladi.

c) Multiple thread, multiple process (har birida 1 tadan thread bo’lgan 2-4 ta processda sinadim). Bir vaqtda bir nechta corega load tushdi va active corelar o’zgarib turdi. Masalan, hozir 1, 2, 3 corelar ishlayotgan bo’lsa, birozdan keyin 2, 4, 5 corelar ishlayapti.

Bu tajribadan keyin menda 3 ta savol tug’ildi:
1. Process ishlash davomida 1 ta coredan boshqasiga o’tadimi va agar shunday bo’lsa nega? Agar shunday bo’lsa, bu kim tomonidan bajariladi? Application, OS yoki undan ham pastroqdami?
2. Agar process ishlayotgan core OS tomonidan almashtirib turilsa unda resourcelar (RAM va balki CPU cache ham) qanday qilib share qilinadi?
3. Agar shunday bo’lsa nega multi thread, single process holatda (b) core o’zgarmadi?

Agar shu narsalar haqida ko’proq ma’lumot yoki resurs bilsangiz, kommentlarda qoldirsangiz xursand bo’lardim.

Bugun volatile memory haqida juda qiziq ta'rif o'qib qoldim:

No money – no honey,
No power – no memory.

© Manbaa

Pythonda yozilgan bu kodda juda chiroyli xatolik bor. Uni topa olasizmi?

P.S. Pythonda yozilgani xatolik emas ))

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. Stateful bo'lish esa protocolni og'irlashtirish va sekinlashtirishga olib keladi. Qiziq, unda nega stateful network protocol (TCP)ning ustiga qurildi? Sababi, protocol ishonchli bo'lishi kerak edi. TCP state orqali data to'liq yetkazilishini ta'minlaydi. 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 bloklanib turadi. Bu narsa OSIda 4-qavatda sodir bo'ladi, 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 (RFC 9114) 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. Sababi, QUICning o'zida multiplexing xususiyati bor va u retransmission bilan bitta layerda joylashgan. 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

P.S. Tanishlarga share qilinoradi 🙂

Anchadan beri chuqur texnik mavzularda post yozmadim.
Qaysi texnik mavzularda yangi maqola kutayapsiz?

Most of the time, it is not a good idea to use UUIDs in a centralized(single node) databases until it’s really needed.

@boboshersnotes

IP vs MAC
Yoxud birga ishlashga nima yetsin

Taxminan 50 yillar oldin bitta tarmoq orqali 2 tadan ortiq qurilmalar orasida ma’lumot almashish usuli o’ylab topildi. Lekin ma’lumotni aynan kerakli qurilmaga yuborish uchun har bir qurilma uchun unikal bo’lgan address kerak edi. Shu sababdan MAC address ishlab chiqildi. Agar device A device B ga ma’lumot yubormoqchi bo’lsa, ma’lumotni frame deb atalgan “quticha”ga soladi va “Bu ma’lumot device B uchun” deb belgilab, device B ning MAC addressini qo’shib yuboradi. Qizig’i, bu frameni networkdagi hamma device oladi. Lekin ochishdan oldin u yerda ko’rsatilgan MAC addressni o’ziniki bilan solishtirib ko’radi. Masalan, device C frameni qabul qiladi, lekin bu device B uchun ekanini bilganidan keyin ochmasdan, tashlab yuboradi. Natijada, faqat device B unga yuborilgan ma’lumotni o’qiydi.

MAC address orqali ma’lumot almashish yaxshi g’oya edi, lekin tarmoq hajmi kattalashgan sari bu usul samarasiz bo’lib boradi. Sababi, agar tarmoqda minglab device bo’lsa har bir device tarmoqda yuborilgan har bir frameni qabul qilishiga va tekshirishiga to’g’ri keladi. Bu esa juda ineffektiv.

Tarmoqdagi devicelar soni millionlab bo’lganida esa faqat MAC address orqali ma’lumot almashish ilojsiz bo’lib qoladi. Endigi vazifa katta, tekis tarmoqni bir necha qavatlardan iborat “tree” shaklida kichik qismlarga bo’lib tashlash va shu orqali ma’lumotni butun tarmoqqa emas, aynan kerakli device joylashgan qismga yuborish. Buning uchun IP address ishlab chiqildi. IP addressning MACdan asosiy ustun jihati u MAC kabi shunchaki tasodifiy raqamlar ketma-ketligi emas, ma’lumotni qayerga yuborishni ko’rsatuvchi address edi. Masalan, menga USdan “O’zbekiston, Toshkent shahri, falon ko’chasiga” deb pochta yuborilsa, pochta tizimi bu address orqali meni qayerda topish mumkinligini biladi, ular meni Berlindan yoki Samarqanddan izlashmaydi. IP address ham xuddi shunga o’xshash, u orqali reciever taxminan qaysi kontinentda turgani, qaysi internet providerdan foydalanayotgani aniqlanadi va ma’lumot hammaga emas, aynan kerakli joyga yuboradi. Lekin faqat IP addresslardan foydalanib internetni qurib bo’lmas edi. Hozirgi internet esa ikkalasini qo’shib ishlatadi: global tarmoq uchun IP address orqali, lokal tarmoqda MAC address orqali yuboriladi. ARP protocoli esa IP va MAC addresslar orasida “tarjimon” vazifasini bajaradi.

P.S. Yuqorida yozilganlar bu narsalar aslida ishlashidan ko’ra minglab marta sodda tushuntirilgan va shu sabab ba’zi qismlari haqiqatdan biroz farq qiladi.

@boboshersnotes