Владимир Чернышев

Мне помог такой подход на существующем коде:
— функциональные/приемочные тесты на новые или изменяемые фичи (по сути описание ТЗ на неком DSL)
— модульные/интеграционные при рефакторинге
— тесты на баги

И не надо в большинстве случаев, имхо, тестировать внутреннее состояние хоть системы в целом, хоть отдельных её объектов или переменных. Тестировать нужно её поведение. Соответствие результата ожидаемому. При этом нужно ориентироваться на семантику, а не на знание внутренностей, не нарушать инкапсуляцию. При таком подходе не нужно будет писать, например, тесты на геттеры и сеттеры отдельно, достаточно написать один тест, что значение, возвращаемое геттером равно установленному раннее сеттером. Или, переходя на систему в целом, не нужно тестировать что нажатие кнопки «сохранить» пользователем вызывает какие-то изменения в БД. Нужно тестировать, что после нажатия этой кнопки пользователь может получить эти данные.

Плюсик в сторону Python: он широко используется не только в вебе, но и во множестве других областей, от замены баша до «взрослого» геймдева. Ruby тоже может, но на практике он скорее экзотика, чем рабочий инструмент. С чем связано не знаю, может просто биндингов маловато или они сырые, может объективные причины есть, может Python проще. Хотя Capistrano, да, мощная штука :) Да и вообще в качестве платформы для DSL самый известный Ruby всё же, имхо.

Можно хранить настройки пользователей (хоть сам файл sqlite, если шаринга данных между пользователями не требуется) в каталоге os.path.join(site.getuserbase(), 'appname'), но в винде это не совсем нативно выглядит. Вот платформонезависимого решения как получить путь к дефолтным настройкам не знаю. Наверное, всё же, следует анализировать платформу (отличия, как минимум, *nix, WinNT <6.0 и >=6.0) и хранить настройки и вообще данные в соответствии с гайдами ОС.

Хоть и не спец, сам джангу только осваиваю

<ul>
{% for album in albums %}
  <li>{{ album.artist }} - {{album.disc}}
    <ol>
    {% for track in album.track_set.all %}
      <li>{{ track.title }}</li>
    {% endfor %}
    </ol>
  </li>
{% endfor %}

Как-то так, подробнее docs.djangoproject.com/en/1.3/topics/db/queries/#related-objects

P.S. для уменьшения обращений к БД («проблема 1+N» кажется называется)можно в контроллере использовать

albums = Album.objects.select_related().order_by('id_album').all()[ 0:10]

P.P.S. Модели у вас очень оригинальные, я бы так описал:

class Album(models.Model):
    artist = models.CharField(max_length=100, null=True)
    disc = models.CharField(max_length=100, null=True)
 
class Track(models.Model):
    album = models.ForeignKey(Album)
    title = models.CharField(max_length=100)

Довольно много полезного про NoSQL (при применении в вебе вообще, и в django в частности) есть вот здесь allbuttonspressed.com/

Имхо, если стартовые условия одинаковые (при текущем знании и Python, и Java — одинаковые стартовые условия по ЗП и прочим «бонусам»), то через 5 лет ничего особо не изменится, а через 20 вопрос не будет иметь смысла. Нет оснований полагать, что динамика роста зарплат изменится, по-моему, при одном и том же росте квалификации, если не случится какого-то форс-мажора типа новой (а в действительности хорошо забытой старой, но не восстребаванной в прошлом из-за дорогих ресурсов) парадигмы программирования

Не
connects = []

а

def __init__(self)
connects = []

PS Отступы парсер съел :(

Если интересует именно веб-разработка, то лучше, наверное, после изучения базового синтаксиса python, начать с django, если сейчас используете веб-фреймворки на php типа symfony или zend. В таком случае, не следует, имхо, углубляться в тонкости питона как языка, а лучше прочитать что-нибудь по django и либо начинать писать свой проект, либо примкнуть к множеству уже существующих, изучая собственно язык и стандартные библиотеки по мере необходимости. Второй вариант ценен реальной возможностью получить нормальные фидбэки на свой код, а не продолжать писать на php лишь изменив синтаксис, но оставив те же подходы.

Вот тут blog.programmableweb.com/2009/02/20/google-api-now-lets-you-get-documents-in-many-formats/ кажется есть что вам нужно — там ссылка на примеры на нескольких языках, думаю разберётесь. Да, версия протокола 3.0, то что в Labs

Рекомендую для изучения собственно языка (и частично затронута веб-разработка) «Марк Лутц. Изучаем Python, 3-е издание» (Символ, 2009) ну или оригинал :) Learning Python. Third Edition. Mark Lutz? (O'Reilly, 2008, может уже есть и 4-е издание, но не встречал). Ориентирован на Питон 2.5, то самый что в GAE.

По App Engine в 90% случаев хватает доков (по крайней мере если на пехепе работал с фреймворками типа симфони и орм типа доктрин) — на английском доки полнее (не успевают переводить, видимо), плюс гуглогруппа

Если же на пехепе писал в стиле близком к процедурному, то сильно рекомендую ещё (а то и до) изучить книги «банды четверых», Фаулера и т. п. по паттернам, DDD, TDD, UML и т.д.

Чем ипортирование через ключик не нравится? :)

python -c import %package%.%module%

Имхо, сначала нужно прочитать Dive into Python (можно без глубокого вникания в текст и/или запуска примеров — просто иметь представление о возможностях языка), а потом написание более-менее реального приложения в выбранной области реальных задач (веб-программирование от, например, программирование стэнд-элон приложений сильно отличается). Примеры в книгах/на сайтах часто оторваны от жизни и не подразумевабт никакого UI, большего чем консоль/файлы с данными. Также полезно посмотреть код реальных приложений, того же django

Ессно, это касается ситуации когда Python «ещё один mast-have язык» и что такое ветвление, цикл или хэшированная коллекция (ака словарь) понимать не нужно.