Как определить раздел в django-cms?

На одном из django-сайтов, активно использующих django-cms, понадобилось менять флэшку в зависимости от раздела. Не придумал ничего лучше смотреть кусок пути:

{% ifequal request.path_info|slice:":10" '/ekologiya' %}

...

{% endifequal %}

Дело в том, что в джанго-цмс у страниц может быть множество потомков, потому то и приходиться смотреть на кусок uri.

Может быть Вам известен более правильный путь? (более, т.к. этот тоже работает :) )

 

ЗЫ. Конкурс на угадывание сайта, для которого это понадобилось: приз – ссылка с 3 моих сайтов (кому только они нужны?) на сайт угадавшего.

Скрипт для раскрутки twitter аккаунта на python (tweepy)

Привет, друзья!

Недавно начал писать сайт для автораскрутки в twitter. В основе скрипт, который фоловит друзей друзей. Написано отвратно, но при соблюдении рекомендации результат дает:

import tweepy



for user in TwiAccount.objects.all():

    auth = tweepy.BasicAuthHandler(your_user_name, your_user_password)



    def follow_his_friends(username):

        user = tweepy.api.get_user(username)

        for friend in user.friends():

                try:

                    tweepy.API(auth).create_friendship(friend.id)

                except:

                    follow_his_friends(friend.screen_name)



    follow_his_friends('markeyev')

Tweepy, кстати, невероятно хорош - когда я искал python-библиотеку он был лучшим по соотношению понятность/возможности.

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

Подобные скрипты очень востребованы на зарубежных сайтах фриланса и будут продаваться до тех пор пока твиттер присылает уведомления о новых фоловерах и не уведомляет об отписавшихся. Стратегия продвижения благодаря этой особенности проста как мычание: фоловить по 50-100 аккаунтов в день (чтоб не забанили за strange activity) и затем быстренько от них отписываться.

Опыты показали, что strange activity наступает при 700 новых фоловингах в день (то есть когда Вы фоловите кого-либо).

Стали бы Вы пользоваться таким сервисом, который я пишу, или может мне бросить эту дурацкую затею?

www.russned.tv

Вот и подошел к  концу первый этап разработки www.russned.tv – это видеохостинг на django. Из названия ясно, что сайт сделан для наших друзей - Русской недели. При разработке использована куча всяких django-приложений:

• django-cms (с кучищей плагинов)
• django-profile (понадобиться для регистрации и, поздней, для добавления роликов пользователями)
• django-ratings
• django-ajaxcomments
• + набор собственных приложений, которые теперь переносятся из проекта в проект.

У некоторых роликов есть полная avi-версия.

Django-сообществу возможно, будут интересны следующие куски кода этого проекта:

1. Список последних просмотренных роликов

videos = MyVideo.objects.annotate(last=Max('videoview__when')).order_by('-last')[:limit]

Между прочим, универсальный вариант GROUP BY средствами django ORM’а.

2. Ролики отсортированные по соотношению рейтинга к кол-ву голосов:

videos = MyVideo.objects.extra(select={

        'a_rating': 'rating_score/rating_votes'

    }).order_by('-a_rating')[:limit]

Это специфика использования djangoratings – кто использовал поймет ;)

3. Ролики с сортировкой по кол-ву комментариев (только откомментированные):

videos = MyVideo.objects.annotate(comments_count=Count('comments')).\

        exclude(comments_count=0).order_by('-comments_count')[:limit]

В основе файл models:

class MyVideo(models.Model):

    ...

    title = models.CharField(_(u'название'), max_length=250, unique=True)

    desc = models.TextField(_(u'описание'), max_length=250, null=True, blank=True)

    category = models.ForeignKey(Category, verbose_name=_(u'категория'), blank=True, null=True)

    tags = TagAutocompleteField()



    rating = RatingField(range=5, weight=1, can_change_vote=True, allow_anonymous=False)



    comments = generic.GenericRelation(Comment, content_type_field="content_type", object_id_field="object_pk")



class VideoView(models.Model):

    video = models.ForeignKey(MyVideo)

    when = models.DateTimeField(auto_now_add=True)

    user = models.ForeignKey(User, null=True, blank=True, editable=False)

