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

Вообще YAML — неплохой пример “хотели как лучше” и отсутствия системного мышления. Конечно, прикольно иметь кучу неявных конвертаций, но очень грустно, когда произойдет что-то неожиданное вроде false вместо Норвегии. Если это еще скомбинировать с каким-нибудь шаблонизатором и затруднить проверку, то будет еще больнее — наверно, поэтому это де-факто стандарт для “девопсов” с их куберами и хельмами, да?

Для java и Kotlin павлики были, пришел через для C++.

Занятный видос, в котором реализовали public_cast, чтобы получить доступ к приватному методу. Помимо этого, там в конце есть еще и кратенькое объяснение, зачем нужны вообще эти *_cast’ы и чем плохо сишное преобразование типов (MyType)someVar.

У меня случайно был включен Caps Lock, и вместо head s<Tab>omefile я напечатал HEAD S<Tab>omeOtherFile. ВНЕЗАПНО, HEAD это валидная команда, так же как и GET и POST — это утилита lwp-request, которая, по сути, аналог curl, причем еще написанный на перле! Судя по всему, это стандартный пакет Debian.

Найти ответ на вопрос, как в стандартной библиотеке реализовано вычисление логарифма, оказалось сложнее, чем можно подумать. Во-первых, алгоритмов вычисления довольно много: от наивной итерации по Тейлору до хитрых методов с таблицами. Во-вторых, реализация будет отличаться в зависимости от архитектуры процессора, наличия векторизации (SIMD, SVE и прочие страшные аббревиатуры) и от авторов библиотеки (GNU, musl, UCRT и т.п.).

Если смотреть на среднебольничную реализацию, то это будут математические преобразования по сужению области определения, набор предвычисленных таблиц и вычисление 5-7 членов ряда Тейлора. Некоторые процессоры имеют встроенную команду fyl2x для x * log2(y), и она даже используется, правда она может выполнятся довольно медленно: на некоторых старых процессорах — больше 1000 тактов, а в среднем за 50-100 тактов.

При этом двоичный логарифм довольно особенный. Если работать с числами с плавающей точкой и нам не очень важна дробная часть, то можно просто взять показатель двоичной степени при помощи frexpf. А если работаем с целыми числами, то достаточно знать позицию первой единицы слева или количество нулей слева — для этого у некоторых процессора есть команды bsr и/или clz соответственно, а в GCC — встроенная функция __builtin_clz.

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

Один из главных выводов статьи: асинхронные функции — это решение проблемы, однако у сообщества нет четкого и однозначного понимания, в чем эта проблема состоит (без внятного ТЗ результат ХЗ).

В статье затронуты такие проблемы как много способов сделать одно и то же в Scala, несовершенство двухцветной реализации корутин в Kotlin и трактовку RPC как локальных функций. Открыт вопрос, надо ли делать решение только под JVM или под все платформы, и должно ли решение быть на уровне языка или библиотек.

Для постановки проблемы нужно понять:

1. Должны ли эффекты фигурировать в сигнатуре метода? Почти все в сообществе склоняются к “да”.
2. Должна ли эта информация распространятся на вызывающие методы вплоть до точки входа? А вот тут мнения разделяются.
3. Что вообще надо отслеживать? Это занятно пересекается с п.1 Нужно ли учитывать асинхронность вычислений? А с учетом Loom? Любой ввод-вывод? Ошибки?

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

Интересное исследование от GitHub про то, что нужно разработчикам, чтобы быть продуктивными и чувствовать, что день был прожит не зря. Много довольно очевидного, но тут хотя бы есть какие-никакие экспериментальные данные. Из довольно капитанских выводов:

1. Состояние потока это важно, должно быть выделенное время для сосредоточенной работы
2. Больше двух встреч в день — это рак, 1 встреча — норм.
3. Даже оформление пулл-реквеста — это выход из потока.
4. Больше времени в состоянии потока — больше достижений и меньше стресса.

Менее очевидный вывод: разработчики, которые ежедневно тратили пару минут в конце дня, чтобы порефлексировать, был ли день хорош и почему, начинали ДУМАТЬ и они даже что-то меняли в итоге в своем подходе к работе.

Когда я впервые столкнулся с agile, я писал себе коротенько, что делал за день, чтобы потом на стендапе не надо было вспоминать. Но вскоре я, к сожалению, в этом разочаровался: увы, большинству людей абсолютно насрать, че ты там делал, проквакал че-то нормальное и пофиг. До agile я записывал только свои достижения. Вот это полезно, и я продолжаю везде это делать. На Performance Review ты молодец-огурец, кучу всего достиг и ничего не забыл. Да и в резюме есть что записать.

