alexa.cpp

Minimalistic Cocoa application

2011-02-03T23:22:00.001+06:00

Some time ago I faced with problem - to write crossplatform application with GUI, but it should not contain any tool-specific resources like MSVC rc files, or xcode resources. It should build GUI in the most native way. Simplify problem: there was the following interface in existing code base, that I have to satisfy.

struct IWindow
{
  virtual void Create() = 0;
  virtual void DoEvents() = 0;
  virtual void Focus() = 0;
  virtual void Hide() = 0;
  virtual void Close() = 0;
  virtual bool IsClosed() = 0;
};

And an application should be designed to use the similar pattern (it comes from windows-os application as far you can see):

int main()
{
  IWindow* window = OSDependent::GetCurrentWindowSystem()->GetWindow();
  windiw->Create();
  window->Focus();
  while (!window->IsClose())
  {
    window->DoEvents();
    ///<! some logic should be placed here
  }
  return 0;
}
#ifdef __OBJC__
class MyWindow : public IWindow
{
public:
  ///!< .. methods of IWindow interface
protected:
  NSWindow* window_;
};
#endif // __OBJC__

After a lot of reading and number of tries, I made a native Cocoa window without any xcode-specific resource. Ta-da-dam!! :) The main function of this post:

void MyWindow::Create()
{
  NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
   
  [NSApplication sharedApplication];
  [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
        
  unsigned int styles = NSResizableWindowMask | 
    NSClosableWindowMask | 
    NSTitledWindowMask;
        
  NSRect rectanle = NSMakeRect(100, 100, 640, 480);
  window_ = [[NSWindow alloc] 
    initWithContentRect:rectangle
    styleMask:styles
    backing:NSBackingStoreBuffered 
    defer:NO];
  [window_ setTitle:@"(none)"];
  [window_ setReleasedWhenClosed:NO];
  [window_ 
    performSelectorOnMainThread:@selector(makeKeyAndOrderFront:) 
    withObject:nil 
    waitUntilDone:YES];
  [NSApp activateIgnoringOtherApps:YES];
  [NSApp finishLaunching];
        
  [pool release];
}

The most strange code here is setActivationPolicy code line. It allows window to be activated, receive keyboard and mouse event and more. I spent a lot of time to find it (this was my first macosx experience).

Next key of system - a message pump. Usually, it isn't necessary, because of usage [NSApp run]; functionality to make window application work. As far I understand NSApp run includes look-like code. In my case, I have to implement message cycle by myself. Here it is:

void MyWindow::DoEvents()
{
  NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
  NSEvent* event = [NSApp nextEventMatchingMask:NSAnyEventMask
    untilDate:[NSDate distantPast]
    inMode:NSDefaultRunLoopMode
    dequeue:YES];
  if (event) {
    [NSApp sendEvent:event];
    [NSApp updateWindows];
  }
  [pool release];
}

Other minor implementation, easy to get, but might be useful:

bool MyWindow::IsClosed() 
{
  return ![window_ isVisible];
}
void MyWindow::Focus()
{
  NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
  [window_ makeKeyAndOrderFront:nil];
  [pool release];
}
void MyWindow::Hide()
{
  NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
  [window_ orderOut:nil];
  [pool release];
}
void MyWindow::Close()
{
  [window_ close];
}

As for addition, we could add custom NSView to our window, here the defenition of derived view.

@interface MyView : NSView
{
  MyWindow* window_;
}

- (id)initWithFrame:(NSRect)rectangle;
- (id)initWithMyWindow:(MyWindow*)window;
- (MyWindow*)getWindow;
@end

@implementation MyView

- (id)initWithFrame:(NSRect)rectangle
{
  self = [super initWithFrame:rectangle];
  m_Window = 0;
  return self;
}
- (id)initWithMyWindow:(MyWindow*)window
{
  Math::Rect wr = w->GetRectangle();
  NSRect r = NSMakeRect(wr.x, wr.y, wr.Width, wr.Height);
  if (self = [self initWithFrame:r])
  {
    window_ = window;
  }
  return self;
}
- (MyWindow*)getWindow
{
  return window_;
}
- (BOOL)acceptsFirstResponder
{
  return YES;
}
- (BOOL)becomeFirstResponder
{
  return YES;
}
- (BOOL)resignFirstResponder
{
  return YES;
}
- (BOOL)canBecomeKeyView
{
  return YES;
}
@end

Final window create method:

void MyWindow::Create()
{
  NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
        
  [NSApplication sharedApplication];
  [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
        
  unsigned int styles = NSResizableWindowMask | 
    NSClosableWindowMask | 
    NSTitledWindowMask;
        
  NSRect rectanle = NSMakeRect(100, 100, 640, 480);
  window_ = [[NSWindow alloc] 
    initWithContentRect:rectangle
    styleMask:styles
    backing:NSBackingStoreBuffered 
    defer:NO];

  [window_ setTitle:@"(none)"];
        
  [window_ setReleasedWhenClosed:NO];
       
  view_ = [[MyView alloc] initWithMyWindow:this];
  [window_ setContentView:view_];
  [window_ makeFirstResponder:view_];
        
  [view_ setFrame:NSMakeRect(0, 0, rectangle.Width, rectangle.Height)];
       
  [window_ 
    performSelectorOnMainThread:@selector(makeKeyAndOrderFront:) 
    withObject:nil 
    waitUntilDone:YES];
  [NSApp activateIgnoringOtherApps:YES];
  [NSApp finishLaunching];
        
  [pool release];
}

That's all. Yes, this is not the most minimal cocoa application, but it is created without usage of xcode magic, and includes not-big code :) The most interesting and hard things have been found at cocoa with love.

P.S. Sorry for my bad english ^^

Populate fake data in django

2010-10-26T02:02:00.000+07:00

Задача - нагенерить N рандомных слов, которые хоть чуть-чуть похожи на настоящие слова (то есть подобие слогов). Халява на пайтоне:

>>> def gen_rand_strings(num):
...     import random
...     allchars = [chr(i) for i in range(97, 97+26)]
...     vowels = ['a', 'e', 'i', 'o', 'u', 'y']
...     consonants = [i for i in allchars if i not in vowels]
...     ret = []
...     for i in range(0, num):
...         s = ''
...         rr = random.randint(2, 6)
...         for j in range(1, rr):
...             s += random.choice(consonants)
...             s += random.choice(vowels)
...         ret.append(s)
...     return ret
>>> gen_rand_strings(20)
['vydohefy', 'hete', 'comegihu', 'sarabo', 'tyde', 'ro', 'mojuletabu', 'ruridaviqy', 'my', 'tafaluhy', 'teleniwu', 'xixy', 'cyky', 'hypakelo', 'kicuba', 'jekiqovazu', 'botaveci', 'byru', 'dolizojaca']

Зачем это понадобилось, да вот захотелось набить БД фейковыми данными :) примерно так (по проекту homebudget):

>>> from homebudget.purchases import models
>>> models.PurchaseTag.objects.count()
0
>>> new_tags = gen_rand_strings(20)
>>> for tag in new_tags:
...     ntag = models.PurchaseTag.objects.get_or_create(value=tag, norm_value=tag, owner=usernew)
...     ntag[0].save()
>>> models.PurchaseTag.objects.count()
20
>>>
>>> from datetime import date, timedelta
>>> last = date.today()
>>> dt = date(year=2010,month=05,day=1)
>>> oneday = timedelta(days=1)
>>> while (dt < last):
...     rr = random.randint(3, 10)
...     for i in range(0, rr):
...          tag = models.PurchaseTag.objects.get(value=random.choice(new_tags))
...          price = random.randint(1, 100)
...          purch = gen_rand_string(2)[0]
...          p = models.Purchase(name=purch,quantity=1.,price_for_one=price,price_total=price, purchase_date=dt, owner=usernew)
...          p.save()
...          p.tags.add(tag)
...          p.save()
...     dt += oneday

База забита фейковыми покупками за полгода, к каждой покупке привязан один из 20 новых тагов. Теперь можно спокойно тестить выборки для построения статистики. Халява как она есть.

хроники django или homebudget part 7

2010-10-18T00:29:00.001+07:00

После долго молчания, возвращаемся к нашим баранам.

Во первых, что обязательно нужно описать, так это передвижение с google-code на launchpad. Предпосылки:

во-первых плюсы DVCS системы:
1. банальные мелочи, у меня есть четыре машины с которых я колбашу код. Естественно, я один, про фитчи думаю один, изменения архаичные, некоторые нужно сразу в главную ветку, другие - только в бранчи. В свн-бранчи все оформлять тупо лень (т.к. о них нужно помнить). По этому колбашу в trunk-е. И синхронизировать 4 машины ой какая проблема - типа вчера уснул и часть не закомитил, а изменения были эпические. Работа встала на других машинах. В распределенной системе - каждая локальная копия по-сути бранч. Работотать на нескольких машинах в разы проще.
2. смерджить можно все что угодно, без последствий. В свн-е же для мерджа нужные крепкие нервы и холодные разум.
3. можно без проблем откатиться до любой версии. Кто как, но я это люблю.
во-вторых плюсы launchpad-а:
1. bazaar собственно.
2. Хостинг многих опен-сурс проектов, которые я использую (хотя бы убунта и терминатор)
3. всякие бонусы типа отображения публичного gpg ключа и активности пользователь.
4. есть публичная страничка на которой отображены все проекты пользователя. В гугль-коде такую не нашел. Мне это критично.
давно хотел провести глобальные изменения архитектуры
1. есть мой хостинг (пока не рассекреченный), крутится ngnix, заведен джанго-проект. В нем крутится homebudget (как не трудно догадаться). Иногда мне нужно добавлять новые приложения для личных целей (скорее не целей, а идей и экспериментов). Заводить новый процесс под это ой как не хочется, да и не логично. А в старой структуре свн-а был заведен репозиторий прямо на проект, и лежащие внутри приложения. Новые приложения хранятся (или не хранятся вовсе) в разных местах. Ну вот и логичнее всего мне вести репозитории по приложениям, а не по проекту. Так что от репозиторя для проекта было решено отказаться в пользу локального репозиторя. А приложения - в народ.
2. Еще один плюс приложений - манипулировать гораздо проще. Развертываешь в отдельной папке такую-то ревизию, ставишь на нее симлинк, а старый затираешь. Круто, да круто.
3. Хотя нужно сказать структура проект-приложение не совсем гибкая. Это не удобно, тупо не удобно. Нужно больше ветвления. Типа переиспользуемые под-приложения.

Как это делалось, да просто как можно догадаться.

изменил все межпроектные линки на использование глобальных "homebudget.purchases" и "homebudget.tagsfield"
вынес маппинг урлов из проектого urls.py в соответствующие файлы приложений. В проектном urls.py теперь стоит просто include bla-bla-bla.
разместил статик контент и темплейты по директориям проектов (т.е. было "homebudget/content/purchases/css", стало "homebudget/purchases/media/css" и тд)
в новый проект добавляется директория типа "static-content", в нее ставятся симлинки на директории "homebudget/purchases/media". MEDIA_ROOT смотрит на директорию "static-content". В итоге: из проекта до его статик файлов можно достучаться по пути "/site-media/purchases/css/" (работает MEDIA_URL, имя проекта, и путь по симлинке).
темплейтные директории прописываются явно в settings.py в TEMPLATES_DIR (типа "/homebudget/purchases/templates/"). Соответствующий код для взятия темплейтов был подправлен.
ну и проекты были добавлены в PYTHONPATH, типа "export PYTHONATH=${PYTHONPATH}:/path/to/project" где-то внутри "~/.bashrc"

Собственно ссылки:

https://code.launchpad.net/~alexa-infra/+junk/homebudget - новый репозиторий
http://code.google.com/p/homebudget-site/ старый репозиторий (будет апдейтиться по ключевым моментам, но рабочие измениния в нем не найти)

Посты по теме:

FrOSCon 2010

2010-08-27T23:16:00.000+07:00

Итак, пора уже представить миру мой отчет о том как проходила конференция FrOSCon 2010 (Free and Open Source Software Conference). Состоялась она 21-22 августа, в Германии, в "городке" Sankt-Augustin, в здании местного IT-технического университета.

почему "в городке" - насколько я понял, из объяснений друзей, участников конфы, и карты метро-трамваев - Санкт-Агустин это не совсем город, не совсем деревня, не совсем район города, но официально город. Изначально я приехал в Бонн (население около 300 тыс), но этого города не было в объявлении поезда, так как в 30 км от него находится Кельн где проживает около 3 млн. Бонн состоит из районов - давным давно они были деревнями, потом срослись и сохранили свои названия в названиях районов. Совсем рядом к Бону, ну полностью прилегают, без какой-то границы, еще штук 7-8 аналогичных городов, в числе которых и Санкт-Агустин, и Кельн.

Нужно сказать что конференция проходила пятый раз и выросла с маленькой тусовки в 10-20 человек в конференцию, объединяющую более одной тысячи человек. Организаторы, в бывшем студенты сего местного университета в один день сказали что-то типа "we will go build our own conference, with blackjack and hookers", договорились и сделали. Полный опен-сурс, полный кайф. Что у них получилось? Не маленькая локальная тусовка гиков, а действительно международная тусовка гиков. Хотя на конференции сильно чувствуется преобладание немецкого языка (большинство народу все-таки местные), но как водится в it-community "да че этот английский язык?! там все слова взяты из си-плюс-плюса!" - большинство нормально говорят по английски, и могу свободно изъясняться на двух языках. Как говорят, в этом году было предложение провести полностью конференцию (все доклады) на английском языке, но встала проблема, не все докладчики могли полностью свободно изъясняться на английском, такие дела. Но радует (как для человека без знания немецкого) что около 25% докладов были на английском. Этого вполне достаточно. Если есть вопросы - на них докладчик может ответить и на ломаном английском, но без микрофона.

Где это было. В августе в университетах не проводятся занятия, но все равно там находится туча народу, кто-то делает свой проект, кто-то просто тусуется. И понятно почему. Здание универа просто восхитительное, все очень и очень модерновое, все укомплектовано под завязку, в аудиториях очень сильно приятно находиться. Все семинарные комнаты оборудованы компами, за каждым местом студента. Вокруг универа какие-то архитектурные сооружения (типа гигантского магнита). Внутри куча работающих кафе. Пусть наши универы (вроде триждыпроклятого и родного НГУ) поперхнуться слюной. Организаторы полностью снимают это здание на выходные. Фойе и коридоры отводятся под стенды контор, лекционные аудитории - под доклады, семинарские аудитории - под проекты, столовая - под столовую, внутренний двор - под опен-эйр-пати.

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

Как проводилось. Достаточно скромно, вход для обычных людей на 2 дня - 5 евро, для коммерческих контор - 100 евро, для волонтеров - бесплатно. Вот вам и сила опен-сурса. Сколько нужно мозгоебаний и затрат для того что бы попасть на конфу мсфт? во-во. Стендов было много. bsd, debian, ubuntu, gentoo, centos - и все им смежные... gnome, kde, qt... postgresql, firebird, mysql... openoffice... zope, и че-то там еще для python-а... xen и че-то еще для виртуальщиков... куча прессы типа open-source-press где можно было в тридешево купить книжки (только на немецком)... какие-то проекты типа linux для школы, ноутбук каждому, космическая программа германии... был и гугль, и был (мне не известный) tarent... Всего не упомнил, но большинство охватил.

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

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

Free and Open Source Software in the Developing World Jon "maddog" Hall это было в качестве keynotes, человек-директор Linux International, такой тихинький свиду дедушка, отжег по полной. Полная ненависть к Windows, много умных вещей про развитие стран третьего мира, про коммерческий и опен-сурсный код. Очень профессиональный доклад. Куча инфы, перемешка шуток, очень хорошие ораторские способности. Основные идеи: странам третьего мира навязывается использование проприетарного софта, в большинстве случаев которому имеются полностью свободные аналоги, все происходит от удалености и незнания, на это тратится уйма денег.
Agile in a Year Thomas Ferris Nicolaisen - доклад не про опен-сурс, а про технолигии которые доступны всем, про очень удобные методы разработки, про то как одна компания из Бонна внедряла Agile процессы на практике. Замечательный доклад, как мне показалось, очень много практических вещей было освещено, что было сложно что было легко, зачем и почему. Тема конечно же очень общирная, но тут все было представлено на одном конкретном примере. Допустим "... таким образом для выполнения основных фитч нашей программы мы выбрали систему канбан, и использовали ее напротяжении месяца". Говорилось про то, как в данной конторе пришли к идее ежедневных stand-up meetting, про переселения девелоперов, про функции менеджеров, про то что agile-master бесполезный человек и тп. Очень интересно. Многим компаниям хотя бы до таких мыслей расти и расти, а тут люди не боятся и экспериментируют. Не понравилось то что пример очень уж узкий вышел - компания состоит около 10-15 человек. Что понравилось: графическое представление презинтации, сразу же на все изображение выводятся все слайды, логические переходы между ними обозначены стрелочками, когда разговор переходит на какой-то слайд - тогда камера "приближается"/"перемещается" к нужному участку карты. Очень удобно понимать логику всего доклада, да и запоминается намного лучше, что и отокуда.
Inside the Cassandra distributed database Jonathan Ellis - доклад про не-реляционную БД cassandra. Я все время знал про существование таких бд, про то как их применять, и зачем они нужны, но у меня никогда не было причины задействовать такую БД. Это используется в facebook, в amazon s3, в twitter, в digg и т.д. Там где очень много данных, где данные однотипные и всегда растут в колличестве. После прослушивания доклада я наконец-то проникся идеей, это круто. Любое возможное представление, любые масштабы. Да сложно проектировать и программировать. Но если рассматривать такой тип БД как средство оптимизации - то есть уже полностью есть модель sql обычной базы, все отлажено, выставлены все нужные индексы и тп., но падает производительность на простых запросах, базу нужно перетаскивать на несколько машин и т.д. - тогда вполне реально перетащить базу на cassandra, переделать все sql запросы - и будет простое чудо. Докладчик рассказывал про внутреннее устройство, как происходит запись и чтение, что такое "ключ" в данной бд, как строится дата-кластер, какие возможности есть. Все очень понятно. Не понравилось то что в зале возникло много откровенно тупых вопросов по устройствам дата-кластеров, возможно это сложно для обычных людей. Мне очень понравилось.
Be lazy, make automation Fabrizio Manfredi - говорилось про то как построить свой собственный "умный" дом. Идея в основном такая: существуют девайсы которые можно купить (типа розетка с lan/wlan интерфейсом), поставить их в свой дом для освещения и т.п., потом настроить домашний софт на влючение/выключение по рассписанию (по cron-у), или на показания других датчиков (типа датчиков движения). Входишь в комнату - свет включается, выходишь - выключается. Нужно разогреть баню пока едешь в общественном транспорте? - подключаешься к домашнему серверу или отправляешь смс-ку. Кондиционер сам выключается когда открыты окна. Согласитесь, это круто. Докладчик объяснял как это все делается, на каких протоколах базируется система, как лучше строить архитектуру (от базового - провода или wifi, до сложного - распределенной системы), какие опен-сурсные проекты реализуют доступ к протоколам. Да это очень прикольно, но дорого, одна розетка стоит 10-20 евро, так как в ней стоит как минимум один чип. Плюс, вопрос секурити вообще не ставится (тупо твой сосед может выключить тебе свет). В общем я сильно проникся, но пока это мне не по карману, да и строить такое нужно только в собственном жилье.
Antifeatures, Benjamin Mako Hill - тоже keynotes, тоже очень знаменитая персона (бог debian-а и gnu, как-никак), тоже очень интересно. Что сразу заметилось - очень быстрый и очень понятный английский. Человек тоже замечательный оратор, где нужно вставит конфузную шутку на предмет Windows и тп. Основные идеи: каким образом строится стоимость софта, за что реально приходится платить, какие минусы (не баги) может приносить использование софта, ну и собственно идеи GNU. Один из первых примеров - Windows NT Workstation и Windows NT Server - отличались в цене на 800 баксов, а фактически - одной записью в реестре. За что платится разница? во-во, наводит на мысли.
MySQL Plugins - what are they? Sergei Golubchik - рассказ про еще один форк mysql, про то как в достаточно большой проект была впилена сисмета плагинов и расширений. Вообще говоря - ничего особенного по части проги я не услышал, все очень привычно. Ничего не скажу как это смотрится со стороны знатоков mysql, к коим я не отношусь. Запомнилось одно - английский от русского человека слышно за версту, это точно.
HiPHoP for PHP - докладчик - человек из комманды facebook, у них сейчас много опен-сурсных проектов. Что такое php я сам себе слабо представляю, попал на доклад случайно, но он мне понравился, я достаточно хорошо туда попал. Есть какая-то магия в том что делает facebook, во-первых если им не нравится php - они его исправляют и не стесняются, во-вторых - у них очень даже рационализаторский подход. Так как пхп - интерпретируемый язык и на фейсбуке сидят миллионы, то давайте перенесем код пхп на цпп. Все, на. Другими словами - сделаем свой интерпритатор пхп который будет рождать бинарный код. Вот и вся суть проекта. Да, есть проблемы со скоростью работы, удобством и т.п. Но это работает в разы быстрее и стабильнее! Я проникся.

Интересно заметить когда в зале возникла куча вопросов по поводу скорости, и компиляции докладчик просто свернул презинтацию, открыл консоль и показал что и как делается. Да реально, вся аудитория засекала ~20 секунд. Вот еще одна фишка it-конференций, можно продемострировать все за пару секунд.
GNOME 3 Hendrik Richter - тут мало чего сказать, так как доклад был на немецком, да и решают только картинки. Могу сказать три вещи: это будет скоро, много добавится графических наворотов, они уже думают об GnomeOS.
1, Qt, Profit! Daniel Molkentin - честно говоря этот доклад был расчитан на людей которые скажут "ой, а что такой qt?", по-этому особых эмоций у меня не возникло. В большей части было показано как обычное десктоп приложение портируется на symbian, "то что можно его отлаживать" ну и все. Жидко как-то, не уровень qt, это всяко.

Еще был Social Event - огромная пьянка на открытом воздухе, я там был и мне понравилось. Особо нужно сказать как она проводилась. Есть собственная валюта конференции "Bon" - 1 Bon = 1 euro, пиво и еду можно покупать только за Bon-ы. Маленький стаканчик пива - 1 Bon, Большой стакан - 2 Bon + 1 Bon (fant), Мясо (ааа!) - 3 Bon. Вот там монжно было бухнуть много пива и заобщаться с любым человеком. Были награждения проектов (которые я собственно даже не видел), было файер-шоу, был большой торт... у, там было круто!!

Это все что я смог написать про это событие, многое еще крутится в голове, но изложить будет сложно. Выводы - таких конференций очень не хватает в России, очень не хватает конференций такого уровня (типа тут ставятся вопросы - что делать если у тебя дата-кластер на 1000 машин, а не банальное - как установить линукс новичку), просто не хватает аналогичных по духу событий. А организаторам FrOSCon - отдельное спасибо, все было просто круто!!

htc hero is not detected as drive

2010-08-26T19:33:00.000+07:00

Только что словил гигантский глюк андройда (htc hero), надо сказать первый за полгода работы. В коем веке понадобилось перекачать фотографии с телефона на комп. Втыкаю его в линуксовую машину, и ничего не происходит. Лампочка зарядки светится, но никаким другим образом комп не определяет подключенный к нему девайс. dmesg вообще ничего не сказал. Стандартная процедура: выключить, вытащить батарею, включить - не помогла. Глянул в гугле, народ старным образом колдует и после этого телефон определяется (типа прочистить usb разъем и тп). Ни один из этих вариантов не подошел.

Следующая мысль что все таки глючит ядрышко моего линукса. Благо совершенно случайно рядом оказалась виндовая машина. Но, на ней я опять таки ничего не увидел. Комп отказывался понимать что в usb разъем что-то вообще вставлено, как собственно и телефон. Шла только зарядка.

Что меня спасло: то что на борту стоял 2.1 андройд и было доступно обновление ядра до 3.32.411.2, после его установки, о чудо, телефон корректно стал определяться компом. Может быть кому это поможет

хроники django или homebudget part 6

2010-08-07T17:03:00.001+07:00

Давно не писал в хроники, а проект уже ушел далеко, так что сначала догоню версию блога до версии репозитория :) Сегодня будет html-css-javascript, делаем календарик для просмотра месяца.

