Помнится была тут дискуссия, как мы уехали с gitlab на purge git + ssh. Поскольку полгода полет нормальный и появилось время, выкладываю скриптики:

https://github.com/alttch/gmg

Основной менеджер сделан бинарем. Внезапно на Rust.

Про наш колхоз.

Мы - компания небольшая (~15 человек) и выпускаем единственный коммерческий продукт - https://www.bohemia-automation.com/software/eva4/

У нас не так много клиентов (~ <= 10), мы берем на поддержку только крупный ентерпрайз, это в основном монстры энергетики, и у каждого клиента есть лаба. Которая более или менее дублирует его прод.

Появляется бага. Баги делятся на два вида: первые клиент может починить сам с помощью документации, вторые он даже не понимает, что происходит. Каждая бага второго типа, как правило, осматривается прямо в лабе, затем там же "по-горячему" чинится, путем заливки соответствующего бинарника. Клиент сообщает, что баги больше нет - коммит уходит в ветку.

Выпуск билдов. У нас нет графика. Иногда билд нужен срочно, потому что полная emergency - бага каким-то образом появилась на проде. Иногда билдов может не быть несколько месяцев.

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

Автоматическое тестирование? Ха. Во-первых полный тест идет много часов, что в некоторых случаях (emergency на проде) - недопустимо. Поэтому тесты делятся на группы, которые отбираются вручную, в зависимости от того что менялось. Некоторые тесты невозможно запустить без подготовки - оборудование стоит денег и его нужно собирать, отбирать у инженеров с криками и матами, а иногда еще и прошивать под тесты. Иногда своего оборудования просто нет и приходится просить, чтобы клиент дал доступ к лабе через свои 2 VPN-а. Полный тест запускается очень редко.

Если тест прошел - человек ставит напротив билда подпись. Электронную. Затем билд еще раз тестируется вручную на нескольких конфигурациях, прогоняясь по тем местам, где была бага. Затем тестовый билд ставится клиенту в лабу и он еще раз подтверждает, что баги нет. Затем мы набираем побольше воздуха и маркируем билд как stable.

Клиент апдейтится до stable? Ха. Еще чего. Мы сообщаем клиентам, что появился stable, в котором добавлены такие-то фичи и починены баги. Они берут это к сведенью. Затем заливают stable билд в лабу и там прогоняют по своему набору тестов, критичных для своего же прода. Затем ответственное лицо у клиента ставит подпись (тут уже, как правило, реальную), что конфигурация готова к апдейту.

Затем они набирают побольше воздуха и осторожно апдейтят свой прод.

Вопрос. Куда тут вставить CI? И с кого потом спрашивать, если эта CI что-то пропустит? Найдите мне QA, который бы не только написал авто-тесты, но еще и подписал на всё материальную ответственность. Пока таких не обнаружили.

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

Так вот, что хочу сказать - Axum сделан не через жопу. Ну почти. Пользуюсь второй месяц и еще не сильно матерюсь.

Еще раз об изменении рабочего процесса, который происходит прямо сейчас.

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

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

Теперь мне не нужен джун, у меня для этого есть ChatGPT. И это произойдёт не только в IT. Юристы тоже останутся. А вот помощники юристов будут только носить кофе. С соответствующими последствиями для их зарплат.

Негативная сторона: в любой профессии падаван учился и со временем становился мастером. Это может исчезнуть и как с этим быть - пока непонятно.

Набирает популярность менеджер пакетов для C++ Zork: https://github.com/zerodaycode/Zork

Проект почти полностью написан на Rust. Вот.

Записал видео по машинному обучению в IoT (или как его называли в древние века - АСУ) для своей молодой команды. Ну и вы посмотрите

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

После вчерашнего видео коллега задал вопрос, почему иногда "вероятность" возникновения алярма заканчивается раньше, чем он реально возникает.

Регрессия не вычисляет "вероятность". Она вычисляет значение Y (алярм) по состоянию системы X и может предположить, сколько это Y продлится в будущем. После чего Y с графика пропадет, потому что модель настроена на четкий горизонт событий, по которому ее обучали, сдвигая Y в датафрейме.

Чтобы понять, как это работает, представьте такой пример:

- Вы пошли к ведьме, которая видит ровно на 24 часа вперед, и она вам сказала, что через 24 часа вас убьют

- Вы наняли телохранителей, запрелись дома и залезли под кровать. оттуда звоните ведьме и спрашиваете, убьют ли вас

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

Что делать? Во-первых, быть начеку все 24 часа. Во-вторых - позвонить другой ведьме, которая видит на 12 часов вперед и спросить, как там дела. А потом, на всякий случай, ведьме, которая видит на 4.

