Публикации с меткой «blog»

Vurtseed

Блог с песнями об App Engine

В общем я понял, что постоянно слежу на новостями об Google App Engine и для себя фиксирую разные интересные находки, кроме того иногда что-то пишу сам (и тексты и код). И вот решил совместить приятное с полезным и сделал блог в котором выкладываю находки и мысли. Совмещать это в ЖЖ не хочу и это не интересно. Поэтому решил делать на новой платформе и так как удобно именно мне.

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

Сам блог поднят на тумблере http://app-engine.tumblr.com/, чтобы сократить время запуска проекта. Но как только допилю что-то свое, то перенесу данные на другой хостинг и домен, поэтому если пользуетесь RSS читалками, то лучше подписываться на http://feeds.feedburner.com/app-engine адрес фида меняться не будет.

Материалы постепенно перенесу и опубликую то что накопилось. Если хочется поделиться своей умной мыслью, то http://app-engine.tumblr.com/submit и заодно проверим работает это или нет.

Еще раз реклама ссылок:

- Временно постоянный сайт http://app-engine.tumblr.com/
- RSS фид http://feeds.feedburner.com/app-engine

Александр Соловьёв

Размер шрифта

Ян Бикинг написал несколько слов о дизайне, которые напомнили мне об отзывах на текущий дизайн моего блога. В принципе, его слова (и статья Вилсона Майнера, которая собственно и сподвигла меня таки сделать редизайн - там есть на неё ссылка) - это выражение причин, по которым дизайн изменился. :)

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

P.S. Подумываю прикрутить к блогу фид линков с комментариями... А то иногда хочется обратить внимание на что-то интересное, но делать пост из 10 слов - как-то некошерно. :(

Александр Соловьёв

Размер шрифта

Ян Бикинг написал несколько слов о дизайне, которые напомнили мне об отзывах на текущий дизайн моего блога. В принципе, его слова (и статья Вилсона Майнера, которая собственно и сподвигла меня таки сделать редизайн - там есть на неё ссылка) - это выражение причин, по которым дизайн изменился. :)

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

