Привет, Хабр! Мой путь в мире IT официально начался относительно недавно: в октябре 2025 года. До этого программирование вообще не выходило за рамки увлечений. Но однажды я решил испытать удачу и выйти на тропу приключений, после которой я уже не вернулся прежним...
Привет, Хабр! Когда-то совсем недавно я, (пока что) зеленый джун, узнал о таком интересном языке, как Brainfuck. Даже не языке, а так, "язычке", с 8 командами. 8-битные лимиты чисел (т.е. не может обрабатывать числа больше 255), а синтаксис и процесс кодинга такой, что и тимлид там ногу сломит. Увидев сие чудо 1993 года (динозавер), меня постигла безумнейшая идея провести один веселый вечер за компов, породив полноценный калькулятор, использовав BF-код для вычислительных мощей в своей забавной разработке. Но сначала давайте по порядку...
Типовая ситуация: в проект приходят умные люди, менеджеры внедряют эффективные процессы, а проект все равно превращается в болото. Фичи разрабатываются месяцами, релизы откладываются, а на ретроспективах все жалуются на зависимости. При этом на схемах все выглядит красиво: микросервисы, CI/CD, облака. Что с этим миром не так?
Понятно, что «не так» может быть что угодно и как обычно it depends, но здесь и сейчас разберем одну из возможных причин, а именно ситуацию, при которой архитекторы и техлиды работают только с одним видом сложности – технологической. Рисуют квадратики, проводят стрелочки, выбирают базы данных. Реальность разработки при этом гораздо сложнее: в любом проекте одновременно живут три вида сложности, и они постоянно влияют друг на друга.
Привет, Хабр! Меня зовут Игнатий Цукергохер, я фриланс-журналист и блогер. На Хабре в основном пишу про технику и выкладываю интервью, но решил вернуть рубрику обзоров мероприятий. И начну с такой камерной и при этом хардкорно-айтишной встречи, как True Tech Arch #8.
От корпоративной ИТ-архитектуры сегодня ждут скорости, устойчивости и понятной ценности для бизнеса, но она все еще часто существует в виде схем, презентаций и документов, которые быстро устаревают и мало помогают в ежедневной работе команд. На конференции True Tech Arch #8, последней встрече Гильдии архитекторов MWS в 2025 году, рассказывали, как выбраться из этого замкнутого круга.
В этом материале расскажу про основные темы, которые на ней поднимались: переход от Big Data к Small Data и Data Lakehouse, способы превратить архитектуру в исполняемую и измеряемую систему, а также изменение роли архитектора и коммуникаций между командами при внедрении AI-ассистентов.
Привет, Хаброжители! Мы хотим поделиться с вами главой из книги «Машинное обучение. Проектирование систем от идеи до реализации» Валерия Бабушкина и Арсения Кравченко. Это подробное пошаговое руководство, призванное помочь вам на всех этапах разработки ML-системы: от сбора информации и выполнения предварительных шагов до разработки, запуска в эксплуатацию и последующего сопровождения.
Как следует из названия, книга посвящена именно проектированию ML-систем. Мы не сосредоточиваемся на какой-то одной технологии, а предлагаем универсальный фреймворк для решения задач, связанных с созданием, сопровождением и совершенствованием ML-систем различного масштаба и сложности.
Переход из одной большой компании в другую — обычная практика. Такие трансферы далеко не всегда связаны с проблемами на старом месте работы, иногда они просто помогают расширить или углубить экспертизу, разобраться в новых задачах и вырасти в заработке.
Хабр, привет! Меня зовут Раф, я работаю аналитиком ценообразования в Авито (а раньше — в Яндекс Лавке), преподаю машинное обучение в Центральном университете, окончил факультет компьютерных наук в НИУ ВШЭ и прошёл курс «Специалист по Data Science» в Яндекс Практикуме. В этом материале расскажу, как переходил из Лавки в Авито и к чему стоит быть готовым аналитикам, которые захотят повторить мой опыт.
Всем привет! Меня зовут Кирилл Грищук, я Tech Lead в команде Инфомодели в Авито. Мы развиваем платформу объявлений и их характеристики.
В предыдущей статье я рассказал, как мы строим отказоустойчивые системы при работе с многомиллионным трафиком.
В этой статье рассказываю, почему, даже когда всё падает, никто этого не замечает. Статья будет полезна всем, кто хочет погрузиться в проблему раздачи и обработки редко изменяемых данных.
ЭТО - НЕ ПРО ОШИБКУ КАДРОВ. Это про систему, где клиническая неспособность становится культом, а профессиональный кретинизм возводится в ранг гениальности. История о том, как в команду внедряют "ментального инвалида" на позицию продакта, и его начальник - сентиментальный идиот наверху - с благоговением принимает этот дефект за "нестандартное мышление".
Вы узнаете, как любая тупость - от предложения "сделать всё зелёным" на сложном техсовещании до полного игнорирования переписок - магическим образом превращается в "фокусировку на сути" и "созерцательную мудрость". Как молчание выдаётся за работу на "прорывных глубинах", а реальные победы команды, добытые вопреки и без него, нагло присваиваются этому "тихому гению".
Мы разберём наркотическую зависимость начальника от такого подчинённого: пустой сосуд, в который можно лить любой бред, не боясь вопросов или критики. И доведём ситуацию до логического абсурда - до сцены награждения, где "Лучшим сотрудником года" становится пустое место в дорогом свитере, а вкалывающая команда давится тошнотой.
В финале - не жалость, а чёткий, безжалостный алгоритм выживания. Ваше профессиональное достоинство не должно сгореть в костре, разожжённом восторженными идиота́ми. Эта статья - инструкция по тушению.
Задумывались ли вы когда-нибудь, с чего на самом деле начинается великая игра? Не с первой строчки кода. Не с первого полигона модели. И даже не с концепт-арта. Она начинается с мысли, которая была поймана и пригвождена к бумаге.
В индустрии принято много говорить о развитии технологий. Мы знаем всё об эволюции движков, о войне консолей и о том, как за считанные десятилетия пиксели превратились в фотореалистичные пейзажи. Но у нас есть огромное слепое пятно. Мы почти ничего не знаем об эволюции мысли. О том, как развивался сам способ вынимать абстрактную идею из головы и превращать её в систему, которую можно не только почувствовать, но и построить. Мы научились создавать логические мосты между нашим “я хочу, чтобы игрок ощутил это” и техническим “система должна работать вот так”, превращая эфемерные мечты в понятные инструкции для других людей.
Сегодня мы называем этот инструмент просто и почти до зевоты скучно — Гейм-Дизайн Документы.
4000 строк в одном MR. Три часа на ревью, 12 замечаний, исправления - ещё 800 строк. На четвёртом заходе я закрыл вкладку и понял: проблема не в коде, а в том, что никто не знал, что именно нужно было написать.
Если ты работаешь с большими кодовыми базами, ситуация знакомая. Большие MR - симптом. Когда непонятно, чтоименно нужно сделать, разработчик пишет больше кода, чем требуется. Добавляет на всякий случай. Покрывает сценарии, которые никто не просил. MR растёт не потому что задача большая, а потому что границы размыты.
Другая причина — иллюзия, что проще сделать всё в одной задаче, чем декомпозировать. Кажется, что разбиение создаёт лишнюю работу. На практике монолитный MR на 4000 строк никто не может нормально проверить, и баги просачиваются в продакшн.
Мне был нужен инструмент, который позволил бы описать наши сервера, описать какие приложения на них запущены, как всё это связано между собой, как делаются бэкапы баз данных и так далее. Если бы я был DevOps, то наверное написал бы для этого Terraform конфиг. Но я архитектор, поэтому визуальные схемы мне ближе. В итоге мы скрестили ежа с ужом (ArchiMate с AWS Cloud Notation) — если вам интересно что получилось или вам интересно как в принципе создаются новые языки моделирования, то добро пожаловать в статью.
Привет, Хабр! Меня зовут Грищенков Евгений, я системный аналитик Fix Price. В этой статье расскажу о собственном приложении FixMark. Отгрузка в коробках уменьшает затраты на транспортную и складскую логистику. Для маркировки коробок используются общепринятые SSCC-коды (сокращение от Serial Shipping Container Code), которые облегчают отслеживание грузов и помогают автоматизировать логистические операции, позволяя идентифицировать грузы на всех этапах транспортировки. Фактически один SSCC-код агрегирует данные о штрих-кодах всех товаров внутри коробки, позволяя проводить операции со всем содержимым через одно сканирование.
Мы в Геоинтеллекте любим геоданные и геоаналитику. Часто миксуем технологии. Вот, например, мы попробовали генерировать графики BI системы DataLens внутри платформы для Геоаналитики “Геоинтеллект”. Что из этого вышло, посмотрим на реальном кейсе, которая выполняла наша сотрудница.
Задача
Предположим вы, как аналитик, хотите понять, где выгоднее всего искать помещение для открытия пункта выдачи заказов маркетплейса. Для этого нужно обратить внимание на ряд факторов, которые влияют на выбор:
Звучит знакомо, когда пытаешься объяснить или понять процессы, но при просмотре диаграмм, которые их представляют, в итоге запутываешься в куче стрелок и квадратов? 😥 Несколько дней назад я наткнулся на очень интересное исследование, которое объясняет, как мы можем использовать языковые модели, чтобы упростить эту работу. По мере роста и усложнения организаций их бизнес-процессы тоже становятся сложнее. При составлении диаграмм этих процессов модели обычно становятся более детализированными и трудными для понимания — до такой степени, что может понадобиться больше одной чашки кофе ☕️, чтобы их разобрать.
В этом посте я хочу суммировать для вас это исследование и показать, как LLM могут стать вашими союзниками в распутывании этих диаграмм и превращении их из запутанных украшений в полезные инструменты. Если хотите углубиться, оставлю ссылку на оригинальное исследование: Leveraging Large Language Models for Enhanced Process Comprehension.
Идея простая, но мощная: сочетание абстракции моделей процессов с техниками промптинга, чтобы ИИ мог анализировать и интерпретировать диаграммы более ясно и эффективно. Кроме того, я поделюсь кодом, чтобы вы могли поэкспериментировать сами и открыть новые применения. Поехали! 🛠️✨
“Надо увеличить ценность нашего продукта!” - фраза, которую произнес, пожалуй, каждый продакт хотя бы раз за свою карьеру. Эта фраза уже так набила оскомину, что уже потеряла всякий смысл.
А вот такой фразой “это не увеличивает ценность продукта для пользователей” отшиваются многие неугодные инициативы будь-то от команды или от СЕО.
Но что скрывается за этим мифическим термином “ценность для пользователя”?
Давайте разбираться.
В предыдущей статье "Почему нейросети не заменят прикладных специалистов: простая логика против вероятностных подходов" рассматривались общие вопросы поиска решений управляемого данными. Эта информационная технология, основанная на простой логике, позволяет оперативно вести диалог с пользователем, используя накопленные в процессе поиска решения данные. Для того чтобы это работало - требуется фрагментировать знания предметной области в виде функций с заданными областями допустимых значений входящих в них параметров.
В данной статье рассматривается вопрос о представлении предметных знаний в виде общедоступных документов, позволяющих интерпретировать их, как вышеозначенные функции и затем использовать в качестве компонентов базы знаний.
Всё нижеследующее, хорошо всем известно, но в контексте поиска управляемого данными обретает новый смысл и функциональность.
ПРИМЕЧАНИЕ. В качестве примера выбрана реальная задача из медицинской практики связанная с назначением антирабической помощи. Антирабическая помощь необходима для исключения заболевания бешенством после контакта с домашним или диким животным. Бешенство смертельно опасное заболевание. От правильности врачебных назначений зависит жизнь обратившегося за медицинской помощью. Имеется инструкция, регламентирующая действия по оказанию антирабической помощи, которая и является первоисточником базы знаний. Несмотря, на кажущуюся простоту выбор лечения (профилактики) требует чёткого анализа ситуации и учёта многих факторов. Экспертная система в диалоге управляемом данными не позволит ничего пропустить и предложит безошибочное решение.
Цикл научного метода для AI в коде Python:
Hypothesis — формируешь гипотезу
Action — действуешь на её основе
Data — собираешь данные
Insight — делаешь вывод
Привет, Хабр! Мы — бизнес-линия разработки кредитных продуктов для физических лиц в Т. Нам крайне важно использовать актуальное, безопасное и предсказуемое решение в проектировании бизнес-процессов. Для автоматизации выдачи кредитных продуктов мы используем движок бизнес-процессов Camunda.
В прошлом году компания объявила о завершении бесплатной поддержки Camunda 7. Платформа больше не будет получать обновления, включая критические исправления безопасности и уязвимостей. Для нас, как для финансовой организации, где безопасность, стабильность и соответствие стандартам играют ключевую роль, такой поворот стал серьезным сигналом.
Мы решили проанализировать текущее состояние оркестрации бизнес-процессов во всем банке. Хотели собрать потребности команд и найти подходящие решения, которые будут безопасными, масштабируемыми, надежными и готовыми к изменениям. Мы провели многоэтапный анализ существующих решений и сформировали итоговые рекомендации в виде дерева. В статье делимся тем, что получилось.
Как мечта гения прошлого века задает тренды нашего столетия
12 января 2026 года исполнилось 119 лет со дня рождения Сергея Павловича Королева. Его нет с нами уже более полувека, но созданный им космический «задел» до сих пор определяет контуры не только российской, но и мировой космонавтики. Мы живем в эпоху Илона Маска и частных стартапов, возвращения на Луну и полетов к Марсу. При чем здесь советский конструктор, родившийся при царе? Ответ прост: именно Королёв заложил фундаментальные принципы, на которых стоит наше сегодняшнее представление о космосе как о пространстве для жизни, работы и мечты.
Я не экономист и не связан с менеджментом, тем более никогда не интересовался складской логистикой. У меня свой взгляд человека со стороны, разобравшегося и осмыслившего частную проблему. Хочу описать то понимание, которого мне не хватало изначально, как программисту. Хочу сохранить это понимание и, возможно, донести эти мысли для профессионалов в своей области. Возможно, хочу сохранить свои эмоции.. Без формул и заумных терминов, эта несложная математика уровня средней школы, которая может различаться у разных групп людей. Например, кто‑то подгоняет lcr под 100%, а другие считают обратное значение и добиваются зеленного уровня в 25-35%, и это просто местные привычки, которые погоды не делают. Поэтому в дальнейшем буду оперировать словами «хороший» и «плохой» lcr, потому что каждый менеджер сам знает, какие цифры под этими словами подразумеваются. Другое дело, есть ли вообще понимание, зачем это считать? Оказывается, самое сложное не посчитать, а объяснить, зачем мы это считаем.
