Просмотр исходного текста страницы SECR-2013: Отчёт Виталия Филиппова

[[Категория:SECR-2013]]
* Конференция «Software Engineering Conference Russia — 2013». Даты проведения — 24-25 октября 2013.
* От нас ходило 8 человек, но я, по-моему, так выбирал доклады, что с другими пересекался мало. Хорошо — значит, отчёт будет полезнее :)
* Темы — разные, качество докладов — среднее, были интересные, но много и всякой фигни, в том числе долгих «круглых столов».
* Докладов много, 4 параллельных сессии в первый день, 5 параллельных сессий во второй.
* Место проведения: Digital October. Типичная для него проблема — всё время в проходах ставят мелкие столики, вокруг них толпится народ, и в итоге фиг пройдёшь, всё время расталкивать кого-то приходится.
* Торможений в организации не наблюдалось.
* Презентации уже есть на сайте — http://2013.secr.ru/, и это тоже хорошо.
* Еда: Кофечай был всё время, это хорошо. В перерывах давали довольно гнусные бутерброды, претендующие на вид «мини-бургеров», и печеньки, которые мгновенно сжирались. Обед нормальный, люди как всегда выстраивались в длиннющие очереди, а я применял хак.
* Ну какой нафиг software engineering может быть в 9:00? Хоть бы в 10, что ли… :)

== День 1 ==

=== Легковесное профилирование разделяемых библиотек в Linux для встраиваемых систем — Кирилл Кринкин, Санкт-Петербургский Электротехнический Университет ===

Что у них там за «встраиваемые» системы на x86 и x86-64, я не до конца понял, но сам подход довольно простой и понятный. Допустим, мы:
* не хотим / не можем менять саму библиотеку
* не хотим никак менять стандартные библиотеки системы
* не хотим или не можем инструментировать программу разными valgrind’ами
* хотим профилировать ограниченное число функций в любых библиотеках, в том числе системных, и чтобы это работало быстро

Логичное решение — делать всё это путём подмены динамического загрузчика (/lib/ld-linux.so.2 и libdl.so). То есть путём патчинга libc. Модификация заливается на целевую систему, софт запускается через подменённый загрузчик. Оный получает имена функций из переменной окружения (их же немного), и для каждой генерирует профилирующую ассемблерную обёртку. Получается очень шустро и занимает мало памяти — профилируется-то не всё. Просто создаётся по «контексту» на каждое место вызова.

Проект выложен на github — [https://github.com/OSLL/elfperf elfperf].

=== Система видеосвязи для невидимого интернета — Андрей Бодренко, Волгоградский Государственный Университет ===

Разрывной доклад! Немолодой и даже уже немного лысеющий чувак открыл для себя децентрализованную оверлейную сеть [http://ru.wikipedia.org/wiki/I2P I2P]. Сделал для неё просто-таки ZverBrowser:

[[File:008 bodrenko.pdf|page=11|400px]]

И у чувака реальные идеи — ух ты! На этом можно построить децентрализованную социальную сеть! Ух ты! На этом можно сделать децентрализованный email, когда почтовый ящик будет прямо у тебя в комнате на миникомпьютере, воткнутом в розетку! Можно делать VPN! ''«Можна грабить корованы, можна подзрывать мосты!»''

Рассказывал с множеством «эээ» и «эту программу я реализовал на языке си шарп под операционную систему виндоус». Основной упор вообще был на видеосвязь. Он вроде даже что-то такое реализовал (опять-таки «на языке си шарп»).

То есть в принципе понятно, что идеи нормальные, просто смешно немного, типа открытие такое :). Но основной плюс I2P в прозрачном шифровании и анонимности, и отсутствии централизованной аллокации адресов, а не в бессерверности, которую можно сделать и на базе обычного IPv4 (или, например, IPv6 для обхода NAT’ов), и которая всё равно требует написания кода, отвечающего за корректное взаимодействие всех твоих систем (видео или каких там ещё). А IPv6, кстати, легко врубить себе прямо сейчас через anycast адрес.

Короче, вот если бы он сделал аналог скайпика для I2P, или прототип системы, поставив которую на «мини-компьютер», ты бы получал свою электронную почту — вот это было бы круто… а так — просто zverbrowser :)

