getUnindexedReports barcha indexlanmagan reportlarni olib keladi.

Indexlash haqida qisqacha aytsam bizga kelgan reportlarni Opensearchga yozamiz. Bazida birnecha file gigabyte bo'lib ketadi. Opensearchga esa bu datalarni shunchaki save qimaymiz balki index pattern qilib dicover uchun url ham qoldirish kerak.

Asosiy ideya report qilingan loglarni analiz qila olishdan iborat getUnindexedReports bizda barcha yangi indexlanmagan reportlani olib keladi va endi har bir reportni indexlanishi umuman processing ancha uzoq bo'ladi shu endi har bir reportni concurrent process qilish kerak.

Manashu joyda haskellni yulduzli onlari concurrent qilishga man forM ni shunchaki forConcurrently ga o'zgartirib qo'ydim va shu bilan endi hamma reportlar concurrent process qilinadi.

Express savol javob bo'ldi o'ziyam.

Man senior bo'lmaganman 🥲

Lekin rossa ko'p dolban seniorlarga shapaloq berganman.

Ko'pchilik murakkab yoki juda nazariy deydigan mavzular industrialashuviga yaxshi misollardan biri bu algebraic effect handlers umuman effect sistemalar.

Effect sistemalar controlflow uchun alternativ sifatida qaraladi. Masalan siz bilgan, try/catch/finally vaxakazolar ham manashu alebraic effect handlerlarga misol. Effectlarga misol esa Fs, IO capabilietes deb qarashingiz mumkin. Masalan sizni funksiyada faylni o'qish kerak bo'lsa demak funksiyangizda FS capabilites bo'lishi kerak. Effect sistemalar esa manashuni ma'lum semantics asosida generalize ham qiladi. Aytaylik siz ni funksiyada faqat FS capabilites bor, demak funksiyada biror muammo chiqsa aynan FS related side effectlardan chiqadi va ushbu side effectlar compile timeda check va track qilinadi. Va invariantlar bo'lsa compile timeda yuzaga chiqadi. Bu bilan biz runtime emas compile timeda side effectlar xavfsizligiga erisha olamiz. Yani biz side effect qilishimiz uchun oldin ushbu side effect capabilitesni ishlatish kerakligini ham belgilashimiz kerak.

Effect sistemalarning yana bir kuchli tomoni bemalol mock ham qilish mumkin. Masalan biror effectni mock qilsangiz sizni dasturning holati o'zgarmaydi. Masalan readFile mock qilinsa siz readFile chaqirganingizda olgan natijangizga qarab dastur ishi davom etaveradi. Agar biror muammo bo'lsa albatta effect throw qiladi siz esa uni catch qilasiz. Effect success bo'lsa sizni dastur ishini davom qialveradi.

Agar effect system effectlarni yetarlicha yaxshi track qila olsa bazi holatlarda determinizmga ham erishish mumkin. Masalan Random(seed) agar seed fixed bo'lsa nextInt doyim birxil inputga birxil output qaytaradi. Qiziq tomoni random funksiyasi nondeterministic ko'ringani bilan bu yerda deterministic ishlayabi sababi bu yerda nondeterminizm parametrlangan yani seedga bog'liq. Agar shunchaki Random() bo'lsa ham barbir seedni qayerdandir explicit oladi. Demak nextInt side effect qiladi ammo buning sababi bu yerda seed nondetermenistic ekanida. Ushbu misol yana bir qiziq narsaga etiborni qaratadi yani effectlar boshqa effectlardan foydalanishi mumkin. Effect sistemalarda aynan birnecha effectlarni compose qilish uchun ham turli yechimlar qilingan. Masalan bazi effectlar statega bog'langan bazilari orderinga bog'langan.

Ko'p dasturlash tillarida esa bunday narsalar doyim ham inobatga olinmaydi. Kegin runtimeda turli muammolarga sabab bo'lishi mumkin. Effect sistemalar esa manashunday muammolarni aynan compile timeda topishga dasturni eng boshidan xavfsiz side effectlar qila olishiga kerakli imkoniyatlarni taqdim qiladi.

