mythmaker
+5
  1. scala
  2. javafx+scene builder
  3. IntelliJ IDEA
  4. JNR
mythmaker
0
Немного некорректно использование термина actor, потому что оно употребляется при использование use cases. User story не просто так названа, мы говорим именно про пользователя, потому что за ним скрывается человек, понять которого нам предстоит.

Кроме того, если вы говорите про экспертов, то хотелось бы видеть экспертов именно в agile.
mythmaker
+1
Да, braintree он такой =(
mythmaker
+1
К кнопкам никаких претензий нет, а вот Express Checkout все таки немного муторная штука. В случае реальных товаров нужно же собирать, например, адрес доставки, и тут начинается…
mythmaker
0
Первый же вопрос — зачем придумывать велосипед, если все описаное есть в Exploratory testing?
mythmaker
0
Нет, на хабре анонса мы не делали, только на сайте agile russia и в одноименной группе на facebook. Плюс в том, что мы эту встречу проводим регулярно, следующая возможно будет в январе-феврале
mythmaker
+1
о, а по какому принципу у вас строится exploratory тестирование? SBTM или что-то свое? Как я понимаю, на вход помимо всего тестировщики получают и скетчи?
mythmaker
0
Спасибо за статью, но она все же спорная, потому что очень категоричная, даже для меня =)
1) мы делаем веб-сервис для интеграции с партнерами
2) в приложении много алгоритмов и внутренней логики, например, валидация ряда параметров или какая-то миграция данных
В этих ситуациях все таки приходится писать текст и вот тут BDD, кстати, работает максимально хорошо.

Опять таки, непонятно, что в итоге с тестировщиками? От тест-кейсов в большом продукте не получается уйти, потому что регрессионное тестирование и прочие вещи. Как вы у себя решаете этот вопрос?
mythmaker
+1
Часть вещей я не написал потому что это секрет фирмы =) В первую очередь это касается того, как мы проводим анализ и определяем текущий уровень компании. Модель строится на существующих в индустрии практиках. Например, когда мы говорим о разработке это касается следующих параметров:
  • наличие VCS и как с ним идет работа
  • практики тестирования (unit, integration,...)
  • работа с Continuous Integration
  • гибкость архитекутры
  • качество кода
  • и так далее

