Разработка

Ты просто кодишь, а ждёшь миллионы и аплодисменты? Добро пожаловать в клуб разочарования.

Ты выучил React за 3 месяца и ждёшь, что мир падёт ниц? Миллионы получают те, кто решает миллионные проблемы, а не те, кто прошёл курс на Юдеми.

В последние годы рынок IT стал похож на комикс: каждый второй джун чувствует себя Тони Старком, а каждый третий считает, что его CRUDна React — это вклад в мировую цифровую революцию.

Причём, если зарплата меньше 300к — значит, «рынок сдох», »айти умирает», «никто не ценит». Знакомо?

Это не синдром бога. Это синдром пузыря.

Рынок меняется, и да, он стал жёстче. И дело не в твоих навыках, а в том, что рынок больше не прощает завышенных ожиданий. Но ждать, что тебе что-то подарят, - не выход.

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Недавно получил такой комментарий к одному из обзоров ESB: «Я считаю, что интеграционные платформы больше не нужны», а спустя время в Телеграм-сообществе «Шины не для машины» развернулась дискуссия на тему «Паттерн ESB безнадежно устарел». Решил собрать в одной статье популярные вопросы по теме и ответить на них.

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

Привет, Хабр! Меня зовут Константин Архипов, я scrum-мастер продукта «Среда ЭДО» в МТС. Последние несколько лет я занимаюсь электронным документооборотом и вижу, насколько это сложный процесс и как его недооценивают.

Малый бизнес может взять коробочное решение и подключиться к ЭДО через оператора. Крупный уже давно и основательно занимается in-house-разработкой — с такими объемами не остается другого выхода. Например, в экосистеме МТС существует несколько инстансов биллингов, где рассчитываются счета и формируются закрывающие документы. Интегрировать каждый биллинг со своим оператором ЭДО нерационально, поэтому мы объединяем потоки данных в нашем продукте «Среда ЭДО» и в начале месяца обрабатываем и маршрутизируем в день до 350 тысяч документов из разных источников.

Средний бизнес находится в подвешенном состоянии: коробочные решения им не подходят, а на что-то свое не хватает ресурсов. Пока еще многим выполнять ручные операции гораздо проще, чем строить сложную систему. Например, я лично встречался с ситуацией, когда в нескольких компаниях хотели внедрить ЭДО, назначали ответственных… но те меняли направления, так как ЭДО было слишком сложным и непонятным.

Мы в МТС вместе с коллегами из других компаний суммировали свой опыт и подготовили карту внедрения ЭДО — она должна помочь с первыми шагами. В этом материале я расскажу, зачем нужна карта, с чего надо подступиться к ЭДО и чем опасна ситуация, когда все действуют по принципу «гром не грянет — мужик не перекрестится».

В наш век технологий обработка данных и мониторинг систем становятся критически важными. Поэтому для обеспечения бесперебойной работы я часто использую в своих проектах Elastic Stack (ранее известный как ELK Stack), позволяющий собирать, хранить и визуализировать огромные объемы данных. Этот подход широко применяется для анализа логов, мониторинга инфраструктуры, создания отчетов, а также для обнаружения аномалий и ошибок. 

Одной из ключевых задач при работе с Elastic Stack является настройка эффективной системы уведомлений. Это позволяет оперативно реагировать на происходящие события и минимизировать последствия сбоев или атак. В таком контексте фреймворк ElastAlert 2 представляет собой мощный инструмент, который значительно расширяет возможности встроенных уведомлений Elastic Stack, обеспечивая гибкость и детализацию алертов.

В этой статье в блоге ЛАНИТ я расскажу о том, какое одно универсальное правило для мониторинга событий в ElastAlert 2 охватывает все основные варианты условий срабатывания. Рассмотрим, как можно использовать ElastAlert 2 для расширения функциональности алертинга в Kibana и как интегрировать оба инструмента для более эффективного мониторинга событий.

• compile-time-рефлексия
• рефлексия параметров функций
• аннотации
• std::optional<T&‍>
• параллельные алгоритмы

Я работал аналитиком в одной из тир-4 команд, которая не могла пройти дальше полуфиналов. Мы выигрывали небольшие турниры, перебирали составы, готовились к матчам… но каждый раз сталкивались с одной и той же проблемой — нехваткой данных или их переизбытком.

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

Каждый день я сталкивался с тем, что данные есть, но нет инструмента, который бы их собрал, обработал и показал бы мне не просто прогноз, а понятное объяснение:

Почему один драфт сильнее другого? На какой минуте начнётся лейт? У кого преимущество в ерли?

И вот однажды я спросил себя: «Почему в 21 веке нет алгоритма, который поможет решить эту задачу?»

Не нашёл ответа. Значит, нужно было сделать самому.

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

Но со временем стало получаться. Очень быстро.

Сегодня DotaDiviner — это мультиплатформенный инструмент анализа драфтов , доступный через Telegram бот, мобильное и десктоп-приложение. Он строит график силы каждой команды поминутно, показывает, когда произойдёт камбек, кто доминирует в ерли, а у кого пик силы придётся на лейт.

А ещё он умеет отправлять автоматические уведомления о матчах, где есть явное преимущество — например, как на PGL Wallachia Season 5, где можно было легко ловить коэффициенты выше 10.

Продолжение под катом.
Если тебе интересно, как всё это работает — добро пожаловать 👇

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

