Java *

Компания 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++ при программировании систем с низкой задержкой. Либо мог бы обучить ИИ, чтобы он сделал это за меня. Второй подход, в конце концов, сэкономил бы мне массу времени – искусственный интеллект генерировал бы за меня тысячи статей в секунду – но редактор вряд ли обрадовался бы услышать, что на подготовку первой статьи мне нужно два года.

Аналогичная ситуация возникает при необходимости разработать систему с низкой задержкой.

Данный цикл статей рассматривает сложнейший мир многопоточного программирования через достаточно щекотливую тему, читатель должен быть готов к тому, что некоторые образы и примеры могут негативно повлиять на его психологическое состояние, некоторые — вызвать отвращение. Следует учитывать, что все описанные ситуации являются вымышленными и совпадения с реальностью случайны. 

Повествование будет разбито на две части, от простого к сложному. 

В первой части будут рассмотрены базовые понятия, стандартные подходы и проблемы. Будут приведены примеры использования нескольких, довольно известных примитивов синхронизации.

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

Кому может быть полезна эта статья?

Извращенцам делающим ML на Java? Или может быть для обучения?

Хотя зачем эти оправдания? Весь код был написан because we can.Под катом мы рассмотрим как превращать числа вида "Двенадцать тысяч шестьсот пятьдесят девять целых четыре миллионных" в форму вроде 12 659, 000 004.

Разбор планирования и логики работы небольшого Back-end проекта на Java Spring Boot

Maven

Забавный факт: единственной IDE, которая поддерживает одновременную разработку на Java и C++, является Android Studio. Нет, мы не были готовы пойти на эту жертву.

Что такое .equals() и .hashcode() в java? Зачем их переопределяют? Как это принято делать?

Сегодня я расскажу вам как можно опубликовать своё Spring Boot приложение в GitHub Packages с помощью GitHub Actions. Вот так. В общем-то всё. Вот. Спасибо за внимание.

Ас-саляму алейкум, братья!

Думаю многие в своей жизни хотели разобраться с тем как при помощи программного кода обрабатывать изображения и видео. Применений у этого навыка бессчётное количество, у кого на что фантазии хватит. Можно начать с автоматической коррекции огромного числа фотографий, а закончить deep fake видео с участием " Олега Тинькова ".

Какой же инструмент для этого применить, да если ещё учесть что вы закоренелый джавист? Думаю лучшим инструментом в этом случае будет библиотека OpenCV. Исходя из всего вышеперечисленного представляю вам серию видеороликов в которых Я подробно расскажу вам о том как установить библиотеку OpenCV, её функционале и работе с изображением и видео на языке Java.

Давным-давно, когда мир был юн, и компьютеры в нем были в новинку, я учился по программе на младшего сотрудника (Associate Degree) по обработке данных – программ по «компьютерным наукам» тогда не было – и в рамках этой программы преподавались бухгалтерское дело, математика, статистика, а также три языка программирования: ассемблер IBM/360, FORTRAN и COBOL. К 80-м студентам уже рассказывали, что COBOL мертвый язык, и никто его больше не изучают.

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

В статье рассмотрены проблемы и решения, которые возникли при добавлении Kotlin в небольшой существующий микросервис на Spring Boot, написанный на Java. В рамках статьи не будут рассматриваться плюсы и минусы того или иного языка - здесь и так сломано много копий. В рамках проекта мы хотели протестировать, как будет работать Kotlin в нашем обычном стеке. Рассматривается стандартный стек Spring WebMVC (не реактивный)