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.
🪐 Oxirgi oylar menga bitta kuchli signalni yana tasdiqladi: “AI bor” degan gap endi afzallik emas. Haqiqiy afzallik — AI’ni mahsulotga qanday integratsiya qilayotganingizda.
Ko‘p jamoalar bir xil xatoga tushyapti: model tanlaydi, prompt yozadi, demo qiladi — lekin foydalanuvchi hayotida deyarli hech narsa o‘zgarmaydi. Amalda esa yutayotganlar boshqacha fikrlayapti: AI — feature emas, balki ish jarayonining (workflow) bir qismi.
### Men amalda ko‘rgan “builder” signallari
• Qo‘l mehnatini kamaytiradigan joyga zarba berish: 10% “wow” effekti emas, 50% vaqt tejalishi bo‘lsa, foydalanuvchi qaytib keladi.
• Kichik va aniq agentlar: “Hammasini qiladigan bot” emas. Bitta vazifa: masalan, *support ticket’ni triage qilish + javob draft tayyorlash*.
• Human-in-the-loop dizayni: tekshirish nuqtalari bo‘lmasa, AI faqat xatolarni tezlashtiradi.
• Observability: loglar, trace, prompt va versiya nazorati. Agar “nega bunday javob berdi?” degan savolga 2 daqiqada javob topsangiz, mahsulot tez o‘sadi.
• Narx va latency real bo‘lishi kerak: eng zo‘r model emas, ko‘pincha eng arzon va yetarli model yutadi.
### Qisqa takeaways
• AI qo‘shishdan oldin: foydalanuvchi bugun nimaga 30 daqiqa yo‘qotyapti? — shuni toping.
• “Model”dan ko‘ra **workflow**ni chizing: *kirish → tekshiruv → natija → qayta aloqa*.
• Sifatni “his” bilan emas, metrikalar bilan o‘lchang: vaqt tejalishi, xato foizi, retention.
### 7 kunlik amaliy reja (oddiy, lekin ishlaydi)
1. 10 ta real user jarayonini yozib chiqing (qog‘ozda bo‘lsa ham bo‘ladi).
2. Eng ko‘p takrorlanadigan bitta ishni tanlang.
3. Shu ish uchun minimal AI assist qiling (draft, suggest, summarize).
4. Review checkpoint qo‘ying (tasdiqlash yoki inkor).
5. Log + feedback tugmasi qo‘shing (“foydali/foydasiz” + sabab).
6. 3 xil model bilan A/B test qiling (tezlik va narxni solishtirib).
7. Natija bo‘lmasa — AI’ni emas, jarayonni qayta dizayn qiling.
Menga yoqadigan qoida: AI’ni “aqlli” qilishdan oldin, mahsulotni “aniq” qiling.
Ko‘p jamoalar bir xil xatoga tushyapti: model tanlaydi, prompt yozadi, demo qiladi — lekin foydalanuvchi hayotida deyarli hech narsa o‘zgarmaydi. Amalda esa yutayotganlar boshqacha fikrlayapti: AI — feature emas, balki ish jarayonining (workflow) bir qismi.
### Men amalda ko‘rgan “builder” signallari
• Qo‘l mehnatini kamaytiradigan joyga zarba berish: 10% “wow” effekti emas, 50% vaqt tejalishi bo‘lsa, foydalanuvchi qaytib keladi.
• Kichik va aniq agentlar: “Hammasini qiladigan bot” emas. Bitta vazifa: masalan, *support ticket’ni triage qilish + javob draft tayyorlash*.
• Human-in-the-loop dizayni: tekshirish nuqtalari bo‘lmasa, AI faqat xatolarni tezlashtiradi.
• Observability: loglar, trace, prompt va versiya nazorati. Agar “nega bunday javob berdi?” degan savolga 2 daqiqada javob topsangiz, mahsulot tez o‘sadi.
• Narx va latency real bo‘lishi kerak: eng zo‘r model emas, ko‘pincha eng arzon va yetarli model yutadi.
### Qisqa takeaways
• AI qo‘shishdan oldin: foydalanuvchi bugun nimaga 30 daqiqa yo‘qotyapti? — shuni toping.
• “Model”dan ko‘ra **workflow**ni chizing: *kirish → tekshiruv → natija → qayta aloqa*.
• Sifatni “his” bilan emas, metrikalar bilan o‘lchang: vaqt tejalishi, xato foizi, retention.
### 7 kunlik amaliy reja (oddiy, lekin ishlaydi)
1. 10 ta real user jarayonini yozib chiqing (qog‘ozda bo‘lsa ham bo‘ladi).
2. Eng ko‘p takrorlanadigan bitta ishni tanlang.
3. Shu ish uchun minimal AI assist qiling (draft, suggest, summarize).
4. Review checkpoint qo‘ying (tasdiqlash yoki inkor).
5. Log + feedback tugmasi qo‘shing (“foydali/foydasiz” + sabab).
6. 3 xil model bilan A/B test qiling (tezlik va narxni solishtirib).
7. Natija bo‘lmasa — AI’ni emas, jarayonni qayta dizayn qiling.
Menga yoqadigan qoida: AI’ni “aqlli” qilishdan oldin, mahsulotni “aniq” qiling.
🪐 So‘nggi oyda bitta narsani aniq sezdim: “AI hammasini qiladi” degan gap ko‘p joyda loyihani sekinlashtiradi. Amaliyotda esa yutqazayotganlar — modellarga emas, tizimga e’tibor bermayotganlar.
Hozir ko‘rinayotgan builder signallar (AI + IT)
• Konteyner emas, konteks yutadi. Kod bazangiz, loglar, mijoz feedback’i, ticketlar — bular tartibli bo‘lmasa, AI faqat “chiroyli javob” beradi.
• Kichik feature > katta reja. 2 haftalik “katta refaktor”dan ko‘ra, 2 kunlik “bir muammo = bir patch” tezroq pul/foyda beradi.
• Observability qaytdi. Monitoring, tracing, audit log — AI agent qo‘shsangiz ham, qo‘shmasangiz ham, baribir kerak. “Nima bo‘ldi?” degan savolga 30 soniyada javob topa olmasangiz, growth ham bo‘lmaydi.
• Vendor-lock emas, exit-plan. Har qanday SaaS/LLM: bugun zo‘r, ertaga narx oshadi. Oldindan “ko‘chish yo‘li” bo‘lsin.
Men ishlatadigan oddiy yondashuv
1. Bitta metrikani tanlang: masalan, “support javob vaqti” yoki “build time”.
2. AI ni o‘sha joyga uring: promptlar emas — pipeline. (masalan: PR template + test checklist + log format)
3. Chegara qo‘ying: AI faqat taklif qiladi, merge esa test va reviewdan keyin.
4. Har hafta 1 ta avtomat: lint, CI cache, migratsiya script, alert — farqi katta.
Olib ketadigan xulosalar
• AI — kuchaytirgich. Zaif jarayonni “tezroq zaif” qiladi.
• Eng yaxshi investitsiya: loglar, testlar, release tartibi.
• “Agent qo‘shdim”dan oldin: o‘lchov + nazorat + rollback.
Agar hozir yangi product qilyotgan bo‘lsangiz: birinchi bo‘lib “qanday qilib tez-tez release qilaman?” degan savolni hal qiling. Qolgani keyin keladi.
Hozir ko‘rinayotgan builder signallar (AI + IT)
• Konteyner emas, konteks yutadi. Kod bazangiz, loglar, mijoz feedback’i, ticketlar — bular tartibli bo‘lmasa, AI faqat “chiroyli javob” beradi.
• Kichik feature > katta reja. 2 haftalik “katta refaktor”dan ko‘ra, 2 kunlik “bir muammo = bir patch” tezroq pul/foyda beradi.
• Observability qaytdi. Monitoring, tracing, audit log — AI agent qo‘shsangiz ham, qo‘shmasangiz ham, baribir kerak. “Nima bo‘ldi?” degan savolga 30 soniyada javob topa olmasangiz, growth ham bo‘lmaydi.
• Vendor-lock emas, exit-plan. Har qanday SaaS/LLM: bugun zo‘r, ertaga narx oshadi. Oldindan “ko‘chish yo‘li” bo‘lsin.
Men ishlatadigan oddiy yondashuv
1. Bitta metrikani tanlang: masalan, “support javob vaqti” yoki “build time”.
2. AI ni o‘sha joyga uring: promptlar emas — pipeline. (masalan: PR template + test checklist + log format)
3. Chegara qo‘ying: AI faqat taklif qiladi, merge esa test va reviewdan keyin.
4. Har hafta 1 ta avtomat: lint, CI cache, migratsiya script, alert — farqi katta.
Olib ketadigan xulosalar
• AI — kuchaytirgich. Zaif jarayonni “tezroq zaif” qiladi.
• Eng yaxshi investitsiya: loglar, testlar, release tartibi.
• “Agent qo‘shdim”dan oldin: o‘lchov + nazorat + rollback.
Agar hozir yangi product qilyotgan bo‘lsangiz: birinchi bo‘lib “qanday qilib tez-tez release qilaman?” degan savolni hal qiling. Qolgani keyin keladi.
🪐 Bugun shuni o‘rgandim: “AI qo‘shsak bo‘ldi” degan yondashuv eng tez charchatadi. Real foyda — observability va intizomda: loglar tushunarli bo‘lsa, trace id bo‘lsa, xatoni 5 daqiqada topasan. Aks holda, model ham, mikroservis ham faqat shovqin. Hozir har feature’dan oldin: “buni prod’da qanday o‘lchayman, qanday rollback qilaman?” degan 2 savolni yozib qo‘yyapman. Debug — productning yarmi ekan.
🪐 Bugun yana bir marta bildim: “AI hammasini yozib beradi” degan fikr — tuzoq. Model kodni tez chiqaradi, lekin kontekstni (nima uchun, qaysi chekka holat, qaysi limit) sizdan oladi. Eng katta tezlik — aniq cheklov + kichik iteratsiya + tez test. Debug muhim