DCI: Data-Context-Interaction

Введение
Пару-тройку недель назад попалась ссылка на интересный подход к проектированию называющийся DCI, сформулированный создателем  MVC.

В кратце его можно передать так: все, что сейчас разрабатывается не ООП, а Class Orientied Programming.
И на самом деле должно быть разделение не на объекты, которые умеют как-то менять свое состояние, а на данные + роли, т.е. то, как разные классы данных взаимодействуют.
Ведь в сущности объект человек это набор ролей: отец, брат, продавец, муж и т.д.

Описание
Во время выполнения программы или любого алгоритма 1 объект может выступать в разных ролях и попытка впихнуть весь этот функционал в класс приводит к жуткой мешанине кода, тесной связность и вообще страданиям, страху и ужасу).

Вместо этого классы доменной логики, сами по себе должны быть эдакими "тупыми" объектами.
Например, объект Банковский Счет должен знать, что у него есть баланс, и он может его повышать и понижать, но только в рамках определенной роли и определенного контекста, к нему добавляется логика, например
1)возможность или невозможность залезть в долг при выдаче наличных,
2)возможность перевода денег на другой счет, при наличии достаточного количества на счету
3)возможность оплатить деньги всем кредиторам.

Все 3 предыдущих пункта - роли, играемые данным счетом в определенном контексте, и например во 2м варианте , этот же счет может играть роль "принимающего" счета.

Фактически любая программная система это динамический набор объектов, которые принимают то одну то другую роль за время своей жизни в рантайме и концпеции типа MVC, позволяют через сеть слоев соединить ментальную модель пользователя с настоящей vjltkm. работы системы.
Но во время разработки программист работает, с ментальной моделью статичной программы, в которой есть классы А И Б, которые умеют действий В и Г, а не с динамической моделью, что вот в этом месте класс А впитывает в себя роль принимающего счета, или брата, или чего-либо еще.
Подход к разработке с использованием парадигм DCI, пытается смягчить "impedance mismatch" (как это по русски-то называется ?)) между моделью системы в работе(runtime), и моделью ее во время разработки(compiletime),  что должно послужить повышению читаемости, понятности и предсказуемости поведения программ.

Итого

Чем-то этот подход и сама идея незримо напоминает AOP (который слишком сложен и неудобен и потому не получил особого распространения) и очень даже напоминает идеи mixin-нов, trait-ов и соответственно аспектов (которые мало-помалу вкрадываются во все новомодные языки и предают им синтаксической и концептуальной силы).

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

В общем-то видно, что интуитивно идея постепенно просачивается в программерское сообщество с тенденциями типа DDD, mixin`ов и trait`ов, но возможно с другим именем, и пока только кусками.

Источники
Тексты/Статьи:
1)http://en.wikipedia.org/wiki/Data,_Context_and_Interaction - статья в википедии
2)http://heim.ifi.uio.no/~trygver/themes/babyide/baby-documents.html - набор ссылок от автора

3)гугл =)

Видео:
1) http://oredev.org/videos/dci-in-practice(качественная речь, на слух воспринимается до скорости 1.3-1.4х)
2) James Coplien - The DCI Architecture: Supporting the Agile Agenda (качественная речь, до 1.6х скорости воспринимается)

3) Trygve Reenskaug - DCI: Re-thinking the foundations of object orientation and of programming
(у него жуткий акцент, очень сложно воспринимаемое на слух видео)

Московская встреча Стратоплана.

Не далее, как вчера прошла Московская  мини-конференция Stratoplan World от участников Стратоплана (http://www.stratoplan.ru) и при поддержке CustIs.

Было интересно =)

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

Хотелось бы отметить доклад Михайла Заборовова "О чем стоит подумать развивая персонал", основная мысль, которого , что развитие - процесс неообратимый и перед тем как кого-то "развивать" стоит подумать, а не станет ли хуже =) Т.е надо придерживаться принципа "не навреди") Привел много примеров из своей жизни, когда получилось "навреди" и с людьми приходилось расставаться из-за появившихся завышенных ожиданий, или из-за того, что "развиваемому" приходилось говорить - "извини, не тянешь, мы нашли получше)".

