Это продолжение туториала по JUnit 5. Введение опубликовано здесь.
Рассмотрим как создавать HTML-отчет для результатов выполнения тестов JUnit. В этом примере я создаю HTML-отчет для проекта JUnit-Examples, представленного на Github.
Kotlin создавался, чтобы избежать некоторых проблем Java. Но как и в любом языке, есть в нем свои особенности. Разрабатывая собственный проект, мы наткнулись на несколько таких моментов. Часть стреляет вам в колено на продакшене, только если вы ими злоупотребляете. Другая отражается на производительности высоконагруженных систем. Все эти моменты сложно заметить, поскольку их не подсвечивают специально плагины для IDE, да и в целом на первый взгляд код похож на валидный.
В этой статье мы поговорим о том, на что нужно обратить внимание.
Все мы, разработчики, знакомы с отладчиками и используем их ежедневно - они важная часть процесса программирования.
Но давайте будем честными. Обычно мы используем только опцию точки останова. При большом желании мы можем использовать условную точку останова.
Но знаете что, отладчик IntelliJ IDEA имеет множество мощных и передовых функций, которые полезны для более эффективной и простой отладки.
Чтобы помочь вам, мы составили список советов и приемов от наших разработчиков в Lightrun. Мы надеемся, что эти советы помогут вам быстрее находить и устранять ошибки.
В данной статье рассмотрены крупные нововведения Java начиная с 8 по 15 версии.
Каждый раз, когда мы вносим изменение в схему нашей базы данных, мы также должны вносить изменения в код, который использует эту схему базы данных.
Когда мы добавляем новый столбец в базу данных, нам нужно изменить код, чтобы использовать этот новый столбец.
Когда мы удаляем столбец из базы данных, нам нужно изменить код, чтобы этот столбец больше не использовался.
В этом руководстве мы обсудим, как мы можем координировать изменения кода с изменениями базы данных и развертывать их в нашей производственной среде без простоев.
Мы шаг за шагом рассмотрим пример сценария использования и воспользуемся флагами функций, помогающими нам выполнить изменения.
Одним из основных преимуществ Java является автоматизированное управление памятью с помощью встроенного сборщика мусора (или сокращенно GC). GC неявно заботится о выделении и освобождении памяти и, таким образом, способен решать большинство проблем, связанных с ее утечкой.
Хотя GC эффективно обрабатывает значительную часть памяти, он не гарантирует надежного решения проблемы с ее утечкой. GC достаточно умен, но не безупречен. Утечки памяти все еще могут закрасться даже в приложения, созданные добросовестным разработчиком.
По-прежнему возможны ситуации, когда приложение создает значительное количество лишних объектов, расходуя ресурсы памяти, что иногда приводит к его полному отказу.
Утечки памяти — это настоящая проблема в Java. В этом руководстве мы рассмотрим, каковы потенциальные причины утечек, как распознавать их в рантайме и как справиться с ними в нашем приложении.
Если ваш проект с автотестами растет, то рано или поздно ставится вопрос о том, как централизованно управляться с этими тестами. Как найти время на поддержку тестовой документации? Как ее структурировать? Где хранить отчеты? Как избавиться от нестабильных тестов и быстро выявить ответственных за них? В Wrike мы смогли ответить на все эти вопросы и автоматизировать процессы, которые они затрагивают. В статье расскажем, как нам это удалось.
#application.properties
spring.datasource.url=${SPRING_DATASOURCE_URL}?someProperty=${PROPERTY}
В последнее время я довольно часто сталкиваюсь с оптимизацией процессов загрузки и обработки информации. Периодически вижу не самые оптимальные, а то и вредные для производительности решения причем от разработчиков middle и senior уровня. Поэтому хотелось бы подробнее описать общий подход к написанию правильных и быстрых многопоточных архитектур с максимальной утилизацией ресурсов, но при этом с минимально возможным в каждом отдельном случае количеством потоков.
Компания Liferay выпустила очередную версию своей портальной платформы Liferay CE 7.4.3 и гордо заявила в анонсе что это теперь полноценное No Code решение. Так ли это на самом деле?
В Java 8 кардинально переработали процедуру вывода типов выражений. В спецификации появилась целая новая глава на эту тему. Это весьма сложная штука, изложенная скорее на языке алгебры, чем на языке нормальных людей. Не каждый программист готов в этом разобраться. Я, разработчик IDE, которому приходилось ковыряться в соответствующем коде, к своему стыду тоже довольно плохо разбираюсь в этой теме и понимаю процесс только по верхам. Причём сложно не только мне, но и авторам компилятора Java. После выхода Java 8 обнаружились десятки багов, когда поведение компилятора не соответствовало спецификации, либо текст спецификации был неоднозначен. В средах разработки для Java ситуация обстояла не лучше: там тоже были баги, причём другие, поэтому код мог отображаться ошибочным в вашей IDE, но успешно компилироваться. Или наоборот. С годами ситуация улучшилась, многие баги исправили, хотя всё ещё в спецификации остались тёмные углы.
Как добиться необходимого контроля, удобства и даже скорости при подготовке тестовых данных для микросервисов и тестов производительности? В каких случаях лучше не генерировать XML и JSON файлы с помощью конкатенации строк? Зачем анализировать статистику по SQL запросам?
Меня зовут Вячеслав Смирнов, и я ускоряю дистанционное банковское обслуживание юридических лиц, а еще поддерживаю чат QA — Load & Performance в Телеграм, где сообщество инженеров по тестированию производительности обсуждает тестирование нагрузки.
Статья получилась длинной, поэтому сегодня я расскажу про подготовку тестовых данных для тестирования производительности и про то, как с помощью SQL, Pandas и Java эти данные готовить. Поговорим про анализ метрик и логов с точки зрения данных и с использованием InfluxDB, Grafana и прочих инструментов, А ещё о том, как может выглядеть хороший отчет по системе, в которой много данных. В следующих частях перейду к генерации и анализу тестовых данных для нагрузки.
При работе с большой кодовой базой довольно естественно не помнить каждую подсистему или вариант реализации. Особенно если вы новичок в кодовой базе, или вы сосредоточились на определенной области кодовой базы.
Большинство людей начнут с использования «git blame» (или соответствующей функциональности в своей среде IDE/редакторе). Но в большинстве нетривиальных проектов вы обычно заканчиваете коммитом рефакторинга, переименованием или тривиальным исправлением проекта, например переключением на другую библиотеку assertion. При первом взгляде, мы видим только самые последние изменения, но не самые важные.
Нам нужно аккуратно удалить слой за слоем песок и грязь, которые были нанесены на реальные изменения, чтобы выявить их.
В автоматизации отчетности очень часто используют открытую Java-библиотеку JasperReports, например статья Опенсорс-решение для автоматизации отчетности рассказывает об ее использовании для получения PDF форматов отчетности между делом упомянув о возможности экспорта в другие форматы.
Однако нередко возникает потребность получать данные не в твердой копии, а в форматах электронных таблиц и в этом направлении в библиотеке JasperReports есть мощный инструмент Crosstab. Вместе с механизмом экспорта в форматы электронных таблиц данный инструмент может быть востребован для получения форматированных документов, которые годны как отчеты для анализа, так и для дальнейшей обработки данных.
Основная цель использования печатной формы - выгрузка данных в электронные таблицы для дальнейшего использования данных. Разработку печатной формы будем делать в среде TIBCO Jaspersoft® Studio
При разработке очередной платформы перед командой АТОЛ встал вопрос выбора языка программирования/стека технологий/железа/фреймворка для создания решений. Железо было выбрано на базе относительно недорогой Linux-платформы STM32MP153/512MB DDR3/8GB eMMC. Эта платформа имеет на несколько порядков больше ресурсов, чем используемые в нашей основной массе решений LPC1768/LPC1778/LPC4078/STM32F207. 100% наработок кода компании для устройств были написаны на C/C++, однако прогресс не стоит на месте, и периодически необходимо актуализировать инструменты и технологии разработки, особенно с учетом новых аппаратных возможностей. Из статьи станет ясно, как мы дошли до жизни такой и почему выбрали Golang для создания очередного набора решений.
Выбор стека технологий важен для всех компаний, которые занимаются разработкой железа и перерастают крошечные embedded контроллеры на Cortex M0/M3/M4/M7. Обычно команды при переходе на новую платформу выбирают одно из двух решений: стараются сделать новую версию системы на новом железе/технологиях/архитектуре, превращая решение в нестабильный долгострой, или наоборот — вносят минимальное количество изменений, но иногда вместо совокупности положительных черт разных подходов получают совокупность отрицательных.
В статье исследованы особенности различных языков программирования/технологий (Java, Python, C/C++, Rust, Golang), их плюсы и минусы, сформулированы критерии выбора и представлен выбор команды АТОЛ.
Для анализа использован метод SWOT-анализа. В качестве источников данных — информация сайтов фреймворков. Помимо этого, косвенная информация о боли и страданиях разработчиков получена на Stackoverflow, и часть субъективных выводов сделана на основе моего экспертного мнения за более чем 30-летний опыт программирования.
Одним из наиболее распространенных «лучших практик» в программировании является принцип DRY: не повторяйся. Для реализации этого принципа можно использовать множество методов: инкапсуляция, параметризация, инверсия управления и многое другое. Одним из этих методов является абстракция, и одно из основных различий между функциональным программированием (FP) и объектно-ориентированным программированием (ООП) заключается в способе применения абстракции. Обычной практикой в ООП является ограничение абстракции до строгого полезного минимума для рассматриваемой проблемы. В ООП преждевременное абстрагирование часто считается ошибкой, как и преждевременная оптимизация.
В FP, с другой стороны, абстракция, как правило, продвигается настолько далеко, насколько это возможно. Каждая проблема разбита на серию простейших возможных функций, которые затем комбинируются для построения решения проблемы. Выявление этих абстракций обычно является наиболее важной частью решения проблемы. Фактически, программисты FP часто тратят больше времени на то, чтобы найти, какую проблему им следует решить, чем на их решение. И, конечно же, обычно кажется, что эти функции одинаковы от одной проблемы к другой. Только способ их комбинирования отличается. Это причина, по которой абстракция является одним из наиболее ценных методов, используемых программистами FP.
В этой статье мы сравним, как ООП и ФП будут обрабатывать абстракцию в конкретной простой задаче: вычислении суммы целых чисел от 1 до произвольного значения n. Проблема настолько проста для решения с помощью императивного программирования, что кажется, что в этом нет ничего интересного. Вот как это можно сделать в Java:
Продолжаем рассказывать про чаты на вебсокетах, но уже со стороны бэкенда. Когда-то использовали сторонний сервис, но было важно решить ряд моментов, которые он не мог покрыть. Выбирать особо не пришлось, и мы принялись разрабатывать собственное решение.
Ниже подробности о том, что было до написания кастомных чатов и какие стояли требования к реализации, из каких компонентов они состоят, как вписываются в нашу инфраструктуру и что получилось в итоге. А в конце статьи — ссылки про особенности разработки наших чатов на вебсокетах для iOS и Android.
Вчера перевели в статус Candidate новый JEP 421: Deprecate Finalization for Removal. Путь к удалению механизма финализации из Java начался в Java 9, когда метод Object.finalize() был впервые объявлен deprecated. Рано или поздно механизм исчезнет из Java, поэтому если вы его используете, самое время задуматься об альтернативах. Однако статья не об этом.
Я думал, что довольно хорошо представляю себе все минусы механизма финализации. Многие из них перечислены, например, в этой статье. Однако, прочитав JEP, я узнал об уязвимости, о которой раньше и не думал. Оказывается, с помощью финализации можно создать объект со сломанными инвариантами.
Все разработчики знают, что есть два способа сделать дело: первый — вручную, медленно, нервно, сложно, либо второй – автоматизировано, быстро и еще сложнее.
Например, я мог бы продолжить писать эту статью о том, почему стоит использовать Java вместо C++ при программировании систем с низкой задержкой. Либо мог бы обучить ИИ, чтобы он сделал это за меня. Второй подход, в конце концов, сэкономил бы мне массу времени – искусственный интеллект генерировал бы за меня тысячи статей в секунду – но редактор вряд ли обрадовался бы услышать, что на подготовку первой статьи мне нужно два года.
Аналогичная ситуация возникает при необходимости разработать систему с низкой задержкой.
Данный цикл статей рассматривает сложнейший мир многопоточного программирования через достаточно щекотливую тему, читатель должен быть готов к тому, что некоторые образы и примеры могут негативно повлиять на его психологическое состояние, некоторые — вызвать отвращение. Следует учитывать, что все описанные ситуации являются вымышленными и совпадения с реальностью случайны.
Повествование будет разбито на две части, от простого к сложному.
В первой части будут рассмотрены базовые понятия, стандартные подходы и проблемы. Будут приведены примеры использования нескольких, довольно известных примитивов синхронизации.
Во второй части, мы углубимся в более сложные концепты и так же, на простых и понятных примерах, разберем нетривиальные концепции, которые существуют в современных языках программирования.