Посты с тэгом web development


Как быстро поднять простой HTTP-сервер

Скорее заметка для себя. Постоянно забываю об этом ключе.

Иногда нужно очень быстро поднять HTTP-сервер с минимальным функционалом. Например, нужно проверить HTML+JavaScript, который работает только через веб-сервер. Я, конечно понимаю, что у меня под рукой всегда есть, как минимум nginx, и поднять на нем сайт, который будет раздавать статические фалы, делов на 5-10 минут. Но, во-первых, это долго, а во-вторых, этот самый nginx у меня находится на виртуалке, пусть и включенной в 90% времени на ноутбуке. А тут прийдется не только веб-сервер настроить, но и расшаренные папки в VirtualBox-е, и так далее...

Единственное, что у меня действительно всегда есть под рукой, это Python (уже несколько лет не пользуюсь ОС Windows, а на всех *nix он есть из коробки). Поднять простой тестовый веб-сервер на питоне можно всего одной командой:

$ python -m SimpleHTTPServer 8100

После этой команды, у вас локаль



Django 1.5 Release Candidate

4 января вышел релиз кандидат fullstack-фрейморка для разработки веб-приложения Django. Обзоры, наверено, не писали/читали только ленивые. Но пишут, в основном, про мажорные фичи, из-за которых и выпускают релиз. Я перевел свой небольшой прототипчик одного приложения на Django 1.5 RC и поюзал некоторые минорные нововведения, о которых пишут мало, но которые почти делают каждый релиз тем, из-за чего часто хочется использовать именно его. Из того, что мне понравилось - это:

  • изменения в template engine: теперь True, False, None воспринимаются так же, как и в python;
  • дополнительные батарейки для работы с временными зонами - мелочь, а очень приятно;
  • исправленна ошибка OutOfMemory при использовании команды dumpdata - особенно полезно на небольших хостингах;
  • mod_wsgi auth handler - для тех, кто все еще использует Apache и Basic авторизацию;
  • в debug конфигурации приложения логи дополнительно выводятся в консоль;
  • user_login_failed


Отключение кеширования статических файлов в Tornado

 

Статические файлы (картинки, скрипты, css), как правило кешируются для более быстрой работы сайтов (уменьшение трафика - это уже скорее побочное явление). И в этом, казалось бы, нет ничего плохого. За исколючением одного - когда это самое кеширование мешает разработке. В моем случае используется стандартная связка nginx для статики + Tornado для всего остального. Но так как создавать вторую версию конфигурации nginx’а с отключенным кешированием мне не хотелось, да и в процессе разработке во многих случаях можно обойтить самим лишь Tornado, то я решил отключить кеширование в Tornado.

За отдачу статических файлов в Tornado отвечает StaticFileHandler. То логичным было предположить что кеширование отключается где-то в его настройках. Но единственное что там можно сделать, это переопределить метод get_cache_time, который и так во всех случаях возвращает 0. Исключение составляет л



Мобильные сайты на Django

Как правило, адаптация сайтов под мобильные устройства заключается в выполнении одного или нескольких пунктов из следующего списка:

  • подключения специальной версии CSS;
  • подключения нужных JavaScript’ов;
  • создание мобильных шаблонов (templates) с версткой (html).

Сразу оговорюсь, что вопрос мобильной верстки сейчас затрагивать не буду.

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

{% if request.mobile %}
    Mobile
{% else %}
    Not mobile
{% endif %}

 

Или же наша view поменяет вид на такой:

def index(request):
    if not request.mobile:
        return render_to_response('index.html’)
    else:
        return render_to_response('mobile_index.html’)

Теперь дел



Django и jQuery Template

 

По отдельность Django и плагин jQuery Template у меня работали хорошо. А вот вместе возникли небольшие проблемы. Вот только не знаю: это все из-за моей невнимательности или данная фича/бага плагина тоже сыграла свою роль.

Вначале просто  data binding работал отлично и никаких проблем не предиделось. Но стоило только появиться необходимости использовать тег {{if}} из jQuery Template, встретились первые неожиданности.

Неожиданность номер раз:

Не совсем, конечно, неожиданность, а, скорее, первая меленькая проблемка. Конструкция “{{“ - совпадает с синтаксисом шаблонов в Django, от чего мы получаем ошибку что у нас неправильный темплейт. Пришлось открыть доки django и найти там что такое template tag и как им пользоваться.

В итоге мой шаблон стал выглядеть, примерно, таким образ



Когда нужно использовать Django

Выбор веб-фреймворка не в .NET стеке для нового проекта достаточно нетривиальная задача. Их много - больших, маленьких, хороших и не очень, горячих и зелёных. Так как при работе с Python больше сталкивался с Django, то для себя, т.е. очень IMHO, сделал несколько правил.

Использовать Django нужно когда: 

  • нужно получить опыт с Django;
  • нужно сделать быстро сайт с админской частью (блог, CMS и т.д.);
  • есть хорошее готовое приложение/модуль для Django и его нужно сомсем немного доточить напильником;
  • нет необходимости заморачиватья с DAL (data access layer) и стандартного ORM вполне достаточно;
  • какие-то из модулей Django уж ооочень хорошо подходят для текущей задачи;
  • нужно сделать что-то очень быстро и нет опыта с другими фреймворками.
Итого получилось 6 пунктов. Если не выполняют


Dev Time #4 - Python

Среда, 13 апреля этого года должна была пройти так же, как и остальные среды, но не тут-то было. В этот день состоится очередная встреча харьковского сообщества разработчиков Dev Time (мой отчет с первой встречи: http://blog.e0ne.info/post/First-Kharkov-DevTime-event-summary.aspx). 

Особенностью этой встречи будет то, что это первое подобное события на моей памяти в Харькове, посвященное языку программирования Python. О Python будет говорить Настя Хоменко aka @Eva__Brown с докладом "Python Tips" (детали уточняются). Вторым докладчиком буду я. И поговорю я о Google App Engine и web фреймворке tipfy

Примерное содержание моего доклада:

  • Goole App Engine (GAE) и Python
  • Почему не Django?
  • Преимущества и недостатки фр