31 мая 2012 г.

Practicing Continuous Deployment (David Cramer)

Подоспела очередная видеорекомендация: на этот раз на тему развёртывания проектов на Django.
Об этом не понаслышке знаком Дэвид Крамер, один из разработчиков Disq.us. Мы с удовольствием пользуемся их сервисом по встраиванию комментариев на сайты. Поскольку Disq.us считается самым большим django-приложением, особенно интересно послушать как
устроен deployment у них.

Видео (41:20)
Слайды



Основные темы

  • плюсы и минусы внедрения continuous deployment;
  • зачем любая библиотека или приложение должны быть пакетом и как упростить жизнь простого девелопера;
  • как ускорить тесты и не наступить на грабли continuous integration.
Ребята применяют:
  • авторский Sentry для логирования ошибок на десятках серверов;
  • активно применяют "feature flip" для обкатки нового кода на определенной части пользователей;
  • используют Phabricator (от разработчиков Facebook) для ревью кода (раньше использовали github pull requests);
  • для сбора и отрисовки метрик применяют Graphite.
Презентация является сжатой версией 90-минутного выступления Pitfalls of Continuous Deployment с EuroPython 2011. Кому-то она может понравиться больше.




26 мая 2012 г.

Чтиво на выходные 26-27 мая

Сегодня вас ждёт небольшой спецвыпуск про python и Django only. Наслаждайтесь :)

Django + Python

В мае появился новый подкаст, посвящённый Django. Ребята успели записать пару выпусков, первый про новинки Django 1.4, второй - про Celery и очереди задач. Рекомендуется новичкам с хорошим знанием английского.

Принят PEP 405: Python Virtual Environments от Карла Майера, автора virtualenv. В питоне 3.3 этой осенью нас ждёт виртуалэнв из коробки, это не может не радовать.

Ещё принят PEP 420: Implicit namespace packages, не менее интересное предложение, одним из результатов которого станет отсутствие необходимости в __init__.py во всех питоновских пакетах (подробности по ссылке).

Недавно зарелизился замечательный пакет django-discover-runner, позволяющий сделать обнаружение тестов более удобоваримым, а именно discovery из unittest2. Подробнее в презентации того же Карла Майера Testing and Django.

Люди жаловались, что python-сообщество не ценит дизайн, а вышедший в декабре менеджер пакетов Stallion пытается это опровергнуть. Он отличается от классических pip, easy_install тем, что предоставляет визуализацию установленных пакетов и несколько функций для управления ими. Написан на Flask и использует Twitter bootstrap. Похвастать оригинальностью тут нечем, зато аккуратно и симпатично.

История сервиса для шаринга Pinterest, написанного на Django, очень напоминает Instagram за исключением покупки: облачная архитектура, быстрый рост, огромное количество данных и небольшое количество сотрудников.

Статья на Хабре про Django + MySQL, особенности использования с InnoDb и транзакции. Advanced-чтиво, очень полезно всем, кто ещё не переключился на Postgresql.

Пост с кучей полезных советов по питону и перевод на Хабре.

24 мая 2012 г.

High Performance Python (Ian Ozsvald)

После небольшого перерыва - продолжаем обозревать годные видео с различных PyCon`ов. На этот раз речь пойдёт о проблеме, которую питонисты поднимают неохотно, а зачастую даже избегают её, оправдываясь фразами вроде "зато разрабатывать быстро" или "зато код читабельный", или ещё что-то в этом роде. И проблема эта - производительность. Одна из немногих проблем, которая действительно имеет место и с которой мало кто знает как бороться.

Зато это знает Ian Ozsvald. На последнем американском PyCon`е он выступил, вероятно, с самым большим докладом (в двух частях, по 3 часа каждый), в котором достаточно подробно, пошагово, осветил современные и недорогие методы увеличения производительности Python-кода - от компиляции отдельно взятых модулей через трансляцию в C-код (небезызвестный проект Cython) до параллельных вычислений. В интерактивном режиме, докладчик вместе с аудиторией построчно улучшает скорость выполнения функции создания множества Мандельброта (в качестве образцово-показательного примера), постепенно увеличив её более чем в 50 раз. Да-да, время отработки уменьшилось с 50 до 0.7 секунд, на одном ядре. Потрясающий результат.

