Привет Хабр, сегодня я расскажу о том, как я проходил тестовое задание на летнюю стажировку в Яндекс. Эта публикация будет полезна начинающим разработчикам, любителям олимпиадного программирования, тем кто неравнодушен к С++ и Java, или просто хочет прочесть интересную статью после трудного рабочего дня.

Чего ожидать от этой статьи?

• Introduction, о том что такое стажировки в Яндкесе, как и когда на них подать
• Мотивация к написанию данной статьи
• Примеры задач, моё решение и краткий разбор (Можно смело пропустить первые два пункта, и начинать именно отсюда)

Introduction

Для тех кто мало знаком с системой отбора на стажировку в Яндексе расскажу вкратце. На сайте яндекса, за несколько месяцев до лета объявляется оплачиваемая вакансия для начинающих разработчиков, в том отделе, в котором вы бы хотели работать (i.e. Яндекс.Диск, Яндекс.Алиса). По ссылке, нужно заполнить форму, о том где Вы учитесь, чем занимаетесь, какой был опыт работы, о чем писали дипломную работы итп. После заполнения формы Вам на почту присылают тестовое задание, на выполнение которого у Вас есть 6 часов, в любой день в течении недели с момента, когда Вы получили это письмо.

Привет, Хабр! В этой статье я расскажу про npyscreen — библиотеке для создания текстовых интерфейсов для терминальных и консольных приложений.

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

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

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

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

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Введение

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

Собственно вот такие:

(источник).

Так, чтобы не углубляться в теорию оптимизации за примерами достаточно вспомнить формулу численного интегрирования Рунге-Кутты четвёртого порядка:

$$

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

Как можно заметить основную массу математических операций как для векторов, так и для матриц составляют:

• сложение и вычитание — более быстрые;
• умножение и деление — более медленные.

О сложности вычислений хорошо написано в соответствующем курсе МФТИ.

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

Соответственно есть смысл заняться снижением количества операций привносящих наибольшую сложность — умножения (математика) и операции управления памятью (алгоритмика).

TL;DR

1. В глубоких нейронных сетях основным препятствием для обучения являются седловые точки, а не локальные минимумы, как считалось ранее.
2. Большинство локальных минимумов целевой функции сконцентрированы в сравнительно небольшом подпространстве весов. Соответствующие этим минимумам сети дают примерно одинаковый loss на тестовом датасете.
3. Сложность ландшафта увеличивается по приближении к глобальным минимумам. Почти во всём объёме пространства весов подавляющая часть седловых точек имеет большое количество направлений, по которым из них можно сбежать. Чем ближе к центру кластера минимумов, тем меньше «направлений побега» у встреченных на пути седловых точек.
4. Всё ещё неясно, как найти в подпространстве минимумов глобальный экстремум (любой из них). Похоже, что это очень сложно; и не факт, что типичный глобальный минимум намного лучше типичного локального, как в плане loss'a, так и в плане обобщающей способности.
5. В сгустках минимумов существуют особые кривые, соединяющие локальные минимумы. Функция потерь на этих кривых принимает лишь чуть большие значения, чем в самих экстремумах.
6. Некоторые исследователи считают, что широкие минимумы (с большим радиусом «ямы» вокруг) лучше узких. Но есть и немало учёных, которые полагают, что связь ширины минимума с обобщающей способностью сети очень слаба.
7. Skip connections делают ландшафт более дружелюбным для градиентного спуска. Похоже, что вообще нет причин не использовать residual learning.
8. Чем шире слои в сети и чем их меньше (до определённого предела), тем глаже ландшафт целевой функции. Увы, чем более избыточна параметризация сети, тем больше нейросеть подвержена переобучению. Если использовать сверхширокие слои, то несложно найти глобальный минимум на тренировочном наборе данных, но обобщать такая сеть не будет.

Всё, листайте дальше. Я даже КДПВ ставить не буду.

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

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

Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616.

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

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

Изучая кодировки, я понял, что недостаточно хорошо понимаю системы счислений. Тем не менее, часто использовал 2-, 8-, 10-, 16-ю системы, переводил одну в другую, но делалось все на “автомате”. Прочитав множество публикаций, я был удивлен отсутствием единой, написанной простым языком, статьи по столь базовому материалу. Именно поэтому решил написать свою, в которой постарался доступно и по порядку изложить основы систем счисления.

Введение

Система счисления — это способ записи (представления) чисел.

Что под этим подразумевается? Например, вы видите перед собой несколько деревьев. Ваша задача — их посчитать. Для этого можно — загибать пальцы, делать зарубки на камне (одно дерево — один палец\зарубка) или сопоставить 10 деревьям какой-нибудь предмет, например, камень, а единичному экземпляру — палочку и выкладывать их на землю по мере подсчета. В первом случае число представляется, как строка из загнутых пальцев или зарубок, во втором — композиция камней и палочек, где слева — камни, а справа — палочки

Системы счисления подразделяются на позиционные и непозиционные, а позиционные, в свою очередь, — на однородные и смешанные.

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

Деревья. Кратко напомним

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

Предисловие

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

Что это

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

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

Практически любой начинающий программист на Python патологически старается написать свой чат. А если еще и с GUI, то эта прорамма является просто пределом мечтаний.

Data Science – область очень перспективная. За прошлый год мы в ЕРАМ получили 210 резюме от людей, которые хотят заниматься Data Science. Из них на техническое интервью мы пригласили 43 человека, а предложили работу семи. Если спрос большой, почему так?

