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

Данный проект рассматривается как pet-project. Любую критику и советы готов увидеть в комментариях.

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

Репозиторий с исходным кодом: https://github.com/theartofdevel/notes_system

Видео версия: https://www.youtube.com/watch?v=Txi95RQPRP0

Под катом текстовая расшифровка.

Предисловие Около года назад я задался целью получить оффер от FAANG. Как следствие, постоянной частью моей жизни стали тематические форумы, площадки и вся сопутствующая атрибутика. Спустя какое-то время я попробовал себя на собеседованиях в околоFAANGoвые компании: Lyft, Spotify, Booking и т. д, где-то успешно, где-то не очень. В это же время мне порекомендовали попробовать пройти собеседование в Тинькофф банк, который внедрил схожий процесс. После стандартного общения с HR менеджером была получена ссылка на описание процесса собеседования. “Хм, почти что FAANG + тех. интервью по Primary Skill”, - подумал я и сказал, что готов приступать. В тот же час было назначено 2 интервью: техническое и coding, а вот 3 этап, system design, нужно было заслужить успешным прохождением первых двух. Почему именно эти 2 части являлись основополагающими, осталось неясным.

Акт первый, технический

В назначенный час я встретился со своим интервьюером. Собеседование выглядело “добротным” и стандартным в заданной проф. области, оттого местами скучным. Было много задач на ревью кода и обсуждения специфики языка, в частности...

Очередная история успеха после череды неудач. Расскажу, чего мне стоило получить офферы от Facebook*, Google, Amazon, JP Morgan в Европе, как я готовился, сколько собесов зафейлил перед тем, как удача повернулась ко мне правильной стороной.

TL;DR. Послал сотни резюме. Прорешал около 100 задач на Leetcode. Прочел книжку по архитектуре (не той, которая про дома, а той, которая system design). Прошел 9 интервью. Получил 4 оффера. Принял 1. Жил, пока что, не очень долго, но, вполне себе, счастливо в Лондоне.

Декабрь 2020, вторая волна Ковида в разгаре. Я ПМ на удаленке в Американской компании. После похорон отца в Тбилиси я находился в прострации, надо было возвращаться в США и как-то менять своё положение, ведь денег, которых я зарабатывал явно не хватало на нормальную жизнь. Сами воспоминания о моём предыдущем поиске вызывали во мне холодный озноб и какой-то внутренний голос тихо шептал «подожди, сейчас пандемия, многие и о таком мечтают, как-нибудь выкрутишься…».

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

Я зарегистрировал себе американский номер в Google Voice, чтобы мне начали звонить рекрутеры и начал рассылать резюме. Я разослал около сотни адаптированных резюме и указал в LinkedIn что активно ищу работу. Постепенно на меня начали выходить рекрутеры небольших компаний, но я понимал, что в них условия будут в лучшем случае на 40% лучше текущей и это все равно не решало моих проблем. Хоть и казалось, что на LinkedIn висят тысячи позиций, однако основных работодателей я этим исчерпал. Подавался я в основном на Sr. Project Manager или Engineering Manager позиции.

Осознание пришло, когда я стал читать teamblind.com – лучший ресурс в США по анализу рынка в ИТ и levels.fyi где можно посмотреть реальные зарплаты. Раньше я читал Glassdoor, но информация на нем устарела.

Оказалось, что в финансовой сфере в США, которая мне была интересна - плохие условия и токсичная культура, тоже самое в консалтинге кроме компаний из Big4 или MBB где надо работать долгие часы, но возможно получать 1+ миллион долларов в год дослужившись до партнёра. Самыми интересными оказались компании, которые называют FAANG (Fb, Apple, Amazon, Netflix, Google) иногда в место этого списка используют FAANGMULA справедливо добавляя туда Microsoft, Uber, Lyft и Airbnb – все они технологические, инновационные компании не просто создающие бизнес-продукты, но и технологии, которыми пользуются весь мир. Компании, создающие де-факто стандарты разработки цифровых продуктов, инвестирующие в научные исследования, создающие легендарные условия для своих сотрудников, чем привлекают умнейших инженеров и ученных со всего мира.

При переходе с Java на Kotlin многие вопросы приходится решать заново, а точнее по-другому. Два года назад мы начали социальный Open Source проект BrainUp на Kotlin, который сейчас акивно развивается, а мы узнаем на практике что значит Kotlin и его эко-мир, какие удобства он вносит в нашу жизнь, разработчиков, и какие вопросы, задачи встают по-новому.

