SEC(R) 2009: Отчет Филиппова Виталия

Ссылки сюда (1) →

Культурный центр ГУ-ВШЭ (SU-HSE, хе-хе), три зала — A большой, B хороший, C аскетичный, но удобный. В A лампы засвечивали экран, и было два варианта — либо люди не видят доклад, либо докладчик не видит людей — если свет выключить, форменная кинозальная темнота. В B у меня было любимое место слева аудитории на полу у стеночки, он чистый, тёплый, мохнатый и удобный. Вайфай кстати постоянно отваливался, хотя некоторым, типа Миши Заборова, везло и они его юзали). Видеозаписи докладов, не говоря уже об онлайн-трансляции, насколько я понял, не было, а жаль =(

Программа менялась, аки рельеф при землетрясении. Такое впечатление, что каждый следующий день была новая программа. Когда раздавали её на бумажках, раздавали несколько разных вариантов — неправильную на русском, правильную на английском, во второй день также правильную и на русском. И всё равно кое-что отменялось. Может оно и к лучшему — никаких «Шахидов» не было (сначала предполагалось, что будет какой-то перец из Shahid Beheshti University).

Конференция менее «техническая», чем всякие хайлоады, доклады на совершенно отбалдовые тематики, но в этом и плюс: потому и аудитория менее унылая — например, количество девушек на конференции не равнялось O(0). Как писал про какой-то хайлоад Стас, если O(0) — аудитория выглядит просто как корабль уродов, а так — ну да, творческие личности, ага.

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

Была парочка ископаемых (динозавров) (дедушки такие) — один из ВЦ Мингорисполкома, и другой тот самый, который устраивал митинг про «программирование на естественных языках», а на самом деле по сути про семантик веб, а точнее RDF (тройки субьект-отношение-объект) и то что это типа естественная форма представления информации и всё из неё можно вывести.

Фотки кстати выложу, да.

Анкеты

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

• Каков размер IT-бюджета вашей компании? (А сколько бы с вас срубить бабла?)
• Интересно ли вам узнать об Intel Parallel Studio побольше? (А хотите спама об IPS?)
• Интересно ли вам узнать о других продуктах Intel побольше? (А хотите спама от Intel вообще?)
• Какие технологии вы используете для построения Rich Internet Application? (Конечно, намёк на Flash/Flex и его конкурентов)

Я ответил так:

• IT-бюджета нет! — был такой вариант. любопытно, почему не было «не знаю»
• В пень! («нет»)
• В пень! («нет»)
• Какие технологии?! Свободные!

Были также вопросы про количество разработчиков в целом и про количество .NET-чиков; мы всё равно плотно сидим на игле, так что на эти я ответил честно.

День первый

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

Владимир Ицыксон, Михаил Моисеев, СПбГПУ. Автоматическое обнаружение дефектов в промышленных программных системах на языках С/С++

Рассказали про свой инструмент — очередной статический анализатор программ C/C++. Написанный, кстати, на Java :-) их спросили — а вы свой код пробовали анализировать? Они: Ы! А это невозможно. Он на жабе, а мы жабу не умеем, хотя и видим в ближайших планах на будущее. Инструмент сравнивали и с другими системами, и получалось лучше — хотя увы, не сравнили с … забыл название … короче, системой, считающейся самой мега-крутой, но увы — она стоит в районе 150000$ за лицензию.

Сравнивали на OpenSource проектах — Постгресе, Мазиле и т. п. Сравнивали, правда, тоже забавно: количество найденных дефектов :-) то есть, без учёта качества найденных дефектов — может, там мусор один? Дефектов, конечно, тысячи, и все проверить тяжело, но проверили бы хотя бы пару небольших случайных выборок. В общем они, наверное, верят в свою систему и её отлаживали, поэтому и считают, что скорее всего всё ОК.

Сама система производит впечатление, что находится вполне на уровне. Товарищ тоже неплохо разбирался в том, что говорил. Потом на докладе о «ранней обработке ошибок» вопрос «а какие у вас алгоритмы, какой мат.аппарат?» задал именно он.