Rasmda Algebraic Effect handlersni mainstream qilishdan motivivatsiya bayon qilingan.

LLMlar yo'q zamonda ko'p narsa qadirliroq edi.

1. Yozilgan kodning qadri. Masalan bir narsani yakunlash ham oson bo'lmas edi bazida. Bazi narsalarni tadbiq qilgani esa oylab vaqt ketar edi kerak bo'lsa.

2. Bilimning qadri. Kuchli bilimli odamlar qadri ancha baland edi va sezilib turar edi chatlarda ham uning kvalifikatsiyasi. Eslayman internet tanqis davrlarda torrentlardan ko'chirib Hard diskga tutorial yeg'ib o'tirar edik. Zeal kabi dasturlarni ishlatar edik manual o'qigani or apilarni qaragani chunki doyim ham online access bo'lmasligi mumkin edi.

3. Networking qadri ancha baland edi. Odamlar yangi hamkasblar bilan tanishish uchun ham turli forum, chatlarda o'tirishardi. Meetup, conferencelarda ham ancha saviyali mavzular bo'lgani uchun ham odamlar borar edi networking va bilim olgani.

4. Exchange expirence. Tajriba almashinuv ancha qadirli edi bazi momentlarda soatlab debatlar ham bo'lar edi. Tajriba almashar edik va yangi narsalarni ko'p o'rganar edik. Bunday momentlar o'ziga yarasha juda qiziq jarayon bo'lar edi sababi biror narsani soatlab gaplashib debat qilish, hulosalarni jamlab olish va vaqt o'tganida shu narsa amalda tadbiq qilinsa yana shu tajribani boshqalarga ulashish o'ziga yarasha kayf edi.

Bundan taxminan 3-4 yil oldincha dasturlash oddiy kasb bo'lib qolishini aytganimda. Yani qadirsizlanib ketishini aytganimda bu jarayon aynan manashunaqa ko'rinishda bo'lishi hayolimga ham kelmagandi. Shunchaki kuzatuvlarimda ko'rgan edimki odamlar mazza qilib ishlamayabti, ko'pchilik asosan pul topishga kelgan va getting shit done qiladi. Shundan tushungan edimki birkun kelib dasturchining ham qadri pasayib ketadi. Shu kunlarni ham yashayabmiz mana. Buyog'iga nima bo'lishi haqida ham hulosam yo'q. Ammo mani muhandislik bilimlarim farzandlarimga kerak bo'lmasa kerak degan taxminim ham bor. Huddi otamning muhandislik bilimlari manga kerak bo'lmagani kabi.

Juda qiziq video. Rust boshida ancha boshqacha bo'lgan ekan.

https://www.youtube.com/watch?v=79PSagCD_AY

Blya takoy neforskiy coffe ichayin desam 120$ deyabtiku no insoflar.

Yoshlar aynab bumble coffe ichlyabti mikkimauslar

Nega bu kompaniyalar bunchalik qo'rqoq bo'lmasa-a ?

Blya vpn yoniqligida uzum ishlamas ekan, boshqa juda ko'p local servislaram ishlamaydi.

Coffega shakar solishni o’zi jinoyatdir

Forgejo api bilan ishlaganda manashunday holatlarga duch kelyabmiz.

Muammo nimada ?

Masalan forgejo issue yasagani api bor deylik. Endi tabiyki Issue kimgadir yoki kimlargadir tayinlanishi mumkin.

Forgejoda shular special bo'lib qolgan. Agar siz faqat bir odamga tayinlamoqchi bo'lsangiz shu assigne qilasiz. Agar ko'pchilikga bo'lsa asigness ga berasiz. Bu holatda bunaqa bo'lishi mumkin.

Single.

{
...
 "assigneess": [User]
...
}

Single holatida bu field o'zi nullable. Yani assignee qiymati null bo'lishi mumkin.

Multiple:

