Благодарю, интересно. Записывайте еще, если не трудно.

Спасибо за свои программысли, очень помогают увидеть вещи под другим углом)

Отличный выпуск, спасибо! =)

Спасибо, личный опыт это драгоценно. Спасибо и Божьих благословений Вам и Вашим близким.

@andrei2242

Жыл бұрын

Аминь

Ох, спасибо, Михаил. У меня опыта в программирований недавно стукнуло 3 года. И мне нравится тейк про то, что нужно осознанно подходить к задаче, и прежде чем что-то выбрать или начать производство - понять, а что это такое и нужно ли оно? Не идти просто так за всеми. Такой же подход в каком-то из подкастов говорил Соер, ну он собственно и топит за осмысленную разработку, когда ты понимаешь, что делаешь.

@programisli

Жыл бұрын

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

Много новых терминов узнал, спасибо за рассказ)

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

Выходить из vim….)))

@programisli

Жыл бұрын

Научился, но это не самое важное из того, что я узнал

@dgr4277

Жыл бұрын

@@programisli очень некрасиво поступаете, вас просят совета, а вы просто "забили болт", проигнорив . Надеюсь вам это все вернется и люди будут к вам также относиться

@Deletedeletedelete

Жыл бұрын

Юмор для юниоров:)

Как хорошо, что попал на Ваш канал. Спасибо большое за творчество! Засмотрелся, подписался! Интересные мылси, хорошо поставленная речь! Очень интересно послушать матерого кодера)))

@programisli

Жыл бұрын

Спасибо

@sadulla123

Жыл бұрын

@@programisli я только начинаю изучать язык программирования, и решил я изучать питон, не знаю на сколько правильный выбор, но полагаю, что для новичка именно этот язык программирования отличный порог вхождения в тему. Так вот вопрос! Что именно необходимо минимально знать и Как правильно реализовать полученные знания для того что бы устроиться в компанию?

Начала изучать программирование с месяц назад, 90% терминов в видео не поняла от слова совсем, но уловила ваш посыл, спасибо)

@Ignat99Ignatov

11 ай бұрын

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

Забавно. Задавали ли я вопрос Why? Не часто, но задавал. Обычно ответом было - потому что так. И все. Я исхожу из одной простой мысли данной мне моим первым и наверно одним из лучших в моей жизни начальником еще в советском НИИ - лучшее враг хорошего. Ничего не надо улучшать, если оно и так работает. Я нажимаю кнопки с 1986 года, хотя и не все это время подряд. В 1992-94 работал дальнобойщиком, потом настраивал пневматические системы. Веселое время было, но в 1997 все же вернулся в программизм и уже в 1999 получил работу в США. Так что что в программизме самое важное, вопрос наверно открытый. На мой взгляд после примерно того же 30 летнего опыта (хотя с алголом я познакомился еще в школе в далеком 1979 году) ответ достаточно прост, хотя и другой - чем меньше ты нажимаешь кнопок, тем лучше для тебя и твоего продукта.

Некоторых в настоящее время при слове "монолит" просто вводит ступор и ты в их глазах становишься самым непонимающим айтишником на самом низу эволюции) Мне нередко приходилось встречать такую реакцию людей на собеседованиях и на местах работы. Более свойственно это молодым людям, которые привыкли гнаться за модой и модными течениями, пытаясь все в мире перевести на эти новые рельсы, это лишь показывает их малый опыт в мире IT. Я встречал сеньоров, которые становились сеньорами в 23, и мидлов которым было под или за 50, при этом они работали в одной конторе, и имели за плечами разницу в опыте измеряющуюся в десятках лет) Первые просто угодили своей конторе, а вторые работали в соответствии с совсем другой философией) Все относительно как говорится. Хорошо что я посмотрел это видео, так как в нем именно это еще раз подтверждается и я теперь не буду себя чувствовать неуверенно при разговорах о монолите и его праву на существование в современном мире.

@rubiks7196

Жыл бұрын

Новые рельсы это хорошо, если они производительные

@user-hp7pc3lv3v

Жыл бұрын

