А вот только что я наткнулся на Colubrid, который является обработчиком запросов для веба, который разбирает урлы, GET/POST запросы и т.д. Ну и, судя по документации и вообще сайту, порядочно inspired Джангой. Написан тем же автором, специально чтобы отказаться от Джанго. При этом предоставляет парочку очень интересных способов разбора адресов (хех, в том числе и routes).

Ну и напоследок статья о том, как написать сайт без фреймворка. Берётся набор инструментов и всё склёпывается в подобие фреймворка. :D Про этот самый Colubrid, Jinja, SQLAlchemy, markdown и FormEncode (хм, вот что это - я еще не знаю, надо посмотреть).

И из самого интересного - это то, как мы поступили с пользователями залогинившимися. Я раньше использовал только встроенный django’вый фреймворк sessions. Эта штука очень удобна, на самом деле даёт возможность вообще ни о чём не думать (как выразился… CTO? ну не важно, выразился - when you start using sessions, you can’t drop them. Прям наркотики ;)). Но у них есть один порядочный недостаток, над которым я раньше никогда не задумывался.

Закешировать можно, как понятно любому человеку в здравом уме и светлой памяти, только те страницы, у которых всё (абсолютно всё) передаётся в GET-запросе. То есть любые параметры, которые приходят из формы или берутся из базы по какой-то внутренней логике, которую нельзя привязать к GET’у, мешают кэшировать документ. Не дают кешировать его вообще. И это, понятное дело, очень сильно убивает производительность, т.н. scalability.

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

Чтобы избежать такой потери производительности (цифр у меня нету, но есть все заверения о том, что тесты были проделаны, от людей, которые запускали очень крупный сайт - собственно, от этого CTO и его друзей), применяется очень хитрая штука. Сайт разделяется не на две (анонимный/вошедший посетитель), а на три (анонимный/вошедший/изменяющий посетитель). Изменяющий - это условно, в том смысле, что он либо там пишет себе в блог, либо отсылает себе новый пароль, либо что-то ещё. И ставится любому залогинившемуся посетителю в куки не только его login_id, но и прочая не сильно важная информация (которую можно подсмотреть в профиле пользователя) - как то его имя, фамилия, возраст и прочее. И тогда странички и показывают персонализированное “Hello, dear John Smith”, и не делают запросов в базу (ну и кешируются).

Но когда пользователю приходит идея что-то изменить - тогда и делается проверка этого login_id. Но так как POST-форму и так нельзя никак закешировать, никаких потерь это нам не приносит. И волки целы, и овцы сыты.

The P2 quickly dominated racing and continued to be competitive over a period of six years. The Type 35 Bugatti also dates from 1924, but in virtually every instance where the Alfa and Bugatti raced together, the Alfa won.

Here.

http://kamaelia.sourceforge.net/Introduction

Думаю, если проапгрейдить комп интеловским процом, то можно вполне себе и поставить.

Еще как поддерживаю. Вообще нравится и ководство, и бизнес-линч очень-очень-очень. Хорошо люди работают. А дизайн people.net.ua… ну не знаю, может это я один не понимаю, нафига так всё раскидано.

А так - всё очень и очень.

А еще можно почитать о тарифах PEOPLEnet вот тут.

И вот тут начинается куча лишнего кода. Потому что каждый вызов rendertoresponse начинает выглядеть так:

return render_to_response('cool/template.html',
                          {'people': people, 'things': things},
                          context_instance=RequestContext(request))

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

from django.shortcuts import render_to_response
from django.template import RequestContext

def render_to(tmpl):
    def renderer(func):
        def wrapper(request, *args, **kw):
            output = func(request, *args, **kw)
            if not isinstance(output, dict):
                return output
            return render_to_response(tmpl, output,
                                      context_instance=RequestContext(request))
        return wrapper
    return renderer

Теперь отрисовывать всё можно с помощью декоратора:

@render_to('cool/template.html')
def view(request):
    return {'people': people, 'things': things}

Если функция вернёт словарь - render_to обернёт его в render_to_response и отпустит на волю, а если что-то другое (к примеру, HttpResponse - перенаправление какое-нибудь) - то просто отпустит на волю. :] Для меня это оказалось очень удобным решением.

P.S. Ну и как водится, через минут 10 после всего я обнаружил, что в принципе изобрёл велосипед - вот тут уже есть подобный декоратор. Хотя мой велосипед просто проще. ;)