• Let the Holy War begin: Java vs С++
    +5
    1. scala
    2. javafx+scene builder
    3. IntelliJ IDEA
    4. JNR
  • Работаем с User stories: Руководство Gov.uk
    0
    Немного некорректно использование термина actor, потому что оно употребляется при использование use cases. User story не просто так названа, мы говорим именно про пользователя, потому что за ним скрывается человек, понять которого нам предстоит.

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

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

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

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

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

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

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

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