en
Feedback
Programming ∀

Programming ∀

Open in Telegram

Ushbu kanalda IT va Dasturlashga aloqador mavzularda subyektiv fikrlarimni bayon qilaman.

Show more
1 217
Subscribers
No data24 hours
-87 days
-3530 days
Posts Archive
MacBook Pro 16” inch 2019 CPU i9 9880h 2.3GHz 8/16 RAM 16 gb GPU AMD Radeon Pro 5500M SSD 1tb Battery 154 cycles Работает идеально Ishlashi a’lo

photo content
+4

K8sdagi imkoniyatlar texnik yechim sifatida doyim qoyil qoldirgan. Masalan clustering va scalingga aloqador yechimlar. Undan tashqari juda ko'p integrationlar va flexibility :)

Man ko'rgan solutionlar ichida haligacha hayron qoldiradigan narslardan ko'plari k8s mavjud :) Yana bir ajoyib narsalardan biri esa k3os :) https://github.com/rancher/k3os

✨ Нужно всегда разделять прикладной и системный код (это минимум два слоя реальности), как и роли программистов, описал подробнее. 🧑‍💻 Прикладной программист пишет продуктовый код, занимается моделированием предметной области и автоматизацией процессов в ней. Прикладному программисту нужно знать node.js как инструмент, его возможности, концепции, преимущества и недостатки, но не нужно глубоко погружаться в код платформы, не нужно строить прослойку между node.js и прикладным кодом, не нужно изобретать фреймворки (внутри продукта), изобретать обобщенные инструменты и библиотеки, не имеющие отношение к предметной области. Если это происходит, то он выполняет две роли - системную и прикладную, они должны быть максимально отделены: отдельные репозитории, отдельное рабочее время и должность, отдельные цели и задачи. Чтобы писать системные вещи смотри вопросы в следующем разделе. 👨‍🔧 Системный (платформенный) программист пишет код, не связанный с предметной областью: фреймворки, сетевые протоколы, транслятор, компиляторы, интерпретаторы, библиотеки, занимается вещами, которые могут быть переиспользованы в сотнях и тысячах разных проектов. Это называется производство средств производства. Систем программисту нужно знать node.js гораздо глубже, не только, его возможности, концепции, преимущества и недостатки, но и недокументированные возможности и даже баги, особенности платформы, которые очень редко используются, потому, что он строит прослойку между node.js и прикладным кодом, а прослойка эта позволяет делать прикладной код более абстрактным и приближенным к предметной области.

((a × b) × (c + d × e)) Tokenization haqida
+1
((a × b) × (c + d × e)) Tokenization haqida

Savol axmoqona bo'lishi mumkin. Ammo masalaga primitiv qaramasligingizni iltimos qilar edim ! Tassavur qiling hamma aytgan gap amalga oshdi 100% Engineer ishini AI qilyabti. Hosh AI uchun ham paragmatistic point of viewlar kerak bo'ladimi :) Yo'q deyishga shoshilmang. Ha deyishga ham.

Yoshligimda yosh edimda :) Biror narsani biror narsaga bog’lab o’rgansam. Haa deman bu narsa faqat shunda bor ekan… Shunday fikrda bo’lib olar edim el qatori 😃 Keginchalik tushunib yetdimki u narsa boshqalarda ham bor va avvalo u narsaning umumiy qolipi yoki izohi mqvjud :) Masalan JS da async/await bor. Bu narsa faqat jsga hos emas. JSdagi asinxron ishlash ham faqat jsga hos emas. Asynchronus programming degan alohida bo’lim bor computer scienceda 🙂 Hammasi ashiyerdan boshlangan hurmatli grajdanlar :)

Ushbu mavzular haqida o'ylar ekanman yana bir narsani tushundim. Bu "paradigm paradox in business". Bu haqida kim qanday fikrlar aytgan ammo mani fikrlarimga ko'ra bu paradoxga aylangan edi. Business uchun ishlaydigan narsa kerak ammo qachondur sifat ham kerak. Paradigm sifatni beradi ammo boshqa narsani oladi biznes esa bularni yoqotish intervalida kasod bo'ladi ))) Qiziq paradoxni qanday buzish mumkin ? Yoki buzish kerakmi ? Lekin bazi holatlarda buzilyabtiku )) Buzilsa nega paradox ? Bu masalaning yechimlari turli ko'rinishlarda va holatlarda kengayib ommalashib borayabti )). Balki tor doirada qolib ketar. Lekin bu paragmatic fanatism emas ekaniga ishonchim komil. Paradigmlarni targ'ib qilayotganlar ularning ko'r ko'rona muhilsi emas. Shunchaki ular boshqalarga qaraganda ko'p savol berishadi. Paradimglar esa ulardagi abstract savollarga aniq javoblarni va yechimlarni taqdim qilgani uchun sevishadi )) Yana boshqalarga bu savollar va ularning javoblari qiziq emas bir kam dunyo :)