P.S. Подумываю прикрутить к блогу фид линков с комментариями... А то иногда хочется обратить внимание на что-то интересное, но делать пост из 10 слов - как-то некошерно. :(

Lazy Crazy Coder's blog

Quick review of 20 Django blogs.

I wrote my own blog engine in Django. How about you? There are many opensource django application which implement different features. For example, my own blog engine "firefly" (which is used at http://svetlyak.ru) has support for text post and also it has builtin photo blog with separate feed, urls and tagging. Also, it includes meny other features, but I don't think, that all these features will be useful even for 10% of readers.

Today, I decide to look at existing opensource django blogs with hope to find a universal solution, simple but flexible enough to build a blog with any kind of the media. I need a reusable django application to build a blog with support for posts with links, text, images, whatever.

So, lets look, what you can find at http://code.google.com/hosting/ and http://github.com using keywords "django blog":

  • banjo -- very complex "all-in-one" solution, with many models and custom plugins. This is absolutelly not "Django Way".
  • becca -- minimalistic blog application. There is only two models -- for post and for tags. Pretty code, but to be updated to work with django 1.0.
  • blogango -- relatively simple design, but with custom tags and comments.
  • blogmaker -- has more or less complex design with built-in trackback and tags support.
  • coltrane-blog -- simple blog by James Bennett with two separate models for posts and links. Uses custom categorization and django-tagging.
  • django-basic-blog -- really simple blog application, some where similar to coltrane -- basic-blog also uses separate categories and django-tagging.
  • django_blog -- very, very, very minimalistic blog application.
  • django-blog-entries -- interesting models design. This blog uses comment_utils for moderation.
  • django-diario -- also has very interesting models.py. I've learn some new things about usage of django's fields. This blogging application has relatively simple and has optional support for django-tagging. Also, django-diario has multi-site support and one post can be published on different sites. I don't like it complexity in multi-site part, but other ideas are look good.
  • django-ink -- very simple and clean models. Nothing exeptional, just easy to use blog application.
  • django-yab -- yab is nothing but yet another django blog. However, it has support for multiple blogs, which may be interesting to somebody, not for me, certanly.
  • flother -- besides a simple and straigt blog application, "flother" includes a photo gallery application. In that way, "flother" very similar to my "firefly" engine, which also includes a blog for text and a separate photoblog.
  • lifeflow -- another "all-in-one" solution. Complex, with custom comments, categories, tags, translation support, uploads and other strange post's grouping tools. LifeFlow is huge and ugly for my taste.
  • n00bish-django-blog -- really noobish app, very simple and useless :-)
  • oebfare -- simple blog, which includes few application to publish posts and links. Nothing interesting.
  • shiftingbits -- based on the "oebfare", straightforward blog, with additional support for import from Wordpress, metaWeblog API, Akismet, django.contrib.comments and comment_utils.moderation.
  • zangetsu -- pretty simple blog application with custom tags and example of TinyMCE, embedded into a django admin. Also, it has import from the wordpress and from a plain rss feed.
  • zsite -- the most minimalistic blog. It has just a settings.py, manage.py and urls.py. Zsite includes basic.blog and basic.inlines from a django-basic-apps.
  • byteflow -- is a very complex, full-fleged blog engine, based on separate applications. I don't need all this stuff, but sometimes it is very interesting to look "under the hood" of the byteflow and discover something interesting.
  • firefly -- my own blog. Complex and with tight coupling between application. I want to separate them from each other, but sometimes it is to difficult. Has support for multiple languages, pingbacks, tagging (with modified multilingual django-tagging application), akismet moderation, photo blogging, pinging of blog search engines and etc..

As you can see, there are many solutions, but I am not found any application which comply with my requirements. So, I need to continue my investigations of the Django world…

Александр Соловьёв

Картинки в статьях

Наконец-то долгожданная фича, до которой у меня никак не доходили руки (и мозги ;), работает: теперь из админки можно загружать и публиковать картинки. Пока только с синтаксисом markdown'а, но если кто хочет проапгрейдить - патчи велкам. ;)

Думаю, со временем можно будет проапгрейдить, но пока и такой вариант очень неплох, имхо - выглядит это как ссылка "attach image" рядом с полем для ввода текста в админке, где можно написать дескрипшен и выбрать картинку (или, жмакнув по кнопке, загрузить новую). Вообще там какие-то проблемы с submit-row - откуда-то появляется обрамляющий всё тег a, что корёжит слегка раскладку, но я не понимаю пока, откуда же он. :(

В общем, огроменное спасибо Виктору Надь (Viktor Nagy) за этот офигенский патч. ;-)

Ну из мелочей я по пинку всё того же Виктора добавил django-maintenancemode. Если вдруг вам нестерпимо захочется выключить для всех ваш блог, стоит добавить лишь MAINTENANCE_MODE = True в settings_local.py. При этом стафф всё равно всё может видеть, а форма для логина в админку вообще останется видна всем (на случай, если кому-то из стаффа надо залогиниться).

Ну и несколько разных багов поправил, куда ж без них...

Александр Соловьёв

Картинки в статьях

Наконец-то долгожданная фича, до которой у меня никак не доходили руки (и мозги ;), работает: теперь из админки можно загружать и публиковать картинки. Пока только с синтаксисом markdown'а, но если кто хочет проапгрейдить - патчи велкам. ;)

Думаю, со временем можно будет проапгрейдить, но пока и такой вариант очень неплох, имхо - выглядит это как ссылка "attach image" рядом с полем для ввода текста в админке, где можно написать дескрипшен и выбрать картинку (или, жмакнув по кнопке, загрузить новую). Вообще там какие-то проблемы с submit-row - откуда-то появляется обрамляющий всё тег a, что корёжит слегка раскладку, но я не понимаю пока, откуда же он. :(

В общем, огроменное спасибо Виктору Надь (Viktor Nagy) за этот офигенский патч. ;-)

Ну из мелочей я по пинку всё того же Виктора добавил django-maintenancemode. Если вдруг вам нестерпимо захочется выключить для всех ваш блог, стоит добавить лишь MAINTENANCE_MODE = True в settings_local.py. При этом стафф всё равно всё может видеть, а форма для логина в админку вообще останется видна всем (на случай, если кому-то из стаффа надо залогиниться).

Ну и несколько разных багов поправил, куда ж без них...

Александр Соловьёв

OpenID в Byteflow

Такой маленький пост, чисто похвастаться. :) Вот уже несколько месяцев благополучно работают обе части OpenID в движке - и клиент, и сервер. Ни одного бага (кроме небольшого, связанного с траблами реверс-проксирования и не имеющего отношения к логике работы) с тех пор, как мы закончили встраивать DjangoID (главным образом усилиями Олега) в Byteflow, т.е. примерно с марта. Ура! :)

