В работе с форками на гитхабе меня всегда раздражало вливание свежего мастера с оригинального проекта в свой форк.

В первый раз надо сделать

git remote add upstream git://github.com/USERNAME/REPONAME.git
git fetch upstream

Потом каждый раз вспоминать, что вместо git pull надо выполнить git pull upstream master... Который обязательно не сработает, потому что для вот именно этого проекта, с которым я сейчас работаю, пока ещё не указан upstream, так что goto 1

Иногда казалось, что проще снести старый форк и сделать новый вместо того, чтобы вспоминать команды.

А сегодня я обновил проект одной командой hub sync консольный утилиты hub от команды гитхаба, и всё просто заработало как надо 🙏

ВЫШЕЛ ВЫШЕЛ ВЫШЕЛ

Релиз Scala 2.13

Улучшенные коллекции, улучшенные Future, partial unification по дефолту, literal types и ещё куча вкусностей

Дружно тащим в прод!

Начал перетаскивать свои проектики на Scala 2.13 и сразу же обнаружил не самое приятное нововведение. Теперь в стандартной библиотеке есть по два инстанса Ordering для Double и Float, отличающихся отношением к NaN.

IeeeOrdering работает в соответствии со спецификацией IEEE, а TotalOrdering считает, что NaN больше всех остальных чисел (даже Double.PositiveInfinity).

При этом ни один из них не выбран по умолчанию. Поэтому больше нельзя написать просто List(1.0, 3.0, 2.0).sorted, надо обязательно указать, как именно будут сравниваться числа:

List(1.0, 3.0, 2.0).sorted(Ordering.Double.TotalOrdering)
// или
import Ordering.Double.TotalOrdering
List(1.0, 3.0, 2.0).sorted

Вот issue, с которого всё началось, а тут накодякана разница между ними. Как это объяснять тем, кто только начинает программировать на скале, я вообще без понятия 😔

Stephen Samuel, автор scrimage, elastic4s и ещё многих классных библиотек, сделал публичным свой список вопросов для собеседований скалистов. Он пока не завершён, но выглядит очень даже неплохо, можно растаскивать для своих собесов.

А ещё там есть файлик с заданием на system design.

Нашёл ещё один статический анализатор кода на скале — scapegoat.

Более популярный wartremover скорее ограничивает возможности языка (запрещает null, имплиситные преобразования и аргументы, и прочее). При этом он не даёт скомпилировать проект с нарушениями правил.

А scapegoat имеет больше встроенных инспекций, например:
- сравнение чисел с плавающей точкой через ==
- не идиоматичное или не эффективное использование методов коллекций
- использование contains с потенциально неверным типом аргумента и сравнение заведомо разных типов

При этом он автоматически не подвязывается к компиляции, а генерирует отчёт в html по команде.

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

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

Вот Илья Бирман написал заметку о том, как проверить строку на пустоту в php. Ему в комментариях накидали ещё семь (!) вариантов кода, из которых работает правильно только один. А всё потому что мы не знаем, какой тип на самом деле лежит в переменной и как он приведётся к строке. Например, любой массив превратится в строку "Array".

На этой неделе вышла новая версия metals (это language server для скалы, совместимый с LSP), и им, в принципе, можно пользоваться.

Работает go to definition, find references, поиск по имени класса или метода, дерево пакетов, автоматический импорт, автодополнение. Все зависимости проекта индексируются.

Перемещение по исходникам работает пока не так хорошо, как в IDEA, хотя ситуаций, когда у metals не получается найти определение метода, с каждой новой версией всё меньше и меньше. Раздражает разве что очень долгий запуск при открытии проекта.

Для больших проектов у Intellij IDEA всё ещё нет альтернатив, а маленькие либы я уже давно редактирую в VS Code с металлами. Но это история не про личную производительность, а про эстетическое удовольствие: мне просто больше нравится, как ощущается, выглядит и рендерит текст VS Code. А когда надо сделать вэлью, приходится расчехлять Intellij 🐗

Если ещё не пробовали металлы, почитайте релизный блогпост, там много интересного.

Раньше рассказывал про линтер scapegoat, а сегодня он смог меня удивить.

Проект после подключения линтера начал падать с фатальным NoSuchMethodError. Продолжительное следствие установило, что scapegoat и библиотека scalikejdbc, тоже использующая в проекте, зависят от несовместимых версий либы scala-collection-compat. При сборке в jar попадает версия от линтера, и на вызове определённого метода все взрывается.

Так я узнал две вещи:
1. Транзитивные зависимости в итоговый артефакт могут просочиться даже из sbt-плагинов 😔
2. Линтер может положить прод 💪🤟

Кто на скале программировал, тот в цирке не смеётся

Сама либа. Скала собрала, наверное, все известные человечеству подходы к работе с асинхронностью: акторы, монадки, промисы, асинк/авэйт... Оказалось, что ещё и гошные каналы 😏

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

TL;DR: вместо имплиситов введут делегаты, новый механизм будет совместим со старым, имплиситы будут потихоньку депрекейтить

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

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

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

Новость прямо очень крутая, потому что дефолтных тестов и правда не хватало, а тут ещё и очень удобный и действительно легковесный минитест🎉

Чуть-чуть поработал с проектом без scalafmt и понял, насколько сильно успел привыкнуть к хорошему.

Уже очень давно не приходилось перед каждым коммитом вспоминать о расстановке скобочек, вместо того, чтобы просто написать код всрато и скормить форматировщику.

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

.scalafmt.conf в репозитории и ✅ Format On Save в редакторе — обязательные условия комфортного программирования 💁🏻‍♂

Очевидно, что...

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

Провозился полчаса, потом взял ammonite, стандартный модуль scala-xml и за 5 минут накидал то, что мне надо. Репл подсказывает типы аргументов и возвращаемых значений, dsl максимально простой и интуитивный. Даже не пришлось писать, собственно, скрипт, хватило пары выражений в репле.

И вот непонятно: это я разучился писать на динамических языках или работать с XML в скале действительно удобнее, чем в питоне? 🤔

Мы не одобряем такие редиректы

Открылась регистрация на скала-конференцию 28 сентября в Москве 🎉

Пропустить такое событие просто преступно: 7 докладов, воркшопы про korolev и ZIO (второй проведёт сам John De Goes)! Когда ещё у вас будет возможность бесплатно поучаствовать в воркшопе Дегуза?

Осознал, что инструменты для замера code coverage немножко способствуют неправильному восприятию результатов.

Выхлоп какого-нибудь codecov можно представить как прогрессбар с зелёной полоской:
[✅✅✅ХХ] (60% кода покрыто тестами).

С практической точки зрения это означает, что 40% кода не покрыто тестами, а 60% чем-то покрыты, но гарантий качества этих тестов нет. Мы узнали не то, что можем безопасно модифицировать какую-то часть кода, а то что для остального кода тестов нет вообще и менять его ещё опаснее.

Поэтому, на мой взгляд, правильнее было бы инвертировать статистику coverage:
[❌❌✓✓✓] (40% кода не покрыто тестами!).

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

Искал документацию для scalastyle, а нашёл компанию Скала-Стиль, которая делает винтовые лестницы (почти как в EPFL!)

Если кто-то не знает, на логотипе скалы нарисована винтовая лестница из университета, а слово Scala в итальянском означает лестницу. Вот оригинальное объяснение из 2009 года.

Дошли руки (глаза?) до прошлогоднего доклада Виктора Гамова. Замечательный обзор внутреннего устройства кафки и реализации exactly once. Наверное, тем, кто только начинает трогать кафку, будет вдвойне интересно.