Привет, читатель!

Меня зовут Рушан, и я автор Telegram‑канала Нейрон. Не забудьте поделиться с коллегами или просто с теми, кому интересны такие статьи.

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

Меньше слов, больше данных.

Подборка датасетов для машинного обучения:

• Данные смертей и сражений из игры престолов — этот набор данных объединяет три источника данных, каждый из которых основан на информации из серии книг.
• Глобальная база данных терроризма — Более 180 000 террористических атак по всему миру, 1970-2017.
• Биткойн, исторические данные — данные биткойнов с интервалом в 1 минуту с избранных бирж, январь 2012 г. — март 2019 г.

UPD: готова вторая часть статьи.

Привет, Хабр! Меня зовут Александр Измайлов. В Badoo я возглавляю команду релиз-инженеров. Я знаю, что во многих компаниях можно присылать изменения кода специально обученному человеку, он их смотрит и добавляет куда следует (например, именно так происходит с кодом Git). А я хочу рассказать о том, как мы автоматизировали этот процесс у нас.

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


Изображение: источник

Феерическая расстановка точек над i в вопросе удаления файлов из переполненной директории.

Прочитал статью Необычное переполнение жесткого диска или как удалить миллионы файлов из одной папки и очень удивился. Неужели в стандартном инструментарии Linux нет простых средств для работы с переполненными директориями и необходимо прибегать к столь низкоуровневым способам, как вызов getdents() напрямую.

Для тех, кто не в курсе проблемы, краткое описание: если вы случайно создали в одной директории огромное количество файлов без иерархии — т.е. от 5 млн файлов, лежащих в одной единственной плоской директории, то быстро удалить их не получится. Кроме того, не все утилиты в linux могут это сделать в принципе — либо будут сильно нагружать процессор/HDD, либо займут очень много памяти.

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

Heroes of Might & Magic III через полтора года исполняется 20 лет. Игра, покорившая не одно поколение своим волшебством, не потеряла своей привлекательности и сегодня — многие называют её «новыми шахматами», утверждая, что превзойти «магическую» формулу третьих «Героев» с тех пор так никому и не удалось.

Сегодня вашему вниманию предлагается рассказ о том, как появились на свет HoMM III и её наследники. Учитывая, что знания, проливающие свет на события тех дней, всегда могут кануть в Лету, и их не спасет даже The Internet Archive (что уже произошло с некоторыми интервью) — а сама серия, по слухам, волей Ubisoft отправлена в глубокую «заморозку» из-за неважных финансовых показателей последней части франшизы — лучше сделать это сегодня, чем завтра.

Мой рассказ является реконструкцией событий, происходивших два десятилетия назад, и в его основе лежат десятки источников — поэтому он может содержать некоторые неточности; к счастью, история пока сохранила для нас достаточно сведений про то, как New World Computing и 3DO смогли произвести на свет игру, удавшуюся настолько, что мы годы спустя продолжаем в неё играть. Узнаете вы и про то, что произошло после выпуска третьих «Героев».

Когда всё закончится, ты забудешь о том, как тяжело тебе было, и захочешь повторить это снова.
Джон Ван Канегем, «Напутствие тем, кто переживает кранч»

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

Недавно мы рассказывали про генератор стихов. Одной из особенностей языковой модели, лежащей в его основе, было использование морфологической разметки для получения лучшей согласованности между словами. Однако же у использованной морфоразметки был один фатальный недостаток: она была получена с помощью “закрытой” модели, недоступной для общего использования. Если точнее, выборка, на которой мы обучались, была размечена моделью, созданной для Диалога-2017 и основанной на закрытых технологиях и словарях ABBYY.

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

Вместо морфологического движка ABBYY я использовал широко известный pymorphy2. Что в итоге получилось? Спойлер — получилось неплохо.

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

Введение

Вы могли слышать термин кадры в секунду (FPS), и что 60 FPS — действительно хороший ориентир для любой анимации. Но большинство консольных игр идут на 30 FPS, а кинофильмы обычно записывают на 24 FPS, так зачем же нам стремиться к 60 FPS?

Кадры… в секунду?

Ранние времена кинопроизводства

