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

Привет, Хаброжители!

Предлагаем ознакомиться с краткими обзорами новинок, отправленных в типографию.

Для тех, кто создает системы сбора данных с датчиков и мониторинга метрик для умных домов и промышленного оборудования есть хорошая новость. Теперь такие системы можно собирать с применением Российского одноплатного компьютера Repka Pi (который в т. ч. есть в реестре Минпромторга) и недавно появившейся Российской операционной системы Napi Linux, специально созданной для решения подобных задач и, что важно, с открытым кодом.

К микрокомпьютеру Repka Pi через порты USB, Ethernet, GPIO, в т. ч. SPI, I2C, Uart и другие интерфейсы можно подключать различное оборудование с целью мониторинга средствами ОС Napi Linux.

Операционная система Napi Linux разработана для встраиваемых (Embedded) систем.

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

Привет, Хабр! Меня зовут Дмитрий, я работаю в компании Orion soft. Преимущественно занимаюсь проектированием и разработкой бэкендов различного уровня от низкоуровневых сервисов до масштабируемых API. Сегодня мои основные инструменты — языки Python и Go. Так как ранее плотно работал с системным программированием, очень люблю *nix и всё, что с ними связано.

В статье расскажу, почему классические подходы к сетям перестали работать в условиях масштабирования, как мы выбирали стек, с какими архитектурными и техническими ограничениями столкнулись на практике — и почему выгоднее доработать существующий Open Source, а не переписывать всё с нуля. Покажу, как мы шаг за шагом избавлялись от узких мест, оптимизировали работу с большими объёмами ACL, переносили критичные компоненты на Go, и что в итоге получилось в продуктивных инсталляциях.

Если вам интересно, как реально эволюционирует инфраструктура и почему MVP — это не всегда «быстро и грязно», а зачастую — про осознанный выбор компромиссов — добро пожаловать под кат! Перед вами наш путь разработки программно-определяемой сети (SDN) для платформы виртуализации zVirt.

В какой-то момент в нашей команде стало очевидно: пора тащить всю инфраструктуру в Git — по-взрослому, через GitOps. Kubernetes у нас уже был, ArgoCD тоже. Осталось «дотащить» туда AWS-ресурсы, которые мы описываем с помощью AWS CDK.

Идея казалась простой: есть CDK-код в Git, запускается ArgoCD, всё красиво деплоится в облако. Но реальность оказалась совсем не такой. CDK — это не YAML и даже не Terraform. Это исполняемый код. GitOps — это про декларативность и kubectl apply. CDK с этим не дружит.

Ожидалось, что наверняка есть готовый Kubernetes-оператор, который запускает cdk deploy при изменении кода. Как это уже сделано для Terraform (через ArgoCD Terraform Controller), Pulumi, или хотя бы через ACK. Но после долгого ресерча выяснилось: нет ничего рабочего и production-ready.

Так появилась идея — написать собственный Kubernetes-оператор, который сможет:

- раз в какое-то время (или по коммиту в Git) запускать cdk deploy;
- проверять cdk diff и cdk drift для отслеживания изменений и дрифта;
- удалять CloudFormation-стэк, если ресурс удалили из Git;
- интегрироваться с ArgoCD и Prometheus.

Получился полноценный GitOps-воркфлоу для AWS CDK — без пайплайнов, без ручных cdk deploy, без дрейфующих стэков.

Под катом — расскажу, как мы подошли к проблеме, как устроен Custom Resource CdkTsStack, какие фишки мы добавили (метрики, хуки, IAM-пользователи), и почему наш подход оказался практичнее, чем существующие альтернативы вроде Terraform Operator или Pulumi.

Рустам Курамшин, эксперт Spring АйО, разобрал свежий отчёт Stack Overflow за 2025 год о результатах ежегодного опроса разработчиков за 2025 год, и это отличный повод взглянуть на экосистему Java через призму статистики и интересов сообщества.

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

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

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

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

В 2024 году мы — команда практического анализа защищенности «Инфосистемы Джет» — выполнили 130 проектов и выяснили, что в среднем достаточно 10 часов, чтобы вывести крупные суммы со счетов, остановить производство или слить критичную информацию. В работе мы используем сложные методы, но из-за низкой защищенности организаций часто хватает базовых техник[1] и общедоступного ПО. Наши наблюдения подтверждаются исследованиями кибератак[2]: в 83% случаев злоумышленники добивались успеха за счет «простых» методов — фишинг, эксплуатация уязвимостей по умолчанию или слабые пароли. State of art атаки с поиском 0-day — это скорее исключение. Обычно компании взламывают куда более прозаичными способами.

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

