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 для куда менее очевидных задач.

В этой статье я попробую ответить на такие вопросы:

• может ли один доклад умного человека сделать другого человека одержимым?
• как окунуться в машинное обучение (почти) с нуля?
• почему не стоит недооценивать многоруких бандитов?
• существует ли серебряная пуля для a/b тестов?

Ответ на первый вопрос будет самым лаконичным — «да». Услышав это выступление bobuk на YaC/M, я восхитился элегантностью подхода и задумался о том, как бы внедрить похожее решение. Я тогда работал продуктовым менеджером в компании Wargaming и как раз занимался т.н. user acquisition services – технологическими решениями для привлечения пользователей, в число которых входила и система для A/B тестирования лендингов. Так что зерна легли на благодатную почву.

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

Доброго времени суток, хабр!

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



Мы будем использовать их вместе!

Последняя пятница апреля не стала исключением для встречи сообщества любителей языка Python. В этот раз спикеры на Python Meetup поделились следующими темами:

• Grail: шаги для ваших Python-тестов
• Rest сервисы на Flask
• GUI приложение за пять минут

Видео и ссылки на презентации под катом. Приятного просмотра!

Вышла третья версия OpenCV (Open Computer Vision Library) — популярной библиотеки алгоритмов компьютерного зрения, обработки изображений и численных алгоритмов общего назначения с открытым исходным кодом.

Релиз включает примерно 1500 патчей, отправленных через github. Упомянуто, что в OpenCV использовано большое количество интеллектуальной собственности Intel (IPPCV), которую компания передала пользователям библиотеки бесплатно, без лицензионных выплат, для коммерческого и некоммерческого использования. Аппаратное ускорение с использованием OpenCL теперь доступно разработчикам через T-API (transparent API). Помимо этого, в третью версию OpenCV добавлено огромное количество новых возможностей, улучшений производительности и стабильности, подробнее обо всём можно почитать по ссылке.

Это первая стабильная версия библиотеки, которая полностью поддерживает Python 3. Для Windows и Python 3.4 бинарники уже можно скачать на сайте lfd.uci.edu. Модуль всё ещё имеет название cv2.

Коллеги — до конференции DevConf 2015 осталось меньше 2-х недель — помогите выбрать достойные доклады.

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

Список секций: DevOps, Storage, PHP, Python, Ruby, Javascript, Common
ГОЛОСУЕМ ЗА ДОКЛАДЫ ДО 8 ИЮНЯ!

Александр Чистяков работает главным инженером в компании Git in Sky, любит зеленый чай, белыми ночами превращается в котика, а черными — в обезьяну. Несколько лет назад выступил публично на DevConf и с тех пор не может остановиться.

Наиболее известные средства управления конфигурацией по ряду причин написаны на языке Ruby, а что же делать тем, кто не хочет или не может использовать Ruby в своей инфраструктуре? Python-разработчики не остались в долгу и создали SaltStack и Ansible — простые и эффективные средства, о которых вы можете увидеть в видео с DevConf.

Здесь рассматривалась задача управления компьютером на Windows из Linux. Решалась с помощью winexe.

Подобная задача удаленной установки софта, проверки состояния, дистанционного выключения/перезагрузки большой группы Windows компьютеров (учебные классы) ниже решается с помощью freeSSHd — ssh-сервера для Windows.

На сайте лежит только последняя версия freeSSHd — 1.3.1. У меня она работает неустойчиво (иногда падает сервис). Предыдущая версия — 1.2.4 — работает прекрасно от XP до Win8.1, хотя и есть небольшой эксплоит — но вроде ничего кроме, как завалить сервис FreeSSHDService не получается, поэтому можно закрыть на это глаза. На всякий случай положил эту версию здесь (размер — 782456)

Был у меня как-то сайт по поиску твинков в World of Warcraft. Любой мог ввести ник и получить список персонажей, находящихся на той же записи (если данные имелись в базе сайта, конечно).

И вот однажды ко мне зашел посетитель из Blizzard:



99% людей во время первого посещения ищут себя и своих друзей. Посетитель из Франции не стал исключением и оставил в логе просмотров несколько персонажей, скорее всего принадлежащих работникам близзард (что было видно по активности на форуме и другим признакам). Конечно, мне стало интересно, чем же отличаются персонажи гейммастеров от персонажей обычных смертных и отличаются ли вообще.