А ещё git не нужен, даёшь папочки с датой)

@RustamHelloWorld

Жыл бұрын

​@@user-hp7pc3lv3v ага шутник, пока вы пытаетесь рефакторить, везде пихая DI, выбирая лучшую структуру проекта, постоянно переделывая ее, делаете избыточные реализации типа закладывая код под масштабируемость в будущем, которая никогда скорее всего на проекте не наступит, тратя кучу времени и делая проект дороже, мы уже давно запиливаем процесс и запускаем его в прод.

@rerurkful

Жыл бұрын

@@user-hp7pc3lv3v не, ну не))

@rerurkful

Жыл бұрын

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

Интересная история ❤

Как я понял. Надо делать удобно и в зависимости от требования:)

Мне 18 и я хочу стать программистом. Люблю посмотреть такие видео , очень мотивируют к продвижению в этой сфере 😁

@Edvard-Aliev

Жыл бұрын

У автора видео много хороших книг по C# у самого есть почти все книги Миши 😊

Красиво!

Чему я научился за 25 лет программирования - красиво делай, красиво будет

Много написал. Считайте это выплеском боли человека, который работает на ужасном монолите и уже не в состоянии это терпеть =) С технической точки зрения и в идеальном мире не могу поспорить. Но в реальности мне кажется есть больше аспектов, чем только то, что монолит может выдерживать те же нагрузки. Я встречал однажды такой монолит, который сам с собой общался через внешнюю очередь и просто разные модули этого одного монолита подхватывали нагрузку, когда могли. Код - по сути монолит, но можно скейлить количеством задеплоенных инстансов почти, как в микросервисах, имея при этом более простую инфраструктуру. Главная проблема вылезает, когда растет команда. В такой команде получается, что каждый может вроде отвечать за какую то свою зону, но доступ имеет ко все кодовой базе. Даже если представить, что в изначальной версии мы имели идеальную архитектуру, что вряд ли, со временем начинается каша. На каждого девелопера сверху давят менеджеры по срокам и начинается срезание углов - где-то надо было использовать готовый код, но что-то не срослось и сделал запрос в общую базу в своем модуле, где-то не понял замысел архитектора и добавил свой код в не совсем верный модуль, следующий разработчик посмотрел на это и решил, что так и надо и пошло поехало. Через N лет получаем что-то невероятное мягко говоря =) Кроме того, чаще всего монолит - это одна общая база и все это ползет в нее тоже. У меня опыт, конечно, не гигантский, но я работал и на нескольких монолитах и на микросервисных проектах. Все монолиты, что я видел, были просто ужасающими. Сейчас уже пол года работаю над довольно крупным монолитом, команда опытная, сеньоры и архитекторы сохранились на проекте еще почти со времен его зарождения, код стандарты, код ревью довольно жесткие и аппрувить могут только несколько избранных. Но это не помогает. Во певых, даже эти избранные вообще ничего не помнят про большую часть проекта. Что в целом не удивительно, когда отвечаешь за все сразу. Проект превратился в полное месиво, где нет никаких разделений ответственности, все что угодно может происходить где угодно. Я так за эти пол года и не понял изначальной идеи архитектора, за слоями костылей этого уже не разглядеть. База данных - вообще кошмар. Под сотню схем, сколько таблиц вообще один господь бог знает. Есть много таблиц дубликатов или чего-то в стиле payments, payments1, payments_depricated и тд. В таблицах сотни полей, большая часть из которых пустые и никто не знает, зачем они нужны и нужны ли вообще. Делать релейшены между таблицами никто и не помышляет уже давно. Данные, которые вроде должны бы храниться где-то рядом, могут быть разбросаны по разным схемам в рандомном порядке. Микросервисная архитектура, что я видел тоже была не идеальной. Но она хотя бы устанавливает более четкие границы между зонами ответственности, которые нарушить очень сложно. Над разными зонами могут работать разные команды, что снижает объем того, что необходимо знать разработчику на своих участках. Сервисы сильно проще для понимания. По мне, если не иметь какую-то идеальную команду, где все дисциплинированы, одинаково хорошо разбираются в технологии и при этом еще и не меняются, то монолит будет эффективнее в разработке. У тебя все под рукой, ни с кем договариваться не надо. Берешь и делаешь. Но все упирается в команду, как по мне. Люди не идеальные, они меняются, знания теряются, а область ответственности растет. И вместе с этим растет сложность добавления новых фич. Микросервисы в начале сложнее. Дополнительные сложности с инфраструктурой, общением между командами и.т.д. Но эта сложность со временем растет предсказуемо и не так сильно. В то время, как сложность работы с монолитом в начале меньше, но со временем ускоряется все больше, пока компания не помрет в один момент. Мне кажется идеальный вариант начинать с монолита, который изначально планируется, под разбиение на сервисы в момент, когда сложности этих двух подходов пересекутся. И последний аспект, уже более относящийся к самому девелоперу. Возьмем девелопера, который проработал на монолите в котором из стека всего и есть, что C# и SqlServer. Кому он будет нужен на рынке, если его вдруг уволят или компания умрет? Это же просто конец карьеры, если только не найти точно такую же компанию.

