О разработке требований

Бывало ли у вас, что непонятно, что должна делать эта фича\таска\проект ?
Бывало ли, что при чтении кода или работе с программой становилось непонятно: это бага или фича ?
Возникала ли у вас хоть раз мысль: "что этой формулировкой тут хотели сказать, %№:%№ ?!" ?
Случалось ли хоть раз, что заказчик говорил вам: "это не то, что я вам пояснял !!!" ?

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

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

В общем думаю без преувеличения можно сказать, что все это видели, видят и еще долго будут видеть в будущем =)

вот как-то так и работаем =)

К чему это я: за 30-40 лет существования более-менее коммерческой части ИТ мы научились делать сложные, большие, высоконадежные, масштабируемые, качественные системы, но до сих пор не научились понимать, ЧТО и ЗАЧЕМ надо все таки реализовать.А процент успешных проектов - так и остался на уровне 30-40 %, с небольшим ростом около 5% за последние годы.
Новые технологии не спасают, т.к. проблема так и осталась в людях - мы просто плохо представляем, что же они хотят получить от нашей системы в итоге.

Эти мысли переодически меня волнуют  и потому, чтоб чуть лучше понимать почему такое случается, и что мы все делаем не так -  прочел "Разработку требований к программному обеспечению" Вигерса.

И МНЕ ОТКРЫЛОСЬ!

Шучу конечно)) Ничего сверхестественного не открылось, но где потенциально профакапить можно стал понимать лучше)

Вобще данная книжка по праву должна считаться "настольной книгой аналитика" и скорее всего ваш аналитик читал ее, если нет - то пусть прочтет.
У вас нет аналитика ?
Но кто-то же выполняет его роль ? Разаботчики\ПМ\ПО\юзабелист\маркетолог ? 
Никто ?
А ну тогда ясно почему вам приходиться переделывать, что-то по 5 раз прежде, чем заказчик это примет.
Кто-то эту роль выполняет - если он выполняет ее неявно и тяп-ляп - вам же хуже.

И в интересах компании, чтоб кто-бы ни брал на себя обязанности аналитика, чтоб он мог сказать почему и зачем так реализована КАЖДАЯ фича в вашем продукте.


Хотя бы вскользь прочитав первую главу, вы поймете: КТО, ЧТО и ПОЧЕМУ.

Анонимные пользователи

Кто.

Это в первую очередь те для кого создается продукт(клиенты): конкретные классы пользователей, которые хотят решить свои задачи. 
И пусть один из этих классов - холодильник, использующий ваш интернет магазин для заказа еды владельцу, но у него есть свои пожелания, ограничения и требования. 
Некоторые пользователи могут быть привилегированнее других, и при конфликте требований(да такое бывает =)!) зачастую важнее решить их задачу. 
Некоторый класс пользователей можно случайно забыть и тогда счастье тотальной переделки продукта вам обеспечено, т.к. забыли спросить вон у тех товарищей, что им надо.


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


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

ЧТО ?!

Что и почему.

Что такое требования ?
Как их разрабатывать и как ими управлять?
Зачем ими заниматься ?
Почему у хороших людей могут появляться плохие требования?
Как отличить хорошие требования от плохих?
Как заметить, что какие-то требования пропустили?
Как требования разрастаются и как происходит их "золочение" ?

Если вы не можете ответить на хотя бы 1 из вопросов или возникает смутное ощещение, что вы не понимаете о чем это - значит вам надо прочитать 1ю главу, как минимум =)

Как.

Вторая глава посвящена правильной разработке требований.

В кратце я бы сказал так: если для каждой фичи и, соответствующей строчки кода, реализующей эту фичу, можно сказать какое требование пользователей они реализуют (с ссылкой на соответствующий документ и индификатор требования) и наоборот, то вы на правильном пути.
Если при этом пользователи вам говорят: "это именно, то что мы хотели и ожидали", то скорее всего можно смело закрыть эту статью и занять своими делами =)

