Читать в телеге. Когда-то там были посты не только от меня.
Что такое шейдер
Классная обучающая и интерактивная статья про шейдеры. Я очень далек от графики (и игор, которые ее требуют Т_Т), но прочитал с удовольствием.
Передача данных через ICMP (ping)
Классная статья, в которой хорошо разобран протокол ICMP, можно узнать как работает tracert
и как с помощью буханки и троллейбуса (питона и винды) получить туннель из огороженной сети в интернет.
Поиск TODO и FIXME в ветке
Вот вы накалякали PR, пришла стадия рефакторинга — стоит пройтись по всем мелким замечаниям и поправить их. Но по умолчанию в какой-нибудь Intellij будут показываться все TODO, а не только ваши. Конечно, ваша кодовая база хорошая, и их будет не очень много, да? Падме.жпг В итоге надо как-то отфильтровать только то, что относится к вашей ветке.
Теоретически эту проблему могут решить области поиска, однако динамические области в IntelliJ пока не поддерживаются. Есть плагин, который вроде работает, но подписка стоит аж 1 доллар в месяц — непозволительные расходы!
Попробуем сделать это через консоль. Читать документацию git
— сомнительная затея: как и пользовательский интерфейс git
, она тоже любит “тщательно выбирать друзей”. Нам нужны все изменения в ветке:
git diff --merge-base master
Эта команда выдаст патч на все закоммиченное и добавленное в git
. Но есть еще и недобавленные файлы:
git ls-files --others --exclude-standard
Объединяем это все через cat
и grep
’аем. Ну и чтобы не запоминать колбасу, добавляем функцию в ``~/.bash_aliases` (или где вы там храните своё):
function branch_todo(){
cat <(git ls-files --others --exclude-standard -z | xargs -0 cat) \
<(git diff --merge-base master) \
| grep -i -E 'TODO|FIXME|FIMXE'
}
У людей еще есть шанс в го
Многие, я думаю, слышали, как в 2016 Alpha Go победил Ли Седоля в го, после чего тот заявил о своем уходе из го.
В феврале этого года вышло исследование, в котором экспериментировали с аналогичным, более продвинутым движком и нашли в нем дырку: стратегию, которой может научиться человек и обыгрывать компьютер в 97% случаев. Стратегию эту мог бы заметить любой достаточный опытный игрок. По сути, это adversarial атака на движок.
Если шахматы “почти решены” за счет алгоритмов и вычислительных мощностей, и там все +- предсказуемо и понятно качество, то с го получается сложнее: да, ИИ обыгрывает чемпионов, но засчет кучи паттернов, которые, как оказалось, покрывают не все случаи. Причем просто поправить это, по мнению авторов исследования, не получится.
В общем, глубокие нейронки крутые, но не супер-надежные. Нужно больше GAN’ов строить для них.
Нужны ли аналитики
В некоторых кругах бытует мнение, что аналитики нафиг не нужны. Вот норм доклад-наброс на тему.
Если вкратце, “зависит от задачи команды”. Докладчик обсуждает явный антипаттерн, когда аналитик выполняет некоторые функции архитектора, менеджера, продуктового менеджера, техписателя, тестировщика, программиста и т.д. — по сути, универсальная затычка. (Вьетнамские вертолеты — был в одной компании отдел из аналитиков, которые на low-code жахали целые продукты). В пользу аналитиков приводится довольно вялый аргумент, что когда нужны, тогда нужны (соответственно, когда не нужны, то не нужны). Если отбросить тавтологии, то по мнению докладчика получается, что реальная необходимость в системных аналитиках возникает только при наличии сложной предметной области и для формулирования четких требований. Уже на секции вопросов докладчику вполне закономерно указали, что требования вообще продакт должен формировать, а за толкованием предметной области — это к бизнес-аналитику. Т.е. в нормальной команде системные аналитики не нужны (и я с этим согласен).
Этот доклад мне немного напомнил мой старый пост про деление на задачки: если разрабу нужен отдельный человек, который ему будет разжевывать, что и как надо делать, то зачем он вообще нужен? Код писать? Это и ChatGPT умеет…
Однако стоит стоит отметить, что системные аналитики не нужны в нормальной команде. Если у вас есть кретины или происходит взаимодействие с кретинами (увы, подобные обстоятельства часто встречаются), то тогда дополнительная прослойка-защита от них не помешает. Но тут как в математике: если у нас система утверждений противоречива, то из нее выводимо любое утверждение.
YAML
Забавный сайтик, в котором в примерах показывается, чем плох YAML. И неплохо дополняющая его статья.
Вообще YAML — неплохой пример “хотели как лучше” и отсутствия системного мышления. Конечно, прикольно иметь кучу неявных конвертаций, но очень грустно, когда произойдет что-то неожиданное вроде false
вместо Норвегии. Если это еще скомбинировать с каким-нибудь шаблонизатором и затруднить проверку, то будет еще больнее — наверно, поэтому это де-факто стандарт для “девопсов” с их куберами и хельмами, да?
Павлик Морозов для C++
Для java и Kotlin павлики были, пришел через для C++.
Занятный видос, в котором реализовали public_cast
, чтобы получить доступ к приватному методу. Помимо этого, там в конце есть еще и кратенькое объяснение, зачем нужны вообще эти *_cast
’ы и чем плохо сишное преобразование типов (MyType)someVar
.
HEAD
У меня случайно был включен 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 Нужно ли учитывать асинхронность вычислений? А с учетом Loom? Любой ввод-вывод? Ошибки?
Обсуждение все еще в процессе. А еще Одерски запустил исследовательскую программу Caprese для поиска способов отслеживать эффекты, так что может что-то новое оттуда родится.