2-qism.

Umringizni sarflab DDIA, Cracking coding interview, clean architecture, clean code vaxakazo adabiyotlarni o'qidingiz.

O'qish yaxshu albatta lekin esda ham qolishi kerakda. Agar siz o'sha kitobdagi narsalarni amalda sinab ko'rmasangiz o'qiganingiz bir tiyn, chunki esingizdan chiqadi yoki yodlab olgan bo'lasiz.

Ko'pchilik interveiwda shaqillatib javoblar berib tashlaydi, UML chizib diagrammalarda vapshem 22-asr yechimlarini qivoradi ammo shu narsani code bilan yozib berolmaydi. Tayyor moduli frameworklar bilan bo'lsa ham qiberolmaydi, masalan spring cloud kabi.

O'zi shu sababli ham hech inteviewlarga tayyorlanmaganman. Algo & DS, System design vaxakazolarga ham unchalik etibor qilmaganman. Esimda qolgani qolgan qolmaganini eslab olaman. O'ylaymanki interviewlarga tayyorlanishdan ko'ra doyimiy learning yaxshiroq foyda beradi, lekin qandaydir vaziyat bo'lsa masalan tezroq ishga kirish kerak, pul kerak bo'lsa ha interviewga tayyorlanasizmi, leetcode yechasizmi farqiyoq. Bu yerda sizni prioritet ish topishdan iborat. Lekin long termda bu strategiya yemaydi, chunki huddi sizdaka templatedagilar qalashib yobitbi. Shu sababli short term uchun ha interviewga tayyorlanasizmi, template narsalarni yodlaysizmi buni axamiyati yo'q chunki tezroq ish topishga extiyoj bo'lishi mumkin lekin long termda bu yaxshi ishlamaydi, chunki inkubatordan chiqgan jojalar kabi birxil sizdakalar qalashib yotibti.
Agarda moddiy resurslarga extiyoj kamroq bo'lsa biroz balandroq dorga osilish, learning paytida ham expirementlar bilan qilish yaxshiroq. Chunki detailarga aralashsiz, murakkab abstraksiyalar sodda abstraksiyalardan tashkil topgan shu sababli siz ham eng quyi abstraksiyalardan boshlab o'rganishingiz va amaliyotlar qilishingiz mumkin. Long termdagi rejalarda trendlar katta axamiyatga ega emas, shu sababli trendagi adabiyotlar yoki trendagi mavzularga emas balki fundamentalroq narsalarni o'rganishga va torroq mavzularda rivojlanishga etibor qaratish yaxshiroq fikrimcha.

Manashu strukturani parsingi tayyor, hashtable qoldi, lekin spec bo'yicha parsing tayyor.

https://github.com/Susambil-Labs/journal-monad/blob/master/src/Journal.hs

Endi bunga write streamlar qo'shish kerak va agar man biror structure berib shuni journalga yozsam o'zi encode qilib streamga tashlashi kerak.

Shunda bunaqa tassavur qilsangiz bo'ladi.

Har bir journal entry bu raw
Har bir entry field bu column.

Ammo journal holatida hammasi dynamic typed yani bunga pofig tiplar.

Ho'sh tiplar qachon kerak aynan databse perespektivasida ?

Man bilganim asosan indexlash uchun kerak. Yani tipga qarab indexing strategiyalari qilinadi. Indexlansa demak search va sort oson bo'ladi eng kamida.

Demak xozirgi turishida bitta NOSQL concept ham tayyor bonusga structured journaling.

Ertaga streamlarni cook qilib ko’ramiz. Haskellda eventga o’xshatibroq stream qilishni bilmayman xozircha. Yoki bo’lmasam database connectionlardan ilhomlanish mumkin. Bunga ham focus o’ylaymiz albatta fikrlar bo’lsa yozib qoldiring.

Data size uchun ham kerak, masalan binary formatlarda hamma data bir biriga yopishib ketadi shunga aniq bit by bit qarash yoki turli focuslar bilan bufferlar qilish kerak. Lekin uyam muammoli. Shu sabab datasize uchun kerak.

Compression uchun kerak. Bizda empty bufferlar 0 0 0 0 bo'ladi, bulari adashmasam losless compress qilsa bo'ladi.

Xozir hayolga kelib qoldi uyqudan oldin.

Efficiency uchun tiplar axamiyati katta ekan, dynamic qilingani bilan cast qilish kerak, masalan journaldagi raqamlarni ham bytestring qilib o'qiyabman xozir, bu esa yomonroq. Ishqilib optimizatsiya haqida o'ylasam ancha narsalarni tog'irlash kerak ekan.

O'ylab qarasam, odamlarga shunchaki alternativ narsalarni ko'rsatish kerak ekan.

Endi bu kanalda shu o'zimni expirementlarim, OSS, bazida koryera haqida gaplashamiz.

