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

В итоге было решено сделать собственный прокси-сервер, который реализовывал бы контроль скорости и предоставлял бы асинхронный доступ к API.

В предыдущий раз я переводил краткую теорию цвета и описание управления цветом для формата PNG. Если пересказывать своими словами, то цветовые модели делятся на физические (XYZ) и логические (RGB или YUV). В форматах хранения изображений и видео используются логические форматы (потому что они ограничены в диапазоне значений), иногда с добавлением метаданных, описывающих правила конвертации из логической модели в физическую. В то время, как логическая модель обычно хранит значения в диапазоне от 0 до 255 или от 0 до 1, физическая модель оперирует комбинацией трех чисел, каждое из которых представляет взвешенную сумму энергий излучения по всему спектру видимого цвета, взятую с разными весами.

Что касается дисплеев, для них производитель указывает характеристики, описывающие то, как цифровой сигнал из, например, RGB преобразуется в значения XYZ, излучаемые этими самыми дисплеями. Такими характеристиками является точка белого (т.е. какому физическому цвету соответствует RGB-сигнал с компонентами max/max/max), основные цвета (максимумы RGB при остальных минимумах), гамма или передаточная функция, а также охват (gamut), который описывает всё множество физических цветов, которые в принципе может отобразить дисплей.

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

Краткое содержание

Предлагается новая конструкция try, созданная специально для устранения if-выражений, обычно связанных с обработкой ошибок в Go. Это единственное изменение языка. Авторы поддерживают использование defer и стандартных библиотечных функций для обогащения или оборачивания ошибок. Это маленькое расширение подходит для большинства сценариев, практически не усложняя язык.

Конструкцию try просто объяснить, легко реализовать, этот функционал ортогонален другим языковым конструкциям и является полностью обратно-совместимым. Он также является расширяемым, если мы захотим этого в будущем.

Остальная часть этого документа организована следующим образом: после краткого введения, мы приводим определение встроенной функции и объясняем ее использование на практике. Раздел обсуждения рассматривает альтернативные предложения и текущий дизайн. В конце будут приведены выводы и план реализации с примерами и секцией вопросов и ответов.

От переводчика: я наткнулся на TheUpdateFramework при поиске библиотек, реализующих автоматическое обновление ПО на десктопе. С одной стороны, мне показалось интересным и обстоятельным представленное ниже описание аспектов безопасности систем обновления ПО; с другой — наверняка помимо академических исследований, хоть и под крылом LinuxFoundation, можно найти много годных решений. Можете предлагать варианты в комментариях.

Безопасность

Мы можем считать систему обновления ПО "безопасной", если:

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

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

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

Целью этой статьи является предоставление гайдлайнов и реализации для определенных непрерывных переходов между фрагментами ОС Android. Мы продемострируем, как реализовать переход из картинки в RecyclerView в картинку внутри ViewPager и обратно, используя "общие элементы" (shared elements) чтобы определить, как и какие элементы участвуют в переходе. Мы также обработаем сложный случай перехода обратно в сетку после листания на странице к элементу, который в сетке изначально был за пределами экрана.

Вот результат, которого мы хотим добиться (анимированная версия под катом).

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

От переводчика. Далее будет довольно много кода и гифок (по прикидкам, мегабайт на 20).

Наступила осень, и, несмотря на хорошую погоду, наши зрители потянулись за новым видеоконтентом. Бекенд-серверы, обслуживающие эмбеды с видео, стали упираться в CPU. С криками "а-а-а" прибежали системные администраторы и начали отбирать у отдела разработки ноутбуки и десктопы, грозясь поставить их в датацентры "на усиление". Разработке это конечно всё не понравилось и все поувольнялись с этой хренью решили что-нибудь сделать.

Операционная система Android предоставляет мощный фундамент для разработки приложений, которые отлично работают на множестве разнообразных устройств и форм-факторов. Теперь, как говорится, мы услышали жалобы разработчиков: трудно создавать "безглючные" приложения в условиях сложных циклов жизни объектов и отсутствия рекомендованной архитектуры приложения.

Нам, создателям Android, надо сделать простым и веселым написание устойчивых приложений, чтобы перевести усилия разработчиков в те области, в которых можно создавать инновации. Сегодня мы аннонсируем путеводитель по архитектуре Android-приложений и превью библиотек Architecture Components. Вместо того чтобы изобретать колесо, мы признаем работу, сделанную авторами популярных сторонних Android-библиотек (прим. пер.: WAT?).

Прошло много времени с моего последнего поста о Channels, и вместе с этим много чего случилось — API разработано и стабилизировано, добавился функционал вроде "контроля за переполнением" (backpressure), ситуация с бекендами выглядит гораздо лучше, особенно после того, как слой взаимодействия локальных и удаленных машин стал немного взрослее.

С другой стороны, однако, появилось недопонимание и озабоченность относительно направления, в котором развивается Channels; направления, которое этот проект задает для Django и Python. При разработке Channels пришлось касаться и даже бороться с моими собственными переживаниями об это направлении, выбирать правильный набор компромиссов — иногда даже из двух одинаково правильных вариантов.

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

Что обычно делает python-программист, когда его отправляют воевать с ошибкой?
Сначала он лезет в sentry. Здесь можно найти время, сервер, подробности сообщения об ошибке, traceback и, может быть, какой-нибудь полезный контекст. Затем, если этих данных недостаточно, программист идет c бутылкой к админам. Те залезают на сервер, ищут это сообщение в файловых логах, и, может быть, находят его и некоторые предшествующие ошибке записи, которые в редких случаях могут помочь в расследовании.
А что делать, если в логах только loglevel=ERROR, а ошибка настолько крута, что ее локализация требует сопоставления логики поведения нескольких различных демонов, которые запущены на десятке серверов?

Решение — централизованное хранилище логов. В самом простом случае — syslog (за 5 лет, что был развернут в rutube, не использовался ни разу), для более сложных целей — ELK. Скажу честно, "ластик" — крут, и позволяет быстро крутить разнообразную аналитику, но вы интерфейс Kibana видели? Этой штуке так же далеко до консольных less/grep, как винде до линукса. Поэтому мы решили сделать свой велосипед, без Java и Node.js, зато с sphinxsearch и Python.

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

Начать стоит, наверно, с постановки бизнес-задачи:

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

А еще нефункциональные требования:

• Django-проект с дофига просмотрами и постоянными обновлениями описаний видео
• Инкапсуляция работы с поисковым движком в библиотеке и совместимость с остальными библиотеками на сайте (в первую очередь, Django REST Framework)

Про то, как в Rutube используется sphinxsearch и будет данный рассказ.

Предисловие

• карточки видео, с тамнейлами и описаниями;
• карточки авторов или тегов, с большой кнопкой «подписаться».