=== OpenStack as a public cloud at IBM: lessons learned — Николай Марин, IBM ===

Рассказ о тех фичах, которые IBM допилил для OpenStack, чтобы сделать у себя публичное облако на его основе. Доработки довольно простые — отпилили суперюзера, чтобы извне зайти в панель управления под «рутом» было нельзя… как-то допилили миграцию — то ли чтобы между датацентрами работала, то ли ещё что-то… пересунули часть сервисов самого openstack’а тоже в виртуалки… вроде добавили прямое подключение дисков… Также в презентации было в целом про детали их сервиса (CloudFirst Factory) — типа сколько компов, стоек, какая конфигурация…

Ну а люди их спрашивают — вы конечно молодцы, что похвастались :), а где код доработок-то? Чувак ответил что-то невразумительное — то ли они дорабатывают транк, то ли код доработок сейчас вообще только внутри IBM, а наружу только торчит сервис и демо (cloudfirst.demos.ibm.com)…

=== Компромиссы в развитии платформы Java — Алексей Фёдоров, Oracle ===

Прикольный лысый явист из Оракла рассказывал про, в основном, проблемы совместимости платформы Java и том, почему оно вынуждено медленно развиваться. Были различные примеры, но общий смысл такой:
* Старые public методы убирать вообще нельзя, по понятным причинам.
* Разные баги платформы можно фиксить в major релизах. Баги там обычно, в общем-то, довольно мелкие, например, по спецификации метод NULL не должен принимать, а он его принимает. Или имя приватного класса, не фигурирующего в спеке, наружу через getClass и сериализацию утекает. А оценить, кому вы что сломаете, если пофиксите — невозможно, потому что Java используется дофига где и собрать фидбэк со всех этих мест очень сложно. Поэтому риск по умолчанию «high».
* Новые public методы только в major релизах, ибо если добавлять постоянно, то альтернативные JVM вынуждены будут постоянно гнаться за оригиналом и могут вообще послать оригинал куда подальше.
* Был у них какой-то пример, когда появилась компания, которая сказала — оракл (или ещё сан?) баги не фиксит, а мы вот фиксим, и начала поддерживать свою версию Java для своих клиентов. А потом в новой версии оракл (или сан?) эти баги таки пофиксил, но по-своему. Те было хотели выкинуть свой фикс, а клиенты им сказали — нельзя, у нас уже на это всё завязано. В общем, так всё и загнулось.

=== Kotlin vs Java puzzlers — Светлана Исакова, JetBrains ===

Прикольная такая девочка рассказывала про язык Kotlin (мало) и про примеры из книжки Java Puzzlers (больше) — то есть некие примеры кода, выполняющиеся неочевидно. Местами притянутые за уши:
* Сравнение строк на ==. Константа может быть не равна сформированной в рантайме строке, две сформированные в рантайме строки могут быть не равны друг другу.
* С вещественными числами. Типа из-за точности вычисления 2-0.1 != 0.9.
* С конструктором StringBuilder’а. Типа символом он не ициализируется.
Я бы не назвал это недостатками Java. Не на PHP, в конце-то концов, пишете, чтобы это всё очевидным было ))

