Стань DevOps инженером за 4 месяца обучения! 🙌 wiki.merionet.ru/merion-academy/courses/devops-inzhener-s-nulya/?YT&

@52RK

2 ай бұрын

You are breathtaking! Я на канале минут 20, и каждое видео максимально понятное. Спасибо за ваш труд!

@GSSG70

2 ай бұрын

Не надо обманывать народ. Вы зазываете их всех и потом народ в обломе больше никогда не берётся за сферу IT. Нереально НОРМАЛЬНЫМ DevOps стать не то что за 4 месяца, там вообще во всех этих направлениях учиться всю жизнь. За 4 месяца более менее человека можно научить работать с командной строкой, разделение дистрибутивов, работа с установщиками ПО в каждом поотдельности, настройка сети и вообще основы блин TCP/IP, далее можно какой-то разобрать даже файер вроде ufw , но ни о каком iptables и всех на его базе речи не будет. И ты смотри мы ещё не дошли соответственно до разбора API и даже разбор протокола HTTP. Мы даже ещё не затронули что-то вроде сертификатов SSL. Ой, а ещё море баз данных вроде Mysql. Там как бы тоже различий много и если придётся работать с MS SQL или PostgreSQL, то мне жалко того девопса, который только Mysql или MariaDB изучал. В общем если было не 4 месяца, а год записано, то и в этом случае очень сложно. Да чего далеко ходить, какой-нибудь арч линукс с нуля без мануала кто-то установит? Вот ни разу не заглянув в мануалы установите? :) Это я сейчас не закидываю какашками, а просто пытаюсь объяснить, что все уже который год рекламируют сферу IT, но мало кто понимает сколько лет труда, бессонных ночей, нервов это будет стоить.

@kae6108

Ай бұрын

​​@@GSSG70Год-два это ни о чем время. В жизни 60-100 лет. Потратить пару лет и дальше всю жизнь развиваться в выбранной сфере, при этом не выискивая акции в пятерочке очень выгодно с точки зрения планирования жизни. Понятно, что не всем такой путь по душе. Ну а рекламой они занимаются ради собственной выгоды. Это их хлеб.

Видео краткое и понятное А монолит нужен там: - где нет запредельных нагрузок, так как с масштабированием проблема, но оно дешевле, так как при масштабировании микросервисов нужно на каждый сервис отдельно нода - где важна скорость взаимодействия, так как в монолите вся функциональность находится в одной кодовой базе и ноде, и соответственно все быстрее функционирует - где команда разработчиков способна работать в одном стиле и с одним языком программирования, все же дебажить монолит проще, чем микросервисы

@shurik4493

2 ай бұрын

поправка: на каждый сервис не нужна отдельная нода

@validationerror3830

2 ай бұрын

​@@shurik4493бывает, что нужна

@roninsh4341

2 ай бұрын

факты, которые не имеют отношения к современной кодовой разработке

Классный формат. Для начинающих так вообще идеально, все сжато и весело подается. Очень удобно повторять перед собеседованиями

@_vpru

2 ай бұрын

Формат - понос Тинькоффский. Нельзя по-человечески что ли объяснять? Обязательно петросянить?

@equim7363

2 ай бұрын

Если хочешь сурьёзный нудный формат - иди на просторы интернета, там полно материала про микросервисы.

@9968322594393

2 ай бұрын

Это же обзор, что из этого можно использовать на собеседовании? 😮

Я думаю, надо же, еще не видела это видео, а оно только вышло) Люблю вас за то что даже я понимаю)

Не забываем положить все микросервисы в монорепо 😍😍😍

@realfootball338

2 ай бұрын

А какая разница ? Если другие команды не лезут в другие сервисы то все ок. У каждой команды свои бранчи и все в монорепе это удобно. Скачал репу на мастере и поднял всю инфраструктуру локально через docker compose. Нужны другие сервисы подтянул к себе в бранчу бранчи других сервисов - это даже удобнее чем в отдельных репах