Статья может быть полезна backend-разработчикам, лидам, тестировщикам, аналитикам, которые проектируют и разрабатывают сложные системы. Код написан на java и соседних технологиях, но подходы, я уверен, универсальны. Они упростят жизнь при разборе ошибок на проде и на тестовых стендах.

Подробное руководство по работе с параметрами и автоматизации оформления чертежей в nanoCAD BIM Строительство. Особое внимание уделено инструментам для ускорения оформления документации: мастерам размеров, настройке выносок и маркеров.

Системным аналитикам часто приходится проектировать процессы авторизации, выбирать протоколы и описывать требования к аутентификации. Но когда дело доходит до SSO (Single Sign‑On) — архитектурных решений становится неожиданно много:
OIDC, SAML, Kerberos… Что из этого выбрать и почему?

В статье — подробный разбор SSO:

• Что это такое, как работает и где мы сталкиваемся с этим каждый день (вход через Google, корпоративные порталы, файловые ресурсы Windows);

• Как устроены OIDC, SAML и Kerberos — и чем они отличаются на каждом этапе: от запроса до logout;

• Кому какой протокол подходит и как избежать архитектурных ловушек (например, использование SAML в мобильном приложении — это боль);

• И, конечно, схемы, псевдокод и чек‑листы выбора.

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

Почта с адресом info@пример.бел технически возможна и мы в HB.BY её поддерживаем. Но спроса почти нет. В статье разбираем, кто мечтал о кириллической почте и что от неё отталкивает, чтобы узнать, к чему всё приведёт.

Сегодня расскажем о нашем новом модуле — контроле качества в контактном центре.

В 2х словах напомним, что ЭРА — это информационно-коммуникационная платформа для автоматизации контактных центров, созданная профессионалами с 25-летним опытом в сфере коммуникационного программного обеспечения. В основе платформы лежит микросервисная архитектура, которая обеспечивает отказоустойчивость и масштабируемость системы.

Платформа включает в себя слой телефонии и слой функций контактного центра, которые позволяют автоматизировать процессы обслуживания клиентов. ЭРА поддерживает мультиканальные кампании, различные режимы набора номера, анализатор ответа и гибкую интеграцию с другим ПО, а также способна обрабатывать огромное количество звонков и обращений, что подтверждается результатами нагрузочных тестов.

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

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

Возникает множество процессов и управляемых объектов. Мы приняли решение сфокусироваться на управленческих процессах (отсюда и название УКЦ) и подойти к их организации системно. Мы заметили, что каждый контактный центр уникален, отличается уровнем процессной зрелости и своими особенностями. Однако всем необходим четкий ориентир — эталон, к которому можно стремиться и на который можно опираться при определении требований к эффективному контактному центру с точки зрения управления и организации. Таким ориентиром мы выбрали международный стандарт ISO 18295:2017.

Flowable Async Executor (также известный как Job Executor) — это ключевой компонент Flowable. По сути, это многократно используемый, автономный компонент, работающий внутри различных движков Flowable и обеспечивающий асинхронное выполнение логики.

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

Сегодня мы рассмотрим самый — казалось бы — скромный модификатор, который способен сэкономить кучу времени в горячих участках кода. Речь, конечно, про in-аргументы. Рассмотрим, чем они отличаются от ref и out, где ими действительно стоит пользоваться, а где лучше пройти мимо.

После переезда в США мой английский был на уровне A1. Вместо курсов и приложений я решил создать собственный языковой тренажёр и заодно прокачать себя как fullstack-разработчика. В статье рассказываю как я парсил словари, получил бан, внедрил геймификацию и достиг уровня B2 за год.

Привет, Хабр! Мы — Настя, Эвелина и Миша — бэкенд-разработчики Т-Банка, пишем код на Scala и горим желанием его популяризировать. Мы собираем и агрегируем новости из разных источников, включая Scala Times, блог Petr Zapletal и канал Scala Nishtyaki, добавляем дополнительные новости и собственные комментарии. Мотивацию мы черпаем из желания развиваться и делиться полученными знаниями.

Приветствуем любую обратную связь! (づ ◕‿◕ )づ

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

Если коротко:

Автор работает в IT с 18 лет. Сейчас ему 24. И он пишет, как несправедлив этот мир, потому что его потолок — 400k. Видимо, за умение слепить форму или написать CRUD’ы должны платить миллионы.

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

Итог статьи и её автора — печален. Мы наблюдали нелепый акт самовыпила с Хабра. Сначала автор улетел в минуса, потом в read-only. После чего создал второй аккаунт, чтобы в последний путь бряцнуть своим дипломом бакалавра.

Привет, Хабр! В этой статье рассмотрим невинный на первый взгляд параметр shuffle=True в train_test_split.

Под «перемешать» подразумевается применение псевдо‑рандомного пермутационного алгоритма (обычно Fisher‑Yates) к индексам выборки до того, как мы режем её на train/test. Цель — заставить train‑и-test быть независимыми и одинаково распределёнными (i.i.d.). В scikit‑learn эта логика зашита в параметр shuffle почти всех сплиттеров. В train_test_split он True по умолчанию, что прямо сказано в документации — «shuffle bool, default=True».

Со времени публикации комментария о «подводных камнях» файловой системы ReFS накопились наблюдения, заслуживающие отдельной статьи.