Hullas kim kimni aldayabti, qaysi til yaxshi yomon vaxakazolarga tupurgan holda. Turli qiziq mavzular haqida tajriba almashamiz. Faqat biroz autism va enthusiasm bilan.

Saviyasiz trollinglar va commentda yemagan narsalar bo'lsa oldindan aytaman ayamay chopaman mute qilmay, restrict qilmay balki ayamay chopaman. Agar man shunaqa qilsam feedback bering iltimos harxolda kanaldan o'zimni chopmaymanu.

O'zim file spec yasab ko'rganimdan kegin tushundimki bu yerda ham ajoyib abstraksiyalar qilsa bo'lar ekan. Shu o'rinda aytish keraki aslida bir ideya masalan shu journaling juda ko'p joylarda ishlatilingan. Bu haqida yuqorida ham aytgan edim. Lekin g'oyaning tadbiq qilinishi ham turlicha ko'rinishda bo'lgan. O'zim qilayotgan narsani biroz optimizatsiya qilish haqida o'ylar ekanman bu narsa turli layerlarda bo'lishini kuzatdim.

Masalan bazida I/O sababli dastur sekinlashishi mumkin bu muammoni hal etishga juda ham ko'p uslublar bor va bularni talabga qarab layer by layer ko'raveramiz.


Masalan Hardware levelda ham optimizatsiya uchun turli yechimlar qilingan, Bu yerda shularni bazilari bilan tanishishingiz mumkin: https://storedbits.com/hmb-vs-pseudo-slc-vs-dram-ssd/

Undan tashqari OSlarda alohida asynchronus I/O APIlar ham chiqib ketgan linuxda io_uring misol.

App layer uchun ham yechimlar ko'p biroz generallaridan biri shu Streamlar. Lekin general narsalar har doyim ham specific muammolarga yechim emas. Biz nima qilmoqchi ekanimizga qarab talablar o'zgaraveradi.

Ko'pchilik universitetlarda Computer architecture, Operating systems fanlari o'tiladi. Manashu fanlarda Harware yoki Kernel kabi mavzularni yaxshi o'qib qo'yish va bunga vaqt ajratish zarar qilmaydi, muhimi sizda background bo'lsin tushunchalar bo'lsin. Kegin qidirib topaverasiz. Yaqin kelajakda boshingiz crud qilishdan chiqmasligni bilsangiz ham yaxshi o'qing.

Buning asosiy sababi biror narsani detailed design qilganingizda juda ham ko'p nuanslar chiqib kelaveradi. Masalan birxil natija beradigan kodni turli uslubda yozish yoki optimizatsiya qilish vaxakazolar uchun biz ko'proq narsa discover qilishimiz va effectivelarni yaxshi o'rganishimiz kerak.

Masalan haskellda streamlar mavzusida juda ham ko'p experimentlar qilingan ekan. Birnechta major librarylar ham bor: conduit, pipes, streamly. Batafsil bu yerda: https://jmtd.net/log/haskell_streaming/
Bunday yechimlardan tashqari turlicha experiment namunalari bor. Kimdirlar parallel stream processing ustida research qilgan va shu tajribalardan kelib chiqib nimadir yechim qilgan vaxakazo. Hullas bular orasida adashmasam 2kun adashib qoldim juda ham ko'p ishlar qilingan ))

Hullas faylar contentini qanday o'qiyman yoki faylga qanaqa uslubda content yozaman degan savol mani shulargacha olib bordi. Qiziq tomoni shuncha narsani process qilib ham shunchaki readFile va writeFile qivorishim mumkin. Buncha ovoragarchilikdan maqsad shunchaki vibelearning emas. Masalan man oldin ham io_uring haqida o'qigan edim, oldin ham ma'lumotlar dbda qanaqa saqlanishini ko'rgan edim(Btree, MergeTree etc). Bu safargi rabbithole bilan shularni biroz update qivoldim. Albatta man qanaqadir Database, Filesystem yozishim uchun bu bilimlar umuman yetmaydi. Lekin ish bahonasida biroz learning ham zarar qilmaydi. Faqat oshirib yubormaslik kerak masalan crud yozaman deb OS haqida kitob o’qimaysizu :) Hammasi sekin sekin bilimlarni update qilib yuramiz va muhim qismi focus ko’p joyda bo’lishi kerak emas. Prioritetga qarab bo’lishi kerak. Shunda yuqorida aytganimdek o’rgangan narsalarni esdan chiqarish imkoni kamayadi. Doyim yangi mavzu o’rganish esa esdan chiqishga sabab bo’ladi. Albatta eng muhim qismi practice ham qilish kerak. Imkon boricha qanaqadir code yozish kerak.