Иначе позвольте задать вам пару вопросов:
Что такое бизнес-требования, как они превращаются в образ и границы проекта?
Как найти и отобрать этого скрытого пользователя, который точно знает, что же ему нужно от вашего продукта?
Как выпытать из него нужные сведенья с максимальной пользой, эффективностью и удовольствием для обоих сторон(интим не предлагать)?
Как понять, что то что вы услышали, действительно, то что надо, а не получить "качели" ?
Что такое бизнес правила и с чем их едят ?
Почему документация не такое уж и зло, и как применить это зло во благо ?
Что такое атрибуты качества ПО и как их выявить ?
Зачем создаются прототипы ?
Как утверждать требования ?
Какие бывают проблемы при разработке требований ?
Вы таки создал требования - что делать дальше ?)
Кто убил Кеннеди ?

На эти и тысячи других увлекательных вопросов вы сможете узнать в нашем супер-пупер издании, которое так же излечивает гемморой, головную боль. И в добавок если вы позвоните прямо сейчас, то получите ... супер приз - АВТОМОБИЛЬ!!!.

Нет, кажется это из другой оперы.
Получите кучу полезных знаний и пару-тройку мыслей для размышления =) Не автомобиль, но тоже - неплохо.

Куда.

Все эти полезные знания конечно хорошо, но ими еще надо как-то управлять, да еще и требования после того, как их узнали от клиентов имеют привычку периодически меняться, т.к. клиенты тоже живут своей жизнью и бизнес у них не стоит. И чтобы вам в голову не приходила мысль сделать слоеный word (вырезанный кусочек, если тему потрут). Лучше прочитать 3ю главу о том, как этими самыми требованиями управлять, связывать и прочее.

Ну а так, как к этому моменту вы поймете насколько у вас все плохо, то 4я глава расскажет вам как реализовывать этот самый процесс построения требований =)

Кроме того для лентяев и тех кому все таки лень читать книжку в ее конце есть пара приложений, с целью само проверки насколько хорошо вы управляетесь с требованиями.
Вырезка из CMMI рассказывающая, как эти самые процессы совершенствовать.
И руководство по поиску  и решению проблем, связанных с требованиями (куча таблиц, показывающих, что 90% ваших ежедневных проблем - неправильная работа с требованиями=))
Ну и естественно пример, как оно должно быть =)

Приятного чтения.

Обзор книги Эрика Берна "Лидер и группа. О структуре и динамике организаций и групп"

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

Если имя автора вам ничего не говорит, то можно загуглить "транзакционный анализ" и "родитель-ребенок-взрослый". Узнаете кое-что полезное =)

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

Если обычная книга по ит-пипл-менеджменту говорит: "дайте вашим программистам отдельный офис, хольте и лелейте их", то стандартный параграф из этой будет звучать как "вот Джуди провела   транзакцию относительно Карла с позиции Взрослый-Взрослый, а Карл разрушил их транзакцию переведя ее в разговор в стиле Родитель-Взрослый".

С одной стороны знания почерпнутые из книги довольно сложно применить "в лоб", сказав что-то вроде: "с этого дня буду делать встречи 1 на 1". С другой такие обще-человеческие знания типа существования внешних и внутренних групповых границ (внутренняя - лидерский аппарат), существовании второстепенных границ, о том, что групповая динамика в принципе измеряется количественно, например, такими показателями, как сплоченность. О том, что бывает внешний и внутренний групповой процесс.

Группы можно классифицировать 10ками способов, а не просто "толпа коллег": по структурным, динамическим, рабочим, властным аспектами и т.д. "Коллеги за работой" и "толпа пьяных фанатов" - две группы но такие разные =)

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

Если по прохождению тренинга по командообразованию, мне было известно о двух типах руководителей "администратор" & "лидер", то теперь узнал что их 3:

