Python *

Друзья, сегодня я хочу рассказать вам о том, как появился на свет сервис 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% людей во время первого посещения ищут себя и своих друзей. Посетитель из Франции не стал исключением и оставил в логе просмотров несколько персонажей, скорее всего принадлежащих работникам близзард (что было видно по активности на форуме и другим признакам). Конечно, мне стало интересно, чем же отличаются персонажи гейммастеров от персонажей обычных смертных и отличаются ли вообще.

Барышников Максим, Solutions Architect в Wargaming.net
«Очень развитая веб-часть» в реалиях Wargaming — это:
— более 40 отдельных проектов, над которыми работают более 200 человек (только в минской студии);
— 2 млн UDV только на сайте worldoftanks.ru в день релиза;
— подробные досье 60 млн. игроков — это только часть тех данных, которые мы предоставляем игрокам вне игры;
— Public API;
— Мировая война на Глобальной Карте.

Этот пост — небольшая шпаргалка по mongodb и немного длинных запросов с парой рецептов. Иногда бывает удобно когда какие-то мелочи собраны в одном месте, надеюсь, каждый, кто интересуется mongodb, найдет для себя что-то полезное.

Не хотелось бы, чтобы пост воспринимался в ключе холиваров на тему SQL vs. NOSQL И так понятно что везде есть свои плюсы и минусы, в данном случае это просто где-то немного справки, где-то немного примеров из того, с чем приходилось сталкиваться. Примеры на mongo shell и на python.

1. Миграция в на новые версии в mongodb
   
   • До версии 2.6
   • С 2.6 до 3.0 версии
   • Новое в PyMongo
2. Запросы сравнения и логические
3. Полнотекстовый поиск в Mongodb, regexp, индексы и пр.
4. Атомарные операторы (модифицирующие данные )
5. Немного о транзакциях в Mongodb
   
   • Уникальный индекс
   • Двухфазный коммит
6. Агрегационный фреймворк и JOIN-ы в Mongodb
7. Примеры
   
   • Деревья, комментарии в Mongodb
   • Теги, блоги
   • Е-commerce, и сложные фильтры в Mongodb
8. Небольшая песочница на Python

Многие разработчики, особенно принимающие активное участие в проектировании системы, наверняка сталкивались с подобной ситуацией: приходит коллега (разраб, проектлид или продажник не суть важно) с очередной идеей-фикс: давай перепишем все на java, scala и т.д. (любимое подставить).

Вот и мне в очередной раз «спустили» такую идею в немаленьком-таком legacy проекте. Не совсем переписать, не совсем все (ну в перспективе). В общем перейти с питона (а у нас там еще и тикль модульно присутствует) на scala. Речь пока шла о разработке новых модулей и сервисов, т.е. начинать с наименее привязанных к middle-level и front-nearby API's. Как я понял в перспективе возможно совсем.

Человек — не разработчик, типа нач-проекта и немного продажник (для конкретного клиента) в одном лице.

Я не то, чтобы против. И скалу уважаю и по-своему люблю. Обычно я вообще открыт ко всему новому. Так, например, местами кроме тикля и питона у нас появляются сервисы или модули на других языках. Так, например, мы переехали с cvs на svn, а затем на git (а раньше, давно-давно, вообще MS-VSS был). Примеров на самом деле масса, объединяет их один момент — так решили или как минимум одобрили сами разработчики (коллективно ли, или была группа инициаторов — не суть важно). Да и дело в общем в аргументах за и против.

Проблема в том, что иногда для аргументированной дискуссии «Developer vs. Anybody-Else» у последнего не дотягивает уровень знаний «материи» или просто невероятно сложно донести мысль — т.е. как-бы разговор на разных языках. И хорошо если это кто-нибудь типа software architect. Хуже, если имеем «беседу» например с чистым «продажником», огласившим например внезапные «требования» заказчика.

Ну почему никто не предписывает, например, плиточнику — каким шпателем ему работать (типа с зубцами 10мм клея же больше уйдет, давайте может все же 5мм. А то что там полы-стены кривущие никого не волнует). И шуруп теоретически тоже можно «закручивать» молотком, но для этого же есть отвертка, а позже был придуман шуруповёрт. Утрирую конечно, но иногда действительно напоминает такой вот абсурд.

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

Но что-то я отвлекся. В моей конкретной истории аргументов — за scala, у человека как всегда почти никаких.
Хотя я мог бы долго говорить про вещи, типа наличие разрабов, готовые наработки, отточенную и отлаженную систему и т.д. и т.п. Но зацепился за его «Питон очень медленный». В качестве примера он в меня кинул ссылкой на Interpreting a benchmark in C, Clojure, Python, Ruby, Scala and others — Stack Overflow, которую он даже до конца не прочитал (ибо там почти прямым текстом есть — не так плохо все с питоном).

Имелось ввиду именно вот это (время указано в секундах):

  Sexy primes up to:        10k      20k      30k      100k
  ---------------------------------------------------------
  Python2.7                1.49     5.20    11.00       119     
  Scala2.9.2               0.93     1.41     2.73     20.84
  Scala2.9.2 (optimized)   0.32     0.79     1.46     12.01

Samba4 имеет встроенный интерфейс на Python. Многие утилиты (samba-tool, например) полностью реализованы на Python с применением этого интерфейса.

Все, что делалось из LDAP-интерфейса, можно сделать на Samba 4 Python Scripting. Преимущества — файловый доступ, значит высокая скорость, некоторые фичи, которых нет в LDAP. Например, можно взять хэш паролей пользователей из одной базы и перекинуть в другую. Да и самих пользователей с их SID-ами, паролями и всем прочим перекинуть в другой домен (без заморочек с SID-history).

Привет, Хабр!
Историй о разработке игр было немало, сегодня я попробую вкратце рассказать нашу.

Мир есть текст — Жак Деррида
Игра есть словарь — a11aud

В статье речь пойдет о построение нейронных сетей (с регуляризацией) с вычислениями преимущественно векторным способом на Python. Статья приближена к материалам курса Machine learning by Andrew Ng для более быстрого восприятия, но если вы курс не проходили ничего страшного, ничего специфичного не предвидится. Если вы всегда хотели построить свою нейронную сеть с преферансом и барышням векторами и регуляризацией, но что то вас удерживало, то сейчас самое время.

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

Доброго здравия! Не удивлюсь, что Вы раньше даже не слышали об этой программе. Как и я, до того дня, когда мне пригодился Python Debugger. Да, знаю, есть pdb, но его функционал и то, как он представлен, мне совершенно не приглянулось. После непродолжительных поисков я наткнулся на этот замечательный продукт. Тут есть все, что может пригодиться в отладке ваших Python приложений (скажу сразу: данный язык я не изучал, поэтому, если какие-то неточности всплывут, просьба не ругаться).

Друзья, спешу сообщить, что 28 мая в 19:00 в офисе компании Rambler&Co пройдет встреча сообщества Moscow Python Meetup. Тема встречи — «Async: why and when?».

В программе интересные доклады, общение, холивары и море позитива.