@albrehtdurer557

Жыл бұрын

хорошо написал, видел подобное...

@paxbritanica5217

Жыл бұрын

В своей практике поступаем так, MVP-версию (прототип) делаем как монолит, чтобы примерно сделать демо основных замыслов. Если поддерживается дальнейшая разработка, тогда проектируется более детальная архитектура с разбивкой на сервисы и выбором стэка. Чтобы избавиться от старого кода, ненужных таблиц обычно делается новая ветка проекта, в которую переходят только актуальные модули и таблицы данных.

@DokDa95

Жыл бұрын

Послать все наХ в таком случае 😂 И переформулироваться в другую специальность 😂

Михаил, большое спасибо за видео и личный опыт! Хотелось бы также услышать Ваше мнение насчет ChatGPT и страшилок, что скоро developers, technical support engineers, QA engineers могут быть заменены искусственным интеллектом. Спасибо

@programisli

Жыл бұрын

Думаю над этим

Согласен с автором. Мне лично тоже запомнился случай, когда мой начальник снаряжал сервачок в какой-то технологический цех еще на 2000 винде и тамошний начальник айти завел речь, что надо бы автоматические обновления, антивирусы подрубить, на что начальник так же ответил: нафига? Сервак стоит, собирает свои данные с датчиков, в него никто не лезет, и так и будет работать годами. Поставь автообновления и начнется: то то не так, то это не так, здесь перезагрузитесь, здесь переустановите. А потом довелось немного коснуться японского айти, там вообще могут работать на доисторическом или самопальном софте и не париться как у нас: ах ох, надо срочно обновляться!

Очень крутое видео! Можете рассказать любопытному фронтендеру возможна ли такая нагрузка при которой понадобятся микросервисы или это нужно только для организационных вопросов в больших командах?

@programisli

Жыл бұрын

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

То, с чего следует начинать всем - монолит, его хватит условным 80% по принципу Парето, а на время выхода на IPO хватит всем. Золотая середина - это SOA, но не микросервисы. Микросервисы - это удел единиц, но это модно, поэтому они везде.

Не часто на старых технологиях проекты хороши и востребованы, если хочется расти по карьере, то только актуальный стек, в целом можно и не бежать за стеком, но тогда надо быть уверенным, что не останешься без работы завтра (в РФ на легаси можно не найти то что хочешь)

@programisli

Жыл бұрын

Актуальный стек конечно важно. И обновлять стек с целью быть на коне - это хорошая причина "почему" это стоит сделать

