Разработка

Современная вычислительная техника в разы превосходит ту, что была десятки лет тому назад. Данный технологический прогресс не является чем-то удивительным, а лишь показывает, что совершенствование не имеет предела (по крайней мере, мы его пока точно не достигли). Одной из потенциальных ветвей развития вычислительной техники является использование света (фотонов) вместо электрического тока. Однако, данная технология, как и любая другая в зачаточном состоянии, сопряжена с рядом проблем. Одной из которых является контроль над потоками света. Ученые из Нью-Йоркского университета (США) разработали новый тип материалов, который потенциально может решить эту проблему. Из чего он состоит, в чем его особенности, и как именно он позволяет управлять фотонами? Ответы на эти вопросы мы найдем в докладе ученых.

Привет, Хабр! Меня зовут Артём. Я руковожу группой Scala‑разработчиков в компании «Криптонит» и веду Scalabook — русскоязычную базу знаний по Scala и функциональному программированию. В ней можно найти другие мои статьи‑инструкции, а также примеры кода. В этой статье предлагаю обсудить циклы и связанные с ними спорные моменты.

На связи Георгий, аналитик SoftMediaLab. В этот раз хочу поделиться опытом создания ИИ-агента для оценки на пресейле. Инструмент вырос из желания упростить участие разработчиков и ускорить процесс. Это настоящая боль — выдернуть разраба из проекта, чтобы тот отключился от боевой задачи и посмотрел на какой-то запрос...

Недавно мы в Beeline Cloud рассказывали о необычных визитках, способных наглядно продемонстрировать инженерные навыки владельца и служить уникальной запоминающейся «раздаткой». Сегодня мы подобрали несколько аналогичных проектов — разумеется, open source. Это — LED-визитка с плещущимися огоньками, карточка-тренажёр для QA-инженеров и миниатюрная плата-визитка с ретроиграми.

Команда Python for Devs подготовила перевод статьи о том, почему автору SQLAlchemy нравится… но не настолько, чтобы не попробовать создать собственный ORM. SQLORM ― минималистичный, прямолинейный и честный: никакой магии, никаких скрытых Unit of Work, максимум контроля над SQL и минимум связности с сессией.

Этот пост станет глубоким разбором того, как мы снизили задержки P95 конечной точки API с 5 до 0,3 секунды при помощи нишевого трюка computer science под названием «фильтр Блума».

Мы расскажем о том, почему конечная точка была медленной, о решениях, которые мы рассматривали для повышения её скорости, и о критериях выбора между ними. Также мы объясним, как всё это устроено внутри.

Любой, кто работает в корпоративной информационной безопасности, знает, что отчётность отнимает больше времени, чем хотелось бы. Формирование отчётов, согласование данных между подразделениями, бесконечные Excel-файлы, ручное копирование показателей из систем — всё это не только демотивирует специалистов, но и напрямую снижает эффективность ИБ. Пока команда занята сводками для аудиторов и контролёров, реальные риски могут оставаться без внимания.

Я нередко наблюдаю, как крупные организации с развитой ИБ-службой тратят недели на подготовку ежеквартальных отчётов, четверть, а то и треть от всего периода, чтобы закрыть квартал. И речь не только о государственных организациях или финансовых компаниях, работающих по различным нормативным требованиям, таким как 152-ФЗ (и подзаконные НПА) или ГОСТ 57580. Даже коммерческие структуры, не обременённые строгим регулированием, сталкиваются с тем, что любая проверка превращается в проект на полгода. Особенно если речь идет про построение различных систем менеджмента информационной безопасности, или соответствие лучшим практикам.

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

Привет! Я — Андрей Шалягин, руководитель Офиса цифровизации в Альфа-Банке. Наша команда помогает различным подразделениям внедрять технологии и решения, направленные на выявление и оптимизацию рутины, повышение производительности и цифровизацию операций.

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

Чтобы получить объективную картину мы применяем Process mining — технологию, которая позволяет построить модель реального исполнения бизнес-процесса на основе логов событий. В банке развернута платформа Proceset от команды Инфомаксимум.

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

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

Всем привет! Наша группа занимается RISC-V Linux и загрузчиками в компании «Синтакор». Однажды перед нами возникла задача — реализовать поддержку аппаратных триггеров в ядре Linux и OpenSBI. Она стала началом исследования, в ходе которого я изучил смысл аппаратных триггеров с точки зрения отладчика, их устройство и использование для вотчпойнтов и брейкпойнтов, а также принял участие в совершенствовании поддержки аппаратных триггеров в RISC-V Linux и OpenSBI. 

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

Светодиодная лампа Osram Ultra, купленная по акционной цене 176 рублей. На коробке заявлены 12 Вт, «высокая стабильность», «качественный свет» и прочие обещания, которые производители любят печатать крупным шрифтом.

