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.

Eski narsalar esimga tushib ketdi, kutish barbir azobda...

Ho'sh sizningcha o'quv markazlar AI ni replace qiladimi ?

Forgejo 423 degan custom http status qo'shgan ekan.

Man 429 code bilan adashtiribman. O'zi o'ylagandim 429 da repo archived ekani haqida aytishi g'alatiroq ekanini. Nu mayli degandim ammo etibor qilmabman custom codega. Kegin muammo kutilmagan joyda chiqib qoldi )) libni ishlatilgan joyda comile bo'lmay qogan ))

Voot rfcdan chetga chiqish manashunaqa mikkimausliklarga sabab bo'ladi bazilar. Biz esa forgejoni so'ka so'ka davom etyabmiz ishni...