понедельник, 31 января 2011 г.

CSS фреймворк. Что это, и кому оно нужно.

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

Что же с CSS?
Кросс-браузерность в CSS также наболевшая задача для многих верстальщиков. Но, насколько мне известно, каждый опытный верстальщик имеет свой набор правил верстки, что помагает ему практически безошибочно делать кроссбраузерный код, тем более для современных браузеров, где анализ CSS-стилей не так уж сильно отличается, как было, например 2-3 года назад. Рассмотрим CSS фреймворк на примере blueprint CSS. Есть и множество других фреймворков, которые решают подобные задачи, но я остановился на этом.

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

Мои впечатления
Имея некоторый опыт верстки до фреймворка, с использованием фреймворка все получается действительно быстрее. Если оценивать себя, то могу сказать, что создал довольно неординарную верстку страницы (в т.ч. для IE6).

Плюсы:
  • Быстрота верстки и создания базового html-кода
  • Легкость внесения изменений в верстку
  • Вся вестка div-контейнерами
  • html-код получается чистый и короткий (это очень важно как с точки зрения разработки, поддержки, так и SEO)
  • Наложение стилей работает "иерархически", то есть никаких проблем с встраиванием контейнеров в контейнеры
Минусы:
  • В связи с тем, что применяются классы с "несемантическими" именами, более того, к одному и тому же контейнеру может применятся от одного до трех классов из фреймворка, код выглядит немножко "странновато" (но всегда можно добавить какой-нибудь класс-маркер, чтобы не забыть, для чего создавался тот или иной контейнер)
  • 15 кб базового CSS (в некоторых случаях этого может быть многовато)
Кому это нужно
Со всего вышесказанного, сделаю небольшое резюме. Я бы рекомендовал использовать CSS-фреймворки следующим категориям верстальщиков:
  1. Неопытные верстальщики, которые только начинают свой трудных боевой путь. Такой подход позволяет быстро решать задачи верстки и не срывать сроки по проекту.
  2. Программисты, которые делают свой проект/стартап (коим я и являюсь), но пока не имеют средств для того, чтобы нанять опытного верстальщика.
  3. Студенты, которым нужно сдавать зачет по предмету <предмет>, а препод поставит зачет, если ему сверстать красивую html-страничку для сайта кафедры/факультета/... , но ни предмета ни верстки студенты делать не умеют, а в армию не хочется.
Всем удачной верстки.

четверг, 27 января 2011 г.

Как перейти c PHP на Python


Вступление
На форуме python.su, в жизни которого я активно участвую начали появляться темы о том, как перейти с php на python. Естественно, здесь я буду рассматривать только веб-разработку.
В этой статье я бы хотел рязъяснить некоторые моменты, чтобы php разработчикам, которые все-таки решили начинать разрабатывать веб-приложения на python было понятно, что да как.

Как работает php?
Для начала, примем во внимание, что PHP изначально задумывался и разрабатывался исключительно как язык для веб-разработки, и в 99.9% случаев для этого и используется (можно, конечно, писать и GUI-приложения, например, для этого есть GTK-биндинги).

Говоря о том, как работает PHP? я имею в виду то, как принято в большинстве случаев разрабfтывать веб-приложения на PHP. Я не буду углублятся в устройство интерпретатора, расширения, MINT, и т.д. Для пущей простоты примем интерпретатор PHP за некую отдельную сущность. В общем случае, все происходит примерно так:
То есть в самом простом случае, мы создаем html страницу, внутри которой находятся блоки PHP-кода, обрабатывающие запрос и генерирующие динамическое содержимое страницы. Первое, что PHP-программисты при переходе на python обычно делают (по крайней мере те, которые пользуются веб-сервером Apache):
  1. Ставят на Apache mod_python.
  2. Конфигурят директорию в httpd.conf.
  3. Добавляют туда скрипт с содержимым: print "Hello, world!".
  4. Запускают браузер и указывают URL якобы скрипта, например: "localhost/hello.py".
Такое - не работает.

Так что же насчет Python?
Опять же таки вернемся к истории. Исторически и практически Python является языком общего назначения, то есть не нацелен на какую-либо узкую область решения задач. Поэтому он не обладает встроенными средствами работы в веб-среде, как, например, работа с http-сессиями (в отличие от php). Поэтому вариант "создать страничку -> добавить блоки python-кода внутрь" не проканает.

Как разрабатываются веб-приложения на Python?

В отличии от PHP в Python нет стандартных механизмов работы с веб окружением (куки, сессия, и т.д.). Каждый фреймворк и подход имеют свои библиотеки для работы с этими вещами.

Вариант 1. Почти как в PHP. Называется это Python server pages - проект умер в зародыше, а кто так пишет подвергается в Python-сообществе остракизму. Возможен благодаря mod_python. Более детально можно почитать здесь.

