Amazon byteflow

Такой маленький пост, чисто похвастаться. :) Вот уже несколько месяцев благополучно работают обе части OpenID в движке — и клиент, и сервер. Ни одного бага (кроме небольшого, связанного с траблами реверс-проксирования и не имеющего отношения к логике работы) с тех пор, как мы закончили встраивать DjangoID (главным образом усилиями Олега) в Byteflow, т.е. примерно с марта. Ура! :)

Возможно вы ещё не видели — я начал писать для DOU серию статей про Mercurial. Уже появилась первая, и продолжение не за горами. :)

Последнее время мне всё более и более странным (я бы даже сказал “недальновидным”) кажется решение авторов оригинального туториала по Джанге показывать именно такой формат расположения файлов в джанге (и уж тем более то, какой sys.path они там используют): в туториале все файлики, созданные с помощью startproject, лежат в одной директории вместе с приложениями. Соответственно, все импорты выглядят как from someproject.someapp import views.

Мне понятно, откуда ноги растут — на деле у них все приложения лежат в sys.path, и потому импортируют они оттуда как from someapp import views, а проект — это лишь настройки да корневой конфиг урлов. Тогда можно родительскую для всех проектов директорию положить в sys.path, и менять только DJANGO_SETTINGS_MODULE. Но в любом случае одним интерпретатором питона для двух джанговских проектов не обойдёшься (спасибо этому самому DJANGO_SETTINGS_MODULE), а способность к лёгкому созданию дистрибутива и его распространению страдает порядочно (что особенно важно для опенсорсовых проектов).

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

project/
  apps/        # собственно приложения
  template/    # шаблоны
  static/      # статические файлы — картинки оформления, стили, JS
  media/       # файлики, загруженные пользователями, не версионируется
  locale/      # переводы
  compat/      # тут библиотеки типа django-atom
  manage.py    # файлы, относящиеся к описанию проекта
  settings.py
  urls.py
  ...

При этом в sys.path добавляется сама директория проекта, DJANGO_SETTINGS_MODULE становится равен settings, а в settings.py двумя строками кода в sys.path добавляется и apps/ с compat/¹. В результате все импорты простые и не содержат имени проекта (что тупо хотя бы потому, что я не могу склонировать проект рядом и поэкспериментировать в нём из-за того, что будут проблемы с импортами), а проект становится достаточно независимой вещью, которая для разворачивания на каком-то сервере требует только Джангу и библиотеки, которые достаточно распространённые и/или большие для того, чтобы не включать их в проект.

Заметил одну интересную особенность статей о Гите — каждая из них рассказывает о формате его репозитория, в который раз талдыча про его простоту и понятность, в то время как статьи про Меркуриал и Базар содержат более близкую пользователю информацию.

Похоже, всё потому, что с интерфейсом Гита просто невозможно справиться, не понимания в точности, что же происходит. В то время как в Меркуриале эта информация избыточна — всё достаточно просто и без того. :)

Какое-то время назад Бурчик перевёл свой блог на Byteflow, и благодаря его стараниям в движке появилась возможность получать новые комментарии по почте. “Возможность” — это, конечно, сильно сказано, потому как получали их все прокомментировавшие без особых разбирательств. ;)

Однако, несмотря на всё несовершенство этой штуки, она сделала своё дело — заставила меня перестать бездельничать и написать функциональность, которая бы позволяла подписаться и отписаться от комментариев к определённому посту. За сегодня родилось небольшое приложение, которое следит за вашими подписками, позволяет подписаться на избранные посты, посмотреть список подписок (ух, каламбурище ;) и отписаться от желаемого.

По-моему, получилось всё довольно неплохо и даже немного обобщённо для того, чтобы можно было это приложение использовать в других проектах. :)

P.S.А ещё я починил рекаптчу сегодня, сто лет долгой жизни разработчикам jQuery, её поломавшим.

Enjoy!

В транке меркуриала появилась одна очень клёвая штука — дерево чейнджсетов в hgweb’е. Раньше его можно было посмотреть только локально, а сейчас — и онлайн. Например, вот byteflow.

Кстати, последние изменения в crew¹ говорят о том, что возможно в скором времени можно будет коммитить без рабочей копии (т.е. прямо из памяти, используя API). :-)

Пока честный rebase для меркуриала находится в стадии проекта для GSoC, я расскажу про то, как его сделать с помощью существующих инструментов — всё же это бывает полезно.

Довольно долго для расшаривания репозиториев меркуриала мне хватало обычного доступа по HTTP: легко настроить (дал права пользователю веб-сервера — www-data, и всё), просмотреть, работает всё чётко и без запинки. Но в конце-концов достало меня раз за разом набирать пароль для заливания своих изменений в репозиторий, а так как единственным альтернативным вариантом при доступе через HTTP является запись пароля открытым текстом в hgrc локального репозитория, я решил поиграться с доступом по ssh.

Few days ago there was a lot links on the Internet to gitshelve, which implements persistent versioned storage of objects in the git. I’ve read it description and realized that there are few serious design flaws:

• Can store only strings
• Uses subprocess.PIPE for interconnection with git
• Uses bunch of C+Perl+Shell code in Python library instead of using another Python library ;-)

Итак, 24 мая опять намечается тусовка питонистов! ;-) Что хорошо — у Ивана получилось, как он и обещал, устроить это всё через пару месяцев. А что отлично — что это будут мастерклассы. Три штуки.

Меня лично больше всего интересует Twisted, как наиболее далёкая для меня сейчас из всей троицы вещь. ;) А вот трюки… сделать тут интересный и полезный доклад реально сложно. Ну посмотрим, что получится.

В общем, главное — приходите! Семинар крут не только своими докладами, но и тусовкой после завершения. =)