Максим Васильев

на edx.org:
MITx 6.041x Introduction to Probability — The Science of Uncertainty Course Starts - Feb 04, 2014
UTAustinX UT.5.01x LAFF: Linear Algebra - Foundations to Frontiers Course Starts - Jan 16, 2014

Покурите мануалы на предмет
Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Expose-Headers

ekiga.org/ смотрели?

Если вам нужно именно слить таблицы прямо в базе - то вам нужен SQL, а не джанго.

А если вам нужно сделать "виртуальную таблицу" на уровне ORM, которая бы налету склеивала модель из двух других, то я бы покурил на тему model manager:
https://docs.djangoproject.com/en/1.6/topics/db/managers/
И написал бы к ModelC кастомного менеджера, котрый транслирует запросы objects.* в sql с joinами.
В принципе, в него можно встроить и сохранение моделей в разные таблицы.

Когда-то давно делал такое для слияния трёх таблиц из трёх разных баз (на разных серверах). Но это было с очень древним джангой.

Распарсите формулу в дерево.
Линеаризуйте дерево с сортировкой элементов по алфавиту.

В любом случае имеет смысл также приобрести и прочесть библию программирования Дональда Кнута:
Том 1. Основные алгоритмы
Том 2. Получисленные алгоритмы
Том 3. Сортировка и поиск

Если других книгах есть тоже, что и у Кнута - это ненужные книги.
Если в других книгах есть то, чего нет у Кнута - это неправильные книги.

Чтобы пакеты ходили между сетями А=192.168.1.0/24 и Б=192.168.2.0/24 нужен шлюз, подключенный к обеим этим сетям (двумя и нтерфейсами) и имеющий IP-адреса в обеих этих сетях. Например gwА=192.168.1.251 и gwБ=192.168.2.251.

Чтобы сам шлюз знал, к каким сетям подключен, на нём нужны маршруты:
192.168.1.0/24 dev ethX (без шлюза)
192.168.2.0/24 dev ethY (без шлюза)
(обычно они выставляются автоматически при настройке интерйейса, но мало ли что)

Чтобы шлюз знал, как достичь всех остальных сетей (кроме А и Б), на нём нужен маршрут
0.0.0.0/0 via какой-нить шлюз, находящийся в сети А

Чтобы узлы в сети Б видели саму сеть Б, на них нужен маршрут:
192.168.2.0/24 dev ethX (автоматический интерфейсный маршрут)

Чтобы узлы в сети Б видели сеть А, на них нужен маршрут:
либо 192.168.1.0/24 via gwБ (если нужна только сеть А)
либо 0.0.0.0/0 via gwБ (если через сеть А выход в интернеты)
NB: gwБ находится в сети Б и поэтому виден благодаря интерфейсному маршруту.

Чтобы узлы сети А видели сеть Б, на них нужен маршрут:
192.168.2.0/24 via gwА
NB: gwА находится в сети А и поэтому виден благодаря интерфейсному маршруту.

rsync с бэкапного сервера может подключаться к резервируемому если на том стоит rsyncd.

Пропатчите скрипт автозапуска, чтобы он писал весь stdout/stderr от apachectl в логфайл.

Так а что мешает просто добавить атрибут к объекту Factory?
В смысле что вынести mainClient в более глобальную область видимости и сделать mainClient.somedata = блаблабла

А трансформайсы разве не банят за ботов?

Насколько я понимаю, задача сводится к тому, чтобы:
1. сохранить в гуглокалендаре событие и привязать к нему товар
2. при наступлении события дёргать какой-нибудь api для блокировки этого товара.

1.
API гуглокалендаря не позволяет добавлять произвольные атрибуты к событиям, развечто в поле description. Поэтому хранить связку евент-товар лучше в своей базе.
Ещё можно поглядеть гаджеты, которые можно добавить к евентам:
https://developers.google.com/google-apps/calendar/gadgets/
Вроде бы в гаджеты можно запихать всё что угодно, в том числе ссылку на товар.

2. Есть подписка на изменение событий с push-уведомлением по http:
https://developers.google.com/google-apps/calendar/v3/push
По ней можно отслеживать, когда событие перенесли/отменили/итп.
Однако, уведомления о том что событие "наступило" там нет, потмучто нет никакого атирбута "наступило".
Поэтому отслеживать наступление события тоже надо самому, на какомнить cron.

2.2. Можно добавить к событию уведомление по email, и направить его на адрес робота, который будет блокировать товар.

Accept: выставить пробовал, не помогает.

GET /addr/ HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Cache-Control: no-cache
Accept: application/json
Pragma: no-cache
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.114 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: csrftoken=3V2ntHJJHr0v8zXBvcHyX0aYxG4bPzIS

А оно вобще работает, или тестится?

Например, в Лиспе:
www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_restart-case.html
chaitanyagupta.com/lisp/restarts.html

расколупать django.contrib.sessions

пока писал тут на stackoverflow уже ответили:
Все __магические__ методы ищутся в словаре класса, а не объекта.

когда найдёте решение — напишите статью :)
весьма любопытно будет.

вести syslog, в который писать все события голосования (а может быть заодно и другие, типа создания сообщений/комментариев)
решит проблему и одноразового голосования, и голосования типа «раз в день»