Валерий Семенов

Пишу на обоих языках.
Руби в своё время выбрал за внешний вид кода (как бывшему делфисту он мне ближе).
Позже, в связи с бОльшим распространением на хостингах, стал писать и на питоне.

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

Руби кажется более структурированным и идеологически выверенным. Питон же более прагматичный язык. Но со временем понимаешь, что у питона есть свой шарм. Например после питона я постоянно норовлю двоеточие поставить, или end'ы «забываю» ставить )

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

Поставь себе программистскую задачу. И выполни её на руби и на питоне.
Сам почувствуешь, какой язык тебе ближе.

Все зависит от того, что скрывается под словом «простенький».

Мы сами начинали с ubercart (drupal), вполне работоспособно.
Но нам хотелось собственных «фишек», а кастомизировать ubercart, лично мне было сложно, совсем страшные подходы к кастомизации.
Пробовали django-lfs — гораздо лучше, но опять-таки, когда нужно уйти в сторону — приходится подпирать костылями.

В итоге разработали свое казино свой интернет-магазин (на базе django), на нем и едем.
Когда проводил сравнение с год-два назад, django-shop был в зачаточном состоянии.
В моем рейтинге явно лидировал LFS, надежды подавал магазин на базе mezannine, и еще разработка от создателей FeinCMS. Все остальное по каким-либо причинам забраковал.

Советую взять LFS, если дело ограничится «простеньким», потом, когда дело пойдет, сможете вложиться в собственную разработку.

from contextlib import nested

with nested(mock.patch(...), mock.patch(...), ...):
  ...

тут

А с python 2.7 вообще просто так:

with mock.patch(...), mock.patch(...), ...:
    ... 

Почитайто про routing. Надо эти задачи отправить в отдельную очередь и настроить только один воркер, обрабатывающий эту очередь, а в нем разрешить тольо один поток. Это единственный способ, если вы хоите использовать только celery.
Если нужна еще надежность, нужна сторонная реализация многомашинного lock'а, задачу выполнять под ним. Также, как и в первом случае лучше настроить отдельную очередь но уже с несколькими воркерами.

Я увидел в Вашем вопросе две части.

Как правильно организовать деплой (выкладку работоспособного кода на сервер)?

В самом простом случае Вам подойдет связка ssh + git pull на сервере. В этом случае на сервер будут доставлены патчи коммитов, которые есть в репозитории, но еще не появились на сервере, т.е. «только обновления файлов, которые сейчас существуют». Этот метод довольно подробно обсудили в ответах на другой вопрос.

Если хочется автоматизировать процесс, что похвально, то я вижу три доступных инструмента для этого: Capistrano, Mina (мой персональный фаворит) и Vlad the Deployer. Все три проекта схожи по сути. Принцип их работы таков:

1. Подключиться к целевому серверу.
2. Залить обновление кода из репозитория.
3. Выполнить предписанные Вами инструкции (перезапуск демонов, сброс индексов, обновление структуры БД и прочее).
4. ...
5. PROFIT!

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

Как организовать процесс тестирования?

Если Вы еще не определились с методикой тестирования (Test Driven Development, Behavior Driven Development, Лень-Driven Development), то Вам следует для начала заняться именно этим.

Скорее всего, тесты будут выполняться на Вашей локальной машине, пока Вы пишете код. Используя RSpec, я держу открытым Guard. Guard отслеживает изменения в коде и запускает набор юнит-тестов, которые покрывают измененный код. Весь процесс занимает не больше минуты-двух, и особо не напрягает. Как только я вижу провалившийся тест, я меняю код до тех пор, пока он не станет зеленым. Пока тестов мало (это не самый лучший знак, к слову), Вы работаете один, локального запуска перед деплоем может оказаться достаточно — например, чтобы проверить релиз на доступность критического функционала: регистрации, покупки, создание постов и т.п.

В какой-то момент речь может зайти о Continious Integration. Это возможность иметь стабильный билд в любой отрезок времени, а так же принимать решение о годности каждого отдельного коммита. Сопряжено с деплоем кода на integration-сервер и запуском на нем тестов. Скорее всего, это Вас не интересует, если Вы не работаете в команде. Но, для полноты картины, Вы можете понаблюдать за билдами на Travis CI известных Open Source проектов: Symfony 2 и Ruby on Rails.

Таким образом

Вы не указали, какие конкретно инструменты для разработки Вы используете. Если же с деплоем все гораздо проще, то при выборе инструментов для тестирования я рекомендую Вам ориентироваться на те, которые нативны для Вашего основного фреймворка и языка (PHP, если правильно понимаю) и привычны их пользователям. Это позволит быстро применить устоявшиеся практики к Вашему проекту и понять всё на деле.

Приведите в порядок Ваш репозиторий с кодом, используйте mina для деплоя и запускайте тесты на Вашей локальной рабочей машине. Как только Вы почувствуете, что этого не достаточно — Вы наверняка уже будете знать, куда шагать дальше.

unic = {icon['event_id']: icon for icon in reversed(icons)}.values()

Несовсем понятно, что вы ищете, но отвечу следующим образом:

— в Django есть встроенный механизм кэширования с несколько стандартных бэкендов к нему — FileBackend, MemcacheBackend, DatabaseBackend (мог напутать в названиях, но суть та же). Вы сами выбираете, включать ли кэш и какой бэкэнд использовать в настройках (settings.py).

Имейте в виду, что для удобства разработки, удобнее всего использовать DummyBackend, а полную информацию можно прочитать в документации

— Если надо кэшировать большое количество queryset'ов и есть возможность использовать Redis, то рекомендую посмотреть в сторону решений с автоматической инвалидацией. Одним из лучших подобных инструментов считаю cacheops, кстати автор — наш соотечественник и уже писал о нем на Хабре.

Обычно демоны создают pid-файл. Проверяйте его наличие.
Или вы сами пишете демон?

Насколько я помню, схема от всей формы тоже ShemaNode, так что preparer должен получить весь appstruct

schema = Schema(preparer=my_preparer)
form = deform.Form(schema, buttons=('submit',))

так же можно переопределить deserialize у формы или написать свой widget в который будет обрабатывать оба способа загрузки файла и отдавать только одно значение

Вот пример
http://deformdemo.repoze.org/file/

class Schema(colander.Schema):
    upload = colander.SchemaNode(
        deform.FileData(),
        widget=deform.widget.FileUploadWidget(tmpstore))

В поля типа FileData есть все нужные данные
Лучше всего, видимо, при обработке формы взять файл (в form.upload.fp) и сохранить на диск куда надо.

Также обратите внимание на параметр tmpstore у deform.widget.FileUploadWidget
создав свой tmpstore можно контролировать где будет храниться временно загруженный файл

Python Imaging Library (PIL) + nginx (для location /favicon.ico задать кеширование ответа бэкенда ~30-60 минут, ну и max-age соответствующий). Правда это сомнительная затея.