Съёмки голливудского фильма 1950 года «Юлий Цезарь» с Чарлтоном Хестоном

Когда первые кинематографисты начали снимать кино, многие открытия делались не научным методом, а путём проб и ошибок. Первые камеры и проекторы управлялись вручную, а плёнка была очень дорогой — настолько дорогой, что при съёмке старались использовать наименьшую возможную частоту кадров, лишь бы сэкономить плёнку. Этот порог обычно находился между 16 и 24 FPS.

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

Кадр из Top Gear: USA (серия 2)

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

Практически с самого начала в качестве реализации ассоциативных массивов мы использовали Judy. У неё есть C-интерфейс и множество преимуществ. Мы даже используем обёртку для PHP, так как в версиях PHP до 7.0 Judy сильно выигрывает по количеству потребляемой памяти по сравнению со встроенными мапами.

Однако время идёт, и с момента последнего релиза Judy прошло немало лет – самое время посмотреть на альтернативы.

Меня зовут Марко, я – системный программист Badoo в команде «Платформа». Мы с коллегами провели небольшое исследование в поисках альтернатив Judy, сделали выводы и решили поделиться ими с вами.

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

Русскоязычные видео

Статический анализ кода

Долго выбирал между «Алгоритмами», «Читальным залом» и «Я пиарюсь», в итоге остановился на Data Mining.

Эта история началась в конце октября, когда я очередной раз пытался выбрать, что бы мне почитать. Лично я с собой в отпуск/в дорогу беру что-нибудь из фантастики (как, думаю, и большинство присутствующих), причем категорически не люблю всякий модный новодел.

И вот, терзаясь муками выбора, я забил в поиск «IMDB for books» и… не нашел ничего пристойного. Весь интернет забит рекомендательными сервисами для книг, и все они выдают полную чушь. Вот, например, топ имхонета для раздела «Самая лучшая фантастика и фэнтези»:

1. Мастер и Маргарита. Михаил Булгаков, 1940 год
2. Цветы для Элджернона (рассказ). Дэниел Киз, 1959 год
3. Цветы для Элджернона. Дэниел Киз, 1966 год
4. Битва Королей. Джордж Мартин, 1998 год
5. Рыцарь Ордена: Клинки у трона. Сергей Садов, 2000 год
6. Голубятня в Орехове. Владислав Крапивин, 1983 год

Эээ… Это совсем не то, что я ожидал увидеть на первых местах в рейтинге фантастики. «Мы пойдём другим путём», — подумал я. Отказавшись от идеи найти нормальный читательский рейтинг, я просто пошёл в Вики, нашёл список лауреатов премий Хьюго и Небьюла и выбрал пару-тройку книг — как, собственно, я всегда раньше и делал.

«А не замутить ли мне свой рейтинг книг, взяв за основу престижные премии?» — внезапно подумал я. И замутил. Знакомьтесь: top-books.info

Может ли самый первый релиз продукта быть достаточно хорошо оттестированным, или кучу шишек неизбежно набьёшь уже в продакшене? Конференция по тестированию «Гейзенбаг», которую мы недавно провели в Москве, состоялась в самый первый раз, так что можно было на её наглядном примере и посмотреть. Как она прошла? Возникли ли проблемы? И как вообще должна выглядеть конференция по тестированию, если внутри него существуют подвиды с совершенно разной спецификой, а дело с ним имеют специалисты разного профиля?

Нам очень нравится формат AMA (ask me anything) на Reddit, когда кто-нибудь (в нашем случае – команда разработчиков) приходит в сабреддит AMA и говорит, что готов отвечать на заданные вопросы. Из самых запоминающихся сессий Ask Me Anything, например, команда инженеров Space X, или инженеры из Google, и даже действующий президент США Барак Обама четыре года назад отвечал на вопросы на Реддите. Недавно наша Android-команда проводила AMA и в онлайн-режиме отвечала на вопросы разработчиков.

Но в России нет своего Реддита. Зато есть свой Хабр. Поэтому мы решили прийти с форматом «задай нам вопрос» сюда. И не с пустыми руками, как велят правила AMA. Чтобы вам было проще понять тему, мы выбрали одну из наших команд – «Платформу» – и попросили ребят рассказать, чем они занимаются, на чём программируют и чего добились за время существования команды. И подвели небольшие итоги уходящего 2016 года. Поехали!

