Чтиво на выходные 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.

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

High Performance Python (Ian Ozsvald)

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

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

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

Чтиво на выходные 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 мая

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

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

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

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

Плохо: <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

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