Смотрите, качайте, советуйте друзьям! www.russned.tv.

Мороз. Можно в школу не ходить?

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

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

Данные берутся из гисметео (только Тюмень), а правила отмены занятий взяты из статьи http://www.t-i.ru/article/8745/. Скрипт простой как мычание:

# -*- coding: utf-8 -*-

from django.shortcuts import render_to_response

from django.template import RequestContext

from django.utils import http

from datetime import datetime

import xml.etree.ElementTree as ET



def average(numbers):

    return sum(numbers) / len(numbers)



class Forecast(object):

    datetime = datetime(2009, 12, 7, 20)

    pressure_max = pressure_min = temperature_max = temperature_min = wind_max = \

    wind_direction = wind_min = relwet_max = relwet_min = heat_max = \

    heat_min = 0

    def avg(self):

        return average([self.temperature_max, self.temperature_min]), \

            average([self.wind_max, self.wind_min])

    def npu_1_4(self):

        '''

        Занятия для учеников 1-4-х классов отменяются, если температура воздуха

        опускается до -30 С и ниже при скорости ветра менее 2 метров в секунду.

        При скорости ветра 2 метра в секунду и более занятия отменяют уже при

        -25 градусах.

        '''

        avg_temp, avg_wind = self.avg()

        return (avg_wind >= 2 and avg_temp <= -25) or (avg_wind < 2 and avg_temp <= -30)



    def npu_1_9(self):

        '''

        Школьники 1-9-х классов могут остаться дома, если столбик термометра

        показывает -35 градусов и ниже, при этом скорость ветра должна быть

        менее 2 метров в секунду. А при большей его скорости занятия для

        учеников отменяются и при температуре -30 и ниже.

        '''

        avg_temp, avg_wind = self.avg()

        return (avg_wind >= 2 and avg_temp <= -30) or (avg_wind < 2 and avg_temp <= -35)

    def npu(self):

        '''

        Занятия отменяются по всей школе (1-11-е классы) при температуре

        наружного воздуха -40 градусов и ниже (при этом скорость ветра не должна

        превышать 2 метров в секунду).

        ??? превышать ??? - наверное, должна быть не меньше.

        '''

        avg_temp, avg_wind = self.avg()

        return (avg_wind >= 2 and avg_temp <= -40)



def index(request):

    h = http.urllib.urlopen('http://informer.gismeteo.ru/xml/28367_1.xml')

    xml = h.read()

    tree = ET.XML(xml)

    res = []

    for f in tree.getiterator('FORECAST'):

        obj = Forecast()

        obj.date = datetime(

            int(f.get('year')), int(f.get('month')), int(f.get('day')),

            int(f.get('hour'))

        )

        for x in f.getchildren():

            for y in x.items():

                setattr(obj, str(x.tag.lower())+'_'+y[0], int(y[1]))

        res.append(obj)

    output = {

        'res': res,

    }

    return render_to_response('index.html', output, context_instance=RequestContext(request))

Посмотреть результат можно тут: school.concepter.ru. Он не причесан и не информативен, но с функцией справляется – если занятий нет, он напишет.

UPD. Спасибо Земе за ликбез.

UPD2: Нужно смотреть не температуру (temperature_min и temperature_max), а температуру комфорта (heat_min и heat_max) – отменяют по ней.

Заочная встреча с создателем вИшиме.ru

Позавчера (в субботу) прокладывали ethernet-кабели в новом офисе ИГС. Из-за разных неожиданных мелочей провозились на 1.5 часа больше, чем я планировал. Не страшно, но в 15 часов ко мней домой приезжал Дмитрий Орлецкий - автор перспективного проекта о городе Ишиме - вИшиме.ru. Так уж вышло, что я в этом проекте тоже участвую.

Встретится у нас так и не получилось, но на мою жену он произвел положительное впечатление, что само по себе уже очень хорошо. Новое время стирает привычные границы. Раньше я не мог себе представить, что буду работать с каким-нибудь человеком 2 месяца, получать от него деньги, и не видеть его "в живую". Теперь - обычное дело.