Итак, у нас есть master page следующего содержания. Из отличий с предыдущим его описанием - добавил блок head, через который дочерние страницы могут добавлять скрипты и стили в html код страницы.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <link rel="stylesheet" href="content/css/main.css" />
    <title>Homebudget site: {% block title %} manage yourself {% endblock %}</title>
{% block head %}{% endblock %}
</head>
<body>
<div id="content">
{% block content %}
{% endblock %}
</div>
</body>
</html>

Еще есть убогий month view который выводит обычный список день-сумма.

{% extends "purchases/master.html" %}

{% block title %} monthly view {% endblock %}

{% block content %}
<p>Date: {{view_date}} </p>
{% if day_price_dict %}
    <ul>
        {% for key,value in day_price_dict.items|dictsort:"0" %}
            <li>
                {{key}} 
                <b>{{value}}</b> 
                <a href='/purchases/view/{{key.year}}/{{key.month}}/{{key.day}}/'> Edit </a>
            </li>
        {% endfor %}
    </ul>
{% else %}
    <p>No purchases yet</p>
{% endif %}
<p>
    Total: <b>{{month_total}}</b>
</p>

<a href='/purchases/add/'>Add</a>
{% endblock %}

Я хочу отобразить календарик. Самое простое решение - тупо таблица, ряды - недели, столбцы - дни недели. Но как сказал знакомый верстальщик "деревня, таблицы - это прошлый век, нужно использовать div-ную верстку". В чем она заключается, как я понял для себя, это выделение всех элементов в блоки, и задание их относительного расположения через стили. В итоге было подсмотрено решение в одном проекте.
В темплейте month-view заключаем список день-сумма в div с id-шником dashboard
```
<div id="dashboard">
<ul>
...
</ul>
</div>
```
Создаем файлик dashboard.css в content/css, добавляем его в monthview темплейт.
```
{% block head %}
<link rel="stylesheet" href="content/css/dashboard.css" />
{% endblock %}
```
Теперь все происходит в dashboard.css, сначала выставим фиксированную ширину для контейнера dashboard и уберем дефолтные стили списка с ul.
```
#dashboard {
    width: 900px;
    display: inline;
    position: relative;
    float: left;
}
#dashboard ul {
    list-style: none outside none;
}
```
Элементу списка (можно сказать элементу календаря) выставляем фиксированный размер - высоту и ширину. Размер вычисляем по формуле "ширина dashboard-а" разделить на 7, минус пара пикселей. Логика простая - в неделе 7 дней, по этому в контейнер должно помещаться не более 7 элементов. А плюс-минус пиксели, это нужно для учета бордеров элементов. А так же выставим float: left, этот магический параметр определяет с какой стороны будут располагаться соседние элементы. То есть для left следующий элемент выстроится слева от текущего. Если располагать некоторым абстрактным мышлением то можно понять к чему все это приведет. Правильно, к календарю.
```
#dashboard li {
    float: left;
    position: relative;
    width: 120px;
    height: 120px;
    text-align: center;
}
```

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