Александр Соловьёв

OpenID в Byteflow

Такой маленький пост, чисто похвастаться. :) Вот уже несколько месяцев благополучно работают обе части OpenID в движке - и клиент, и сервер. Ни одного бага (кроме небольшого, связанного с траблами реверс-проксирования и не имеющего отношения к логике работы) с тех пор, как мы закончили встраивать DjangoID (главным образом усилиями Олега) в Byteflow, т.е. примерно с марта. Ура! :)

Изучаем Django

Создание моделей

Немного теории

Модель в Django это описание сущностей приложения при помощи специального синтаксиса, например у нас может быть сущность пользователь с полями логин, пароль, адрес электропочты, дата рождения и сущность запись в блоге с полями заголовок, содержание и ссылкой на пользователя, который опубликовал запись. Модель описывается как класс, унаследованный от Model, поля объекта описываются путем присвоения значений из класса Model, каждое из значений означает один из допустимых типов полей. Для примера опишем указанные выше сущности:
        #сущность пользователь
 class User (models.Model):
  login = models.CharField(max_length=50)
  password = models.CharField(max_length=50)
  email = models.EmailField()
  age = models.DateField()
  
 #сущность запись в блоге
 class Post (models.Model):
  title = models.CharField(max_length=100)
  body = models.TextField()
  poster = models.ForeignKey('User')
Рассмотрим что же мы написали. Запись вида login = CharField(max_length=50) означает, что сущность пользователь обладает свойством логин, которое представлено строкой символов максимальной длиной 50, просто не правда ли? EmailField это поле для хранения адреса электропочты, DateField — для хранения даты, TextField для хранение текста, а ForeignKey определяет ссылку poster на объект класса пользователь. По описанию моделей Django сможет разработает для нас схему базы данных, создаст административный интерфейс и валидаторы. Мы написали всего 10 строчек кода, а получили достаточно много функций, это одна из основных идей рассматриваемого фреймворка — написание приложения с использованием меньшего количества кода. SQL-код сгенерированный Django по описанным моделям:
CREATE TABLE `default_post` (
    `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
    `title` varchar(100) NOT NULL,
    `body` longtext NOT NULL,
    `poster_id` integer NOT NULL
)
;
CREATE TABLE `default_user` (
    `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
    `login` varchar(50) NOT NULL,
    `password` varchar(50) NOT NULL,
    `email` varchar(75) NOT NULL,
    `age` date NOT NULL
)
;
ALTER TABLE `default_post` ADD CONSTRAINT poster_id_refs_id_3b3164d6 
FOREIGN KEY (`poster_id`) REFERENCES `default_user` (`id`);

Приложение

Для завершения настройки нашего проекта создадим приложение — осмысленная часть нашего проекта выполняющая какие-либо действия. В Zend Framework можно найти аналогичный механизм — модуль. Пока не вижу необходимости разбивать наш проект на приложения, поэтому ограничимся одним и назовем его default. Запустите эту команду находясь в директории coblogs python manage.py startapp default Итак, мы получили новую директорию default, в ней вы найдете файл models.py, который содержит описания моделей, весь код описанный далее содержится в этом файле. Так же необходимо отредактировать settings.py, включив default в список установленных приложений
INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'coblog.default'
)

