Forwarded from Azim Pulat
Million inson uchun tizimlar qanday quriladi?
Videoda:
- Barcha kompaniyalarda uchradigan kengayishdagi muammolar
- Kam xarajat bilan ko'plab insonlarga xizmat ko’rsatish
- Amazon, Facebook, Googledagi tizim dizaynidagi tajribalarim
- Tizim Dizaynini qanday tizimli o'rganish
haqida gapirdim.
Havola: youtu.be/g2g62uyBp88
Videoda:
- Barcha kompaniyalarda uchradigan kengayishdagi muammolar
- Kam xarajat bilan ko'plab insonlarga xizmat ko’rsatish
- Amazon, Facebook, Googledagi tizim dizaynidagi tajribalarim
- Tizim Dizaynini qanday tizimli o'rganish
haqida gapirdim.
Havola: youtu.be/g2g62uyBp88
Forwarded from Jakhongir Rakhmonov - IT
Parallel va Async Dasturlash Asoslari
Multi-threading, multi-processing, GIL, async/await haqida gaplashdik.
Rust va Python da multi-threaded kodlar yozib solishtirib chiqdik.
Video uchun havola:
https://www.youtube.com/watch?v=O7REBjE1Jhs
Multi-threading, multi-processing, GIL, async/await haqida gaplashdik.
Rust va Python da multi-threaded kodlar yozib solishtirib chiqdik.
Video uchun havola:
https://www.youtube.com/watch?v=O7REBjE1Jhs
YouTube
Parallel va Async Dasturlash Asoslari. Birinchi Qism.
Ushbu videoda parallel va async dasturlashning mental modelini yasaymiz.
Operatsion sistemadan boshlab, Python va Rust tillarida yozilgan haqiqiy misollar yordamida parallel va asynxron dasturlar nimaga aynan shunday tarzda o'zini tutishini ko'ramiz.
Multi…
Operatsion sistemadan boshlab, Python va Rust tillarida yozilgan haqiqiy misollar yordamida parallel va asynxron dasturlar nimaga aynan shunday tarzda o'zini tutishini ko'ramiz.
Multi…
Forwarded from Otabek Kholmirzaev 💻
GitHub’dagi bu Repoda oxirgi 3 oy ichida qaysi kompaniyalar intervyularda qaysi LeetCode savollarini berganini bilib olishingiz mumkin.
Intervyuga oz vaqt qolganda LeetCode dagi hamma savollarni yechmasdan o'zingiz topshirayotgan kompaniya beradigan savollarni bu yerdan ko'rib ishlashingiz mumkin.
@Otabek_Kholmirzaev
Intervyuga oz vaqt qolganda LeetCode dagi hamma savollarni yechmasdan o'zingiz topshirayotgan kompaniya beradigan savollarni bu yerdan ko'rib ishlashingiz mumkin.
@Otabek_Kholmirzaev
🔥1
Unlimited storage using Telegram as a backend.👀
Simply log in using your Telegram ID
https://github.com/inulute/unlim-cloud
Simply log in using your Telegram ID
https://github.com/inulute/unlim-cloud
GitHub
GitHub - inulute/unlim-cloud: UnlimCloud provides unlimited cloud storage for your files, utilizing Telegram as the storage solution.…
UnlimCloud provides unlimited cloud storage for your files, utilizing Telegram as the storage solution. Simply log in using your Telegram ID, and you are good to go. - inulute/unlim-cloud
Saw a very cool tool on GitHub called PortKiller. It’s a powerful cross-platform port management app for developers, with a native UI on macOS, Windows, and Linux.
What makes it fun is that it goes beyond just listing ports. It auto-discovers all listening TCP ports, lets you kill processes with one click, supports search and filtering, favorites, watched ports with notifications, and smart categorization for common dev services.
It also covers real workflows: managing kubectl port-forward sessions with auto-reconnect, logs, and connect or disconnect notifications, plus visibility into active Cloudflare Tunnel connections.
https://github.com/productdevbook/port-killer
What makes it fun is that it goes beyond just listing ports. It auto-discovers all listening TCP ports, lets you kill processes with one click, supports search and filtering, favorites, watched ports with notifications, and smart categorization for common dev services.
It also covers real workflows: managing kubectl port-forward sessions with auto-reconnect, logs, and connect or disconnect notifications, plus visibility into active Cloudflare Tunnel connections.
brew install –cask productdevbook/tap/portkiller.
https://github.com/productdevbook/port-killer
Forwarded from Otabek’s I/O
#experience
Dropbox Dash jamoasi bilan 4 oy ishladim (Tour of Duty). Va RAG haqida va uni katta masshtabda yuritish (running at scale) haqida juda ko'p o'rgandim.
Agar RAG qurayotgan bo'lsangiz va write/read amallari soni juda ko'p bo'lsa siz qurayotgan RAG katta ehtimollik bilan kengaya olmaydi va juda ko'p alaqsiraydi (hallucination). Vector database kichik bo'lsa kNN qidiruvi ishlashi mumkin. Agar ma'lumot bo'laklar hajmi 80k-100k dan oshsa juda katta kechikish (latency) sodir bo'ladi. Sababi so'rov (query) va har bir vector o'rtasidagi masofani xisoblash qimmatlashib va og'irlashib ketadi.
Buni qanday yechish mumkin? kNN o'rniga ANN algoritmlaridan foydalanish kerak, misol uchun HNSW (Hierarchical navigable small world) indekslari. Eng katta trade off, 100% to'g'ri ma'lumot emas, balkim 99.5% - 99.9% foiz aniqlikda ma'lumotlarni topa olasiz. Xisoblash (Computing) hali ham qimmat xisoblanadi garchi ba'zilar buni hozir amal qilmaydigan ta'rif deyishsada. Agar ana katta kompaniyalar aytishayabdi desangiz, Cloud narxi nega tushmayabdi? Xullas tushundingiz menimcha.
PDF kabi xujjatlarni qanday qilib saqlaydi va ulardan qanday ma'lumot qidiradi deysizmi? Bu yerda ham shunday trade off qilinadi. Vector Quantization ya'ni rasmlarni sifatini tushurish degani, compression. High-precision floating point raqamlar saqlashdan ko'ra, ularni round qilib saqlaysiz simple cluster'larga.
Ba'zan alaqsirashga (hallucination) sabab "The Context Window Paradox" bo'ladi va uni "Lost in the Middle" muammosi deb ataymiz. Ya'ni "promptda ko'proq ma'lumot bersang, yaxshiroq natija olasan" degan gaplar noto'g'ri. Buni ko'pincha Attention modellar qanday ishlashini bilmaydiganlar aytadi. Chunki bu model diqqatini (attention) buzadi. Ya'ni prompt o'rtasiga borib model ma'lumotni yo'qotadi. Buning uchun "Re-ranking layer" yechimlari mavjud. Xullas LLMga berishdan oldin, vector db dan olingan ma'lumot bo'laklarni (chunk) cross-encoder'ga berasiz va re-rank qilingan top 3-5 tasini yuborasiz LLMga.
Bizda ham RAG qurayotganlar ko'payabdi, balkim foydasi tegar : )
Dropbox Dash jamoasi bilan 4 oy ishladim (Tour of Duty). Va RAG haqida va uni katta masshtabda yuritish (running at scale) haqida juda ko'p o'rgandim.
Agar RAG qurayotgan bo'lsangiz va write/read amallari soni juda ko'p bo'lsa siz qurayotgan RAG katta ehtimollik bilan kengaya olmaydi va juda ko'p alaqsiraydi (hallucination). Vector database kichik bo'lsa kNN qidiruvi ishlashi mumkin. Agar ma'lumot bo'laklar hajmi 80k-100k dan oshsa juda katta kechikish (latency) sodir bo'ladi. Sababi so'rov (query) va har bir vector o'rtasidagi masofani xisoblash qimmatlashib va og'irlashib ketadi.
Buni qanday yechish mumkin? kNN o'rniga ANN algoritmlaridan foydalanish kerak, misol uchun HNSW (Hierarchical navigable small world) indekslari. Eng katta trade off, 100% to'g'ri ma'lumot emas, balkim 99.5% - 99.9% foiz aniqlikda ma'lumotlarni topa olasiz. Xisoblash (Computing) hali ham qimmat xisoblanadi garchi ba'zilar buni hozir amal qilmaydigan ta'rif deyishsada. Agar ana katta kompaniyalar aytishayabdi desangiz, Cloud narxi nega tushmayabdi? Xullas tushundingiz menimcha.
PDF kabi xujjatlarni qanday qilib saqlaydi va ulardan qanday ma'lumot qidiradi deysizmi? Bu yerda ham shunday trade off qilinadi. Vector Quantization ya'ni rasmlarni sifatini tushurish degani, compression. High-precision floating point raqamlar saqlashdan ko'ra, ularni round qilib saqlaysiz simple cluster'larga.
Ba'zan alaqsirashga (hallucination) sabab "The Context Window Paradox" bo'ladi va uni "Lost in the Middle" muammosi deb ataymiz. Ya'ni "promptda ko'proq ma'lumot bersang, yaxshiroq natija olasan" degan gaplar noto'g'ri. Buni ko'pincha Attention modellar qanday ishlashini bilmaydiganlar aytadi. Chunki bu model diqqatini (attention) buzadi. Ya'ni prompt o'rtasiga borib model ma'lumotni yo'qotadi. Buning uchun "Re-ranking layer" yechimlari mavjud. Xullas LLMga berishdan oldin, vector db dan olingan ma'lumot bo'laklarni (chunk) cross-encoder'ga berasiz va re-rank qilingan top 3-5 tasini yuborasiz LLMga.
Bizda ham RAG qurayotganlar ko'payabdi, balkim foydasi tegar : )
❤1
🪐 Bugun AI/IT’da eng “viral” trend: kod yozishni emas, kodni boshqarishni avtomatlashtirish (agentlar + workflow). Ya’ni ChatGPT/Claude/Codex faqat snippet berib qo‘ymaydi — repo’ni ochadi, test yozadi, PR tayyorlaydi, hatto monitoring/loglardan muammo topib, fix taklif qiladi. Menimcha, “AI koderni almashtiradi” degan gaplar biroz shov-shuv: asl yutadiganlar — AI’ni jarayoniga qo‘shib, tezroq yetkazib beradigan (delivery) dasturchilar. Tezlikning o‘zi emas, nazorat va sifat ustun bo‘ladi.
Amaliy qadam: bugun bitta kichik task tanlang (masalan, API endpoint’ga validation + test qo‘shish) va AI’dan “reja → patch → test → PR tavsifi” formatida so‘rang. Keyin siz faqat review qiling: xavfsizlik, edge-case, naming, logika. 1-2 soatda natijani solishtirib ko‘ring — qaysi bosqichda AI foydali, qaysi joyda albatta inson kerakligini aniq ko‘rasiz.
Amaliy qadam: bugun bitta kichik task tanlang (masalan, API endpoint’ga validation + test qo‘shish) va AI’dan “reja → patch → test → PR tavsifi” formatida so‘rang. Keyin siz faqat review qiling: xavfsizlik, edge-case, naming, logika. 1-2 soatda natijani solishtirib ko‘ring — qaysi bosqichda AI foydali, qaysi joyda albatta inson kerakligini aniq ko‘rasiz.
🪐 Bugun AI atrofida eng ko‘p ko‘rayotgan xato: “model tanladim” deb o‘ylab, ish tugadi deb sanash.
Builder uchun haqiqiy ish — model emas, tizim.
Agar sizda quyidagilar yo‘q bo‘lsa, eng zo‘r model ham foydasiz:
• aniq input/output kontrakt (format, limit, misol)
• loglar (nima keldi, nima chiqdi, qayerda yiqildi)
• fallback (model ishonchsiz bo‘lsa nima qilamiz?)
• eval (har release’da 20 ta real case bilan tekshiruv)
• cost/latency budjet (pul va vaqt ham feature)
AI’ni “sehr” deb emas, “infratuzilma” deb quring. Infratuzilma esa har doim: o‘lchanadi, kuzatiladi, va nazorat qilinadi.
Builder uchun haqiqiy ish — model emas, tizim.
Agar sizda quyidagilar yo‘q bo‘lsa, eng zo‘r model ham foydasiz:
• aniq input/output kontrakt (format, limit, misol)
• loglar (nima keldi, nima chiqdi, qayerda yiqildi)
• fallback (model ishonchsiz bo‘lsa nima qilamiz?)
• eval (har release’da 20 ta real case bilan tekshiruv)
• cost/latency budjet (pul va vaqt ham feature)
AI’ni “sehr” deb emas, “infratuzilma” deb quring. Infratuzilma esa har doim: o‘lchanadi, kuzatiladi, va nazorat qilinadi.
🪐 Bugun builder/operator signali: “AI agent”lardan ko‘ra, kuzatuvchanlik va standartlar ko‘proq foyda beradi. Prod’da 3 ta narsani odat qiling: 1) har servisga SLO + alert (kechikish/5xx/queue) 2) har deployga “rollback 1 tugma” 3) loglar strukturali: request_id, user_id, trace_id. Shunda AI ham, odam ham muammoni 10x tez topadi. Eng zo‘ri: bular yangi tool emas — intizom.
🪐 Operatsion signal: “AI”dan ko‘ra “AI infratuzilmasi” qimmatlashyapti. Modelni chaqirish oson, lekin prod’da xarajat va kechikish (latency) sizni yutadi.
Amaliy checklist:
• Har endpoint uchun SLO: p95/p99, timeout, retry budget.
• Cache: prompt+context hash, “hot” javoblar uchun TTL.
• Observability: token/so‘rov narxi, rate limit, fallback ishlaganini log qil.
• Vendor lock-in’ni kamaytir: model adapter, feature-flag, A/B.
Bugun 1 soat ajrating: eng ko‘p trafik endpointga shu 4 qatlamni qo‘ying — “AI feature” darhol barqarorlashadi.
Amaliy checklist:
• Har endpoint uchun SLO: p95/p99, timeout, retry budget.
• Cache: prompt+context hash, “hot” javoblar uchun TTL.
• Observability: token/so‘rov narxi, rate limit, fallback ishlaganini log qil.
• Vendor lock-in’ni kamaytir: model adapter, feature-flag, A/B.
Bugun 1 soat ajrating: eng ko‘p trafik endpointga shu 4 qatlamni qo‘ying — “AI feature” darhol barqarorlashadi.