Java *

При разработке очередной платформы перед командой АТОЛ встал вопрос выбора языка программирования/стека технологий/железа/фреймворка для создания решений. Железо было выбрано на базе относительно недорогой 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. Нет, мы не были готовы пойти на эту жертву.

Сегодня я расскажу вам как можно опубликовать своё 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 (не реактивный)

Ремарка - речь пойдет о 98% собеседований в постсоветском пространстве на позицию Java Developer. 

Начну вот с чего: знание Collections Framework, его иерархии наследования, внутренней работы HashMap и количества примитивов в языке - никак, совсем никак, не может дать представления о работоспособности человека. 

 - Фу, какая банальщина, все и так всё понимают. Такие вопросы на собеседованиях дают представление о базовых знаниях человека, а на остальную работу смотрят в период испытательного срока.

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

Вот пункты, которые, на мой взгляд, должны лежать в основе построения плана собеседования:

1) Работа разработчика состоит из 40% кодинга и 60% рассуждений, размышлений и попыток понять и вместить задачу, выбрать оптимальный алгоритм ее решения. И я не говорю о созвонах, декомпозиции и обсуждении предстоящего спринта и т.д. и т.п. В таком случае кодинга остается процентов 20.

2) Без грамотного и прозрачного процесса коммуникации между членами команды, проекта не получится. И к сожалению, какой бы прекрасный не был тимлид и ПМ, если разработчики не умеют общаться и понимать, какую информацию важно озвучивать команде, что нужно спрашивать, а что можно загуглить, у проекта будут проблемы.

3) Языки, фреймворки, библиотеки, базы данных и прочее - это всего лишь инструмент для решения проблемы, и он должен быть подобран под задачу, а не наоборот.

В этой статье вы узнаете несколько полезных советов и приемов, связанных с фреймворком Quarkus. Мы сосредоточимся на функциях, которые выделяют Quarkus среди других Java фреймворков.

Идея поэкспериментировать с интеграцией Neo4j с Helidon возникла вполне естественно.

Neo4j — графовая система управления базами данных с открытым исходным кодом, реализованная на Java. По состоянию на 2015 год считается самой распространённой графовой СУБД. (Википедия, 21.10.2021)

Neo4j написана на Java и доступна из ПО, написанного на других языках с использованием языка запросов Cypher, через транзакционную конечную точку HTTP или через двоичный протокол «bolt». Neo4j в настоящее время является стандартом де-факто для графовых баз данных, используемых во многих отраслях.

Вообще, в се началось с небольшого разговора с Michael Simonis, одним из авторов Spring Data Neo4j 6 и сопровождающим Neo4j-OGM. Мы спросили Михаеля, что он думает о том, как Helidon и Neo4J могут работать вместе. Менее чем через час Михаель прислал мне ссылку на этот репозиторий с полнофункциональным примером для Helidon MP и Neo4j SDN.

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

Сравнить точность алгоритмов можно прямо сейчас на этой странице.

В конце будет краткая памятка по тому, где и когда лучше применять какой из методов. При правильном выборе можно добиться увеличения скорости вычислений в 5 раз при погрешности ~1%, а иногда и вовсе без неё.

Ранее я описал различные методы ускорения ваших Maven сборок. 

Сегодня я хотел бы расширить их область применения и сделать то же самое для сборок Maven внутри Docker.

• Заполни заявку на сайте;
• Получи подтверждение от рекрутера;
• Пройди техническое собеседование;
• Прими оффер в течение 48 часов и получи welcome-бонус!