Тут речь не про приложения, а про целевую платформу. Цитата Microsoft (https://learn.microsoft.com/ru-ru/windows/win32/winprog64/running-32-bit-applications) отсюда: "Обратите внимание, что 64-разрядная версия Windows не поддерживает запуск 16-разрядных приложений windows. Основная причина заключается в том, что дескриптор имеет 32 значимых бита в 64-разрядной версии Windows. Таким образом, дескрипторы не могут быть усечены и переданы в 16-разрядные приложения без потери данных. Попытки запуска 16-разрядных приложений завершаются сбоем со следующей ошибкой: ERROR_BAD_EXE_FORMAT."
Речь идет не о готовой плюсовой либе, а о расширении функциональности через готовое решение, написанное на С++. Берем этот код, если нужно — вносим необходимые изменения, собираем из него динамическую библиотеку и подключаем к нужному нам проекту. В статье мы пошагово расписали, как это сделать применительно к Java и Python. Про боль и страдания — вопрос субъективный ?
Под началом работы на проекте мы подразумеваем этап написания ТЗ, поэтому фактически контрольные точки мы определяем до старта разработки. И ревью архитектуры проводит архитектор не из команды проекта, чтобы избежать "замыленности взгляда".
Часть пунктов из вашего списка как раз у нас в выводах.
Про плавную раскатку согласна. Но не всегда ее можно провести. И даже не всегда есть возможность отказаться от релиза в выходной. Есть разные продукты и требования бизнеса. Есть продукты, когда релиз проводится только в выходной и ночью. Потому что есть определенные требования к доступности сервиса.
То есть все пункты здравые и нужно “примерять” их к конкретному продукту для минимизации рисков при проведении релизов.
Мы в компании развиваем культуру качества, когда открыто говорим об ошибках без последующих наказаний и каких-то санкций. И по поводу “отстоять свое мнение, привести аргументы” — это мнение разработчика. Собственная ретроспектива.
Согласна с вами, что одной причины аварий/неудачных релизов не бывает, это чаще всего сочетание причин, упущений на разных этапах. Здесь как раз упущения были на нескольких направлениях.
Если бы не усложнение иерархии новых реальных тренировок, то система возможно выдержала бы нагрузку. Если бы примеры данных актуализировали раньше, то возможно проблему бы выявили уже на тестировании. Если бы изначально правильно выстроили запросы, то возможно усложнение иерархии данных не положило приложение. Если бы сразу провели нагрузочные испытания, то проблему выявили бы раньше, а не на проде.
Ключевое слово “возможно”, сейчас мы это уже никак не можем проверить. И наша главная цель — снизить вероятность повторения подобных ситуаций. Для этого мы исправляем процессы, а не назначаем виновных.
Ваш посыл в целом здравый. Но все же отметать надежность на ранних этапах развития продукта может привести к тому, что он не “взлетит”. Поэтому лучше искать золотую середину между скоростью и надежностью.
Спасибо за замечание! Обновили статью, добавили описание методов контроллера, цепочку вызова и команду по запуску сервисов через javaagent. Надеемся, это поможет вам и другим читателям)
Мы в выводах написали как раз, что после инцидента ввели мораторий на релизы в пятницу и предпраздничные дни. Но у клиента есть сезонность в бизнесе, поэтому ему было важно опубликовать обновления именно в новый год.
Есть смысл. Так как при использовании асинхронности мы самостоятельно переключаем контекст и поток исполнения. А при многопоточности этим занимается операционная система.
Эта статья не про взаимодействие с веб-сервисами, использующих SOAP, а лишь о некоторых способах работы с XML-документами ? Именно поэтому ничего не сказано о WSDL и XSD. SOAP рассмотрен как пример частного случая. К тому же необходимость получения данных из XML бывает при различных задачах.
Отметим, что эта статья рассказывает о возможных способах работы с XML-документами в целом, а не о взаимодействии с веб-сервисами, использующих SOAP. XML-документ — это не всегда SOAP, а значит, схем может и не быть. Кроме того, мы не ставили целью проведение полноценного сравнительного анализа JAXB и DOM, а лишь показали выполнение одних и тех же преобразований с использованием каждого из них, и в заключении отмечаем только некоторые плюсы и минусы JAXB и DOM.
Вы правы, эта библиотека была удалена с версии Java 11. Мы внесли исправления, спасибо! ? К слову о создании классов и расстановке аннотаций, XML-документ — это не всегда SOAP, а значит, схем может и не быть. Задачи при работе с подобными документами бывают абсолютно разными. Здесь описаны лишь некоторые способы, с помощью которых возможно получить доступ к требуемым данным из XML.
Тут речь не про приложения, а про целевую платформу. Цитата Microsoft (https://learn.microsoft.com/ru-ru/windows/win32/winprog64/running-32-bit-applications) отсюда: "Обратите внимание, что 64-разрядная версия Windows не поддерживает запуск 16-разрядных приложений windows. Основная причина заключается в том, что дескриптор имеет 32 значимых бита в 64-разрядной версии Windows. Таким образом, дескрипторы не могут быть усечены и переданы в 16-разрядные приложения без потери данных. Попытки запуска 16-разрядных приложений завершаются сбоем со следующей ошибкой: ERROR_BAD_EXE_FORMAT."
Речь идет не о готовой плюсовой либе, а о расширении функциональности через готовое решение, написанное на С++. Берем этот код, если нужно — вносим необходимые изменения, собираем из него динамическую библиотеку и подключаем к нужному нам проекту. В статье мы пошагово расписали, как это сделать применительно к Java и Python. Про боль и страдания — вопрос субъективный ?
Под началом работы на проекте мы подразумеваем этап написания ТЗ, поэтому фактически контрольные точки мы определяем до старта разработки. И ревью архитектуры проводит архитектор не из команды проекта, чтобы избежать "замыленности взгляда".
Часть пунктов из вашего списка как раз у нас в выводах.
Про плавную раскатку согласна. Но не всегда ее можно провести. И даже не всегда есть возможность отказаться от релиза в выходной. Есть разные продукты и требования бизнеса. Есть продукты, когда релиз проводится только в выходной и ночью. Потому что есть определенные требования к доступности сервиса.
То есть все пункты здравые и нужно “примерять” их к конкретному продукту для минимизации рисков при проведении релизов.
Мы в компании развиваем культуру качества, когда открыто говорим об ошибках без последующих наказаний и каких-то санкций. И по поводу “отстоять свое мнение, привести аргументы” — это мнение разработчика. Собственная ретроспектива.
Согласна с вами, что одной причины аварий/неудачных релизов не бывает, это чаще всего сочетание причин, упущений на разных этапах. Здесь как раз упущения были на нескольких направлениях.
Если бы не усложнение иерархии новых реальных тренировок, то система возможно выдержала бы нагрузку.
Если бы примеры данных актуализировали раньше, то возможно проблему бы выявили уже на тестировании.
Если бы изначально правильно выстроили запросы, то возможно усложнение иерархии данных не положило приложение.
Если бы сразу провели нагрузочные испытания, то проблему выявили бы раньше, а не на проде.
Ключевое слово “возможно”, сейчас мы это уже никак не можем проверить. И наша главная цель — снизить вероятность повторения подобных ситуаций. Для этого мы исправляем процессы, а не назначаем виновных.
Ваш посыл в целом здравый. Но все же отметать надежность на ранних этапах развития продукта может привести к тому, что он не “взлетит”.
Поэтому лучше искать золотую середину между скоростью и надежностью.
Спасибо за интерес и справедливое замечание. Расширили раздел про auto-accessor
Спасибо за замечание! Обновили статью, добавили описание методов контроллера, цепочку вызова и команду по запуску сервисов через javaagent. Надеемся, это поможет вам и другим читателям)
С проблемой нехватки слотов у архитекторов/senior мы тоже сталкивались. Но процедура проходит по новым процессам железно, не отменяем.
А замечание про выкатку на ограниченную аудиторию дельное. Спасибо!)
Мы в выводах написали как раз, что после инцидента ввели мораторий на релизы в пятницу и предпраздничные дни. Но у клиента есть сезонность в бизнесе, поэтому ему было важно опубликовать обновления именно в новый год.
Спасибо за внимательность! Исправили
Действительно, было такое. Заменили
Спасибо за оценку и дополнение! Добавили его в материал
Спасибо за внимательность! Да, аутентификация. Поправили
Добрый день! Подключить фильтр можно в ConfigureServices следующим образом:
services.AddSwaggerGen(options =>{options.OperationFilter<SourceHeaders>();});Добрый день! Мы добавили в статью новый раздел «Версионность», где рассказали, как настроить Swagger для работы с разными версиями API
Есть смысл. Так как при использовании асинхронности мы самостоятельно переключаем контекст и поток исполнения. А при многопоточности этим занимается операционная система.
Эта статья не про взаимодействие с веб-сервисами, использующих SOAP, а лишь о некоторых способах работы с XML-документами ? Именно поэтому ничего не сказано о WSDL и XSD. SOAP рассмотрен как пример частного случая. К тому же необходимость получения данных из XML бывает при различных задачах.
Отметим, что эта статья рассказывает о возможных способах работы с XML-документами в целом, а не о взаимодействии с веб-сервисами, использующих SOAP. XML-документ — это не всегда SOAP, а значит, схем может и не быть. Кроме того, мы не ставили целью проведение полноценного сравнительного анализа JAXB и DOM, а лишь показали выполнение одних и тех же преобразований с использованием каждого из них, и в заключении отмечаем только некоторые плюсы и минусы JAXB и DOM.
Вы правы, эта библиотека была удалена с версии Java 11. Мы внесли исправления, спасибо! ?
К слову о создании классов и расстановке аннотаций, XML-документ — это не всегда SOAP, а значит, схем может и не быть. Задачи при работе с подобными документами бывают абсолютно разными. Здесь описаны лишь некоторые способы, с помощью которых возможно получить доступ к требуемым данным из XML.