Оглавление

1. Чем занимается «Платформа»
2. Сервисы: Pinba, SoftMocks и другие
3. Системное программирование. Как мы начали использовать Go и к чему это привело
4. Фотографии
5. Скриптовое облако
6. LSD: Live Streaming Daemon
7. Cassandra Time Series: что это и как работает
8. Badoo AMA: задай вопрос разработчикам «Платформы»

Пруф, что это действительно мы.

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

С самого начала истории жанра мы видим, как разработчики старались сделать процесс гонки приближенным к реальной жизни. Отличные примеры — реальная трасса Фудзи Спидвей в игре Pole Position, управляемые заносы в TX-1, возможность выбрать поворот в Out Run, изменение погодных условий в Rad Racer.

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

В приложении 2ГИС теперь есть навигатор. Мы научились «ехать» по треку, озвучивать манёвры, автоматически перестраивать маршрут, рассчитывать время в пути, доводить пользователя до входа в здание или организацию, учитывая заборы и шлагбаумы, — и всё это в честном офлайне. Пробки (вот разве что для них нужен интернет), разведённые мосты и перекрытые улицы учитываем давно. Пока в нашем навигаторе — необходимый минимум. Чуть позже научим его предупреждать о слишком высокой скорости, лежачих полицейских и камерах ГИБДД, настроим ночной режим, сделаем маршруты по платным и грунтовым дорогам опциональными. Чтобы воспользоваться им, нужно обновить 2ГИС в своем смартфоне или скачать в AppStore или Windows Store. Для Android обновление выходит постепенно, начиная с 22 августа (будет доступно на всю аудиторию к сентябрю).

А сегодня расскажем, как навигатор 2ГИС предугадывает положение автомобиля и плавно перемещает стрелочку по маршруту. Ведь именно качество ведения пользователя по маршруту определяет эргономику интерфейса любого современного навигатора, простоту ориентирования на местности и своевременность совершения манёвров.

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

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

Все остальные правила для меня выглядят совершенно, ну просто абсолютно произвольно. Почему у нас есть 12 нот, но для их обозначения применяются только 7 букв? Откуда взялись знаки при ключе? Почему ни одну статью по музыке в Википедии просто невозможно понять, не прочитав сперва все остальные?

В понедельник, 9 ноября 1998 года, около четырёх часов вечера в обычном офисном комплексе где-то под Сиэттлом человек в синей рубашке берёт в руки монтировку. Он держит её обеими руками и встаёт в позу для атаки. Затем следует смачный удар по головокрабу. Набитая игровыми деньгами из «Монополии» и заводными игрушками с персонажами «Южного парка» пиньята падает на пол. Под ликование толпы краба добивает ещё один человек. Это Гейб Ньюэлл и Майк Харрингтон, основатели компании Valve Software, празднуют выход своей первой игры Half-Life на тиражирование.

В четверг, 14 октября 2004 года, в 12:15 дня после долгих уговоров толпы уничтожить цель пораньше церемония повторяется. На этот раз Гейб в красной поло обороняется от нападения сканера из Half-Life 2. Контрольные удары для болтающихся на верёвочке кусочков пиньяты выполняет сценарист игры Марк Лэйдлоу. На «золото» вышла вторая игра серии.

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

Не стала исключением Half-Life 2: игра была в разработке почти 6 лет. По меркам игровой индустрии — это эпоха. За шесть лет игровые консоли успевают разок обновиться. Как можно было так всё затянуть и опять сорвать срок релиза?

Для того чтобы мы могли считать статистику, наш сайт в своей работе генерирует огромное количество событий. Например, при отправке сообщения другому пользователю, при заходе пользователя на сайт, при смене местоположения и т.д. События представляют из себя строку в формате JSON или GPB (Google Protocol Buffers) и содержат время отправки, идентификатор пользователя, тип события, а также поля, относящиеся непосредственно к самому событию (например, координаты пользователя).

