Было бы неплохо дать не только ссылку на репозиторий, а написать немного про язык для тех, кто о нем ничего не знает. В частности, описать задачи, в которых программирование на основе узлов и пересылки сообщений выигрывает у чистого Go (или с чем вы сравниваете). Если выигрывает по наглядности\читаемости - нужны примеры листингов со сравнениями, если по производительности - бенчмарки, и т.д.
Оно не стирает указания типов, а забивает их пробелами. Поэтому, наоборот: размер исходника не меняется (следовательно экономии нет), все значимые вещи остаются в точности на своих местах (следовательно source maps не нужны), и все это нужно сугубо для удобства быстрого запуска локально. Для сборки на прод по-прежнему нужен полноценный TS с проверками, минификатор и т.д.
По сути, IOCCC - соревнование компьютерных фокусников, показывающих на Си магические трюки. Принцип работы хорошего фокуса должно быть сложно разгадать
В самом начале сказано, что это игра на двух игроков. Если вы хотите сыграть против компьютера, у этого же автора есть не менее безумный шахматный движок на регулярках, там можно играть против ИИ.
Имхо обобщить получение одного или нескольких элементов - логичный шаг, а вот прилепить туда же длину - нет.
Перегрузка — это подход, когда один модуль или блок кода выполняет больше одной задачи. Например, функция, которая возвращает имя пользователя, его email и государственный налог на добавленную стоимость.
Это очень поверхностная статья. Стоило хотя бы почитать про COBOL в википедии, чтобы не писать, что это "язык для работы с легаси-кодом".
В некоторых языках, индексация начинается с 1
В Visual Basic индексация может начинаться с любого числа. Этот функционал до сих пор доступен в .NET и им можно пользоваться даже из C#, но никто в своем уме этого не делает.
Семантическая разница только в наличии умысла со стороны компании, в котором она конечно же никогда не признается. А для пользователя это фактически одно и то же
Тогда нужно каждый новый метод объявлять с version = {X, LATEST_VERSION}, где X - текущее значение LATEST_VERSION, иначе при добавлении новой версии все равно искать где было version = LATEST_VERSION и править
Да в том-то и дело, что не проще. Я могу понять, когда работа с базой ведется через 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
Было бы неплохо дать не только ссылку на репозиторий, а написать немного про язык для тех, кто о нем ничего не знает. В частности, описать задачи, в которых программирование на основе узлов и пересылки сообщений выигрывает у чистого Go (или с чем вы сравниваете). Если выигрывает по наглядности\читаемости - нужны примеры листингов со сравнениями, если по производительности - бенчмарки, и т.д.
Оно не стирает указания типов, а забивает их пробелами. Поэтому, наоборот: размер исходника не меняется (следовательно экономии нет), все значимые вещи остаются в точности на своих местах (следовательно source maps не нужны), и все это нужно сугубо для удобства быстрого запуска локально. Для сборки на прод по-прежнему нужен полноценный TS с проверками, минификатор и т.д.
По сути, IOCCC - соревнование компьютерных фокусников, показывающих на Си магические трюки. Принцип работы хорошего фокуса должно быть сложно разгадать
В самом начале сказано, что это игра на двух игроков.
Если вы хотите сыграть против компьютера, у этого же автора есть не менее безумный шахматный движок на регулярках, там можно играть против ИИ.
Вы можете запустить ее онлайн, например здесь, просто скопировав исходник:
https://www.onlinegdb.com/online_c_compiler
Выглядеть будет примерно так:
Имхо обобщить получение одного или нескольких элементов - логичный шаг, а вот прилепить туда же длину - нет.
Это очень поверхностная статья. Стоило хотя бы почитать про COBOL в википедии, чтобы не писать, что это "язык для работы с легаси-кодом".
В Visual Basic индексация может начинаться с любого числа. Этот функционал до сих пор доступен в .NET и им можно пользоваться даже из C#, но никто в своем уме этого не делает.
Но все они не подключены к UPS, только у нового NAS есть встроенное резервное питание? Почему?
Любопытный вариант, но странновато держать на резерве только один NAS, а роутер\свич нет. Надеюсь на "каноничный" ответ автора
Выглядит классно, респект за проделанную работу.
Не понял только, какой резон делать встроенные аккумуляторы по сравнению с готовым UPS - просто хотелось попробовать, или есть объективные причины?
Семантическая разница только в наличии умысла со стороны компании, в котором она конечно же никогда не признается. А для пользователя это фактически одно и то же
Это просто готовая нейросетка первый попавшийся исходник зачитывает, или они действительно играют и поют?
Тогда нужно каждый новый метод объявлять с
version = {X, LATEST_VERSION}, где X - текущее значениеLATEST_VERSION, иначе при добавлении новой версии все равно искать где былоversion = LATEST_VERSIONи правитьЕсли вызов
_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