Book

GNU Hello, Linux Config и scaffolding

Пришла идея создать визард скелетов проектов на основе билд-системы ядра линукса:

- Пускаем make config. Он спрашивает язык-платформу-фичи-способы реализации тем же туем, что и ядро, но с другим файлом опций, и получаем Config.h
- Пускаем make. Который на основе конфига и шаблонов лепит проект. Шаблоны причём можно первое время прямо препроцессором С делать.
- PROFIT!

Мы убили двух коней:

- возможность создания "больших" скелетов - сразу с CI, тестами, эксепшенами в sentry.io, линтом, конфигами IDE и т д
- сочетания unopinionated гибкости и presets, выбранных умными людьми за нас. Если вам нравится пресет, но у вас условный HIPAA, и слать данные каким-то хуям с горы типа DataDog и Sentry вам нельзя по комплаенсу - отключаете галочку.

Как выглядит скелет проектов здорового человека, можно посмотреть на примере GNU Hello. Это такой Hello, world!, но у которого есть man, парсер командной строки, интернационализация сообщений, компайл-тайм опции и т д.



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

Ну и вот язык LinuxKernelConf, на котором задокументированы опции ядра и зависимости между ними, https://zippel.home.xs4all.nl/lc/ по идее достаточно зрел и функционален, чтобы все эти варианты описать. А затем это вопрос шаблонизатора всю эту логику заимплементить. Ну и прослойка make позволяет делать это более-менее языконезависимо.
Book

Веб-фреймворк на Расте/wasm

https://yew.rs/docs/en/getting-started/build-a-sample-app

Помимо прочего, видно, что тулинг уже приличный. Можно например системные модули для ноды писать, и условный zstd-wasm лепить, который будет работать на Винде и в Андроиде без приседаний.
Book

IDE-fu

Два вопроса:

1. А есть ли какие-нибудь хорошие курсы-туториалы по WebFront? Так, чтоб я научился в те фичи, из-за которых всё остальное говно, и ради которых стоит брать именно вебфронт. Я тут вижу что есть люди, которые не могут в IDEA, и есть которые не видят смысла в чём-то другом. Я хочу перейти во 2 категорию. Ну и если вы вдруг не считаете IDEA революцией лучше не разводить срач. По моей текущей гипотезе вы просто в 1 категории пока.

Ну и если например TC значительно хуёвее Жабы (или Го) в плане поддержки IDEA, настолько, что ускорение, достигаемое в Жабе, не переносится на ТС, хотелось бы научиться в Java/Go+IntelliJ. Чтобы понять что мы (я и гребцы) теряем.

2. Есть ли у кого-то сетап neovim+coc+ts, такой, чтобы тултипы не были вырвиглазными. Поделитесь nvimrc.

Upd:



Вот тут код тётка "пишет код рефакторингами". Обратите внимание, как мало она печатает. В реале всё ещё быстрее, оно выглядит, как сцена с неправдоподобно быстрым ковбоем из "Blazing Saddles". Хлоп-хлоп и 6 классов и гуй. А я только придумал, как главный файл назвать. У вас такие товарищи есть?
Book

Открыл для себя Chevrotain JS Parser

https://chevrotain.io/docs/

пример кода chevrotainEmbeddedParser.js. Это для бенча в браузере, поэтому там нет модулей, а так есть.

Ну и он накручивает круги вокруг конкурентов, включая внезапно парсер-генераторы. ~4x быстрее.

Что конечно абсурдно - т.е. это перфоманс-баг либо в бенчах, либо в кодогенераторах парсер-генераторов. Но для любителей "надо просто неправильное заменить на правильное", которым заодно надо реально парсить, а не "регулярками" (Chevrotain использует регулярки, разумеется), сгодится!
Book

Открыл для себя npmtrends.com

https://www.npmtrends.com/

Позволяет сравнивать график даунлоадов по пекеджам и некоторую другую статистику в табличке.

Удобно, потому что основная задача менеджера - это прикрывать себе жопу в части выбора технических решений. Использовать зрелую популярную либу - это no-brainer, a get out of jail free card. Даже если это говнище типа zlib или request в эпоху расцвета.
Book

Первый случай в моей карьере

Microsoft Edge Dev Version 91.0.838.3 (Official build) dev (64-bit) вешается при отправке комментария на гитхабе. Все окна всех табов. Один процесс отъедает 100% одного ядра. При его убийстве весь Эдж убивается, при переоткрытии разумеется восстанавливает табы.

И это новый Эдж на Хромиуме, а не старый. Но к оправданию MS developer preview, а не релиз.

Это так смешно, что даже грустно. Ору.
Book

Тайп-фу на TypeScript

https://github.com/ThomasAribart/json-schema-to-ts/blob/master/src/parse-schema/object.ts

