Python *

24 июня 2015 разработчики Telegram открыли платформу для создания ботов. Новость кого-то обошла стороной Хабр, однако многие уже начали разрабатывать викторины. При этом мало где указаны хоть какие-то примеры работающих ботов.

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




Как известно, ренедеринг видео и трёхмерных изображений занимает много времени и требует много ресурсов компьютера. Ещё свежи воспоминания, как будучи студентом я ставил на ночь жужжащий компьютер с запущенной программой сборки фильма, а на утро оказывалось, что либо не хватило места на жёстком диске, либо что-то забыл добавить в ролик и всё приходилось начинать сначала. Сейчас настоящие профессионалы делают эту операцию удалённо. Например, режиссёр Джеймс Камерон во время съёмок фильма «Аватар» специально для себя сделал заказ на создания целого дата-центра, в котором запускались рендеринги сцен. Я пока ещё не настолько крут, чтобы строить свой отдельный дата-центр, но идея того, что эта операция могла бы быть запущена отдельно на другом сервере не давала мне покоя долгое время.

Вторая проблема – это монтаж самого видео. Несмотря на то, что современные компьютеры становятся мощнее, развитие видеокамер тоже не стоит на месте и получившиеся видео файлы становятся всё тяжелее и тяжелее. И, как следствие, их становится проблематично обрабатывать. Когда монтируешь продолжительный фильм, то предпросмотр трека с наложенными фильтрами и переходами начинает подгружать процессор и изображение начинает лагать, делая творческий процесс монтажа утомительным. Из того, что я пробовал, самый продуктивный был iMovie, что предустановлен на всех Маках. Даже фильм продолжительностью в 45 минут можно было редактировать без особых проблем на относительно маломощном макбуке. Можно было применить любой фильтр и увидеть результат в окне предпросмотра без каких-либо лагов. Так что владельцам маков тут повезло. Один минус у iMovie: во время работы он начинает потреблять непомерное количество дискового пространства. Видимо, это связано с агрессивным кэшированием для редактирования и предпросмотра.

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

Вступление: Позапрошлым летом я открыл для себя великолепную книгу SICP — чтение только первого раздела книги открыло для меня новый мир функционального программирования. Анонимные функции, функции, что возвращают функции, функции высших порядков. Во втором разделе книги авторы показали, что возможно с помощью одних только функций создавать различные структуры данных, такие как пара, список, или даже деревья! Сегодня мне бы хотелось реализовать кое-какие идеи из этой книги на языке программирования Python. Конечно же, исключительно с помощью функций.

Привет, Хабр! Как упоминалось в прошлой статье, немаловажной частью нашей работы является сегментация пользователей. Как же мы это делаем? Наша система видит пользователей как уникальные идентификаторы cookies, которые им присваиваем мы или наши поставщики данных. Выглядит этот id, например, так:

42bcfae8-2ecc-438f-9e0b-841575de7479

Эти номера выступают ключами в различных таблицах, но первоначальным value является, в первую очередь, URL страниц, на которых данная кука была загружена, поисковые запросы, а также иногда некоторая дополнительная информация, которую даёт поставщик – IP-адрес, timestamp, информация о клиенте и прочее. Эти данные довольно неоднородные, поэтому наибольшую ценность для сегментации представляет именно URL. Создавая новый сегмент, аналитик указывает некоторый список адресов, и если какая-то кука засветится на одной из этих страничек, то она попадает в соответствующий сегмент. Получается, что чуть ли не 90% рабочего времени таких аналитиков уходит на то, чтобы подобрать подходящий набор урлов – в результате кропотливой работы с поисковиками, Yandex.Wordstat и другими инструментами.

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

От переводчика: в двух словах, в декабре 2015 выйдет релиз Python 2.7.11, ускоряющий работу интерпретатора CPython до 20%. Ниже перевод статьи с LWN.net, рассказывающей о сути и процессе произошедших изменений в коде. Имена, в произношении которых я не уверен, даны в оригинальном написании. Об ошибках и неточностях перевода просьба, как обычно, сообщать в личные сообщения.