@hackyou497

2 ай бұрын

и использовать под каждый микрофронтент ФСД архитектуру

@FooFie2131

Ай бұрын

​@@hackyou497 фсд это просто структура папок. и все

В монолите если что-то лежит, лежит все приложение. Но и наоборот в микросервисах никогда полностью не работает приложение - обязательно что-то лежит :D

Лайк если у тебя микросервисов больше чем пользователей

@bpospanov

2 ай бұрын

😂😂😂

@RgavayaGalaktika

Ай бұрын

😂

Спасибо за вашу работу! Очень хотелось бы увидеть ролик про брокеры сообщений)

Контент очень крутой, и полезный, как раз сейчас на работе занимаюсь тем что разбираю монолит, и переношу его на мса)

Как всегда, в видео кто-то получает по жопе, зато понятно и забавно) А монолитную архитектуру проще использовать в маленьком приложении, которое даже если и будет обновляться и масштабироваться, все-равно вызовет намного меньше боли, чем реализация его с использованием микросервисной архитектуры. Например какой-нибудь новостной сайт

Большое спасибо за видео!

все объяснено простыми словами в доступной форме, огромное спасибо!

Вы как всегда лучшие, обожаю смотреть ваши видео😂, так держать👍🏻🤝

Как всегда очень полезно, чётко и по делу. Красавцы чё! 😊

Классное видео, хотел бы увидеть от вас видео про SSR/CSR

Спасибо за старания и контент. Грузим лукас.

Микросервисы - это только одна из нескольких распределенных архитектур. Есть SOA, в свое время словившая хайп не меньше, чем недавно микросервисы. Вдобавок еще есть service based и event driven архитектуры.

Ура, новое видео!

Монолиты удобно использовать в маленьких проектах с использованием clean архитектурой p.s. Хочется видос по DDD

Спасибо!😅

Как всегда годната

Можно узнать название саундтрека к вашим роликам? Контент очень краткий и интересный!

спасибо за видео

Монолит использоваться можно смело в случае маленьких проектов, например с фреймворком Django, можно создавать другие приложения в других каталогах, и при этом делать это зависимо и не зависимо, выходит можно разграничивать логику и при этом использовать одну кодовую базу. А в случае с большими проектами исключительно микро сервисы.

Еще есть протокол LDAP, что,для чего и где, было бы не плохо с такой подачей :)

А где у Вас в курсе SQL , AWS или GCP ,Kafka? Prometheus???

Мне как hr было полезно и понятно) спасиб)

За МОНОЛИТ!

Сделай gRPC vs REST vs http vs http2

@merionacademy

2 ай бұрын

Вы прям в самую точку, следующий видос - про это! Уже даже озвучен. Подписывайтесь, чтоб не пропустить)

@yourownazog8069

2 ай бұрын

@@merionacademy круто!

Микросервисы нужны только для разделения труда в больших проектах. Они не добавляют скорости приложению (наоборот) и стабильности. Если в "монолите" будет ошибка в api для авторизации, остальные эндоинты продолжат нормально работать точно также. Если внесены изменения только в модуль авторизации, его тоже можно загрузить отдельно точно также, а не весь проект. Зачем сбивать людей с толку такими видео.

@tomasddf

2 ай бұрын

А теперь представь синтаксическую ошибку в общем ядре - и вот уже ни одна страничка не открывается,😢, ни один метод апи не работает. Или та же ошибка, но например на более высоком уровне, например в базовом контроллере или одном из классов, которые он использует как зависимости - и вот уже отвалилось все апи сайта, и нет возможности ни каталог открыть, ни корзину ю

@wildcat4435

2 ай бұрын