Endi so'z yakuni sifatida. Procedurial programmingda siz kompyuterga nima qilishni aytasiz. OOP yoki FPda esa siz kompyuterdan nima hohlayotganingizni aytasiz :) Cho'loq OOP orqali nima hohlaytoganingizni qanday izohlaysiz 😁

Endi o'sha xozirgi cho'loq OOP haqida :) Alan Kay 1998 yilda object haqida birmuncha boshqacha ekanini aytdi va bo'shqa yaxshiroq messaging degan g'oyani izohladi. Maqola uchun havola: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html Xozirgi OOP cho'loq ekanini qanday izohlashadi ? Agar haqiqiy OOP tadbiq qilinsa qanday bo'ladi ? Dasturlash tili dizaynerlari focusni user friently va ma'lum orientationlarga qaratishgan. Shu o'rinda ma'lum nuqtalarda yangiliklar qilishgan. Masalan bazilar orientatsiyalarni perfomance va tezlikga qaratgan bo'lsa yan bazilar sodda syntaxga qaratgan. Undan tashqari bazi tillar aynan maxsus ishlar uchun yo'naltirilan. Yana bazilari esa maxsus paradigmlarni tadbiq qilishga qaratilgan. Ushbu nafaqat tillar formal lagunages nuqtai nazaridan balki ma'lum prioritetlarga qarab baholangan. OOP SmallTak dan boshlangan bo'lsa. Xozirgi mashxur C++ JS, PHP, Java C# kabi tillargacha kirib keldi. Umuman ushbu tillarning asosi C++ :) C++dagi OOP rivojlandi desa ham bo'lar balki ). Ammo to'liq unday emas. O'sha davrlardagi industry tilni soddalashtirishga osonlashtirishga xarakat qildi. Nega ? Oldin code faqat bir tipdagi processorlar uchun yozilgan. Paradigm yoki boshqa narsalarga etibor qilinmagan. Asosiy masala biror narsani bajarishga qaratilgan va bu jarayon anchagina murakkab bo'lgan. Keyin C kabi tillar chiqdi. Ular qaysidur ma'noda cross platform negaki bitta codeni birqancha processorlarga compile qilish mumkin edi. Keyin C++ uni yana osonlashtirishga xarakat qildi. Undan keyin Java/C# C++ ni osonlashtirmoqchi bo'ldi :) Bitta code turli OSlarda ishga tushadigan bo'ldi vaxakzolar :) Tillar osonlashti va abstraksiya yuqorilashdi. Projectlar kattalashdi codebase kattalashdi. Endilikda faqatinga oson til emas balki yana boshqa talablar qo'yila boshladi. Cho'loq OOP esa paradigmni notog'ri tadbiq qilishdan boshlandi. OOP dagi intheritence mavzusini o'qiganmiz. Hosh bu nega kerak ? Inheritence o'zi nima ? U bilan nimaga erishamiz ? Ko'pchilik kamroq code yozish uchun desa yana bazilar kengayishni nazarda tutadi :) Aslida qisman ikkisi ham to'g'ri ammo biz ishlatadigan inheritence noto'g'ri tadbiq qilingan. Objectlar boshqa objectlardan tashkil topishi degani bu classlar boshqa classlardan meros olishi degani emas :) Shu kabi static methodlar. Yoki null g'oyasi vaxakzolar. Bular biz tilni ishlatishimizni oson qilishi uchun ham tadbiq qilingan va hamma bir biridan ko'rib rivojlantirgan. Hosh demak shunday ko'chirmachilik asosida bo'lgan evolution sabab OOP mutantlashdimi ? Qisman ha bu ham talab va taklif masalasi. Man JS ni yoqtiraman ammo undagi mutant OOPni emas. JSda primitive tiplar masalasini o'zi ham biroz og'riqli :) Nima endi bularni hammasi qog'ozda qolaveradimi ? True OOP cho'loq OOPni ustidan kulishga o'ylab topillganmi shunda ? Aslida yo'q, qisqa aytganda OOP ideologiyasi birdaniga ko'p tomonlama rivojlandi. Sciencedan tez kirib keldi katta sayoz auditory yegdi. Bu masalaning yechimi FP kabi. FP auditory xozirgacha yangiliklar qilishadi. Yangicha yechimlar patternalar yuzasidan ko'plab ilmiy maqolalar va izlanishlar olib boriladi. Huddi shunday FP birqancha tillarda sucessfull implement ham qilingan (Haskell, Scala, Elixir). OOPda esa asosan ko'p marketing bo'lib qoldi :) Shu sabab cho'loq OOP shunday ildiz otdi. Ammo FPdagi bazi baxsli mavzular ko'p ayniqsa tiplar genericlar va yana boshqa type theory and computingga aloqador. Shu sababdan ham rivojlanish yuqori. OOPdan esa adabiyotlar xozircha kam izlanishlar ham kam. Ushbu mavzular ham rivojlanadi va yangi tillar paydo bo'ladi. Ammo FP kabi tor auditoryda qoladi katta extimol bilan. Asosiy sabab hamma ham biror yechimni aniq ma'lum formalistik asoslar bilan asoslagisi kelmaydi. Shundoq ham boshqa pointlar ko'p :)

