Нагрузочное тестирование API без использования UI
В этой статье поговорим о Нагрузочном тестировании при помощи JMeter-Java-Dsl и реализуем наш первый нагрузочный тест для API с генерацией динамических значений.
Основным средством для командной работы с репозиторием компании, в которой я работаю, является Gitlab. На первый взгляд, он хорош: и бесплатной версии хватает сполна, и CI/CD - пайплайн имеется, и хранить артефакты тоже можно (долой Nexus). Однако, и у GitLab есть свои минусы.
Так, например, разработчики до сих пор не смогли реализовать визуализацию покрытия тестов. Да, она у них есть, но для её реализации нужно сгенерировать и загрузить в GitLab отчет о покрытии в устаревшем формате Cobertura, а не в актуальном Jacoco. Основная же проблема в том, что Cobertura plugin последний раз обновлялся в далеком 2015 году.
В публикациях на хабре, чаще всего самое интересное в комментариях. Вот и в моем прошлом посте "Сгенерировать web интерфейс из БД или объектной модели не стало проще даже 10 лет спустя" я собрал джекпот из SharePoint, Vaadin и нескольких библиотек либо устаревших, либо поддерживаемых "одним автором".
Что я пытался объяснить читателям, что на этапе проверки идей не нужна дополнительная сложность в виде серверной инфраструктуры только ради этой самой инфраструктуры и нового языка программирования/платформы. Именно поэтому мне не нужны сейчас Yii, Symfony и Laravel, не подойдет ADF. На любое обучение тратится драгоценное время и поэтому надо понимать зачем тратить время на что-то, что потом возможно навсегда придется забыть через неделю-другую игры с прототипом.
В своих эксперементах с помощью лапшекода на JavaScript я быстро разработал вполне функциональный интерфейс. А начиналось все с Java 21, хотя в итоге обошелся без нее!
Небольшое мнение о вредных вопросах на собеседовании на примере популярного старичка "Как работает HashMap". Пытаемся разобраться в проблемах современного шаблонного подхода, параллельно задумываясь об альтернативных вариантах проведения.
Меня зовут Александр Певненко, я Java developer в СберТехе. Вместе с командой развиваю Platform V DataSpace — BaaS-продукт, обеспечивающий базовые сервисы для работы с данными.
В этой статье я собрал примерный список алгоритмов, которые использую в работе с высоконагруженным проектом с большой кодовой базой. Материал будет интересен всем, кто на практике решает задачи оптимизации и вообще задумывается, обязательно ли разработчику глубоко погружаться в математику.
Если скорость и производительность критичны для системы, то оптимизация кода перестает быть пустой тратой времени. А использование сторонних библиотек без понимания их устройства становится риском, так как может обернуться падением производительности.
Поэтому здесь я приведу несколько «базовых» алгоритмов, знание которых помогает мне работать с прицелом на эффективность кода, и дополню примерами на Python и Java.
Как разработчик TeaVM, компилятора байт-кода JVM в JavaScript и WebAssembly, я часто рекомендую пользователям, почему-то жаждущим сгенерировать WebAssembly, начать с JavaScript. Если честно, бэкэнд WebAssembly я очень давно не развиваю, не реализую в нём недостающих фич и не фикшу баги. Меня спрашивают: а почему так? Обычно, я просто игнорирую подобные вопросы, потому что в двух предложениях ответить на них невозможно, а для того, чтобы писать больше предложений, у меня нет времени. Обычно если я встречаю чьи‑то попытки объяснить, чем WebAssembly плох для реализации JVM (а так же, CLR, JavaScript и прочих динамических сред), то они сводятся к следующему: «Java (.NET, JavaScript, ваш вариант) — это управляемый язык со сборкой мусора и исключениями, так что приходится тащить с собой гигантский рантайм». Что же, на самом деле, ситуация несколько сложнее, а размер рантайма вовсе не такой страшный и не является основным источником бед.
После работы над двумя коммерческими проектами на Rust я получил хороший практический опыт в этом языке. Это были backend сервисы для веб-приложений, где Rust использовался для основной бизнес-логики и работы с базами данных.
Кроме того, я создал три open source библиотеки на Rust, которые публиковал на GitHub. Это позволило мне лучше изучить идиоматичный Rust, работу с асинхронностью и т. д.
В целом, после работы над этими проектами у меня как Java-разработчика накопился интересный опыт, которым хотелось бы поделиться для тех, кто только начинает изучать Rust, приходя из мира Java. Далее я привожу несколько полезных советов, которые помогут в переходе на Rust.
Есть бесконечное количество способов ошибиться при написании кода. Однако иногда можно заметить явные интересные закономерности, как и где ошибаются программисты. Поговорим о коде, который "притягивает" опечатки.
С целью тестирования и продвижения статического анализатора кода PVS-Studio мы проверяем различные открытые проекты. Найдя ошибки, мы сообщаем о них авторам проектов, коллекционируем их и пишем статьи про наиболее интересные случаи.
Рассматривая все эти ошибки, я постепенно замечаю различные повторяющиеся паттерны опечаток. За редким исключением они не зависят от языка программирования. По крайней мере, они одновременно свойственны коду, написанному на C, C++, C#, Java. В этой статье я опишу 7 паттернов, которые заметил к настоящему моменту:
Заметность закономерностей в ошибках свидетельствует о том, что они крайне распространены. Полезно знать о них, чтобы избегать написания потенциально опасного кода или более эффективно находить их в процессе обзоров кода. Другим словами, вы узнаете, какой код притягивает ошибки, и будете более внимательно его проверять. Конечно, PVS-Studio способен выявить многие подобные ошибки, но не все. Поэтому дополнительное внимание не повредит.
Как установить оптимальное значение таймаутов в микросервисной архитектуре, чтобы достичь максимальной производительности и отказоустойчивости.
Под катом вы узнаете как установить оптимальные значение connection и request timeout, стоит ли повторять запрос при ошибке или лучше избегать этого.
В конце статьи есть небольшая шпаргалка и куча полезных ссылок. Приятного чтения.
Разобравшись в том, как процессоры, память и кэш влияют на выполнение программ, вы сможете лучше понять производительность приложений и оптимизировать свой подход к их написанию.
Закрытый ключ КриптоПро CSP представляет из себя флеш-накопитель, на котором в директории ххххх.000 лежат файлы primary.key, primary2.key, masks.key, masks2.key, name.key и header.key.
Пакеты в Java появились с самого начала, во времена, когда язык еще назывался Oak. Их описание уже присутствует в его ранних спецификациях.
Java-пакеты реализуют так называемое пространство имен (namespace), позволяющее использовать в проекте файлы с одинаковыми именами. Такой подход существует с давних времен во многих языках.
Также с помощью пакетов разработчики структурируют файлы удобным и понятным для себя способом, т. к. чем их больше используется в программе, тем в них сложнее становится ориентироваться. Если они будут размещаться бессистемно, то это рано или поздно приведет к полному запутыванию кодовой базы и дезориентации программистов.
И наконец, с помощью пакетов можно ограничивать доступ (из других пакетов) как целиком к классам, так и к их отдельным элементам.
Об этом и многом другом и пойдет речь в данной статье.
Это 2-ая часть статьи "Как задеплоить монолитный pet проект на Java с 0 и не сойти с ума". Первую часть вы можете найти по ссылке.
В первой части мы успешно добавили свои наработки в репозиторий GitHub, в этой части мы рассмотрим что такое GitHub Actions и как с помощью них добавить свой образ docker контейнера с приложением в хранилище DockerHub.
Всем привет!
В этой статье рассмотрим применение библиотеки Apache Flink ML для построения конвейеров машинного обучения. Затем реализуем простой проект по прогнозированию поведения системы, а также ответим на вопросы: какие задачи Machine Learning подходят для Flink и какие особенности Flink делают его подходящим для использования в задачах Machine Learning.
До недавнего времени мой опыт работы с бекенд-приложениями ограничивался созданием приложения на базе Spring Boot различных версий с использованием реляционных баз данных, ликвибейза, брокеров сообщений и т.д. Приложения в большинстве своем были легковесными, быстро запускались и не требовали большого количества ресурсов. Пока на работе мы с командой не столкнулись с проектом, который мало того, что запускался мучительно долго, так ещё и работал с большим количеством сервисов, постоянно то отдавая, то обрабатывая различные данные. Всё это, конечно же, приводило к медленной работе в продакшене, частым зависанием или вообще поломкой сервиса.
Это стало одной из причин интереса к GraalVm - виртуальной машине, написанной на Java, помогающая делать программы быстрее с помощью JIT компилятора. GraalVm помогает скомпилировать java код в так называемый native image. Это исполняемый файл приложения, который мгновенно запускается без старта JVM.
Эта статья - туториал, как подружить между собой Spring Boot, GraalVm, Liquibase и Docker, какие могут возникнуть подводные камни и как их можно обойти.
Представляем вашему вниманию первую статью из серии о синхронизации потоков в Java, в которой мы рассмотрим основы: состояния гонки, объекты блокировки, объекты условий, а также методы await, signal и signalAll.
Перерыв в работе заставил меня задуматься над смыслом выражения "Сапожник без сапог". Будучи Java Backend Developer с 3-ех летним стажем я не имею на руках ни одного pet проекта. Конечно, на GitHub у меня есть какие-то мелкие проектики, но они не доведены до конца и кроме того как просто висеть на доске "почета" они больше ничего и не могут. С этой мыслёй я пошел в интернет гуглить "как мне задеплоить свое приложение?".
Скажу сразу, это статья содержит шаги по развертыванию Java приложения с помощью GitHub Actions на серверах AWS EC2 и это моя интрерпретация тех инструкций, которые я находил в интернете. Собственно это статья содержит для новичков, кто просто не делал никогда деплой своего приложения, но очень хочет в сжатые сроки похвастаться своим результатом.
Эта статья является первой, написанной мной. Буду очень рад, если она все же будет опубликована. На данный момент являюсь Junior Java разработчиком, поэтому в этой статье не будет сложной аналитики и глубокого погружения в тему, но я свой опыт изучения и реализации приложений с использованием Spring Security, возможно, кому-то это поможет справиться с теми трудностями, с которыми встретился я.
Недавно мне пришлось подключать и настраивать авторизацию через Spring Security версии 3.1.0. В процессе разработки и решения сложностей, которых было не мало, я заметил, что информации по версии 3.1.0 довольно мало, если не считать документацию.
Ваш первый день на работе. Вчера вы рассказывали про чистую архитектуру, SOLID принципы, и про то, как создавать аккуратную и масштабируемую архитектуру.
Сегодня нужно написать простенький экран, который будет отображать список. Вы с огромным энтузиазмом начинаете реализовывать прекрасный список - каталог товаров магазина. Один запрос, один список. Все сделали красиво, фрагмент создался, подтянул из DI ViewModel, которая в свою очередь передала остальным слоям, чтоб загрузить данные по АПИ и закешировать их. Все эти компоненты правильно освобождаются, так как все это сделано как надо отдельным Субкомпонентом с отдельным скоупом.
Следующий день, оказалось, что к списку нужно добавить расценки, однако их можно загружать только отдельным запросом. Этот запрос оказался тяжелым на сервере, так что каждый ответ может приходить дольше чем обычно, и сам запрос ко всему списку разбит на несколько подзапросов. При отправке запроса клиент должен выслать список наиболее просматриваемых товаров пользователем. Бэк при этом очень попросил лишний раз запросы не делать, так как сервер и так не справляется.
В одночасье, мы понимаем, что наша шаблонная архитектура превращается из легкой и понятной в сложную и нечитабельную. А все потому, что нам нужно прежде всего обеспечить жизненный цикл компонентов достаточно большим, чтобы эти компоненты успели: собрать информацию для запроса, выполнить долгие запросы, а может быть и несколько за раз, при страничной загрузке, сохранить ответы сервера и закешировать их, также сформировать один общий список товаров с 2 разных запросов и, наконец, выполнить фильтрацию и сортировку конечного списка.
Ранее я рассказывал о том, как запустить PostgreSQL в Docker. Тогда речь шла об использовании «ванильных» образов Postgres и поднятии одного хоста. В большинстве случаев этого достаточно как для тестов, так и для экспериментов, но нужно понимать, что в промышленной эксплуатации чаще всего используются высокодоступные (отказоустойчивые, кластеризованные) конфигурации PostgreSQL.
Сегодня я покажу, как запустить уже целый кластер PostgreSQL в Docker, а также в тестах через Testcontainers, и как вручную инициировать смену мастер-хоста.
