🧩 "Нодовое" программирование Node programming – языки / системы, которые позволяют визуально собирать логику кода из блоков, вместо текста.

Такое очень давно применяется в анимации и создании эффектов, но слабо заходит, например, на backend программирование.

Один из самых современных проектов и интересных проектов в этой среде – https://n8n.io

Один из самых старых и проверенных (даже мной) – https://nodered.org

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

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

⛓ Почему Kafka такая быстрая ⛓

Статья на medium Тут 2 поинта (и бонус), которые применимы ко многим кейсам:

1. Sequential I/O (Последовательный ввод / вывод) – если мы читаем и пишем в файлы (особенно, на HDD) в разных местах – это долго (100Kb/s), но если мы только добавляем записи в конец (append) и читаем записи с определенной точки и последовательно вперед, то эти операции по скорости не уступают чтению и записи из памяти (100Mb/s).

Kafka использует append-only log, где каждая новая запись добавляется в конец, а читаем мы с определенной точки файла (offset) и до конца.

2. Zero copy read (чтение без копирования) – мы хотим начать отправлять клиенту данные из файлов хранилища с определенного места. Для этого, в стандарте, мы получаем запрашиваем данные с диска в приложение (1 копия идет в OS Buffer, 2-я из OS Buffer в наше прилодение), далее мы отправляем в Socker (3-я копия), а Socket уже в NIC Buffer (4-я копия), который уже отправляет данные получателю.

При Zero copy read мы используем системный вызов sendfile, в котором указываем какой файл и откуда читать, и указываем куда его читать, благодаря чему файл записывается в OS Buffer и оттуда сразу попадает в NIC Biffer. При этом при всем даже не задействуется CPU.

III. Бонус В этом видео не сказали еще один хак, который использует Kafka:

Все данные, которые идут через Kafka, сохраняются в отдельных файлах, называемых "сегмент". Когда сегмент достигает заданного лимита (дефолтно 1Gb) Kafka создает следующий сегмент.

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

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

👢 "Сапожник без сапог" 👢

Что общего между этими 4-мя сайтами?

veed.io vidyard.com getsharex.com freescreenrecording.com Во-первых, они посвящены инструментам по создания и монтажу видеоинструкций с экрана.

А во-вторых... ни на одной из этих главных страниц нет видео с демонстрацией продукта...

Вы делаете софт, который должен помогать создавать видеоинструкции и при этом не показываете ниодной видеоинструкции... 😐

Волшебная тупость

P.S.

А вообще, кто-нибудь может посоветовать приложение по захвату экрана, которое автоматически отправляет мои видосы в какой-нибудь Google Drive?

🪐 Jupyter NoteBook на Node.js + TypeScript 🪐

https://github.com/Dionid/JupyterNotebook.ts

Иногда мне бывает нужно сделать аналитику по БД или логам (будь то выгрузка для маркетинга, тех подов или просто проверить консистентность данных)

В стандарте я накидываю кучу запросов в DataGrip / Compass / PgAdmin, но это подходит для просмотра 1-3-х запросов и тем более не подходит, если вам нужно произвести какую-то логику между запросами

Более хороший вариант – воспользоваться Jupyter NoteBook, который позволяет создать файл с исполнянемыми скриптами и все это визуализировать

Проблема в том, что он на Python и если вы хотите поанализировать свой код из TS, вам придется потратить кучу времени, чтобы самостоятельно переписать все на Python

НО Я НАШЕЛ РЕШЕНИЕ

Я использовал проект tslab и добавил поверх него немного удобств (типа env-ов и возможность добавлять кастомные библиотеки)

Вот получившийся код: https://github.com/Dionid/JupyterNotebook.ts

Чтобы было нагляднее, вот вам преза, которая показывает возможности Jupyter + tslab: https://slides.com/yearofmoo/jupyter-notebooks-with-es6-and-typescript/fullscreen

Всем мощной прокачки 💪

🐘 PostgreSQL vs MySQL 🐬

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

Статья на medium (с картинками) Одна из луууучших лекций на тему сравнения PSQL и MYSQL, так еще и с конференции моих товарищей

Коротко:

- Функционально MySQL уже догнал PSQL

- PSQL на каждый connection открывает отдельный процесс, а MySQL отдельный тред, поэтому на PSQL надо использовать PgBouncer и/или PGPool-II для оптимизации работы с connection