def month_view(request, year, month):
    """
    List all day in month, with daily sum
    """
    try:
        view_date = datetime.date(year=int(year), month=int(month), day=1)
    except:
        raise Http404
    from django.db.models import Q
    plist = Purchase.objects.filter(Q(purchase_date__year=view_date.year) & Q(purchase_date__month=view_date.month)).order_by('purchase_date')

    y, m, d = view_date.timetuple()[:3]
    dt_next = datetime.date(year=y+((m+1)/12), month=(m+1)%12, day=d)
    day_price_dict = {}

    first_calend = view_date
    while first_calend.weekday() != 0:
        first_calend -= datetime.timedelta(days=1)
    dt = first_calend
    while dt < view_date:
        day_price_dict[dt] = (Decimal('0.0'), 'prev_month')
        dt += datetime.timedelta(days=1)

    month_total = Decimal('0.0')
    while (dt < dt_next):
        purchases_day = plist.filter(purchase_date__day=dt.day)
        day_total = Decimal('0.0')
        for it in purchases_day:
            day_total += it.price_total
        month_total += day_total
        weekend = dt == datetime.date.today() and 'today' or dt.weekday() >= 5 and 'weekend' or 'day'
        day_price_dict[dt] = (day_total, weekend)
        dt += datetime.timedelta(days=1)

    last_calend = dt
    while last_calend.weekday() != 0:
        day_price_dict[last_calend] = (Decimal('0.0'), 'prev_month')
        last_calend += datetime.timedelta(days=1)

    return render_to_response('purchases/month_view.html', locals())

Теперь сделаем нормальное отображение дня (ячейки календаря). Для этого сначала выставим классы для элементов. sum для суммы дня, edit для линки перехода на день, date для числа календаря. Для самой ячейки нужно добавить класс дня, полученный в предыдущем пункте.

<div id="dashboard">
    <ul>
        {% for key,value in day_price_dict.items|dictsort:"0" %}
            <li class="{{value.1}}">
                <span class="date">{{key.day|stringformat:"02i"}}</span>
                {% ifnotequal value.1 'other_month' %}
                <span class="sum">{{value.0}}</span> 
                {% endifnotequal %}
                <a class="edit" href='/purchases/view/{{key.year}}/{{key.month}}/{{key.day}}/'>Edit</a>
            </li>
        {% endfor %}
    </ul>
</div>

Потом обозначим для них стили отображения внутри ячейки. Выставим top-left-right-bottom, для этого понадобится position:absolute.

#dashboard .date {
    font-size: 60px;
    position: absolute;
    left: 10px;
    top: 10px;
}
#dashboard .sum {
    font-weight: bold;
    bottom: 5px;
    right: 5px;
    position: absolute;
    font-size: 20px;
}
#dashboard .edit {
    position: absolute;
    right: 5px;
    top: 5px;
}

Теперь мы займемся дизигнерством. То есть разукрасим календарь. Так как необходимые навыки отсутствуют напрочь, и вообще мы дальтоники, то спиздим. Открыл для себе клевый сайт на котором можно выбрать комбинацию сочетающихся цветов. Мой выбор такой. В соотвествии этому выставим цвета для всех элементов.
```
#dashboard li {
    background: none repeat scroll 0 0 #D5E1DD;
    border: 1px solid white;
    font-color: white;
    cursor: pointer;
}
#dashboard .prev_month {
    background: none repeat scroll 0 0 #747e80;
}
#dashboard .weekend {
    background: none repeat scroll 0 0 #F7F3E8;
}
#dashboard .today {
    background: none repeat scroll 0 0 #F2583E;
}
#dashboard .hover {
    background: none repeat scroll 0 0 #77BED2;
}
#dashboard .date {
    color: white;
}
#dashboard .sum {
    color: #2B3E42;
}
```
Ну и последние штрихи. При наведении на день курсора будем менять цвет ячейки. Для этого понадобится клиентский javascript. Будем использовать мега рулезную библиотеку jQuery. Есть несколько способов ее подключить.
- Самый простой и стандартный. Скачать себе jquery, и добавить в статические ресурсы сайта. Использовать можно следующим образом (добавляем в head):
```
<script src="content/common/js/jquery-1.4.2.js"></script>
```
- Использовать гугл-апи. Способ матер и говорят для оптимизации кеширования само оно, но для себя я отметил следующий минус - для локальной разработки он тормозит сильно. Да и кол-во запросов увеличивается. В общем я от него отказался в пользу первого. Использовать можно следующим образом (добавляем в head):
```
<script src="http://www.google.com/jsapi" type="text/javascript"></script>
<script type="text/javascript">
    google.load("jquery", "1.4.2");
</script>
```
- Что-нить еще, типа подключить с какого-нить хостинга.

Заполучив jQuery можно решить задачу с изменением цвета под курсором.

<script type="text/javascript">
$(document).ready(function(){
    $('#dashboard li').bind("mouseenter", function() {
        var pthis = $(this)
        pthis.addClass('hover')
    });
    $('#dashboard li').bind("mouseleave", function() {
        var pthis = $(this)
        pthis.removeClass('hover')
    });
});
</script>

Посты по теме:

compiz headtracking

2010-07-24T03:43:00.001+07:00

Моя цитата из твиттера: "собрал эту игрушку, забавно и бесполезно, но кайфа - вагон! хочу большой монитор! http://www.youtube.com/watch?v=kTNG1GN4VV8"

Итак вдохновившись... Теперь о том как она ставилась

Хочу предупредить: у меня ubuntu 10.04, тачка домашне-девелоперская, много на ней чего стоит, так что кой-чего может и не оказаться в вашей системе. Не стоит бояться, как только проблема - сразу же внимательно читаем ошибку и ищем недостающий пакет. В общем, стоит начать с того что - обновляем систему. Главная цель - получить compiz-fusion 0.8+

Очень бодро качаем сам headtracking плагин, и смотрим на то как он не собирается.

mkdir projects/headtrack
cd projects/headtrack/
git clone --depth 1 git://anongit.compiz-fusion.org/users/klange/headtracking
cd headtracking/
make

Говорит что-то про bcop, быстро находим в репозитории
```
apt-cache search compiz-fusion-bcop
sudo apt-get install compiz-fusion-bcop
```
Совершенно аналогичным методом разрешаем остальные зависимости.
```
sudo apt-get install compiz-dev libcompizconfig0-dev libtool libtool highgui libhighgui-dev
```
Примерно где-то здесь начнется проблема с opencv. ВАЖНО: не стоит искать в репозитории libcv - хотя она там и есть, но увы не заработает, очень старая сборка, проверено. Это была моя большая ошибка, не повторяйте ее.

Собираем руками последнюю версию opencv из репозитория:

mkdir projects/opencv
cd projects/opencv
svn co https://opencvlibrary.svn.sourceforge.net/svnroot/opencvlibrary/tags/latest_tested_snapshot
cd latest_tested_snapshot/opencv
mkdir release
cd release/
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D BUILD_PYTHON_SUPPORT=ON ..
make

После того как ~~вы сварили и попили чаю~~ собралась opencv, устанавливаем ее в систему.
```
sudo make install
sudo vim /etc/ld.so.conf.d/opencv.conf
sudo ldconfig -v
```
Теперь финально билдим headtracking и устанавливаем его в систему:
```
cd projects/headtracking
make clean
make
sudo make install
```
Теперь идем в настройки compiz-а, жмем клавишу extraz, там headtracking. Включаем его. Окошки видоизменились. Нажимаем галку - General/Webcam head track. Теперь если веб-камера включилась и изображение поплыло в какую-то сторону, то все правильно сделано. Можно наслаждаться. Если нет и камера не включилась - что-то значит у вас не по фен-шею или чего еще, типа генетики. А скорее всего тупо web-камера не совместима с video4linux, чего и советую проверять :)
Когда у вас заболит шея (как у меня), можно поинтересоваться как это все работает. Для ленивых хинт:
```
cd projects/opencv/latest_tested_snapshot/opencv/samples/c/
chmod +x build_all.sh 
./facedetect
```

хроники django или homebudget part 5

2010-06-27T15:06:00.007+07:00

За посленее время много чего натворил в проекте, попытаюсь все изложить.

довел до ума систему тегов
добавил South к проекту для удобной работы
переделал логику добавления/редактирования покупок
сделал красивое отображение месяца

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

