;Автор(ы): Гласс Р.
;Страница книги на сайте издательства: http://www.symbol.ru/alphabet/666333.html

http://www.books.ru/img/666333.jpg

== Рецензии ==
=== Наши рецензии ===
==== Рецензия Павла Трушина ====

{{Блог:Павел Трушин/Роберт Гласс. Креативное программирование 2.0.}}

=== Рецензии в рунете ===
* http://www.it4business.ru/lib/2003/

[[Категория:Библиотека]]
[[Категория:Рецензии на книги]]

Deadline (Демарко)

2014-02-26T15:28:21Z

;Автор:Том ДеМарко (он же ''Том Де Марко'')
;Название: «Deadline. Роман об управлении проектами» (''The Deadline: A Novel About Project Management'''''')
;Читать: http://www.litru.ru/?book=139

== Рецензия ([[Участник:StasFomin|Стас Фомин]]) ==
В блогосфере роман очень популярен. Внятных рецензий правда мало или нет, но очень много односложных рекомендаций вида «must read», или «читал, много думал».

Соответственно, такие рекомендации перед чтением настроили на достаточно большие ожидания.
Плюс, тут же автор — тот самый [[RuPedia:Tom_DeMarco|Том Демарко]], который уже полвека в индустрии, член всяких IEEE/ACM/…, отец метрик в разработке, автор бессмертного заклинания «тем что нельзя измерить, нельзя управлять»<ref>От которого, он правда [http://bishop-it.ru/2009/07/softwareengineeringisdead/ недавно отказался].</ref>, плюс изложение не в виде сухой академической статьи, в виде убогого шестистраничного двухколоночного PDFа<ref>стандарт для всяких около IEEEшных статей</ref>, а в виде увлекательного динамичного романа, даже с любовной линией.

{{note}} Признаться, и меня часто посещали мысли написать производственный роман о современной разработке, с любовным треугольником (менеджер → тестировщица → суперпрограммист ← сисадмин …), с напряжением, бегом по коридору при сигналах о сломанных в [[Continuous Integration|CI]] сборках, мощному давлением от бизнесов на менеджмент, менеджеров на разработчиков, разработчиков на тестировщиков и аналитиков, аналитиков на юзабилистов, плюс вокруг возня HR-ов с их мотивацией… Конфликты социотипов, проблемы технологий и методологий (SCRUM vs. Dilbert-style, XP vs. Waterfall), важность правильных инструментов… Ну и название, лучше чем «ДедЛайн» тоже не придумать.

С таким ожиданиями я начал чтение, и в процессе все более и более мрачнел.

Судя по этому роману, автор НИЧЕГО не понимал в процессе разработки софта.

А такой роман может за пару недель написать очень слабая команда литературных негров, или слабенький автор из тусовки русского фендома<ref>Тусовка авторов русской фантастики</ref>. Без малейшего понимания, что такое программирование, тестирование, какие вообще бывают технологии, архитектуры и вообще виды разработки, что такое пользователь и какой ему нужен интерфейс, и в чем смысл эволюции требований и управления ими, где народ ищет серебряную пулю и откуда должен появиться «Agile Manifesto». Без ПОНЯТИЯ! Ни в одной области!

Кратко перескажу свое впечатление, которое сложилось после прочтения четверти, и дальше только укреплялось.

ГГ (главный герой), работавший менеджером в какой-то конторе (похоже, даже не софтовой ни разу, но возможно он руководил таки программистами) был уволен (и похоже, что справедливо).

ГГ — лузер. Ему где-то сороковник, у него нет (и не было) семьи, друзей, нормальной собственности, увлечений — только кот.
ГГ совершенно не разбирается в технологиях разработки (ни в одной области).
Ни в архитектуре, ни в аналитике, ни юзабилити, ни в чем.
В гуманитарных областях — психология, общение, конфликты — тоже ноль (хотя считает, что у него «большое сердце»).
Да вообще, он совершенно неэрудирован — элементарные школьные факты были для него новостью. У него географический кретинизм.
Чистейший роговолосый шеф из Dilbertа, только более безобидный и к тому же уволенный.

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

{{caution}} Ближайшие культурные коды — [[RuPedia:Бразилия_(фильм)|концовка фильма «Бразилия»]], роман «Ubik» от [[RuPedia:Дик, Филип Киндред|Филиппа Дика]].

----
<center><small>начало домыслов</small></center>
----
Уволенный ГГ спивается, теряет остатки денег, и похоже бомжует, побираясь с тележкой из супермаркета.
Перестав ценить жизнь, он потерял полностью осторожность и был сбит автобусом (возможны варианты).
Далее главный герой умирает, и распадающийся мозг рожает ему картину, что …
----
<center><small>пошел роман</small></center>
----

…Им заинтересовалось мощное тоталитарное государство (гибрид СССР, Албании, Болгарии, Венгрии — фантазия почище «Казахстана от Бората» — учитывая необразованность ГГ, была рождена странная географическая химера). И прислало за ним красавицу-шпионку, соблазняющую его и отвозящую в эту страну ОЗ<ref>Советский читатель наверняка помнит адаптацию «Волшебник Изумрудного Города»</ref>.
Он смело идет <s>по дороге из желтого кирпича</s> живописным аллеям с пальмами, прямо в столицу к Великому и Ужасному Гудвину, и оказывается (surprise!), что это Старый Добрый Билл Гейтс купил себе Страну с Потрохами (и огромным числом дешевых высококвалифицированных программистов), и вот единственное, что ему не хватало для счастья — это ГГ в качестве топ-менеджера.

У него полный карт-бланш — он может <s>вызывать духов</s> заказывать любых людей и ресурсы, ему предлагают сыграть в увлекательную RPG-стратегию, где у него будет куча юнитов — программистов и менеджеров, которые будут что-то там программировать. Что — его совершенно не волнует, он этого даже не понимает. Официальная легенда:
# Копируем известные программы, фигли там думать, трясти надо.
# …
# PROFIT!!!!!

Его задача, как геймера — чисто расставлять юниты, и наблюдать, как они шебуршатся. Более того — юниты ему выданы с запасом, он может устраивать эксперимент — запускать в одну миссию несколько команд, и расслабившись смотреть — кто эффективней добежит до цели.

От него не требуется ничего.

Он прекрасно проводит время — если ему интересно пообщаться с выдающимися людьми — ему их доставляют (ну или он срочно летит на личном самолете в другую страну, чтобы непринужденной обстановке в пабе перекинуться парой словечек с каким-нибудь экспертом). Иногда «вызывает Оракула» по email (насколько я понял, намек на Ларри Элиссона).
У него появляются женщины — отдельно красивая — ''wamp-style'' шпионка, отдельно высокая (бомжующая ПМ эксперт/баскетболистка — явно трансляция своего собственного бомжевания).
Время от времени, у него возникают легкие конфликты, но каждый раз он доходит до Босса этого уровня, после чего Босс легко сдается и становится его сторонником.
Единственная проблема ГГ — какой-то злобный роголовосый финменеджер, которого почему-то случайно поставили над ним, и который давил и смешно угрожал ГГ. И то, эту проблему ГГ не решил, она внезапно решилась методом «deux from machine».

Ничего полезного ГГ не сделал. Максимум — не сильно мешал людям.
В процессе этого Великого Пути, автора посещают озарения и он записывает открывшиеся ему Великие Принципы Программного Менеджмента.
Сборник этих рецептов (все как на подбор от Капитана Очевидность), можно не читая роман найти [http://www.slideshare.net/galushko/deadline-2120656 тут]. Эти принципы никак не приоретизированы, то есть если рассматривать их как ограничения — «допустимого решения нет»<ref>Хотя я одобряю основной мотив этих принципов — нет «микроменеджменту», нет надуманным ограничениям, больше доверия. и т.п.</ref>.

Концовка вообще из серии «[http://lurkmore.ru/%D0%95%D0%B1%D0%B0%D0%BD%D1%8B%D0%B9_%D1%81%D1%82%D1%8B%D0%B4 полный позор]» — все само как-то счастливо закончилось и ему в подарок случайно падает королевство с принцессой (купленная Болгария с женщиной-wamp). В общем, «Бразилия» в полный рост, воспринимать это иначе никак не возможно.

В общем, я не рекомендую это чтение.
Если хочется почитать какой-нибудь бизнес-роман о разработке, бизнесе, консалтинге — то лучше наверное «Цель-3» от Голдратта (кстати, написан примерно в то же время). Хотя там разработки совсем мало, но все гораздо живей и жизненней. Там только концовка подкачала (слишком уж шоколадно все).

Ну и может действительно надо написать свой собственный Великий Роман О ---.

P.S. Кстати, если хочется чего-то художественного о ДедЛайне, как это выглядит на самом деле, то лучше всего, ИМХО,
это удалось у [[RuPedia:Кон,_Сатоси|Сатоси Кона]], в аниме-сериале «[[RuPedia:Агент_Паранойи|Агент_Паранойи]]», особенно в 10-й серии. Режиссер действительно видел и познал настоящий Ужас ДедЛайна, вероятно поэтому и умер в 46 лет.

[[File:The project team (cartoontester).jpg|400px|center]]

== Ссылки ==

* http://www.litru.ru/?book=139
* [http://www.slideshare.net/galushko/deadline-2120656 Конспект «прописных истин» из романа]

== Примечания ==
<references/>

{{replicate-from-custiswiki-to-lib}}
[[Категория:Рецензии на книги]]

2014-02-25T12:27:15Z

VitaliyFilippov:

Статьи сотрудников компании, опубликованные в бумажных и электронных СМИ.
<div style="display:none">
</div>

[[Категория:CustisWikiToLib]]

Файл:Logo profsoux.45a753e62c3f.png

2014-02-25T11:11:11Z

VitaliyFilippov: Массовая правка: удаление Категория:Открытые тесты

Категория:CRN (Публикации)

2014-01-14T13:57:47Z

VitaliyFilippov: VitaliyFilippov переименовал страницу Категория:CRM (Публикации) в Категория:CRN (Публикации) без оставления перенаправления

Статьи сотрудников компании, опубликованные в [http://www.crn.ru/ CRN/RE] («ИТ-бизнес»).

[[Категория: По СМИ (статьи сотрудников)]]
[[Категория: CustisWikiToLib]]

Шаблон:Bug

2013-11-12T21:50:34Z

VitaliyFilippov:

<noinclude>
Ссылка на баг в Bugzilla. Использовать так:
<pre>
{{Bug|Номер бага|(опционально) заголовок}}
</pre>
-----

См. также:
* [[:Template:Attachment|Ссылка на вложение]]
* [[:Template:BugInfo|Маленький информер по багу]]
* [[:Template:BugInformer|Большой информер по багу]]
* [[:Template:Bz-embed|Встраивание списка багов из Bugzilla (с учётом прав доступа)]]

{{replicate-from-custiswiki-to-all}}</noinclude><includeonly>[http://bugs.office.custis.ru/bugs/show_bug.cgi?id={{{1|}}} {{#if:{{{2|}}}|{{{2}}}|Bug:{{{1|}}}}}]</includeonly>

Highload-2013: Отчёт Виталия Филиппова

2013-11-11T22:04:47Z

VitaliyFilippov: /* Как рассуждать о производительности хранилищ баз данных / Mark Callaghan (Facebook) */

Информация о конференции, организация:
* Highload-2013, «Конференция разработчиков высоконагруженных систем». Проходила в очередной раз в конференц-зале гостиницы Radisson на м. Киевская.
* Самая первая и самая распиаренная из Бунинских конференция. Билет стоил аж 21000, плюс ещё были отдельные «учебный» и «VIP» дни (на которых я, естественно, не был).
* Хайлоад начался с хайлоад-очереди на регистрацию. В разные обработчики она, правда, почему-то была разная (очередь с приоритетами, где каждый оценивает свой приоритет сам?), и встав в другую, ты терял времени на порядок-два меньше.
* Вайфай нормально не работал, до отваливания в нём удавалось посидеть минут 5.
* С едой всё было более-менее в порядке — кофе-чай всё время, 2 перерыва, каждый из которых для части людей — кофе-брейк с плюшками, а для другой части — обед (балансировали нагрузку талонами). Небольшие трудности с обедом — народу много, места сесть не хватало, часть еды быстро кончалась. Но голодным там всё равно никто не оставался.
* Дали большую кучу раздаточных материалов — книжку с частью докладов с прошлой конференции, диск, рекламу, 3 блокнота… Полезный элемент — в этом году вместо ахтунг-стайл красной авоськи дали сумку для ноутбука, в которую и был упакован весь выданный crap.

Общая атмосфера:
* Атмосфера в целом какая-то «коммерческая», видно, что компании туда ходят уже по накатанной для регулярного пиара.
* Докладчики (компании) — всё одни и те же лица, посетители — наоборот, похоже, исключительно новые. Правильно Стас выразился — это как с борделем, нормальный человек ходит туда 1 раз в жизни; это ты ходишь постоянно, и тебя уже ничем не удивишь.
* Девушек на конференции не было почти совсем, ''«радостную»'' программистскую тусовку разбавить было некем.
* Многие зарубежные «звёзды», как обычно, лили воду, содержательной части в докладах от FB, например, процентов 10.
* Было много докладов от одних и тех же компаний — может это и не плохо, но по-моему свидетельствует о неком спаде доступного разнообразия (или слабом подборе). Ну и badoo (которое сайт знакомств и вообще непонятно, почему в 21 веке имеет столько юзеров) уже слушать как-то неинтересно. Примеры повторов:
*: По 3 доклада от Badoo и 2ГИС; по 2 от Одноклассников, Facebook, Monty Program AB, Qrator/HLL, mail.ru, HashiCorp. К этим в общем-то претензий нет, понятно, что вторых таких же чуваков, как Qrator, найти сложно.

== День 1 ==

=== Экосистема Сочи 2014. Космос как предчувствие / Михаил Чеканов (Оргкомитет Сочи 2014), Ольга Куликова (Articul Media) ===

На докладе не был, отмечаю потому, что из интересного там было очевидное :-) сайт сначала сделали на БИТРИКСЕ, но потом всё-таки поняли, что с этого нереального ужоса надо сваливать. И таки свалили — переписали всё сами и довольны.

=== (незачёт) Как поставить миграцию баз данных на поток / Илья Космодемьянский, Роман Друзягин ===

Чуваки пытались рассказывать доклад вдвоём попеременно. Это хороший формат выступления, но слайды у них тем не менее были совершенно жуткие, да и сам рассказ таил в себе больше воды.

* Из содержательного — миграции нужно всегда отрабатывать и нужно всегда иметь план «Б», то есть иметь возможность быстро откатиться назад, если миграция БД не удастся.
* Из смешного — если будете покупать IBM DB2 — скажите, что мигрируете с оракла, они вам сделают скидку :-D

=== Полнотекстовый поиск в Почте Mail.Ru / Дмитрий Калугин-Балашов ===

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

Из смешного — их спросили, неужели вам не подошло ни одно из готовых решений, зачем вы написали свой поиск? Они ответили — потому что есть ресурсы! («because we can!»)

=== Своевременная оптимизация / Carlos Bueno (Facebook) ===

Доклад рассказан неплохо, хоть содержательность и хромает. В основном было много общих слов.

Чувак из фейсбука перевёл слайды на русский язык (на каждом слайде фраза была и по-английски, и по-русски)… но, видимо, перевёл google translate’ом, потому что были такие перлы:
* Optimisation: don’t ever do it! (* except sometimes).<br /> {{mag|Оптимизация: никогда не делайте его! (* кроме иногда)}}
* Distrust numbers. Especially your own.<br />{{mag|Числа недоверия. Особенно ваше собственное.}}

Ещё из смешного — доклад он начал со слов:
* I work at Facebook, it’s a V Kontakte in America. I work at facebook performance team…
И тут кто-то спросил (было в твиттере, было ли в реале — не уверен) :D
* OK, so when will you begin? [working on facebook performance]

А дальше общие размышления:
* Проблема должна быть проверяемой, если она непроверяемая — то это не проблема…
* Два пути решения — повысить производительность либо сдвинуть нагрузку (которой мы можем управлять — обсчёт какой-нибудь и т. п.)
* Оптимизация это больше не про computer science, а про science science; вообще вся разработка — типа, умение «playing computer in your head». Однако: who is better than you in playing computer? the fucking computer! (не помню, к чему это — видимо к тому, что можно пытаться не придумать, а симулировать нагрузку)
* Опять про корректность измерений: «I feel really stupid saying about this, but directly measure what you optimize»
* Говорит, мы в один день проснулись, а Facebook на 10 % быстрее. Он такой — я говорю начальнику, смотри, круто! А он — ты зря радуешься, если много ситуаций, в которых система может ВНЕЗАПНО стать на 10 % быстрее, и лишь малая часть из них — хорошие :-)

=== Распространение систем на Scala благодаря Finagle / Julio Capote (Twitter) ===

Товарищ из Twitter’а просто рассказывал какая хорошая scala, и какая у них есть под неё библиотека RPC [https://github.com/twitter/finagle Finagle], я как-то выпал из контекста.

=== Опыт переезда соцсети Livestreet с PHP/MySQL на NodeJS/Redis/Lua / Дмитрий Дегтярев (Хабикаса) ===

Странный доклад… У чуваков был стандартный сайтик на стандартной отстойной блого-социально-подобной CMS’ке Livestreet. Данных там мало, всего несколько тысяч постов. И его вместо того, чтобы просто переписать, переписали на сильно извращённый вариант:
* В качестве БД — Redis
* В качестве логики — хранимые процедуры на Lua внутри Redis’а O_O
* Вместо классической схемы сделали сайт почти целиком на AJAX
* Генерация маленьких HTML страничек для возможности индексации осталась в Node.js

Сразу отметим: запихивать толстые хранимые процедуры в redis == на корню убивать его производительность, он же однопоточный мультиплексирующий и все команды должны выполняться быстро.

Типа, кэш мы инвалидировать не хотим, давайте сразу всё хранить в кэше… :-) хотя Redis — это вообще-то не кэш, а БД. Просто когда он вылезает за размеры памяти, работает весьма печально, а пока не вылезает, всё и так в памяти и по скорости он таки да, почти как memcache. Ещё в Redis’е есть два понятия — embed и sideload, типа при загрузке связанные сущности могут либо подгружаться по ID отдельно, либо встраиваться прямо в родительскую сущность. Первое, очевидно, меньше занимает места, второе — делает меньше запросов.

Потом чувак сделал мегасерьёзный «бенчмарк» и расстроился, потому что redis с его подходом не получился быстрее MySQL! Бенчмарк заключался в измерении скорости загрузки ВСЕХ ПОСТОВ из базы одним запросом. Офигеть бенчмарк. «На мой взгляд редис должен быть в 10 раз быстрее… но сейчас это не так, или я тест сделать ниасилил подходящий даже» :-)

Ещё в моих заметках отмечено «бред про многопоточный редис», но что это значит, я уже забыл :-)

Потом он полез профилировать redis, и обнаружил, что 50 % времени тот проводит в string2ll (конвертации строки в число). Интересно.

Но в общем и целом, буханка, троллейбус. Badoo’шники того же мнения, их чувак выразился «то есть вы решили пересесть с лёгких наркотиков на тяжёлые».

=== Дизайн движка метапоиска aviasales / Борис Каплуновский (Aviasales) ===

Интересный доклад от Aviasales («метапоисковика» авиабилетов), докладчик сначала было испугался, что его, как и предыдущего, сейчас запинают насмерть ребята из Badoo — он сказал, «я наверное тоже по вашему мнению пересел на тяжёлые наркотики», но на самом деле — нет, и архитектура, и доклад вполне адекватны и тот же badoo’шник это признал :-)

'''Задача:''' есть куча поставщиков API, которые по запросу умеют отдавать дикого размера XML’ки или JSON’ы с ценами на авиабилеты (1-30 мб). Пользователь выбирает даты, пункт отправки и назначения и число человек, и по этому запросу Aviasales должен максимально быстро сделать запросы ко всем поставщикам, собрать от них цены и отобразить пользователю в порядке возрастания. Кэшировать особо не покэшируешь, так как информация быстро меняется и должна быть максимально актуальной.

Нюанс: поставщики обычно сами тоже агрегаторы и тоже делают запросы к авиакомпаниям. И эти запросы поставщикам API '''не''' бесплатны. Соответственно, хоть запросы от Aviasales к ним для самого Aviasales и бесплатны, всё-таки лишние запросы тоже делать нельзя. Короче говоря, задача достаточно простая и прямолинейная.

Ещё нюанс: по их исследованиям конверсия уменьшается на 30 %, если среднее время ответа сайта повышается со 100 до 500 миллисекунд. Так-то.

'''Как было:''' Раньше у них всё это было представлено некой системой, написанной на Ruby On Rails, и это было довольно печально, так как RoR — типичный веб-фреймворк:
* Стартует небыстро, 5-10 секунд (и перезачитывать код на лету видимо не умеет?) — это несколько затрудняет отладку.
* Занимает немало памяти под каждый процесс зависимостями и т. п. (у них вроде 300 мб, но вероятно с учётом разделямой памяти)
* Полностью синхронный, и пока какой-то процесс делает запрос к внешней системе — процесс тупо висит, курит бамбук и ждёт ответа на сокете. Занятая память простаивает. Кроме того, пока таким образом не завершатся все скачивания — не получается начать отдачу страницы пользователю (не получается сделать «живой поиск»).

'''Как стало:''' В общем, им всё это поднадоело, они решили всё переписать и изобрели свой «сервис-ориентированный» DSL на питоне, на основе сервера [http://www.tornadoweb.org/ Tornado]. DSL называется «Ясень», состоит из изолированных обработчиков (у которых на входе 1 объект и на выходе 1 объект) и довольно прост, умеет всего 3 вещи:
* Последовательные цепочки — выход одного обработчика скармливается другому
* Параллельные цепочки — выход одного обработчика скармливается набору других
* Отложенные цепочки — выход всегда равен входу, предназначены для побочных эффектов (логгирование и т. п.)
Цепочки запускаются внутри одного процесса, то есть даже никакие JSON’ы между серверами туда-сюда не гоняются. Каждый обработчик при этом можно дёрнуть извне, таким образом отлаживаясь.

Система в целом написана на этом DSL, и его даже понимают менеджеры — бывает, приходят и говорят: а вставьте-ка мне вот сюда вот такой обработчик… И они вставляют.

'''Архитектура хранения''' — данные делятся на несколько видов:
* Мелкие справочники (например, валюты) — хранятся в памяти процесса на каждом сервере.
* Толстые справочники (> 1 мб) — хранятся в файловой key-value БД [http://fallabs.com/kyotocabinet/ kyotocabinet]. Она маппится в память процесса, соответственно, разделяется всеми процессами. Реплицируются на сервера с помощью, кажется, файловым репликатором [http://code.google.com/p/lsyncd/ lsyncd].
* Логи — всегда пишутся локально, а потом асинхронно перетаскиваются в глобальное хранилище.
* Динамические данные — пишутся на 2 redis-сервера для отказоустойчивости.

'''Какие есть процессы:'''
* «Пчёлы» — рабочие процессы, «муравьи» — те, что логи переносят, и локальное хранилище (плёлы и муравьи — это не я придумал, это у него в докладе так было).
* Ещё есть [http://haproxy.1wt.eu/ HAProxy] для распределения соединений, «многоножка» — интерфейс администрирования, и мониторинг [http://mmonit.com/monit/ monit], в который смотрит «пингвин»-админ.
* Если упадёт 1 redis — пофиг, система работает дальше. Если упадёт второй redis — ну, увы. Говорит, если у меня упадёт два редиса, я сначала уволю админа, а потом поставлю третий.
* Ещё при каких-то видах сбоев (если помрёт глобальное хранилище логов?) — часов 8 оно точно спокойно проживёт, а это время, за которое типичный «пингвин» может выспаться, прийти и всё пофиксить.

Как делается синхронизация данных на серверах после сбоя — он не рассказывал. Возможно, делается руками админа-«пингвина».

=== Как мы храним 60 тысяч событий в секунду / Арсен Мукучян (AdRiver) ===

Сурьёзный плюсист в чорном костюме рассказывал, как за 5..10 человеко-лет (5 человек за 2 года вперемешку с другими задачами) они переписали хранилку событий в AdRiver. Событие ≈ показ баннера, занимает от 0.1 до 4 Кб. Старая система работала на основе syslog (оригинально), который дропает события, когда их становится много (это фича, а не баг). Писали они исключительно хранилку, конкретные вычисления статистики отданы на откуп клиентам к хранилищу (то есть, другим отделам).

Рассказывал немного грустновато, я немного отключался. Итог реализации — кажется, поточная схема взаимодействия и «поуровневая» система архивирования: свежие события на «ближних» серверах, старые «дальше», ещё из старых событий может удаляться малополезная, но длинная информация типа Referer…

Нагрузка сейчас 2 гбит/сек (закладывали до 20 гбит/сек), загрузка CPU 20-40 %, обслуживается 5000 клиентов с 10 серверов.

=== Обзор популярных современных алгоритмов хранения данных на диске: LevelDB, TokuDB, LMDB, Sophia / Константин Осипов (Mail.ru, Tarantool) ===

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

Во-первых, '''[[wikipedia:Log-structured_merge-tree|LSM-деревья]]''' (Log-structured merge-tree). Идея в том, что у LSM дерева есть несколько уровней хранения увеличивающихся размеров, первый (нулевой, он же memtable) из которых лежит в памяти, а остальные лежат на диске. Каждый уровень представляет собой дерево или список деревьев, и у каждого уровня есть растущий (обычно в 10 раз на уровень) лимит размера. Вставка производится сначала в нулевой уровень, при переполнении он сбрасывается в первый, при переполнении первого — попадает во второй… И так далее. Вставки получаются быстрые, так как не нужно мучаться с перезаписью отдельных мелких блоков данных. Однако зато мы, во-первых, имеем неслабый write amplification, а во-вторых — при поиске значений должны просматривать все деревья (что не круто). С первым ничего не поделаешь, а со вторым борются поддержание в памяти bloom-фильтров — некой хеш-таблицы, посмотрев в которую, можно сказать, в каких деревьях данных точно НЕТ, а в каких они МОГУТ БЫТЬ.

LSM-деревья используются в библиотеке [http://code.google.com/p/leveldb/ LevelDB] от гугла, встраиваемой SQL БД [http://sqlite.org/src4/doc/trunk/www/design.wiki SQLite 4], в HBase, Wired Tiger и в NoSQL БД [http://cassandra.apache.org/ Apache Cassandra].

Во-вторых, '''Cache-oblivious структуры''' (общий термин, характеризующий то, что структуры эффективно используют кэш процессора, не зная его точного размера). Подход используется в новомодном движке хранения для MySQL — [[wikipedia:TokuDB|TokuDB]] (у них это называется [http://www.tokutek.com/2013/07/tokumx-fractal-treer-indexes-what-are-they/ Fractal Tree Indexes]). Идея в чём-то похожая — просто в каждом узле обычного B-дерева ещё поддерживается «буфер» для вставок, и вставляемые элементы сначала попадают туда, а уже потом сбрасываются в дочерние узлы. Засчёт этого скорость записи опять-таки увеличивается и не падает, даже когда индекс перестаёт влезать в память.

В-третьих, '''Bitcask''', используемый в [http://basho.com/riak/ Basho Riak]. Это вообще вещь тупая — данные всегда пишутся последовательно, хеш-индекс всегда держится в памяти.

Ну и последнее — некий гибридный подход, используемый в библиотеке '''[http://sphia.org/architecture.html Sophia]'''. Там, с одной стороны, данные делятся на непересекающиеся регионы, индекс которых (min, max для каждого) держится в памяти (получается что-то типа листов B-дерева), с другой — в памяти есть хеш-таблица, в которую в начале попадают новые элементы (чем-то похоже на memtable LSM-дерева). На диск последний хеш пишется в виде «журнала» (чтобы данные не терялись). А когда данных в этом хеше становится слишком много — данные распределяются по регионам, которые в свою очередь при переполнении разбиваются на под-регионы.

В конце докладчика спросили — а как [http://tarantool.org/ Tarantool]-то хранит?! Как, как — да никак. В памяти он хранит. В будущем, возможно, его научат хранить и на диске.

=== Статистика на практике для поиска аномалий в нагрузочном тестировании и production / Антон Лебедевич ===

Доклад интересный — про то, как можно применять методы статистики для выявления потенциальных проблем системы по графикам кучи показателей с кучи серверов. Ну или как их хотя бы сгруппировать / почистить так, чтобы количество стало вменяемым и в нём мог разобраться человек.

Выявление аномалий:
* Поиск изменения среднего. С помощью банального скользящего обычного или экспоненциального среднего.
* Поиск изменения распределения данных (делим данные на две части, применяем критерий Колмогорова-Смирнова).
* Выявление нелинейного роста.
* Выделение тренда с учётом сезонности + сильный выход за его границы (классический Холт-Винтерс). Минус в том, что нет нормального алгоритма для трёх сезонов, а их обычно как раз три :-) да и вообще в реальных данных часто встречается, например, график вида «пила».
* Нарушение автокорреляции показателя.

Группировка показателей (поиск зависимостей между графиками):
* Применяются методы кластеризации (k-средние, иерархическая группировка).
* На основе, например, корреляции или среднеквадратичного отклонения между графиками.
* Однако есть минус — такая группировка прекрасно «ловит» ротацию логов (когда старые логи сжимаются/удаляются). Она обычно происходит на всех машинах в один момент, и смена разных показателей в этот момент отлично группирует графики, хотя вообще-то их группировать незачем.

Всё это (или по меньшей мере часть), как ни странно, реализована в опенсорсном виде и её можно пощупать: https://github.com/etsy/skyline, https://github.com/etsy/oculus (части некого Kale Stack).

== День 2 ==

=== Завалить в один запрос: уязвимости веб-приложений, приводящие к DoS / Иван Новиков (ONsec) ===

Доклад немного в стиле «капитан ясен хрен», и явно было заметно, что товарищ пиарил свою конторку.

Рассказывал про баги в сайтиках, через которые «всё поломать» не получится, но DoS устроить вполне можно. Часть идей была полным (или НЕполным) бредом:
* Бажные парсеры — типа бывают баги в парсерах (XML, CSV, входных параметров и т. п.), из-за которых оные зацикливаются. Утверждал бред, что если передать PHP параметр вида ?a[][][]…[][][], то он зациклится. Это конечно не отменяет того, что такие баги _возможны_, но явно не в этом месте.
* Ещё одна бредовая идея — чувак утверждал, что популярные новомодные «классификаторы» (типа [http://utinet.ru ютинетовского]) тормозят, если им выдать что-то непонятное («синий красный зелёный одновременно фиолетовый и вес меньше 100кг»). Дурь. С чего им тормозить? Разве что имеются ввиду движки, которые по условию (< 100кг) вытаскивают все возможные значения веса и ищут по множеству? Но и это к серьёзным тормозам не приведёт. Ютинетовский подтупливает, конечно, но он и в целом небыстрый… а на DoS в один запрос это как-то не тянет.
* Про переполнение хранилища сессий. Типа если сессии очень жирные (если там хранится вся история посещений со всеми полями запроса), то их туда можно накидать своих, и других людей не будет логинить, или если они в tmpfs, память кончится (что бред — tmpfs ограничен в размере). Но даже если всё так, то эксплуатировать довольно геморно — это надо реально долбить сервер запросами, иначе ваши «толстые» сессии всё равно будут вытесняться.
* А вот эта относится к классу «капитан ясен хрен»: вспомнил поиск по регэкспам в БД, которые при этом ещё и берутся из параметров запроса. Не, то есть я не против, PHP-сайтики много <abbr title="Сам Себе Злобный Буратино">ССЗБ</abbr> пишут — многие популярные движки, например, исполняемый код в базе хранят (битрикс, Invision Power Board, например). Но это же реально ССЗБ — ясно же, что поиск по регэкспу в БД медленный ВСЕГДА. А он говорил, что типа можно сделать такой регэксп, который будет делать очень глубокий поиск с возвратом (backtracking) и тормозить.

Некоторые идеи были вполне ничего:
* Часто ограничивают заливаемую картинку размером в килобайтах, но не ограничивают размер в пикселях. А ведь в PNG можно создать хоть 100000x100000 картинку маленького размера, залитую одним цветом — там же сжатие. И в итоге на масштабирование, и даже на кроп такой картинки приложение тут же потратит всю память сервера. Лучше даже так рассчитать размер, чтобы в OOM процесс сваливаться не успевал, а чтобы просто дико свопился — пожалуйста, DoS в один запрос.
* Пример с яндексом — они нашли баг в WebDAV сервисе яндекс диска — попытка перемещения папки в свою дочернюю приводила к зацикливанию. Им даже 5000 рублей за эту находку дали.
* Любые взаимодействия по сокетам, в которые можно подсунуть свой адрес — например, OpenID. Дело в том, что таймаут запроса часто работает не в целом, а на 1 операцию чтения из сокета. Тогда делаем свой сервер, который на запрос будет раз в ''(таймаут-1)'' секунд отвечать 1 байтом. Подсовываем его URL и делаем с ним штук 80-100 запросов к сайтику. Итог — все рабочие процессы заняты тем, что прилежно ждут, пока наш сервер им посылает данные по 1 байту.

Но про самое классическое чувак почему-то не вспомнил! Самое классическое — это банальное открытие последних страниц какого-нибудь длинного тяжёлого поиска. В один запрос, конечно, не завалишь, но лёгким DoS’ом заставить сайт дико тупить от такого действия можно очень часто.

=== Масштабирование скомпилированных приложений / Joe Domato ===

Причем тут «масштабирование» — непонятно. Рассказ был про автоматизацию сборки и CI. Послушал чуть-чуть, услышал про:
* На винде все эти автотесты и CI настраивать геморно, на нормальных системах сильно удобнее.
* Тестов мы не хотим много и не хотим мало.
* Сборка должна быть повторяемой.

=== (полный отстой) Анализ производительности и оптимизация MySQL / Пётр Зайцев (Percona) ===

Тут я даже заметок никаких не напишу. Доклад вообще ни о чём, его можно было не делать. Там были не просто общие слова, а 100%-ная вода, состоящая из тривиальнейших идей. Про оптимизацию MySQL там не было '''вообще ничего''', ни одной фразы.

Кто после такого доклада пошёл ещё и на мастер-класс этого мастера лить воду — лопух ;-)

=== Платформа для Видео сроком в квартал / Александр Тоболь (Одноклассники) ===

Рассказ о том, как Одноглазники передалали свой видеосервис на собственную платформу. До этого он работал сначала на платформе видео@мейл.ру, потом на rutube. Но, судя по всему, ни качество, ни стабильность ни того, ни другого их не устроило, а задача создания средненького видеосервиса — она в принципе не такая уж и суперсложная, поэтому они его решили сделать сами.

Объёмы нормальные, в день: 10 млн уников, 60 млн просмотров (до 100 гб/сек), 50 тысяч новых видео (= 5 ТБ = до 5 гб/сек).

Итого устроено всё довольно просто:
* Хранилище — 70 серверов, 5 петабайт, БД и кэш — ещё 30, парк ffmpeg’ом под zookeeper’ом для трансформации — ещё 60, раздача и загрузка — ещё 30.
* Есть возобновляемая загрузка (failover).
* Используют flash. Хотят доделать HTML5 плеер.
* Как обычно, псевдостриминг (и правильно, все так делают, кроме тупого рутуба). То есть, не RTMP или что-то подобное, а обычная раздача MP4 через HTTP, а если нужно перемотаться — HTTP Range Request.
* Собственный вариант [https://github.com/danielgtaylor/qtfaststart qt-faststart] — скрипта, который перемещает MOOV Atom (заголовок видео) в начало файла (он в MP4 по дефолту в конце O_o), а также удаляет из него информацию о лишних keyframe’ах.
* Нюансы перепаковки: несколько качеств, в 15 % случаев требуется коррекция длительности.
* Чтобы всё это работало быстро, они, во-первых, напилили собственный кэш на своих [https://github.com/odnoklassniki/one-nio one-nio] и [https://github.com/odnoklassniki/shared-memory-cache unsafe кэше], в который всегда попадают все заголовки видео, плюс попадает само видео кусками по 256 Кб.
* Для кэша используется 96 Гб RAM и 4 ТБ SSD’шек на каждом сервере, плюс [http://obsproject.com/ OBS]. 80 % cache hit.

=== Вещание видео на 10 ГБит/с / Максим Лапшин (Erlyvideo) ===

Erlyvideo теперь вышел на американский рынок и называется Flussonic. И, видимо, теперь его используют разные группы нехороших лиц, наживающихся на продаже «нихрена» (контента). Сам Erlyvideo от этого, правда, хуже не стал (а то и стал лучше) и остался опенсорсным, что, безусловно, хорошо.

Рассказывал про разные нюансы раздачи видео с одного сервера на 10 гигабит. Типа процы в принципе не особо ускорились за 5 лет, но зато подешевели 10 гбит каналы, и появились SSD’шки, и вроде как стало можно раздавать и 10 гигабит. Например, на нагрузках в несколько гигабит у них подыхал software raid. И прочее — прерывания, дисковые очереди и т. п.

=== DDoS атаки в России в 2013 / Александр Лямин (QratorLabs/HLL) ===

Обзор ситуации с DDoS’ом в России за этот год.

Интересное:
* Атак стало больше в 1.5 раза, рекорд за день вырос в 2 раза, макс. размер ботнета тоже немного подрос, рекорд длительности — наоборот, упал.
* Spoofed атак («с чужого IP») стало больше, чем прямых.
* В основном пик активности был в конце зимы и весной (в отличие от 2012 — пик был летом).
* Уверенный лидер по атакам как в 2012, так и в 2013 — внимание, '''магические услуги'''! O_o за ним идёт правительство с почти четырёхкратным отставанием. Это что, такая «чёрная ddos магия»? Или просто кармическое наказание для шОрлатанов?
* Отличная картинка и фраза про «год фиолетового DNS» (DNS amplification): ''тут есть всё — и фиолетовые пони, и облака, и кирпичи высокой кристаллизации… А почему пони фиолетовый — это потому, что его уже просто больше нельзя бить, он сплошная гематома''<br />[[File:Год фиолетового DNS.jpg]]
* Товарищ зачем-то ругал UDP, потому что типа «любой протокол без авторизации и с плечом ответа» может привести к такому же усилению. Что-то мне кажется, что глупо UDP ругать — не будет его, будет что-нибудь ещё. А вот ratelimit на публичных сервисах — это правильно, да.

=== История MySQL и MariaDB / Michael Widenius (Monty Program Ab) ===

Видениус забавен, говорит с совершенно аццким акцентом. Рассказывал просто обзор фич MariaDB (аналогично https://mariadb.com/kb/en/mariadb-versus-mysql-features/). Напоминаю, [https://mariadb.org/ MariaDB] — это такой правильный MySQL, который пишут в основном те же люди, что писали изначально, вместо индусов из Oracle. О чём Видениус и напомнил, сказав, что программисты оракла явно не совсем понимают код, над которым работают.

Хотел я у него спросить, что у них там происходит с движком Aria, но не успел :-(. Aria — это «безопасный MyISAM», который в будущем они планировали сделать и транзакционным. Интересно, насколько он развивается, и есть ли вообще смысл в том, чтобы делать из него транзакционный движок — есть подозрение, что с появлением транзакционности все его плюсы (которые были) растворятся, и получится ещё один InnoDB, тормозящий на вставках.

=== Оптимизатор запросов в MariaDB: теперь и без индексов! / Сергей Голубчик (Monty Program Ab) ===

Отличный доклад — разработчик марии рассказывал о том, как они недавно наконец-то запилили в MariaDB статистику, независимую от движка хранения.

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

А теперь сама мария умеет считать статистику по таблицам, индексам и даже колонкам (без индексов, ищет мин/макс, процент NULL, среднюю длину, обратную мощность и умеет считать гистограммы) путём ANALYZE, работающего через фулскан таблицы. Используются гистограммы равной высоты (то есть с неравномерной шкалой).

Нюансы, я так понял, такие: во-первых, надо иногда делать ANALYZE (само оно статистику не считает), во-вторых, часть оптимизаций полезна для «медленных» выполнений запроса, без индексов.

Из юмора:
* Показывал пример с таблицами сотрудников — «вот, смотрите, это такой странный набор данных, где мало менеджеров…»
* Ему задавали вопрос, он такой, «я не уверен что я понял <s>запрос</s> вопрос…» :D

=== Как рассуждать о производительности хранилищ баз данных / Mark Callaghan (Facebook) ===

А вот и ещё один доклад про всевозможные LSM-деревья, LevelDB и подобное. В принципе нормальный доклад, но не совсем про производительность, а именно что про «рассуждения».

А именно — про Write Amplification, Read Amplification и Space Amplification — то есть, про увеличение числа записанных/прочитанных/хранимых данных по сравнению с тем, что мы реально хотим записать/прочитать/хранить. Понятное дело, что зачастую Write Amplification есть у оборудования (например, SSD), у СУБД (redo/undo лог), ФС (мин. единица записи — 1 сектор). Space Amp: метаданные, фрагментация, старые версии данных… Read Amp: как раз относится ко всяким LSM, когда чтобы что-то прочитать, нужно сходить во все уровни. Типа, Write/Read Amp ограничивает производительность — она не может быть больше, чем максимальная скорость работы дисков делить на усиление.

А теперь примерные оценки этих значений:
<tab sep="tab" class="wikitable" head="topleft" style="text-align: center">
Алгоритм point read-amp range read-amp write-amp space-amp
B-дерево 1 1..2 page/row * GC 1..2
LSM leveled 1 + N*bloom N 10*уровни 1.1 X
LSM с N частями 1 + N*bloom N возможно < 10 can be > 2
log-only (bitcask) 1 N 1 / (1-%live) 1 / %live
memtable+L1 (sophia) 1 1 размер БД/размер L0 1
memtable+L0+L1 (MaSM) 1 + N*bloom N 3 2
tokudb 1 2 10*уровни 1.1 X
</tab>

Примечания:
* Это копия со слайда, только я про разные типы B-дерева опустил — у них всех один и тот же показатель. Разница только в сборке мусора
* Если постоянно коммитить в B-деревьях, то Write Amp — очень большой (1 на лог + размер страницы делить на размер строки), есть нет — то меньше. Space Amp зачастую около 2, так как страницы держатся полными на ~60 %.
(10 — это типичная разница в размерах между уровнями)

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

См. также linkbench в https://www.facebook.com/MySQLatFacebook

=== Cassandra vs. In-Memory Data Grid in eCommerce / Александр Соловьев (Grid Dynamics) ===

Рассказ о том, как они переводили некий продукт с хранилища в оперативной памяти (а конкретно это был Oracle Coherence In-Memory Data Grid) на Кассандру. Именно на неё, потому что у Mongo и HBase обнаружены <abbr title="Single Point Of Failure, единая точка отказа">SPOF</abbr>, сложное развёртывание, и некоторые эксклюзивные блокировки. Плюс, кассандра умеет работать на несколько датацентров, что тоже было требованием.

Резюме — если данные влезают в память и если немного подтюнить кассандру — она, в принципе, практически так же производительна, как in-memory БД, ибо Linux’овый дисковый кэш работает хорошо.

У них была магическая цифра, с каждым тюном производительность росла на +15 % TPS :-D конкретно тюны были следующие:
* Выключить swap
* Commit log и данные — положить на разные диски
* Асинхронные запросы по многим ключам + token-aware routing → ещё +15 % TPS
* Юзать последнюю версию — с 1.2.6 на 1.2.8 → ещё +15 % TPS
* Ключ «родительского» объекта как первый компонент составного ключа «дочернего» (группирует она их, видимо) → ещё +15 % TPS
* Локальные кэши → ещё +15 % TPS

=== Сравнение распределенных файловых систем / Marian Marinov (1H Ltd.) ===

Доклад с качественным вдумчивым бенчмарком нескольких распределённых файловых систем (линуксовых, разумеется).

* Сначала про ethernet контроллеры — из типичного гигабитного выжимается ~500 mbit всего лишь. Чтобы приблизиться к теоретическому лимиту (~920 mbit), нужно покупать дорогой контроллер.
* Потом про ядро — почесать разные сетевые sysctl (см. презентацию: http://www.slideshare.net/profyclub_ru/marian-marinov), ethtool (всякие segmentation offload, receive offload)
* Потом переходим к бенчмаркам: GlusterFS, XtremeFS, FhgFS, Tahoe-LAFS.
* Итог — наилучший вариант это FhgFS, так как скорость хорошая и нет внезапных тормозов.

=== JIT компиляция в виртуальной машине Java / Алексей Рагозин ===

Тот же мэн, что рассказывал на SECR’е про Performance Test Driven Development. «Серия» из двух докладов, с общим названием «JVM Deep Dive» :-)

Первый доклад — про JIT.
* Бывает классический JIT. Просто берёт код и компилит в машинный код перед запуском. Это .net, jvm, v8, ionmonkey.
* Бывает трассирующий JIT (tracing JIT) — который сначала запускает в интерпретируемом варианте, а потом повторяющиеся куски («трассы») JIT’ит. Они получаются идеальные и без ветвлений совсем. Это flash, tracemonkey, pypy, luajit.
* JIT в JVM (и официальной, и OpenJDK) довольно крутой. Он умеет разные оптимизации:
** Умеет на лету inline’ить функции
** Умеет заменять метод на стеке — в момент возврата из функции управление получает JIT, подменяет реализацию метода (вдруг заинлайнить что-то решил, например) и подменяет адрес возврата.
** Умеет превращать простые объекты в наборы скаляров (типа Point = float x, float y).
** Умеет инкрементальную компиляцию.
** Умеет ликвидировать код синхронизации там, где он не нужен (если значение не утекает за пределы текущего вызова функции). Например, StringBuffer.
** Умеет девиртуализацию функций (если вариантов нет) и инлайн final static членов класса.

=== Cборка мусора в Java без пауз / Алексей Рагозин ===

Второй доклад, тоже интересный, теперь про сборку мусора и про то, бывает ли она без пауз.

Резюме — нет, сборки мусора без пауз не бывает. Если очень много выделять памяти и не освобождать автоматически, в какой-то момент она всё равно кончится и придётся останавливать мир :-). А ещё — паузы можно уменьшить, и их отсутствие мало от чего спасёт — в real-time применениях всё равно найдётся ещё 100500 других проблем (свопинг, кривые руки и т.п).

Какие вообще есть алгоритмы сборки мусора?
* Простейшее (mark&sweep) — остановили всех, прошлись рекурсивно по всем объектам, пометили достижимые, удалили остальные.
* Concurrent mark&sweep с барьерами на запись: Немножко всех тормозим, находим корневые ссылки, потом всех возобновляем и маркируем достижимые объекты, потом всех приостанавливаем снова, перемаркируем то, что было изменено, опять всех возобновляем и удаляем отмеченное недостижимым. Барьер — это просто bitmap, который даёт нам понять, что же было изменено.
* Разделение кучи на поколения — «старые» объекты живут долго и редко собираются, «молодые» — живут недолго и собираются часто.
* Алгоритм «метроном» — сборка копированием с барьерами на чтение. Есть 2 области памяти: «старая» и «новая». Сначала все объекты в старой. Параллельным потоком включается сборка мусора, и начиная с этого момента, если поток при чтении видит, что объект в «старой» области — он его нерекурсивно копирует в новую и обновляет ссылку. Таким образом, код работает только с «новыми» объектами. Мусорщик параллельно тоже перемещает «старые» объекты в «новую» область памяти, обновляя ссылки. Процесс когда-то заканчивается. В общем-то идея хороша, но — накладные расходы немаленькие.
* JVM-суперкомпьютер Azul Vega. По сути, хитрожопый вариант «метронома» с поколениями и аппаратной поддержкой, а именно — с дополнительными битами в адресах, служащими как барьеры (плюс для работы со слабыми ссылками). Но — физические JVM CPU делать невыгодно, они уже все почти повымерли, поэтому потом они сделали Azul JVM с той же идеей, которая использовала сначала виртуализацию, а потом и просто модуль ядра Linux x86-64 для поддержки этих самых бит. Ещё у неё есть 3 стратегии копирования — байтами (до 256 Кб), 4 Кб страницами (до 16 Мб), и 2 Мб страницами (> 16 Мб объекты).

См. также «[http://blog.ragozin.info/2013/11/hotspot-jvm-garbage-collection-options.html шпаргалку]» по сборке мусора в JVM от автора.

{{replicate-from-custiswiki-to-lib}}
[[Категория:Конференции]]

Файл:Год фиолетового DNS.jpg

2013-11-11T11:39:55Z

VitaliyFilippov: загружена новая версия «Файл:Год фиолетового DNS.jpg»

SECR-2013: Отчёт Виталия Филиппова

2013-11-01T14:06:49Z

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

[[Категория: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}}

SECR-2013: Отчёт Виталия Филиппова

2013-11-01T13:19:13Z

VitaliyFilippov:

[[Категория: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’а. Типа символом он не ициализируется.
История [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}}

Файл:008 bodrenko.pdf

2013-10-30T15:20:31Z

VitaliyFilippov:

ViewVC

2013-10-23T15:54:31Z

VitaliyFilippov:

ViewVC — система онлайн-просмотра репозиториев систем версионного контроля [[CVS]] и [[Subversion]]. Ранее называлась ViewCVS.

* Сайт: http://www.viewvc.org/, http://viewvc.tigris.org/
* Лицензия: Permissive, типа [[rupedia:Лицензия MIT|MIT]]. Free & OpenSource.
* Версия с нашими доработками (ViewVC4Intranet): https://github.com/vitalif/viewvc-4intranet
*: Ниже значком ([[File:Wiki4intranet-logo.svg|32px|link=]]) помечены фичи, присутствующие только в нашей версии.

= Основные возможности =

Просмотр:
* Листингов директорий (ls) (в том числе по предыдущим версиям)
* Журналов ревизий с комментариями, списков изменённых файлов (log)
* Различий между версиями, в том числе в формате патча (diff)
* Содержимого файлов
** С подсветкой синтаксиса многих языков программирования, в том числе нашего PL/SQL препроцессируемого [[m4]] (*.sp4)
* Аннотаций, поиск виновного (blame/annotate)

[[#Поиск изменений|Поиск изменений]]:
* Поиск по параметрам ревизии
* ([[File:Wiki4intranet-logo.svg|32px|link=]]) [[#Поиск по содержимому|'''Поиск по содержимому файлов''']], в том числе бинарных (офисных и т.п.)
* Генерация [[RSS]]-лент изменений (в том числе по любому запросу поиска)
* ([[File:Wiki4intranet-logo.svg|32px|link=]]) [[#Патчи из выбранных изменений|Генерация патчей]] из выбранных списков изменений
* [[#Списки merge для отмены изменений|Вывод команд svn merge для отмены выбранных изменений]]

Поддержка:
* Прав Subversion.
* ([[File:Wiki4intranet-logo.svg|32px|link=]]) Прав CVSnt.
* ([[File:Wiki4intranet-logo.svg|32px|link=]]) Корректных проверок прав в результатах поиска.
* ([[File:Wiki4intranet-logo.svg|32px|link=]]) Мелкие доработки и исправления багов, полный список [https://github.com/vitalif/viewvc-4intranet/blob/master/CHANGES здесь].

== Листинги директорий ==

Заходя на главную страницу ViewVC, можно увидеть список [[CVS]]- и [[Subversion]]-репозиториев, а также ссылку «Query revision history» вверху страницы. Далее можно выбрать репозиторий — вы увидите список файлов и каталогов/модулей (cvs), находящихся в нём. Аналогично, кликнув на каталог, вы увидите листинг файлов и подкаталогов в нём.

== Журналы ревизий ==

К журналу ревизий можно перейти, выбирая файл из списка (по умолчанию открывается журнал ревизий), кликая в списке на номер ревизии рядом с каталогом, или переходя по ссылке «(modified)» в списке изменений, просматриваемом по номеру ревизии.

== Различия между версиями ==

Diff’ы отображаются с подсветкой удалённых/добавленных/изменённых строк и некоторым количеством строк контекста. Можно просматривать различия только по отдельным файлам; удобнее всего делать это со страницы журнала ревизий — нажимая на ссылки «Diff to previous XXX» или выбирая две версии (числовых, а в случае с CVS — и именованных) и желаемый формат различий внизу страницы. А со страницы с самими различиями можно скачать патч, нажав на ссылку «Patch».

== Списки изменений по ревизиям ==

В [[Subversion]] (не [[CVS]]) каждая фиксация изменений атомарна, а в репозиториях хранятся данные для сопоставления номера ревизии репозитория и всех изменений, в ней произошедших. Кликнув по номеру ревизии на странице журнала изменений файла, или по номеру ревизии вверху страницы со списком файлов в каталоге [[Subversion]], вы попадаете на страницу с информацией об изменениях, произошедших в данной ревизии.

== Построчное аннотирование ==

Аннотирование (поиск виновного): файл разбивается на строки, и напротив каждой строки выводится информация о том, кто последний её менял. Чтобы перейти на страницу с аннотацией, нужно кликнуть на ссылку annotate на странице с журналом ревизий.

== Поиск изменений ==

На страницу поиска коммитов (изменений) можно попасть по ссылкам «Query revision history» в листингах каталогов. На странице поиска можно выбрать:
* ([[File:Wiki4intranet-logo.svg|32px|link=]]) Текст для поиска по содержимому версионированных файлов. При поиске учитывается русская и английская морфология, поиск ведётся ''во всю глубину истории''.
* ([[File:Wiki4intranet-logo.svg|32px|link=]]) Репозиторий, тип репозитория.
* Поддиректорию, путь к конкретному файлу.
* Логин автора.
* ([[File:Wiki4intranet-logo.svg|32px|link=]]) Номер ревизии.
* Интервал дат.
* Текст комментария для поиска.

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

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

Форма поиска используется для интеграции с [[Bugzilla]] — в Bugzilla можно увидеть ссылки «Look for bug in CVS&SVN», ведущие на результаты поиска изменений с номером бага или словом «bugXXXX» в тексте.

=== Поиск по содержимому ===

([[File:Wiki4intranet-logo.svg|32px|link=]]) Долгое время для поиска по содержимому у нас пытался жить [[SVNSearcher]] (если это можно назвать жизнью). Но — не прижился. Ибо '''очень''' медленный, '''очень''' некачественный, и генерирует '''очень''' большие индексы. В тормозах его виноват, правда, не Lucene (который вполне [[Сравнение движков полнотекстового поиска|быстрый]]), а качество реализации.

А теперь наша сборка '''ViewVC''', с помощью прикрученных к ней Tika и Sphinx’а, умеет отлично искать по содержимому Subversion.

<span style="font-size: 200%">[[File:viewvc-logo.png|link=http://viewvc.org/]] + [[File:Tika.png|200px|link=http://tika.apache.org/]] + [[File:Sphinx.jpg|link=http://sphinxsearh.com/]]</span>

'''Tika''' — это java-библиотека для вытаскивания текста из бинарных документов. Собственно, самое вкусное, что было в составе SVNSearcher’а. Чтобы работала быстро, её можно запускать в режиме TCP-сервера.

'''Sphinx''' — в качестве движка поиска. Его realtime индексы, из которых по факту ничего нельзя удалить, а можно только добавить, идеально подходят для индексации содержимого системы контроля версий.

Для использования поиска нужно нажать '''Query revision history''', ввести в поле «Search content» нужный текст, выбрать желаемые даты (по умолчанию поиск только за последнюю неделю), и нажать Search.

[[File:ViewVC-ContentSearch.png|400px]]

=== RSS-ленты изменений ===

Кликнув на привычный значок [[RSS]] [[File:rss14.png]] на странице, можно получать результаты любых поисков в формате [[RSS]]. В том числе, можно подписываться на изменения по отдельным репозиториям, каталогам, файлам — нужно просто кликнуть по значку [[RSS]].

=== Патчи из выбранных изменений ===

([[File:Wiki4intranet-logo.svg|32px|link=]]) ViewVC может генерировать патчи из результатов поиска изменений (ревизий). Для генерации патча перейдите по ссылке «''Show a patch built from these changes''», показываемой вверху страницы результатов поиска. Помните, что если результаты поиска включают в себя изменения одних и тех же файлов, сильно разнесённые во времени, патч будет включать также и все изменения, сделанные в том же файле между найденными. ViewVC старается отслеживать такие ситуации и выводить предупреждение о них в следующей форме: '''CAUTION: selected changes are not contiguous, patch may include differences from other commits'''.

=== Списки merge для отмены изменений ===

Ещё одна нетривиальная возможность страницы результатов — ссылка «''Show commands which could be used to back out these changes''». Перейдя по ней, вы увидите список команд merge, которые нужно выполнить в рабочей копии репозитория, чтобы попытаться отменить все изменения, выведенные на странице результатов поиска.

= Ссылки =

* [http://www.viewvc.org/ Официальный сайт ViewVC];
* [http://viewvc.tigris.org/ ViewVC на хостинге проектов tigris.org];
* [[WikiPedia:ViewVC|ViewVC в Википедии]];

{{replicate-from-custiswiki-to-lib}}
{{replicate-from-custiswiki-to-4intranet}}

MediaWiki:Sidebar

2013-10-22T13:00:06Z

VitaliyFilippov:

2013-09-20T14:47:27Z

VitaliyFilippov:

'''Ленточная диаграмма''' (''horizontal bar chart'')
позволяет отобразить множество дискретных данных вида (категория, число) в виде прямоугольников, ширина которых одинакова, а длина каждого прямоугольника пропорциональна заданному значению для этой категории.
Например, таким образом удобно показывать дискретные распределения.
В [[{{SITENAME}}]] можно легко включать ленточные диаграммы, используя тэг «hbarchart»:
<nowiki>
«Готовы ли Вы приобрести мобильный телефон отечественной сборки?»
<hbarchart>
Нет 4873
Да 1970
затрудняюсь ответить 1286
это зависит от того, где его будут собирать 688
</hbarchart>
</nowiki>

«Готовы ли Вы приобрести мобильный телефон отечественной сборки?»
<hbarchart>
Нет 4873
Да 1971
затрудняюсь ответить 1287
это зависит от того, где его будут собирать 681
</hbarchart>

Аналогично, можно использовать вертикальный график — '''столбиковую диаграмму''' (''vertical bar chart'').
Для этого используется тег «vbarchart»:

«Количество новорожденных в роддоме города N.»
<vbarchart>
2003 1523
2004 1985
2005 2123
2006 2345
2007 9876
</vbarchart>

[[Категория:Справка]]
{{replicate-from-custiswiki-to-smwiki}}
{{replicate-from-custiswiki-to-lib}}