- PSQL и MYSQL строят запросы примерно одинаково заисключением этапа Executor, где в MySQL процедуры передаются в движок, который вы используете для таблицы, а в PSQL движок всего один, что позволяет PSQL быть более оптимизированным (он конкретно знает как устроен его движок и обращается к нему напрямую)

– Статистика на PSQL знает гораздо больше о данных, которые в нем храняться (поскольку он может собирать ее напрямую из единственного движка), что в свою очередь дает возможность оптимизатору выстраивать запросы SELECT более оптимизировано

– PSQL и MySQL используют MVCC для работы с транзакциями.

PSQL при каждом изменении создает копию записи с указанием в каком id транзакции произошли изменения и помечает этим же id старую запись, (2) при удалении указывает транзакцию. Далее при процессе AutoVacuum он очистит все данные, который были удалены ранее самой старой активной транзакции.

MySQL же всегда держит 1 актуальную версию объекта, а в отдельном месте (undo_log) создает запись с тем, что было изменено (включая INSERT, UPDATE и DELETE).

Соответственно: UPDATE в PSQL потребует больше места на диске и дольше, а INSERT меньше и быстрее, также откат транзакций быстрее. Но в целом, MySQL быстрее в операциях INSERT, UPDATE и DELETE.

– Индексы бывают кластерные (храняться вместе с данными, сразу отсортированы по нему и может быть всего один) и некластерные (индексы храняться рядом)

В PSQL все индексы некластерные + PSQL поддерживает множество видов и типов индексов.

В MySQL есть кластерный индекс (PRIMARY KEY) + поддеживает только B+ Tree index.

🔍 Audit Log для PostreSQL своими руками 🔎

https://www.bluelabellabs.com/blog/how-to-setup-automatic-audit-logging-in-postgres-using-triggers-and-trigger-functions/

В догонку к предыдущему посту добавлю способ самостоятельно сделать Audit Log.

Audit Log – утрированно, сохранение всех операций над БД в отдельную таблицу. Например, Notion проходился по этим данным скриптом и переносил эти операции в отдельные базы для шардирования

Процесс простой:

1. Создаем таблицу, где будем хранить лог
2. Создаем функцию, описывающий создание записей в этом логе
3. Создаем на каждую таблицу триггер на Update, Insert и Delete, который будет запускать функцию создания лога операции
4. Не забываем добавлять его на все таблицы

Ну и, конечно, при большом объеме данных вы можете (1) сделать несколько таблиц для записи лога, (2) иногда его чистить, (3) локально партицировать 1 таблицу на несколько.

Мощной прокачки 💪

Ссылка на статью на Medium

Как Notion шардировал PostgreSQL https://www.notion.so/blog/sharding-postgres-at-notion

Коротко:

. Шардирование – техника разбивания одного инстанса БД на множетсво (шардов) с разделением данных между ними для распределения нагрузки

. Самая большая сложность – выбрать алгоритм деления данных по шардам так, чтобы 1 запрос затрагивал только 1 шард (в идеале)

. Notion решил шардировать по workspace id, потому что по факту, если человек что-то делает, то делает только в рамках одного workspace id

. Для них оптимальный размер 1 таблицы – 500Gb, а одного инстанса – 10 Tb (это на заметку про возможности PSQL)

. Они разделили все на 32 базы по 15 схем в каждой (480 схем). Это удобно, потому что 480 делиться без остатка на множество чисел, что позволяет пропорционально увеличивать объем небольшими шагами (например, добавлять по 4 базы за раз)

. Выбрали стратегию миграции через audit log – создаетеся отдельная таблица, в которую пишут операции записи, а потом отдельный скрипт подхватывает эти записи из таблицы и применяет их к нужным инстансам шардов

. Далее у них был отдельный скрипт для проверки валидности данных, одной из его функции был Dark read (в проде при чтении данных, читаем из старой и новой базы и сверяем одинаковость данных)

. Идентификатором в таблицах это композитный ключ из id сущности и id workspace, но гораздо проще было бы сделать 1 id, в котором совместить оба этих столбца

Все мощной прокачки 💪

Статья на Medium

Видео про устройство Kafka https://www.youtube.com/watch?v=-AZOi3kP9Js

