Архив за [undefined]

FDD: Forum-driven development

Это такая новая техника разработки ПО. Она же "MDD" (mailing-list-driven development), и она же "CDD" (chat-driven development). Я конечно же немного утрирую, но не могу отделаться от этого ощущения. На программистских форумах, рассылках, jabber/irc конференциях очень часто можно встретить топики от одного и того же человека, который разрабатывает какой-то "проект". Он последовательно задает вопросы и по этим же вопросом можно достаточно детально узнать о проекта и более того можно стать его автором даже в больше степени, чем вопрошающий. По крайне мере складывается такое впечатление.

Замечаешь это не сразу, а постепенно вопрос за вопросом вырисовывается картина того что же делает человек. Получается он ведет разработку, получая ответы и внедряя их в свой код (который хочется надеяться есть), проходит так весь путь написания проекта. И с большой долей вероятности в конце он прийдет на этот же форум и похвастается сделанным. И только изредка скажет спасибо участникам, которые по сути и написали этот проект.

Иногда случается так что в очередном вопросе ты видишь свой же код, данный в ответ на вопрос заданный ранее, но уже как-то измененный и "не работающий". Ну ты понимаешь -- не работает он потому, что автор его не осознал и попытался как-то наобум изменить, что конечно не получилось. Это ...

DevConf::Python() 2010

Какие у вас планы на 17-18ое мая этого года? Пока не знаете? Тогда я могу вам предложить интересное занятие на эти дни.

В означенные дни в Москве пройдет первая российская конференция DevConf, которая соберет множество веб-разработчиков из различных "вселенных".

Среди прочих вселенных (секций), там будет своя, отдельная, уютная и посвященная Python. Не знаю как вы, а я о чем-то подобном уже давно мечтал.

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

Поверьте, такие мероприятия проходят не часто и если вы хотите быть в курсе последних трендов в Python мире, то оно того стоит чтобы поучаствовать.

На данный момент мы активно ищем докладчиков и формируем программу. Если у вас есть интересные мысли и желание поделиться ими с сообществом, то регистрируйтесь и предлагайте свои доклады/мастер-классы. Если у вас возникнут какие-то вопросы, то можете смело задавать их мне, т.к. я являюсь членом оргкомитета и отвечаю за питонячью секцию.

Call to arms!

Чем ходить по http?

Как оказалось в питоне нет однозначно подходящего варианта. Всего-то хочется удобно дергать какие-то API и иногда стягивать файлы.

Есть несколько библиотек, многие из которых друг друга используют и заимствуют функционал. Но вот чего-то одного, удовлетворяющего достаточно простым (ведь так?) требованиями, нет.

Требования же эти такие:

  • поддержка http/https
  • возможность использовать любые http verb
  • возможность отослать body запроса с произвольным Content-Type
  • поддержание коннекта между запросами (keep-alive)
  • работа с куками
  • стандартная аутентификация
  • file-like интерфейс к body ответа
  • кеширование
  • conditional get
  • обработка низкоуровневых ошибок и оборачивание их в какой-то дженериковый HTTPError и наследников.
  • возможность добавить в конвейер запроса хуки, чтобы можно было какие-то действия производить с отсылаемыми данными, либо результатом.
  • возможность задать таймаут хотя бы для соединения

Ну и пара экзотических хотелок:

  • поддержка http pipelinening
  • возможность делать запросы асинхронно

Ведь не невозможного хочется. Но что мы имеем.

httplib

По сути основа всех питонячих "ходилок" по http. Находится в стандартной библиотеке. Главная особенность -- позволяет присоединиться к http серверу и делать запроса к его урлам в рамках одного соединения.

connection = httplib.HTTPConnection('example.com')
result = connection.request('GET', '/foo')
# ...
result = connection.request('GET', '/bar')
# ...
connection.close()

Возвращает file-like объект и с недавних пор позволяет задать таймаут для соединения. Тут фичи заканчиваются и мы остаемся наедине ...

И даже с FogBugz не сложилось

Выбор идеального или приближенного к таковому тикет-трекера для личных проектов это просто какая-то мука. Сколько я уже их перепробовал -- и Trac пытался поднимать, и на bitbucket пытался вести таски по проекту. Все не прет. Bitbucket вообще в последнее время не радует своей нестабильностью и баговатостью, в том числе и в трекере.

Требования у меня-то простые. Трекер должен помогать мне держать в актуальном состоянии фичи для реализации и баги для исправления. Все просто и чтобы без лишних рюшечек.

Наверно самым удобным для меня сейчас является баг-трекер на Google Code. Там у меня есть один активный проект (Djapian), в котором довольно много всего приходится делать именно в тренере. Как-то так сложилось, что он даже в некоторой степени превратился в форум -- там задают вопросы, а я на них отвечаю с резолюцией Invalid. Мне это не очень нравится, зато я накопил опыт его использования. И метки мне там нравятся, и возможность добавить в фавориты какие-то таски, и разумные провязки с репозиторием кода. Да, по workflow наверно самый для меня подходящий. Только вот проектов больше там у меня не предвидится. Во-первых они там все публичные, что не всегда удобно, а во-вторых ни svn, ни даже hg уже не вставляют…

В отчаянии решил попробовать FogBugz. Читал ...

В одну корзину

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

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

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