Да в том-то и дело, что не проще. Я могу понять, когда работа с базой ведется через ADO или Dapper - тогда действительно имеет смысл оборачивать ее в DAL и выставлять наружу осмысленные методы, чтобы в бизнес-логике не нужно было конструировать SQL-запросы. Правда, в таком случае со временем в этом DAL появляется миллион методов с тысячей параметров в каждом, и каждая конкретная комбинация используется всего в одном месте, но это вроде как все еще меньшее из зол. Но если мы говорим про LINQ и ORM вида Linq2DB/EF, то это уже абстракция, причем максимально гибкая. Зачем ее оборачивать в еще одну абстракцию?
Ну а что касается интеграционных тестов - они по своей природе медленные, зачастую на несколько порядков. Поэтому чем больше мест получается протестировать без них, тем лучше.
С подходом, когда мы оборачиваем EF в абстракцию и мокаем ее, есть две проблемы. Во-первых, появляется огромное количество бойлерплейта, который утомительно поддерживать. Во-вторых, ощутимая доля настоящей логики оказывается замокана, а следовательно не покрыта тестами.
На моем опыте, самым удобным вариантом оказалось подсунуть EF вместо настоящего провайдера БД провайдер от SQLite InMemory. Они заявляют не 100%, но довольно высокую совместимость с PostgreSQL, как в виде LINQ-запросов, так и в виде голых SQL-запросов. Мелкое оставшееся уже нужно покрывать интеграционными тестами, если это критично.
Так я про это и говорю - в тех случаях, когда в приложении действительно нужно иметь два отдельных контекста, предлагаемый вариант не решает главную проблему отсутствия единой транзакции.
Если оба ваших контекста работают на основе одного и того же DbConnection, то не было смысла разделять их на два (тогда DbSet = IRepository, а DbContext = IUnitOfWork). А если на разных, то вам потребуются распределенные транзакции, которые дотнет поддерживает только на Windows.
Итого - бойлерплейта написали, какую задачу решили непонятно.
Не знаю, попробуйте связаться с автором - у него в профиле указан email, и плагин вроде бы последний раз обновлялся относительно недавно, в 2023 году: https://plugring.farmanager.com/plugin.php
"Встроенная ИИ-функция", работающая через сторонний сервис, перестала быть встроенной по определению. В лучшем случае это интеграция с чем-то, но никак не встроенность. Если вы купите в магазине пылесос "со встроенным источником питания", а в коробке окажется обычный проводной с припиской мелким шрифтом, что "источник питания встроен в ближайшую электростанцию и вам просто нужен шнур, чтобы к нему подключится", вы разве не почувствуете себя обманутым?
Моя претензия в первую очередь к желтому заголовку. Вы намеренно используете по соседству слова "HTML-тег" (что-то очень простое) и "встроенная ИИ-функция" (что-то очень сложное), чтобы на этом контрасте создать иллюзию удивительности и парадоксальности. При прочтении оказывается, что парадокса никакого нет, допущения делают задачу тривиальной, а предназначение статьи по всей видимости только в том, чтобы попиарить вашу библиотеку. Но даже 89 ее потенциальным пользователям, судя по количеству звезд на гитхабе, в качестве готового рецепта она не подойдет, потому что чтобы не светить свой ключ от API, большую часть придется переписать.
Настоящий "HTML-тег со встроенной ИИ-функцией" на самом деле может существовать. Чтобы оправдывать название, работать он должен так: W3C стандартизует новый атрибут, например <textarea ai-actions="summarize rewrite explain"></textarea>, а разработчики браузеров добавляют в них локальную LLM, которая может эти команды выполнять. Я уверен, что в определенный момент что-то подобное появится, и тогда новость была бы сногсшибательной. Но вы написали совсем не про это.
Давайте будем называть вещи своими именами. У вас нет встроенной ИИ-функции, а есть запрос к внешнему сервису. А это не HTML-тег, а кастомный компонент на вашем фреймворке. По сути, вы продемонстрировали только то, что из JS-кода можно отправить HTTP-запрос, и это не выглядит особо удивительным.
Только что специально проверил на айфоне - если слушаешь музыку в беспроводных наушниках и включаешь режим полета, музыка не прерывается. Возможно в других устройствах не так
Во-первых, в "самолетном режиме" отключается только основная антенна, но bluetooth и wifi работают как ни в чем не бывало. Во-вторых, это никак не спасет от детонации по таймеру, альтиметру, или же просто ручной активации смертником.
Ага, то есть вместо того, чтобы улучшить интероп между плюсами и растом, автор предлагает затащить половину раста в сами плюсы. Выглядит как хитрый план по обеспечению безопасности собственной карьеры - после этого и без того запредельная когнитивная сложность языка подскочит еще сильнее, молодежь не захочет его изучать, заменить дедов будет попросту некому - как с COBOL.
устранена проблема, при которой ошибки могли быть допущены в процессе написания кода, но они все равно считались допустимым кодом JavaScript и принимались. Теперь компилятор будет отслеживать и выдавать ошибки, когда сможет синтаксически определить истинную или нулевую проверку
Вообще ничего не понятно. Смысл в том, что в JS некоторые типичные опечатки являются валидным кодом, который при этом делает совсем не то, что хочет пользователь, например:
if(/abc/) { ... } // забыли .test(...)
if(x => 0) { ... } // имелось в виду x >= 0, а получилась лямбда
if(a < foo.bar ?? 100) { ... } // парсится как (a < foo.bar) ?? 100 В этих случаях теперь будут варнинги, что условие всегда истинно. При этом, в случаях типа while(true) варнинга не будет, поскольку это распространенный паттерн.
Также ничего не сказано при киллер-фичу, что у итераторов появились аналогичные массивам методы map, filter, take и т.д.
какие франшизы, на ваш взгляд, являются самыми важными в истории шутеров
Имхо, такие культурно значимые игры как Duke Nukem, Serious Sam, Quake, Unreal Tournament, Crysis, Bioshock, Overwatch и Fortnight стоило упомянуть больше чем одним словом или скриншотом
движок Unreal сегодня является одним из основных в игровой индустрии наравне с Unity, CryEngine и Godot.
Поставить Unreal и Godot в одну линейку - это мощно
Cреда исполнения CPython состоит из компилятора, который преобразует исходный текст в байт-код (который даже можно сохранить в файл .pyc), а также виртуальной машины, которая этот код дальше интерпретирует. Оптимизацию, о которой я говорил выше, было бы вполне уместно делать именно на уровне компилятора, хотя и в ВМ тоже можно
А компилятор питона не может сам оптмизировать x ** y % z до вызова pow(x, y, z) если тот вариант более производительный? Выглядит как элементарная peephole-оптимизация
Если вызов
_auditTransaction.Commit()упадет, что будете делать?Да в том-то и дело, что не проще. Я могу понять, когда работа с базой ведется через ADO или Dapper - тогда действительно имеет смысл оборачивать ее в DAL и выставлять наружу осмысленные методы, чтобы в бизнес-логике не нужно было конструировать SQL-запросы. Правда, в таком случае со временем в этом DAL появляется миллион методов с тысячей параметров в каждом, и каждая конкретная комбинация используется всего в одном месте, но это вроде как все еще меньшее из зол. Но если мы говорим про LINQ и ORM вида Linq2DB/EF, то это уже абстракция, причем максимально гибкая. Зачем ее оборачивать в еще одну абстракцию?
Ну а что касается интеграционных тестов - они по своей природе медленные, зачастую на несколько порядков. Поэтому чем больше мест получается протестировать без них, тем лучше.
С подходом, когда мы оборачиваем EF в абстракцию и мокаем ее, есть две проблемы. Во-первых, появляется огромное количество бойлерплейта, который утомительно поддерживать. Во-вторых, ощутимая доля настоящей логики оказывается замокана, а следовательно не покрыта тестами.
На моем опыте, самым удобным вариантом оказалось подсунуть EF вместо настоящего провайдера БД провайдер от SQLite InMemory. Они заявляют не 100%, но довольно высокую совместимость с PostgreSQL, как в виде LINQ-запросов, так и в виде голых SQL-запросов. Мелкое оставшееся уже нужно покрывать интеграционными тестами, если это критично.
Так я про это и говорю - в тех случаях, когда в приложении действительно нужно иметь два отдельных контекста, предлагаемый вариант не решает главную проблему отсутствия единой транзакции.
Если оба ваших контекста работают на основе одного и того же DbConnection, то не было смысла разделять их на два (тогда DbSet = IRepository, а DbContext = IUnitOfWork). А если на разных, то вам потребуются распределенные транзакции, которые дотнет поддерживает только на Windows.
Итого - бойлерплейта написали, какую задачу решили непонятно.
Не знаю, попробуйте связаться с автором - у него в профиле указан email, и плагин вроде бы последний раз обновлялся относительно недавно, в 2023 году:
https://plugring.farmanager.com/plugin.php
Но ведь ffmpeg, используемый в примере, во много раз больше sqlite, почему для него подходит?
Также было бы интересно посмотреть сравнение по скорости тем же кодом на C, скомпилированным в wasm
"Встроенная ИИ-функция", работающая через сторонний сервис, перестала быть встроенной по определению. В лучшем случае это интеграция с чем-то, но никак не встроенность. Если вы купите в магазине пылесос "со встроенным источником питания", а в коробке окажется обычный проводной с припиской мелким шрифтом, что "источник питания встроен в ближайшую электростанцию и вам просто нужен шнур, чтобы к нему подключится", вы разве не почувствуете себя обманутым?
Моя претензия в первую очередь к желтому заголовку. Вы намеренно используете по соседству слова "HTML-тег" (что-то очень простое) и "встроенная ИИ-функция" (что-то очень сложное), чтобы на этом контрасте создать иллюзию удивительности и парадоксальности. При прочтении оказывается, что парадокса никакого нет, допущения делают задачу тривиальной, а предназначение статьи по всей видимости только в том, чтобы попиарить вашу библиотеку. Но даже 89 ее потенциальным пользователям, судя по количеству звезд на гитхабе, в качестве готового рецепта она не подойдет, потому что чтобы не светить свой ключ от API, большую часть придется переписать.
Настоящий "HTML-тег со встроенной ИИ-функцией" на самом деле может существовать. Чтобы оправдывать название, работать он должен так: W3C стандартизует новый атрибут, например
<textarea ai-actions="summarize rewrite explain"></textarea>, а разработчики браузеров добавляют в них локальную LLM, которая может эти команды выполнять. Я уверен, что в определенный момент что-то подобное появится, и тогда новость была бы сногсшибательной. Но вы написали совсем не про это.Давайте будем называть вещи своими именами. У вас нет встроенной ИИ-функции, а есть запрос к внешнему сервису. А это не HTML-тег, а кастомный компонент на вашем фреймворке. По сути, вы продемонстрировали только то, что из JS-кода можно отправить HTTP-запрос, и это не выглядит особо удивительным.
Только что специально проверил на айфоне - если слушаешь музыку в беспроводных наушниках и включаешь режим полета, музыка не прерывается. Возможно в других устройствах не так
Во-первых, в "самолетном режиме" отключается только основная антенна, но bluetooth и wifi работают как ни в чем не бывало. Во-вторых, это никак не спасет от детонации по таймеру, альтиметру, или же просто ручной активации смертником.
Тут стоит оставить disclaimer, что вы являетесь автором этой библиотеки
Ага, то есть вместо того, чтобы улучшить интероп между плюсами и растом, автор предлагает затащить половину раста в сами плюсы. Выглядит как хитрый план по обеспечению безопасности собственной карьеры - после этого и без того запредельная когнитивная сложность языка подскочит еще сильнее, молодежь не захочет его изучать, заменить дедов будет попросту некому - как с COBOL.
Вообще ничего не понятно. Смысл в том, что в JS некоторые типичные опечатки являются валидным кодом, который при этом делает совсем не то, что хочет пользователь, например:
if(/abc/) { ... } // забыли .test(...)if(x => 0) { ... } // имелось в виду x >= 0, а получилась лямбдаif(a < foo.bar ?? 100) { ... } // парсится как (a < foo.bar) ?? 100В этих случаях теперь будут варнинги, что условие всегда истинно. При этом, в случаях типа
while(true)варнинга не будет, поскольку это распространенный паттерн.Также ничего не сказано при киллер-фичу, что у итераторов появились аналогичные массивам методы
map,filter,takeи т.д.Твой Vue создан, чтобы пронзить небеса!
Имхо, такие культурно значимые игры как Duke Nukem, Serious Sam, Quake, Unreal Tournament, Crysis, Bioshock, Overwatch и Fortnight стоило упомянуть больше чем одним словом или скриншотом
Поставить Unreal и Godot в одну линейку - это мощно
Со словом "теология" как-то справились
Найди 10 отличий от VS Code
Cреда исполнения CPython состоит из компилятора, который преобразует исходный текст в байт-код (который даже можно сохранить в файл
.pyc), а также виртуальной машины, которая этот код дальше интерпретирует. Оптимизацию, о которой я говорил выше, было бы вполне уместно делать именно на уровне компилятора, хотя и в ВМ тоже можноА компилятор питона не может сам оптмизировать
x ** y % zдо вызоваpow(x, y, z)если тот вариант более производительный? Выглядит как элементарная peephole-оптимизация