Tagless Final подход остаётся горячей темой в ФП-комьюнити. До сих пор практически не существовало инструментов, способных облегчить жизнь TF-адепту. Библиотека Tofu пытается решить эту проблему, предоставляя удобные абстракции для создания простого, честного и тестируемого ФП-кода.
Приёмы функционального программирования в обычном JavaScriptPavel Klimiankou
Что можно привнести в объектно-ориентированный JavaScript из функционального программирования, не переходя в секту свидетелей монад. В программе:
1. Immutability
2. Просто функции
3. Непросто функции
4. Комбинация ООП/ФП
5. Функторы
6. Ок, монады
Отладка производительности приложения на Erlang / Максим Лапшин (Erlyvideo)Ontico
Байткод эрланга выполняет очень хорошо отлаженная виртуальная машина BEAM, которая превосходно работает даже на современных 72-х и более ядерных компьютерах.
Ключевая возможность эрланга в том, чтобы использовать все ядра в одном приложении, т.е. иметь в памяти одни и те же данные и обеспечивать к ним доступ без запуска кучи экземпляров одного и того же приложения по количеству ядер.
С ростом обрабатываемого трафика данных начинают возникать проблемы с многоядерным доступом к данным, возникают бутылочные горлышки и более низкоуровневые проблемы синхронизации.
В этом докладе будет рассказано, какие есть методы поиска, анализа, замера и устранения различных проблем, связанных с многотредностью: синглтонные процессы, простаивания на мьютексах и т.п.
Приёмы функционального программирования в обычном JavaScriptPavel Klimiankou
Что можно привнести в объектно-ориентированный JavaScript из функционального программирования, не переходя в секту свидетелей монад. В программе:
1. Immutability
2. Просто функции
3. Непросто функции
4. Комбинация ООП/ФП
5. Функторы
6. Ок, монады
Отладка производительности приложения на Erlang / Максим Лапшин (Erlyvideo)Ontico
Байткод эрланга выполняет очень хорошо отлаженная виртуальная машина BEAM, которая превосходно работает даже на современных 72-х и более ядерных компьютерах.
Ключевая возможность эрланга в том, чтобы использовать все ядра в одном приложении, т.е. иметь в памяти одни и те же данные и обеспечивать к ним доступ без запуска кучи экземпляров одного и того же приложения по количеству ядер.
С ростом обрабатываемого трафика данных начинают возникать проблемы с многоядерным доступом к данным, возникают бутылочные горлышки и более низкоуровневые проблемы синхронизации.
В этом докладе будет рассказано, какие есть методы поиска, анализа, замера и устранения различных проблем, связанных с многотредностью: синглтонные процессы, простаивания на мьютексах и т.п.
В докладе мы рассмотрим создание переносимого дистрибутива Python для любых нужд и операционных систем (Windows & Linux). Познакомимся с существующими и альтернативными решениями. Сравним их достоинства и недостатки.
Докладчик: Григорий Кареев (Odin)
Видео: https://www.youtube.com/watch?v=fvBJG_IKvaQ
Индустрия меняется прямо на глазах. Технология, еще вчера проходившая по категории "модно, но не нужно", сегодня используется даже бомжами, а завтра выбрасывается на свалку. Что учить, куда смотреть, какие книги читать? Я попробую рассказать свой взгляд на серверное программирование сейчас, в 2016 году.
SECON'2016. Тюменцев Евгений, Разработка надежных параллельных, распределенны...SECON
Набор практических приемов, которые позволяют создавать сложные многопоточные, параллельные, распределенные серверные приложения программистам без опыта сетевого и многопоточного программирования, работы с базами данных.
ELK: менеджмент логов, быстрая локализация проблем / Сергей Шумов (News360)Ontico
Сначала несколько слов про предпосылки задачи.
1. Что нам завещали деды: zcat | cut | sort | uniq -c | sort -nr . На самом деле, нормально работает, когда на проекте есть только лог nginx и не больше пары ГБ в день. В случае аварий tail -f | grep позволяет найти проблему за пару минут.
При первой же попытке параллелизации инстансов работать становится неудобно, нужна
2. Сборка логов: syslog-ng, rsyslog etc. Логи с локальных syslogd по UDP агрегируются в одно общее файловое хранилище.
Помогает собирать файлы логов с разных инстансов или сервисов. Минусы:
* Мы по-прежнему ограничены общим объемом логов. Текущие аварии на одном сервисе локализуются сравнительно быстро, но ретроспективная статистика строится часами.
* Появляются неприятные артефакты: задержки при доставке логов в хранилище, неупорядоченность событий в логах из-за разной задержки на разных инстансах. Последнее - вообще, беда, так как по-хорошему требует полной пересортировки лога.
* Поскольку события хранятся как строки в файлах логов, нет жесткой необходимости соблюдать формат. Значит, он соблюдаться и не будет. Нет, все будут стараться, но косяки все равно постоянно будут возникать.
* Отвратительно (муторно, медленно, вручную) работает трекинг проблемных реквестов, особенно в сложных системах с десятками взаимосвязанных сервисов.
3. Ок, давайте сделаем все правильно:
* для всех логов будет описан формат полей;
* события вместо файлов будут храниться в горизонтально масштабируемой БД;
* большинство агрегатов будет рассчитано заранее.
Дальше пара слайдов про компоненты ELK и переходим к главному: как Kibana помогает в локализации проблем.
Полезные фичи Elastic & Kibana:
* мгновенное масштабирование от месяцев до долей секунд;
* статистика распределения для каждого поля по любому диапазону и фильтру;
* field templates;
* significant terms filtering;
* geohashing;
Несколько кейсов, где Кибана выступает отлично:
* Получение списка объектов/пользователей, на которых возникают проблемы;
* Трекинг связанных проблем на разных сервисах;
* Просмотр сессии конкретного пользователя;
* Выявление аномальных пользователей (ботов);
* Отслеживание последующих действий пользователей, попавших во всплеск активности. Средства вроде graphite визуализируют только суммарные значения, а сильная сторона Kibana именно в трекинге отдельных пользователей.
Метрики и дашборды: тут они с graphite примерно одинаково гибки, но упомянуть об этом надо.
* Как отслеживать связанные события в разных логах? Связка через общий request_id vs полное добавление контекста в событие.
* LogStash vs fluentd для доставки? Мы выбрали fluentd - меньше затраты ресурсов.
Кратенько об альтернативах, плюсы-минусы:
* realtime log readers: LogWatch
* LaaS: Splunk
Планирование требуемых ресурсов, (не-)линейность масштабирования.
В докладе мы рассмотрим создание переносимого дистрибутива Python для любых нужд и операционных систем (Windows & Linux). Познакомимся с существующими и альтернативными решениями. Сравним их достоинства и недостатки.
Докладчик: Григорий Кареев (Odin)
Видео: https://www.youtube.com/watch?v=fvBJG_IKvaQ
Индустрия меняется прямо на глазах. Технология, еще вчера проходившая по категории "модно, но не нужно", сегодня используется даже бомжами, а завтра выбрасывается на свалку. Что учить, куда смотреть, какие книги читать? Я попробую рассказать свой взгляд на серверное программирование сейчас, в 2016 году.
SECON'2016. Тюменцев Евгений, Разработка надежных параллельных, распределенны...SECON
Набор практических приемов, которые позволяют создавать сложные многопоточные, параллельные, распределенные серверные приложения программистам без опыта сетевого и многопоточного программирования, работы с базами данных.
ELK: менеджмент логов, быстрая локализация проблем / Сергей Шумов (News360)Ontico
Сначала несколько слов про предпосылки задачи.
1. Что нам завещали деды: zcat | cut | sort | uniq -c | sort -nr . На самом деле, нормально работает, когда на проекте есть только лог nginx и не больше пары ГБ в день. В случае аварий tail -f | grep позволяет найти проблему за пару минут.
При первой же попытке параллелизации инстансов работать становится неудобно, нужна
2. Сборка логов: syslog-ng, rsyslog etc. Логи с локальных syslogd по UDP агрегируются в одно общее файловое хранилище.
Помогает собирать файлы логов с разных инстансов или сервисов. Минусы:
* Мы по-прежнему ограничены общим объемом логов. Текущие аварии на одном сервисе локализуются сравнительно быстро, но ретроспективная статистика строится часами.
* Появляются неприятные артефакты: задержки при доставке логов в хранилище, неупорядоченность событий в логах из-за разной задержки на разных инстансах. Последнее - вообще, беда, так как по-хорошему требует полной пересортировки лога.
* Поскольку события хранятся как строки в файлах логов, нет жесткой необходимости соблюдать формат. Значит, он соблюдаться и не будет. Нет, все будут стараться, но косяки все равно постоянно будут возникать.
* Отвратительно (муторно, медленно, вручную) работает трекинг проблемных реквестов, особенно в сложных системах с десятками взаимосвязанных сервисов.
3. Ок, давайте сделаем все правильно:
* для всех логов будет описан формат полей;
* события вместо файлов будут храниться в горизонтально масштабируемой БД;
* большинство агрегатов будет рассчитано заранее.
Дальше пара слайдов про компоненты ELK и переходим к главному: как Kibana помогает в локализации проблем.
Полезные фичи Elastic & Kibana:
* мгновенное масштабирование от месяцев до долей секунд;
* статистика распределения для каждого поля по любому диапазону и фильтру;
* field templates;
* significant terms filtering;
* geohashing;
Несколько кейсов, где Кибана выступает отлично:
* Получение списка объектов/пользователей, на которых возникают проблемы;
* Трекинг связанных проблем на разных сервисах;
* Просмотр сессии конкретного пользователя;
* Выявление аномальных пользователей (ботов);
* Отслеживание последующих действий пользователей, попавших во всплеск активности. Средства вроде graphite визуализируют только суммарные значения, а сильная сторона Kibana именно в трекинге отдельных пользователей.
Метрики и дашборды: тут они с graphite примерно одинаково гибки, но упомянуть об этом надо.
* Как отслеживать связанные события в разных логах? Связка через общий request_id vs полное добавление контекста в событие.
* LogStash vs fluentd для доставки? Мы выбрали fluentd - меньше затраты ресурсов.
Кратенько об альтернативах, плюсы-минусы:
* realtime log readers: LogWatch
* LaaS: Splunk
Планирование требуемых ресурсов, (не-)линейность масштабирования.
Алексей Куканов — Параллелизм в C++: управляйте приложением, а не потоками!Yandex
Алексей Куканов, Intel.
Последняя версия стандарта С++ добавляет в язык и библиотеку поддержки средства для использования потоков исполнения (threads) и синхронизации между ними. Однако это лишь необходимая низкоуровневая база для внедрения параллелизма. Эффективная разработка параллельных программ требует высокоуровневого API, реализующего типичные шаблоны использования параллелизма в виде, пригодном для применения в широком спектре алгоритмов и приложений. В докладе речь пойдёт о наиболее часто встречающихся параллельных шаблонах, реализованных в программных моделях Intel® Threading Building Blocks и Intel® Cilk Plus, и о примерах их использования.
Карта граблей на поле сбора и доставки логов. Lazada-way.Yury Bushmelev
Слайды с моего доклада на HL++ 2017 о том, как мы в Лазаде строили систему сбора и доставки логов, с какими трудностями мы при этом столкнулись и какие выводы сделали.
Карта граблей на поле сбора и доставки логов. Lazada-way / Юрий Бушмелев (Laz...Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/3036.html
Логи — важная часть системы, позволяющая понять, что она работает (либо не работает), как ожидается. В условиях микросервисной архитектуры работа с логами становится отдельной дисциплиной специальной олимпиады. Нужно решить сразу кучу вопросов:
- как писать логи из приложения;
- куда писать логи;
- как доставлять логи для хранения и обработки;
- как обрабатывать и хранить логи.
...
2. О чём поговорим
• Что такое Tofu
• Зачем оно нужно?
• Из чего состоит Tofu
• Немного о его ингридиентах
• Немного (много) об Env
3. О чём не поговорим
• Что такое тайпклассы
• Что такое Cats/Cats-Effect
• Что такое Tagless-Final
4. Что такое Tofu?
• Набор инструментов для удобного ФП
• Множество удобных абстракций
• Родился из внутренних fputils
• Отлично сочетается с Tagless-Final стилем
• https://github.com/TinkoffCreditSystems/tofu/
• Production-ready, чистое value!
5. Зачем нужно Tofu
• Несовершенство текущей иерархии тайпклассов Cats/Cats-Effect
• Есть вопросы к расположению тайпклассов в иерархии
• Многие тайпклассы слишком «сильны»
• Более точный контроль над кодом/эффектами
8. Что включает в себя Tofu?
• env-monad
• optics
• memoization
• config
• logging
• атомарные тайпклассы (Context, Timeout, Raise, etc.)
9. Tofu-core
• Ядро tofu
• Содержит множество полезных тайпклассов и абстракций
• Абстрагировано от конкретных монад
• Предоставляет инстансы либо способы создания
10. Tofu-core: Fire/Race/Start
Позволяют:
• запускать вычисления в фоне с игнорированием результата
• запускать вычисления в фоне с возможностью получения
результат
• запускать несколько параллельных вычислений, возвращая
первое
13. Tofu-core: обработка ошибок
Raise:
• Позволяет прерывать цепочку вычислений (monadic fail-fast)
• Можно создать инстанс для любого ApplicativeError
17. Tofu-core: Timeout
• Позволяет прерывать вычисление после заданного интервала
• Есть инстанс для cats.effect.IO
• Можно создать инстанс для любого cats.effect.Concurrent
18. Tofu-core: Context
• Легковесная версия ApplicativeAsk
• Описывает вычисление, имеющее неизменяемый контекст
• Широко используется в tofu-logging и Env
20. Tofu-core
А также множество других полезных тайпклассов для F:
• GenUUID для генерации случайных UUID
• Lift/Unlift как аналог FunctionK[F, G] и замена cats.effect.Effect
• Тайпклассы для работы с HKT
• Аналоги Alternative из Cats
• и многое другое!
21. Tofu-logging
• Реализация логирования на тайпклассах
• Операции представлены в виде алгебры
• Логирование – это эффект!
• Структурное логирование
• Синтаксис со строковой интерполяцией
• Логирование контекста
26. Tofu-logging: Loggable
• Тайпкласс
• Описывает, как значение должно быть записано в log message
• Описывает, как значение должно быть записано в «контекст»
• «Контекст» – слабая форма построения JSON (addString, addInt,
etc.)
• Контекст может быть использован для чего угодно – ELK layout,
JSON, GELF, etc.
• Неявно конвертируется в LoggedValue
29. Tofu-logging: Loggable - syntax
• вы тоже устали от logger.{info|error|etc.}?
• мы идём к вам!
• просто добавь воды сахарка синтаксиса
• сам подхватит Logging из скоупа
• сам попросит Loggable для всех параметров
• сделает всё не всё за вас
33. Env-монада
• Монада для передачи «окружения» произвольному вычислению
• Доступ к контексту в любое время вычисления
• Прозрачная передача
• Вычислительный примитив – Monix Task
• Умеет всё, что умеет Task
34. Env-монада — зачем?
• Зачастую необходимо передавать вычислению контекст
• Логирование
• Использование в вычислениях
35. Env-монада — зачем?
• Можно передавать через implicit параметр
• Не очень удобно везде прокидывать параметр
• Можно забыть про него
36. Env-монада — зачем?
• Можно передавать через ThreadLocal/TaskLocal/etc.
• Для Future — написать свой ExecutionContext
• Плюсы для Future:
• boilerplate отсутствует
• Минусы для Future:
• Писать свой ExecutionContext
• Следить за context propagation на границе между Future и не-Future
(например, Akka) и прокидывать руками
• Сложно контролировать, контекст появляется «из воздуха»
37. Env-монада — зачем?
• Можно передавать через ThreadLocal/TaskLocal/etc.
• Для Monix Task — использовать TaskLocal
• Плюсы для Task:
• boilerplate меньше
• более приемлемый контроль над тем, где контекст есть, а где - нет
• Минусы для Task:
• boilerplate с параметрами всё равно есть - TaskLocal нужно передавать
параметром по коду
• отслеживание на границах с другими моделями исполнения всё равно есть
38. Env-монада — что предлагает?
l Прозрачная передача контекста
l Все функции «знают», что работают в некотором контексте
l Функции композируются
l Возможно переопределить контекст для локального скоупа
l Никаких сюрпризов с «потерянным» контекстом
40. Env-монада — что умеет?
l Работа с сайд-эффектами
l Работа с чистыми значениями
l Создание из других типов (Try/Either/Future/IO)
l Наличие tailRecM
42. Env-монада — что умеет?
l Обработка ошибок
l Повторы в случае ошибок
l Обработка с учётом контекста
43. Env-монада — что умеет?
l Доступ к контексту in a monadic way
l Возможность переопределить контекст для локального скоупа
l Контроль над параллелизмом «из коробки»
l Мемоизация
l Таймауты
45. Env дружит с tofu-logging!
l Один раз определить имплисит
l Показать, как контекст может быть вытащен и использован
l …
l Контекст автоматически вытаскивается и записывается в лог
l PROFIT!
l Документация с примерами интеграции coming soon!
46. Итоги
• Если вы пишете в Tagless-Final стиле – обязательно попробуйте
Tofu
• Если вы не пишете в Tagless-Final стиле, но вам нужны вычисления
с контекстом – попробуйте Tofu
• Если вы пишете код на Future – обязательно попробуйте Tofu и
Env/Task
• Если вы пишете код на акторах - Бог вам судья!