```

Bu holatda birnechta user bo'lishi mumkin.

Xop diffda ko'ryabsizki buyoqda [User] tipi yana Maybega o'raldi. Buning sababi nima ?

Buning sababi siz empty list of users bera olmaysiz sodda aytsak. [] mumkin emas. Bu albatta null bo'lishi kerak.

Endi nima confuse qilyabti ?

1. Agar man assigneess qiymatiga 1ta itemlik user list bersam validmi ? Agar ha bo'lsa unda nega kerak bu assignee ?

2. Nega bizda 2ta empty case bor list uchun ? Yani bizda null bor va [] bor. Ammo api empty case deb faqat null ni qabul qiladi.

Yechim.

Agar chiroyli design qilish kerak bo'lsa qanday qilgan bo'lar edik ? assigneess qoldiramiz faqat agar [] bu issueni hechkimga tayinlanmaganini bildiradi, qolgan keyslarda esa list of users va hamma baxtli.

nixpkgs reposiga oʻzingiz paket chiqarish boʻyicha qilinadigan ishlarni yozdim.

- Maintainer roʻyxatiga github noyobnomizni qoʻshish
- Yangi yoki mavjud paketga fix yuborishda kommit xabarga kalitsoʻz yozish

https://gist.github.com/bahrom04/167ece36a268855aaac5332b7e94d3f9

Macosda low power modega qo'yib rossa kutibman buildni, blya rostdan ishlar ekan power save mode ))

Manga anchadan buyon qiziq bo'lyotgan narsa bu verified, reproducible events.

Masala oson ko'rinadi eventlarni storega yozamiz ularning irarxiyasi bo'yicha reproduce qilsak bo'ladi yani shunchaki olib kelamiz va execute qilamiz.

Ammo savollar juda ko'p masalan eventlar concurrent bo'lsachi ? ev2 -> oneof(ev3 | ev4) yoki bo'lmasam cheksiz irarxiya... Bu odatda kattaroq stream processingda sodir bo'ladigan hodisa, masalan kafkadan kelgan streamlar. Bu yerda event larni reproduce qilish doyim ham o'xshamasligi mumkin shunchaki katta sequence bor aynan Xni reproduce qilishga hammasini qayta qiladigan holatga duch kelish mumkin. Masalan har bir chunk ketmaketligi o'ziga hos unikal bo'lsa.

Undan tashqari vaqt faktori ham mavjud. Masalan bazi eventlar expire bo'lishi mumkin. Aytaylik verification code 1 daqiqada expire bo'ladi. Buni retry qilganingizda esa xato bo'lishi mumkin.

Ammo mavzu va bir chekkadan boshlashga arziydi. Xozircha manabunaqa plan qilyabman. Event source qilaman, bu narsani qisqaroq iohlasak. Biror statega nisbatdan sodir bo'lgan barcha actionlar. Kegin manashu actionlarni snapshot qilib saqlayman. Nu yuqorida aytilganidek va ularni bog'lab qo'yaman next, previus qilib.

Masalan qandaydir processing flow yakunlanganida sodir bo'lgan barcha actionlar record qilingan bo'ladi. Eng muhimi actiondan kegin state ham store qilinadi.

Kegin esa qandaydir spec yozaman umumiy flow qanday bo'lishi kerakligi haqida. Spec esa shu Statemachine temporal logic yani Allow + TLA deb tushunak bo'ladi. Hali aniq bilmayman ))

Endi event loglarni spec bilan mos ekanini tekshirish qoldi. Yani event loglar butun jarayonda sodir bo'lgan hodisalar. Bizni spec esa aynan jarayon qanday bo'lishining modeli endi qanaqadir checker bor, modelni o'qiydi va event loglarni o'qiydi va solishtiriadi jarayon modelga mos keladimi yo'qmi. Agar mos kelmasa demak tizimda nimadir xato.

Shunda biz eventlarni doyim ham reproduce qilishimiz ham shart emas. Shunchaki verify qilolsak bo'lgani. Shunda biz doyim garantiya berishimiz mumkin, agar falon hodisa bo'lsa demak aniq undan oldingi hodisa bo'lgani haqida.

Masalan Agar tsansaction success bo'lgan bo'lsa demak eshmatga aniq pul o'tgan. Biz unga pul o'tganligini reproduce qilishimiz shart emas balki transaction success bo'lishi uchun kerakli eventni bajarishga garantiya berolsak bo'lgani.

Dostavkalardagi estimation mexanizmlar juda yolg'on ishlaydi.

Masalan yandex 2x kechikishi mumkin. Yoki 1 soat kutganizdan kegin ham zakazni otmen qivorishi mumkin. Ammo tayinli kompensatsiya kutmang.

Uzum ham vapshe vapkod ekani sezilib turadi. Random momentlanrni belgilaydi. Masalan atayin sinaganman ko'chani narigi betidagi cafedan buyurma qilib va 40 minutda kelgandi. Kuryeradn so'raganimda biratola 3ta zakazga qo'shvordim degan.

Xop, kuryerlar birnechta buyurmani barobar olib kelar ekan. Unda nima uchun vaqtni shunga moslamaydi ? Estimation odatda siz tezroq buyrma qivorishingizga mo'ljallanadi firkimcha.

Sababi yaqinda kuryerga telefon qilib 50k sum qo'shib beraman aka deganimda 2x tez keldi buyurma 😁

Hulosalarim.
1. Estimation musor ishlaydi, uyoqda asosiy psixologiya tezroq buyurma qilish.
2. Kuryerlar vapshe ishlagisi kelmasdan ishlaydi, demak ularni ishlatadigan tizim molxona.
3. Restoranlar bilan vaqtlarni kelishmaydi. Masalan X taomni tayyorlanishiga vaqt ketmasligi mumkin lekin buni bazida avg estimationga qo'shvoradi. Aslida birdan kuryer topish mumkin edi. Ishqilib bu borada turli edge caselar o'ylanmagan deb o'ylayman.
4. Estimationi kuryer qilolmaydi, masalan 15-daqiqada yetkazib beraman deb estimate qilsa uje ekranizda boshqa raqam ko'rinishi mumkin.
5. Failar arzon. Msalan siz N summalik buyurma qildingiz, nimadir fuckup chiqdimi ? Sizga arzimagan summalik promokod beradi. Agar fail qimmat bo'lsa, masalan har bir kechikgan daqiqasi uchun 10k sum to'lasa bormi :) Kuryerga telefon qilib 10 daqiqa kech kelsa 50k berishimni aytardim )))

Qisqa gap bilan aytganda bu galvarslar ishlamaydi. Estimationlar mexanizmlari ham chirigan legacyligicha qolgan.

Progressiv davlatda yashayabmiz ahir, manashunaqa masalalarda corplarni yaxshigina itaradigan qonunlar chiqsa zo'r bo'lar edi... Masalan dostakva kechikgani uchun katta jarima davlatga va userga, biror payment app downtime bo'lgani uchun userga shtraf to'lasa ana surprizu mana surpriz bo'ladida.

Man zerikandan 24/7 tekshirardim uptime va orderlar kechikmayotganini 😎

Etibor bering, bankar kreditingiz o'tib ketsa sizdan % olishadi.

Ammo schet block bo'lib qolsa, sizga juda kerak payitda app ishlamasa va yana boshqa shunaqa momentlarda sizga bir tiyn ham to'lashmaydi.

Daje bu galvarsalar sizni scam qilmasliklariga ham javob berolmaydi. KYC deysizmi ? hehe common guys bunchalik sodda bo'lmanglar myid da ham teshiklar bor ekanini bilamizku hammamiz.

Umuman logichno, agar punktuallik muhim bo'lganida kuryerlik qilmas edi hamma ham :)

Undan tashqari bu biznes va bu ishlayabti, mandaka tabi nozik mijozlar ularga na**y keramas. Fuckuplar bo'lyabti va bu norm muhimi bizness yuryabti.

O'zi hamma prikol shunda anavi gap bor ediku "Biznes uchun kod bunaqa bo'lishi..." Aslida buni dolban programmerlar aytgandi nu mayli bizni keysda ham mos tushadi yani biznes uchun murakkab sistema kerak emas ko'p narsani cover qiladigan sistema bo'lsa yetarli.