• эффективный лидер - "доминирующий и влиятельный"
• ответственный лидер - "тот, кого призывают к ответу "
• психологический лидер - "первый после бога =)" - всемогущий, всезнающий и гениальный - в общем, как Стив Джобс для Эппла =).  

В общем почвы для размышлений можно понабрать на месяц-другой =)

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

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

Итого: первую часть можно и нужно почитать, вторую чтоб на практическом примере понять как же оно работает, и получить в голове пару озарений в стиле "ага, вот оно что!", а третью и четвертую - только если вам реально интересно и есть свободное время =)

Октябрь - пора конференций

Good news everyone!

Удачное начало месяца (good news =)): удалось посетить парочку конференций в частности: более-менее технологическкий Highload  и скорее тусовочный 404fest =)


Начну в хронологическом порядке с мини-отчета по 404: 
Собственно особо чего-то нового от конференции не ожидал, т.к. поехал больше потусить и повидать знакомых и бывших коллег (из Parсsis, которые собственно поглотили турбомилк: организаторов 404). 
Судя по всему таких было немало, т.к. в твиттере проскакивали сообщения типа: "без докладов была б вобще отличная конференция")


В общем-то народ общался о всякой фигне, развлекался, пил алкоголь (который в виде айпад-приложения, и прилагающегося к нему барменом, был предоставлен plusmedia(определенно ГОРАЗДО лучший способ попиариться, чем стенд с надписью) =). 


Из полезных и интересных докладов, которые мне хоть чуть-чуть запомнились были:


1) доклад Кирилла Готовцева "Почему инвестор это существенно хуже чем кажется", мысль то в общем проста: инвестор - это тот чел, что в 90е смог отжать\удержать\заработать себе так много, что сейчас у него есть лишние деньги, и в общем-то сейчас вы все: программисты, дизайнеры, и т.д. ни разу не круты, чтоб с ним тягаться. 
И если ВДРУГ что-то пойдет не так, то будьте готовы растаться со всем: проектом, командой, идеей и т.д.,  т.к. этот чел, знает как и что забрать и удержать. 
С одной стороны вроде очевидность, но с другой - мало наверно кто об этом задумывается, когда строит планы: вот инвестиции рекой потекут и ламборджини через полгода куплю себе.


2) Очень понравился доклад Сергея Котерева "Театр абсурда или история измерений удобства веб-интерфейсов с помощью трофейного прибора Eye-Tracker" товарищ рассказал, как они применяют этот самый прибор для математически точного измерения юзабельности UMI.CMS и сравнения его с аналогами. 
Сколько кликов нужно, чтоб добавить новость, сколько секунд это занимает, где люди вобще ищут кнопку, как сделать, так чтоб кнопку редактировать вобще заметили. И на конец: "А нужна ли кнопка вобще" ?
Так например во время юзабилити тестирования кнопки "демо" на сайте обнаружилось, что женщинам-менеджерам вобще нафиг не сдалось демо: они читают описание и ищут телефон, чтоб позвонить и расспросить уже селза, так что как кнопку не выделяй по ней вобще не щелкают, а лучше телефон сделать виднее и понятнее.


3) Послушал ЕДИНСТВЕННЫЙ более-менее технологический доклад от Олега Шарова из Echo, рассказали про тяжелую жизнь калифорнийского стартапа, который боролся за рынок на котором даже и денег-то особо не было. Чуть рассказал о том, что у них 50 тачек риака + индексы на пострегресе(20 машин), а написано все на эрланге + окамле. Что сначала боролись с дискасом, то у них появилась фича - через неделю она на дискасе, то наоборот, хотя денег никто и не получает, и потмо они поняле, что это путь в никуда и превратились по большей части в риал-таймовую бд на основе который люди могут строить свои системы, ну и вроде как поперло. 