Мы поговорили с техническими интервьюерами и выяснили: проблема многих кандидатов в том, что они плохо представляют, чем занимаются аналитики данных. Поэтому их знания и навыки не всегда релевантны для работы. Кто-то считает, что опыта работы с Big Data достаточно, чтобы работать в Data Science, кто-то уверен, что хватит просмотра нескольких курсов по машинному обучению, некоторые думают, что хорошо разбираться в алгоритмах необязательно.

Дмитрий Никитко и Михаил Камалов – аналитики данных и технические интервьюеры из ЕРАМ – рассказали, чего ждут на собеседованиях от кандидатов, какие вопросы задают, что ценится в резюме и как подготовиться к собеседованию.

Перевод Background removal with deep learning.

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

Несколько месяцев назад, после прохождения отличного курса Fast.AI, звезды совпали, и у нас появилась такая возможность. Современные достижения в технологиях глубокого обучения позволили осуществить многое из того, что раньше казалось невозможным, появились новые инструменты, которые сделали процесс внедрения более доступным, чем когда-либо.

Мы поставили перед собой следующие цели:

1. Улучшить наши навыки работы с глубоким обучением.
2. Совершенствовать наши навыки внедрения продуктов, основанных на ИИ.
3. Создать полезный продукт с перспективами на рынке.
4. Весело провести время (и помочь весело провести время нашим пользователям).
5. Обменяться опытом.

Автор: Игорь Пантелеев, Software Developer, DataArt

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

Регулярные выражения в Python от простого к сложному

Решил я давеча моим школьникам дать задачек на регулярные выражения для изучения. А к задачкам нужна какая-нибудь теория. И стал я искать хорошие тексты на русском. Пяток сносных нашёл, но всё не то. Что-то смято, что-то упущено. У этих текстов был не только фатальный недостаток. Мало картинок, мало примеров. И почти нет разумных задач. Ну неужели поиск IP-адреса — это самая частая задача для регулярных выражений? Вот и я думаю, что нет.
Про разницу (?:...) / (...) фиг найдёшь, а без этого знания в некоторых случаях можно только страдать.

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

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

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

Чтобы улучшить качество распознавания своих сетей, исследователи старались добавлять в сети больше слоёв, однако со временем пришло понимание, что иногда ограничения производительности попросту не позволяют обучать и использовать настолько глубокие сети. Это стало мотивацией для использования depthwise separable convolutions и создания архитектуры Xception.

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

Вы правильно поняли из названия, что это не совсем обычное описание алгоритма JPEG (формат файла я подробно описывал в статье «Декодирование JPEG для чайников»). В первую очередь, выбранный способ подачи материала предполагает, что мы ничего не знаем не только о JPEG, но и о преобразовании Фурье, и кодировании Хаффмана. И вообще, мало что помним из лекций. Просто взяли картинку и стали думать как же ее можно сжать. Поэтому я попытался доступно выразить только суть, но при которой у читателя будет выработано достаточно глубокое и, главное, интуитивное понимание алгоритма. Формулы и математические выкладки — по самому минимуму, только те, которые важны для понимания происходящего.

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

Если есть желание, то предлагаю пройти те же этапы самостоятельно параллельно со статьей. Проверить, насколько приведенные рассуждения подходят для разных изображений, попытаться внести свои модификации в алгоритм. Это очень интересно. В качестве инструмента могу порекомендовать замечательную связку Python + NumPy + Matplotlib + PIL(Pillow). Почти вся моя работа (в т. ч. графики и анимация), была произведена с помощью них.

Внимание, трафик! Много иллюстраций, графиков и анимаций (~ 10Мб). По иронии судьбы, в статье про JPEG всего 2 изображения с этим форматом из полусотни.

Хочу поделиться простым рецептом, как можно эффективно выполнять большое число http-запросов и других задач ввода-вывода из обычного Питона. Самое правильное, что можно было бы сделать — использовать асинхронные фреймворки вроде Торнадо или gevent. Но иногда этот вариант не подходит, потому что встроить event loop в уже существующий проект проблематично.

В моем случае уже существовало Django-приложение, из которого примерно раз в месяц нужно было выгрузить немного очень мелких файлов на AWS s3. Шло время, количество файлов стало приближаться к 50 тысячам, и выгружать их по очереди стало утомительным. Как известно, s3 не поддерживает множественное обновление за один PUT-запрос, а установленная опытным путем максимальная скорость запросов с сервера ec2 в том же датацентре не превышает 17 в секунду (что очень не мало, кстати). Таким образом, время обновления для 50 тысяч файлов стало приближаться к одному часу.

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

Получается, всего-то нужен пул потоков, который будет выполнять запросы. К счастью, такой пул уже написан. Начиная с версии 3.2 для унификации всей асинхронной работы в Питоне появилась библиотека concurrent.futures. Для второй версии Питона есть бекпорт под именем futures. Код до безобразия прост:

from concurrent.futures import ThreadPoolExecutor

with ThreadPoolExecutor(concurrency) as executor:
    for _ in executor.map(upload, queryset):
        pass

Здесь concurrency — число рабочих потоков, upload — функция, выполняющую саму задачу, queryset — итератор объектов, которые по одному будут передаваться в задачу. Уже этот код при concurrency в 150 смог пропихнуть на сервера Амазона ≈450 запросов в секунду.