Андрей Карпов, ООО «Системы программной верификации». Ранняя диагностика ошибок в параллельных программах (отстой)

Чувак пытался рекламировать свой продукт — VivaMP. Сделали статический анализатор, который чего-то там анализирует. В основном тупые семантические ошибки, а не ошибки параллельных алгоритмов. Вопрос из зала — А какие у вас алгоритмы используются, какой математический аппарат? — Ответ был в том духе, что нууу, чё-то там налабали, ну проверки какие-то, короче у нас его нет.

Станислав Фомин, Заказные ИнформСистемы. Управление тестами с Testopia — недостающее звено? (был отжиг)

Великий и неподражаемый =))) Стааааас Фомиииииин! Идея доклада, если кто-то не знает, в том, что системы управления тестами все жирные и пытаются лезть туда куда не надо. Их надо кастрировать и оставить только то, что надо (статусы и прогоны). Доклад рассказывался у нас внутри 20 октября 2009, видео есть в \\st-fomin\VIDEO\2009-10-20-testopia\, также, видимо, будет выложено в Корпоративный блог.

Примечание: сама Testopia, имхо, не совсем идеальна, а точнее, совсем не идеальна. Выкинуть бы из неё весь этот несчастный AJAX и заточить на пару простых юз-кейсов…

Конечно есть traceability, от бага можно перейти к коммиту, и т. д. и т. п. А вообще — traceability, traceability! Достали вы уже своим traceability!!! Не так он и важен, минимального — достаточно!

Андрей Бибичев, Заказные ИнформСистемы. Проектирование больших информационных систем в Agile

К сожалению сбежал с середины, так как дальше надо было выступать, так что видел не всё — запомнил мало, в основном буквы *DD… Хорошо запомнил что было в бодреньком ритме (82 слайда, вполне информационных) и как всегда по делу — Андрей всегда по делу рассказывает =)

Виталий Филиппов, Заказные ИнформСистемы. Одежка для Subversion: ViewVC и SVN-Searcher (я)

Рассказывал я про lib:ViewVC и lib:SVNSearcher, которые у нас развёрнуты. Типа, с их помощью хорошо дополняется функционал SVN’а. Тема не бог весть какая, но я постарался её рассказать получше, по крайней мере не уныло =) записал видеопрезентацию следующим образом — показывал презентацию на мониторе и записывал его на фотоаппарат, показывая рукой на экране что-нибудь. Получился «театр теней» (рука — тень такая большая страшная). ИМХО — забавно.

А теперь зафиксирую немножко самокритики =) что надо было сделать:

• Клон-режим запускать из-под Linux’а — хоть и нужно сначала понять, как это делать, по крайней мере будешь знать, что после этих команд он точно заработает, а не как под виндой — ТРИЖДЫ проверил, подключение проектора она опознавала. Когда надо — снова эффект демонстрации и ничего не заработало, в итоге я снова рассказывал в режиме расширения, а чтобы попадать в видео — смотрел на экран, стоя вполоборота к залу — это не очень хорошо :(
• Скринкасты вставить не в середину, а в конец, ибо они означают всё-таки переключение контекста и занимают в общем-то тупёжкой время, которое в конце можно было бы параллельно употребить на вопросы.
• Что было со временем, я что-то тоже не понял — у меня было видео 24:41 и потом я к нему добавил ещё где-то минуту — выложу, посмотрю точно. Но получилось так, что ещё не до конца уже осталось 3 минуты, в итоге вопросы были, но в коридоре.
• Рассказывать, возможно, получше — мне самому оценить тяжело, но возможно немного быстровато? Короче, совершенствовать ораторские качества. =)

Вадим Савкин, Лаборатория Касперского. Формальные инспекции на практике

А чем отличаются ваши инспекции от Code Review? Ну типа Code Review — это неформальная такая процедура, а с инспекциями не схалявишь, потому что потом всё равно считаются метрики и агааа! Как же ты это не нашёл дефектов! Ты не смотрел!

Инспекторов должно быть не меньше двух, это обычные разработчики — так же как и при ревью, это может быть ктопопало, заодно и научится. У инспекторов, типа, приоритет — если ему что-то надо, нужно всё бросить и показать, ибо иначе он будет простаивать.

Показал, что в среднем чем дольше проверяешь, тем больше находишь. Логично.

По сути — это всё.

Алексей Иешин, F-Secure. Автоматизация Тестирования: Гибкий Подход (мегаотвратительный отстой)

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

Чувак уныло рассказывал про «псевдо»-команду — летучий голландец, летающий по фирме и оплодотворяющий другие команды автоматизированием тестов, сначала силами этой команды, а потом отдавая автоматизированную систему целевой команде. Рассказывал под англоязычные слайдоменты мелким серым шрифтом, в стиле «три герлицы под виндом пряли поздним ивнингом» — 3 слова русских, 1 английское, причём не термины какие-то специальные, а обычные довольно слова, звучащие дико в русском контексте по-английски.

Матвей Брагинский, ВЦ Мингорисполком. Об управлении разработками в наших краях

Вот он, последний динозавр! Как так, говорит, получалось, что в 70-80х годах мы писали ПРАВИЛЬНО без всяких Agile, SCRUM и т. д.?! А вот так, говорит, мы мол просто были профессионалы и хотели, и следовали корпоративным стандартам — внедряйте у себя стандарты на всё! На отступы, названия классов, файлов, переменных и вообще на всё, и заставляйте всех им следовать терморектальными методами. То есть ГОСТ, улучшенный и дополненный (Стас: никак оно не сдохнет! нафига его дополнять!) И будет всё хорошо, по крайней мере не плохо.

Стас: Я вообще хотел немного выступить — сказать пару фраз… минут на 10… Но всё-таки как-то решил, что бесполезно. Да и нехорошо дедушку пинать.

Вопрос из зала от какого-то другого чувака тоже из Минска (дословно не помню, но смысл): а что вы сделали-то, вообще?.. — В ЗАГСе были?! Ну вот, автоматизация ЗАГСов. (и ещё что-то)

В этом сокрыто обращение к залу — эээ чуваки… посмотрите… мы там не все такие, мы нормальные…

Сергей Рубцов, Technische Universiteit Eindhoven. Применения Dn метода для анализа коммерческих Java приложений

Некая формула D_n, точно не помню (наверняка Олег Клинчаев напишет), но включает в себя «абстрактность» и «изменяемость». Взяли сколько-то там ведущих opensource проектов и посчитали по ним, посчитали среднее, решили, что это хорошее значение показателя, и всем советуют делать, чтобы и у вас D_n был такой же. Мысль некая в этом безусловно присутствует, конечно.

День второй

Антон Хританков, Auriga Inc. Метод оценки прибыльности проекта на основе стохастической модели рисков при разработке ТКП

Был чуть-чуть в конце. Условно говоря — мат.статистики пришли в проектирование =) прогнозируют прибыльность проекта на основе статистики.

Владимир Рубанов, ИСП РАН. Система анализа обратной бинарной cовместимости библиотек Linux

Симпатично! Оказывается, LSB и abi-compliance-checker лабает ИСП!

Товарищ кратко рассказал про изменения, могущие повлечь за собой бинарную несовместимость разделяемых библиотек (обычных — C/C++). Условно говоря — изменения сигнатур функций, изменения виртуальной таблицы класса, изменения структур, изменения свойства статичности метода класса, изменения констант. Всё это в той или иной степени накрывает обратную бинарную совместимость. Пара примеров — libstdc++ и FreeType. Первые (скорее случайно, чем специально) поменяли в какой-то версии порядок методов в классе. Им довольно быстро в вежливо-матерных выражениях разъяснили, что так делать не нужно… Они долго-долго извинялись, потом вроде пофиксили. Вторые (скорее специально, чем случайно) решили оптимизировать структуру какой-то структуры. Дооптимизировались и сломали почти на пустом месте бинарную совместимость. Но — поняли и пофиксили быстро.

Инструменты для борьбы с этим безобразием. Во-первых, версионирование библиотек (soname главным образом) — чтобы было не просто libstdc++.so, а libstdc++.so.6.0.10, на который ссылается симлинк libstdc++.so.6, и на него libstdc++.so, а номер версии «6.0.10» сохраняется и в самом файле. Таким образом при загрузке проверяется версия, и если она не совпадает, значит, что-то с бинарной совместимостью, скорее всего, не то. Во-вторых, [[1]], который все эти фишечки проверяет. Конечно же, он не может проверить семантику работы библиотеки (хотя и такой проект у них есть), но бинарную совместимость проверяет (это ответ на вопрос из зала). Некоторые проекты уже включили его в свой цикл разработки. В-третьих, LSB для бинарной совместимости между разными дистрибутивами Linux.

Да… теперь Linux-вирусы, если хотят быть переносимыми, должны будут соблюдать LSB… Но что-то всё равно пока не получается :-)

Юлия Нечаева, NIX Solutions. Ловушки заказного тестирования

Пхехе. Три ловушки: жадность, лень и тупость. И от жадности ква-ква, и от глупости. И ещё от хвастовства, ква-ква-ква, ква-ква-ква, не поможет твой товар… Злой прааативный Дуремаааар!

Все три ловушки — отношение клиента к тестерам-аутсорсерам :-) красной нитью сквозь всю презентацию проходила фраза «Заказчик не понимает. И когда подписывал — тоже не понимал». Олег Клинчаев: а может заказчик просто тупой?! :-) И таки действительно, последней проблемой была именно тупость.

По каждой есть рекомендации, как для тестеров, так и для заказчика.

Жадность: «давайте мы вам на тестирование выделим специального узкого специалиста, он лучше сделает» — «да вы просто жадные и денег хотите больше»! А надо объяснять, что на самом деле мы можем сделать и так, и так, но при этом у вас будут такие-то и такие-то риски, такое-то и такое-то качество. Доказывать, что специалист — действительно специалист, а не хрен с горы, очень желательно не увещеванием и даже не регалиями (бумажками-сертификатами и т. п.), а портфолио — примерами реальных проектов, которые он делал и сделал — бизнесы это лучше понимают.

Лень: «дайте мне документацию» — «стоп! мы об этом не договаривались» — «да вы просто ленивые! мне даже не документация нужна, а детализация чего вы делали — за что я платил»?! Рекомендация: отчёты и описания тест-кейсов надо писать всегда, даже если это не оговаривалось. Это не так дорого, чтобы этого не делать, а потом напороться на «непонимание» заказчика, которому перед кем-нибудь свыше, скорее всего, нужно ещё и отчитаться. Также нужно делать работу тестировщиков прозрачнее.

Тупость: «да вы тупые мышекликеры, куда вам столько денег»! А надо объяснять, что на самом деле не всё так просто, и что и деньги вы платите нам не зря, и качество мы действительно обеспечиваем. Делать работу прозрачнее.

Игорь Одинцов, Intel. Опыт применения методов ТРИЗ для повышения эффективности разработки ПО

Скорее отчёт, чем доклад — было такое и ещё на нескольких докладах, типа вот мы статью написали и смотрите всё там, а здесь мы просто скажем что это есть.

ТРИЗ — Теория Решения Изобретательских Задач. Она рассчитана на реальный мир, а не на нематериальный код, но эти чуваки решили её приспособить и, типа, приспособили. Рассказа о том, КАК — в принципе почти не было. Зато они ведут семинар по этой теме и привели данные опроса участников ДО и ПОСЛЕ проведения семинара — как вы считаете, ТРИЗ можно использовать в разработке? (да/частично/нет). «Нет» не отвечал никто, но надо отметить забавный факт — после проведения семинара оптимизма у участников поубавилось процентов на 7 народу — раньше они говорили «да», а после семинара стали «частично».

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

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

До прослушивания доклада была такая мысль: «блин, вот вам делать там нечего — лучше бы качество поднимали; ну давай, послушаем лентяев»! После прослушивания доклада была такая мысль (и не у меня одного): «вроде как ВАЗовцев не послушаешь — рассказывают вменяемые вещи, а почему ж на выходе-то такое г…?»

В целом товарищи молодцы, раньше (лет 10 назад) у них был зоопарк виндов, дельфей (Delphi), FoxPro, Oracle, много разных серверов и т. п. Всё это на 14000 рабочих мест. Теперь у них Itanium-сервера (это, конечно, не молодцы, что и сами понимают), Oracle остался, то, что можно было (хотя такого мало), перенесли на Postgres, винду ликвидировали калёной метлой, сэкономили 14000 лицензий, поставили везде бездисковые компы (замечательная фраза — «а зачем нам в цехе, где мастер регистрирует приход детали, полноприводный персональный компьютер?»), грузится всё это с флешек с Linux Castrated Edition (ну в смысле урезанным каким-то), Mozilla Firefox в качестве тонкого клиента и LA…P (Linux, Apache, …, PHP — вместо … обычно MySQL, но у них Oracle) на серверах.

В качестве приложения — стандартный PHP-быдлокод, похожий, как написал Миша Заборов (сам ты «линакс», кстати =)))), на наш CustisWeb. Пхехе. Приложений не одно и не два, а много, например, есть некий а-ля плантайм — тоже самописная база сотрудников. На последнем слайде с контактами был как раз скриншот оттуда.

Всё это постепенно развивалось, туда же подключили дилеров и т. п. Ещё рассказывал про жесть, которая была — одно время были одни серые дилеры, которые покупали на заводе за дёшево, а продавали рядом же за дорого. Из 600 серых дилеров в системе зарегистрировалось 7… (я так понял)

Их ещё спросили, а чего же вы от Оракла-то не отказались, он же стоит зараза нереальных денег — сложилось исторически, перетаскивать тяжело, хотя возможно в будущем сделают и это.

• Кстати-1: В качестве системы контроля версий они используют CVS.
• Кстати-2: поддержкой всего-всего-всего этого занимается примерно 300 человек.
• Цитата: 40 лет назад мы выпускали 2700 автомобилей в день. Сейчас всё то же самое, только этот процесс теперь обслуживает 14 тыс. АРМов…

Станислав Фомин, Заказные ИнформСистемы. Собор или базар: системы контроля версий — централизованные или распределенные?

Продолжение «говорит и показывает StasTV ™». Сначала показал первую серию Дилберта (1x01) и пару роликов CodeSwarm. Снова конечно же замечательный доклад, рассказ про DVCS (Git http://git-scm.com/, Mercurial, Bazaar) vs CVCS (SVN — венец эволюции). Про SVK ничего не сказал, а кто-то хотел бы узнать — вопрос задали из зала. Материалы, наверное, будут на http://team.custis.ru/, но какие — я не знаю, видео-то нет.

Стас, кстати, считает, что лучше всех Bazaar. Но по популярности Git’у он проигрывает очень сильно (раз в 10). Это данные из опроса с Хабра, на котором Стас, кстати, хорошо прокачал себе карму :-))

Данные вот такие:

Система	Голоса	Процент
CVS	238	8.21 %	Шаблон:Localimage:habravote .gif" width="88" height="10" />
Subversion (SVN)	1744	60.14 %	Шаблон:Localimage:habravote winner.gif" width="644" height="10" />
Другая бесплатная централизованная VCS	11	0.38 %	Шаблон:Localimage:habravote .gif" width="4" height="10" />
Коммерческая централизованная VCS	105	3.62 %	Шаблон:Localimage:habravote .gif" width="39" height="10" />
GIT	459	15.83 %	Шаблон:Localimage:habravote .gif" width="169" height="10" />
Mercurial (Hg)	197	6.79 %	Шаблон:Localimage:habravote .gif" width="73" height="10" />
Bazaar (bzr)	48	1.66 %	Шаблон:Localimage:habravote .gif" width="18" height="10" />
Другая бесплатная распределенная VCS	8	0.28 %	Шаблон:Localimage:habravote .gif" width="3" height="10" />
Коммерческая распределенная VCS	23	0.79 %	Шаблон:Localimage:habravote .gif" width="8" height="10" />
Другое	67	2.31 %	Шаблон:Localimage:habravote .gif" width="25" height="10" />
Всего голосовало	2167

Александр Хрущев, Instream. Эффективность использования автоматических тестов в ИТ-проектах

В общем доклад мало о чём, хотя и не сказать, чтобы совсем ни о чём. Сказал, что начале вы затратите времени на автоматизацию тестирования сильно больше, чем на ручное — окупаться автотесты начнут релиза где-то с третьего. Графики нарисовал (явно отбалдовые). Ну, за исключением нагрузочного тестирования и иногда — модульного. Ничего не упомянул про Continuous Integration (а это ведь тоже выигрыш). Сказал, что раз затраты — давайте попробуем их разделить с заказчиком, хотя это и не получится в 99 % случаев. Сказал, что никогда не надо выдавать результаты автотестов за результаты ручного тестирования — заказчик может это понять и обидеться (и правда, с чего бы вдруг?).

Вячеслав Васильев, Красный угол. Технология Microsoft.NET Micro Framework для построения беспроводных систем сбора медицинской информации

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

Алексей Лянгузов, Sun Microsystems. Контекстное Тестирование ПО: Практические Рекомендации (ни-а-чём)

Вот уже этот доклад действительно ни о чём — совсем ни о чём. Я, говорит, лет 9 уже работаю в тестировании, и когда полгода назад услышал про школу «Контекстного» тестирования и почитал про неё — понял, что это всегда и делал, ничего об этом не зная. О, оказывается, вот оно как называется — дай-ка расскажу. НО!!! Ни одной практической рекомендации доклад не содержал. Такое «Контекстное» (типа «контекст важен!» — жизнь это вообще контекст, кто же спорит) можно придумать всё что угодно — разработку, забивание гвоздей. Оказавшийся под гвоздём палец — обычно неудачный контекст. Хотя, если этот палец чей-то, а не свой, и из этого человека надо выбить какие-то сведения — как раз наоборот…

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

Очень хорошо суть доклада иллюстрирует последний слайд, на котором написан «алгоритм решения проблем»:

• определить проблему
• оценить ситуацию
• найти решение
• воплотить решение в жизнь

Бу-га-га!!! Гениальное открытие!!! «Первый шаг: воруем трусы…» (c)

Александр Орлов, Happy-PM. Профессиональный тестировщик

Доклад без слайдов. Чувак рассказывал про то, что по его мнению, из тестировщиков получаются хорошие менеджеры, ибо тестировщик занимается всем, вынужден отбиваться от всех, и организовывать весь процесс. В реальности, по-видимому, его просто лично так хорошо пропёрло попасть в Sun тестером на зарплату в 2.5 раза большую, чем у него была тогда разработчиком. Потом стал начальником тестеров, потом менеджером, а потом ему надоело и он стал организовывать тренинги.

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

У Дэйла был талант что-нибудь ломать. Он ломал всегда, все и где угодно. Ломал карандаши, когда учился в школе, ломал ц&!-@ всем девчонкам района когда стал постарше, ломал заборы и фонарные столбы, лифты и перила в подъездах…Когда Дэйл занялся изучением премудростей программирования, то тут ему открылись такие широкие возможности для ломания, что он даже оставил попытки сломать сам компьютер.

Возможное мнение: ну да, наверное. А возможно подход нашей компании вменяемее — ЧистоТестеров нет, есть Аналитеги. Из которых — а кто спорит — действительно может получиться более вменяемый менеджер… Ну а кроме того, это всегда так :) а понимаем только мы! :)