Архитектура: искусство делать излишнее необходимым.

Фредерик Кислер

Наверняка у многих бизнес-аналитиков есть цель использовать особые артефакты: Impact Map, CJM (Customer Journey Map), USM (User Story Map). Особые, т. к. не так часто они встречаются в бизнес-требованиях, и даже бывалый аналитик может с непривычки растеряться, если не создаёт их каждый день. 

Меня зовут Ирина, я ведущий бизнес-аналитик с более чем пятилетним опытом. Сейчас работаю в X5 Tech в направлении “Цепочки поставок”.

В статье описываю общие принципы построения Impact Map, CJM и USM и вариации их использования не только на примере своих рабочих кейсов, но и на бытовых примерах (буквально на жареной картошке и строительстве дома). Для опытных специалистов разобранные примеры пополнят копилку насмотренности. А для новичков в бизнес-анализе статья будет полезна с точки зрения постижения азов.

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

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

Николай Лобачевский и в 2024 году может сотворить нечто неожиданное. Так, он подарил российским математикам новую дату — их профессиональный праздник уже с этого года начнут отмечать 1 декабря. Именно в этот день в 1792 году родился Лобачевский, один из первооткрывателей новой геометрической системы — неевклидовой.

На самом деле Нижний Новгород — родина, место обучения и город, в котором зарождались теории и открытия многих выдающихся математиков. Одни из них хорошо известны каждому. Другие — только профильным специалистам. Которых, кстати, в городе немало — их для отечественных технологических гигантов на высоком уровне готовят 10 региональных вузов. И сегодня они вместе с физиками и информатиками составляют костяк местного бурно развивающегося ИТ-сообщества.

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

Меня зовут Олег, я уже 20 лет работаю в ИТ и в основном на Enterprise-проектах. Сейчас работаю в Альфа-Банке на проекте Альфа-Онлайн и хочу поделиться своим видением управления сложностью на больших проектах.

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

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

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

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

Привет, Хабр!

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

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

htmx — инструмент для создания сложных и интерактивных веб-приложений на HTML, альтернатива клиентскому рендерингу на Javascript. В этой статье рассказываем, как библиотека помогает переиспользовать элементы на сервере, сократить объем кода на Javascript и отказаться от сборки.

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

Введение

Уверен, что заголовок вызвал здоровую реакцию — “ну опять началось…” Но позвольте завладеть вашим вниманием на 5-10 минут, и я постараюсь не обмануть ожидания.

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

Для того, чтобы была ясность в том, что такое RPC, предлагаю рассматривать стандарт JSON-RPC 2.0. C REST ясности нет. И не должно быть. Все, что нужно знать о REST — он неотличим от HTTP.

В последнее время GraphQL набирает всё большую популярность. Изящный синтаксис запросов, типизация и подписки.

Кажется: "вот оно — мы нашли идеальный язык обмена данными!"...

Я разрабатываю с использованием этого языка уже больше года, и скажу вам: всё далеко не так гладко. В GraphQL есть как просто неудобные моменты, так и действительно фундаментальные проблемы в самом дизайне языка.

С другой стороны, большая часть таких "дизайнерских ходов" была сделана не просто так — это было обусловлено теми или иными соображениями. По факту, GraphQL — не всем подойдет, и может оказаться совсем не тем инструментом, который вам нужен. Но обо всём по порядку.

Кажется в кино кризис — хороших фильмов один на сотню. Могу предложить один сюжет — психологический триллер. Сценарий для него будет начинаться со строк: «Была у нас одна легаси-система. Монолитная. И задумали мы провести миграцию...»

Чем отличается Telegram от других популярных мессенджеров? Он — открытый!
Другие мессенджеры тоже имеют API, но почему-то именно телеграм известен как наиболее открытый из самых популярных?

Начнем с того, что у Telegram действительно полностью открытый клиентский
код. К сожалению, мы не видим комиты каждый день прямо на GitHub, но у нас есть код под открытой лицензией. Архитектура Telegram подразумевает, что и Bot и API имеет практически такие же методы — https://core.telegram.org/methods.

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

Обновлённая поддержка прокси-серверов в клиентах Telegram

• Новый MTProto-прокси. Работает с родным для Telegram протоколом MTProto
• Открытый исходный код сервера на GitHub
• Docker-образ на DockerHub
• В мобильных клиентах появилась возможность добавлять несколько прокси-серверов каждого типа. Пользователь может выбрать наиболее подходящий