Сделайте, пожалуйста, выпуск "Куда уходят умирать программисты за 50". Есть куча роликов, как стать джуниор программистом, а вот ничего про то, как/куда продолжить быть программистом. Опыт в программировании 20+, бэк на java, застоявшийся мидл, никак не сдвинуться дальше. На своём месте работаю качественно. Работал в монолитах, умею в микросервисы. Освоить новое - не проблема. Но, наверное, гореть только работой уже не готов, когда днем и ночью только код, курсы, постоянные флешмобы "лучшей версии себя". Всё-таки семья, хобби, ложиться костьми не хочется. Возраст - сорокет с хвостом. Оглядываюсь по сторонам - практически не вижу своих ровесников рядом. Куда они уходят умирать, с какой скалы сбрасываются? Знаю, некоторые перешли в аналитиков. Кто-то - в админов/девопсов. Кто-то в бухгалтерию(раньше был тренд). Кто-то в архитекторов или в административную работу, управление. В чём причина этого, боятся, что год-3-5 и мозг сдаст, не смогут конкурировать с молодняком на равных? Как вы видите возможный путь? Есть ли вариант переквалифицироваться в датасайнс или еще во что-то смежное интересное перспективное(понятно, что это нифига не просто, тут скорее речь о возможном рывке в 2-3 года). Понятно, что в Канаде/США и России этот путь - он разный, но всё же. Спасибо.

@programisli

Жыл бұрын

Если нравится дата сайнс, то можно переквалифицироваться. В Канаде много программистов в возрасте, которые продолжают писать код. Я сам не знаю, куда деваться после 50

@Alonso_Kinn

Жыл бұрын

​@@programisli, а никуда и не надо ! Надо быть профессионалом в своем деле . Глупо расти 30 лет и потом куда то уходить. Вы же профи ! А профи всегда нужны везде . Главное физ.форму держать .

Относительно cloud vs 'on premises'. Есть такой зверь: Azure on premises Он спасет мир :-)

ещё один хороший навык: умение спрашивать: а почему нет? особенно когда в команду приходит новенький и модный мальчик и спрашивает: а почему вы это делаете на монолите, а не на микросервисах? или а почему вы используете TFS, а не модный сейчас git. В ответ спросить его: а объясни почему по-твоему мы должны переходить на эту технологию? Пусть объяснит. А самому внимательно послушать. Кстати, вопросы почему? и зачем?: они принципиально отличаются друг от друга. И в английском тоже их часто путают: Why - meaning: what caused this? And: what for - meaning: what will be the outcome or the result if you do this?

А мы с коллегами второй месяц уже Apache nifi в кубер пытается запихнуть, а что поделать, а что поделать, никакого монолита))

У монолитной и майкросёрвис архитектуры есть у обоих свои преимущества и недостатки, как вы и сказали. Майкросёрвисы можно можно более точечно скэйлить. Монолит же можно скэйлить только полностью. Всё решает use case а не хайп

@user-hz1yc6cw6k

11 ай бұрын

Нет. Монолит это больше маркетинговое название, придуманное для того, чтобы продать тебе микросервисы в облаке. А правильно говорить N-tier архитектура. В ней могут быть и сервера баз данных, и сервера для бизнес логики, и сервера для веба. Можно выделять отдельные небольшие приложения для специфических задач на отдельные сервера, и, в общем делать все что угодно, и все это прекрасно скейлить. До того, как облачные провайдеры начали впаривать микросервисы, проблем с масштабированием по частям никогда и не было. Например, у Microsoft в Azure до сих пор доступна инфраструктура Azure Cloud Services из домикросервисной эры, в которой сервера объединяются в так называемые роли и эти роли могут автоматически скейлиться. Там ты просто настраивал выкладку билда на стейдж и все, не нужно было никаких девопсов, YAML, ничего - ты просто писал код и не парился о том, сколько серверов нужно для какой части проекта. Поэтому не сказал бы, что в классической архитектуре прям уж нельзя масштабировать отдельные части, там для этого очень много возможностей, которые зачастую были даже удобнее докера и микросервисов. Другое дело, что чем меньше у тебя частей, тем меньше накладных расходов на их взаимодействие, поэтому в простых проектах для лучшей производительности обычно все кроме базы данных держали в одном приложении и скейлили все разом по серверам, а не по уровням.

Привет, что думаешь о гос службе в IT? Я имею в виду фсб или кгб какое-нибудь. Как считаешь стоит ли начитать свою карьеру там? Будет ли это хорошим опытом? Да и вообще общее мнение интересно насчет этого.