История [http://kotlin.jetbrains.org/ Kotlin]'а, видимо, в том, что пришёл к ним RedHat со своим [http://ceylon-lang.org/ Ceylon]'ом и попросил под него сделать IDE, а они не захотели и сделали свой Ceylon с БДж и Ш.

Хотя отличия есть — Ceylon пишет свою стандартную библиотеку, а Kotlin ориентируется на обычную Java’вскую. Но имхо Ceylon хоть редхат поддерживает, а котлин — это вообще поделие… Но девочка прикольная была, да.

=== Веб-разработчик и голый SQL: конфликты и подходы к решению — Филипп Торчинский, JetBrains ===

По сути реклама IDE JetBrains и того что она умеет в SQL базы данных лазать, особо полезного там было мало. Соответственно и меня там тоже было мало. Какие нафиг конфликты, чего все так пристали к SQL, непонятно. Оленей что ли нанимаете, которые язык не понимают?

=== Современные вызовы образования в области программной инженерии — Юрий Куприянов, WikiVote! ===

Был чуть-чуть в конце, доклад — рассказ про нюансы IT-образования, например, отсутствие нормального обучения практике программирования в ВУЗах. По этому поводу, кстати, я лично от себя хочу добавить, что это, может, и хорошо — образование должно быть в первую очередь фундаментальным, потому что фундаментальную часть тебе потом после выпуска уже никто никогда не расскажет, а практику догнать всегда можно самому. А будут учить одной практике — так и вырастешь быдлокодером.

Также докладчик упомянул SEMAT — новое популярное слово в этом году :-D, типа некая классификация методологий разработки («теория всего?») и то, что этим надо грузить студентов (нет уж, нахрен-нахрен…). Ещё было про онлайн-курсы (MOOC, Massive Open Online Courses) и про то, что это круто и этим обязательно надо пользоваться. Тут не поспоришь, курсы действительно хорошая штука, дают «инвертированное образование» — на лекции можно не ходить (на них и так никто не ходит), вместо этого ты их смотришь на диване дома, а разбор и практику наоборот делаешь на учёбе.

Ещё был хороший термин '''«скрамно»''' (означает, что «у нас скрам, но…») — он не новый, просто я его только сейчас услышал :) сначала ещё был английский аналог — scrumbutt.

А потом мы с Юрием и Стасом после доклада интересно побеседовали на тему MediaWiki в целом и Semantic MediaWiki в частности, потому что WikiVote как раз её использует и участвует в разработке, и я с ними время от времени даже общался в списке рассылки. А ещё — не далее, чем на этой неделе (28-30 октября) они проводили аж целую конференцию по SMW в Берлине. Вообще они занимаются продвижением управления знаниями на основе SMW в разные НЕ-разработческие компании (вплоть до нефтяных), и Юрий говорил, что заходит оно туда довольно тяжко. Стас подкинул ему идею, что всё это управление знаниями — оно типа не даёт возможность снизить затраты на 1-2 % прямо сейчас, а наоборот само создаёт некоторые затраты, но направленные на страховку от того, чтобы в будущем не произошёл Большой Пипец — например, чтобы новая внезапная технология не похоронила всю компанию… Пообсуждали… Юрий сказал, что по его ощущению — это да, биг боссам донести реально, foresight и всё такое :) я ещё порассказал об SMW — о том, что там, например даже отрицания не было (и мы его допилили), то есть даже язык запросов неполный был… о том, что используется она не для семантик веба, который нафиг уже не модный и никому не нужен, а для того, чтобы на вики делать объектную модель :) а оно для этого не всегда удобно… ну и так далее.

=== Программно-Конфигурируемые Сети и Виртуализация сетевых сервисов — новый вызов для разработчиков ПО — Руслан Смелянский, Московский государственный университет ===

Про OpenFlow и т. п. Был в самом конце. Я так понял, что тут тоже было достаточно много общих слов и в чём конкретно «вызовы», не вполне понятно — об этом задавали вопрос и я согласен — ну появятся ПКС, один раз алгоритмы под них напишут и расслабятся люди. Разве что придумают много-много каких-то разных и хитрых применений. Но в принципе не замечено ничего такого, что требует именно ПКС. Все эти поганые зонды типа DPI и без него нормально работают, ага (увы).

=== Суперкомпьютерное программирование — третья грамотность — Игорь Одинцов, Intel ===

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

Разве что забавно — он сказал, что Ломоносов, который на ВМК МГУ стоит и пол-парковки своими чиллерами занимает так, что не пройдёшь, грузят в основном в сессию, типа студенты всякую фигню начинают считать :)

=== «Блиц-сессия» ===

Блиц потому, что доклады по 15-20 минут.

==== Абстрактный синтаксический анализ на основе GLR-алгоритма — Семён Григорьев, СПбГУ ====

Идея — заюзать [[rupedia:GLR-парсер|GLR]]-алгоритм разбора для проверки/автокомплита/трансляции кусков динамически генерируемого кода, встроенных в код на другом языке (например, SQL-литералов). ''Гусары, молчать! ORM это не решается, так как всё равно тормозной отстой и почти всегда приводит к идиотизмам в духе <tt>foreach(rows) { select where id=rows[i].id }</tt> — прим. меня ;-)''

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

