среда, 30 декабря 2015 г.

Сборная солянка видеодокладов для самообразования на разную тематику - Выпуск 6

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

Медиатека: просто мноооооого видео от Стаса Фомина. Кому скучно на каникулах - welcome.

Уже древняя запись квартирника с Codefest 2015 "Мир без тестировщиков. Миф или реальность?" Даже не знаю, почему она у меня в до сих пор не опубликована была.


Куда класть исходники Немного best practice от Григория Петрова

Как не угробить свою архитектуру Евгений Кривошеев про то, что это такое "архитектура" и как с ней жить.

Внутреннее устройство PostgreSQL (как работает механизм транзакций, рекомендации к тюнингу производительности). Статья про одну из тем доклада.

"Без слайдов" интересное интервью с Дмитрием Завалишиным про IT-бизнес.

Слава Панкратов: "Как включить ответственность в сотрудниках?"
Интересно и на примерах. Интересно, где-нибудь применяется, или эта магия никому не нужна?
Еще видео с конференции НайтиОтвет#9.

Запись доклада с конференции LinuxPiter "Container security". Немного сбивчиво, но идея понятна. Больше докладов с этой конфы.

Всех с наступающим! Больше знаний и возможности их применения :)

вторник, 22 декабря 2015 г.

Где грань между программистом и тестировщиком?

Такой вот полет мысли, может достаточно сумбурный родился после прочтения сегодня двух хороших статей: "Roles and Fluidity" Алана Пейджа и история про изменения в процессе разработки в Yahoo! "Who Needs QA? Not Yahoo!"

Еще вчера с товарищем Papa Minos (aka Никита Макаров) делились впечатлениями от выпуска RadioQA "QA: Пациент жив или мертв?", где @umputun раскатывал всех в тонкое тесто (хотя получилось это у него натужно и скорее в силу авторитета, а не согласия оппонентов).

Как мне кажется, всё сходится к одному: ролей, которые приходится играть при разработке ПО, много (здравствуй, КО). И искусство, мастерство, если хотите, заключается в том, чтобы уметь между этим ролями переключаться.

Кому то это удается хорошо, кто то справляется хуже, а кому то это вообще неинтересно, но роли есть и это факт.

четверг, 5 ноября 2015 г.

Отзыв "Искусство войны в иллюстрациях"

В посылке, полученной от издательства "Манн, Иванов и Фербер" для участников IT Global Meetup 6, была интересная книжечка "Искусство войны в иллюстрациях". Не удержался и, воспользовавшись "служебным положением", полистал ее.
Очень забавная книжечка.
Давно хотел почитать "Искусство войны", но каждый раз заканчивал на первых страницах. Тяжело давалась восточная мудрость. Даже скорее не сама по себе военная мудрость, а ее трансляция в обычную жизнь.

Тут же перед нами оригинальная попытка перевести витиеватые восточные фразы, да еще и на военную тематику, на современный язык графическим способом. В итоге получился сборник советов для менеджеров, тех кто планирует ими стать и сочувствующих :)
На самом деле, есть даже советы и просто для жизни.
Понятно, что этот "перевод" скорее всего субъективен, но большей частью получилось очень изящно.

Рекомендую и вам посмотреть, хотя бы в книжном магазине полистать :)

Ниже несколько цепанувших меня картинок.

среда, 28 октября 2015 г.

Анонс "IT Global Meetup #6" (Питер)

Уже традиционное ежеквартальное мероприятие IT Global Meetup от Piter United.
Шестая встреча, и уверен, что не последняя :)

С каждым разом количество участников растет и уже превышает 750 человек.

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

Регистрируйтесь и приходите 28 ноября по уже привычном адресу: СПб, пр.Медиков, д.3

Издательство "Манн, Иванов и Фербер" снова с нами, и у нас опять есть чем отблагодарить волонтеров, помощь которых приветствуется.
Книги волонтерам от издательства "Манн, Иванов и Фербер"
Ммм, "Искусство войны" в картинках, я аккуратненько гляну, можно? :)

Отчет с конференции "IT NonStop Санкт-Петербург"


23 октября прошла питерская серия глобальной конференции "IT NonStop" от компании DataArt.

Конференций по IT-тематике проходит много и зачастую сложно угодить требовательным слушателям: то доклады сыроваты, то докладчики выступают со своими "заезженными" презентациями.

Надо отдать должное организаторам "IT NonStop" - лично я не видел ни одного доклада, который бы уже мелькал где то. Ну а насчет сырости докладов, потупив глаза, отнесу свой к их числу :) Надеюсь остальные больше понравились участниками.

Организаторы сделали 2 секции (менеджерскую и техническую) по 8 докладов в каждой. С одной стороны это дало многообразие тем и повысило общий интерес, с другой - усложнило жизнь докладчикам. Уложиться с чем то интересным за 25 мин можно, но сложно. Мне, во всяком случае, точно :)

среда, 21 октября 2015 г.

Анонс доклада на "IT NonStop Петербург"

Осталось всего 2 дня зарегистрироваться на IT NonStop в Питере

Буду там рассказывать про FitNesse+PowerSlim.

Доклад всего 30 мин, поэтому будет по верхам, но после доклада можно пообщаться и про "вглубь и вширь" :)

Приходите ;)

ЗЫ Отчетик чуть позже. Пока вот слайды

Можно посмотреть а-ля слайдкаст со звуком. Если запустить видео, то как раз мой доклад будет. Но похоже я вышел за границы камеры и никто мне не маякнул...

Заодно и другие доклады технической сессии посмотреть

пятница, 25 сентября 2015 г.

75 ссылок посвященных тестированию, безопасности, общетехническим вопросам и прочему (ссылка на блог About98PercentDone)

Себе в сундучок.

Мощная коллекция ссылок про тестирование, тестирование безопасности и прочее by JCD

Link Mania: 75 Links with Commentary on Testing, Security, Tech and Life

Смотреть, не пересмотреть :)

И в рубрике "о чем мы писали год назад":


пятница, 18 сентября 2015 г.

Конспект "Управляя изменениями" И.Адизес

Издательство "Манн, Иванов и Фербер"

Интересная книга Ицхака Адизеса от издательства "Манн, Иванов и Фербер". Автор опираясь на свою теорию менеджмента PAEI пытается рассказать как мы можем попытаться управлять изменениями вокруг нас.

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