Каждую секунду генерируются сотни тысяч событий, и нам нужны инструменты, чтобы их собирать и анализировать эффективно и с минимальной задержкой. Мы рассматривали несколько существующих решений для этой задачи и до недавнего времени использовали демон под названием Scribe от Facebook. Он в целом нас устраивал и позволял делать все, что нам нужно. Однако в какой-то момент Facebook забросил свою разработку, и при некоторых условиях Scribe начал у нас падать (например, при перегрузке upstream-серверов). Самостоятельно устранить причину падений демона у нас не получилось, поэтому мы начали искать альтернативу.

Немного предыстории

Мобильное приложение Badoo существует для основных «нативных» платформ (Android, iOS и Windows Phone) и для мобильного веба. Несмотря на то, что в разработке мы не используем никаких кроссплатформенных фрэймворков, подавляющая часть бизнес-логики в приложениях схожа, и чтобы не дублировать функциональные тесты для всех платформ, мы пишем кроссплатформенные тесты с помощью Cucumber, Calabash и Appium. Это позволяет нам выносить в общую часть и переиспользовать в тестах для всех платформ код, отвечающий за проверку этой самой бизнес-логики. Различной же остается лишь реализация взаимодействия с приложением (более подробно мы рассказывали об этом здесь).

Когда кроссплатформенная автоматизация только начиналась (на iOS и Android), было принято решение использовать в качестве серверов Mac Mini. Это позволило сделать каждую из 8 билд-машин универсальной: на ней можно было собирать и запускать функциональные и юнит-тесты как для приложений на iOS, так и на Android. Такое решение устраивало нас практически всем до тех пор, пока количество функциональных тестов не перевалило за пять сотен для каждой платформы, а прогоны не стали требовать все больше времени. Для того чтобы удержать время прогона в разумных границах, мы постоянно работаем над оптимизацией тестов, а также добавляем новые Android-устройства (для iOS мы добавляем симуляторы по-другому). Со временем у нас появились Mac Mini с более чем 8 смартфонами. Важно отметить, что мы подключаем устройства одной модели к одному серверу, чтобы прогоны тестов были консистентны на одном агенте.

Мы проводим много разных конференций для разработчиков: Java, .NET, JavaScript, iOS/Android, – и в каждой из них акцент всегда ставится на технический хардкор и отсутствие воды в докладах. Кроме того, мы уже больше года опрашиваем наших участников, каких конференций не хватает в России. И вот результат: 10 декабря в Москве состоится первая в своем роде глубоко техническая конференция по тестированию Гейзенбаг 2016 Moscow.

Обратите внимание: Гейзенбаг — это именно конференция «по тестированию», а не «для тестировщиков». Мы приглашаем на конференцию:

• тестировщиков,
• программистов, разрабатывающих тесты для своего кода (или думающих об этом),
• специалистов по автоматическому тестированию
• специалистов по нагрузочному тестированию
• тимлидов, которые думают о том, чтобы повысить эффективность тестирования в своих проектах.

Итак, какую техно-жесть мы готовим для вас? Смотрите под катом.

Время на месте не стоит, и у горячо любимого всеми Docker от версии к версии появляется новый функционал. Случается так, что когда читаешь Changelog для новой версии, видишь там то, что может пригодиться и сделать какие-то вещи лучше, чем есть на данный момент.

Так дело обстояло и в моем случае. Хочу заметить, что многие задачи, которые приходится делать, я делаю по принципу keep it simple. То есть почти всегда, если для решения задачи можно использовать простые инструменты и шаги, я выберу этот путь. Я понимаю, что простой или сложный шаг или инструмент — оценка субъективная, но т.к. работаем мы в команде, то вот такие критерии могут подходить при выборе инструментов:

• используется ли инструмент в инфраструктуре?
• если требуется что-то новое, то нельзя ли использовать то, что уже есть?
• насколько сильно обслуживание (обновление, перезапуск) сервиса будет отличаться от остальных сервисов?
• <...>

В этой статье речь пойдет о сетевом аспекте Docker. Расскажу обо всем по порядку, но хочу заметить, что на этот раз я не буду говорить «мы используем сеть хоста, всячески избегая применения NAT».