Модели

Напомню, что мы создаем сервис коллективных блогов с визуальным/wiki редактором, тегами, кармой и рейтингом постов и комментариев. Попробуем создать костяк моделей проекта, постепенно расширяя его при необходимости. Первая модель — наш дорогой и любимый пользователь, но описывать её не нужно в Django есть встроенный механизм аутентификации включающий модель User. Поля «стандартного пользователя»:
username
имя пользователя (логин), обязательное поле, не более 30 букв, цифр и знаков подчеркивания.
first_name
имя пользователя (по паспорту ;), опционально, не более 30 символов.
last_name
фамилия пользователя, опционально, не более 30 символов.
email
электропочта.
password
хеш пароля, обязательное поле, метод set_password поможет установить хэш по паролю.
is_staff
определяет, может ли пользователь использовать админку.
is_active
определяет, не заблокирован ли пользователь (true — не заблокирован).
is_superuser
если true, то пользователь имеет все возможные права.
last_login
дата и время последнего входа на сайт.
date_joined
дата и время создания аккаунта.
Кроме полей есть полезные стандартные методы, описанные в руководстве. Для пользователя в нашем проекте не хватает одного поля — кармы, добавим его, воспользовавшись механизмом профайлов:
# -*- coding: utf8 -*-  укажем кодировку этого файла

#подлючение механизма моделей
from django.db import models
#подключение стандартной модели пользователя
from django.contrib.auth.models import User
import math

class Profile(models.Model):
        #Порог уровня изменения кармы см. get_karma_delta
        KARMA_DELTA_THRESHOLD = 10

        #ссылка на стандратную модель пользователя
  user = models.ForeignKey(User, unique=True)
        __karma = models.IntegerField(default=0)

        def inc_karma(self, delta):
                """Увеличивает(или уменьшает) карму пользователя на delta"""
                self.__karma += delta

        def get_karma(self):
                """Возвращает карму пользователя"""
                return self.__karma

        def get_karma_delta(self):
                """
                Возвращает на какое значение пользователь может
                изменить карму другого пользователя
                """
                if self.__karma == 0:
                        return 1
                else:
                        return math.ceil(self.__karma/self.KARMA_DELTA_THRESHOLD)

  #Данный класс нужен для появления модели в административном интерфейсе 
                #(об этом в следующий раз)
        class Admin:
                pass
Для подключения нашего профиля добавим строку в settings.py:
AUTH_PROFILE_MODULE = "default.profile"
теперь профиль пользователя доступен при помощи метода get_profile(). Следующие модели — блог (пока содержит только название и описание) и запись в блоге:
class Blog(models.Model):
        caption = models.CharField(max_length=50)
        description = models.TextField()
        created = models.DateTimeField(auto_now_add=True)

        #функция __unicode__ определяет строковое представление объекта
  def __unicode__(self):
                return self.caption

        class Admin:
                pass

class Post(models.Model):
        """ Запись в блоге """
  #ссылка на блог в котором опубликована запись
        blog = models.ForeignKey(Blog)
  #ссылка на пользователя опубликовавшего запись
        poster = models.ForeignKey(User)

        #рейтинг записи
        __rate = models.IntegerField(default=0)

  #заголовок записи
        caption = models.CharField(max_length=50)
  #содержание записи (wiki-размеченный текст)
        content = models.TextField()
  #поле определяет, является ли запись черновиком
        draft = models.BooleanField(default = True)
  #дата создания
        created = models.DateTimeField(auto_now_add=True)
  #дата публикации (устанавливается после снятия опции черновик)
  posted = models.DateTimeField()

        def inc_rate(self, delta):
                self.__rate += delta

        def __unicode__(self):
                str = '';
                if self.draft:
                        str = ' (draft)';
                return self.caption + str

        class Admin:
                pass