Agar siz paradigmlarni amaliyotda qo'llaydigan darajada bo'lishni xoxlasangiz. Xozirdan versuslarni kamaytirib ko'proq o'qish kerak sababi mavzjula juda katta va keng tarmoqli :)

Masalaning asli ilm fan va biznes mavzusi desa ham bo'ladi. Dasturlash paradigmlari bu fan. Uning bir tomoni xisoblash va informatikaga qarlgani bilan asosi matematika xisoblanadi. Nega aynan Math ? Sababi biz xozirgi o'rganadigan va foydalanadigan narsalarning asosi matematika va undagi g'oyalardan olingan yoki to'g'ridan to'g'ri tadbiq qilingan. Shu bilan birgalikda Math biror narsani isbotlasa juda ko'p holatlarda ushbu yechim o'zgartirib bo'lmaydigan darajada to'g'ri va aniq bo'ladi. Sababi biror masalani yechimi shunchaki og'zaki yoki intuitiv emasligida. Shu o'rida har bir qonuniyatga ma'lum contextlar yuzasidan amal qilinadi va huddi shunday tekshiriladi. Lekin birqacha bosqichli abstraksiya evaziga biz bularni sezmaymiz va shu sababdan ham xozir dasturchi bo'lish uchun matematika muhim emas. Ammo bu mavzudan actual masala yuqorida aytganimday paradigmlar haqida. Keyingi masala esa formalizm masalasi. Paradigmlarda formalizmga qattiq etibor qaratilgan. Shu orqali mavhumlik imkoniyati maksimal darajada kamaytiriladi. Bu esa aniqlik va kam xatolarga eng asosiy sabab. Dasturlashdagi paradigmlarning ko'pida asosan matematik formalizm no'rmalarini sezish mumkin. Bu esa har bir gipotiza yoki yechimning aniqligini ta'minlaydi. Hosh paradigmlar bizga shunday imkoniyatlar taqdim qilar ekan nima uchun asosiy hamjamiyat bularga amal qilmaydi yoki tadbiq qilmaydi ? Bu faqat tor doirasa qolib ketaveradimi ? Paradigmlarda auditory tor ekaniga asosiy sabablardan biri gipotizalar ko'p ekani. Undan tashqari bu mavzularga support kam ekanligida. Qachonki ushbu paradigmlarga etibor darajasi oshadigan bo'lsa shunda yanada tezroq rivojlanadi. Biznes esa dasturlashga asosan instrument sifatida qaraydi. Ushbu nuqta muhim. Nega sababi biznes nimadurga oson erishib oson sotish orqali katta foyda olishni ko'zlaydi. Agar siz biror startup qilsangiz katta extimol bilan juda ko'p narsalarni skip qilasiz. Eng minimal resurslar bilan maksimal rezultat xarakatida bo'lasiz. Shu sabab juda ko'p xolatlarda staruplar trashcode bilan boshlanadi. Endi masala enterprise va anchadan buyon ishlab kelayotgan tizimlarga qolyabti. Startuplardan umid juda kam ekan )) Hosh ildiz otgan tizimlar bu masalaga qanday qarashadi ? Biznes stabillikni hohlaydi. Demak mavjud narsani o'zgartirish uchun critical holatlar bo'lishi kerak. Uchinchi holat esa. Loyihadagi talablar aynan ma'lum paradigmlar asosida yechiladigan yechimlarga bog'liq. Shu o'rinda ushbu resurslarni ta'minlashga imkoniyat mavjud. Bu holatda bemalol yaxshi promotion qilinadi. Kerak bo'lsa yangiliklar amaliyotda sinaladi. Nega engineerlar o'zlari ushbu masalani to'liq implement qilishmaydi. Hosh aynan OOP yoki FP paradigmlari ustida ishlaydigan juda bo'lmasa chuqurroq o'rganishga xarakat qilib amal qiladigan engineerlarning juda ko'pari juda zo'r background egalari. Shu bilan birga o'zlarining ma'lum ambitsiyalari asosida ishlaydilar. Shu o'rinda "Toza OOP yoki FP elegant engineerlar uchun" yoki "OOP yoki FP haqiqiy dasturchilar uchun" Degan fikrlarni ham ko'p aytadilar :) Aytganimday bizneslarning barchasi ham bunday hodimlarni ishga yonlay olmaydi :) Talab bo'lmasa taklif bo'lmaydi... Bu ketishda hechkim biror narsani o'zgartirgisi kelmaydiku. Ha yuqoridagi kabi masalalar sabab paradigmlar tor doirada qolmoqda. Ammo xozirgi kunda paradigmlar populatsiyasi anchagina o'sganini ko'rish muhimkin. 20-30 yil oldin ushbu masalalarga juda kam odamlar etibor qaratgan bo'lsa endilikda xatto bizda ham paradigmlar muhlislari ko'payib borayabti. Endi masalaning eng muhim qismi. Rostdan ham ma'lum paradigmlar shunchalik muhimmi ? Ushbu savolga javobimni aytaman ? Cubeni cube ekgani sizga muhimmi ? Agar shu savolni javobini o'zgarmaydigan darajada bermoqchi bo'lsangiz paradigmlar muhim. Agar sizga cubeni shunchaki qilish kerak bo'lsa. Yana qo'shimcha izoh o'rnida paradigmlarni chuqur o'rganish bizga juda ko'p narsalarga aniq javoblar topishga va har qanaqa darajadagi abstraksiya bilan ishlashga katta yordam beradi.

