Java *

Когда-то в мире был только Си. Или Бэйсик. Или Паскаль. Это если не считать ассемблер для КР580ВМ. И хотя в книгах можно было найти упоминание ещё и о Фортране, но уже тогда, вместе с упоминаниями, были и предостережения о не самом удачном выборе, если бы вам вдруг захотелось писать на этом языке. Так выглядел мир глазами школьника из СССР.

Начинать тогда предлагалось с Бэйсика. Журнал "Наука и жизнь" так прямо и указывал. А заодно предлагал серию статей, заменявших вводный курс программирования начинающим хакерам. Была, конечно, ещё и "Техника молодёжи" с её занимательно составленным введением в программирование, но только на программируемом калькуляторе. Сегодня, наверное, сложно себе представить, как можно было увлечься каким-то программируемым калькулятором, ведь все с детства привыкли к айфонам с андроидами, но в те стародавние времена, когда книг с фантастикой в местной библиотеке было мало, школьники как некое чудо воспринимали коротенькие фантастические рассказы в "Технике молодёжи", сопровождавшиеся показом, как можно самостоятельно рассчитать все манёвры главного героя около Луны и летавшей где-то неподалёку окололунной станции.

Так мы входили в АйТи. Или в IT? Ну тогда мы даже аббревиатуры такой не знали. А потом пришлось взрослеть.

Пройдя много собеседований, выяснилось, что довольно приличная часть собеседующих, спрашивавших или как-то затрагивавших тему транзакций и их работы, не знают как работают транзакции и что означает для разработчика термин изоляция. Вплоть до архитектора в одной очень большой российской компании, для которого выводы, использованные мною для формулирования решения при прохождении архитектурной секции оказались чем-то вроде бреда. Пока готовится вторая статья (Миллиард абитуриентов МИРЭА 2), можно отвлечься и разобрать тему, продемонстрировать разработчикам что означает для них I в ACID.

Добрый день, меня зовут Рустам Ахметов, я архитектор ГК Юзтех и интеграционной шины данных UseBus. В предыдущей статье я рассказывал о Kafka и её аналогах, а сегодня хочу рассмотреть NiFi.

Вы узнаете:

Доброе время!

Часть 2-я по открытому занятию нового учебного курса: реализация простого JWT через новый Spring Boot OAuth2 Resource Server (первая часть: Spring Boot 3.0 — готовимся заранее). Что такое JWT и зачем, писать здесь не буду - в сети материалов много, начинать знакомство обычно рекомендую с Википедии. А вот хорошая ссылка по реализации JWT+OAuth2. Здесь я привожу Java код, основанный на официальном примере spring-projects - простейшей реализации JWT Login Sample (без refresh token и отдельного авторизационного сервера), "творчески доработанный" и с моими пояснениями. Еще раз - без теории, для тех, кому интересен код актуальной Java реализации. Если это Вы - прошу.

Здравствуй, читатель Хабра!
До выхода Spring Boot 3 осталось совсем немного - 3 месяца. Уже появляются статьи -
What’s New, It's time to get ready. Недавно JetBrains выпустила IDEA с поддержка Spring 6 и Spring Boot 3. Самое время потренироваться заранее в миграции. В разработке нового учебного курса я попробовал перевести свой открытый учебный проект Spring Boot 2.x + HATEOAS на Spring Boot 3, шаги и код проекта ниже.

Периодически возникает желание получать уведомления, иметь возможность настраивать источник и фильтровать сообщения по темам, и писать как можно меньше кода. Например, присылать себе картинку/цитату/слово дня или дельту по изменениям ордеров на бирже. В результате получился универсальный инструмент - бот и персональное АПИ для отправки сообщений в Telegram.

В предыдущей статье, была рассмотрена модель данных, необходимая для хранения информации об абитуриентах. Теперь пришло время показать, как используя реляционные БД можно обрабатывать модифицирующие запросы от миллиарда абитуриентов. А что бы расставить все точки над i, предлагаемая архитектура должна обрабатывать миллион модифицирующий запросов в секунду. Используя реляционные БД, гарантировать, что все возможные комбинации обрабатываются за сутки для миллиарда абитуриентов, каждому из которых предоставляется 20 вариантов! С ростом числа абитуриентов требования по железу должны рости линейно.

Добрый день, меня зовут Рустам Ахметов, я архитектор ГК Юзтех и интеграционной шины данных UseBus. В этой статье я расскажу о нашем опыте разработки продукта и выборе технического стэка. Хочу добавить, что я буду давать лишь поверхностный Helicopter view на продукты и их аналоги.

Из статьи вы узнаете:

Описывается, как можно инициировать автообновление клиентов Spring Cloud Config Server без использования Spring Cloud Bus или какой-либо иной вспомогательной технологии

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

Поэтому я попытаюсь показать вам практический подход к чистому коду. Не вдаваясь в теорию, покажу, как я пишу Чистый Код.

Привет! Согласитесь, во многих крупных компаниях рано или поздно возникает проблема — какой-то прибыльный продукт превращается в legacy. Причем обычно менеджмент это осознает, когда хочет "просто" поменять одну цифру на другую к вечеру, а разработчики оценивают это в два спринта. Или когда разработчики один за другим теряют мотивацию и покидают продукт, а новые кандидаты выбирают другие офферы.