South - удобный процесс миграции БД

для начала я обновил себе django до последней дев-сборки (в репозиториях убунты все-то лежит 1.1).
```
sudo apt-get remove python-django
cd ~/devtools
svn co http://code.djangoproject.com/svn/django/trunk/ django
cd django
python setup.py install
```
стоит проверить что django проекты не потеряли работоспособность (:

Устанавливаем south (для этого нужен mercurial)

cd ~/devtools
hg clone http://bitbucket.org/andrewgodwin/south/
cd south
sudo python setup.py install

Добавляем south в installed_app (в settings.py)
```
INSTALLED_APPS = (
     ...
     'south',
)
```

для параноиков - backup/restore существующей бд.

Backup:

sudo -u databaseuser pg_dump homebudget > dump_db

Restore:

sudo -u postres psql homebudget2 < dump_db

создаем таблицы для south в проекте (это последний раз когда мы сделали syncdb(: )
```
./manage.py syncdb
```
теперь если бд пустая (т.е. таблицы для проектов не созданы), добавляем проекты в installed_apps и выполняем
```
./manage.py schemamigration purchases --initial
./manage.py migrate purchases
```
если данные в ней уже были, то: создаем начальную точку миграции
```
./manage.py schemamigration purchases --initial
```
исправляем скрипт создания (комментим все строки с созданием таблиц)
```
purchases/migration/0001_initial.py
```
накатываем "псевдо" изменения
```
./manage.py migrate purchases
```
теперь закоменченные строки можна убрать - для истории
основной сценарий работы c South
- делаем изменения в модели
- создаем автоматическую точку миграции
```
./manage.py schemamigration purchases --auto
```
- проверяем сгенеренный код в purchases/migration/XXXX_randomname.py
- если что-то не так - правим код в методах backward и forward
- в объекте orm находится замечательная django orm :)
```
allpurchases = orm.Purchase.objects.all()
```
- накатывание изменений на БД
```
./manage.py migrate purchases
```
- посмотреть все миграции (звездочками помечены те которые успешно прошли)
```
./manage.py migrate purchases --list
```
- если хочется смигрировать только данные
```
./manage.py datamigration purchases my_super_migration_of_data
```
- или можно даже вот так
```
./manage.py schemamigration purchases --empty my_super_migration_of_data
```

Таги

как уже упоминалось ранее таги были добавлены самопальные. Работают примерно так - в модели Purchase есть поле ManyToMany к модели Tag. Дефолтная реализация ManyToMany откидывается. В форму насильно добавляется новое CharField, переопределяются методы загрузки и сохранения формы, в которых как раз идут операции с полем m2m и CharField. Все делается в ручную. Это не никак не нравилось, так как чтобы переиспользовать эти таги пришлось бы прибегать к copy-paste, что не есть хорошо. В общем решил продолжить поиски компонент:
- django-tagging - жутко наворочанный пакет, вроде бы есть все что нужно, все очень кастомно. но того как оно сделано я вряд ли скоро пойму. много-много черной магии для выполнения простых операций. много, очень много sql-я (без orm-а). Сразу же был откинут.
- django-taggit проект поменьше чем предыдущий. но черная магия опять таки присутствует. в некоторых моментах я тупо не разобрался.
- tagsfield от Ивана Сагалаева. Вот оно то что нужно. Идея проста - наследуемся от ManyToManyField и заменяем дефолтный widget на собственный. Кода ну очень мало, все предельно понятно. Выбрал я его. Конечно же понадобились изменения.
первым делом копируем к себе tagsfield, добавляем его в installed_apps
изначально проект работает так: в html записывается список всех тагов и список всех тагов объекта, через javascript все это управляется - юзер может добавлять и убирать теги обекта, может добавлять новые. Когда форма сабмитится список активных тагов сохраняется в поле m2m.
для моего подхода (de.li.cious style таги) было сделано следующее
поле MultipleHiddenInput было заменено на TextInput. Поясняю - при сабмите приходил список значений hidden-input-ов, а мне нужно только одно text-input поле.
```
class TagsFormField(forms.Field):
    text_widget = forms.TextInput
```
собственно загрузка списка тагов (метод render):
```
'value_tags': " ".join(value_tags)
```

из модели убрал поле created и переименовал модель в BaseTag (зачем - ниже)

class BaseTag(models.Model):
    value = models.CharField(max_length=50)
    norm_value = models.CharField(max_length=50, editable=False)

сохранение:

def save_form_data(self, instance, data):
    splitted = data.strip().split(' ')
    tags = [self._get_tag(value) for value in splitted]
    setattr(instance, self.attname, tags)

шаблон виджета:

<div id="{{ id }}" class="tagsfield">
<input type="text" name="{{ name }}" value="{{ value_tags }}" />
</div>

удалил больше не нужные файлы и зачистил js и css файлы. Еще были изменения, но все незначительные, так что лучше их смотреть в репозитории.
теперь об одном ограничении оригинального кода - все таги хранятся в одной таблице. То есть если навешать таги на два класса - таги у них будут общие. Плохо. Для решения использовал еще один уровень абстракции, в приложении Purchases создал новый класс PurchaseTag который является наследником BaseTag. Теперь в бд будет две таблицы - одна для BaseTag из приложения TagField и одна для PurchaseTag из приложения Purchase. Таги для них не пересекаются :) Ну и собственно TagField одинаково хорошо работает для PurchaseTag класса. Тем более в последствии можно кастомизировать PurchaseTag и добавить к нему дополнительные поля. В файле purchases/models.py (старый класс Tag уже затерт)
```
from homebudget.tagsfield import fields
from homebudget.tagsfield.models import BaseTag
class Purchase(models.Model):
    ... 
    tags = fields.TagsField('PurchaseTag')

class PurchaseTag(BaseTag):
    pass

class PurchaseItemForm(ModelForm):
    class Meta:
        model = Purchase
        exclude = ('purchase_date',)
```
Ну и в коде везде где обращались к Tag теперь обращаемся к PurchaseTag, ну и из мелочи - поле name изменилось на value.
Как проходила миграция данных (замена старых таго на новые). У меня база уже забита. Собственно для этого и прикручивался South (см. выше)
Сначала была таблица для приложения TagField (чтобы не было никаких проблем)
Потом было добавлена модель PurchaseTag в проект Purchases, в модель Purchase было добавлено поле ntags = fields.TagsField('PurchaseTag'), старое поле tags = models.ManyToManyField('Tag') не удаляя.
Первая попытка миграции. Не работает (!!) и South отправляет на страницы http://south.aeracode.org/wiki/MyFieldsDontWork http://south.aeracode.org/docs/customfields.html#extending-introspection. Типа дописывайте сами себе правила на собственные поля. Ну ведь использовано поле отнаследованное от m2m, значит и вести оно должно себя также.. Значит спиздим определение ManyToManyField из кода south-а
```
rules = [
(
    (TagsField,),
    [],
    {
        "to": ["rel.to", {}],
        "symmetrical": ["rel.symmetrical", {"default": True}],
        "related_name": ["rel.related_name", {"default": None}],
        "db_table": ["db_table", {"default": None}],
        "through": ["rel.through", {"ignore_if_auto_through": True}],
    },
),
]
from south.modelsinspector import add_introspection_rules
add_introspection_rules(rules, ["^homebudget\.tagsfield\."])
```
Поставим это прямо возле определения TagsField-а.

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

class Migration(DataMigration):
    def forwards(self, orm):
        plist = orm.Purchase.objects.all()
        for p in plist:
            old_tags = p.tags.all()
            for i in old_tags:
                norm_value = i.name.lower()
                tag, created = orm.PurchaseTag.objects.get_or_create(
                    norm_value = norm_value,
                    defaults = {'value': i.name}
                )
                p.ntags.add(tag)
                p.tags.remove(i)
            p.save()
        old_tags = orm.Tag.objects.all()
        for i in old_tags:
            i.delete()
    def backwards(self, orm):
        "Write your backwards methods here."
        plist = orm.Purchase.objects.all()
        for p in plist:
            old_tags = p.ntags.all()
            for i in old_tags:
                tag, created = orm.Tag.objects.get_or_create(
                    name = i.value,
                )
                p.tags.add(tag)
                p.ntags.remove(i)
            p.save()
        old_tags = orm.PurchaseTag.objects.all()
        for i in old_tags:
            i.delete()

Теперь удаляем модель Tag (старую) и поле tags. Апдейтим базу через South.
Все хорошо, только поле называется ntags... Переименовываем поле. Смотрим в скрипт сгенеренный South-ом - не порядок, он пытается удалить нашу таблицу и создать новую. Исправляем его ошибку и накатываем изменения
```
class Migration(SchemaMigration):
    def forwards(self, orm):
        db.rename_table('purchases_purchase_ntags', 'purchases_purchase_tags')

    def backwards(self, orm):
        db.rename_table('purchases_purchase_tags', 'purchases_purchase_ntags')
```
Теперь все окей :)

Посты по теме:

хроники django или homebudget part 4

2010-06-14T13:41:00.004+07:00

Выдалось время и появилось настроение. Чего-то нового сваял :)

Первой целью стояло добавление тагов. Очень полезная вещь для организации однотипных данных. Посмотрел что предлагает интернет на этот вопрос. Есть проект django-tagging, типа все готовое прямо из коробки под джангу. Не понравился по нескольким причинам - я не понял как он работает (какие-то мега-архи приемы используются для управления тагами, типа прямых запросов к бд), куча не нужных мне наворотов, находится он бете и имеет баг лист, да и народ от него не в восторге. Вообще вопрос построения тагов теоретически выглядит довольно простым - так что было решено отказаться и самому написать простенькое решение, для целей самообучения имхо лучше. Когда понадобится облако тагов - я подумаю в сторону перехода на сей стандартный плагин. Мое требование такое - чтобы было одно поле на форме, в котором записаны все таги итема через пробел, при сохранении это поле split-ится по пробелам, и к итему добавляются/убираются теги. Как узналось в процессе - это de.li.cious style таги.

Отправной точкой является модель тага

class Tag(models.Model):
    name = models.CharField('keyword, bookmark or term', max_length=100)

и отношение many-to-many к модели purchase

class Purchase(models.Model):
    ...
    tags = models.ManyToManyField('Tag')

