Мелкие кремниевые полезности

Selenium - это бесплатное и очень удобное средство автоматизации веб приложений. Работает как библиотека на разных языках (Java, C#, Ruby, PHP, Perl, Python), подключаемая к вашему тестовому сьюту. Там большое количество атомарных методов, но для большего удобства постоянно приходится немного дорабатывать различными дополнительными методами.

Пожалуй правильнее всего с точки срезния разработки не встраивать такие методы в свои тестовые методы, т.к. они не связаны с логикой приложения, но используются в тестах, а унаследовать от основоного класса библиотеки Selenium и добавить такие дополнительные методы именно туда.

Приведу пару примеров, а заодно сохраню их у себя :)

Быстро, не значит плохо

Вчерашняя встреча PM Zone с Томом Альберсом вдохновила меня на самоанализ и как следствие ряд мыслей.

Я представил сколько раз я за эти пару месяцев отложил всяких проблем только потому что не видел необходимого решения или еще зачем то. И что в итоге? Они остались. Т.е. они есть до сих пор и скапливаются, а срочных дел меньше не становится.
Простое и не оригинальное решение для такого рода несрочных и важных задач: первое что взбредает в голову.

Я не знаю, что я еще не рассказал, еще своим сотрудникам о системе и забываю об этом. Пойду повешу их планы прямо рядом с ними и буду помнить об этом.

Как раз такие быстрые и незамысловатые решения могут помочь больше и лучше, нежели отложить

P.S. Вот помнится на Agileee двое ребят очень забавно рассказывали о таком подходе. Жаль Видео нет

The sword and Other Tales

У 66666 дьяволят логины везде одинаковы

Цифры продолжают меня преследовать.

После подсчета общего количества активных пользователей системы, у которых логин и емейл имя строго соответствуют наша БД выдала фееричное число в 66666 пользователей.

Рейс #666

Ничего не предвещало беды. Сидим вечером в офисе и готовим демо заказчику, которое должно было пройти 3 часа назад: как всегда в планируемых фичах начали обнаруживаться всякие блокеры.
И тут ко всему прочему падает билд. Что?! Как?! Оракл?! Где он?!
Вот так вот билд #666 лихо вырубил Оракл на тестовых средах и гордо смотрит на нас сквозь красную иконку "Build Failed"

P.S. Что было с билдом #13 я не знаю

Agileee 2010 accomplished!

Два дня Agileee 2010 прошли даже не как один, а даже быстрее. 4 потока, более 30 докладов и даже не знаю какое число участников. По моим ощущениям близкое к 400, но организаторы знают точно.
Началось все для меня в четверг, когда я все-таки решил поехать, и обнаружил для себя, что регистрация была закрыта. Да уж люблю я легкие пути :) Но где наша не пропадала. Я там побывал и не жалею.

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

Beyond Agile

View more presentations from Andrea Provaglio.

Она не техническая. Не касается ни методологий разработки, ни практик работы с Agile. Автор говорит о том, что важная составляющая Agile это команда, и Agile manifesto говорит нам "Individuals and interactions over processes and tools", но мы продалжаем говорить о процессах и инструментах, и на практике часто забываем о команде.
Следующее выступление я не буду коментировать. Скажу только, что автор Mary Poppendieck, вставлю тут анонс к выступлению и продолжу. Это надо просто просмотреть и подождать видео выступления.

"There is nothing so useless as doing efficiently that which should not be done at all." ~ Peter Drucker
If you look at the history of software failures, the vast majority can be attributed not to technical mistakes, but mistakes in understanding what should be built, what customers will buy, what the system needs to do in order to be successful. The bottom line is this - if we don't build the right thing, we may as not build anything at all. Because customers don't want software - they want a problem solved. And if they could get that problem solved without software - they would be delighted.

Mary Poppendieck “It’s Not About Software”

View more presentations from Agileee.

Еще принимал участие в игровом тренинге François Bachmann "The Art of the Retrospective".  Отметил про себя и для себя варианты визуального представления информации о проекте от Anda Abramovici “Making Feedback Visible” (ничего очень нового и революционного сказано не было, но при должном уровне абстракции восприятия, можно взять на вооружение). Послушал J.B. Rainsenberg'a и мне кажется, что меня скорее впечатлила его манера рассказывать, формат подачи материала и устройство рисования к iPad (или у него просто планшетник и Paint). Т.е. да он прямо по ходу рисовал свои слайды, как будто-бы рассказывал всей аудитории на бумажке как необходимо правильно писать интеграционные тесты. И не могу не отметить ребят из Англии, которые в конце представили свой подход к пониманию и использованию Agile-практик в виде небольшого театрализованного представления