Django 1.0

На самом деле, сдувать пыль с давно не менявшегося движка я начал ещё в августе, благо в Gentoo был даже доступен ебилд для SVN-версии Django. По сути дела, в основном потратил время на подчистку кода, освоение новой системы комментирования и django-tagging.

Чистить было что — в шаблонах остались скелеты динозавров эпохи второго варианта оформления моего блога.

contrib.comments

Новые комментарии были созданы студентом Thejaswi Puthraya (не рискну написать его имя по-русски) в рамках проекта Google Summer of Code 2008. Отличия от того, что было, есть.

Не различаются комментарии от регистрированных пользователей и анонимов (если юзер залогинен, то при постинге просто его номер сохраняется, а потом при доступе к полям комментария делается запрос сразу к базе пользователей) — здорово

Есть стандартные виды для отправки, удаления, модерирования комментариев — здорово. Так я удалил огромную кучу кода в одном из своих видов, которых занимался обработкой формы комментирования. Пока ещё кое-что — отложенные редиректы при помощи next= — не работает.

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

{% get_comment_list for blog.entry entry.id as comment_list %}

То же самое можно сделать и через менеджер объектов модели CommentComment.objects.for_model().

Пока что модуль contrib.comments сыроват, немножко не успели к релизу допилить всё.

django-tagging

Сагалаев не выпускал новую версию своего расширения под newforms вообще, и я уже было хотел переписать таки его под 1.0, но тут в рассылке случайно прочитал про django-tagging, и понял, что в данном случае изобретать велосипед не стоит. По сути дела, я прельстился реализованным там декоратором для видов «все такие-то модели с определённым тегом» и функцией для обсчёта облачка тегов (можно выбирать линейную и логарифмическую шкалу). К тому времени как раз эти самостоятельно реализованные функциональности были по сути единственным нетривиальным «пользовательским» кодом в моём движке. Код этот в итоге опять же отправился под нож — взамен его теперь используются стандартные средства django-tagging. Не хватает:

  • унификации по регистру (в сагалаевских тегах специально это было реализовано — хранился тег и его нормированное значение (в отдельных полях value и norm_value)); я собираюсь сделать это для django-tagging.

  • всё же виджет формы в сагалевских тегах был удобен — там был комплишен и теги добавлялись по одному, каждый в своей ячейке. Здесь же нужно вводить их просто в строку (однако успешно используется особая магия по распознаванию способа разделения тегов в списке — то есть, tag1 tag2 считается как два тега, разделённых пробелами, а tag1, tag2 foo, tag3 — как три, разделённых запятыми)

Заодно насчёт тегов

Кстати, давно планировал пробежаться по всем-всем записям, проверить, единобразно ли у меня проставлены теги. Я давно заметил, что основанные на тегах таксономии неизбежно замусориваются по разным причинам — появляется большое количество тегов-сирот, которыми обладают одна-две записи (правда, это не всегда говорит о проблемах; иногда просто тематика действительно мало освещена); от таких тегов в принципе можно было бы избавиться вовсе, потому что из-за субъективных соображений проставляющго теги во время написания записи может появиться тенденция с излишней детализации таксономии. Это размывает таксономию и приуменьшает достоинства использования меток для классификации.

В массовых системах (например, del.icio.us) это нивелируется большим числом субъектов, осуществляющих расстановку меток, поскольку релевантность метки существенно подтверждается при выборе её более чем одним субъектом (на этом принципе основан Google Image Labeler). Когда такой субъект один (в случае индивидуального блога) процесс усложняется — нужно либо тупо забить, либо целенаправленно проводить политику расстановки тегов.

Так вот, в процессе выработки такой политики я ещё раз пришёл к выводу, что вести блог — это офигеть как полезно и круто, и сейчас скажу, почему.

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

Wicked mindmap

Степень серьёзности отношения к такой карте стоит избирать сообразно серьёзности отношения к онлайн-дневнику. Если писать одну херню, то и в тегах будет одна херня. Я, например, заметил, что тегу «родители» соответствует всего одна запись, и та скрытая, но это не значит, что такой сущности в моей жизни нет — просто я не пишу о ней. Так, где-то после сотни пройденных записей, я ужаснулся величине тега «школа» в облаке — школиё овладевает! — но нет же, просто школа действительно когда-то что-то значила в моей жизни. Точно так же ужасает величина тега «X-Post», посвящённый левой системе на PHP, на которой почти год проработал мой блог и которую я считал венцом инженерной мысли. Несколько лет назад я и представить не мог, что можно успешно абстрагировать работу с данными таким образом, что значительная часть логики их обработки будет выводиться из описания используемых моделей данных. Эти соображения намекают мне на то, что нужно сделать на страничке со списком тегов интерфейс для выбора периода, по записям из которого будет генерится список тегов — так можно будет смотреть, как менялись жизненые сущности с ходом времени.

Вместе с тем, писать нужно обо всём, я считаю. Помогает. Последний год я делал совсем мало записей, хотя их объём увеличился несоизмеримо — например, в одиннадцатом классе я и предположить немог, что когда-нибудь напишу большую статью про «Средства описания изображений». Расти — здорово!

CAPTCHA

Теперь я ещё хочу переделать капчу на более хитрую.

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

Используемая сейчас арифметическая капча вида «7x7+1=?» выглядит примитивно для блога студента-вот-уже-третьекурсника, поэтому я планирую в ближайшее время сделать капчу с вопросами плана «7×7+?=300», где под знаком вопроса стоит натуральное число.

git