Что характерно, этот подход уже применяется в опенсорсных реализациях:
* [http://alvor.googlecode.com/ Alvor] — плагин-проверялка SQL для IDE Eclipse
* [http://www.brics.dk/JSA/ Java String Analyzer] — само по себе ничего не делает, только строит грамматики для вычисляемых строковых выражений
* [http://www.score.is.tsukuba.ac.jp/~minamide/phpsa/ PHP String Analyzer] — то же для PHP

Честно говоря, как человек, оставивший IDE в возрасте лет 15, слабо понимаю, нахрена это вообще надо. Функции, генерящие всякий SQL — они маленькие и элементарно проверяются глазами. Ну а если вы этого не можете делать, то по-моему лучше вообще не программировать.

==== Static Analysis for Dynamic Updates — Евгений Кабанов, ZeroTurnaround ====

Статик анализис — тут это не анализ путей выполнения программы, а только анализ иерархии типов и добавленных/удалённых методов, чтобы иметь возможность их подменять на лету в жирных живых java процессах (300 мб и больше).

==== Моделирование WAN-сетей для исследования вредоносного ПО — Виталий Антоненко, Центр прикладных исследований компьютерных сетей (ЦПИКС) ====

Чувак поигрался с сетевыми неймспейсами линукса — засовывал в них по процессу, представляющему из себя «узел сети» и помоделировал на них «распространение вредоносного ПО». «Распространение» по его логике — это когда хост смотрит на пришедший пакет и сразу знает «ой, там вирус, я уже заразился!» :D таким макаром на паре серверов можно «моделировать» десятки тысяч «узлов». На выходе получается карта распространения вредоносного ПО. Один маленький нюанс — нахрена для этого пускать процессы, вообще непонятно, потому что если у нас заражение известно заранее, то карту распространения легко смоделировать тупо математически.

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

==== Разработка AutoCAD приложения для расчета заземления и молниезащиты электрических подстанций — Дмитрий Шишигин, Вологодский государственный технический университет ====

На SECR занесло студентика, который в духе защиты курсовой (в бесполезном таком духе) рассказывал про то, что написал плагинчик, рассчитывающий в AutoCAD «канонические экраны [защиты от молний] — сферические, цилиндрические <s>и офигические</s>».

Абсолютно бесполезный доклад.

==== Автоматизация поддержки репозиториев ПО для Linux — Денис Силаков, РОСА ====

Денис из РОСЫ рассказывал об их автоматизированном инструменте исправления типичных примитивных ошибок, возникающих при сборке новых версий программы в rpm пакет по старой спеке (чтобы руками спеку не обновлять и чтобы мантейнеры выполняли меньше monkey-job).

Для отслеживания новых версий юзают http://upstream-tracker.org/, а про сам инструмент можно почитать в их Wiki — http://wiki.rosalab.ru/ru/index.php/Updates_builder

== День 2 ==

=== LLVM и Clang — новейшие компиляторы и инструменты программиста — Крис Латтнер, LLVM ===

Товарисч на самом деле из Apple, говорил хвалебные речи в адрес шланга… Мне что в нём понравилось — по ощущению какое-то чистейшее произношение, по-моему, ни одного слова не было, которого бы я не понял. А с докладом он, видимо, особо не заморачивался — например, тест производительности, который приводил, явно взял с [http://phoronix.com/ похороникса].

Вкратце, LLVM — «модульная платформа для компиляторов». LLVM означает (по крайней мере изначально означало) Low-Level Virtual Machine — то есть некий промежуточный машинный язык, в который можно компилировать языки программирования и который сам может компилироваться уже в реальные машинные языки, с применением глубоких оптимизаций. Соответственно, потенциально писать компиляторы легче, потому что:
* Компилятор одного и того же языка не нужно заново писать для всех новых аппаратных платформ
* Оптимизации не нужно заново писать для новых языков программирования
Также LLVM умеет JIT-компиляцию, которая несколько медленная, но зато опять-таки применяет все те же оптимизации кода.

Clang (шланг) — это LLVM’ный компилятор языков C, C++ и Objective C. Главные фишки — более быстрая компиляция (до 2 раз, кажется) и максимально дружелюбные сообщения об ошибках, в том числе в безумном ++ном коде с миллионом шаблонов, и сишном с многоэтажными макросами.

Архитектур по факту LLVM поддерживает пока что СИЛЬНО меньше, чем gcc.

Пилится всё это весьма активно Apple’ом, Intel’ом и прочими. До какого-то момента gcc его сильно делал по скорости результирующего кода, сейчас он вроде начал (иногда?) его обгонять. FreeBSD недавно выбрало LLVM в качестве основного компилятора, правда, по дико тупой причине — только из-за того, что он не GPL.

Минус (потенциальный) у LLVM только один — это НЕ-копилефт (пермиссивная) лицензия, что теоретически может привести к распространению закрытых плагинов и неюзабельности его в свободной среде. Этого, вроде-бы, пока не происходит, но гарантии никакой нет, особенно учитывая, что проект создан Apple. Но, например, закрытое ПО на его основе уже есть (XCode), и есть планы по обеспечению его использования в выжал студии.

Но в любом случае, ещё один свободный компилятор лишним не будет.

=== Осторожно: патентные тролли! Теория, практика и актуальные примеры — Юрий Бардмессер, Bardmesser Law Group ===

Рассказ про патентных троллей — в основном в США, потому что там эта проблема из-за разрешённости патентов на ПО стоит наиболее остро (сейчас не меньше 60 % исков по ПО — троллевые).

Определение тролля — это компания, которая занимается не реальной деятельностью, а монетизацией патентных прав. Они почти всегда предпочитают договориться, хотя и не стесняются подавать в суд. Бизнес-модель простая — если затраты на троллинг меньше, чем оценка выигрыша (вероятность успеха * продажи жертв * насчитанный ущерб), то ТРОЛЛИМ! Патенты либо тупо придумываются, либо скупаются, реальная деятельность компанией либо (обычно) вообще не ведётся, либо бывает, что велась когда-то, но кончилась.

А дальше рассказ о том, как они от всего этого отмазываются. Что собственно и доказывает дурь патентной системы — если даже предположить пример, который бы работал в благих целях, юристы всё равно занимаются тем, что внимательно смотрят claim’ы и придумывают отмазки, и зачастую у них это удаётся:
* Юрисдикция: ГДЕ происходят «нарушения»? Какой штат, а может — страна? А может, нас вообще там нет, и никогда не было? Сколько мы там продали и продавали ли вообще? А нарушение — на сервере или на клиенте? А где стоят сервера?
* Что конкретно написано в формуле изобретения? Метод, система, и то, и то? Нарушаем напрямую или косвенно? Есть ли режимы работы, которые не нарушают? Что конкретно продаётся — сервис, диск?
* Какой срок действия патента? Что написано в переписке с патентным офисом? Есть ли родственные патенты?
* Есть ли prior art, допустим — если вы это трактуете вот так, то вот в одна тысяча хз каком году это делали вот те ребята, и тогда оно тоже должно трактоваться так же.

А дальше на основе найденного выбираются стратегии действия:
* Игнор, рисковать получить иск.
* Написать ответ, в котором разъяснить что их позиции слабы — скорее всего отвянут. Но «извините, мы были неправы» — не скажут никогда.
* Вступить в переговоры, например, чтобы потянуть время — тролли обычно согласны почти на любые суммы денег, и можно долго торговаться. И пока ты торгуешься и они думают, что есть шанс стрясти бабло, в суд они не подадут.
* Подать петицию на пересмотр их патента (post-grant review) — дорого, но может получиться. Google так сделал с Lodsys, и последний пока проигрывает.
* Обойти патент в реализации.

=== («а теперь глазами тролля…») Патентование интерфейса мобильного приложения — Михаил Радченко, SoftPatent ===

Вот уж действительно, это называется «а теперь глазами тролля…» — когда человек говорит, что идея может стоить X денег, это определённо патентный тролль. Гопота! «Кто первый встал, того и тапки».

Основная идея: всё, что можно придумать, можно запатентовать, если оно не запатентовано ранее. Например, в области мобильных технологий в первую очередь надо смотреть в 364-страничный Steve Jobs Patent, эти тролли запатентовали уже почти всё, что можно. Ещё можно юзать поисковики по патентам. Если запатентовать нельзя — есть патентные юристы, которые придумают, как, и станет можно. Аналогично — способ / устройство / и то и другое.

=== Организация продаж своего продукта онлайн: путеводитель мимо грабель — Олеся Чедлеева, Avangate B.V. ===

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

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

=== KPI разработчика — Леди Ада (Евгения Фирсова), Яндекс. Деньги ===

Слушал кусочками, ибо там было не продохнуть. Любят все эту говорящую Леди Аду, хотя в этот раз она, кажется, причёску сменила и на собственно Леди Аду стала похоже меньше :)

Но я бы к ней работать не пошёл :-D то у них XSLT, то разработчики уходят (потому что XSLT?), то вот теперь тем кто остался, метрики придумывают (доклад был об этом) :) ну то есть хз, может это и нормально. Критерии влияют на премию, измеряется, типа, только то, что выходит за пределы того, что и так должно быть в норме. Измеряется не по шкале, а бинарно (например, «делал code review»), более того — иногда измеряется «дифференциально», например, «раньше не делал code review, а тут вдруг стал». Критерии разработчикам известны, а коэффициенты, по которым в итоге считается премия — нет. Плюс всё это время от времени меняется.

Слушал я этот доклад неактивно, так что подробнее можно почитать в других отчётах.

=== Опыт использования технологии KDB+/Q в Дойче Банке — Андрей Бабанин, Deutsche Bank ===

Я уже как-то раз видел это буквосочетание и поэтому мне было очень интересно, что же это за хрень такая — KDB+/Q. Поэтому пошёл слушать этот доклад. Не ошибся, доклад был хороший. По содержанию — обзор сей технологии.

В итоге смысл такой:
* KDB+ — это дико оптимизированная на всех уровнях (например, код ядра маленький и легко влезает в кэш процессора) специфическая база данных для хранения '''огромных''' объёмов упорядоченных данных (миллиарды записей в день — даже 32-битное целое переполнится), таких, как, например, биржевые котировки.
* Q — это тоже очень странный (специфический) интерпретируемый язык для, собственно, работы с этими данными. Состоит из странного синтаксиса, теории множеств и смеси императивного, функционального и SQL-подобного кода. В общем, не похож ни на что. Но когда вкуришь — вроде, разрабатывать на нём сильно быстрее, чем то же самое на чём-то другом. Есть отладчик, который написали они сами.
* Ещё пример оптимизации — строки обычно складываются в таблицу и индексируются как числа.
* KDB+ во многом завязана на поточную обработку данных (конвейеры — пишущие, читающие), потому что это и есть наиболее оптимальный вариант и именно он требуется большинству потребителей (сверхбыстрая торговля, алгоритмическая торговля). Кластеризацию — поддерживает.
* Естественно, требует быстрого хранилища — сначала они применяли массивы через Fiber Channel, потом сервера, потом обратно FC…
* Цифры адские! 30 миллиардов записей в день, 2.5 миллиона активных подписок, 2 петабайта места, 3000 активных процессов, > 200 серверов, 70 миллионов запросов в день, несколько тысяч внутренних пользователей.

Вот уж реально Big Data :)

=== Performance Test Driven Development — Алексей Рагозин, Deutsche Bank ===

Докладчик жжот — рассказал 1 доклад на SECR в пятницу 25-го и потом ещё 2 на Highload во вторник 29-го. И все, что характерно, интересные.

Конкретно этот доклад был про очередной *DD, на этот раз — Performance-Test DD. Типа, есть такие приложения, в которых основное требование к системе — это производительность. И главное, что со временем жизни системы цена ошибки очень сильно растёт… а объём тестов, наоборот, растёт медленно.

В итоге подход — пишем код как-нибудь (без преждевременной оптимизации на основе умозрительных заключений!), пишем нагрузочный тест, тестируем, выявляем и исправляем узкие места. Тестируем непрерывно, на всём протяжении жизни ПО, при добавлении функционала добавляем нужные бенчмарки и изолированные тесты.

Проблемы здесь такие: нагрузочные тесты, как правило, весьма тяжёлые и зачастую распределённые, требуют желательно идентичного тестового окружения (актуальной БД…), требуют дополнительного оборудования (столько же, сколько на бою, всё равно никогда не бывает, так что экстраполируют), плюс изначально конкретных требований по нагрузке обычно нет (должно быть «быстро» и всё тут), так что их ещё приходится формализовать.

Варианта того, как всё это сделать, он представляет себе два — ssh/bash/логи/анализ на Excel/R, либо второй вариант — писать всё на Java. Они делают второе (они же Java разработчики), хотя и приходится изобретать велосипеды. Когда-то делали первое, и когда перешли, то у них наконец-то куски тестов стали реюзабельными.

Ещё сказал про то, что надо обращать внимание на корректность измерений — например:
* Неправильно измерять просто скорость отдачи ответа. Так как в какой-то момент сервис может начать отдавать 503, и будет делать это очень быстро.
* Например, есть тест, который делает 10000 запросов в 10 потоков. Но в какой-то момент сервер затупил и все 10 потоков висели по 10 секунд. В итоге ''процент'' неудачных запросов будет очень низкий, но это неправильно — пока сервер тупил, 10 потоков ждали и новые запросы не отправляли. В реальности же запросы бы продолжались, и неудачных было бы гораздо больше.

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

Ссылки: java gridkit (github, google code), XChart и его блог — http://blog.ragozin.info/.

=== Как совместить жесткий график выпуска релизов и качественное тестирование? — Алексей Надененко, Сбербанк технологии, Минск ===

А вот этот доклад уже получился сильно более унылым. Немолодой дядечка из Сбер-технологий рассказывал про то, как они у себя пишут ГУЁвые автотесты для систем на Java и MFC, у которых релизы выходят каждые 6 недель.

Не до конца понял — то ли они сами написали систему тестирования полностью (AWN), то ли тоже сами, но на основе чего-то готового, кажется, от HP.

Главный нюанс в том, что у них эти автотесты очень жирные и их должен писать автоматизатор вместе с человеком с хорошим знанием предметной области, так как она дико развесистая и научить ей разработчиков/автоматизаторов сложно. Я так понял, что сначала у них было чисто ручное тестирование, а теперь они заставили ручных тестеров писать автотесты, и всё стало, типа, хорошо — затраты в среднем около 2х минут на шаг теста, то есть минимум 4 теста в день один разработчик пишет (да-да, тесты по 200—300 шагов).

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

=== Миграция проекта на PHP глазами .Net разработчика — Михаил Ершов, First Line Software ===

Ох ржака будет, думал я, но нет, всё оказалось довольно просто, прозаично и успешно. Причина перехода тоже банальная — попросил заказчик. С одной стороны несколько странное требование, с другой — ну и хорошо, оно-то теперь на FreeBSD будет запускаться, а не под виндовым сервером. Так что ОК ]:->

