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

Удалить все слитые с мастером:

git branch --merged | grep -v master | xargs git branch -d

Удалить все не влитые в мастер, кроме подходящих под регулярку:

git branch --no-merged | grep -v -E 'superfeature.*|.*stable' | xargs git branch -D 

Само собой, делать это надо крайне осторожно :)

Мастрид про роли и качества тимлида. Самое развёрнутое описание из тех, которые мне встречались.

https://felixit.blog/2018/03/31/timlid-v-trioh-licah/

#ссылки

У тебя есть 30 секунд, чтобы объяснить, почему ты до сих пор не используешь Astra Linux в качестве основной операционной системы

Astra Linux ― это инновационная операционная система класса Linux (на основе Debian) с уникальным графическим окружением рабочего стола Fly

Astra Linux ― это первая и единственная ОС, сертифицированная по требованиям ФСТЭК РФ

Astra Linux импортозамещает операционные системы и офисное ПО в Челябинской области

Astra Linux работает на процессорах Эльбрус

Жду ваши оправдания

http://astralinux.com

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

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

1. Переключится на master-ветку;
2. Подгрузит свежие изменения;
3. Вернётся на ветку, в которой я находился изначально.

Работая в командной строке, я могу написать примитивную программу и задать её как алиас:

[alias]
  pm = git checkout master && git pull && git checkout -

А при взаимодействии с гитом через графическую обёртку остаётся надеятся на то, что разработчик моего любимого инструмента сделает такую функцию.

Когда программируешь на C, и надо вручную освободить память

Scala Puzzlers

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

Код из таких книг, конечно, достаточно сильно оторван от реальной жизни и обычно представляет из себя bad practices. Но его разбор позволяет расширить представление о тонкостях работы компилятора и освежить в голове некоторые нетривиальные моменты.

Последняя надежда

Вышло видео доклада John A. De Goes с отличной критикой современного состояния Scala-экосистемы. Позитивная повестка довольно абстрактна, но это не проблема, потому что это доклад про «Кто виноват?», а не «Что делать?».

Озвученные проблемы:

1. Котлин очень быстро отжирает рынок языков на jvm, а Oracle в последние годы начал активно развивать джаву. Скала же всё не может закрепиться среди других популярных промышленных языков, хотя очень близка к ним;

2. Балансировка на двух стульях между джавой и хаскелем. Вроде и стремимся сделать промышленный язык, элегантный, как хаскель, но ограничения платформы заставляют городить внутри него костыли (хотя их не так уж и много);

3. Маркетинг скалы сосёт. Пока голанг продаётся, как язык для быстрой разработки эффективных высоконагруженных приложений, скалку подают под соусом возможности совмещать ООП и ФП. Акцент делается не на решении задач бизнеса, а на академических интересах;

4. Есть вероятность (примерно 100%), что грядущий релиз Scala 3 создаст такой же коллапс с параллельным развитием версий, как у питона. Крупным компаниям будет тяжело обновиться со второй версии;

5. Утечка кадров из сообщества, внутренние междусобойчики, политика внутри инженерного сообщества;

6. В Scala 3 пытаются пропихнуть пару фич, которые не нужны ни одной из частей скала-сообщества. Фичи ради фич приведут к усложнению языка (куда уж больше?), но не принесут реальной пользы, потому что часть людей уже использует библиотеки, реализующие то же самое, а остальным это в принципе не нужно.

Предложения:

1. Брать пример с Котлина: больше документации, больше тулинга, больше надёжности;

2. Не делать мертворождённых проектов ради PhD у аспирантов Одерски;

3. Не распыляться в попытках впихнуть весь опыт компьютерных наук в один язык. Делать меньше вещей, но делать их лучше;

4. Признать, что скала — это функциональный язык, и выгнать из сообщества ООП-макак (не шутка). Сделать уже ФП-возможности скалы конкурентным преимуществом, а не замыливать их кучей вторичных фич.

Видео выступления: https://www.youtube.com/watch?v=v8IQ-X2HkGE

Продолжаем унижение скалистов. Есть такая шина для передачи сообщений — Apache Kafka. Биг дата, распределённые системы, все дела.

В своё время она была написана на Scala, а сейчас 70% кодовой базы — это отборный Java-код. Последний коммит в .scala файл датируется 2016 годом, а проект находится в состоянии перехода Scala -> Java с 2015 года.

Почему? Может быть дело в языковых конструкциях, высоком пороге входа? Или в долгой компиляции? Или в экосистеме языка? Нет. Просто у Scala нет бинарной совместимости между версиями. И разработчикам приходилось билдить и тестировать артефакты для 2.8, 2.9, 2.10, 2.11... версий компилятора. В конце концов им это надоело, и всё, кроме ядра системы, было переписано на джяву.