Докладчик занимается проблемой искусственного интеллекта, активно использует в своей работе numpy, поэтому для него скорость выполнения особо сложных вычислений стоит более остро, чем для рядового веб-разработчика. Но, тем не менее, целый ряд приёмов наверняка будет полезен многим питонистам, независимо от сферы применения языка. 6 часов видео осилить непросто, но это стоит ваших выходных :)




19 мая 2012 г.

Чтиво на выходные 19-20 мая

Django

Добрые люди выкачали все видеозаписи с последнийх PyCon и сделали торрент-раздачи: PyCon US 2011 Atlanta и 2012 Santa Clara. Есть также торрент на PyCon 2012 Santa Clara рутрекере. Спасибо Михаилу Феоктистову и Михаилу @mktums.

Неплохая обзорная статья про варианты кеширования в Django. Рассмотрены как готовые решения, так и общие рецепты для собственных решений.

Подробный разбор безопасности Django в отличной презентации ”Case Study of Django: Web Frameworks that are Secure by Default”


WebDev

Инструмент для экспорта слоев Фотошопа в css. Обещают скорый релиз.


Разное

RFC-документы, содержащие спецификации и стандарты, широко применяемые в интернете: все в одном месте, красиво оформленные и с поиском.


События

2-го июня пройдёт 4-й KharkivPy (Харьков, Украина) и ещё не поздно зарегистрироваться. Пока ожидается 5 докладов про Flask, Django и Python в общем, но скорее всего их будет больше. Рома Семирук будет там и подготовит отчёт, как всегда, для тех, у кого не получится приехать.

В этот же день в Минске пройдёт Яндекс.Субботник и жаль, что Рома не умеет клонироваться :) Некоторые доклады повторяются, но есть и новые темы. Субботники всегда вызывают аншлаг, поэтому регистрироваться на событие лучше уже прямо сейчас.

13 мая 2012 г.

Чтиво на воскресенье 13 мая

Django + Python

Продолжаем делиться опенсорсом: django-future-url от Виталия Олевинского. Как без особых проблем сделать все теги {% url %} совместимыми с будущими версиями Django.

Ребята из dabapps рассказывают про свой подход к работе с ORM: заменяйте низкоуровневые вызовы кастомными Queryset-менеджерами. У себя в студии мы делаем примерно то же самое.

Несколько полезных ссылочек, которые были озвучены на Moscow Django Meetup (timepad, facebook).
Достойная альтернатива Django Compressor — django-gears.
С документацией Class Based Generic Views дела обстоят не очень хорошо, http://ccbv.co.uk/ отличный помощник в этом.

Небольшой но полезный сниппет для Flask - декоратор для быстрой разработки RESTful-сервисов.

Webdev

Советы верстальщикам или как не надо готовить БЭМ. Статья нашего главного фронтендера Артёма Голикова “.b-left или .b-right?

Образец клиентской оптимизации на примере Github. Много конкретики, все рекомендации по делу. Кстати в эту тему недавний апдейт их иконок, которые стали векторными.

Что такое прототипы в JavaScript и как их готовить. Для начинающих, просто и лаконично. Там же, рядом, аналогичная статья про замыкания.

Конференции

Успешно прошёл Moscow Django Meetup #3.
Мы выложили свой отчёт о киевском Яндекс.Субботнике.
Девконф начал голосование за доклады.

12 мая 2012 г.

Moscow Django Meetup #3



Хотим поделиться впечатлениями от третьей московской встречи Django-девелоперов, она же Moscow Django Meetup. Благодаря организаторам из GreenfieldProject и Seven Quark в этот раз удалось подыскать для встречи отличное место: один из вместительных залов MOD Design. Очень уютное, близко к центру, а главное, всем хватило места и было удобно. Огромный проекционный экран, кликер для докладчика, вкусный кофе в перерыве, что ещё надо для хорошего митапа.

Презентации на SlideShare
Группа Moscow Django в Facebook
События на timepad

В программе были заявлены 5 докладов: 3 полноценных по 20 минут и два укороченных по 10, разделённые одним кофебрейком. Сколько пришло народу из почти сотни зарегистрированных сказать сложно, человек 50-60, вероятно, кто-то не успел
прийти в себя после праздников. На фото зал минут за 10-15 до начала, потом народ ещё подтянулся.

11 мая 2012 г.

.b-left или .b-right?

