Содержание

День 1

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

Что у них там за «встраиваемые» системы на x86 и x86-64, я не до конца понял, но сам подход довольно простой и понятный. Допустим, мы:

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

Проект выложен на github — elfperf.

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

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

008 bodrenko.pdf

И у чувака реальные идеи — ух ты! На этом можно построить децентрализованную социальную сеть! Ух ты! На этом можно сделать децентрализованный 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 и том, почему оно вынуждено медленно развиваться. Были различные примеры, но общий смысл такой:

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

Прикольная такая девочка рассказывала про язык Kotlin (мало) и про примеры из книжки Java Puzzlers (больше) — то есть некие примеры кода, выполняющиеся неочевидно. Местами притянутые за уши:

Я бы не назвал это недостатками Java. Не на PHP, в конце-то концов, пишете, чтобы это всё очевидным было ))

История Kotlin'а, видимо, в том, что пришёл к ним RedHat со своим 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-алгоритма — Семён Григорьев, СПбГУ

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

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

Что характерно, этот подход уже применяется в опенсорсных реализациях:

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

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

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

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

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

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

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

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

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

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

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

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

День 2

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

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

Вкратце, 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’ы и придумывают отмазки, и зачастую у них это удаётся:

А дальше на основе найденного выбираются стратегии действия:

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

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

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

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

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

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

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

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

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

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

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

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

В итоге смысл такой:

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

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

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

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

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

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

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

Ещё сказал про то, что надо обращать внимание на корректность измерений — например:

Их результаты применения 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 части у их приложения и так почти не было.

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

Из интересного:


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


Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «SECR-2013: Отчёт Виталия Филиппова»