В Evolution ломается периодически получение почты с невнятной ошибкой. Плюс фильтры настолько кривые, что невозможно с ними работать - в итоге пользуюсь веб версией аутлука...
Как показывает практика и болезненный опыт, нельзя давать пользователю прямую дыру в базу... Это неплохо работает при старте проекта, когда непонятно, что надо отдать пользователю, или в каких-то ограниченных ситуациях. В общем и целом - это должно быть запрещено законодательно и за такое желание надо бить по рукам.
Яркий пример реализации динамических фильтров - протокол OData. Почти что прямой sql. Сюда же можно и GraphQL приплести. Но есть и обратная сторона медали: ответственность за то, насколько запрос будет быстрым, ложится на вызывающий код со всеми вытекающими. Кроме того, тестировать это непонятно как - вроде как ответственность на вызывающем коде, но в то же время и внутренние ошибки не исключены. Получается миллион разных комбинаций "входные данные - запрос - результат", некоторые из которых могут быть некорректными, но возможности исправления тут весьма ограничены (запрос то от пользователя). Также любое отклонение от принятой канвы приводит к боли и страданиям: в OData например, не получится так просто прикрутить кэш или собрать данные из двух сервисов.
В общем, моё личное мнение, что для большинства сценариев (включая фильтры во всяких интернет-магазинах) достаточно фильтров наподобие упомянутых [здесь](https://habr.com/ru/articles/848446/#comment_27382348), а в остальных случаях стоит крепко подумать
Есть ещё EmguCV (https://www.emgu.com/wiki/index.php/Main_Page). А то, что предлагает автор... ну мягко говоря, является изобретением велосипеда и не должно применяться в промышленных решениях практически никогда (пожалуй только если не стоит задача интеграции с дремучим легаси без поддержки - тогда придётся подстраиваться). Начинать же новый проект с лютых костылей - это путь в один конец
Если стоит задача связать именно два приложения (а не встроить библиотеку), то есть следующие опции:
любое средство для удалённого вызова (тут можно остановиться на grpc или http) - по сути сразу получаем распределённую систему из коробки, которая может работать и локально тоже
именованные каналы, чистый сокет и т.п. (требует разработки собственного протокола обмена, поэтому сложно, да еще и платформозависимо в общем случае)
обмен через файл (имеет место быть в некоторых сценариях), тогда обычно родительский процесс вызывает дочерний с аргументами вида "пиши сюда", дожидается окончания работы и обрабатывает файл с результатом
Для встраивания нативной библиотеки единственный промышленный путь - это использование PInvoke с маршаллингом типов (https://learn.microsoft.com/ru-ru/dotnet/standard/native-interop/pinvoke). В результате может получиться производительно, но в нетривиальных случаях придётся повозиться. Или, как написано выше, стоит обратить внимание на уже готовые обёртки, которые всю сложность вызова нативного кода прячут внутри
Даже если вычитывать. Иногда генерируются такие выражения, которые обычный человек не будет использовать в реальности. Ну в духе вместо "пойдем вечером в кино" может сгенерироваться "не соблаговолит ли прекрасная леди посетить сеанс кинопоказа сегодня пополудни". Пример утрирован, но мысль, я думаю ясна. Удачные выражения, передающие исходный смысл, никто не будет править. И вот сообщение наполовину наше, а наполовину Гоголя или Толстого. Кажется, что для всяких статистических инструментов это и правда может быть проблемой
Касперский и распознавание лиц... Только на это и будет уходить батарея, на езду не останется ресурсов. Зато безопасно - не может ехать, никого не убьёт. К слову, цифровые двойники не распознаются, как там будет просто с близнецами, никто не знает, также как и что с устойчивостью к атакам предъявлением (когда фотографию или видео показываешь в камеру). Да и в целом всё это напоминает в лучшем случае демонстратор технологий, а в худшем - освоение
Интересно, а наши сервисы типа госуслуг можно зарегать на симкарту, которая меняет второго/третьего хозяина? Или может можно получить доступ к старым аккаунтам? Были же истории с личными кабинетами банков, куда попадали левые люди, купившие ранее использовавшийся номер. Как вообще компании и государства решают данную проблему, которая, похоже, будет становиться только острее?
А расскажите пожалуйста, в чём преимущество перед стандартным парсером из System.Text.Json? Есть ли бенчмарки? Кажется, что даже десятки мегабайт, прочитанные один раз (речь ведь про настройки) не должны стать проблемой
Это зависит от процессов и представления команды, где находится источник правды. Если правдой считать код сервиса, то генерация схемы оттуда приемлема.
Мне все же видится, что schema-First подход более интересен, потому что позволяет развязать команды фронта, бека и тестирования и согласовать API максимально дёшево - всё же yaml поправить гораздо быстрее и дешевле, чем код бекенда. Также такой подход неплохо срабатывает в случае, когда API является внешним - проще создать схему (при её отсутствии) и нагенерить себе по ней клиентов, тестовых заглушек и чего угодно ещё
Но, как обычно, есть нюансы) Например, существующие инструменты генерации северного когда под .net не умеют в minimal API, odata и прочие штуки - генератор придётся писать самим. То же самое с клиентом - если используется библиотека, которая не поддерживается генератором, то попадаешь на разработку собственного инструмента
Во кто-нибудь может объяснить, почему все так в линуксе? Ну не хватает программе возможностей системной библиотеки - положи Альтернативу рядом с ней и используй. Или только хард код-путь? Только из системой папки... Снап вроде бы попытался, но не смог. В Windows проблема более-менее решена, а тут прям 90-е полным ходом
То есть надо изобрести 300 вариантов одного и того же резюме? Ладно ещё сопроводительное письма, хотя тоже на 5 фантазия иссякает, но опыт то как трансформировать
Спасибо за статью. Не так давно читал тут про реализацию s3 хранилища у яндекс. И тут возник вопрос: в не смотрели в сторону партнерство с ними в этой части? Или может быть совместной разработки и опенсорса/продажи решения? С моей колокольни это могло бы дать положительный эффект для всех
В Evolution ломается периодически получение почты с невнятной ошибкой. Плюс фильтры настолько кривые, что невозможно с ними работать - в итоге пользуюсь веб версией аутлука...
Как показывает практика и болезненный опыт, нельзя давать пользователю прямую дыру в базу... Это неплохо работает при старте проекта, когда непонятно, что надо отдать пользователю, или в каких-то ограниченных ситуациях. В общем и целом - это должно быть запрещено законодательно и за такое желание надо бить по рукам.
Яркий пример реализации динамических фильтров - протокол OData. Почти что прямой sql. Сюда же можно и GraphQL приплести. Но есть и обратная сторона медали: ответственность за то, насколько запрос будет быстрым, ложится на вызывающий код со всеми вытекающими. Кроме того, тестировать это непонятно как - вроде как ответственность на вызывающем коде, но в то же время и внутренние ошибки не исключены. Получается миллион разных комбинаций "входные данные - запрос - результат", некоторые из которых могут быть некорректными, но возможности исправления тут весьма ограничены (запрос то от пользователя). Также любое отклонение от принятой канвы приводит к боли и страданиям: в OData например, не получится так просто прикрутить кэш или собрать данные из двух сервисов.
В общем, моё личное мнение, что для большинства сценариев (включая фильтры во всяких интернет-магазинах) достаточно фильтров наподобие упомянутых [здесь](https://habr.com/ru/articles/848446/#comment_27382348), а в остальных случаях стоит крепко подумать
Вот только это windows-only решение. В Linux C++/CLI не завезли и не планируют. Там или PInvoke, или описанные выше решения
Есть ещё EmguCV (https://www.emgu.com/wiki/index.php/Main_Page). А то, что предлагает автор... ну мягко говоря, является изобретением велосипеда и не должно применяться в промышленных решениях практически никогда (пожалуй только если не стоит задача интеграции с дремучим легаси без поддержки - тогда придётся подстраиваться). Начинать же новый проект с лютых костылей - это путь в один конец
Если стоит задача связать именно два приложения (а не встроить библиотеку), то есть следующие опции:
любое средство для удалённого вызова (тут можно остановиться на grpc или http) - по сути сразу получаем распределённую систему из коробки, которая может работать и локально тоже
именованные каналы, чистый сокет и т.п. (требует разработки собственного протокола обмена, поэтому сложно, да еще и платформозависимо в общем случае)
обмен через файл (имеет место быть в некоторых сценариях), тогда обычно родительский процесс вызывает дочерний с аргументами вида "пиши сюда", дожидается окончания работы и обрабатывает файл с результатом
Для встраивания нативной библиотеки единственный промышленный путь - это использование PInvoke с маршаллингом типов (https://learn.microsoft.com/ru-ru/dotnet/standard/native-interop/pinvoke). В результате может получиться производительно, но в нетривиальных случаях придётся повозиться. Или, как написано выше, стоит обратить внимание на уже готовые обёртки, которые всю сложность вызова нативного кода прячут внутри
Даже если вычитывать. Иногда генерируются такие выражения, которые обычный человек не будет использовать в реальности. Ну в духе вместо "пойдем вечером в кино" может сгенерироваться "не соблаговолит ли прекрасная леди посетить сеанс кинопоказа сегодня пополудни". Пример утрирован, но мысль, я думаю ясна. Удачные выражения, передающие исходный смысл, никто не будет править. И вот сообщение наполовину наше, а наполовину Гоголя или Толстого. Кажется, что для всяких статистических инструментов это и правда может быть проблемой
Касперский и распознавание лиц... Только на это и будет уходить батарея, на езду не останется ресурсов. Зато безопасно - не может ехать, никого не убьёт. К слову, цифровые двойники не распознаются, как там будет просто с близнецами, никто не знает, также как и что с устойчивостью к атакам предъявлением (когда фотографию или видео показываешь в камеру). Да и в целом всё это напоминает в лучшем случае демонстратор технологий, а в худшем - освоение
а включенный vpn не помогает в ide обновляться?
Сравнивали ли вы ваш код с популярными Automapper, Mapster и прочими?
Любые плагины из магазина JB
Интересно, а наши сервисы типа госуслуг можно зарегать на симкарту, которая меняет второго/третьего хозяина? Или может можно получить доступ к старым аккаунтам? Были же истории с личными кабинетами банков, куда попадали левые люди, купившие ранее использовавшийся номер. Как вообще компании и государства решают данную проблему, которая, похоже, будет становиться только острее?
А расскажите пожалуйста, в чём преимущество перед стандартным парсером из System.Text.Json? Есть ли бенчмарки? Кажется, что даже десятки мегабайт, прочитанные один раз (речь ведь про настройки) не должны стать проблемой
Выглядит очень неплохо! Подскажите, есть ли возможность работать без контрола и отрендерить график куда-нибудь в svg/png/pdf в бекэнде?
Это зависит от процессов и представления команды, где находится источник правды. Если правдой считать код сервиса, то генерация схемы оттуда приемлема.
Мне все же видится, что schema-First подход более интересен, потому что позволяет развязать команды фронта, бека и тестирования и согласовать API максимально дёшево - всё же yaml поправить гораздо быстрее и дешевле, чем код бекенда. Также такой подход неплохо срабатывает в случае, когда API является внешним - проще создать схему (при её отсутствии) и нагенерить себе по ней клиентов, тестовых заглушек и чего угодно ещё
Но, как обычно, есть нюансы) Например, существующие инструменты генерации северного когда под .net не умеют в minimal API, odata и прочие штуки - генератор придётся писать самим. То же самое с клиентом - если используется библиотека, которая не поддерживается генератором, то попадаешь на разработку собственного инструмента
Соглашусь про снап - но это была попытка, хотя и не очень удачная, решить эту и другие проблемы
Но при всём при том никто не говорит "ой, тут в системной библиотеке нет нужной нам функции, поэтому у нас лапки"
Во кто-нибудь может объяснить, почему все так в линуксе? Ну не хватает программе возможностей системной библиотеки - положи Альтернативу рядом с ней и используй. Или только хард код-путь? Только из системой папки... Снап вроде бы попытался, но не смог. В Windows проблема более-менее решена, а тут прям 90-е полным ходом
Возможно, это эволюционно. Все же кошачьи охотились и охотятся на приматов, а не наоборот
То есть надо изобрести 300 вариантов одного и того же резюме? Ладно ещё сопроводительное письма, хотя тоже на 5 фантазия иссякает, но опыт то как трансформировать
Спасибо за статью. Не так давно читал тут про реализацию s3 хранилища у яндекс. И тут возник вопрос: в не смотрели в сторону партнерство с ними в этой части? Или может быть совместной разработки и опенсорса/продажи решения? С моей колокольни это могло бы дать положительный эффект для всех
И graphql в ту же область. Но odata ближе к sql