О наименованиях

В вёрстке абсолютно независимыми блоками, как ни странно, главное - корректно назвать блок/элемент/модификатор, и это достаточно трудоёмкий процесс. Почему это важно? Класс элемента, сконструированный с соблюдением единого принципа, однозначно указывает на его смысл и назначение. При этом хорошо читается его роль (блок, элемент блока) и/или модификация.

Каким должно быть это название? Во-первых, уникальным. Для блока - в рамках проекта, а для элемента - в рамках блока. Во-вторых, понятно и органично проекту описывающим назначение блока / элемента. Название должно максимально соответствовать системе терминов, принятой в проекте. Названия моделей, их атрибутов и т.п. должны соответствовать названиям блоков, их отображающих.

Нельзя допустить, чтобы название говорило о том, как элемент должен выглядеть, или какой тег ему соответствует. Много лучше, когда название объясняет, что это такое, каков смысл нахождения этого здесь. Про соответствие названия тегу вы, думаю, сами догадываетесь: ничто не вечно, и сегодня это <p>, а завтра <div> и т.д.

Плохо:
<div class="left"></div>

<p class="news__p"></p>

<ul class="ul">
    <li class="ul__li"></li>
</ul>
Хорошо:
<p class="article__teaser"></p>

<ul class="menu">
    <li class="menu__item"></li>
</ul>

Лирическое отступление. У меня иногда возникает ситуация, когда я с трудом даю определение блоку / элементу. И в основном это связано с «красотой» дизайна, не несущего смысловой нагрузки. В эти моменты я грущу, так как бессмысленность дизайнерскоро решения отражается на коде, усложняя его, приводит к потенциальным проблемам, усложняет рефакторинг. Уверен, хороший дизайнер всегда задаёт себе вопросы: что это? почему это здесь?..

О дублировании кода

Рефакторинг, перевёрстка - все эти слова больше не пугают, если названия хорошо сконструированы, не пересекаются, а стили изолированы друг от друга. Тут есть один тонкий момент, связанный с пересечением вёрстки. Часто возникает соблазн вынести общие стили, например, скругления уголков или одинаковые отступы справа, в отдельные классы или даже блоки и примешивать их к одному и тому же html. С одной стороны, это уменьшает дублирование кода, создаёт свой внутрипроектовый фреймворк, позволяет в одном месте изменить значение внешний вид блоков / элементов, к которым добавлены эти примеси. С другой стороны, если увлечься, вёрстка становится размытой и внешний вид блока определяет не один css, связанный только с ним, но также и куча других правил, раскиданных по проекту, а количество класcов на тегах становится устрашающим. Ещё один минус - потеря семантики, так как эти примеси говорят скорее о внешнем виде, чем о сути, и, о ужас, в проекте могут появиться теги, на которые повешены только лишь классы примесей, говорящие не о смысле, а о внешнем виде его. Эта тенденция похожа на деградацию до старых каскадов и глобальных стилей. Рефакторинг такой вёрстки затрудняется. Всё это говорит о том, что не стоит перебарщивать с вынесением общих стилей.

Плохо:
<div class="news i-col50 i-left i-nowrap i-rounded-borders"></div>
Плохо:
<section class="blog">
    <div class="i-col60">
        <article class="blog__post">
            ...
        </article>
    </div>
    <div class="i-col40">
        <aside class="blog__author">
            ...
        </aside>
    </div>
</section>
Хорошо:
<section class="blog">
    <div class="blog__posts">
        <article class="blog__post">
            ...
        </article>
    </div>
    <div class="blog__description">
        <aside class="blog__author">
            ...
        </aside>
    </div>
</section>

О префиксах

Что касается префиксов, то их использование не имеет особой необходимости. Раньше я использовал разные префиксы: b-, l-, .h, g- и т.п. Если посмотреть на код, то большинство классов получало префикс b-, и это не несло эффективной смысловой нагрузки, только усложняло редактирование. Некоторые префиксы, как h- раньше или i- сейчас, имеют проблемы, связанные с их пониманием. Например, i- префикс предлагается использовать для глобальных блоков, примесей, а также для интерактивных элементов, что само по себе неопределённо и размыто. С другой стороны, иногда использую префикс g- для глобальных стилей (например, g-clear или g-hide) и префикс m- для темизации страницы (вешаю на <body />). Если возвратиться к старым префиксам, то можно отметить префикс l-, который имеет некоторый смысл в плане улучшения читаемости кода. Если подвести итог, то префиксы по большому счёту не нужны и только загромождают код.