4) Интересно было послушать Александар Калугина из Mercury Development про "Большие проблемы маленьких устройств", разрабатывать под мобильные платформы не так легко, как кажеться, полд декстоп - гораздо легче: проблемы с лицензированием, жпсом, количеством памяти, 3-5 разными раскладками интерфейса под IOS, и десятками под андройд, про то, что бывают андройд-клиенты без тачпада - с клавиатурой, и там тоже это должно работать. Вобщем мобильная разработка - это такой себе отдельный мини-мир в разработке с кучей проблем и неочевидностей. Начинающим и не очень начинающим разработчикам под мобильные устройства: обязательно пообщаться с автором =) 


5) Достаточно интересный филофоски-образовательный доклад был от Петра Диденко из Скб Контура "Мы все конкурируем с бумагой" оказывается эти ребята разрабатывают "Диадок", систему замены бумажного документооборота, я про нее слушал от знакомых работающих в банках и обычно ничего хорошего =) Но оказалось, что в общем-то ребята пытаются решить одну проблему: избавить документооборот об бумаги вобще, т.к. по сути все документы щас создаются в электронном виде, а печатаются\передаются курьером\подписываются и т.д. лишь для отчетности перед государством. Послушать было интересно, хоть и безполезно =)


6) Послушал Евгений Кобзева из того же СКБ Контура про то какие данные можно достать в этих наших интернетиках о частных и юридических лицах, тоже интересно: о списках акционеров, уставных капиталах, кто где зареган, кто чем владеет, кто сколько доходов\прибыли получает: опять же считать чужое жутко интересно, но довольно безполезно: зато можно посмотреть а то, где я работаю прибыли то приносит: в этих данных зачастую всплываю "попилы": типа убытки -540 миллионов, но банки опять дают этому предприятию 500 миллионов кредитов. Бзеполезно, но забавно.


7) Последнее, что не досидел до конца из интересного было: "Customer Journey (неисповедимы пути потребителя)" от Андрея Сикорского. 
Планировали и думали, как конкретный потребитель попадает на конференцию. Какие ожидания у него формируются.
Что ему мешает найти нужную информацию или совершить нужное действие(барьеры): стоимость, документы, необходимость добраться до другого города.
Что его стимулирует продолжить путь к намеченной цели: темы докладов, фотоотчеты с предыдущих конференций, имена известных лиц, отзывы друзей и т.д. 
Что он ожидает после конфы: выкладывание отчетов ? выкладывание презентаций, возможность сконтактировать с понравившимися докладчиками и т.д.? 
В общем очень полезная деятельность - странно, что я не видел и не слышал, чтоб ее где-то применяли из более-менее известных мне компаний. Надо бы как-нибудь


Жаль до конца не досидел, т.к. надо было уже бежать на самолет(, который все равно зараза на 4 часа опаздал: Epic Fail!)


Еще была пара-тройка докладов, которые хотел послушать, но "не судьба" =)


В остальном все было обычно: людей хантили(особо островок.ру, думаю пару-тройку человек они нашли =)), старые знакомые знакомились, новые знакомые заводились, полеголые барышни пиарили Мегафон, кого-то там еще и т.д. в общем было весело =).





А теперь про highload++:


В принципе за его цену я ожидал большего, ГОРАЗДО большего. Но еда была отличной =)

Было наверно штук 7-8 западных докладчиков, но они либо пиарили свой продукт, либо рассказывали вещи из мануалов и туториалов на сайте. Русские докладчики рассказывали иногда что-то более-менее интересное, но это было скорее исключением:

Alvaro Videla пересказал мануал RabbitMq, т.к. я по него знал нового, ничего не всплыло.

Buddy Brewer заинтересовал только прикольным именем и фамилией, о чем он рассказывал я уже забыл даже =(.

Потом послушал Андрея Саса из Badoo про 100 миллионов писем в день - в принципе интересно, т.к. мало кому с такими объемами приходиться работать. особо чего-то не запомнил, но буду знать у кого спросить. 

Макс Лапшин из erlyvideo рассказал, как он перепроектировал свое приложений чтоб перейти от 800 клиентов слушающих видео к 3500, что в принципе это заняло всего-то неделю времени достаточно начинающего программиста и все благодаря эрлангу. Вобще докладов про эрланг или продукты на нем было 5-6 и думаю через пару-тройку лет он уже пойдет в мейнстрим. Думаю после конференции его подучат 10к-другой человек).

