Блог студии Future Colors

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

noreply@blogger.com (Илья Барышев) — Sat, 26 May 2012 18:01:00 +0000

Сегодня вас ждёт небольшой спецвыпуск про 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.

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

High Performance Python (Ian Ozsvald)

noreply@blogger.com (Роман Семирук) — Thu, 24 May 2012 19:51:00 +0000

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

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

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

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

noreply@blogger.com (Future Colors) — Sat, 19 May 2012 09:48:00 +0000

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 мая

noreply@blogger.com (Future Colors) — Sun, 13 May 2012 06:10:00 +0000

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.
Мы выложили свой отчёт о киевском Яндекс.Субботнике.
Девконф начал голосование за доклады.

Moscow Django Meetup #3

noreply@blogger.com (Future Colors) — Sat, 12 May 2012 11:40:00 +0000

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

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

Доклады

Александр Емелин из Mail.ru Group доступно рассказал про Class-based generic views. Тем кто до сих пор не пользуется вьюхами на классах, рекомендуем обратить на них внимание, порой они экономят очень много boilerplate-кода. Тем же, кто активно их применяет, неплохая ссылочка по рекомендации Александра: Classy CBV - замена официальной путаной и неудобной документации по видам на классах. Доставило обсуждение CBV vs functional views, когда уместно использовать тот или иной вариант и почему.

Владимир Филонов из WebCanFly поведал про расширяемые приложения. На примере небольшой части интернет-магазина рассмотрели различные варианты реализации API для подключения плагинов к django-приложениям. Подробно, много кода, но всё понятно и логично выстроено. Хороший доклад, думаем, при разработке сложных систем со слабым связыванием компонентов всем придётся столкнуться с чем-либо подобным.

Михаил Юматов про статику в Django.
Доклад можно было смело назвать django-gears, поскольку речь шла в основном об этой амбициозной билиотеке, которую разрабатывают ребята из Trilan. Она призвана заменить django-compressor и webassets, обладает большей частью их функциональности, к тому же хранит зависимости прямо в css/js (по аналогии с sprockets). Пока приложение ещё не в продакшене, но от этого не менее интересно.

Иван Вирабян про производительность в Django.
По большей части речь шла об ORM. Иван объяснил, почему «db_index=True не творит чудеса», показал каким иногда непредсказуемым может быть генератор SQL, объяснил как нужно использовать «Defer()», а так же описал основные подходы к инвалидации кеша и оптимизации контекст процессоров в Django. Самое продвинутое выступление явно не для новичков, жаль, что всего лишь на 10 минут, такая тема достойна больших временных рамок. Обязательно посмотрите слайды, очень полезный и наиболее прикладной доклад.

Александр Шлемин про Django на Андроиде.
Докладчик наглядно показал, что Django это не только про Web и что его можно запускать в том числе на мобильных устройствах. Александр продемонстрировал нам это на примере мобильного телефона на базе Android. Доклад вызвал, наверное, самую бурную реакцию аудитории со смехом и овацией.

Для тех кто захочет попробовать свои силы и поставить Django на Android, Александр советует запускать manage.py runserver с ключом --noreload — это увеличит время жизни вашего аккумулятора :)
Используя силу root доступа к телефону и несколько батареек (к Django), мы получаем доступ к списку контактов или базам данных других приложений. А стандартная админка Django покажет все эти данные в приемлемом оформлении.
Взаимодействие с API телефона происходит через Python драйвер, таким образом мы можем вибрировать телефоном, писать смски, получать данные GPS и даже звонить!
В общем, для любителей «экстремального» программирования!

Заключение

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

В планах провести Django-спринт или Django-dash, в общем покодить совместно этим летом. Активисты и прочие желающие приглашаются в группу на фейсбуке, там сейчас идёт активное обсуждение.

P.S. Ждём следующего митапа через месяц. Там один из нас снова попробует свои силы за микрофоном у проектора с докладом.

Илья Барышев
Виталий Олевинский

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

noreply@blogger.com (Артём Голиков) — Fri, 11 May 2012 08:36:00 +0000

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

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

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

Нельзя допустить, чтобы название говорило о том, как элемент должен выглядеть, или какой тег ему соответствует. Много лучше, когда название объясняет, что это такое, каков смысл нахождения этого здесь. Про соответствие названия тегу вы, думаю, сами догадываетесь: ничто не вечно, и сегодня это <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, связанный только с ним, но также и куча других правил, раскиданных по проекту, а количество класов на тегах становится устрашающим. Ещё один минус - потеря семантики, так как эти примеси говорят скорее о внешнем виде, чем о сути, и, о ужас, в проекте могут появится теги, на которые повешены только лишь классы примесей, говорящие не о смысле, а о внешнем виде его. Эта тенденция похожа на деградацию до старых каскадов и глобальных стилей. Рефакторинг такой вёрстки затрудняется. Всё это говорит о том, что не стоит перебарщивать с вынесением общих стилей.

Плохо:

<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>

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

noreply@blogger.com (Виталий Олевинский) — Thu, 10 May 2012 12:06:00 +0000

Если вы тоже столкнулись с проблемой переноса старых проектов на 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» теги.

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

noreply@blogger.com (Роман Семирук) — Wed, 09 May 2012 16:58:00 +0000

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

Посудите сами: арендован конференц-зал в шикарном пятизвёздочном отеле "Опера", в центре Киева...

...4 кофе-брейка и лёгкий обед...

