Programming ∀

Linkedin prank qilyabti…

Mutabilityni sevadiganlar uchun maxsus 😕

Nodejsda file move command yo’q ekanini endi bilibman 😁 Hosh move yo’q bo’lsa qanday yechim qilish mumkin ?

WTH, prankmikan bu yoki bo'lmasam razerni sayti ahostda turibtimikan 🤔

Alerting + Autoscale. Qiziq usecase. Tassavur qiling ishlab turgan tizimda load ko'payib ketdi va alerting bo'la boshladi CPU, RAM, DISK Deyarli to'lgani haqida info kelayabti. Shunday caseda autoscaleni automation qivorish kerak ekan. Aynan downtime bo'lmasligini oldini olish uchun. Masalan yangi volume qo'shvorish. Yoki bo'lmasam yangi cluster memberlar. Umuman turli approachlar qilsa bo'ladi. Bazi technologylarda bunday imkoniyatlar uje bor bo'lsa ham kerak adashmsam. Kimda shunday holatga extiyoj bo'lgan va qanday yechim qilgan ?

Mayli bugun trash markazlar va u yerdagi "mentorlar"ni hate qilmaymiz. Ularni kuni bo'lmasa ham bizni asab ketmasin 😎

Bugun o'zimga nima sovg'a qilsam ekan. Juda o'ylanib qoldim shu mavzuda 😎

Paradigmlar haqida qiziq hodisalarni kuzatdim. 1. Bazi paradigmlarga amal qiladiganlar mohiyatni tushunib emas balki shunchaki absurtlarni copy paste qilib ishlashadi. OOP haqida beriladigan ma'lumotlarni ko'plari aynan shu absurtlarga boy. 2. Paradigm paradoxlar mavjud. Ayniqsa traditional software engineeringda shunday. Yuqori bilim tajribali engineerlar jamoada kam yoki umuman yoqligi sababdan paradigmlarni buzishni paradox ko'rinishida amalga oshirishadi. — Business uchun ish tez bitishi kerak... — Biz hamma narsani murakkablashtirsak boshqalar tushunmay qoladi... 3. Paragmatical idealar asosi subyektiv fikrlardan kelib chiqadi. Lekin ma'lum formalism aspectlari orqali ushbu g'oyalar obyektivroq tus oladi. 4. Ko'p paradigmlar asosida Matematika bo'limlari yotadi. To'plamlar nazariyasi, Kategoriya nazariyasi, Lambda calculs, Calculs, Linear algebra. Bu yaxshi yoki yomon ekaniga aniq fikrlarim yo'q. Ammo matematik paradoxlar o'z o'zidan buyoqga ham aralashish extimoli bor. Lekin buyam shunchaki asossiz fikr. 5. Paradigmlar taqdim qiladigan yechimlar tomondan qaralganida juda ham o'xshash bo'ladi. Ammo yondoshuvlar farq qiladi. 6. General va specific paradigmlar mavjud. General paradigmlar o'ta complex va keng qamrovli bo'ladi. Specificlar asosan paradigm bo'limlari yoki kengaytirilgan yoki biror narsaga yo'naltirilgan ko'rinishda bo'ladi. 7. Paradigmlarni mix qilish masalan OOP va FP dagi bazi approachlarni qo'shib ishlatish bazida juda keng tarqalgan. Lekin mix qilish odatda katta prioritetizatsiya qilishga ham sabab bo'lishi mumkin. Sababi mixlardan boshqa side effectlar chiqmasligi uchun. 8. Aynan paragmatism tarafdorlari juda kichik jamiyat. Asosiy engineering jamiyatining taxminan maksimum 5-10% qismini tashkil qilsa kerak. Lekin shu torgina jamiyatlar ham juda ko'plab jamiyatchalarga bo'linib ketishgan. 9. Paradigmlar orasida aynan Functional programming jamiyati ancha active. Shu o'rinda adabiyotlar va resurslar ham juda ko'p xisoblanadi. Ammo mavzular asosan adavanced :) 10. Aynan biror paradigm oriented engineering uchun joblarda junior positionlar deyarli yo'q 😁

