Разработка

Я пришел в Data Science не сразу. Учился в магистратуре по вечерам, работая в совершенно другой сфере (строительство). Осваивать машинное обучение и анализ данных было интересно, но один из самых неожиданных вопросов, который возник буквально сразу - в какой среде писать код?

На первый взгляд кажется, что Jupyter Notebook, Google Colab, Kaggle и сравнительно новая Marimo - это одно и то же, ноутбук с ячейками и Python (так же поддерживаются другие языки программирования). Но на практике каждая из этих сред подходит для разных задач, где-то удобнее учиться, а где-то работать командой.

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

Статья будет полезна:

Поколение большого пальца – вот как нас называли. Какие глубокомысленные переписки мы ухитрялись вести на кнопочных телефонах, набирая текст SMS большим пальцем асинхронно с конспектированием лекций…

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

Естественно, в Kotlin Flow, где данные текут непрерывным потоком и легко провоцируют избыточные реакции, эта проблема стоит особенно остро. Например, если мы построим на Flow систему автодополнений, то увидим что-то такое:

История о том, как написать свой P2P-мессенджер, когда Discord и Telegram перестали устраивать. В статье разбирается устройство транспортного протокола с ECDH и ротацией ключей, решение проблем с NAT traversal, реализация голосовых звонков и работа с аудиоустройствами. Бонусом — откровенный опыт использования LLM для написания кода: что работает из коробки, а какие модули пришлось полностью переписывать.

Можно использовать iperf3, но он про TCP и базовый UDP. Можно взять отдельные QUIC-библиотеки, но без визуализации и нагрузки. Можно написать кастомные симуляторы, но они не отражают реального поведения каналов. Хочешь проверить, как BBRv3 ведет себя на трассе Москва — Новосибирск? Пожалуйста, найди три сервера в разных дата-центрах, настрой netem, собери метрики вручную и надейся, что результаты будут воспроизводимы.

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

Недавно я получил письмо с embedded.com о новом микроконтроллере MSPM0C1104. Что в нем такого кроме размеров? Разбираемся.

В этом тексте я бы хотел рассказать про простой бинарный протокол, который я сам придумал для всяческих нужд при разработке приборов на микроконтроллерах. Называется он TBFP (Trivial Binary Frame Protocol)

Локаторы являются одним из ключевых элементов UI‑автоматизации. От того, насколько устойчиво тест находит нужный элемент, зависит стабильность всего тестового набора. Несмотря на кажущуюся простоту, выбор правильного локатора часто становится самым критичным и самым недооценённым аспектом автоматизации.

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

В настоящее время я занимаюсь подготовкой рукописи для второго издания книги «История моей страны. Записки военного инженера-программиста». Естественно, в ней много старых черно-белых фотографий разного качества. Это не только бытовые фотографии, но и уникальные фотографии вычислительной техники, которая сегодня не только не выпускается, но порой и не сохранилось ни одного экземпляра. В 90-е года эту технику бойко сдавали на драгметаллы. Но сегодня еще живут люди, которые работали в те времена, видели и даже творили на этой техники. Они могут рассказать, как и что выглядело. Я знаю многих людей глубоко пенсионного возраста, которые занимаются восстановлением старых фотографий в цвете. Это тяжелая и кропотливая работа. Но в конце августа сего года вышла модель генерации изображений Nano Banana от компании Google, которая просто совершила революцию в этом деле, но и она, несмотря на свои возможности, имела недостатки:

Изучая получившийся клеточный автомат Коллатца (CCA), ранее описанный в статье. Я задумался о том, как лучше показать взаимодействие его клеток, чтобы это было доступно и наглядно. Простое описание опций, это теоретическая часть, но как известно, практика, помогает укрепить понимание протекающих процессов.

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

Игра - Лабиринт

Не откладывая задачу в долгий ящик, представляю Вам прототип игры "Лабиринт".  На рисунке 1, представлен пример поля лабиринта, основанного на CCA. Справа от поля имеется легенда с описанием цветов ячеек.

Привет, Хабр! Я Ильдар Ишкинин, ведущий инженер Центра компетенций Innostage. В этой статье хочу поделиться результатами нагрузочного тестирования отечественного NGFW «Континент 4», которое мы провели в нашей лаборатории INSI (Innostage Security Infrastructure).

Работаете с ИИ-ассистентом и чувствуете, что он вас не понимает? Ломает архитектуру, пишет код мимо кассы, а на простые вопросы отвечает какой-то ерундой?

Спокойно. Скорее всего, дело не в нём. Давайте разберёмся, где кошка зарыта.

Обзор на браузерные API, которые стали Widely available в октябре 2025. Раз в месяц я буду вам напоминать, что вы уже можете использовать в проде.

Каждый месяц выходят новые CSS-свойства, HTML-атрибуты, JavaScript-методы и WebAPI, но применять в проде мы их конечно же не будем. 2.5 года назад также каждый месяц выходили новые фичи в браузере, а вот их уже пора начинать применять.

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

Онлайн‑игры давно стали частью повседневности: миллионы людей заходят вечером «сыграть пару каток», кто‑то строит карьеру в киберспорте, а кто‑то просто ищет отдых после работы. Но вместе с этим миром выросла и его тень — читеры. Они всегда рядом: в рейтинговых матчах, в казуальных режимах, даже в мобильных проектах. И сколько бы индустрия ни тратила сил на борьбу, окончательной победы так и не случилось.

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

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

Всем привет, меня зовут Рома, я работаю во ВкусВилле, руковожу портфелем ИИ-проектов. Пишу про продукты и управление проектами у себя на канале: https://t.me/gde\_value. Сегодня расскажу, как спор между командами привел нас к пересмотру методов планирования рабочей недели. 

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

Недавно обсуждал это с тимлидом из Ozon. Мы крутились вокруг темы эффективного количества рабочих часов, и ближе к концу он вкинул фразу: «Ну, сорокачасовая неделя ведь не зря придумана; наверное, кто-то исследовал и доказал, что так эффективнее всего». Эта фраза зацепила. Она звучит как успокаивающий миф, как будто есть универсальная «магическая» цифра, и если не выходить за её пределы, то и продуктивность, и здоровье в порядке. Но внутренне я вижу другое: одни люди успевают сокрушительный объём за те же часы, в которых другие тонут в бесконечных переключениях и «шуме».

Привет, Хабр! В предыдущем материале мы упомянули, что при работе с текстовыми корпусами embedding-модели не всегда оптимальный инструмент. В этой публикации на примере задачи поиска релевантных документов по запросу рассмотрим ограничения такого варианта решения, разберем на практике гибридный подход и оценим его эффективность.

Меня зовут Вадим Скляров, я аналитик компании MWS, и уже по традиции мы будем разбираться в технической задаче с позиции системного и бизнес-анализа:

— сформулируем основные моменты, которые нужно знать и описать, прежде чем передать проект команде разработки;

— рассмотрим, как быстро проверить подходы к решению.

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

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

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

Речь пойдёт о некогда созданной мной библиотечкe, музыкальном «драйвере» или движке под названием «FamiTone», предназначенном для озвучки любительских (homebrew) игр для 8-битной игровой приставки Famicom, она же NES, она же «Денди». По пути разберёмся, что это, как устроено, кому и зачем вообще могло понадобиться, и пригодилось ли в итоге. Спойлер: да.

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

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

Почему оборудование и люди не спасают, а ИБ превращается в кошмар

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

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