Несмотря на то, что разработка Python 2 (а конкретно ветки Python 2.7.x) находится сейчас в состоянии «никаких новых фич», которое в обычной ситуации заранее ставит крест на любых крупных изменениях, команда разработки приняла решение рассмотреть и принять backport-патч из Python 3, привносящий заметное улучшение производительности интерпретатора.

Давно хотел прикрутить к своей домашней Raspberry Pi удобный интерфейс «общения», который бы удовлетворял главному требованию — простота и лёгкость, с доступом из любой точки мира и с помощью любого оборудования (но в первую очередь — со смартфона).

В связи с отсутствием дома выделенного IP и наличием сурового и неподкупного NAT варианты с SSH клиентами и web-интерфейсами отпали сразу. Для небольших потребностей решение тоже должно быть простое, быстрое и, в качестве бонуса, надежное. Так что идея использования протокола одного из распространенных мессенджеров показалась мне весьма привлекательной. Под прицел попали Jabber, Telegram и WhatsApp.

Против Jabber сыграло нежелание устанавливать лишний клиент. Ну а так как Telegram — это, IMHO, тот же WhatsApp, только лучше и удобнее (и даже чуточку безопаснее), то именно на нём я и решил остановить свой выбор. К тому же появившаяся недавно в Telegram возможность создавать своих рабов ботов и взаимодействовать с ними с помощью очень простого API позволяет избавиться от необходимости регистрировать новый аккаунт, а так же дает некоторые очень полезные и удобные возможности.

На самом деле всё действительно настолько просто, что опытным человекам хватит и 30 минут, чтобы разобраться, поднять и настроить своего бота. Остальным же: Добро Пожаловать!

Хотите заглянуть вовнутрь и узнать, как устроен AllMyChanges.com? Сегодня я немного расскажу вам, как работает наш робот и почему ему удается так хорошо находить информацию о релизах.

На самом деле, весь наш робот, это просто набор функций.
Поиск и обработка ченьджлогов состоит из нескольких этапов:

1. надо понять, каким образом получать данные по урлу;
2. использовать выбранный метод, чтобы скачать данные на диск;
3. пройтись по скачанным файлам и извлечь из них куски, которые имеют номер версии и описание;
4. понять, какие куски реально являются частью ченьджлога, а какие – просто мусор;
5. сложить найденное добро в базу.

Части 1,2 и 5 вполне себе механические и не требуют от робота особого интеллекта.

Получение данных

В предыдущей статье я упоминал о том, что AllMyChanges поддерживает несколько различных источников данных. Во-первых, он умеет выкачивать из из Git и Mercurial. Во-вторых — умеет скачивать HTML страницы, как по одной, так и рекурсивно обходя весь сайт. Ну и в-третьих, наш робот может скачивать некоторую информацию из App Store и Google Play.

TL;DR

Чтобы просто установить и изолировать зависимости проекта, virtualenv часто оказывается слишком тяжелым решением. Предлагаем простую альтернативу:

1. добавить ./.pip в переменную окружения PYTHONPATH,
2. установить пакеты локально с помощью pip install -t .pip,
3. запускать python из папки проекта.

Введение

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

Код предназначен для Python 3, хотя должен идти и на Python 2.

Для начала – напомню определение:

F_n= F_n-1+ F_n-2

и F₁= F₂=1.

Всем привет! Мы хотим поделиться с вами записями выступлений с предыдущего Python Meetup. В этот раз мы обсуждали полезность сохранения исходного кода с Григорием Петровым и особенности применения машинного обучения с Андрем Гриненко.

Приветствую, коллеги! Несколько недель назад состоялся 27-й Moscow Django Meetup, а всего через три дня, в эту среду, состоится 28-й. В этом топике я расскажу что интересного было на предыдущем митапе и что будет на следующем. Участие — бесплатное, площадка Фрии City Hall в центре Москвы ждет вас!

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



Данная статья является руководством по настройке системы сбора и анализа метрик приложения на базе Graphite и vimeo/graph-explorer.

