Otabek’s I/O

#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 emasligini aytadi
4. Va albatta ⭐️ bosishni unutmang.
5. Ko'proq open source loyihalar uchun, [follow me]

Batafsil: https://github.com/otabekswe/verify

Claude 4 sinab ko'rdim, u qilgan ishlar miyyamni portlatvoray dedi 🤯

Butun boshli codebase'ni bitta prompt orqali yangilab chiqdi. Kodlarni modular qilib ajratdi, test yozdi va katta chalkash funksiyalarni, kichik va chiroyli funksiyalarga bo'lib chiqdi.

git add -A
git commit -m "enhance code quality and modularity"

Kodni ishga tushurib ko'rganimda hech nima ishlamadi 😬, lekin malades, shuncha yaxshi ish qilib chiqdi. Ha do'stlar, biz shunday ajoyib AI davrida yashayabmiz.

git reset --hard HEAD~1

#experience

Ikki hafta oldin kompaniyada TechTalk’da "Memory leak" mavzusida ma’ruza berdim. 51 ta turli xil jamoalardan muhandislar kirib eshitishdi, to‘g‘risi ancha qo‘rquv bosdi. Memory leak juda nozik mavzu, agar siz ishlatayotgan tilni mohiyatini yaxshi bilmasangiz xotira bilan ishlashda juda chiroyli muammolarga duch kelishingiz mumkin. Biz asosan Python va Go tillaridan misollar ko‘rib ketdik.

Online meeting orqali qatnasha olganlar juda ajoyib feedback yozishdi. Ularni har hafta o‘qib maza qilyapman. Ma’ruzamning videosi chiqqanidan so‘ng tomosha qilganlar ham yaxshi xabarlar yozishdi, ammo bir yigitni xabari e’tiborimni tortdi. U bu ma’ruzadan keyin tizimdagi memory leak’ni topishga muvaffaq bo‘lgan. 

Ular ishlaydigan tizim kodi Java’da yozilgan ekan. Bilamizki Java ham Garbage collected til hisoblanadi. GC xotirani tozalash uchun reference counting dan foydalanadi. Agar obyekt ishlatiladigan bo‘lsa uni reference count odatda +1 ga teng bo‘ladi. GC juda aqlli bo‘lgani bilan, benuqson emas. 

U yozgan xabarda inner class yozish va uni xotiraga ta’siri haqida gap ketgan. Men uning ma’ruzamda memory leak’ga sabab bo‘lishi mumkinligi haqida misollar bilan yoritib o‘tgan edim. 

Muamo outer class obyekti o‘chib ketganiga qaramay inner class obyekti ishlatilishda davom etishida. Qanday qilib inner class obyekti o‘chib ketmadi deyishingiz mumkin. Sabab, unga reference saqlanib qolgan (ref count +1). Dastur to‘laoqnli to‘g‘ri ishlashini ta’minlash uchun uni o‘chib ketishini ham o‘zingiz dasturlashingizga to‘g‘ri keladi. 

Yana bir bola o‘zining frontend loyhasidan memory leak topganini yozibdi. Closures - outer scope’dagi o‘zgaruvchilarni eslab qola oladi. Agar obyektni saqlab qolsangiz, u reference qilgan qiymatlar ham o‘chmay saqlanib turaveradi degani. Agar ehtiyot bo‘lmasangiz Javascript kodingiz, browser’da leak’ga sababchi ishlar qilishi juda osonligini ko‘rdim. U yuborgan koddan parcha:

function setup() {
  const bigData = new Array(1e6).fill(’leak’);

document.getElementById(’btn’).addEventListener(’click’, function () {
    console.log(bigData[0]);
  });
}

Bunday muammolar ko‘p. Ma’ruza berish orqali faqat o‘rgatmadim, balkim ko‘p o‘rgandim ham. Videoni ommaviy ulashish imkoni bo‘lsa, ulashishni reja qilib turibman. Sizga ham bir parcha tajriba ilindim : )

Promotion oldim 🎉

