Недавно мне довелось поработать над приложением, которое должно было контролировать скорость своих исходящих подключений. Например, подключаясь к одному URL приложение должно было ограничить себя, скажем, 200KiB/sec. А подключаясь к другому URL — всего 30KiB/sec.

Самым интересным моментом здесь оказалось тестирование этих самых ограничений. Мне потребовался HTTP-сервер, который бы отдавал трафик с какой-то заданной скоростью, например, 512KiB/sec. Тогда бы я мог видеть, действительно ли приложение выдерживает скорость 200KiB/sec или же оно срывается на более высокие скорости.

Но где взять такой HTTP-сервер?

Поскольку я имею некоторое отношение к встраиваемому в С++ приложения HTTP-серверу RESTinio, то не придумал ничего лучше, чем быстренько набросать на коленке простой тестовый HTTP-сервер, который способен отдавать клиенту длинный поток исходящих данных.

О том, насколько это было просто и хотелось бы рассказать в статье. Заодно узнать в комментариях, действительно ли это просто или же я сам себя обманываю. В принципе, данную статью можно рассматривать как продолжение предыдущей статьи про RESTinio под названием "RESTinio — это асинхронный HTTP-сервер. Асинхронный". Посему, если кому-то интересно прочитать о реальном, пусть и не очень серьезном применении RESTinio, то милости прошу под кат.

«Закон масштабирования Деннарда и закон Мура мертвы, что теперь?» — пьеса в четырёх действиях от Дэвида Паттерсона

«Мы сжигаем мосты, по которым сюда мчимся, не имея других доказательств своего движения, кроме воспоминаний о запахе дыма и предположения, что он вызывал слёзы» — «Розенкранц и Гильденштерн мертвы», абсурдистская пьеса Тома Стоппарда

15 марта д-р Дэвид Паттерсон выступил перед аудиторией из примерно 200 наевшихся пиццы инженеров. Доктор вкратце изложил им полувековую историю конструирования компьютеров с трибуны в большом конференц-зале здания E в кампусе Texas Instruments в Санта-Кларе во время лекции IEEE под названием «50 лет компьютерной архитектуры: от центральных процессоров до DNN TPU и Open RISC-V». Это история случайных взлётов и падений, провалов и чёрных дыр, поглотивших целые архитектуры.

Паттерсон начал с 1960-х годов и новаторского проекта IBM System/360, основанного на ранних работах Мориса Уилкса по микропрограммированию 1951 года. По меркам IT это было давным-давно… Ближе к концу выступления Паттерсон показал потрясающую диаграмму. Она наглядно демонстрирует, как именно смерть закона масштабирования Деннарда, за которой следует смерть закона Мура, полностью изменили методы проектирования компьютерных систем. В конце он объяснил посмертные технологические последствия этих потрясений.

Или как мы писали клиентскую C++ библиотеку для ZooKeeper, etcd и Consul KV

В мире распределённых систем существует ряд типовых задач: хранение информации о составе кластера, управление конфигурацией узлов, детекция сбойных узлов, выбор лидера и другие. Для решения этих задач созданы специальные распределённые системы — сервисы координации. Сейчас нас будут интересовать три из них: ZooKeeper, etcd и Consul. Из всей богатой функциональности Consul мы сосредоточимся на Consul KV.



По сути все эти системы представляют собой отказоустойчивые линеаризуемые key-value хранилища. Хотя их модели данных и имеют существенные отличия, о чём мы поговорим позднее, они позволяют решать одни и те же практические проблемы. Очевидно, каждое приложение, использующее сервис координации, завязывается на один из них, что может приводить к необходимости поддерживать в одном датацентре несколько систем, решающих одинаковые задачи, для разных приложений.

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

Одной из самых знаменитых способностей Супермена является суперзрение, которое позволяло ему рассматривать атомы, видеть в темноте и на огромное расстояние, а еще видеть сквозь предметы. Эту способность крайне редко демонстрируют на экранах, но она есть. В нашей же реальности видеть сквозь практически полностью непрозрачные объекты также можно, применив некоторые научные трюки. Однако, полученные снимки всегда были черно-белые, до недавнего времени. Сегодня мы познакомимся с исследованием, в котором ученые из университета Дьюка (США) смогли сделать цветной снимок объектов, спрятанных за непрозрачной стеной, применив однократное световое воздействие. Что это за супер-технология, как она работает и в каких областях может применяться? Об этом нам расскажет доклад исследовательской группы. Поехали.