Обновляем схему базы. У нас появляется новая таблица Тагов, и таблица отношения таг-покупка (по foreign-ключам из тагов и покупок). Нужно заметить что таблица PurchaseItem не меняется, значит все правильно.
Таким образом получилась следующая штука, которую лучше всего опробовать на shell-е:
```
from homebudget.purchases.models import Purchase, Tag
t = Tag(name='beer')
t.save()
p = Purchase.objects.filter(name=u'туборг')[0]
p.tags.add(t)
p.save()
[i.name for i in p.tags.all()]
[i.name for i in t.purchases_set.all()]
```
Нужно заметить, что пока объект Purchase не материализован (не сохранен) в базе, у него нет поля tags. И наоборот, пока Tag не создан в базе у него нет поля purchases_set.
Если сейчас оставить все как есть и посмотреть что находится на вьюхах добавления и редактирования, то может стать плохо. Так как я использовал ModelForm для генерации html-формы для Purchase - для всех полей подставилась стандартная реализация. И для поля ManyToManyField она тоже есть, и выглядит прям отвратительно (тупой селект). Минусы - совершенно не подходит под мое представление, и добавить новый тег - нужна отдельная форма. Так что нах стандарты!
В PurchaseItemForm добавляем новое собственное поле, и удаляем из представление оригинальное поле tag модели PurchaseItem
```
from django.forms import CharField
class PurchaseItemForm(ModelForm):
    ...
    tags_inner = CharField()
    ...
    class Meta:
        model = Purchase
        exclude = ('tags',)
```
Правильное поле есть, но оно никак не обрабатывается. Сначала мы его заполним данными. Как мне кажется - лучше всего это сделать через override функции __init__ формы. Сначала вызываем родной __init__ (в котором как мы сделали - уже нет оригинального поля tags), потом заполняем собственное поле tags_inner тагами, разделенными пробелами. Проверка на null-ы нужна как раз для создания и редактирования (пока объект Purchase не создан, у него нет поля tags).
```
class PurchaseItemForm(ModelForm):
    ...
    def __init__(self, *args, **kwargs):
        super(PurchaseItemForm, self).__init__(*args, **kwargs)
        if kwargs.has_key('instance'):
            inst = kwargs['instance']
            if inst is not None and inst.pk is not None:
                self.fields["tags_inner"].initial = " ".join([i.name for i in inst.tags.all()])
```
Теперь сохранение. Я выбрал решение через override функции save (которая вызывается при сохранении данных формы из вьюхи). Сначала - обязательно вызываем базовый метод (чтобы объект Purchase наверняка сохранился в базе), потом - вытаскиваем из cleaned_data значения поля tags_inner. Далее понятные операции - split по пробелам, получаем все таги буквенно, потом создаем новые, удаляем несуществующие, и сохраняем финально.
```
def save(self, *args, **kwargs):
        inst = super(PurchaseItemForm, self).save(*args, **kwargs)
        tags = self.cleaned_data["tags_inner"].strip().split(' ')
        for tag in tags:
            if len(Tag.objects.filter(name=tag))==0:
                new_tag = Tag(name=tag)
                new_tag.save()
            if len(inst.tags.filter(name=tag))==0:
                inst.tags.add(Tag.objects.get(name=tag))
        for tag in inst.tags.all():
            if tag.name not in tags:
                inst.tags.remove(tag)
        inst.save()
```
Ну вроде бы с реализацией все - можно пробовать. Какие минусы сейчас есть: отсутствует валидация, отсутствует зачистка тагов к которым не привязан не один итем, поле tags теперь обязательное для заполнения, решение деревянное и не гибкое. Запишу в todo :) А пока нужно наполнить тагам базу.

После того как база заполнена можно сделать вьюху для просмотра статистики по тагам. Во views.py добавляем purchases_by_tag

def purchases_by_tag(request, tag_name):
    try:
        tag = Tag.objects.get(name=tag_name)
    except:
        raise Http404
    total = Decimal('0.0')
    for item in tag.purchase_set.all():
        total += item.price_total
    return render_to_response('purchases/tag_view.html', {
        'total': total,
        'tag': tag,
    })

Добавляем новый темплейт tag_view.html

<p>Tag: {{tag.name}}</p>
<ul>
    {% for item in tag.purchase_set.all %}
        <li>
            {{item.name}}
            <b>{{item.price_total}}</b>
            {{item.purchase_date}}
            <a href='/purchases/edit/{{item.pk}}/'>Edit</a>
        </li>
    {% endfor %}
</ul>
<p>Count: {{tag.purchase_set.count}}</p>
<p>Total: {{total}}</p>

Добавляем новое правило урлов в urls.py:

urlpatterns = patterns(
    ...
    (r'^purchases/tags/(?P\w+)/$', 'purchases_by_tag'),
)

Теперь по ссылке http://127.0.0.1:8000/purchases/tags/beer/ можно узнать когда, и на какую в сумму мы выпили пива :)

Можно навести красивости, типа в daily view добавить в каждую строчку таги связанные с покупкой, типа
```
Tags:
   {% for tag in p.tags.all %}
   <span>{{tag.name}}</span>
   {% endfor %}
```
Для реализации тагов мне в один момент понадобился дебаг, использовал для этого модуль logging, очень удобный надо сказать, вот так его заставить работать (output идет в консоль локального сервера, что архи удобно):
```
import logging
logging.basicConfig(
    level = logging.DEBUG,
    format = '%(asctime)s %(levelname)s %(message)s',
)
```
а вот так легко использовать:
```
logging.debug(p.tags)
```
Еще по мелочам, из области рефакторинга, наткнулся на мега функцию locals - она возвращает все локальные переменные из области видимости, в виде словаря 'имя переменной'-'значение'. Это позволило значительно сократить код на render_to_response, до:
```
return render_to_response('purchases/month_view.html', {
    'view_date': view_date,
    'dict': day_price,
    'total': month_total,
})
```
после:
```
return render_to_response('purchases/month_view.html', locals())
```
И это в каждой вьюхе, очень удобно. Конечно же пришлось поправить все темплейты и вьюхи на предмет именования переменных, но так все таки намного лучше.
На последок добавил Master Page - по крайней мере так оно обзывается в ASP.NET. Нужно это для двух вещей - чтобы все страницы имели общую часть - в мастере, и чтобы меньше писать кода. После коротких поисков нашел что это в джанге реализуется через наследование темплейтов читать тут. В общем по простому: добавил master.html
```
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <link rel="stylesheet" href="content/css/main.css" />
    <title>Homebudget site: {% block title %} manage yourself {% endblock %}</title>
{% block head %}{% endblock %}
</head>

<body>

<div id="content">
{% block content %}
{% endblock %}
</div>

</body>
</html>
```
Теперь он будет у меня основным шаблоном. Любой другой шаблон может его расширять и дополнять. Все элементы block - можно использовать в дочернем шаблоне. Пока я полностью не разобрался, но то что есть сейчас меня устраивает. Вот например новый шаблон tag_view.html
```
{% extends "purchases/master.html" %}

{% block title %} view purchases by tag {% endblock%}

{% block content %}
<p>Tag: {{tag.name}}</p>
<ul>
    {% for item in tag.purchase_set.all %}
        <li>
            {{item.name}}
            <b>{{item.price_total}}</b>
            {{item.purchase_date}}
            <a href='/purchases/edit/{{item.pk}}/'>Edit</a>
        </li>
    {% endfor %}
</ul>
<p>Count: {{tag.purchase_set.count}}</p>
<p>Total: {{total}}</p>
{% endblock %}
```
Кстати говоря, в мастере используется ссылка на css-документ, он должен лежать в папке обозначенной в конфигурации как MEDIA_ROOT, и для этого пути должно быть правило в урл-реврайтере... Для чего оно нужно? чтобы в можно было вынести весь статический контент в отдельный сайт, необремененный обработчиками джанги и тп. В settings.py:
```
MEDIA_ROOT = '/home/username/projects/homebudget/content/'
...
MEDIA_URL = '/content/'
```
И в urls.py
```
from django.conf import settings
if settings.LOCAL_DEVELOPMENT:
    urlpatterns += patterns("django.views",
        url(r"%s(?P.*)/$" % settings.MEDIA_URL[1:], "static.serve", { "document_root": settings.MEDIA_ROOT, })
    )
```
Переменная LOCAL_DEVELOPMENT заведена на будующее.

Посты по теме:

хроники django или homebudget part 3

2010-05-16T14:54:00.004+07:00

Этот мини проект обзавелся public репозиторием на google code. Выбрал я его из-за встроенного баг-трека и вики. По большому счету лучше подошел бы launchpad, но с гуглокодом я уже работал и более-менее там освоился. Из минусов - репозиторий svn, а у меня локально все ведется в bzr. Ну это не беда, пройденный этап ;)

Из последних приготовлений кода к первому коммиту - были убраны все пароли и пути из settings.py, убирал примерно следующим образом

Создал файл в домашней директории .homebudget-settings со следующим содержанием:

DATABASE_NAME = 'homebudget'
DATABASE_USER = 'username'
DATABASE_PASSWORD = 'password'
DATABASE_HOST = 'localhost'
DATABASE_PORT = '1234'

MEDIA_ROOT = '/home/username/projects/homebudget/content/'

SECRET_KEY = '-thisismysecretkey!'
TEMPLATE_DIRS = (
    '/home/username/projects/homebudget/templates',
)
LOCAL_DEVELOPMENT = True

В файле settings.py потер значения одноименных переменных, примерно так
```
DATABASE_NAME = ''
DATABASE_USER = ''
DATABASE_PASSWORD = ''
DATABASE_HOST = ''
DATABASE_PORT = ''
```
В конец файла settings.py была добавлены следующие строчки:
```
from os.path import expanduser
execfile(expanduser('~/.homebudget-settings'))
```
Проект готов к выкладыванию на публику :)

Посты по теме:

хроники django или homebudget part 2

2010-05-10T22:42:00.006+07:00

Итак, как обстоят дела: после первого рывка я скурпулезено заполнял базу через существующие странички. Иногда когда скрипели зубы - добавлял функциональность. А так могу сказать - сейчас меня более-менее устраивает, все работает как и должно, есть куда развивать систему, следующие шаги ясны. Собственно, вот продолжение хроник, информация восстановлена по change-ам. Все измения фискируются в source-control'е в качестве которого я успешно использую bazaar.

Добавляем просмотр отдельного дня. То есть это выборка из базы по конкретному дню, ссылки на редактирование отдельных записей (покупок), собственно ценники, и сумма за день. Как - добавляем новый метод в контроллер, добавляем отдельную вьюху для html-я, добавляем правило для урлов. all right, let's get started
Чтобы было понятно - начинаем с правила для урлов. хотим чтобы запрос для странички дня выглядел типа blah-blah-blah/view/day/2010/04/30 ну типа никаких идиотских GET параметров. В urls.py добавляем следующее правило:
```
(r'^purchases/view/(?P<year>\d{4})/(?P<month>\d{1,2})/(?P<day>\d{1,2})/$', 'day_view')
```
Новый метод контроллера (в файле purchases/views.py), логика такая - добавленное в предыдущем пункте правило добавит необходимые параметры день/месяц/год, мы из них делаем нормальный объект datetime (если не получается - типа 68 января - то 404), потом забираем из базы все записи Purchase с этой датой, берем сумму по ценам и выводим все во вьюху.
```
def day_view(request, year, month, day):
    try:
        dt = datetime.date(year=int(year), month=int(month), day=int(day))
    except:
        raise Http404
    plist = Purchase.objects.filter(purchase_date = dt)
    price_sum = Decimal('0.0')
    for it in plist:
        price_sum += it.price_total

    return render_to_response('purchases/day_view.html', {
        'date': dt,
        'list': plist,
        'price_sum': price_sum,
    })
```
Создаем новый темплейт вьюхи templates/purchases/day_view.html с примерно следующим содержимым. Логика такая - пробегаем по списку значений как на главной странице, выводим ссылки на изменение и тд, выводим отдельно заранее посчитанный тотал.
```
<p>Date: {{date}} </p>
{% if list %}
    <ul>
        {% for p in list %}
            <li>
                {{p.name}} 
                <b>{{p.price_total}}</b> 
                <a href='/purchases/edit/{{p.pk}}/'>Edit</a>
            </li>
        {% endfor %}
    </ul>
{% else %}
    <p>No purchases yet</p>
{% endif %}
<p>
    Total: <b>{{price_sum}}</b>
</p>

<a href='/purchases/add/'>Add</a>
```
Проверяем на работоспособность. Должно работать :)
Теперь делаем тоже самое но для месяца. Тупо по аналогии.
Добавляем аналогично просмотру дня правило для просмотра месяца (доступ по ссылке типа blah-blah-blah/view/day/2010/04/):
```
(r'^purchases/view/(?P<year>\d{4})/(?P<month>\d{1,2})/$', 'month_view')
```
В методе контроллера имеем сразу же несколько проблем. Первая - нужно сделать запрос на совпадение и года, и месяца одновременно (в случае с просмотром дня - все было просто - тупо совпадение даты). Лечим следующим методом:
```
from django.db.models import Q
plist = Purchase.objects.filter(Q(purchase_date__year=dt.year) & Q(purchase_date__month=dt.month))
```
Вторая проблема - нет в стандартной библиотеке пайтона функций типа добавить месяц. Можно есть - добавления отрезка времени, но так как в месяцах непостоянное кол-во дней такой способ выглядит очень корявым. Какой по-проще способ нашел - по дате составить новую с месяцем+1.
```
# dt - дата
y, m, d = dt.timetuple()[:3]
dt_next = datetime.date(year=y+((m+1)/12), month=(m+1)%12, day=d)
```
Третья проблема - как передать данные во вьюху. Я выбрал способ через словарь (dictionary) - в котором date => purchase_item.