Потом был вкусный обед)

После этого послушал про mysql в Facebook`e от Domas Mituzas запомнилось, что у них сейчас 5.1 с кучей своих патчей, полезностей от которых в 5.5 еще нет, но вот в 5.6 добавят, что-то похожее и они на него перейдут, в основном патчи, связанные с производительностью, которые в чем-то дополняют, а в чем-то конкурируют с перконовскими сборками.

Послушал Роберта Вирдинга про реализацию эрланговской VM(Virtual Machine), в принципе все из рассказа уже где-то читал, да и думаю любой кто-хоть сколько-нибудь знаком с эрлангом знает о том, что garbafe collect происходит для каждого процесса, а не по аналогии я Явовским "Stop the world", что решение копировать память при пересылке сообщений - сделано для упрощения реализации этого самого GC. Из вроде-бы нового узнал, что есть такая штука, как erjang, краем уха слышал но не интересовался, т.е. реализация эрланга поверх явовской вм, дает ускорение на некоторых задачах(например число-дробительных), но привносит тот-самый "stop the world". Думаю тем, кто в первый раз слышал о эрланге было интересно.

Следующим был действительно интересный доклад Валентина Нечаева из ClustrixWatch про мониторинг кластеров супер-компьютеров. 

Зачем это нужно? Если сломается кондиционер в серверной, то то количества тепла что вырабатывает стойка хватит, чтоб сжечь ее за 6-7 секунд. Т.е. если что-то сломалось есть всего секунда-две чтоб отреагировать прежде чем ваш замечательный кластер отправится на свалку.

Потому мониторить - надо, но мониторить надо реал-таймово + реагировать очень быстро потому ос + тсп тут не особо подходят, т.к. у tcp могут быть довольно длинные задержки. Соответсвенно выход - удп, + собственный биос, который цепляется к шине данных материнки и отслеживает подозрительные события и шлет их супервайзерам (написанным на основе эрланговского OTP).Т.к. событий даже в 10000-ядерном кластере миллионы, все это шардится и судя по всему устроено так же, как дерево супервайзеров в эрланге. 

Половину доклада я,вероятно, переврал, но суть кажется передал) 

В общем 1 из интереснейших докладов.

Пару последних докладов первого дня я пропустил, хотя хотел послушать и потмо вернулся только на фуршет) Опять же поили и кормили вкусно =) 

После фуршета отправились с группой товарищей из Новосибирска (работают в 2Гис) и парой Московских знакомых в Тарас Бульбу неподалеку) 

Обсудили конференцию: не понравилось, что фирм не написано, т.к. не известно кто чем занимается и с какими технологиями работает, чтоб пообсуждать общие проблемы и интересы) Надо бы на бейджах писать теги типа #git. #rabbit, #geo, #php, #c++, #erlang и т.д., чтоб было понятно кто тебе интересен и с кем хочешь пообщаться=) Думаю надо бы эту мысль протолкнуть на следующей организации подобной технологической конференции.

В общем посидели опять же пообщались, новосибирцы попиарали свой CodeFest =)

Утром второго дня вернулся послушать доклад Константина Осипова про их Tarantool в сравнении с redis`ом, запомнил только, что у них более похожая на реляционную организация работа с бд, с несколькими уровнями иерархии. А больше ничего и не запомнил, чем он лучше редиса пропустил и вобще проспал =)