Если говорит об анализе, то нас интересует как именно команда работает на требованиями, как они строят видение продукта и прочее.
По большому счету правильнее назвать наш процесс assessment`ом, но так уж вышло что прицепилось слово аудит.
mythmaker
+1
Как я писал — у нас есть внутренняя модель зрелости компаний с 7 показателями. Ключевым критерием является то, как быстро команда может реализовывать идеи бизнесы и доносить их до клиента. Отсюда собственно и вытекают метрики и критерии.
mythmaker
+1
Обычно, мы обговариваем набор метрик, по котором и видно, как происходит работы. Обратную связь мы собираем постоянно, потому что цель не отсидеть часы и сделать только то, что в них описано, а решить насущные проблемы.
mythmaker
+2
А можно раскрыть, что такое «занимаюсь DevOps»?
mythmaker
+1
Люди уникальны, а вот паттерны поведения одинаковы. Проверено десятком компаний.
mythmaker
0
как раз на подходе статья про Nokia Entertainment
mythmaker
0
проблема в том, что хоть этим утверждениям уже и больше 30 лет, всем как то резко пофигу на них. зато потом большие глаза и фразы «как же так вышло»
mythmaker
0
Тогда нужно слушать вот этот доклад, это именно про DevOps для java в российском проекте для ростелекома.
Или тот же HeadHunter тоже исповедует принципы devops
mythmaker
+1
Если я не ошибаюсь, то оно было написано на фортране. А вот про железо не был в курсе, так как был еще падаваном и изучал яву.
mythmaker
+1
Это был один из самых первых проектов для меня. Писали систему для шедулинга (создание расписания для логистики в данном случае), а эта система отвечала в компании заказчика за внутреннюю бюрократию — счета, платежи и так далее. Так и работали — мы делаем расписание и считаем стоимость перевозок и если ок, то пользователь нажимал большую кнопку и генерировались нужные документы. Надо сказать, что система работала на редкость стабильно.
mythmaker
0
Имел счатье интергрироваться с кодом 75 года розлива, но на этом все и кончилось, внутрь его мы не лезли
mythmaker
+1
Обязательно напишу, скорее всего он будет о направлении в развитии джедаев — мастер, рыцарь и так далее)
mythmaker
0
Гойко знает себе цену, снижали цену как могли
mythmaker
0
Как дополнение к статье, так совпало, что в день публикации провел вебинар на ту же тему, по ссылке видео с него.
Кстати, автор и евангелист Spec By Example, Гойко Аджич, будет вести тренинг в Мск этой весной.
mythmaker
+2
На эту тему в фейсбуке недавно проскакивала картинка =) а вообще мероприятия, инструменты и конференция звучат конечно лучше, извиняюсь за подобный сленг
mythmaker
0
Ну собственно этот пост и готовился как обзорный — просто чтобы начать рассказывать про DevOps как явление. Дальше уже буду делать посты и эвенты про конкретные тулы и приемы. В частности на конфе AgileDays у меня мастер-класс по Chef.
mythmaker
0
Среди российских компаний могу сказать, что HeadHunter идет по пути DevOps. Кроме того, наша компания внедряет такой подходе в ряде компаний. В планах перевести статьи о том, как построили DevOps во Flickr и ряде других компаний.
mythmaker
+1
Да, было бы интересно, но можно ли будет выложить такой код в открытый доступ?
mythmaker
+1
такой вариант тоже принимается, просто если я сам буду просматривать все проекты в open-source на это уйдет несколько лет.
mythmaker
0
Не привык принимать что-то на веру — реквестирую примеры вещей поудобнее) и чем программирование по контракту лучше и мощнее?

И да, ТДД я открыл достаточно давно, но это так, к слову)
mythmaker
0
Возникает стойкое ощущение, что вы не прочувствовали TDD, потому что оно является следующим этапом программирования по контракту и позволяет писать только тот код, который нужен на данном этапе с точки зрения требований. Именно отсюда и возникает эволюционный дизайн. Опять же, важным этапом TDD является рефакторинг, одной из задач которого и является приведение архитектуры к стройному виду.

Вообще, с TDD такая же история как с Agile вцелом, каждый понимает его по своему с налета, не пробую посмотреть по сторонам и поучиться у других. Жаль(
mythmaker
+2
Это легко =) Анонс можно тут разместить.
mythmaker
0
Подход «тесты вперед» всегда позволяет писать правильный код и при этом только минимальное количество. Эволюционный и адаптивный дизайн тоже возникает только при TDD. Детальная документация кода возникает когда тестов много — это раз, и когда в тестах проверяется только нужное — это два. Это тоже возможно только когда они появляются в ходе TDD.
И да, TDD это не юнит-тестирование, это дизайн кода через тесты.
mythmaker
0
Суть данного поста не сводилась к описанию пользы от TDD, я только хотел передать мысль о том, как его внедрять. Сами преимущества описаны по ссылке.
Ключевые из них, на мой взгляд:
  • Когда пишешь тест в начале, думаешь о том, как написать правильный код
  • Детальная документация кода
  • Эволюционный и адаптивный дизайн

mythmaker
0
Первый вариант более правильный, имхо, так как если что, неактуальный тест проще удалить и написать заново, чем пытаться что-то разобрать в связке unit-тестов. По поводу второго варианта — есть возможность задавать данные не из внешнего файла, а из кода; наглядный пример — TestFabric в TestNG для Java. Думаю что-то похожее есть, я думаю, и для других фреймворков/языков.

P.S.: мое имхо, если unit-тест, особенно написанный в процессе TDD, работает с файлами, то это уже не unit-тест, а интеграционный. По-крайне мере я это видел в ряде литературы.

P.P.S.: за ссылку спасибо, интересно!
mythmaker
+1
Спасибо, обновил пост.
mythmaker
0
Кстати, было бы интересно услышать мнение людей, минусующих статья — что их не устроило?
mythmaker
0
Кстати, на правах пиара — сейчас развивается подобное русскоязычное сообщество Russian Software Craftsmanship Community. Мы проводим два типа встреч — XP Battle (ежемесячные встречи с целью изучения одной из инженерных практик) и Code&Coffee (утренние встречи с целью покодить в свободной обстановке). Так же зову всех в группу на FaceBook. В планах есть и CodingDojo, и StudyGroup для изучения книг и многое другое.
mythmaker
0
agile = fail fast. не очень хочется летать на таком самолете =)
mythmaker
0
фейлят конкретные фреймворки типа скрама, нарушая его правила. что же касается agile — принципы нарушаются так же с легкостью, особенно про людей и про документацию.
mythmaker
0
Опять же, проекты для АЭС и прочие, где безопасность человека на 1 месте.
mythmaker
0
написание программы обработки энцефаллограмм — алгоритм известен, ui известен, пользователи известны. используем так называемые good practice и успешно выполняем проект.