Programming ∀

MAANG inteview masalasiga kelsak. Uyoqda bularni zo'r bilib ishlamay yurgan tayinli impact qilmaganlar qalashib yotibti. Chunki kapitalizm shunaqa, tashqariga hamma narsani zo'r deb ko'rsatishadi ammo ichkari molxonadan iborat)) Nu hotya qiziq projectlar bo'ladi buni rad qilolmaymiz. Lekin ular shuncha yil o'tib karantindan kegingina gibrit yoki remote modellarni ko'rib chiqishdi. Yani rivojlanish va bazi policylarni o'zgartirish masalaalari ularda ancha sekin...

Manimcha uncha buncha kompaniya va projectlar uchun Algo&DS biladiganlar keramas. Chunki default leetcode zadrodlar oddiy relase pipeline haqida tayinli narsa bilmaydi. Engineering culture haqida tayinli narsa bilishmaydi, biror muammoni ayt desangiz formal description yozib berisholmaydi. Bunaqa toifa xozir qalashib yotibti. Qachon so'ngi marotaba formal describe qildingiz muammoni ? Man turli projectlarda va turli rolelarda ishlaganman lekin har safar algo interviewdan o'taman lekin hechqachon in-order tree yozmayaman. Tree kerakmi package... Chunki anashu companiy siyosati shunaqa. Unda manga nafik kere zadrod bo'lib ? Undan ko'ra man formalized relase qilay va downtimelar kamaysin va workflow yaxshilashsin. MAANG qiladiku ? Sizni kompaniyadan algo interviewdan o'tsam MAANG beradigan salary berasizmi ? Bo'lmasa ko'zingizni qattiq yumingda hiring processni kompaniyangiz va projectingizga biroz moslashtiring. Hullas copy paste qilmang sizga keragini qiling. Projectingiz highload bo'lib ketsa maksimum kuber ishlatasizku axir )) Man ko'rmaganman birorta o'rtacharoq companydagi engineerlar harbaloni tuning qilib customized qibtashaganini... Undan ko'ra stackowserflow ishlatishni o'rganilar, githubga issue yozishni o'rganilar. Shu payitgacha Algo DSni yo'l yo'lakay organib kelganamn va man bilgan juda ko'p engineerlar shunaqa qilgan man hurmat qilganlarim ham. Chunki ular R&D qilishni eplay oladi. Oddiy muammoyizni googlega yozolmasangiz nima qialsiz Algo ds haqida o'ylab. DTM ga o'xshaydi hiring processlar ham hamma tayyorlanadi va shablon savollar bo'ladi. Manga qimmatli engineer problem solvingni aniq bir sistematikaga sola olgan engineer. Fundamental bilimlari baqquvat engineer. Git stashni zo'rga eplaydigan leetcoder emas ))

Man bilgan companylarni 99% qismida hiring deyarli birxil. Ammo hamma companiyalar turli domainlarda ishlashadi. Sal g'alati emasmi ?

Overall bizni sohadagilar uchun hiking juda zo'r hobby ekan tavsiya etaman. Agar extreme qiziq bo'lsa unaqalariyam bor. Masalan manga extreme juda qiziq. Lekin hali juda extreme joylarga bormadim, ammo xavfliroq yo'llardan ham yurdik sal adashsangiz sirg'anib tushib ketasiz lekin eplasa bo'ladi. Lekin barbir man uchun eng yuqori daraja bu BASE jumping. Bu yerda tezlik 300-350km/h bo'lar ekan. Ammo bu aniq maqsad emas xozircha maqsad parashutdan sakrash taxminan 7-8km balandlikdan sakrab ko'rishni reja qilyabman. Qisqasi hamkasblarga tavsiya agar balandlikdan qo'rqmasangiz va adrenalin kerak bo'lsa manashu ikki sportdan birini sinab ko'ring. https://youtu.be/WIVQR4O6uFU?si=6x32C-6nZ57YQt87

Adashib haqiqatlarni aytvoray dedim🤭

Lean juda ham elegant qilingan ekan. Masalan haskellda bunaqa emas inheritance juda ko'p type classlarda. 3-rasmda shuni ko'rishingiz mumkin. Buyoqda esa har bir operation uchun alohida typeclass qilingan. Tog'risi hatto typeclasslardagi inheritance ham odamni qiynab qo'yadi bazida.

Xozircha Dependent Type Theoryga keldim lekin juda sodda tushuntirilgan ko'p narsalar. Overall bugun ertalabdan o'zim uchun yangi point of viewlar paydo bo'la boshladi. Tavsiya etaman: https://lean-lang.org/theorem_proving_in_lean4/title_page.html

Bu yerda Js, py va phpchikar haqida bitiklar topdim. Ammo manosiga tushunmadim tillar hayvonga o’xshatilgan deb umid qilaman🤔

Toshlarga bitib keldim FP haqida:)

Umuman olganda 3 yilda anchagina ko’p devops tools chiqib ketibti 🤷 Masalan kuberda qiryuzmillard narsa🥲 Qaysi kerak qaysi kerak emas ajratish qiyin. Bittasi argocd desa bosqasi flux deydi. Bittadi helm desa boshqasi kustomize deydi. Yana devtools yasaydiganlarda 2 trend kuzatdim. 1. Harbaloga Go ishlatishadi. 2. Biror toolni yaxshilash o’rniga yangicha tool qilishadi(xazil va chin) Juda ko’p projectlar tupo marketing qanaqadir jiddiy impact bermaydi🫠 CNCF qilayotgan bazi projectlari yoqdi. Ammo boshqa bazi devtools ishlab chiqaradiganlarni productlaridan extiyot bo’lish kerak. Ancha oldin ko’rgan bazi bordak projectlarim ham biroz tartiblanibti. Ammo monopolyga doir muammolar haliyam actual🥲 Yana monopol certicationlardan tortib OSS contributorlarni rossa ishlatib buyoqda soqqani qilayotgan companylargacha hammasi manashu yerda😏 Hullas devops stuffga qaytganim bir tomondan hursand qilgan bo’lsa boshqa tomondan qattiq o’yga cho’ndirdi)) Juda ko’p devtools scam bo’lib ko’rinyabti ko’zimga🫠 Developerlar skill issuesini yopamiz deb qilishgan.