@programisli

Жыл бұрын

Я там не работал. В ФСБ наверно не стал бы, думаю там есть потом ограничения на выезд из страны, а я люблю путешествовать. Если ограничений нет, то ... сложно сказать, не задумывался об этом

Спасибо за видео! Интересно, у монолитного Stackoverflow компиляция тоже занимает весь день?🤔

@programisli

Жыл бұрын

Не думаю. У меня Sony электронный магазин на горячую занимал не более минуты. Даже полная компиляция с нуля не более 5

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

@programisli

Жыл бұрын

Целое видео пока не готов записать, я еще думаю над этим. Если коротко, то пока не заменят.

@baofusan2669

Жыл бұрын

@@programisli в целом согласен и ответ знаю, но просто жду ваш ролик маэстро, как будет время и желание естественно

@user-du2mf4zj1p

Жыл бұрын

да уделали но вопрос кому это нужно и ответ авторитарной системе которая стремится подчинить себе все и вся но это объять не объятное парадокс? да! но на этом и стоит движение вперед

Спасибо за интересную информацию. Но насчет микросервисов: оптимизация работы конечного продукта может быть не всегда является окончательной целью. Если проект ОЧЕНЬ динамично развивается и на нем сидит с пол тысячи сотрудников, то прогонять, к примеру, через CI\CD работу каждого сотрудника может значительно замедлить общий процесс, тк dev окружение не всегда такое "щедрое", как prod)) А замедление процесса на таких объемах может конвертироваться в солидные финансовые потери. Возможно для Netflix с их штатом в 15000 этот переход решил какие-то проблемы в бизнес процессах. У стека, я смотрю, около 200 сотрудников. Что скажете если посмотреть на эти програмысли с такой точки зрения?)

@programisli

Жыл бұрын

200 сотрудников не значит, что 200 программистов. Там много тостеров, админов, инженеров, программисты могут работать над разными вещами. Поэтому монолит для них работает. Я не знаю, сколько из сотрудников Netflix программисты. Но если даже 1000, то тут ясно, почему они выбрали микросервисы. Да и проект у них шире, так что я уверен, что у них микросервисы оправданы

@fanfromzp

Жыл бұрын

@@programisli цифры по сотрудникам приведены только для объемного сравнения. Понятно, что доля программистов будет совершенно другая, но в процентном соотношении этих двух компаний все равно можно увидеть разницу в штате. Но основная мысль моего комментария "тире" вопроса именно в том, что не всегда решающим аргументом может быть 100% техническая составляющая. Иногда это может быть завязано на оптимизации внутренних бизнес процессов, которые напрямую влияют на финансы бизнеса. Так ли это?

Жизненно, особенно когда твой сервис и так является Микросервисом в большой системе, а вас заставляют распиливать ещё на 100 разных сервисов его) это не всегда нужно Это как с базами, иногда нужна и денормализация

@Deletedeletedelete

Жыл бұрын

Когда интересно нужна денормализация?)

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

@programisli

Жыл бұрын

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

@aleksandrdemidov6058

Жыл бұрын

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

@dmitryo6153

11 ай бұрын

И правильно делали. Микросервисы - инструмент для решения проблемы организации работы программистов. Это зона ответственности менеджмента

Здраствуете Михаил можно вопрос стоит ли изучат Xamarin для мобильной разработка

@programisli

Жыл бұрын

Можно, но он не сильно популярен. Я бы лучше Flutter изучал

@Alonso_Kinn

Жыл бұрын

​@@programisli, а почему не Kotlin?! И могли бы вообще видео снять про ваше мнение про Kotlin?! Спасибо

Крутой дядька) Сам фронтом интересуюсь. Но когда смотрю про бэк ребят, то понимаю какие они лютые) И, наверное, понимаю, почему ребята из бэка не считают фронтменов за прогеров)

@programisli

Жыл бұрын

А я не знаю, почему фронтов не считают за программистов. React и Angular достаточно серьезные фреймворки

@ShoxaKardashian

Жыл бұрын

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