Inheritanceni DRYga juda mos keladi deganda bir g'alati narsani sezib qoldim. Suxbat kecha bo'lgan edi bu savol bugun keldi. Shu kabi narsalardan chiqadigan side effectlar DRYni buzish bo'ladiku ? Chunki har safar birxil turdagi muammolarni chiqarasiz 😁 Demak DRY bug levelda ham mavjud ekan :) Qolganlar qanday fikrda ?

Juda qiziq mavzudagi kitob uchrab qoldi. Yaqinda analog xisoblash mavzusida qiziq suxbat qilgan edik. O'sha suxbatdan keyin xisoblash tizimlari yanada qiziqtirib qo'ydi. Organization of computer systems kitobida digital computing qanday amalga oshirilishi, tarixi, rivojlanishi va turli texnik yechimlari haqida tanishgan edim. Mavzular juda qiziq va birmuncha murakkab edi. Ammo bu kitob mavzulari va aynan xisoblashga qaratilgan turli yondoshuvdagi contentlar etiborimni tortdi. Shu yilgacha Menga traditional digital va quantum computing tanish edi vanihoyat analog computing... Qiziq yana qanday xisoblash tizimlari mavjud. Bu tizimlarni aynan birortasiga industury o'tganida yoki o'tish jarayonida traditional engineerlar nima qiladi ? Qiziq savollarim ko'payib ketdi )) Ammo kitobni o'qish kerak manimcha katta dunyoqarash beradi va ko'p savollarimning va boshqalarning savollarini javoblari bor bu kitobda ))

Analog and Hybrid Computer Programming, 2nd Edition (2023) Автор: Bernd Ulmann Количество страниц: 335 Классические цифровые компьютеры приближаются к своим физическим и архитектурным границам, поэтому интерес к нетрадиционным подходам к вычислениям, таким как квантовые и аналоговые компьютеры, стремительно растет. Для широкого круга практических приложений аналоговые компьютеры могут превосходить классические цифровые компьютеры как по скорости вычислений, так и по энергоэффективности. Книга представляет собой введение в программирование аналоговых и гибридных компьютеров. Оно содержит большое количество практических примеров, начиная с простых задач, таких как радиоактивный распад, гармонические осцилляторы и кинетика химических реакций, и заканчивая сложными темами, включающими моделирование нейронов, хаотических систем и многое другое. Скачать книгу

Nazarimda bazi "Hackaton"ga otni kallasiday pulni saflab ishlamaydigan software product olgandan ko'ra. Yuqoridagi kabi tizimlar ishlab chiqib product or industury based modification qilgan afzal. Masalan manga qiziq bo'ldi yuqoridagi event. Maqsad 10k$ yutuq emas haqiqiy challenge :)

Our colleagues from Russian-Armenian University together with my friends from a large and famous IT company organize a competition for the developers of EOLANG LLVM-based code analyzers, with a prize of $10K for the winner: submit your project here.

Лидирующая финтех компания Payme открывает набор на оплачиваемую стажировку с возможностью дальнейшего трудоустройства в отдел backend разработки. Что мы ожидаем от кандидата: — Фундаментальные знания JavaScript — Опыт разработки на node js будет преимуществом — Желание развиваться как Backend разработчик Мы предлагаем: — Обучение в высокопрофессиональной команде и возможность стать её частью! — Длительность стажировки от 1 до 3 месяцев — График 5/2, с 10:00 до 19:00 — Условия оплаты обсуждаются на собеседовании Обучение будет проходить на русском языке. По окончанию стажировки, показавшие лучшие результаты стажеры будут трудоустроены на позицию Junior backend разработчика. Для участия в отборе необходимо отправить резюме в TG - @dianaKpayme с пометкой «Стажировка в backend». Резюме, направленные без пометки, к сожалению, не будут рассмотрены.