вИшиме.ru написан на django и использует несколько весьма популярных pluggble апликух. Если хотите, я могу описать его архитектуру подробней, может быть даже выложу некоторые куски кода. Хотите?

Всё о Тюмени – агрегатор новостей

Вчера, потехи ради, запустил Агрегатор новостей о Тюмени.

Цель: посмотреть на поведение поисковиков по отношению к копированному контенту.

Я уже замечал, что google не охотно индексирует сайты с контентом похожим на уже отсканированный, но в случае с подобными этому сайтами блокада ресурса может вообще никогда не пройти - прошлый эксперимент закончился тем, что по прошествии 2 месяцев в гугле так и не было ни одной страницы с сайта.

Посмотрим, чем все кончится на этот раз…

Perfect10.ru – ворох женщинофф.

По работе задействован в проекте http://perfect10.ru/ - международный интернет-конкурс красоты. Проект сделан на django.

Заказчики не ждали большого количества посетителей, но на днях обнаружилось, что конкурс весьма и весьма востребован. Каждый день регистрируется не менее 5 новых участниц (и даже один участник уже был).

Интересного с точки зрения django в проекте – платные сервисы сделанные при помощи smscoin.

Сейчас доделываю инструмент для рассылки сообщений участницам. Вызываться он будет по крону (management command) и срабатывать по определенному правилу. Например, если в анкете нет фотографии, то раз в день участнице будет отправляться письмо с просьбой добавить фото (наверное, ограниченное количество раз, а затем анкета будет удалятся).

Конечно, у сайт ещё масса недочетов – нет настроек для главного фотографии участницы (портретные фото есть, оказывается, не у всех); карта сайта обещана, но пока не сделана; голосование оформлено в виде ссылок, а не форм (в итоге, первое время поисковые боты постоянно дергали ссылки рейтингов); анонимный рейтинг не так уж и сложно накрутить и прочее...

Идея для закрытого сервиса закладок

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

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

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

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

Даже название есть (Маша придумала): "Кротжмот.ру - сервис асоциальных закладок". По наалогии с "БобрДобр.ру - социальный сервис закладок Рунета". :)

Unobtrusive everything, but html. Ненавязчивое все, кроме html.

В интернете сейчас огромное количество материалов о unobtrusive javascript. Появляются не смелые упоминания о том, что может быть ещё и unobtrusive css. Ненавязчивай в данном контексте значит - не объязательный, не нужный. То есть должно работать и без него.

Насмотревшись на это сполна выдвигаю встречную теорию unobtrusive everything, but html.

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

В той же django для генерации html форм на лету уже несколько инструментов есть с помощью которых из голой идеи можно получить результат за 30-40 минут (http://f.labwr.ru например), не больше, но нерадивый программист тратит 70% времени проекта на отлаживане работы вот этой вот рюшечки, которая относится к юзаюилити, а не к функциональности в фундаментальном смысле слова.

Ниже таблица приоритетов снизу вверх она уменьшает уровень приоритетности:

yui	ExtJS	любой другой javascript framework
	Unobtrusive javascript
Unobtrusive CSS	или оба сразу	Unobtrusive CSS framework
	HTML

Наверное Вы скажете: "Что это за фигня такая вааще? Что за банальности?". А я отвечу: "Да, это банальности, но почему-то каждый раз начиная новую проект программист забывает эти банальности..."

Пример масса: у многих горе-любителей AJAX есть привычка фигачить в ссылки асинхронный запрос к серверной части, который возвращает кусок страницы. Итог: отключаем javascript и логи нарушается полностью. Про javascript framework'и я вообще молчю

О том, что на самом деле обычно нужно заказчику...

Я не трудоголик. Это факт. Есть просто интересные темы, которые меня могут иногда на долго поглатить, но трудоголизмом я никогда не отличался... Но вот случилось кое-что, что заставило меня всеръез задуматся о моей принадлежности к этой касте (трудоголиков).

Я занимался аудиторным фондом ТюмГНГУ чуть больше 2 недель. Решил достаточно большое количество проблем связных с адаптацией джанго форм к моим конктретным нуждам. Очень много всего понял про джангу.

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

 

Итак, кульминация:

- за 2 недели я сделал кучю коммитов

- написал много, очень много строк кода

- изматерил всех кто хоть как-то связан с имуществом нефтегаза

сегодня заглядываю в админку (в 500 раз) и понимаю, что реально заказчику нужно было, чтоб к модели данных, которой они пользуются какой-нить добрый человек приделал фильтрацию и скрыл из админки все лишние объекты. На это у меня ушло ровно 3 минуты. 2 недели псу под хвост.

 

ЗЫ. Зато Серегин диплом готов :)

