funca

Два варианта:
1. Использовать нативную поддержку докера в PyCharm.

Интеграция по всей видимости рассчитана на docker-machine и boot2docker. Но если хочется использовать docker из хост-сиситемы, то настраивать docker-machine и ssh не обязательно. Вместо этого можно использовать скрипт-заглушку из https://youtrack.jetbrains.com/issue/PY-17454#comm... Путь к docker-machine заглушке указать в настройках PyCharm.

В систему необходимо добавить пользователя "docker" с паролем "tcuser". Эти реквизиты использует дебагер.

sudo useradd --system --create-home --home /var/lib/docker docker
echo 'docker:tcuser' | chpasswd

Если дебагер не может подключиться к контейнеру, чинится добавлением IP адреса 10.0.2.2/8 интерфейсу docker0:

sudo iptables -A INPUT -i docker0 -j ACCEPT
sudo ip addr add 10.0.2.2/8 dev docker0 \
        && (sudo ip link set dev docker0 down; sudo ip link set dev docker0 up) ||:

Интеграции с docker-compose нет. PyCharm будет запускать контейнеры самостоятельно, поэтому провязку с внешними сервисами придется костылять отдельно. Через .env файлы, например.

2. Использовать обычный удаленный доступ по SSH.

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

# за основу берется проектный image
FROM myproject

# sshd
RUN apt-get update \
    && apt-get install -y --no-install-recommends \
           openssh-server \
           vim \
    && rm -rf /var/lib/apt/lists/* \
    && mkdir -p -m0755 /var/run/sshd \
    && echo 'root:screencast' | chpasswd \
    && sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config \
    && sed 's@session\s*required\s*pam_loginuid.so@session optional pam_loginuid.so@g' -i /etc/pam.d/sshd \
    && echo "export VISIBLE=now" >> /etc/profile

# PyCharm хочет исходники в /opt/project
WORKDIR /opt/project

# автоматически активировать virtualenv при логине root 
RUN echo "\ncd /opt/project; if [ ! -f env/bin/activate ]; then virtualenv env; fi; . env/bin/activate" >> /root/.bashrc

# ssh, django runserver
EXPOSE 22 8000
CMD ["/usr/sbin/sshd", "-D"]

После этого проект и зависимости можно запускать один раз через docker-compose up -d, а в PyCharm - настроить интеграцию с контейнером через обычный удаленный доступ по SSH.

# docker-compose-dev.yml
# vim: sw=2 ts=2
version: '2'
services:
  web:
    build: .
    links:
      - db
    volumes:
      - ./:/opt/project
      - ./data/env:/opt/project/env
    ports:
      - "127.0.0.1:2222:22"
      - "127.0.0.1:8000:8000"
  db:
    image: mysql
    volumes:
      - ./data/mysql:/var/lib/mysql
    environment:
      - MYSQL_ALLOW_EMPTY_PASSWORD=yes
      - MYSQL_DATABASE=mydb
    ports:
      - "3306:3306"

В примере исходники, virtualenv и директория с данными для MySQL монтируются через volume, чтобы не терялись при пересоздании контейнеров.

Я использую это вариант, поскольку он работает заметно быстрее.

правильность, как любое оценочное понятие, зависит от контекста. в вашем случае — от целей тестирования. тестирование модуля и модульное тестирование это не одно и то же. :)

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

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

Сильно зависит от характера решаемых саппортом задач. Если это что-то стандартное, в чем клиент не компетентен, а саппорт может решить проблему без участия клиента (типа «у меня пропал интернет»), почему бы и нет. Клиенту не нужно напрягаться, пытаясь рассказать телефонной трубке непонятные для себя вещи (при этом еще не выставить себя дураком), а оператору — выслушивать и пытаться разобрать это бред. Тут барьер, в виде простого голосового меню, всеми воспринимается адекватно.

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

зы: по ссылке не ходил)

Читал, что в PostgreSQL есть продвинутые возможности для работы с XML — этот формат подходит для хранения документов с произвольной схемой. Можно делать выборки по xpath, строить индексы, и даже грабить… отдельные фрагменты документов. Может быть стоит поискать решение в этом направлении?

2. Может быть есть какие средства сбора метрик для Git?

ага. смотрите icefox.github.com/git-achievements/ :)

Ага, наверное который Home в Pro превращает. Самба не может эмулировать PDC, может только стать частью существующего домена, домен получится у вас неполноценным без него.

samba 2.x уже могла выступать в роли PDC для NT домена, интегрироваться с LDAP (хранение ресурсов) и Kerberos (авторизация). ключ для XP устанавливал флажок в настройках метода авторизации.