Dropbox'da ish boshlaganimga ko'p bo'lmadi. Shu paytgacha Core Team a’zosi sifatida 2 ta katta loyiha ustida 2 jamoa bilan ishladim: Network Engineering Team va Infrastructure Team.

Ha Big Tech'da (hammasida ham emas) siz asosiy va qo'shimcha loyiha sifatida yana bir loyiha bilan ishlasangiz bo'ladi va biz uni ToD (Tour of Duty) deb ataymiz.

Polshada hiring juda ko'paydi va bu interviewer bo'lish uchun zo'r imkoniyat ochdi. Hozirgacha 5 ta interview o'tkazdim. 2 tasida shadow va 3 ta interviewer sifatida. Yaxshi tomoni ko'p narsa o'rgandim. Yomon tomoni men o'tkazgan intervyulardan kandidatlar yaxshi perform qila olishmadi (yaxshi kandidat uchramadi).

Sizni o'sishingiz doim ham siz ishlayotgan loyihaga bog'liq emas, balkim menejeringizga ham juda katta bog'liqligi bor. Meni omadim kelib, yaxshi menejerlar uchrab qoldi. Va bugun ularni menga bergan yordamlari bilan Staff Software Engineer (IC5) lavozimiga ko'tarilayabman (Avgust oyidan).

Yaxshi loyihada ishlash yaxshi, ammo loyihani o'sishini (company impact) va loyiha menejerini jamoaga bo'lgan e'tiborini ham inobatga olish juda muhim ekan. Shuning uchun intervyuda faqat kompaniya/menejer sizni emas, siz ham kompaniya/menejerni intervyu qilishingiz muhim.

To'g'risi, agar kimdir "24 yoshingda Staff Software Engineer bo'lib ishlaysan" deyishsa "qo'ysangizchi-ye" degan bo'lardim.

Yig'ilgan tajribalarni esa tez kunlarda 42.uz va otabek.io da bo'lishib o'tamiz.

otabek.io v2.0 🎉

- Podcast va Talklar uchun sahifa [Talks]
- Kodlarni yuritib ko'rish (execute) imkoniyati
- Yanada tezroq va interaktivroq
- Bloglar endi Ingliz va O'zbek tilida
- Dark & Light theme

Shunchaki blog o'qish va undagi kodlarni ko'rib o'tib ketish juda zerikarli. Ammo endi bunday bo'lmaydi.

Sinab ko'ring 😉

▶️ #podcast

Vohid aka yangi podcast chiqaribdilar.

Ularni aytishi bo’yicha, bu yigit eng yosh Seniorlardan emish. Siz ko’rishingiz kerak bo’lgan eng yaxshi podcast shu bo’lishi mumkin emish:

https://www.youtube.com/watch?v=UKUHx5P3ISk

#experience