Добрый день, хаброжители!

Введение

В свободное от работы время увлекся написанием приложений на PyQt5. И свой давний проект по ведению домашней бухгалтерии MyWallet решил в конце мая переписать с плюсов на Python, так как в предыдущей версии были допущены ряд архитектурных ошибок, которые на хотелось исправлять. Поэтому собрав PyQt5 из исходников под Fedora 21, где-то за две недели реализовал весь функционал, который был ранее. И теперь встает вопрос в визуализации данных по расходам/доходам помесячно. Так как имел опыт визуализации данных с помощью QCustomPlot , хотел визуализацию сделать с помощью этой либы. Но к огорчению, не нашел биндов.

Когда пишешь программу в среде LabView, в определенный момент её становится слишком много для того, чтобы уместиться в один экран. «Правила хорошего тона» LabView говорят о том, что в таких случаях надо разбивать один vi файл на несколько subvi файлов. Со временем таких subvi становится очень много. Однако об удобной навигации ребята из NI как-то не позаботились.

Мало того, что LabView сдвигает все свои окна в начало Alt-Tab списка (больше так не делает никто: en.wikipedia.org/wiki/Alt-Tab), так еще, несмотря на активно используемую возможность переопределять иконки для vi файлов, в списке Alt-Tab вместо них – стройные ряды из логотипов LabView:



Некоторых такое поведение подталкивает к покупке второго монитора. Для них в значительной степени проблема этим и решается. Еще частично помогает интерфейс Windows Aero с его миниатюрами в меню Alt-Tab. Но вроде бы лежащее на поверхности решение – (а) сделать переключение такое же, как во всех остальных приложениях, и (б) выводить в списке иконки vi – стандартными средствами недостижимо.

Судя по тому, что началось это едва ли не с самой первой версии, а соответствующая «идея по улучшению» пылится на «форуме по обмену идеями» с 2010 года forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-Alt-Tab-behaviour-consistent-with-other-applications/idi-p/1162219, просить об этом National Instruments бесполезно. Однако кое-что сделать всё-таки можно.

Крупнейшая конференция DevConf 2015 пройдет в эту пятницу в Москве (конгресс центр Измайлово Бета).
20 июня пройдут эксклюзивные мастер-классы: Sphinx 3.0, MySQL 5.7, Docker, cоздание мобильных игр и архитектуры социальной сети
62 докладчика — 7 потоков: Python, PHP, Ruby, Javascript, Storage, DevOps, Common — каждый Веб-разработчик найдет что-то интересное для повышения своей квалификации!

[ Первая часть ]

В этом посте будет то, что не поместилось в первую часть. Это некоторые операторы, которые есть в aggregation framework и достаточно вольный перевод трех статей из раздела экоситема на сайте со справкой к MongoDB, описывающих некоторые случаи применения для интернет-коммерции.

Случаи использования разделены там на восемь статей, которые условно можно разделить на три группы. Мне показались самыми интересными для перевода три материала, связанные с e-commerce.

1. Операторы в aggregation framework
2. Каталог продуктов
3. Корзина и управления остатками на складе
4. Иерархия категорий

Друзья, сегодня я хочу рассказать вам о том, как появился на свет сервис Allmychanges.com. Дело было в далеком 2013 году. Солнечным осенним днем я обдумывал идеи для реализации в рамках двухдневного хакатона Django Dash. Хотелось сделать какой-нибудь сервис для разработчиков, но не очередной континуос-интегрейшн-в-облаке, а что то более интересное и полезное.

Проблема номер один

И вот, в результате возникла такая идея – а что если сделать сервис, которому даешь URL, а он сам находит и показывает ChangeLog проекта? Ведь какая проблема с большинством, да что там с большинством – со всеми софтверными проектами – сложно найти, что у них изменилось от версии к версии. А в release notes, порой, можно найти интересные и полезные вещи. Разработчики Django, к примеру, пишут не только от том что изменилось, но и про всякие деприкешены и про то, как мигрировать с одной мажорной версии на другую.

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