Как вырасти в 10 раз под количеству запросов к БД не переезжая на более производительный сервер и сохранить работоспособность системы? Я расскажу, как мы боролись с падением производительности нашей базы данных, как оптимизировали SQL запросы, чтобы обслуживать как можно больше пользователей и не повышать расходы на вычислительные ресурсы.

Привет, хабровчане! В прошлой теме я рассказывал, как мы с командой производили (и дальше производим) ромхакинг такой игры, как Xenoblade Chronicles на Nintendo Wii. Я бы хотел рассказать о менее простой, но интересной теме – устройство хранения файловой системы у Nintendo GameCube. Так уж вышло, что я полюбил данную консоль и никак не мог упустить шанс рассказать о её технической стороне, хоть и малой. Не будем затягивать, начнём!

Какое-то время назад Хабре проскакивала заметка про клиент-парсер сайтиков на Питоне. Автор на этом примере разбирал проблемы многопоточных сетевых приложений.

Но мне показалось, что ту же задачу (вернее, ее главную часть — параллельные соединения c http-cервером) вполне можно эффективно решить и без потоков.

Разработчикам часто приходится иметь дело с файлами, представляющими из себя древовидную структуру: XML, JSON, YAML, всякого рода языки разметки вроде Markdown или Org-mode. Облегчая в общем и целом нашу жизнь, такие файлы имеют склонность к бесконтрольному росту, в какой-то момент из решения превращаясь в проблему.

Стандартное решение этой проблемы — разбиение на меньшие файлы. Это, конечно, работает, но не всегда удобно.

Но существует и альтернатива, о которой — ниже.

Виртуальные машины языков программирования в последние десятилетия получили весьма широкое распространение. С презентации Java Virtual Machine во второй половине 90-х прошло уже достаточно много времени, и можно с уверенностью сказать, что интерпретаторы байт-кодов — не будущее, а настоящее.

Но данная техника, на мой взгляд, практически универсальна, и понимание основных принципов разработки интерпретаторов пригодится не только создателю очередного претендента на звание "Язык года" по версии TIOBE, но вообще любому программисту.

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

"No matter how hard you try, you can't make a racehorse out of a pig. You can, however, make a faster pig" (комментарий в исходном коде Емакса)

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

Во второй части серии статей об интерпретаторах байт-кодов я на примере небольшой стековой виртуальной машины ПВМ («Поросячья Виртуальная Машина») постараюсь показать, что не всё потеряно для трудолюбивых поросят с амбициями и что в рамках (в основном) стандартного C вполне возможно ускорить работу таких интерпретаторов по меньшей мере в полтора раза.

17 млрд событий, 60 млн пользовательских сессий и огромное количество виртуальных свиданий происходят в Badoo ежедневно. Каждое событие аккуратно сохраняется в реляционные базы данных для последующего анализа на SQL и не только.

Современные распределённые транзакционные базы данных с десятками терабайт данных — настоящее чудо инженерной мысли. Но SQL как воплощение реляционной алгебры в большинстве стандартных реализаций пока не позволяет формулировать запросы в терминах упорядоченных кортежей.

В последней статье из серии, посвящённой виртуальным машинам, я расскажу про альтернативный подход к поиску интересных сессий — движок регулярных выражений («Поросячий Матчер»), определённых для последовательностей событий.

Виртуальная машина, байт-код и компилятор прилагаются бесплатно!

Сбор, хранение, преобразование и презентация данных — основные задачи, стоящие перед инженерами данных (англ. data engineer). Отдел Business Intelligence Badoo в сутки принимает и обрабатывает больше 20 млрд событий, отправляемых с пользовательских устройств, или 2 Тб входящих данных.

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

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

Добро пожаловать в первую часть «Современного рендеринга текста в Linux». В каждой статье из этой серии мы разработаем самодостаточную программу на C для визуализации символа или последовательности символов. Каждая из этих программ будет реализовывать функцию, которую я считаю необходимой для современного рендеринга текста.

В первой части настроим FreeType и напишем простой рендерер символов в консоли.



Вот что мы будем писать. А вот и код.

Такси должно быть комфортным и безопасным. А это зависит не только от качества автомобиля и сервиса, но и от концентрации внимания водителя, которая падает при переутомлении. Поэтому на уровне сервиса мы ограничиваем время, которое водитель проводит за рулём.

