Оно github.com/Egobrain/oauth_cowboy/blob/master/src/oauth_to_functions.erl?

На самом деле Вы классно сделали. Таки, довели до конца задумку Ники.
Единственное, сразу возникает желание завести что-то типа generic decorator
и потом от него наследоваться. Вы об этом думали?

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

В вашем случае каскад декораторов отработает корректно?

it depends в обоих случаях.

А потом, по сути все равно будет О(1), ибо ««вряд ли придет в голову динамически создавать десятки сотни, тысячи полей.
Проплисты — можно матчить как обычные списки, возможно придется учитывать порядок следования, но если производительность важнее, то можно и потерпеть такие неудобства.

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

черная магия parse_transfotm

что в нем чего-то таки не хватает.

Статической типизации, каррирования, монад)) Но как это обойти во общем-то понятно. Но это тоже «черная магия».

State хранится в record

А чем Вам proplists не угодили? Они конечно медленее, но тут применимы.

На тему мемоизации, то, что вы реализовали, это скорее безвременное кеширование.
Интереснее было бы через декораторы реализовать настоящую мемоизацию.
что-то типа
gist.github.com/2875252
Через Y-комбинатор. Но не сильно понятно, как на это можно навесить декораторы, так чтобы не пришлось описывать уродским не очень удобным образом функции.

fibimpl(Self) ->
    fun
        (0) -> 1;
        (1) -> 1;
        (N) when N > 1 ->
            ((Self)(N - 1)) + ((Self)(N - 2))
    end.

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

Недоделанный перевод (моего авторства) оригинальной статьи
gist.github.com/2919244
Таки так и не осмелился опубликовать таки, ибо все таки не уверен, что будет полезно в серьезных проектах.

>Курс рассчитан на практикующих iOS-разработчиков

А какой таки уровень подготовки требуется?

Возможно я ошибаюсь, но «Интерпретатор» тов. Нил затронул совсем поверхностно. Я думал, что будет показано как можно красиво и декларативно реализовать разбор грамматики.

dirty_read? Будут потери, но тут это не сильно важно.

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

Мне кажется, что быстрый поиск тут менее важен, чем медленная вставка.
Тем более где у Вас поиск по ключу? При set вставка будет за константное время (из документации, по тестам не совсем), для ordered_set за логарифмическое. На больших объемах данных становится очень заметно.

+ со временем при больших таблицах могут возникнуть проблемы для remove_old_limiters/0. ets:select_delete, да и все ets:select* выполняются атомарно. До тех пока поиск не произведется никакие управление другому потоку передано не будет. Возможно, имеет смысл посмотреть в сторону ets:first() ets:next(). Удаление происходит реже чем вставка, потому мне кажется, можно в отдельном потоке обходитьь и всю таблицу. Но для реальных условий надо тестировать.

+ мне кажется для реальных условий совсем не помешает иметь пул таких приложений, но с одной ets. Для создания пула можно воспользоваться github.com/devinus/poolboy.

Есть несколько вопросов по коду.
1) Зачем ordered_set? + Зачем Вы имя именованной ets загоняете еще в макрос?
2) В чем был смысл оформления алгоритма в виде отдельного приложения?

Спасибо, но ведь Вы по какой-то причине используете именно его, а не Mochiweb?

По README они вроде все хороши, но под нагрузкой, и в условиях (аврала) | ( истерики (руководства)|(инвесторов)) проявляются различные особенности.

А он умеет все что умеет Mochiweb? Никаких подводных камней?

Самый «shii» что fun2ms реализована через parse_transform и это самый fun нельзя более нигде определить.

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

Хехе, эту тему озвучивал полгода назад, победителям прошлого росимкапа — забраковали.
К сожалению, уже не смогу стать участником. Если у кого-то будут вопросы по алгоритмической части этой идей — смело обращайтесь. Штука сама по себе простая (cм statmt.org). Здесь, еще, очень к месту подойдет использование Azure.

Замечание: если что-то пишите, пишите хорошо и правильно сразу. Это дольше и сложнее, и вроде как ни к чему, но в условиях аврала конкурса, вам возможно что-то придется переделывать на ходу. Если изначально все сделано аккуратно, то потом менять что-то проще.

Весьма полезный комментарий, только последний абзац немного не понял.

Очень позитивная статья.

это вытеснение из HTML5 всех стилевых элементов, общая нежелательность использования inline-стилей, в том числе, с точки зрения производительности.

Что тут имелось ввиду?
Мне не желательно использовать id и class для тегов?
Сам тесты не проводил, но насчет производительности, говорят, что

t(.class) < t(.id) < t(tag)