@@tomasddf синтаксическая ошибка в общем микросервисе для извлечения данных из бд вызовет тоже самое. Правда он не скомпилируется скорее всего, но точно также, как и typescript код. И не будет меняться долгое время, но опять точно также, как и обычные базовые модули. Во вторых, с чего бы таким общим классам, от которых все зависят, вообще быть, меня никто не заставляет их делать, если я хочу более модульную архитектуру. Микромодули они и так есть в любой нормальной архитектуре приложения. Весь стек технологий для именно микросервисов нужно тянуть только в том случае, если это реально упростит жизнь команде и она точно знает зачем ей это. Если команда будет их делать потому что "так в фейсбуке и так сказал чел с ютуба" жизнь усложнится очень быстро, а с возросшим бюджетом на разработку заказчик может послать куда подальше.

@tomasddf

2 ай бұрын

@@wildcat4435 "синтаксическая ошибка в общем микросервисе для извлечения данных из бд". А это как? Каждый микросервис самостоятельно ходит в свою БД. Причем у каждого микросервиса эти БД могут быть разного типа, в зависимости от потребности

@BOPHAKOHE

Ай бұрын

Чем подкреплено тво мнение ?

@wildcat4435

Ай бұрын

@@BOPHAKOHE мО мнение подкреплено тем, что это исторический факт и его никто не отрицает. Иди лучше внедряй микросервисную архитектуру в лендинг пейдж своей мамы, а не пиши глупые комментарии

Все, уверовал... Теперь учу микросервисную архитектуру...

Мне понадобилось 48 часов...

Монолит лучше, где не требуется масштабировать, ну например гос сайт узкого направления. Микросервисы удобны масштабированием. Ну и тд.

@rexdraconis1703

2 ай бұрын

По факту, каждый гос сайт узкого направление это и есть микросервис.

Хороший ролик, для понимания топ

@vladimir.kravets

Ай бұрын

Жаль, что вводит в заблуждение, выдает желаемое за действительное. Low coupling прекрасно возможен в монолите и нарушить его запросто можно и в микросервисах. Микросервисы это в первую очередь история о том, что команда разработки начинает сильно превышать оптимум из 7-12 человек, по этому одна команда разбивается на несколько отдельных команд, которым надо независимо друг от друга уметь релизиться и вот тут микросервисы будут уже ой как кстати.

Монолиты можно использовать при реализации mvp продукта, тк это сильно дешевле, чем микросервисы пилить:) Если гипотеза взлетает, то можно уже делать полноценный продукт на микросервисной архитектуре. Хотя…нет ничего более постоянного, чем временные решения😢

О, открыли для себя flaticon :)

Для меня самый неожиданный момент , что в таких случиях можно писать на разных языках .

Когда вместо "функционал" начнете использовать "функциональность", будет совсем хорошо )

пушка

Че насчет транзакции, которая должна пройти через несколько микросервисов? И если посредине этой транзакции, когда часть процессов на определенных сервисах закончилисиь, возникает ошибка и нужно все изменения откатить. Монолит в этой ситуации рулит...

Я правильно понимаючто микросервисы возможны только со стороны сервера и только если программа сетевая. То есть программа которая устанавливается на телефон или компьютер пользователя она всегда монолитная и если ее надо обновить то надо пересобирать и перезаписывать всю программу и обновить чать программы на устройстве конечного пользователя не возможно?

@dmitryandreew8582

2 ай бұрын

совсем не обязательно что микросервсное приложение - сетевое. Например возьмем Evernote. Представим, что у него нет сетевых функций, но оффлайн функционал остался. Таким образом, наше приложение (Evernote) может быть поделено на сервисы (Заметки, Календарь, фотографии, тудушка и пр..)

@xtech3408

2 ай бұрын

@@dmitryandreew8582 тогда это многомодульный монолит. Про это в видосе не сказали, но можно запилить монолит из нескольких модулей, где у одного модуля может быть даже несколько инстансов, если это понадобится. Разработка модулей ведется сравнительно раздельно, так при деплое можно пересобирать только изменившиеся модули, и можно спокойно разделить команды, чисто технически можно использовать разные языки с учетом того, что четко прописан будет не только API, но и ABI(конвенция вызовов), естсно это работает только для языков с одной платформы, например jvm, .net, llvm или просто компилируемые в машинно-зависимые бинарники

