вероятно, некоректно выразился.svn использую три года. Конечно, можно и после этого оставаться некомпетентным, но, надеюсь, это все же не так:)
2bialix: Спасибо. Интересно услышать мнение от «непосредственно работающего лица».Это лицо, конечно же, одновременно и заинтересованное:) Приятно слышать, что со скоростью все не так уж и плохо.Я использавал 0.90.0. Проблем не замечал (может, не добрался до них).А удобство оценил.
А у вас standalone installer? если нет — то открыть файл bzr (у меня он в c:/python25/scripts) и в начале написатьimport sysimport timet1 = time.time () def exitfunc (): print ’eplased time: ’, time.time () -t1, ’secs’import atexitatexit.register (exitfunc) Если очень нужно — можно и собрать версию с поправкой, чтобы переслать вам.
2bialix: Спасибо вам за хорошие ответы.Я консервативен в используемых системах облегчения жизни разработчика.Долгое время меня устраивала svn, о чем вам не раз и писал.Потом сменились внешние обстоятельства, и стало возможным поискать альтернативу — благо была одна на примете:) Эксперимент считаю удачным для себя.Буду рекомендовать друзьям и приятелям.Кстати, а что вам НЕ ПОНРАВИЛОСЬ в Базаре? На какие неудобства вы наткнулись? Крайне интересно услышать критику от весьма знакомого с системой человека.Скорость... В самом моем большом проекте было около 250 файлов. Неудобств по скорости не ощутил. Так же быстро, как и svn. Мне показалость приемлимым.Конечно, было бы интересно оценить на моем последнем проекте.Там было порядка 15 000 файлов в svn, и svn откровенно тормозила. Она тормозила заметно даже на другом проекте из 1500 файлов.Из мелочей. В svn help тут же показываются короткие сочетания (update (up), commit (ci), checkout (co), move (mv), status (st) и т.д.) В bzr это неочевидно. Понял, что оно работает — только забывшись и по привычке написав «как в svn». А поправить так легко!
Хочу прийти
Исходников нет. Вернее есть, но дать не могу. Закрытая разработка. Почему так — для меня загадка. Можно смотреть на открытый PyFIT.Модулей с фикстурами — порядка сотни. Большинство фикстур до смешного простые и короткие. Исчезающе малая часть по сравнению с тысячами тестовых файлов (а учитывая многостраничность excel общее количество тестов уверенно переваливает за десять тысяч).Тестировщики ни одной строки кода не написали, зато бодро ваяют excel’ки.
Конечно же, технология подходит не для всего. Для CMS, кажется, не подходит для CMS как продукта и хорошо годится для конечных продуктов, делающихся на основе какой-либо CMS.Acceptance — не для библиотек, а для конечных программ.
Да, еще.Задание по внесению новой функциональности начинается, естественно, с обсуждения:, а что, собственно говоря требуется? Но к моменту deployed to QA у этих самых QA-тестировщиков должен уже быть готов fit тест на это дело.Если что-то «завалилось» — то тесты показывают, что именно.Конечно же, вся эта лавочка служит преимущественно для облегчения работы с теми ребятами, которые говорят «что должно получиться в конце концов».На чисто программерские заботы никак не отражается. Я, занимаясь преимущественно архитектурой проекта, с такими тестами редко имею дело. Но они реально помогают.
Могу рассказать, как дело обстоит у нас. Пишем софт для работы на финансовом рынке (очень похож на традиционный банковский).Программеры успешно кропают свои юнит-тесты и большего им не нужно (а если тестов мало — приходит начальник и в нескольких простых понятных фразах объясняет, что к чему).Юнит-тесты — действительно очень классная вешь.Но у нас есть отдел тестирования и мужи от бизнеса, которые на фондовом рынке собаку съели, а на Питоне писать не могут. Заявляют, что програмирование на Питоне для них — слишком сложная наука:) Выход — именно в том подходе, который описал Всеволод. Правда, мы используем не fit, а asgard — он делает практически то же (в какой-то степени клон), но в качестве входных данных понимает excel таблицы. Так проще нашим business guys и эти таблицы гораздо удобней редактировать. Все, что им нужно знать — как следует описывать данные для конкретной фикстуры и какие фикстуры нужно упоминать в тесте. Причем в детали реализации фикстур они не вникают — просят программистов сделать им «такую-то и такую-то» (на самом деле отражающую реальное поведение программы) — и все. Они запускают свой тест, видят, что не все отработало. Начинается общение с программерами (предметное). Проблема всегда обнаруживается (по убывающей) в некорректных исходных данных, в неправильной работе программы, в некорректной фикстуре. И быстро лечится. Все довольны. Отклик — очень быстрый. Регрессионные тесты — тщательно обрезанный набор fit тестов (у нас их зовут dev acceptance). И acceptance тысяч шесть, в то время как юнит-тестов «скромные» 2000 с копейками. Мы, программисты, просто не в состоянии написать такое плотное тестирование. Вдобавок полный прогон юнит-тестов занимает 7 минут, acceptance — 3 часа (они делают гораздо больше, работая с реальным источником данных).P.S. У нас нет «ручного тестирования» — его заменяет acceptance.P.P. S. Пока не перешел на эту работу — тоже не понимал, зачем fit. Сейчас не понимаю, как можно разрабатывать наш проект без него.Сергей, на вопрос ответил? Или нужны дополнительные пояснения?
Статья хорошая.Сейчас эти пункты для меня очевидны. Но путь к пониманию был долог и труден.
Прочитал с удовольствием. Спасибо
Поразмыслил. Использование питоновского асма — "дело филигранной техники"© bialix.Поэтому красиво уже само по себе.Но возникает вопрос — когда нужно применять, а когда — не стоит.Способов ускорить работу кода много: psyco, pyrex,
Замечательно изложено. С моим опытом согласуется практически полностью.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 не прошел... Все сложности программирования кроются именно в обработке ошибок — остальное, ИМХО, частности:)
Еще раз посмотрите на возможные workflow.Работа с bzr не навязвает единого стиля. Можно так, а можно этак.Можно «как в svn» — с единым сервером. Можно без него — если мы с другом мелочь мелкую быстро сделать хотим.А можно с «взятием работы на дом», длительной возни с веткой, локальными коммитами — и потом «возвращением в семью».Можно очень по разному. И способ работы тоже можно менять по мере необходимости, ничего проблемного в этом нет.По поводу mercurial: убедили, пошел смотреть. Хотя бы попробовать его, похоже, стоит.