Если это крупняк, то всё вполне закономерно. А если мелочь, то вы просто не достучались до нужного человека. Хотя и во втором случае могут быть нюансы вроде зиц-председателя или конторы-прокладки.
Взгляд на графы через решётки - вот и вся разница.
Ценное - новый взгляд часто упрощает какие-то моменты из взгляда по старому.
Теория групп, например, подходит для множества случаев, от теории чисел до геометрии, тем самым обобщая наш взгляд на эти задачи. Решётки - частный случай общей алгебры, как и группы.
Что сказать конкретно? Да не знаю. Потому что и сам автор лишь переводит стрелки на произведение, ссылку на которое даёт в начале статьи. Видимо нужно прочитать то произведение, что бы указать вам на конкретику.
Хотя да, автор мог бы быть более щедрым на пояснения. Но он написал в конце, что статья для кого-то конкретного, а все остальные - так, довесок, поймёте - хорошо, нет - автор не будет против.
Общая проблема подобных текстов - концентрация на мелочах.
Да, автор проделал полезную работу, но полезна она в узких рамках одного из множества процессов разработки. Очевидно, что оптимизируя всю разработку, то есть комплекс процессов, можно получить во много раз больший результат. Но как раз замахиваться на всё целиком желающих нет. Точнее на это замахивается молодёжь, но им абсолютно разумно и быстро бьют по рукам, ибо они навертят такого, что потом точно всё встанет.
Главный стопор, как всегда - бизнес. Им надо быстро, потому всё оптимизировать никогда не дадут, ибо дорого. В результате поощряется кусочная оптимизация, частичная автоматизация, а в целом - страшное убожество, если смотреть глобально.
С другой стороны, если и мелочью не заниматься, то получится вообще печально - никакого развития, даже в виде крайнего убожества. Но тратить время на убожество тоже ничуть не радостная перспектива. Отсюда мораль - бизнес обязан находить в себе ресурсы для какого-то оптимального улучшения самого себя. Проблема здесь следующая - бизнес платит деньги и ожидает, что за деньги ему сделают красиво. Но это, как большинству из нас отлично известно, явное заблуждение. Или отмазка, то есть самооправдание бизнеса и перекладывание вины с себя на работников. Вот такие отмазки и нужно вылечить. Чья это задача? Уж точно не программиста.
В конце текста есть примеры с иерархиями. Для иерархии не важно, сколько килограммов в конкретном узле, потому что узел - абстрактный, то есть вмещает любое количество экземпляров (представителей вида). Абстрактная "морковь вообще" может быть одна штука, может быть десять, и может быть два кило, но общее для всех этих кучек - это морковь. То есть от параметров цвет, вес, длина, толщина и т.д. мы абстрагируемся, или забываем о них. Остаётся лишь название. Классификацию же продуктов на морковь и прочее мы отдаём столь же абстрактному классификатору, устройством которого не интересуемся. Ну и за одно нам не интересно, есть ли он в природе, потому что для нас главное - типы, и то, что в голове мы их можем выделить, а могут ли это сделать реальные классификаторы, нам безразлично. Таковы свойства абстракции, как, собственно, и всей математики.
Хотя да, отношение "больше или равно" действительно не задано для упомянутых в тексте иерархий. Оно подразумевается. Примерно задать можно так - элемент множества с более высоким уровнем абстракции находится в отношении "больше или равно" с элементом с менее высоким уровнем абстракции со стороны "больше". Если в иерархию добавить "морковь мытую" и "морковь немытую", получим, что оба этих элемента множества узлов в иерархии находятся в отношении со стороны "меньше" если вторым в отношении будет узел (элемент множества) "морковь", ну или "морковь" "больше или равна" чем "мытая морковь" (что точнее, поскольку отношение "меньше" в системе нами не задано).
В целом - текст не для тех, кто ожидает строгости. Но никто не мешает ввести строгость самостоятельно в качестве упражнения. Для остальных же строгость будет большой помехой (до поры до времени).
Почему? БПЛА Орлан-10 принят на вооружение и в комплекте оборудования имеет датчик ИК диапазона. Другое дело, МЧС отказывается применять подобные вполне дешёвые изделия. Или вам не дают. Но суть от этого не меняется - технология прекрасно работает. А вот организационные проблемы гос.монополий (в частности МЧС) не дают нам всем использовать вполне доступные возможности.
Ночью поиски с дронами практически не проводятся, днем бесполезен
Опять какая-то околесица. Либо это опять организационные причины (читай коррупция), но вы их не замечаете. Как раз ночью поиск с БПЛА с ИК датчиком - самое лучшее время в сравнении с камерой видимого диапазона. Бесполезность днём - это вообще нонсенс. Посмотрите кучу видео на трубе, где хоть днём, хоть ночью, прекрасно видно цель.
Повторюсь - алгоритм выделения тёплого объекта в кадре на много порядков проще работы с видимым диапазоном, отсюда преимущества, которые даются нам хоть днём, хоть ночью, и даже в туман.
На сбор 30 тысяч снимков и их разметку у меня ушла пара лет (календарных конечно).
Ну вот, пара лет вместо простейшего алгоритма, который пишется за день. Так зачем же возражать против очевидного?
Однако связь на поисках не всегда достаточно чтобы передавать тысячи снимков на изучение
Ну да, МЧС не даёт вам свою связь, согласен. Но вы разве не понимаете, что это проблемы бюрократии и коррупции? И вы прикрываетесь бюрократией и коррупцией. Правильно?
Если же вы решили своими силами сделать всё, включая связь, то вы замахнулись на очевидно дорогую и сложную задачу. Не знаю, может вам оно нравится, но с точки зрения эффективности это безумное расточительство ресурсов. Вы сливаете в пустоту работу сотен людей. Да, какие-то результаты даёте, но что могли бы сделать те же люди, вооружённые нормальным оборудованием? В тысячу раз больше. И вместо тысячи раз вы довольствуетесь тем, что можете осилить, то есть буквально жалкими крохами с барского стола МЧС, МО и прочих полиций.
Да, найти одного человека вашими усилиями хорошо, но упуская при этом возможность найти ещё тысячу, вы тем самым поощряете наплевательское отношение к жизни людей. Меняете одного избранного на тысячу не найденных и умерших. Зачем так легко разбрасываться человеческими жизнями? Не лучше ли указать на крайнюю неэффективность чинуш, ответственных за поиск людей? Не лучше ли требовать от них предоставить вам то оборудование, которое эти чинуши имеют и не используют для нахождения тех самых дополнительных 1000 человек? Они своей неэффективностью и коррумпированностью убивают всех не найденных, а вы делаете вид, что так и надо, давайте им поможем воровать побольше, жить полегче, сами кого-нибудь найдём вместо них, что бы они записали себе в список достижений "общественную поддержку" и найденных вами людей. Ну правильно, поощряем пакость и удивляемся, а почему это они становятся всё хуже и хуже.
взаимозаменяемых сотрудников, которых легко найти на рынке
Хотя в этом случае желание бизнеса приводит к обратным результатам. Бизнес хочет взаимозаменяемое, но он ведь не один. Все хотят взаимозаменяемое, и их много, поэтому все ищут "специалиста по ХХХ с опытом от УУУ лет". Но когда все ищут одно и тоже, то получаем дефицит. А потом, когда специалисты наелись технологией ХХХ и перепрыгнули на технологию ZZZ, она постепенно становится новой модой и бизнес теперь начинает искать спецов по ZZZ. Но их массово опять нет, опять имеем голод. И так продолжается уже лет 30.
Эмоционально видение проблемы разделяю. Но рационально автор не сумел отделить личную боль от общественной.
Общая боль состоит в неэффективности бизнеса. От этого все тормоза, неудобства и баги.
Личная боль - нарушение гармонии (в понимании автора). Да, убогие решения строят ерунду, на которой пишут "мега-супер-храм-вашего-всего". То есть бьют больно по мечте, по красоте, по идеалу, наклеивая ярлык "идеал" на кучу из отходов жизнедеятельности. Ну и рекламируя громко это изделие, разумеется, под флагом "идеальное лично для вас" (хотя меня они не знают ни на грамм, разумеется).
Раздел "что делать" так же несколько искажает реальность, а потому нереалистичен по части воплощения в жизнь.
Например:
вы не рабы, а интеллектуальная элита современности
Интеллектуальная элита современности, я уж извиняюсь, но это точно не IT. IT - это слесаря. Им поручают напилить гаек, ну и они дают стране угля именно в указанных габаритах.
Интеллектуальная элита же не даёт стране угля. Она даёт стране будущее. Какое будущее нам дали IT-шники? Нет, они лишь угля нам навалили, а дальше мы вот разгребаем все эти тормоза и баги.
Из показанного непонимания следует:
В IT сильный дефицит кадров, а хороших кадров - острый дефицит.
Понятно, что если себя причислил к интеллектуальной элите, то сразу начинаешь думать "как меня такого гениального мало".
Но в реальности кадров завались. Дефицита реально нет. Хотя есть искажённые требования к слесарям, определяемые самими слесарями с целью улучшения позиции оных слесарей на их текущем рабочем месте. Ну а причина опять та же самая - неэффективность бизнеса. Не следствие, а именно причина.
Каждый проект имеет уникальную архитектуру
И опять мимо. Названия там могут быть отличающиеся, но от общего цикла работы с данными никто из велосипедистов никуда не денется. Всегда - взять данные, передать, показать, прочитать ввод, передать, сохранить. Ну а если при этом чешут ухо пяткой, то нового от этого в проекте ничего не появляется. Или если показывают с графиками и анимацией, то суть явления "показать" от этого тоже никуда не девается.
Одни и те же детские болезни в каждом проекте.
Вот и подтверждение от автора - ничего в проектах не меняется, включая одни и те же болезни.
Но, тем не менее, автор поднял важную тему. Не беда, что не дотянул до глубин. Главное - чем больше подобных обсуждений случится, тем будет лучше. Хотя быстро уменьшающаяся карма, похоже, сильно ограничит данное направление дискуссии. А жаль. Но это тоже часть нашего неидеального мира.
Я точно знаю, что ваши индивидуальные усилия неэффективны. Эффективность даёт лишь групповая работа специалистов. Один условный Орлан-10 с ИК камерой и десяток сидящих дома добровольцев, готовых поглядеть на автоматически выбранные кадры. Это намного эффективнее всех персональных квадрокоптеров вместе взятых.
Вопрос цены, на самом деле, уводит вас в сторону от истины. На первый взгляд кажется, что пусть даже миллион рублей - это много. Но вспомните, сколько тратят поисковики на одно мероприятие? У меня нет точных цифр, но допустим участвует 100 человек. Каждому нужно доехать до мероприятия = примерно 10-20 т.р. на всех. Нужно оборудование - рации, машины, квадрики, зарядки, одежда, и прочее. Суммарно на 100 человек за год выйдет очень приличная сумма, возможно даже миллион. Стоит стукнуть одну единственную машину - ремонт вам встанет в десятки тысяч минимум. Ну и таким образом можно расписать множество затрат, которые вы упускаете из виду, потому что их несут другие. Только "другие", это те, кто мог бы вместо означенных затрат скинуться и совместно купить этот самый тепловизор.
О возможностях МЧС я уже не говорю, потому что, во первых - там полнейшие бездари, а во вторых - лютая коррупция. Но тем не менее, средств у них - как у дурака махорки.
И вот на фоне крайне реалистичных возможностей иметь нужное оборудование даже в варианте "бесплатные любители", мы видим статьи, предлагающие тренировать нейронки. Но что такое "тренировка нейронок"? Это работа очень недешёвых специалистов. Да, возможно кто-то из них согласился отдать свою работу даром, но тем не менее, это лишь напоминает нам о том самом игнорировании (в том числе вами) чужих затрат. Бесплатно не значит "ничего не стоит". Люди обязательно несут эти затраты. А те, кто легко запрягает этих добровольцев нести груз и далее, ни на секунду не осознавая его тяжесть (несут-то не они) - как бы вы их назвали?
Другими словами - бессмысленно расходуются большие ресурсы. Транжирству способствует ощущение "бесплатности" происходящего. Ну и далее уже около бесплатного сыра начинают вертеться всяческие желающие достичь свои корыстные цели, опять так нахально эксплуатируя "бесплатное" и чужое.
Ну и по эффективности. Листва и прочее - гарантия неработоспособности нейросети. А с инфракрасным датчиком это, во первых, не всегда так (неплотная листва всё же пропускает), а во вторых - есть куча ситуаций, когда инфракрасный датчик принципиально нельзя заменить работой в видимом спектре. То есть вместо крайне эффективного решения предлагается намеренно продолжать эксплуатировать добровольцев в наименее благоприятных условиях. Упрощённо - примитивный детектор контраста, автоматом отмечающий нужные области, с дальнейшей отправкой данных на подробное изучение куда-нибудь, где есть тёплый и мягкий диван, кофе, и все прочие радости, вместо напряжённой работы в полях сотен добровольцев, которые обязаны прочёсывать местность тогда, когда нейросеть не способна что-то распознать (а это большая часть условий - ночь, дымка, дождь, не то освещение).
А зачем ставить заведомо много более сложную задачу, если есть простое решение? Каким местом думали, когда предлагали вместо давно привычного инфракрасного датчика использовать фото в видимом диапазоне?
Скорее всего кто-то, используя авторитет Лиза-алерт, решает свои шкурные задачи.
Части, признаки, свойства - философские категории, не отражающие реальную глубину явления.
Изучение - классификация/систематизация, где выявляются первичные общие характеристики. Затем выявляются зависимости и ограничения. Потом строят модель/модели. Полное понимание - программа, отвечающая на любые вопросы о явлении. Наша ограниченность - мы не знаем, какие вопросы корректны. Соответственно, нам далеко до полного понимание почти во всех хоть сколько-нибудь сложных вопросах.
Нет, не разбил. Разные сервера это разные инстансы одного и того-же сервиса
Разбили, но не заметили. Кодовое слово - балансер.
Ага, однако у конструкторов (или через что там ваш DI работает) ваших классов бизнес-логики от силы с десяток параметров, очень редко когда больше, вот и вся связность монолитов
Компоненты приложения взаимодействуют через вызов методов, а не конструкторов. Методов может быть тысяча (гуглим god's class)
в хороших книжках вам скажут, что если останется значительная связность, то это будет не микросервисная архитектура, а распределенный монолит и что это наихудшее архитектурное решение, которое можно предлопожить. Так что ни о какой квадратичной зависимости микросервисов речи не идет.
Пример - слоёный сервис. И каждая веб-страница (через серверную часть) дёргает все возможности логики. Потому что так види художник (и на каждой странице хочет предложить пользователю). И одновременно уведомляет остальные страницы об изменениях через ненаблюдаемую им лично реактивность.
Квадратичность достижима легко, ну а неверие в силу "настоящих художников" проходит после личного знакомства с их творчеством.
Видится мне так: клиенты ж не напрямую к сервисам подключаются, а через балансировщики, так что клиентская сессия останется живой
Ну вот, вы уже торгуетесь.
Смысл в том, что придраться к отдельным, оторванным от контекста словам можно, но целом в тексте был несколько другой посыл. Посыл такой - нужно разумно подходить к выбору решений. И если нам нужны клиентские сессии, то мы вынуждены будем думать в сторону разбиения монолита. Но не на 1000 микросервисов, а для начала на два - первичная обработка запроса и всё остальное. Далее возможны ещё варианты, но если два сервиса справятся (а это реально работает), то зачем нам 1000?
В свою очередь это значит, что ваш пример справедлив только для плохой архитектуры, а сравнивать обычные монолиты и плохие микросервисы несколько несправедливо...
Скорее ваши слова справедливы лишь для ваших предположений. Микросервис может просто оставить сообщение в очереди, на диске, хоть на 1000 лет. Как вы предлагаете сделать такой финт в монолите? Ответ - добавив в монолит функционал очередей. Теперь следите за руками - очередь, это отдельный сервис? Немного по другому - очередь, это отдельный компонент? И ещё вариант - в микросервисном решении с самого начала были очереди, а в монолите не было, отсюда вопрос - мы всё же что-то добавили?
Поэтому не стоит много слов тратить на рассказ о том, что "в принципе оно всё похоже". Да, в принципе мы вообще тут ерундой занимаемся и перегружаем лишними разговорами свои распределённые микросервисы. Но это только в принципе. А конкретика несколько другая.
Общая шина данных используется не только в микросервисной архитектуре - во многих фреймворках реализован observer и я во многих проектах видел использование внутри монолита.
Вы опять не обратили внимания на причину использования шины.
Но ведь дурацкие связи - это и для монолита актуально, просто там последствия менее очевидны
Последствия более очевидны - нет или есть накладные расходы. Результат - вместо, скажем, 10 000 серверов твиттер имеет 100 000.
Какая асинхронность?
Пример - очереди.
Речь же была о реализации и документировании API
Про документирование вы не говорили, а про реализацию - она стала асинхронной.
Если же Вам принципиально не нравится, что тут появляются сетевые задержки, то да, это недостаток
Там ещё в 10 раз больше серверов появляется.
так что много времени и сил не отнимают, особенно при использовании удобных инструментов.
Конечно, 10 против 100 тысяч.
нужно знать активность пользователей, отслеживать платежи, контролировать воронки активаций, проводить А/Б-тесты и т.д
Про это написано в разделе про аналитику.
доступности сервиса, кол-ва ошибок, дисконнектов, состояния железок и виртуалок и т.д. ... условный HTTP API один на 1000 методов в монолите
Монолит падает один раз. Микросервисы - 1000. Разница 1000 раз вам ничего не говорит? Условный HTTP API один только для монолита. А для микросервисов протокол один, а параметров - 1000 наборов. И обычно под мониторинг в каждом сервисе выделяют отдельный вход - вот ещё 1000 задачек.
С раздутым монолитом над которым работают сотни разработчиков это нифига не просто.
Я не говорил, что абсолютно всё следует держать в одном монолите. Этого никогда не требовалось, например в мире Java. Там уже больше 20 лет существует концепция сервера приложений, где условный единственный монолит организации давно разделён на отдельные приложения. Результат - два-три десятка приложений слабо зависимы. Но работают все на одном сервере. Сам сервер, разумеется, даёт нам кластеризацию и прочие способы масштабирования, но приложения об этом не задумываются (ну почти). Всё это - на основе опыта с приложением в организации с десятками миллионов клиентов.
В итоге - в такой ситуации нет ничего подобного описанному вами. Соответственно, организация, работавшая с серверами приложений, переходит на микросервисы уж точно не из-за того, о чём говорите вы.
одновременно работают и старая и новая версии, новые сессии открываются на новых версиях серверов, старые работают до тех пор пока не будут завершены все старые сессии
Правильно, но вы уже разбили монолит. Это означает, что претензии у вас не ко мне, а к вашему собственному пониманию.
Простите, а у вас в монолите тоже каждый класс знает о всех остальных классах и взаимодействует с ними?
Каждый класс "знает" о других. То есть при необходимости может и взаимодействовать. Лёгкость организации взаимодействия ведёт к повышению количества связей. Хотя да, можно не учитывать мои слова из текста о сильной зависимости количества связей от умений архитектора.
Идеал микросервисной архитектуры это когда сервисы настолько не связанны, что вообще друг с другом никак не разговаривают и дел не имеют
Это не идеал микросервисной архитектуры, это скорее ваши фантазии. В любой книжке по архитектуре вам скажут, что связность нужно сокращать, но ни в одной из них не скажут, что связность нужно уменьшить до нуля.
Да, в такой работе есть сложная часть, и я на неё указывал, правда без подробностей.
В плане "куча специалистов" - да, какое-то количество потребуется, но это один отдел, вместе со всеми нейросетями и прочим для рекламы. Одни и те же люди. Одно и то же железо. Железо мощное, но не запредельно (не тысячи серверов).
Разумеется, если ставить цель тренировать какую-нибудь GPT-4, тогда вам потребуется домик метров сто длинной для одних только серверов, но я сильно сомневаюсь в необходимости такой задачи в случае с твиттером.
Математическим анализом занимаются математики. Такова устоявшаяся терминология. Ну а системные аналитики анализируют именно системы, даже если это кому-то кажется неправильным. Специализация на задачах бизнеса для системного аналитика возможна, а вот переход на анализ сложных систем при помощи системного подхода для бизнес-аналитика будет сложным.
Смешивание терминов и придание им новых смыслов, отличающихся от первоначальных, есть неизбежное следствие движения в сторону прикладного упрощения, свойственного в частности бизнесу.
Системный аналитик занимается анализом систем. Вроде бы масло масляное, но если мы уточним, что такое система, что всё встанет на место.
Бизнес - это система. Компьютер - это тоже система. Вселенная - тоже система. Системы бывают вложенными, связанными, структурированными и т.д. Это всё слова из системного анализа. Им и занимается системный аналитик. И поэтому у него системное мышление (вы ведь слышали о таком?).
А бизнес-аналитик, это тот, кто разбирается в бизнесе, но с системным мышлением у него не очень. То есть системный - более абстрактный, более высокоуровневый. Но при этом в конкретном бизнесе может ничего не понимать.
Что микросервис, что монолит можно поднять в нескольких инстансах и переключать - green/blue deployment
Проблема не в инстансах, а в подключенных клиентах. В том же твиттере в каждый момент открыты тысячи сессий. Им всем придётся умереть.
Что внутри монолита выполнение функции может прерваться с выбросом исключения, что при обращении к сервису запрос может вернуть ошибку. Обрабатывать нужно в любом случае
Повторю из статьи - там разный алгоритм. В монолите некуда переключатьcя. А в микросервисе есть.
Как внутри монолита делили код на модули/пакеты/неймспейсы и старались ослаблять связи, так и с микросервисами. Каждый отдельный микросервис знает о считанных единицах других, а некоторые и вовсе могут никого не знать и общаться, например, исключительно через общую шину данных
О ком знает микросервис - зависит от архитектора (о чём опять же было написано). А сама необходимость введения шины нам говорит лишь об одном - квадратичный рост является проблемой и один из способов борьбы - шина.
один раз создав и описав входящий/исходящий интерфейсы сервиса, это будет переиспользовано другими сервисами
Вносимая асинхронность с вами несогласна. Есть и другие специфические моменты.
Для монолита тоже мониторинг нужен по предметным областям и тут пофиг, это монолит или сервисы
Если вы имеете в виду внешние интерфейсы, то да, они мало меняются. Но зачем же забывать о создании тысячи внутренних?
А предметно-независимый, то бишь инфраструктурный мониторинг вообще-то шаблонный, его тоже достаточно один раз описать и переиспользовать
Если вы здесь имеете в виду мониторинг внутренних интерфейсов, то на тысячу сервисов нам потребуется тысяча описаний. Даже если они выполняются один раз. Сравните с отсутствием потребности в тысяче описаний для альтернативы.
Вы хорошо знаете, какие проблемы возникали и как решались в Твиттере, или просто "да я это сделаю за ночь и бутылку водки"?
А здесь вы уже вышли за рамки аргументированных возражений, и потому я оставлю дальнейшее без комментариев.
Пожалуйста, не экстраполируйте плохие практики на всю индустрию, если не знаете наверняка
Кое-что знаю. Но да, о Твиттере - только из интернета. Оттуда же про 100 000 серверов, и про десяток тысяч работников, ну и про остальное. Остальное как раз сильно намекает на то, что видел сам лично.
Если это крупняк, то всё вполне закономерно. А если мелочь, то вы просто не достучались до нужного человека. Хотя и во втором случае могут быть нюансы вроде зиц-председателя или конторы-прокладки.
То есть поймите свою среду обитания, да обрящете.
Взгляд на графы через решётки - вот и вся разница.
Ценное - новый взгляд часто упрощает какие-то моменты из взгляда по старому.
Теория групп, например, подходит для множества случаев, от теории чисел до геометрии, тем самым обобщая наш взгляд на эти задачи. Решётки - частный случай общей алгебры, как и группы.
Что сказать конкретно? Да не знаю. Потому что и сам автор лишь переводит стрелки на произведение, ссылку на которое даёт в начале статьи. Видимо нужно прочитать то произведение, что бы указать вам на конкретику.
Хотя да, автор мог бы быть более щедрым на пояснения. Но он написал в конце, что статья для кого-то конкретного, а все остальные - так, довесок, поймёте - хорошо, нет - автор не будет против.
Общая проблема подобных текстов - концентрация на мелочах.
Да, автор проделал полезную работу, но полезна она в узких рамках одного из множества процессов разработки. Очевидно, что оптимизируя всю разработку, то есть комплекс процессов, можно получить во много раз больший результат. Но как раз замахиваться на всё целиком желающих нет. Точнее на это замахивается молодёжь, но им абсолютно разумно и быстро бьют по рукам, ибо они навертят такого, что потом точно всё встанет.
Главный стопор, как всегда - бизнес. Им надо быстро, потому всё оптимизировать никогда не дадут, ибо дорого. В результате поощряется кусочная оптимизация, частичная автоматизация, а в целом - страшное убожество, если смотреть глобально.
С другой стороны, если и мелочью не заниматься, то получится вообще печально - никакого развития, даже в виде крайнего убожества. Но тратить время на убожество тоже ничуть не радостная перспектива. Отсюда мораль - бизнес обязан находить в себе ресурсы для какого-то оптимального улучшения самого себя. Проблема здесь следующая - бизнес платит деньги и ожидает, что за деньги ему сделают красиво. Но это, как большинству из нас отлично известно, явное заблуждение. Или отмазка, то есть самооправдание бизнеса и перекладывание вины с себя на работников. Вот такие отмазки и нужно вылечить. Чья это задача? Уж точно не программиста.
В конце текста есть примеры с иерархиями. Для иерархии не важно, сколько килограммов в конкретном узле, потому что узел - абстрактный, то есть вмещает любое количество экземпляров (представителей вида). Абстрактная "морковь вообще" может быть одна штука, может быть десять, и может быть два кило, но общее для всех этих кучек - это морковь. То есть от параметров цвет, вес, длина, толщина и т.д. мы абстрагируемся, или забываем о них. Остаётся лишь название. Классификацию же продуктов на морковь и прочее мы отдаём столь же абстрактному классификатору, устройством которого не интересуемся. Ну и за одно нам не интересно, есть ли он в природе, потому что для нас главное - типы, и то, что в голове мы их можем выделить, а могут ли это сделать реальные классификаторы, нам безразлично. Таковы свойства абстракции, как, собственно, и всей математики.
Хотя да, отношение "больше или равно" действительно не задано для упомянутых в тексте иерархий. Оно подразумевается. Примерно задать можно так - элемент множества с более высоким уровнем абстракции находится в отношении "больше или равно" с элементом с менее высоким уровнем абстракции со стороны "больше". Если в иерархию добавить "морковь мытую" и "морковь немытую", получим, что оба этих элемента множества узлов в иерархии находятся в отношении со стороны "меньше" если вторым в отношении будет узел (элемент множества) "морковь", ну или "морковь" "больше или равна" чем "мытая морковь" (что точнее, поскольку отношение "меньше" в системе нами не задано).
В целом - текст не для тех, кто ожидает строгости. Но никто не мешает ввести строгость самостоятельно в качестве упражнения. Для остальных же строгость будет большой помехой (до поры до времени).
Почему? БПЛА Орлан-10 принят на вооружение и в комплекте оборудования имеет датчик ИК диапазона. Другое дело, МЧС отказывается применять подобные вполне дешёвые изделия. Или вам не дают. Но суть от этого не меняется - технология прекрасно работает. А вот организационные проблемы гос.монополий (в частности МЧС) не дают нам всем использовать вполне доступные возможности.
Опять какая-то околесица. Либо это опять организационные причины (читай коррупция), но вы их не замечаете. Как раз ночью поиск с БПЛА с ИК датчиком - самое лучшее время в сравнении с камерой видимого диапазона. Бесполезность днём - это вообще нонсенс. Посмотрите кучу видео на трубе, где хоть днём, хоть ночью, прекрасно видно цель.
Повторюсь - алгоритм выделения тёплого объекта в кадре на много порядков проще работы с видимым диапазоном, отсюда преимущества, которые даются нам хоть днём, хоть ночью, и даже в туман.
Ну вот, пара лет вместо простейшего алгоритма, который пишется за день. Так зачем же возражать против очевидного?
Ну да, МЧС не даёт вам свою связь, согласен. Но вы разве не понимаете, что это проблемы бюрократии и коррупции? И вы прикрываетесь бюрократией и коррупцией. Правильно?
Если же вы решили своими силами сделать всё, включая связь, то вы замахнулись на очевидно дорогую и сложную задачу. Не знаю, может вам оно нравится, но с точки зрения эффективности это безумное расточительство ресурсов. Вы сливаете в пустоту работу сотен людей. Да, какие-то результаты даёте, но что могли бы сделать те же люди, вооружённые нормальным оборудованием? В тысячу раз больше. И вместо тысячи раз вы довольствуетесь тем, что можете осилить, то есть буквально жалкими крохами с барского стола МЧС, МО и прочих полиций.
Да, найти одного человека вашими усилиями хорошо, но упуская при этом возможность найти ещё тысячу, вы тем самым поощряете наплевательское отношение к жизни людей. Меняете одного избранного на тысячу не найденных и умерших. Зачем так легко разбрасываться человеческими жизнями? Не лучше ли указать на крайнюю неэффективность чинуш, ответственных за поиск людей? Не лучше ли требовать от них предоставить вам то оборудование, которое эти чинуши имеют и не используют для нахождения тех самых дополнительных 1000 человек? Они своей неэффективностью и коррумпированностью убивают всех не найденных, а вы делаете вид, что так и надо, давайте им поможем воровать побольше, жить полегче, сами кого-нибудь найдём вместо них, что бы они записали себе в список достижений "общественную поддержку" и найденных вами людей. Ну правильно, поощряем пакость и удивляемся, а почему это они становятся всё хуже и хуже.
Тоже поддерживаю.
Хотя в этом случае желание бизнеса приводит к обратным результатам. Бизнес хочет взаимозаменяемое, но он ведь не один. Все хотят взаимозаменяемое, и их много, поэтому все ищут "специалиста по ХХХ с опытом от УУУ лет". Но когда все ищут одно и тоже, то получаем дефицит. А потом, когда специалисты наелись технологией ХХХ и перепрыгнули на технологию ZZZ, она постепенно становится новой модой и бизнес теперь начинает искать спецов по ZZZ. Но их массово опять нет, опять имеем голод. И так продолжается уже лет 30.
Эмоционально видение проблемы разделяю. Но рационально автор не сумел отделить личную боль от общественной.
Общая боль состоит в неэффективности бизнеса. От этого все тормоза, неудобства и баги.
Личная боль - нарушение гармонии (в понимании автора). Да, убогие решения строят ерунду, на которой пишут "мега-супер-храм-вашего-всего". То есть бьют больно по мечте, по красоте, по идеалу, наклеивая ярлык "идеал" на кучу из отходов жизнедеятельности. Ну и рекламируя громко это изделие, разумеется, под флагом "идеальное лично для вас" (хотя меня они не знают ни на грамм, разумеется).
Раздел "что делать" так же несколько искажает реальность, а потому нереалистичен по части воплощения в жизнь.
Например:
Интеллектуальная элита современности, я уж извиняюсь, но это точно не IT. IT - это слесаря. Им поручают напилить гаек, ну и они дают стране угля именно в указанных габаритах.
Интеллектуальная элита же не даёт стране угля. Она даёт стране будущее. Какое будущее нам дали IT-шники? Нет, они лишь угля нам навалили, а дальше мы вот разгребаем все эти тормоза и баги.
Из показанного непонимания следует:
Понятно, что если себя причислил к интеллектуальной элите, то сразу начинаешь думать "как меня такого гениального мало".
Но в реальности кадров завались. Дефицита реально нет. Хотя есть искажённые требования к слесарям, определяемые самими слесарями с целью улучшения позиции оных слесарей на их текущем рабочем месте. Ну а причина опять та же самая - неэффективность бизнеса. Не следствие, а именно причина.
И опять мимо. Названия там могут быть отличающиеся, но от общего цикла работы с данными никто из велосипедистов никуда не денется. Всегда - взять данные, передать, показать, прочитать ввод, передать, сохранить. Ну а если при этом чешут ухо пяткой, то нового от этого в проекте ничего не появляется. Или если показывают с графиками и анимацией, то суть явления "показать" от этого тоже никуда не девается.
Вот и подтверждение от автора - ничего в проектах не меняется, включая одни и те же болезни.
Но, тем не менее, автор поднял важную тему. Не беда, что не дотянул до глубин. Главное - чем больше подобных обсуждений случится, тем будет лучше. Хотя быстро уменьшающаяся карма, похоже, сильно ограничит данное направление дискуссии. А жаль. Но это тоже часть нашего неидеального мира.
Я точно знаю, что ваши индивидуальные усилия неэффективны. Эффективность даёт лишь групповая работа специалистов. Один условный Орлан-10 с ИК камерой и десяток сидящих дома добровольцев, готовых поглядеть на автоматически выбранные кадры. Это намного эффективнее всех персональных квадрокоптеров вместе взятых.
Вопрос цены, на самом деле, уводит вас в сторону от истины. На первый взгляд кажется, что пусть даже миллион рублей - это много. Но вспомните, сколько тратят поисковики на одно мероприятие? У меня нет точных цифр, но допустим участвует 100 человек. Каждому нужно доехать до мероприятия = примерно 10-20 т.р. на всех. Нужно оборудование - рации, машины, квадрики, зарядки, одежда, и прочее. Суммарно на 100 человек за год выйдет очень приличная сумма, возможно даже миллион. Стоит стукнуть одну единственную машину - ремонт вам встанет в десятки тысяч минимум. Ну и таким образом можно расписать множество затрат, которые вы упускаете из виду, потому что их несут другие. Только "другие", это те, кто мог бы вместо означенных затрат скинуться и совместно купить этот самый тепловизор.
О возможностях МЧС я уже не говорю, потому что, во первых - там полнейшие бездари, а во вторых - лютая коррупция. Но тем не менее, средств у них - как у дурака махорки.
И вот на фоне крайне реалистичных возможностей иметь нужное оборудование даже в варианте "бесплатные любители", мы видим статьи, предлагающие тренировать нейронки. Но что такое "тренировка нейронок"? Это работа очень недешёвых специалистов. Да, возможно кто-то из них согласился отдать свою работу даром, но тем не менее, это лишь напоминает нам о том самом игнорировании (в том числе вами) чужих затрат. Бесплатно не значит "ничего не стоит". Люди обязательно несут эти затраты. А те, кто легко запрягает этих добровольцев нести груз и далее, ни на секунду не осознавая его тяжесть (несут-то не они) - как бы вы их назвали?
Другими словами - бессмысленно расходуются большие ресурсы. Транжирству способствует ощущение "бесплатности" происходящего. Ну и далее уже около бесплатного сыра начинают вертеться всяческие желающие достичь свои корыстные цели, опять так нахально эксплуатируя "бесплатное" и чужое.
Ну и по эффективности. Листва и прочее - гарантия неработоспособности нейросети. А с инфракрасным датчиком это, во первых, не всегда так (неплотная листва всё же пропускает), а во вторых - есть куча ситуаций, когда инфракрасный датчик принципиально нельзя заменить работой в видимом спектре. То есть вместо крайне эффективного решения предлагается намеренно продолжать эксплуатировать добровольцев в наименее благоприятных условиях. Упрощённо - примитивный детектор контраста, автоматом отмечающий нужные области, с дальнейшей отправкой данных на подробное изучение куда-нибудь, где есть тёплый и мягкий диван, кофе, и все прочие радости, вместо напряжённой работы в полях сотен добровольцев, которые обязаны прочёсывать местность тогда, когда нейросеть не способна что-то распознать (а это большая часть условий - ночь, дымка, дождь, не то освещение).
А зачем ставить заведомо много более сложную задачу, если есть простое решение? Каким местом думали, когда предлагали вместо давно привычного инфракрасного датчика использовать фото в видимом диапазоне?
Скорее всего кто-то, используя авторитет Лиза-алерт, решает свои шкурные задачи.
Что такое "агентская проблема"?
Части, признаки, свойства - философские категории, не отражающие реальную глубину явления.
Изучение - классификация/систематизация, где выявляются первичные общие характеристики. Затем выявляются зависимости и ограничения. Потом строят модель/модели. Полное понимание - программа, отвечающая на любые вопросы о явлении. Наша ограниченность - мы не знаем, какие вопросы корректны. Соответственно, нам далеко до полного понимание почти во всех хоть сколько-нибудь сложных вопросах.
Разбили, но не заметили. Кодовое слово - балансер.
Компоненты приложения взаимодействуют через вызов методов, а не конструкторов. Методов может быть тысяча (гуглим god's class)
Пример - слоёный сервис. И каждая веб-страница (через серверную часть) дёргает все возможности логики. Потому что так види художник (и на каждой странице хочет предложить пользователю). И одновременно уведомляет остальные страницы об изменениях через ненаблюдаемую им лично реактивность.
Квадратичность достижима легко, ну а неверие в силу "настоящих художников" проходит после личного знакомства с их творчеством.
Это не "готовое ПО", это готовое решение. В других решениях цифры могут быть другими.
Ну вот, вы уже торгуетесь.
Смысл в том, что придраться к отдельным, оторванным от контекста словам можно, но целом в тексте был несколько другой посыл. Посыл такой - нужно разумно подходить к выбору решений. И если нам нужны клиентские сессии, то мы вынуждены будем думать в сторону разбиения монолита. Но не на 1000 микросервисов, а для начала на два - первичная обработка запроса и всё остальное. Далее возможны ещё варианты, но если два сервиса справятся (а это реально работает), то зачем нам 1000?
Скорее ваши слова справедливы лишь для ваших предположений. Микросервис может просто оставить сообщение в очереди, на диске, хоть на 1000 лет. Как вы предлагаете сделать такой финт в монолите? Ответ - добавив в монолит функционал очередей. Теперь следите за руками - очередь, это отдельный сервис? Немного по другому - очередь, это отдельный компонент? И ещё вариант - в микросервисном решении с самого начала были очереди, а в монолите не было, отсюда вопрос - мы всё же что-то добавили?
Поэтому не стоит много слов тратить на рассказ о том, что "в принципе оно всё похоже". Да, в принципе мы вообще тут ерундой занимаемся и перегружаем лишними разговорами свои распределённые микросервисы. Но это только в принципе. А конкретика несколько другая.
Вы опять не обратили внимания на причину использования шины.
Последствия более очевидны - нет или есть накладные расходы. Результат - вместо, скажем, 10 000 серверов твиттер имеет 100 000.
Пример - очереди.
Про документирование вы не говорили, а про реализацию - она стала асинхронной.
Там ещё в 10 раз больше серверов появляется.
Конечно, 10 против 100 тысяч.
Про это написано в разделе про аналитику.
Монолит падает один раз. Микросервисы - 1000. Разница 1000 раз вам ничего не говорит? Условный HTTP API один только для монолита. А для микросервисов протокол один, а параметров - 1000 наборов. И обычно под мониторинг в каждом сервисе выделяют отдельный вход - вот ещё 1000 задачек.
Я не говорил, что абсолютно всё следует держать в одном монолите. Этого никогда не требовалось, например в мире Java. Там уже больше 20 лет существует концепция сервера приложений, где условный единственный монолит организации давно разделён на отдельные приложения. Результат - два-три десятка приложений слабо зависимы. Но работают все на одном сервере. Сам сервер, разумеется, даёт нам кластеризацию и прочие способы масштабирования, но приложения об этом не задумываются (ну почти). Всё это - на основе опыта с приложением в организации с десятками миллионов клиентов.
В итоге - в такой ситуации нет ничего подобного описанному вами. Соответственно, организация, работавшая с серверами приложений, переходит на микросервисы уж точно не из-за того, о чём говорите вы.
Правильно, но вы уже разбили монолит. Это означает, что претензии у вас не ко мне, а к вашему собственному пониманию.
Каждый класс "знает" о других. То есть при необходимости может и взаимодействовать. Лёгкость организации взаимодействия ведёт к повышению количества связей. Хотя да, можно не учитывать мои слова из текста о сильной зависимости количества связей от умений архитектора.
Это не идеал микросервисной архитектуры, это скорее ваши фантазии. В любой книжке по архитектуре вам скажут, что связность нужно сокращать, но ни в одной из них не скажут, что связность нужно уменьшить до нуля.
Да, в такой работе есть сложная часть, и я на неё указывал, правда без подробностей.
В плане "куча специалистов" - да, какое-то количество потребуется, но это один отдел, вместе со всеми нейросетями и прочим для рекламы. Одни и те же люди. Одно и то же железо. Железо мощное, но не запредельно (не тысячи серверов).
Разумеется, если ставить цель тренировать какую-нибудь GPT-4, тогда вам потребуется домик метров сто длинной для одних только серверов, но я сильно сомневаюсь в необходимости такой задачи в случае с твиттером.
Математическим анализом занимаются математики. Такова устоявшаяся терминология. Ну а системные аналитики анализируют именно системы, даже если это кому-то кажется неправильным. Специализация на задачах бизнеса для системного аналитика возможна, а вот переход на анализ сложных систем при помощи системного подхода для бизнес-аналитика будет сложным.
Смешивание терминов и придание им новых смыслов, отличающихся от первоначальных, есть неизбежное следствие движения в сторону прикладного упрощения, свойственного в частности бизнесу.
Системный аналитик занимается анализом систем. Вроде бы масло масляное, но если мы уточним, что такое система, что всё встанет на место.
Бизнес - это система. Компьютер - это тоже система. Вселенная - тоже система. Системы бывают вложенными, связанными, структурированными и т.д. Это всё слова из системного анализа. Им и занимается системный аналитик. И поэтому у него системное мышление (вы ведь слышали о таком?).
А бизнес-аналитик, это тот, кто разбирается в бизнесе, но с системным мышлением у него не очень. То есть системный - более абстрактный, более высокоуровневый. Но при этом в конкретном бизнесе может ничего не понимать.
Проблема не в инстансах, а в подключенных клиентах. В том же твиттере в каждый момент открыты тысячи сессий. Им всем придётся умереть.
Повторю из статьи - там разный алгоритм. В монолите некуда переключатьcя. А в микросервисе есть.
О ком знает микросервис - зависит от архитектора (о чём опять же было написано). А сама необходимость введения шины нам говорит лишь об одном - квадратичный рост является проблемой и один из способов борьбы - шина.
Вносимая асинхронность с вами несогласна. Есть и другие специфические моменты.
Если вы имеете в виду внешние интерфейсы, то да, они мало меняются. Но зачем же забывать о создании тысячи внутренних?
Если вы здесь имеете в виду мониторинг внутренних интерфейсов, то на тысячу сервисов нам потребуется тысяча описаний. Даже если они выполняются один раз. Сравните с отсутствием потребности в тысяче описаний для альтернативы.
А здесь вы уже вышли за рамки аргументированных возражений, и потому я оставлю дальнейшее без комментариев.
Кое-что знаю. Но да, о Твиттере - только из интернета. Оттуда же про 100 000 серверов, и про десяток тысяч работников, ну и про остальное. Остальное как раз сильно намекает на то, что видел сам лично.