@Hello_there_777

Жыл бұрын

@@ShoxaKardashian 🤣🤣🤣🤣

@aleksandrdemidov6058

Жыл бұрын

@@programisli а extjs как? есть спрос?

@VasjaG

Жыл бұрын

Я ангулярщик. Было два проекта, в которых главным был джавист. Джавист выбрал Ануляр для фронта. Но только потому, что Ангуляр внешне похож на джаву. Он говорит, как надо делать (исходя из своих джавистых скиллов), но получается не очень. Но виноват - я. Вот так. Будьте бдительны! Фроненд - это не только div+div+div+display:flex;

Добрый день! А где можно посмотреть что за сайт на бусти?

@user-yn6tq3df5n

Жыл бұрын

всё нашла)

Учу с#, и докер кажется пока сложно. Но все таки придётся учить его

@programisli

Жыл бұрын

Скорей всего, он полезен и с монолитами и микросервисами

@user-ix4cm7ch5z

Жыл бұрын

@@programisli это как с гитхабом, вначале думал все сложно да и зачем он мне сейчас 😁

@Hello_there_777

Жыл бұрын

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

Привет. Посмотрел произношение build на американском англ. и на британском - оно одинаковое. Я думаю, что это дикция конкретного человека была - 'булд'

@programisli

Жыл бұрын

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

Очень неудобно поправлять, но не flash mode, а flash mob (толпа).

@programisli

Жыл бұрын

Без проблем, я нормально отношусь к таким вещам. Во время записи просто забыл вообще как называются такие. Даже флеш мобом это не назовешь, кажется есть другой термин

попробуйте открыть для себя "serverless" патерн, вместо монолитов и микросервисов.

@programisli

11 ай бұрын

Это не универсальная таблетка

@michaelinuente92

11 ай бұрын

@@programisli SOA architectures преполагает "стабильную топалогию", т.е. лукавицу по любому нужно делать. ну что-бы два раза не вставать, зачем париться только с "фанкшен (или домэйн) лайером", если можно и "процесс лайер" переложить на функции?

OOOOOooooooooooooo двигаца вперёд быстрее ПОчему Зачем

Второй после если вести счёт

Профи фигни не посоветует: думай что и зачем делаешь и не забывай про бабки))

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

@alexanatem7218

Жыл бұрын

До слез знакомая история

Привет. Услышал много раз слово монолит. Это о чём?

@programisli

Жыл бұрын

Ты не знаешь, что такое монолит?

@pu0081

Жыл бұрын

@@programisli ааа, все про это знают, а я нет, как же так! Погуглил специально, чтобы понять терминологию. На самом деле именно монолиты я и собираю на Delphi. Как пример, использую встроенное средство для работы с базами. И 100% кода собирается при компиляции. На данном этапе я собираю порой в рамках 1 приложения сразу несколько EXE-шников, для чего написал отдельное приложение-инструментарий, ибо батники и скрипты на msbuild оказались костылями, управлять которыми неудобно

@pu0081

Жыл бұрын

Добавлю, навык формулировать и задавать правильные вопросы полезен не только в dev

@programisli

Жыл бұрын

Я просто не понял твоего изначального коммента, что ты именно ввиду. Если ты делаешь десктопные приложения в Delphi то это не монолит и не микросервисы, это просто десктопные. Ты можешь вызывать различные сервисы как WebAPI.

@pu0081

Жыл бұрын

