Pull to refresh
58
Karma
0
Rating

Пользователь

Документирование ASP .Net Core Web API с помощью OpenAPI/Swagger. Библиотека Swashbuckle

Добрый день! Подключить фильтр можно в ConfigureServices следующим образом:

services.AddSwaggerGen(options =>
{
options.OperationFilter<SourceHeaders>();
});

Документирование ASP .Net Core Web API с помощью OpenAPI/Swagger. Библиотека Swashbuckle

Добрый день! Мы добавили в статью новый раздел «Версионность», где рассказали, как настроить Swagger для работы с разными версиями API

Как работать с процессами и потоками в Python

Есть смысл. Так как при использовании асинхронности мы самостоятельно переключаем контекст и поток исполнения. А при многопоточности этим занимается операционная система.

Java. Работа с XML-документами

Эта статья не про взаимодействие с веб-сервисами, использующих SOAP, а лишь о некоторых способах работы с XML-документами 🙂 Именно поэтому ничего не сказано о WSDL и XSD. SOAP рассмотрен как пример частного случая. К тому же необходимость получения данных из XML бывает при различных задачах.

Java. Работа с XML-документами

Отметим, что эта статья рассказывает о возможных способах работы с XML-документами в целом, а не о взаимодействии с веб-сервисами, использующих SOAP. XML-документ — это не всегда SOAP, а значит, схем может и не быть. Кроме того, мы не ставили целью проведение полноценного сравнительного анализа JAXB и DOM, а лишь показали выполнение одних и тех же преобразований с использованием каждого из них, и в заключении отмечаем только некоторые плюсы и минусы JAXB и DOM.

Java. Работа с XML-документами

Вы правы, эта библиотека была удалена с версии Java 11. Мы внесли исправления, спасибо! 🙂
К слову о создании классов и расстановке аннотаций, XML-документ — это не всегда SOAP, а значит, схем может и не быть. Задачи при работе с подобными документами бывают абсолютно разными. Здесь описаны лишь некоторые способы, с помощью которых возможно получить доступ к требуемым данным из XML.

Зачем нам вулканец на борту: обзор Spock Framework

Добрый день! Спасибо за уточнение. Действительно, на момент написания статьи в 2020 году версия 2.0 была только анонсирована. Поэтому мы упоминаем о скором добавлении параллельного запуска, но не учитываем его при сравнительном анализе с другими фреймворками.

Параллельный запуск был добавлен после публикации материала в версии 2.0-M4 (2020-11-01). До сих пор это версия 2.3, в документации указана с пометкой WARNING как experimental feature: https://spockframework.org/spock/docs/2.3/release_notes.html#_2_0_m4_2020_11_01

Как работать с процессами и потоками в Python

Спасибо!
Чтобы обмениваться, multithreading и асихнронка уже используют общую память.
Для обмена между процессами можно использовать очереди (Queue) или каналы данных (pipe).

Как работать с процессами и потоками в Python

Решить проблему с Deadlock могут помочь 2 правила:

Так как Deadlock — это взаимная блокировка, т.е. захват в прямом и обратном направлении в разных потоках, отсюда вытекает правило. Если в процессах нужно захватывать Lock, то делаем это всегда в одном порядке (направлении).

И второе правило — освобождаем блокировки в обратном порядке их захвата, подобно стеку. Первым захватили — последним отпустили.

Разделяй и не страдай: что выбрать для микрофронтенда?

По мнению автора:
Заниматься поддержкой версий при независимом деплое идеологически неверно. Должна быть обратная совместимость, раз мы пошли этой дорогой. И это не то же самое, что проверка типа. Версия может поменяться, но типы остаться прежними. Как разработчикам AppShell узнать сигнатуры методов, чтоб локально все компилилось, если объединяемся в рантайме? Только чтение документации к МФ-ам, а тут могут быть и человеческие ошибки. Допустим мы компилим под флаг strictNullChecks, передаем null в метод, который оказывается не умеет работать с null. Без тайпингов компиляция не отловит ошибки. Поэтому и предложен "замороченный" вариант с одновременной сборкой МФ-а и сборкой тайпингов под пакет

Разделяй и не страдай: что выбрать для микрофронтенда?

Уточните, что имелось в виду:

  1. В рантайме мы можем типизировать с помощью утиной типизации. Не очень удобно, громоздко, для декларативного подхода нужно json валидаторы писать или использовать либы. Но по сути все кастомные тайп гарды так и работают. Опять же ошибки всплывут в рантайме, просто мы сможем их качественней обработать

  2. Можно попробовать составить d.ts файлы на основе сборки МФ-ов. Файлы эти нпм пакетами доставлять в основное приложение. Именно этот вариант вы и описали, как я понял. Но тогда надо будет при каждом деплое МФ-а пересобрать основное приложение с учетом потенциально изменившихся типов. При этом версии этих пакетов надо менять, ведь они зафиксированы в package-lock. Апать пакет и комить новый резолв зависимостей через ci, чтоб разработчики могли потом подтянуть изменения и узнать, что да как там в новой версии. Способ компромиссный, но по-своему хлопотный

Разделяй и не страдай: что выбрать для микрофронтенда?

Автоматизированный подход может помочь взять лучшее от этих двух подходов: простоту типизации и независимость команд, но надо учесть массу нюансов.

