простите, я тоже люблю Qt, сигнал-слотовый механизм - это реально круто, но правильно ли я понимаю, что книга по qt, выпускаемая в России, в 2026 году, должна буквально начинаться со сценария "как скачать QT SDK и не заработать 'административку'" ? ))
в этой книге такой рецепт есть? ) такой, чтобы и сам работал, и РКН не считал что у вас стоит "средство обхода ограничений"? )
причем сарказм-сарказмом, но проблема-то реальная: как заставить работать их инсталлятор, или на худой конец, собрать qt-sdk из исходников?
исходников, которые тоже надо ещё знать где скачать. причем, желательно, "под виндоус". ага.
понятное дело что в некоторых продуктах как банковские приложения и похожее такое неприемлемо, но для проектов среднего уровня и чуть выше вполне нормально, если там не требуется убер безопасность😌
проблема в том, что у вкатунов и вайбкодеров нет понимания границ.
нет понимания того, когда эта самая безопасность начинает быть важной.
а лёгкость освоения хелло-ворлд задач и эффект Даннинга-Крюгера порождают архаровцев, которые с такой же лёгкостью берутся за "неподходящие задачи", "калечат" всё что угодно (даже не понимая, что за дичь они творят) и толпой затопчут на любом "конкурсе".
(дада. "заказчик сам виноват", "потом всё ясно будет"... но растраченный бюджет не вернуть, а обезьянок успешно мимикрировавших под разработчиков даже не оштрафовать, а ты сидишь, без денег, и смотришь как эти идиоты и неофиты тупо всё разваливают.)
а теперь вопрос . кто из этих выпускников этих разных курсов - имеет знания для того, чтобы пройти хотя бы (!) экзамен OCA ?
с одной стороны бесплатно же да...
а с другой - возьми книжку по подготовке к сертификации OCA от Mala Gupta и пойми как джава работает, а не вызубрись на прохождение опросника по популярным java-технологиям.
ps: мы стажёров на собеседовании гоняем по опроснику слизанному с вопросов OCA. а спринг он или в процессе выучит, или вместо спринга выучит какой другой фреймворк, потому что спринг это всего лишь один из множества фреймворков. не спрингом единым живы проекты.
____
а вопрос "учить питон или джава" и данный в статье ответ - говорит об абсолютном непонимании автором ниш этих технологий. причем "ниша" не в плане банковский сектор или датасайнтист, а объем кода, сложность проекта, длительность его жизненного цикла - особенностей проистекающих в первую очередь из системы типизации в этих языках.
позволю немного критики. или критиканства, уж простите.
(1) я не увидел новой парадигмы. именно новой. сам я джавист, и простите, я видел тот же jsf с "сервер сайд рендерингом" и невнятной вёрсткой формы на xml. ужасы типа vaadin со всеми вытекающими. даже я сам приложил руку к увеличению безобразий.
вы правильно отмечаете, что фейсбучная разработка по модели рест+тяжелый js настойчиво подталкивают к "утеканию бизнес логики на клиента". я бы ещё добавил "по факту раздуваемые" трудозатраты, но это уже "надо доказывать". но не суть. вопрос в том, а в чем парадигма?
(2) как в вашем фреймворка сделать кастомную верстку?
(2.2) как интегрировать в ваш фоеймворк работу со сторонними js-клмпонентами? например, я хочу интегрировать в систему яндекс-карты?
(3) простите, но пыха для бизнес приложений - ... выглядит сомнительно. конечно, если вы останетесь в модели рест-запросов и стейтлесс-(микро?)сервисов, без фоновых процессов и многопоточного серверного кода, кеширования в памяти... то конечно, "почему бы да"... но потолок для таких систем весьма не высок ( не, может в пыхе что то и придумали, простите, я ушёл на джаву примерно когда "не состоялся пхп 6 с многопоточностью"). в общем я к чему - разработка бизнес-прилодений с тяжёлой бизнеслогикой и сложными сценариями на языке без многопоточности... сомнительно это выглядит). не говоря о необходимости стандартизации языка, обеспечения гарантий обратной совместимости (как же писать бизнес приложение, если у него срок жизни равен сроку поддержки текущего компилятора?) и статической типизации ( в больших проектах это оооочень сильно помогает избежать кучи ошибок), но это уже совершенно другой разговор.
используя а качестве словаря вероятностные связи в обученной нейронке?)) и при этом это ещё и сжатие с потерями... это что?! jpeg для текстов? wow!!!! XD
маленький шаг для жертв егэ бакалавриата, большая ржака для человечества )))
ps: жаль, что первоапрельская шутка не выглядит как шутка . ага. XD))
в случае чата - достаточно self-hosted приложения.
вот что-то, что можно поставить себе в докладе и продолжать работать с коллегами и подрядчиками . штука, за которую автору не надо "платить за сервеоа".
ну и где? )) что по итогу - маттерный-мост ставить?)) или что у нас там есть ещё?
С одной стороны, все вайбкодер-адепты на каждом шагу кричат, как всё прекрасно, легко и быстро.
С другой стороны, там уже **много*времени*" блокируют сервисы звонков и чатов.
Объясните мне : где сотни навайбкоженных конкурентов Скайпа, Дискорда, Телеграмма ? Не просто чатов типа того же ВКМессенджеоа, Виичата, или какого-нибудь ужаса типа яндекс-мессенджера-приложения-к-телемосту... а функциональных, равных по возможностям тому же телеграмму?
и заметьте я не про "безопасность" говорю, я про функциональность. Группы с комментариями, ответ-цитирование части текста, лайки к сообщениям, голосовые, кружочки, голосования, трансляция геопозиция... где это всё?).. Где тонны приложений вида - "не хочешь переходить на Макс ? - вот смотри, я найбкодил -смотри как прекрасно работает и удобно".
Всё что я увидел - это обзоры уже давно сделанных чатов.
Причем кто-то там уже сам начал писать свой чат. И вроде уже дописал до функционирующего прототипа. Без ИИ.
Почему ни один вайбкодер так и не осилил сделать быстро, красиво и функционально то, что делали гнустные кожаные мешки без прекрасной ии-шечки?...
Неужели адепты вайбкодинга что-то не договаривают ?!
начиная с мидла, особенно "среднего" звена(*1) - технические специалисты "растут" и повышают грейды не за счёт изучения новых технических навыков, а в первую очередь - за счёт опыта и софт-скилов. старший миддл без навыков работы с другими (не только опыт работы в команде, но и джуно-ботоводство), без опыта и кругозора определяющих качество его решений и умения отлаживать и разбираться в чужом коде и новой sdk, без знаний в архитектуре - ни разу не миддл. ни о каком продвижении в лиды в отношении такого недоспеца - речи быть не может.
изучение новой технологии, нового стека технологий - для мидла - не достижение, а рутинная обязанность. он не растет изучив спринг-бут, jpa, апи кафки, (прислать любое название из статьи выше)... это его рядовая обязанность. смена специализации и изучение технологий - важный скилл для дальнейшего роста мидла. а умение учиться - как вы понимаете - совсем не технический навык. это помимо софт скиллов.
сама модель статьи, идея о том, что "изучив технические скиллы - ты станешь лидом"... не просто порочна - это смешно. зазавалово для неофитов. с таким подходом только до начальных мидлов и получится добраться.
а насчёт грейдов и технических навыков - у нас например джун не перейдет в мидлы не обладая твёрдыми знаниями на уровне Java OCA. а специализируется он на спрингбуте, или jee- ветке и хочет выучиться на Java OCP - это не суть. потому - половина всего написанного в статье про мидлов и лидов - имхо чушь. как список технологий - перечень хороший. а попытка увязать это с грейдами - это, мягко говоря, смешно. рассуждения гуманитария о марсоходах.
________
Скрытый текст
*1) мы делим каждый грейд на 3 подгрейда/"звена": условно начальный, средний и старший. итого получается примерно 10 ступеней : стажёр, 3 ступени джуна, 3 ступени мидла, 3 ступени лида, и тимлид/гип, но верхняя ступень достаточно условна потому что это скорее сдвиг в бок.
на каждый ваш пункт есть конструктивный ответ и понятное решение.
Отлично! ну значит и покажите, пожалуйста, эти решения.
Потому, что когда дело доходит до практики этих "понятных решений" - оказывается что всё совсем не так уж "понятно" и совсем не так "конструктивно".
Начиная от сложности выбора модели которую ты можешь "скачать и запустить", и кончая весьма скудными возможностями, которые могут предоставить локально развернутые модели, способные хотя бы запуститься на оборудовании "доступном простым смертным".
Мы ходили, потратили денег на железо, и (пока) не нашли пригодного рабочего варианта. Может быть "пока не нашли". А может быть и так, что "у нас лапки".
Но вы же.. у вас же получилось, вы же говорите что конструктивные решения есть, и они понятны. Значит, вы знаете как это сделать. Расскажите пожалуйста ?
Не надо нас отсылать "на деревню дедушке" (тем более, на ресурс не доступной в России "официально"). Тем более, если это всё, с ваших слов, так "понятно, просто и конструктивно" ?)))
Статью про то как круто использовать ИИ хостящийся в облаке - вы смогли написать. А статью, про то как круто локально развернуть и использовать в тех-же сценариях sels-hosted ИИ - вы не сможете?
Ждем от вас статью.
Заранее спасибо. Надеюсь, вы развеете наше впечатление от пока негативного / бесполезного опыта использования локально развернутых ИИ/нейросеток.
Вот всё то прекрасное, что вы описали в статье - на локальных мощностях офисных серверов.
Справитесь?))) с конкретными ттх серверов, пожалуйста, их стоимостью и счетами за электричество в месяц.
Потому что когда все ваши модели закроет ркн... когда у вас упадет тырнет... когда случится крах доткомов... когда к вам придет безопасник и скажет, что "очень негоже постить в иностранные ИИ системы схему бд в которой будет храниться персоналка граждан РФ"... негоже вплоть до уголовки. ага?)
... когда, ИИ-провайдеры поймут признают, что у них нет внятной модели монетизации, а ваши 200+ буказоидов за доступ к "американскому гпт" ни разу не позволят им выйти в ноль, и они взвинтят цены раз в 10, вставят вам "непроматываемую рекламу" (кстати, чатгпт такое уже начал делать), начнут постить вам в комменты бд рекламные баннеры в ascii-арте....
... когда ИИ-провайдеры поймут признают,что множества новых датацентра не будет ближайшие лет 10-20, потому что электричества больше взять неоткуда, а ближайшая "электрическая мощь" появится как раз "за срок строительства новой аэс" (те самые 10-20 лет)...
... и никакого качественного улучшения работы моделей не будет, не только по причине абзаца выше, но и потому что они уже выпылесосили весь код какой можно, и просили корпорации дать им закрытые сходники, ибо обучать модели "больше не на чем".. (и им конечно же всё дали, а потом ещё раз догнали....)...
что вы будете делать ?
с вашими прекрасными процессами и джуном-недо-менеджером страдающим даннингом-крюгером?...
что с этим всем делать, см выше, если ии-шка на которую у тебя "всё завязано" - развернута не у тебя в офисе?
вы получили минуту славы, а потом катись оно всё медным тазом?))
хотите раскрою секрет? просто все адепты микросервисов слепо считают антипаттерн "связи многие ко многим" автоматически приравненным к монолиту.
впрочем это не мешает им следующим шагом рассуждать о том, "как плохо делать распределенный/микросервисный монолит", в котором микросервисы организованы так, что сбой/изменение одного модуля, приводит к сбою / необходимости обновления всей системы.
вот не складывается у них, не складывается, что не в микросервисах дело, не в способе сборки и упаковки компонент системы...
тупят, как Алиса Яндексовская в той истории про "самую длинную реку в мире".
даже в 1с поддерживается альтернативное английское написание ключевых слов.
если это учебный язык для школьников - то им нужен не js с его альтернативно-одаренной псевдо параллельностью, которую и взрослым то не объяснить нормально. и кучей других приколов на тему " '1'+1 ' и " '1'-1 "
если переводить, то переводить Паскаль или Бейсик. а так - это мертворожденная идея, которая не прижилась ни разу на протяжении более чем 40 лет. начиная с советских лого-подобных черепашек.
человеку, который не знает английского - в it делать нечего. абсолютно и совсем. и даже в 1С - без английского и внешних языков ты будешь узконаправленный ограниченным кодером.
это, конечно, если эта статья не стёб и провокация.
не существует монолита и микросервисов. как "архитектур".
есть компонентно-ориентированная архитектура и антипаттерн "связи все ко всем" .
непонимание компонентно-ориентированной архитектуры порождает "микросервисный монолит", в котором вроде всё разнесено на сотни хостов, всё по книгам, но что-то поменять сыкотно, потому, что не знаешь где какая проблема вылезет. потому что связи между элементами системы запутаны и трудно прослеживаемы.
а понимание компонентно-ориентированной архитектуры позволяет оставаясь даже в концепции "монолитной сборки и дистрибуции" достигать всех "преимуществ приписываемых якобы-только микросервисам" - распределенные независимые команды, отказоустойчивость, незаметное развертывание новых фич и пр.
простите, я тоже люблю Qt, сигнал-слотовый механизм - это реально круто, но правильно ли я понимаю, что книга по qt, выпускаемая в России, в 2026 году, должна буквально начинаться со сценария "как скачать QT SDK и не заработать 'административку'" ? ))
в этой книге такой рецепт есть? ) такой, чтобы и сам работал, и РКН не считал что у вас стоит "средство обхода ограничений"? )
причем сарказм-сарказмом, но проблема-то реальная: как заставить работать их инсталлятор, или на худой конец, собрать qt-sdk из исходников?
исходников, которые тоже надо ещё знать где скачать. причем, желательно, "под виндоус". ага.
а наследники троллей уже позволяют скачивать sdk с сайта без впн?))
проблема в том, что у вкатунов и вайбкодеров нет понимания границ.
нет понимания того, когда эта самая безопасность начинает быть важной.
а лёгкость освоения хелло-ворлд задач и эффект Даннинга-Крюгера порождают архаровцев, которые с такой же лёгкостью берутся за "неподходящие задачи", "калечат" всё что угодно (даже не понимая, что за дичь они творят) и толпой затопчут на любом "конкурсе".
(дада. "заказчик сам виноват", "потом всё ясно будет"... но растраченный бюджет не вернуть, а обезьянок успешно мимикрировавших под разработчиков даже не оштрафовать, а ты сидишь, без денег, и смотришь как эти идиоты и неофиты тупо всё разваливают.)
и я даже не знаю, что хуже - разгребать гумус за вкатунами, или кодревьювить за вайбкодерами....
("комментарий отозван") :)
а теперь вопрос . кто из этих выпускников этих разных курсов - имеет знания для того, чтобы пройти хотя бы (!) экзамен OCA ?
с одной стороны бесплатно же да...
а с другой - возьми книжку по подготовке к сертификации OCA от Mala Gupta и пойми как джава работает, а не вызубрись на прохождение опросника по популярным java-технологиям.
ps: мы стажёров на собеседовании гоняем по опроснику слизанному с вопросов OCA. а спринг он или в процессе выучит, или вместо спринга выучит какой другой фреймворк, потому что спринг это всего лишь один из множества фреймворков. не спрингом единым живы проекты.
____
а вопрос "учить питон или джава" и данный в статье ответ - говорит об абсолютном непонимании автором ниш этих технологий. причем "ниша" не в плане банковский сектор или датасайнтист, а объем кода, сложность проекта, длительность его жизненного цикла - особенностей проистекающих в первую очередь из системы типизации в этих языках.
позволю немного критики. или критиканства, уж простите.
(1) я не увидел новой парадигмы. именно новой. сам я джавист, и простите, я видел тот же jsf с "сервер сайд рендерингом" и невнятной вёрсткой формы на xml. ужасы типа vaadin со всеми вытекающими. даже я сам приложил руку к увеличению безобразий.
вы правильно отмечаете, что фейсбучная разработка по модели рест+тяжелый js настойчиво подталкивают к "утеканию бизнес логики на клиента". я бы ещё добавил "по факту раздуваемые" трудозатраты, но это уже "надо доказывать". но не суть. вопрос в том, а в чем парадигма?
(2) как в вашем фреймворка сделать кастомную верстку?
(2.2) как интегрировать в ваш фоеймворк работу со сторонними js-клмпонентами? например, я хочу интегрировать в систему яндекс-карты?
(3) простите, но пыха для бизнес приложений - ... выглядит сомнительно. конечно, если вы останетесь в модели рест-запросов и стейтлесс-(микро?)сервисов, без фоновых процессов и многопоточного серверного кода, кеширования в памяти... то конечно, "почему бы да"... но потолок для таких систем весьма не высок ( не, может в пыхе что то и придумали, простите, я ушёл на джаву примерно когда "не состоялся пхп 6 с многопоточностью"). в общем я к чему - разработка бизнес-прилодений с тяжёлой бизнеслогикой и сложными сценариями на языке без многопоточности... сомнительно это выглядит). не говоря о необходимости стандартизации языка, обеспечения гарантий обратной совместимости (как же писать бизнес приложение, если у него срок жизни равен сроку поддержки текущего компилятора?) и статической типизации ( в больших проектах это оооочень сильно помогает избежать кучи ошибок), но это уже совершенно другой разговор.
" правильный номер ".... равный длине искомой книги )))
британские учОные открыли словарные алгоритмы сжатия?!
используя а качестве словаря вероятностные связи в обученной нейронке?)) и при этом это ещё и сжатие с потерями... это что?! jpeg для текстов? wow!!!! XD
маленький шаг для жертв
егэбакалавриата, большая ржака для человечества )))ps: жаль, что первоапрельская шутка не выглядит как шутка . ага. XD))
ага. именно. но. нам бы у себя в локалке чатик развернуть, чтобы по работе созвоне держать , да с подрядчиками болтать в годовых комнатах.
в случае чата - достаточно self-hosted приложения.
вот что-то, что можно поставить себе в докладе и продолжать работать с коллегами и подрядчиками . штука, за которую автору не надо "платить за сервеоа".
ну и где? )) что по итогу - маттерный-мост ставить?)) или что у нас там есть ещё?
Народ, товарищи! Позвольте пооффтопить ?
Я тут тут вот "одной вещи понять не могу".
С одной стороны, все вайбкодер-адепты на каждом шагу кричат, как всё прекрасно, легко и быстро.
С другой стороны, там уже **много*времени*" блокируют сервисы звонков и чатов.
Объясните мне : где сотни навайбкоженных конкурентов Скайпа, Дискорда, Телеграмма ? Не просто чатов типа того же ВКМессенджеоа, Виичата, или какого-нибудь ужаса типа яндекс-мессенджера-приложения-к-телемосту... а функциональных, равных по возможностям тому же телеграмму?
и заметьте я не про "безопасность" говорю, я про функциональность. Группы с комментариями, ответ-цитирование части текста, лайки к сообщениям, голосовые, кружочки, голосования, трансляция геопозиция... где это всё?).. Где тонны приложений вида - "не хочешь переходить на Макс ? - вот смотри, я найбкодил -смотри как прекрасно работает и удобно".
Всё что я увидел - это обзоры уже давно сделанных чатов.
Причем кто-то там уже сам начал писать свой чат. И вроде уже дописал до функционирующего прототипа. Без ИИ.
Почему ни один вайбкодер так и не осилил сделать быстро, красиво и функционально то, что делали гнустные кожаные мешки без прекрасной ии-шечки?...
Неужели адепты вайбкодинга что-то не договаривают ?!
начиная с мидла, особенно "среднего" звена(*1) - технические специалисты "растут" и повышают грейды не за счёт изучения новых технических навыков, а в первую очередь - за счёт опыта и софт-скилов. старший миддл без навыков работы с другими (не только опыт работы в команде, но и джуно-ботоводство), без опыта и кругозора определяющих качество его решений и умения отлаживать и разбираться в чужом коде и новой sdk, без знаний в архитектуре - ни разу не миддл. ни о каком продвижении в лиды в отношении такого недоспеца - речи быть не может.
изучение новой технологии, нового стека технологий - для мидла - не достижение, а рутинная обязанность. он не растет изучив спринг-бут, jpa, апи кафки, (прислать любое название из статьи выше)... это его рядовая обязанность. смена специализации и изучение технологий - важный скилл для дальнейшего роста мидла. а умение учиться - как вы понимаете - совсем не технический навык. это помимо софт скиллов.
сама модель статьи, идея о том, что "изучив технические скиллы - ты станешь лидом"... не просто порочна - это смешно. зазавалово для неофитов. с таким подходом только до начальных мидлов и получится добраться.
а насчёт грейдов и технических навыков - у нас например джун не перейдет в мидлы не обладая твёрдыми знаниями на уровне Java OCA. а специализируется он на спрингбуте, или jee- ветке и хочет выучиться на Java OCP - это не суть. потому - половина всего написанного в статье про мидлов и лидов - имхо чушь. как список технологий - перечень хороший. а попытка увязать это с грейдами - это, мягко говоря, смешно. рассуждения гуманитария о марсоходах.
________
Скрытый текст
*1) мы делим каждый грейд на 3 подгрейда/"звена": условно начальный, средний и старший. итого получается примерно 10 ступеней : стажёр, 3 ступени джуна, 3 ступени мидла, 3 ступени лида, и тимлид/гип, но верхняя ступень достаточно условна потому что это скорее сдвиг в бок.
Отлично! ну значит и покажите, пожалуйста, эти решения.
Потому, что когда дело доходит до практики этих "понятных решений" - оказывается что всё совсем не так уж "понятно" и совсем не так "конструктивно".
Начиная от сложности выбора модели которую ты можешь "скачать и запустить", и кончая весьма скудными возможностями, которые могут предоставить локально развернутые модели, способные хотя бы запуститься на оборудовании "доступном простым смертным".
Мы ходили, потратили денег на железо, и (пока) не нашли пригодного рабочего варианта. Может быть "пока не нашли". А может быть и так, что "у нас лапки".
Но вы же.. у вас же получилось, вы же говорите что конструктивные решения есть, и они понятны. Значит, вы знаете как это сделать. Расскажите пожалуйста ?
Не надо нас отсылать "на деревню дедушке" (тем более, на ресурс не доступной в России "официально"). Тем более, если это всё, с ваших слов, так "понятно, просто и конструктивно" ?)))
Статью про то как круто использовать ИИ хостящийся в облаке - вы смогли написать.
А статью, про то как круто локально развернуть и использовать в тех-же сценариях sels-hosted ИИ - вы не сможете?
Ждем от вас статью.
Заранее спасибо. Надеюсь, вы развеете наше впечатление от пока негативного / бесполезного опыта использования локально развернутых ИИ/нейросеток.
А теперь, вопрос на бис, пожалуйста.
Вот всё то прекрасное, что вы описали в статье - на локальных мощностях офисных серверов.
Справитесь?))) с конкретными ттх серверов, пожалуйста, их стоимостью и счетами за электричество в месяц.
Потому что когда
все ваши модели закроет ркн... когдау вас упадет тырнет... когдаслучится крах доткомов... когда к вам придет безопасник и скажет, что "очень негоже постить в иностранные ИИ системы схему бд в которой будет храниться персоналка граждан РФ"... негоже вплоть до уголовки. ага?)... когда, ИИ-провайдеры
поймутпризнают, что у них нет внятной модели монетизации, а ваши 200+ буказоидов за доступ к "американскому гпт" ни разу не позволят им выйти в ноль, и они взвинтят цены раз в 10, вставят вам "непроматываемую рекламу" (кстати, чатгпт такое уже начал делать), начнут постить вам в комменты бд рекламные баннеры в ascii-арте....... когда ИИ-провайдеры
поймутпризнают,что множества новых датацентра не будет ближайшие лет 10-20, потому что электричества больше взять неоткуда, а ближайшая "электрическая мощь" появится как раз "за срок строительства новой аэс" (те самые 10-20 лет)...... и никакого качественного улучшения работы моделей не будет, не только по причине абзаца выше, но и потому что они уже выпылесосили весь код какой можно, и просили корпорации дать им закрытые сходники, ибо обучать модели "больше не на чем"..
(и им конечно же всё дали, а потом ещё раз догнали....)...что вы будете делать ?
с вашими прекрасными процессами и джуном-недо-менеджером страдающим даннингом-крюгером?...
что с этим всем делать, см выше, если ии-шка на которую у тебя "всё завязано" - развернута не у тебя в офисе?
вы получили минуту славы, а потом катись оно всё медным тазом?))
скажите... а кодирование туда-обратно... оно уже быстрее чем zip-ование "не-перекодированного 4х байтового" utf или ещё пока нет ? ;)
Позволю себе немного оффтопа, если позволите.
Скажите, а OpenStreetMap уже перестал играть в политику и блокировать доступ к тайловым серверам для государственных служб России?
А на OpenStreetMap Data Extracts они вернули "регион Россия" для выгрузки карт нашей страны не в составе "региона Азия" ?
Нет? А тогда почему мы и обсуждаем?)) плаируем закопипастить наработки?
хотите раскрою секрет? просто все адепты микросервисов слепо считают антипаттерн "связи многие ко многим" автоматически приравненным к монолиту.
впрочем это не мешает им следующим шагом рассуждать о том, "как плохо делать распределенный/микросервисный монолит", в котором микросервисы организованы так, что сбой/изменение одного модуля, приводит к сбою / необходимости обновления всей системы.
вот не складывается у них, не складывается, что не в микросервисах дело, не в способе сборки и упаковки компонент системы...
тупят, как Алиса Яндексовская в той истории про "самую длинную реку в мире".
даже в 1с поддерживается альтернативное английское написание ключевых слов.
если это учебный язык для школьников - то им нужен не js с его альтернативно-одаренной псевдо параллельностью, которую и взрослым то не объяснить нормально. и кучей других приколов на тему " '1'+1 ' и " '1'-1 "
если переводить, то переводить Паскаль или Бейсик. а так - это мертворожденная идея, которая не прижилась ни разу на протяжении более чем 40 лет. начиная с советских лого-подобных черепашек.
человеку, который не знает английского - в it делать нечего. абсолютно и совсем. и даже в 1С - без английского и внешних языков ты будешь узконаправленный ограниченным кодером.
это, конечно, если эта статья не стёб и провокация.
подброшу аффтору пару мыслишек :
не существует монолита и микросервисов. как "архитектур".
есть компонентно-ориентированная архитектура и антипаттерн "связи все ко всем" .
непонимание компонентно-ориентированной архитектуры порождает "микросервисный монолит", в котором вроде всё разнесено на сотни хостов, всё по книгам, но что-то поменять сыкотно, потому, что не знаешь где какая проблема вылезет. потому что связи между элементами системы запутаны и трудно прослеживаемы.
а понимание компонентно-ориентированной архитектуры позволяет оставаясь даже в концепции "монолитной сборки и дистрибуции" достигать всех "преимуществ приписываемых якобы-только микросервисам" - распределенные независимые команды, отказоустойчивость, незаметное развертывание новых фич и пр.