Недавно на форуме случился топик посвященный извечной проблеме всех питонистов -- кодировкам. Человек жаловался на то, что у него в программе получаются строчки вида:
Вы заметили что что-то не так? И я вот. Строчки как бы уникодные, но внутри них закодированные utf-8 байты. Что-то pдесь не так. Разбираясь дальше и потребовав скрипт, которые такое генерирует, становится понятно, что данные берутся из веба. Вполне обычным способом через urllib и потом скармливаются в lxml.html для разбора. Поскольку urllib оперирует только байтовыми строками, то он не мог их так превратить в уникод, а значит во всем виноват lxml.
Вообще lxml очень крутая библиотека - и быстрая, и функциональная, и умеет мимикрировать интерфейсом под ElementTree, и взаимодействовать с BeatifulSoup. Она давно уже пользуется популярностью у питонистов, когда надо как-то удобно работать с xml.
Но тут немного другой случай. Тут используется парсер html. И именно в нем происходят эти неприятные метаморфозы со строками.
Я решил понять в чем же всё-таки и дело и как побороть такое поведение.
Для начала, я сходил на http://yandex.ru/ и посмотрел что за html там отдается. Кодировка контента utf8. Сразу что бросилось в глаза -- это ...
Пора нарушить молчание и рассказать о том, что на недавней замечательной конференции 404fest я тоже имел честь выступать с докладом. Посвящен он был модной ныне теме - NoSQL. Доклад получился коротким и поэтому больше политическим чем техническим. Я хотел показать, что этот новый тренд не просто так захватывает умы всё большего числа разработчиков.
Это только первое моё выступление на эту тему, но, я надеюсь, что в скором времени последуют другие на новых площадках
Вам не кажется, что чем большее распространение получаются всякие фреймворки для быстрого создания веб-приложений, то всё большему числу людей кажется, что можно "за один вечер" сделать какой-то сайт и это получится хорошо, интересно и полезно. Нет, так не бывает.
Сейчас я хочу немного порассуждать про сайты-сообщества, например Питона, Джанги или любой другой любимой вами технологии/языка. Это очень похвально, что люди готовы только на энтузиазме (ну или почти только на нем) продвигать продукт, которым они пользуются. Но зачем это делать "как все" и совершенно неэффективно, наступая на всё те же грабли из раза в раз?
Сто есть на каждом сайте какого-либо сообщества?. Агрегатор блогов - так называемая "планета". Но многие уже разочаровались в таком способе в одной ленте получать записи из разных источников. Главная проблема - это автоматическая суть таких агрегаторов. Т.е. авторы чьи блоги входят в эту ленту могут вдруг начать писать что-то совсем отвлеченное или банально неинтересное и что делать? Отписываться от планеты целиком? Не очень удобно, но нет выбора, если кто-то действительно в неё "спамит" и захламляет ваш ридер.
Как показывает практика, гораздо лучше ручные агрегаторы. Все наверно читают Саймона Виллисона и регулярно ходят по интересным ссылкам на какие-то статьи или проекты из его постов. Такого уровня качества ...
Беру небольшую передышку в своих изысканиях о композитных полях для большего прилива вдохновения. Подамся-ка я в другую область на время.
Представим себе ситуацию(а лучше вспомним один из прошлых проектов, который вы делали:)), что есть пара приложений от сторонних разработчиков. И это не какие-то совсем простые приложения, а что-то более комплексное. А отличительной чертой их комплексности будет наличие в каждом своей модели профиля. Ведь было такое? Увы, было. Ну и пусть будут, только вот ещё незадача - их поля являются пересекающимися множествами. Ну т.е. и в том и в другом есть, допустим, поле с ссылкой на сайт владельца. И что же делать? Конечно, для облегчения работы интерфейс редактирования информации профиля один для выбранного основного профиля. А объектов профиля закрепленных за пользователем два (а может быть и больше, если проект используем много разных приложений). Надо как-то синхронизировать данные...
Вообще ситуация того, что в каждом мало-мальски большом приложении свой профиль - это как бы уже давно проблема. И тут ничег уже не поможет. Универсальный профиль помещенный в contrib, конечно, может как-то решить её, но не всегда. Да и потом, с профилем разберемся, так что-то другое появится. Надо находить универсальные пути решения.
Кстати, обсуждения данной темы были как на неформальной встрече джангистов по поводу ...
Нет, я не про музыку решил написать. А про композицию данный, агрегацию если хотите.
В джанге на данный момент агрегации в ORM нет. Но как известно скоро должна появиться, а значит жизнь в очередной раз станет проще.
Зачем?
Но на много ли? Да, писать запросы с агрегацией станет проще. Но в большинстве случаешь выполнять запрос для сервера легче не станет. Вот ту на помощь приходит техника денормализации.
Денормализация - это добавления избыточности данных для увеличения производительности чтения данный. Обычно чтение данных требуется гораздо чаще чем их запись, а значит на запись в принципе можно потратить чуть больше времени, за-то потом много раз сэкономить на выборке. Агрегацию я привел в качестве, наверно, самого популярного источника данных для денормализации, но ею конечно не ограничивается применение денормализации. Суть в том, что лучше что-то тяжелое посчитать при записи и сохранить, чем каждый раз при чтении пересчитывать заново.
Наверно многие из вас в своих проектах писали код наподобие такого, тем более, если писали "свой блог движок":
class Post(models.Model):
comment_count = models.PositiveIntegerField(default=0)
class Comment(models.Model):
post = models.ForeignKey(Post, related_name="comments")
def save(self):
super(Comment, self).save()
self.post.comment_count = self.post.comments.count()
def delete(self):
super(Comment, self).delete ...