@@programisli Речь идёт о терминологии. Чтобы к ней выработать отношение, хорошо бы всем прояснить, о чём речь. Я сталкиваюсь иногда с тем, что термины, применяемые блогерами, с ходу не были известны, а по мере вникания оказывается, что таким ты уже лет 100 как пользуешься и есть свой опыт, которым можно делиться. Чтобы использовать микросервисы в чистом виде, это должна быть обособленная задача, к использованию которой могут быть причасны несколько разных или несколько экземпляров приложений. Другая сторона медали. Как только решаемая задача усложняется, скорее всего выделение её в отдельный микросервис также усложняется. Поэтому и заинтересовал эфир, ведь чужой опыт он иногда дополняет собственный. И так как я с микросервисами знаком минимально, но выделяются среди множества задач экосистемы те, что по логике могут быть обособлены в отдельное решение, мне тема интересна. Я подошёл к решению, когда часть функционала приложения я выделяю в отдельное небольшое приложение, и оно разбирает команды, полученные по TCP/IP и в командной строке. Я называю такие микро-приложения ассистентами. Причина их появления в том, что когда требуется выполнить несколько действий, связанных с основной темой приложения, нет необходимости запускать его полностью, с интерфейсом, достаточно запустить в режиме - инициализируй состояние готовности, предварительная подготовка данных, подключения разные, отработай несколько команд и закрыв всё, прописав в логи, заверши работу. И на время выполнения этого движения некий набор межпрограммных взаимодействий будет недоступен, своего рода "критическая сессия". Но это, как я понимаю не совсем микросервисы. Вопрос в буквальном определении терминов. Скорее всего, дальше я буду двигаться в сторону, процесс приложения висит, всё инициализировано и готово, получил-отработал команды, и дальше себе "вишу" ) Если это называть микро-сервисом, то да, использование таких решений у меня назрело, так как подготовка к выполнению порой сравнима по времени с выполнением, и когда через батник или послав пакет команд я запускаю кучу раз на выполнение это микро-приложение, происходит многократная инициализация и это бессмысленно и по факту просто как потеря времени. Но я вышел из этого, было несколько случаев, когда я передавал именно большой пакет команд, то есть не несколько вызовов а сценарий, 5 команд, если условие, то следующие, иначе другой набор, и сценарии решают задачу того, чтобы 100 раз не проделывать инициализацию. Если сценарии возможны, сейчас я использую сценарии. Но в чистом виде, как микросервис, я планирую таковой, ибо есть задача, растянутая во времени в том смысле, что некоторые действия над информационным объектом нельзя спланировать как сценарий, это как хаотически возникшие потребности. Я о задаче техподдержки, когда доступ к состоянию некоторой задачи требуется по принципу - ну как я проверю, как там сейчас дела, а есть ли ошибки, а как проц и память нагружены, а если в задаче давно открытые базы и сложные индексы не используются, что если я позакрываю. И хорошо бы тиражирование и перенос на новый клон работающего приложения проделывать автоматом. Думаю над этим, и послушал лекцию про докер, как бы, двигаюсь в ту сторону. Вот такой мой опыт. Послушать опыт человека, книгу которого я читал, для меня честь. Если надумаешь делать видео про практику использования докера, без воды, а конкретно, задача, вот сценарий, вот так это получается, то прими мой голос в поддержку. Спасибо за интересные видео

А с кофе прикольно получилось то!) Буква "Р" такая картавая, акцент американский будто))

ссылку на интервью так и не разместили)

20 мин про то, что научился задавать вопрос why.

@programisli

Жыл бұрын

Ну я в начале предупреждал, что будет долго, с историями, почему я люблю спрашивать почему

Почему я не увидел это видео два года назад когда начал изучать бэк)

Стоит ли 45 летним программистам переезжать в Канаду?

@programisli

Жыл бұрын

Я думаю, что будет сложно, но можно.

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

Первый!!!

У меня пермоментое состояние того, что ты только подумал что, чему то научился. А потом понимаешь что ничего не знаешь

@programisli

Жыл бұрын

Бывает такое.

За 30 лет работы программистом научился быть ДевОпсом)

@programisli

Жыл бұрын

И им тоже, говорил про это здесь DevOps глазами программиста - как я познакомился с DevOps kzread.info/dash/bejne/kYJlzLCuZ8eqorA.html

@yarbersheer8559

Жыл бұрын

@@programisli да я к тому, что зашёл про опыт программиста посмотреть) но.. не дождался) А девеопс для бекендера понятное дело уже мастхев выходит..

Что такое трафик?

@programisli

11 ай бұрын

Смотря в каком контексте, в отношении машин на дороге - пробка. Я не помню в каком контексте в использовал в видео