@dmitryandreew8582

2 ай бұрын

@@xtech3408 Спасибо за пояснения. С монолитами приходилось работать только на стадии раннего мвп и тестирования бизнес идей, посему никогда не копал так глубоко как вы.

@andynaz7044

2 ай бұрын

@@dmitryandreew8582 И что тут глубокого продемонстрировано?

хорошее видео

По вопросу где лучше имхо для начала стоит рассмотреть структуру подразделений разрабов, вероятно, делить на отдельные репы стоит учитывая этот фактор, если у вас небольшая группа, фиг ли там городить микро?.. если у вас много больших команд, наверное стоит задуматься о гибридных вариантах… имхо. Буду рад, если кто поправит и выскажет свои мысли

@tomasddf

2 ай бұрын

Я думаю что архитектура вторична. Попытки все описывать микросервисами - это в некотором роде преждевременная оптимизация. Софт живёт и развивается, и на каждом этапе к нему разные требования. В начале важнее стоимость запуска и сроки, чуть позже становится важнее уже стоимость поддержки и изменчивость, способность противостоять неконтролируемому росту сложности, сохранение низкого порога входа и возможность с лёгкостью находить людей для поддержки. Так что нет ничего плохого в том, что на разных этапах жизненного цикла у софта разная архитектура. Софт меняется исходя из изменения требований к нему: на каком-то этапе отдельные модули монолита так или иначе придется выделять в отдельные сервисы, частично или полностью независимые от монолита. Например на ранних этапах этого процесса к монолиту прикручивают внешние сервисы, такие как например эластик, и формируют вокруг них слой поддержки, а позже все это отпочковывается в отдельный проект, чтобы быть проще, надёжнее, и хорошо выполнять какую одну конкретную функцию

не нужно дублировать текст мемом , как по мне. Можно просто заменить мемом слово и станет только лучше. Хотя бы протестировать. Извиняюсь, если сильно раскритиковал

@merionacademy

Ай бұрын

Спасибо, учтём)

Микросервисы нужны в первую очередь там где хайлоад. В противном случае у вас кратно увеличивается стоимость и время разработки и поддержки.

теперь про микрофронтеды пожалуйста

как вам идея создать видео, в котором расскажите, в каком порядке нужно учить тему сеть (networking)?

Как вывести текущую сессию авторизации например в пользовательскм интерфейсе? Когда они в разных микросервисах. При каждой загрузке сайта дергать другой сервис?

@rexdraconis1703

2 ай бұрын

Так фронт разве тоже микросервисно делиться? Если использовать около микросервисную архитектуру (например NX monorepo), то там проблем особо вообще не будет с этим. Или я не правильно понял вопрос?

@tomasddf

2 ай бұрын

Это задача апи гейта - это отдельный микросервис, который снаружи виден как монолит с публичным апи, а внутри по факту является диспетчером для всех остальных микросервисов и общается с ними через их отдельные апи или очереди. Так что с этой стороны все ок, фронт получит сессию авторизации точно также, как получил бы ее в монолите. Ну а под капотом апи гейт собирает ответ для фронта из данных от множества других сервисов. Но он их не дёргает каждый запрос, т.к. в таких системах обязательно применяется многоуровневое кеширование: он эту сессию каждый запрос будет доставать из какого-нибудь быстрого кеша, так что по затратам это будет сравнимо с отдачей статики. Сервис авторизации в свою очередь будет контролировать этот кеш: воссоздавать его при авторизации и инвалидировать при деавторизации или истечении срока жизни сессии.

За монолит!

А у меня микрозарплата

а где исходник примера.

Монолиты это жесть, особенно если они были написаны 10+ лет назад и их не хотят обновлять

@Aleksandr37rus

2 ай бұрын

Еще и на скриптах 😅 кайф легаси, смерть развитию

@rayman4x4