Если вы не поняли, там парсер типов на коде уровня типов. Берёте жсон-схему, делаете из неё объектный литерал. Ну и дальше в TS есть способ из литерала сделать синглтон-тип, населённый единственным значением, этим литералом. При этом фактически литерал тупо лифтится на уровень типов. Ну а дальше там есть функции уровня типов, примерно в том же духе с т.з. кривизны, что в С++ (но я не настоящий сварщик, детально сейчас не разбирался, но похоже на то).

Ну и в принципе это не парсер, а трансформатор одного AST в другое. На типах. Рекурсивно. В TS.
Book

Сияющий код

Мы тут слепили API на AWS Lambda PaaS. В-общем пора помечтать о "второй версии". Идея сделать некий opinionated framework, в который некий галерный раб (т.е. не второй я) будет копипастой вписывать новые интеграции. И "общую" часть, не содержащую специфики нашего сервиса, выложить на гитхаб.

Проблема в том, что сейчас оно тоже копипастой, но сделано так, что чудовищный объём клея по сравнению с объёмом смыслового кода. Хочется, чтобы была неизменная "рыба", в которую только смысловой код вписывать, и чтобы было максимально негибко, но в то же время можно было "фреймворк" выкинуть и сделать "по-старому".

Также хочется по максимуму задействовать инструментальную поддержку всяческую:

- IDEA и VsCode
- Postman
- OpenAPI Schema Validation
- AWS-сервисы типа X-Ray (но там реально ~десяток наберётся)

Притом надо сделать так, чтобы в "умный" код никто не лез. Т.е. писать для людей, для которых простыни на 700 строк это "просто", а заменяющие их 7 строк - это "зачем так сложно, когда можно просто..". Бить их так сказать их же подходом "Оно же работает? не трожь!". А если вдруг не работает -- то вот херачь к хуям и копипасть отсюда "простой" вариант, а дальше его своими методами доводи напильником, а потом как-нибудь я это увижу и переделаю фреймворк как надо, чтобы новый код в него вписался.

Кроме этого базовые вещи внедрить:

- CD - уже внедрён просто по техническим причинам (в PaaS напрямую не зальёшь, а если лить скриптом с машины разраба - то просто медленно ибо инет хуёвый, а нормального нет по техпричинам; поэтому деплоит всегда Гитлаб, просто вот совсем-совсем всегда, если на прод).
- CI нет из-за отсутствия тестов, которых в свою очередь нет, так как код работает в PaaS и в-основном занимается перекладыванием данных из одного апи в другой, включая ~5 SaaS от AWS. То есть нужно мокать достаточно много всего, для чего надо показать, как мокать, чтобы можно было действовать "по образцу". Ну а если не мокать то надо делать дизайн не как выйдет, а такой, чтобы можно было хотя бы что-то проверять по типу "вход-выход", т.е. "без инета" и без моков.
- Тестовый эндпоинт и тестовые планы для подключающихся. Это в принципе можно сделать через JSON Schemas, просто дав очень детальную схему того, какие варианты ответов возможны.
- Валидацию и типы по метаданным, а не простыни if request.foo == bar then throw Error. Благо API у нас высокостабильный, т.е. логично использовать в коде доку как the only source of truth, а не из кода доку лепить.
- К вопросу о доке - вcё обмазать JsDoc в формате, подстроенном под использование в IDE
- метрики, алерты и уровни логирования
- Нормальные аутентификации в ассортименте. Понятно, что всё это может быть как 4 схемы, так и 1, поддерживающая все фичи сразу. Хочется:
- Более стандартную схему, эквивалентную тому, что делается сейчас в API v1 (request body HMAC+nonce; у нас там ещё чуть хуже, по образцу того что сделано у конкурентов)
- труЪ схему с non-repudiation. Есть UK OpenBanking, там всё энтерпрайзно. Есть FAPI 1, там какие-то говно и палки в стиле OpenId/OAuth, есть вроде FAPI2 с non-repudiation, но это во-первых драфты, во-вторых там чёрт ногу сломит в спеке, как-то непонятно даже мне, долго прокуривать надо
- какую-то схему, которая хорошо поддерживается в Postman
- какую-то схему, под которую у всех давно есть либы
- сегментацию приложения в соответствии с духом рекомендаций PCI DSS. Мы-то технически можем хоть сервисную пыль сделать, но во-первых влетит в копеечку, во-вторых если везде заборы - то затрудняется работа; надо выработать какой-то компромисс и заложить его во фреймворк

По схемам хочется валидировать не только себя, но и пиров - т.е. валидировать всё (можно статистически, т.е. семплировать изредка):
- HTTP Requests от клиентов к нам
- HTTP Responses от нас к клиентам
- HTTP Requests от нас к партнёрам
- HTTP Responses от партнёров к нам