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

File locking cooked

Dromatic: f*ck sleep keep coding!
Realist: f*ck coding keep sleep!
Me: f*ck sleep and coding keep shitposting.

Haskell Haskell Haskell!

https://www.youtube.com/watch?v=ETxmCCsMoD0&list=RDETxmCCsMoD0&start_radio=1

WTH man ?

Man nix discourseni ochdim va asablarim tugadi.

Man ko’rgan birnechta dasturchilar turlicha commitlar qilishadi PRga. Mana yana qiziqlaridan biri :)

FAFO deriving custom typeclass.

Hullas bungacha manda journal entry Key Val dan tashkil topgan edi. Manabunday:

let entry = Entry::new(vec![
            Field::string("_SYSTEMD_UNIT", "myapp.service"),
            Field::string("PRIORITY", "6"),
            Field::string("MESSAGE", "Application started"),
        ]);

Ammo bu narsa yomonam noise beradi. Rustda ham Haskell kabi derive qilsa bo'ladi typeclasslarni. Shu ideya hayolga keldi. Yani manabunaqa qilsa bo'larmikan ?

#[derive(JournalEntry)]
pub struct ServiceLog {
    #[journal(rename = "_SYSTEMD_UNIT")]
    pub unit: String,

    #[journal(rename = "MESSAGE")]
    pub message: String,
    #[journal(rename = "PRIORITY")]
    pub priority: u32,
}

Agar shunaqa bo'lsa man o'zim yasagan tipni osongina journal entryga ham o'gira olaman shu bilan birga type safety ham joyida qoladi. Undan tashqari log entrylar tag bilan ajratilgan bo'ladi constructor namega qarab bu esa journalda grouping kabi narsalar qilishga juda foydali.

Haskellda siz yozgan typeclassni derive qilish unchalik qiyin emas. GHC.Generics bilan ishingiz anchagina oson ham bitadi, bu mavzularda juda ko'p resurslar bor. Lekin rustda esa bunday mavzular haqida kerakli resurslar deyarli topolmadim. Topganim bitta shu HeapSize. Ishqilib anchagina FAFOlardan kegin bu narsani yedirdim vanihoyat man yozgan typeclassni derive qilsa bo'ladigan bo'ldi.

Implementation: https://gist.github.com/lambdajon/c815ea20b9743e69fba9911e7583d930

Aytgancha

FAFO -> Fuck Around and Find Out