Давайте натрём наши болиды до блеска и посмотрим, как они входят в повороты компиляторных оптимизаций на примере использования std::array. Смогут ли они не только не уступить, но и обогнать встроенный массив?
Мало какая компания пользуется среди поклонников компьютера ZX Spectrum такой любовью и уважением, как Ultimate Play the Game. За свою недолгую историю она выпустила два с лишним десятка игр, бóльшая часть которых моментально становились бестселлерами. Многие из них мы ставим на «Спектрумы» в Яндекс Музеях. Особенной любовью публики пользуются Jetpac и Knight Lore, причём последняя зачастую заставляет посетителей удивлённо переспрашивать: «А этой игре точно недавно стукнуло 40 лет?»
В шедевры Ultimate Play the Game я начал играть с того момента, как у меня появился ZX Spectrum — то есть с 1991 года. Тогда мало кто знал, откуда появилась эта компания и как она умудрилась наделать такое количество прекрасных игр за столь короткое время.
И вот, спустя много‑много лет, я решил найти ответы на эти вопросы. Для этого я достал с полки все фирменные игры Ultimate, купленные в Великобритании, для удобства скачал их образы из интернета и потратил несколько дней, чтобы как следует в них наиграться. А затем обложился журналами Crash, Your Sinclair и Sinclair User, нашёл в интернете несколько десятков статей про Ultimate Play the Game и её создателей… И погрузился в расследование.
Кто же эти гении, буквально за полтора года прошедшие путь от Jetpac до Knight Lore? И почему информации о создании всех игр Ultimate так мало? Давайте разбираться вместе.
Привет, Хабр!) Меня зовут Ильяс. В этой статье мы разберём известную идею — keepalive в межсервисном взаимодействии, которая спасла уже не одну компанию в трудное время :). Но чтобы добавить интереса, мы разберём, какие проблемы в keepalive принесли современные технологии (ведь что может пойти не так с этой простой идеей?). Поэтому в статье мы рассмотрим механизмы, которые позволяют проверять стабильность соединения между клиентом и сервером в случае, когда обычные TCP keepalive из-за сложности архитектуры не могут определить состояние сервера.
Привет, Хабр! В статье подробно рассмотрим область применения самого базового статистического критерия Стьюдента. Посмотрим, как он ведёт себя, когда мы не хотим отдавать качество подбора наших групп на волю случая.
Привет! Меня зовут Настя, я старший системный аналитик в X5 Tech. Я рисую sequence-диаграммы каждый день на протяжении четырёх лет. За это время я прошла все круги ада по Данте, то есть попробовала разные инструменты для рисования этих самых диаграмм. Пока не встретила его – PlantUML.
Что удивительно, инструмент довольно не новый, но тем не менее лучше него я пока не встречала. А ещё удивительно, что он не особо популярный. Когда мы запустили в управлении системного анализа первый воркшоп по PlantUML, за 3 минуты после анонса пришли 12 заявок от аналитиков разных грейдов – от Junior до Lead.
В процессе подготовки материалов к воркшопу мы искали статьи и литературу, которые помогли бы дополнительно изучить sequence-диаграммы в PlantUML. Ничего интересного мы не нашли.
На самих воркшопах участники часто говорили о том, что они пытались самостоятельно изучить PlantUML, но их пугало то, что нужно писать какой-то код и учить какой-то синтаксис. Документация достаточно обширная, но информации о том, как последовательно строить sequence почти нет.
Поэтому и появилась эта статья.
Всем привет, меня зовут Илья Аллендорф, я занимаюсь дизайном внутреннего продукта в X5 Tech. В статье расскажу, как я улучшил подготовку макетов для разработки и навёл порядок в рабочем проекте в Figma.
В 2023 году я пришёл в новый продукт, который разрабатывался с нуля. За два года мы запустили MVP, перевели бизнес-процесс в продукт, достигли целевых метрик, а ещё совершили ошибки и сделали ценные выводы. Кроме того, мы ускорили сycle time, улучшив взаимодействие с дизайном: навели порядок в Figma, договорились с аналитиками, упростили жизнь разработке и уменьшили этап дизайн-ревью.
Сегодня поговорим о неочевидной особенности некоторых коллекций в .NET. Долго вокруг да около ходить не будем и начнём с задачки на самопроверку.
Привет, Хабр! Меня зовут Дмитрий Селютин, я ведущий разработчик команды R&D в Cloud.ru.
Ситуации, когда при решении совершенно конкретной задачи упираешься в сложности откуда-то сбоку, возникают в разработке с завидной регулярностью. В задачах, зависящих от автоматизации, очень часто случается, что слабым местом оказываются непосредственно инструменты для этой автоматизации, если они вообще есть. Такие инструменты могут рождаться и умирать, но порой они могут возрождаться заново. Сегодня поделюсь рассказом о том, как в ходе исследований производительности нашего облака Cloud.ru Evolution мы внезапно сделали SDK и CLI посредством генерации кода и интроспекции. Статья будет полезной всем, перед кем стоит задача быстро обернуть сгенерированный API на Python в нечто более симпатичное и поможет из этого автоматически сделать CLI. Ну а для тех, кто не связан с темой, это будет поучительная история из разряда «если у вас завалялся кусочек кода, не спешите его выбрасывать».
При запуске новых плат и устройств с PCIe-соединениями недостаточно просто вставить карту в слот. Нужно так настроить эквалайзеры, редрайверы, пресеты и ретаймеры, чтобы на каждой полосе «поднялся линк», то есть установилось соединение. Это значит, что приемопередатчики на обоих концах распознали друг друга, договорились о кодировке и скорости передачи.
Долгое время без специального дорогостоящего инструмента нельзя было убедиться в устойчивости линка: что он не пропадает при малейших воздействиях температуры, влажности или любопытных лапок. То есть нелегко было узнать количественный запас по уровню сигнала, насколько он близок к границе потери различимости физических уровней — а значит, и разрыва соединения. Эта безнадежная ситуация изменилась с появлением четвертого поколения стандарта PCIe.
TLDR. Я примерно год создавал курс из 141 урока. Курс получился хороший, все кто проходят рады и пишут положительные отзывы. Я пытался его продавать, в лучшем случае у меня получалось отбивать рекламу в ноль. Короче, я хороший разработчик, я хорошо доношу материал, но я плохой маркетолог. Все эти таргреты, ретаргеты, воронки, шморонки — тоска унылая. Мне гораздо веселее и понятнее заработать на создании и запуске IT-продуктов, чему я и учу в этом учебнике. Так что пишу эту статью, чтобы сообщить вам о существовании моего курса и предложить всем желающим абсолютно бесплатно получить от него пользу 🙂
Цель обучения — создать проект с нуля, изучив и применив технологии и архитектуру, которые обеспечивают качество и масштабируемость вашего кода, скорость разработки, а также удовольствие и радость от процесса.
Привет, Хабр! Меня зовут Станислав Егоркин, я инженер юнита IaaS департамента разработки Infrastructure в Авито. В этой статье я расскажу про инструмент, который мы используем для обнаружения деградаций на нодах в кластерах Kubernetes, а также покажу дашборд, где мы наблюдаем за состоянием всех наших нод.
Написать эту статью меня побудил один забавный случай. Он хорошо демонстрирует, что не стоит слепо доверять одному источнику, каким бы авторитетным он ни был. Впрочем, обо всём по порядку.
Когда только начинаешь карьеру разработчика, часто гложет сомнение: верно ли я выбрал язык программирования? Может, он уже устарел, или наоборот — слишком новый и не факт, что перспективный? Легко ли будет найти по нему актуальные книги и уроки? Много ли таких неофитов будет вместе со мной обивать пороги ИТ-компаний через год-два?
Опытным разработчикам тоже порой не хватает знания единственного языка программирования. В какой-то момент появляются специфические заказы и интересные вакансии, где крайне желательно владеть вторым (а то и третьим) языком.
Помочь с выбором языка программирования призваны рейтинги их популярности. Однако тут легко обмануться. Каждый рейтинг составляется по своей методике и даёт разные результаты (порой — весьма неожиданные). В этой статье я постарался сделать более взвешенную оценку популярности языков программирования (далее — ЯП) по нескольким источникам. Подробнее о них и почему это важно — рассказываю ниже.
Индексы популярности
Всё началось с того, что мне попался на глаза свежий рейтинг актуальности ЯП, где в TOP 10 внезапно ворвался Delphi. Пытаясь разобраться в причинах его внезапной популярности в 2025 году, я стал искать методики составления таких списков и нашёл много любопытного. Как обычно, дьявол кроется в деталях.
Индекс TIOBE — известный инструмент мониторинга, показывающий динамику интереса к разным ЯП. Он учитывает частоту поисковых запросов, связанных с ЯП. Для этого каждый месяц в Google, Bing, Yahoo! и Baidu отправляются запросы по определённому шаблону, чтобы отсеивать из выдачи мусор и корректно сравнивать статистические данные. Дополнительно в рейтинге учитывается число образовательных материалов о ЯП: количество видеоуроков на YouTube, книг на Amazon и упоминаний на Wikipedia.
Всем привет! Это Сергей Качеев, старший разработчик в отделе сетевой инфраструктуры Yandex Infrastructure. Наша команда создаёт технологии, на которых работают сервисы Яндекса. В прошлый раз я рассказал целый сетевой детектив о том, как мы искали баг, который убивал DNS‑сервер Unbound. И сегодня я расскажу не менее интересную историю.
Мне на развитие попала XDP eBPF‑программа, которая защищает DNS‑серверы от выхода из строя под слишком большой нагрузкой (другими словами, от DDoS). На ядре 5.4 алгоритм защиты был основан на EWMA‑статистике с вероятностными дропами, которые постоянно контролировались из Control Plane. Это делало eBPF‑программу неавтономной. К тому же если Control Plane падал, то сервер оставался в состоянии последнего удачного обновления eBPF. Это нужно было исправлять — было решено заменить это всё на Token Bucket. Этот момент и будем считать отправной точкой в нашей истории.
Привет! Наш отдел разработки в Ozon Tech часто сталкивается с проблемой онбординга руководителей команд, ведь в каждой компании работа тимлида имеет свою специфику и не всегда позволяет ощутить остроту всех граней управления группой разработчиков. Статья представляет собой настольную инструкцию для лида, которую можно изучать самому или адаптировать для своей команды тимлидов.
Меня зовут Арманд, я руководитель отдела Ozon Crowd. Наш основной продукт — это краудсорс-система Ozon Profit. Изначально я собирал материал для приватной страницы онбординга руководителя в нашу команду, но получилось выделить общие моменты (убрать всю секретную информацию) и составить цельную картину того, с чем может столкнуться начинающий менеджер. Этим я и хочу поделиться с сообществом.
Материал статьи не претендует на объективность. Все упомянутые истории происходили в моей практике или в практике моих сотрудников, совпадения не случайны. Без лишних предисловий, начнём!
Поговорили с Сергеем, ведущим Java-разработчиком Нижегородского подразделения «Криптонита». В интервью – о языке программирования Java, «синих воротничках», бесполезности pet-проектов и работе инженера в энтерпрайзе без прикрас.
Сергей, расскажи, как именно ты пришёл к мысли изучать Java?
Это забавная история. Все мальчишки в начале 90-х хотели компьютер для игр. Моим товарищам покупали «Спектрум», на котором игры были цветные. У моих родителей не было таких денег. Поэтому они, скрепя сердце, купили мне старый компьютер без модуля цветной псевдографики. Назывался он «Партнер 01.01», как сейчас помню.
Мои приключения с растениями продолжаются. Я выращиваю настоящий васаби в Москве и планирую построить для него целую ферму. Сейчас я озабочен поиском посадочного материала для своей фермы, но купить рассаду настоящего васаби в России невозможно, её нет физически. Поэтому я решил производить её самостоятельно. И не абы как, а с помощью микроклонального размножения. Для этого я из подручных средств организовал себе лабораторию, о ней и будет этот пост.
В статье речь пойдет об ALD Pro (Astra Linux Domain Pro).
Один заказчик попросил предоставить инструмент нагрузки LDAP-запросов, да не простой, а с GUI и графиками.
Наша команда в своей работе активно использует open source инструмент нагрузочного тестирования Locust (англ. Саранча). Сам по себе Locust является ядром нагрузки с минимальным функционалом из коробки, но этот функционал расширяется за счет использования Locustfiles, которые пишутся на чистом Python, что позволяет не ограничиваться набором инструкций, как, например, в Dockerfile/Containerfile/Vagrantfile, а писать отдельные Python-модули.
На создании инструмента нагрузки ничего не закончилось, а все только началось.
Мы нагрузили ALD Pro, получили графики и...обнаружили катастрофу.
Распознавание жестов — это технология, которая позволяет людям взаимодействовать с устройствами без физического нажатия кнопок или сенсорных экранов. Интерпретируя жесты человека, эта технология нашла свое применение в различных потребительских устройствах, включая смартфоны и игровые консоли. В основе распознавания жестов лежат два ключевых компонента: сенсор и программный алгоритм.
В этом примере используются измерения акселерометра MPU 6050 и машинное обучение (ML) для распознавания трех жестов рукой с помощью ESP32. Данные из сенсора распознаются на микроконтроллере и результат выводится в консоль в виде названия жеста и вероятности результата. Модель ML использует TensorFlow и Keras и обучается на выборке данных, представляющей три различных жеста: "circle" (окружность), "cross" (пересечение) и "pad" (поступательное движение).
Разработка проекта начнется с получения данных из акселерометра для построения набора жестов. Затем мы проектируем полносвязную нейронную сеть для распознавания жестов, и подключим модель в проекте ESP32.
В следующей части рассмотрим как настроить Bluetooth LE (BLE) на ESP32 и Android устройстве. Передадим квантированный набор ускорений сенсора по BLE. Настроим Модель ML для распознания жестов на Android.
Привет, Хабр! Меня зовут Денис Савран. Я старший разработчик направления серверной разработки на интерпретируемых языках и работаю в компании «Криптонит». В этой статье я хочу поделиться опытом сборки проектов на Python с использованием самых современных инструментов.
Меня зовут Ира и я руковожу отделом тестирования мобильной платформы: наш отдел занимается разработкой инструментов для автоматизации тестирования мобильных приложений Ozon и тестированием внутренних библиотек, которые используются в наших приложениях. Около года назад мы пытались понять, почему у одной из команд джоба с автотестами отваливается по тайм-ауту. К слову, это был проект мобильного приложения для продавцов, и на нем у нас для автоматизации тестирования используются нативные фреймворки: Kaspresso + Kotlin для Android и XCTest + Swift для iOS.
Одна из гипотез заключалась в том, что в приложении могут быть утечки памяти и что-то зависает. Спойлер: дело было не в этом. В общем, около года назад я проверяла, что к чему там у нас с памятью приложения, а сейчас поняла, что полученными знаниями можно и поделиться.
Эта статья будет полезна тем, кто только начинает изучать, что происходит со стабильностью мобильного приложения. Внутри статьи разберёмся с тем, как приложение работает с оперативной памятью; что такое утечки памяти и когда они возникают; как утечки влияют на стабильность работы приложения и как их находить.