Решил перед сном посмотреть ленту гитхаба, и не зря.
Li Haoyi, один из самых значимых людей в скала-сообществе, сегодня дропнул новую библиотеку — requests-scala. Это портирование отличной питоновской библиотеки requests на скалу. Либа имеет то же самое апи и практически идентичную реализацию.

Почему это важно?

Есть много http клентов для скалы. Многие из них являются частью массивных фреймворков (Akka-http, Play, http4s). Некоторые сами по себе большие и сложные проекты (sttp, dispatch). Ещё доступны клиенты из джява-мира (apache). Все они имеют тонну конфигураций, предназначены для больших нагрузок, обработки массы крайних случаев, интеграции со сторонними апи...

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

Haoyi сверхестественно талантливый разработчик. Он имеет уникальное чутьё на проблемы, которые всех раздражают, но никто не берётся их осмыслить и решить. Хотите написать быстрый и удобный парсер? fastparse. Покрыть проект тестами, но не заморачиваться с фреймворками для тестирования? utest. Дефолтный репл скалы вроде бы устраивает, но хочется большего? ammonite. Создать небольшой проект и не париться с конфигами sbt? mill. И это всё сделал один человек!

Его проекты всегда простые. Для сложных задач нужны сложные решения. Но не все задачи сложны, многие из них банальны. Хочется простого и понятного инструмента, чтобы быстро с ними справится. И тут на помощь приходит Haoyi. Его проекты отлично написаны, имеют великолепное интуитивное api и подробную документацию.

Haoyi — тот человек, с которого стоит брать пример. А ещё у него очень интересный блог.

Сравнение размеров формальных грамматик разных языков программирования. Совершенно неожиданно «сложные» языки Scala и Haskell описываются проще, чем Swift, Kotlin и Java 🙃

Довольно интересный доклад для расслабленного прослушивания.

Основные тезисы:
* Обозначать идентификаторы можно как угодно, главное, чтобы не возникало вопросов «что это?» и «зачем это?»
* Может быть, ваша функция на 8 строчек понятна и с переменными p, pc, ac понятна сама по себе. Но она существует как часть кодовой базы из десятков тысяч строк, и отдельно от контекста её никто читать не будет.
* Надо помнить про кошелёк Миллера: человек может держать в голове одновременно только 5-9 объектов. Не надо перегружать читателя, пожалуйста.

И самое, на мой взгляд, важное: код пишется отрывками, но читается полностью.

https://www.youtube.com/watch?v=z5WkDQVeYU4

Время ломать стереотипы

Бытует мнение, что программистская нотация x = x + 1 контринтуитивна, потому что в математика значок = всегда означает равенство объектов.

На самом деле это не так, и в математике существует куча способов использования этого знака. Например, для перечисления элементов множества
A = { n/2 : n = 1, 2, 3, ..., 100 }
или Big-O нотации
f(x)=O(g(x)).

Так что программистское присваивание — это не исключение из правила, а n+1 способ использования символа =.

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

Из текущего дайджеста мне больше всего понравились две статьи:

* Akka anti-patterns: too many actors TL;DR: не надо плодить сущности без необходимости (иначе будет страдать производительность системы). А ещё в этом блоге есть список из 15 антипаттернов для Akka. Можно поиграть в бинго на своём проекте 🐭

* Kinds of types in Scala, part 1: types, what are they? объяснение сути строгой типизации как таковой и её реализации в Scala. Вывод типов, ADT и вот это всё на базовом уровне.

Годные ссылочки на сегодня:

Подборка Scala Best Practices от Alexandru Nedelcu — контрибьютора typelevel, автора Monix и cats-effect. Последнее изменение было в 2016 году, но документ совершенно не устарел. Много примеров кода и несколько годных паттернов.

Choose an open source license — сайт с подсказками по выбору лицензии для Open Source проектов, краткое изложение сути лицензий, их плюсы и минусы. TL;DR если проект маленький и в планах нет монетизации, можно брать MIT и не париться.

#ссылки

В стандартной библиотеке джявы есть очень интересный класс java.util.Date. И у него есть конструктор Date(int year, int month, int date), помеченный deprecated. Мне всё время казалось странным то, что такой удобный конструктор зачем-то убрали и предлагают создавать объекты Date, указывая время в милисекундах. Ведь иногда так удобно указать просто год, месяц и день.

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

Преклоняю колени.

Монада — это просто моноид в категории эндофункторов

Сегодня я наконец-то нашёл действительно понятное объяснение этой фразы: The Proof - Monad as a Monoid in Category of Endofunctors. Великолепная статья с разбором основ теорката для тупых. Последовательные определения моноида, моноидальной категории, моноида в категории и категории эндофункторов схлопываются в максимально простое доказательство. И, самое главное, все утверждения в статье сопровождаются кодом на скале!