Расскажем о том, как устроен поиск похожих треков среди всех аудиозаписей ВКонтакте.

Зачем всё это надо?

У нас действительно много музыки. Много — это больше 400 миллионов треков, которые весят примерно 4 ПБ. Если загрузить всю музыку из ВКонтакте на 64 ГБ айфоны, и положить их друг на друга, получится башня выше Эйфелевой. Каждый день в эту стопку нужно добавлять еще 25 айфонов — или 150 тысяч новых аудиозаписей объёмом 1.5 ТБ.

Конечно, далеко не все эти файлы уникальны. У каждого аудио есть данные об исполнителе и названии (опционально — текст и жанр), которые пользователь заполняет при загрузке песни на сайт. Премодерации нет. В результате мы получаем одинаковые песни под разными названиями, ремиксы, концертные и студийные записи одних и тех же композиций, и, конечно, совсем неверно названные треки.

Если научиться достаточно точно находить одинаковые (или очень похожие) аудиозаписи, можно применять это с пользой, например:

• не дублировать в поиске один трек под разными названиями;
• предлагать прослушать любимую композицию в более высоком качестве;
• добавлять обложки и текст ко всем вариантам песни;
• усовершенствовать механизм рекомендаций;
• улучшить работу с жалобами владельцев контента.

Если вы последний год пользовались мобильными приложениями от ВКонтакте (пусть даже не официальными), то этот материал раскроет немного данных по тому, как у нас это время работают пуш уведомления. Пушилка реализована на языке Go, и рассылает до 9 миллиардов пушей в сутки на четыре целевых платформы: GCM, APNS, MPNS, WNS.

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

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

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

В Lua ООП нет. И оно, в общем-то и не нужно: удобной модульности и функций первого класса достаточно для реализации многих вещей. На этом можно было бы и закончить, но пост не про это. В данном случае я распишу работу с метатаблицами, где в качестве примера шаг за шагом будет реализовываться системка по работе с классами в несколько таком python-стиле. Для понимания нужен хотя бы основной базис языка: таблицы, upvalues.

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

Думаю, что все разработчики на PHP (включая меня) так или иначе проходили через период, когда код представляет из себя жуткую смесь html и php, напиханных в одном файле. И речь не о шаблонах, а вообще о всей логике в лапше/спагетти-коде.
И в качестве концепта я решил к первому апреля набросать реализацию чего-то подобного, но на lua под nginx. Прямо как на картинке.

Решил пополнить копилку статей на Хабре про такой замечательный ЯП, как lua, парой примеров его использования под капотом nginx. Разбил на два независимых поста, второй тут.

В этом посте nginx используется как «горячий кеш» неких постоянно пополняемых данных, запрашиваемых клиентами по интервалу с опциональным группированием (некий аналог BETWEEN и GROUP BY/AGGREGATE из SQL). Подгрузка данных в кеш осуществляется самим же lua+nginx из Redis. Исходные данные в Redis складываются ежесекундно, а клиенты хотят их от сих до сих (интервал в секундах, минутах, часах...) с агрегацией по N (1<=N<=3600) секунд, отсортированные по дате и в json формате.
С хорошим hitrate на имеющейся машине получается обеспечить 110-130к «хотелок» в секунду, правда с плохим — только 20-30к. Что, в общем-то, тоже приемлемо для нас на одной инстанции nginx.

Данный пост является продолжением применения lua в nginx.

Там обсуждалось кеширование в памяти, а тут lua будет использоваться для фильтрации входящих запросов в качестве этакого фаервола на nginx-балансере. Нечто подобное было у 2GIS. У нас свой велосипед :) В котором разделяем динамику и статику, стараемся учесть NAT и белый список. И, конечно же, всегда можно навернуть еще специфичной логики, что не выйдет при использовании готовых модулей.
Данная схема сейчас спокойно и ненапряжно (практически не сказывается на использовании cpu) обрабатывает порядка 1200 запросов/сек. На предельные величины не тестировалось. Пожалуй, к счастью :)

Чтобы хоть как-то разбавить тенденцию к 30строчникам решил написать достаточно завершенную и, в сравнении с 30lines, объемную реализацию классической игры Asteroids.

Я не буду меряться числом строк или символов кода, т.к. в нем есть и достаточно нормальное оформление и даже комментарии.
Мир игры отрисовывается на canvas, все объекты мира унифицированы, а детектор коллизий использует попиксельный тест. Есть простая озвучка, жизни, godmod на первые секунды после появления, очки, растущая вместе с очками сложность и, конечно, разваливающиеся на куски астероиды.
Попробовать можно тут. Очень советую Chrome или хотя бы FF.