Привет, Хабр. Меня зовут Аня, я аналитик, в прошлом году устроилась на работу в крупное digital-агентство, которое называть нельзя из-за NDA. Там я попала в непростую ситуацию. Бо́льшую часть нашей команды решили отправить на обучение в другой город. Все расходы на командировку — билеты и гостиницы — надо было самостоятельно оплатить с последующей компенсацией. Билеты купили, гостиницу забронировали, но учёбу в последний момент отменили из-за роста заболеваемости коронавирусом. А вот компенсации пришлось ждать несколько месяцев. Я уже не работаю в той компании, но вопросы остались: как же нужно выстраивать обучение сотрудников? Кому это нужно больше? И кто за это должен платить? Попросила руководителей IT-компаний ответить.

Здравствуйте! Сегодня я хочу поведать вам свой путь становления как разработчика. Сейчас, на волне множества курсов и вездесущей рекламы «как войти в IT», много людей устремилось в эту бескрайнюю, интересную и очень непростую область. Я написал эту историю для них и для себя. Как некоторый взгляд в прошлое. На всё, что было сделано и чего это стоило. Кому интересно, прошу под кат.

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

Эта статья является выжимкой ключевых фактов из целого ряда кейсов (и клиентских, и собственных) за последние 4 года. В основном расскажу о том, где мы набивали шишки, и помогу вам избежать этого на своем пути. Статья будет полезна, как владельцам/менеджерам, так и маркетологам.

Этот текст не для разработчиков, не для тестировщиков и даже не для product-менеджеров. Сегодня мы обсудим тему, которая интересует HR.

В Kolesa Group мы регулярно ведем поиск кандидатов на IT-позиции и хорошо представляем, как чувствуют себя HR в мире IT.

Когда вы пишете кандидатам десятки писем в день, но отвечает вам кто-то один, мы понимаем эту “боль” и хотим порассуждать насчет этого.

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

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

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

Любите Spring? А Spring Data? Я тоже люблю. Если хотите разобраться, почему же возникает этот unexpected transaction rollback, а также быть уверенным, что транзакция отменится, а не закоммитится, добро пожаловать под кат.

В статье я хочу поделиться своим опытом достижения нулевого даунтайма ответа одного из API, использующего большой индекс ElasticSearch.  Эта статья будет полезна тем, кто уже использует ElasticSearch и не может позволить себе ни минуты простоя, а один из ваших индексов продолжает расти. Также будет полезна тем, кто работает над ускорением наполнения индекса или пытается сформировать группу индексов, например несколько индексов для разных городов или стран.

Столкнулась наша команда с двумя из описанных выше проблем: ускорение наполнения и обеспечение минимального даунтайма ответа API. Все это случилось довольно быстро, когда количество потенциальных документов для индексации стало превышать 1 млн записей. До этого момента проблема решалась оптимизацией кода и запросов в БД. Конечно, подготовка такого объема данных и формирование индекса занимает не один час. Усложнило задачу то, что индекс использовался в нескольких ключевых API системы, которыми пользуется мобильное приложение, компании, имеющие интеграцию с нашим сервисом, внутренние инструменты технической поддержки. Над индексом постоянно выполняются CRUD-операции.

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

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

Но если брокер такой как у меня - Interactive Brokers (организация, третьего дня запрещенная на территории РФ), декларацию вам придется делать и подавать самому. Делать это всем, конечно же лень, и неплохо бы отдать подготовку на аутсорс...

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

В качестве прикладного дополнения к рассуждениям мы разработали несколько Proof of Concept, сопроводили их разработку краткими пояснениями и приложили исходный код PoC.

Пожалуй, многих хотя бы раз посещала мысль поделиться своим опытом. Помочь коллегам и подрастающему поколению собранными граблями, изложить сообществу любопытные (а может и поворотные, как знать!) идеи, оставить что-то “после”.

Книга, опыт выпуска которой и послужил источником данного материала, в статье ранее https://habr.com/ru/post/512460/ набрала тысячи скачиваний и десятки благодарных отзывов. 

Для тех, кто хочет узнать, как работает книжное дело сейчас, выкладывать ли онлайн самому или сотрудничать с издательством, сколько получают авторы, как попасть на полки Буквоеда, Читай-города, в главные интернет-магазины, и все ли решают лайки — прошу:

Улучшения языка Java, которые вам следует знать

Последнее обновление 30.03.2021, чтобы включать изменения до JDK 16.

Когда в Java 8 были представлены Streams и Lambdas, это было большим изменением, позволившим использовать функциональный стиль программирования с гораздо меньшим количеством шаблонного кода.

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

* В данной статье примеры будут на TypeScript

Краткое предисловие

Что такое DDD (Domain Driven Design) вопрос обширный, но если в кратце (как Я это понимаю) — это про перенос бизнес логики, как она есть, в код, без углубления в технические детали. То есть в идеале, человек, который знает за бизнес процессы, может открыть код и понять, что там происходит (так кстати часто бывает в 1С).

Всё это сопровождается кучей разных рекомендаций по технической реализации вопроса.

Для лучшего понимания статьи советую прочитать материалы, касающиеся DDD.