Очень просто - наука предлагает выбрать приоритеты. По научному - критерии оптимизации. Если у вас нет приоритетов, тогда вы обречены на бессилие. Но если приоритеты есть, то именно наука вам поможет. Только наука.
Вы путаете идеологию, сегодняшнее состояние общества, и в добавок много чего ещё.
Идеология "капитализм" предполагает одно единственное средство самореализации - наращивание капитала. Отсюда следствие - нет у бизнесов других путей, кроме накопления денег.
Идеология "коммунизм" предполагает что-то ещё (здесь требуется уточнение), но на основе уточнённого понимания предложения автоматически растёт следствие о задачах бизнесов или чего там ещё будет разрешено.
Процветание человечества - суть лозунг, то есть пустота, если вы не готовы наполнять её идеологией, а за ней и теорией, обосновывающей идеологию.
Есть часть науки, отвечающая за синтез. Она отвечает на вопрос "как правильно". И хотя это больше инженерная составляющая, но именно наука придумала и разжевала инженерам все необходимые методики синтеза.
Я кратко посмотрел, логично - поворачиваем систему и смотрим плюс или минус по координате Y у точки.
Но это всё беллетристика, потому что сначала было "не все абстракции полезны", потом возник "поворот", потом перешли к точке над вектором (многоугольником и т.д.). То есть погружение вдаль от абстрактного начала привело куда-то в абсолютные частности, которые непонятно как связаны с исходным тезисом.
Попробуйте забыть про "моё решение" и все исключительно психологические моменты, связанные с его обоснованием. Это всё лирика, если нет связи с исходным посылом.
Какие абстракции вредны и какие полезны для описания операции "поворот"? Так, скорее всего, мы будем ближе к отправной точке.
Правильно ли я понял, что на самом деле бизнесу просто был нужен график ввода в эксплуатацию, а всё остальное - местный фольклор и эмоциональное восприятие (лошади с толкучками)?
И почему время ввода в эксплуатацию большое? Каков процент ручных тестов?
Стоит задать аксиомы. Можно использовать комплексные числа? Можно синусы? Можно углы?
Началось всё с поворота без тригонометрии и комплексных чисел. Поворот выполняется в пространстве. Пространство описывается, в том числе, векторами (векторное пространство), но это не единственный способ описания. Смысл поворота в любом пространстве задаётся авторами. Либо нужно создать пространство, где поворот является его основой (аксиомой, порождающей операцией), но опять смысл задаётся автором.
Вы в итоге всё равно возвращаетесь к смыслу, а не к математике. Поэтому и важно задать ограничения, в которых смысл определён. Например - минимум операций (вычислительная сложность) - это ограничение по разному может выглядеть для разных определений пространства. Хотя вполне возможно, что после ряда преобразований, не выходя за рамки аксиом, определяющих выбранное пространство, мы получим тот же набор операций, то есть выполним ограничение на минимум действий сразу в нескольких пространствах. Отсюда спор о матрицах против комплексных чисел становится бессмысленным, если в обоих случаях мы можем получить один и тот же результат (в рамках одних ограничений).
С другой стороны, скорее всего, вами двигала какая-то дополнительная мысль, которую мы не знаем. Начать стоит именно с неё, ибо она - суть то самое ограничение.
Могу предположить, что вы искали простоту, но тогда требуется определение простоты. Минимум операций - одно из определений. Вывод о бессмысленности сравнения двух подходов можно доказать, найдя преобразования, сводящие набор операций к указанному минимуму в обоих случаях. Сложнее доказать, что в каком-то из случаев минимум недостижим.
В общем - начинайте от основ. В математике это аксиомы. Без них спор будет гулять по неведомым и бессмысленным траекториям, пока спорщики всё равно не вернутся к мысли об аксиомах.
Если мы продолжим использовать эти структуры достаточно часто, то привыкнем к ним
В этом проблема. Достаточно часто нужно себя заставлять делать то, что занимает много времени. За это время можно много раз решить поставленную задачу. В реальном приложении можно, конечно, пытаться искать способы применения сложных преобразований, но чаще всего это ведёт опять к потере времени. Возможно в итоге, когда наизусть выучим все задействованные законы используемых преобразований, мы начнём видеть свет в ряде случаев, но опять же - это не массовые проблемы, это меньшая часть.
Итого - ради возможной выгоды в редких случаях нужно тратить много времени во многих случаях. И так, пока не наступит просветление. Возможно в бесконечном цикле. То есть без гарантий.
Хотя да, что-то в этом есть, но "что-то" есть и в альтернативных подходах. Может им и уделить то самое время, которое требуется на "использовать эти структуры достаточно часто"?
А с другой стороны над нами стоят сроки. Вот и выбираем локальный оптимум.
Необходимо обеспечить высокую скорость поставки изменений. Очень высокую: утром и в обед могут быть противоречащие друг другу задачи.
Процессы разработки должны быть не просто гибкими, а гибчайшими, потому что нужно соответствовать вызовам бизнеса.
Часто приходится экономить на важном: на людях, серверах, софте.
Нужно постоянно помнить о выдвигаемых к продукту требованиях и соответствовать заявленному MVP во всём многообразии, включая любые внезапные требования. Например, анимацию иконок.
Почему они ложные? Очень просто - требующие хотят, что бы предел прочности материала был выше, чем написано в справочнике. Ну вот так их бизнесу нужно. Или ещё вариант - вот так хотят наши клиенты. А на самом деле - вот так хочет хозяин бизнеса, потому что у него нет денег на оборудование, соответствующее справочнику по сопромату. И поэтому хозяин хочет выкрутиться за счёт конструктора, заставить его сделать изделие, предел прочности в котором обязательно будет превышен. Понятно, что изделие в итоге сломается. Ну и что? Зато хозяин успеет продать несколько штук и обогатится.
Я понимаю желание заработать много денег (кто бы в этом мире его не понимал?), но я не понимаю упорного стремления забороть законы физики. Хотя да, слово "хочу" никак не соотносится ни с какими законами, кроме законов хотения.
Либо бизнес станет реалистом, либо ваш стартап лопнет. И вас, скорее всего, посадят. Зачем до этого доводить?
Физически шарды логических таблиц - это как правило разные таблицы
Не надо ходить этой скользкой дорожкой. Вы про микросервисы или про внутреннее устройство БД? Если про первое, то БД к ним никакого отношения не имеет, вместе с её внутренностями.
Важно получить обоснование - зачем вам понадобились микросервисы. Вы пока ни одного приемлемого варианта не озвучили, только переводите стрелки на БД и прочие рассуждения.
Ну либо всё же признайте - вам сказано "внедрить", а зачем - не важно. Ну вы и внедряете. Можно даже как-то политкорректно, вроде "у нас решили перейти на микросервисы, потому что очень умные люди очень много рассказывали про важность такого перехода".
Понятно, что с переходом на микросервисы у вас появилось много неожиданных проблем, но разве ради неожиданных проблем всё это затевалось? Как минимум, в тексте я не обнаружил указания на преимущества вашего решения, то есть пока всё было исключительно ради проблем.
обработка информации об остатках совершенно не требует одной базы и одной таблицы
А потом сами пишете:
шардировать таблицу с остатками например по подразделениям
То есть вы не ушли от одной БД и одной таблицы.
на самом деле эффект от МСА будет уже тогда, когда мы сможем собрать все бизнес-функции по работе с товарным запасом в одном микросервисе, отделив их от других функций, связанных с продуктами
Это называется "разделить по компонентам". Компонент может быть связан с другими через HTTP, и может общаться напрямую внутри приложения. Наличие компонента никак не зависит от микросервисов - и с ними и без них он будет. А вот вносимая микросервисами задержка при коммуникации будет лишь в случае принятия концепции микросервисов. Добавьте к этому сложность оркестровки зоопарка сервисов.
Я в целом не против разделения ПО на компоненты, но считаю, что такое деление должно быть обосновано, особенно, если за ним следует уменьшение эффективности за счёт появления прямых и косвенных дополнительных задач, как мы видим в случае с микросервисами.
Возможно, вам было бы проще, если бы вы не приводили примеры микросервисов. Просто принято решение - перейти. А обоснование остаётся за скобками. Это паллиатив, конечно, но так вы избежите многих споров.
Интерпретация есть внематематическое действие. Математике нужны аксиомы, множества, операции. Где в этой троице интерпретации?
Поворот при возведении в квадрат i является геометрической интерпретацией. Для введения в математику такая операция требует указания перехода от геометрии к комплексным числам. Но даже представив такое отображение вы будете противоречить сами себе, ведь вы потребовали "без тригонометрии и комплексных чисел".
Задайте какую-то основу, затем задайте отображение из неё на геометрию, так получите углы, а без углов все преобразования будут лишь наборами чисел, каким-либо строгим образом не связанным с понятием "поворот", которое всегда предполагает наличие угла.
В тексте приведены некорректные примеры задач, требующих перехода на микросервисы.
Всплеск продаж
Видеонаблюдение
Первый пункт никак не побеждается разбиением системы на запчасти, взаимодействующие через HTTP или даже что-то доморощенное. Всегда останется задача проверки остатков по позициям, что предполагает одну БД и одну таблицу в ней.
Второй пункт - вообще никак не связан с микросервисами, поскольку это всего лишь распараллеливание обработки на абсолютно одинаковых обработчиках.
То есть с самого начала текста ставится ложная задача - перейдём на микросервисы лишь потому, что автору кажется, что микросервисы чем-то помогут, хотя на самом деле в приведённых задачах они не помогут ничем.
Ве́кторное простра́нство (лине́йное пространство) — математическая структура, представляющая собой набор элементов, называемых векторами, для которых определены операции сложения друг с другом и умножения на число — скаляр
Оттуда же:
Эти операции подчинены восьми аксиомам
Итого:
Определение операции "поворот" в списке допустимых отсутствует.
Но вы можете сузить толкование математической структуры добавкой вашего определения операции "поворот" (сузить в плане уменьшения количества переходов между элементами множества посредством введения новых ограничений (аксиом)).
Любой математический инструмент опирается на набор аксиом. Линейные преобразования на то и линейны, что бы не выходить за предписанные рамки.
Или по другому - вы задались не тем вопросом. Или выбрали не тот инструмент.
Правильный подход - пояснить, зачем вам вообще понадобилось вдруг исключить тригонометрию и комплексные числа.
Напишите хотя бы просто обзор той книги, где активно используются решётки. По ходу обзора станет видно, что именно решётки дают нам в контексте анализа программ. Затем это нечто можно слегка допилить своими домыслами, чем ещё более расширить понимание полезности закономерностей, выведенных для решёток.
Хотя я вполне допускаю, что автор той книги просто использовал привычную ему терминологию, не привнеся в собственно анализ ничего полезного из общей алгебры.
Очень просто - наука предлагает выбрать приоритеты. По научному - критерии оптимизации. Если у вас нет приоритетов, тогда вы обречены на бессилие. Но если приоритеты есть, то именно наука вам поможет. Только наука.
Вы путаете идеологию, сегодняшнее состояние общества, и в добавок много чего ещё.
Идеология "капитализм" предполагает одно единственное средство самореализации - наращивание капитала. Отсюда следствие - нет у бизнесов других путей, кроме накопления денег.
Идеология "коммунизм" предполагает что-то ещё (здесь требуется уточнение), но на основе уточнённого понимания предложения автоматически растёт следствие о задачах бизнесов или чего там ещё будет разрешено.
Процветание человечества - суть лозунг, то есть пустота, если вы не готовы наполнять её идеологией, а за ней и теорией, обосновывающей идеологию.
Человек - набор клеток, взаимно достигающих некую цель, задаваемую мозгом.
Компания - набор человеков, взаимно достигающих некую цель, задаваемую мозгом хозяина.
Чтобы что-то реально поменять нужно сменить идеологию. Остальное приложится само.
Есть часть науки, отвечающая за синтез. Она отвечает на вопрос "как правильно". И хотя это больше инженерная составляющая, но именно наука придумала и разжевала инженерам все необходимые методики синтеза.
Я кратко посмотрел, логично - поворачиваем систему и смотрим плюс или минус по координате Y у точки.
Но это всё беллетристика, потому что сначала было "не все абстракции полезны", потом возник "поворот", потом перешли к точке над вектором (многоугольником и т.д.). То есть погружение вдаль от абстрактного начала привело куда-то в абсолютные частности, которые непонятно как связаны с исходным тезисом.
Попробуйте забыть про "моё решение" и все исключительно психологические моменты, связанные с его обоснованием. Это всё лирика, если нет связи с исходным посылом.
Какие абстракции вредны и какие полезны для описания операции "поворот"? Так, скорее всего, мы будем ближе к отправной точке.
Правильно ли я понял, что на самом деле бизнесу просто был нужен график ввода в эксплуатацию, а всё остальное - местный фольклор и эмоциональное восприятие (лошади с толкучками)?
И почему время ввода в эксплуатацию большое? Каков процент ручных тестов?
Стоит задать аксиомы. Можно использовать комплексные числа? Можно синусы? Можно углы?
Началось всё с поворота без тригонометрии и комплексных чисел. Поворот выполняется в пространстве. Пространство описывается, в том числе, векторами (векторное пространство), но это не единственный способ описания. Смысл поворота в любом пространстве задаётся авторами. Либо нужно создать пространство, где поворот является его основой (аксиомой, порождающей операцией), но опять смысл задаётся автором.
Вы в итоге всё равно возвращаетесь к смыслу, а не к математике. Поэтому и важно задать ограничения, в которых смысл определён. Например - минимум операций (вычислительная сложность) - это ограничение по разному может выглядеть для разных определений пространства. Хотя вполне возможно, что после ряда преобразований, не выходя за рамки аксиом, определяющих выбранное пространство, мы получим тот же набор операций, то есть выполним ограничение на минимум действий сразу в нескольких пространствах. Отсюда спор о матрицах против комплексных чисел становится бессмысленным, если в обоих случаях мы можем получить один и тот же результат (в рамках одних ограничений).
С другой стороны, скорее всего, вами двигала какая-то дополнительная мысль, которую мы не знаем. Начать стоит именно с неё, ибо она - суть то самое ограничение.
Могу предположить, что вы искали простоту, но тогда требуется определение простоты. Минимум операций - одно из определений. Вывод о бессмысленности сравнения двух подходов можно доказать, найдя преобразования, сводящие набор операций к указанному минимуму в обоих случаях. Сложнее доказать, что в каком-то из случаев минимум недостижим.
В общем - начинайте от основ. В математике это аксиомы. Без них спор будет гулять по неведомым и бессмысленным траекториям, пока спорщики всё равно не вернутся к мысли об аксиомах.
В этом проблема. Достаточно часто нужно себя заставлять делать то, что занимает много времени. За это время можно много раз решить поставленную задачу. В реальном приложении можно, конечно, пытаться искать способы применения сложных преобразований, но чаще всего это ведёт опять к потере времени. Возможно в итоге, когда наизусть выучим все задействованные законы используемых преобразований, мы начнём видеть свет в ряде случаев, но опять же - это не массовые проблемы, это меньшая часть.
Итого - ради возможной выгоды в редких случаях нужно тратить много времени во многих случаях. И так, пока не наступит просветление. Возможно в бесконечном цикле. То есть без гарантий.
Хотя да, что-то в этом есть, но "что-то" есть и в альтернативных подходах. Может им и уделить то самое время, которое требуется на "использовать эти структуры достаточно часто"?
А с другой стороны над нами стоят сроки. Вот и выбираем локальный оптимум.
Эта операция там не определена. Так точнее.
Спасибо за признание. Не буду больше приставать :)
Автор приводит ряд ложных требований:
Необходимо обеспечить высокую скорость поставки изменений. Очень высокую: утром и в обед могут быть противоречащие друг другу задачи.
Процессы разработки должны быть не просто гибкими, а гибчайшими, потому что нужно соответствовать вызовам бизнеса.
Часто приходится экономить на важном: на людях, серверах, софте.
Нужно постоянно помнить о выдвигаемых к продукту требованиях и соответствовать заявленному MVP во всём многообразии, включая любые внезапные требования. Например, анимацию иконок.
Почему они ложные? Очень просто - требующие хотят, что бы предел прочности материала был выше, чем написано в справочнике. Ну вот так их бизнесу нужно. Или ещё вариант - вот так хотят наши клиенты. А на самом деле - вот так хочет хозяин бизнеса, потому что у него нет денег на оборудование, соответствующее справочнику по сопромату. И поэтому хозяин хочет выкрутиться за счёт конструктора, заставить его сделать изделие, предел прочности в котором обязательно будет превышен. Понятно, что изделие в итоге сломается. Ну и что? Зато хозяин успеет продать несколько штук и обогатится.
Я понимаю желание заработать много денег (кто бы в этом мире его не понимал?), но я не понимаю упорного стремления забороть законы физики. Хотя да, слово "хочу" никак не соотносится ни с какими законами, кроме законов хотения.
Либо бизнес станет реалистом, либо ваш стартап лопнет. И вас, скорее всего, посадят. Зачем до этого доводить?
Если кто-то использует молоток для забивания шурупов, это не значит, что именно так все и должны делать.
Не надо ходить этой скользкой дорожкой. Вы про микросервисы или про внутреннее устройство БД? Если про первое, то БД к ним никакого отношения не имеет, вместе с её внутренностями.
Важно получить обоснование - зачем вам понадобились микросервисы. Вы пока ни одного приемлемого варианта не озвучили, только переводите стрелки на БД и прочие рассуждения.
Ну либо всё же признайте - вам сказано "внедрить", а зачем - не важно. Ну вы и внедряете. Можно даже как-то политкорректно, вроде "у нас решили перейти на микросервисы, потому что очень умные люди очень много рассказывали про важность такого перехода".
Понятно, что с переходом на микросервисы у вас появилось много неожиданных проблем, но разве ради неожиданных проблем всё это затевалось? Как минимум, в тексте я не обнаружил указания на преимущества вашего решения, то есть пока всё было исключительно ради проблем.
А потом сами пишете:
То есть вы не ушли от одной БД и одной таблицы.
Это называется "разделить по компонентам". Компонент может быть связан с другими через HTTP, и может общаться напрямую внутри приложения. Наличие компонента никак не зависит от микросервисов - и с ними и без них он будет. А вот вносимая микросервисами задержка при коммуникации будет лишь в случае принятия концепции микросервисов. Добавьте к этому сложность оркестровки зоопарка сервисов.
Я в целом не против разделения ПО на компоненты, но считаю, что такое деление должно быть обосновано, особенно, если за ним следует уменьшение эффективности за счёт появления прямых и косвенных дополнительных задач, как мы видим в случае с микросервисами.
Возможно, вам было бы проще, если бы вы не приводили примеры микросервисов. Просто принято решение - перейти. А обоснование остаётся за скобками. Это паллиатив, конечно, но так вы избежите многих споров.
Интерпретация есть внематематическое действие. Математике нужны аксиомы, множества, операции. Где в этой троице интерпретации?
Поворот при возведении в квадрат i является геометрической интерпретацией. Для введения в математику такая операция требует указания перехода от геометрии к комплексным числам. Но даже представив такое отображение вы будете противоречить сами себе, ведь вы потребовали "без тригонометрии и комплексных чисел".
Задайте какую-то основу, затем задайте отображение из неё на геометрию, так получите углы, а без углов все преобразования будут лишь наборами чисел, каким-либо строгим образом не связанным с понятием "поворот", которое всегда предполагает наличие угла.
В тексте приведены некорректные примеры задач, требующих перехода на микросервисы.
Всплеск продаж
Видеонаблюдение
Первый пункт никак не побеждается разбиением системы на запчасти, взаимодействующие через HTTP или даже что-то доморощенное. Всегда останется задача проверки остатков по позициям, что предполагает одну БД и одну таблицу в ней.
Второй пункт - вообще никак не связан с микросервисами, поскольку это всего лишь распараллеливание обработки на абсолютно одинаковых обработчиках.
То есть с самого начала текста ставится ложная задача - перейдём на микросервисы лишь потому, что автору кажется, что микросервисы чем-то помогут, хотя на самом деле в приведённых задачах они не помогут ничем.
Из википедии:
Оттуда же:
Итого:
Определение операции "поворот" в списке допустимых отсутствует.
Но вы можете сузить толкование математической структуры добавкой вашего определения операции "поворот" (сузить в плане уменьшения количества переходов между элементами множества посредством введения новых ограничений (аксиом)).
Любой математический инструмент опирается на набор аксиом. Линейные преобразования на то и линейны, что бы не выходить за предписанные рамки.
Или по другому - вы задались не тем вопросом. Или выбрали не тот инструмент.
Правильный подход - пояснить, зачем вам вообще понадобилось вдруг исключить тригонометрию и комплексные числа.
Напишите хотя бы просто обзор той книги, где активно используются решётки. По ходу обзора станет видно, что именно решётки дают нам в контексте анализа программ. Затем это нечто можно слегка допилить своими домыслами, чем ещё более расширить понимание полезности закономерностей, выведенных для решёток.
Хотя я вполне допускаю, что автор той книги просто использовал привычную ему терминологию, не привнеся в собственно анализ ничего полезного из общей алгебры.