Одна из лучших лекций про устройство Kafka: чисто по делу, отлично слушается на х1.75, достаточно для получения полноценного представления о технологии

Я буду писать статью на тему реализации EDA и RPC на Kafka, но если вкратце:

EDA – каждая consumer group будет получать инстанс сообщения из топика, поэтому достаточно раскладывать разные приложения по разным consumer group и вы будете иметь возможность обрабатывать Events (единственный сложный момент – выбор количества партиций, но я бы брал число равное половине самой большой consumer группы)

RPC – создаете топик ответов (response topic) с 1 партицией и уникальным названием (между всеми инстансами) у отправителя, в header сообщений Kafka добавляете уникальный id сообщения (correlationId) и название response topic, отправляете в топик из которой читают RPC запросы (приоритетнее отдельный топик на call, но можно и указывать название call как key сообщения одного большого топика). Консьюмер прочитал сообщение, сформировал ответ и отправил его туда, куда вы прописали в headers.

Примеры реализации уже опишу в статье (а еще будет такая же статья по RabbitMQ)

P.S.

Забыл упомянуть, что самый простой способ раскрыть Kafka на K8s – это strimzi.io (прям советую)

Хотите MasterCard для оплаты зарубежных покупок, так еще и с Apple / Google Pay? Короче, я сделал себе и дико доволен, штука очень крутая:

Проект Maps.me позволяет прямо в их приложении открыть себе некастодиальный (объясню ниже) криптокошелек, создать виртуальную MasterCard и привязать ее к Apple / Google Pay.

Что нужно сделать 1. Скачать приложение maps.me
2. Перейти во вкладку кошелек и нажать что-то типа "хочу кошелек"
3. Перейти в бота по ссылке https://t.me/N2ActivationCodeBot и получить ключ активации
4. Ввести ключ активации в приложении
5. Пройти KYC (подтверждение через загранпасспорт)
6. Заплатить за карту 10$
7. Вуаля, у вас виртуальная MasterCard, которая добавляется в Apple / Google Pay и которой можно оплачивать любые международные сервисы (сработало на Airbnb и Onlyfans) и в магазинах / ресторанах по всему миру (спокойно плачу в турции)

"Некастодиальный" означает, что приватный ключ от этого кошелька лежит лично у вас, то есть вы полностью владеете данным крипто кошельком и можете делать с ним что угодно и вне maps.me

Как работает оплата 1. Вы перекидываете себе криптовалюту на криптокошелек maps.me
2. При его создании maps.me берет разрешение на снятие с него денег
3. Европейский банк создает вам MasterCard счет и связывает оплаты по нему с вашим криптокошельком
4. Когда вы оплачиваете по MasterCard, они списывают деньги с криптокошелька на свой, а сами переводят фиатную валюту (доллары / лиры / евро и т.д.) продавцу

Причем курс 1$ к 1USDC.

Как перевести на него деньги USDC – основная криптовалюта кошелька, но через Binance нужно переводить, используя BUSD.

Сначала про конвертацию фиата (может быть неочень понятно, за разъясненими пишите в комменты):

1. Binance – самая удобная площадка
2. Регаемся, проходим KYC по заграну
3. Заходим во вкладку P2P (это доска объявления о продаже / покупке валют)
4. Там выбираем банк для перевода (Тинькофф точно работает)
5. Выбираем продавца и покупаем BUSD (сейчас курс 65 руб за 1 BUSD)

Если у вас USDT:

1. Заходите в Binance на вкладку "trade"
2. Выбираете справа вверху "market"
3. Выбираете BUSD
4. Покупаете сколько нужно (курс 1 к 1)

Теперь как перекинуть:

1. В приложении maps.me копируем адрес криптокошелька
2. Заходим в spot, нажимаем withdraw
3. Выбираем USDC
4. Вводим адрес и сеть Solana
5. Вуаля у вас бабки на кошельке

Есть вопросы? Пишите в комменты

Абстракция ООП vs Pattern Matching ФП По-немногу начинаю приходить в себя и возвращаться в строй, решил запилить короткую статью с интересным примером отличия ООП и ФП

Чем больше я использовал Pattern Matching, тем больше в него влюблялся и осозновал, что практичнски всегда есть возможность отказаться от "абстракции" / "обобщения" и остаться в плюсе

Ссылка на статью _