С 15 по 17 декабря в Киеве пройдет одна из крупнейших и авторитетных конференций по разработке программного обеспечения. Как легко понять из названия конференция носит практический, а не теоретический характер. На основную часть конференции уже зарегистрировалось более 200 человек из более 50 компаний.

Организаторы приложили максимум усилий для того, чтобы привезти на конференцию известных докладчиков и тренеров, которые стояли у истоков современных инженерных подходов. Это даст участникам возможность получить информацию из первых уст. Будут освещены основные инженерные практики: Unit Testing, TDD, Continuous Integration, BDD, Code Review, Refactoring, Acceptance Testing и другие. Также будут обсуждаться вопросы архитектуры в Agile проектах, борьбы с технической задолженностью, взаимоотношений разработчиков и тестировщиков, а также многие другие проблемы современной разработки.

Давайте посмотрим, что нам приготовили организаторы конференции!

Поздравляем всех с Днем программиста и напоминаем, что уже через 5 дней в Москве начнется HackDay #7.

На хакдее сможете:

• собрать команду под свою идею или присоединиться к существующей;
• послушать практические мастер-классы и на их основе разработать свой проект;
• научиться разрабатывать приложения для iPhone/iPad;
• разработать приложение виртуальной реальности;
• разработать приложение дополненной реальности.

А также обзавестись новыми контактами и провести время весело и с пользой.

Регистрируемся здесь.

"Отзывчивый" - в данной ситуации означает "изменяющийся в зависимости от окружающих реалий".

Предлагаю вниманию свой взгляд с иллюстрациями на сущность «отзывчивого», развиваемого дизайна. Меня заинтересовал конспект лекции об «отзывчивом дизайне», поскольку текущая наша разработка идёт именно в таком ключе — функционал добавляется понемногу, в процессе уточнения и переосмысления задач, без революций, с хорошим пренебрежением к академической идеальности и законченности, которой в процессе развития просто не имеет права быть. Это по-своему замечательно — пренебрегать правилами валидности (они — для будущего), кроссбраузерности (функционал есть, но отображается в IE c долей снисхождения) и концептуальности до момента, пока функционал системы не определён. Она имеет только те куски «мяса», которые работают, отработавшие куски постепенно удаляются. Именно это описывает Кент Бек в своей лекции, поэтому так живы и богаты ассоциации с его классификацией о четырёх стратегиях.

Все много писали про «Парное программирование». Как это клёво и всё такое. Но как бы возникает проблема, что два программиста за день пишут как бы 150% работы одного программиста. Ну то есть теоретически меньше.

А вот у нас в компании было так, что просто за каждым коммитером (тот кто имеет право добавлять код в основную ветку программы) был назначен ревьюер и после коммита в trunk (основную ветку программы), тикет (да!!! каждый коммит должен быть сделан по тикету) переводился на ревьюера (в тикете писался номера коммито(ов) для этого тикета). Ревьюер отсматривал изменения и или переводил тикет тестеру или же возвращал его коммитеру по одной из причин: логическая ошибка, не соблюдение правил кодирования, сложный код который нельзя прочитать и он не задокументирован, ну или же он явно видел ошибку в коде (напр. забыл проэскейпиться).

Таким образом повышалась как читаемость — соблюдались все правила кодирования, так и документированность — сложные участки кода были задокументированы.

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

А у вас что-нить подобное использовалось/используется?

UPD. понял свою ошибку. Переименовал топик.

Вслед за обзором автоматизированных тестов, расскажу о еще одной технологии «экстремального программирования» (XP), с которой я столкнулся в своей практике.

Итак, парное программирование. Как оно выглядит? За один компьютер садятся два человека. Один из них пишет код за клавиатурой, второй сидит рядом и дает советы. Время от времени они меняются ролями. Проходит рабочий день и оказывается, что они написали в полтора раза больше кода, чем вчера, когда каждый сидел за своим компьютером. Эй, что за чертовщина происходит?

Практика экстремального программирования включает в себя "Small Releases" - частый выпуск "коротких" релизов программ с интервалами в несколько недель.
Подразумевается, что нужно это для того, чтобы получать "обратную связь" от пользователей и вовремя вносить изменения. Сами релизы при этом, как правило, включают 1-2 "фичи" и исправление некоторых (а не всех) ошибок.

Мне интересно, насколько эта практика имеет смысл и пользу при разработке коммерческих программных продуктов. Нужны ли пользователям на самом деле частые релизы? Какой им интерес выступать, по сути, постоянными бета-тестерами?
Мне представляется, что короткие релизы не позволяют планировать заранее большие изменения. Насколько такая практика способствует (или не способствует) сохранению идейной и архитектурной целостности продукта?

В индийском R&D-подразделении Microsoft изобрели новую технологию, которая позволяет разделить монитор на две независимые части, так что за одним ПК могут спокойно работать два человека: один — на правой половине монитора, второй — на левой.

Разумеется, на две части делится не только монитор, но и все остальные ресурсы компьютера, в том числе загружаются две копии операционной системы Windows с двумя курсорами, поддержкой двух клавиатур и двумя наборами приложений. Каждый пользователь может «залезать» курсором на чужую половину и помогать напарнику в работе.