2bialix: Спасибо вам за хорошие ответы.Я консервативен в используемых системах облегчения жизни разработчика.Долгое время меня устраивала svn, о чем вам не раз и писал.Потом сменились внешние обстоятельства, и стало возможным поискать альтернативу — благо была одна на примете:) Эксперимент считаю удачным для себя.Буду рекомендовать друзьям и приятелям.Кстати, а что вам НЕ ПОНРАВИЛОСЬ в Базаре? На какие неудобства вы наткнулись? Крайне интересно услышать критику от весьма знакомого с системой человека.Скорость... В самом моем большом проекте было около 250 файлов. Неудобств по скорости не ощутил. Так же быстро, как и svn. Мне показалость приемлимым.Конечно, было бы интересно оценить на моем последнем проекте.Там было порядка 15 000 файлов в svn, и svn откровенно тормозила. Она тормозила заметно даже на другом проекте из 1500 файлов.Из мелочей. В svn help тут же показываются короткие сочетания (update (up), commit (ci), checkout (co), move (mv), status (st) и т.д.) В bzr это неочевидно. Понял, что оно работает — только забывшись и по привычке написав «как в svn». А поправить так легко!

последнем — на предыдущей работе

Теплый-холодный кеш (не знал, кстати, что они так зовутся) — известная беда.Я привык оценивать свои ощущения по «теплому». Ведь я системой пользуюсь постоянно, а не от случая к случаю.По поводу сокращений: не спорю, настройка их — фича очень мощная.В svn проблема алиасов решается так: svn help... blame (praise, annotate, ann) ...У вас бы могло быть annotate (ann, blame, praise) Если возможно, неплохо бы включить и настройки пользователя. Но это уже не важно.По опыту — если человек такое видит — начинает использовать. Если нужно долго читать — не читает, пока случайно не наткнется. А вещь востребованная. Просто вы этого не видите, т.к. досконально знаете систему (по себе сужу). Не всегда вычитывается manual «от и до». Гораздо чаще — «до состояния способности работать с системой». Потом уже набирается нужный опыт — если задача заставляет лезть опять в manual.А еще. Если алиасы можно настраивать — то почему бы не упомянуть последней строкой ссылку на http://doc.bazaar-vcs.org/bzr...? Хотя, может быть, последнее — лишнее.Мелочь, как я уже говорил. Мне — не мешает. Но было бы приятно.

Во первых, когда вы делаете ветку в svn — это действительно серьезная причина. Новая экспериментальная версия или серьезный багфикс.В базаре ветка делается для того, чтобы вы сделали свои изменения. Личные.Другой разработчик сделал то же.Как потом быть? Да так же, как и в svn, только удобнее.Можно мержить параллельные ветки и, добившись совместной работы, выложить это в trunk.Или еще куда нибудь (наша_совместно_собранная_ветка.dev) Можно попытаться запостить свое первым — привет, svn, кто последний, тот и латка (в смысле именно он разбирается с конфликтами). У нас на работе это нередко превращалось игру.Если все изрядно запутано — много разработчиков, они не сидят рядом, каждый ведет свою ветку — то тоже все видно. Кто когда и как менял.И, самое главное, что я увидел — свобода.Желаешь работать «как в svn» — работай. Желаешь сделать ветку — делай. Она не отразится в главном репозитарии. Если хочешь ее засветить — свети. Склеивай с другими. Работай локально — и потом склеивай.Можно базар рассматривать как «svn с большими степенями свободы», но этим он не исчерпывается.Централизованный svn — можно так и на базаре. А можно и иначе (причем для каждого разработчика).Кому что нравится. Осваивать новое можно в процессе использования.Базар дает больше гибкости, на мой взгляд. Не накладывая ограничений.

Тогда уж лучше bialix’у статьи писать. Думаю, лучше него в ближайших окрестностях систему никто не знает

Хочу прийти

Могу рассказать, как дело обстоит у нас. Пишем софт для работы на финансовом рынке (очень похож на традиционный банковский).Программеры успешно кропают свои юнит-тесты и большего им не нужно (а если тестов мало — приходит начальник и в нескольких простых понятных фразах объясняет, что к чему).Юнит-тесты — действительно очень классная вешь.Но у нас есть отдел тестирования и мужи от бизнеса, которые на фондовом рынке собаку съели, а на Питоне писать не могут. Заявляют, что програмирование на Питоне для них — слишком сложная наука:) Выход — именно в том подходе, который описал Всеволод. Правда, мы используем не fit, а asgard — он делает практически то же (в какой-то степени клон), но в качестве входных данных понимает excel таблицы. Так проще нашим business guys и эти таблицы гораздо удобней редактировать. Все, что им нужно знать — как следует описывать данные для конкретной фикстуры и какие фикстуры нужно упоминать в тесте. Причем в детали реализации фикстур они не вникают — просят программистов сделать им «такую-то и такую-то» (на самом деле отражающую реальное поведение программы) — и все. Они запускают свой тест, видят, что не все отработало. Начинается общение с программерами (предметное). Проблема всегда обнаруживается (по убывающей) в некорректных исходных данных, в неправильной работе программы, в некорректной фикстуре. И быстро лечится. Все довольны. Отклик — очень быстрый. Регрессионные тесты — тщательно обрезанный набор fit тестов (у нас их зовут dev acceptance). И acceptance тысяч шесть, в то время как юнит-тестов «скромные» 2000 с копейками. Мы, программисты, просто не в состоянии написать такое плотное тестирование. Вдобавок полный прогон юнит-тестов занимает 7 минут, acceptance — 3 часа (они делают гораздо больше, работая с реальным источником данных).P.S. У нас нет «ручного тестирования» — его заменяет acceptance.P.P. S. Пока не перешел на эту работу — тоже не понимал, зачем fit. Сейчас не понимаю, как можно разрабатывать наш проект без него.Сергей, на вопрос ответил? Или нужны дополнительные пояснения?