ЗЫ 2. Я сильно поумнел :)

Отркыл для себя yahoo ui. Наезды на ExtJS.

В этом и нескольких следующих постах опишу свое знакомство с  Yahoo User Interface Library. Штука это, прямо скажу, замечательная, так как с недавних пор (после знакомства с ExtJS) меня радует все, что хорошо справляется со своими возможностями, но не тянет за собой ничего лишнего. Последнюю часть предыдущего предложения пожалуй опишу по подробней.

• ExtJS - классный фремворк для создания Интранет приложений.

Почему? Представьте, что грид. или форма, используют большие массивы данных (в гридах примеры не нужны, в формах - список стран, городов и пр.). Представьте, теперь, что Вы, чтоб это дело не тормозило, сделали динамическую подгрузку данных с сервера. Ура, вроде проблема решена, но известный факт что javascript машины в разных браузерах работают по разному.

Например, стал свидетелем того, как мой layout из 3 колонок с вложенным в него деревом, гридом и панелью картинок (но помню как точно называется компонент) грузился в опере за 3-7 секунд в фоксе (из за известного повисания в начале перегрузки страницы) 10-15, а в safari - рекрдные 30-40, причем бэнчмарк для этих браузеров дали такие результаты:

firefox 2.0.0.14 - 25172.2ms +/- 2.3%

Safari 3.1.1 - 6174.0ms +/- 7.1%

Ещё интересный материал по теме http://celtickane.com/webdesign/jsspeed2007.php, результаты которых подходят по смыслу больше (сравнивается работа с массивами), но парадокса все равно не объясняют.

• Если убрать из ExtJS стили он поплывет - спорное предположение, но не без основательное. Придумывать свои стили для ExtJS - сложная, рутинная работа.
• ExtJS очень плохо описан - факт, если сравнивать с yahoo ui, например. Ничего тут удивительного нет, консультации и поддержка - основная статья доходов создателей фреймворка.

Вывод: ExtJS - один хороший фреймворк можно было бы разделить на два отличных (javascript и стили), но тогда, видимо, было б сложней продавать поддержку  - ведь все стало б быстрей и проще :). ExtJS рано или поздно выйдет на Enterprise уровень, где ему и место и станет библиотекой для Visual Studio и пр. монстров. И попытки ограничть круг использующих ExtJS просто ради забавы уже сейчас видны - 2.1 версия под новой лицензией.

 