Masalan manga umuman tushunarsiz bo'lgan narsa. Data Deduplication umuman olganda buni biroz tushunaman. Lekin FSda shu narsa qanaqa qilingani qiziq bazi joylarda bu narsa manual yani siz duplicated fielearni birlashtirvorishni aytasiz. Lekin tassavur qiling bu narsa avtomatik bo'lsa, huddi GCga o'xshaganroq.

Lekin qanaqa qilib less overhead qilsak bo'ladi ? yoki qanday qilib bunaqa ishlashi mumkin ?

Masalan duplicated blocklarni birlashtirvorib pointerlarni o'zgartirsa bo'ladi, bazida compressionlar shunaqa focuslar qiladi. Ammo bu narsa Deduplicationda yemasa kerak ))

Endi refactorlar bahona nimalarni qanday dizayn qilish haqida ham detail gaplashishimiz mumkin.

Katta abstraksiyalar kichik abstraksiyalardan tashkil topgan.

Bugun ohirga yetkazolgan ishlarimdan biri faqat quyidagi PR bo'ldi.

Hullas imerativ tillardagi for bilan qilsa bo'ladigan ko'p narsalar uchun turli abstraksiyalar o'ylab topilgan. Masalan haskellda foldlar va Foldable typeclass mavjud. Juda sodda izohlaganda to'plamli strukturalarni(Array, Vector, List etc..) bir valuega olib kelish uchun. Real misolda length yoki reduce kabi funksiyalarni olsa bo'ladi.

Rustda iterator uchun fold bor ekan shundan foydalanib for yoki custom recursion bilan qilsa bo'ladigan narsani fold bilan hal etdim.

Juda sodda va oson code bo'ldi.

https://github.com/bleur-org/bleur/pull/15

Fikrimcha manashu muhim boshlanishiga, kichik turli abstraksiyalarni o'rganamiz kegin ularni yopishtirib complexroq narsalar quramiz.

Ho'sh foldlarga misol qanaqa abstraksiyalarni bilasiz ?

100% coverage.

Tarixdan ma'lumki sanoat rivojlanishi bilan jarayonlarni avtomatlashtirish g'oyalari boshlandi, sodda mexanizmlardan murakkabroq yarm avtomat mexanik qurilmalar turli dvigitelardan tortib zamonaviy elektron qurilmalargacha.

Zamonimiz cyberpunk modeliga ham birmuncha mos keladi. Telefon va bazi gadjedlar bizning organlarimizga aylanib bo'lgan neurolink kabi narsalarni kutib o'tirish kerak emas.

Inson har davrda nimadirni osonlashtirishga harakat qildi ammo har safar qandaydir resurslar yetishmovchiligiga duchor bo'la boshladi. Resurslarni boshqarish esa iqsodiyot kabi fanlar shakillanishiga sabab bo'ldi. Biz tushundiki bazi narsalarga sarflanadigan resurslar cheklangan alternativ yechimlar kerak.

Masalan kiym tikish fabrikasini 100% avtomatlashtirgan afzalmi yoki bo'lmasam yaxshi tikuv mashinalari va tikuvchilarni yonlash kerakmi. Balki qo'lda tikish kerakdir ?

Manashunaqa tradeofflar iqsodiyot perespektivasidan qo'yila boshladi shu sababdan ham kiyim tikish fabirkalari 100% avtonom emas.

AI doirasida bo'layotgan turli fikr va munozalarlar bizni tarixga qarashga signal beradi. Kimdir konservativ kimdir liberalroq pozitsiyadan ushbu masalalarni analiz qiladi. Tarixdan ko'rdik jamiyat oddiy tovarlar oldi berdisidan elektron pullargacha qanday kelganini, tarixdan ko'rdiki hamma vahima qilgan Bitcoin oltin o'rniga o'tishi uchun yaxshigina muammoga ega ekanini(Mining va infratuzulma uchun sarflanadigan energiya)

Sanoat rivojlanishi bilan unga mos iqsodiyot, infratuzulma va yana boshqa ko'plab sektorlar rivojlangan. Yoki bu graphni har tomoni main qilib keltirishimiz mumkin. Lekin fakt shundaki hammasida tradeoff mavjud, ha nimadir kechagiday bo'lmaydi demak biz ham kechagidek bo'lmasligimiz kerak.

Dasturlash ham huddi shunday biz huddi popscience o'rgangandek doirada dasturlashni bilishimiz mumkin, ish ham topa olarmiz mayli. Ammo hal etilmagan muammolar qalashib yotibti. Iqsodiy tomondan boshqa savollar ham bor. Masalan balki fabrikani biroz avtomatlashtirarmi ? Ho'sh agar biz asosan CRUD qilsak shu ishlarni avtomatlashtiraylik, xop shunday bo'lsa ham xarajatlarimiz qanday bo'ladi ? 6ta ishchiga 1000$ to'layotgan edik, Claudecode 200$ dan 3ta hodimga qoldirsakchi ? Shunda 600+3000$. Bizga optimizatsiyalar kerak emas yangi server oladigan bo'lsak xarajat bor yo'g'i oyiga N summa qo'shilar ekan lekin optimizatsiya qilishimizga sarflangan vaqtda N^3 xarajat qilar edik.

