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

Обнаружился странный и одновременно неприятный глюк – не подхватываются локали для языка отличного от указанного в LANGUAGE_CODE. Платформа – django 1.2.5, django-cms 2.1.0b3

Собственно – сама странность в том, что локали нормально отрабатывают при запуске проекта через runserver и runfcgi, никаких проблем нет и под gunicorn. Непонятное поведение зафиксировано только при работе под uwsgi или mod_wsgi.

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

class Resource(Publisher, CommentableModel, SortableModel):
    title = models.CharField(max_length=255)
    slug  = models.SlugField()
    attachment  = models.FileField(upload_to=upload_file)
    type  = models.IntegerField(choices=TYPE_CHOICES, editable=False)
    description  = models.TextField(blank=True, default='')
    date_created = models.DateTimeField(default=datetime.now, editable=False)
    category     = models.ManyToManyField(Category, related_name='resources')

    snapshot = models.ImageField(
        blank     = True,
        null      = True,
        upload_to = upload_snapshot,
        help_text = _('Snapshot for resource, not required'),
    )

class Video(Resource):
    objects = VideoManager()

    def get_type(self):
        return FMT_VID

    class Meta:
        verbose_name = _('video')
        verbose_name_plural = _('videos')
        proxy = True

models.signals.pre_save.connect(new_video_thumbnail, sender=Video)
models.signals.post_save.connect(generate_video_thumbnail, sender=Video)

Как видно из кода, к модели Video присоединяется два сигнала — перед сохранением в базу данных и после.

Вот код самих сигналов:

def generate_thumbnail(source_file_path, tmp_file_path):

    args = ['-y', '-i', source_file_path, '-vframes', '1', '-ss', '00:00:02', '-an',
        '-vcodec', 'png', '-f', 'rawvideo', tmp_file_path]

    if os.path.exists(tmp_file_path):
        os.remove(tmp_file_path)

    p = subprocess.Popen(args, executable='ffmpeg')
    p.wait()

    return tmp_file_path

def get_tmp_path(source_path):
    return os.path.splitext(source_path)[0] + '.tmp'

def generate_video_thumbnail(sender, **kwargs):
    instance = kwargs.get('instance', None)
    created = kwargs.get('created', None)

    if created:
        instance.save()

    elif os.path.exists(instance.snapshot.path):
        tmp_file_path = get_tmp_path(instance.attachment.path)
        os.remove(tmp_file_path)

def new_video_thumbnail(sender, **kwargs):
    instance = kwargs.get('instance', None)

    if os.path.exists(instance.attachment.path):

        if instance.snapshot and os.path.exists(instance.snapshot.path):
            os.remove(instance.snapshot.path)

        tmp = generate_thumbnail(
                source_file_path = instance.attachment.path,
                tmp_file_path = get_tmp_path(instance.attachment.path)
            )
        source_filename = os.path.basename(instance.attachment.path)
        snapshot_name = os.path.splitext(source_filename)[0] + '.png'

        instance.snapshot = File(open(tmp), snapshot_name)

Всё волшебство происходит в методе generate_thumbnail, остальное разнообразие служит для корректной обработки создания нового экземпляра и редактирования существующего, когда изображение нужно сгенерировать заново, при замене видеоролика.

Последние три недели наша команда ударными темпами ведёт работу над сайтом 13-го Томского инновационного форума. Всё бы ничего, но по ходу дела возникли несколько проблем. Обо всём по-порядку:

Теггирование.

Существующее решение позволяет добавлять теги к любой сущности (что нам собственно и надо). Делает это за счет generic relations со стороны тегов (Tag + TaggedItem). И тут то возникает первая проблема – расчет тег-клауда. Проходит это в несколько этапов:

1. сам запрос выглядит довольно просто:

SELECT tags_tag.id, count(tags_tagged_item.id)
FROM tags_tag
JOIN tags_tagged_item ON tags_tagged_item.tag_id = tags_tag.id
GROUP BY tags_tag.id