...11 докладов от сотрудников Яндекса, в основном про БЭМ/фронтенд; большое-пребольшое количество людей в зале, несколько большее, чем предполагали организаторы, поэтому многим пришлось слушать доклады стоя, у входа в зал. И это несмотря на то, что с отеля выжали все стулья :)

Открытие

Начинать конференцию с кофе и плюшек - это хорошая традиция, особенно когда действие начинается с самого утра и без кофе ну никак не проснуться. Стол регистрации начал свою работу точно по расписанию, в 9:30

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

Первая секция

Первые два доклада оказались практически развлекательного характера. Очаровательная Ольга Онойко поведала залу об асессорах Яндекса, благодаря чему я узнал, что существует такая профессия как "асессор" и что есть специально надрессированные люди, которые особым образом обучают нейронную сеть собственного поискового движка.

Было безумно интересно и вопросов осталось больше, чем ответов. Подпортили веру в человечество только вопросы из зала. У сеошников заблестели глаза от возможности приоткрыть завесу тайны алгоритма релевантности в Яндексе. Увы, недалёкие сеошники так и не поняли, что асессоры не имеют никакого отношения к порядку поисковой выдачи. Никто не может гарантировать именно порядок выдачи, можно лишь скорректировать решения нейронной сети, вручную, на базе целого набора критериев. Ольга неоднократно повторила это во время доклада и, тем не менее, десяток вопросов из зала был про или около сео. Ну дурынды, что с них взять?..

(человек на фото - представитель касты "вопрошающих", здесь только для иллюстрации)

А вот доклад "Дизайнер в поиске" от Анастасии Ларкиной, увы, ни о чём. Да, интересно наблюдать эволюцию дизайна специальных интерактивных сниппетов, будь то карта, или организация, или пробки, но совершенно никаких полезных знаний доклад в себе не несёт. Типа "вот так когда-то было, а вот так теперь стало + добавилась новая сущность!" Круто, круто, круто...

Сидим, слушаем дальше. Александр Зинчук, с повестью о новом API Яндекс.Карт, открыл череду технологических докладов, заодно немного оживив публику. Ничего такого, чего нельзя было бы узнать из документации, увы, не проскочило. Хотя узнать от первоисточника каковы были основные мотивы того или иного архитектурного решения и как происходит процесс разработки - безусловно бесценная информация.

Нам, кстати, пообещали, что в этом году будут англоязычные тайлы карт не только Турции, как сейчас, но и всего СНГ... хотя к Евро 2012 точно не успеют. Поэтому геосервисы для иностранцев на Яндекс.Картах лучше пока не делать.

Небольшой перерыв, пьём кофе, разминаемся.

Вторая секция

Переходим к следующему докладу "Используем git без проблем" от Сергея Сергеева, для "сомневающихся svn-щиков". Если вы уже используете git, то доклад можно не смотреть, ничего нового не узнаете. Несколько рекомендаций общего характера можно, конечно, вынести и здесь. Например, про использование cherry-pick только для тех веток, которые вы гарантированно не будете в будущем merge`ить с другими.

Известный факт, что у Яндекса много сложного клиент-сайда и наверняка существуют какие-то гайдлайны по написанию JS-кода, возможно какие-то внутренние стандарты... Так я думал, пока Дмитрий Щадей не выступил с докладом о jsLint. Это широко извеcтный JavaScript code quality tool, главная задача которого - автоматическое обнаружение анти-паттернов и различного рода вольностей, которые часто позволяют себе разработчики и которые ухудшают читабельность и усложняют отладку кода. Так вот оказалось, что jsLint и есть той самой "совестью" и широко применяется внутри Яндекса в качестве кнута для веб-технологов. Нет никаких описанный в вики стандартов - есть jsLint и его форк jsHint.

После чего сразу два человека, Евгений Батовский и Николай Птущук, выступили с докладом "Современный станок верстальщика". Много интересной инсайдерской информации, эволюция инструментов для мультибраузерного тестирования внутри Яндекса, от удалённых виртуалок до достаточно необычного решения на базе продуктов от Novell (виртуализация) и Microsoft (платформа). Это представляет из себя некий бандл-пакет, весом около 15 гигабайт, с Windows 7 в качестве базовой платформы и десятками установленных в ней актуальных версий браузеров (точную цифру, увы, не помню). Этот пакет особым образом конфигурируется и доступен любому верстальщику, его можно развернуть локально на своей рабочей машине, что позволяет вручную (!) проверять вёрстку в любой версии любого браузера: Firefox (более десятка версий), Chrome (несмотря на автообновления браузера, держат зоопарк из нескольких последних мажорных версий), Opera и IE 7/8/9. Сами инструменты разработки не стандартизированы, верстальщик в праве выбрать себе как платформу, так и редактор для повседневной работы. Обычно это Mac OS X или Windows, с редактором Sublime. Что характерно, в украинском офисе Яндекса, в Симферополе, все поголовно на "маках", в Москве же обратная ситуация - на маках единицы, обычно это Windows или Ubuntu.

Обед

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

Я же, перекусив, вышел на улицу продышаться и только тогда обратил внимание на фирменный автобус знаменитого футбольного клуба "Шахтёр", который стоял прямо напротив входа в отель.

Оказалось, что "горняки" тоже приехали на Субботник, но их никто не пустил :) Вообще богатые дяденьки и тётеньки, которым "посчастливилось" в тот день снять номер в "Опере" были, мягко говоря, недовольны происходящим. Надеюсь, администрации не сильно влетело. Один из докладчиков, Александр Зинчук, даже на рояле в холле сыграл, что как бы +1 к общей интеллигентности и мирности мероприятия :)

В общем хватит прохлаждаться, не ради халявной еды мы сюда пришли (хотя кто как).

Третья секция

Виталий Харисов - первый, нанятый в 2006-м году, сотрудник украинского офиса Яндекса в Симферополе. Сейчас он руководитель разработки в Украине и после обеденного перерыва, в рамках небольшого 15-минутного доклада, поведал несколько интересных фактов об особенностях украинского Яндекса. Оказывается, украинский Яндекс работает практически автономно и децентрализовано. Преимущественная платформа разработки - Mac (несколько человек использует Ubuntu). С Москвой происходит синхронизация по специальному, быстрому каналу. Чего я не услышал, или прослушал, - почему был выбран именно Симферополь в качестве стартовой площадки, а не, скажем, более подходящие для этого Харьков, Днепропетровск, Донецк, Киев? В целом, доклад каких-то особых откровений в себе не содержит, что, впрочем, не делает его неинтересным.

Александру Титула-Бойченко - отдельное спасибо. Благодаря его докладу "Приложения для соцсетей", я впервые осознал целесообразность применения bem-tools. Оказывается, это действительно может иметь смысл :)

Мне всегда казалось, что яндексовые фронтендщики - больные на всю голову шизоиды, которые хотят описать JSON`ом весь мир и которые серьёзно усложняют себе жизнь невнятным набором сборщиков, оптимизаторов и минификаторов. На самом же деле, всё кажется каким-то адом лишь на этапах описания задачи в терминах БЭМ и построении соответствующего БЭМ-дерева. Все дальнейшие модификации - это лишь правка модифицирующих JSON-файлов, и на примере создания простейшего приложения сразу для нескольких социальных сетей преимущество данного подхода стало очевидным. В общем, вместо моего пересказа, рекомендую дождаться видеозаписи и вдумчиво, без предрассудков, посмотреть её. Просветление гарантировано.