Помогите пожалуйста мужу устроиться на работу, он программист C#, проработал 15 лет в компании, уволили, ищет работу, но пока отказы, у нас ребёнок инвалид, работать я не могу, муж один кормилец в семье, а у нас ещё кредиты, помогите пожалуйста, может быть кто нибудь сможет помочь, ему удаленка нужна 🙏

Я в шоке что вы уже 30 лет работаете) Вы выглядите на 35, надеюсь не с 5 лет работаете))

@programisli

Жыл бұрын

Мне 47

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

Миша, детей твоих давно не видно... Покажи хоть как-нибудь!

@programisli

Жыл бұрын

На неИТшном канале они появляются часто m.kzread.info/dron/3VuryIjs0xXFu2vlbdbP0Q.html

Это оно? kzread.info/dash/bejne/oI6Mk5WdhtvUeto.html

@programisli

Жыл бұрын

С этой же девушкой но другое. Там формат интервью был и похоже его не сохранили.

@alexandrl2677

Жыл бұрын

@@programisli просто картинки из видео, там тоже были)

@programisli

Жыл бұрын

Картинки взял уже из этого видео, потому что не нашел то, которое смотрел в декабре

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

@programisli

Жыл бұрын

Почему монолиты дорого масштабировать?

@kl45gp

Жыл бұрын

@@programisli потому что часто нужно отскейлить отдельный кусочек, бывает даже сотнями инстансов, если делать 100 копий монолиотов то это по ресурсам серверов накладно(Дорого). Еще надо помнить что ошибка в монолите приводит к краху всего приложения, в то время как в микросервисах упадет лишь один сервис (и то его один инстанс)

@user-hz1yc6cw6k

11 ай бұрын

@@kl45gp Почитайте на досуге как устроен веб сервер, может перестанете говорить глупости.

@dmitryo6153

11 ай бұрын

⁠@@kl45gpможно отрубать все ненужные кеши и роутить на определенные машины определенные урлы. По ресурсам будет как микросервисы, а чаще даже лучше

Как понять, что ты стал програмистом?

@programisli

Жыл бұрын

А оно нужно заморачиваться такими вопросами? Научился писать какой-то код уже программист, дальше уже вопрос уровня

@zakharbondarev7814

Жыл бұрын

@@programisli спасибо

Казалось бы название "Чему я научился за 30 лет работы программистом" а по итогу пересказ истории , а чему научился - нет ...

@programisli

11 ай бұрын

Есть

Микросервисы решают проблему менеджмента. Поэтому толковые книжки об этом сразу начинаются с Conway’s law. Если монолит не соответствует орг-структуре, то начинаются проблемы с временем доставки фичей до пользователя. Да, есть технические преимущества, но они менее значительны. При желании можно хорошую архитектуру сделать с монолитом и десятком сервисов вокруг. Но если у вас 40 команд работают изолированно с разной скоростью, вас это не спасёт. А вот если 20 программистов в пяти командах, то нафиг это не надо. У них просто на тулинг времени не будет и они вечно будут заняты проблемами интеграции своих сервисов.

А зачем 30 лет работать программистом?

@programisli

Жыл бұрын

Мне нравится код писать. Я сейчас менеджер, но продолжаю для себя писать что-то

Программировать? Лол

Послушал 9 минут. Ничего не понял.

@programisli

Жыл бұрын

Жаль

@user-od9qk8fp7b

Жыл бұрын

@@programisli но я разберусь. Видимо время займёт. Я только начал учиться на разработчика.

Удивительный канал, программист с опытом вместо того чтоб работать собирает донаты со зрителей. Успешный успех? Докер это отстой, они используют виртуал бокс а в них имиджи из говна и палок слеплены. Лучше Фотон ОС и ВМваре.

@programisli

11 ай бұрын

У меня есть работа. Это же донаты, не хочешь, не участвую, всё добровольно

А почему Миша записывает это видео?

@programisli

Жыл бұрын

Чтобы вы задавали самый важный вопрос - почему! :)

Надоели микросервисы. Из-за этого хайпа столько ресурсов уходит.