Вариант 2. WSGI (web server gateway interface). Являет собой стандарт взаимодейтсвия веб-сервера и веб-приложения Python. В качестве веб-сервера можно использовать Apache с mod_wsgi, nginx с uWsgi, CherryPy и другие. На базе этого стандарта работают многие фреймворки для веб-разработки, в том числе и популярнейший из них - Django. В общем случае, для того, чтобы разрабатывать веб приложения, вам нужно обратится к документации к одному из этих фреймворков. Вот несколько из них:
Вариант 3. Неблокирующий веб-сервер и фреймворк к нему, которые написаны на Python. Имеют свои специфические API. Примеры:
  • Tornado
  • Zope3
  • Twisted (это скорее средство построения фреймворков и серверов)
Данные фреймворки написаны в стиле событийно-ориентированного программирования.

От себя
От себя порекомендую для начала разработки веб-приложений на Python обратится к одному из простых фреймворков, так называемых, микрофреймворков, например, Flask.

Полезные ссылки

четверг, 20 января 2011 г.

Python xrange и OverflowError

sic! Данная проблема присуща Python версии 2.х. Счастливым обладателям интерпретатора Python версии 3.х можно дальше не читать.

Простой пример
Представьте себе, бывает и такое. Осталось выяснить, почему. Давайте взглянем на пример кода, который приводит к такой ошибке. Пример довольно простой:
for i in xrange(100000000000):
print i
Приводит этот пример к следующей ошибке:
OverflowError: long int too large to convert to int

Поэкспериментируем
Ладно, не хочет Python так, - попробуем совершенно дурацкую мысль - заменить xrange на range:
for i in range(100000000000):
В результате получаем еще одну интересную (как и стоило ожидать) ошибку:
OverflowError: range() result has too many items
Не хочет, хороняка, он создавать такой длинный список. Исходя из вышеизреченных интерпретатором ошибок, мы узнаем несколько интересных (для кого-то, может и неинтересных) фактов о Python:
  1. Максимальная длина списка в Python = sys.maxint, то бишь - 2147483647.
  2. xrange для создания итератора принимает числа <= sys.maxint.
  3. Если вы подумали, что сможете создать список длиной sys.maxint, - вы ошиблись =). Я, например, получил еще одну забавную и очень лаконичную ошибку:
MemoryError
Ну не влезает он в память, хоть ты тресни.

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

Очевидное решение
Ну, решение действительно очевидное: обратимся к старому доброму циклу while, при этот получив нужный результат (стоит заметить, работающий гораздо медленнее, нежели xrange):
number = sys.maxint + 10000
while number > 0:
number -= 1
При этом интерпретатор долго будет думать, но, хотя бы, получили рабочий код.

среда, 19 января 2011 г.

Встроенный Django сервер тормозит на Windows 7


Столкнулся с такой вот проблемой, что встроенный сервер Django очень долго обрабатывает запросы в операционной системе Windows 7. Ситуация примерно такая. Запускаем сервер:
python ./manage.py runserver 127.0.0.1:3333
Заходим на сайт:
http://localhost:3333/
После этого получаем контент только после долгой задержки, что не очень приятно в процессе активной разработки или тестирования сайта. Оказывается, проблема возникает из-за, кто бы подумал, IPv6, так как понятие localhost в контексте наличия разных протоколов уже не такое однозначное. Поэтому делаем 2 шага:

1. Раскомментируем строчки (у кого они не раскомментированы в C:/Windows/System32/drivers/etc/hosts)
127.0.0.1 localhost
#::1 localhost
2. Заходим на сайт не через localhost, а по 127.0.0.1.

Удачного джангирования!

вторник, 4 января 2011 г.

Статика и девелоперский сервер на большом Django-проекте


Что есть девелоперский сервер?
Хотел бы поделиться одним своим наблюдением насчет работы со статикой сервера django, который из коробки, и, собственно, не рекомендуемый для использования в production-среде. Для простоты использования статических файлов, то бишь всяких там стилей, картинок и клиентских скриптов, разработчики django-фреймворка втулили некое представление:
django.views.static.serve
Наверное большиство django-программистов используют эту вещь в работе, как и девелоперский сервер:
python ./manage.py runserver :
Более того, по статистике djangosites 1.2% пользователей не заморачиваются со всякими там инжиниксами, и апачами, и публикуют свои приложение таким вот нехитрым способом.

Проблемка
При этом всем, наверное, немногие сталкивались с тем, даже в довольно крупных проектах, что девелоперский сервер зависает на каждом втором-третьем запросе, что не просто раздражает, а делает разработку практически невозможной. С одной из причин такого зависания я недавно столкнулся. А дело было в статических ресурсах, которые должны были отдаваться клиенту, но по объективным причинам не отдавалий, то есть на каждый запрос по требованию картинки, скрипта, и т.д. приходил ответ 404. Так вот, если таких ресурсов накопится 20-30, сервер виснет уже на 2-3 запросе.

Вместо заключения
Причина этого кроется в том, что над такими проблемами с сервером никто не заморачивается, так как для работы в production-среде он не предназначен, и уж тем более для обслуживания статики.
В этом гаджете обнаружена ошибка