Kurgan-Telecom Ru | Информационные технологии

Разбираемся, как организовать нагрузочное тестирование на Python с Locust — с сидинговыми сценариями, кастомными API-клиентами на HTTPX, конфигурацией через Pydantic и автоматическим запуском в GitHub Actions. Всё — на практике, с архитектурой, фреймворком и публикацией отчётов в GitHub Pages.

Зачем существуют профессиональные конференции? Зачем одни подают заявки на доклады, стремятся поделиться практическим опытом или личным мнением относительно того или иного вопроса? Зачем другие платят не маленькие деньги, покупают билеты, слушают, о чём говорят первые?

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

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

Привет! Меня зовут Евгений. Я — Full-Stack QA Engineer в Devscribed и сегодня хочу поделиться своим экспериментом — QA Mentor Bot. Это Telegram‑бот, который отправляет в телеграмм группу случайные вопросы по тестированию и сразу же генерирует на них развёрнутые ответы с помощью AI. В этой статье я расскажу, как устроен проект и с какими «подводными камнями» столкнулся в процессе разработки.

Четыре года назад на собеседовании я услышал от интервьюера о том, как замечательно паттерн Спецификация помогает справиться с проблемой разрастания репозитория. Я думаю, многие с этим сталкивались, когда количество методов типа getByThisAndThat(…) улетает за десяток, а то и за несколько десятков, и репозиторием становится пользоваться неудобно.

Вдохновившись таким позитивным отзывом, я изучил первоисточник и начал экспериментировать с использованием спецификации как со средством упрощения репозитория.

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

В воскресенье, 20 июля, компания Microsoft выпустила срочные патчи, закрывающие две уязвимости в ПО для совместной работы Microsoft SharePoint. Речь идет о корпоративных инсталляциях SharePoint, облачная версия SharePoint Online, входящая в пакет Microsoft 365, не подвержена проблеме. Уязвимости с идентификаторами CVE-2025-53770 и CVE-2025-53771 являются вариантами проблем, обнаруженных еще в мае этого года и пропатченных (как выяснилось, не до конца) в июльском наборе обновлений от Microsoft.

Мой первый опыт публикации и рассказ о том, как я за четыре недели сделал рабочую альфа-версию покер-бота. В проекте использованы методы Монте-Карло, компьютерное зрение (YOLO), Python и инструменты вроде Cursor и Roboflow.

Текст будет полезен новичкам в машинном обучении и компьютерном зрении, тем, кто хочет понять, как связать ИИ, детекцию объектов и покерную математику в одном проекте, а также всем, кто интересуется практическим применением ИИ для создания собственных инструментов.

Обычно о бухучёте вспоминают в двух случаях: когда приходят деньги или когда приходит налоговая. Так и было у одного ИП с самозанятыми: выручка уже перевалила за 150 миллионов, на горизонте замаячил НДС, появились вопросы от налоговой по подрядчикам. Рассказываю, как избежать проблем и законно сэкономить на налогах, когда бизнес быстро растет. Этот кейс — готовая инструкция для IT-предпринимателей, которым пора стать ООО.

В этой статье мы подробно расскажем о пути перехода платформы контейнеризации dBrain.cloud с MaaS на Metal³. Основная задача, которую решают оба этих проекта, состоит в установке операционной системы на серверы платформ. Озвучим причины, по которым мы искали альтернативные решения, и объясним, чем Metal³ превосходит MaaS.

Практически каждому разработчику однажды приходилось искать утечки памяти в его приложении / либо же профилировать использование памяти процессом. Задача эта довольно трудоемкая и непростая.

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

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

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

Спойлер - удалось ускориться по отношению к heaptrack в 30 раз.

Время выполнения потоковых задач в разработке часто колеблется: один день задача занимает 2 часа, в другой — 6. Из-за этого сложно предсказать, уложится ли команда в срок. Control chart помогает отслеживать разброс времени, находить аномалии и корректировать процесс до того, как отклонения станут проблемой. 

В статье разберем, как это работает, и покажем, как можно читать график, чтобы определить SLA при работе с заказчиком.

Идея написать статью пришла ко мне, когда я читала книгу «Цветы для Элджернона». Кто не знаком с произведением, советую его прочитать: это глубокий и пронзительный психологический роман, в котором мужчина с нарушениями интеллектуального развития по имени Чарли стал гением благодаря научному эксперименту. И хотя цель была высокой и благородной, а результат — достойным, герой  доставил достаточно хлопот ученым на своем пике развития интеллекта. Что-то все-таки пошло не так, и постепенно Чарли потерял все знания, которые ему открылись. В какой-то момент чтения я подумала: а ведь похожим образом ведут себя требования. Они сначала простые, понятные. Потом бац! Они начинают умнеть, эволюционировать, требуют больше ресурсов и в конечном счете создают хаос и порой даже рушат текущие процессы.

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