Вот получившийся код. Логика такая - получаем год/месяц - строим дату как первое число месяца. Выбираем из базы все записи purchase за этот месяц. Потом прибавляя по дню пока не прийдем к первому числу следующего месяца, попутно собирая суммы за каждый день и сумму за весь месяц.

def month_view(request, year, month):
    try:
        dt = datetime.date(year=int(year), month=int(month), day=1)
    except:
        raise Http404
    from django.db.models import Q
    plist = Purchase.objects.filter(Q(purchase_date__year=dt.year) & Q(purchase_date__month=dt.month)).order_by('purchase_date')

    y, m, d = dt.timetuple()[:3]
    dt_next = datetime.date(year=y+((m+1)/12), month=(m+1)%12, day=d)
    day_price = {}
    month_total = Decimal('0.0')
    while (dt < dt_next):
        purchases_day = plist.filter(purchase_date__day=dt.day)
        day_total = Decimal('0.0')
        for it in purchases_day:
            day_total += it.price_total
        month_total += day_total
        day_price[dt] = day_total
        dt += datetime.timedelta(days=1)

    return render_to_response('purchases/month_view.html', {
            'date': datetime.date(year=int(year),month=int(month),day=1),
            'dict': day_price,
            'total': month_total,
        })

Создаем новый темплейт templates/purchases/month_view.html

<p>Date: {{date}} </p>
{% if dict %}
    <ul>
        {% for key,value in dict.items %}
            <li>
                {{key}} 
                <b>{{value}}</b> 
                <a href='/purchases/view/{{key.year}}/{{key.month}}/{{key.day}}/'>Edit</a>
            </li>
        {% endfor %}
    </ul>
{% else %}
    <p>No purchases yet</p>
{% endif %}
<p>
    Total: <b>{{total}}</b>
</p>

<a href='/purchases/add/'>Add</a>

Проверяем. Опа, не работает - все дни вперемешку, хотя и выставлено для запроса order_by. А тут начинаются темные, не хорошо документированные особенности джанги по сортировке словаря (я об этот момент чуть голову не сломал). Есть миллион решений - типа сделать буферный список из отсортированных ключей и его передавать с моделью, и тп. Но вот чтобы применить к for-у для словаря сортировку прямо в темплейте - нашел только один:
```
for key,value in dict.items|dictsort:"0"
```
Сделаем так чтобы после Edit-а или Add-а происходил редирект на просмотр использованного дня.

Метод Add-а:

def purchase_add(request):
    if request.method == 'POST':
        form = PurchaseItemForm(request.POST)
        if form.is_valid():
            form.save()
            purchase_date = form.cleaned_data["purchase_date"]
            return HttpResponseRedirect('/purchases/view/%s/%s/%s/' % purchase_date.timetuple()[:3]) 
    else:
        form = PurchaseItemForm()

    return render_to_response('purchases/purchase_add.html', {
        'form': form
    })

Метод edit-а:

def purchase_edit(request, purchase_id):
    try:
        item = Purchase.objects.get(pk=purchase_id)
    except Purchase.DoesNotExist:
        raise Http404

    if request.method == 'POST':
        form = PurchaseItemForm(request.POST, instance=item)
        form.save()
        purchase_date = form.cleaned_data["purchase_date"]
        return HttpResponseRedirect('/purchases/view/%s/%s/%s/' % purchase_date.timetuple()[:3])
    
    form = PurchaseItemForm(instance=item)
    return render_to_response('purchases/purchase_edit.html', {
        'form': form,
        'id' : purchase_id
    })

Делаем добавление покупки на конкретный день (а не только на сегодня) - те если хотим добавить покупку за вчера со страницы вчерашнего дня - то поле дата должно быть корректно подставлено на вчера. Другими словами blah-blah-blah/purchases/add/ - должно добавлять покупку на сегодня, а blah-blah-blah/purchases/add/2010/04/30 - должно подставлять 2010.04.30

В urls.py добавляем следующий словарь для определения сегодня:

import datetime
year, month, day = datetime.datetime.today().timetuple()[:3]
today_dict = {'year':year, 'month':month, 'day':day}

И следующее правила взамен старого add-а:

    (r'^purchases/add/$', 'purchase_add', today_dict),
    (r'^purchases/add/(?P<year>\d{4})/(?P<month>\d{1,2})/(?P<day>\d{1,2})/$', 'purchase_add'),

Метод add должен теперь выглядеть так:

def purchase_add(request, year, month, day):
    if request.method == 'POST':
        form = PurchaseItemForm(request.POST)
        if form.is_valid():
            form.save()
            purchase_date = form.cleaned_data["purchase_date"]
            return HttpResponseRedirect('/purchases/view/%s/%s/%s/' % purchase_date.timetuple()[:3]) 
    else:
        try:
            dt = datetime.date(year=int(year), month=int(month), day=int(day))
        except:
            dt = datetime.today() 
        purchaseitem = Purchase()
        purchaseitem.purchase_date = dt
        form = PurchaseItemForm(instance=purchaseitem)

    return render_to_response('purchases/purchase_add.html', {
        'form': form
    })

Ну и собственно линка внутри templates/purchases/day_view.html
```
<a href='/purchases/add/{{date.year}}/{{date.month}}/{{date.day}}/'>Add</a>
```

Посты по теме:

хроники django или homebudget part 1

2010-04-04T22:03:00.008+07:00

В общем решил вплотную изучить django фреймворк. Есть опыт работы с asp.net mvc фреймворком, есть знания питона. Почему бы и нет?) Как изучить новую технологию максимально эффективно? считаю что нужно сразу же делать какое-нить реальное приложение. Типа учебная тревога.

Здесь буду публиковать хроники моих изысканий, не хочется чтобы они пропали зря. Не в коем случае не претендую на самое оптимальное решение и описание. Вообще происходящее будет много дублировать офф tutorial и примеры из документации с http://docs.djangoproject.com/, в этом нет ничего странного - я по этому и учусь ;)

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

инсталируем django (надеюсь питон уже есть)
```
sudo apt-get install python-django
```
инсталируем psycopg2 модуль к питону для работы с бд
```
sudo apt-get install python-psycopg2
```
инсталируем postgre
```
sudo apt-get install postgresql
```
проверям что все установилось и демон запусчен:
```
ps -A | grep postgres
```
запускаем консоль постгреса
```
sudo -u postgres psql postgres
```
меняем пользователю postgres пароль
```
\password postgres
```
выходим из консоли
```
\q
```
создаем базу
```
sudo -u postgres createdb homebudget
```
создаем новый django проект
```
django-admin.py startproject homebudget
```
проверям что все работает
```
cd homebudget
./manage.py runserver
```
в браузере переходим на линку
```
http://127.0.0.1:8000/
```

редактируем settings.py

DATABASE_ENGINE = 'postgresql_psycopg2'
DATABASE_NAME = 'homebudget'
DATABASE_USER = 'postgres'
DATABASE_PASSWORD = 'наш пароль'
DATABASE_HOST = 'localhost'
DATABASE_PORT = '5432'

запускаем синхронизацию проекта с базой (нужно чтобы работали installed_applications из настроек проекта)
```
./manage.py syncdb
```
на вопрос You just installed Django's auth system, which means you don't have any superusers defined. отвечаем да и вводим данные
стартуем новое приложение в проекте
```
./manage.py startapp purchases
```

редактируем models.py

from django.db import models
 
class Purchase(models.Model):
    name = models.CharField('identifier of item', max_length=200)
    quantity = models.FloatField('quantity of purchase')
    price_for_one = models.DecimalField('price for one item', max_digits=10, decimal_places=2)
    price_total = models.DecimalField('price for all', max_digits=10, decimal_places=2)

добавляем приложение в installed_apps, в файле settings.py добавляем в список
```
'homebudget.purchases'
```
синхронизируем базу с моделями
```
./manage.py syncdb
```
забиваем базу тестовыми данными (можно через pgadmin), заходим в консоль джанги
```
./manage.py shell
```

там вбиваем

from homebudget.purchases.models import Purchase
p = Purchase(name='beer',quantity=3, price_for_one=48, price_total=144)
p.save()
quit()

добавляем новое правило для url rewriter-а в файле urls.py
```
(r'^purchases/$', 'homebudget.purchases.views.index')
```

создаем новое view, редактируем файл purchases/views.py

from django.template import Context, loader
from homebudget.purchases.models import Purchase
from django.http import HttpResponse

def index(request):
    all_list = Purchase.objects.all()
    t = loader.get_template('purchases/index.html')
    c = Context({
        'all_list': all_list,
    })
    return HttpResponse(t.render(c))

создадим папку templates в каталоге проекта, и подпапку purchases
```
mkdir templates
mkdir templates/purchases
```
добавляем папку templates в проектные шаблоны, правим файл settings.py (путь абсолютный!)
```
TEMPLATE_DIRS = (
    '/home/username/projects/homebudget/templates',
)
```

создадим файл templates/purchasesindex.html

{% if all_list %}
    <ul>
        {% for p in all_list %}
            <li>{{p.name}} <b>{{p.price_total}}</b></li>
        {% endfor %}
    </ul>
{% else %}
    <p>No purchases yet</p>
{% endif %}

запускаем сервер, в браузере переходим на страницу. ништяк? ;)
```
http://127.0.0.1:8000/purchases/
```
добавляем новое поле к модели (purchases/models.py)
```
    purchase_date = models.DateField('date of buying')
```
так как джанга не поддерживает миграцию бд, делаем руками
```
./manage.py sql purchases
```

получаем sql код, лезем в postgre и правим в нем таблицу

ALTER TABLE purchases_purchase ADD COLUMN purchase_date date;
UPDATE purchases_purchase SET purchase_date=now();
ALTER TABLE purchases_purchase ALTER COLUMN purchase_date SET NOT NULL;

создаем add форму

в файл models.py добавляем следующий класс

from django import forms

class PurchaseItemForm(forms.Form):
    name = forms.CharField(max_length=200)
    quantity = forms.FloatField()
    price_for_one = forms.DecimalField(decimal_places=2)
    price_total = forms.DecimalField(max_digits=10, decimal_places=2)
    purchase_date = forms.DateField()

в файл views.py добавляем новую вьюхую

from homebudget.purchases.models import PurchaseItemForm
def purchase_add(request):
    form = PurchaseItemForm()
    t = loader.get_template('purchases/purchase_add.html')
    c = Context({
        'form': form
    })
    return HttpResponse(t.render(c))

создаем новый файл templates/purchases/purchase_add.html

<form action="/purchases/add/" method="post">
{{ form.as_p }}
<input type="submit" value="Save" />
</form>

в файл urls.py прописываем новый маппинг паттерн
```
(r'^purchases/add/$', 'homebudget.purchases.views.purchase_add'),
```
запускам дев сервер, в браузере переходим на страницу
```
http://127.0.0.1:8000/purchases/add/
```
теперь добавляем сохранение данных, это будет происходить на той же самой странице по post запросу

в файл views.py добавляем обработку post запроса и сохранение

from django.http import HttpResponse, HttpResponseRedirect
def purchase_add(request):
    if request.method == 'POST':
        form = PurchaseItemForm(request.POST)
        if form.is_valid():
            name = form.cleaned_data['name']
            quantity = form.cleaned_data['quantity']
            price_for_one = form.cleaned_data['price_for_one']
            price_total = form.cleaned_data['price_total']
            purchase_date = form.cleaned_data['purchase_date']
            item = Purchase(name=name, quantity=quantity, price_for_one=price_for_one, price_total=price_total, purchase_date=purchase_date)
            item.save()
            return HttpResponseRedirect('/purchases/') 
    else:
        form = PurchaseItemForm()
    t = loader.get_template('purchases/purchase_add.html')
    c = Context({
        'form': form
    })
    return HttpResponse(t.render(c))

