Полезный материал, написано понятным языком - спасибо за публикацию. Мемасов имхо многовато, девять штук - это уже перебор, особенно с учетом того что и без них читается отлично
Пробовал: они позволяют сделать кастомную модель на основании предзагруженных треков. Для хорошего результата просит 24 трека и только те, на которые у вас “есть права”, то есть практически никакие. Это вкупе с Max Mode дало результат несколько лучше, но до уровня 4.5 все еще далеко
Их модель v4.5 была последняя, которая давала хорошие результаты с запоминающимся мотивом. Что v5, что тем более v6 - выдает просто бренчание, как бог на душу положит
И какое решение они предлагают? Запретить или уничтожить ИИ уже не получится, как и ядерное оружие - отказ ставит страну в заведомо проигрышное положение. Видимо, как и в разработке, нужно не противопоставлять себя ИИ, а пользоваться им как инструментом
Сам по себе проект любопытный, но с используемой вами терминологией я не согласен. JSON - это формат хранения данных: он не может быть “вычисляемым” или “считать сам себя”. Вычислениями занимается ваш движок формул, который просто хранит данные в виде JSON, и, насколько я понял, поддерживает не произвольный JSON, а один конкретный формат - массив структур. Если движок написан как следует, то не должно составить огромного труда добавить в него поддержку других форматов хранения, будь то XML, или CSV, или что либо еще.
Неопытный вайбкодер может создать приложение, где все пароли пользователей хранятся в открытом виде.
Для любой приличной LLM хранение паролей в открытом виде - это категорически недопустимый подход. Сама по себе она такое не предложит и даже будет активно отговаривать пользователя, поэтому сделать такое “по неопытности” перестало быть возможным - только по злому умыслу
Не для того деды воевали, чтобы кто-то потом сознательно поддерживал сайт под IE6 в 2026 году! Ну а если серьезно, то сделано классно и целеустремленность автора впечатляет
Но какой смысл? Запилить такое вручную еще было бы удивительно, а так, для ИИ реализовать давно известный алгоритм на полном по Тюрингу языке не особо сложно. И сколько времени занимает генерация одного кадра?
Окей, классно, но как это сделать? Я ждал, что автор не просто подсветит проблему, а покажет конкретный пример ее решения, но есть ощущение, что это далеко не всегда возможно. Если у нас объекты появляются или скрываются в результате анимации, они в какой-то момент неизбежно будут обрезаны, или замылены, или сжаты. Вещи, красивые в движении, не всегда красивы в статике (и наоборот), в частности человеческая мимика.
код обмазанный unsafe чуть меньше, чем полностью, будет быстрее
Во-первых, это не факт. Использование unsafe может мешать JIT проводить оптимизации. Во-вторых, если код густо обмазан unsafe, есть подозрение что выбор C# как языка или .NET как платформы для этого проекта был ошибочным.
Если судить по бенчмаркам Techempower, нельзя сказать, что джава заметно отстает от дотнета - скорее даже наоборот. Получается, там придумали, как это сделать достаточно оптимизированно, не перекладывая низкоуровневые концепции типа ref/value типов на разработчика. За это им респект
А версия no sql была без ef? Как бы получается, что вопросы эти касаются именно ef. Грубо говоря, для get-by-id - если в первой реализации вы не трекали изменения, значит во второй используете as-no-tracking
Да, изначально была самопальная реализация репозитория. Разумеется, можно было бы везде использовать AsNoTracking, но это противоречит принципам EF и приводит к неоптимальному коду, о чем я говорил выше: придется создавать контекст отдельно на каждую операцию, явно прикреплять к нему объект и т.д.
чистый репозиторий + unit of work дает больше гибкости, чем orm
EF сам по себе уже предоставляет эти абстракции: DbContext = Unit of work, DbSet<T> = Repository.
если был включен трекинг - метод update вырождается до вызова save changes
Верно - в таком контексте метод update вообще не имеет смысла, потому что обновление состояния происходит при изменении любого свойства (в том числе произвольного другого объекта, входящего в отслеживаемый граф)
Проблемы в любом случае будут, просто потому что перевести нетривиальный проект с одной базы на другую - это само по себе сложная инженерная задача, вне зависимости от используемой методологии, DDD или что угодно еще. Репозиторий позволяет разве что упростить миграцию в одном слое за счет усложнения другого: условно, логика приложения переезжает вообще без изменений, зато на слое доступа к данным теперь творится ад. Во многих случаях это оправдано, но нужно учесть, что некоторые проблемы (в частности с производительностью) с такими ограничениями становятся вообще нерешаемыми, поэтому менять интерфейс в любом случае придется
пишем новую реализацю репозитория, подставляем в алиас новый репозиторий и все
репозиторий явно не самый сложный паттерн
Темболее что это супер легко я не писал.
Судя по вашему вопросу в отдельной ветке про “маппинг для IQueryable” я могу сделать вывод, что вы вообще не имеете никакого представления о C# \ EF, однако решили поучаствовать в дискуссии, цитируя прописные истины. А как только я предложил обсудить вопрос по существу, запас тотчас иссяк и началось - “вопрос недостаточно конкретный”, “я не я и лошадь не моя” и т.д… Жаль, что так получилось.
Так вы же выше утверждаете, что всё очень просто, и если не получается сделать красиво - это просто skill issue. Вот я вам пример задачи привожу, минимальный и конкретный: как бы вы в этом случае сделали красиво? Только по существу, пожалуйста, а не цитаты абстрактных определений из книг
Окей, вот конкретный пример. У нас был репозиторий примерно такого вида, когда первая версия проекта работала поверх CosmosDB:
interface IRepository<T>
{
T GetById(int id);
void Remove(int id);
void Update(int id, T value);
}
Все очень просто: взял запись, поправил, сохранил. С NoSQL отлично работает. Дальше пытаемся переехать на SQL + EF, и сразу возникают вопросы:
Внутри GetById нужно делать AsTracking или AsNoTracking? Оба варианта имеют проблемы с производительностью, третий вариант “выставить флаг наружу” нарушает абстракцию
Remove должен вызывать ExecuteDelete (быстро, но ломает стейт) или SaveChanges (требует подгрузки, может применить другие изменения)?
Нужно поменять две сущности вместе, атомарно, в одной транзакции. В интерфейсе такого нет - не было нужно, база не умеет и т.д., что делать? Нарушить абстракцию и использовать транзакции, или писать саги-реверты по старинке с горой бойлерплейта?
И это только то, что пришло в голову, на двух достаточно хорошо известных технологиях. А если через два года потребуется переехать на что-то еще более экзотическое?
Полезный материал, написано понятным языком - спасибо за публикацию. Мемасов имхо многовато, девять штук - это уже перебор, особенно с учетом того что и без них читается отлично
Если бы это было хотя бы приблизительно в пределах моих возможностей, мне бы не нужен был Suno
Пробовал: они позволяют сделать кастомную модель на основании предзагруженных треков. Для хорошего результата просит 24 трека и только те, на которые у вас “есть права”, то есть практически никакие. Это вкупе с Max Mode дало результат несколько лучше, но до уровня 4.5 все еще далеко
Их модель v4.5 была последняя, которая давала хорошие результаты с запоминающимся мотивом. Что v5, что тем более v6 - выдает просто бренчание, как бог на душу положит
И какое решение они предлагают? Запретить или уничтожить ИИ уже не получится, как и ядерное оружие - отказ ставит страну в заведомо проигрышное положение. Видимо, как и в разработке, нужно не противопоставлять себя ИИ, а пользоваться им как инструментом
Сам по себе проект любопытный, но с используемой вами терминологией я не согласен. JSON - это формат хранения данных: он не может быть “вычисляемым” или “считать сам себя”. Вычислениями занимается ваш движок формул, который просто хранит данные в виде JSON, и, насколько я понял, поддерживает не произвольный JSON, а один конкретный формат - массив структур. Если движок написан как следует, то не должно составить огромного труда добавить в него поддержку других форматов хранения, будь то XML, или CSV, или что либо еще.
Для любой приличной LLM хранение паролей в открытом виде - это категорически недопустимый подход. Сама по себе она такое не предложит и даже будет активно отговаривать пользователя, поэтому сделать такое “по неопытности” перестало быть возможным - только по злому умыслу
И сколько человек им пользуется?
Не для того деды воевали, чтобы кто-то потом сознательно поддерживал сайт под IE6 в 2026 году! Ну а если серьезно, то сделано классно и целеустремленность автора впечатляет
Это не чистый SQL, а диалект ClickHouse. Даже в readme написано, что они пытались запускать на других базах и оно не работает
Но какой смысл? Запилить такое вручную еще было бы удивительно, а так, для ИИ реализовать давно известный алгоритм на полном по Тюрингу языке не особо сложно. И сколько времени занимает генерация одного кадра?
Значит продадут неофициально, со скидкой, каким-нибудь китайцам - не выкидывать же партию
Окей, классно, но как это сделать? Я ждал, что автор не просто подсветит проблему, а покажет конкретный пример ее решения, но есть ощущение, что это далеко не всегда возможно. Если у нас объекты появляются или скрываются в результате анимации, они в какой-то момент неизбежно будут обрезаны, или замылены, или сжаты. Вещи, красивые в движении, не всегда красивы в статике (и наоборот), в частности человеческая мимика.
Во-первых, это не факт. Использование unsafe может мешать JIT проводить оптимизации. Во-вторых, если код густо обмазан unsafe, есть подозрение что выбор C# как языка или .NET как платформы для этого проекта был ошибочным.
Если судить по бенчмаркам Techempower, нельзя сказать, что джава заметно отстает от дотнета - скорее даже наоборот. Получается, там придумали, как это сделать достаточно оптимизированно, не перекладывая низкоуровневые концепции типа ref/value типов на разработчика. За это им респект
Отвечу сразу на оба комментария:
Да, изначально была самопальная реализация репозитория. Разумеется, можно было бы везде использовать
AsNoTracking, но это противоречит принципам EF и приводит к неоптимальному коду, о чем я говорил выше: придется создавать контекст отдельно на каждую операцию, явно прикреплять к нему объект и т.д.EF сам по себе уже предоставляет эти абстракции:
DbContext= Unit of work,DbSet<T>= Repository.Верно - в таком контексте метод update вообще не имеет смысла, потому что обновление состояния происходит при изменении любого свойства (в том числе произвольного другого объекта, входящего в отслеживаемый граф)
Проблемы в любом случае будут, просто потому что перевести нетривиальный проект с одной базы на другую - это само по себе сложная инженерная задача, вне зависимости от используемой методологии, DDD или что угодно еще. Репозиторий позволяет разве что упростить миграцию в одном слое за счет усложнения другого: условно, логика приложения переезжает вообще без изменений, зато на слое доступа к данным теперь творится ад. Во многих случаях это оправдано, но нужно учесть, что некоторые проблемы (в частности с производительностью) с такими ограничениями становятся вообще нерешаемыми, поэтому менять интерфейс в любом случае придется
Судя по вашему вопросу в отдельной ветке про “маппинг для IQueryable” я могу сделать вывод, что вы вообще не имеете никакого представления о C# \ EF, однако решили поучаствовать в дискуссии, цитируя прописные истины. А как только я предложил обсудить вопрос по существу, запас тотчас иссяк и началось - “вопрос недостаточно конкретный”, “я не я и лошадь не моя” и т.д… Жаль, что так получилось.
Так вы же выше утверждаете, что всё очень просто, и если не получается сделать красиво - это просто skill issue. Вот я вам пример задачи привожу, минимальный и конкретный: как бы вы в этом случае сделали красиво? Только по существу, пожалуйста, а не цитаты абстрактных определений из книг
Окей, вот конкретный пример. У нас был репозиторий примерно такого вида, когда первая версия проекта работала поверх CosmosDB:
Все очень просто: взял запись, поправил, сохранил. С NoSQL отлично работает. Дальше пытаемся переехать на SQL + EF, и сразу возникают вопросы:
Внутри
GetByIdнужно делатьAsTrackingилиAsNoTracking? Оба варианта имеют проблемы с производительностью, третий вариант “выставить флаг наружу” нарушает абстракциюRemoveдолжен вызыватьExecuteDelete(быстро, но ломает стейт) илиSaveChanges(требует подгрузки, может применить другие изменения)?Нужно поменять две сущности вместе, атомарно, в одной транзакции. В интерфейсе такого нет - не было нужно, база не умеет и т.д., что делать? Нарушить абстракцию и использовать транзакции, или писать саги-реверты по старинке с горой бойлерплейта?
И это только то, что пришло в голову, на двух достаточно хорошо известных технологиях. А если через два года потребуется переехать на что-то еще более экзотическое?