13 520
правок
Изменения
Новая: Культурный центр ГУ-ВШЭ (SU-HSE, хе-хе), три зала — A большой, B хороший, C аскетичный, но удобный. В A лампы з...
Культурный центр ГУ-ВШЭ (SU-HSE, хе-хе), три зала — A большой, B хороший, C аскетичный, но удобный. В A лампы засвечивали экран, и было два варианта — либо люди не видят доклад, либо докладчик не видит людей — если свет выключить, форменная кинозальная темнота. В B у меня было любимое место слева аудитории на полу у стеночки, он чистый, тёплый, мохнатый и удобный. Вайфай кстати постоянно отваливался, хотя некоторым, типа Миши Заборова, везло и они его юзали). Видеозаписи докладов, не говоря уже об онлайн-трансляции, насколько я понял, не было, а жаль =(
Программа менялась, аки рельеф при землетрясении. Такое впечатление, что каждый следующий день была новая программа. Когда раздавали её на бумажках, раздавали несколько разных вариантов — неправильную на русском, правильную на английском, во второй день также правильную и на русском. И всё равно кое-что отменялось. Может оно и к лучшему — никаких «Шахидов» не было (сначала предполагалось, что будет какой-то перец из Shahid Beheshti University).
Конференция менее «техническая», чем всякие хайлоады, доклады на совершенно отбалдовые тематики, но в этом и плюс: потому и аудитория менее унылая — например, количество девушек на конференции не равнялось O(0). Как писал про какой-то хайлоад Стас, если O(0) — аудитория выглядит просто как корабль уродов, а так — ну да, творческие личности, ага.
Стас был как всегда неподражаем, нагоняя ужас на аудиторию в Вассермановской жилетке и очках-биноклях, нереально отжигая в первый день, показывая мультики и проводя бесконечный «стихийный воркшоп» на ноутбуке в холле во второй.
Была парочка ископаемых (динозавров) (дедушки такие) — один из ВЦ Мингорисполкома, и другой тот самый, который устраивал митинг про «программирование на естественных языках», а на самом деле по сути про [[rupedia:Семантическая паутина|семантик веб]], а точнее RDF (тройки субьект-отношение-объект) и то что это типа естественная форма представления информации и всё из неё можно вывести.
Фотки кстати выложу, да.
== Анкеты ==
Были анкеты. В анкетах было проставление оценок докладчикам по 5-балльной шкале, а также очень любопытные вопросы (в скобках перевод на русский):
* Каков размер IT-бюджета вашей компании? (А сколько бы с вас срубить бабла?)
* Интересно ли вам узнать об Intel Parallel Studio побольше? (А хотите спама об IPS?)
* Интересно ли вам узнать о других продуктах Intel побольше? (А хотите спама от Intel вообще?)
* Какие технологии вы используете для построения Rich Internet Application? (Конечно, намёк на Flash/Flex и его конкурентов)
Я ответил так:
* IT-бюджета нет! — ''был такой вариант. любопытно, почему не было «не знаю»''
* В пень! («нет»)
* В пень! («нет»)
* Какие технологии?! Свободные!
Были также вопросы про количество разработчиков в целом и про количество .NET-чиков; мы всё равно плотно сидим на игле, так что на эти я ответил честно.
== День первый ==
На первом докладе (от гугла) я не был. Говорят, там было прикольно, и примерно то же самое, что и в некой презентации, которая выпускалась сразу после выпуска Хрома.
=== Владимир Ицыксон, Михаил Моисеев, СПбГПУ. Автоматическое обнаружение дефектов в промышленных программных системах на языках С/С++ ===
Рассказали про свой инструмент — очередной статический анализатор программ C/C++. Написанный, кстати, на Java :-) их спросили — а вы свой код пробовали анализировать? Они: Ы! А это невозможно. Он на жабе, а мы жабу не умеем, хотя и видим в ближайших планах на будущее. Инструмент сравнивали и с другими системами, и получалось лучше — хотя увы, не сравнили с … забыл название … короче, системой, считающейся самой мега-крутой, но увы — она стоит в районе 150000$ за лицензию.
Сравнивали на OpenSource проектах — Постгресе, Мазиле и т. п. Сравнивали, правда, тоже забавно: количество найденных дефектов :-) то есть, ''без учёта качества'' найденных дефектов — может, там мусор один? Дефектов, конечно, тысячи, и все проверить тяжело, но проверили бы хотя бы пару небольших случайных выборок. В общем они, наверное, верят в свою систему и её отлаживали, поэтому и считают, что скорее всего всё ОК.
Сама система производит впечатление, что находится вполне на уровне. Товарищ тоже неплохо разбирался в том, что говорил. Потом на докладе о «ранней обработке ошибок» вопрос «а какие у вас алгоритмы, какой мат.аппарат?» задал именно он.
=== Андрей Карпов, ООО «Системы программной верификации». Ранняя диагностика ошибок в параллельных программах (отстой) ===
Чувак пытался рекламировать свой продукт — [http://www.viva64.com/terminology/VivaMP_rus.html VivaMP]. Сделали статический анализатор, который чего-то там анализирует. В основном тупые семантические ошибки, а не ошибки параллельных алгоритмов. Вопрос из зала — А какие у вас алгоритмы используются, какой математический аппарат? — Ответ был в том духе, что нууу, чё-то там налабали, ну проверки какие-то, короче у нас его нет.
=== Станислав Фомин, Заказные ИнформСистемы. Управление тестами с Testopia — недостающее звено? (был отжиг) ===
Великий и неподражаемый =))) Стааааас Фомиииииин! Идея доклада, если кто-то не знает, в том, что системы управления тестами все жирные и пытаются лезть туда куда не надо. Их надо кастрировать и оставить только то, что надо (статусы и прогоны). Доклад рассказывался у нас внутри 20 октября 2009, видео есть в \\st-fomin\VIDEO\2009-10-20-testopia\, также, видимо, будет выложено в [http://team.custis.ru/ Корпоративный блог].
Примечание: сама Testopia, имхо, не совсем идеальна, а точнее, совсем не идеальна. Выкинуть бы из неё весь этот несчастный AJAX и заточить на пару простых юз-кейсов…
Конечно есть traceability, от бага можно перейти к коммиту, и т. д. и т. п. А вообще — traceability, traceability! Достали вы уже своим traceability!!! Не так он и важен, минимального — достаточно!
=== Андрей Бибичев, Заказные ИнформСистемы. Проектирование больших информационных систем в Agile ===
К сожалению сбежал с середины, так как дальше надо было выступать, так что видел не всё — запомнил мало, в основном буквы *DD… Хорошо запомнил что было в бодреньком ритме (82 слайда, вполне информационных) и как всегда по делу — Андрей всегда по делу рассказывает =)
=== Виталий Филиппов, Заказные ИнформСистемы. Одежка для Subversion: ViewVC и SVN-Searcher (я) ===
Рассказывал я про [[ViewVC]] и [[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<sub>n</sub>, точно не помню (наверняка Олег Клинчаев напишет), но включает в себя «абстрактность» и «изменяемость». Взяли сколько-то там ведущих opensource проектов и посчитали по ним, посчитали среднее, решили, что это хорошее значение показателя, и всем советуют делать, чтобы и у вас D<sub>n</sub> был такой же. Мысль некая в этом безусловно присутствует, конечно.
== День второй ==
=== Антон Хританков, Auriga Inc. Метод оценки прибыльности проекта на основе стохастической модели рисков при разработке ТКП ===
Был чуть-чуть в конце. Условно говоря — мат.статистики пришли в проектирование =) прогнозируют прибыльность проекта на основе статистики.
=== Владимир Рубанов, ИСП РАН. Система анализа обратной бинарной cовместимости библиотек Linux ===
Симпатично! Оказывается, [[rupedia:Linux Standard Base|LSB]] и [http://ispras.linuxfoundation.org/index.php/ABI_compliance_checker abi-compliance-checker] лабает [http://www.ispras.ru/ ИСП]!
Товарищ кратко рассказал про изменения, могущие повлечь за собой бинарную несовместимость разделяемых библиотек (обычных — C/C++). Условно говоря — изменения сигнатур функций, изменения виртуальной таблицы класса, изменения структур, изменения свойства статичности метода класса, изменения констант. Всё это в той или иной степени накрывает обратную бинарную совместимость. Пара примеров — [http://gcc.gnu.org/libstdc++/ libstdc++] и [http://www.freetype.org/ FreeType]. Первые (скорее случайно, чем специально) поменяли в какой-то версии порядок методов в классе. Им довольно быстро в вежливо-матерных выражениях разъяснили, что так делать не нужно… Они долго-долго извинялись, потом вроде пофиксили. Вторые (скорее специально, чем случайно) решили оптимизировать структуру какой-то структуры. Дооптимизировались и сломали почти на пустом месте бинарную совместимость. Но — поняли и пофиксили быстро.
Инструменты для борьбы с этим безобразием. Во-первых, версионирование библиотек ([[wikipedia:soname|soname]] главным образом) — чтобы было не просто libstdc++.so, а libstdc++.so.6.0.10, на который ссылается симлинк libstdc++.so.6, и на него libstdc++.so, а номер версии «6.0.10» сохраняется и в самом файле. Таким образом при загрузке проверяется версия, и если она не совпадает, значит, что-то с бинарной совместимостью, скорее всего, не то. Во-вторых, [[http://ispras.linuxfoundation.org/index.php/ABI_compliance_checker|abi-compliance-checker]], который все эти фишечки проверяет. Конечно же, он не может проверить семантику работы библиотеки (хотя и такой проект у них есть), но бинарную совместимость проверяет (это ответ на вопрос из зала). Некоторые проекты уже включили его в свой цикл разработки. В-третьих, [[rupedia:Linux Standard Base|LSB]] для бинарной совместимости между разными ''дистрибутивами Linux''.
''Да… теперь Linux-вирусы, если хотят быть переносимыми, должны будут соблюдать LSB… Но что-то всё равно пока не получается :-)''
=== Юлия Нечаева, NIX Solutions. Ловушки заказного тестирования ===
Пхехе. Три ловушки: жадность, лень и тупость. ''И от жадности ква-ква, и от глупости. И ещё от хвастовства, ква-ква-ква, ква-ква-ква, не поможет твой товар… Злой прааативный Дуремаааар!''
Все три ловушки — отношение клиента к тестерам-аутсорсерам :-) красной нитью сквозь всю презентацию проходила фраза «Заказчик не понимает. И когда подписывал — тоже не понимал». ''Олег Клинчаев: а может заказчик просто тупой?! :-)'' И таки действительно, последней проблемой была именно тупость.
По каждой есть рекомендации, как для тестеров, так и для заказчика.
Жадность: «давайте мы вам на тестирование выделим специального узкого специалиста, он лучше сделает» — «да вы просто жадные и денег хотите больше»! А надо объяснять, что на самом деле мы можем сделать и так, и так, но при этом у вас будут такие-то и такие-то риски, такое-то и такое-то качество. Доказывать, что специалист — действительно специалист, а не хрен с горы, очень желательно не увещеванием и даже не регалиями (бумажками-сертификатами и т. п.), а ''портфолио'' — примерами реальных проектов, которые он делал и сделал — бизнес'''ы''' это лучше понимают.
Лень: «дайте мне документацию» — «стоп! мы об этом не договаривались» — «да вы просто ленивые! мне даже не документация нужна, а детализация чего вы делали — за что я платил»?! Рекомендация: отчёты и описания тест-кейсов надо писать всегда, даже если это не оговаривалось. Это не так дорого, чтобы этого не делать, а потом напороться на «непонимание» заказчика, которому перед кем-нибудь свыше, скорее всего, нужно ещё и отчитаться. Также нужно делать работу тестировщиков прозрачнее.
Тупость: «да вы тупые мышекликеры, куда вам столько денег»! А надо объяснять, что на самом деле не всё так просто, и что и деньги вы платите нам не зря, и качество мы действительно обеспечиваем. Делать работу прозрачнее.
=== Игорь Одинцов, Intel. Опыт применения методов ТРИЗ для повышения эффективности разработки ПО ===
Скорее отчёт, чем доклад — было такое и ещё на нескольких докладах, типа вот мы статью написали и смотрите всё там, а здесь мы просто скажем что это есть.
[[rupedia:Теория_решения_изобретательских_задач|ТРИЗ]] — Теория Решения Изобретательских Задач. Она рассчитана на реальный мир, а не на нематериальный код, но эти чуваки решили её приспособить и, типа, приспособили. Рассказа о том, КАК — в принципе почти не было. Зато они ведут семинар по этой теме и привели данные опроса участников ДО и ПОСЛЕ проведения семинара — как вы считаете, ТРИЗ можно использовать в разработке? (да/частично/нет). «Нет» не отвечал никто, но надо отметить забавный факт — после проведения семинара оптимизма у участников поубавилось процентов на 7 народу — раньше они говорили «да», а после семинара стали «частично».
Заодно этот товарищ пытался очень завуалированно пропихнуть рекламу чего-то интеловского (не запомнил чего), но вроде, в принципе, не стал.
=== Владимир Булов, ВАЗ. Создание технологического портала товаропроводящей сети автомобилестроительной компании ===
До прослушивания доклада была такая мысль: «блин, вот вам делать там нечего — лучше бы качество поднимали; ну давай, послушаем лентяев»! После прослушивания доклада была такая мысль (и не у меня одного): «вроде как ВАЗовцев не послушаешь — рассказывают вменяемые вещи, а почему ж на выходе-то такое г…?»
В целом товарищи молодцы, раньше (лет 10 назад) у них был зоопарк виндов, дельфей (Delphi), FoxPro, Oracle, много '''разных''' серверов и т. п. Всё это на 14000 рабочих мест. Теперь у них [[rupedia:Itanium|Itanium]]-сервера (это, конечно, не молодцы, что и сами понимают), Oracle остался, то, что можно было (хотя такого мало), перенесли на [http://www.postgresql.org/ Postgres], винду ликвидировали калёной метлой, сэкономили 14000 лицензий, поставили везде бездисковые компы (замечательная фраза — «а зачем нам в цехе, где мастер регистрирует приход детали, полноприводный персональный компьютер?»), грузится всё это с флешек с Linux Castrated Edition (ну в смысле урезанным каким-то), Mozilla Firefox в качестве тонкого клиента и [[rupedia:LAMP|LA…P]] (Linux, Apache, …, PHP — вместо … обычно MySQL, но у них Oracle) на серверах.
В качестве приложения — стандартный PHP-быдлокод, похожий, как [[SEC(R) 2009:Отчет Заборова М.А#Владимир Булов. АвтоВаз. Портал для товароповодящей сети автомобителестроительной компании.|написал]] Миша Заборов (сам ты «линакс», кстати =)))), на наш CustisWeb. Пхехе. Приложений не одно и не два, а много, например, есть некий а-ля плантайм — тоже самописная база сотрудников. На последнем слайде с контактами был как раз скриншот оттуда.
: [[Участник:Mikle Zaborov|Mikle Zaborov]] 20:42, 2 ноября 2009 (UTC) Я к тому времени отчет еще не написал (то были пометки для себя):-(
Всё это постепенно развивалось, туда же подключили дилеров и т. п. Ещё рассказывал про жесть, которая была — одно время были одни серые дилеры, которые покупали на заводе за дёшево, а продавали рядом же за дорого. Из 600 серых дилеров в системе зарегистрировалось 7… (я так понял)
Их ещё спросили, а чего же вы от Оракла-то не отказались, он же стоит зараза нереальных денег — сложилось исторически, перетаскивать тяжело, хотя возможно в будущем сделают и это.
* Кстати-1: В качестве системы контроля версий они используют CVS.
* Кстати-2: поддержкой всего-всего-всего этого занимается примерно 300 человек.
* Цитата: 40 лет назад мы выпускали 2700 автомобилей в день. Сейчас всё то же самое, только этот процесс теперь обслуживает 14 тыс. АРМов…
=== Станислав Фомин, Заказные ИнформСистемы. Собор или базар: системы контроля версий — централизованные или распределенные? ===
Продолжение «говорит и показывает StasTV ™». Сначала показал первую серию Дилберта (1x01) и пару роликов CodeSwarm. Снова конечно же замечательный доклад, рассказ про DVCS ([[rupedia:Git|Git]] http://git-scm.com/, [[rupedia:Mercurial|Mercurial]], [[rupedia:Bazaar|Bazaar]]) vs CVCS ([[rupedia:Subversion|SVN]] — венец эволюции). Про [[wikipedia:SVK|SVK]] ничего не сказал, а кто-то хотел бы узнать — вопрос задали из зала. Материалы, наверное, будут на http://team.custis.ru/, но какие — я не знаю, видео-то нет.
Стас, кстати, считает, что лучше всех [[rupedia:Bazaar|Bazaar]]. Но по популярности Git’у он проигрывает очень сильно (раз в 10). Это данные из опроса с Хабра, на котором Стас, кстати, хорошо прокачал себе карму :-))
Данные вот такие:
<tab sep=tab head=topleft class=simpletable cellpadding=2>
Система Голоса Процент
CVS 238 8.21 % <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="88" height="10" /></html>
<font color="#008000">Subversion (SVN)</font> <font color="#00A000">'''1744'''</font> <font color="#00A000">'''60.14 %'''</font> <html><img </html>src="{{localimage:harbavote_winner.gif}}"<html> width="644" height="10" /></html>
Другая бесплатная централизованная VCS 11 0.38 % <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="4" height="10" /></html>
Коммерческая централизованная VCS 105 3.62 % <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="39" height="10" /></html>
<font color="blue">GIT</font> <font color="blue">459</font> <font color="blue">15.83 %</font> <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="169" height="10" /></html>
Mercurial (Hg) 197 6.79 % <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="73" height="10" /></html>
<font color="#A00000">Bazaar (bzr)</font> <font color="#A00000">48</font> <font color="#A00000">1.66 %</font> <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="18" height="10" /></html>
Другая бесплатная распределенная VCS 8 0.28 % <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="3" height="10" /></html>
Коммерческая распределенная VCS 23 0.79 % <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="8" height="10" /></html>
Другое 67 2.31 % <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="25" height="10" /></html>
Всего голосовало '''2167'''
</tab>
=== Александр Хрущев, Instream. Эффективность использования автоматических тестов в ИТ-проектах ===
В общем доклад мало о чём, хотя и не сказать, чтобы совсем ни о чём. Сказал, что начале вы затратите времени на автоматизацию тестирования сильно больше, чем на ручное — окупаться автотесты начнут релиза где-то с третьего. Графики нарисовал (явно отбалдовые). Ну, за исключением нагрузочного тестирования и иногда — модульного. Ничего не упомянул про Continuous Integration (а это ведь тоже выигрыш). Сказал, что раз затраты — давайте попробуем их разделить с заказчиком, хотя это и не получится в 99 % случаев. Сказал, что никогда не надо выдавать результаты автотестов за результаты ручного тестирования — заказчик может это понять и обидеться (''и правда, с чего бы вдруг?'').
=== Вячеслав Васильев, Красный угол. Технология Microsoft.NET Micro Framework для построения беспроводных систем сбора медицинской информации ===
Зачем-то стал сначала рассказывать про врачебные ошибки, хотя на самом деле, я так понял, была идея продемонстрировать маленькую коробочку (в холле показывал потом), которая в себе содержит .NET и передаёт давление пациента по беспроводному каналу.
=== Алексей Лянгузов, Sun Microsystems. Контекстное Тестирование ПО: Практические Рекомендации (ни-а-чём) ===
Вот уже этот доклад действительно ни о чём — совсем ни о чём. Я, говорит, лет 9 уже работаю в тестировании, и когда полгода назад услышал про школу «Контекстного» тестирования и почитал про неё — понял, что это всегда и делал, ничего об этом не зная. О, оказывается, вот оно как называется — дай-ка расскажу. '''НО!!!''' Ни одной практической рекомендации доклад не содержал. Такое «Контекстное» (типа «контекст важен!» — жизнь это вообще контекст, кто же спорит) можно придумать всё что угодно — разработку, забивание гвоздей. Оказавшийся под гвоздём палец — обычно неудачный контекст. Хотя, если этот палец чей-то, а не свой, и из этого человека надо выбить какие-то сведения — как раз наоборот…
Возможно, в реальности действительно есть школа «КТ» и у них действительно есть какие-то практики, но тут… одни общие слова. Он даже сам сказал — ну я не знаю, как про это можно рассказать, этому можно только опытом научиться.
Очень хорошо суть доклада иллюстрирует последний слайд, на котором написан «алгоритм решения проблем»:
* определить проблему
* оценить ситуацию
* найти решение
* воплотить решение в жизнь
Бу-га-га!!! Гениальное открытие!!! ''«Первый шаг: воруем трусы…» (c)''
=== Александр Орлов, Happy-PM. Профессиональный тестировщик ===
Доклад без слайдов. Чувак рассказывал про то, что по его мнению, из тестировщиков получаются хорошие менеджеры, ибо тестировщик занимается всем, вынужден отбиваться от всех, и организовывать весь процесс. В реальности, по-видимому, его просто лично так хорошо пропёрло попасть в Sun тестером на зарплату в 2.5 раза большую, чем у него была тогда разработчиком. Потом стал начальником тестеров, потом менеджером, а потом ему надоело и он стал организовывать тренинги.
Из зала очень хорошо кто-то сказал, что если бы он попал на любую другую должность, где была бы такая же з/п и если бы его так же пропёрло, то став потом тренером, он делал бы такой же доклад про другую должность. С другой стороны, возможно была у него изначально природная склонность всё ломать (программист ведь строит, а тестер ломает). Чип всегда доверял Дэйлу во всем, что касалось вскрытия программ.
''У Дэйла был талант что-нибудь ломать. Он ломал всегда, все и где угодно. Ломал карандаши, когда учился в школе, ломал ц&!-@ всем девчонкам района когда стал постарше, ломал заборы и фонарные столбы, лифты и перила в подъездах…Когда Дэйл занялся изучением премудростей программирования, то тут ему открылись такие широкие возможности для ломания, что он даже оставил попытки сломать сам компьютер.''
Возможное мнение: ну да, наверное. А возможно подход нашей компании вменяемее — ЧистоТестеров нет, есть Аналитеги. Из которых — а кто спорит — действительно может получиться более вменяемый менеджер… Ну а кроме того, это всегда так :) а понимаем только мы! :)
[[Категория:SEC-2009]]
Программа менялась, аки рельеф при землетрясении. Такое впечатление, что каждый следующий день была новая программа. Когда раздавали её на бумажках, раздавали несколько разных вариантов — неправильную на русском, правильную на английском, во второй день также правильную и на русском. И всё равно кое-что отменялось. Может оно и к лучшему — никаких «Шахидов» не было (сначала предполагалось, что будет какой-то перец из Shahid Beheshti University).
Конференция менее «техническая», чем всякие хайлоады, доклады на совершенно отбалдовые тематики, но в этом и плюс: потому и аудитория менее унылая — например, количество девушек на конференции не равнялось O(0). Как писал про какой-то хайлоад Стас, если O(0) — аудитория выглядит просто как корабль уродов, а так — ну да, творческие личности, ага.
Стас был как всегда неподражаем, нагоняя ужас на аудиторию в Вассермановской жилетке и очках-биноклях, нереально отжигая в первый день, показывая мультики и проводя бесконечный «стихийный воркшоп» на ноутбуке в холле во второй.
Была парочка ископаемых (динозавров) (дедушки такие) — один из ВЦ Мингорисполкома, и другой тот самый, который устраивал митинг про «программирование на естественных языках», а на самом деле по сути про [[rupedia:Семантическая паутина|семантик веб]], а точнее RDF (тройки субьект-отношение-объект) и то что это типа естественная форма представления информации и всё из неё можно вывести.
Фотки кстати выложу, да.
== Анкеты ==
Были анкеты. В анкетах было проставление оценок докладчикам по 5-балльной шкале, а также очень любопытные вопросы (в скобках перевод на русский):
* Каков размер IT-бюджета вашей компании? (А сколько бы с вас срубить бабла?)
* Интересно ли вам узнать об Intel Parallel Studio побольше? (А хотите спама об IPS?)
* Интересно ли вам узнать о других продуктах Intel побольше? (А хотите спама от Intel вообще?)
* Какие технологии вы используете для построения Rich Internet Application? (Конечно, намёк на Flash/Flex и его конкурентов)
Я ответил так:
* IT-бюджета нет! — ''был такой вариант. любопытно, почему не было «не знаю»''
* В пень! («нет»)
* В пень! («нет»)
* Какие технологии?! Свободные!
Были также вопросы про количество разработчиков в целом и про количество .NET-чиков; мы всё равно плотно сидим на игле, так что на эти я ответил честно.
== День первый ==
На первом докладе (от гугла) я не был. Говорят, там было прикольно, и примерно то же самое, что и в некой презентации, которая выпускалась сразу после выпуска Хрома.
=== Владимир Ицыксон, Михаил Моисеев, СПбГПУ. Автоматическое обнаружение дефектов в промышленных программных системах на языках С/С++ ===
Рассказали про свой инструмент — очередной статический анализатор программ C/C++. Написанный, кстати, на Java :-) их спросили — а вы свой код пробовали анализировать? Они: Ы! А это невозможно. Он на жабе, а мы жабу не умеем, хотя и видим в ближайших планах на будущее. Инструмент сравнивали и с другими системами, и получалось лучше — хотя увы, не сравнили с … забыл название … короче, системой, считающейся самой мега-крутой, но увы — она стоит в районе 150000$ за лицензию.
Сравнивали на OpenSource проектах — Постгресе, Мазиле и т. п. Сравнивали, правда, тоже забавно: количество найденных дефектов :-) то есть, ''без учёта качества'' найденных дефектов — может, там мусор один? Дефектов, конечно, тысячи, и все проверить тяжело, но проверили бы хотя бы пару небольших случайных выборок. В общем они, наверное, верят в свою систему и её отлаживали, поэтому и считают, что скорее всего всё ОК.
Сама система производит впечатление, что находится вполне на уровне. Товарищ тоже неплохо разбирался в том, что говорил. Потом на докладе о «ранней обработке ошибок» вопрос «а какие у вас алгоритмы, какой мат.аппарат?» задал именно он.
=== Андрей Карпов, ООО «Системы программной верификации». Ранняя диагностика ошибок в параллельных программах (отстой) ===
Чувак пытался рекламировать свой продукт — [http://www.viva64.com/terminology/VivaMP_rus.html VivaMP]. Сделали статический анализатор, который чего-то там анализирует. В основном тупые семантические ошибки, а не ошибки параллельных алгоритмов. Вопрос из зала — А какие у вас алгоритмы используются, какой математический аппарат? — Ответ был в том духе, что нууу, чё-то там налабали, ну проверки какие-то, короче у нас его нет.
=== Станислав Фомин, Заказные ИнформСистемы. Управление тестами с Testopia — недостающее звено? (был отжиг) ===
Великий и неподражаемый =))) Стааааас Фомиииииин! Идея доклада, если кто-то не знает, в том, что системы управления тестами все жирные и пытаются лезть туда куда не надо. Их надо кастрировать и оставить только то, что надо (статусы и прогоны). Доклад рассказывался у нас внутри 20 октября 2009, видео есть в \\st-fomin\VIDEO\2009-10-20-testopia\, также, видимо, будет выложено в [http://team.custis.ru/ Корпоративный блог].
Примечание: сама Testopia, имхо, не совсем идеальна, а точнее, совсем не идеальна. Выкинуть бы из неё весь этот несчастный AJAX и заточить на пару простых юз-кейсов…
Конечно есть traceability, от бага можно перейти к коммиту, и т. д. и т. п. А вообще — traceability, traceability! Достали вы уже своим traceability!!! Не так он и важен, минимального — достаточно!
=== Андрей Бибичев, Заказные ИнформСистемы. Проектирование больших информационных систем в Agile ===
К сожалению сбежал с середины, так как дальше надо было выступать, так что видел не всё — запомнил мало, в основном буквы *DD… Хорошо запомнил что было в бодреньком ритме (82 слайда, вполне информационных) и как всегда по делу — Андрей всегда по делу рассказывает =)
=== Виталий Филиппов, Заказные ИнформСистемы. Одежка для Subversion: ViewVC и SVN-Searcher (я) ===
Рассказывал я про [[ViewVC]] и [[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<sub>n</sub>, точно не помню (наверняка Олег Клинчаев напишет), но включает в себя «абстрактность» и «изменяемость». Взяли сколько-то там ведущих opensource проектов и посчитали по ним, посчитали среднее, решили, что это хорошее значение показателя, и всем советуют делать, чтобы и у вас D<sub>n</sub> был такой же. Мысль некая в этом безусловно присутствует, конечно.
== День второй ==
=== Антон Хританков, Auriga Inc. Метод оценки прибыльности проекта на основе стохастической модели рисков при разработке ТКП ===
Был чуть-чуть в конце. Условно говоря — мат.статистики пришли в проектирование =) прогнозируют прибыльность проекта на основе статистики.
=== Владимир Рубанов, ИСП РАН. Система анализа обратной бинарной cовместимости библиотек Linux ===
Симпатично! Оказывается, [[rupedia:Linux Standard Base|LSB]] и [http://ispras.linuxfoundation.org/index.php/ABI_compliance_checker abi-compliance-checker] лабает [http://www.ispras.ru/ ИСП]!
Товарищ кратко рассказал про изменения, могущие повлечь за собой бинарную несовместимость разделяемых библиотек (обычных — C/C++). Условно говоря — изменения сигнатур функций, изменения виртуальной таблицы класса, изменения структур, изменения свойства статичности метода класса, изменения констант. Всё это в той или иной степени накрывает обратную бинарную совместимость. Пара примеров — [http://gcc.gnu.org/libstdc++/ libstdc++] и [http://www.freetype.org/ FreeType]. Первые (скорее случайно, чем специально) поменяли в какой-то версии порядок методов в классе. Им довольно быстро в вежливо-матерных выражениях разъяснили, что так делать не нужно… Они долго-долго извинялись, потом вроде пофиксили. Вторые (скорее специально, чем случайно) решили оптимизировать структуру какой-то структуры. Дооптимизировались и сломали почти на пустом месте бинарную совместимость. Но — поняли и пофиксили быстро.
Инструменты для борьбы с этим безобразием. Во-первых, версионирование библиотек ([[wikipedia:soname|soname]] главным образом) — чтобы было не просто libstdc++.so, а libstdc++.so.6.0.10, на который ссылается симлинк libstdc++.so.6, и на него libstdc++.so, а номер версии «6.0.10» сохраняется и в самом файле. Таким образом при загрузке проверяется версия, и если она не совпадает, значит, что-то с бинарной совместимостью, скорее всего, не то. Во-вторых, [[http://ispras.linuxfoundation.org/index.php/ABI_compliance_checker|abi-compliance-checker]], который все эти фишечки проверяет. Конечно же, он не может проверить семантику работы библиотеки (хотя и такой проект у них есть), но бинарную совместимость проверяет (это ответ на вопрос из зала). Некоторые проекты уже включили его в свой цикл разработки. В-третьих, [[rupedia:Linux Standard Base|LSB]] для бинарной совместимости между разными ''дистрибутивами Linux''.
''Да… теперь Linux-вирусы, если хотят быть переносимыми, должны будут соблюдать LSB… Но что-то всё равно пока не получается :-)''
=== Юлия Нечаева, NIX Solutions. Ловушки заказного тестирования ===
Пхехе. Три ловушки: жадность, лень и тупость. ''И от жадности ква-ква, и от глупости. И ещё от хвастовства, ква-ква-ква, ква-ква-ква, не поможет твой товар… Злой прааативный Дуремаааар!''
Все три ловушки — отношение клиента к тестерам-аутсорсерам :-) красной нитью сквозь всю презентацию проходила фраза «Заказчик не понимает. И когда подписывал — тоже не понимал». ''Олег Клинчаев: а может заказчик просто тупой?! :-)'' И таки действительно, последней проблемой была именно тупость.
По каждой есть рекомендации, как для тестеров, так и для заказчика.
Жадность: «давайте мы вам на тестирование выделим специального узкого специалиста, он лучше сделает» — «да вы просто жадные и денег хотите больше»! А надо объяснять, что на самом деле мы можем сделать и так, и так, но при этом у вас будут такие-то и такие-то риски, такое-то и такое-то качество. Доказывать, что специалист — действительно специалист, а не хрен с горы, очень желательно не увещеванием и даже не регалиями (бумажками-сертификатами и т. п.), а ''портфолио'' — примерами реальных проектов, которые он делал и сделал — бизнес'''ы''' это лучше понимают.
Лень: «дайте мне документацию» — «стоп! мы об этом не договаривались» — «да вы просто ленивые! мне даже не документация нужна, а детализация чего вы делали — за что я платил»?! Рекомендация: отчёты и описания тест-кейсов надо писать всегда, даже если это не оговаривалось. Это не так дорого, чтобы этого не делать, а потом напороться на «непонимание» заказчика, которому перед кем-нибудь свыше, скорее всего, нужно ещё и отчитаться. Также нужно делать работу тестировщиков прозрачнее.
Тупость: «да вы тупые мышекликеры, куда вам столько денег»! А надо объяснять, что на самом деле не всё так просто, и что и деньги вы платите нам не зря, и качество мы действительно обеспечиваем. Делать работу прозрачнее.
=== Игорь Одинцов, Intel. Опыт применения методов ТРИЗ для повышения эффективности разработки ПО ===
Скорее отчёт, чем доклад — было такое и ещё на нескольких докладах, типа вот мы статью написали и смотрите всё там, а здесь мы просто скажем что это есть.
[[rupedia:Теория_решения_изобретательских_задач|ТРИЗ]] — Теория Решения Изобретательских Задач. Она рассчитана на реальный мир, а не на нематериальный код, но эти чуваки решили её приспособить и, типа, приспособили. Рассказа о том, КАК — в принципе почти не было. Зато они ведут семинар по этой теме и привели данные опроса участников ДО и ПОСЛЕ проведения семинара — как вы считаете, ТРИЗ можно использовать в разработке? (да/частично/нет). «Нет» не отвечал никто, но надо отметить забавный факт — после проведения семинара оптимизма у участников поубавилось процентов на 7 народу — раньше они говорили «да», а после семинара стали «частично».
Заодно этот товарищ пытался очень завуалированно пропихнуть рекламу чего-то интеловского (не запомнил чего), но вроде, в принципе, не стал.
=== Владимир Булов, ВАЗ. Создание технологического портала товаропроводящей сети автомобилестроительной компании ===
До прослушивания доклада была такая мысль: «блин, вот вам делать там нечего — лучше бы качество поднимали; ну давай, послушаем лентяев»! После прослушивания доклада была такая мысль (и не у меня одного): «вроде как ВАЗовцев не послушаешь — рассказывают вменяемые вещи, а почему ж на выходе-то такое г…?»
В целом товарищи молодцы, раньше (лет 10 назад) у них был зоопарк виндов, дельфей (Delphi), FoxPro, Oracle, много '''разных''' серверов и т. п. Всё это на 14000 рабочих мест. Теперь у них [[rupedia:Itanium|Itanium]]-сервера (это, конечно, не молодцы, что и сами понимают), Oracle остался, то, что можно было (хотя такого мало), перенесли на [http://www.postgresql.org/ Postgres], винду ликвидировали калёной метлой, сэкономили 14000 лицензий, поставили везде бездисковые компы (замечательная фраза — «а зачем нам в цехе, где мастер регистрирует приход детали, полноприводный персональный компьютер?»), грузится всё это с флешек с Linux Castrated Edition (ну в смысле урезанным каким-то), Mozilla Firefox в качестве тонкого клиента и [[rupedia:LAMP|LA…P]] (Linux, Apache, …, PHP — вместо … обычно MySQL, но у них Oracle) на серверах.
В качестве приложения — стандартный PHP-быдлокод, похожий, как [[SEC(R) 2009:Отчет Заборова М.А#Владимир Булов. АвтоВаз. Портал для товароповодящей сети автомобителестроительной компании.|написал]] Миша Заборов (сам ты «линакс», кстати =)))), на наш CustisWeb. Пхехе. Приложений не одно и не два, а много, например, есть некий а-ля плантайм — тоже самописная база сотрудников. На последнем слайде с контактами был как раз скриншот оттуда.
: [[Участник:Mikle Zaborov|Mikle Zaborov]] 20:42, 2 ноября 2009 (UTC) Я к тому времени отчет еще не написал (то были пометки для себя):-(
Всё это постепенно развивалось, туда же подключили дилеров и т. п. Ещё рассказывал про жесть, которая была — одно время были одни серые дилеры, которые покупали на заводе за дёшево, а продавали рядом же за дорого. Из 600 серых дилеров в системе зарегистрировалось 7… (я так понял)
Их ещё спросили, а чего же вы от Оракла-то не отказались, он же стоит зараза нереальных денег — сложилось исторически, перетаскивать тяжело, хотя возможно в будущем сделают и это.
* Кстати-1: В качестве системы контроля версий они используют CVS.
* Кстати-2: поддержкой всего-всего-всего этого занимается примерно 300 человек.
* Цитата: 40 лет назад мы выпускали 2700 автомобилей в день. Сейчас всё то же самое, только этот процесс теперь обслуживает 14 тыс. АРМов…
=== Станислав Фомин, Заказные ИнформСистемы. Собор или базар: системы контроля версий — централизованные или распределенные? ===
Продолжение «говорит и показывает StasTV ™». Сначала показал первую серию Дилберта (1x01) и пару роликов CodeSwarm. Снова конечно же замечательный доклад, рассказ про DVCS ([[rupedia:Git|Git]] http://git-scm.com/, [[rupedia:Mercurial|Mercurial]], [[rupedia:Bazaar|Bazaar]]) vs CVCS ([[rupedia:Subversion|SVN]] — венец эволюции). Про [[wikipedia:SVK|SVK]] ничего не сказал, а кто-то хотел бы узнать — вопрос задали из зала. Материалы, наверное, будут на http://team.custis.ru/, но какие — я не знаю, видео-то нет.
Стас, кстати, считает, что лучше всех [[rupedia:Bazaar|Bazaar]]. Но по популярности Git’у он проигрывает очень сильно (раз в 10). Это данные из опроса с Хабра, на котором Стас, кстати, хорошо прокачал себе карму :-))
Данные вот такие:
<tab sep=tab head=topleft class=simpletable cellpadding=2>
Система Голоса Процент
CVS 238 8.21 % <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="88" height="10" /></html>
<font color="#008000">Subversion (SVN)</font> <font color="#00A000">'''1744'''</font> <font color="#00A000">'''60.14 %'''</font> <html><img </html>src="{{localimage:harbavote_winner.gif}}"<html> width="644" height="10" /></html>
Другая бесплатная централизованная VCS 11 0.38 % <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="4" height="10" /></html>
Коммерческая централизованная VCS 105 3.62 % <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="39" height="10" /></html>
<font color="blue">GIT</font> <font color="blue">459</font> <font color="blue">15.83 %</font> <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="169" height="10" /></html>
Mercurial (Hg) 197 6.79 % <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="73" height="10" /></html>
<font color="#A00000">Bazaar (bzr)</font> <font color="#A00000">48</font> <font color="#A00000">1.66 %</font> <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="18" height="10" /></html>
Другая бесплатная распределенная VCS 8 0.28 % <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="3" height="10" /></html>
Коммерческая распределенная VCS 23 0.79 % <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="8" height="10" /></html>
Другое 67 2.31 % <html><img </html>src="{{localimage:harbavote_.gif}}"<html> width="25" height="10" /></html>
Всего голосовало '''2167'''
</tab>
=== Александр Хрущев, Instream. Эффективность использования автоматических тестов в ИТ-проектах ===
В общем доклад мало о чём, хотя и не сказать, чтобы совсем ни о чём. Сказал, что начале вы затратите времени на автоматизацию тестирования сильно больше, чем на ручное — окупаться автотесты начнут релиза где-то с третьего. Графики нарисовал (явно отбалдовые). Ну, за исключением нагрузочного тестирования и иногда — модульного. Ничего не упомянул про Continuous Integration (а это ведь тоже выигрыш). Сказал, что раз затраты — давайте попробуем их разделить с заказчиком, хотя это и не получится в 99 % случаев. Сказал, что никогда не надо выдавать результаты автотестов за результаты ручного тестирования — заказчик может это понять и обидеться (''и правда, с чего бы вдруг?'').
=== Вячеслав Васильев, Красный угол. Технология Microsoft.NET Micro Framework для построения беспроводных систем сбора медицинской информации ===
Зачем-то стал сначала рассказывать про врачебные ошибки, хотя на самом деле, я так понял, была идея продемонстрировать маленькую коробочку (в холле показывал потом), которая в себе содержит .NET и передаёт давление пациента по беспроводному каналу.
=== Алексей Лянгузов, Sun Microsystems. Контекстное Тестирование ПО: Практические Рекомендации (ни-а-чём) ===
Вот уже этот доклад действительно ни о чём — совсем ни о чём. Я, говорит, лет 9 уже работаю в тестировании, и когда полгода назад услышал про школу «Контекстного» тестирования и почитал про неё — понял, что это всегда и делал, ничего об этом не зная. О, оказывается, вот оно как называется — дай-ка расскажу. '''НО!!!''' Ни одной практической рекомендации доклад не содержал. Такое «Контекстное» (типа «контекст важен!» — жизнь это вообще контекст, кто же спорит) можно придумать всё что угодно — разработку, забивание гвоздей. Оказавшийся под гвоздём палец — обычно неудачный контекст. Хотя, если этот палец чей-то, а не свой, и из этого человека надо выбить какие-то сведения — как раз наоборот…
Возможно, в реальности действительно есть школа «КТ» и у них действительно есть какие-то практики, но тут… одни общие слова. Он даже сам сказал — ну я не знаю, как про это можно рассказать, этому можно только опытом научиться.
Очень хорошо суть доклада иллюстрирует последний слайд, на котором написан «алгоритм решения проблем»:
* определить проблему
* оценить ситуацию
* найти решение
* воплотить решение в жизнь
Бу-га-га!!! Гениальное открытие!!! ''«Первый шаг: воруем трусы…» (c)''
=== Александр Орлов, Happy-PM. Профессиональный тестировщик ===
Доклад без слайдов. Чувак рассказывал про то, что по его мнению, из тестировщиков получаются хорошие менеджеры, ибо тестировщик занимается всем, вынужден отбиваться от всех, и организовывать весь процесс. В реальности, по-видимому, его просто лично так хорошо пропёрло попасть в Sun тестером на зарплату в 2.5 раза большую, чем у него была тогда разработчиком. Потом стал начальником тестеров, потом менеджером, а потом ему надоело и он стал организовывать тренинги.
Из зала очень хорошо кто-то сказал, что если бы он попал на любую другую должность, где была бы такая же з/п и если бы его так же пропёрло, то став потом тренером, он делал бы такой же доклад про другую должность. С другой стороны, возможно была у него изначально природная склонность всё ломать (программист ведь строит, а тестер ломает). Чип всегда доверял Дэйлу во всем, что касалось вскрытия программ.
''У Дэйла был талант что-нибудь ломать. Он ломал всегда, все и где угодно. Ломал карандаши, когда учился в школе, ломал ц&!-@ всем девчонкам района когда стал постарше, ломал заборы и фонарные столбы, лифты и перила в подъездах…Когда Дэйл занялся изучением премудростей программирования, то тут ему открылись такие широкие возможности для ломания, что он даже оставил попытки сломать сам компьютер.''
Возможное мнение: ну да, наверное. А возможно подход нашей компании вменяемее — ЧистоТестеров нет, есть Аналитеги. Из которых — а кто спорит — действительно может получиться более вменяемый менеджер… Ну а кроме того, это всегда так :) а понимаем только мы! :)
[[Категория:SEC-2009]]