В целом я бы ее порекомендовал к прочтению. Ниже я приведу наиболее зацепившие меня места. Вообще у меня получился скорее конспект, чем отзыв с размышлениями. Но каждая цитата ниже запустила во мне цепочку размышлений. Если интересно, можно обсудить в комментариях

четверг, 27 августа 2015 г.

Про техническое собеседование от создателей Hexlet.io

"...Я считаю что собеседование прошло успешно, когда кандидат в конце спрашивает - 
"Блиин, что мне надо почитать, куда двигаться, что делать, чтобы все это знать?"..."
К.Мокевнин
Запись вебинара про собеседования от создателей Hexlet.io
Кроме интересных технических моментов Кирилл делает упор и на soft skills.
Основные советы для собеседования junior-ов, но есть много интересных моментов и про сеньоров.

Заметки (с точки зрения того, кто проводит собеседы):
1. Отличная задача про часы (сколько градусов между часовой и минутной стрелкой в 15ч 15мин). Мой старший сын не решил, хотя должен был легко. Буду теперь тоже на собеседах использовать (хотя они и крайне редко теперь у меня организуются)
2. Кирилл рекомендует использовать задачи на логику, именно техническую, а не творческую. Особенно для джуниоров. Упоминался интересный ресурс http://www.braingames.ru/. Сам я такие задачи не люблю, но возможно имеет смысл попробовать.
3. В противоположность таким задачам, задачи в стиле "как сдвинуть Фудзи" малополезны.
4. Обращайте внимание на то, как человек общается и может формулировать свои мысли
5. Дальше стандартные вопросы на алгоритмы, перестановки символов в строке и тп
6. Кирилл проехался танком по аутсорс-компаниям :)
7. На вопрос "Что ответить кандидату, когда его спрашивают про зарплату?" Кирилл ответить не смог :)
8. Ожидать ли объяснения отказа и что за этим стоит. Тут надо вспомнить отечественные реалии и изменения в Трудовом Кодексе. Интересно, уже кому-нибудь приходилось это делать?

Вообще рекомендую глянуть, очень бодро, много примеров из жизни. Я с Кириллом общался на конференции AgileDays2014 . Очень интересный тогда был доклад.

Вместе с докладом про собеседы они дают хорошую картинку того, как должна выглядеть компания (команда)-мечта, если ты ее строишь сам, или помочь выбрать такую компанию.

понедельник, 17 августа 2015 г.

Премирование в IT - фикция или работающий инструмент?

Отличный доклад с конференции "Найти Ответ #9"


Очень актуально он для меня нарисовался в новостной ленте. Содержимое порадовало.

Спойлер для ленивых: Элеонора считает, что это фикция! И я с ней согласен.

Доклад будет полезен тем, кто считает что премии у нас в IT таки работают - есть шанс внять советам и не косячить грубо, когда вы их внедряете, меняете систему премирования и тп.

Спасибо IT-Доминате за возможность посмотреть видео докладов. Пока там далеко не все, но будем надеяться, что постепенно их откроют ;) Но тут можно посмотреть все презентации.

вторник, 21 июля 2015 г.

Релиз Visual Studio 2015

Просто линк, чтобы потом не искать.
Внутри много полезных ссылок по новшествам в этой студии касательно C++

Еще один линк про поддерживаемые таргетные Windows-платформы.

Поддержка C++ не устанавливается при сетапе по умолчанию. Странное решение.

пятница, 5 июня 2015 г.

3 главных вещи для инженерного лидера по мнению С.Протасова

2.5 года назад я рассказывал о видеоинтервью Станислава Протасова.

Сейчас попалась очень интересная статья-интервью с ним. Рекомендую.

Что изменилось за это время? Если раньше Станислав говорил о толковости, нацеленности на результат, коммуникабельности, как о 3-х ценных качествах менеджера, то сейчас это трансформировалось (слегка) в

"...инженерный лидер должен хорошо делать три вещи. Первое — хорошо управлять людьми: вдохновлять, вести за собой, мотивировать. Второе — хорошо разбираться в технологиях: какие технологии отмирают, какие появляются, что правильно делать, что неправильно. Третье — обладать хорошим вкусом в управлении продуктом: интерфейс удобный, юзабилити высокое. Нормальный человек может обладать максимум двумя качествами из трех. Соответственно, задача инженерного лидера — понять, каких качеств ему не хватает и кто может закрыть пробелы в этой тройке. Конечно, это лишь один из способов посмотреть на работу, но что-то в этом есть."

Очень хорошо.

Еще вот это тоже тронуло

"Ответственный человек, когда продукт получается плохим, понимает, что сработал плохо он. Чтобы в следующий раз сделать лучше, он разбирается в причинах, почему клиенты пишут отвратительные отзывы. А когда я ответственен лишь за кусок процесса, то, вроде как, и за продукт не отвечаю. Частичная ответственность рождает ощущение, что всем плевать."

среда, 27 мая 2015 г.

Про конструкторы сайтов или как я сайт решил сделать

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

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


среда, 20 мая 2015 г.

Мое интервью "О питоне, самообразовании и пользе конференций"

"А вы не любите TDD, как не люблю его я?"

Если вы хотели прочитать все аргументы против TDD в одном месте, то вот вам ссылка.

"TDD есть опиум для народа"

На данный момент, это самый аргументированный и подробный ответ апологетам TDD (из известных мне на русском языке).

Хотите узнать продолжение истории и проникнуться ответами другой стороны - подписывайтесь на дискуссию на страничке "Radio QA"

И как мне теперь с ним на работе общаться? Опасный человек оказывается :)

Да, кстати, подписывайтесь на блог Владимира, он классно пишет. Надо его мотивировать писать чаще :)


четверг, 14 мая 2015 г.

"Разрабатываем без нянек" (с) или как минимизировать участие тестировщиков в вашей работе

Первый наброс по мотивам сегодняшнего подкаста Radio QA. Читаем, набрасываем свои вопросы на вентилятор в 14.05 18.00 по Мск.
Запись подкаста.

Мы уже обсуждали вопрос "почему разработчики не пишут тесты"

И даже обсуждали, зачем нам тестировщики, если разработчики пишут тесты.