Был интересный доклад от Педько Олега о том как сотрудники "выгорают", в принципе мысль была такова - "скорее всего придеться растаться:
1)отпустить,
2)перевести на другой проект (что посути тоже самое для текущего менеджера),
3)кратковременно мотивировать, но надолго не поможет, потому все равно выбирать между пунктом 1 и 2", по крайней мере такой был опыт автора.

Очень запомнился доклад\рассказ о своей личной карьере Славы Панкратова: в своей жизни он подходил к себе, как к эдакому компьютерному персонажу - "что бы мне такого прокачать, чтоб получить lvl-up". И постепенно прокачивал: "тестирование" - стал тестировщиков, "тестирование + говорить" - стал тест-лидом, "тестирование + говорить + писать" - тест-менеджер, и так постепенно прокачивая то чего не хватает докачался до своего бизнеса консультантом, тех. дира Яндекса.Украины, Директора УЦ Люксофта, и сейчас опять качается до собственника своего учебного бизнеса. Цинично и практично, и немного удачи, но сработало и еще как!
Респект ему, не все на такое способны :)


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

Психбольница и ты %username%!

Не далее, как в прошлые выходные осилил прочесть "Психбольница в руках пациентов" Алана  Купера. Замечательное чтиво по поводу простоты, сложности и создания именно того, что нужно пользователю.
Чтиво написано простым и понятным языком, и хотя Автор усиленно кроет программистов-пациентов (к коим и я себе причисляю) все равно оставляет неизгладимое впечатление собственного просветления.

Attention! Многа букав!

О чем же оно:
Понял, как жестоко я был не прав всю свою программерскую жизнь=)

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

Для подтверждения хочется привести пример из книги:

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

Для доказательства этого тезиса проектировщик взаимодействий Скотт Мак-Грегор на своих занятиях использует вот такой замечательный тест. Он описывает продукт с помощью перечня функций и просит слушателей записать, что это за продукт, как только они догадаются. Он перечисляет:
1) двигатель внутреннего сгорания;
2) четыре колеса с резиновыми покрышками;
3) трансмиссия, связывающая двигатель с ведущими колесами;
4) трансмиссия и Двигатель смонтированы на ходовой части;
5) рулевое колесо.

На этот момент времени каждый слушатель уже записал, что это автомобиль, но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя:
6) быстро и легко срезает траву;
7) на этом удобно сидеть.
На основании пяти функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка. Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.

Читал и плакал! ;)

Плакаль

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

Сам использую и зачастую создаю программное обеспечение с раздражающими интерфейсами (а ведь еще Скотт Беркун писал что раздражать людей - последнее дело).

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

Помимо казалось бы банальные советов не использовать неудобное ПО, которое вам не нравиться. Но его так же не следует Создавать, т.к. в итоге и оно выйдет боком, опять же процитирую:

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

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

Не только об интерфейсах:
Вот с чего бы юзабилисту рассуждать об архитектуре и дизайне ПО ? Ведь интерфейс - он от бизнес логики MVC отделен или еще как. Но нет и тему рефакторинга и переписывания заново затрагивают:

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

Типичный представитель
 10 летнего ПО =) 

Читал и чувствовал боль и искреннее понимание.

Сейчас приходиться и в прошлом приходилось работать с 5-10 летними программными монстрами, которые имеют несколько слоев кода написанных в разных стилях, пару разных слоев абстракции Бд и ТЫСЯЧИ хаков, чтоб поддержать еще и вот эту логику.

Эдакий мясной рубцовый-мутант =)

То же самое относиться и к использованию прототипов в качестве основы для будущего по (ну жалко же выбрасывать!).
Только тут вы сразу начинаете с нежизнеспособного мутанта с 10ю поддерживающими его костылями.
Это кстати можно сказать обратная сторона ажайл-разработки, как только показана первая РАБОЧАЯ версия программы, выкинуть и переписать ее уже будет сложно.

Так что :

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

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

