Да. Я всё же несколько некорректно поставил вопрос. Рейзить эксепшины равнозначно их отлавливать. Слишком много мест в коде и слишком большие трейсбеки. (чаще всего где-то какой-то сервер не ответил или БД перегружена).
logrotate следить за состоянием на более низком уровне. Он наблюдает за работой самого сервера БД и регистрирует именно системные события. У меня же несколько другой шаблон использования. Мой log engine пишет события, совершаемые пользователем в системе в нужном мне формате: кто, что, где и когда. Это совсем не накладывается на парадигму слежения за состоянием сервера БД. Хотя, возможно, я не верно понял mysql-log-rotate.
Как показывает моя практика за командировку проблемы решаются в десятки раз быстрее, чем по мылу, скайпу и телефону вместе взятыми. Назовите меня ретроградом, но пока человечество не достигло уровня развития, на котором можно иметь полноценную или очень приближенную альтернативу реальным встречам. Я завёл в компании пользовать видеовстречами в Google+, но это скорее вынужденная мера. Когда мы случайно все съехались в подмосковье опять же, это было сильно эффективнее google+ hangout.
Конечно, как говориться, «сам себя не похвалишь никто не похвалит». Ну на питоне много последние несколько лет пишу. Да и преподавал тоже не мало другие вещи.
Пока в голове схема стандартная:
1) Синтаксис (типы данных, языковые конструкции)
2) ООП
3) Шаблоны проектирования
3) По потребностям по мере их убывания на рынке труда: django, GAE, SQLAlchemy -> twisted, gevent, (tornado), -> PyQt. Галопом чтобы иметь представление.
У меня совсем мало опыта, выскажу только свои оценочные суждения.
Лучше всего команду набрать среди «своих». Т.е. тех, кого вы знаете, с кем не испытываете трудностей в коммуникации, с кем можете встретиться для обсуждения алгоритма за стаканом пива. Интернет, безусловно, это удобно, но собрание физически в одной точке почему-то всегда добавляет интеллекта. Мой выбор и совет — однозначно работать в своей команде.
— Стандартные решения работают. Но медленно и крайне неэффективно. Но в задач чаще всего 90% — это те самые подготовительные мелочи. Только последние 10% — место для фантазии и интеллекта. Львиную долю работу придётся проделывать чисто механическую. Проще всего «решить влоб», понять, что решение есть, а потом искать обходные пути ускорить-улучшить-добавить точности.
Если вы связаны с семантическим анализом, значит ваши познания явно сильно больше и глубже моих. Вам однозначно стоит себя попробовать на разных челенджах.
>>> будет ли это означать, что поле category будет ссылать на какой-то конкретный объект модели CategoryArticle и данные не будут дублироваться?
Да. Поле category будет ссылаться на конкретный объект модели CategoryArticle (на тот самый Key) и данные НЕ будут дублироваться.
>>> А так как ReferenceProperty хранит в себе модель, то, как я понял, мне надо будет или реализовать
метод str для объекта или использовать [(category.key().id(), category.title) for category in ArticleCategory.all()]
И опять таки да. Если вы хотите использовать идентификатор (id) какой-то Entity для своих целей вам придётся сделать явное приведение типов.
