Yana bir qiziq narsalardan biri pseudo random generator. Linux o'zida /dev/random va /dev/urandom faylarini ochib raqamlarni olsangiz bo'ladi. Lekin bu maxsus shifrlangan random raqamlar yani decode qilish kerak.

Random generate qilish bilamizki doyim o'ziga yarasha challengelardan iborat va buning turlicha algorithmlari mavjud.


Real usecaselardan biri.
cat /dev/random | hexdump bilan biz random hex generate qilsak bo'ladi, hex esa uuidga o'xshab ketadi, aniq formati va size esda yo'q bilganlar share qiling iltimos, lekin biz ls /dev/disk/by-uuid buyrug'i bilan disklar idsini ko'rsak bo'ladi va bu biz randomdan olgan formatga juda o'xshash. Ushbu idlar bizga booting paytida beriladi.

Batafsil: https://en.wikipedia.org/wiki//dev/random

D-bus degan qoʻshiq eshitayotganmidiz?

Dbus degan anime edi.

Yangi o'yinchi.

Kechadan buyon bu loglarni alohida storagega vaqtincha saqlash bizdagi logs(huddi gnome logs) kabi app uchun ko'rastish uchun mos keladigan structure o'ylayotgan edim.

1. Sqlite yoki bo'lmasa boshqa emmbeded databasedan foydalanish g'oyasi kelgandi. Ammo buning minusi loglarni dbga yozib kegin undan yana dump export qilish va server sideda ushbu loglarni yana transform qilish qiyinroq bo'lishini o'yladim.

2. Har bir problem alohida folderda saqlanadi va FS o'zida strukturalanadi, huddi linux kabi )) Ammo bu narsa report paytida collect qilib compress qilishga efficent emas chunk ko'p bo'lsa processing uzoqroq vaqt olishi mumkin.

Hullas bugun ham ushbu masala muhokamasi bo'ldi. Lekin boshqa ideya kelib qoldi. Huddi systemd journal kabi journaling organize qilsakchi ?

Linuxda jouraling yetarlicha efficient qilingan write, search, read hammasi norm. LSM tree ishlaydi undan tashqari ushbu formatni export qilish uchun ham tayyor alogirthmlar ko'p, bu degani, bizga katta loglar kelsa ham chiroyli formatga olish va troubleshooting qilish osonroq bo'ladi indexing ham oson. Hullas ideya tayyor va shuni minimalroq versiyasini yasash kerak endi.

Systemd doclarni aylanib yurib journal file formati haqida o'qib qoldim. Hullas bu narsani prototype versiyasini qilib ko'rishga arziydi, manda xozircha systemd kabi juda ko'p parametrlar emas shu sababli taxminan manashu narsalarni yaxshi qilib olsak vapshem zo'r bo'ladi.

- Can store binary data, up to 2^64-1 in size
- Seekable
- Primarily append-based, hence robust to corruption

Journal file format haqida batafsil: https://systemd.io/JOURNAL_FILE_FORMAT/

Loglar huddi suflyorga o'xshaydi.

Bir uxlab tursam yangi odamman.

Hullas tajribam davomida sezdimki man o'rgangan ko'p narsalar esdan chiqgan. Masalan 2020 yil distrubuted systems mavzulari rossa hype bo'layotgan davrda manam zadrod bo'lib o'qigan edim. U payitlar optionlar kam edi, highload degan kanalda juda ko'p mavzular topganman va yana birnechta shu youtube kanallardan qidirib bazi communitylardan kerakli odamlardan so'rab o'rgangan edim. Kegin Domain driven design ham shunaqa bo'lgan Evnasni 700 betlik nazariyasini o'rganaman deb rossa siqilgan edim unda ham shu axvol youtube, gotoda Martin Fawler amakilar chiqib rossa ko'p narsalar aytib berishardi.

2023 deyarli hechvaqo o'rganmagandim, devopslik qilganman va baravar 3ta ishda ishlagan payitim bo'ldi. Biror yangi narsa o'rganish uyoqda tursin odamlarni ko'rishni istamay qolgandim.

2024 true oop o'rganaman deb hamma joyni rasvo qilganman. Nu asosan ko'p yangi perespektivalarni discover qildim. Asosan professionalism o'rgandim desam bo'ladi. Hayotga logn term qarashni boshladim.

2025 Functional programming, Haskell etc..

Ishqilib tushundimki paytida rossa ishlatgan narsalarimi ko'pi ham esdan chiqib ketgan fikrimcha bu normal holat. Hullas kerak bo'lganida topilmaydigan uyda yotgan batareyka yoki boshqa narsa kabida bu foydalanilmagan bilim. Shu sababli nimadirdan foydalanmasam uni o'rganishga vaqt sarflash haqida o'ylab ko'raman. Agar kamida shu mavzuda expirementlarga vaqt ajrata olishimni sezsam unda qo'rmasdan o'rganaman.

O'tgan kuni bir hamkasbim bilan shu backendagi bir muammosi haqida gaplashgan edik na terminlar esga keladi na odamga o'xshab tushuntirolaman. Biroz 5-6 daqiqa o'ylab kegin gapirib berdim.

Biror narsa yaxshi esda qolishi uchun esa rutine kerak yani qanaqadir davomli shu narsaga qaytaverish. Bo'lmasa esda qolmaydi ham kerak bo'lganda esga kelmaydi ham. Shu sababli endi takrorlashni odat qila boshladim.

Journal file taxminan manashunaqa formatda bo'ladi.

Eng qizig'i odamlar binary file formatlar uchun encoder/decoder generate qiberadigan DSL ham qilishgan ekan.

Hullas ideya bunaqa.

YAMLda spec yozasiz file formatni, kegin shunga parser generate qilsa bo'ladi aynan o'sha binary data structure uchun.

Batafsil bu yerda: https://kaitai.io/#what-is-it

Man code generate qilib o'tirmadim. Lekin shu yerdagi speclardan qarab simple journal format tuzib ko'rdim va rasmda taxminiy formatni ko'ryabsiz.

Journaling aslida juda ko’p storage related systemlarda ishlatiladi.

Filesystems, databases, etc…

Oldin databaselar haqida biroz o’qigan edim ammo aynan enginelar qanaqa organize qilishini tushungan bilan o’zim yozib ko’rmaganman.

Bu videoni ko’rganda esa juda ko’p joyini tushuna boshladim.

https://youtu.be/wxcCHvQeZ-U?si=MgDkzAHioMqkWW5p

Bizni journal unchalik murakkab ham emas, lekin nosql db ideyasiga juda yaqin, agar eplolsam ADT structure ham qo’shib ko’raman biror field typega.

Hullas kimga journalga 5 qo’yib berish kerak bo’lsa kelourasilar.

1 soat oldin 2025-yil edi axir.

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 ))