Да, еще.Задание по внесению новой функциональности начинается, естественно, с обсуждения:, а что, собственно говоря требуется? Но к моменту deployed to QA у этих самых QA-тестировщиков должен уже быть готов fit тест на это дело.Если что-то «завалилось» — то тесты показывают, что именно.Конечно же, вся эта лавочка служит преимущественно для облегчения работы с теми ребятами, которые говорят «что должно получиться в конце концов».На чисто программерские заботы никак не отражается. Я, занимаясь преимущественно архитектурой проекта, с такими тестами редко имею дело. Но они реально помогают.

Исходников нет. Вернее есть, но дать не могу. Закрытая разработка. Почему так — для меня загадка. Можно смотреть на открытый PyFIT.Модулей с фикстурами — порядка сотни. Большинство фикстур до смешного простые и короткие. Исчезающе малая часть по сравнению с тысячами тестовых файлов (а учитывая многостраничность excel общее количество тестов уверенно переваливает за десять тысяч).Тестировщики ни одной строки кода не написали, зато бодро ваяют excel’ки.

Конечно же, технология подходит не для всего. Для CMS, кажется, не подходит для CMS как продукта и хорошо годится для конечных продуктов, делающихся на основе какой-либо CMS.Acceptance — не для библиотек, а для конечных программ.

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

Прочитал с удовольствием. Спасибо

Поразмыслил. Использование питоновского асма — "дело филигранной техники"© bialix.Поэтому красиво уже само по себе.Но возникает вопрос — когда нужно применять, а когда — не стоит.Способов ускорить работу кода много: psyco, pyrex, c-extesion и boost.python, наконец.С перечисленным работал и примерно знаю, чего ожидать.Какие показания и противопоказания для описанного в статье подхода? Т.е. как быстро понять, что оптимизировать нужно именно в сторону асма?

Замечательно изложено. С моим опытом согласуется практически полностью.2 Мрачный заказчик: Контора должна обеспечивать корректные ответы программистов. Технически это весьма просто: project manager или кто там есть на должности руководителя проекта тоже просматривает эту переписку и дает по шапке слишком зарывающимся работникам. Или получает по шапке сам. Это же часть его работы. Если часть становится слишком большой — следует нанять чела на саппорт, и спрашивать с него.Разработчик должен уважать и любить своего пользователя — ведь именно он в конечном счете дает деньги. (Исключения из правила рассматриваются в особом порядке и обсуждаются отдельно).Но нужно заставить пользователя проявлять ответное уважение и помогать разработчику в решении общих проблем. Никакого противоречия не вижу. Несоблюдение этого простого принципа приводит к негативным результатам для всех учавствующих сторон.Тем более пользователь — не злобный тиран, поставивший целью жизни максимально осложнить жизнь разработчику. Он, как правило, готов задавать правильные вопросы чтобы получить ожидаемый ответ в виде исправления/улучшения функциональности. Попытки научить задавать хорошие вопросы воспринимает положительно — или плохо учили.

Обалденная штука. Раньше пользовал py.test, это — лучше. Кстати, никто не писал под него тесты для twisted? Может, есть уже для плагин, повторяющий функциональность twisted.trial?

С++ умер — ха. С умер — трижды ха-ха-ха. Просто на этих языках сейчас не стоит писать программу бухгалтерского учета или сайт интернет магазина. Но если потребуется нечто поболее и высоконагруженное — скорее всего прийдется подумать о том, чтобы сделать некоторые внутрисистемные части таки на сях/плюсах. Потому что иначе тормозят неимоверно.

“/t: Clean; Build”, “/p: Configuration=Release”], cwd=’./winforms’)

Для Гуя используем winforms, через python.net отлично со всем прочим клеится. От Шарпа остается только визуальный редактор (и создание своих специфических виджетов) — подписывание на события тоже на питоне. Не то чтобы я был в полном восторге, но наличие такой библиотеки как DevExpress сильно экономит время и нервы.

P.S. Хороший код — не тот, который правильно работает в «стандартной» ситуации. А который надежно и внятно обрабатывает нестандартные — connection порвался, commit/validation не прошел... Все сложности программирования кроются именно в обработке ошибок — остальное, ИМХО, частности:)