inv2004 Dev Blog

Наткнулся: https://habr.com/ru/articles/884932 Я бы пошёл дальше и вообще убрал JOIN из клика (его и не было раньше) так как считаю, что его добавили, так как просто слишком часто спрашивали. Конечно, можно нафантазировать какие-то случаи и небольшой левой таблицей, например, на основании ReplacingMergeTree, но с ходу даже не припомню, когда это было бы лучше, чем словарь, или, опять, денормализация в плоскую #clickhouse

#golang #rust

#rust

... пост вызван 8 годами разочарования в сообществе C++ ... ... автор ожидает возмездия за свои обвинения ... Лучшее за сегодня: https://300.ya.ru/pzMdEwEG Из комментов https://t.me/itpgchannel/2723

Самое смешное, что случилось в HighTech в 2024м Другая команда сказала, что мы слишком быстро посылаем пачку сообщений в кафку, а они не успевают читать и сохранять и попросили вставить что-то вроде sleep(X) на нашей стороне - чтобы они успевали. Тут я понял, что, так сказать, не боги горшки обжигают

Кажется мне надо. Кто-то в китае берёт thinkpad клавиатуры от ноутов и делает обычные

Диванные бенчмарки: вывод по WSL2 * может вызвать гнев Кто-то мне рассказал про CachyOS - заоптимизированный Arch, а тут под руку еще и флешка подвернулась и я не устоял. Запускал всё на ramfs. - Сначала проверил время сборки в Void: https://github.com/inv2004/bench_nim_build/issues/107 57.675s + 15.594s - Потом CachyOS: https://github.com/inv2004/bench_nim_build/issues/108 55.545s + 14.893s - Win11+WSL2: https://github.com/inv2004/bench_nim_build/issues/109 56.206s + 15.657s - это и ставит точку - отличий даже от оптимизированного CachyOS почти нет - Win10 + WSL2: https://github.com/inv2004/bench_nim_build/issues/110 55.382s + 14.341s - понятно, что тут _все_ цифры в пределах погрешности, но тут даже быстрее чем CachyOS - И напоследок решил запустить Opensuse Tumbleweed: https://github.com/inv2004/bench_nim_build/issues/111 52.725s + 14.464s - и вот тут магия - он заметно оторвался от всех других. Вывод: В нативном Linux для разработки нету необходимости, если только нет каких-то предпочтений по UI => WSL2 вообще никак не отстаёт, если не опережает большинство дистрибутивов — added — - ubuntu тоже удивила в плохом смысле: https://github.com/inv2004/bench_nim_build/issues/115 59.900s + 16.025s

Диванные бенчмарки Скорость сборки в WSL-2 на Win-10 и Win-11 Старый 6300U:: - win-10: 350s - win-11: 388s - Нативный Arch: 299s Но не стоит ликовать, на 12600K оно так: - win-11: 61s - Linux 5.16: 71s https://github.com/inv2004/bench_nim_build Другие тесты: https://www.phoronix.com/review/windows11-wsl2-zen4 https://www.pugetsystems.com/labs/hpc/wsl2-vs-linux-hpl-hpcg-namd-2354/ https://openbenchmarking.org/result/2107013-IB-WIN11WSL289 https://www.phoronix.com/review/wsl-wsl2-tr3970x/2 , но меня интересовал именно bench_nim_build

