Найти иголку в стоге сена тяжело, но ещё сложнее найти в обширной базе нужные документы, удовлетворяющие множеству параметров сразу. Гораздо сложнее, когда поток запросов — десяток тысяч в секунду, а допустимое время на ответ исчисляется миллисекундами.

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

Еще обсудим:
* как устроены индексы;
* как хранить их вне heap-памяти;
* как использовать VarHandle;
* и почему же решение на Scala лучше.

Akka Persistence — одна из самых часто используемых Scala-библиотек для написания приложений по принципу Event Sourcing. Однако ее стандартный плагин akka-persistence-cassandra не идеален, и в нем есть несколько недостатков, которые можно исправить. В докладе мы познакомимся с подходом Event Sourcing, akka persistence, их проблемами и тем, как мы можем их исправить при помощи FoundationDB.

На докладе вы узнаете:
- как прицепить 1000 тегов к событию и не взорвать кластер;
- можно ли жить без надежного Split Brain Resolver;
- как реализовать eventsByTag, не тратя лишние дисковые ресурсы;
- как FoundationDB помогает предотвратить потерю данных при Split Brain в Akka Cluster;
- возможны ли low-latency-обновления в eventsByTag.

Рассмотрим варианты использования Scala.JS в production, когда его стоит брать, когда не стоит, возможности для применения и как жить в мире с JavaScript-разработчиками в одном проекте.

A good API is not only a pleasure to use, but also makes the code easy to read and explore. How to create a programmer-friendly API in Scala?

Does tapir succeed in that area? What kind of techniques does it use? What were the problems?

Come and find out!

У ZIO есть много значительных преимуществ перед Future. C библиотекой ZIO нет причин использовать Future, нет такого аспекта, в котором ZIO будет отставать от Scala Future.

Основные преимущества ZIO над Scala Future:
- Производительность: ZIO намного быстрее, чем Scala Future.
- Отмена и время ожидания: ZIO позволяет отменять эффекты вручную или автоматически, когда эффекты не будут использоваться.
- Безопасность ресурсов: ZIO предоставляет вам версию try / finally и try-with-resources, которая позволяет безопасно получать и освобождать ресурсы.
- Согласованность: параллельность ZIO построена на волокнах, которые являются легкими зелеными нитями, и предоставляет вам основанные на волокне версии таких вещей, как ThreadId, ThreadLocal и так далее.
- Эквациональное обоснование типов: поскольку ZIO является чисто функциональным, вы можете рассуждать о своих программах ZIO на равных; и типы говорят вам многое о том, что могут делать ваши программы.
- Тестируемость: ZIO позволяет тестировать логику любого приложения, не взаимодействуя с внешним миром.
- Управление ошибками и отладка.

Нельзя не согласиться, что JDBC слишком стар и уже неактуален. Этот инструмент видел мир без гугла и первый Ipod, он даже был хорош, но не в 2019 году. Это инструмент, который небезопасен для хранения типов данных, реактивен на изменения и плохо обрабатывает Null. Этот инструмент даже не имеет удаленного функционала для управления и плох для диагностики, он имеет ещё много минусов. Отвергнем его.

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

В своём докладе я хотел бы обратить внимание на работу с базами данных, но без JDBC. Я пронесу основную идею доклада на практических примерах работы с базой данных (в моём случае это будет Postgres):
- рассмотрим работу с сокетами (как обычными, так и векторными);
- рассмотрим IOApp;
- рассмотрим Encoder / Decoder;
- рассмотрим протоколы соединения.

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

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

Что же в нем особенного? Детский психолог Сэм Васс провел исследование, в котором выяснил, что дети задают до 73 вопросов каждый день — так они быстрее познают мир. Эта же стратегия помогает развиваться студентам, стажерам и джуниор-девелоперам!

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

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

Как часто вам не хватало встроенных в библиотеку средств кастомизации макро-генерируемых инстансов и приходилось писать инстанс вручную? А сколько раз "разъезжались" форматы представления sealed trait'ов при переходе с одной библиотеки на другую?

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

Writing typeclass instances for your business types can be long and tedious. But once I’ve shown you how it is done by SchemaZ, using only simple algebra notions and the power of recursion schemes, I hope we’ll all agree: deriving typeclasses with SchemaZ? EZ katka!

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

Http services & clients? Database access? Parsing? Stream processing? Typesafe data? Let’s go for a journey through creating a real-world app and see how well-integrated libraries can make our life better than any framework could. All of that in purely-functional sauce.

Technology has always been dominated by hype, and the Scala ecosystem is no exception. From language features to libraries, tools to techniques, and patterns to paradigms, evaluating the dazzling number of wares in the ecosystem can be intimidating and confusing, even for experienced Scala developers.

In this fast and furious presentation, John A. De Goes will take you on a sometimes harrowing, sometimes entertaining look across the Scala ecosystem, with an emphasis on the functional side, offering an opinionated and uncensored take on all the hype in Scala.

Come learn about the snake oils and elixirs of the Scala language and ecosystem!

Приличные (для некоторого определения приличности) языки программирования должны основываться на теоретических принципах, в противном случае они больше напоминают лоскутное одеяло из плохо стыкующихся друг с другом элементов. Забота о приличности языка Scala привела его разработчиков к необходимости соответствующие принципы сформулировать, так возникла модель DOT — система типов с зависимыми объектами.

Не факт, что наличие формальной модели поможет языку Scala 3 стать, наконец-то, приличным — все ли его элементы можно будет выразить в DOT? Ответа на этот вопрос я пока не знаю, может, после доклада мне кто-то это разъяснит. Я же в докладе буду говорить о том, что модель DOT собой представляет, попутно вводя необходимые элементы и общие принципы теории типов. Для понимания доклада желательно знать Scala, но разбираться в теории типов необязательно.

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

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

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

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

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

О GraalVM не слышал только ленивый: новые оптимизации, интеграция с Python/Ruby/JS и AOT-компиляция в нативный код. На любой JVM-конференции из каждого утюга рассказывают, как изменится наша жизнь к лучшему с приходом коммунизма^W этой технологии. Но вот о чем обычно не рассказывают — так это об ограничениях и особенностях этой технологии, с которыми вы наверняка столкнетесь, если попытаетесь пойти хоть немного дальше hello-world.

В этом докладе мы попытаемся выяснить, ради чего это может понадобиться на практике и какие проблемы могут возникнуть при попытке протащить GraalVM в свой scala-проект:
* AOT-компиляция не компилирует;
* АОТ-компиляция таки иногда компилирует, но код почему-то тормозит;
* Reflection не рефлексирует;
* в тридесятой транзитивной зависимости нашелся хитрый неподдерживаемый MethodHandle;
* у вас Akka.

Часто ли вам приходится искать данные в структурированной, но очень зашумленной базе с действительно большим объемом данных? Из этого доклада вы узнаете, как это делаем мы -- оператор фискальных данных Первый ОФД.

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

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

В докладе я расскажу, как мы это делали, с какими проблемами столкнулись и, конечно, покажу, что же из этого вышло. Вы увидите, как делать exploratory data analysis и визуализацию в Zeppelin прямо из IDEA, как мониторить задания и работать с удаленной файловой системой прямо из вашей любимой среды разработки.