А если допустить фантастическое, что верхи и низы (или правые и левые?) хотят одного: работать правильно. И писать с тестами, и тестировать, а не проверять? То есть просто супер-пупер все, с чистого листа.
отсюда
С чего начинать?

среда, 13 мая 2015 г.

Сборная солянка видеодокладов для самообразования на разную тематику - Выпуск 5

Всем привет, готова очередная подборка видео.

Тема сегодня: роль тестирования и автоматизация (тестирования или в тестировании? :) )

Первым идет интересный рассказ Atlassian о том, какую роль у них играют QA.


Коротко в картинках





А вот баттл про тесты"Нужно - не нужно. Если да, то кто их пишет". Рекомендую досмотреть до конца и дождаться ответа на вопрос "сколько времени займет фикс, если у вас есть автотесты и без них". Я уверен, что фикс с тестами займет сильно меньше времени.




Ну и еще про автоматизацию. Доклад с новомодной темой "Automation in testing"
  
Есть еще одно интересное, но длинное видео про жизнь без тестировщиков с Codefest. Но я думаю к нему мы вернемся после первого выпуска live-подкаста Radio QA.

Приходите 14.05 (уже завтра!) в 18.00 по ссылке, слушайте и задавайте вопросы по теме "Разработка без нянек" - как доверить разработчикам тестирование продукта, чтобы потом не было мучительно больно ни продукту, ни разработчикам, ни тестированию.

среда, 6 мая 2015 г.

Sublime плагин для Fitnesse-PowerSlim

Один очень хороший человек написал плагинчик для sublime для тех, кому проще редактировать Fitnesse текст (тесты) с подсветкой синтаксиса.

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

Как это работает визуально:



Стало проще видеть макросы Fitnesse, переменные PowerShell и служебные слова slim-а

среда, 29 апреля 2015 г.

13 вопросов для выбора инструмента автоматизации тестирования (проверок?)

отсюда
Коллеги в настоящее время выбирают себе тестовый фреймворк, на базе которого хотят
разрабатывать автоматические тесты.

Кстати, сейчас Болтоном и Бахом активно продавливается тема, что это не автоматические тесты, а автоматические проверки (testing vs checking). Но это тема отдельного поста, холиварить будем там.

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

1. Я хочу посмотреть список тестов, какие проверки ими делаются и какая функциональность продукта проверяется. Можно ли это сделать с рабочего места, например Product Manager-а или меня как руководителя разработки, без установки дополнительного ПО?

2. Возможно ли написание одного теста в виде пользовательской истории из последовательных шагов (проверок) пользователя выполняемых на разных машинах.

3. У меня есть повторяющиеся действия, которые нужно делать в нескольких тестах – могу ли я сделать «библиотеку действий» и использовать ее при написании тестов.

4. Можно ли одни и те же тесты запускать с разными настройками, на разных окружениях?

5. Как посмотреть результаты тестов без установленного дополнительно ПО? Если ли возможность присылать их по почте? Если да, то откроется ли это в осязаемом виде и что будет, если это результат 100, 500, 1000 тестов.

6. Как хранится история запусков? Можно ли контролировать время выполнения тестов для профилирования и сравнивать время запуска с предыдущими.

7. Если тест красный – то как разбираться? Есть ли возможность привязки логов продукта к тестам, сборки нужных логов как артефактов.

8. Могу ли я запускать одни и те же тесты на разных машинах (например, на машинах разработчиков)?

9. Какая система хранения исходников тестов и формат настроек (если они есть). Есть ли возможность привязки тестов к исходниками продукта (чтобы было понимание того, какие тесты на каких исходниках работают).

10. Можно ли менять данные для тестов автоматически (снаружи). Например для проверки версии продукта – чтобы каждый раз руками не менять в тестах. То есть, возможно ли генерить/менять тесты (или данные для них) автоматически.

11. Можно ли в инструменте использовать компоненты продукты (исходный код, бинарники) для тестирования

12. Существует ли возможность интеграции в системы CI, если да, то какие и что можно получить.

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

PS Число 13 случайно получилось - просто выписал все из головы, а получилось 13. Можно конечно продолжить и действительно есть чем, но пусть будет так. Символично...

понедельник, 27 апреля 2015 г.

Сборная солянка видеодокладов для самообразования на разную тематику - Выпуск 4

В этот раз не совсем солянка, скорее сборник :)

В своем отчете о PiterPy#2 я упоминал, что познакомился там с Григорием Петровым.
Порыв интернеты, нашел несколько интересных видео его докладов.

Простые темы докладов не должны вас смущать, просто посмотрите.

Как называть переменные
Комментарии писались по другому видео с аналогичным докладом. Оно потерялось, но Гриша часто выступает, вот новый вариант. Возможно есть отличия - я не пересматривал.
Тема неожиданная, но содержимое очень порадовало. Для начинающих - смотреть обязательно, остальным рекомендуется.
Вот это очень понравилось: не нужно приводить существующий код в соответствие новым стандартам исходников.

Зачем выступать на конференциях
Кроме вопроса "зачем выступать", Гриша отвечает на вопросы как готовится, на что обратить внимание в презентации, а также зачем ходить на доклады :)

Есть еще доклады (в т.ч. про комментирование исходников и то, как их хранить)

Интервью Гриши на конференции PiterPy "Чем похожи программирование и алхимия?"

пятница, 17 апреля 2015 г.

Software-Engineering Myth Busters (покрытие кода тестами, TDD, организация и распределенные команды)

Наткнулся недавно на подборку интересных исследований проведенных Empirical Software Engineering and Measurement Research Group.

Товарищи на примере деятельности команд разработки Microsoft попытались получить хоть какие то цифры отражающие влияние различных инженерных практик и процессов, например TDD на качество получаемых продуктов.

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

Влияние покрытия кода тестами на качество
Покрытие кода рассчитывается как процент (отношение) строчек кода, которые вызываются при запускаемых тестах к их общему количеству.
Казалось бы логичным считать, что чем больше покрытие - тем лучше качество. Но результаты показали, что не все так просто (кто бы мог подумать).
Одна метрика не может характеризовать качество для любых продуктов. Процент покрытия кода сам по себе ничего не говорит, если не учитывать сложность кода и частоту его использования.
Если 99% кода протестировано, но оставшийся 1% кода постоянно используется, то от 99% толку мало. Также влияет сложность кода: сложный код сложнее тестировать, и добиваться высокого процента покрытия.
Итого: важно получить большое покрытие для сложного и часто используемого кода, чем "просто некий" процент покрытия.
Еще интересная статья про покрытие: How to Misuse Code Coverage
И еще про TDD и покрытие