Интересно оказалась послушать товарищей(Андрея Смирнов и Василий Евсиенко) из Skype`а про решардинг редиса на живую, они почитали код редиса и написали хитрый прокси-демон который умеет фильтровать поток репликации редиса, чтоб разбить его на несколько аналогичных потоков и таким образом поделить 1 шард на несколько "на лету". Можно только похлопать им. Вобще решение получилось простое и гениальное) Жаль не опенсорсное)

Потом паралельно шли доклады об Apache Cassandra и pconnet`е от Сергея Аверина из Badoo. Об кассандре опять начали читать мануал и потому я бегал между залами и коридором, то там, то сям ожидал не расскажут ли чего полезного. Про pconnect были комменты в стиле: "php`шнеги впервые узнали о сокетах что-ли =)". Собственно аверин из них себе пользу извлечь умудрился, т.к. оверхед на установление соединения у него был равен оверхеду полученяи данных. Хоят и рассказывал очевидности, но по крайней мере живо и весело, что встречалось мало у кого, за что ему плюс в карму.

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

Сначала Аксенов начал с пересказа архитектуры процессоров x86 и умен зародилась мысль типа : "И ты Брут ?!?" (будешь пересказывать мануал), но он быстро исправился и начал рассказывать о действительно интересных вещах. И на примере показывать, как оптимизировал конкретное приложение в 4 раза по скорости выполнив 8 шагов, где-то убыстрив на 8-15%.

Качество его доклада хорошо отображается таким твиттом "после доклада Аксенова стало стыдно, что пишу на интерпретируемом языке." Вобще наверно один их тех докладов от которых была для меня наибольшая польза =) 

Узнал, что msvc по умолчанию компилирует с какими-то жутко древними флагами совместимости) А gcc не так плох но и за ним надо следить)

Потом опять был обед)

Доклад про openstat меня не впечатлил, даже забыл о чем рассказывали. Опять же доклад про column-orientied бд типа InfoBright для MySql`я вроде был и неплох но не запомнился, т.к. ничего полезного для себя не запомнил, кроме того, что в них чаще всего можно только инсертить, но по некоторым запросам они быстрее оказываются, чем стандартный myisam & innodb.

Петр Зайцев пересказал кучу "What's new" о MariaDb, Drizzle и прочих форках и не форках mysql`я. Что опять же заставляет грустить, лучше случаев из своей консалтерской практики рассказал.

Говорят Комсомольская Правда эпически облажалсь на своем докладе про код в стиле 90х, но сам не слушал, потому рассказать не могу.

Потом послушал Олега Илларионова из вконтакте про Ajax Layout, хоть и не highload, но было просто интересно, как переводили сайт, что делали, почему ифрейм лучше аякс запросов, о том как они заставляют работать кнопку назад, об уведомлениях и прочих штуках, после доклада его обступила толпа человек в 20-30, так что ,наверно, можно считать одним из самых успешных докладчиков.

Предпоследним из интересного был доклад Евгения Кирпичева про опыт разработки инфраструктуры для эффективной загрузки кластера из 10к ядер. Опять же был раббит, но уже с конкретными советами, что делать можно, а чего нельзя, а не чтение мануала, рассказывалось, как по логам мониторилась загрузка и эффективность работы кластера. Про систему распределения задач и про собственноручный писанный демон ответственный за запуск высоко-приоритетных задач и мониторящий ресурсы кластера. Опять же на общем фоне докладов этот был интересен.

Последнее, что запомнилось был доклад об нестандартном использовании репликации Mysql, как вы возможно догадываетесь ребята написали библиотечку для парсинга row-based репликации mysql`я. Например через нее можно написать какой-нить кеширующий демон, или наоборот чистилку кеша. Штука я считаю вобще полезная хотя пока и не знаю где-бы она мне могла пригодиться.

Итого: 

Еда - отлично. 

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

Докладчики и доклады - на троечку, иностранные докладчики ничего особо нового и интересного не рассказали тоже. Более-менее интересные доклады были, от русско-язычных докладчиков и почти все про эрланг =)

Цена - ужасно высокая для такого мероприятия. 

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

Афтерпати надо добавить определенно, и может добавить мини-секции по конкретным технологиям и интересам.