Vim на старом железе: 3/3 Как я писал тут https://t.me/inv2004_dev_blog/155, всё это по причине, что, видимо, раз в 5 лет опять свербит: «А вдруг Linux стал хорошим десктопом?» => и эта идея залетает на старый ноут. В этот раз залетели void-linux + (lazy) vim. Итог: - Оказалось (очевидно же), что сам редактор для разработки — это меньшая часть того, что его подпирает и тормозит при этом. - Даже якобы лёгкий vim со всеми свистелками может лагать и зависать, например, telescope легко фризится на секунду-две. Точную причину не знаю, думаю, тут три момента: treesitter пытается раскрасить preview, и, может быть, не особо асинхронно это делает. Тут же возникает впечатление, что vscode тормозит меньше просто по причине, что все эти моменты там полировали значительно больше народу и дольше. Аналогично, когда LSP-сервис что-то сканирует — даже курсор тормозит. Итог: я опять вернулся к мысли, которую уже озвучивал тут https://t.me/inv2004_dev_blog/30. Я не знаю причин, но после установки win-10 обратно на машину — она выглядит опять достаточно рабочей. Про причины у меня только догадки: может быть графическая подсистема (хотя карта старая и встроенная), может быть как-то по-другому работает scheduler, может быть кеши как-то иначе кешируют. Может быть всё вместе, просто из-за того, что это самый массовый десктоп и там всё долго оптимизировать, но и браузер, и vscode+WSL-2 работают заметно плавнее (не быстрее) под win. Замечу, что на машинах посильнее эта разница уже не особо заметна. Обратно тоже применимо: на современных машинах WSL-2 не отличается по производительности от нативного Linux: https://github.com/inv2004/bench_nim_build. P. S.: можно сказать, что я потратил время с почти нулевой пользой и вернулся в исходную точку по этому вопросу. Но, некие минорные, но полезные вещи я всё же узнал, о чём напишу потом. #linux

Шаблон с шаблонами Запилил по работе в ClickHouse wrapper ошибок для случая, когда всякие корпоративные krb5 тикеты протухают. Код довольно абстрактный получился, так как покрывает всё взаимодействие с hdfs => на входе и выходе любые функции и типы могут быть. И теперь для меня мем пакет с пакетами звучит как

шаблон с шаблонами

#cpp

Я попробовал все парсеры командной строки для Nim и выбрал лучший На самом деле просто для себя записать, чтобы быстрее вспомнить когда понадобится, а склероз уже наступит. Требования такие: - поддержка отдельных команд - каждая команда должна иметь отдельный набор аргументов - умение работать с типами - я не хочу парсить в своём коде - аргументы не текущей команды не должны быть доступны при компиляции Итого, из 13 библиотек в финал прошла всего одна: https://bitbucket.org/maxgrenderjones/therapist. На втором месте: https://github.com/casey-SK/commandant. Я немного удивлён тому, что, оказывается, это не так просто — предоставить хороший интерфейс для такой простой штуки. Хотя бы вспоминая clap из Rust, где даже это требовало обильной обмазки макросами. В идеале так вообще лучше всё типами описать, а оно само разберётся, и therapist тоже к этому тоже ближе всего. Скинул примеры сюда: https://github.com/inv2004/argparse_nim_examples #nim

Lazyvim в качестве рабочего инструмента: 2/3 Сорян за паузу, продолжаю. В не слишком горячее время решил не открывать vscode и провести месяц-два в vim. Поначалу, конечно, ломало. Но в итоге всё удалось. Основные простые функции работают нормально и удобно: навигация, рефакторинг через lsp, осмотр файлов проекта. Но, в остальном, как часто бывает в linux'ах, очень много недоделок. Примеров масса, и чем дальше, тем больше они начинают напрягать: - telescope неудобно обрезает широкие строки — сложно скроллить preview. Можно покрутить настройки. - telescope вообще отрезает имена файлов, а в большом проекте это очень неудобно. Но тоже можно покрутить настройки - statusbar тоже отрезает путь. Тоже надо поправить. Почему это не из коробки так? Ощущение, что кто-то выложил plugin, но используют в реальной работе его не так много, уж точно не столько, как vscode, где все эти моменты уже отшлифованы. Потому и допиливают это значительно меньше. - отладчик в vim — полурабочая штука, надо внешний. + neotest — работают хорошо и удобно, есть даже watch и перезапуск автоматом. - call hierarchy — полный провал, и это один из решающих моментов. Я не очень понимаю, как без этого можно называться IDE. Судя по всему, вопрос до сих пор актуален. + lazygit — это открытие. Никогда его не использовал на постоянной основе, но в lazyvim он добавлен как основной инструмент, и оказалось очень удобно, удобнее vscode, где я больше просто git в консоле. - multicursor — сильно удобнее regexp, вроде было что-то и для vim, но в ленивом vim не нашёл. В целом, недоработанных мелочей полная коробка — то диалог не там отроется, то два split экрана неожиданно путаются местами. В сумме по мелочам и не нет итог, что как IDE vim всё ещё не тянет. Куда более рабочая схема — vscode + vim-plugin. Есть и обратный момент, после пары месяцев на nvim, то и vscode начинает немного раздражать — практически постоянно приходится елозить мышью. ... дальше про то, насколько это всё легко работает на старом ноуте #vim