2 ай бұрын

Лол. Это как ругать родителей, что ты есть.

@user-yu5yz7pf4u

2 ай бұрын

Монолит намного проще ,ACID из коробки и нет гемора с сетью между сервисами)

@EarthCitizen124

2 ай бұрын

​​@@user-yu5yz7pf4u А еще транзакционность поддерживать между запросами... А еще всякие BFF для каждого микросервиса А про общий shared код - вообще молчу) его педалят все... и ломается оно сразу у всех 😂

@Chel1k7

2 ай бұрын

@@rayman4x4 программирование это не связь ребенка с родителем, здесь если ты не развиваешься - ты не просто стоишь на месте, а деградируешь

Ну девопсы не то чтобы прям легко с этим справляются 😂

Вообще, лучше монолит. Микросервисы - если у вас нормальный архитектор, который понимает: вот тут по другому ну ВАЩЕ никак. У нас на работе микросервисное и оно мальца без доков кумарит

@tomasddf

2 ай бұрын

А у нас монолит, и оно без доков тот еще ад. Лучше бы распилили на сервисы, чтобы уменьшить связность, и разграничить зоны ответственности между командами. А также в этом случае можно было бы получить преимущества благодаря независимости : у каждого сервиса свои задачи, которые эффективнее решать какими-то своими инструментами, в монолите же все вынуждены страдать, оставаясь в рамках одного общего языка и архитектуры, изобретая велосипеды, вместо того чтобы просто воспользоваться более подходящими инструментами. Отдельная боль - тестирование монолита. Степень связности там настолько высокая, что ни о каком автоматическом тестировании и речи быть не может, только ручное тестирование, только хардкор и боль. И нет никаких надёжных способов как-то ограничить рост сложности монолита: несколько команд, текучка, хаос, каждый лепит как умеет, количество костылей год от года растет, и разгрести все это ресурсов просто нет. Вместе со сложностью растет и количество ошибок и стоимость поддержки/разработки, контроля становится все меньше, и увеличивается текучка: копаться в этой куче навоза желающих нет, слишком высокий порог входа, слишком больно, и как вишенка нет документации, точнее она моментально устаревает, все держится только на экспертизе старожил, которых с каждым годом становится все меньше и меньше. Люди уходят, я тоже уже подумываю уходить, нервов уже на все это не хватает. Так что лучше уж пачка небольших микросервисов, рост сложности которых ограничен, в которых низкий порог входа и есть возможность всегда найти людей для поддержки, и самое главное, в которых четко ограничена сфера ответственности, на уровне архитектуры, и при всем желании повысить связность и сложность ни у какого отдельного разработчика просто нет возможности. Самая большая беда, когда какой-нибудь не особо умный разработчик пытается срезать углы, прокладывая новые связи там, где их быть не должно - это наиболее сильно влияет на степень сложности и количество ошибок, и это возможно только в монолитной архитектуре, где разработчик ничем не ограничен и может творить грязь.

микросервисы - микрослоники, напевал я , перенося полтерабайтные контейнеры со старого сервера на новый.

Монолиты хороши когда надо сделать что-то быстро и, скажем, протестировать какую-то бизнес-идею. Собрал мвп, выплюнул в фокус группу / реальных пользователей и смотри как оно работает. Работает - можем пилить на мс. Не работает - штош, не велика беда

@andynaz7044

2 ай бұрын

болтуна видно сразу

@dmitryandreew8582

2 ай бұрын

@@andynaz7044 поделитесь своим мнением

Нюхали как то “монолит”

А куда делось видео про кубер?

@merionacademy

19 күн бұрын

Оно там же, где и прежде 🙂

типо это разные html файлы, которые обращаются друг к другу на разных лвлах? не совсем понял суть микросервисов. Ну, да, удобнее работать над проджектом, но как их воссоединить?

Ну это в теории так работает. В реальности пишут монолиты и вяжут каким-нибудь нгинксом молясь на прокси