Yana bir fikr kelyabti. Achitecture must be Open source. Mani fikrimcha aynan manashu narsa learning va optimizing purpose uchun juda ham effektiv. Massalan qandaydir tizim o'zining arxitekturasini ochiq qildi deylik. Aynan shunaqa tizim ustida ishlayotgan boshqalar o'z fikrlarini bildirishlari yoki shunaqa tizim qurmoqchi bo'lganlar o'rganishlari mumkin.

Qiziq maqola ekan, Lean4 bilan salgina tanishganimdan kegin aynan amazon ham shundan ko'p foydalanishiga guvoh bo'lgan edim. Kegin @keilambda TLA+ kabi narsalardan ham foydalanishini aytdi )) Fikrimcha dasturlash sohasida aynan manashunaqa narsalarga extiyojlar ko'payabti. Chunki mavjud bo'lgan traditional yechimlar doyim ham o'zini oqlamayabti. Masalan mani tajribamda bir tizim uchun architecturedan tortib hamma narsani documented qilish va uni doyim update qilib yurish juda qimmatga tushgan edi. U yetmaganidak turli dunyo qarashdagilar turlicha tushunadi. Masalan requirements bo'yicha QA test qiladi ammo fichani bug deydi... Yoki yozilgan testlarda exeptionlar barbir chiqadi. Prooflar bunaqa muammolarning davosi. Ammo ko'pchilik learning curve deb bunaqa narsalardan uzoq turadi. Lekin business uchun aynan manashunaqa yechimlar arzonroqga ham tushadi deb o'ylayman. Masalan architectlar uchun TLA+, Alloy6 kabi toolar juda ham foydali instrument. Sababi siz qanaqadir diagramlar bilan emas balki aniq propositionlar bilan define qilasiz tizimni. Diagramlar sizga aniq muammoni ko'rsatmaydi siz shunchaki UML chizasiz. Ammo UML shunchaki rasm u bilan nimadirni isbotlash yoki tekshirish qiyin yani inson faktoriga asoslangan. Ammo biz 21 asrdamiz, xozirda hamma narsa juda complex bo'lib ketgan. Barcha edge caselar inson miyyasiga sig'maydi. Shu sababdan bizga boshqacharoq narsa kerak. Bu narsalar bizni xato qilishdan saqlashi yoki xatoyimizni ko'rsatishi kerak. Fikrimcha bunaqa point of view bizga ancha qulayroq va effektivroq deb bilaman. TLA+ at amazon: https://awsmaniac.com/how-formal-methods-helped-aws-to-design-amazing-services/ Lean4 at amazon: https://www.amazon.science/blog/how-the-lean-language-brings-math-to-coding-and-coding-to-math

Endi sekin directionchani olib manashu concept ustida ishlayman. O'ylaymanki bu ideyalar DevOpslar uchun yoqimli ergonomik tilda ishlash imkoniyatiga sabab bo'ladi. Shu sababdan IaC mavzusida sizlarni nimalar qiynasa uyalmasdan aytaveringlar 🙂

imports {
  DebianConfs,
  RedhatConfs
}

type OS = Debian | RedHat

configurations Debian = DebianConfs
configurations RedHat = RedhatConfs

Haskellga o'xshab qoldi-a )) Hullas bu masalada ancha ideyalar kelyabti.

imports {
  DebianConfs,
  RedhatConfs
}

type OS = Debian | RedHat

configurations = match os {
  Debian => DebianConfs
  RedHat => RedhatConfs
}

Bunisi esa rustga o'xshaydi. Qisqasi ADT va Patternmatch bo'lsa tassavur qiling siz Os tipiga yangi member qo'shsangiz compiler error beradi sababi uning configurationlarini defiine qilishiz shart. Bu esa manabunaqa holatlarda esdan chiqarmaslikga yordam beradi. Configlarni esa module qivolib bosaverasiz.

Barbir miyyada eslab qolishingiz kerak nima qo'shgan qo'shmaganizni.

Xitoyliklar qilayotgan kernel OSS ekanmi 🤔 Tushunishimcha rustda ekan to'liq. Bu mavzuda contextda borlar bilganlarizni ulashing ularni kerneli qanday ekani qiziq ))

Multi master k8sda etcd external etcd )) Manimcha ko'pchilik clusterni setup qilganida k8s componentlarga etibor qilmaydi, oqibatda biror muammo chiqsa qiynalib yuradi. Shaxsiyga manashunaqa masalada yozishgan edi. K8s eslab olishga biroz vaqt ketti va ohiri mana yechim. Multi master clusterda eng birinchi target etcdni external olib chiqamiz. Bu aynan etcd o'zi bilan direct ishlashga va kuberga bog'liq bo'lib qolmaslikga yordam beradi intensivlikni oshiradi. Mani tajribamda bunaqa yechim ko'proq foydali bo'lgan pod ichiga tiqanimdan ko'ra. Ammo support ham alohida bo'ladi... Qo'shimcha resurs: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/

Haskell kundan kunga baqquvatlashib boryabti haliyam😎