Официально — Эксперт по Питону в HedgeServ
  • О славной системе контроля версий. Vivat, Bazaar!

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

  • О славной системе контроля версий. Vivat, Bazaar!

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

  • О славной системе контроля версий. Vivat, Bazaar!

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

  • О славной системе контроля версий. Vivat, Bazaar!

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

  • О славной системе контроля версий. Vivat, Bazaar!

    Тогда уж лучше 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 — не для библиотек, а для конечных программ.

  • 10 вещей, которым я научился за 10 лет профессиональной разработки ПО

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

  • Стиль удава: компиляция на лету

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

  • Стиль удава: компиляция на лету

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

  • Об эффективных багрепортах

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

  • Тестирование Python-приложений: от unittest к nose

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

  • Насколько реально востребованы навыки программирования на ассемблере

    Писал embedded. На C и немного на C++ -, но почти никогда не на ассемблере. Если у контоллера есть хоть немного памяти на программу и данные — существует C компилятор.
    Писал gemedev — на Питоне и немного на C++ (хоть эта небольшая часть и была самая критичная).
    Драйвера — С и С++ (последнего все больше, ибо удобен). Под винду и 3 года назад можно было писать на плюсах — сам делал (но stl был значительно обрезан).
    Сейчас пишу на Питоне и немного на C#. Чуток на С++.
    Так вот: писать на АСМе сейчас практически не нужно. Но ВСЕГДА рано или поздно сталкивался с тем, что нужно уметь читать АСМ. Либо для того, чтобы сделать действительно оптимальный код, либо — что гораздо чаще — чтобы суметь правильно прочитать stack trace и поймать эту самую чертову ошибку.
    Мне довольно часто приходилось видеть этот «кошмар прикладного программиста», когда большая и сложная программа валится на невнятном сообщении «выполнена недопустимая операция». И без знания АСМа понять, что случилось — невозможно. Со знанием, впрочем, тоже не то чтобы легко.

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

  • Скрипт рейтинг

    Python. Если он есть — bat файлы не нужны. Если есть С++ (на предыдущем проекте) или С# (на текущем) — собирается все равно Питоном. Тем более что чудесно работает такая вещь:
    log.info (’COMPILE WINFORMS’)
    verbose = ’/verbosity: quiet’ if self.verbose else ’/verbosity: normal’
    subprocess.check_call ([r’c: \WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe’, ’Views.sln’, ’/nologo’, verbose,

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

  • Темы новых статей

    Интересно про deployment. Сейчас медитирую над blog.ianbicking.org/...a-build-system и пытаюсь сделать свой внятный процесс сборки дистрибутива (как для серверной части так и для клиентской). С ветками, тагами, обязательным запуском юнит-тестов и проч.

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

  • О качестве кода и профессионализме

    Достал с полки одну из любимых книг по программированию: Герб Саттер, Андрей Александреску, «Стандарты программирования на С++».
    Цитата из предисловия:
    В напряженной обстановке, при жестких временных рамках люди обычно делают то, чему их учили, к чему они привыкли... Когда на нас давит график работ..., мы работаем так, как приучены. Неряшливые программисты, которые даже при обычной неспешной работе не помнят о правильных принципах разработки программного обеспечения (а то и вовсе незнакомы с ними), при нехватке времени окажутся еще небрежнее, а их код будет изобиловать ошибками. Соответственно, программист, который выработал в себе хорошие привычки и регулярно ими пользуется, при «повышенном давлении» будет продолжать выдавать качественный код.
    Доки писать не люблю — пытался когда-то, но слишком много времени уходит на поддержку их актуального состояния. Докстринги — пишу для public интерфейса. Поскольку они в самом коде, то читаются постоянно (и поддерживаются в адекватном состоянии). Юниттесты тоже пишу. В начале разработки подсистемы — много. Часть из них — dev acceptance. Оформленный как unittest пример использования, но таковым не являющийся. Потому что зависит от окружения (лезет в базу данных, общается с миром, требует предварительных настроек, исполняется долго). Не может быть исполнен на системе автоматического тестирования.
    Потом — на каждое внесение новой функциональности и на каждый обнаруженный баг. Юниттесты — для библиотек. Чем выше уровень (ближе к пользователю) — тем юниттесты писать сложнее. У нас для этого fit тесты, и пишут их тестеры.
    Хороший код — максимально простой, но не проще (почти по Эйнштейну). Меньше багов и проще понимать другим. Остальное дополняется простым человеческим общением (и работой в паре, конечно). Эффективно заменяет горы документации.
    Вопрос «правильной» нотации для меня выглядит странно. В рамках модуля нотация должна быть единой, а дальше — как повезет. Уговорить всех — невозможно (мы используем библиотеки сторонних разработчиков, а у них тоже свои предпочтения). Да и не важно это. Ширина строк — должна вмещаться на экране вашего редактора. И если у всех программистов экраны по 32 дюйма — можно писать очень длинные строки.

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

    Підтримав: Volodymyr Sharayenko
← Сtrl 12 Ctrl →