Однако даже для проекта, мейнтейнеры которого заботливо ведут ChangeLog, найти его бывает проблематично. Почему? Да потому что фреймворки и библиотеки пишут люди, а люди все разные. Кто то записывает release notes в файлике NEWS, кто то в ChangeLog, a некоторые разбрасывают их по отдельным файликам типа docs/src/releases/1.7.rst. Хуже всех те, кто то вообще не ведет человеческих релиз ноутов и заставляет вас ползать по гит-логу и собирать крупицы знаний по коммит-мессаджам.

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

Основные проблемы, которые встречаются в библиотеках валидации данных

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

Проблема №2. Процедурное описание правил валидации. Я не хочу каждый раз думать про алгоритм валидации, я просто хочу описать декларативно, как должны выглядеть правильные данные. По сути, я хочу задать схему данных (почему не «JSON Schema» — в конце поста).

Проблема №3. Описание правил валидации в виде кода. Казалось бы, это не так страшно, но это сразу сводит на нет все попытки сериализации правил валидации и использования одних и тех же правил валидации на бекенде и фронтенде.

Проблема №4. Валидация останавливается на первом же поле с ошибкой. Такой подход не дает возможности подсветить сразу все ошибочные/обязательные поля в форме.

Проблема №5. Нестандартизированные сообщения об ошибках. Например, «Field name is required». Такую ошибку я не могу показать пользователю по ряду причин:

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

То есть, нужно возвращать не сообщение об ошибках, а стандартизированные коды ошибок.

Проблема №6. Числовые коды ошибок. Это просто неудобно в использовании. Я хочу, чтобы коды ошибок были интуитивно понятны. Согласитесь, что код ошибки «REQUIRED» понятней, чем код «27». Логика аналогична работе с классами исключений.

Проблема №7. Нет возможности проверять иерархические структуры данных. Сегодня, во времена разных JSON API, без этого просто не обойтись. Кроме самой валидации иерархических данных, нужно предусмотреть и возврат кодов ошибок для каждого поля.

Проблема №8. Ограниченный набор правил. Стандартных правил всегда не хватает. Валидатор должен быть расширяемый и позволять добавлять в него правила любой сложности.

Проблема №9. Слишком широкая сфера ответственности. Валидатор не должен генерировать формы, не должен генерировать код, не должен делать ничего, кроме валидации.

Проблема №10. Невозможность провести дополнительную обработку данных. Практически всегда, где есть валидация, есть необходимость в какой-то дополнительной (часто предварительной) обработке данных: вырезать запрещенные символы, привести в нижний регистр, удалить лишние пробелы. Особенно актуально — это удаление пробелов в начале и в конце строки. В 99% случаев они там не нужны. Я знаю, что я до этого говорил, что валидатор не должен делать ничего кроме валидации.

3 года назад, было решено написать валидатор, который не будет иметь всех вышеописанных проблем. Так появился LIVR (Language Independent Validation Rules). Есть реализации на Perl, PHP, JavaScript, Python (мы на python не пишем — фидбек по ней дать не могу). Валидатор используется в продакшене уже несколько лет практически в каждом проекте компании. Валидатор работает, как на сервере, так и на клиенте.

Возникла задача: есть приложение под Windows, которое делает HTTPS-запросы к серверу и получает ответы. После обновления сервера приложение перестало работать. Выяснилось, что на сервере изменилась версия SSL (перешли с SSLv3 на TLSv1), а наше приложение умеет работать только по SSLv3. Приложение никто не поддерживает уже давно и менять, перекомпилировать, тестировать не хотелось. Решено было сделать прослойку между приложением и сервером, которая будет транслировать SSLv3 в TLSv1 и наоборот. Я поискал какой-нибудь прокси в интернете, но сходу не нашел (плохо искал). Решил сделать прокси на питоне. Я не профессионал в питоне, но мне показалось что для этой задачи он хорошо подходит, и интересно параллельно по изучать питон на примере реальной задачи.

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