Programming ∀

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

Haskell yoki Rustga o'xshagan tillarda optional tiplarga duch kelasiz. Imperativ tillardagi NULL o'rniga ko'proq manashunday abstraksiyalar ishlatilinadi. Haskell: Maybe Rust: Option Bu abstraksiyalar bizga optional valuelar bilan ishlagani kerak, imperativ…

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.

Yoshlar aynab bumble coffe ichlyabti mikkimauslar

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

Juda qiziq video. Rust boshida ancha boshqacha bo'lgan ekan. https://www.youtube.com/watch?v=79PSagCD_AY

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.

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.

The State of Post-Quantum Cryptography https://www.feistyduck.com/newsletter/issue_139_the_state_of_post-quantum_cryptography

Man senior bo'lmaganman 🥲 Lekin rossa ko'p dolban seniorlarga shapaloq berganman.

Express savol javob bo'ldi o'ziyam.

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.

O’ylab qarasam juma kundan buyon deyarli chiqmabman uydan.

Pandocga ham 20 yil bo’libti turli turdagi document filelarbi convert va parse qilgani juda ham kuchli instrument. https://pandoc.org/twenty-years-of-pandoc.html

Maqboq

Qiziq tarix ushbu video hisoblash tarixi haqida. Ammo eng qizig'i bu videoda International Research Conferenceda eng birinchi marotaba computing history haqida gapirilgan. O'sha davrlarda ishlab chiqilgan hisoblash mashinalari yani computerlar xozirgilari bilan solishtirsangiz juda katta farqlarga ega. Ammo videoda analog computing ham biroz gapirilgan. Bu mavzuda ham o'z branchida davom etyabti xozirgacha. Video juda qiziq ko'rishga arziydi. https://www.youtube.com/watch?v=uS0OBi74hfM&list=PLQsxaNhYv8dajXDgwQzSKo1UyKmWpa9bI&index=9

https://youtu.be/eqNNrowKVoE?si=7emDw939fmZG_rGN

Linter bilan manashunday o'zimizni std dagi funksiyalarni ishlatishga undaydigan qilishni boshlaganman. Bu narsaning yaxshi tomoni bazi narsalarni shunchaki code rewiewda takroran aytib yuravermaymiz. Shunchaki manashunday qoidalar yozib qo'yamiz va linter ishlaganda yoki error yoki warn beradi. Manabunaqa LSP integrationlar bilan esa birdan autofix qivorish mumkin )) Bazi convensionlarni hammaga takrorlash shart emas shunchaki linter o'rgatadi. G'alati ko'rinadiya agentlar zamonida biz linter ishlatyabmiz. Ammo boshqa tomondan qarasak bizda bu arzonroq chunki AI yetarlidan ko'p determenistic bir narsani ikki marotaba turlicha qilishi mumkin. A og'zaki qanaqadir qoidalaringizda esa qoidalar bir biriga contraversal bo'lishi mumkin bu invariantlarni va exeptionlarni ko'paytiradi. Bizda esa sal boshqacharoq maksimal darajada invariantlarni kamaytiramiz va determinizmga xarakat qilamiz. Chunki bundan oladigan manfatlarimiz ko'proq. Masalan reproduce qila olamiz. Yoki kutilmagan xatolarsiz code yoza olamiz. Bu ham o'ziga yarasha tradeoff sababi barcha xatoliklarni oldini olish uchun ham haskell kuchi yetmaydi boshqa yanada kuchliroq tillar kerak. Ammo bizda to'liq xatolardan holi kod degan talab ham yo'q xozircha. Agar bo'lsa kegin o'ylab ko'ramiz )) Lekin juda ko'p turdagi common xatolar masalan null pointer exeption boshqa paniclar bizda deyarli chiqmaydi. Endi manashu linter qoidalari bilan esa yanada kamayadi. Chunki bazi exeption qaytaradigan yoki unsafe funksiyalar ishlatilsa linter detect qiladi va shapaloq uradi.