"bem server: система сборки фронтенда" - логическое продолжение предыдущего доклада. Сергей Белов терпеливо, несмотря на постоянную зевоту в зале, рассказывал о ядре bem-tools, о том как именно работает сборщик (он же отладочный веб-сервер). Это самый гиковский доклад из всех, без пол-литра, с наскока, никак не разобраться, и чтобы не сказать какую-нибудь ерунду - рекомендую интересующимся и сочувствующим дождаться видеозаписи доклада. Сергей постарался описать процессы доступным языком, были даже вопросы из зала, а значит кто-то что-то понял. Спорный момент - возможность применения инструмента вне Яндекса, по крайней мере в том виде, в котором нам показали.

Перерыв, кофебрейк, многие стали уходить по домам с морщинами глубокой мысли на лице, Бобук абстрагировался от происходящего в коридоре, а зал заметно поредел.

Четвёртая секция

Да, нельзя сказать, что БЭМ - доступная каждому тема, хотя Яндекс делает всё возможное, чтобы популяризировать методологию и оправдать применение bem-tools вокруг неё. Владимир Гриненко, на примере небезызвестной Фоторамы, показал как писать декларативный объектно-ориентированный JavaScript в БЭМ-терминах с помощью i-bem.js. Честно говоря - самый бестолковый инструмент из всего семейства bem-tools, как по мне. Это уже какой-то БЭМ ради БЭМ и велосипед всех велосипедов. Всё, что нам показали можно решить средствами обычного jQuery и Backbone.js. Думаю, что i-bem.js создан как раз для того, чтобы сделать bem-стек полным и самодостаточным, в этом его суть.

И, наконец, последний доклад для выживших, от Кира Белевича, о применении БЭМ в процессе создания сайтов под iOS/Android. В принципе, ничего нового нам не рассказали, весь процесс в деталях обрисовали два предыдущих докладчика. Модификаторы, БЭМ-дерево, сборщик - всё это мы уже видели и слышали. Сам же Кир, который наверняка хороший специалист, совершенно никудышний докладчик: нудно, вяло, неинтересно.

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

Fin

Видно, что Яндекс уже собаку съел на организации подобных мероприятий. Всё чётко, продумано, без технических заминок. 2 камеры снимали действие на видео,

фотограф наверняка отщёлкал немало клёвых фотографий (ждём, ждём),

работало 3 проектора, чтобы презентацию было видно из любой точки зала, девочки с микрофонами бегали по залу во время "вопросов из зала",

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

Будем надеяться, что подобные Субботники будут проходить в Киеве чаще одного раза в год. Да и Москва тут недалеко, ждём YaC 2012! :)

Официальные видео и фото появятся в течение недели-двух, об этом я сообщу дополнительно и дополню статью соответствующими ссылками.

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

noreply@blogger.com (Future Colors) — Sun, 06 May 2012 19:48:00 +0000

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

Пол Айриш делится хорошим набором приложений и инструментов для фронтенд-разработчика.

Вот ещё небольшой блиц:

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

GeoIP и Django #2

noreply@blogger.com (Илья Барышев) — Fri, 04 May 2012 17:12:00 +0000

Мы зарелизили 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-диапазона по базе а также отделение механизма геолокации от кастомной модели (например, если определение страны происходит с помощью стороннего софта).

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

Testing with mock (Michael Foord)

noreply@blogger.com (Илья Барышев) — Thu, 03 May 2012 11:02:00 +0000

Майкл Форд - опытный 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.

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

noreply@blogger.com (Илья Барышев) — Wed, 02 May 2012 14:36:00 +0000

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 тоже там будет, подходите в перерывах - пообщаемся.

