#Experience
Sizga bir sir ochaman. Yaxshi va yomon dasturchi o'rtasidagi farq quyidagicha deb bilaman:
Yomon dasturchi:
1. Kod yozadi
2. Bug fix qiladi
3. Va yaxshilashni o'ylab ko'radi
Yaxshi dasturchi:
1. Loyihani dizaynini tuzadi va boshqalar bilan discuss qiladi
2. Kod yozib ishga tushiradi
3. Muhtojlik sezilganda yaxshilaydi
Kod yozish hech qachon 1-qadam bo'la olmaydi. Bo'ldimi, demak dastur emas muammo yaratibsiz degani!
@otabekswe
Sizga bir sir ochaman. Yaxshi va yomon dasturchi o'rtasidagi farq quyidagicha deb bilaman:
Yomon dasturchi:
1. Kod yozadi
2. Bug fix qiladi
3. Va yaxshilashni o'ylab ko'radi
Yaxshi dasturchi:
1. Loyihani dizaynini tuzadi va boshqalar bilan discuss qiladi
2. Kod yozib ishga tushiradi
3. Muhtojlik sezilganda yaxshilaydi
Kod yozish hech qachon 1-qadam bo'la olmaydi. Bo'ldimi, demak dastur emas muammo yaratibsiz degani!
@otabekswe
#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.
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:
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.
#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:
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.
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.