проверям в браузере, в случае удачного сохранения будет переход на список всех
займемся совершенствованием

в файл views.py добавляем

from django.shortcuts import render_to_response

ужасные loader.get_template, Context, return HttpResponse(..) заменяем на простую конструкцию
```
    return render_to_response('purchases/purchase_add.html', {
        'form': form
    })
```
в файле models.py вставляем ModelForm взамен идиотского дублирующего кода из модели
```
class PurchaseItemForm(forms.ModelForm):
    class Meta:
        model = Purchase
```

да и после этого во вьюхе не нужно перечислять все поля.. теперь будет так:

def purchase_add(request):
    if request.method == 'POST':
        form = PurchaseItemForm(request.POST)
        if form.is_valid():
            form.save()
            return HttpResponseRedirect('/purchases/') 
    else:
        form = PurchaseItemForm()

    return render_to_response('purchases/purchase_add.html', {
        'form': form
    })

в файле urls.py тоже изменения:

urlpatterns = patterns(
    'homebudget.purchases.views',
    (r'^purchases/$', 'index'),
    (r'^purchases/add/$', 'purchase_add'),
)

запускаем дев сервер и все перепроверяем, что работает как до рефакторинга
добавляем edit для элемента, по быстрому

в файл views.py

def purchase_edit(request, purchase_id):
    try:
        item = Purchase.objects.get(pk=purchase_id)
    except Purchase.DoesNotExist:
        raise Http404

    if request.method == 'POST':
        form = PurchaseItemForm(request.POST, instance=item)
        form.save()
        return HttpResponseRedirect('/purchases/')

    form = PurchaseItemForm(instance=item)
    return render_to_response('purchases/purchase_edit.html', {
        'form': form,
        'id' : purchase_id
    })

создадим файл templates/purchases/purchase_edit.html

<form action="/purchases/edit/{{ id }}/" method="post">
{{ form.as_p }}
<input type="submit" value="Save" />
</form>

в файл index.html добавим линки для редактирования и добавления нового элемента:

{% if all_list %}
    <ul>
        {% for p in all_list %}
            <li>
                {{p.name}}
                <b>{{p.price_total}}</b>
                {{p.purchase_date}}
                <a href='/purchases/edit/{{p.pk}}/'>Edit</a>
            </li>
        {% endfor %}
    </ul>
{% else %}
    <p>No purchases yet</p>
{% endif %}

<a href='/purchases/add/'>Add</a>

в файл urls.py

    (r'^purchases/edit/(?P<purchase_id>\d+)/$', 'purchase_edit'),

запускаем дев сервер и наслаждаемся

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

Посты по теме:

2010-02-27T02:10:00.003+06:00

This is a debug hell routine... 500 page views per working day by one developer - it's possible! P.S. fucking IE6

bzr+svn friends?

2010-01-17T15:57:00.002+06:00

Уже говорил про мою проблему с bzr-svn плагином. Так вот после умозаключений и тестов, я пришел к оптимальному для меня решению - удалить bzr-svn плагин, пользоваться bzr и svn поотдельности. В существующем checkout от svn я проинициализировал bazaar shared репозиторий (bzr init-repo) прямо в папке svn-резозитория. В svn-е я поставил игнор файлов .bzr, а в Bazaar поставил игнор файлов .svn и почти усе. Потом добавил в bazaar все файлы из svn-овской папки (bzr add). Все локальные изменения теперь я бренчую через bzr, туда же постоянно комитаю свои собственные маленькие изменения. Когда фитча локально оттестирована, я сливаю ее в основной bazaar репозиторий. И только потом идет коммит в обычный svn-репозиторий. С апдейтами из svn, благодаря тому что базарный репозиторий mirror - проблем не возникает. Да, я понимаю что комманд стало чуток больше, но прелесть все равно есть. Мое локальное счастье наступило.

bzr+svn

2010-01-13T10:04:00.005+06:00

Очень хотел использовать Bazaar для работы с svn, но увы и ах bzr-svn needs to access the root to e.g. find out what the repository layout is что не позволяет использовать его на закрытых репозиториях. Практически выглядит так bzr checkout svn+https://svn.myserver.com/myproject/src src bzr: ERROR: A Subversion remote access command failed: Server sent unexpected return value (403 Forbidden) in response to PROPFIND request for '/' Ну вот только если удастся получить доступ к корню репозитория... или перестать пользоваться такими svn репозиториями. Пока смотрю в сторону Git, там нет такой проблемы.

2009-11-19T00:13:00.001+06:00

xckd как всегда отжигает. жизненно и в тему.

asp.net, website, objectdatasource

2009-10-24T13:12:00.003+07:00

В asp.net есть такой тип проекта WebSite. Он отличается от WebApplication тем, что проектный сайт не создается, любой попавшый в папку файл добавляется в сайт, и самое главное - сайт не собирается в отдельную сборку. На продакшн сайт можно добавлять новые странички не компилируя их (ну есть конечно же предкомпиляция сайта, но см. далее). Каждая страничка компилируется через iis сервер в собственную сборку с рандомным именем. Как это разруливает сервер - загадка.

Для простой логики где все находится в пределах одной страницы все окей, а вот когда требуется вызвать код находящийся на другой страничке - начинаются проблемы: одна страничка ничего не знает о другой (т.к. находится в собственной сборке). Обычное решение - выносить такой нужный код в отдельную собственную сборку, типа библиотеки, закинуть ее в bin директорию сайта, подключать ее в страничках сайта и использовать в коде. Хорошо то оно хорошо. А что делать если ну никак не хочется выносить одну единственную функцию в библиотеку, код которой нужен только на одной единственной страничке?

Пример - нужно реализовать bind грида через object data source, и не через что-либо иное (такое может понадобится для использования фишек грида типа редактирования, удаления в табличке, сортировки, пейджинга и т.п.). Проблема сводится к тому что в SelectMethod нужно написать имя метода, в SelectParameters - параметры, а в TypeName - полное название типа где находится метод. А класс лежит в своей собственной сборке, а имя генерируется рандомно. Единственное решение проблемы - динамически заполнять поле TypeName на этапе загрузки страницы. Вот финальный код:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="myprojectclass.aspx.cs" Inherits="myprojectclass" %>

<asp:GridView ID="gridView1" runat="server" DataSourceID="objectDataSource1" AutoGenerateColumns="True" />
<asp:ObjectDataSource ID="objectDataSource1" runat="server" SelectMethod="GetData" TypeName="" ></asp:ObjectDataSource>

public partial class myprojectclass : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
         // ...
         objectDataSource1.TypeName = String.Format("{0}, {1}", this.GetType().FullName, this.GetType().Assembly);
         gridView1.DataBind();
    }
    
    public System.Collections.Generic.List<DataItem> GetData() {
         // ...
    }
}

Повторюсь - это будет работать в пределах одной страницы, код другой странички получить не получится. Только через собственную сборку. Выводы: 1. никогда не использовать WebSite 2. использовать только WebApplication - так как все получается логично и понятно 3. По возможности никогда не использовать ASP.NET - есть другие более удобные инструментарии веб-разработки

Подсветка синтаксиса в блоге

2009-10-18T20:25:00.004+07:00

Прикрутил к блогу подсветку синтаксиса кода. Некоторое время я провел за поисковиком, все примеры были не очень и в основном старые. Нашел кое-что подходящее на heisencoder.net. В итоге и использовал эту компоненту syntaxhighlighter. Еще есть старый репозиторий на гугл-коде. Жалко что пример на том блоге устарел и почему-то у меня не заработал. Благо у автора компоненты очень подробная док-ция Компонента представляет собой набор javascript-ов и css шаблонов, заходим на http://alexgorbatchev.com/pub/sh/ выбираем нужную версию и качаем. Можно и не качать, а использовать прямые ссылки на хостящиеся файлы. В общем внутри head-а странички вставляем следующий код:

<link href='http://alexgorbatchev.com/pub/sh/2.1.364/styles/shCore.css' rel='stylesheet' type='text/css'/>
<link href='http://alexgorbatchev.com/pub/sh/2.1.364/styles/shThemeDefault.css' rel='stylesheet' type='text/css'/>
<script src='http://alexgorbatchev.com/pub/sh/2.1.364/scripts/shCore.js' type='text/javascript'/>
<script src='http://alexgorbatchev.com/pub/sh/2.1.364/scripts/shBrushCSharp.js' type='text/javascript'/>
<script src='http://alexgorbatchev.com/pub/sh/2.1.364/scripts/shBrushXml.js' type='text/javascript'/>
<script src='http://alexgorbatchev.com/pub/sh/2.1.364/scripts/shBrushCpp.js' type='text/javascript'/>

<script type='text/javascript'>
  SyntaxHighlighter.config.clipboardSwf = 'http://alexgorbatchev.com/pub/sh/2.1.364/scripts/clipboard.swf';
                SyntaxHighlighter.config.bloggerMode = true;
  SyntaxHighlighter.defaults['gutter'] = true;
                SyntaxHighlighter.all();
</script>

