Привет, ранее я написал статью о своем плагине и том, как переосмыслил подход к получению проектной модели Maven. И обещал более подробно рассказать о технических деталях реализации плагина и точках расширения IDEA, которые использовал.

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

Всем этим условиям удовлетворяют популярные билд-системы: Gradle, Maven, Sbt и не только, например Docker-compose. IDEA плагины для них построены на External System API. Поэтому для написания своего плагина, я также использовал данное API и хочу рассказать о нем более подробно.

Привет, сегодняшняя статья будет о некоторых тонкостях загрузки и инициализации классов и немного о производительности (совсем чуть-чуть и в самом конце).

Поводом для написания статьи стал вопрос на StackOverflow. Откройте, но не торопитесь читать ответ ;)

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

В статье я отвечу на эти вопросы.

Сколько времени это заняло?

Я начал готовиться за 2-3 месяца до собеседований в BigTech. В то время я тратил по 2-3 часа в день на подготовку.

В июле в офисе РСХБ-Интех (технологической дочки Россельхозбанка) состоялся бесплатный митап для Java-разработчиков — RSHB Backend Dev Meetup. Обсудили Kotlin, Go, маппинг и разные аспекты бэкэнд-разработки. В числе докладчиков выступал Иван Кочергин, руководитель центра собственной разработки РСХБ-Интех. Иван более 10 лет занимается разработкой на Java, последние три года — на Kotlin. В своем докладе он сравнил, на чем лучше писать микросервисы в банке: Java, Kotlin или Go. Делимся расшифровкой доклада. Запись всего митапа можно посмотреть на Rutube.

Всем привет! 👋 👋 👋

Мы — Java-разработчики Тинькофф: Константин, Андрей и Арсений. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и решили делиться этим не только с коллегами, но и со всем сообществом. 

Льюис Кэрролл писал: «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!» Надеемся, что поможем немного сберечь силы в этом марафоне всем читателям. Stay tuned! 😉

Redis на хайпе. Но мы переехали на него с Hazelcast не из-за этого, а потому, что в какой-то момент осознали, что не замечать сколько инцидентов у нас возникает из-за Hazelcast, дальше невозможно. Сегодня расскажу вам замечательную историю как мы всем Альфа-Мобайлом сменяли одну технологию на другую.

Разработчик проводит на порядок больше времени за чтением кода, чем за его написанием. Поэтому на код ревью мы чаще всего проверяем форматирование, нейминг, наличие тестов и т.п. В статье рассказано о нескольких неочевидных кейсах использования корутин, которые могут возникнуть при разработке Android приложения на kotlin и то, о чём ещё стоит помнить при проверке кода с их использованием. 

Эта заметка является переводом поста в блоге Дэвида Ханссона под заголовком «Even Amazon can't make sense of serverless or microservices». Здесь минимум редактуры для сохранения оригинальной авторской подачи.

Команда Prime Video из Amazon опубликовала довольно примечательное тематическое исследование, посвящённое их решению отказаться от своей микросервисной serverless-архитектуры и заменить её монолитом. Этот шаг сэкономил им ошеломляющие 90% (!!) эксплуатационных расходов, а также упростил систему. Какая победа!

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

Оркестрация — это убийство времени.

Сколько времени вы потратили на управление задачами в оркестраторе? Сотни часов? Тысячи? Независимо от того, что это было, такая деятельность была малоценной, и вы, вероятно, тоже так считали.

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

Привет, Хабр! Я Андрей Мещеряков, Android-разработчик в команде роста Тинькофф Инвестиций. Мы в Инвесте всегда стараемся пробовать новое и поддерживать современный стек технологий. Не обошли стороной и библиотеку Kotlinx.Serialization, которой сейчас пользуемся. Меня удивило малое количество русскоязычных публикаций по Kotlinx.Serialization, и я решил поделиться опытом Инвеста по миграции с Gson на Kotlinx.

Расскажу о подводных камнях, неочевидных моментах ее использования и проведу сравнение работы этих библиотек.

Всем привет! На связи Максим Смирнов, архитектор по фронтенду в Тинькофф. В серии статей будет история о том, как мы переписывали один из монолитных сервисов на Federation.

Расскажу о том монолите, который переписали, и как дошли до момента, что надо распилиться. Еще покажу, какие фишки мы накрутили в Module Federation, потому что из коробки многих фич нет, надо докручивать самим. Добро пожаловать под кат!

Blade Runner 2049, Warner Bros. Pictures

Я видел не во сне, а наяву атакующие корабли, пылающие под четырьмя вложенными if-else, и лучи CI с кучей сканирований у ворот Тангейзера, вызывающие лютую боль разработчиков. Меня зовут Максим Морев, и я техлид в Газпромбанке.

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

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

Однако минусы микросервисов настолько огромны, что это все равно, что отрубить себе правую руку, чтобы научиться писать левой; есть более управляемые (и менее болезненные!) способы достижения того же результата.

Даже с тех пор, как началось повальное увлечение микросервисами, возобладали некоторые более хладнокровные. В частности, Оливер Дротбом, разработчик среды Spring, долгое время был сторонником альтернативы moduliths. Идея состоит в том, чтобы сохранить монолит, но спроектировать его вокруг модулей.

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

SEDA, или Staged Event-Driven Architecture, представляет собой архитектурный стиль, предложенный Мэттом Уэлшем в его докторской диссертации. диссертация. Его основными преимуществами являются масштабируемость, поддержка высококонкурентного трафика и удобство эксплуатации.

В этом туториале мы будем использовать SEDA для подсчета уникальных слов в предложении с помощью двух разных реализаций: Spring Integration и Apache Camel.

"Отдайте этот функционал в другую системы - он относится к ним" - ворчал мой собеседник. Ему с пылом отвечали: "Так быть не должно. Мы сами должны его сделать!" Спор грозил затянуться до вечера. Ни одна из сторон не могла привести ни одного настоящего аргумента, почему новый функционал нужно поместить в ту или иную автоматизированную систему.

Проблема была в том, что никто не понимал как правильно делить системы на части и по каким признакам включать в них новые модули. У собеседников не было никакой единой простой методики.

Но методика на самом деле есть, и весьма неплохая. Называется она Предметно Ориентированным Дизайном (Domain Driven Design, DDD). С помощью DDD деление большой системы на (микро)сервисы становится простым и понятным.

Всем привет, меня зовут Дмитрий Гаевский, я руковожу созданием внутренней платформы для разработчиков в Тинькофф. Последние два года стали знаковыми для российской ИТ-отрасли с точки зрения «распаковки» тем о таких платформах. Крупные технологические компании начали делиться опытом, и сегодня я расскажу о нашем кейсе. 

Как для мобильных разработчиков менялся Android с 2014 года и до сегодняшнего дня? Казалось бы, можно просто открыть официальное описание каждой версии и узнать. Но интереснее не просто читать сухие чейнджлоги, а вместе вспомнить все и из отдельных фактов сделать общие выводы. 

В июне я выступил с докладом об этом на конференции Mobius, а теперь для аудитории Хабра публикую его текстовую версию. Если есть что добавить — пишите в комментариях!