Путь разработчика долог и порой тернист. Но когда ты идёшь от junior к middle, всё понятно — есть задачи, старшие наставники, миллионы курсов. Движение от middle к senior уже сложнее. Теперь не ты обращаешься к коллегам за советами, а всё чаще они приходят к тебе. Но вот ты senior. Дальше можно менять предметную область или язык.

Но я предложу ещё несколько вариантов. Если есть желание (и умение) организовывать работу других, это прямая дорога к управлению командами. А если нет? И вот на этой развилке возникает вариант для тех, кто хочет максимально закопаться в свою сферу. Это путь архитектора: системы, решений, кластера и так далее.

В этой статье я расскажу про суть работы архитектора решений. Перейдём к знакомству?

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

Меня зовут Варвара Фролочкина, я работаю менеджером направления концептуального проектирования инициатив в дирекции по архитектуре Х5 Tech. Хочу рассказать о том, как выглядит процесс согласования архитектурных решений в нашей компании и какие вообще архитектурные решения у нас существуют. И постараюсь объяснить, почему же так важно обращаться к архитектору на самом раннем этапе проекта. 

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

Большая подборка для аналитиков данных, продуктовых аналитиков, веб аналитиков, маркетинговых аналитиков и особенно тех, кто хочет ими стать. От автора Telegram-канала «Аналитика и Growth mind-set».

Но прежде несколько важных моментов:

Я работаю бизнес-аналитиком. Создание диаграмм последовательностей (sequence diagram) – часть регулярной рутины. Всё классно. Но процесс правок…

К счастью, я нашел для себя решение. Теперь я не рисую sequence diagram, а пишу "кодом". Это легко, быстро и удобно.

Если возникает вопрос об описании архитектуры системы, то есть несколько основных решений где и как это сделать. Среди популярных нотаций для визуализации схемы архитектуры можно выбрать C4, разработанную Саймоном Брауном.

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

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

Сравнительный анализ Apache Kafka и RabbitMQ

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

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

В этой статье мы рассмотрим 10 лайфхаков мобильного UX/UI дизайна, которые помогут создать действительно эффективные и приятные для пользователя мобильные приложения.

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

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

Что еще? Думаю что надо как то договорится о подаче материала. Здесь, как и в первой статье, я рассмотрю конкретный пример из своей практики, который, как мне кажется, максимально точно иллюстрирует специфику работу данного специалиста. Как и раньше, в заключении, попробую ответить на следующие вопросы: кто такой Системный Архитектор, какими навыками должен обладать и т.д. Поехали? 

И последнее, думаю, надо представится. Меня зовут Владимир Воловиков. Опыт работы в сфере разработки программного обеспечения более 20 лет. В должности Системного архитектора и Программного архитектора, в общей сложности, более пяти лет. Имею четыре международных сертификата. Текущее место моей работы Системный архитектор, Банк ВТБ. 

При реализации потоковой обработки и анализа данных может возникнуть необходимость агрегирования записей для объединения нескольких независимых поток данных или обогащения какой-либо модели данных. Для этой цели может использоваться Kafka Streams, которая позволяет выполнять обработку данных в режиме реального времени. 

В этой статье мы рассмотрим основные компоненты Kafka Streams и теоретические аспекты их использования. Мы будем использовать последние версии технологий, доступных на сегодня: Kafka 3.4.0 и Java 17 в качестве языка программированию. Для снижения входного порога мы будем использовать только нативные возможности Kafka и Kafka Streams, и не будем рассматривать решения с использованием различных фреймворков вроде Spring.

Вопрос выбора СУБД для российской компании или госоргана – вопрос не праздный, тем более сейчас – когда с момента ухода с рынка западных вендоров прошло уже полтора года и пора что-то решать. Но как не запутаться в номенклатуре СУБД и выбрать ту, которая лучше всего подходит? Без ложной скромности скажу: мы в «Кругах Громова» уже немного поднаторели в систематизации, поэтому надеемся, что наша шпаргалка для тех, кто хочет выбрать СУБД, окажется полезной.

Начнем с классики. СУБД делятся на несколько типов. Не будем описывать их подробно, остановимся только на их основном предназначении.

Привет! Меня зовут Настя, я системный аналитик в X5 Tech. В этой статье хочу поделиться своим опытом создания чек-листа для технического задания (далее – ТЗ), какие ошибки совершала на начальных этапах работы над продуктом, и как сформированный чек-лист помогает мне уже на протяжении трёх лет. Такой чек-лист может пригодиться не только для самостоятельной работы над ТЗ, но и как инструмент проверки уже готового документа.

Статья будет полезна, как мне кажется, системным и бизнес-аналитикам, владельцам продуктов и тем, кто работает с разработкой требований.