О тегах

Так как блок является смысловой единицей, главный, «рутовый» тег блока должен являтся смысловым в плане html-разметки страницы. Такими тегами являются section, article, aside, footer, header, nav. Тег div особой смысловой нагрузки не несёт, как и span, является нейтральным; их стоит использовать для задач оформления, то есть для экстра-разметки, необходимой, чтобы повторить изыски дизайна в вёрстке.

Плохо:
<div class="page">
    <section class="page_content">
        <div class="header">
            <header class="logo">
                ...
            </header>
        </div>
    </section>
    ...
    <footer class="footer">
        ...
    </footer>
</div>
Хорошо:
<section class="page">
    <header class="header">
        ...
    </header>
    <section class="greeting">
        ...
    </section>
    <section class="hews">
        ...
    </section>
    <footer class="footer">
        ...
    </footer>
</section>

О выделении блоков

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

Было:
<section class="blog">
    <article class="blog__post">
        <header class="blog__post-info">
            ...
        </header>
        <div class="blog__post-teaser">
            ...
        </div>
    </article>
    <aside class="blog__author">
        <div class="blog__author-name">
            ...
        </div>
    </aside>
</section>
Стало:
<section class="blog">
    <article class="post">
        <header class="post__info">
            ...
        </header>
        <div class="post__teaser">
            ...
        </div>
    </article>
    <aside class="author">
        <div class="author__name">
            ...
        </div>
    </aside>
</section>

10 мая 2012 г.

Миграция на Django 1.4

Если вы тоже столкнулись с проблемой переноса старых проектов на Django 1.4, то этот пост для вас.

Первое что довольно сильно напрягает это «Deprecation warnings» в логах:
  • DeprecationWarning: The syntax for the url template tag is changing. Load the url tag from the future tag library to start using the new behavior.
  • The ADMIN_MEDIA_PREFIX setting has been removed; use STATIC_URL instead.
  • Authentication backends without a `supports_inactive_user` attribute are deprecated. Please define it ...

К слову, в Django 1.4 этот список довольно большой.

Один вариант решения это «Забить!» и вставить в manage.py пару строчек:
import warnings
warnings.filterwarnings('ignore', category=DeprecationWarning)

Другой — это заменить в строке выше 'ignore' на 'error' и попробовать исправить все ошибки. «ADMIN_MEDIA_PREFIX» и «supports_inactive_user» решаются довольно быстро, а вот с шаблонными «url» тегами придётся повозиться:
  • Добавить в шаблон тег «{% load url from future %}».
  • Обновить теги ссылок например «{% url myapp:view-name arg arg2 as the_url %}» должно стать «{% url 'myapp:view-name' arg arg2 as the_url %}».
При мысле о том, что нужно бегать по всем шаблонам и ручками добавлять кавычки и «load» теги, становится как-то дурно и хочется воспользоваться вариантом «Забить!», что я и сделал. Но дабы упростить себе жизнь я написал небольшой скрипт, который делает это автоматически.

Работает очень просто:
1. Ставим пакет.
2. Заходим в папку с django проектом.
3. Для начала запускаем скрипт с ключом «--dry-run»: django-make-future-url.py --dry-run.
4. Внимательно смотрим что на что заменяется.
5. Обновляем файлы по-настоящему: django-make-future-url.py.

Теперь во всех *.html, *.txt файлах правильные «url» теги.

9 мая 2012 г.

Киевомайский Яндексосубботник



Наш специальный корреспондент Роман (то есть я), заблаговременно отправив заявку на участие в ежегодном майском Яндекс.Суботнике, оказался в числе приглашённых на эту замечательную конференцию для веб-технологов. Судя по уровню проведения - совсем недалеко от нашумевшей в прошлом году московской YaC (там я тоже имел честь побывать).

6 мая 2012 г.

Чтиво на майские праздники

Django

Отец-основатель Django рассказывает о подводных камнях перевода крупного опенсорс-проекта с SVN на git и гитхаб. Будем надеяться, что у разработчиков получится поженить их развесистый workflow на Trac и гитхабовские пуллреквесты.