Я попробовал все сборки поверх neovim и выбрал лучшую: 1/3 Начал я всё это из-за шила в ради старого ноутбука. Он хоть и старый, но лет так 5 назад я писал на нём на расте в Clion, параллельно собирая докер кликхауск в другом докере. Сейчас он заметно отстаёт по современным меркам, и это довольно заметно, что хорошо. Опробованы: spacevim, nvchad, astrovim, lazyvim, lunarvim. В двух словах: одни сильно тяжелее других: spacevim заметно тяжелее, самые лёгкие это nvchad и lazyvim. Но выбирал я исключительно по своему удобству, а именно в попытках понять, насколько это у авторов оно совпадает с моим. Первый же пример, когда что-то делаешь — переключиться на другой файл довольно частая задача, и нажимать space+f+f не так удобно, как space+space (lazyvim). Вся работа с кодом/lsp по space+c, с отладчиком по space+d. В других обычно это всё раскидано, как мне показалось, довольно хаотично, а в lazyvim вроде норм. Другой вопрос, сколько подпрыгиваний надо сделать, чтобы были и go, и cpp, и nim. Например, в nvchad надо сильно больше, чем в других. Выбрать-выбрал, но этого мало, теперь надо реально его использовать. Тут два момента: на домашнем ноуте особо негде, я поставлю на рабочий, где кодовая база сильно больше. Тут надо разделить на две части: использование на работе и насколько оно лучше на старом ноуте, так как вещи не особо пересекающиеся. ... #vim

Детская травма в IT Лет 20 назад работал в одной конторе и допиливал код за сотрудником, который уже покинул компанию. Там было несколько запросов и сложная логика кода на несколько страниц, которую пришлось разбирать. Но итог был удивительным: удалось выпилить вообще весь код , вся суть которого уместилась в LEFT JOIN. Удивление вызвало, что недавно опять пришлось столкнуться с подобным подходом. И для меня это часто как красный флаг: с чего кто-то наскоком решил, что может в коде питона или go реализовать логику JOIN быстрее, чем это делает база? Основное свойство которой — делать именно это, что допиливали и разгоняли годами. Клик в расчёт не особо берём, я считаю, что JOIN — чуждый элемент в клике. + Отдельное удивление, что почти все базы до сих пор не смогли решить нормально проблему с пагинацией, которую раскидывают на дополнительные запросы параллельно. + Хотя и это не мейнстрим, но считаю бизнес-логику в базе нормальным подходом

Оказывается канал в go нормально собирается GC и close ему для этого вовсе не обязателен. Можно откатить прошлое "изобретение" #golang

errchan.Chan: всё оказалось немного сложнее @pragus в https://t.me/inv2004_dev_blog/150 накинул хороший пример, о том, что вызов .Err() не гарантирован => не гарантированы закрытие + drain канала. А сделать это через defer тоже _красиво_ не получится - потому как вызывать его надо на другом уровне. Но не зря несколько раз говорили об итераторах - они тут пригодились, хотя и в другом контексте. С помощью него удалось принудительно закрыть и очистить канал сразу после закрытия чтения. Хотя теперь читается не сам канал, а итератор, в который заворачивается канал (может надо переименовать Chan()), но выглядит и функционирует одинаково. Пример обновил: https://go.dev/play/p/dI40gU9DeZT — added — а что если даже .Chan() не вызывается для чтения. Получается надо следить за блоком в котором исполняется - по сути раст, но глазами #golang