И последние две модели — комментарий к записи в блоге и тэг к записи:
class Tag(models.Model):
        """ Тэг (метка) для записи в блоге """
        post = models.ForeignKey(Post)
        tag = models.CharField(max_length=30)

        def __unicode__(self):
                return self.tag

        class Admin:
                pass

class Comment(models.Model):
        post = models.ForeignKey(Post)
        parent = models.ForeignKey('self')
        user = models.ForeignKey(User)

        __rate = models.IntegerField()
        content = models.TextField()
        created = models.DateTimeField(auto_now_add=True)

        def inc_rate(self, delta):
                self.__rate += delta

        def __unicode__(self):
                return self.content

        class Admin:
                pass

Создание структуры базы данных

Пришло время магии :) создадим структуру базы данных из наших моделей. Для этого достаточно ввести команду:
python manage.py syncdb
Сгенерированный SQL-код можно посмотреть при помощи команды:
python manage.py sql default

Манипуляции с моделями

После создания структуры базы данных, можно познакомиться с Database API предоставляемый джанговским ORM. Откроем Python консоль и поэкспериментируем с методами моделей:
#> python manage.py shell
#импортируем стандартную модель пользователя
>>>from django.contrib.auth.models import User
#создадим экземпляр класса User и установим ему пароль '12345'
>>> user = User(username = 'testuser', first_name='Василий', last_name='Пупкин')
>>> user.set_password('12345')
#сохраним пользователя
>>> user.save()
#пользователь был успешно добавлен в БД, посмотрим сгенерированный id
>>> user.id
3L
#импортируем все наши модели
>>> from coblog.default.models import *
#создадим профиль пользователя для testuser и сохраним его в БД
>>> profile = Profile(user=user)
>>> profile.save()
#посмотрим карму
>>> user.get_profile().get_karma()
0L
>>> выведем имена всех пользователей
>>> for usr in User.objects.all() :
...     print usr
root
testuser
#напишем пост
>>> blog = Blog(caption='Блог о Django')
>>> blog.save()
>>> post = Post(poster= User.objects.get(username='testuser'),
caption='Database API', blog=blog)
>>> post.content = 'вот мы вкратце и ознакомились с Django Database API.'
>>> post.save()

Александр Соловьёв

OpenID server

Этот пост будет кратким - благодаря стараниям Олега в Byteflow теперь присутствует сервер OpenID. Клёво. :-)

P.S. А ещё byteflow - второй по тегу django на ohloh.net, после самой джанги. :-)

Александр Соловьёв

OpenID server

Этот пост будет кратким - благодаря стараниям Олега в Byteflow теперь присутствует сервер OpenID. Клёво. :-)

P.S. А ещё byteflow - второй по тегу django на ohloh.net, после самой джанги. :-)

Александр Соловьёв

Пользователь и его профиль

Известная штука, что у Django есть статическая (неизменяемая официально поощряемыми путями) модель User и костыль для дополнительных полей (которые может каким-либо образом использовать приложение) в виде настройки USER_PROFILE, указывающей на модельку-профиль. В результате использования такого костыля, если не делать дополнительных телодвижений, количество запросов возрастает (пример для данного блога, где каждому комментирующему ставится ссылка на его сайт) на число комментариев (даже не комментировавших, а комментариев!).

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

Потому, после продолжительных колебаний и сомнений, я решил сделать всё радикальнее - удалить всю модель UserProfile, применив вместо неё monkey patching к стандартной модели:

User.add_to_class('site', models.URLField(verify_exists=False, blank=True))
User.add_to_class('email_new', models.EmailField(blank=True))

User._meta.admin.fields += (
    ('Byteflow Extensions', {'fields': ('site', 'email_new')}),
    )

Конечно, главная проблема здесь - это то, что способ совершенно не стандартный и вряд ли кто-то будет ожидать, что табличка auth_user будет меняться. Но такой способ настолько выгоднее и удобнее, что я решил наплевать на эти трудности. :-)