Reallik qanday ekani biroz bo'lsada tushunarli bo'ldi deb o'ylayman.

Yaqin kunlarda Xinuxʼda boʻlayotgan oʻzgarishlar:

- GNOME oʻzbek tili tarjimalari boʻyicha yuborilgan kamchiliklar toʻgʻirlandi va yangi qoʻshilayotgan dasturlarni ham tarjima qilish jarayoni ketyapti. Tarjima qilingan oʻzbek tili ulushi 73 % dan 76 % ga oʻsdi.
- Kutubxonalarda paydo boʻlgan zaifliklarni (CVE) bartaraf etish uchun Xeonitte, software-center, e-imzo-manager ishlatgan kutubxonalar versiyasi eng oxirgi versiyasiga koʻtarildi.

Yangi dastur ishlab chiqilmoqda:

Relago — lambdajon va let-rec
tomonidan ishlab chiqarilayotgan tizimda paydo boʻlgan error xabarlarni payqab, batafsil error log haqida foydalanuvchiga UI dasturi orqali umumlashtirilgan jurnal qilib koʻrsatadi.

With sigma @shakhzodme

Our Σboys :)

Yana bir qiziq challenge.

Tassavur qiling biz bir filega Nta processdan turib content yozyabmiz va bu holatda race condition bo'lib contentlar kasha bo'lib tushish shansi bor. Masalan Process 1 hali yarmini yozib bo'lmasadan process 2 yozishni boshlaydi vaxakazo.

Ho'sh ushbu masalani qanday hal etsak bo'ladi ?

Hayolga keladigan eng sodda misollar quyidagicha.

1. File locking, bu huddi mutexlarni FSdagi versiyasiga o'xshaganroq conceptda ishlaydi. Lekin muammosi agar ko'p concurrent jobs bo'lsa deadlocks. Lekin garantiya beradi kernel darajasida.

2. Posix based systemlarda ham file denoscriptorda atomic operations qilsa bo'ladi. Masalan file desriptorni append modeda ochish orqali atomic writelar qilsak bo'ladi. Muammosi max buffer size 4KB.

3. Temp files, masalan har bir process alohida temp file ochadi va kegin safe merge qiladi. Muammosi consistencyga o'zingiz javob berishingiz kerak asosan.

4. Stariy dobriy centeralized mexanizmlar masalan bitta socketda eshitib turamiz va writelar shu socketga bo'ladi socket esa filega yozadi. Ammo over operations.

Bizni relago journalga barmoq bilan sanagulik darajadi processlar ulanadi. Shu sababli bizga mos keladigan va osonroq bitadigan ish bu albatta file locking mechanism. Resurs kam yeydi keginchalik mmap qivolish ham oson va eng muhimi read va write streamlar alohida bo'ladi shu sababli chala loglarni read qilish kabi narsalarga ham duch kelmaymiz. Agar bizni journal entrylar 4kb dan kam bo'lganida atomic qilar edik lekin bunga aniq garantiyalar yo'q xozircha write agnostic qilib entryni chunksdan yeg'ib oladigan qilsa bo'ladi lekin unga oldin max 4kblik buffer qilish kerak hullas ish ko'proq. Qolgan yechimlar esa yoki perfomance issue yoki bo'lmasam optimizatsiya uchun ko'proq code yozish kerak va ularning natijasi ham noaniq.

References:
https://gavv.net/articles/file-locks/
https://www.diskodev.com/posts/linux-atomic-operations-on-files/
https://pvk.ca/Blog/2021/01/22/appending-to-a-log-an-introduction-to-the-linux-dark-arts/

Guys tez maynerlarni o'chiramiz.

https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability.html

Hash funksiya nima deysizmi ?

Masalan biror murakkab qurilmani qiziqib ochasiz va barcha detallarini ajratib qo'yasiz, kegin birdan aralashtirvorasiz hammasini. Manashu holat o'sha qurilmaning hashed versiyasi.

Biroz intro qilishga shuni o'qisangiz bo'lsa kerak: https://tuttlem.github.io/2024/10/26/simple-hashing-algorithms.html

Naxren leetcode agar bunaqa narsalarni hayotga tadbiq qilmasangiz Qo'chqor aka!

Bu yerda esa yanada qiziqroq ma'lumot bor: https://binarymusings.org/posts/rust/rust-hashmap-memory-layout/

Bu yerda SMID bilan qilingan focuslar: https://kylematsuda.com/blog/writing_a_hashmap_part_3a