Очень часто чуть ли не единственным техническим аргументом в пользу использования java, а не какого-нибудь высокоуровневного языка, слышу что-то вроде “ой, ну вот с этим синтаксическим сахаром ничего не понятно, вот на java все просто и логично, там легко читать и все понятно”.

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

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

Для создания виртуального экрана есть даже специальные HDMI-затычки и масса программных вариантов. Из них я попробовал 2:

1. DeskPad — ноль настроек, запустил и готово. Но экран только один.
2. BetterDisplat — настроек до фига. Но при запуске какого-то черта меняет настройки основного экрана. И хотя тут можно добавить больше одного виртуального экрана, я не разобрался, как сделать так, чтобы они не были зеркалом друг друга.

Шарил экраны с помощью Deskreen. Что тут сказать… вроде работает, но мыльно и тормознуто: лаг довольно заметен. Что интересно, я пробовал еще подключать iPad как третий монитор, и там лаг меньше. Еще совсем не помогало, что у личного ноута 16:10, iPad 4:3, а у мака вообще 1800x1169 — этот зоопарк либо обрезался, либо растягивался (возможно это можно настроить нормально, но из коробки работало так себе).

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

1. Когда в настройках мака сделал виртуальный экран основным, то маковский экран “завис”, а ноутный просто отвалился. Хорошо, что на iPad был запущен терминал, через который я прибил виртуальные экраны.
2. Когда открыл окно на полный экран, мак сходит с ума и на своем экране показывает черноту, а на остальных получается либо статическая картинка, либо артефакты.

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

В общем, great idea, does not work.

Недавно понадобилось сделать простую операцию над текстовым файлом: посчитать минимальную/максимальную длину строки. Звучит элементарно, ща быстренько состряпаем что-нибудь из cat + wc + sort… Только надо подобрать правильную комбинацию параметров и xargs вставить. С наскока, разумеется, не получилось. На питоне ради этого писать лениво, и в итоге на StackOverflow было найдено решение с awk:

awk '{print length}' input.txt | sort -rn | head

На чистом awk минимум будет выглядеть так (решение предложено ChatGPT):

awk 'NR == 1 || length < min { min = length } END { print min }' input.txt

Еще проще будет посчитать среднюю длину строки:

awk '{total += length} END {print total/NR}' input.txt 

Раньше я обычно игнорировал решения на awk, потому что они были не очень понятны в отличие от различных комбинаций grep, sed, cut, wc, sort и прочих: они достаточно простые, и “делают одну вещь хорошо”. А если что-то серьезное возникало — то писал что-то на питоне.

Но после описанного случая решил немного почитать про awk и, оказывается, он из коробки поддерживает построчную обработку (питонячий бойлерплейт), разбивку на поля (cut) и регулярки (grep/sed). Достигается это за счет довольно интересной концепции: каждая строка проверяется по паттерну(ам) — условию/регулярке, и если она соответствует, то выполняется действие в фигурных скобках. В общем, планирую попробовать.

Хотя можно не париться и просто ChatGPT попросить скрипт написать.

За время своей работы встречал разнообразные мнения по данному вопросу:

1. Нужно 4 монитора! На одном реверсить, на другом даташит открыт, на третьем среда разработки, на четвертом разводка платы… Больше мониторов богу мониторов!
2. Два монитора норм, на одном кодишь, на другом открыт тикет/чат/порнуха/унылый созвон. Или запускаешь созвон на одном экране, а другой шаришь.
3. Нужен только один монитор (но большой), потому что если много мониторов — теряешь фокус на одной задаче.

Когда-то мне казалось, что надо 3 монитора, но сейчас я склоняюсь к умеренному варианту №2, причем это экран ноута + монитор. На одном большом экране даже со всякими приемами разделения окон может быть не очень удобно переключаться между контекстами (а на маке разделение экрана само по себе конченое). А двух экранов достаточно, чтобы выполнять переключение поворотом головы.

Вообще, переключение контекста — довольно дорогая операция. И если их нужно одновременно больше двух, то, возможно, вы что-то делаете не так? Может надо сделать какую-то предварительную обработку “вспомогательных” контекстов, чтобы они работали как один?

А что говорит по этому поводу наука? Нашел мета-исследование на тему (по DOI можно найти на сцихабе полный текст). Если смотреть на опросы пользователей, то там все понятно: минимум 17”, большинству подавай два монитора. Однако кто говорил, что ему надо четыре, не использовал их по полной. Если смотреть на более объективные измерения, то в одном исследовании измеренная продуктивность выше с двумя мониторами, чем с одним, но при этом третий монитор существенно на нее не влияет. В другом исследований не обнаружили разницу между одним и двумя мониторами 17” или 22” (зависит от задачи, в общем). При этом есть умеренные свидетельства уменьшения числа кликов/переключений окон при увеличении размера и количества мониторов.