И ещё одно - спасибо Амиту, который и показал конкретно, как это сделать. ;-)

Александр Соловьёв

Пользователь и его профиль

Известная штука, что у Django есть статическая (неизменяемая официально поощряемыми путями) модель User и костыль для дополнительных полей (которые может каким-либо образом использовать приложение) в виде настройки USER_PROFILE, указывающей на модельку-профиль. В результате использования такого костыля, если не делать дополнительных телодвижений, количество запросов возрастает (пример для данного блога, где каждому комментирующему ставится ссылка на его сайт) на число комментариев (даже не комментировавших, а комментариев!).

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

Потому, после продолжительных колебаний и сомнений, я решил сделать всё радикальнее - удалить всю модель UserProfile, применив вместо неё monkey patching к стандартной модели:

User.add_to_class('site', models.URLField(verify_exists=False, blank=True))
User.add_to_class('email_new', models.EmailField(blank=True))

User._meta.admin.fields += (
    ('Byteflow Extensions', {'fields': ('site', 'email_new')}),
    )

Конечно, главная проблема здесь - это то, что способ совершенно не стандартный и вряд ли кто-то будет ожидать, что табличка auth_user будет меняться. Но такой способ настолько выгоднее и удобнее, что я решил наплевать на эти трудности. :-)

И ещё одно - спасибо Амиту, который и показал конкретно, как это сделать. ;-)

Александр Соловьёв

Темы

С подачи lorien'а блог обзавёлся возможностью переопределять только нужные темплейты в темах. Всего лишь добавил загрузчик темплейтов (это оказалось очень просто), да настройку THEME - теперь первым делом темплейты ищутся в themes//, а уж потом в templates/. :-) Ещё думаю сделать добавление стилей в зависимости от этой настройки, но не решил каким образом будет лучше. Наверное, темплейт тег, который будет проверять существование файликов со стилями кастомных и добавлять их в хидер. Или есть варианты лучше?

Ещё подумываю добавить мультиязычность. ;-) Но как это реализовать?... Пока знаю только django-multilingual и i18ndynamic. Может кто знает лучший вариант? Было бы неплохо, чтоб комментарии к разным языкам не пересекались, наверное... Или плохо? :\

Александр Соловьёв

Темы

С подачи lorien'а блог обзавёлся возможностью переопределять только нужные темплейты в темах. Всего лишь добавил загрузчик темплейтов (это оказалось очень просто), да настройку THEME - теперь первым делом темплейты ищутся в themes//, а уж потом в templates/. :-) Ещё думаю сделать добавление стилей в зависимости от этой настройки, но не решил каким образом будет лучше. Наверное, темплейт тег, который будет проверять существование файликов со стилями кастомных и добавлять их в хидер. Или есть варианты лучше?

Ещё подумываю добавить мультиязычность. ;-) Но как это реализовать?... Пока знаю только django-multilingual и i18ndynamic. Может кто знает лучший вариант? Было бы неплохо, чтоб комментарии к разным языкам не пересекались, наверное... Или плохо? :\

Метки