Лучший способ сделать программу дружелюбной к пользователя поставить на коробке штамп "USER FRIENDLY".
Зачастую в составляющей программы заинтересовано 3 стороны:
бизнес - "продукт овнер", тот кто заинтересован на ней навариться,
технари - "тестеры, бэкэндеры, фронтэндеры", те кто ее разрабатывают,
проектировщики\юзабелисты, те кто предоставляют голос пользователя.
Так вот для успешного продукта не достаточно только первых и вторых, такой продукт может продаваться и быть монополистом на рынке, но как только придет конкурент который позаботиться о пользователе, так и вашему продукту настанет крышка.


Как пример приводиться 3 компании: Novell, Microsoft & Apple.

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

Programmers VS Users

Красной линией по всей книге идет черта: позволять программистам проектировать софт - не правильно. 
Так как программист это Homo logicus, а не обычный Homo sapiens.

Мы - программисты отличаемся от обычных людей по 4 важным пунктам:

• Программисты пожертвуют простотой ради контроля. 
• Мы предпочтем более но сложную, но понятную систему магическому "черному" ящику.
• Для хомо логикус контроль - цель, тогда как сложность - просто цена, которую они готовы платить за достижение цели.
• Обменяют успех на понимание.
• Хомо логикус не может устоять перед тягой познания - он просто обязав узнать, как работают вещи. Хомо сапиенс же, напротив, стремится к достижению успеха.
• Программистам знакомо желание добиться успеха, но они часто принимают провал как цену, уплаченную за понимание.
• Они сосредотачиваются на исключительных ситуациях вместо того, чтобы сосредоточиться на типичных. 
• Нужно обработать и этот возможный вариант! (с) Я, более 1000 раз за всю свою жизнь
• И, наконец, ведут себя грубо и прямолинейно, как быки.

  

  Типичный программист

  
  

• Мы смотрим свысока на тех, кто не способен разобраться в этом не совсем интуитивном функционале: 
• Ну что за идиот! В мануале ж все написано!
• Кто смотрел Футураму ?) 
• Кому (из программистов) НЕ нравиться Бендер ?) 
• Всем нравиться! 
• Дык Бендер это сферический программист в вакууме!
• Логичный (робот же), приямолинейный (честый =)) и грубый =)

Подпишусь под каждым пунктом!


Итого: mustread!

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

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

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

А так же главные фичи книги, средство избавление от всех болезней, ответ на главный вопрос жизни, вселенной и всего такого, работающие практики: 

Целе-ориентированное проектирование и Персоны

Если вы вы слышали краем уха про agile-проектирование продуктов для пользователя, так вот все это копи-паста с ЭТОЙ книги. 

Удачного чтения и спасибо за рыбу!

Что почитать. Список.

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

И соответственно пошарил его со своими знакомыми.

И вот что-то неприятно мне, что такой труд пропадает зря (т.к. реально им воспользовалось отсилы человек 10, и что еще хуже дополнило его тоже человека 3-4).

Посему отпускаю список в свободное плаванье в интернет, я его пополняю сам и надеюсь иногда его пополняют другие)

Велкам, использовать и дополнять:

Линк: https://spreadsheets.google.com/ccc?key=0Ak_zA4oHbdpWdF9KZlFDbl9remx4VjA1Y1hadGJoY2c&authkey=CKPG4rcO&hl=en#gid=0

Peopleware(Человеческий фактор).

Прочитал недавно классику мировой фантастики менеджмента - сабж От Демарко и Листера)

Коротко расскажу, чтоб было нового и интересног из того, что запомнилось:

Интересное:

1) Книга  наполнена яркими тезисами, которые так и не терпится выписать и наклеить на стену (читал в оригинале потому и тезисы на англиском):

• The major problems of our work are not so much technological as sociological in nature.
• We Haven't Got Time to Think About This Job, Only to Do It
• People under time pressure don't work better; 
• they Just work faster
• Quality, far beyond that required by the end user, 
• is a means to higher productivity.

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