Нашёл ну прям подарок — Усманское городское Покровское кладбище. Оно старое настолько, что в прямом смысле слова горожане ( включая таксистов), называют старым другое кладбище, которое находится не в центре города. На Покровском очень давно не хоронят людей, наверное с 1970 — 1975 годов. Начало свою работу в 1815 — 1820 годах. Эдакая капсула времени из 5000 могил. Не все могилы сохранились с датами и именами, но многие. Усмань в конце 19, начале 20 века имела население 8000–10000 человек.

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

Мы рассмотрим подробнее эту методологию и особенности её применения. А также на нескольких примерах из практики М.Видео‑Эльдорадо и Т1 покажем, чем процессная аналитика может быть полезна в компании.

SLA (Service Level Agreement) — это соглашение об уровне услуг, документ, который четко определяет, кто, что и в какие сроки должен делать.

SLA (Service Level Agreement) — это не просто очередная бюрократическая бумажка, а свод правил, который спасает проекты от хаоса.  Если представить проект внедрения 1С как футбольный матч, то SLA — это правила игры. Если у одной команды — мяч, а у другой — шайба, игра превращается в хаотичную драку. SLA как раз и нужен, чтобы все играли по одним правилам.

Привет, Хабр! Я Катя Павлова, работаю в «Петрович-Тех». Последние 8 лет я пытаюсь управлять проектами, а 30 апреля 2025 года получила сертификат РМР.

В этой статье поделюсь опытом, как можно сдать на РМР в 2025 году, не продавая душу дьяволу. Ну, почти.

Заметки о забытой природе дзен-коанов

Сознание — это процесс, в котором оно пытается прорвать свою границу, чтобы найти несуществующее 'я', но граница не исчезает, а лишь сдвигается. Коаны — катализаторы этого вечного процесса.

Ещё совсем недавно я был в роли ищущего: выкладывал резюме на hh, бесконечно его редактировал, заказывал консультации, писал в телеграм-каналы, откликался на вакансии, делал тестовые… и всё это — без особого результата. Иногда доходил до собеседования, несколько раз даже до тестового, но итог был один — отказ.

Привет, меня зовут Алексей. Мне 53 года, и уже около 30 из них я в дизайне. В эту профессию я пришёл случайно — по образованию я химик, но, как выяснилось, дизайн люблю больше, чем науку. Начинал с издательств и редакций газет, потом были рекламные агентства, а в 1999 году стал одним из первых фрилансеров в стране. Работал с многочисленными западными и отечественными клиентами. Почти 20 лет сотрудничал с российским представительством Volkswagen, делая дизайн интерфейсов для внутренних систем — от складского учёта до HR. Были и другие проекты: Toshiba, LG, Bausch & Lomb, Erich Krause и другие…

Фриланс в моём случае исчерпал себя. Крупные клиенты ушли, конкуренция выросла, появилось много школ и курсов, которые зачастую дают поверхностные знания — и на выходе огромная армия юных и неопытных дизайнеров, готовых работать за копейки. Я понял: хочу обратно в команду, к живым людям, с кем можно обсуждать, спорить, вместе думать и работать над сложными и крутыми проектами. И главное — делиться опытом. Я стал искать работу. Но сначала запустил свой Telegram-канал, где начал публиковать истории, викторины, разборы, советы, лайфхаки — всё, что может помочь дизайнеру расти.

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

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

С любопытством в уме и почтением в сердце продолжим заглядывать через плечо французскому ламподелу-любителю 1920-х годов — М. Н. Минье, примечательного неукротимым энтузиазмом и использованием в работе простейших средств. Дела у нашего героя идут всё интереснее — обзаведясь простейшим огневым оснащением и невеликим ассортиментом материалов (Часть 1), он уже освоил ряд нехитрых стеклодувных приёмов и изловчился собрать простейший стеклянный вакуумный насос ртутно-капельного типа, для опорожнения (откачки) своих электровакуумных приборов (ЭВП) (Часть 2). Ниже — первая порция работ практических — дополнение вакуумного насоса простейшим средством измерения — разрядной трубкой; изготовление учебно-тренировочных ламп накаливания.

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

Привет, Хабр! Меня зовут Игорь Цупко и я — инженерный менеджер с 13+ годами опыта, работаю на стыке технологий, процессов и людей. Создаю устойчивые команды, процессы и платформы для масштабирования бизнеса. В числе кейсов — запуск mos.ru, масштабирование Flant, управление платформами с сотнями приложений в Лемана Тех.

В предыдущем посте мы рассказали, что за цикл затеяли и на какое интервью с Дмитрием Пищальниковым будем ссылаться. Интервью категорические рекомендуем всем предпринимателям и руководителям!

В числе ключевых проблем низкой производительности труда – брак на производстве. Дмитрий Пищальников называет четыре источника брака:

При разработке SoC много говорят про RISC-V, а вот информации про шину AHB-Lite сравнительно мало. Все, что есть на русском языке, касается старого проекта MIPSFpga. Почему бы не взять открытые наработки из MIPSFpga Plus и не использовать совместно с ядром RISС-V?