Влияние TDD на качество
В исследовании рассматривались результаты команды практикующих TDD и не использующих эту практику, при этом подчиняющихся одному менеджеру (видимо, чтобы убрать наводку менеджерской активности на результаты). Эти команды разрабатывают Windows, Visual Studio и MSN (в самом исследовании есть еще результаты команд IBM).
Получились такие цифры: команды с TDD писали на 60-90% лучше, чем те которые игнорировали эту практику. Но, при этом время на разработку увеличивалось на 15-30%.
Рекомендую глянуть само исследование подробней. Там приведены исходные данные в виде размера команд разработки, их опыта, применяемых языков программирования и сроков разработки.
Итог получился в виде такой табличке

Использование проверок в коде (assertions) и как оно помогает
Еще одно интересное исследование. В качестве подопытных выступили две команды двух разных компонентов Visual Studio. Тут подробно расписывать не буду, дока не маленькая. Вывод закономерен: больше ассертов - меньше багов. Но интересно, что при внедрении этой практики настойчиво рекомендуется не вводить метрик в виде отношения количества ассертов к количеству строк. Разработчик должен "чувствовать" и осознавать необходимость использования таких проверок. Кстати, статический анализ тоже поможет.

Следующие два исследования анализировали влияние организационной структуры и распределенности команды на качество кода
Кроме влияния традиционных метрик кода (code churn, code complexity, code dependencies), хочется понимать, а как на итоговый результат может повлиять организационная структура команд(ы) разрабатывающей продукт. Это исследование описывает влияние всех этих метрик. Организационные метрики получились достаточно запутанными, и я в них пока не въехал :)

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

В общем, кому охота прогрузиться цифрами на выходных - вам сюда.

воскресенье, 12 апреля 2015 г.

Тестируем с помощью Fitnesse+PowerSlim. Часть 5. Пример

Часть 1. Введение 
Часть 2. База 
Часть 3. Advanced
Часть 4. Демо FitNesse + Jenkins
Часть 5. Пример трансформации PowerShell скрипта в тест
Плагин для sublime, который подсвечивает синтаксис теста на Fitnesse+PowerSlim

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

Итак, "мы прочитали твои посты, позапускали примеры, дальше то что? С чего начать?"

Давайте попробуем написать некое подобие теста для реальной (ну или почти реальной) ситуации. И, заодно, обратим внимание на один очень интересный момент, который облегчит написание тестов.

В Hyper-V PowerShell API есть такие cmdlet'ы: New-VM, Get-VM, Remove-VM. Давайте попробуем проверить, что мы можем ими пользоваться. Ситуация выглядит немного синтетической, но представьте, что есть продукт, который стоит внутри Hyper-V и расширяет модель авторизации этой платформы виртуализации. Такой продукт даже в природе существует  (vGate for Hyper-V) :)

Если опустить за рамки примера установку и настройку vGate, то хочется проверить, что пользователь может создать виртуальную машину и удалить ее.

Для этого можно использовать например такой PowerShell скрипт (проверки условны, но имеют право на жизнь):


New-VM -Name newVM -ComputerName 192.168.2.21 -MemoryStartupBytes 32MB -NoVHD
$vm = Get-VM -Name newVm -ComputerName 192.168.2.21 #получили созданную VM
$vm.State -eq "Off" #проверили что она выключена
Remove-VM -VM $vm -Force #удалили
$vmX = Get-VM -Name newVm -ComputerName 192.168.2.21 #опять пробуем получить
$vmX -eq $null #проверяем что не смогли

Собственно проверок (assert'ов) то здесь и нет, поэтому давайте их сделаем на FitNesse+powerslim.

Как видно, каждая строчка PowerShell скрипта превратилась в отдельную команду скрипта FitNesse. Так удобнее для удобства чтения и проверок, хотя никто не запрещает выносить несколько PowerShell команд в одну строку с разделением через ';' (а, например, при использовании PowerShell функций этот способ просто необходим)
Там где нужно просто выполнить PowerShell команду - мы используем eval, там где нужно проверить и сравнить, используем комбинацию check и eval.

Каждая строчка скрипта FitNesse отправляется на указанный в команде script powerslim-сервер, запущенный на удаленной машине (у нас 192.168.1.31), и там, с помощью команды Invoke-Expression выполняется. (Для тех кто любит поковыряться в кишочках: посмотрите скрипт splim.ps1, там используется Invoke-Expression alias: iex). 

Вот так вот мы получили первый тест, примитивный, но работающий.

Теперь про полезные хитрости (возможно, это не всегда очевидно). 
Результат возвращаемый в переменных PowerShell (в нашем случае $vm, $vmX) будет "жить" все время пока запущен powerslim-сервер, который выполнял команду. Другими словами, мы можем разделить выполнение команд eval и check в разные script'ы и все будет работать как и раньше. Более того, между этими командами можно выполнять команды на других powerslim-серверах, если нам это нужно по сценарию проверок (в пример ниже - 192.168.2.10):


Тут видно, что мы используем переменную $vm в другом вызове script на 192.168.1.31, так как знаем, что она там еще "живет".

Как правило, в наших тестах на одной тестовой странице идет работа минимум с тремя powerslim-серверами, что удобно и позволяет проверять достаточно сложные сценарии и обходить подводные камни.

А вот как выглядит результат выполнения этого скрипта в консоли powerslim сервера: 

Тут видны выполняемые команды, результат их выполнения и ошибки (красным). Например, в нашем случае, мы не смогли получить виртуальную машину после ее удаления (второй Get-VM) и PowerShell cmdlet вернул нам описание ошибки. Объект $vmX при этом равен $null.

Подобного рода вывод в консоль powerslim-сервера, при его редиректе в файл, помогает разбираться в возникших проблемах.

Обратите внимание! Время выполнения одного теста по умолчанию ограничено 10 сек. Для увеличения необходимо задать нужно значение свойству slim.timeout в файле plugins.properties лежащему рядом в запускаемым fitnesse-standalone.jar. Задается как slim.timeout = 100, где 100 новое значение тайм-аута в секундах).