Группа на facebook

Регистрация

Чтиво на выходные 29 апреля - 1 мая

noreply@blogger.com (Future Colors) — Sun, 29 Apr 2012 12:22:00 +0000

Python

Django теперь на гитхабе!

Сравнение дизайна аналогичных продуктов на python и ruby не в пользу первых. Dear Python, Why Are You So Ugly?

Галопом по европам, как Yandex использует Python и Django.

Client-side

Презентация Вячеслава Олиянчука на тему правил хорошего тона в CSS. Причеши свой CSS, наконец!

Неплохое flash/html5 приложение для мультизагрузки файлов и Django app к нему.

Как заставить динамический сайт работать по БЭМ.

Интервью с javascript-гуру Дагом Крокфордом.

Работаем с навигацией каретки в RIA. Надеюсь, до такого низкого уровня вам не суждено опуститься, но если вдруг захочется хардкора, то вперд.

Подборка движков javascript-шаблонизации.

Разное

РИФ + КИБ. Выложены видео-материалы конференции.

Гугло-диск или dejà vu?

6-ти дневная неделя под урчание котэ или шум дождя?

Ну, и напоследок, Opera TV browser.

fc.tape — js-библиотека для простой анимации спрайтов

noreply@blogger.com (Артём Голиков) — Sat, 28 Apr 2012 08:37:00 +0000

Пару недель назад нами была представлена javascript-библиотека fc.tape (пост на Хабре), которая предназначена для управления анимацией спрайтов (склеенных кадров).

Эта библиотека используется в наших проектах, например, в TNK Racing Team. Она предоставляет low-, medium- и high level API для управления анимацией.

Для использования fc.tape вам понадобятся jQuery (1.6+), jQuery UI (1.8+), компоненты Core и Widget. Создать спрайт из отдельных файлов изображений можно утилитой convert, входящей в пакет ImageMagick.

Вчера fc.tape была обновлена до версии 0.2 и вот список изменений:

появилась новая настройка loop для управления зацикливанием анимации;
для методов windTo, stepInTo и setPosition позиция, на которую нужно перейти, задаётся в форматах 15 или '30%' (параметра isRelative теперь нет);
настройка gradually переименована в smooth;
починена демонстрационная страница.

Посмотреть на работу виджета можно на demo-странице. Проект хостится на гитхабе, будем рады пуллреквестам и идеям по развитию.

Промо-сайт крутой бритвы от Panasonic

noreply@blogger.com (Артём Голиков) — Mon, 23 Apr 2012 09:22:00 +0000

В нашем портфолио появилась ещё одна работа — промо-сайт бритвы от Panasonic «5 лезвий». Концепция и дизайн, а также 3D-рендеры были созданы студией Nile.

В этом проекте перед нами стояла задача разработать сайт, основным элементом которого является крутящаяся бритва. Её анимацию нужно было реализовать без использования Flash. Результат можно посмотреть на http://5blades.panasonic.ru/.

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

В этом проекте был использован backbone.js, что позволило сделать javascript-код модульным.

Чтиво на выходные 21-22 апреля

noreply@blogger.com (Future Colors) — Sat, 21 Apr 2012 10:56:00 +0000

Python

Андрей Светлов рассказал о том, что реализация импорта в Python 3.3 переписана на чистый Питон и что в этом хорошего.

Опубликованы расписания EuroPython 2012 и DjangoCon Europe 2012.

Добрый самаритянин Michael Feoktistov сделал торрент-раздачу всех видео с последнего PyCon US. Несмотря на то, что они все есть на YouTube, вероятно кому-то будет полезно просто выкачать их в разрешении 480p.

Большая статья про интерпретаторы, виртуальные машины и скорость выполнения кода (англ.).

Webdev

Чудесный наброс «PHP: a fractal of bad design» на тему почему PHP — унылое говно. Кому больше нравится на русском, есть перевод на Хабре. Мы, кстати, осознанно отказались от использования PHP в студии в конце 2010 года и полностью перешли на Python ;)

Яндекс запустил новую версию API Карт под номером 2.0. Быстрее, красивее, не нужны API-ключи, поддержка мобильной платформы, кластеризация из коробки. 26 апреля в четверг команда Карт устраивает APIшник, где расскажет про все новинки и можно будет пообщаться с разработчиками.

На базе LESS ребята из Twitter сделали RECESS — инструмент для проверки, сжатия и компиляции кода.

Концепт новой революционной IDE LightTable собирает деньги на Kickstarter.

Свежий доклад от Яндекса про масштабируемые javascript-приложения (к слову, 5-го мая в Киеве пройдёт Яндекс.Субботник, ещё не поздно зарегистрироваться)

Расставляем точки. В чём же разница между URI и URL?

Django in Depth (James Bennett)

noreply@blogger.com (Роман Семирук) — Thu, 19 Apr 2012 07:49:00 +0000

Продолжаем новый формат и повышаем планку. На этот я предлагаю вам потратить 3 часа своей жизни ради интереснейшего доклада с PyCon US 2012 - Django in Depth, это дополненная современными реалиями версия одноименного доклада с PyCon US 2010, от того же докладчика. Докладчика, к слову, зовут James Bennett, который помимо основной работы в Mozilla успевает быть контрибьютором и релиз-менеджером Django, да и вообще стоял у истоков его создания. Доклад, в целом, рассчитан на разработчиков с опытом, повествование построено снизу вверх, то есть с глубинных процессов внутри Django - на поверхность. И несмотря на свою длину, интересен до последней минуты.