Разберем npm пакеты. В package.json можно указать диапазон версий, что даст возможность апать пакет и триггерить сборку главного приложения. Но в package-lock.json зафиксирована конкретная версия пакета, которая работала на момент ручной интеграции или обновления пакета разработчиком. Опасно удалять этот файл и ставить зависимости заново, так как могут быть зарезолвлены иные версии сторонних зависимостей. Можно точечно обновить пакет и сделать комит через CI, чтобы разработчики могли отребейзиться и увидеть изменения в зависимостях, но в этом случае большая ответственность возлагается на DevOPS-инженеров.

С сабмодулями Git проще, поэтому это решение выглядит рабочим. Можно сделать git submodule foreach "git checkout master", а затем дергать сборку, но здесь может быть появиться блок со стороны разработки. Не всем нравится разработка через сабмодули, так как она приводит к сильной связности кода и проект ощущается монолитом. Когда проект достаточно большой, то хочется большей изоляции фич друг от друга.

Новые функции внедрения зависимостей в .Net 6

Спасибо за подробные дополнения!

Нефункциональные требования: как не пустить систему ко дну

Спасибо) передадим автору)

Нефункциональные требования: как не пустить систему ко дну

Обнаружили баг, далее разработчик анализирует код, к обсуждению подключается аналитик и другие члены команды (по возможности). Если есть возможность оптимизации - оптимизирует, нет - эскалирует проблему тимлиду. Затем уже тимлид анализирует и оптимизирует, если есть возможность, если нет - эскалирует продакту, детально описывая проблемы и указывая возможные риски. Далее продакт обсуждает проблемный пункт НФТ с бизнесом. Обычно находим нужные доводы и приходим к компромиссу.

Но, по нашему мнению, нефункциональные требования не нужно менять из-за того, что система им не соответствует. Наоборот, это систему надо менять. Если вы видите, например, в kibana или в Sentry, что она не справляется - зовите девопсов. А еще лучше в коде заранее предусмотреть контрольные точки, на которых могут возникать проблемы, и при их возникновении получать соответствующие алерты. Но тут опять же мы говорим не об изменении НФТ под систему, а о внесении изменений в систему под НФТ.

Camunda: тестируем модели процессов

Добрый день.
В данном случае bpm предназначена для одного из российских банков. По нашим наблюдениям, Camunda бывает удобны как для бизнеса, так и для разработчиков, поскольку позволяет привязывать к схеме делегатный джава-код и сильно ускоряет процесс разработки.
Как мы отмечали в прошлой статье, в чистом коде реализация займет гораздо больше времени, а поддерживать может быть нелегко из-за запутанной паутины вызовов и управления доступом. Хотя где-то действительно можно и проще работать без bpm – каждый решает сам.

Автоматизируем бизнес-процессы с Camunda и Spring Boot: отказоустойчивая реализация BPM-схем

Всем привет! Вышло продолжение статьи - на этот раз рассмотрим особенности тестирования моделей процессов.

Автоматизируем бизнес-процессы с Camunda и Spring Boot: отказоустойчивая реализация BPM-схем

Добрый день. Всё  зависит от задачи, условий и уровня владения тем или иным инструментом. В общем случае сеньор-разработчику зачастую проще написать все чистым кодом, тогда как бизнесу бывает удобнее Camunda – чтобы наглядно видеть блок-схему процесса и легко подключать к проекту разработчиков любого уровня, не требуя от них погружения в чужой код.

Что касается вопросов, мы сделали несколько предположений, исходя из опыта нашего проекта – и в других проектах, безусловно, могут быть свои особенности.

1.  Как версионировать БП, как мигрировать со старой версии на новую?

Можно указать в пулах version tag, кроме того, при деплое активные процессы закончат свой жизненный цикл по старой версии схемы.

2.  А если при этом состав процессов или модели данных несовместимы?

Основы SOLID говорят, что проект должен быть открыт для расширения, но закрыт от изменений. Модель данных нужно менять в рамках разумного.

3.  Где хранить актуальное состояние модели: только в инстансе процесса или во внешнем хранилище? Если во внешнем хранилище как решать проблему конкурентного доступа?

Можно хранить в контексте или во внешней БД (что даже лучше). Проблему конкурентного доступа нужно решать по мере ее возникновения, иначе сориентироваться трудно, если вообще возможно. Острее будет стоять вопрос версионирования и миграций БД. Также стоит присмотреться к документоориентированным БД.

4.  Как вообще рефакторить это все это добро?

Рефакторить как раз-таки просто: схема оказывается отвязана от кода и можно с большой степенью свободы менять реализацию как схемы, так и кода.

5.  И самое главное: а какой вообще bpm дает профит? По своей сути bpmn - это описание конечного автомата, так почему не использовать, например, акторную модель?

Дело в скорости разработки: в чистом коде реализация займет гораздо больше времени, а поддерживать может быть нелегко из-за запутанной паутины вызовов и управления доступом. Хотя, где-то действительно можно и проще работать без bpm – каждый решает сам.

Автоматизируем бизнес-процессы с Camunda и Spring Boot: отказоустойчивая реализация BPM-схем

Рады, что материал полезен! Показать детали, увы, не можем – зато через неделю расскажем подробности о тестировании проекта. Кода будет больше)

Ускоряем работу с тестовой документацией. Экспорт данных из Allure-отчета в Confluence

Здравствуйте. В статье мы привели немного упрощенный фрагмент кода, на практике в каждом проекте будут свои настройки. В частности, в нашем проекте была отдельная папка для attachments, поэтому мы не обращались к фильтрации. По второму вопросу — согласны, во многих проектах это бывает необходимо.

Information

Rating
Does not participate
Location
Россия
Works in
Registered
Activity