Надеюсь, эта статья прояснила некоторые моменты и поможет вам в освоении FitNesse+PowerSlim.

Приведенный выше пример очень далек от "production"-тестов: например адреса серверов, имя виртуальной машины лучше задавать через макросы. Повторяющиеся действия, например Get-VM, выносить в сценарии. Но это уже другая история.

И помните, "Дорогу осилит идущий" (с) :)
Удачи!

вторник, 7 апреля 2015 г.

Прямо с моей головы писано: "The Rise and Fall of Unit Testing"

taw's blog: The Rise and Fall of Unit Testing

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

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

И про mock-и я тоже писал

четверг, 2 апреля 2015 г.

Сборная солянка видеодокладов для самообразования на разную тематику - Выпуск 3

Сегодня обзор совсем небольшой (по количеству видео), но интересный.

Видео всего два и начну с "Jira против PivotalTracker" (а то после анализа второго, до него не доберется никто). А оно интересное. Живо, динамично. Мне больше понравился Pivotal, наверно потому что я его использовал когда то. Защитник Pivotal'a креативен :)

интересно, это Андрей? (тут)
Дальше обнаружилось видео доклада Андрея Солнцева "Пацан накодил - пацан протестил".
Он выступал с ним у нас Питере, в соседнем здании бизнес-парка, но у меня не получилось туда сходить. Как оказалось - к сожалению.
Краткое резюме: Java-стам, особенно начинающим надо посмотреть. Вот сначала посмотреть, а потом говорить "такие простые вещи тестировать понятно, что можно, а вот у нас все сложнее, умнее, жирнее, глупее, или просто 'не так' (нужное подчеркнуть)". Вещи, о которых говорит Андрей, базовые и если вы их не понимаете или не знаете, как писать тесты для простых приложений, то до сложных точно не доберетесь.

Вернемся к докладу.
Доклад получился очень живой, с примерам, в т.ч. из реальных приложений (онлайн-банк одного из Питерских банков).
Сразу о том, что не понравилось: в первые несколько минут обилие неприятных слов из гоп-культуры. Да, я согласен с тем, что можно для остроты добавить пару оборотов, но акцентировать на этом внимание - излишне. В комментариях к видео есть аналогичное мнение и Андрей там попытался ответить на этот вопрос.

Идем дальше. (Осторожно, холивар!)
Почему то, TDD многие рассматривают только как юнит-тесты и ничто другое. Мне кажется чаще проще отталкиваться от итогового результата и попробовать посмотреть на тесты в том числе и уровнем выше.

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

Аналогично с примером Андрея (кстати, классная игра). Он пишет приложение в котором вся логика внутри одного класса. Понятно, что все приложение будет работать и базой данных, и логировать и тп "обвязкой", но логика приложения в одном классе. Мы тестируем всю логику приложения через один класс и опять, то что наши тесты юнит - это просто потому, что больше ничего у нас еще и нет (да и не будет).
В обычной жизни, чаще всего, вся "обвязка" уже есть и написать тест уровнем выше (выходя за рамки класса), используя подход "тест вперед" проще, чем мокировать все, что движется используется и писать классический юнит-тест. Ведь, согласитесь, в реальности, у нас все гораздо запутанней и сложнее, чем один класс. И я не согласен с тем, что такие тесты всегда долго работают и что это могут быть только UI-тесты. И приложение получается сразу можно попробовать в реале, а не на классах смотреть. Что то похожее на мои мысли тут.

Допускаю, что мой подход неканоничен. И вики выделяет Acceptance TDD от TDD. Но поверьте, он тоже работает и чаще проще понимается разработчиками. Если у вас проблемы с внедрением тестов - попробуйте.
Пожалуй закончу тут про юнит-тесты. Подумалось, что надо отдельную статью писать. Есть еще много мыслей отличающихся от канонов, а то этот пост совсем еретическим получится и до конца никто не дочитает :)

Вернемся к докладу.
  • Отсыл к Чаку Норису и охоте vs убийство - отлично :)
  • Тестировщики не нужны!? Обожаю эту тему :)
  • Узнал про Gradle. Андрей его использует для запуска тестов в разном порядке. Есть и C++ версия, надо посмотреть, что за зверь
  • Мутационное тестирование: меняем код - смотрим какие тесты отвалились. Отличный прием, мы им пользовались лет 6 назад (ужас, как давно уже).
  • 20 минут ответов-вопросов после почти 2-х часового доклада. Слушателям понравилось, думаю, если бы Андрею не надо было бежать на автобус, его бы еще долго не отпускали
Резюмируя (тут то, что срезонировало с моим понимаем проблемы и я под этим подписываюсь):
  • Тесты заставляют разработчика думать
  • Разработчики должны иметь возможность запускать тесты на своем компе
  • Тесты решают проблему 95% багов, остальные 5%  мы чиним быстро, если в них втыкаются.
  • Для хороших тестов надо уметь переключать mindset с "разработчик" на "тестировщик". Это разные типы мышления.

среда, 1 апреля 2015 г.

Изучаем Python с нуля

(c)
Иногда коллеги спрашивают. Решил все свои рекомендации в одно место сложить.

Ссылки для самообразования:
Еще немного ссылок на Python для детей

PS буду признателен, если посоветуете еще интересных ресурсов.


суббота, 21 марта 2015 г.

Отчет с конференции PiterPy#2

20 марта 2015 прошла 2-я ежегодная конференция PiterPy. Давненько я не был на чисто программерских конференциях. И напрасно - именно здесь заряжаешься энергетикой от большого количества увлеченных людей. На менеджерских или специализированных конференциях я такого не наблюдал.
Возможно еще сказывается достаточно камерный (пока?) формат PiterPy: 2 потока, 2 зала рядом, удобно, спокойно и без суеты.
Но коллега (Леха, привет), вернувшийся недавно с C++ Russia, отметил тот же эффект подзарядки от большого количества программеров в одном месте.
Поэтому, хочу сделать заявление: программеры (хочется верить большая их часть) очень позитивные и общительные люди, особенно когда это касается их любимой работы.

Твит-лента конфы.