Также как и с ведьмами, в accident prevention и predictive maintenance может работать одновременно несколько моделей. Каждая - со своим "горизонтом событий". И оператор системы должен принимать решения, опираясь на предсказания каждой из них.

Программировать на Rust под AWS сейчас еще тот адок:

Авторы Rusoto практически не заинтересованы развивать проект, потому что появился официальный AWS SDK и когда амазон меняет API, в Rusoto что-то дохнет, как правило уже навсегда.

Официальный же AWS SDK for Rust до сих пор висит в Developer Preview и не имеет части функций, которые еще работают в Rusoto.

Зачем выкладывать альфу своего SDK и держать ее в таком состоянии три года - мне непонятно. Впрочем, амазон всю историю обожает издеваться над клиентами.

Apple согласились с требованиями Еврокомиссии и USB-C может появиться уже в iPhone 15.

Но работать будет только через "сертифицированные" кабеля Apple. С кабелями других производителей будет обеспечиваться только минимальная скорость передачи данных и зарядки.

Конец популярного крейта once_cell.

Потому что once_cell больше не отдельный крейт, а официально ушел в std. С чем его поздравляем, ура.

https://github.com/rust-lang/rust/pull/105587

Прошло три недели с тех пор, как я первый раз увидел R и до того момента, как написал на нем необходимый модуль-клиент для нашего продукта (спасибо ChatGPT, 10% кода там его) с пакетом и нативными юнит-тестами. И, так сказать, "первое впечатление":

- В моделировании R мне удобнее питона, потому что R-studio. Продукт, за который просят в том числе, большие деньги, выглядит действительно хорошо. Вопрос, что будет когда Posit интегрируют в R-студию питон. Будет интересно сравнить ощущения

- В графиках R еще недавно уделывал питон, пока не появился Seaborn. Сейчас идут примерно на равных

- Опять вернемя к моделированию. В R и язык, и экосистема чуть менее чем полностью заточена на интерактив: некоторые библы разрешают пропускать кавычки, а при импорте все функции обычно сразу вылезают в global namespace. Это действительно хорошо, когда вы работаете в командной строке, но предсказуемо местами ужасно, когда вы на нем начинаете программировать

- По этой причине подавляющее большинство модулей R написаны не на R. Кстати, Rust там весьма и весьма хорошо интегрируется

- По этой же причине люди бегут с R на Python. Когда вы знаете и постоянно используете Python (а еще и например Rust) и немножко умеете в R, то вы можете вымахиваться и перебирать, или там всё это как-то совмещать. А людям нужно банально кодить простые вещи

- Поэтому не смотря на то, что R по некоторым опросам вырвался на второе место в Data science, он далеко отстает от питона. Тем не менее, свою нишу, судя по всему будет держать еще долго - сейчас R скорее конкурирует с Matlab

- Потому что они оба заточены на пользователей. А не на программистов. Как и в Matlab, в R массивы начинаются с 1. А range 1:10 - действительно от одного до десяти

- Мне R для своих задач понравился, буду к нему иногда возвращаться в канале

(табличка на слайде не моя)

Ukrainian Rust Conference 2023 - уже 8 апреля. Я читаю доклад по Rust+Qt (ENG)

https://www.reddit.com/r/rust/comments/127j6bp/ukrainian_rust_conference_2023_april_8th/

Тут периодически возникали дискуссии насчёт ужасного CSV и передачи данных в потоке.

CSV нужен только для совместимости со старыми базами, навроде Influx 2, потому что весь прогрессивный мир переходит на Apache Arrow.

Во-первых arrow легко стримится из коробок, во вторых он column-based by design (что например очень важно, когда вы отдаёте отдельные IoT метрики, собирая их из разных источников).

В третьих, если взять таблицу чисел 10к столбцов х 100к строк, arrow (даже через polars) её прочитает за ~8 секунд, с csv подобная операция займёт уже 30-40 (а со старым pandas 1.x - вообще минуты полторы). Это даже если не брать во внимание эффективность работы с памятью - arrow куда более компактный.

Но пока (ещё недолго) это все революции в пробирке, к сожалению весь прод в data engineering в основном продолжает сидеть на pandas. Настоящая революция произойдёт, когда выйдет pandas 2.0, который работает с arrow из коробки. А это случится в ближайшие месяцы, две недели назад уже вышел 2.0.0rc1 (хотя вы уже можете читать arrow через тот же polars а потом конвертить в pandas 1.x, overhead на 1ккк ячеек будет пара секунд).

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

