Как можно расширить синтаксис Python и добавить в него необходимые возможности? Прошлым летом на PyCon я постарался разобрать эту тему. Из доклада можно узнать, как устроены библиотеки pytest, macropy, patterns и как они добиваются таких интересных результатов. В конце есть пример кодогенерации с помощью макросов в HyLang — Lisp-образного языка, бегущего поверх Python.


— Привет, ребята. Хочу в первую очередь поблагодарить организаторов PyCon. Я разработчик в Яндексе. Доклад будет совсем не про работу, а про экспериментальные вещи. Возможно, кого-то из вас они наведут на мысль, что в Python можно делать клевые штуки, о которых вы раньше даже не догадывались, не мыслили в эту сторону.

REPL (read-eval-print loop) бесполезен в Python, даже если это волшебный IPython. Сегодня я предложу одно из возможных решений этой проблемы. В первую очередь доклад и мое расширение TheREPL будет полезны тем, кого интересует более быстрая и эффективная разработка, а также тем, кто пишет stateful-системы.


— Меня зовут Александр, я в Яндексе работаю программистом. Пишем мы в моей команде на Python, на Go пока не перешли. Но в свободное от работы время я, как ни странно, тоже программирую и делаю это на очень динамическом языке — Common Lisp. Он, пожалуй, даже более динамический, чем Python. Его особенность заключается в том, что сам процесс разработки устроен несколько иначе. Он более интерактивный и итеративный, потому что в REPL на Lisp вы можете делать всё: создавать новые и удалять старые модули, добавлять методы, классы и удалять их, переопределять классы и т. д.

Друзья, сегодня я хочу рассказать вам про одну идею, которая давно поселилась в моей голове. Она возникла много лет назад и смысл её в том, чтобы сделать сервис, который бы аггрегировал и представлял в удобном виде все коммуникации, происходящие вокруг интересных вам GitHub проектов. Такой сервис будет в первую очень полезен тем, у кого много своих проектов на GitHub, или тем создаёт много пуллов и тикетов в чужих проектах.

Я верю в то, что люди, создающие тикеты и пуллы делают это ради того, чтобы улучшить те opensource проекты, которые им небезразличны. А для этого нужно, чтобы тикеты превращались в пуллы и пуллы своевременно мерджились. Чем быстрее будет происходить этот процесс, тем быстрее будет развиваться OpenSource.

Однако, на GitHub часто бывает, что коммуникация вокруг тикета или пулла затихает и теряется. Происходит это по разным причинам, но как правило — из-за того, что какой-то из участников пропускает email-отбивку о комментарии. Причины могут быть разные, а результат всегда один — тикет теряется и иногда проходят годы, прежде чем про него вспоминают.

Часто приходится видеть, как новички пробуют Common Lisp и потом жалуются, что с ним невозможно нормально работать. Как правило, это происходит из-за того, что они не понимают как настроить себе процесс, обеспечивающий тот самый "быстрый отклик" от среды разработки, когда ты поменял функцию, скомпилировал её и изменения тут же начали использоваться внутри уже "бегущей" прогрммы без её перезапуска.

Понять, как это выглядит, можно посмотрев какой-нибудь ролик на youtube, где демонстрируется интерактивная разработка на Common Lisp.

Сегодня я хочу поговорить про будущее сервиса AllMyChanges.com. Для тех, кто впервые о нём слышит, поясню, это такой сервис для подписки на выход новых версий библиотек, софта и чего угодно, что имеет номер версии и её описание. Более подробно можно почитать в предыдущих статьях.

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

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

Итак, как уже было сказано, я вижу три направления развития. Давайте посмотрим на первое.

Кавайность

Многие пользователи говорят мне, и не без оснований, что сервис мог быть и посимпатичнее, или поудобнее. При этом, как правило, кивают в сторону конкурентов, типа Sibbel, советуют взять Bootstrap и тому подобное.

Никто впрочем, не опускается до деталей и подобные замечания, как правило, неконструктивны, а потому заканчиваются ничем.



Я прекрасно понимаю, что сервису недостает модного ныне гламура. Но зато он отлично выполняет свои функции — парсит ченьджлоги и рассылает уведомления о новых релизах.

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

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

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

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

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

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

Когда наш проект только зарождался, он базировался на гипотезе, что почти для любой библиотеки можно найти changelog, а если найти нельзя, то можно построить его из коммит-мессаджей. Но реальность оказалась не столь радужной, как нам того хотелось: то файл changelog в каком нибудь безобразном формате попадётся, то его перестали вести, а продукт меж тем развивается, то что нибудь ещё. И тогда мы поняли, что распарсить мир – мало, надо его менять.

Изменить что-то за один миг — необычайно сложная задача

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



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

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

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

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

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



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

Просмотрел списки инсталляций MongoDB и CouchDB.

MongoDB используют как минимум два крупных сервиса, это SourceForge и Disqus, а вот в списке CouchDB я вообще не нашел ничего достаточно крупного, по моему там все небольшие наколеночные сайтики. Поправьте меня, если я не прав.

Вот список для MongoDB, а вот для CouchDB.

Как по вашему, что из них больше готово для продакшена?

Ура! Теперь и для Windows! Сегодня я выложил очередную версию плагина для закачивания снимков на Яндекс Фотки.

Не знаю, работал ли раньше плагин в версии Lightroom для Windows, но судя по тем ошибкам, которые я обнаружил — не должен был :-)

В общем, теперь я кажется все починил, и оно должно работать. Все дело было в том, что версии LR для MacOSX и Windows по разному обрабатывают cookie, приходящие от браузера. Ну да ладно, простым пользователям это не интересно, а разработчикам LR я еще напишу пару ласковых.

Помимо того, что плагин починен и проверен под Windows XP, других изменений нет. Впрочем, если что не так, не стесняйтесь оставлять комментарии.

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