Привет! На связи снова Саша Симоненко, операционный директор Xilant. Сегодня разбираем конкретные методики написания безопасных требований: INVEST, SMART, What-If и misuse cases. Чтобы быть в контексте, зачем они нужны и какую проблему решают, рекомендую начать с первой части трилогии — о том, как неточные формулировки становятся уязвимостями и где в SDLC теряется безопасность.

Я руководитель проектов, работаю с крупными корпоратами и банками первой пятёрки.

Самый ад — это когда проект на стыке двух таких банков. У меня есть живой пример )

На этом проекте:

На этом проекте:

— Юристы и безопасники из двух банков 4 месяца гоняли договор по кругу. Надо было как-то их договорить и всё-таки начать работать.

— Договор был рассчитан до 2026 года, а бюджет в системе был заложен только на 2025-й. Бухгалтерия возвращала ошибку Not defined и предлагала запланировать бюджет на 2026 год прямо сейчас.

— Уволился ключевой подписант.

— Это был ИТ-директор!

Так что у нас есть все виды бюрократии: комплаенс, Департамент кибербезопасности (ДКБ), риск-чемпионы и, конечно, юристы.

Как я уже говорила, это ад.

Но бюрократия всё же нужна. Потому что на больших проектах она означает стандартизацию.

Что бывает, когда такое не выполняется, мы отлично знаем по взломам доставки еды, например, когда стандарт был, но его не применили.

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

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

Сегодня поговорим о том, как на практике построить высоконагруженный обратный прокси-сервер на основе YARP, отличной библиотеки от Microsoft для .NET.

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

Команда комплексного реагирования на киберугрозы экспертного центра Positive Technologies завершила анализ инцидентов за период с IV квартала 2024 года по III квартал 2025 года. За это время мы провели более сотни расследований и в очередной раз убедились: киберугрозы не становятся сложнее, но становятся результативнее. Хакеры нечасто придумывают что-то принципиально новое — они совершенствуют уже проверенные методы и реализовывают их эффективнее .

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

Привет! Меня зовут Роман Христевич, я DevOps-инженер в Cloud.ru, занимаюсь плагинами и безопасностью для кластеров Kubernetes. Сегодня расскажу, как я сражался с ветряными мельницами — мусором в кластерах Kubernetes после тестирования релизов, рандомных Helm Chart и просто в автотестах. И как я эти мельницы все-таки одолел.

Если вы DevOps, SRE или системный администратор, то вам не раз и не два приходилось вычищать кластеры от отработанных Jobs в статусе Complete или Configmaps с Secrets, которые создали руками для уже раскатанного Helm Chart. Разовая акция не вызывает особых забот, а вот если это надо делать несколько раз в неделю, это уже проблема или даже боль.

Под катом я расскажу, как прошел путь, усеянный граблями, от самописных решений до K8s-cleaner, и почему я теперь доволен. Если ты еще не прошел мой путь, приглашаю под кат!

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

Три основных типа карьерных самосвалов в России

В российской добывающей отрасли применяются три доминирующих класса машин, каждый из которых имеет собственные особенности измерения веса:

Классические карьерные самосвалы с жёсткой рамой, такие как БелАЗ 7555–7513 и CAT 777–793, оснащаются гидропневматической подвеской с датчиками давления. Эти датчики служат для оценки веса полезной нагрузки через измерение давления в подвеске. Однако их данные сильно зависят от темпа движения и амплитуды раскачки кузова, что создает шумы и неточности при динамическом движении. В качестве инженерного дополнения к измерению веса для таких моделей важно применять алгоритмы фильтрации и компенсации динамических колебаний, а также дополнять данные от датчиков давления весовыми сенсорами, установленными на шасси, для повышения точности оценки нагрузки и снижения влияния факторов движения. Для БелАЗ и CAT, реализованы высокоточные системы взвешивания с погрешностью в диапазоне до ±0,1–1%. Однако, из-за сильных вибраций и динамических пиков в процессе работы, количество данных с аномальными колебаниями составляет примерно 20–35%. Благодаря строгой конструкции и стабильной гидравлической и электронной схемам, такие системы обеспечивают относительно меньшую дисперсию и более предсказуемую точность, особенно при использовании фильтров и компенсационных алгоритмов.

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

Стремясь к распространению Windows 95 и Windows NT, Microsoft начала процесс замены своей старой операционной системы MS-DOS. С 1996 по 1997 год доля DOS на рынке упала на 50%. Некоторые разработчики, например, Blizzard North, делали рискованный шаг и создавали игры наподобие Diablo только для Windows 95. Компания id Software же пошла на подвиг по созданию единого двоичного файла quake.exe, способного работать и в DOS, и в Windows.

Ещё более впечатляет то, что разработчикам удалось реализовать стек TCP/IP Quake лучше, чем у Windows 95. Давайте разберёмся, как им это удалось.

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

Меня зовут Александр Борецкий, я архитектор в Т1 Облако. Поделюсь своим опытом работы с самыми популярными из брокеров сообщений — Kafka и RabbitMQ. Расскажу, как выбрать и настроить подходящий брокер, а также какие архитектурные особенности есть у каждого из них.