Видео о том, какой важный и нужный канал. Себя не похвалишь, никто не похвалит

5039 нах ) ps спасибо ребят за вашу работу очень познавательно

А можно пожалуйста еще гачистов в мемы, плз?

Я сейчас только монолит и пишу. Допустим боты на Python

Да нет никаких раньше и сейчас - монолитная архитектура имеет право на существование и никуда не денется. Новый проект проще, быстрее и гораздо дешевле реализовывать через монолит, чтобы не так жалко было осознавать, что он не взлетел и загибается, ну а если выстрелит, нагрузки и прибыли поползут вверх - тогда уже имеет смысл переписать его на микросервисную архитектуру. 🤔

Специально кладу сайт, чтобы получить по жопе.

02:28; 02:57

Рассказали бы лучше про курс подробнее, а то ссылкой тычите уже год

@merionacademy

2 ай бұрын

Вы можете узнать детали пройдя по ссылке, или пройти вводный урок! 🙂

@user-ql4xu5qu2u

2 ай бұрын

@@merionacademy там стандартный лендинг, ничего интересного

@merionacademy

2 ай бұрын

пройдите вводный урок, там будет интереснее! 🙂

Теперь хрен сделаешь магазин, стольким сервисам плотить, разве что наркоту продавать и то не везде, цены упали а сервисы умножились..

Несколько не согласен, что в монолите все перекомпилировать и пересобирать. Даже элементарные более оптимальные построения классов позволяют компилить только то, что создано вновь либо модифицировано. Потом, почему речь идёт только о монолите и микро?.. а где гибриды, скажем проекты, взаимодействующие длл или иными способами? Сборка одного длл конечно подразумевает общую сборку проекта в деплой, но речь не идёт о компиле или сборки с нуля всей кодовой базы

Веб разработчики такие Клоуны. Если у вас не гугл, Яндекс, сбер или что то похожее по размерам. Дрочь с Микро сервисами не нужна. Медленная, дорогая разработка, маленькая производительность, относительно монолитов. Увеличенное кол во программистов

А есть смешанный формат? Типа и то и другое, плюсы одного и другого

микрочл

Я 10

Я первый

Рест предпочтительно использовать в простых проектах, где нет потребности в огромной скорости и пропускной способности, но есть потребность в скорости развертывания и написания апи.

Спешу всех расстроить , на курсах devoos вы не научитесь🎉

@merionacademy

2 ай бұрын

А что за курсы по devoos?

Чувак, который создавал ролик видно какой-то программер? Скажи мне мил человек где ты последний раз видел программера, который бы САМ что-то любил оптимизировать? Может лет 20-25-30 назад были такие, которые были ограничены аппаратными ресурсами. Я вот например писал всякие системные штуки. Создатели игр тоже вынуждены были оптимизировать, потому чтобы в массы что-то пошло приходилось всё же двиги вылизывать. Но опять тут тоже ключевые слова ВЫНУЖДЕНЫ и ПРИХОДИЛОСЬ. Так за последующие 25 лет я ни разу не встретил разраба, который бы по своей воле что-то начинал оптимизировать. Конечно если писали какую-то уж очень дичь и какой-то запрос на кассе занимал по полминуты, то конечно некоторым ума хватало оптимизировать. Сегодня таких нет. Но зачем всем этим вообще заниматься? А давайте поделим всю эту хрень на кирпичи и всучим им совершенно другим кадрам. Пусть они мучаются. Как результат получили кучу новых технологий. Штук 12 точно, которые почему-то всем и сразу бывают нужны. Взаимозаменяемость? Не, не слышали. Написать в одном проекте? Не, тоже не слышали. И получается интересная вещь, что по сути все эти проблемы нагрузили на админов. Да да, тех самых самых обычных админов, которыем надо было с системой возиться, либо с сетью. Ну а кто бы ещё кроме них весь этот винигрет потянул? Проблема заключается ещё в том, что и классическое понимание каких-то инженеров, сисадминов, сетевиков изживает себя. Смотришь вакансию и не понимаешь, написано скажем хотят просто айти администратора, а вот функционал там как у начальника отдела поддержки по запуску ракет в космос. Или скажем позиция сисадмина, но функционал хотят тот же - работа с облаками, куча всяких кафок, докеров, шмокеров, кубернетисов. Так и хочется всех этих хитрозадых спросить - вам что в лом было написать что вы хотите вообще ДевОпса? Ну вы же Девелопера уже девелопером называете и от девелопера даже администрирования баз данных не требуете? В общем зажирается начальство в айти секторах. Если кто не понял поясню. Разница в зарплатах и нагрузке в разы. Потому никто даже правильно не пишет чего им надо на самом деле, но юзать тебя будут как девопса. Но есть ещё один нюанс. Даже если вы проработаете условно сисадмином на позиции для девопса, то вы даже в резюме своём это не сможете легально записать. В общем надеюсь понятно объяснил.

