Разумеется, в виду имеются старые игры. Игры детства. В какой-то момент, захотелось их вспомнить. Многие скажут, что есть DOS Zone и будут правы, но что может сравниться с тем, чтобы запустить любимую игру у себя на компьютере, локально, пусть даже и внутри Internet-браузера. Ну и сама возможность разобраться, пусть даже и довольно поверхностно, со всеми этими JS-DOS технологиями дорогого стоит.
Команды и пользователи часто находятся в разных городах, поэтому большинство исследований на моих проектах проходит удалённо. Со временем у нас встроился процесс, который позволяет проверять интерфейсы без лабораторий, специального оборудования и больших бюджетов.
В этой статье расскажу о пяти способах, которые использую в работе. Покажу их не только в теории, но и на примере одного из наших реальных проектов в «Северстали».
На днях, а именно, 31 августа, вышла новая модель работы с временными рядами от Google — TimesFM-3 (Time Series Foundational Model).
Если вкратце, задача моделей семейства TimesFM — прогнозировать дальнейшее поведение системы на основе ретроспективных данных. Интересно, что для этого исследователи Google применяют токенизацию групп временных отсчетов, а сам трансформер TimesFM — decoder‑only. Также в третьей версии TimesFM заявлена поддержка одновременно множественных переменных (multi‑variate).
Так я был в отпуске и мне было скучно, я вспомнил про старую задачу полуторагодовалой давности: классификация сценариев поведения пользователя на основе данных энергопотребления.
Недавно на исследование в департамент комплексного реагирования на киберугрозы Positive Technologies (PT ESC IR) поступил ряд образцов банковского трояна для Android с функциями удаленного управления — Drama RAT. Это вредоносное семейство распространяется с помощью фишинговых сообщений в мессенджерах и маскируется под VPN-сервисы, банковские приложения и другие взломанные утилиты со встроенной платной функциональностью. Ранее о нем писали в УБК МВД.
Нужен драйвер — пиши на C. Нужно что-то рядом с ядром — тем более пиши на C. В низкоуровневой разработке этот подход воспринимается почти как правило по умолчанию. Но иногда задача требует большей выразительности, больше удобной работы со структурами данных и дополнительных гарантий со стороны языка.
Меня зовут Женя Ерохин, у меня около 15 лет опыта разработки драйверов на C++ под macOS. Сейчас я старший разработчик в Kaspersky Lab, занимаюсь операционной системой KasperskyOS. Много всего создал в ее микроядре, а теперь знакомлю нашу ось со всяким железом на мобильных устройствах.
Под катом я покажу, как мы использовали C++ при разработке драйвера для микроядерной ОС. В том числе разберу гетерогенный lookup — возможность выполнять поиск по разным типам аргументов без лишних преобразований. На практике такая фича хорошо показывает, почему C++ может быть полезен даже там, где обычно ждут C. Я расскажу, почему драйверы на C++ для микроядерной ОС — вполне рабочее инженерное решение. Покажу, где именно плюсы помогают писать более аккуратный и надежный код, как они упрощают работу со структурами данных и почему в нашей задаче такой выбор оказался естественным.
Новый руководитель приходит в команду с горящими глазами, переписывает регламенты, меняет метрики, а через три месяца команда измотана, половина инициатив заброшена, и сопротивление только выросло. Знакомо?
Попытка исправить всё разом распыляет ресурсы. Системный подход требует другого: найти одну точечную правку с максимальным КПД.
Алексей Лапунов, ведущий менеджер цифровых продуктов департамента информационной безопасности и системного администрирования в ТЕХНОНИКОЛЬ Диджитал, в статье на Хабре объяснил, как выстроить процесс, который не выматывает команду и действительно решает проблему.
В материале эксперт делится пятью универсальными принципами для решения сложных рабочих проблем и даёт чек-лист из 7 вопросов, который стоит пройти перед запуском очередных изменений.
Всем привет, это команда Ринго! Уже не первый год Apple публикует Deployment Guide — руководство для системных администраторов, охватывающее развертывание, настройку и управление техникой Apple. После каждой WWDC в нём появляется раздел «Что нового?», и в этом году основная повестка не про новые возможности, а про потери. В macOS 27 перестанут работать привычные MDM-команды управления обновлениями.
Разбираем ключевые изменения из What’s New for IT at WWDC26: что приходит на смену старым командам, какие декларации появились для сетевых настроек и статусов устройств и что следует проверить в инфраструктуре до массового обновления парка. Сервисы, официально недоступные для организаций, зарегистрированных в России (Apple Business Manager, Volume Purchase Program и другие), мы намеренно оставляем за скобками — говорим только про управление macOS 27.
Несколько недель назад интернет гудел новостными заголовками, в которых говорили, что продавец из Гонконга выложил на eBay видеокарту GeForce RTX 2080 Ti с 22 ГБ видеопамяти вместо штатных одиннадцати. При этом он просил за нее всего 499 долларов. Тогда мало кто вспомнил, что про такие же карты с тем же ценником еще в феврале 2024 года рассказывали ребята из Tom's Hardware, но в то время переделкой занимались китайские мастерские. Сама по себе эта история очень интересная, особенно учитывая, что это не курьез из новостной ленты, а вполне сложившийся рынок со своими ценами и своей логикой. Сейчас расскажу все по порядку.
В Bot API 10.2 появилось отдельное событие для изменений в регулярной подписке — Update.subscription.
Сразу уточню область применения: речь идёт о повторяющихся платежах в Telegram Stars, созданных через счёт бота с subscription_period. Это не то же самое, что нативная платная пригласительная ссылка на канал. Бот получает оплату, а уже наша система решает, какой доступ выдать пользователю.
Внутри Update.subscription находится объект BotSubscriptionUpdated. У него есть пользователь, invoice_payload и одно из трёх состояний:
Заранее извиняюсь перед дизайнерами, которые сейчас будут кидаться в меня Figma-файлами. Тема неприятная, но обсудить её надо.
В древней стране Философии существует правящий совет философов, члены которого строго упорядочены по степени власти и престижа. Различные привилегии также распределяются в соответствии с этим рангом. Философ 1 - признанный философ-царь и самый могущественный член совета, за ним следует философ 2 и так далее.
Пришло время сформировать новый совет. Согласно давно установленной процедуре, философ с самым низким рангом предлагает новый состав совета и распределение мест в нем. В принципе, в предложенный совет может войти любой гражданин Философии - круг кандидатов не ограничен членами нынешнего совета. Хотя, как ни странно, обычно новый совет все же состоит из членов предыдущего. После выдвижения нового предложения совет голосует. Если большинство голосует за, предложенный состав и распределение мест утверждается. В противном случае философ с самым низким рангом исключается из совета, а предложение выдвигает следующий философ с конца. Этот процесс продолжается до тех пор, пока новый состав совета и распределение рангов не будут одобрены.
Я называл членов правящего совета философами, но стоит подробнее рассказать об их ценностях и о том, по каким критериям они оценивают предложения. На самом деле это жаждущая власти компания макиавеллистов, каждый из которых отчаянно стремится стать философом-царем. Для каждого члена совета важнее всего попасть в новый совет, и он никогда не проголосует за предложение, в котором для него нет места. Во-вторых, если философ входит в предлагаемый совет, он предпочитает получить как можно более высокий ранг, то есть как можно меньшее число: быть философом 1 лучше всего, философом 2 - второй по предпочтительности вариант и так далее. В-третьих, если место философа в совете и его ранг уже определены, он предпочитает, чтобы совет был как можно меньше, поскольку не хочет без необходимости делиться властью.
Предположим, что сейчас в совете пять членов. Какое предложение выдвинет философ с самым низким рангом, то есть философ 5?
В мой телеграм‑канал про 152-ФЗ регулярно приходит один и тот же вопрос, только с двух противоположных сторон. Бухгалтер на аутсорсе спрашивает: «я веду учёт для десяти компаний, чем мне это грозит?» А через неделю пишет владелец фирмы: «мы отдали бухгалтерию на сторону, нам вообще что‑то нужно оформлять?» Оба чувствуют, что с персональными данными что‑то не так, но никто не понимает, что именно. И вот вопрос, который я задаю в ответ обоим: а вы вообще знаете, кем приходитесь друг другу по закону?
Предлагаю разобраться с этим. Для этого постараюсь встать на ту сторону, где риск больше, — сторону заказчика.
С современным уровнем развития технологий многие вещи, которые раньше казались фантастическими, порой можно реализовать буквально за один вечер. В данной статье я расскажу как можно легко и непринужденно создать свою собственную PoE IP камеру с возможностью удаленного доступа через браузер.
Представьте, разработчики добавили прозрачное шифрование в файловую систему, собрали ядро и прогнали Fio — пропускная способность не изменилась. Однако после раскатки на продакшен производительность резко упала. Дело не в том, что бенчмарк ошибся: он честно измерил предел быстродействия жесткого диска, а накладные расходы на шифрование остались скрыты за дисковыми задержками. Так и возникает одна из самых типичных ошибок storage-бенчмаркинга.
Хранение до сих пор кажется многим инженерам простой подсистемой: файловая система, блочное устройство, метрика throughput. На практике это одна из самых коварных частей стека — с иерархией памяти в 4–8 порядков разницы между самой быстрой и самой медленной операцией, слоями виртуализации (LVM, программные RAID, NFS) и переключениями контекста между ядром и user-space.
Чтобы разобраться, как корректно измерять производительность систем хранения, обратимся к докладу Эреза Цадока, профессора Университета Стони-Брук, возглавляющего Лабораторию файловых систем и хранения данных.
Все подробности — под катом.
В далеком 1999 году я написал и опубликовал статью с таким названием в журнале Сети. Тема была актуальной в эпоху бурного развития уличного Wi‑Fi и радиомодемов, которыми занимались многочисленные тогда беспроводные операторы. Сейчас их немного, успешные были поглощены крупными компаниями, остальные просто ушли.
У крупных компаний проблем с расчетом на сегодня нет, они используют профессиональные расчетные среды и цифровые модели местности. Стоят они дорого, но успешно решают задачи по расчету радиоканалов и зон покрытия. Тем не менее круг пользователей радиоканалов остается достаточно большим и не сильно богатым, чтобы позволить себе приобретение профессиональных расчетных программ. Это разработчики радиосистем связи, уже немногочисленные системные интеграторы, корпоративные структуры, да просто радиолюбители.
Все они часто задаются вопросом: как рассчитать и какими, желательно недорогими или бесплатными программами воспользоваться. Ниже — краткое пояснение методики расчета и обзор таких средств.
Привет, Хабр! Меня зовут Алексей Васильев, я тимлид команды «Рекомендательные системы и персонализация» Sber AI Lab — Центра практического искусственного интеллекта Сбера. Мы занимаемся исследованиями в области рекомендаций, разрабатываем новые модели и, конечно, сравниваем свои результаты с результатами коллег и других исследователей. И регулярно сталкиваемся с ситуацией, когда результаты, заявленные в научной статье или полученные от другой команды, не удаётся воспроизвести, хотя ключевые параметры пайплайна полностью совпадают. В этой статье мы с Анной Володкевич, исследователем из нашей команды, расскажем про свой опыт анализа таких расхождений, на основе которого разработали фреймоворк SplitLight.
Когда результаты научной статьи или успех другой команды не удаётся воспроизвести, обычно начинают с поиска багов в реализации модели: смотрят архитектуру, функцию потерь, способ сэмплирования негативных примеров. Хотя часть несоответствий обусловлена именно этим, наш практический опыт показывает, что процедура подготовки данных зачастую сильнее влияет на итоговый результат сравнения рекомендательных моделей. Например, формулировка из статьи «датасет Zvuk, global temporal split с квантилем 0,9» не сообщает, какие фильтры и агрегации применяли, как обрабатывали события с одинаковыми временными метками и повторные взаимодействия, удаляли ли холодные объекты, какие данные передавали модели на вход и по каким событиям рассчитывали метрики. Поэтому два пайплайна с одним датасетом и одинаковым названием разбиения могут оценивать разные постановки задачи. Это затрудняет воспроизведение экспериментов и сравнение результатов между работами.
Офисный переезд без остановки работы начинается с того, что физическое перемещение и работу с данными разводят по разным ответственным ещё до старта. ИТ-команда заказчика отвечает за бэкапы, корректное отключение сервисов и проверку запуска на новом месте; подрядчик — за упаковку, маркировку, перенос и расстановку; менеджер проекта сводит оба графика в один. Эта статья даст готовый шаблон запросов, чтобы разослать по потенциальным подрядчикам: техническое задание, пять главных вопросов, ред флаги и матрицу оценки ответов с весом каждого пункта.
Если коротко: выбирайте компанию для офисного переезда, которая до подписания договора осматривает оба объекта, письменно фиксирует состав работ и возможные доплаты до переезда, назначает ответственного менеджера и отдельно планирует перенос ИТ-оборудования.
За последние пару лет произошло странное: написать работающий код стало почти неприлично легко, а построить хорошую программную систему наоборот - сложнее. Сегодня человек без классического IT-бэкграунда может за вечер собрать интерфейс, API, базу и даже что-то задеплоить. А потом начинается самое интересное: архитектура расползается, зависимости живут своей жизнью, безопасность появляется «во второй версии», а никто уже толком не понимает, почему система вообще работает.
Я написал эту статью после наблюдений за коллегами, студентами и знакомыми, которые всё активнее используют ИИ для разработки. И поймал себя на мысли: ИИ удешевил производство кода, но почти не удешевил понимание того, какой код нужно производить.
Отсюда и главный вопрос: как вообще должна выглядеть маленькая IT-компания, если значительную часть работы уже могут выполнять цифровые исполнители?
Представляю мою спорную модель такой компании: умница-аналитик, архитектор-разработчик, супертестировщик, фантазёр, DevOps, параноик по безопасности. Плюс общая память компании, потому что без неё нейросети очень быстро начинают изобретать архитектуру заново.
Возможно, половина этих ролей действительно может оказаться одним человеком в домашних тапочках. Но тогда к этому человеку возникает неприятно много требований...
Маркетолог прислал мне скрин дашборда и одно слово: «пусто».
На скрине — панель «Количество пришедших по реферальной ссылке за период». Ноль. Под ней — график регистраций. Тоже ноль. Ссылка, по которой он пришёл, вела на дашборд с фильтром по конкретному slug — тому самому, который он неделю крутил в закупке.
Я открыл ту же ссылку, поменял в урле from=now-6h на from=now-30d и увидел 16 регистраций.
Дефолтный интервал в Grafana — 6 часов. У бота ночью в этой гео никого нет. Аналитика работала идеально и показывала абсолютно честный ноль.
Это самая безобидная из историй, которые тут будут. Дальше — про то, как мы строили продуктовую аналитику для Telegram-бота с AI-персонажами на ~300K MAU, ~75 RPS в пике и ~1.5M событий в день: без ClickHouse, без Amplitude, без единой event-таблицы. Двенадцать дашбордов в Grafana поверх боевой MySQL. Три из них какое-то время врали, и это выяснилось не сразу.
Главный парадокс всего проекта помещается в одну строку: через систему проходит полтора миллиона событий в день, и ни одно из них не записано как событие. Есть только строки в продуктовых таблицах и их created_at. Всё, что вы прочитаете ниже, — следствие этого факта.
Статья — не туториал «подключите MySQL к Grafana за 10 шагов». Это разбор того, что происходит, когда продуктовые метрики приходится доставать из схемы, которую проектировали под продукт, а не под аналитику, — и когда по этим метрикам прямо сейчас решают, лить трафик дальше или нет.
Дисклеймер: проект под NDA, поэтому названия, точные объёмы и часть деталей изменены. Порядок величин, схема и сами проблемы — настоящие.
Привет! В предыдущей статье https://habr.com/ru/articles/1042328/ я рассказал о математической оценке коэффициента шума (КШ) методом отношения сигнал-шум. Сегодня перейдем от теории к практике - к автоматизации радиоизмерений. Покажу, как построить гибкую систему управления измерительными приборами на Python, которая не боится разношёрстного парка оборудования в лаборатории.