API (Application Programming Interface, программный интерфейс приложения), является жизненно важным компонентом в современном ландшафте разработки программного обеспечения, обеспечивая строительные блоки для взаимодействия приложений друг с другом. В этой статье рассмотрим пять основных типов API: REST, SOAP, WebSocket, gRPC и GraphQL, чтобы получить более четкое представление об их функциях, особенностях и идеальных сценариях использования.

Apache Kafka де-факто превратился в стандарт потоковой передачи событий для обработки данных на лету. По мере его широкого распространения в отрасли появляются вопросы: «А когда НЕ нужно использовать Apache Kafka? Какие ограничения у этой платформы? В каких ситуациях он не предлагает необходимые возможности? Как понять, что Kafka — неподходящий инструмент для какой-то задачи?»

В статье, перевод которой мы подготовили, автор Kai Waehner постарается ответить на эти вопросы. В отдельных главах приводится объяснение, когда стоит использовать Kafka, когда — нет, а когда — возможно.

__1. Давайте подумаем, какой уровень у человека, который читает английскую классику почти без словаря?

Я был таким человеком в 2008 году, когда приехал в частную школу английского языка в Лондоне. В школе были группы семи уровней: Beginner, Elementary, Intermediate (и Pre- и Upper-), Advanced, Advanced+. После тестирования меня определили в группу Advanced+. Наверно, у меня было что-то в районе Proficiency, C2?

Ребята-казахи из группы Pre-Intermediate как-то посмеялись надо мной в пабе, потому что меня официант не понял, а их – без проблем. А ещё я не знал некоторых простых разговорных выражений, которые знали люди из групп Intermediate и даже ниже, поскольку в предыдущие пять лет делал упор на чтение классической литературы. И ещё очень, ОЧЕНЬ плохо понимал живую речь на слух. Похоже на С2?

А какой уровень у человека, которого чуть не застрелила полиция в США потому, что он не смог разобрать на слух простые слова “the police”?  Это произошло со мной в 2012 году в городе Чарльстон, Южная Каролина. На тот момент, кстати, я как профессионал вырос на голову по сравнению с 2008 годом и уже успел поработать переводчиком. А ведь реально написали бы потом, что был он иностранец, плохо знал язык. Справедливости ради, “the police” проорал афроамериканец с характерным выговором, в гражданской одежде, из автомобиля без полицейской маркировки (“undercover police” это называется).

В бюро переводов обычно есть отдел редакторов, где сидят довольно серьёзные профессионалы. Они проверяют уже сделанные переводы на наличие ошибок перед тем, как отдать заказчику. В том бюро, где работал я, в отделе редакторов был мужчина, который спокойно признавался, что очень плохо говорит и почти не воспринимает на слух бытовую английскую речь. Хорошо, что плевать он хотел на то, какой у него «уровень», а то б, наверно, уволился с работы и впал в депрессию.

Я использую Архимейт в своей работе уже более 7 лет. Когда я познакомился с этим языком, то он привлек меня тем, что позволял изображать систему в динамике, то есть отображать не только структуру программы, но и бизнес-процессы, которые она автоматизирует, и средства, на которых она развернута. К тому же Архимейт казался очень простым — подумаешь, каких-то 10 стрелок и 20 компонентов. На тот момент я был уже очень опытным программистом и архитектором, у меня был огромный опыт проектирования систем и баз данных, также я на приличном уровне освоил несколько языков программирования. И казалось, что выучить такой простой язык — это дело нескольких часов.

Но как же я был не прав: приличные Архимейт модели у меня стали получаться только через 3 месяца, а спустя год я понял, что всё, что я рисовал ранее — хорошо бы перерисовать. Но вот почему Архимейт оказалось освоить совсем не так просто?

Друзья аналитики и ценители данных!

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

Сейчас я также руковожу отделом аналитики в IT-компании и выступаю в роли PM по внедрению BI-систем и построению DWH. Хочу начать делиться своим опытом, фактами и советами о том, как аналитику выстроить карьеру в этой сфере. В будущих статьях смогу подробно рассказать про Data Governance, поделиться опытом внедрения аналитических систем в различных компаниях и о том, как избежать типичных ошибок в аналитике.

Поехали разбираться вместе! Это моя первая статья на Хабре, и я рада поделиться своими знаниями и опытом с этим замечательным сообществом.

Бизнес-аналитик - мастер переговоров или как не сойти с ума, работая с требованиями

Представьте, что вы - бизнес-аналитик в консалтинговой компании, и перед вами стоит задача внедрить систему бизнес-аналитики (BI) для клиента, чей проект продаж страдает от разобщенности и несогласованности. Каждый отдел в этой компании считает ключевые показатели по-своему, используя свои методики и инструменты. Отдел продаж фокусируется на выручке и конверсиях, финансисты - на марже и затратах, а маркетологи оперируют такими метриками, как ROI, CAC и LTV.

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