Я волновался за свой текущий уровень знания Python, но, как оказалось, в голове еще что-то осталось и большинство докладов я спокойно переваривал. Правда был мега-deep доклад Александра Кошкина про кишки yield'а и тут мозг дал слабину :). Но почему то мне кажется, что я такой был не один - это действительно были кишки, мясо и расчлененка Питона в дизассемблере :) Кстати, доклад похоже один из лучших был.
Рейтинг докладов по версии афтерпати :) (с)
Заканчиваем прелюдию, ближе к теме. Здесь я уже набрасывал себе программу и получалось так, что почти все эти доклады и послушал.

Итоговую программу конференции можно найти здесь. Все видео тут.

По моему рейтингу получилось, что, по совокупности темы и мастерства докладчика, больше всего мне понравились доклады Кирилла Борисова и Алексея Пирогова. Уверен, что доклад Григория Петрова был супер, но я в это время увлеченно общался с Денисом Калановым и даже дал видеоинтервью ребятам из LoftBlog (теперь с ужасом его жду :) ) Теперь очень надеюсь на видеозапись доклада Гриши, потому что неофициальный рейтинг дал Грише призовое место. Ну а про доклад Саши Кошкина я уже сказал - это не для моего расслабленного менеджерского мозга :)

"Сверхоптимизация кода на Python"
Иван Ремизов
Доклад про то, как можно ускорить питоновский код в 30 раз. Очень рекомендую посмотреть тем, кого волнует тема. Еще раз прозвучало мое любимое "преждевременная оптимизация - зло". Оптимизацией они занимаются по факту обнаружения проблем. Часто мониторят логи продукта, чтобы держать руку на пульсе.
Видео доклада. Пара слайдов с советами и полезными ссылками:



(с)
"Beyond grep: Practical Logging and Metrics"
Hynek Schlawack
Интересный доклад про то, как можно собирать ошибки, логи и метрики. Ключевые слова и линки: Sentry + Raven, InfluxDB, StructLog, LogStash. Видео запись с конфы.


"Легковесный Dependency Injection"
Алексей Пирогов  разобрал на примерах существующие DI-контейнеры и рассказал о своей библиотеке yadic (yet another DI container). И тема была интересная и Алексей очень хорошо рассказывает. Приятно слушать. Слайды можно найти тут, видео тут. Если кому интересно, то у Алексея есть мастер-классы на его youtube-канале.

"Контроль за качеством кода"
Кирилл Борисов
Общепрограммерская история, было очень интересно. Видеозапись. Чувствовалось, что докладчик болеет темой :) Кирилл рассказал, как они в Яндекс-Паспорт работают с кодом: ревью, утилиты в IDE, утилиты в pre-commit хуках. Большая часть всего этого в нашем родном C++ встроена в компилятор, но есть интересные фишки по поиску FixMe, TODO, WTF :) (библиотека сейчас на апруве для выкладки в открытый доступ) или, например, сортировки import'ов

Дальше по расписанию был обед, за качество которого организаторам жирный плюсик.

Выбор следующего доклада предопределила такая характеристика докладчика

Я купился и не пожалел (хотя доклад Armin Ronacher "Developing an Open Source Library" надо обязательно посмотреть в записи).
Петр рассказывал про то как они в Wargaming разрабатывают тулу для конвертации одного дизайнерского формата в другой. Внутренности и проблемы взаимодействия Python и .Net (C#), проблемы и достоинства IronPython. Итого: WPF с IronPython дружит плохо (знаем - плавали), поэтому UI пишут на C#+WPF, а бизнес-логика на Python (потому что много Python-библиотек от UI-сред, в которых работают дизайнеры). Взаимодействие через stdin|stdout o_O. Вот так вот забавно. Но работает :) Видеозапись.


Про доклад Гриши Петрова я уже упоминал выше, будем смотреть запись. Хочу сказать пару слов об этом человеке. Я не был знаком с ним и его работой до этой конференции. Зря :) Очень умный и интересный собеседник. Хороший рассказчик. Получает удовольствие от того, что делится своими знаниями. Побольше бы таких людей. Рекомендую почитать его небольшой цикл статей про управление разработкой (открываем первую, дальше кликаем "Следующая статья" и получаем удовольствие).
это я после доклада Саши

"Знай и люби свой yield. Корутины и генераторы за гранью for loop."
Александр Кошкин
ААА..., ну вы поняли (см пояснения в самом начале). Это надо смотреть, объяснить я не смогу. Интересно много людей в зале врубилось в тему? :) Очень надеюсь, что такие были. Интервью Саши про yield после конференции.

"Анатомия автоматизации тестирования"
Алексей Тремаскин старательно отвечал на вопрос зачем городить свой велосипед, если вокруг и так много средств передвижения. Обожаю рассказы про новые конструкции велосипедов :) Алексей отвлек мое внимание упомянув Sikuli и и я налажал - увлекся этим вопросом и забыл спросить про Robot Framework. В итоге ребята действительно запилили свой велосипед и проверяют им UI в World of Warships.
Эхх, единственное, что может их оправдать это то, что по словам автора, он занимает около 150 строк. Если так, то может и не так страшно. Жаль не посмотреть - разработка внутренняя. Но способ использования yield для локализации ассерта интересен. Ждите слайдов и видео если кому интересны детали.

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

Вот вроде и все. Было интересно, здорово и позитивно. Познакомился с интересными людьми. Послушал умных людей, сам что то там рассказал. Спасибо организаторам за хорошую программу и организацию. Уверен, что PiterPy#3 будет круче. И он, кстати, уже готовится. Следите за новостями :)

Все слайды с конфы уже можно найти на ее странице.
"Как это было в лицах" - фотки с PiterPy#2
Отчет не про доклады, а про организацию конференции от Сергея Матвиенко

Короткий видеоотчет от ребят из LoftBlog

пятница, 13 марта 2015 г.

Размышлизмы про то, как часто пишется софт

Просто навеяло.
Вчера был в гостях на работе у своего товарища. Пересекся с ребятами, которые по заказу
компании друга (не IT-компания), делают им софт. Они в это время проверяли его на реальном железе (софт связан с радиосвязью).
По словам товарища, им часто приходится перепроверять и чинить то, что раньше работало.

Ребята-разработчики это с грустью подтвердили.

Спросил, есть ли у них автоматические тесты, хоть какие-нибудь. Порадовало то, что они про тесты знают, но дальше огорчение - они их не пишут. Про Continuous Integration тоже знают, но тоже не используют.

