Otabek’s I/O

Google'ga yo'q dedim.
Ha, noto'g'ri eshitmadingiz, Google bergan taklifni rad qildim. Qancha yoshlarni orzusi bo'lgan kompaniyaga men rad javobini berdim.
Google bilan pishirgan ilk oshimiz o'tgan yili bo'lgandi. Kompaniyadan ishga taklif kelgan ammo L4 (middle) lavozimiga, Dropbox taklif qilgan IC4 (Senior) lavozimi balandroq bo'lgani uchun Google bilan karyeramni davom etmadim.
Ammo Google bas kelmadi, men uchun
Tizim Dizayni
intervyusini tashkil qilib berdi. Undan yaxshi o'ta oldim, bu safar L5 (Senior) lavozimiga taklif oldim, ammo Dropbox IC5 (Staff) lavozimga taklif bilan Googleni ortda qoldirdi yana.
Google'dan keyingi qadamni kutib qolaman.
Google'dagi akalar, rekruiterlarga aytinglar, yaxshi oylik va sharoit qilib bersa boraman.

#experience
Let's talk about distributed systems.
Siz distributed system backend qismini qurayabsiz. Client serverga request (so'rov) yuboradi -
API
,
message queue
yoki
event bus
orqali. Ammo bir muammo bor, qanday qilib
request
'ni serveringiz aniq bir marta
process
qilishini ta'minlaysiz?
Eng qiziq muammolar bu yerda faqat u emas balkim:
- Network paketlarni drop qilishi mumkin (tashlavoradi)
- Client retry qilishi (qayta so'rov yuborishi) mumkin
- Server process qilish jarayonida crash bo'lishi (buzilishi) mumkin
- Message ketma-ketligi buzilishi, kech kelishi, yoki 2 marta kelishi mumkin
Agar yuqoridagi muammolarni oldini olmasangiz:
- Client'dan 2 marta to'lov yechishingiz mumkin
- Duplikat ma'lumot yaratib qo'yishingiz mumkin
- Mahsulotni 2 marta yuborishingiz mumkin
- 50 marta notification yuborishingiz mumkin (Twitter bir yili shunday qilgandi, foydalanuvchilar retry sababli chatiga bir xil xabarlar bilan to'ldirilgandi)
Distributed tizimlarda "At-most-once", "At-least-once" va "Exactly-once" degan tushunchalar mavjud. "At-most-once" holatida xabarlar/so'rovlar 0 yoki 1 marta yetkaziladi. Duplikatlarsiz, ammo siz uni yo'qotishingiz (drop) mumkin. "At-least-once" holatida xabarlar 1+ marta yetkaziladi. Yo'qotish yo'q, lekin takrorlanish mumkin. "Exactly-once" holatida xabar bir marta yuboriladi (bu ko'rsatkichga erishish qiyin).
Exactly-once holati deyarli mavjud emas. Siz user'ni
idempotent
qilib fake qilib turasiz. Ya'ni HTTP headerga doim
idempotency token
qo'shasiz. Process qilingan ID'lar tarixini saqlab borasiz. Outbox patter ya'ni event (xodisa)lar ma'lumotlar omborida saqlaysiz va ularni o'sha yerdan olib process qilasiz.
Misol uchun, S3, Google drive, Dropbox kabi tizimlarga ko'pchilik fayllarni yuklashadi. API'lari doim ham barqaror ishlamaydi. Xuddi o'sha PUT yoki POST request bir necha marta yuborilishi mumkin. Har bir obyekt uchun maxsus key va ETag (content caching) bilan yuborishadi. Bu esa
content-based idempotency
deyiladi. Yanada chqur kirsak, kontentlarni bitta qilib yubormaydi, TCP ni chegarasi (65KB) tufayli kontentlar bir nechta iteratsiya qilib yuboriladi va buni MTU deyishadi. Endi tasavvur qiling, brinchi yuklashda 20% yuklandi va crash bo'ldi, 2chisida esa 40% bo'lib crash bo'lsa nima qilasiz. Bu holatlarda ham
content-based idempotency key
ishlatish ko'p muammoni yechadi. Keyingi marta qayta urinishda siz kelgan joyidan davom eta olasiz degani.
System Design intervyularda ko'p yordam bergan shu mavzular menga. Sizga ham foydali bo'lishi mumkin. Bugunchalik kallangizni achitish uchun shu yetadi : )

Boshqalar
: Hamma narsani zo'r eplayabdida shu yigit, malades.
Men
:
🥲

👀
https://t.me/thetechkz/9275

Problem
Har qanday kompaniyada "
onboarding
" jarayoni bor ya'ni sizni kompaniya, jamoa, muhit, va ish qurollari bilan yaxshilab tanishtirishadi.
Mobal.io
kompaniyasidan oldingi barcha ishlagan joylarida o'zimga bir xil gapni takrorlar edim:
-
Tezroq hamma narsani o'rganishim va code contribution qilishim kerak!
Biror yangi mavzuni o'rgansam "
obsessed
" bo'lib qolar edim. Kunlar emas, haftalarni sovurib yuborardim. Bunga asosiy sabab bu berayotgan xato savollarim bo'lardi:
-
How it works (internally)?
-
Why it works (that way)?
Experience
Bu qilgan qarorlarim xatoligini kech tushundim. Ba'zilari esa menga juda qimmatga tushgan. Texnologiyalarni ichini qanday ishlashini tushunish yoki yodlab olish sizni
Senior
qilib qo'ymaydi. Texnik bilimlarni kuchliligi sizni
Senior
qilib qo'ymaydi. Ishonavering,
Senior
bo'lish uchun ko'plab omillar kerak, yaxshi komunikatsiya, jamoa bilan ishlay olish, to'g'ri paytda to'g'ri yechim qilishni ko'ra olish va boshqa (
Soft skill
) tajribalar ham talab qiladi. Men buni kech angladim.
Solution
Onboarding
vaqtida sizdan hech kim, hech qanday ortiqcha ishlar kutmaydi. Siz shunchaki o'zingizdan ko'p narsa kutishingiz mumkin. Jamoa sizni tezroq moslashishingizga yordam berish uchun doim tayyor bo'ladi. Ko'p vaqtingizni tejamoqchimisiz? Unda ushbu 2 savolni bering:
- What and Where?
- Bu servis o'zi nima?
- Nimaga mavjud?
- Qayerda ishlatishim kerak o'zi buni?
... degan savollar to'g'riroq bo'ladi. Har qanday kompaniyada ko'plab texnologiyalar va servislar ishlatiladi. Ularni nimaligi, qayerda ishlatishingizni bilish, sizga boshqa bilimlardan ustunroq xisoblanadi.
Muhtojlik xis qilmaguncha tegmang
. Ha bu xuddi "
kod ishlayabdimi, demak tegmang
" degan gapdek eshitiladi va bu juda to'g'ri fikr. Siz servislarni optimizatsiya qilaman deb ishlab turgan narsani buzishingiz mumkin. Bu esa ishlab turgan biznesni buzishdek gap. Buni
premature optimization
deyishadi (kerakmas bo'lsa ham optimizatsiya qilish).
Ko'plab muvaffaqiyatli startup'lar o'zlari ishlatayotgan servis yoki texnologiyalarni to'liq yoki qisman bo'lsa ham tushunishmaydi. Ammo ular bu servis/texnologiyalarni qayerda ishlatishni, qanday ishlatishni bilishadi.
Dropbox'ga ilk bor qo'shilganimda
Networking & Automation Team
a'zosi edim. Asosiy loyihalarimiz ko'lami cheklangan edi. Ko'p jamoalar, tizimlar bilan ishlash uchun loyiha berishdi. Jamoani bu tizim/texnologiya bilan tajribasi yo'qligi va men ularni o'rganib, tadbiq qila olishim ham ko'p qo'l keldi. Bu tizmlarni qanday ishlashini aniq bilmayman, ammo ularni ishlatish bizdagi muammoni yecha olishini sezib turar edim. Bu ish ham
promotion
olishga katta xissa qo'shgan. Bilaman boshqa omillar ham bor, misol uchun ko'plab
TechTalk
'lar berish va jamoalarni bilmlarini oshirish ayniqsa juda katta role o'ynaydi. Kompaniyamiz CTO'si bilan tanish bo'lishim ham sababchi bo'lishi mumkin : )

#randomThoughts
Bozorda "sun'iy intelekt poygasi" boshlangan. Hamma AI haqida gapirayabdi. Meta eng yaxshi mutaxasislarni jalb qilishga qattiq bel bog'lagan.
Jensen Huang
(CEO at Nvidia)
Machine Learning
va
Computing
uchun eng foydali yo'l bu
CPU
bilan emas, balkim
GPU
bilan ekanini qisman bo'lsa ham ko'ra olgan inson sifatida bilaman. Hozir Nvidia kompaniyasi bozor narxi $4 trillion dan oshibdi, bu Google + Meta va yana bir nechta kompaniyalarni bozor narxi degani.
Hamma AI uchun kurashayotgan bir vaqtda meni bir narsa ko'p e'tiborimni tortayabdi -
"Quantum Computing"
. Agarda kelajakda AGI balkim, ASI ishlab chiqariladigan bo'lsa ular albatta ko'p quvvat va tezlik talab qilishni boshlashiga olib boradi. Bunda GPU lar qanchalik darajaga bora olishini bilmayman, ammo ular nazarimda Quantum chip'larchalik kuchli bo'la olishmaydi deb o'ylayman.
Agar kelajak uchun yaxshi investitsiya qilmoqchi bo'lsangiz, qanchadir vaqtingizni shu sohani o'rganishga ham investitsiya qiling.
Let me know if I am wrong.

#computerNetworking
System Design intervyularda asosan katta tizimlarni qurish haqida gaplashiladi. Butun katta tizimni 45 daqiqada qurish qiyin, ammo uning qaysidir muhim qismiga diqqat qaratish va o'sha qismini yaxshiroq qilib berish nisbatan osonroq.
Siz har qanday servis qurishingizdan qat'iy nazar sizni servisingiz tashqi servislar bilan aloqa qila olishi kerak. Buning uchun sizdan Networking bilimi talab qilinadi. (Ha hozir
hype
bo'layotgan
AI
,
cloud provider
,
cloud computing
,
frontend
,
backend
,
devops
, ... larni barcha networking siz oddiy narsalar bo'lib qolishadi)
Interviewer
: servisingiz
low bandwidth
xolatida ham yaxshi ishlay oladimi?
Siz, ichingizda
: WTH,
low bandwidth
nima?
Bandwidth
bu berilgan vaqt oralig'ida network connection orqali qancha ma'lumot yubora olishingiz xisoblanadi. Misol uchun siz wifi o'rnatish uchun kelishga ISP servis 100Mb/s degan bo'lsa, demak sizni tarmoqingiz ISP dan sekundiga 100 Megabits ma'lumot yuklab ololadi yoki yubora oladi.
Ammo menda bir muammo bo'layabdi. Kecha do'stim yuborgan linkga bosganimda sahifani ochishga 5 soniya vaqtim ketdi. Sahifada katta fayllar mavjud emas ekan. Bu holatda, meni internetim yomon ishlayabdimi?
Yo'q,
high bandwidth
degani har narsani tez yuklaydi/yuboradi degani emas. Bu yerda
latency
degan tushuncha kirib keladi.
Network latency
bu so'rov yuborish va qabul qilish jarayoni uchun ketkazilgan vaqtga nisbatan aytiladi.
High latency
keltirib chiqaruvchi omillar turli xil bo'lishi mumkin: serever side dynamic content'ni compile qilinishi, server-client o'rtasidagi masofa, browser render qilish vaqti, va boshqa faktorlar ham bo'lishi mumkin. Agar software tomonda hammasi yaxshi bo'lsa, demak gap aniq masofada bo'ladi.
Misol uchun Google har qanday mamlakatda yaxshi ishlaydi. Buning sabablaridan biri bu masofa. Ya'ni sizni ISP servisingiz eng yaqin Google servislariga so'rov yuboradi. Shunda low latency bo'lgani xisobiga sizga garantiya berilgan internet o'z o'rnida ishlayotgandek ko'rinadi. Eng yaqin serverlarni joylashtirish jarayoni esa CDN ya'ni Content Delivery Network (Kontent yetkazuvchi tarmoq) deb ataladi.
Global servis qurayotganingizda masofaga albatta e'tibor bering. Chunki dasturingiz qanchalik yaxshi bo'lmasin, masofa uni sekinroq yoki yomonroq ishlar ekan degan tushunchaga sabab bo'lib qolishi mumkin.

#randomThoughts
Hamma havotir olayotgan, katta kompaniyalar tinimsiz bozorda raqobatlashayotgan narsa bu hozir AI. Sizu-biz ishlatayotgan LLM'lar ham aslini olganda bir til. Ularni linguistic, coding, communication, translation, explanation va e.t.c language yo'llarida ishlatishingiz mumkin. Dasturlash sohasini o'sish tarixi doim ajablantirib keladi.
Tarixda ilk yaratilgan dasturlash tillaridan biri bo'lmish
FORTRAN
(FORmula TRANslation) ham asosan matematik xisoblash va shu kabi yo'nalishlarda ishlatilgan. Assemblyda kod yozish juda katta intelektual kuch talab qilinishi xisobiga bunday tillar ishlab chiqilgan. Ha compiler dasturlash tillaridan oldin odamlar 0 va 1 larda kod yozishgan (adashmasam).
Tillar sekin-asta yaxshilanib inson tiliga yaqin tarzda kod yozish imkonini berishi o'sib boraverishini tillarni syntax'idan ko'rsangiz bo'ladi. C'da yozilgan kodni tushunish qiyin ammo Python kabi tillardagi kodlarni shunchaki o'qib tushunish osonroq. Hozir esa AI davridamiz. Siz to'laqonli inson tilida kod yozasiz (deyarli).
"Python bo'lmaydi, C++ o'rganish kerak", "Hech kim C da kod yozmay qo'yadi" kabi so'zlarni deyarli 20-30 yildan beri aytib kelishayabdi ammo ular akutalligini yo'qotishmadi. Xuddi shunday AI ham sizni ishingizni olish uchun emas, balkim siz uchun qulayroq ish muhiti yaratish uchun ishlab chiqarilayabdi deb o'ylayman.
AI ishni olib qo'yish xavfi bormi? Albatta, ammo yangi ish o'rinlari yaratish ehtimoli ham bor (balkim yo'qdir, aniq aytish qiyin). Aniqroq nimani ayta olish mumkin? AI shunchaki yordamchi bo'lib qoladi, to AGI yoki ASI yaratilmaguncha. Chunki AI o'zi, erkin harakat qila olmaydi, fikrlay olmaydi (hozircha).
AI qurish uchun eng zo'r til bu Python deyishadi. Menimcha unchalik ham emas. Shaxsan hozircha ko'rgan katta loyihalarim source kodi asosan Rust yoki C++ da (Dropbox'da ham). Adashmayotgan bo'lsam Anthropic (Claude) va Github (Copilot) ham asosan shu tillardan foydalanadi. Buni sabablari ko'p (qoidalar qattiqligi, xotira boshqaruv, xavfsizlik, resurslar, e.t.c.).
Bu post nimadir o'rgatish uchun emas, shunchaki fikrlarimni yozib qo'yish uchun yozildi. "Nimadir" yozgim kelmadi, o'rniga "random thought of mine" yoza qoldim
🙃

#experience
Software engineering is all about choosing the right trade-off
degan gapni eshitgan bo'lsangiz kerak. Eshitmagan bo'lsangiz, keling men birinchilardan sizga buni isbotlab beray.
AWS
,
GCP
kabi
cloud
servislar 99.95%
SLA
taklif qilishadi. Ya'ni service yil davomida qancha vaqt
up & running
bo'lishini xisoblaydi. Qanchalik 9 lar soni ko'p bo'lsa, bu yil davomida servisda kamroq
down time
bo'ladi (yumalab qoladi) degani. Misol uchun:
☹️
99.9% (uchta to'qqiz) yiliga 8.77 soat yumalab yotadi,
🙂
99.99% (to'rtta to'qqiz) 52.6 minut yumalab yotadi,
😇
99.999% (beshta to'qqiz) 5.26 minut yumalab yotadi,
... va bu ko'rsatkich to'qqizlar soniga qarab pasayib boraveradi. Ammo to'qqizlarni qanday oshiradi u servislar? Well,
vertical
va
horizontally scale
qilish kerak bo'ladi. Bu ko'proq pul (serverlar, tarmoqlar, elektr ta'minotlari, ...),
fault-tolerant design
,
failover systems
, va ko'plab ishlar qilinishi kerak degani. Bular tekinga bitmaydi. Va siz
high availability
'ni taminlash uchun ko'proq pul sarflashingiz kerak bo'ladi. Yo tizimni boricha qabul qilishlarini so'rab pul ishlaysiz, yoki pul ishlatib tizimni yaxshilab keyinchalik pul ishlashni tanlaysiz.
Tasavvur qiling, siz
database
,
table
yaratdingiz va ichiga ma'lumotlar yozdingiz. Ketidan ushbu
query
'ni yuritsangiz nima bo'ladi?
SELECT * FROM students WHERE name = "Otabek"
Butun
table
'ni
scan
qilib sizga to'g'ri, siz so'ragan
row
'ni qaytaradi. Agar ma'lumotlaringiz juda ko'p bo'lsa (100 million row), qidiruv ko'proq vaqt olishi mumkin. Agar name
column
'ni indekslasangizchi? Xuddi o'sha query endi tezroq yurishni boshlaydi (
query
o'zgarmadi, ammo o'qish tezlashdi). O'qish tezlashgani bilan
yozish
,
o'chirish
va
yangilash
(indekslash xisobiga) sekinlashadi. Chunki endi bir emas ikki joyda o'zgarish sodir bo'ladi (
index
va
table
o'zida ham). Biriga erishish uchun ikkinchisiga ko'z yumayabsiz.
K8S orqali servis deploy qilayabsiz.
Rolling Update
strategiyasini tanladingiz. Yangi
deployment
incremental
(birma-bir) yangilanadi va config yozish ham juda oson. Eng asosiysi bu sizga
Zero downtime
(odatda) xissini beradi. Ko'rinishidan juda oson va xavfsizdek. Agar tassavvur qiling, servisingiz noto'g'ri ishlashni boshlasa
pod
'larni
rollback
qilish ham
incremental
sodir bo'ladi. Va ba'zilarda bu nostabil ishlashga sabab bo'lishi mumkin (chunki rollback qilish vaqt oladi va ba'zilarda yangi, ba'zilarda eski versiya ishlagani sabab vaqtinchalik
inconsistency
sodir bo'ladi).
Dasturlashda til, texnologiya, strategiya, tizim, servis, operatsion tizim va har qanday narsani tanlash bu nimagadir ko'z yumish degani (mindey o'ylab qarasam hayotda ham shunaqa ekan). Qaysi biriga ko'z yumishni bilish uchun esa, sizga tajriba kerak. Tajriba qiling!

VeriFy AI
Ochiq kodli, hech qanday kutubxonalarsiz, va o'rganish maqsadida qurilgan
scam detector
.
Loyiha har qanday
AI
va
ML
o'rganmoqchi bo'lganlar uchun. Loyihani tushunish uchun kodni va uyerdagi izohlarni o'qish kifoya qiladi.
1. Loyihani kompyuteringizga clone qiling
2. Uni ishga tushuring va train bo'lishini kuting
3. Xabar yozing, u sizga
scam
yoki
scam emas
ligini aytadi
4. Va albatta
⭐️
bosishni unutmang.
5. Ko'proq open source loyihalar uchun, [follow me]
Batafsil
:
https://github.com/otabekswe/verify