Часто эту проблему пытаются решить переписыванием продукта с нуля. Но переписывание с нуля кроет в себе отложенную проблему, так как можно потерять мелкие нюансы и в итоге переписанный продукт будет поначалу болеть "детскими болячками", которые много лет назад были вылечены в legacy. Мы, в АльфаСтраховании считаем, что все члены команды разработки должны понимать, что их материальный успех зависит от того, сколько компания зарабатывает, используя написанный ими продукт. А сколько денег принесет продукт, который постоянно спотыкается и плюется ошибками? И клиентов не удовлетворить ответами из серии: "Ну зато у нас тут микросервисы и неблокирующие стримы". Им важно, чтобы продукт работал быстро и стабильно. А написан ли он в виде скрипта на bash или в виде микросервисов на Scala, потребителям наплевать. Конечно, разработчикам не нужно забывать и о своём развитии — регулярно изучать новые технологии, получать опыт использования их в продуктиве, но не в ущерб бизнесу.

Что с этим делать? Мы нашли для себя ответ, успешно применили на одном продукте и надеемся что этот подход или его части помогут и другим.

Когда речь идёт о технологиях, позволяющих компьютеру написать часть кода за человека, разговор вечно соскальзывает в гадания на кофейной гуще. Уволят через десять лет всех программистов или нет?

Но вообще-то тут есть о чём поговорить помимо этих спекуляций, причём разговор может быть куда предметнее. Как все эти разнообразные «copilot» вообще работают (вот сейчас, а не через десять лет)? Какие сложности возникают при их создании? Где эти сложности можно преодолеть, а где есть принципиальные ограничения формата?

На конференции Joker об этом рассказывали Никита Поваров allfather и Роман Поборчий p0b0rchy. На момент доклада оба работали в JetBrains, так что получилось не просто абстрактное описание вопроса, а «взгляд изнутри» со стороны тех, кто делает инструменты для разработчиков.

• Славное прошлое
• Фантастическое настоящее
• Счастливое будущее

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

Единственное необходимое условие? Вы должны иметь приблизительное представление об ACID, то есть о том, что такое транзакции баз данных и зачем их использовать. Также здесь не рассматриваются распределенные транзакции или реактивные транзакции, хотя общие принципы, с точки зрения Spring всё же применимы.

Туториалы делятся на две больших категории: либо "как нарисовать сову", либо подробно расписанные тысячи шагов в формате "напиши туториал для дурака - и только дурак захочет его читать".

Как какой из двух категорий относится эта статья — решать вам.

В этой статье вы увидите пошаговое создание cloud-native микросервиса на Amazon AWS, пригодное для "чтения с листа". Чтобы понять, что здесь происходит, не нужно разворачивать проект - достаточно обладать живым воображением и прочитать текст по диагонали. Если же вы всё-таки захотите повторить шаги, вам будут жизненно нужны знания вида, как создавать классы в IDE и что такое Spring.

Вначале мы напишем пару простых микросервисов на Spring Boot, докеризуем их, зальём в AWS, настроим красивые доменные имена и HTTPS, прикрутим логирование и мониторинг, Prometheus и Grafana. Это небольшое путешествие по всем кругам ада, из которого вы не вернетесь прежним.

Текст написан на основе текстов и демо-проекта microservice-customer за авторством @kamaruzzaman. Если вы потеряли нить повествования, всегда можно зайти на GitHub и найти весь код в пригодном для запуска виде. Если захочется закопаться в тему, то бро Дима Чуйко (@Teapot) написал вам ещё две части статьи "Микросервисы: от CRUD до Native Image" (раз, два).

Последняя важная оговорка. В этом гайде будут использоваться технологии Amazon и обычные дистрибутивы OpenJDK. Автор осознает, что мы живём в России, и возможно, вместо Amazon куда лучше подойдет что-то вроде SberCloud или MTS Cloud, а вместо обычного OpenJDK - Axiom JDK с сертификацией по ФСТЭК. Особенности российских технологий - тема для отдельной статьи. Если вы захотите таковую после чтения этого гайда - отметьтесь в комментариях.

Представим ситуацию – вам надо сделать небольшой отчет на основе данных из другой системы. Звучит обыденно и вы сразу в голове представляете, что надо будет делать: узнать какие будут входные данные и в каком виде они к нам поступят, какая будет логика отчета (что на что надо умножить и т.д.) и в каком виде отчет должен быть представлен (график, диаграмма, таблица и т.д.), реализовать.

Но что, если я вам скажу, что это должна быть не какая-то новая система, а плагин для Jira. Все вышесказанное никуда не уходит, но добавляются нюансы. Вот о таких нюансах (и как не вылететь из-за них из всех разумных сроков) эта статья.

Когда изменения затрагивают несколько микросервисов, возникает вопрос, как протестировать их в связке. Можно покрыть границы сервисов юнит тестами, а интеграцию проверить, развернув измененный код на тестовом окружении. У такого подхода две главные проблемы: цикл изменения-тестирование-исправления становится достаточно долгим и нужно много полноценных окружений, чтобы обеспечить параллельную работу нескольких разработчиков. Давайте попробуем решить проблему иначе.

Будем решать проблему последовательно, по шагам преодолевая возникающие трудности.
Код можно найти на GitHub. К каждой части будет ссылка на ревизию.

В этой статье я расскажу про исключительную ситуацию, которая произошла с одним исключением в продакшене нашего Android приложения.

Какой есть общий недостаток у мобильной, front-end и back-end разработки и иногда распила микросервисов? Дублирование логики. Очень часто я видел статьи или новости, где одна команда мобильных разработчиков ждет другую, чтобы выкатить релиз. И если с мобильными версиями более-менее все понятно и есть решения, то что делать с браузером? Очень часто логику работы приложения нужно поддержать и там.

Что делать, если хочется писать нативный код и при этом не иметь дублей реализации — на этот вопрос я постараюсь ответить подробно в данной статье. В процессе чтения можно будет познакомиться с технологией Kotlin Multiplatform и создать полноценный проект всем известной игры «Крестики-нолики» на трех самых популярных платформах Browser (JS), iOS (Swift) и Android (Java) с общей логикой на Kotlin.