Обязательно к просмотру всем, кого интересует какие механизмы работают внутри Django и почему. Ну и, конечно, советы от Django-гуру не повредят вашему мастерству :)

Видео (3 часа 5 минут)

По существу, в докладе освещены такие темы:

1. ORM

архитектура Django 1.4;
как работает Django ORM, вся цепочка от database backend до model;
менеджеры, кастомные QuerySet-классы;
корректная работа в несколькими БД (роутинг, шардинг);
трюки с переопределением методов модели .save() и .delete();
абстрактные и прокси- модели;
Q- и F- выражения.

2. Формы

кастомные виджеты/мультивиджеты;
валидаторы;
динамическое создание форм;
медиа-файлы.

3. Шаблоны

как работает загрузчик шаблонов;
low-level работы шаблонизатора;
темплейт-теги и их парсер;
что есть контекст на самом деле и как происходит рендеринг.

А также:

request/response;
URL resolution;
handlers;
views (в том числе любимые нами class-based);
middlewares;
админка (оговорены некоторые возможности кастомизации, что можно и что не стоит переопределять).

Ну и некоторые факты с доклада, для затравки:

"Oracle is weird" (Джеймс о базе данных, неоднократно упрекнул её в "магичности");
имплементация класса Query занимает 1900 строк кода, это один из самых сложных и загадочных (here be dragons) модулей во всём Django;
Query.__str__() возвращает скомпилированный SQL-запрос;
QuerySet.exists() намного эффективней обычной булевой проверки;
"Just don't use classmethods, use managers". Аргументы не до конца ясны, но смысл в том, что нужно описывать действия над моделью на уровне менеджера модели. Видимо потому, что менеджер имеет больше отношения к объекту типа queryset, чем classmethod и концептуально вписывается в архитектуру ORM (что тоже не аргумент, но поверим опытному дядьке). Обсуждение вопроса на 51-й минуте видео.

Чтиво на выходные 14-15 апреля

noreply@blogger.com (Future Colors) — Sat, 14 Apr 2012 08:06:00 +0000

Django, Python

Facebook купил Instagram за 1 млрд. $ и многие с удивлением узнали что сервис использует Django Framework. Вообще интересно почитать про архитектуру Инстаграма в их технологическом блоге. И, конечно, на Insight IT по-русски.

Вышли версии Python 2.6.8/2.7.3/3.1.5/3.2.3 c багфиксами, в том числе закрыли нашумевшую дырку с атакой на хэш-таблицу. Обратите внимение, что фикс по-умолчанию отключён.

На Хабре недавно появилась статья из двух частей о декораторах в Python. Таких было уже предостаточно, но эта, судя по всему, самая доходчивая. Всё, что вы хотели знать, но боялись спросить.

Несколько русскоязычных видео-уроков по новым фичам Django 1.4. Пока доступно 3 урока, автор обещает выкладывать новые раз в неделю, по использованию методов ORM prefetch_related, bulk_create и админки.

Зарелизился Pycharm 2.5

Javascript

Мы зарелизили небольшую jQuery-библиотеку fc.tape, с помощью которой мы анимируем спрайты: сайт гоночной команды ТНК, страница команды Future Colors. Пост на Хабре.

Раз, два, три, четыре, пять - на Nettuts Backbone опять.

Быстрый вводный курс в Underscore - библиотеки, которая расширяет возможности функционального программирования в JS (и которая, заодно, является вечным спутником Backbone).

И ещё раз про Backbone. Благодаря стараниям некоторых хабровчан, он, наконец, обзавёлся русскоязычной документацией. Будем надеяться, что это немного снизит порог вхождения в технологию для тех, кому английский даётся с трудом.

Webdev

Трюк с псевдоселектором :target. Позволяет динамически стилизировать блок, если его id и hash в адресной строке совпадают.

Небольшой How To по работе с HTML5 File System API.

БЭМ продолжает покорять сердца и обзаводится своими фан-клубами. Один из них разработал толковый и доступный каждому сайт с описанием самой методологии.

Познавательная презентация об адаптивном веб-дизайне от Mail.ru. Недавний редизайн главной страницы сделал её адаптивной и им точно есть что сказать по этому поводу.

Дизайн

Создатели 5∞px.com сделали крутые страницы с Terms of Use их сервиса понятные для обычных людей, а не только с юридическим образованием.

Разное

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

Любопытное видео от Linux Software Foundation о том, как создаётся и где используется Linux в наши дни.

Testing and Django (Carl Meyer)

noreply@blogger.com (Илья Барышев) — Thu, 12 Apr 2012 10:01:00 +0000

В дополнение к субботней рубрике попробуем новый формат: рекомендации самых интересных выступлений с PyCon, DjangoCon и других конференций. Ребята будут советовать самые любопытные и полезные на их взгляд видео, которые точно стоит посмотреть.

Карл Майер (один из django core developers) делится своими соображениями о best practices тестирования django-приложений. Доклад рассчитан на опытную аудиторию, знакомую как с django, так и с основыми принципами тестирования.

Слайды
Видео (47:15)

Вот ключевые моменты доклада:

как правильно запускать тесты django или 14 секунд из жизни, которые не вернуть;
как правильно организовать обнаружение тестов (test discovery) и избавиться от беспомощных импортов в tests/__init.py;
почему надо выделять из сложных методов модели части, взаимодействующие с БД в отдельные методы;
зачем нужен factory_boy и почему нужно срочно выбросить фикстуры в помойку;
как лучше всего юнит-тестировать вьюхи;
чем WebTest лучше стандартного django.test.Client;
когда какие типы тестов использовать (юнит, интеграционные. с использованием селениума);
пара новых фич Django 1.4 в примерах (override_settings и in-browser testing);
тестируем примеры из документации;