2) Том Демарко и Листер обыденно говорят, что ничего такого волшебного не случиться и никакая мега-нова методология\технология и т.д. не помогут выполнять проекты на 100 % лучше, попутно обсуждая, что "Программы Улучшения Процессов"(на примере CMM) ни разу не помогают , т.к. ведут к эффективному производству того, что вы итак умели делать. Что ведет к снижению рисков, но обратным эффектом будет снижение создаваемой ценности и доходности бизнеса. Довольно спорный момент, т.к. отсутствие таких программ ни разу не дает гарантий улучшений чего-либо в ближайшей перспективе и насколько мне известно ВСЕ программы улучшения процессов нацелены именно на долгосрочное развитие.

3) Целая ЧАСТЬ(2-ая) посвящена вопросам обстановки офиса и обустройства пространства дабы работать было комфортно:

- Удивительно, что ДО СИХ ПОР (проблема с местом\посторонним шумом\постоянными отвлечениями актуальна на всех работах, где мне приходилось работать) такое положение дел еще действует.

- Об этом не высказался только ленивый): например Саша Орлов на PmDays еще в далеком 2008м, где-то еще слышал историю(ссылку не найду) от Славы Панкратова про невозмутимого тестировщика, которого отвлекали по 50 раз на дню.

- Авторы предлагают метрику E-Factor эффективности офисного пространства: количество ЦЕЛЫХ(совсем без отвлечений на посторонние звуки) часов деленное на количество часов проведенное на работе, которое удалось провести без единого прерывания. 

Кто-нибудь готов сказать что он хотя бы дотягивает до 0.5 не говоря уже от 0.8-0.9 ?).

4) Хотя авторы и против всяких монструозных программ улучшений процесса, но меняться всеравно надо иначе отстанешь, станешь древним диназавром ну и т.д.

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

Соответственно надо уметь выбрать тех, кто станет твоими союзниками в изменениях:

из 3х групп: 

1) Те, кто слепо последуют за новой идеей

2) Те, кто будут задавать вопрос: что в этом для меня ?

3) Те, кто категорически будут отрицать ее.

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

При прочтении вспомнился замечательный доклад на ту же тему от Хенирка Кенинберга Everyone likes change, but nobody likes to be changed (Henrik Kniberg, AgileDays-2011)

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

2) Внезапно откровением, оказалась глава  в которой Авторы рассказывают, что закон Паркинсона не совсем работает, и наиболее продуктивными оказываются те команды у которых нет дед-лайнов и оценок размера работ (всетаки оценка работ - waste, в самом тру-lean смысле).
Хотя с другой стороны может быть они уже были настолько круты и продуктивны, что оценка работ действительно не была нужна.

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

3.5) Опять же понравилась история про(внимание барабанная дробь) ЧОРНУЮ КОМАНДУ ТЕСТИРОВЩИКОВ! Суть которой в том, что компания сумела создать такую команду, которая выработала свою философию "деструктивного" тестирования и находила в этом свой fun & lulz, и дух и философия этой команды даже пережила уход ВСЕХ изначальных членов этой команды.

4) Вроде бы очевидная вещь и баян, но все же этому разделу посвящена опять же целая часть:

"IT'S SUPPOSED TO BE FUN TO WORK HERE" - компания должна быть такой, чтоб работать было интересно и не скучно. Дюди должны чувствовать, что компания вкладывает в них и заботится о них и подразумевается, что люди останутся в ней надолго. Соответственно если компания хороша - у нее очень маленький отток людей (Гм, это наверно классный критерий оценки\поиска работы !).

Итого:
Количество полезных идей\на символ (думаю отличная метрика для книги) в книжке зашкаливает, посему - must read (но вы ведь это знали и без меня, так ведь ?).

Инженерные практики: Модель принятия инженерных решений Евгения Кривошеева

Дисклаймер:

Стас Фомин(http://belonesox.moikrug.ru/) регулярно негодует, что последствия конференций как-то не видны: т.к. первые два-3 дня видна отдача в виде отчетов а потом про них все забывают, и как-бы 5-6 отчетов\упоминаний не слишком выдающийся результат для такой огромной кучи усилий как собрать конференцию =)

Потому периодически пересматриваю и пытаюсь отписывать фидбэк)

