К основному контенту

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


Через 15 дней в Питере запланировано проведение интересного мероприятия: IT Global Meetup. Update: как все прошло.

Что это такое и для чего?

Говоря официальным языком:

"IT Global Meetup — это уникальное событие для опытных профессионалов и начинающих ИТ-специалистов, на котором собираются вместе участники ИТ-сообществ Санкт-Петербурга, знакомятся друг с другом, обмениваются знаниями и опытом.

IT Global Meetup проводится в рамках некоммерческой инициативы Piter United, целью которой является формирование благоприятной экосистемы для развития ИТ-сообществ Санкт-Петербурга."

А что будет на самом деле?

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

Ну и, собственно, это не конференция вовсе. Это возможность встретиться, познакомиться, пообщаться о наболевшем, научится. И все это в неформальной обстановке.

Будут программеры, тестировщики, UX-спецы, аналитики, технические писатели. Ну и куда уж без менеджеров :)

Предварительные программы сообществ (считай inside)

Тестировщики
"Основание отдела тестирования" Екатерина Гайнутдинова, Trans-IT
"Правила написания хороших тест-кейсов" Наташа Узенцова, Total Objects
"Как дружить с разработчиками" Юля Атлыгина, ALM Works
"VIQA - тестирование UI с помощью VI" Роман Иовлев

UX-спецы
"Техническое и дизайн-мышление: почувствуйте разницу", Захар Кириллов, Ольга Павлова, КБ "Собака Павлова"
"UX-тестирование в Яндексе", Ксения Артеменко, Яндекс
"Карты эмпатии", Никита Ефимов, IT Mine

Писатели
"Word: великий и ужасный", Алексей Агибалов, Рамакс Интернейшнл
"Промышленная разработка в DITA на основе единого источника"
"Инструменты создания Help"
"ГОСТ, ISO - пишем по стадартам"

Lisp
"Костыли и грабли. Метапрограммирование в мейнстримных языках(и лиспе)", Дмитрий Игнатьев, Artec
"Литературное программирование и Common Lisp", Михаил Глухов

IT Talk
"Нелёгкий путь культуры свободного кода", Кирилл Тимофеев, DataArt
"Ошибки молодого PM. 10 вещей, которые я сделал не так, получив свой первый проект", Евгений Ефимов, DataArt
"Sick Systems. Как работа уничтожает нас", Евгений Ефимов, DataArt

Agile Piter
"Предания старины глубокой или когда жесткие планы и нормы - это хорошо", Сергей Котлов, Happy Melly

Аналитики
"Неочевидные аспекты работы с user stories в agile", Дмитрий Петрашев, Dell
"Анализ документа: эвристический и с помощью разметки", Абрамова Анна, мастер-класс

Менеджеры
"Использование мотивационных факторов в работе с командой на основе работ С.Рисса", Евгений Крапивко, EPAM Systems
"Почему легко построить продажи в IT", Владимир Лапардин, А25
"Как выбирать проектные методологии и как от них отказываться" (кейсы, обсуждение), Иван Селиховкин, НИПК "Электрон"


Мероприятие бесплатное.

Регистрация обязательна и доступна на сайте проекта.

Присоединяйтесь.

Если есть желание помочь с организацией - you're welcome. Благодаря издательству "Манн, Иванов и Фербер" у нас есть полезные подарки волонтерам.


Комментарии

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu