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

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

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

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

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

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

Содержание

Анкеты

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

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

Были также вопросы про количество разработчиков в целом и про количество .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’а. Тема не бог весть какая, но я постарался её рассказать получше, по крайней мере не уныло =) записал видеопрезентацию следующим образом — показывал презентацию на мониторе и записывал его на фотоаппарат, показывая рукой на экране что-нибудь. Получился «театр теней» (рука — тень такая большая страшная). ИМХО — забавно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

День второй

Антон Хританков, 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… (я так понял)

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

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

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

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

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

СистемаГолосаПроцент 
CVS2388.21 %Шаблон:Localimage:habravote .gif" width="88" height="10" />
Subversion (SVN)174460.14 %Шаблон:Localimage:habravote winner.gif" width="644" height="10" />
Другая бесплатная централизованная VCS110.38 %Шаблон:Localimage:habravote .gif" width="4" height="10" />
Коммерческая централизованная VCS1053.62 %Шаблон:Localimage:habravote .gif" width="39" height="10" />
GIT45915.83 %Шаблон:Localimage:habravote .gif" width="169" height="10" />
Mercurial (Hg)1976.79 %Шаблон:Localimage:habravote .gif" width="73" height="10" />
Bazaar (bzr)481.66 %Шаблон:Localimage:habravote .gif" width="18" height="10" />
Другая бесплатная распределенная VCS80.28 %Шаблон:Localimage:habravote .gif" width="3" height="10" />
Коммерческая распределенная VCS230.79 %Шаблон:Localimage:habravote .gif" width="8" height="10" />
Другое672.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 раза большую, чем у него была тогда разработчиком. Потом стал начальником тестеров, потом менеджером, а потом ему надоело и он стал организовывать тренинги.

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

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

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