Решил поддержать серию постов «Делаем XXX на JS в 30 строк». Взял для примера Pong в приближенному к классическому оформлении:

Вышло не совсем в 30 строк, а целых 38, т.к. логики вышло прилично, а совсем убивать читаемость или сжимать минимизаторами/обфускаторами не хотелось.

В демке:

• Управление по Up/Down;
• ИИ противника;
• Ускорение мяча с каждым отскоком;
• Обработка клавиатуры, не зависящая от перемещения мяча;
• Ожидание нажатия клавиш для запуска мяча;
• Поддержка практически любого размера поля и высоты «игроков»;
• Ведение статистики.

Совсем недавно и достаточно неожиданно для самого себя я оказался ответственным за разработку программки для Android. Но ни под Android, ни вообще на Java мне ранее писать не приходилось. Нужно было сделать web-приложение, вроде phonegap и прочих, которое почти полностью работает в компоненте браузера. И все это под версии 2.2 — 4.3 (SDK 8 — 18).

О некоторых выкрутасах Android и костылях под них с точки зрения человека, впервые это все увидевшего, я и хотел бы рассказать. Надеюсь, вышло без HelloWorld, «OMG! Java», и т.п.

Поворот экрана/смена ориентации
Network unreachable
Грузим локальные ресурсы
Мост между Java и JavaScript

По результатам опроса в первой статье, решено было сделать обзор реализации расширения. К этому моменту в угоду существующим IDE немного изменился синтаксис, который, пожалуй, был наиболее обсуждаемым моментом.
Это не еще-одна-статья-о-hello-world-расширении, т.к. желающим разобраться в основах легко найти массу материалов как на самом Хабре, так и в русскоязычном RTFG.
Статья о предпосылках, реализации и подводных камнях. В ней будет мало PHP, в основном C.

Решил поделиться своим видением и наработками по реализации python-style декораторов в PHP.
В качестве завлекалочки небольшой пример использования на изображении справа. Выводит (после реализации логики самих декораторов):

Log: calling b()
int(42)

Реализация выполнена в виде C расширения и не требует пересборки самого PHP. Но не заведется на хостингах, где нельзя загрузить свою so'шку.
На данный момент код находится в стадии беты (весь нужный функционал написан, но баги и утечки памяти наверняка есть :) ). Так что as is. Ну а если есть желание помочь в развитии, то буду рад принять коммиты на github.

Наверное всем, кто хоть раз интересовался Python, известно про GIL — его одновременно и сильное и слабое место.
Не мешая однопоточным скриптам работать, он ставит изрядные палки в колеса при многопоточной работе на CPU-bound задачах (когда потоки выполняются, а не висят попеременно в ожидании I/O и т.п.).
Подробности хорошо описаны в переводе двухгодичной давности. Побороть GIL в официальной сборке Python для настоящего распараллеливания потоков мы не можем, но можно пойти другим путем — запретить системе перебрасывать потоки Python между ядрами. В общем пост из серии, «если не нужно, но очень хочется» :)
Если вы знаете про processor/cpu affinity, пользовались ctypes и pywin32, то ничего нового не будет.

В поисках готового велосипеда для решения задачи мониторинга за изменениями в ФС с поддержкой linux+freebsd наткнулся на приятную python либу watchdog (github, packages.python.org). Которая помимо интересных мне ОС поддерживает также MacOS (есть своя специфика) и Windows.
Тем, кому данный вопрос интересен и кого не отпугнет индийское происхождение автора, прошу

В статье описывается:

• Примеры использования блокирующих сокетов
• Преимущества асинхронных сокетов и Linux epoll
• Примеры асинхронного использования сокетов через epoll
• Вопросы производительности
• Исходный код

В данном топике представлена на мой взгляд удобная и функциональная реализация многопоточного скачивания на cURL для PHP. Возможно кому-то она будет полезна, а мне принесёт инвайт ;)

Скачиванием через cURL не пользовался пусть даже из интереса только ленивый. Будь-то из консоли, либо реализуя код на каком-либо ЯП. Решения блокирующего скачивания одной ссылки валяются на каждом углу сети, к примеру на php.net. Однако, если рассматривать реализации на PHP, то такой подход подчас не подходит ввиду высоких временных затрат на вспомогательные операции ( dns lookup, request waiting и подобные ). Для скачивания большого числа страниц последовательный вариант не приемлем. Если устраивает — дальше можно не читать :)