Но иногда водители выходят на линию уже уставшими — например, весь день человек был занят на другой работе, а вечером решил “подрулить”. Что с этим делать? Как понять, что водитель заступает на смену не выспавшись? Можно, например, попробовать оценить, насколько внимательно он следит за дорогой, и определить признаки усталости, например по характеру морганий. Звучит просто? Всё сложнее, чем кажется.

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

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

На русском языке довольно мало информации про то, как работать с ELF-файлами (Executable and Linkable Format — основной формат исполняемых файлов Linux и многих Unix-систем). Не претендуем на полное покрытие всех возможных сценариев работы с эльфами, но надеемся, что информация будет полезна в виде справочника и сборника рецептов для программистов и реверс-инженеров.

Подразумевается, что читатель на базовом уровне знаком с форматом ELF (в противном случае рекомендуем цикл статей Executable and Linkable Format 101).

Под катом будут перечислены инструменты для работы, описаны приемы для чтения метаинформации, модификации, проверки и размножения создания эльфов, а также приведены ссылки на полезные материалы.

На написание данной статьи меня вдохновила статья об анализе Сишного printf. Однако, там был пропущен момент о том, какой путь проходят данные после того, как они попадают в терминальное устройство. В данной статье я хочу исправить этот недочет и проанализировать путь данных в терминале. Также мы разберемся, чем отличается Terminal от Shell, что такое Pseudoterminal, как работают эмуляторы терминалов и многое другое.

Если выполнить вход на Spotify.me, то можно получить персонализированную сводку того, как Spotify понимает вас через музыку, которую вы слушаете на этом сайте Spotify. Это круто!

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

Мне было очень любопытно, существуют ли какие-то конкретные ингредиенты, из которых составлены хитовые песни. Что делает их крутыми? Почему нам нравятся хиты, и есть ли у них определённая «ДНК»?

Задача

Это привело меня к попытке ответить при помощи данных Spotify на два вопроса:

1. На что похож мой музыкальный плейлист?
2. Существуют ли конкретные атрибуты аудио, общие для всех хитовых композиций?

Инструменты

К счастью, есть очень простые инструменты, позволяющие подключиться к Spotify, получить данные, а затем визуализировать их.

Мы будем работать с языком программирования Python 3, библиотекой Python Spotipy, позволяющую подключаться к Spotify Web API, а визуализировать данные будем с помощью plot.ly и Seaborn.

Массив данных

В конце каждого кода Spotify компилирует плейлист из 100 самых часто воспроизводимых песен. Использованный мной массив данных уже выложен на Kaggle: Top Spotify Tracks of 2018. Список 100 самых популярных песен со Spotify кажется вполне разумным массивом данных для изучения хитов, не правда ли?

Если в одном из моих прошлых постов речь шла о довольно современном подходе к построению сбалансированных деревьев поиска, то этот пост посвящен реализации АВЛ-деревьев — наверное, самого первого вида сбалансированных двоичных деревьев поиска, придуманных еще в 1962 году нашими (тогда советскими) учеными Адельсон-Вельским и Ландисом. В сети можно найти много реализаций АВЛ-деревьев (например, тут), но все, что лично я видел, не внушает особенного оптимизма, особенно, если пытаешься разобраться во всем с нуля. Везде утверждается, что АВЛ-деревья проще красно-черных деревьев, но глядя на прилагаемый к этому код, начинаешь сомневаться в данном утверждении. Собственно, желание объяснить на пальцах, как устроены АВЛ-деревья, и послужило мотивацией к написанию данного поста. Изложение иллюстрируется кодом на С++.

Тема префиксных деревьев поиска уже неколько раз поднималась на хабре. Здесь, например, кратко описывается, что такое префиксное дерево и зачем оно нужно, и рассматриваются основные операции над такими деревьями (поиск, вставка, удаление). К сожалению, ничего при этом не говорится про реализацию. В этом недавнем посте рассматривается «питонья библиотека datrie», являющаяся Cython-оберткой библиотеки libdatrie. По последней ссылке имеется хорошее описание реализации частично сжатых префиксных деревьев в виде детерминированных конечных автоматов (с использованием массивов). Я решил внести свои пять копеек в эту тему, рассмотрев реализацию на языке С++ префиксных деревьев с помощью указателей. Кроме того, была и еще одна цель — сравнить между собой поиск строк с помощью сбалансированного двоичного дерева поиска (АВЛ-дерево) и сжатого префиксного дерева.

Перевод статьи подготовлен специально для студентов курса «Алгоритмы для разработчиков».

---

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