Тем самым мы добавили нужные стили (у меня используется дефолтный, но вообще доступно несколько) и скрипты (здесь я добавил html, cpp, c#), настроили компоненту должным образом. За подробными комментариями по назначению, списку всех параметров и всех возможных скриптов - на сайт производителя. Потом в html-код сообщения добавляем

<pre class="brush: cpp; toolbar: true;">
 #include <iostream>
    int main() {
  std::cout << "hello" << std::endl;
 
 }
</pre>

P.S. Главное не забывать ескейпить символы...

Индусы среди нас

2009-10-15T22:40:00.004+07:00

Один человечек написал подобный код:

  class Item {
    public static void UpdateItem(Item _item) {
    // ...
    }
  }

  Item it;
  // ...
  Item.UpdateItem(it);

Попахивает безграммотностью. Не логично использовать статический метод который принимает экземпляр собственного класса. Я попросил человечка избавиться от статического метода. Код был переписан вот в это:

  class Item {
    public void UpdateItem(Item _item) {
    // ...
    }
  }
  
  Item it;
  // ...
  new Item().UpdateItem(it);

Да, оказывается у некоторых в крови индусские гены и они в тайне по ночам молятся шестируким богам. И почему нельзя сделать вот так, по простому:

  class Item {
    public void UpdateItem() {
    // ...
    }
  } 

  Item it;
  // ...
  it.UpdateItem();

Не вероятно, но факт

2009-08-19T01:54:00.008+07:00

Есть десктоп, на него давно заведена сетка, полностью настройка по dhcp и т.п. Есть ноут, сиротливо лежащий без инета. Было решено завести на нем сетку, для начала хотя бы через вторую сетевуху (покупать вайфай точку лом). К тому же на ноуте упала винда и не хотела восстанавливаться. Взял с полки старенькую сетевуху от dlink-а, воткнул ее в комп. Убунта правильно ее определила, корректно добавила в устройства и сделала на нее интерфейс. Как по инструкции с гугла, во вторую сетевуху втыкаем провод, другой конец заводим в ноут. Т.к. операцонки на ноуте нету - стартуем с live-cd. на десктопе с помощью ifconfig -a получаем имя нового интерфейса (eth1). на десктопе в /etc/network/interfaces пишем: auto lo eth0 eth1 iface lo inet loopback iface eth0 inet dhcp iface eth1 inet static address 195.168.0.1 netmask 255.255.255.0 network 195.168.0.0 broadcast 195.168.0.255 на ноуте: auto lo eth0 iface lo inet loopback iface eth0 inet static address 195.168.0.120 netmask 255.255.255.0 getway 195.168.0.1 перезапускаем сетку и там и там: sudo /etc/init.d/networking restart на ноуте делаем: ping 195.168.0.1 в ответ получаем: destination host unreachable. Че за нах?!! Спокойно, пробую еще несколько раз... может быть с проводом что-то не так, да нет только что друзья обжали и просветили. Лезем в dmesg | grep eth ... видим: eth1 бла-бла-бла "no link". Че за нах?!! Провод же воткнут правильно!! Ладно, забиваю - сетевуха очень старая - может быть в ней косяк. И правда - выдергиваю шнур из второй карточки и вставляю в первую - пинг пошел!! В топку карточку значитсо. На первый раз с меня хватило - решил просто перелить данные с ноута на десктоп. Поставил ftp-сервер, под дефолтными настройками заюзал с ноута - и перелил инфу. Забил. Некоторое время спустя появилась у меня другая карточка. На вид более новая. Втыкаю ее, настраиваю. Та жа лажа - destination host unreachable и "no link". Ну все, меня начинает коробить. Меняю на десктопе местами шнуры и конфиги, включаю - пинг пошел, локальная сетка провайдера работает!! Не вероятно, но факт. В чем была конкретно проблема - мне не понятно. После этого чтобы не парить мозг - ставлю на десктопе проксю 3proxy, настраиваю на айпишник моего ноута. Настраиваю ноут на прокси - вуаля - все пашет как надо, инет есть на двух компах. Потом была установка на ноут полноценной оси, но это уже другая история.

2009-06-05T00:20:00.005+07:00

"Как же мне достучаться до этих детей?" Эрик Картманос Сегодня появился пост на Хабрахабре "Всё ли вы знаете про if?". Я плакал и смеялся... Человек говорит о "style guide"-ах.. не уже ли все так запущено в понимании?! То что описано в пункте про "Фигурные скобки" - это самый обычный стиль Кернигана и Ричи. Но кроме него существуют, и надо заметить имеют право на жизнь, и многие их используют, другие стили типа BSD или GNU. В общем - наверное люди ничего не знают о разнообразии стилей отступов. Прочитать можно здесь. Следует заметить - что современные средства разработки позволяют форматировать эти самые стили отступов - великолепный пример ReSharper, VAssist, да и чего там говорить - голую VS тоже можно "поднастроить". "размещение нескольких выражений в одной строке ещё и затрудняет отладку" - правда? не замечал. Дебагеры научились с этим справляться. Правда. "Используйте преимущества С++. Если переменная нужна только в блоке, то и создавайте её только в блоке. Это сбережёт процессорное время, память… в общем всё, что так дорого каждому человеку, исповедующему гуманистические идеалы :-)", - Гениально Баттерс. Особенно про процессорное время. И про память. "Описывайте сперва нормальный ход событий" - ну это как-то по-китайски. А ведь мы хотим говорить по-русски. Напиши маленький комментарий в коде - "// FAILED!" - и будет понятно что тут ты обрабатываешь ошибку, "//Ok" - скажет что все идет нормально. А вот заставлять всех писать все под-левый руль - не по фен-шую. "// ХОРОШО while (true) {} // ПЛОХО while (1) {} for (;;) {}" Те же яйца но в профиль. "Что такое хорошо и что такое плохо?". Вообще если код-тру: то бесконечных циклов не будет. Хотя - это не факт. Помешать пониманию могут только гены 100%-го говно-кодера. "Разделяйте логические выражения на части" Ну это правильно. Но (!) почему бы не расставить скобки в логическом выражении? Ну и переносы строк. По моему намного лучше - чем засорять сознание человека лишними переменными. "Выражения в условиях" Когда один раз вынесешь операцию из if-а это просто. А вот так еще придется сделать не один десяток раз? Даже самого "настырного читателя" кода достанет что автор писал каждый раз "bool bOk = read(...); if (bOk) {...}". Думаю здесь не должно быть правила. А вот то что реально не описано - так это юзабилити и собственно эффективность. Про замену if (..) else if (...) else if (...) ... на switch - ни слова, хотя для читабельности гораздо лучше. Про случай (см. ниже) я вообще молчу. Хотя оч.оч.много программеров (читай говнокодеров) верят что SomeExpression может повлиять и код обозначенный "unreachable" может быть и выполнится по воле всевышнего над-интеллекта.


bool bTrue = true;
... 
/*bTrue нигде не изменялось*/
...
if (!bTrue&&SomeExpression) {
   // some unreachable code
}

Про define и if-ы. При работе с winapi часто приходится проверять результат выполнения функции (HRESULT) - и часто помогают подобные конструкции


#define RETURNONFAIL(hr) if (FAILED(hr)) { \
   LOG(GetLastError()); \
   return hr; }

Ну и old-school: про старый-старый goto тоже умолчали - хотя можно привести 10k+ примеров когда код с миллионом вложенных if-ов сокращается в разы. Я видел много кода и стилей форматирования. Один знакомый утверждает что в коде не должно быть лишних "пустых строк" и "строк только с одной скобкой" - вроде "код сжатый по вертикали" - надо сказать код этого человека я мог прочитать, понять и работать с ним. Другой знакомый, адепт mfc и wtl, - явная противоположность - код "расстянут" - много пробелов и отступов, но зато каждый "абзац" кода - это мысль, причем понятная. Могу сказать с уверенностью - главное чтобы стиль какой-никакой был и чтобы весь проект был в ОДНОМ стиле. И еще - один знакомый как-то сказал что идеальный метод - это тот, что помещается на один экран без скроллинга. А вот писать говно-код, а потом еще спорить о его читабельности и дизайне оформления - это пафос. В целом - не рекомендую выше обозначенную статью (хотя она висит на главной странице Хабра!) для прочтения.

How to Use Constraints in Generics

2009-01-18T18:04:00.006+06:00

Взято из книжки по подготовке экзамена microsoft "MCTS Self-Paced Training Kit (Экзамен 70-536)", Глава 1 (Framework fundamentals), Урок 3 (What are generics). How to Use Constraints Generics would be extremely limited if you could only write code that would compile for any class, because you would be limited to the capabilities of the base Object class.To overcome this limitation, use constraints to place requirements on the types thatconsuming code can substitute for your generic. Generics support four types of constraints: - Interface Allow only types that implement specific interfaces to use your generic. - Base class Allow only types that match or inherit from a specific base class to use your generic. - Constructor Require types that use your generic to implement a parameterless constructor. - Reference or value type Require types that use your generic to be either a reference or value type. Use the As clause in Visual Basic or the where clause in C# to apply a constraint to a generic. Разберемся - для generic мы можем выставлять ограничение с помощью ключевого слова where, типа как далее:

class Abc<T> where T : IDisposable
{ ... }

Ну это понятно, теперь разберемся с самими ограничениями, с первыми двумя - все и так понятно, а вот на последние два авторы как-то забыли объяснить и дать пример. 1. parameterless constructor - требование безпараметрического конструктора. По-суть очень полезно, если внутри своего класса вы хотите создавать новые экземпляры обобщенного класса. Все очень просто, нужно написать new(). Кстати без данного ограничения вы не сможете написать T it = new T()... :)

class Abc<T> where T : new()
{
 public void DoSmth()
 {
         T it = new T();
 }
}

2. Reference or value type. Тоже может быть очень полезным - так как мы можем полностью отсечь применения типа Abc<int> и т.д. Тут сложнее: для referenced type должно идти ключевое слово class, для value type - ключевое слово struct.

class Abc<T> where T : class
{ ... }

class Cba<T> where T : struct
{ ... }

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

Про RichTextBox в .NET 2.0 и перенос строк.

2008-11-20T11:56:00.003+06:00

Многие знают про то, что RichTextBox поддерживает word-wrap или перенос строк. Но не многие знают - как именно управлять переносом строк. Не так давно я столкнулся со следующей проблемой: в данном контроле перенос строк автоматически начинается с white-space символа или знака препинания, т.е. если хотим вбить 100 символов подряд так чтобы они отображались в 3х строках с произвольным переносом между строк - то проблемы начинаются после того как в середину воткнуть дефис или пробел. Да... выглядит конечно же не очень :( Никакой информации по этому поводу я не нашел. Казалось бы, что это не беда и все можно поправить, но на этом кол-во проблем начало только расти: у контрола RichTextBox есть булево свойство WordWrap, но нет никаких других свойств по изменению поведения этого самого переноса строк. Перепробовал буквально все. Документации по вопросам word-wrapping, word-breaking, hyphernatition почти не нашел. Значит дотНЕТ просто не имеет такого на вооружении. Итак, откуда же можно потрогать сей компонент? Откуда он вообще взялся на .Net? Правильно, на MFC уже много парились с ним. Нельзя просто забыть тот момент, когда приходило осознание того, что нужно подгрузить специальную библиотеку для использования этого самого контрола! Тем более дотнетный компонент является всего лишь обмоткой давно известной вещи. Вследствие этого я обратиться к исходникам данного компонента - а именно к файлу RichTextBox.h и MSDN :) После недолгих поисков была найдена следующая весчь: 1. Оконное сообщение EM_SETHYPHENATEINFO и связанные с ним стили WBF_WORDWRAP и т.д 2. Оконное сообщение EM_SETWORDBREAKPROC и функция EDITWORDBREAKPROC Первое отпало сразу же т.к. MSDN сказал, что это используется только в asian-виндовсах. Второе же оказалось намного интереснее: т.к. в качестве параметров в callback-функцию EDITWORDBREAKPROC передавались стили типа WBF_BREAKAFTER и WBF_ISWHITE, ну и собственно указатель на текст. Заинтересовало :) Т.е. теперь можно создать свою функцию с собственными определениями где и как переносить текст в контроле. Окей, накидал собственно код:

[DllImport("user32.dll")]
extern static IntPtr SendMessage(IntPtr hwnd, uint message, IntPtr wParam, IntPtr lParam);

const uint EM_SETWORDBREAKPROC = 0x00D0;

delegate int EditWordBreakProc(IntPtr text, int pos_in_text, int bCharSet, int action);
event EditWordBreakProc myCallBackEvent;

int myCallBack(IntPtr text, int pos_in_text, int bCharSet, int action)
{
    return 0;
}

public Form1()
{
    InitializeComponent();

    richTextBox.Multiline = true;
    richTextBox.WordWrap = true;
    richTextBox.ScrollBars = RichTextBoxScrollBars.None;

    myCallBackEvent = new EditWordBreakProc(myCallBack);
    IntPtr ptr_func = Marshal.GetFunctionPointerForDelegate(myCallBackEvent);
 
 SendMessage(richTextBox.Handle, EM_SETWORDBREAKPROC, IntPtr.Zero, ptr_func);
}

Итак, теперь разберемся: я создал делегат, совпадающий с определением EDITWORDBREAKPROC, и подписал на него собственную функцию. Через маршалинг получил указатель на мою функцию - теперь можно сделать подмену. Потом взял handle самого контрола и послал ему сообщение EM_SETWORDBREAKPROC на изменение функции переноса строк. Что должна делать функция myCallBack ? Собственно она должна возвращать позицию, в которой следует разорвать строку, относительно текущей. Т.е. реально надо распарсить весь текст и по "какому-то" правилу сказать - "вот здесь будет перенос строки". Для моей задачи вполне хватило вернуть нулевую позицию. Т.е. текст тупо переносится на другую строчку без всяких правил разрыва. Да это же то что мне нужно! Ура!! В качестве дополнения: 1. для остальных случаев, где нужно обрабатывать строки и расставлять переносы, стоит все-таки получить строку из callback функции, это можно сделать с помощью следующего кода:

int myCallBack(IntPtr text, int pos_in_text, int bCharSet, int action)
{
string str = Marshal.PtrToStringUni(text);
...
}

2. Стили у контрола меняются после различных оконных сообщений - типа смены фокуса, enable/disable и т.п. Значит, для полной работоспособности вышеприведенного примера нужно кидать сообщение EM_SETWORDBREAKPROC после всех значимых событий. Хотелось бы вообще забыть про такие мелочи. Выход есть)) Создаем новый контрол, наследуемся от RichTextBox ну и... я думаю вы сами догадаетесь :) 3. Пример на MFC выглядел бы куда проще :)

Начало

2008-10-18T18:22:00.000+07:00

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