Предлагаю обсудить презентацию в комментариях.

Moscow Django Meetup #2

noreply@blogger.com (Роман Семирук) — Sun, 08 Apr 2012 16:58:00 +0000

Предисловие

MoscowDjango #2 прошёл 5-го апреля, через 5 дней после KyivPy #6, на котором я также имел честь побывать. Тот факт, что с докладом выступит мой коллега Илья Барышев (@coagulant) лишний раз подогревал интерес к событию. И после рабочего дня мы всей командой поехали по указанному в анонсе адресу.

Критиковать может каждый и я, конечно, понимаю, что организовать встречу, найти докладчиков, договориться о помещении - это труд и спасибо организаторам за то, что они делают то, что делают. Столь бурный рост локального сообщества восхищает. К сожалению, у меня не получилось попасть на премьерный, первый MoscowDjango, но говорят, что на втором митапе людей было как минимум в два раза больше, чем на первом. Не менее 60 человек. Уже этот факт говорит о том, что московским питонистам-джанговодам интересно собираться для общения и обмена опытом, для полезных знакомств и просто приятной тусовки. Дай волю - собирались бы каждую неделю :)

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

Забегая чуть вперёд скажу, что докладчики не переключали слайды самостоятельно и вместо них это делал один из организаторов - Валентин Домбровский. Я лично не понял в чём профит, стоит или придумать что-то с пультом, или дать возможность подключать к проектору свой ноутбук и выступать за стойкой. Зато не забыли про вай-фай, вот за это отдельное спасибо.

(как бы следим за твит-лентой)

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

На заметку докладчикам - используйте крупные заголовки, гротескные шрифты и делайте слайды монохромными. Помимо того, что было плохо видно, некоторых докладчиков было неважно слышно. Микрофона в зале, увы, не оказалось. В итоге полностью в теме были только люди с первых рядов. Я надеюсь, что видеозапись, которая вот-вот должна появиться, и слайды позволят просмотреть всё ещё раз, с толком и расстановкой.

Первый доклад "Шаблоны проектов на основе PasteScript и Django 1.4" - это как раз тот случай, когда интересная тема доклада утонула в плохих слайдах и тихом голосе докладчика. Я не услышал и не увидел практически ничего. Если кто-то сидел ближе и всё слышал - отпишитесь, пожалуйста, в комментариях что вы вынесли с доклада.

Одного из докладчиков не оказалось на месте, поэтому произошёл сдвиг в программе митапа и для нашего Ильи освободилось время (а ты переживал), благодаря чему на доклад "Что нового в Django 1.4" было столько времени, сколько нужно. Сама тема была интересна, несмотря на то, что Django 1.4 мы используем ещё с ранней альфы. Оказалось, что я ничего не знаю про assignment-теги и про таймзоны. Теперь знаю :) Напомню, что приквелом этого доклада был недавний цикл статей о Django 1.4 в нашем блоге. Никогда не поздно почитать, если вы этого ещё не сделали.

Доклад "Django + SQLAlchemy" вызвал самую неоднозначную реакцию зала. Холиварная, сама по себе, тема подтолкнула зал к общению и процесс было уже не остановить.

Диалог между зрителями продолжался дольше и был местами интереснее самого доклада.

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

А последняя тема "Простой и удобный деплоймент проекта" получает приз как "самая нераскрытая тема митапа". Фактически весь доклад можно уместить в одно приложение: "есть fabric и git, с помощью которых можно и нужно деплоить проекты". Ни примера типового решения, ни best practices. Совсем начинающие не поймут проблемы, а тем, кто уже использует этот стек и эти решения было неинтересно слушать столь очевидные вещи. Но на некоторых лицах было заметно лёгкое удивление во время рассказа о Fabric, поэтому наверняка найдутся люди, которые вынесли для себя что-то и с этого доклада.

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

Интересно, что организацию 3-го митапа не откладывают в долгий ящик и вполне возможно, что он пройдёт в ближайший месяц-полтора. Также есть вероятность того, что небольшие спринты будут проходить ещё чаще. Сейчас в группе на Facebook проходит голосование "как часто стоит собираться". Это моё личное мнение, но если конференция будет проходить слишком часто, тогда событие перестанет быть ожидаемым, а на подготовку толковых докладов будет просто мало времени. Из зала поступило толковое предложение собираться почаще для совместного кодинга. Правда, было бы круто совмещать теорию с практикой, надеюсь организаторы придумают формат и для таких встреч.

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

В коридоре мы встретили наших друзей из Яндекса и проговорили с ними не менее часа.

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

Спасибо всем, кто пришёл. Благодаря вам митап состоялся. Спасибо докладчикам за то, что они создали повод прийти. И отдельное спасибо организаторам за то, то взяли на себя это бремя :)

До следующего MoscowDjango! Следите за активностью в группе на Facebook.

Резюме

Vitaliy Korobkin. Шаблоны проектов на основе PasteScript и Django 1.4: http://digitaldemiurge.ru/slides/templates

Илья Барышев Что нового в Django 1.4: http://www.slideshare.net/Coagulant/django-14

Андрей Попп. Django + SQLAlchemy: http://braintrace.ru/talks/djmeetup.html#slide1