YUI, на первый взгляд, этими вещами не страдает. Наоборот, есть хорошая и очень подробная документация с примерами. По каждому примеру Вас ведут за ручкуу на хорошем английском :(.

Есть даже блог разработчиков в котором публикуют новости из мира yui. Там например, я узнал, что есть сниппет для django использующий YUI Loader как Django Middleware - AJAX, блин, полный.

Главное, что меня привлекает в YUI - возможность наряду с javascript'овыми извращениями сохранять RESTful подход к созданию веб-приложений, оставлять лазейку, в случае если отключен javascript, картинки. Хотя это параноя.

Google Apps API

Кто сказал не нельзя создавать почтовые аккаунты на гугль аппс? Я? Не может! Но факт.

На самом деле, можно.

Вот тому доказательство: creating user accounts.

Модуль написан на python'е, а значит прекрасно встраивается и в Plone и в Django проекты.

Полный список возможностей и объяснениями тут: http://code.google.com/intl/ru/apis/apps/gdata_provisioning_api_v2.0_reference_python.html#Create_Account_Example

Семантический разрыв передачи знаний между стадиями технического дизайна и написания кода

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

Далее цитата из курса "Визуальное моделирование: теория и практика"
Семантический разрыв визуальных моделей и программного кода

...визуальные модели, действительно удобные в работе, "склонны" терять исполняемую семантику. Другими словами, информация, которая в них содержится, оказывается недостаточно полной и детальной, чтобы по ней вычислитель мог бы выполнить свою работу. Ведь никакая "умная" генерация не может добавить то, что отсутствует изначально. Если же визуальные модели усложнять, чтобы они были пригодны для использования вычислителем, то очень часто они теряют наглядность и становятся бесполезными. Кому нужны непонятные, но полные описания программного обеспечения, выполненные с помощью визуальных моделей? Есть тексты на языках программирования, есть документы, есть возможность спросить, в конце концов, разобраться в коде самому…

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

Где выход?

Неудача решения вопроса с генерацией "в общем виде" не говорит о том, что это невозможно в частных случаях. Необходимо лишь понизить степень общности ситуации. Это можно сделать, создавая кодогерационные решения для ПО отдельных видов. Генерация кода по визуальным моделям успешно применяется в промышленности в следующих областях:
* в разработке схем реляционных баз данных;
* при создании событийно-ориентированных систем реального времени;
* при формализации бизнес-процессов компаний.
Эти области и будут подробно рассмотрены в этом курсе лекций.

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

конец цитаты

Есть очень занимательная статья о контекстной технологии программирования (1 и 2). Но она, ровным счетом, ничего не проясняет, хоть и выглядит как "решение всех наших проблем".

Можно лишь сделать вывод, что решение проблемы можно искать в:
* более высоком уровне абстракции языка, на котором ведется разработка;
* использование средств традиционных для проектирования представлений предметной области,но не на полную катушку, а частично.
Первое - нам не подходит, так как у нас с этим полный консенсус и никто язык менять не соберется. Второе - уже лучше, так как опыт показывает, что умл хорош на очень отдаленных от реализации стадиях, но потом, когда сложность диаграмм растет вместе с темпами их эволюции использовать умл становится просто не возможно.

Все это навеяло новую и очень необычную для меня мысль. А что если не пытаться заставить программистов следовать пусть даже 300 тысяч раз хорошей и академичной технологии программирования? Что если инструмент формализации предметной области, действительно, мог бы подстроиться под язык реализации?
Привыкшие быть ломателями стереотипов мышления неумытых программистов сами будут ломаться под новый инструмент. Прекрасно! Вот только я пока не знаю ничего про этот инструмент. И кстати, все это похоже на то, как сумасшедший разговаривает сам с собой. Усиленно что-то сам себе доказывает не получая ответа.

О тщетности всего сущего

Интересные размышления о обязательных шагах разработки и тестирования ПО, состоящие из семи правил встретил на страницах interface.ru. Много думал. Родил нечто подходящее нам:

1.Не стоит урезать рамки и бюджет проекта в угоду заказчику (старый принцип - с мудаками не работаем). Если заказчик не хочет брать за вашу цену - значит вам первому эта сделка не нужна.
2.Варианты использования не сложно поделить на основные и нефункциональные (можете прикопаться к словам). Дык вот, если функциональные требования не выполняются на все 100, а вот в этом месте офигительный AJAX, то это дерьмо, а не сайт!
3.Можно спроектировать все на свете, и даже в очень маленьких проектах. Можно в 30 диаграмма описать авторизацию и регистрацию пользователя, однако, если этот сложный интеллектуальный труд не породит паттерна, который можно будет использовать 2000 раз - Вы зря потратили свое время. И наверняка, не успели тупо протестировать функционал своего ПО.
4.Блин, как же все ж важно давать клиентам бриф, писать с ними ТЗ и использовать на всех этапах разработки документирование. Игнорирование этого правила может спасти в первых трех проектах, где заказчик папа или родной дядя, но с клиентами типа usilok.com все может быть на много плачевней.
5.Ну и последнее: не хило было б вести некую статистику по возникновению тех, или иных проблем. Чаще всего мы десятки раз наступаем на одни и теже грабли...