Плюс, по идее HAVING на минимальное кол-во сущностей, помеченных этим тегом. В принципе, выбирая сразу название тега у нас на руках уже есть все данные для формирования клауда, осталось только вывести всё на шаблон, применив стили на основанию веса каждого тега в их общем множестве, объединив соседние величины, чтобы вписаться в ограниченный набор стилей – в итоге заимеем те самые размеры текста, которые так греют глаз. Но, нам надо формировать ссылку на список всех сущностей (сгруппированных по типу), которые были помечены тегом, нужен цельный экземпляр модели Tag. Итого – чтобы вернуть экземпляр тега + 1 запрос на каждый тег, для получения всех полей и маппинга данных в объект питона.

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

max_weight = 10
cloud = []
for tag in Tag.objects.all():
    cloud.append([
        tag,
        math.log(tag.tagged_items.count()) * max_weight / math.log(max_weight)
    ])

Итог данного решения – жуткие тормоза в приложении, возникающие при передергивании БД на пересчет клауда.

Решение проблемы пришло с неожиданной стороны:

Для поиска по сайту мы используем solr, в индекс которого кладётся много чего, но все протеггированные сущности туда в итоге попадают тоже. Осталось ввести поле tags, объявив его списочным, наложить токенайзер, который разобъёт теги по запятым, и сделать фасеточную выборку из индекса, использовав теги в качестве ключевого поля:

        solr = Solr(settings.HAYSTACK_SOLR_URL)
        kwargs = {
            'facet': 'on',
            'facet.field': 'tags',
            'rows': 0,
            'start': 1
        }
        result = solr.search(q = 'language:%s' % language, **kwargs)

Возможно, конечно, что проблема тут в SQL бэкенде, в качестве которого был выбран PostgreSQL, и доступа к тюнингу которого у нас нет (сайт как и база крутится на хостинге заказчика, причем доступа к хосту с БД у нас нет). Но сам факт порождения такого числа запросов уже слегка расстраивает. Тегов много, очень много, одних статей в периодике уже >3K, отдельно лежат интервью (~1K) и библиотека мультимедиа (в сумме около 1K записей), и далеко не все теги встречаются с более-менее завидной частотой.
Но и это еще не всё, второй момент никак не затрагивает Django, скорее само решение по теггированию. При добавлении тегов к сущности как и все белые люди в обычное текстовое поле мы заносим список ключевых слов через запятую, при сохранении экземпляра разбираем их на этом основании и, лишив хвостовых пробелов, вызываем следующу магию – определяем, есть ли уже такой тег и если нет – создаём новый экземпляр, обновляем TaggedItem с внешними ключами на сам тег и модель. Это еще три запроса на каждый тег. Все происходит быстро, но только потому, что кол-во тегов к одной сущности вряд ли превышает десять штук. И каждый экземпляр модели обрабатывается контент-менеджером более-менее индивидуально.

Возможно, спасло бы кеширование, собственно, оно и спасало нас на начальных этапах, но выставляя большое время хранения клауда в кеше теряется актуальность, т.к. новые ресурсы поступают активно, и хотелось бы наблюдать динамику изменения клауда в приближении к реальному времени.

В общем – или отказываться от услуг ORM, или использовать стороннее решение, что произошло в нашем случае.

Если кто-то предложит красивый способ решения такой проблемы, буду очень благодарен.

Хочу на fulltime удалённую работу python/django разработчиком со стандартной занятостью в пять рабочих дней в неделю. Последний год пробовал работать во freelance режиме на odesk.com — слишком гибко для меня.

Краткое резюме можно посмотреть по адресу lorien.name/cv.html Если вкратце, то занимаюсь django с 2007 года, питон в основном применял для веб-разработок и для различных скриптов сбора и обработки информации.

Мои контакты:

• email/jabber: lorien@lorien.name
• skype: lorien.name