Михаил Корнеев. Простой и удобный деплоймент проекта: http://www.slideshare.net/MoscowDjango/deploy

Бонусы

Ещё фотографии
Анкета-опросник

Чтиво на выходные 7-8 апреля

noreply@blogger.com (Future Colors) — Sat, 07 Apr 2012 17:07:00 +0000

Django

Якоб Каплан-Мосс делится своим видением, как может быть улучшен auth.User, скорее всего в Django 1.5 будет улучшена модель пользователя.

Батарейка tddspry, расширяющая возможности тестирования Django-проектов с помощью nose и twill. Представляет собой набор различных хелперов и тест-кейсов, и позволяет, например, осуществлять автоматический поиск тестов по всему проекту (не обязательно складывать их в папку test внутри приложения), использует twill вместо django.test.Client и умеет делать некоторые другие, не менее полезные в тестировании вещи.

Набор полезных Mixin’ов Braces для class-based views для Django 1.3+

Webdev

Legit - «Git с человеческим лицом», надстройка над git, добавляющая кучу полезных комманд, облегчающих ежедневную рутину. Например:

sync [<branch>]
Syncronizes the given branch. Defaults to current branch. Stash, Fetch, Auto-Merge/Rebase, Push, and Unstash. You can only sync published branches.

Правильное вычисление рейтинга продукта на основе данных пользовательского голосования. Может показаться странным, но индекс популярности != (количество положительных оценок) - (количество негативных оценок).

Javascript

Backbone patterns, как видно из названия, коллекция паттернов, рекоммендаций и соглашений по использованию Backbone.js.

Одним велосипедом меньше - гибкий и функциональный пагинатор для Backbone.js

Каждый четверг яндексоиды делятся своими наборами ссылочек про вёрстку, js и дизайн, не пропускайте.

Консоль для CofeeScript под Хром: CoffeeConsole

Администрирование

Очень толковый набор рецептов и best practices для Fabric, популярного инструмента автоматизации деплоя (и не только) ваших проектов.

Досуг

Fallout 1 раздают бесплатно в течении 48-ми часов, до 8 апреля 20:00 (по Москве) http://www.gog.com/en/gamecard/fallout

Что нового в Django 1.4

noreply@blogger.com (Илья Барышев) — Thu, 05 Apr 2012 20:43:00 +0000

Моя презентация с прошедшего 5 апреля Django Meetup #2.
Она подводит итог под серией Django Days, вот список всех постов:

Django days или обзор новинок Django 1.4

Воскресшая вёрстка

noreply@blogger.com (Артём Голиков) — Wed, 04 Apr 2012 15:47:00 +0000

Случалось ли вам поддерживать вёрстку, которая уже прошла этап оживления? Если да, то наверняка возникало желание посмотреть, какой она была первоначально, до оживления. Мы практикуем такой метод:

В комментарии к вёрстке блока, в css-файле, прописывается не только название блока, но и его разметка в формате ZenCoding. Если вам потребовалась разметка, просто скопируйте строчку и преобразуйте её в HTML (например, в PyCharm'е ZenCoding поддерживается из коробки).

/**
 * @section     Элемент списка
 * article.item.js-item>((header.item__header>((div.item__image>img)+(span.item__favorite>span.favorite)+(h1.item__title>a)+div.item__subtitle))+(div.item__expand>span.item__expand-icon.js-item__expand)+section.item__content.js-item__content)
 */

.item {...}
.item__header {...}
.item__image {...}
.item__favorite {...}
.item__title {...}
.item__subtitle {...}
.item__expand {...}
.item__expand-icon {...}
.item__content {...}

Вот так в данном примере будет выглядеть разметка:

<article class="item js-item">
    <header class="item__header">
        <div class="item__image"><img src="" alt=""></div>
        <span class="item__favorite"><span class="favorite"></span></span>
        <h1 class="item__title"><a href=""></a></h1>
        <div class="item__subtitle"></div>
    </header>
    <div class="item__expand">
        <span class="item__expand-icon js-item__expand"></span>
    </div>
    <section class="item__content js-item__content"></section>
</article>

Чтиво на выходные 31 марта - 1 апреля

noreply@blogger.com (Future Colors) — Sat, 31 Mar 2012 11:24:00 +0000

Python

Парочка холиворов с хабра: наброс Ruby vs Python и грамотный ответ. Что бы вы ни выбрали, вы останетесь в выигрыше.

Спорная, но интересная статья про стиль кодирования и классы в python. Видно, у автора своё понимание чистоты кода.

Замечательный модуль mock станет частью unittest, и будет доступен из коробки уже в python 3.3

Вышла бета Pycharm 2.5: управление пакетами, virtualenv, remote interpreters.

Веб-разработка

Забавная браузерная MMORGP от Mozilla на HTML5 (node.js, вебсокеты, require.js, modernizr, jquery, underscore)

Шпаргалка easing-функций для описания скорости анимации.

Новый, открытый под лицензией CC шрифт с набором широко используемых пиктограмм - Entypo

Единый GUI-клиент для различных СУБД (MySQL, Postgres, MongoDB) Induction.app (OS X only)

Django

Очередная коллекция скринкаcтов про Django - http://godjango.com. Пока обновляется, надеемся так и будет в дальнейшем.

Один из многочисленных “Django design patterns”, местами тривиальный, местами же довольно толковый. Здесь, кстати, нельзя не упомянуть знаменитый Django Advice. Обязателен к прочтению, если вы с ним ещё не сталкивались.

Делаем модную штуку с помощью модного стека. ScrumBoard на Django + Backbone.js + Tastypie. Это не туториал, а уже готовый проект на GitHub`е.

Любопытная батарейка django-bakery. Позволяет превратить динамический контентный сайт в набор статических HTML, дабы избежать хабраэффекта. Ограничение: Django 1.3+, надо использовать class-based views (всем рекомендуем, кстати).
Кстати, для flask давно уже есть Frozen-Flask для этих целей.

Облака

Дыра в безопасности Scalaxy. В течение недели из-за ошибки в API можно было выкачать список всех инстансов.

Профилактические работы у Селектела привели к почти 5-часовому даунтайму виртуальных машин в облаке. В конце дня появился подробный отчёт о проблеме.

Новинки Django 1.4, day 8: Timezones

noreply@blogger.com (Илья Барышев) — Tue, 27 Mar 2012 12:01:00 +0000

Посвящается часовым поясам без DST.

Это предпоследний пост в серии Django Days. В этот раз будет затронуто одно из самых масштабных изменений в фреймворке: работу с часовыми поясами. Документация по этой теме достаточно подробная, мы попробуем рассказать это более интересно и по возможности сжато.

Что это и зачем
В Django до версии 1.4 все даты хранились и отображались для одного часового пояса, того, который указанны в настройках settings.TIME_ZONE. Теперь же появилась возможность хранить все даты в формате UTC и удобно выводить их с поправкой на часовой пояс пользователя.

Дополнительным плюсом нового подхода к хранению дат является обход проблем с переводом часов на летнее время и обратно, которые могут возникать раз в год. Например, 31 октября 2010 года, когда последний раз переводили стрелки осенью в России, время 02:10 утра по местному времени нельзя однозначно интерпретировать (так как час с 2:00 до 3:00 «проходит» дважды: до и после перевода стрелок). Для биллинговых систем это мелочью не назовёшь, поэтому лучше для машин хранить время в UTC, а выводить для людей с учётом часового пояса. Упомянутые «02:10 31 октября 2010» превратятся в понятные программистам "2010-10-30T22:10:00+04:00" и "2010-10-30T23:10:00+03:00".

Основные понятия
Объекты типа datetime в Python поддерживают указание часовых поясов с помощью атрибута tzinfo. Если атрибут заполнен, дата называется «timezone-aware», в противном случае это «naive» дата.

В новых проектах на Django 1.4, или если вы пожелали воспользоваться новой фичей при обновлении, установив settings.USE_TZ=True, Джанго использует timezone-aware даты.

Часовым поясом по-умолчанию (default timezone) называется пояс, указанный в settings.TIME_ZONE (например, 'Europe/Moscow').
Текущим часовым поясом (current timezone) считается тот, что активирован для пользователя в данный момент, об этом ниже.

Текущий часовой пояс
Чтобы показать пользователю дату и время из его часового пояса, необходимо для начала выяснить откуда он. Можно напрямую спросить пользователя и сохранить timezone в сессии, а можно воспользоваться базами вроде maxmind, угадав пояс по ip, или даже использовать Date.getTimezoneOffset() в js. Так или иначе, на основе этого выбора нам придётся активировать часовой пояс пользователя, чтобы повлиять на отображение дат и времени в шаблонах и формах.

Пример установки текущего часового пояса в middleware (из документации):

from django.utils import timezone

class TimezoneMiddleware(object):
    def process_request(self, request):
        tz = request.session.get('django_timezone')
        if tz:
            timezone.activate(tz)

Необходимая функциональность для работы с датами сосредоточена в модуле django.utils.timezone.

Шаблоны
Работа с датами широко поддерживается не только в питон-коде, но и в шаблонах:

# В данном блоке даты будут сконвертированы в парижский часовой пояс
# (а не текущий)
{% timezone "Europe/Paris" %}
    Paris time: {{ value }}
{% endtimezone %}

# В данном блоке даты будут выведены как они хранятся (UTC)
{% localtime off %}
    {{ value }}
{% endlocaltime %}

Это лишь небольшая демонстрация, в документации более подробно.

Мигрируем
1. Включаем settings.USE_TZ = True

2. pip install pytz (чтобы точней работало, см. ниже)

3. Пользователи PostgreSQL пропускают шаг, остальные конвертируют свои даты в БД из местного часового пояса в UTC (если он отличается, конечно).

Теперь ваш код уже поддерживает часовые пояса. Осталось починить некоторые места, в которых Django исправляет старый код за нас, преобразовывая naive-даты в timezone-aware. В противном случае могут возникать ошибки во время перевода на летнее время.

Для полноценной миграции пригодится уже упомянутый модуль django.utils.timezone и отлов мест, где даты в старом формате сравниваются «новыми».

pytz
Это библиотека, позволяющая удобно работать с часовыми поясами в питоне. Она включает в себя базу таймзон Олсона и неплохой API для различных вычислений с часовыми поясами. Несмотря на то, что она необязательна для работы часовых поясов в Django 1.4, разработчики настоятельно рекомендуют установить её, так как это позволит фреймворку не угадывать часовой пояс по-умолчанию при вычислениях, а также предоставляет список доступных поясов для вывода пользователю.

Заключение
Данный обзор повторяет документацию, фокусируясь на ключевых для понимания вещах, но многое оставляет за кадром. Почитайте доки и особенно FAQ напоследок для закрепления
материала :)

В следующий раз я подведу итог по всей серии постов, ещё раз выделив самые интересные моменты Django 1.4. Вероятно до Moscow Django Meetup №2 в блоге также появится моя презентация на эту же тему.