Выбор идеального или приближенного к таковому тикет-трекера для личных проектов это просто какая-то мука. Сколько я уже их перепробовал -- и Trac пытался поднимать, и на bitbucket пытался вести таски по проекту. Все не прет. Bitbucket вообще в последнее время не радует своей нестабильностью и баговатостью, в том числе и в трекере.
Требования у меня-то простые. Трекер должен помогать мне держать в актуальном состоянии фичи для реализации и баги для исправления. Все просто и чтобы без лишних рюшечек.
Наверно самым удобным для меня сейчас является баг-трекер на Google Code. Там у меня есть один активный проект (Djapian), в котором довольно много всего приходится делать именно в тренере. Как-то так сложилось, что он даже в некоторой степени превратился в форум -- там задают вопросы, а я на них отвечаю с резолюцией Invalid. Мне это не очень нравится, зато я накопил опыт его использования. И метки мне там нравятся, и возможность добавить в фавориты какие-то таски, и разумные провязки с репозиторием кода. Да, по workflow наверно самый для меня подходящий. Только вот проектов больше там у меня не предвидится. Во-первых они там все публичные, что не всегда удобно, а во-вторых ни svn, ни даже hg уже не вставляют…
В отчаянии решил попробовать FogBugz. Читал ...
Один из самых часто задаваемых вопросов на форумах по Джанге -- как на одной странице выводить информацию из разных информационных блоков (пример такой ветки или вот совсем свежий). Давайте попробуем разобраться в стандартных способах решения данной задачи. Я специально не хочу рассматривать тут какие-то сторонние решения просто из-за того, что их много и они не интересны с точки зрения изучения классических методик применения возможностей Джанги.
Основной проблемой с которой сталкиваются вопрошающие -- как получить все нужны данные в одной вьюхе и зачастую из разных приложений. Это усугубляется тем, что у большинства в подсознании сидит необходимость разделения приложений на максимально независимые компоненты. И это правильное желание. Другое дело, что не надо этим принципом злоупотреблять. Если всё-таки ваши приложения нуждаются друг в друге достаточно сильно, то нет ничего плохого в том чтобы иметь в них перекрестные импорты и заимствовать функционал (в том числе по получению данных) так или иначе. Другое дело что таком случае стоит подумать о том, что возможно они настолько жестко связаны, что должны быть единым целым, т.е. одним приложением по сути. Но и даже в этом случае имеет смысл как-то чуть-чуть отделить общие данные от локальных.
Обычно исходной целью стремления получить данные из разных приложений являются всякие виджеты, информеры и ...
django-couchdb это ДБ бекэнд для Джанги с поддержкой CouchDB, разработанный командой 42cc.
Начиная новый проект, я очень рассчитывал на это решение, но увы оно совсем не оправдало надежд. Основная цель была, используя CouchDB не отказываться от стандартной джанговской админки и попробовать её заставить работать при помощи это бекэнда. Любовь к админке обусловлена тем, что она уже написана и её не надо изобретать с квадратными колесами нам самим, то что наши контент-менеджеры уже отчасти привыкли к ней и не хочется сбивать им workflow.
Авторы django-couchdb не скрывают что эта их реализация больше академическая и какого-то реального юзкейса у них не было. Что и проявилось в итоге.
Сразу надо сказать, что на данный момент основная гитхабовская ветка не работает с текущей Джангой и свежим CouchDB. Это связано с тем, что в Джанге в последнее время серьезно переработали внутренний API бекэндов баз дынных, а новый CouchDB чуть более строг с структуре документов чем раньше.
Но ладно, завести этот бекэнд вполне можно, что силами Кости Меренкова мы и сделали. Как и предполагалось, заработал базовый ORM, админка, а следовательно и приложения из contrib.
Пожив какое-то время с таким решением, мы поняли, что во многих местах для нашей задачи оно избыточно, а в других просто неудобно ...
По большому счету кроме urllib2 больше ничего и не надо. Но если хочется каких-то более удобных оберток над CouchDB REST API то есть из чего выбрать. Мне на глаза попадались три различные реализации и в начале разработки проекта пришлось потратить время на то чтобы выбрать подходящую.
Сразу оговорюсь, что все они очень похожи и делают одинаковые вещи - оборачивают в объекты основные сущности, которые предоставляет API -- сервер, база, документ и вьюха. Все совместимы с последним релизом самого CouchDB -- 0.10.
Первая из библиотек -- couchdb-python. Самая старая из появившихся. Можно сказать референсная реализаци. Имеет все полезные абстракции и даже чуть боьлше. Это "больше" заключается в возможности задать схему документа в декларативном Django-like стиле и реализация питонячьего view-сервера. Первое нужно чтобы как-то структурировать документы и работу с ними, а второе для того чтобы использовать python как язык для map/reduce обработчиков вместо штатного JavaScript. Умеет работать как с simplejson так и с быстрой cjson библиотекой. Так же хочет чтобы балы httplib2.
Следующий кандидат это couchdbkit. Умеет практически всё тоже самое, но имеет чуть больше хелперов и экстеншенов с адаптерами к популярными библиотекам вроде Django. Тянет за собой в зависимостях restkit (как видно из названия -- REST-клиент библиотека от того же автора) и умную библиотеку ...
Прежде чем "всё переписать", надо рассказать людям - а что это вообще такое! Многие не понимают ни как правильно писать в асинхронном стиле, а вообще всей этой парадигмы.
Уже достаточно давно мой способ знакомства с новой технологией это подписка на список рассылки и внимательное изучение вопросов, ответов и вообще общего духа сообщества. Так случилось что на рассылку node.js я подписался до знаменитого поста Саймона и смог увидеть резко возросший интерес к теме.
Как это обычно бывает набежало сразу куча восторженных людей и пошли многокилометровые споры о том какой MVC фреймворк надо на базе этого сделать и какой шаблонный движок реализовать. Уже плохо. Но когда люди участвующие в подобных спорах вдруг, так, невзначай, приходят и задают с виду безобидные, но выносящие мозг вопросы как этот или этот, то опускаются руки и кажется что в нашем разработческом мире не всё хорошо.
Люди не понимают сути. Совсем. Причем им как бы интересна технология. Встает вопрос почему? Да модно просто. Такое происходит уже не в первой рассылке которую я наблюдаю. Так же было с CouchDB например.
Кстати, что я заметил -- эти люди в основном пишут на... ruby. Ну не важно:-)
Не понимают они, что новые технологии это не только модный buzzword но и ещё ...