Знаете почему? Правильно - времени не хватает. А еще их начальник говорит, что тесты должны писать тестировщики. А тестировщиков у них тоже нет.

Занавес.

PS компания-разработчик, кстати, делает реально крутые ноу-хау вещи, но вот how это все делается, наводит на грустные мысли.
тут (с)

четверг, 5 марта 2015 г.

Сборная солянка видеодокладов для самообразования на разную тематику - Выпуск 2

Scott Meyers - Keynote @ Meeting C++ 2014

Интересный, общепознавательный доклад Скотта про то, как он писал свою знаменитую книгу (тут ссылка для жадных экономных), о том "что" важно говорить людям, когда вы их учите, и "как" это говорить.

Первая часть - это история про главу из книги, посвященную разнице между insert & emplace в STL-контейнерах. На этом примере Скотт показывает важность пунктов из своего списка:

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

Вторая часть (ссылка со сдвигом по времени) больше познавательная и тренирующая английский. Разговор идет о том, как доносить информацию правильно. Часть скорее для тех, кто выступает, или хочет выступать. Есть немного и про то, как важно использовать современные технологии при печати книг (например использовать многоцветную печать). Резюме: готовьте доклады и выступления так, чтобы их было удобно смотреть в записи на видео. Пишите так, чтобы было удобно использовать современные гаджеты.


Добавляем докладик про автоматическое тестирование, для остроты вкуса солянки.
Никита в свое время проехался по нему танком легким броневиком. Собственно с тех времен доклад видимо у меня в запасниках и пылился. Пришло и его время.
Помнится был у меня опыт построения тестов, подобных тем, что описывает докладчик. Вспоминаю с ужасом. Мокировали все, что "движется"... Но, возможно тогда мозг еще не был готов и опыта не хватало.
Доклад в первую очередь для разработчиков, потому что у тестировщиков возникают резонные вопросы про проблемы, возникающие в реальном окружении (см. комментарии Никиты). Но разработчикам действительно важнее проверить максимально возможное количество сценариев (пресловутое покрытие) за минимальное время. А это можно сделать только через unit-тесты. Это действительно можно завести, но будет ли это эффективно?
Есть сомнения. Особенно если ваши тестировщики придерживаются legacy-взглядов на тестирование и никакой автоматики у них нет.
Использование юнит-тестов для проверки как раз исключительных ситуаций (обработка ошибок, граничных условий и тп) действительно оправдано. Часто воспроизвести такое в реальном стенде сложно (или приближается к невозможному). Но жизненные и простые ситуации (success path) проще и правильнее проверять на пользовательских сценариях с использованием всего продукта.
Итоговое резюме: классический пример случая "гладко было на бумаге, позабыли про овраги".


Наличие следующего доклада в этой подборке может показаться странным. Но нужно добавить аромата к солянке. Я настойчиво рекомендую его посмотреть всем. Даже тем, кому еще только за 20.
Меня торкнуло.

среда, 4 марта 2015 г.

Как прошел 4-й IT Global Meetup, Питер


В этот раз сообществ было еще больше, людей тоже больше, программа насыщенней. Кстати, если вы до сих пор не в курсе, что это за мероприятие и зачем оно проводится, то есть интересная статья про IT Global Meetup.

По приблизительным прикидкам организаторов пришло около 700 человек! Тут можно посмотреть фото с мероприятия.

Я выступал на островке Питерского IT talk. Мне понравилось, надеюсь тем кто слушал - тоже.

Рассказывал про технический долг (слайды). Было похоже на доклад с BitByte2014, но немного переработал и добавил жизни. Получилось, судя по пока немногочисленным отзывам, живенько :)

Видео


Для тех кому проще послушать аудиозапись (например в машине) - "их есть у меня". Там бонусом еще и ответы на вопросы (+10 мин).

Потом был интересный доклад Жени Ефимова (см.отчет DataArt), про то как работа может нас сожрать.

А на закуску круглый стол с тестировщиками и аджалистами про вопросы тестирования в Agile-командах. Стенки на стенку не получилось, но было интересно.

В общем, очередное спасибо ребятам, которые это все организуют.

Про ретроспективы. Полезные ссылки

Доклад Бори Вольфсона "Эффективные ретроспективы" (видео, слайды)

Цикл статей Никиты Макарова "Ретроспективы в командах"

Презентация Макса Дорофеева "Правила хорошей ретроспективы или ключ к непрерывным улучшениям"

Хорошая статья про оценку ретроспектив Александра Селяева

среда, 25 февраля 2015 г.

Piter.Py - 2-я Python-конференция на Неве

Осталось чуть меньше месяца до второй конференции Piter.Py.

Пусть это будет черновиком к отчету о посещении и, заодно, моим планом визита туда.

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

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

Итак, пока получается так:

"Анатомия автоматизации тестирования"
Алексей Тремаскин планирует ответить на вопрос зачем городить свой велосипед, если вокруг и так много средств передвижения. Обожаю рассказы про новые конструкции велосипедов :) Особенно в условиях наличия Robot Framework.


"Beyond grep: Practical Logging and Metrics"
Hynek Schlawack
Помнится в свое время (лет 5 назад) мы активно использовали логирование для "разбора полетов" в продакшене у заказчика после работы нашего Python-продукта. Послушаем, что умного-нового расскажут.


"Легковесный Dependency Injection"
Алексей Пирогов.
Действительно интересно послушать что такого-этакого можно рассказать про DI и Python, известного своей легкостью встраивания зависимостей.


"Контроль за качеством кода"
Кирилл Борисов
Общепрограммерская тема, как менеджеру интересно.


"Developing an Open Source Library"
Armin Ronacher
Скорее для общего развития.


"Куда класть исходники"
Григорий Петров
Тоже общеразвивающее-общепрограммерское


"Знай и люби свой yield. Корутины и генераторы за гранью for loop."
Александр Кошкин
В С++ это недавно появилось. Послушаем как это работает в Python


"Быстродействие Python в Web. Постреляем по веб-серверу?"
Иван Цыганов
Холиварная вопрос производительности Python-приложений всегда всплывал, когда я рассказывал про наш проект 5 лет назад: "а почему не С++?" Надеюсь узнать, как теперь все меряется-проверяется.

