Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×
Официально — Эксперт по Питону в HedgeServ
  • О славной системе контроля версий. Vivat, Bazaar!

    Еще раз посмотрите на возможные workflow.Работа с bzr не навязвает единого стиля. Можно так, а можно этак.Можно «как в svn» — с единым сервером. Можно без него — если мы с другом мелочь мелкую быстро сделать хотим.А можно с «взятием работы на дом», длительной возни с веткой, локальными коммитами — и потом «возвращением в семью».Можно очень по разному. И способ работы тоже можно менять по мере необходимости, ничего проблемного в этом нет.По поводу mercurial: убедили, пошел смотреть. Хотя бы попробовать его, похоже, стоит.

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

    вероятно, некоректно выразился.svn использую три года. Конечно, можно и после этого оставаться некомпетентным, но, надеюсь, это все же не так:)

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

    2bialix: Спасибо. Интересно услышать мнение от «непосредственно работающего лица».Это лицо, конечно же, одновременно и заинтересованное:) Приятно слышать, что со скоростью все не так уж и плохо.Я использавал 0.90.0. Проблем не замечал (может, не добрался до них).А удобство оценил.

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

    А у вас standalone installer? если нет — то открыть файл bzr (у меня он в c:/python25/scripts) и в начале написатьimport sysimport timet1 = time.time () def exitfunc (): print ’eplased time: ’, time.time () -t1, ’secs’import atexitatexit.register (exitfunc) Если очень нужно — можно и собрать версию с поправкой, чтобы переслать вам.

  • О славной системе контроля версий. 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». А поправить так легко!

  • ДОУ собирает друзей

    Хочу прийти

  • Инфраструктура для интегрированного тестирования ПО

    Исходников нет. Вернее есть, но дать не могу. Закрытая разработка. Почему так — для меня загадка. Можно смотреть на открытый 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. Сейчас не понимаю, как можно разрабатывать наш проект без него.Сергей, на вопрос ответил? Или нужны дополнительные пояснения?

  • 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 →