Ha yana bir narsa bor. Bu mavzuni anchadan buyon gapirib kelaman. Oldin fikrimni bayon qilay. Agar man biror o'quv markaziga pul to'lab o'qiydigan bo'lsam. Ushbu tashkilot va u yerda dars berayotgan kishilar haqida quydagi fikrlarim mavjud. Tashkilot: Shunchaki tashkilot u bilan Meni bog'lab turadigan narsa o'rtamizda kelishuv. Man ushbu tashkilotdan N miqtordagi pul evaziga aniq yo'naltirilgan ta'lim xizmatini sotib olaman :) Uztoz/Mentor: Ushbu tashkilot ishchishi. Shartnomadagi mavzuga doir barcha huquqlariga ega. Yani man dars qilmasam haydab yuborishi ham mumkin. Ammo uning ham aniq vazifasi bor va bular keltirib qo'yilgan. Ammo o'sha mentor offtopic mavzularda uztozlik qilishi esa offtopic. Endi tashkilot va mijoz o'rtasidagi munosabatlar. Man tashkilotdagi insonlar bilan hoh kotta hoh kichik vaxakazolar bo'lsa qanday gaplashishim yoki gaplashmasligim Manga bog'liq. Bu degani ushbu tashkilotdagi qandaydur "kattakon"lar bilan uzoqdan salom berib qo'lim ko'ksimda bo'lishi kerak va ularga o'ta lutf bilan muomila qilishim kerak degani emas. Ko'z ko'zga tushganida el qatori qarz salomini berishim kerak(Uyog'i insoning madaniyati darajasida. Chunki salomlashishning ham turi, uslubi ko'p). Bazi tashikotlar o'zini xizmat emas balki qandaydur juda ko'p priviligega ega joylarday qilib tanitayotganini eshitganim uchun ushbu fikrlarni bayon qildim. Masalan Man ingliz tilini o'rganishga borganimda Ingliz tili o'qituvchim Manaviyat/Marifat va tarixdan dars berishini hohlamayman. Hohlasa bersin ammo Manda ham tanlov bor hohlasam olaman :) Ammo u kishi o'zini bunga ham majburday tutishi shart emas. Social Distance degan mavzuni yaxshilab o'rganib chiqishimiz kerak...

Eskilarda maktab yaxshi bo'lgan. 10-15 yillik engineerlarning ko'plari bilan gaplashganimda. Fundamental bilimlari yaxshi ekani shundoq sezilib turadi. Ayniqsa Computer science backgrounda univerda o'qiganlar(Gap aynan uzb univerlarida o'qiganlar haqida emas umuman). Shu o'rinda xozirgi boshlangich xamkasblarda nazar solaman(O'zim ham shu qatori). Fundamental bilimlardagi yetishmovchiliklar shundoq sezilib turadi. Gap faqat nazariy bilimlarda emas. Shunchaki dunyo qarashda. Eskilarni dunyo qarashiga faqatgina tajriba sabab emas yaxshi fundament ham bo'lgan. Hulosalarimni aniqroq olish uchun asosan qanday mavzular qiziqtirishidan tortib qanday mavzularda o'qigan qanday resurslar adabiyotlardan foydalanganlarini ham so'rayman. To'g'ri bazi oldschool engineerlarda faqat bilgan narsasini qilish yoki bir tomonlama fikrlash kabi narsalar bor. Ammo bular har qanday kvalifikatsiyadagi insonlarda mavjud. Shu sabab yuqoridagi gaplar bunday insonlarga nisbatan emas. O'zim uchun kashf qilgan farqlarim. Ko'p tajribali engineerlar ma'lumotlarning asosiy qismini kitoblardan olishgan. Bu narsaga infratuzulma ham sabab bo'lgan chunki media rivojlanmagan edi. Demak default holatda ularda talablar yuqori bo'lgan. Bizda esa resurslar uchun asosiy manba bo'lishi mumkin bo'lgan narsalar birqancha. Bu vaziyatni yanayam murakkablashtiradi. Ushbu vaziyatni esa huddi yo'llarga qiyosladim. Oldinlar asosiy yo'llar sanoqli bo'lgan bo'lsa barcha shu yo'llardan yuradiganlar avvalo ko'p sabr qilishgan va ushbu yo'lni manzilga olib borishiga ishonib barcha ogir yengiliga chidab davom qilishgan. Xozirda yo'llar ko'p huddi labirint kabi. Insonlar esa yo'l davomida tugab qolishyabti....

O’quv markazlardagi o’ta bilimsiz “uztoz”larning ko’pligi kuchli mutaxasisslardan ham shubxalanishga sabab bo’layabti. O’tgan yili bir tashkilotdagi “mentor” bir joydagi internship interviewdan otolmagan edi…

