Официально — Эксперт по Питону в HedgeServ
  • QA-outsourcing. Особенности и тонкости

    Вот хоть убейте — не верю в качественный QA «на стороне». Быть может, потому что не видел.Знаю, как нелегко делать outsource программистам — возникает миллион проблем, не предусмотренных первоначальным соглашением.Пробовал создать отдел QA на моей работе лет пять назад — было такое фиаско, что я полностью в тестерах разочаровался. Сейчас понимаю, что мог бы все построить -, но и нам, программистам, пришлось бы поднапрячься, чтобы сделать хорошую среду для QA тестов.Полтора года прошло, как обрел веру опять на новой работе. Спорю с ними, бывает поругиваю втихую (уверен, это взаимно — случалось, что небольшие изменения в программе приводят к переписыванию сотни-другой тестовых сценариев).Но — зауважал и оценил.Наш QA весьма хорош -, но он сидит в одном с разработчиками офисе. И общается постоянно. Удаленный вариант на сегодняшний момент не представляю вообще (быть может, мне предстоит еще раз удивиться?) Тем не менее Все еще уверен, что «ручное» тестирование на поток ставить невозможно — сил не хватит, и тестеры — не идеальные роботы с бесконечным терпением.В лучшем случае это приведет к тому, что баги будут обнаружены через...надцать недель после релиза.К слову, у нас внутренний релиз каждую неделю, и раз в месяц — новая версия продукта.Поэтому тестеры пишут сценарии, которые автоматически гоняет каждую ночь тестовый кластер — одному компу не успеть.Неприятности начинаются, когда этот кластер выдает серию провалившихся тестов — и они попадают разработчикам.Садись, бери кофе, запускай сам — и когда поймешь в чем дело — тащи тестера. Чтобы выяснить — тест о себе слишком много думает, или программа неадекватна. Бывает и третий вариант — все правы, но тест предполагает функциональность итерации, которая будет через два месяца — так что извините.Долго, муторно -, но иначе еще хуже (по крайней мере как я сейчас это дело вижу).Тестеров у нас намного меньше чем программистов — поскольку все автоматизировано. Они тесты пишут, а не по кнопкам тыкают.Кстати, если у вас нет юнит-тестов, continious integration, functional & regression tests — живые тестеры вам не нужны. Это мое убеждение на текущий моментP.P. S.Пребывая в чудесном статусе «эксперта по Питону и сопутствующим технологиям» имею очень много разных сложных задач, не требующих (к счастью, ибо выматывает) взаимодействия с QA. Но когда приходится — их поддержку очень сильно ценю.

  • QA-outsourcing. Особенности и тонкости

    Полной спецификации по продукту не бывает и быть не может.Тем более на момент постановки задачи и начала работы над ней.Никогда живьем не видел зверя по имени «сферический конь в вакууме».

  • QA-outsourcing. Особенности и тонкости

    2Лина.Если работа будет выполнена качественно и довольно быстро — то почему бы и не заплатить.Особенность в том, что вы должны уметь выполнить такое тестирование сами. Или хотя бы очень хорошо представлять, как это делается.Это единственный известный мне способ организовать работу, сделать ее хорошо и при этом остаться довольным.Иначе начинаются всякие неприятные вещи: исполнитель ленится, заказчик не может внятно сформулировать требования или хочет малореального и пр. — нужное подчеркнуть, недостающее вписать. Зато итог закономерен: все участвующие в процессе стороны крайне раздражены и думают уже не совсем о том, как лучше исполнить контракт.Наверное, пишу очевидное: бесполезно нанимать «спецов на нагрузочное тестирование» если нет четкого представления задачи. Спецы могут быть сколь угодно хороши -, но с неадекватным/неподготовленным заказчиком ничего не получится. Верно и обратное.

  • QA-outsourcing. Особенности и тонкости

    2Лина — в вашем случае можно и попробовать.2BAndrik — может и так, если есть хороший техпроцесс.Имею интересный опыт: полтора года работал попеременно то в Нью-Йорке, то в Киеве. Два месяца там — два здесь.Заказчик из штатов.Была возможность сравнить — и ответственно заявляю, что рядом с заказчиком все происходило не в пример быстрей и веселее.Коммуникационное трение резко снижалось — при том что и в Киеве разговаривал с американцами каждый день на планерке и вдобавок регулярно вне ее. Скайп — великое изобретение. Организация была поставлена очень хорошо — по крайней мере на порядок лучше, чем я до тех пор видел.И вот пойди ж ты — расстояние все же играло очень существенную роль.2Кирилл Гончарук -, а что вас смущает? Я — умею и стремлюсь развиваться и дальше.Свою работу делаю лучше, чем окружающие. Задачи смежников тоже могу сделать сам. Как правило хуже и медленней, чем они -, но умею ведь.IT, Database Administration, Infrastructure Team, Support, QA, Continious Integration, Build and Release Management — все эти части хорошо себе представляю. Причем не «вообще» -, а как они функционируют именно у нас. Регулярно помогаю, особенно в части CI и Build Management. Прочим помогать часто не нужно — работа и так хорошо налажена.Не говоря уже собственно о программировании. Проект немаленький, полсотни программистов (наверное, уже больше — никогда их не считал). Три больших команды и четыре маленьких.Десятки мегабайтов кода (и это — в основном довольно лаконичный Питон, на Яве или Шарпе было бы на порядок больше). И тем не менее я в нем довольно свободно ориентируюсь, а изменения в ключевых подсистемах и архитектуре постоянно отслеживаю — и если идет «не туда» — стараюсь корректировать направление движения.Естественно, код отдела, в котором я непосредственно работаю — знаю лучше всего. А свой код — так особенно:) Но это не значит, что я сижу в своей песочнице и за ее пределы даже не выглядываю. Есть у нас на фирме один работник, постоянно повторяющий девиз: «Меньше знаешь — крепче спишь». А довольно многие вслух его не произносят -, но неуклонно следуют.Это — не мой путь. «Уметь самому» нужно по следующим причинам: — чтобы лучше представлять общую картину, и иметь возможность на нее влиять. Дьявол — он в деталях. — сильно упрощается взаимодействие между подразделениями. Пояснять, думаю, не нужно. — легче избежать ситуации «лебедь, рак и щука». Но гарантировать ничего нельзя, конечно... — пресловутые взаимоотношения. Когда я помог Пете, а Петя в свою очередь когда-то помог мне — это здорово объединяет (получше тимбилдингов, но и они тоже очень и очень полезны). В результате когда я в следующий раз к Пете подойду со своей проблемой — он весьма внимательно меня выслушает и изо всех сил постарается помочь. Знаменитая петля обратного эффекта. К тому же это просто по человечески приятно. — имею возможность постоянно и довольно быстро обучаться новому у спецов своего дела, причем очень малой ценой. Конечно, я до этих спецов не дорасту, да и цели такой не ставлю. Все же программирование — это мое все. Но немного расширить свой горизонт познания — очень полезно. — на стыках периодически возникают интересные возможности. Когда смежники не могут выйти за рамки -, а мы даже не догадываемся, что у них есть затруднения, которые мы можем решить на «раз-два-три», немного переделав код. И это тоже может быть большой проблемой. (К слову, мой друг относительно недавно таки нашел свое призвание.Он довольно таки посредственный художник (двухмерка и в основном трехмерка). Креатива не хватает. И такой же посредственный программист. Плюс еще твердые знания по верстке, теории цвета, трехмерной математике, шейдерам и постэффектам — короче говоря, универсал.С руками и ногами взяли на специально для него созданную должность Technical Artist, где он себя наконец смог реализовать по полной программе. Влад, как я понимаю, счастлив. А его работодатели довольны не меньше, ибо таких редких спецов днем с огнем...) — «лапшу на уши» вешать не смогут — что очень ценно. — повышается ценность лично меня как сотрудника на данной конторе (немаловажная мелочь). — наконец, это просто очень приятно. Хочется работать! Прийти на следующий день (единственно огорчение для меня — как сова рано просыпаться не люблю) и снова заняться любимым делом, получая в ответ новую порцию удовольствия.Я ответил на вопрос?

  • QA-outsourcing. Особенности и тонкости

    2 Кирилл Гончарук. Под «соседними функциями», надеюсь, вы понимали не код в файле, лежащий рядом с вашим? Я все еще не представляю себе «достаточно далекую область», которую невозможно изучить -, но при этом имеющую отношение к разработке ПО.Можете привести пример? На работе я совсем не вникал только в бухгалтерию и хозяйственные службы. И не представляю, о чем таком важном думает Самый Большой Босс.2 Николай Скотынянский — полностью с вами согласен.

  • Введение в многоэтапное метапрограммирование и метаязыковую абстракцию

    Пишу в основном на Питоне. С созданием новых языков, парсеров и проч не заморачиваюсь. Не нужно.А встроенные DSL создаю постоянно. Т.е. интенсивно используя декораторы и метаклассы в разы сокращаю объем кода, генерируя его на лету. При этом сохраняю синтаксис Питона -, но создаю свою семантику.Результат мне нравится. Ребята иногда жалуются на то, что всякие IDE перестают работать так, как им хочется. Например, отказываются выполнять автодополнение и кричат о несуществующих именах атрибутов (они появляются только в runtime). С отладчиком бывают сложности — глубокий стек вызовов. Это — личные проблемы сотрудников. Я IDE не люблю и не использую. Зато все отмечают лаконичность — и этот довод все перевешивает. Меньше кода — меньше ошибок. Да и отладчик становится почти не нужным при правильно организованном процессе — и его неиспользование тоже экономит время. Часто подход напоминает фразу из известного мультика — «лучше час потерять, но потом за 5 минут долететь». Если владеешь материалом — можно избежать незавидной участи вороны. Если нет — проще все-таки быть страусом.

  • Python: Веб-разработка без фреймворков (ответ на критику)

    Сергей, всю серию читал с интересом.Вывод «для себя»: предлагаемый подход — «для профессионалов».Django хорош, если не хочется долго разбираться, а нужно «просто сделать сайт, и быстро». В нем уже очень много есть — плюс отличная документация (для кого-то это очень важно, я привык читать исходники). И большое community, contibs и прочее. Сильная завязка на базу данных — плюс и минус одновременно. Легко написать что-то работающее — и сложнее перестроить систему «под себя».Pylons требует больших знаний для изучения -, но гораздо гибче. Правда, многое нужно «делать с нуля» — и делать это можно самыми различными способами. В том числе и уродливыми. «Почувствовать» правильный путь может быть не легко. Документация — откровенно слабая (я уже говорил — для меня не критично). Друзья испытывали довольно сильное «трение вхождения».Чистый WSGI самый гибкий и одновременно самый требовательный. Слишком легко начать писать «не так». Но, одновременно, при правильно выбраном пути (чутье и опыт) — позволяет писать очень эффективно.Это — общий обзор. Не сомневаюсь, что Иван Сагалаев способен выкрутить из Джанги все, что ему нужно — он более чем отлично ее знает.Каждому — свое. И чем меньше нужно в конкретном приложении работать с пользовательским интерфейсом — тем более резонным становится выбор WSGI. Если нужно сделать web service с основным упором на API — зачем мне Джанга/Пилоны? (А есть еще нежно любимый мною twisted, который главным образом не для HTTP).Резонным выглядит разбиение проекта на отдельные сервисы и независимый для каждого сервиса способ реализации.На последнем exception разговаривал с парнем, который сказал: они используют twisted для долгоиграющих и системных нужд. Интерфейс пользователя — на Джанге (так проще и быстрее всего). Связь — через БД (узкое место, не для всяких задач подойдет. Но можно делать и иначе). Результатом более чем довольны.Резюме: для каждой задачи — свой инструмент, наиболее подходящий. И чем задача комплексней — тем больше различных инструментов требуется. Инструменты подбираются «под себя».Серебрянной пули не бывает.

  • Python: Веб-разработка без фреймворков (ответ на критику)

    Фреймворки не экономят время (на любом большом проекте это заметно). Главная их миссия — нести идею в массы. Позволять ньюбам быстро писать что-то работающее.Ньюбы не очень-то знают, что такое HTTP — зато они выучили HTML и знают магию, заставляющую запустить AJAX. Этого достаточно для владения фреймворком. На уровне «сделать простой сайт».Ты думаешь на уровне HTTP — и «небо не обрушивается» — спасибо, отличные слова. Все получается быстро и просто — Дзен по Питоновски. Но это — результат опыта и знаний (очевидное решение может не казаться таковым, если ты не GvR). Я сейчас делаю что-то вроде sqlalchemy для моей работы — просто потому, что должен работать с герерогенными базами, и они не далеко всегда предоставляют SQL фасад (django ORM не рассматриваем — ugly. SQLObject тоже сильно кривой). Результат — написал основу сам. Заимствовав у алхимии основы архитектуры. Оказалось — не слишком-то много работы. И тоже — небо не обрушилось. Другой вопрос — смог ли бы я сделать нечто подобное два года назад? Знаний и умений хватило бы? Давай таки остановимся на том, что «каждому — свое». А по мере профессионального роста стоит иногда попытаться увидеть привычную проблему с новой точки зрения.

  • Python: Веб-разработка без фреймворков (ответ на критику)

    Вспомнилось почему-то интервью с создателями live journal. — Мы ненавидим изобретать колесо. Но если колесо не существует или оно квадратное — мы не боимся изобрести круглое колесо.Frenzy, какое количество разработчиков, уровень текучести и срок разработки нужен, чтобы почувствовать непреодолимую потребность именно в фреймворках? Я всегда основывал свой выбор на несколько иных критериях, поэтому мне очень интересно.

  • Python: Веб-разработка без фреймворков (ответ на критику)

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

  • Python: Веб-разработка без фреймворков (ответ на критику)

    От плохой организации работы «известный фреймворк» не спасает. Совсем.

  • Python: Веб-разработка без фреймворков (ответ на критику)

    Плохая организация — если такая ситуация смертельна для проекта.Коллективное владение кодом спасает.

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

    Сразу предупреждаю — mercurial в глаза не видел. Про различия и сходство ничего сказать не могу. Как и о скорости — я пробовал на относительно небольших проектах. Где предел у bzr, после которого он начинает тормозить? Распределенная, или децентрализованная разработка предполагает необязательность единого сервера. Т.е. можно с ним, а можно и без него. Вот что пишут и рисуют на сайте bazaar

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

    2Анонімно: с остальными синхронизируете вы сами. Теоретически после того, как система прошла все тесты:) Если bzr на момент commit видит, что файл удален — автоматически проводит его как операцию удаления.В svn нужно написать svn rm filename. В bzr достаточно просто удалить файл.Кстати, bzr status отлично отмечает эти изменения.

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

    2Родион Быков: можно и к Апачу

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

    Вообще-то история лично у меня вызывает те же ощущения, что и переползания с CVS на SVN.

← Сtrl 12 Ctrl →