Все это хорошо, но очень уж абстрактно. Собственно, что нового ваш подход вносит в сравнении с хорошо известными луковой или гексагональной архитектурами? Фактически, вы утверждаете, что "то что склонно меняться не должно зависеть от того что меняться не склонно". Ну так об этом же пишет и "дядушка Боб" в "Чистой архитектуре", когда разбирает дерево зависимостей и указывает что чем ближе к корню дерева находится модуль тем более фундаментальным (то есть стабильным) он должен быть.
Для подзаголовка "практика" в этой статье слишком мало собственно практических примеров. Хотелось бы получить ваши комментарии - как этот подход позволяет справляться с двумя следующими сценариями (примеры взяты из моей практики, детали изменены).
Подсистема справочников. Каждый элемент справочника имеет несколько версий, причем версия имеет дату начала действия и дату окончания действия (или действует бессрочно). Элементы справочника могут ссылаться друг на друга (например "Тип продукта" может ссылаться на "Категория продукта" или "уровень SLA"). Бизнес приносит новое требование - теперь ссылаться не на элемент другого справочника, а на конкретную версию этого элемента. Изменение затрагивает всю подсистему - от БД до API. Как с вашей точки зрения здесь можно было провести декопозицию, основанную на нестабильности?
Другой пример. Сервис, отвечающий за подбор маршрута перевозок. Работал синхронно - получил запрос от фронта, получил несколько маршрутов-кандидатов, выполнил по каждому сбор дополнительной информации, рассчитал цены и т.д., после чего вернул топ-5 маршрутов на фронт для окончательного выбора оператором. Бизнес пришел и сказал "что-то долго это все считает. Давайте сделаем так, чтобы на фронте маршруты появлялись по мере готовности. Вот просчитали мы маршрут - отдаем на фронт и пользователь его сразу видит (идею с топ-5 забыли, будем отображать все) и может сразу выбрать (и остальные тогда можно прекращать считать). То есть бизнес-логика (подбор и расчет маршрута) вообще не изменилась, но из синхронной стала асинхронной. Что потребовало по итогу отрефакторить сервис подбора маршрута достаточно глубоко. Как декомпозиция, основанная на нестабильности, позволила бы облегчить это изменение (и чтобы оно не смотрелось оверинжинирингом в первоначальной версии, мы понятия не имели что тут захочется асинхронную логику, нигде в проекте её на тот момент не было)?
Мой первый компьютер. Учился на нем программировать на BASIC. Очень хотел научиться ассемблеру, чтобы писать игры, но в нашей провинции не нашлось толковых книг по этой теме (как и собственно компилятора ассемблера). Так что осталось это желание нереализованным.
Если работает на Steam Deck, то с протоном вполне дружит. Надо пробовать запустить через Стим, в большинстве случаев оно вполне прилично будет работать, тем более на Unity.
Попробуйте, посмотрите на конкретную модель. По моему опыту - грамматические ошибки вполне себе "прощает". Хотя один раз устроила мне неожиданный "разнос", когда вместо forgive me (прости меня), а написал apologize me (проси у меня прощения).
По моим тестам включение --flashattention сильно замедляет вычисления (особенно заметно на CPU т.к. на видеокарте обычно ограничивает не вычислительная мощность, а скорость обращения к памяти), хоть и сокращает объем потребной видеопамяти. Это имеет смысл, если в результате получается сильно сократить количество слоев, которые будут считаться на CPU (или вообще запихать модель в видеопамять целиком). В противном случае - может получиться даже проигрыш по скорости генерации.
Если скопированы только публичные репозитории (а если скопированы приватные - то вопрос к гитхабу как это стало возможным), причем вместе со всем содержимым, включая README, LICENCE, историей коммитов (и, соответственно, авторами конкретных изменений) - то что здесь нарушено? Публичный статус репозитория означает что его может скопировать любой желающий.
Предложенные вами практики очень напомнили буддийскую медитацию на милосердие и сострадание. Только в буддийской традиции принято начинать с себя, сначала выработать навык по отношению к себе, а затем распространять его вовне, по отношению к другим людям.
Мы, разумеется, можем определить функцию возведения в степень как-то иначе и она не будет обладать теми свойствами, которые я использовал. Но тогда это будет другая функция. Собственно любое обсуждение должно начинаться с определений в которых мы ведем дискуссию.
По мне - так достаточно странная статья. Это доказывается из определения операции возведения в степень. Итак, по определению, a^n = a*a*...*a (n раз). Но тогда a^b*a^c = a*a*...*a (b раз) * a*a*...*a (c раз), что, очевидно означает умножение a само на себя b+c раз. Свойство a^b*a^с = a^(b+c) доказано.
Теперь рассматриваем случай c>b, что приводит к отрицательному показатель степени. Единственный способ избежать противоречия в предыдущей формуле - это определить возведение в отрицательную степень как a^(-b) = 1/a^b
Аналогично, рассматривая случай b=c получаем a^0=1. Потому что любой другой случай приводит к противоречию. Например, мы можем умножить любое ненулевое число на a^0. Тогда a^b*a^0=a^(b+0)=a^b. Из чего следует что a^0=1.
Точно также, по определению операции возведения в степень доказывается свойство (a^b)^c=a^(b*c), что позволяет расширить операцию возвещения в степень на множество рациональных чисел.
Еще один момент. Операция умножения на множестве действительных чисел (кроме нуля) образует группу. Соответственно, для определения a^0 (умножить число само на себя 0 раз) просто напрашивается нулевой элемент группы. То есть единица.
А вот 0^0 - неопределенность т.к. ноль не имеет обратного элемента в группе по умножению.
Откуда я это взял? Исследования медиков. Вот отличная статья про игру, там освещается вопрос и влияния го на мозг.
Или почему так происходит? Наверное потому что го - более многофакторная игра, чем шахматы. Просто считать тактические варианты недостаточно, позицию приходится оценивать как локально, так и всю доску в целом.
Ну вот я ни разу не ментейнер спринга. Однако спрингового кода (именно фреймворка) прочитал более чем достаточно, потому как не всегда документация дает четкий ответ "как это работает?" и "откуда вылез этот баг?". В идеальном мире, разумеется, есть идеальная документация, но в реальном мире разработчики приложений еще как читают код библиотек и фреймворков.
Все это хорошо, но очень уж абстрактно. Собственно, что нового ваш подход вносит в сравнении с хорошо известными луковой или гексагональной архитектурами? Фактически, вы утверждаете, что "то что склонно меняться не должно зависеть от того что меняться не склонно". Ну так об этом же пишет и "дядушка Боб" в "Чистой архитектуре", когда разбирает дерево зависимостей и указывает что чем ближе к корню дерева находится модуль тем более фундаментальным (то есть стабильным) он должен быть.
Для подзаголовка "практика" в этой статье слишком мало собственно практических примеров. Хотелось бы получить ваши комментарии - как этот подход позволяет справляться с двумя следующими сценариями (примеры взяты из моей практики, детали изменены).
Подсистема справочников. Каждый элемент справочника имеет несколько версий, причем версия имеет дату начала действия и дату окончания действия (или действует бессрочно). Элементы справочника могут ссылаться друг на друга (например "Тип продукта" может ссылаться на "Категория продукта" или "уровень SLA"). Бизнес приносит новое требование - теперь ссылаться не на элемент другого справочника, а на конкретную версию этого элемента. Изменение затрагивает всю подсистему - от БД до API. Как с вашей точки зрения здесь можно было провести декопозицию, основанную на нестабильности?
Другой пример. Сервис, отвечающий за подбор маршрута перевозок. Работал синхронно - получил запрос от фронта, получил несколько маршрутов-кандидатов, выполнил по каждому сбор дополнительной информации, рассчитал цены и т.д., после чего вернул топ-5 маршрутов на фронт для окончательного выбора оператором. Бизнес пришел и сказал "что-то долго это все считает. Давайте сделаем так, чтобы на фронте маршруты появлялись по мере готовности. Вот просчитали мы маршрут - отдаем на фронт и пользователь его сразу видит (идею с топ-5 забыли, будем отображать все) и может сразу выбрать (и остальные тогда можно прекращать считать). То есть бизнес-логика (подбор и расчет маршрута) вообще не изменилась, но из синхронной стала асинхронной. Что потребовало по итогу отрефакторить сервис подбора маршрута достаточно глубоко. Как декомпозиция, основанная на нестабильности, позволила бы облегчить это изменение (и чтобы оно не смотрелось оверинжинирингом в первоначальной версии, мы понятия не имели что тут захочется асинхронную логику, нигде в проекте её на тот момент не было)?
Мой первый компьютер. Учился на нем программировать на BASIC. Очень хотел научиться ассемблеру, чтобы писать игры, но в нашей провинции не нашлось толковых книг по этой теме (как и собственно компилятора ассемблера). Так что осталось это желание нереализованным.
А разработчики этого и не скрывали, они прямо говорили что вдохновлялись именно Nether Earth
Если работает на Steam Deck, то с протоном вполне дружит. Надо пробовать запустить через Стим, в большинстве случаев оно вполне прилично будет работать, тем более на Unity.
Так в чем же заключается миф о RAM? Так за счет чего мы получили ускорение, даже если данные не помещаются в кэш? Статья не соответствует заголовку.
Попробуйте, посмотрите на конкретную модель. По моему опыту - грамматические ошибки вполне себе "прощает". Хотя один раз устроила мне неожиданный "разнос", когда вместо forgive me (прости меня), а написал apologize me (проси у меня прощения).
По моим тестам включение --flashattention сильно замедляет вычисления (особенно заметно на CPU т.к. на видеокарте обычно ограничивает не вычислительная мощность, а скорость обращения к памяти), хоть и сокращает объем потребной видеопамяти. Это имеет смысл, если в результате получается сильно сократить количество слоев, которые будут считаться на CPU (или вообще запихать модель в видеопамять целиком). В противном случае - может получиться даже проигрыш по скорости генерации.
По ППС четвертая экономика мира - Россия. Так что комментарий выглядит с двойным дном.
А что помешает ничего не соблюдать и без клонирования репозитория в публичный сервис?
Как бы все лицензии - это про доверие между сторонами и ничего более.
Если скопированы только публичные репозитории (а если скопированы приватные - то вопрос к гитхабу как это стало возможным), причем вместе со всем содержимым, включая README, LICENCE, историей коммитов (и, соответственно, авторами конкретных изменений) - то что здесь нарушено? Публичный статус репозитория означает что его может скопировать любой желающий.
Потому что там есть seed. Если задавать его вместе с промптом - то будете получать идентичные картинки
Предложенные вами практики очень напомнили буддийскую медитацию на милосердие и сострадание. Только в буддийской традиции принято начинать с себя, сначала выработать навык по отношению к себе, а затем распространять его вовне, по отношению к другим людям.
Мы, разумеется, можем определить функцию возведения в степень как-то иначе и она не будет обладать теми свойствами, которые я использовал. Но тогда это будет другая функция. Собственно любое обсуждение должно начинаться с определений в которых мы ведем дискуссию.
Это коммутативность. Она не требуется. А ассоциативность 5^2^3 = (5^2)^3 = 5^(2^3). Что также не выполняется. Поэтому не группа.
Так поэтому и не входит, что не имеет обратного элемента.
По мне - так достаточно странная статья. Это доказывается из определения операции возведения в степень. Итак, по определению, a^n = a*a*...*a (n раз). Но тогда a^b*a^c = a*a*...*a (b раз) * a*a*...*a (c раз), что, очевидно означает умножение a само на себя b+c раз. Свойство a^b*a^с = a^(b+c) доказано.
Аналогично доказывается свойство a^b/a^c = a^(b-c).
Теперь рассматриваем случай c>b, что приводит к отрицательному показатель степени. Единственный способ избежать противоречия в предыдущей формуле - это определить возведение в отрицательную степень как a^(-b) = 1/a^b
Аналогично, рассматривая случай b=c получаем a^0=1. Потому что любой другой случай приводит к противоречию. Например, мы можем умножить любое ненулевое число на a^0. Тогда a^b*a^0=a^(b+0)=a^b. Из чего следует что a^0=1.
Точно также, по определению операции возведения в степень доказывается свойство (a^b)^c=a^(b*c), что позволяет расширить операцию возвещения в степень на множество рациональных чисел.
Еще один момент. Операция умножения на множестве действительных чисел (кроме нуля) образует группу. Соответственно, для определения a^0 (умножить число само на себя 0 раз) просто напрашивается нулевой элемент группы. То есть единица.
А вот 0^0 - неопределенность т.к. ноль не имеет обратного элемента в группе по умножению.
Вроде, наоборот, говорили что хотят сокращать LTS-поддержку ядер. А тут размахнулись на 10 лет.
Откуда я это взял? Исследования медиков. Вот отличная статья про игру, там освещается вопрос и влияния го на мозг.
Или почему так происходит? Наверное потому что го - более многофакторная игра, чем шахматы. Просто считать тактические варианты недостаточно, позицию приходится оценивать как локально, так и всю доску в целом.
Ну вот я ни разу не ментейнер спринга. Однако спрингового кода (именно фреймворка) прочитал более чем достаточно, потому как не всегда документация дает четкий ответ "как это работает?" и "откуда вылез этот баг?". В идеальном мире, разумеется, есть идеальная документация, но в реальном мире разработчики приложений еще как читают код библиотек и фреймворков.
Да, именно так.