На правах рекламы хочу напомнить про добротный канал с вакансиями @profunctor_jobs, который может быть особо полезен ищущим удалённую работу.

Периодически попадаются вакансии для Scala и даже Haskell (!) программистов.

В этом году начал выходить приятный подкаст Scala logs со сравнительно небольшими интервью с выдающимися членами Scala-сообщества - на подходе интервью с Робом Норрисом, наиболее известным в качестве автора библиотеки для работы с БД Doobie.

По случаю релиза в России прикладываю ссылку на Spotify-плейлист подкаста, но найти его несложно и на других сервисах.

Решил опубликовать основные выдержки из одной из моих любимых книг - Functional Programming for Mortals. Когда только начинал осваиваться со Scala, книга стала большим подспорьем в изучении наряду с Functional Programming in Scala и Scala with Cats - все книги однозначно рекомендуются к прочтению.

В этом году начал выписывать занятный IT-журнал Increment. Люди, работающие над журналом, ответственно подошли к своей работе - каждый выпуск включает в себя подборку качественных статей, соответствующих определённой теме, от обработки ЧП до архитектуры ПО.

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

Всячески рекомендую к прочтению.

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

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

Давно являюсь поклонником тестирования свойств (e.g. scalacheck), но теперь надеюсь получить более фундаментальные знания в этой и смежных областях.

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

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

Альтернатива проекту Descartes, использованному в работе для мутационного тестирования, имеется и для Scala - плагин stryker4s. Хотя экстремальные мутации (замена тела метода на константу) им не поддерживаются, плагин всё равно позволяет эффективно находить "псевдопротестированные" методы.

Недавно на работе обсудили структурирование классов моделей предметной области в Scala, и стало интересно мнение подписчиков канала. Как вы предпочитаете объявлять классы, единственная роль которых - содержать в себе данные? Речь идёт как о случаях Алгебраических Типов Данных (ADT), так и всех остальных.

Пару недель назад возникла необходимость загрузить новую версию внутренней зависимости в legacy проект. Выяснилось, что пропала бинарная совместимость в библиотеке json4s (с ошибками в рантайме), и попытки вручную выправить версии зависимостей приводят только к бо'льшим конфликтам. Как результат, уже некоторое время активно удаляем старые ненужные зависимости, параллельно поэтапно обновляя необходимые.

Главный вывод - не пренебрегайте инструментами вроде Scala Steward и explicit-dependencies и регулярным аудитом зависимостей через команду sbt evicted, даже в старых проектах. Времени (а, следовательно, и денег) на регулярные обновления уходит гораздо меньше.

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

Как докладчик, так и авторы исходной статьи сходятся во мнении, что нужно стремиться к ситуации, когда одному потоку приложения (связанному с потоком ОС) соответствует одно ядро процессора (без учёта мультитрединга). Однако, поскольку строить всё приложение вокруг количества потоков в ОС часто архитектурно проблематично, а в реальных приложениях часто присутствуют системные вызовы, блокирующие поток исполнения, оптимальной на текущий момент является абстракция над реальными потоками исполнения в виде системы эффектов. Например, cats-effect предлагает оперировать логическими потоками в виде Fiber, не привязанными к потокам ОС, а для блокирующих операций выделять отдельный Executor, работа с которым тоже осуществляется через абстракцию.

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

Помню, как когда только-только начинал работать с языком Java, был жутко обрадован наличию метода toString у каждого объекта - "как же удобно будет теперь отлаживать программы", подумал я.

Однако, чем дольше работаю с JVM-экосистемой, тем больше убеждаюсь, что, как и null-указатели, toString при кажущемся удобстве на самом деле несёт больше проблем, чем пользы. Поскольку метод имеет реализацию по умолчанию, очень сложно следить за тем, где он был явно переопределён, а где - нет. Более того, этот метод не имеет чётко определённой семантики, в результате чего нередко можно встретить проекты, где toString имеет разный смысл в зависимости от класса: где-то он трансформирует объект в строку для логирования, где-то - в строку для использования в интерпретаторе и так далее.

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

В ФП-сообществе уже достаточно давно придумали альтернативу toString в виде тайпкласса Show (ссылка), который сигнализирует о наличии у класса возможности превращения в строку. В нашей команде для логирования объектов и их полей можно использовать исключительно Show, чтобы не допустить ненарочного попадания чувствительных данных в логи.

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

Full Disclosure: статья была написана на заказ, но как-либо продвигать её меня не просили.

https://tproger.ru/articles/kak-perejti-s-java-na-scala/

Впервые с 2019 года Scala Matsuri провели оффлайн и наконец довелось посетить мероприятие вживую.

Это единственное хоть сколь-нибудь крупное Scala-событие в Японии, но даже с учётом этого присутствующих было не так много - бо'льшая часть смотрела конференцию онлайн.

Был приятно удивлён разнообразием презентаций: от краткого экскурса в тип Option и до написания собственного генератора видео с виртуальными ютуберами. Также, несмотря на относительное локальное распространение Scala, компании в Японии уже не боятся использовать Scala 3 и даже кросс-компилировать проекты для разных версий Scala.

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

Чуть больше года спустя впервые с начала эпидемии Scala Matsuri наконец прошла в штатном режиме, когда большинство спикеров присутствовали лично. Впервые удалось вживую увидеться с коллегами из SoftwareMill, поговорить с Джейми Томпсоном, который работает над компилятором Scala 3 и просто посмотреть на более "живую" Scala-тусовку в Токио за пределами родной компании.

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

Неутешительно также, что с прошлого года как минимум одна крупная компания из числа спонсоров мероприятия решила отказаться от использования Scala, что ещё больше подчеркнуло локальность мероприятия - раньше компания занималась предоставлением Wi-Fi связи в павильоне, а заменить её оказалось попросту некому, в связи с чем в лекционном зале, где проходили доклады, интернета не было (совсем, даже мобильного).

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

P.S. Поход на конференцию окупил себя как минимум из-за уникального маскота-тапира одноимённой библиотеки от Адама Варски 😁