@merionacademy

2 ай бұрын

Добрый день! Отвечая на ваш вопрос касаемо разраба, которого мы видели и он любит что то оптимизировать - видели его в пятницу (2 дня назад) крайний раз!

@GSSG70

2 ай бұрын

@@merionacademyИ чего и зачем он пооптимизировал? Ну без подробностей конечно. Сегодня нет каких-то фанатиков или энтузиастов, которые будут пилить код до идеала. В основном все пашут чтобы просто работало. Конечно есть вспомогательные средства проверки кода, даже софт проверки на уязвимости, но по сути это так. Даже компании гиганты вроде Майкрософт, РедХат и т.д. этим не занимаются. А это как бы написание осей.

@merionacademy

2 ай бұрын

Добрый вечер! Отвечая на ваш вопрос: оптимизировал процесс планирования смен операторов!

@GSSG70

2 ай бұрын

​@@merionacademy Да ладно. Мне то какое дело человеку с 27 годиками опыта и 10 годиками образования. Я просто высказал своё мнение. И в подтверждение моих слов можно послушать что тот же Гейтс когда-то говорил сколько памяти кому хватит, потом посмотреть на современные сначала десктоп системы с потреблением памяти, потом на всякий случай глянуть потребление последними версиями андроида и в конец посмотреть уже тех характеристики роутеров и их осей. Ни в одной области оптимизацией написанного кода и не пахнет. Ни один фактически компилятор не выдаёт оптимальный код (мингва более менее ещё). Да вообще как махина типа ВС размерами в 50 и более гигов инсталяшки может оптимально что-то собрать? Её саму надо оптимизировать и оптимизировать. А новое никто ничего не создаёт, нормальное, компактное, безопасное и быстрое. Потому код уже по определению не может быть нормальным.

⁶⁷⁹

Можете просто какую-то дичь рассказывать в таком стиле, всё равно буду смотреть и в ладоши хлопать!

@dobry_music

2 ай бұрын

Действуй бро

Дурацкую музыку можно потише?

@merionacademy

2 ай бұрын

Извините, но ответ на ваш вопрос - нет, нельзя. Спасибо, что спросили!

@Glebcz24

2 ай бұрын

Пока не прочёл комментарий, вообще не заметил что там музыка есть на фоне.

@koussy.3572

2 ай бұрын

:) @@merionacademy

@rashidegintkhoev253

2 ай бұрын

@@merionacademy музыка тематическая и допустимая, но вас там не слышно, так что хотите берите ко сведению хотите нет

Дизлайк за вставочки-смехууечки. Это дно.

@zetta_55

2 ай бұрын

Что такое "дно"? пивнуха в Самаре? дизлайк за нипанятнае арго.

Кликбейт!! Написано 8 минут, по факту 8 минут и одна секунда!

@blackandyellow7125

2 ай бұрын

Везде ложь…

@Roger-qj4wu

2 ай бұрын

@@blackandyellow7125 не ложь а клади