Так вот вместо того. чтоб слать его лично ему, можно ж написать в блог и пользу от фидбэк`а получат больше чем 1-2 человека =)

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

Полезная часть: =)

Небольшой предварительный список вопросов:

- Я могу сказать - почему у меня столько классов сколько их сейчас ?

- Я могу сказать - что для меня важнее гибкость или просто кода ?

- Я могу сказать - зачем я применяю\не применяю определенный паттерн в данном месте ?

- Я могу сказать - чем обоснована моя стратегия деплоя релизов на продакшен ?

- У меня (в моей компании) знают, что такое architectural guidelane и они есть ?

И т.д., если хоть на один вопрос вы ответили - "нет", то видео надо обязательно посмотреть.

Собственно ссылки на само видео презентации Евгений Кривошеева "Модель Принятия Инженерных решений": ekr's blog: Бухтелово на AgileDays2011 или http://vimeo.com/22162357.

Докладчик говорит вполне живо и бодро потому: максимальное ускорение при просмотре можно выставлять на уровне 1.3х =)

Рассказывает вроде бы и очевидные вещи, которые всем нам (ну точнее всем, кто учился на инженера) преподавали еще в институте: "Сначала думай, а потом делай", и если ты не можешь сказать ПОЧЕМУ ты так сделал и ПОЧЕМУ оно будет работать - то это не инженерное решений (по-моему доказательство и сдача лаб по схемотехнике, это до сих пор самое сложное, что мне приходилось делать за всю свою жизнь, как инженеру =)) .

А в процессе работы все , как всегда сводиться к: "По привычке (из-за лени) сделал, как в прошлый раз, потому, что мозг так натренировался."

Это надо исправлять и не в последнюю очередь смотря такие доклады и просто немножко включая голову при проектировании.

Потому смотреть и запоминать, а через месяц проверить прижилось ли в голове и посмотреть еще раз, и повторять до тех пор пока не приживется!

Тем кому понравилась презентация рекомендую посмотреть еще и видео Архитектура в Agile — переосмысляя идею модульности и компонентности (Андрей Бибичев, AgileDays-2011), про ажайл там ан самом деле ровным счетом ничего =) Но излагаются хорошие инженерные практики и стремление думать головой, а не спинным мозгом.

Послесловие:

Вообще удивительная вещь доклады и конференции: вроде бы рассказывают очевидные вещи, но ты все равно так не делаешь\не задумываешься о том, как делаешь до тех пор пока не ткнут носом.

А на конференцию по ажайлу можно ходить даже вы этот ажайл на дух не переносите хорошие инженерные практики (о которых конференция чуть ли не на 50%) полезные в любой методологии.

Прочел Programming Erlang

Хорошая вещь праздники: появляется время поделать что-то из списка "сделать когда-нибудь")

Прочел: Programming Erlang: Software for a Concurrent World  Joe Armstrong`а.

Книжка читается легко и довольно шустро: видно, что автор знает в каком порядке надо раскрывать тему. 40-60% написанного знал и нещадно пролистал вскользь.

Новым/Интересным оказалось:
- устройство Mnesian и ETS\DETS таблиц. (небольшой LOL: Mnesia произошла от Amnesia, но босс сказал им что название не годное - у них не может быть БД, которая "забывает" вещи)
- описание в приложениях об встроенных дебаггере, инструменте проверки покрытия кода и профилирования: чуваки круты что все это есть из коробки, а не через танцы с бубнами и матюгами
- про работу с "портами"(интерфейсы к другим языкам): все таки работа почти что через отдельный сокет\байтовый буфер - овер-гемморой, теперь понятно почему все предпочитают делать REST/Thrift-интерфейсы к своим эрланговским продуктам.

Думаю ее можно прочесть и сразу приступать программировать: Единственное, что все таки вокруг паттерн-матчинга и местами хитроватых стак-трейсов(особенно если еще и супервизор там есть) стоит завернуть свои мозг.