Интересно, а наши сервисы типа госуслуг можно зарегать на симкарту, которая меняет второго/третьего хозяина? Или может можно получить доступ к старым аккаунтам? Были же истории с личными кабинетами банков, куда попадали левые люди, купившие ранее использовавшийся номер. Как вообще компании и государства решают данную проблему, которая, похоже, будет становиться только острее?
А расскажите пожалуйста, в чём преимущество перед стандартным парсером из System.Text.Json? Есть ли бенчмарки? Кажется, что даже десятки мегабайт, прочитанные один раз (речь ведь про настройки) не должны стать проблемой
Это зависит от процессов и представления команды, где находится источник правды. Если правдой считать код сервиса, то генерация схемы оттуда приемлема.
Мне все же видится, что schema-First подход более интересен, потому что позволяет развязать команды фронта, бека и тестирования и согласовать API максимально дёшево - всё же yaml поправить гораздо быстрее и дешевле, чем код бекенда. Также такой подход неплохо срабатывает в случае, когда API является внешним - проще создать схему (при её отсутствии) и нагенерить себе по ней клиентов, тестовых заглушек и чего угодно ещё
Но, как обычно, есть нюансы) Например, существующие инструменты генерации северного когда под .net не умеют в minimal API, odata и прочие штуки - генератор придётся писать самим. То же самое с клиентом - если используется библиотека, которая не поддерживается генератором, то попадаешь на разработку собственного инструмента
Во кто-нибудь может объяснить, почему все так в линуксе? Ну не хватает программе возможностей системной библиотеки - положи Альтернативу рядом с ней и используй. Или только хард код-путь? Только из системой папки... Снап вроде бы попытался, но не смог. В Windows проблема более-менее решена, а тут прям 90-е полным ходом
То есть надо изобрести 300 вариантов одного и того же резюме? Ладно ещё сопроводительное письма, хотя тоже на 5 фантазия иссякает, но опыт то как трансформировать
Спасибо за статью. Не так давно читал тут про реализацию s3 хранилища у яндекс. И тут возник вопрос: в не смотрели в сторону партнерство с ними в этой части? Или может быть совместной разработки и опенсорса/продажи решения? С моей колокольни это могло бы дать положительный эффект для всех
Сложно представить такой сценарий в реальности. Обычно передашь везде один и тот же интерфейс ILogger и всё. Если говорить конкретно про логирование, то там можно конфигурацией определить, куда и что писать.
Кажется, вы пытаетесь выстрелить себе в ногу довольно странным и болезненным способом. Если вы хотите, чтобы сервис зависело от конкретной реализации, то положите эту реализацию явно в контейнер и задайте явно зависимость в сервисе. Если сервис зависит от некоторого общего интерфейса, то там может оказаться любая его реализация, и с этим надо жить. Даже если интерфейс имеет одинаковую сигнатуру, но его семантика отличается, то это два разных интерфейса, которые применяются в разных сценариях. Например, у вас есть интерфейс ICommand с методом Execute и есть потребность некоторые команды вызывать определённым единообразным образом через DI. В этом случае целесообразно было бы ввести интерфейс ISpecialCommand с тем же методом Execute и получать все реализации именно этого интерфейса, а не пытаться разобраться, что там за команда прилетела (может и не самый удачный пример с командами, но я думаю, суть ясна)
О да... На этом мы собственно и застопорились при внедрении API First. Если нельзя использовать генератор без напильника, то смысл автогенерации теряется совсем. Видимо придётся писать свои генераторы под свои потребности, потому что то, что позиционируется как официальные инструменты, не работает как надо. К этому добавляется не очень хорошая поддержка многофайловых схем в инструментах, а в одном файле все держать очень не очень
Вот понятия герои и баланс находятся максимально далеко друг от друга. На случайно сненерированных картах баланс невозможен, это не абсолютно симметричные карты турнирного варкрафта
Кажется, что тестовые контейнеры - это ваш выход. Тесты получаются независимые, запускаются в нативном окружении и лишены проблем с инфраструктурой. Всё, что надо сделать разработчику в Windows - включить wsl и поставить docker desktop, в линуксе все из коробки работает
Интересно, а наши сервисы типа госуслуг можно зарегать на симкарту, которая меняет второго/третьего хозяина? Или может можно получить доступ к старым аккаунтам? Были же истории с личными кабинетами банков, куда попадали левые люди, купившие ранее использовавшийся номер. Как вообще компании и государства решают данную проблему, которая, похоже, будет становиться только острее?
А расскажите пожалуйста, в чём преимущество перед стандартным парсером из System.Text.Json? Есть ли бенчмарки? Кажется, что даже десятки мегабайт, прочитанные один раз (речь ведь про настройки) не должны стать проблемой
Выглядит очень неплохо! Подскажите, есть ли возможность работать без контрола и отрендерить график куда-нибудь в svg/png/pdf в бекэнде?
Это зависит от процессов и представления команды, где находится источник правды. Если правдой считать код сервиса, то генерация схемы оттуда приемлема.
Мне все же видится, что schema-First подход более интересен, потому что позволяет развязать команды фронта, бека и тестирования и согласовать API максимально дёшево - всё же yaml поправить гораздо быстрее и дешевле, чем код бекенда. Также такой подход неплохо срабатывает в случае, когда API является внешним - проще создать схему (при её отсутствии) и нагенерить себе по ней клиентов, тестовых заглушек и чего угодно ещё
Но, как обычно, есть нюансы) Например, существующие инструменты генерации северного когда под .net не умеют в minimal API, odata и прочие штуки - генератор придётся писать самим. То же самое с клиентом - если используется библиотека, которая не поддерживается генератором, то попадаешь на разработку собственного инструмента
Соглашусь про снап - но это была попытка, хотя и не очень удачная, решить эту и другие проблемы
Но при всём при том никто не говорит "ой, тут в системной библиотеке нет нужной нам функции, поэтому у нас лапки"
Во кто-нибудь может объяснить, почему все так в линуксе? Ну не хватает программе возможностей системной библиотеки - положи Альтернативу рядом с ней и используй. Или только хард код-путь? Только из системой папки... Снап вроде бы попытался, но не смог. В Windows проблема более-менее решена, а тут прям 90-е полным ходом
Возможно, это эволюционно. Все же кошачьи охотились и охотятся на приматов, а не наоборот
То есть надо изобрести 300 вариантов одного и того же резюме? Ладно ещё сопроводительное письма, хотя тоже на 5 фантазия иссякает, но опыт то как трансформировать
Спасибо за статью. Не так давно читал тут про реализацию s3 хранилища у яндекс. И тут возник вопрос: в не смотрели в сторону партнерство с ними в этой части? Или может быть совместной разработки и опенсорса/продажи решения? С моей колокольни это могло бы дать положительный эффект для всех
И graphql в ту же область. Но odata ближе к sql
Сложно представить такой сценарий в реальности. Обычно передашь везде один и тот же интерфейс ILogger и всё. Если говорить конкретно про логирование, то там можно конфигурацией определить, куда и что писать.
Кажется, вы пытаетесь выстрелить себе в ногу довольно странным и болезненным способом. Если вы хотите, чтобы сервис зависело от конкретной реализации, то положите эту реализацию явно в контейнер и задайте явно зависимость в сервисе. Если сервис зависит от некоторого общего интерфейса, то там может оказаться любая его реализация, и с этим надо жить. Даже если интерфейс имеет одинаковую сигнатуру, но его семантика отличается, то это два разных интерфейса, которые применяются в разных сценариях. Например, у вас есть интерфейс ICommand с методом Execute и есть потребность некоторые команды вызывать определённым единообразным образом через DI. В этом случае целесообразно было бы ввести интерфейс ISpecialCommand с тем же методом Execute и получать все реализации именно этого интерфейса, а не пытаться разобраться, что там за команда прилетела (может и не самый удачный пример с командами, но я думаю, суть ясна)
О да... На этом мы собственно и застопорились при внедрении API First. Если нельзя использовать генератор без напильника, то смысл автогенерации теряется совсем. Видимо придётся писать свои генераторы под свои потребности, потому что то, что позиционируется как официальные инструменты, не работает как надо. К этому добавляется не очень хорошая поддержка многофайловых схем в инструментах, а в одном файле все держать очень не очень
Что, если не секрет, вы нашли в качестве альтернативы? Без сарказма, просто на ум приходит крайне малое количество альтернатив вроде vlc и gstreamer
oneof инструкция корректно поддерживается? Заметил, что всякая дичь генерится для нее
Вот понятия герои и баланс находятся максимально далеко друг от друга. На случайно сненерированных картах баланс невозможен, это не абсолютно симметричные карты турнирного варкрафта
А куда ногой? Проблемы больших организаций примерно одинаковы независимо от того, банк это или что-то
Кажется, что тестовые контейнеры - это ваш выход. Тесты получаются независимые, запускаются в нативном окружении и лишены проблем с инфраструктурой. Всё, что надо сделать разработчику в Windows - включить wsl и поставить docker desktop, в линуксе все из коробки работает
так и гугла с vpn капча со светофорами вылезает через запрос... из-за этого почти перестал их поисковиком пользоваться