вторник, 17 февраля 2015 г.

Сборная солянка видеодокладов для самообразования на разную тематику - Выпуск 1

Давно ничего не писал, а между тем, есть чем поделиться.
Начнем с того, что я посмотрел за прошедший месяц.

Доклады с конференции XP Days in Ukraine. Весь список видео тут.
Из того, что посмотрел и рекомендую:
На простых примерах показано, куда уходит время у тестировщика, если вместо тестирования он занимается проверками. И не факт, что это его вина.
Интересный доклад про характеристики зрелой команды. Просто и по пунктам. Можно распечатать и на стену.
Название говорит само за себя. Есть ряд моментов, по которым можно подискутировать, но Сергей достаточно убедителен.
Рекомендую посмотреть темы остальных докладов, уверен вы найдете еще что-нибудь для себя интересное.

Поехали дальше и уже не с XP Days.
В записи с вебинара PM-talk (это онлайн-мероприятие регулярно проводится Иваном Селиховкиным) Михаил Рыжиков рассказывает о

Кстати, первая часть вебинара тоже интересная.

Следующий доклад немного перетряхнул мое понимание legacy-продукта. Я понял, что оно было несколько упрощенным.
  • Кейноут "Legacy" by Chad Fowler с конференции GOTO. 
Основная мысль: продукт должен состоять из клеток-"ячеек", которые должны постоянно переписываться. Как клетки живого организма, которые отмирают давая место новым. Хорошо укладывается на популярную нынче тему "микросервисов". А вообще, legacy не значит плохой, это характеристика старого, но при этом нужного продукта. Но вот вносить изменения в него очень сложно.

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

Большой доклад по С++ из двух частей про то, как в Microsoft используют С++ для написания cross-платформенных версий Office.
  • ч.1 Больше история разработки MS Office и общие паттерны и правила, которые они используют для написания cross-platform кода.
  • ч.2 Скорее техническая, про проблемы cross С++ кода, с которыми они столкнулись и примеры взаимодействия С++ с Obj-C

Тема интересная, но докладчики обычные программисты. Мастерство презентации хворает, да и английский специфический :) Но внутренности полезные, особенно для расширения кругозора и понимания, что масштаб твоих текущих задач, мягко говоря, маааленький. А цифра  ~95% shared code между Windows RT и Android версиям внушает уважение.

Еще один кейноут, на этот раз с GTAC 2014
Еще более "крутой" английский в индусском варианте. Но внутренности действительно интересные. Докладчик из Google и занимается там тем, что он называет Test Engineering. Есть интересные цифры и инсайты. Да, Никита, у них действительно есть "моргающие" тесты :) (flaky tests).
В общем, если не посмотреть, то полистать точно нужно. Для успокоения, в том числе, а то меня очень раздражают, наши моргания в сюитах :)



понедельник, 16 февраля 2015 г.

Питер, 4-й IT Global Meetup


27 февраля очередная встреча IT-сообществ С-Петербурга. Многие сообщества уже выложили программу своих островков. Многие островки подготовили совместные обсуждения. Кроме того, к нам планируют приехать участники из других городов.

Регистрируйтесь, приходите. общайтесь, учитесь. Становитесь лучше :)

Программа и отчет с прошлого мероприятия для ознакомления.

В этот раз я тоже решил с вами пообщаться. С моего последнего выступления на тему технического долга, у меня появились новые мысли на этот счет. Готов ими поделиться и с удовольствием познакомлюсь с вашей точкой зрения. Никаких слайдов - только флипчарт и диалог.

Текущий (на 16.02) вариант программы сообществ:

SMART management
19:00 "Техники для селф-коучинга." Светлана Мухина Luxoft (Киев)
20:00 "Как быть ответственным за N проектов и не сойти с ума?"  Захар Кириллов КБ Собака Павлова
21:00 "Impact Mapping на практике."  Александр Бындю ByndyuSoft
22:00 "Взаимоотношения с заказчиком. Ожидание и реальность."  Денис Мишарин Проектный центр ГиДИС


Agile Piter
19:00 "Применение инструментов критической цепи (TOC) и Agile для планирования проекта"  Алексей Васильев SigmaLab
20:00 "Бизнес и системный анализ в гибкой разработке. (Круглый стол на островке аналитиков)"  Рыжиков Михаил WaveAccess
21:00 "User Story Maping и Paper Prototyping, как возможность лучше понять своих пользователей."  Семён Петков Luxoft
22:00 "Тестирование в гибкой разрабокте. Круглый стол с сообществом SQA." Александр Атцик DINS


IT talk
19:00 "Frontend. Keep yourself up to date."  Александр Суевалов DataArt
20:00 "Импотека или как перестать залезать в долги."  Максим Шульга Код Безопасности
21:00 "Sick Systems. Как работа уничтожает нас."  Евгений Ефимов DataArt
22:00 "Как упорядочить свои задачи и при этом не перегореть."  Кирилл Тимофеев DataArt


SPb Community of Analysts
19:00 "Повышение конверсии продукта: дизайн, метрики, сплит-тестирование. На примере Okko Фильмы HD."  Алексей Шемис и Виталий Григораш АНТ-информ / Okko
20:00 "Круглый стол. Бизнес и системный анализ в гибкой разработке." Михаил Рыжиков WaveAccess
21:00 "От проблемы к требованиям.Теория принятия решений в разработке ПО." Александр Гусенко Netrika
22:00 "Формирование требований в виде вариантов использования."  Евгения Чумачкова DINS


IT HR
19:00 "Постановка целей 4D" Ирина Матвеева
20:00 "Постановка целей 4D" Ирина Матвеева
21:00 "Performance Based Hiring. Как перестать мучаться с HR и начать с ним работать." Александр Зверев
22:00 "Система внутреннего обучения в IT - компании" Евгения Миклуш


DevOps-40 SPb Linux User Group
19:00 "Запуск Skype в Docker." Станислав Богатырёв
20:00 "Построение отказоустойчивых кластеров на базе Ceph." Павел Семенец
21:00 "Круглый стол на тему отказоустойчивых кластеров, обсуждение." Александр Чистяков и Павел Семенец
22:00 "Мониторинг наркомана (Riemann)." Станислав Богатырёв

Книги издательства "Манн, Иванов, Фербер" уже ждут активных участников слета