Maqsad bir insoning xatosi sabab hamani qoralash emas: 1. Fakt checking and validation masalasi. 2. Shu bir inson qolganlarning obrosizlantirayotgani. Biror kishi biror joyda dars berayotgan bo'lsa jiddiy qaralmaydi. Chunki shunday insonlar dasdidan ustozlar yana obrosizlangan. 3. Masuliyatsizlikning oqibati. 4. Menga alam qildi bu voqea !

Birovning xatolarini qoralamoqchi emasman. Ammo uztoz deb ko'rsatilgan kishi aynan bunday qo'pol xatoliklarga yo'l qo'yishi alamli bo'ldi....

Gap aynan higtload haqida gap ketganida. Aynan pedogoglardan sifatli javob kutiladi. Bizning IT communitylarda bu mavzular juda ham actual bo'lmasligi mumkin sababi talab, tajriba va resurs kam bo'lishi mumkin. Ammo o'quv markazlardagi uztozlarning juda oddiy masalalarda primitiv qaror qabul qilishi juda og'ir keladi. To'g'ri boshlang'ich dasturchilar bunday mavzularni farqiga bormasligi fakt checking qilolmaslgi mumkin. Ammo bu mavuda tajribasi bor kishilar farqlaydi. Masala aynan o'zi tajribasi umumay yo'q ammo dars berayotgan "uztoz"lar haqida. Ha bu mavzuni man ko'p gapiraman tanqid qilaman. Taxminan 2 yildan buyon :) Lekin mavzuda o'zgarishlarni hech ko'rmadim. Xozir aynan bir masalada shaxsiyga yozishgan ekan. Masala shundaki: Aynan juda ko'p get requestlar bo'ladi. Shu o'rinda DB barchasiga javob berishga ulgurolmay qolyabti va down bo'lyabti. Yechim sifatida DB ni redisga cache qilishgan. Ammo memory va storage to'lib qolishni boshlagan. Yechimni taklif qilgan inson redisni shunchaki app turgan serverga o'rnatib localhostdan call qilgan. Xatolar: 1. Redisda persistance bor ammo memory qimmat resource. 2. Requestlarni hechqanday benchmark qilinmagan. Bu degani 1 soniada qancha paralell connection mavjud ekani haqida hech qanaqa tassavur yo'q 3. DB indexlar analiz qilinmagan shunchaki berib ketilgan. Ortiqcha memory va storage. 4. App bittagina instanceda ishga tushadi shu o'rinda single app. Yani butun boshli loyiha 1 ta kichik serverda va 1 ta process. 5. Downtime mavzusi ochilmagan ham docker-compoose.yaml shunchaki ko'tarilgan :) Yana boshqa juda ko'p ogriqli mavzular bor. Source code haqida esa gapirmasa ham bo'ladi. Xozirgi holatda shu masalani hal etib berish juda actual va ular qancha bersa ham rozi edi. Chunki keyingi haftadan katta load bo'lar emish. Juda tez yechim: 1. Nginx cache. Yani getway levelda cache qilish. TTL kichkina qo'yib ishlasa ancha effective aynan yonayotgan holatda. 2. Instancelarni ajratish. va Load balancing. 3. Minimalroq HA infra qurish. Clusterlar yordamida. App va DB uchun. Kerak bo'lsa readlarni alohida DB da qilish. DB uchun maksimal holatda docker-swarm juda zor versiya. Albatta vaqt sal ko'p bo'lsa bahonada yaxshi Pipeline qo'yib olinadi. 4. Query optimization. Indexing... 5. Cache qisimni redisdan to'liq olib tashalb. Transport levellarda qilish. Search va anaytics qismlarni qoldirsa bo'lishi mumkin yoki elastic ishaltish. Juda foydali: Monitoring, Logging, Alerting, Error tracking, Distrutive transaction tracking va boshqa tracing tracking loggin yechimlar. Bular bo'yicha resurslar. https://www.nginx.com/resources/wiki/start/topics/examples/reverseproxycachingexample/ https://redis.io/docs/interact/search-and-query/query-use-cases/ https://www.designgurus.io/blog/high-availability-system-design-basics https://blog.devart.com/how-to-optimize-sql-query.html