Рассматриваем различные «приколюхи» из C++20 на примере хеш‑мапы!
В статье я разобрал разные способы реализации тех или иных методов в хеш-мапе, так же провел небольшой анализ над ними. Статья является научно-просветительской и немного исследовательской.
Хочу поделиться тем, как мы используем kafka для организации оперативного хранилища справочной информации.
Привет! Я Иван Косолапов, тимлид команды ETA/RTA. Мы часть сервиса Data Science и занимаемся анализом данных и машинным обучением для задач навигации в 2ГИС.
Наша команда появилась несколько лет назад, чтобы сделать точным прогноз времени в пути на автомобиле. Это важно не только для пользователей нашего навигатора, но и для бизнеса: например, для такси и служб доставки. Несколько специалистов по машинному обучению объединились с инженерами из команды навигации и создали решение, которое отвечает строгим требованиям по качеству, снизив ошибку на 20 процентов. Недавно мы также помогли сделать так, чтобы автобусы на карте отображались точно, и начали предсказывать время их прибытия на остановки. И это лишь часть задач, над которыми мы работаем.
Сейчас тема AI, машинного обучения у всех на слуху, и со стороны может показаться, что те, кто этим занимается — маги, которые берут нейросети, прикладывают их к правильным местам, и все проблемы решаются.
На самом деле применение сложных алгоритмов требует большой подготовительной работы по наведение порядка в процессе разработки, что занимает 90 процентов всего времени, если не больше. Более того, как только процесс налажен, может оказаться так, что никакой дополнительной магии машинного обучения уже и не нужно добавлять.
Под наведением порядка в процессе разработки я подразумеваю решение четырёх задач: выбор правильной метрики, подготовка данных, построение воспроизводимой системы экспериментов, перенос алгоритмов туда, где их проще всего развивать.
Расскажу, как решая эти задачи, мы добились более точного отображения автобусов на карте в 2ГИС, упростив существующую на тот момент сложную систему.
Бывает, что в командах тестирования грезят об автоматизации процессов, но почему-то боятся внедрять даже такие простые вещи как хуки: «Они очень усложняют процесс, и писать их тысячу часов». С этим я категорически не согласен, ведь реализовать хуки очень просто.
Меня зовут Денис Федоров, я тестировщик в команде 2ГИС ПРО, сервисе геоаналитики для бизнеса. Рассказываю, что такое гит-хуки, чем они могут быть полезны и как их можно реализовать у себя.
Привет, Хабр! Меня зовут Михаил Килинский, я — Senior Developer в проекте Data Warehouse «Лаборатории Касперского». Наша команда строит хранилища данных и разрабатывает ETL- и ELT-процессы, мы пишем на Python, SQL и C# (.NET), а весь код находится в монорепозитории.
Гибкие методологии построения хранилищ данных — очень популярный тренд. Причина — возрастающая сложность корпоративных моделей данных и необходимость интеграции большого числа разнородных источников, которые включают в себя не только традиционные СУБД и плоские файлы, но и различные real-time-брокеры сообщений, внешние API и базы данных NoSQL.
В этой статье хочу рассказать, как мы изначально хранили данные, почему решили внедрить методологии Data Lake и Data Vault и к чему это привело. Кроме того, покажу, как мы изобрели свой велосипед разработали свой фреймворк по автоматизации работы с помощью модели Data Vault.
В микросервисной архитектуре есть множество зависимостей от других сервисов и инфраструктуры. В результате чего возникают проблемы, которые съедают большое количество сил и времени. Приходит, например, тестировщик с описанием воспроизведения бага — а чтобы его воспроизвести, надо долго готовить данные, а потом еще дольше поднимать фронт… После N-й итерации повторять такое вы, конечно, не будете это, мягко говоря, утомляет. Так интеграционные тесты становятся определенным оверхедом вместо того, чтобы упрощать жизнь разработчикам.
Меня зовут Степан Охорзин, я Senior Go Developer в «Лаборатории Касперского». У нас в компании уже много проектов/продуктов, которые пишутся на Go, а еще мы мигрируем на него с «плюсов» там, где это возможно. Ведь Go — отличный язык, когда речь идет о распределенных системах; в частности, мы разрабатываем на нем облачные решения.
Сегодня речь пойдет как раз об одном из таких инструментов — Kaspersky Security Center (KSC). Если коротко, то KSC — это консоль для удобного управления безопасностью на уровне предприятия, эдакий аналог ЦУПа для сложных IT-систем. Как вы уже догадались, KSC построен на микросервисной архитектуре — и именно в нем мы организовали интеграционное тестирование. Теперь наши тесты не просто не уходят в технический долг, а могут сами служить документацией. Мы же думаем только о бизнес-логике, все остальные вопросы берет на себя DI-контейнер.
В статье расскажу, как мы это реализовали, с деталями и примерами.
На скриптовых языках удобно разрабатывать… И на этом удобство заканчивается. Вне машины разработчика начинаются проблемы. Особенно если вы пишете какой-то прикладной тулинг — cli-утилиты, вспомогательные приложения в вашем SDK и прочее. Вы даже не можете рассчитывать на то, что у пользователя будет pip, чтобы он смог поставить все ваши зависимости, вам все нужно организовать самостоятельно.
В этой статье поговорим о различных формах распространения Python-приложений. Какие есть подходы и инструменты, почему они могут не сработать и как чинить возникающие проблемы.
Если вам покажется, что в чем-то я ошибаюсь, добро пожаловать в комментарии. Буду рад услышать любые альтернативные точки зрения. Кроме, как я уже отметил в заголовке, рекомендации переписать все на Go/Rust/You name it :) Этот холивар мы уже проходили.
Хабр, привет! Меня зовут Мария Недяк, я специализируюсь на разработке харденингов нашей собственной микроядерной операционной системы «Лаборатории Касперского» KasperskyOS. Если вкратце: мы стараемся сделать любые атаки на нашу ОС невозможными — или хотя бы очень дорогими :-)
Один из главных инструментов в нашей нелегкой работе — «канарейка» (ну или Stack Canary), которая защищает от базовой атаки переполнения стека. Лично я к работе с этой птичкой уже давно привыкла — набила руку во время многократных CTF-турниров, где без такого харденинга было никуда… Этот бэкграунд очень пригодился мне в «Лаборатории Касперского», когда перед нашей командой встала задача усилить «канарейку» в KasperskyOS.
В статье я подробно объясню, как работает Stack Canary, как ее ломают — и как от этих методов взлома защититься. Сразу скажу: тема непростая, так что для самых любопытных я оставила список полезной литературы в конце текста. Поехали!
Сейчас в медиа пространстве часто говорится о так называемом "тихом повышении". Под ним как правило имеется ввиду когда работнику дают дополнительные обязанности, но при этом официально не повышают ни зарплату, ни должность. Как правило о таком говорят как о чем-то негативном, но как человек, который сталкивался с ним, хочу разобрать в каких случаях на него всё-таки стоит соглашаться и возможные варианты общения с начальством, если вы на него не готовы.
В данной статье подробно рассмотрим, как собрать ядро, поддерживающее EVL core, и библиотеку, реализующую пользовательский API для этого ядра. А также разберем некоторые аспекты реализации драйвера устройства и приложения под Xenomai 4.
Xenomai — Фреймворк для разработки приложений реального времени на базе ядра Linux. Проект Xenomai был запущен в 2001 году с целью эмуляции традиционной ОСРВ и облегчения ее переноса на GNU/Linux с сохранением гарантий работы в режиме реального времени. Изначально Xenomai был связан с RTAI (интерфейсом приложений реального времени), но на данный момент он независим.
Мы будем работать с Xenomai версии 4. Xenomai 4 имеет архитектуру с двумя ядрами. Первое ядро Linux: для задач, отличных от реального времени, и ядро Xenomai: для задач реального времени. Ядро Linux и ядро реального времени работают практически асинхронно, оба выполняют свой собственный набор задач, всегда отдавая последнему приоритет над первым. Для осуществления доступа к основным сервисам реального времени в проекте Xenomai предусмотрена библиотека С, известная как libevl.
Xenomai поддерживает множество архитектур, таких как PowerPC, Blackfin, ARM, x86, x86_64 др. В данной статье мы используем компьютер c архитектурой x86_64 (Процессор: 12th Gen Intel® Core™ i5-12400 × 12, память: 32,0 ГиБ), операционной системой Debian GNU/Linux 12 (bookworm).