Батарейка недели: django-htmlmin. Полагаем, все пользуются gzip-сжатием, отдавая свои странички через nginx. Чтобы ещё сэкономить ещё больше трафика, предлагается использовать middleware, которая автоматически будет удалять лишние пробелы и комментарии в HTML.

Джанго в продакшене, серия из 3-х статей, которая раскрывает самую недостаточно освещенную, но достаточно важную тему: как же всё-таки деплоить эти джанго-проекты.

Webdev

Замечательный сервис Travis CI, бесплатно предоставляющий услуги continuous integration для опенсорсных проектов на куче языков, запустил в бета-режиме новую киллер-фичу. Теперь они умеют тестировать пулл-реквесты на гитхабе, это очень круто.

Кстати, товарищ Дэвид Крамер из Disq.us поделился своими best practices по использованию Travic CI и Python (и Django).

Конференции

На этой неделе в Киеве прошёл Яндекс.Субботник, собравший полный зал участников. Впечатлениями по ходу дела в твитере делился наш Рома Семирук. Кто не успел поучаствовать или посмотреть прямой эфир ждут видеозаписей, а слайды уже доступны. Немного фоток (фейсбук).

В следующий четверг, сразу после праздников, пройдёт Moscow Django Meetup №3. Мы с нетерпением ждём и обязательно примем участие. Записывайтесь и приходите, обещают клёвые доклады и хорошие условия. Не забывайте про группу на фейсбуке.

В июне 9 числа в Москве пройдёт ежегодная конференция DevConf, которая соберёт вебразработчиков всех мастей: php, js, python, ruby, perl и даже asp.net. Печально, но докладов в python-секции кот наплакал.

Clientside


Всем хороших праздников!

4 мая 2012 г.

GeoIP и Django #2

Мы зарелизили django-geoip две недели назад и опубликовали эту заметку в блоге Джанго на Хабре.

Вебразработчики частенько сталкиваются с классической задачей определения местоположения пользователя по его IP-адресу. Существует множество различных решений, например на основе мировой базы Maxmind Geolite или российской IpgeoBase. Все они обладают достаточно низкуровневыми API, ну оно и понятно: на входе айпишник, на выходе страна, либо город и, если повезёт, ещё какая-нибудь полезная информация.

У всех сайтов с GeoIP, которые мы запускали, есть общая черта: они не только нуждаются в простой геолокации, необходимо также выводить различный контент на сайте в зависимости от месторасположения пользователя. Чтобы упростить для себя эту задачу мы написали небольшую батарейку django-geoip, вдохновившись приложением django-ipgeobase.

Django-geoip

Основное достоинство приложения: оно умеет автоматически определять географию пользователя и передавать её в объект request. Теперь контент на сайте, обладающий «региональностью», легко отфильтровать во views.py по значению request.location.

Фичи

  • pip install django-geoip и ещё несколько простых шагов для установки;
  • подробная документация на ReadTheDocs;
  • покрытие тестами;
  • обновление базы management-командой;
  • понятный API для создания «своей» модели географии в дополнение к существующим;
  • пользователь может поменять свой регион с помощью вьюхи;
  • интеграция с django-hosts.

Особенности реализации

Приложение django-geoip поддерживает иерархию географии Страна — Область — Город, которая хранится в нормализованном виде в СУБД. Данные по диапазонам IP-адресов со связями ко всем элементам географии — в четвёртой таблице. Текущая версия работает только с данными ipgeobase.ru, это почти тысяча городов России и Украины и 150 тысяч IP-диапазонов.

Одной из причин хранения данных в БД является потребность в создании своей модели географии, отвечающей задачам бизнес-логики. Например, в одном из проектов мы ограничиваем определение локации пользователя областями России, в другом — набором городов, в которых присутствует компания. Эта модель реализует паттерн «фасада» к иерархии географии ipgeobase, позволяя гибко настроить геолокацию под себя.

Представим, что наш сайт имеет несколько региональных «версий», каждая из которых может содержать свой контент. При этом регион может иметь произвольное имя и, к примеру, содержать несколько областей РФ (таблица geo_location на схеме):