Nega paragmatic community tor doirada ? Paragmatism qanday darajada bo’lishi kerak ? Bu nega kerak ? Nega judayam tor doira insonlar xozirgi OOPni qoralaydi xato deydi ?

Ushbu post comentiga. Masalalar bor resurslarni yuboring. Aynan web korinishda bolishi shart emas kitob ham bolaveradi. Aynan dasturlash bo’lishi shart emas. Fizika matematika ham bolaveradi.

MongoDB 7.0 Relase candidate :) Ehhe... https://www.mongodb.com/docs/upcoming/release-notes/7.0/

Boshqa sohalardan farqli aynan ITda asosan management juda rasvo. Fikrimcha bizda management maktabi success bo’lishi extimoli bor. Sabab O’zbeklarda muomila va cominication biroz boshqacha. Shuni sal to’g’irlab suniy qismlarni olinsa yaxshi fundament mavjud 😀

O'rtoqlar bir fikr kelib qoldi. Dasturlashni o'rganinglar deb mana ancha bozorni to'ldirib oldik. Endi AyTi korxona ochish, uni yurgizish, buyurtma olish yoki startuplar qilish haqida ham xuddi shu dasturlashga qilgandek bunga ham bosib reklama, targ'ibot qilish kerakmikin, yo'l-yo'riqlarini o'rgatish kerakmikin, nima deysiz? "Treningchilar aytayotgan o'z biznesingizni yo'lga qo'ying va pul ishlang" ko'rinishida emas, chuqurroq va batafsil yo'l yo'riqlar.

Bu haqida alohida yana post yozaman Hudoholasa. O'ylaymanki chartlardan asosiy g'oyani va tushundingiz. Va yana o'ylaymanki b
Bu haqida alohida yana post yozaman Hudoholasa. O'ylaymanki chartlardan asosiy g'oyani va tushundingiz. Va yana o'ylaymanki bu masala haqida yaxshilab o'ylab ko'rasiz maqola chiqganda discussion uchun. Chart uchun havola: https://my.visme.co/view/kk0zrp1x-untitled-project/#s1

Kun yakuniga shu videoni ko'rib uxlash kerak oma. https://www.youtube.com/watch?v=S6_R5j8hzbY