Сегодня в блоге ЛАНИТ на Хабр я хочу поделиться десятью шагами из своего опыта, которые помогали моей команде справляться с ситуациями, когда требования росли быстрее, чем их успевали зафиксировать.

В июле 2025 года Китай выполнил сложнейшую задачу, которая может повлиять на будущее космических миссий. Спутники Shijian-21 и Shijian-25, по данным независимых наблюдателей, провели первую в истории успешную операцию по дозаправке в геостационарной орбите (ГСО) на высоте около 36 тысяч километров над Землей. Это еще один шаг к созданию устойчивой и многоразовой космической инфраструктуры. Разберем, как Китай подготовился к этой миссии, что за технология, какие у нее проблемы и как все это может повлиять на будущее космической индустрии.

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

Каждый пост автомойки – это работа целого набора исполнительных механизмов, датчиков, насосов и клапанов. Сбой хотя бы одного элемента — и автомойка простаивает, бизнес теряет деньги, а клиенты уезжают к конкурентам. А когда на объекте нет персонала (что типично для моек самообслуживания), без надежной автоматизации вся модель рассыпается.

В статье покажем, как инженер Андрей Демшин выстроил систему, в которой автоматика не просто управляет подачей воды и химии, а обеспечивает все бизнес-процессы. На реальном примере сети «Чистомытов» в Санкт-Петербурге разберем, какие технологии помогли превратить автомойки в стабильный бизнес.

Ваша база знаний превратилась в кладбище идей? Я построил RAG-систему, чтобы мой "второй мозг" ожил и стал собеседником. Узнайте, как перейти от хаотичного поиска к осмысленному диалогу с вашими заметками и получить измеримую выгоду для бизнеса.

Что общего у атомной станции, ледокола и промышленной IoT-системы? Все они — часть критической информационной инфраструктуры (КИИ), где сбой может обернуться серьёзными последствиями.

О том, что из себя представляет КИИ, почему она так важна, чему учат будущих специалистов и как устроена работа на практике, рассказывает эксперт из Росатома — руководитель Дирекции «Цифровая Арктика» АО «Гринатом» и ведущий инженер-исследователь научного центра «Сириус».

Всем привет! Меня зовут Михаил Шумовский, я редактор журнала «Конверт» (экс блог Unisender) и нейроэнтузиаст: плотно погрузился в тему год назад и даже завел Telegram-канал про нейросети в маркетинге — @misha_davai_po_novoi

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

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

На сегодняшний день существует множество методологий разработки ПО: SDLC, Agile, Scrum и подобные. Но ни одна из них в чистом виде не подходит к процессу разработки физических устройств, предназначенных для массового производства.

Самые значимые различия (как, впрочем, и сходства) в подходах и методологиях мы рассмотрим через погружение в цикл разработки продуктов потребительской электроники. Разберём, какие именно задачи лежат на инженерах аппаратной разработки, какими знаниями необходимо обладать и почему цена ошибки так велика. А в качестве примера возьмём знакомое и понятное всем устройство: умную колонку с AI‑ассистентом.

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

До коротких видео и алгоритмической ленты были стереоскопы. Простые, но крутые гаджеты, которые имитировали объём. На картоне печатали два почти одинаковых кадра с разницей в пару сантиметров. Вставляешь в прибор, смотришь двумя глазами и получаешь аналоговый 3D.

Вот, например, типичный викторианский NSFW на картонке.

В середине XIX века петербургский инженер Иван Александровский решил, что хочется чёткого объёма без костылей. Он собрал камеру с двумя объективами, которая делала два кадра одновременно. Получалась идеальная стереопара. Зарядил в стереоскоп — и вперёд: смотреть, кивать, звать друзей. Кто-то приносил мадеру, кто-то обсуждал глубину резкости. Так выглядели рилсы.

Никаких свайпов и лайков — только оптика, только хардкор.

Любой программный продукт, язык - не исключение - должен иметь чёткую причину для существования. Просто быть "ещё одним способом выразить алгоритм" уже недостаточно. На насыщенном рынке языков программирования (ЯП) успеха достигают те, у кого есть понятный маркетинговый аргумент для выбора - будь то особенности самого языка, убойные примеры применения (killer apps) или области применения (killer domain), в которой язык особенно силён.