.net .NET C# .sort 1.2 2009 2010 404 error admin ajax amazon analytics and apache api archlinux asp.net async asynchronous autocomplete bash blender blog blogengine blogs book bootstrap bot bpython buildout byteflow bzr C c plus plus C++ cache cbv Chaco checkio chrome ci ckeditor class based views clojure closure cms cms с удобной админкой code coding style collectd COM comet competition conference ConfigParser contest Context continuous integration CouchDB coverage CppCMS cpyext cpython crud csrf CSS ctypes curl custom model fields cx_freeze cython database db dbm dbqueries debian debug debugging decorator decorators deploy deployment descriptor design dev devconf developers development diveintopython Django django 1.2 django 1.3 django advent django framework django template django trunk django weblog django-admin-tools django-cms django-compressor django-hosts django-piston django-registration django-sphinx django.admin djangoadvent djangocms djangodash doc documentation drupal e-legion eclipse EGit emacs encoding Enthought epoll erlang event exception ExtJS fabric facebook fastcgi finaloption fixtures fonts forms formset fp framework freebsd freeswitch fs2web ftp fun funcparserlib functional gae gamin gandi generic views gettext gevent gil git github gitosis Google Google App Engine google picasa Google Translate google wave Google Web Toolkit grab grablab greenlet gtd gui haskell hg hgshelve highlighter host hosting how-to howto html html5lib Hudson humor i18n icfpc ide idiomatic image-scripting improvements Internet interpreter ipython ironpython izmenimsya.ru jabber java javascript jenkins jetbrains JIT job jquery json jstree jython kde kiev kiyv kyivpy l10n ldap library libs Life Links linux Linux & Unix LLVM logging logs lxml Mac OS X magic mail markdown Matplotlib Mayavi maybe mediavirus meetup memcache Memcached memory messages metaclass middleware migration mikrotik mkd model models mod_python mod_wsgi mongodb monitoring mptt musicmans.ru musicx mvc my-projects mysql netCDF networkx newforms newforms-admin news nginx Nhibernate nix nose NoSQL numpy oop open source OpenID openoffice opster optimization oracle orm os pagination parsing path patterns pdf PDF-принтер PEP PEP8 performance performance optimization perl personality photo php picture-driven computing PIL pinax pingback pip plasma plone plugin plugins postgresql programming progress bar psycopg2 py2exe pybb pybbm pycamp pycharm pycon pycow pycurl pydev pygtk pylons PyNGL pypy pyqt PyQt4 pyrad pyramid PySide Python Python 2.5 python 2.7 python 3 python c api python speed python-mssql python3 pywinauto Qt Qt4 queue rabbitmq radius raw sql re redis redsolution redsolution cms regexp regular expressions release repoze.bfg RequestContext reusable apps robokassa rss ru ruby ruby-on-rails sample satchmo scalability SciPy scraping screencast search selenium self.error seo server setattr settings setuptools shell sikuli sms snippet socket.io software sorting south sphinx spider sql sqlalchemy sqlite ssh startup step-by-step subdomain subversion svn SyntaxHighlighter system tags tdd tddspry teh drama template templates templatetags test testing thinkpad threading threads tips tips and tricks tools tornadio tornado tornado server tricks tutorial tweepy twisted twitter typography uapycon Ubuntu ucsvlog uml Uncategorized unicode unit test unit testing UnitTest Unladen Swallow upload urllib urls utf-8 uwsgi validation vcs versioning video vim virtualenv Visual Studio vkontakte voip wave web web-devel web-services web-разработка webdev webfaction webkit webpy websockets webtest widget widgets Win API windows Wirbel work wrapper wsgi wxPython wxWidgets wysiwyg xapian xml xmonad xmpp xpath yandex youtube zip zomg zope [cdata[cbv]] [cdata[ci]] [cdata[class based views]] [cdata[continuous integration]] [cdata[django framework]] [cdata[django-sphinx]] [cdata[django]] [cdata[nginx]] [cdata[python]] [cdata[virtualenv]] [cdata[программирование]] автоматизация администрирование администрирование django админка алгоритмы архитектура атрибуты базы данных Без рубрики безопасность библиотеки блоге бот веб-разработка видео Визуализация данных вконтакте Все записи гвидо ван россум граббер графика графы декоратор декораторы дескриптор дескрипторы документация заметки игра жизнь идея интересное киев Клиентам книги конференция личное математика метаклассы модели модули монады морфология мысли невозможное новости о облачные вычисления обо мне Обработка данных оптимизация оптимизация кода Основная лента основы парсинг парсинг сайтов перевод песочница Питон поебень поиск правила кодирования программирование Проектирование производительность работа рабочее размышлизмы Разное разработка разработка приложений разработки регулярные выражения сайт событие события ссылки статьи тестирование тесты Тюмень убунтариум фигня философия формы форум Хабрахабр хакинг хостинг шаблоны шаблоны проектирования эксперимент Эксперименты юмор я пиарюсь Яндекс