Counter Strike — игра, которая не скатилась (вроде) Заболеть в новогодние выходные — плохая традиция. Так как голова ватная, единственное, до чего дотянулись руки, был Counter Strike 2. Писать было бы неинтересно, если бы параллельно не выходили безумные железки типа nvidia 5000-й серии. А интересно это тем, что CS2, как продолжение CS:GO, является одной из самых оптимизированных игр, и, кажется, что это очень редкий случай, где это это является бОльшей частью успеха этой игры. Это также самая основная киберспортивная дисциплина. Как следствие, pro-игроки, которые, по идее, как раз имеют доступ к топовым видеокартам, но используют эти мощности не для 4K и кинематографичности, для чего эти железки и появляются, а ровно наоборот — для результата, который, оказывается, никак не связан с графикой, а скорее даже наоборот. — Мало кто использует даже Full HD разрешение. Большая часть занижает разрешение на 1280x960. — Графика максимально на Low, кроме antialiasing. — Никаких vsync. Играть я, конечно, в это не буду - надо слишком много времени — added — Кстати, для себя, в разрешении выше fullhd не вижу особой необходимости #cs

Make (golang) Channels Great Again: errchan.Chan Оформил в виде библиотеки https://github.com/inv2004/errchan Продолжение https://t.me/inv2004_dev_blog/145 Основная идея: - Структура берёт на себя головную боль при работе с каналами, контекстом, отменами и обработкой ошибок горутин. Вроде как errgroup + channels + context в одном флаконе. - Можно возвращать из функции, и обработчик будет работать с каналом и обрабатывать ошибки как в примере ниже - Смысла использовать с небуферизованными каналами, наверное, нету - Идея запускать много горутин для записи в канал тоже не была основной, изначально задумывалось для запуска одной, но решил убрать это ограничение - В следствии прошлого пункта, может быть, надо добавить .SetLimit Основной пример такой

import (
    "context"
    "errors"
    "fmt"

    "github.com/inv2004/errchan"
)

func reader(ctx context.Context) *errchan.Chan[int] {
    ech := errchan.WithContext[int](ctx, 10)

    ech.Go(func(ctx context.Context, ch chan<- int) error {
        for i := 0; i <= 3; i++ {
            ch <- i
        }
        return errors.New("fail")
    })

    return ech
}

func main() {
    ctx := context.Background()
    ech := reader(ctx)

    acc := 0
    for x := range ech.Chan() {
        acc += x
    }

    fmt.Println(acc)       // 6
    fmt.Println(ech.Err()) // fail
}

Когда людей не останется, боты продолжат поздравлять друг друга с новым годом 🎄 С НГ!

Из старого ЖЖ Один человек начитался книжек и поехал в Мексику, к тамошним индейцам, чтобы они ему объяснили смысл жизни. Индейцы выдали ему образцы галюциногенной флоры, а потом начали бить в барабан и петь мистические песни. Человек сжевал и съел, все, что нужно, и вовсю начал соприкасаться с Иным: наблюдать как светятся его вены под кожей, слышать волшебную музыку, неистово танцевать, чувствовать будто его ноги удлинились и стали как резиновые, ну и так далее. В конце концов, из цветовых сполохов и мерцаний к нему вышел индейский Дух-хранитель. - Скажи, Дух, что мне делать в этой жизни? Научи правильно жить. Укажи дорогу! - закричал человек. - Тебе надо вернуться в Россию, пройти курс бухучета и устроиться бухгалтером в сеть супермаркетов Дикси. - сказал Дух. - Что? - опешил человек - Но я думал, ты скажешь, что я должен стать художником, воином, правителем, монахом, ученым или музыкантом! Или подскажешь идею для бизнеса! - Нет, - твёрдо сказал Дух - Иди в бухгалтеры. - Но я не хочу - заныл человек - Это скучно, это надо работать в офисе с девяти до шести! Я думал, что я рожден для большего! - Тогда иди в задницу! - ответил Дух и исчез, оставив после себя сухость во рту, озноб и головную боль. — авторство не помню —