Bizning jamoa infrastrukturadagi dasturlarni maintain (qo'llab quvatlab turadi) qiladi. Ish boshlaganimdan 3 oy o'tib menga ham networking'da bir qiziq loyiha berildi va loyiha kodi asosan Rust'da yozilgan ekan (undan oldin asosan C++ da bo'lgan ekan yechim). Loyihani tushunib olishga va Rustga ko'nikishga biroz vaqt ketdi.

Loyiha maqsadi asosan kuniga bir necha ming terabaytlab ma'lumot almashadigan serverlar o'rtasida reliable (ishonchli) yechim qilish bo'lgan. Bu juda katta masshtabli loyiha. Loyihada socket connection, encoding/decoding, async support, va juda ko'p boshqa omillar ro'l o'ynashini juda qiziq dokumentatsiya qilib yozib chiqishgan ekan.

Ushbu loyiha uchun, Go GC (Garbage collector) bor tillardan xisoblangani uchun unda latency (kechikish) tez-tez uchragan ekan (GC spikes), ayniqsa uni grafana bilan monitoring qilganda juda bilindi. Xotiradan ishlatilmayotgan ma'lumotlar darhol o'chishini o'rniga GC ni uyg'onib xotirani scan qilishini kutadi va natijada latency baydo bo'ladi.

Rust meni lol qoldirgan tomoni bu CC (Concurrency Control) bo'ldi. Race condition dan Compile-time da qutilish imkoniyatini berar ekan. Yana bir tomoni Go'da Goroutine'lar runtime-managed, Rust esa sizga threading model tanlash va boshqarishni manually imkon beradi (o'z tabingizga qarab ishlatasiz degani). Data sharing bo'yicha ham Send va Sync yechimlari o'ta go'zal ishlagan, sizga resourslar aro ma'lumotni bo'lishishni ham o'zingiz tanlaysiz (o'zingiz boshqarasiz).

Rust'ni maqtash emas shunchaki undagi xotira bilan ishlash (Memory control) tizimi shunchalik yaxshi ishlaganini va nima uchun ayan Rust memory safe ekanligini qisman, aniqroq tushunib oldim deb o'ylayman.

Misol uchun Go dasturlash tilida mana bunday ish qilsangiz nimalar bo'ladi:

go handleConnection(conn)

Hozir siz:
- gorutine'lar (map, slices, counters, ...) o'rtasida state share qildingiz
- Agar to'g'ri lock qila olmasangiz, data race yuzaga keladi.
- Channel buffer juda kichik bo'lsa, deadlock'ga sabab bo'ladi
- Goroutine leak bo'lsa, silent memory bloat (dastur siz o'ylagandan ko'ra ko'proq resurs yeyishni boshlaydi) sodir bo'ladi

Bunday ishlarni to'liq o'z nazoratingizga olishingiz uchun sizga low-level til kerak bo'ladi, misol uchun Rust yoki C++. O'sha loyihani 25-30% hali ham C++ da turadi, Rust'ni tanlashganini yana bir tomoni aynan o'sha modellarni extend (kengaytirib) qilib ishlatish bo'lgan bo'lsa kerak.

Post ancha uzunroq va sizga tushunarsizroq bo'lgan bo'lishi mumkin. Ammo xavotir olmang, otabek.io da bunday postlarni tushunishingiz uchun ko'proq soddaroq postlar yozishga harakat qilaman. Rust'ni doim ishlatmasakda ammo o'rganayabmiz sekin-asta. Shuning uchun xatolar bo'lsa tushunasiz deb o'ylayman.

#experience

Twitterda, boshqa kichik chatlarda va savollar ichida eng mashxurlaridan biri bu dasturlash tili tanlash haqida bo'ladi. Men o'z tajribamdan kelib chiqib sizga bir maslahat bermoqchiman.

Agar siz kamroq xato qilishni va kod yozishni, ko'proq va tezroq natija olishni istasangiz JavaScript va Python eng zo'r tillar xisoblanadi.

Dasturlaringizda kamroq bug'lar chiqishini va yaxshiroq ishlashini istasangiz sizga qattiqo'l va ma'lumotlar turiga juda qattiq e'tibor beradigan til kerak bo'ladi, misol uchun Java. Java ham interpreted ham compiled til xisoblangani uchun interpreted tillarga nisbatan tezroq va xavfsizroq.

Agar sizga xotira bilan ishlay oladigan (pointers) ammo GC (Garbage collector) til kerak bo'lsa demak siz Go ni tanlashingiz kerak. Go juda tez va juda ko'p boshqaruvni o'zingizga olishingiz uchun imkoniyat beradigan tillardan. Shuning uchun siz Java ni emas balkim Go ni ko'plab infrastruktura leveldagi dasturlarni ishlab chiqishda ishlatilayotganini ko'rasiz.

Agar sizga real-time ishlaydigan va juda tezkor dastur qurish kerak bo'lsa GC'dan voz kechgan tillarni tanlashigniz kerak misol uchun Rust va C++. GC mavjud bo'lgan tillarda dasturingiz orada pauza qiladi, chunki xotirani scan qilib undagi keraksiz ma'lumotlarni tozalash ham katta resurs xarajat qiladi. Shuning uchun ham Telegram C++ ni tanlgan (boshqa sabablar ham bor albatta).

GC ni ko'p kamchiliklari bor aynan gap performance va resource usage haqida ketganda

Meta programming yoqtiradiganlar bor bo'lishi mumkin. Qoidalar yozish, xotira boshqaruvi, system call'lar, embedded system bularni barchasi uchun C va Zig ideal til. Ammo bu tillar bilan o'zingizga pichoq tiqib olishingiz ham mumkin, juda ehtiyotkorlik talab qiladi, chunki bularda hech qanday chegara yo'q.

Perfeksionistlar uchun Haskell tavsiya qilinadi, bu til haqida boshqa gap yo'q menimcha ; )

O'ta performance shaydosi va sabrli bo'lsangiz, COBOL yoki Assembly da kod yozing.

Bu fikrlar 100% to'g'ri bo'lmasligi mumkin, ammo shaxsiy tajribamdan ko'rganlarimni bo'lishdim, siz nima fikrdasiz?

Xabarchi botga keladigan, eng ko'p so'ralgan savol bu:
Nimaga aynan Dropbox'ni tanladingiz?

Mening javobim:
Ko'p kompaniyalar ichidan aynan Dropbox'ni taklifi qiziqroq bo'ldi. Doim katta bosim (high load)ni ko'taruvchi tizimlar qurishda qatnashishga, high-level dan low-level ga o'tishga qiziqib kelganman. Biz bilgan o'sha mashxur data structure va algorithm bilimlarni amaliyotda qo'llashga qiziqqanman. Dropbox bu imkoniyatni qaysidir ma'noda berayabdi. Keyinchalik olayotgan tajribalarimdan ba'zilarini bo'lishib borishga harakat qilaman.

Bilaman ko'p joylardan ishga taklif oldim. Google'ga ishga taklifim hali ham o'z kuchida, Sentyabrgacha bir qarorga kelishimni kutishayabdi. Meta ishga taklifimni internshipga o'zgartirishga harakat qilib ko'rdim, o'xshamadi, rad javob oldim, taklif kuyib ketdi. Undan tashqari yaqinda Atlassian'dan ham ishga taklif oldim Polshadagi jamoaga (Compass mahsuloti & jamoasi uchun), shunchaki qiziqishga topshirib ko'rgandim, o'xshab ketdi.

Olgan xulosalarimdan biri bu:
zo'r kopaniyada ishlashni emas, zo'r mahsulot ustida ishlashni tanlang, yutqazmaysiz. Yo'q degandan zerikmaysiz.

#experience

Kecha qiziq ishlar bo'ldi. Jamoada ansible bilan file transferda muammo bo'layotgani, bandwith oshib ketgani haqida aytishdi. Ya'ni muammo juda ko'p fayllar tarmoqda transfer bo'lsa bandwith oshib ketayotgan ekan. Bu muammoni o'z zimmamga oldim. Ozgina research qilib, bergan yechimim jamoani qiziqtirdi. Muammoga yechimni juda oddiy tilda yozdim: compress (archive all files) before sending

Yechimni discuss qildik va ba'zi pointlarga to'xtalib o'tdim. Bir nechta fayllarni yuborish o'rniga barchasini (compress) archive qilib yuborish yaxshi idea bo'ldi. Jarayonni to'liq test qilib ko'rdik, natija 1 minutdan -> 20 sekundga tushdi. Boshida HTTPS beradigan TLS xavfsizligi yaxshi deb turgandim. Ammo bu faqat file transfer vaqtidagina xavfsiz, fayl manzilga tushgandan keyin u ochiq bo'lishini aytishdi. Ba'zi fayllarni hech kim ocholmasligi kerakligi uchun uni Private (va Public) keydan tashqari encrypt/decrypt qilish uchun imkoniyat qo'shdim.

Kattaroq va ko'proq fayllar bilan sinab ko'rdik (log, va juda ko'p config fayllar bilan), natija juda zo'r. Eski holatdagi o'tkazish uslubi 3 minut oldi. Yangi xolatdagi o'tkazish esa 43.12 sekund. Compression algoritmlari haqida yana ham ko'proq narsa o'rganib chiqdim, qiziq tajriba bo'ldi.

Qiziq narsa eshitdim: Lucerne shahridan Zurich shahrigacha har kuni poyezd orqali 1TB ma'lumot berib yuborilar ekan. (Esimda qolmadi nomi) Qanaqadir labaratoriya va uni tahlil qiladigan korpuslar boshqa-boshqa joyda joylashgani uchun, tarmoq orqali ma'lumotni yuborgandan, uni poyezda yuborish tezroq bo'lar ekan. Chunki uni hali process ham qilish kerak, unga ham vaqt oladida.

Updated:
Katta Data Center levelda ham test qilib ko'rdik, natija 1000x bo'ldi. Ya'ni bu yerda time complexity O(days) -> O(minutes) o'zgardi.

Strawberry Test

Dropbox'da Core Teamda ishlayman. Bizni jamoa butun kompaniyani infrastrukturasini ko'tarish uchun dastur ishlab chiqadi va maintain qiladi. Undan tashqari jamoa AI ustida ham ishlashadi.

Suniy intelektda tokenization jarayoni mavjud. Siz AI'ga matn yozganingizda, matnni kichik bo'laklarga bo'lib oladi va har bir bo'lakni token deb xisoblaydi. Misol uchun "Salom mening ismim Otabek" -> ["Salom", "mening", "ismim", "Otabek"]. Bu jarayon faqat matn uchun emas balki so'z uchun ham, harflar uchun ham ishlaydi. "AI" -> ["A", "I"]. Machine learning modelingiz bu matnni tezroq tahlil qila olishi uchun shunday qilinadi. (Bu qisqacha ma'lumot)

Ayanan shu tokenization jarayonni qanchalik yaxshi qilinayotganini Strawberry test orqali aniqlashar ekan. Ha, AI tokenization jarayoni uchun ham test yoziladi. Siz AI'ga "How many r's in strawberry" deysiz. U esa sizga to'g'ri javob berishi kerak. Ammo nimaga aynan "strawberry"?

"strawberry" so'zi o'zi juda qiziq so'z ekan. Tahminan shunday ["straw", "berry"] token bo'lar ekan. Bu degani ikki so'z ham nimanidir anglatadi va AI aynan shu yerda aldanadi. Yaxshi tokenizatsiya qiluvchi AI model esa buni bitta so'z sifatida ham qaray olishi kerak. Agar siz yaratgan AI model "r" lar soni 1ta desa demak yaxshi tokenizatsiya qilmayabdi ekan.

Tayyormisiz?

FAANGda intervyu olish jarayoniga doim qiziqardim. Senior Software Engineer bo’lganim uchun bu yildan intervyu olishim kerakligni aytishdi (Technical va System Design). Yaxshi intervyu uchun nimalar kerak:

• STAR metodi bo’yicha javob berishni mashq qiling
• Muloyim bo’ling
• Texnik bilimlaringizni sayqallang
• Muammoni yechishdan oldin aniqlashtiruvchi savollar so’rang
• Muammoni va yechimni shoshilmay, yaxshi tushuntirib bering
• Eng asosiysi shashilmang!

Intervyudan o’tish sirini sizga fosh qilib qo’ydim. Agar bu ma’lumotlar sizga foydali bo’lib offer olsangiz, menga ham yozib qo’ying.

Haqiqiy askar intervyuga tayyorlanmaydi, doim intervyuga tayyor turadi.

Intervyuda ko’rishguncha.

Keling tanishamiz!

Anchadan beri auditoryia bilan jonli suxbat qilish uchun vaziyat izlab kelaman. Ushbu onlar keldi deb o'ylayman.

Sizlar uchun sessiya yaratdim, va ushbu sessiya davomida dasturlashga tegishli bo'lgan ba'zi mavzular haqida gaplashamiz. Joyingizni hoziroq band qiling!

Joylar soni: 30 ta
Mavzu: Habits & Algorithms

🔗 Sessiyaga yozilish

otabek.io endi bizniki 🥲