В целом, чтобы люди совсем не обалдели от такого поворота событий — он сначала сделал маленький прототипчик, показывающий, что на PHP в принципе можно писать фактически в той же идеологии, что и на .Net: ну, нет linq, ну и хрен с ним ''(правильно, поддерживаю — прим. меня)'', ну doctrine вместо entity framework, ну и пофиг… Ну Yii вместо аспшного MVC (Yii потому что у заказчика уже были на нём системы), ну и тоже туда же… Ну MySQL, а не MSSQL (чо там, одна буква поменялась в названии :D)… Фронт вообще остался неизменным, потому что изначально был на тотальном JS — HTML части у их приложения и так почти не было.

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

Из интересного:
* На Doctrine перешли легко, проблем не испытывали вообще.
* С Yii похуже, ибо он как и прочие PHP фреймворки, довольно жёсткий ''(и непонятно, зачем вообще нужен, хотя конкретно для бывших шарпистов — наверное понятно, зачем, типа для удобства схождения разных культур в одну точку — прим. меня)''.
* На C# писали юнит-тесты. Перешли на PHP и сначала продолжили писать юнит-тесты. Первый-второй спринт, вроде всё ОК, юнит-тесты проходят… начали склеивать модули воедино — ни хрена не работает, всё отваливается! Выкинули нафиг юнит-тесты и заменили на интеграционные, и всё сразу стало хорошо. Возможно, это в целом интересное общее наблюдение: чем более язык динамический, тем хуже вам подходит именно юнит-тестирование.

-----

После этого доклада ушёл домой, ибо вроде ничего особо интересного более не предвиделось, а спать хотелось жестоко.
{{replicate-from-custiswiki-to-lib}}