Вот пример того, как это настраивается и работает. Определим свою модель географии MyCustomLocation:
# geo/models.py
class MyCustomLocation(GeoLocationFacade):
    name = models.CharField(max_length=100)
    region = models.OneToOneField(Region, related_name='my_custom_location')
    is_default = models.BooleanField(default=False)

    @classmethod
    def get_by_ip_range(cls, ip_range):
        """ Получаем модель географии по IP-дапазону.
            В данном примере диапазон связан с регионом, тот, в свою очередь,  
      связан с нашей кастомной моделью географии
        """
        return ip_range.region.geo_location

    @classmethod
    def get_default_location(cls):
     """ Локация по-умолчанию, на случай, 
         если не смогли определить местоположение по IP"""
        return cls.objects.get(is_default=True)

    @classmethod
    def get_available_locations(cls):
        return cls.objects.all()

    class Meta:
    db_table = 'geo_location'

Это обычная джанго-модель, дополненная тремя классметодами, реализующие “интерфейс” фасада GeoIP. Назначение каждой функции понятно из названия и докстринга. Осталось заполнить базу названиями городов и привязать их к моделям djagno-geoip.

Прописываем в settings.py:
GEOIP_LOCATION_MODEL = 'geo.models.MyCustomLocation'
Добавляем middleware для автоматического определения региона:
MIDDLEWARE_CLASSES = (...
    'django_geoip.middleware.LocationMiddleware',
    ...
)
И вуаля: request.location теперь содержит значение нашей модели MyCustomLocation для каждого пользователя.
def my_view(request):
    """ Passing location into template """
    ...
    context['location'] = request.location
    ...

Если пользователь не оказался ни в одном из этих городов, ему будет присвоен регион по-умолчанию (get_default_location).

Данный подход сильно облегчает задачу создания «региональных» сайтов, отличающихся друг от друга содержимым в зависимости от месторасположения пользователя.

Что дальше

Приложение хотя и альфа, неплохо работает у нас в продакшене (версия 0.2.2). Статус альфа намекает, что в будущем API будет меняться. Мы планируем поддерживать и развивать его дальше, в том числе реализовать определение региона не только для России, но и для остального мира. Также показалось интересной идея оптимизации поиска подходящего IP-диапазона по базе а также отделение механизма геолокации от кастомной модели (например, если определение страны происходит с помощью стороннего софта).

Исходные коды доступны на гитхабе, жду ваших комментариев.

3 мая 2012 г.

Testing with mock (Michael Foord)

Майкл Форд - опытный python-разработчик, автор книжки про IronPython, мейнтейнер unittest в третьей ветке питона (и unittest2, соответственно). Кроме того, он отличился, написав замечательную библиотеку создания mock-объектов для тестирования с одноименным названием, о которой и пойдёт речь в рекомендуемом видео. Mock позволяет заменять определённые части вашей программы на так называеме «объекты-пустышки» в целях тестирования.

Видео (33:22)


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

Видео с PyCon 2011, но оно по-прежнему актуально. С этого времени успела выйти версия 0.8 и даже 1.0alpha, было принято решение включить mock в стандартную библиотеку python 3.3 в пространстве имён unittest.

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

A Gentle Introduction to Mock for Python (13:06)
Why Use Mock? (03:28)
Mock and Django (38:24)

На первый взгляд не менее интересные, чем исходное видео.

P.S. Если не любите английский - есть неплохая статья на хабре с обзором возможностей mock.

2 мая 2012 г.

Третья московская встреча Django разработчиков 10 мая

3-й Московский Django Meetup
В московском центре дизайна «MOD Design»
Малый Конюшковский переулок, дом 2 (м. Баррикадная)
10 мая 2012, 19:00

Через неделю в Москве пройдёт очередная встреча людей, которым небезынтересен Django и Python.

Темы докладов 

  • Разработка расширяемых приложений с плагинами (20 мин)
  • Продвинутые инструменты для работы со статикой в Django (20 мин)
  • Class-Based Views (20 мин)
  • Django на Android (10 мин)
  • Производительность Django (10 мин)

Почему стоит сходить

Наши отчёты о первой и второй встречах Moscow Django Meetup. Почитайте, чтобы иметь представление о том, что это такое, если не были на предыдущих митапах. В этот раз организаторы постарались учесть недостатки предыдущей встречи и обещали удобную аудиторию, экран для презентаций в человеческий рост, микрофон и колонки.

Future Colors тоже там будет, подходите в перерывах - пообщаемся.