Записываю дочку в школу, заполняю формуляр
- сколько будет 20-2?
- 17
- нет, подумай еще
- а, 18!

записываю в графу скилов: арифметика до 20 (на уровне ChatGPT)

Нашел время, пощупал pandas2 rc1 на практике.

- во-первых, хотя pd2 основана на arrow внутри, arrow там напрямую читать-писать пока нельзя, вся интеграция с arrow в i/o только в том, что можно указать pyarrow в качестве engine для парсинга CSV (ха-ха)

- во-вторых на больших таблицах оно дико тормозит и по-моему там что-то сломали в памяти (по крайней мере таблицу на млрд ячеек на моем лаптопе pd2 не грузит)

бенчмарк по чтению (сначала данные читаются в BytesIO, чтобы не было читерства). на таблице 5_000 x 50k.

pandas2 стал даже хуже(!)

Кстати чем я всё это тестировал.

Вернулся в питон, а вменяемого бенчмарка так и нет. Посоветовали какой-то richbench, так он мало того что требует отдельные файлы под бенчи создавать, так еще и в каждом нужно сделать list с функциями. Я не понимаю, бенчмарк должен быть краток и ясен - один аттрибут над функцией и поехали. Кроме того, richbench импортирует бенчмарки "в себя" и не решает мой вопрос - погонять разные версии модулей, а может еще и на разных версиях питона.

Поэтому по-быстрому "портировал" наш bma_benchmark на питон, дописав заодно функционал вызова внешних бенчмарков и объединения всего в одну табличку.

https://github.com/alttch/bma-benchmark-py

Можно забирать

Подробнее про Apache Arrow.

Arrow - попытка ввести стандарт для массивов и таблиц, особенно там, где bigdata, сделав их language-agnostic, zero-copy и со стандартными способами сериализации, десериализации, хранения и передачи. В общем то, чем не стал NumPy.

Через Arrow вы определяете сами данные, их тип, в виде одного массива или нескольких. А также отдельно схему таблицы, где эти массивы являются столбцами. Грубо говоря, если вы пишете на Rust и вам например чем-то не подходит тот же Polars (слишком много всего или наоборот, чего-то не хватает), вы можете написать свой крейт с датафреймами и без фатальных недостатков. При этом ваши таблицы и Polars (и все остальные, кто поддерживает Arrow) будут полностью совместимыми, как на уровне одного процесса, так и на уровне inter-process communication, не придется ничего конвертировать и т.д.

Единственное, что мне не нравится - Arrow имеет возможность сериализации данных либо всех сразу и полностью (в один chunk), либо в виде горизонтальных chunk'ов, вмещающих произвольное количество строк. В случае, если данные у вас приходят столбцами, выход есть - передать в потоке несколько таблиц. Но клиент должен быть об этом как-то уведомлен и при приеме все столбцы соединить обратно.

Но в целом, попытка очень хорошая, в данный момент Arrow существует под все популярные языки, причем под Rust даже сразу несколько версий на выбор. На Arrow переходят все серьезные проекты, включая Pandas и TensorFlow.

Если вы собираетесь начинать работать с Apache Arrow - ни в коем случае не начинайте с Polars.

Там Arrow со своим Луна-парком.

Предсказуемо, если в Polars загрузить массив с типом TimeStamp(TimeUnit::Second), всё ломается к хуям и вы попадаете в 70е. Привет Элвису.

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

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

Через пару лет в Rust наступает полное прозрение, когда ты пишешь генерики и лайфтаймы и тебе доставляет удовольствие, что компилятор жрет их с первого раза. А если не с первого - ты сразу же понимаешь все ошибки и уже не бегаешь в гугл. Я пока не придумал, как вставлять в простые задачи GAT'ы, но знаю, что рано или поздно перейду и на это дерьмо (ц).

У нас много JSON-RPC на серверах и я постоянно пишу мелкие куски клиентского кода, которые что-то дергают или тестируют. Поэтому решил написать крейт, который делает это максимально просто.

https://github.com/alttch/bma-jrpc

Идея - написать один минимальный трейт с процмакросом сверху, по которому автоматически создастся маппинг методов и прочего.

Собственно, идея спионерена у https://github.com/paritytech/jsonrpc, только упрощена до максимума и добавлен MessagePack, как вариант сериализации. Можно также дергать отдельное поле из response, не создавая всю структуру.

p.s. вот сюда я действительно пробовал засунуть GAT'ы, но получалось диковато.

p.p.s. внезапно, половину проц макроса мне написал ChatGPT. он очень неплохо работает с syn/quote.